Tackling Y2K and JES with OS/EM

Three companies find a potential solution to their Year 2000 and Job Entry Subsystem issues with Trident Services' Operating System/Environment Manager.

Since the first release in 1974 of the Job Entry Subsystem (JES) by IBM, systems programmers have depended on the facility - and on custom-developed code modifications and job control "modules" written in house using IBM-supplied EXITs - to optimize JES functionality for their particular environments. For many, the legacy of customized modifications to JES are now proving a stumbling from the standpoint of code maintenance, operating system upgrades and Year 2000 compliance. In fact, there were two versions of JES initially, JES2 and JES3, coming from different development efforts within the mainframe developer’s software shops. Of these, JES2 was the more widely distributed.

Mods Used to Customize Capabilities

Originally, JES2 provided a user interface to the job scheduling control facility of the mainframe operating system, responsible for managing the spooling of job control cards and printout. JES2 did not actually manage the allocation of real resources to specific jobs, but instead worked with Initiators and Allocators to select and execute jobs spooled to a queue.

JES2 was understood by IBM to provide only baseline capabilities to customers. For this reason, it was released as source code, and later with predefined user EXITs, to permit its modification and customization to meet the needs of the specific customer organization. One of the more noteworthy developers of custom modules was Mellon Bank in Pittsburgh, PA.

By the late 1970s, Mellon Bank was already running multiple mainframe systems and a robust printing environment that could not be supported adequately by vanilla JES2. System programmers at Mellon Bank modified IBM’s JES2 source code and produced new job scheduling and symbolic routing capabilities that pre-dated IBM’s own modifications to JES2 in these areas. Subsequent modifications added such advanced capabilities as dynamic resource naming, sophisticated job selection criteria (using advanced checking of resource availability), specialized printing formats and a host of other useful features. These modifications became known as the "Mellon Bank Mods" and enjoyed fairly widespread distribution through IBM’s user organization, SHARE.

Mellon Bank was not alone in its customization of JES2. In nearly every IBM shop, visitors found that customized modules had been defined for any number of purposes –- each specific to the subject company’s needs and often to address the shortcomings of the job entry subsystem in a multi-system environment.

Eventually, IBM’s own JES2 development efforts caught up with evolving multi-system environments of the 1980s. Some of the functionality inherent in many EXIT mods was co-opted into IBM operating system and JES2 releases as part of the vendor’s Parallel Sysplex development efforts. However, many companies did not migrate to later IBM releases. In many cases, they sought to preserve their investment in carefully-constructed EXIT user mods that had performed adequately to meet their job entry and execution requirements for many years.

Today, those companies are discovering that user EXIT mods are a potential point of failure in batch and online job execution. At issue is Year 2000 compliance. As with other code, user EXIT modules that perform date calculations could be sensitive to Year 2000 issues. JES2 itself was made Year 2000 compliant by IBM as part of the 5.2 release of MVS and with Version 1 Release 1 of the IBM’s OS/390 operating system. For companies that refused to upgrade their JES2 in the past, Year 2000 issues now put them between a rock and a hard place. Their alternatives are simple: upgrade JES2 to its Y2K compliant version and assume potentially costly rewrites of custom-coded EXIT modules and other JES code modifications, or risk losing key functions on or about Midnite on January 1, 2000.

Enter OS/EM

To Emma Paoletti, Systems Programmer/Analyst with CTB-McGraw Hill (Monterey, CA), the dilemma is real and the clock is ticking. CTB is responsible for processing the results of standardized tests issued to elementary, middle and high school students throughout the US. Says Paoletti, the processing of test scores and the printing of reports is nearly entirely automated and represents an average of 65,000 batch jobs per month, running on the company’s 161 MIP, IBM MVS/ESA platform.

"Of these jobs, at least 50% use Mellon Mods. The tests we receive are scanned onto tape, then put on the mainframe, and using the Mellon Bank Modifications and JES2, the batch jobs are submitted, numbers are crunched and the output is directed to printers. The Mellon Mods are used to ensure that resources are available before the jobs are run."

