Planning for a JES3 to JES2 migration
This chapter focuses on the planning aspects of a migration, including positioning activities that would make the transition easier.
In this chapter, the following topics are discussed:
•Planning
•Choosing a target system
•Migration process
•Functional testing
•System and integration testing
•Implementation
If you are not familiar with the details of JES2 and JES3, the rest of the chapters in this book discuss them so that you can see the differences. You might prefer to read those chapters first to get familiar with the terminology before reading this chapter.
 
Note: While we cannot cover all possibilities in this chapter, it will serve as a guideline for migration.
 
6.1 Planning
After you decide to proceed with migrating from JES3 to JES2, you will want to use the information gained from the discovery analysis as input to the planning phase. There are several ramifications to converting to JES2. Some are easily managed while others could be more challenging.
One of the initial activities in setting up a migration process is to form the project team. This is important for the standpoint of having continuity and representation for certain areas so the project has a higher degree of success. This starts with the management commitment as mentioned before. Suggestion for appropriate personnel are as follows:
•Project sponsor: Usually an executive that has overall accountability for the project
•Project manager: Help manage project scope and deliverable
•System programmers
 – z/OS (both JES3 and JES2)
 – ISV system programmer
 – Subsystem technology towers
 • IBM IMS™
 • CICS
•Storage engineer
•Security person (RACF, ACF2, or Top Secret)
•Performance engineer
•Operations staff
 – Remote
 – Systems automation
 – Print shop
At some point, there is the need to align this project with the business areas of your company that will be impacted by this migration. Even before the project starts, it would be a good idea to review the process out with several business areas to gauge their interest and allow them time to make ready for system and integration testing.
In addition, you want to create a checklist of component items that need to be validated once the initial target JES2 system is available. This checklist is used at each phase of the migration as new target JES2 systems are built in each environment such as Sys Prog test, Test/Dev, and Production.
6.1.1 Positioning moves
Where possible, position the installation to use more JES2 compatible facilities such as the following:
•Use // OUTPUT JCL instead of //*FORMAT.
•Plan to move to z/OS V2R1. Earlier versions of JES2 were limited to one-character job classes, while JES3 supported eight-character job classes (as does JES2 in V2R1).
•Use multiple console support (MCS) instead of JES3-managed consoles.
•Try running without JES3 deadline scheduling, device pooling, MDS, Generalized Main Scheduling (GMS), and DJC. Use a scheduler such as IBM Tivoli Workload Scheduler (TWS), CA-7, or ESP, to help manage scheduled workload.
•Try getting rid of as many JES3 mods as possible.
•Use SDSF within JES3 to start to familiarize everyone with how it interacts with output.
•Remove “Tape and Disk set up” high water mark thresholds:
 – Use WLM and job schedulers to manage this instead
 – In the JES3 inish deck, under the STANDARDS section, replace SETUP=THWS with SETUP=NONE. This helps with making the JES3 more JES neutral.
