IBM Mainframe Forum

I am relatively new to the mainframe and have a basic question. What are the best conventions to move JCL to production? We have many test regions and many production regions. I would like to create the JCL once in test and be able to copy it to all production regions without changing it for each production region.

On other platforms (client server, midrange) we would either make the JCL (or equivalent) read a configuration file/database to get the correct parameters. I have also heard of some teams developing a system that will automatically change the JCL as it passes from test to production or from production to test. With the limitations of JCL the first approach does not appear to be an option. Any creative ideas would be welcome.

Bob

Hello and welcome to the forums,

I would like to create the JCL once in test and be able to copy it to all production regions without changing it for each production region.

If the proper naming standards are in place this may be accomplished quite easily by putting all jcl in cataloged PROCedures and having a symbolic parameter to identify the environment (i.e. test, uat, qa, prod, etc.).

Done properly, the only differenc between a production execution and some other execution is the job name and the environment parameter.

I have spent years convincing organizations that changing the job stream as part of every promotion means the first production run is actually just a test. . .

I appreciate the response and fully agree with your sentiments on testing in production. This is the first system I have worked with where we literally put hundreds of pieces of code (JCL) into production without the ability to test. I will discuss your comments with the rest of the team since they have more mainframe experience than me. I may be back for a few more pointers.

Come back anytime

There is usually someone "here" (or soon will be)

This is the first system I have worked with where we literally put hundreds of pieces of code (JCL) into production without the ability to test.

I've been a "migrant data worker" for many years and i am still amazed at the number of places that have no source managemrent / promotion infrastructure. And they cannot seem to realize that their lack of such is why there are so many production problems.

Good luck,

d

Every site has its own, unique, process. Any comments we make may be inadequate. You will discover this is more complicated than meets the eye. Some of the issues are

• Data set names.
• Longer run times. Production jobs generally chew on more data than test jobs, so they're more likely to get S322 ABENDs
• Data quality. Quite often the data going into production jobs is "dirtier" than the data going into test jobs, and this often causes problems if the programs don't adequately test for "dirty" data.
• Use of tape. Production jobs tend to use tape for their data repository; this causes unexpected issues in JCL. Not that tape is difficult, but its implementation in JCL is not as similar as the JCL for disk as one might like.
• Offsite requirements with tape. Many shops want backup production data transferred offsite. This has impact in the JCL that can cause difficulties. This is particularly true for shops that use "virtual" tape; the backup data must go to real tape, and this can have unexpected difficulties in JCL.

Back in the 1970s I'd watch the operators "hang" what many people now call "round" tapes onto the tape drives. Their job was often made more difficult because of poor JCL. An experienced analyst who understood the messages could often see problems by examining the JESMSGLG data set, but this was rarely done. I often thought it would be useful to break the rules and bring the programmers onto the floor to watch their jobs being run, but I eventually realized this was basically impossible because of the amount of "noise" from other jobs being run in parallel with their job. Now this is impossible; most shops use tape libraries holding cartridge type tapes (sometimes called "square" tapes) or "virtual" tape, or are at least using tape loaders where "scratch" cartridges are placed into a stackers on the front of real tape drives. In other words,there isn't much to see.

The data quality issue is not a JCL issue; the other issues do have JCL impact that is often hard to predict. Run time issues can sometimes be resolved in the programs; detecting possible problems in test can be difficult; they always seem to be in places that were hard to predict in advance.