COBOL is still the most widely used language in mainframe – both for online transaction processing as well as massive batch processing. Even minor improvement of performance of repeatedly executing COBOL programs directly provides savings of CPU and hence the costs. One of the simple things – and often neglected one – that would optimize COBOL performance is to use the right set of Compile options.

In quite a few performance tuning engagements, the culprit is that the compiler option (set in the JCL or the configuration tool) used by almost all programs having compiler options (mostly left to default) that bring down the performance. Even the veteran COBOL programmers, tend to ignore these and focus on programs alone while trying to improve performance. In this article, I would like to highlight the COBOL compiler options which impacts performance.

The OPTIMIZE compiler option can be used to improve the efficiency of the generated code. NOOPTIMIZE is the default. OPTIMIZE(STD) results in the following optimizations:

• Eliminate unnecessary transfers of control and inefficient branches (including those generated by the compiler).
• Simplify the PERFORM and CALL statement to a contained (nested) program, by placing the statements inline, eliminating the need for linkage code.
• Eliminate duplicate computations (such as subscript computations and repeated statements).
• Eliminate constant computations by performing them when the program is compiled.
• Eliminate constant conditional expressions.
• Aggregate moves of contiguous items (say with the use of MOVE CORRESPONDING) into a single move.
• Delete from the program, code that can never be performed (unreachable code elimination).

In case of OPTIMIZE(FULL) option, additionally it:

• Discard unreferenced data items from the DATA DIVISION, and suppress generation of code to initialize these data items to their VALUE clauses (If the program relies upon unreferenced level 01 or level 77 data items, do not use OPTIMIZE(FULL)).

Note that OPTIMIZE requires more CPU time for compiles than NOOPTIMIZE, but generally produces more efficient run-time code. It is suggested that NOOPTIMIZE is used while a program is being developed, as   frequent compiles would be happening and it also makes it relatively easier to debug a program since code is not moved.

With DYNAM option, all subprograms invoked through the CALL literal statement will be loaded dynamically at run time. NODYNAM is the default. DYNAM allows sharing of common subprograms, provides control of using the virtual storage (that can be freed using CANCEL statement), but with a performance penalty as the call must go through a library routine, whereas with the NODYNAM option, the call goes directly to the subprogram. Detailed information is available at http://itknowledgeexchange.techtarget.com/enterprise-IT-tech-trends/static-dynamic-linking-in-ibm-cobol/.

According to IBM, for a CALL intensive application, the average overhead associated with the CALL using DYNAM ranged from 40% to 100% compared to that of NODYNAM.

Using the FASTSRT compiler option improves the performance of most sort operations. NOFASTSRT is the default. With FASTSRT, the DFSORT product (instead of Enterprise COBOL) performs the I/O on the input and output files named in the SORT . . . USING and SORT . . . GIVING statements.

One program that processed 100,000 records was 45% faster when using FASTSRT compared to using NOFASTSRT and used 4,000 fewer EXCPs.

XMLPARSE(XMLSS) option (the default) selects the z/OS XML System Services parser as against  XMLPARSE(COMPAT) uses the built-in component of the COBOL run time. While XMLSS provides additional capabilities, at present COMPAT option is found to be faster by 20-108%. But it is important to note that as IBM would focus more on XML Parser, the performance difference is most likely to get lower.