•Convert from JES3 managed volumes to SMS-managed volumes.
•Minimize JES3 mod, exits, and user DSPs.
•Migrate from JES3 DLOG to OPERLOG.
•Migrate SNA/NJE to TCP/IP/NJE.
•Stop all spool browsing and modify spool job control from z/VM. In most cases, this is handled using SDSF in JES2 along with other ISV output processing and archiving products.
Another benefit to do implementing the items mentioned, is it can help in managing your installation to become more JES neutral. This is especially true if it appears that a migration will take a significant amount of time to implement. Perhaps the funding will not be there until the following year for example. In addition, moving to a JES-neutral configuration as much as possible can contribute to operational excellence by simplifying over all systems management.
6.2 Choosing a target system
One of the first items to decide is what the target JES2 system will look like. If the installation is not running any system currently with JES2, you will need to plan for installing it separately. Fortunately, JES2 ships as part of the base z/OS product. Therefore, it will be fairly easy to create.
The process to identify applications slated for the target system is straightforward to figure out. Choose whichever applications are currently running on the JES3 system that is the subject of the migration. At a high level of the planning process, there are a couple of alternative approaches to migration from JES3 to JES2. These alternatives include:
•Initially setting up a secondary JES2 under JES3. This can provide experience without the need to set up a new LPAR.
•Creating a new target LPAR with JES2 and migrating by some criteria such as application or application groups and migrating in a phased approach. This approach is less disruptive for application systems.
•There is also the “all at once” or “Big Bang” approach by which JES3 is quiesced having the new JES2 components, Spool, Init decks built. When the old spool is drained, the new JES2 system is started in its place. Of course, one would have already tested all the applications for the new target system in a JES2 test/dev environment first.
For the purposes of this book, we focus on the phased application system migration.
It is perfectly fine to run multiple JESPLEX within the same Parallel Sysplex. These can be run using two different JESPLEX (JES2 and JES3) or the same JESPLEX (JES2 and JES2) in a single Sysplex.
Choosing the correct mix of IBM and ISV products to replace like kind functionality will be dependent upon goals, resource personnel availability, and cost considerations. Some ideas are as follows:
•Base JES2 with minimal installation exits
•Highly customized JES2 with complex exits and user mods
•Additional IBM products
•Additional ISV products
6.2.1 Storage management
At some point in the planning for migration, you will want to engage the storage management group to verify a few items. At this point, you need to understand the number of jobs per day, the size of the input and output, and have defined an appropriate checkpoint and spool for the replacement configuration. Some items to discuss with the storage group include:
•SPOOL allocations and management.
•Any vendor-specific products that might be interfacing with JES and SMS.
•Deciding on how storage device allocations with be handled such as job tape setup, device sharing, and removing single points of failure.
6.2.2 Education
As part of the migration, it is imperative to provide some level of education for your system programmers, application developers, and operations personnel. IBM has an assortment of educational training available, both in class lectures and web-based content. There are classes on implementation and customizing JES2, including SDSF, and RACF considerations. See the following website for more information:
6.2.3 Vendor management
As part of a migration to JES2, contact the ISV vendors to check if there are any issues, technical or licensing, that need to be addressed. Since JES2 is a base-delivered JES with z/OS, this is normally not a problem. However, it is better to review it early rather than during implementation.
Check with the system automation and scheduler software personnel in your installation for any products that might be JES3-specific. There could be some potential cost savings. Also, check with any products that interface with storage, either tape or DASD.
6.3 Migration process
This section of the chapter describes the migration process and focuses on reaching the goal of a running workload in the new JES2 system. This section covers the following topics:
•Setting up JES2
•Functional testing
•System and integration testing
•Implementation
6.3.1 JES2 setup
The recommendation would be to move from JES3 to JES2 in as nondisruptive manner as possible. This entails setting up a new target JES2 system and migrating applications in a controlled manner.
The migration would be slightly easier if your applications support data sharing because that lets you move jobs from one LPAR to another on a job-by-job basis.
IBM does not support running JES2 and JES3 in the same LPAR (though it has worked with no issues). It is supported to run JES2 and JES3 in the same sysplex. To move spool files from JES3 to JES2 or vice versa, the only option is NJE; spool offload files are not transportable across JESs.
As mentioned previously, it depends on what your installation requirements are regarding how to install and test the new target JES2 environment. Regardless of the method, when the new JES2 image is initialized, the way to share workload or functions between the JES3 and JES2 images are by means of NJE. Obviously, you will want to do this in a System Programmer “sandbox” environment first.
Based on the output from the discovery analysis phase, map out and install JES2 exits where appropriate. In addition, you will want to review and set up the JES2 Initialization deck. You might want to also review the CBT tape for mods. Another thing to review in the JES2 setup are system management changes from JES3 to JES2. Table 6-1 provides a model table for you to track your review plan.
Table 6-1 Sample review plan
Functional areas for review
Resp. group
Time Alloc.
Completed
Job management changes and testing
 
 
 
Configuration and definition
 
 
 
System initialization
 
 
 
Security changes and testing
 
 
 
Reliability and serviceability
 
 
 
Exits and mods (might attach separate table)
 
 
 
Automation tools configuration and testing
 
 
 
Initialization deck changes
 
 
 
To ensure timely and consistent conversion of your JES3 jobs to ones that run cleanly on JES2, you need to develop a program using the output from the discovery analysis phase and map the functions and components that have been identified for migration.
A useful document would be Introduction for JES2 System Programmers. See this SHARE presentation:
Below is a list of pre-work items to complete during JES2 setup:
•Create new JES2 SPOOL packs.
•Stage JES2 configuration with mapped SPOOL, NJE, and OUTPUT classes.
•Stage SPOOL Management regarding initiators, example AM/PM initiators, if applicable.
•Rework all ISV products that have JES3 SPOOL offsets and JES3 specific parameters. Examples are CA-View, XPAF (Xerox), and Mobius. Also, SDSF if you are not (yet) on z/OS V2R1.
•Stage new WLM policies with only single character job classes (for z/OS releases earlier than V2R1).
•Stage RACF, security, rules for JES2 congruent with JES3.
•If your installation is not using an ISV product to assist in DJC, you will need to verify that the job mapping has been complete within your installation’s scheduler such as TWS or CA-7/ESP.
 – Include NJE route conversion and other needed JECLs identified from the Discovery Analysis phase
•Review how external JCL/system cards/operation prod control will be handled.
•Communicate “Dataset not found” behavior change for jobs. This has to do with the difference between the way JES3 and JES2 handle data set availability. JES3 performs checking at job initiation time, whereas JES2 performs this on a STEP boundary.
 
