|
 |
Trident Services:
In The News:
|
TRIDENT
SERVICES
Tackling Y2K and JES with
OS/EM
by Jon William Toigo,
The Enterprise Systems Journal, Dec 1998.
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.
|
|
|