THREAD option that enables multi-threading in COBOL and can be used in a non-threaded application (ref. http://itknowledgeexchange.techtarget.com/enterprise-IT-tech-trends/multithreading-in-cobol/) results in runtime performance degradation due to overhead of serialization logic that is automatically generated. NOTHREAD is the default.

ARITH option that allows controlling the maximum number of digits allowed for decimal numbers. ARITH(COMPAT), the default, allows the maximum digits of 18 (which should serve well for most requirements) while ARITH(EXTEND) allows up to 31.

ARITH(EXTEND) causes performance degradation for all decimal data types because of larger intermediate results. The performance impact on an average is 16%, while for programs with heavy use of decimals, it could be as high as 40%.

AWO option implicitly activates the APPLY WRITE-ONLY clause for all physical sequential, variable-length, blocked files (irrespective of whether it is specified in the program). NOAWO is the default option. Using the APPLY WRITE-ONLY clause makes optimum use of buffer and device space. With APPLY WRITE-ONLY specified, the file buffer is written to the output device only when the next record does not fit in the unused portion of the buffer. Without APPLY WRITE-ONLY specified, a file buffer is written to the output device when it does not have enough space for a maximum-size record.

According to IBM, a program using variable-length blocked files and AWO was 86% faster than NOAWO (as the result of using 98% fewer EXCPs to process the writes).

BLOCK0 option changes the default for QSAM files from unblocked to blocked thus gaining the benefit of system-determined blocking for output files. NOBLOCK0 is the default. BLOCK0 is applicable for each file that meets all of the following criteria:

• The FILE-CONTROL paragraph specifies ORGANIZATION clause as SEQUENTIAL or omits it.
• The FD entry does not specify RECORDING MODE U.
• The FD entry does not specify a BLOCK CONTAINS clause.

AWO might apply to more files than it otherwise would, if BLOCK0 is also specified (as AWO applies only for blocked variable-length records). One program using BLOCK0 was found to be 88% faster than using NOBLOCK0 (using 98% fewer EXCPs).

Note that specifying BLOCK0 for existing programs might change the behavior of the program – especially for files opened as INPUT without block size.

NUMPROC(PFD) improves the performance of processing numeric internal decimal and zoned decimal data. With NUMPROC(PFD), the compiler assumes that the data has the correct sign and bypasses the sign fix-up processing. But use this option only if your program data agrees exactly with the following IBM system standards.

Note that NUMPROC(NOPFD)is the default – and recommended if the numeric internal decimal and zoned decimal data might not use proper signs (especially if the program has to process external data files). Also note that NUMPROC(NOPFD) or NUMPROC(MIG) should be used if a COBOL program calls programs written in PL/I or FORTRAN.

NUMPROC(PFD) – that can provide performance benefit between 5-20% – is advisable for performance sensitive applications after ensuring that the necessary conditions are met.

TRUNC(OPT) is another performance tuning option for performance sensitive application and should be used only when the data in the application program conforms to the PICTURE and USAGE specifications.

While the above points are related to runtime efficiency, the following two options are worth noting in a development environment:

• Use BUFSIZE to allocate an amount of main storage to the buffer for each compiler work data set. Usually, a large buffer size improves the performance of the compiler.
• Use the COMPILE option only if you want to force full compilation even in the presence of serious errors. All diagnostics and object code will be generated. Do not try to run the object code if the compilation resulted in serious errors: the results could be unpredictable or an abnormal termination could occur.

With judicial use of the compiler options – suited for the given environment – performance benefits can be achieved without modifying the programs.

Recently one of our Unix experts – focusing on IT optimization – came to me to get an understanding of Mainframe and like most IT people who have not worked in Mainframe had quite a few obsolete notions. So I created a set of documents on Mainframe overview, on zOS (operating system) and CICS (the transaction processor) and sharing the same here.

Mainframe is a self-contained processing center, powerful enough to process the largest and most diverse workloads in one secure “footprint.” At the same time, Mainframe is also just as effective when implemented as the primary server in a corporation’s distributed server farm. There are different classes of mainframe to meet diverse needs of customers – Business Class and Enterprise Class.

Security, scalability, and reliability are the key criterions that differentiate the mainframe. Businesses today rely on the mainframe to:

• Perform large-scale transaction processing (thousands of transactions per second)
• Support thousands of users and application programs concurrently accessing numerous resources
• Manage terabytes of information in databases
• Handle large-bandwidth communication

Typically, the mainframe shares space with many other hardware devices: external storage devices, hardware network routers, channel controllers, and automated tape library “robots,” etc. Unlike in the past, now, the mainframe is physically no larger than many of these devices and generally does not stand out from the crowd of peripheral devices (earlier Mainframe used to have rooms for themselves but now they are just part of a data center).

Mainframe interfaces today look much the same as those for personal computers or UNIX systems. A business application is accessed through a Web browser, with the mainframe in the background.

It is now possible to run a mainframe operating system on a PC that emulates a mainframe. Such emulators are useful for developing and testing business applications before moving them to a mainframe production system (can be useful in cost savings).

Most mainframe workloads fall into one of two categories: batch processing or online transaction processing, which includes Web-based applications. Today’s mainframe can run standard batch processing such as COBOL as well as batch UNIX and batch Java programs.

A mainframe can be the central data repository, or hub, in a corporation’s data processing center. For example, centralizing the data in a single mainframe repository can save customers from having to manage updates to more than one copy of their business data, which increases the likelihood that the data is current.

Mainframe – Hardware

Mainframe hardware consists of processors and a multitude of peripheral devices such as disk drives (called direct access storage devices or DASD), magnetic tape drives, and various types of user consoles;

 o The term Box may refer to the entire machine or model; it is an expression used due to its shape. Mainframe systems today are much smaller than earlier systems-about the size of a large refrigerator. The mainframe’s power consumption today is 0.91 watts per MIPS and is expected to decrease with future models.

o The abbreviation CEC, pronounced keck, is for the Central Electronic Complex that houses the central processing units (CPUs).

o Central processor complex or CPC refers to the centralized processing hub that contains the processors, memory, control circuits, and interfaces for channels.

o All the processors (S/390 or z/Architecture) present in the CPU are referred to as processing units (PUs). The PUs are characterized as CPs (for normal work), Integrated Facility for Linux (IFL), Integrated Coupling Facility (ICF) for Parallel Sysplex configurations and so forth.

o A channel provides an independent data and control path between I/O devices and memory. Today, the largest mainframe can have over 1000 channels. A channel can be considered a high-speed data bus. Todays mainframe use ESCON (Enterprise Systems CONnection) and FICON (FIber CONnection) channels.

o Channels connect to control units. A control unit contains logic to work with a particular type of I/O device – printers, tape drives etc. Today’s channel paths are dynamically attached to control units as the workload demands – providing a form of virtualizing access to devices.

o Control units connect to devices, such as disk drives, tape drives, communication interfaces, and so forth.

o Sharing of I/O devices is common in all mainframe installations. A technique used to access a single disk drive by multiple systems is called multiple allegiance. Multiple paths to a device allows for effective disk sharing (across multiple servers) which in turn can provide improved performance and availability.

The IBM mainframe can be partitioned into separate logical computing systems. System resources (memory, processors, I/O channels) can be divided or shared among many such independent logical partitions (LPARs).

For many years there was a limit of 15 LPARs in a mainframe; today’s machines can be configured with up to 60 logical partitions. Practical limitations of memory size, I/O availability, and available processing power usually limit the number of LPARs to less than these maximums. Logical partitions are, in practice, equivalent to separate mainframes. Right sizing is the key when it comes to partitions. It can be used to control usage of resources, improved security, availability etc.

z/OS

z/OS – widely used mainframe operating system – system is a share-everything runtime environment that provides for resource sharing through its heritage of virtualization technology. z/OS gets work done by dividing it into pieces and giving portions of the job to various system components and subsystems that function interdependently.

A z/OS system usually contains additional, priced products that are needed to create a practical working system. IBM refers to its own add-on products as IBM licensed programs – and comes at a cost. Also independent software vendors (ISVs) offer a large number of products with varying but similar functionality, such as security managers and database managers. The typical products include:

• Security System (Resource Access Control Facility – RACF from IBM)
• Compilers (z/OS includes an assembler and a C compiler. Other compilers – COBOL, PL/1 etc are separate products).
• Relational Database (DB2 from IBM)
• Transaction processing facility (CICS, IMS, WAS from IBM)
• Sort (DFSORT from IBM)
• Utility Programs

Even the System Display and Search Facility (SDSF) program that people use extensively to view output from batch jobs is a licensed program (looking at these licensed programs to see if they are really necessary – and also that there is no other ISV product with similar functionality available in the installation provides another opportunity for cost saving).

Besides z/OS, four other operating systems dominate mainframe usage: z/VM, z/VSE, Linux for zSeries, and z/TPF. The use of z/OS, z/VM, and Linux on the same mainframe is common.

It is also important to note that if there are multiple versions of the same software in an installation, the license costs are actually multiplied.

Mainframe provides Specialty engines -zAAP as a specialized Java execution environment, IFL for Linux – which enables off-loading specific work to separate processors.  As attractive prices are offered for such processors, the overall total cost of ownership reduces by appropriate use of these processors. This also enables the general CPUs to continue processing standard workload increasing the overall ability to complete more batch jobs or transactions.

Consolidation of Mainframe

Data center consolidation initiatives have resulted in several smaller mainframes being replaced with fewer but larger systems.

Software license costs for mainframes have become a dominant factor in the growth and direction of the mainframe industry as mainframe software (from many vendors) can be expensive, often costing more than the mainframe hardware.  Though Software license costs are often linked to the power of the system, yet the pricing curves favor a small number of large machines – replacing multiple software licenses for smaller machines with one or two licenses for larger machines is cost effective (While consolidating mainframes, the licenses for software (with 3^rd party vendors) may have to be re-negotiated for cost savings ).

The relative processing power needed to run a traditional mainframe application (a batch job written in COBOL, for example) is far less than the power needed for a new application (with a GUI interface, written in C and Java). New powerful mainframes might need only 1% of their power to run an older application, but the application vendor often sets a price based on the total power of the machine, even for older applications.

As an aid to consolidation, the mainframe offers software virtualization, through z/VM. z/VM’s extreme virtualization capabilities and Linux on Mainframes make it possible to virtualize thousands of distributed servers on a single server. Consolidating distributed servers to mainframe can directly translate into significant monetary savings (IBM’s has conducted a very large consolidation project named Project Big Green to consolidate approximately 3,900 distributed servers into roughly 30 mainframes, using z/VM and Linux on System z. It achieved reductions of over 80% in the use of space and energy.).

Originally COBOL didn’t support multithreading thereby heavily limiting the possibility of using COBOL subroutines as building blocks for web applications. With Enterprise COBOL, IBM started providing toleration level support of POSIX threads and asynchronous signals.

With THREAD compiler option, a COBOL programs can be run in multiples threads (i.e., it can be called in more than one thread in a single process) – under batch, TSO, IMS or UNIX (and not in CICS). A multi-threaded program needs to be recursive (RECURSIVE clause in PROGRAM-ID) and also compiled and linked with the RENT option.

It is important to note that COBOL doesn’t manage the threads and rather expect the application server or the calling program (in Java, C/C++, PL/I) to manage the same. The threaded application must run within a single Language Environment enclave.

With THREAD option, the storage and control blocks get appropriately allocated on invocation basis, rather than per program – making them thread-safe.  Also additional serialization logic is automatically generated (which in-turn can degrade performance).

Recursive call is where a called program can directly or indirectly execute its caller. For example, program X calls program Y, program Y calls program Z, and program Z then calls program X (the original caller). The persistence of the data for each call depends on whether it is in local storage or working storage.

• Multiple threads that run simultaneously share a single copy of the WORKING-STORAGE data (statically allocated and initialized on first entry to a program and is available in the last-used state for the recursive invocations).
• A separate copy of LOCAL-STORAGE data is allocated and made available for each call of program (or invocation of a method) which gets released on returning from the program. If the VALUE clause is specified, the data is re-initialized to the same for every invocation.

If THREAD compiler option is used, data that is defined in the LINKAGE SECTION is not accessible on subsequent invocations of the program. The address of the record in the Linkage section must be reestablished for each execution instance. Pre-initialization (if required) should be done using LE services (CEEPIPI interface rather than COBOL specific interfaces).

In a multithreaded environment, a program cannot CANCEL a program that is active on any thread (cancel results in severity-3 LE condition). A multithreaded program can be ended by using GOBACK, EXIT PROGRAM, or STOP RUN:

• When you use GOBACK from the first program in a thread, the thread is terminated. If that thread is the initial thread in an enclave, the entire enclave is terminated.
• With EXIT program the thread is not terminated unless the program is the first (oldest) one in the thread. 
• With STOP RUN the entire LE enclave is terminated, including all threads executing within the enclave.

Multi-threaded COBOL programs can have file operations on QSAM, VSAM and sequential files. Automatic serialization happens using the implicit lock on the file definition and during the input and output operations.

To avoid serialization problems when accessing a file from multiple threads, it is recommended that the data items that are associated with the file (such as file-status data items and key arguments) are defined in the LOCAL-STORAGE SECTION.

Similarly to avoid coding of own serialization logic (using POSIX APIs), IBM suggests the following usage patterns:

• For input: OPEN, READ, Process the Record, CLOSE
• For output: OPEN, Construct the output, WRITE, CLOSE

In a threaded application, the COBOL program can be interrupted by asynchronous signals, which the program should be able to tolerate. Alternatively using C/C++ functions, the interrupts can be disabled by setting the signal mask appropriately.

Other factors worth noting are:

• Though you cannot run multithreaded applications in the CICS environment, the program compiled with THREAD option can run in CICS in a single thread.
• There are quite a few restrictions and behavioral differences when THREAD option is used
• Enabling the existing COBOL programs to be multi-threaded can range from just recompiling at best to modifying program logic that require thorough testing.

Using multi-threading feature of COBOL, existing COBOL programs from legacy applications can be effectively utilized in the web applications (directly!).

Using linking, we can have one program call another program that is not contained in the source code of the calling program. Depending on the linkage options,  the object module of the calling program is linked with the object module of the called program “before or during” execution – referred to as static or dynamic linking.

Appropriately choosing the linkage as static / dynamic depending on the application requirement (and not a single technique for the entire application) can result in benefits related to performance, memory usage and maintenance.

 Static CALL

 In the static CALL statement, the COBOL program and all called programs are part of the same load module (self-contained). When control is transferred, the called program already resides in storage, and a branch to it takes place. Subsequent executions of the CALL statement make the called program available in its last-used state, unless the called program has the INITIAL attribute.

A static call occurs:

1. When the CALL literal statement is used in a program that is compiled using the NODYNAM and NODLL compiler options.. With these options, all calls of the CALL literal format are handled as static calls.

Because a statically called program is link-edited into the same load module as the calling program, a static call is faster than a dynamic call (though the load modules are larger).

The key disadvantage is that to change the behavior of the called program, relinking is necessary. As statically called programs cannot be deleted (using CANCEL), static calls might take more main storage. Also if more than one calling program accesses the called program, duplicate copies of the programs have to be loaded into memory.

Dynamic CALL

In the dynamic CALL statement, the called COBOL subprogram is not link-edited with the main program, but is instead link-edited into a separate load module, and, at run time, is loaded only when it is required (that is, when called).

When a dynamic CALL statement calls a subprogram that is not resident in storage, the subprogram is loaded from secondary storage into the region or partition containing the main program and a branch to the subprogram is performed. The first dynamic call to a subprogram within a run unit obtains a fresh copy of the subprogram. Subsequent calls to the same subprogram (by either the original caller or any other subprogram within the same run unit) result in a branch to the same copy of the subprogram in its last-used state, provided the subprogram does not possess the INITIAL attribute.

When a CANCEL statement is issued for a subprogram, the storage occupied by the subprogram is freed, and a subsequent call to the subprogram functions as though it were the first call. A subprogram can also be cancelled from a program other than the original caller.

A Dynamic Call occurs:

1. When the CALL literal statement is used in a program that is compiled using the DYNAM and the NODLL compiler options (or)

2. when the CALL identifier statement is used in a program. CALL identifier is always dynamic, even if the NODYNAM compiler option is used.

The program name in the PROGRAM-ID paragraph must be identical to the corresponding load module name or load module alias of the load module that contains it.

Typically, dynamic CALL statement is used in the following circumstances:

• For ease of maintenance. Applications do not have to be link-edited again when dynamically called subprograms are changed.
• The subprograms called are used infrequently or are very large. If the subprograms are called on only a few conditions, dynamic calls can bring in the subprogram only when needed. If the subprograms are very large or there are many of them, using static calls might require too much main storage. Less total storage might be required to call and cancel one, then call and cancel another, than to statically call both.

The key points to be noted are:

• CALL identifier is always dynamic
• With NODYNAM compiler option, all calls of the CALL literal format are handled as static calls.
• When a static CALL statement and a dynamic CALL statement to the same subprogram are issued within one program, a second copy of the subprogram is loaded into storage.