Note: For installations that use an output archiving product such as CA-View, some thought around handling output and viewing will need to be addressed. For example, CA-View(SAR) parses for//*MAIN and then looks for USER= relative on the same line to output the job to a common SYSID, like a TSO user ID. Under JES2, that parsing will still occur but no action taken since there are no //*MAIN cards. This is another example of why to contact ISV vendors for special handling of existing functions and how they might work under JES2.
6.4 Functional testing
In bringing up the new target JES2 system, you might want to start things manually to gain insight to how the new system works. The next thing that you will most likely want to do is to set up automation of certain procedures and processes. When the new JES2 image is up and running, you will want to familiarize yourself as well as others in how jobs and subsystems interact with it.
While in this mode of testing, it would be prudent to check out how the base components are functioning. Some of the things that will need to be verified are listed here:
•Jobs running in the appropriate classes
 – Are WLM policies working as expected?
•Validate scheduler functionality
•Validate any output/archiving product functions
•Test tape handling and execution
•Verify automation is functioning correctly
•NJE validation
•Verify external feeds are working (might not be able to test until next level)
•Validate that GRS/MIM is functioning correctly
•Test TSO/E interface along with SDSF
•SPOOL off load
•If possible, making a dry run of this migration in a Disaster Recovery test environment would be beneficial
Table 6-2 shows a body of testing functional areas. Some of these might not be able to be tested fully until there are applications brought into the target system.
Table 6-2 Sample test plan
Functional testing areas
Resp. group
Time alloc.
Completed
Job management and tracking (schedulers)
 
 
 
Validate resource management tools
 
 
 
Accounting software
 
 
 
Security functioning as expected (RACF, ACF2, and so on)
 
 
 
Automation tool validation
 
 
 
ISV products
 
 
 
TSO/E usage
 
 
 
SDSF functions
 
 
 
Application group “A”
 
 
 
Application group “B”
 
 
 
6.5 System and integration testing
The next stage of migration is to move and create the similar JES2 system in the Test/Development environment. In this environment, you will then want to stage applications in for testing. This will be the application areas’ first opportunity to do their functional testing.
In this phase of the migration, there are some other job behavior and processing aspects that will need to be validated. These items include:
•Handling of GDGs
•Data set locking
•Data set enqueuing
•Job C/I setup and execution
•Using cataloged procedures
•Job Abend and back out processing
•Validate RACF or Security rules are working
•Test SPOOL off load including fall-back scenarios or make this a clean-up activity
In addition, do some performance/stress testing of the new JES2 environment. Table 6-3 shows some example items.
Table 6-3 Performance and stress test items
Task
Resp. group
Time Alloc.
Completed
Test Batch and TSO
 
 
 
Stress Test Batch and TSO
 
 
 
Online testing and Load test
 
 
 
Test Output devices, RJE, NJE
 
 
 
Weekend simulation cut over
 
 
 
Review results from simulated cut over
 
 
 
6.6 Implementation
In preparation for production implementation, there are some areas to keep in mind. This depends on the needs of your installation. Here are a few ideas:
•Make necessary configuration changes for the new system
•Migrate application systems or group of systems based on a predetermined schedule. Make a list of what has to stay together and what can be moved independently to the new JES2 subsystem:
 – Input devices
 – Execution environment
 – Output processing
 – Printing
 – TSO/E
 – RJE
 – NJE
Switching local devices, RJE workstations, and connections to NJE is fairly straightforward and can be accomplished without disruption to the existing JES3 system. However, note that for job execution, resources that were managed by JES3 will now have to be managed by z/OS for functions like GMS and MDS. Review how your installation will be using WLM regarding this. Table 6-4 shows migration cutover planning charts.
Table 6-4 Sample cutover plan
Production cutover
Resp. group
Time Alloc.
Completed
Idle current system for conversion and archive JES3 SPOOL
 
 
 
Shut down JES3 system LPARs
 
 
 
Bring up JES2 system LPARs
 
 
 
Have WLM in place to handle 36 one-character classes or equivalent WLM scheme in place
 
 
 
IVP Infrastructure
 
 
 
Dry-run test of spool transfer and fail back
 
 
 
Move over JES devices, TP lines, apps, users
 
 
 
Last-minute items from system integration testing
 
 
 
Notify users and operation of schedule for implementation
 
 
 
Cut over (first run) and IVP
 
 
 
Validate applications check out
 
 
 
Make go/no-go decision
 
 
 
Fail back if necessary
 
 
 
Clean up activities
 
 
 
 
Note: Placing //JOB cards in your scheduling package is beneficial since most of the JCL is done at that point. Any external JES3 JCL would be treated as having no job-specific class due to the JCL being treated as //* comment. Therefore, external jobs would then run as a default CLASS.
Each of the rest of the chapters contains details about migrating a specific component from JES3 to JES2.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset