3000 batch transition offers some solutions
March 30, 2010
Migrating HP 3000 sites face multiple tasks and challenges to duplicate the system's ability. But reports from customers making transitions show that the MPE/iX batch and job-stream functions are being duplicated in a wide array of solutions. It's not unusual to see such job control replacement require some customized coding of scripts.
However, Speedware's product manager Nicolas Fortin said his company's clients make commercial scheduler software work for the appropriate size of company, if manual scripting is not in a migrator's skill set.
"Some migrators are either using their own supplied concept/software for batch scheduling, or we are recommending that companies to use commercial job scheduler software with their job-converted code," Fortin said. He adds that for companies which are doing a migration themselves, he's seen them either retain the MPE JCL on the target platform (using a product like Speedware's AMXW) -- or convert the JCL to target-platform scripts. This scripting is being done manually, or aided by a tool provided by a migration solution provider.
FORTIN SAID THAT larger companies tend to use enterprise-grade job scheduler software running in the target environment.
"Either they already own one and it is their corporate standard for job scheduling, or they take advantage of the migration and modernization project to invest in one," he said. Some of these large solutions include Tivoli (while once owned the MPE/iX Maestro product) UC4, or BMC Software's CONTROL-M. Large companies own such software because they have a wide range of servers, but these solutions are usually not used with the HP 3000 job environment. MPE/iX batch and job work is unique and proprietary, so these high-grade scheduler solutions don't support 3000 job management.
The above-named solutions include Windows versions, alongside Unix and Linux options. It's the Windows aspect of job transitions that seems to spark the most manual or tool-aided scripting, among the reports we've received. The enterprise job scheduling software, if it's in place, can be extended to the system taking on the 3000's work.
"When we help them plan their migration," Fortin said, "we remind them that they could extend the use of their existing enterprise software to the new target environment -- thereby consolidating job-related functionality with one standard specific software solutions, method or process. They are usually pretty receptive to this, as it makes sense to maximize the use of existing software and standardize job-related processes across all applications."
Smaller companies can look over some commercial solutions for scheduling, too, options priced more in line with a typical 3000-only site's IT budget. Tidal, Xi-Batch, Maestro and Job Queue were among those Fortin pointed out. Tidal and Maestro already run on the 3000, although some would say these are not small-scale solutions. But Fortin notes that sites adopting AMXW can employ a default scheduler as part of that suite.
"Some are content with using AMXW's default MPE job scheduling functionality (to retain most MPE job concepts), but others choose to use part of AMXW's job functionality (so the SUBMIT jobs still work) while utilizing the native job scheduling features of the target-OS."
If that target is Windows, the native feature set provides less help than that of Unix, but it could be enough for some companies. Mike Howard of UNICON, one of the community's conversion resources, said that using a third party tool for batch management under Windows can help to fill in gaps. "Windows has a basic job scheduler which is often sufficient for most customers," he says, "but if a more comprehensive product is required, I would recommend Global ECS from Vinzant Software."
The AMXW software is designed to permit a combination of the 3000's JCL with Windows or Unix script code, "to get the best of both worlds," Fortin said. This gives a migrating company a way to retain some key MPE concepts while they employ the native target-OS script commands. He added that this can ease a gradual transition to target-OS native concepts. Like many migrations, this aspect happens in steps, sometimes needing customization.
"We encounter all kinds of scenarios, which is just another indication that there is no one solution for everyone," he said. "The solution needs to meet the unique needs and preferences of each customer, and we're fine with that; we adapt, we customize."