Paoletti says that the heavy dependency of CTB on the Mellon Mods, which the company has further modified to meet its requirements, have prevented CTB from upgrading JES2 to the Year 2000 compliant version in the past. However, with the potential impact of Y2K coming into increasing focus, the company had to seek a solution, "We knew we needed to go to the Y2K compliant version of JES2, but we had developed our JCL to use the Mellon Mods Job Scheduling and Controls so much that it would be very difficult to adjust all of our batch processes and JCL to the change."

Two months ago, Paoletti found a potential solution in the form of Trident Services (Sausalito, CA) Operating System/Environment Manager (OS/EM) product. Says Paoletti, "OS/EM provided us with a way to upgrade our JES2 while leaving the Mellon Bank Mods functionality in place. It has saved us an enormous amount of time that would be required to go through our JCL to find the Mellon Bank Mod JCL statements, and rewrite them. Instead, we leave the Mellon Bank Mod JCL statements where they are and OS/EM provides the required Mellon Bank Mod function in JES2 5.1."

Paoletti says that OS/EM is transparent to users, "The /*BEFORE, /*AFTER and /*CONTROL statements in the JCL that typically identify a Mellon Bank Mod Job Scheduling and Resource Routing Function are automatically interpreted by OS/EM and executed as an equivalent function (to the Mellon Bank Mods) in the new JES2. We have tested the solution for two months and will put it into production next month."

Paoletti’s positive results with OS/EM testing are echoed by Jim Erwin, Senior Systems Programmer with MCRB Service Bureau in Chatsworth, CA. MCRB supports more than 100 customers with outsourced processing and Year 2000 compliance testing services. Their mainframe platform provides more than 6,000 MIPs for customers.

Originally, says Erwin, Mellon Bank Mods used in some customer outsourcing systems were creating an obstacle to planned upgrades to Y2K compliant JES2, "We were moving from MVS/ESA to OS/390 and we wanted to come up to the current version of JES2 at the same time. We were looking for a way to replace the Mellon Mods, when we received some literature about OS/EM in the mail. We decided to try the product and finally upgraded JES2 with OS/EM about four months ago."

Erwin says that OS/EM required no JCL changes to support the Mellon Bank Mod customer’s, "We haven’t needed it except for one file involving the opening and closing of VSAM files under CICS. There was a routine that would close and de-allocate VSAM files after a certain job was complete. The problem was, if two people opened the file at the same time, we would have to bring down every region to fix the system. Now, OS/EM delivers the capability to execute the mod smoothly under the new JES2."

Erwin says that MCRB continues to use OS/EM to support customers involved in Y2K compliance testing of systems. The product provides support for special modifications that each customer has made to his existing Job Entry Subsystem in a multiple LPAR environment.

Bob Costello, Technical Support Manager for the CCF Data Center within the Federal Systems Division of Unisys Corporation, shares Erwin’s need for a standardized JES2 EXIT mod handling capability within a diverse client support environment.

Says Costello, "We provide claims processing services for state and federal medical insurance. We have been consolidating data centers and claims processing business from Massachusetts and Kentucky at our California site. Basically, as a part of consolidation, we have been converting systems or replacing them entirely to ensure compliance with Year 2000."

Costello says that OS/EM was acquired a year ago to facilitate the integration of existing claims processing systems into the consolidated mainframe platform at the CCF Data Center "until their existing JES2 EXIT routines could be reviewed for Y2K compatibility."

"We liked how OS/EM handled EXIT routines and the fact that it supported both MVS/ESA and OS/390 operating systems," notes Costello, "We used the product to generate reports on performance and to identify EXIT points taken by coders who wrote the systems we were consolidating. Then we analyzed the EXITs and either revised them for use with the latest JES2 or retained the function using Extended Functions supported by OS/EM."

Costello adds that OS/EM created another important capability for Unisys, "There is often confusion in consolidation scenarios. Different groups of people whose applications are being consolidated have different ways of doing things. We realized that OS/EM could be harnessed to help us to establish and enforce some control policies."

