Mainframes 360
The one stop destination for System Z professionals

Sunday, March 16, 2014

EXEC Statement

How to code the EXEC statement

A job-stream may have a series of steps to pre-process,the core processing followed cleanup or house-keeping steps. Each step is logically defined in JCL by an EXEC statement, you'd have as many EXEC statements as the number of steps. On each step, the EXEC statement identifies the program to be executed by that step.

A program typically reads data from one or more input files, includes business logic to process the data and writes the output records to one or more output files. DD statements let you specify input files, output files and intermediate work files for a program. Stringing it up together, a job-stream would have a skeleton like this.

The PGM parameter

The PGM parameter on the EXEC statement lets you specify the program to be executed. Every program is a member of a partitioned dataset. The member must be a load module(compiled code). You may execute user programs written by a developer. You may run the numerous IBM supplied utility programs - IEBGENER, IEBCOPY, IEBDG, IEWL, SORT.

The PARM parameter

The PARM parameter can be used to pass information to a program. This information is usually used to influence, control the way the program works. Many IBM supplied utilities like compilers, linkers, SORT use the PARM information for various processing options.

Here's an EXEC statement that passes three parameters to the program IGYCRCTL.

Specifying the job's execution time limit

The TIME parameter lets you specify a default processing time limit on your job. Processing time refers to the CPU time and not the wall clock time. You can specify the TIME parameter on the JOB and EXEC statements, with the exception of TIME=0 which can be used only on an EXEC statement.

You normally specify the value in minutes and seconds. TIME=(2,30) implies 2 minutes, 30 seconds. TIME=(,30) has no minutes value, a leading comma and only the seconds part and hence it means 30 seconds.

If you specify a TIME limit of 1440 minutes or code TIME=NOLIMIT keyword, no time limit is applied at all. Your job executes indefinitely. On the other hand, TIME=MAXIMUM imposes a maximum upper bound of 357,912 minutes. If you specify TIME=0 on an EXEC statement, the job step can use the processing time remaining from the previous step. If it exceeds the time available, the step will fail.

Coding TIME parameter on the JOB statement specifies a time limit on the whole job. As each step executes, its execution is added up to the job's total processing time. If the job's time limit is exceeded, the job is cancelled. On the other hand, when you specify TIME parameter on the EXEC statement, it applies to only to that job step.

There is a potential conflict when the TIME parameter on the EXEC statement specifies a greater time limit than on the JOB statement. In that case, the job's time limit takes precedence over the step's time limit.

Dividing central storage into Regions

Like a street address, a storage address(a hexadecimal number) identifies a storage location. A one byte address can refer 28 = 256 locations. A three bytes(24 bits) address can refer 224 = 16 million locations. The amount of storage a program can refer is called its address space.

Before the introduction of System/360 in 1964, computers ran one job at a time. Business and scientific applications used different sized computers having different instruction sets and operating systems. System/360 gave all IBM mainframes the same hardware architecture, so applications could run regardless of the computer model. The System/360 ancestor of today's operating system, MVT(Multiprogramming with Variable tasks) could run 15 jobs concurrently in real storage. Programs lived in variable-sized areas called regions. The system used 24 bits for addressing. Thus, programs could address 16 MB of memory.

Fig. Real storage in MVT

Under MVT, each job was scheduled based on what resources it needed. If a job needed a tape, a JCL statement would describe the tape unit. Until the tape unit was mounted, the OS did not schedule the job. This prevented jobs from sitting idle in real storage. A running job occupied a contiguous region of real storage. Users specified the amount of storage required through REGION size in JCL statements. On completion, the storage is freed. The first region contains the OS modules or the nucleus and always reside in real storage.

By the 1970's, the amount of central storage had become a critical bottleneck. Application programs grew in size. The OS evolved, gained many functions and grew to 8 MB in size. The operating system modules also required a portion of the application program's address space.

The quest for central storage

Fig. Virtual storage

In 1972, IBM introduced the 370 family of computers with a new architectural component - virtual storage. Virtual storage is an illusion, where a program thinks, it has an unlimited amount of memory to itself. The application program is independent of the addresses of central storage. Although limited to 16 MB in size, programs were stored on disk(auxiliary storage) and portions of the program were brought into central storage as and when needed. With virtual storage, a program need occupy only a relatively small part of the central storage. Programs were now also sharing data. The shared data out of a program's address space alongside OS code was placed in a common area. By the end of 1970s, another bottleneck appeared. The 16 MB virtual storage limit was insufficient for programs.

The quest for address space

Fig. MVS/XA storage

In 1983, IBM introduced S/370-XA(Extended Address) architecture. With it, addresses could be 31-bits long;the highest accessible location was 232 - 1 = 2,147,483,648(2GB). The 16M boundary between the two architectures came to be known as the line. Older programs could be marked to run in the 16 MB address space. New programs could use the entire 2 GB address space. Programs that exceeded the 16 MB address space were termed above the line. This could occur in two ways. First, a very large program could require more than 16 MB. Second, in CICS applications, since all programs run under the same address space, even a small program could be forced to run above the 16 MB line. Users had to compile and link-edit their programs with AMODE(31) option for running it above the line.

Fig. z/OS addressability

In recent years, IBM's zArchitecture defines 64-bit storage addresses. A 64-bit address can refer 18,446,744,073,709,551,616 locations. A program on the z/OS can therefore run in 24- , 31- or 64-bit addressing.

Specifying the job's storage limits

The REGION parameter is used to specify the maximum amount of real or virtual storage. It does not acquire memory, but merely specifies an upper bound. You can code the REGION parameter on the JOB or EXEC statement. If you specify it on a JOB statement, the region size applies to all the job steps within the job and overrides any step limits. You can specify the region size in terms of Kilobytes or Megabytes.

Internally, the z/OS maintains a 24-bit(below the line) maximum and a 31-bit(above the line) maximum. The REGION parameter is dual in nature and influences the 24 and 31 bit storage limits, depending on the range of values.

REGION Limits
REGION=0K or REGION=0M The value of zero is a special case. Coding a zero REGION size sets the limits to all of the 24-bit and 31-bit limit available.
REGION=1K to REGION=16M When you code a value between 1K through 16M, the limit will be applied only to 24-bit storage. There's also an impossible range of REGION values between 8192K to 16384K. If your job uses REGION values in the impossible range, you would get an S822 abend. The 31-bit storage limit is set to the IBM default 32 MB.
REGION=16M to REGION=32M The 24-bit storage limit is set to the site defined maximum. The 31-bit storage limit defaults to 32 MB.
REGION=32M to REGION=2047M When you code a value between 32M through 2047, the limit will be applied only to 31-bit storage. The 24-bit storage limit is set to the site defined maximum.

I used Mark Zelden's REXXSTOR utility to determine these storage limits.

To many people who are thrown to work at a mainframe computer on their first job, they feel lost. Mainframe people seem to speak a completely different language and that doesn't make life easy. What's more, the books and manuals are incredibly hard to comprehend.

"What on earth is a Mainframe?" is an absolute beginner's guide to mainframe computers. We'll introduce you to the hardware and peripherals. We'll talk about the operating system, the software installed on a mainframe. We'll also talk about the different people who work on a mainframe. In a nutshell, we'll de-mystify the mainframe.

Readers based in India, can buy the e-book for Rs. 50 only or the print book. International readers based in the US and other countries can click here to purchase the e-book.