The right tool for moving jobs?
July 22, 2009
Migration projects cover a lot more ground than replacing app functionality. The effort needs to replicate the full range of services an HP 3000 offers. One basic building block is job management, included with HP 3000s and sometimes not simple to replace in a new environment such as Windows.
"We have been slowly converting and migrating off our HP 3000," said IT manager Gordon Montgomery of Living Scriptures, Inc. "One of the many things I will miss about the HP is the way it handles jobs. Has anyone found an equivalant to the HP's job environment in the Windows world? You know, like nice job listings of what really goes on, etc. We've been trying to make do with plain batch files, and redirecting the output to a log file, but it is just not the same. And sometimes the batch file just quits and disappears for no apparent reason."
Making Windows batch files perform as elegantly as MPE's job controls is not simple, but it can be done. A familiar face to the 3000 community, Advant's "Captain Greb," posted a few notes on using the Windows scheduler to let batch files log themselves. But there are engineered third party solutions to do this and many more MPE replacements.
The Captain reported that "I created my own job logging for Windows. From the Windows scheduler, a job is started as “jobrun something.bat”. This jobrun program executes the specified bat file and logs the results (as part of a bigger logging scheme) with date/time, program name, messages."
The 3000 community is rich with do-it-yourself moxie, but creating a job scheduler out of stock Windows parts might be a bigger task than building command files, for example. Some of the challenge is the native intelligence of the Windows components. The Captain said that his jobrun.exe program is a Visual Basic 6 executable that is "not fancy; it does a createprocess(“cmd /c something.bat”). It uses pipes to read the process output, and sends the lines to a logging routine that handles the log file IO. This is done in a loop with a 100ms delay (waitforsingleobject) so the output is written to the log file (and timestamped) as its generated."
The resume of Captain Grebs is probably far ahead of most 3000 managers. He's been the technical lead for the programming that helps any PA-RISC server boot up MPE/iX, whether that server was destined to be a 3000 or not. The G in GREBS stands for generic server.
Alas, his jobrun.exe won't be in a contributed library for community use. But others in the community have polished more complete solutions for replicating 3000 job abilities. Speedware's Senior Solutions Architect Ken Robertson suggests that "We have found that Windows’ built-in scheduler is sometimes a little flaky, and you really will need a third-party job-scheduler to do serious production work. Speeware offers this scheduling in its AMXW suite. Those letters stand for "Automated Migration to Unix and Windows." Robertson explained:
!JOB TESTJOB,MGR.FOOBY
!SHOWJOB > SJOUT
!grep “FOO” SJOUT > SJout2
!perl -f myscript.pl SJout2
!EOJ
We support true temporary files, and have an MPE-style SPOOLER, so that, yep, your stdlists appear where you think they should! The PAUSE ,JOB= works, too! Because we don’t depend upon cron in Unix, the priority and scheduling of the job works the way that it’s supposed to. Cron has issues with streaming more than one job per second, and on [IBM's] AIX, more than 60 jobs per minute. Cron also cannot guarantee job execution order for jobs scheduled in the same minute!
With AMXW we can support multiple JOB queues, streaming from inside of code, MPE CI commands, global variables, some MPEX commands, etc. etc. All the things that you’d expect to find in MPE, just running on another platform. There’s even a version of Suprtool-UX (from Robelle) that has been tuned to work with AMXW!
Mark Ranft, who's managing a large installation of HP 3000s as well as offering his services from his own Pro3k consultancy, reports that using the Windows/DOS batch tools was an exciting experience. In one payroll application, "the Time and Attendance portion had to run under DOS. I was scared to death that one of the DOS ‘job’ steps would die and I would not know where it was to restart the ‘job’. The .bat scripts I built were modular and standardized. The logging of individual executables was hit or miss -- depending on how the executable logged messages."
Just like so much in life, the job of replicating jobs for migrating 3000s looks like it has solutions worth every penny you pay for them. Choose the right tool for your stability needs.