Says Costello, using OS/EM’s Extended Functions check submitted jobs against the mainframe security facility, ACF2, in order to establish and enforce job classes, "Basically, before a tape (or non-tape) job is executed, OS/EM Extended Functions check to see whether the requestor is authorized to submit jobs to certain job classes. This provides a way to enforce regions and job class rules that is pretty easy to set up with OS/EM and very reliable."

Costello says that the OS/EM product was put into service approximately three months after it was acquired, and only after extensive testing had been performed, "Trident Services’ support has been very good. They have been very responsive to our requests for enhancements to their product."

Trident Services Bridges JES2 Gap

"OS/EM," says Trident Services Chief Architect, Tim Humphreys, "was designed to be a kind of systems-programmer-in-a-box. Support for Mellon Bank Mods and other custom EXIT modifications as companies upgrade to newer operating system and JES2/JES3 versions is probably the first reason that customers have for acquiring the product, but it is actually capable of much more."

OS/EM, says Humphreys, provides extensive controls for valuable enterprise server resources. Throughput management is implemented using a complete set of enterprise standards control functions, "You can schedule jobs and dictate what resources the job will run with. You add and delete resources through JES2 Operator commands, or you can automatically associate resources with certain types of jobs. This is very important, especially in a large sysplex environment."

Says Humphreys, OS/EM provides full support for all Releases of MVS/ESA through OS/390 Release 2.5 and is fully year 2000 compliant. The time and expense of developing, testing and implementing system modifications is eliminated. The need for production Initial Program Loads (IPLs) when adding or modifying EXITS is also eliminated.

And, of course, OS/EM replaces the Mellon Bank Mods and similar EXIT modules and JES2 code modifications without the requirement for extensive code reviews and rewrites. Humphreys notes, "Source code updates and modifications represent an exposure every time you do PUT maintenance. With OS/EM using ISPF, you can set options in OS/EM’s Base Exit Management and Extended Functions for user mods and other built in OS/EM Extended Functions in a Y2K safe OS/EM environment. You can also REPLACE many mods and enable corresponding options directly in OS/EM. OS/EM incorporates about 95 percent of what people do with mods."

According to Humphreys, OS/EM replaces all IBM-supplied JES2, JES3, RACF, DFHSM, TSO/E, SMF, DFP, ALLOCATION and ISPF Installation Wide EXITs with its own control processor. The OS/EM control processor is installed at IPL time, then dynamically loads and processes all EXITs whether user-written, software loaded or generated using OS/EM itself.

Says Humphreys, the product installs in three to four hours, "Replacing user mods with OS/EM Extended Functions usually goes very smoothly provided that the systems programmer or analyst has analyzed what the old mods were doing, not necessarily where they were doing it."

Once installed, all of OS/EM's features are invoked and driven by easy-to-use ISPF menus designed for use by operations and management personnel with a minimum of support from the systems programming staff. Humphreys adds that technical support staff are available to assist customers who need help turning on various product functions, "The information is in the manuals, but we can save them some time in getting everything configured the way that they want if they call the technical support line."

The Bottom Line

OS/EM is pronounced "awesome" by its end users, perhaps in part because of the powerful "fix" it offers to the dilemma of customized JES2/JES3 and Y2K compliance. Users of the product are unanimous in their praise of both the product and its support from Trident Services. With each installation, Humphreys claims, the portfolio of uses for the product is building steadily.

As the most tenured product in a growing field of Y2K problem solvers for mainframe subsystems, OS/EM is an important solution for companies that, in the words of one integrator, "have not been responsible IBM customers and kept up to date with the latest versions of JES." With OS/EM, the decision of whether to re-invent code modifications and EXIT mods at a labor cost of hundreds or even thousands of hours or to face Year 2000-related job execution errors just got simpler.


ABOUT THE AUTHOR:

Jon William Toigo is an independent writer and consultant specializing in business automation solutions. He is the author of eight books and more than 500 articles on data processing and internetworking. He can be reached at (813) 736-5367, or via the Internet either at jtoigo@intnet.net.