Cheryl Watson's Tuning Letter - 2018 No. 4 © 2019 Watson & Walker, Inc. Page 95

COBOL V6 Compiler TipsWe have been working with an increasing number of customers that are moving to COBOL V6, and helping them get to grips with the performance considerations for COBOL V6 compared to the old COBOL V4 compiler. As a result, we thought that the following tips might prove helpful to the larger audience of our Tuning Letter readers. It is by no means a comprehensive list, and sadly there are lots of ‘it depends’, but we still felt that a little help is better than none.

This article builds on a short User Experience in the Tuning Letter 2018 No. 2 issue. I would especially like to thank IBM’s Tom Ross, the famous ‘Captain COBOL’, for all his help and patience. There is probably no one that knows more about COBOL on z/OS than Tom. I also want to thank Mr, CICS Performance, Ian Burnett from the CICS lab in Hursley, for all his support, and for answering my emails at all hours of the morning, noon, and night. Their enthusiastic support made this article possible.

If you have attended any IBM performance-related sessions at SHARE or other user conferences, you will know that IBM is making it very clear that future performance gains for z/OS applications are increasingly going to come from compiler exploitation of new CPC capabilities. The days of getting 20% annual improvements, thanks mainly to faster chip speeds, are pretty much over. I think that Figure 33 on page 96, extracted from one of Tom’s SHARE presentations, does an excellent job of illustrating this. But don’t miss his text at the side that points out that the effort is higher when you are relying on application-related changes to gain the additional capacity your company needs. If there is any upside to this, it is that this is a challenge for the whole IT world - it is not specific to the mainframe.

LATE BREAKING NEWS

In case you didn’t notice, IBM announced the end of service dates for a load of z/OS-based products on February 5th 2019, in announcement letter ENUS919-022. Included in the list were:

IBM Enterprise COBOL for z/OS V5.1 and V5.2, service ends on April 30th, 2020.

IBM Enterprise COBOL for z/OS V4.2, service ends on September 30th, 2021.

If the potential performance benefits of COBOL V6 are not sufficient to get your application development colleagues moving, the looming end of support for COBOL V4 might do the trick.

Cheryl Watson's Tuning Letter - 2018 No. 4 © 2019 Watson & Walker, Inc. Page 96

Figure 33 - The changing performance picture (Copyright IBM)

The first thing to point out is that the COBOL V5 and V6 compilers are fundamentally different to the old COBOL V4 compiler. The COBOL V4 compiler produces code that is based on the instruction set that was available on a 9672. If you want to benefit from the hundreds of performance-enhancing instructions that have been added over the generations of Z CPCs, then you must use one of the newer compilers.

If you attend any of Tom’s many COBOL sessions at SHARE, you will be familiar with the huge performance gains that the new compilers can deliver for specific COBOL instructions or functions. Depending on what your COBOL programs do, they might see huge benefits from the new compiler, or they might see very few. It is not possible to give an across-the-board relative performance number that will apply to every program, however based on the feedback we have received, the overall customer experience appears to be positive.

But as we all know, there are very few free lunches. When you consider the huge number of new Z architecture instructions, you can understand that the compiler has to work a lot harder to find the most efficient set of machine instructions that will deliver the functions requested by your COBOL program. The new compilers also support many more options, particularly in the area of testing and debugging. As a result of all this additional function, we have seen Rules of Thumb that a compile with COBOL V5 or V6 can take 5 to 12 times as much CPU time as compiling the same program with COBOL V4.

I don’t think that there is anything that you can do to get the compile time for the new compilers back to the COBOL V4 numbers. But there are things that you can, and should, do that affect the compile and run times of the program.

When a program is in the development phase, there will typically be many compiles, so you want to try to keep the compile time down. On the other hand, when the program reaches

Cheryl Watson's Tuning Letter - 2018 No. 4 © 2019 Watson & Walker, Inc. Page 97

production, there will hopefully be hundreds or thousands of executions, and very few compiles. So for production, you want to create a program that will consume as little CPU time as possible when it is running. As you will see, it is probably not ideal to use the same set of compile options for both development and production.

COBOL Compile Time Options

We will start by looking at some of the more important, and possibly more obscure, compile time options that you can use (note that in the following descriptions, the underlined option is the default value):

The OPT(0|1|2) compile time option. Specifying OPT(0) (the default) will use less CPU time than OPT(2) during the compile, but the resulting program object will likely consume more CPU when it is run. OPT(2) should be used when the program is nearly ready for production - it will increase the compile time, but produce a program object that consumes less CPU when it is run.

In some informal testing we performed on our zPDT system, OPT(2) used between two and four times as much CPU time to compile the program as OPT(0). OPT(1) tended to be close to the CPU times of OPT(2), but a little lower.

The ARCH option. ARCH tells the compiler which instructions it can assume will be available when the program is run. The default is ARCH(7), which is equivalent to a z9. The highest ARCH level at the moment is 12, which is equivalent to a z14. You should never specify a value higher than the oldest CPC the program might ever run on, including your disaster recovery CPCs.

The COBOL Performance Guide quotes the following ‘average7’ runtime CPU savings when using higher ARCH levels:

– Moving from ARCH(7) to ARCH(8): 0.4%

– Moving from ARCH(8) to ARCH(9): 0.3%

– Moving from ARCH(9) to ARCH(10): 9.1%

– Moving from ARCH(10) to ARCH(11): 0.9%

– Moving from ARCH(11) to ARCH(12): 8.7%

Figure 34 on page 98 illustrates the difference that the various OPT and ARCH settings can have on the CPU consumed to compile different programs. The first column for each program shows the CU time for a compile using OPT(0) ARCH(7), the next column shows the time for OPT(1) ARCH(7), and so on, all the way to OPT(2) ARCH(12). You can see how changing the OPT value from 0 up to 2 increases the compile time, whereas changing the ARCH value has nearly no impact on how much CPU time is consumed to compile the program.

7 These averages are based on IBM measurements and a limited number of customer results. Your mileage will vary.

Cheryl Watson's Tuning Letter - 2018 No. 4 © 2019 Watson & Walker, Inc. Page 98

Figure 34 - Relative Compile Times

So, what is the best approach? There doesn’t appear to be any benefit from compiling with an ARCH value lower than the one you plan to use in production. However, depending on the program, there does appear to be the opportunity for saving some CPU time by using OPT(0) for your testing, then moving to OPT(2) before you move the program to production. Note, however, that some of the TEST options only take effect if you use an OPT value of 1 or 2. Sadly we didn’t have enough test data to be able to see the difference the different OPT or ARCH levels make to the run time of the programs.

The AFP(VOLATILE|NOVOLATILE) setting. Specifying AFP(VOLATILE) means that values used in program calls must be saved in memory rather than in floating point registers 8 to 15. Remember that access to memory is far slower than access to registers. According to the COBOL Performance Guide, using NOVOLATILE can reduce the overhead of a program call by 10%. The default is now NOVOLATILE, however it used to be VOLATILE. As a result, you might have programs that were compiled with an older level of the compiler that are using VOLATILE.

NOTE: Our measurements were taken on a zPDT system. The results on a real Z CPC could be different, so we recommend that you trying compiling with the different options using a representative sample of your programs on your CPC and see what results you get.

Cheryl Watson's Tuning Letter - 2018 No. 4 © 2019 Watson & Walker, Inc. Page 99

ARITH(COMPAT|EXTEND). In this case, the default value, ARITH(COMPAT) is the more efficient one. We mention it because specifying ARITH(EXTEND) can significantly increase the CPU cost of certain arithmetic operations - the manual cites an example of a floating point exponentiation statement that used 63% less CPU time when COMPAT is used.

The AWO|NOAWO option. This applies to batch programs. If the program updates or creates variable-length record files, and there is a large variation in the record lengths, overriding the NOAWO default with AWO can result in a reduction in the number of I/Os to those files. Specifying AWO has no effect if the program does not write variable length record files, so I don’t see any reason not to specify this for every program.

BLOCK0/NOBLOCK0. Incredibly, the default of NOBLOCK0 indicates that the program should write one record per block for QSAM files. You can override this by specifying a blocksize in the JCL, but if you omit to do that, you will get an unblocked file - not ideal if you are writing records with short lengths. Overriding the default by specifying BLOCK0 could change the file to have a system-determined blocksize.

FASTSRT/NOFASTSRT. NOFASTSRT, the default, indicates that COBOL error handling is required - this means that control must be returned to COBOL after each record is read. Specifying FASTSRT, the recommended value, means that all I/Os are done by the sort program. In an example described in the Performance Guide, a sort of 100,000 records was 45% faster with FASTSRT than NOFASTSRT and generated 4000 fewer EXCPs.

HGPR(PRESERVE|NOPRESERVE) option. This would appear to be particularly important for CICS or IMS programs. A little like the AFP option, the HGPR(PRESERVE) default causes information used during program calls to be written to memory. If you specify HGPR(NOPRESERVE), the high halves of the general purpose registers are not saved during program call. In an IBM measurement, this reduced the overhead of the program call by 6% when the program was compiled with OPT(2).

NONUMCHECK|NUMCHECK. This is another example of where the default option, NONUMCHECK is the most efficient one. Specifying one of the NUMCHECK options can more than double the CPU time of certain zoned decimal operations.

IMPORTANT: In all cases, be sure to review the relevant product manual before you override the default compiler options. While a value other than the default provides better performance in many cases, there are scenarios where you should continue to use the default value. Any recommendations to use values other than the default should be discussed with your development support colleagues to determine if any of the exception situations apply to your company.

A sort of 100,000 records was 45%

faster with FASTSRT than NOFASTSRT!

Cheryl Watson's Tuning Letter - 2018 No. 4 © 2019 Watson & Walker, Inc. Page 100

SSRANGE/NOSSRANGE. Per the COBOL Performance Guide, “The extra checks enabled by SSRANGE can cause significant performance degradations for programs with index, subscript and reference modification expressions in performance sensitive areas of your program.” If you have programs that are compiled with the SSRANGE option, verify with the developer that it would not be feasible to perform range checking in the program for just a subset of subscripted references. Specifying SSRANGE causes additional overhead for all the subscripted references in the program.

The NOSTGOPT/STGOPT option controls whether the compiler removes unreferenced data items and the corresponding code to initialize their VALUE clauses. The default is NOSTGOPT. Specifying STGOPT reduces the size of the program object, but it does not affect the compile or run time.

TEST|NOTEST option. The TEST option produces object code that enables debugging with problem determination tools such as the IBM z/OS Debug Tool and Fault Analyzer. The default setting of the TEST option is NOTEST, which is the best choice from a runtime performance perspective. The EJPD and NOEJPD option controls enablement of the IBM z/OS Debug Tool commands JUMPTO and GOTO in production debugging sessions. EJPD and NOEJPD only take effect if you specify the TEST option and a non-zero OPTIMIZE level. It is understandable that these would be valuable and attractive options while the program is being tested. However, specifying TEST(NOEJPD) increased the runtime CPU by between 6 and 11%, and TEST(EJPD) increased it by a whopping 21 to 28%.

Program Object Sizes

While it is natural to focus on the run-time CPU consumption of the program, CICS customers in particular also need to keep an eye on the size of the generated program objects. This is because they need to be able to fit all of their programs into the 31-bit private area, along with all of the application working storage.

It is wise to monitor load module size changes when upgrading the compiler, or when increasing the levels of optimization. While higher levels of optimization will generally reduce CPU consumption, they also increase the amount of inlining by the compiler, thereby increasing the size of the executable program code.

Some debug options also increase the size of the load module. If you don't need a debug option enabled for First Failure Data Capture (FFDC) purposes in production, consider switching it off, especially if it increases the program object size.

Warning: While specifying STGOPT should reduce the size of the program object, note that it could also cause problems, especially in programs that have “eye catchers” to locate WORKING-STORAGE in dumps, but then do not reference the eye catchers in the program.

Cheryl Watson's Tuning Letter - 2018 No. 4 © 2019 Watson & Walker, Inc. Page 101

Analyzing COBOL Load Modules and Program Objects

Quite a number of the compiler option recommendations in the COBOL Performance Guide say things like “Option xxx provides better performance. But it should not be used if your programs use yyyyy”. Well, that’s great, but how would you know if any of your programs do that, or if they were compiled with a particular compiler option?

One option is to search the source data sets with a tool such as SUPERCE. However, you are not guaranteed that the source necessarily is the one used to create the load module or program object that you are interested in. You should also speak to your developers, as they may have code that you are not aware of. Equally, they might be doing something that is inadvertently impacting performance that they can easily change.

If you want to determine which compiler options were used for a particular set of programs, you should be able to use a tool such as the IBM Debug Tool, or equivalent tools from other vendors. The compiler always places the options that were used for the compile in the load module signature. The IBM Debug Tool has a component called Load Module Analyzer (LMA) that can report on the information from the signature. You can find more information about LMA, together with a sample report here.

If you are not fortunate enough to have such a tool, you could try Roland Schiradin’s excellent COBANAL tool. This is a free tool, available from the CBT tape here. The tool currently supports all levels of the COBOL compiler up to and including COBOL 5.2, and Roland is working on support for COBOL 6.1 and 6.2 right now. The COBANALZ member of the uploaded PDS has a list of changes and supported COBOL Compiler levels, so you can check in there to ensure that you have the level that supports COBOL V6. A partial sample of the output from the program is shown in Figure 35 on page 102.

Cheryl Watson's Tuning Letter - 2018 No. 4 © 2019 Watson & Walker, Inc. Page 102

Figure 35 - Sample Output from COBANAL Tool

Placing COBOL Compiler Load Modules in LPA

Another possibility is to place highly-used compiler modules in LPA. Some customers have found this to be effective. However, the load modules are large and could consume a lot of 31-bit common storage. Also, in our measurements, we didn’t see any significant, consistent benefit. The benefits that we did observe were in the compiles of small programs, presumably because the time required to load the compiler modules was a larger part of the total CPU time for the compile. Having said that, if you do a lot of compiles and have the scope to increase the size of EPLPA, you should test this in your development system to determine if it would be valuable to you.

Considerations for COBOL Program Objects

COBOL program objects are stored in PDSEs. The default used to be that the system would create a 256MB hiperspace to hold frequently-referenced PDSE members. However, the default was changed, meaning that no PDSE buffer is created unless you explicitly specify so in your IGDSMSxx member of Parmlib (on the PDSE_HSP_SIZE and PDSE1_HSP_SIZE parameters).

In addition to having the PDSE cache, you also need to do something to identify the objects that are eligible to reside in the cache. One way is to manage the PDSE with LLA - LLA will then tell PDSE which modules should be placed in the cache. Another option is to assign the PDSE to a storage class with a Milli Second Response (MSR) time target of 9 ms or less.

Cheryl Watson's Tuning Letter - 2018 No. 4 © 2019 Watson & Walker, Inc. Page 103

If you use LLA and VLF for your COBOL V4 load libraries, moving to COBOL V6 could result in longer load times because the program information is no longer cached. For more information about this, refer to ‘Optimizing Efficiency of COBOL V5 Load Processing’ in Tuning Letter 2015 No. 1.

CICS has slightly different considerations to batch. CICS normally tries to retain an in-memory copy of every program it has loaded. It is only when CICS encounters a short-on-storage condition that it will remove programs. Therefore, the time it takes to load CICS programs is not as much of an issue. Having said that of course, because CICS transactions typically run for such a short time, any delay encountered in loading a program have a relatively large impact on the response times of the transactions that use a program that is not already loaded. For those situations, you should investigate the use of LLA to minimize the load times.

For information about the intersection between LLA and CICS, refer to the section titled “Using LLA” in the CICS Performance Guide, SC34-7033. Note that this link is to the CICS TS 4.1 version of the Performance Guide. Even though the information is still valid, it appears to have been omitted from more recent editions of that manual. Also, refer to the section titled “LLACOPY” in the CICS TS System Management manual for your release of CICS. Also, refer to the section titled “Improving module fetch performance with LLA” in the z/OS MVS Initialization and Tuning Guide, SA23-1379.

In special cases, you could also consider placing CICS application programs in LPA. However, the same considerations apply as applied to the COBOL compiler modules. For more information about the use of LPA for application programs, refer to https://www.ibm.com/support/knowledgecenter/SSGMCP_5.5.0/tuning/dfht34g.html and https://www.ibm.com/support/knowledgecenter/SSGMCP_5.5.0/installing/dfha11d.html.

Considerations for CICS COBOL Programs

There are some CICS SIT options that can affect the efficiency of COBOL programs.

The AUTODST (Automatic Dynamic Storage Tuning) option indicates that Language Environment should monitor a program’s use of memory. If the program allocated additional memory while it was running, LE will remember that, and allocate a larger block of memory for the program the next time it is run. The objective of this action is to reduce the number of GETMAINs and FREEMAINs. Note that this is not the default - if you want to enable this capability, you must explicitly specify AUTODST=YES in your CICS SIT statements. However, ensure that you read IBM Technote “DFHSM0133 short on storage after setting AUTODST ON” that describes situations where the use of AUTODST can cause Short-on-Storage conditions in CICS.

Another CICS SIT parameter that can improve performance is RUWAPOOL=YES (the default is RUWAPOOL=NO). The system path length increases when a CICS application

Cheryl Watson's Tuning Letter - 2018 No. 4 © 2019 Watson & Walker, Inc. Page 104

invoked by LE issues an EXEC CICS LINKS request. Repeated EXEC CICS LINK calls to the same program invoked by LE result in multiple GETMAIN and FREEMAIN requests for run-unit work areas (RUWAs).Specifying RUWAPOOL=YES results in the creation of a run-unit work area pool during task initialization. This reduces the number of GETMAIN and FREEMAIN requests in tasks that perform many EXEC CICS LINKS to programs invoked by Language Environment.

For more information about the AUTODST and RUWAPOOL options, refer to IBM Technote titled LE storage tuning in CICS using AUTODST and RUWAPOOL. For more information about these and other CICS settings that can influence performance, refer to IBM Systems Magazine article titled CICS Concepts in Action by Jim Schesvold.

There is some additional processing involved with the initialization and termination of a COBOL V5 or later program object compared to a functionally-equivalent COBOL V4 load module. This additional overhead, however, gives rise to significantly better opportunities for optimization when the program is running.

In batch, this additional overhead is largely irrelevant because it is typically tiny compared to the CPU consumed by the program. However, in a CICS transaction, initialization and termination are a much larger fraction of the overall CPU consumption of the program because CICS programs typically execute for milliseconds, not minutes. For a COBOL V5 or later module to provide equivalent overall performance to a COBOL V4 program in CICS, the CPU improvements achieved by the extra optimization in the compiler must be able to offset the higher initialization and termination cost within a much shorter space of time. As you can imagine, the shorter the transaction, the more difficult it is for it to achieve that goal.

As time goes by, it is reasonable to assume that future generations of CPCs will deliver additional enhancements that will be exploited by future levels of the compiler. Therefore, in the long run, nearly every COBOL V6 CICS transaction should consume the same or less CPU than an equivalent COBOL V4 transaction.

In the meantime, if your objective is to use the new capabilities in COBOL V6 to reduce CPU consumption, it would probably make sense to focus on batch programs and longer-running CICS transactions. I don’t know if the same considerations apply to COBOL/IMS transactions, but it would seem reasonable to expect so.

IMPORTANT: Just in case you didn’t notice, IBM announced that the next release of z/OS will only support CICS releases of 5.2 or later. This is because of the removal of support for user key common storage in z/OS 2.4. For more information, refer to https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.e0zm100/BCP_vsm-rsm_userkeyCA_v2r3.htm.

Cheryl Watson's Tuning Letter - 2018 No. 4 © 2019 Watson & Walker, Inc. Page 105

XML Parsing and COBOL Programs

We have been working on a system tuning exercise with an American z/OS customer. They have a z13s CPC with one zIIP processor. They run their general purpose CPs at very high utilization, but have loads of spare capacity on the zIIP. zIIPs are attractive on any CPC because they are less expensive to purchase and maintain than general purpose CPs, any work that runs on them does not affect your Rolling 4-Hour Average, and they run at the full rated speed of that model. In this case, the zIIP is even more attractive because the GCPs were full and there was loads of spare capacity on the zIIP.

One of the potential users of zIIP capacity is the XML System Services (XMLSS) parser. The COBOL compiler also provides an XML parser. However:

The COBOL-provided XML parser is not zIIP-eligible.

It does not support all the functions that the XMLSS parser supports.

It is not strategic - IBM does not plan on making any further enhancements to it.

However, apparently XML is now ‘old hat’, and the strategic way to go is JSON. Bearing that in mind, there probably are not going to be many changes to XML, so the fact that the COBOL XML parser is functionally stabilized is probably not that big of a deal.

Based on all that, this seems like a ‘no-brainer’ decision to use the XMLSS parser, right? Well, not necessarily. While the XMLSS parser is more powerful, it also consumes more CPU than the more basic COBOL parser. In a measurement performed by IBM a few years ago, the XMLSS parser used about two and a half times as much CPU time as the COBOL parser. About 2/3 of the XMLSS parser time was zIIP-eligible, so on balance it consumed a similar amount of general purpose CP time as the COBOL parser, however it has a longer elapsed time.

Just to be sure that the XMLSS parser is actually using the zIIP when called from a CICS transaction, I then spoke to a CICS performance expert. The parser must be run in enclave SRB mode to be zIIP-eligible, so I wanted to ensure that CICS did not impose any restrictions on this.

The good news is that the XMLSS parser can run inside CICS transactions and utilize zIIP engines. Even better, this can happen without the CICS or z/OS sysprog making any configuration updates, and there are no parameters or anything that needs to be done at the application level to make it zIIP-eligible.

However, the parser itself typically doesn't do a huge amount of work in the grand scheme of a CICS application. It will perform some basic validity checks on the incoming XML, then extract tag and attribute names with data ready for processing by the application. This part is eligible for offload, but the CPI-intensive work of understanding the inbound XML data is still left to the (non-zIIP-eligible) COBOL program.

Cheryl Watson's Tuning Letter - 2018 No. 4 © 2019 Watson & Walker, Inc. Page 106

The net result is that the application logic which understands the XML data still represents the vast majority of the CPU consumed - the percentage of XML-related processing that can be offloaded is typically in the low single figures. This was borne out in the zIIP utilization numbers we were seeing this in this customer.

Based on all this information, we are recommending that any customers that are planning on processing XML documents from inside a CICS transaction should not just automatically select the XMLSS parser. Informed decisions should be based on:

What XML functions are required. If the application requires functions that are not supported by the COBOL parser, then the XMLSS parser is the only option.

Perform comparative measurements using your own data and application logic.

The CICS 110.1 SMF records contain information about the general purpose CP and zIIP usage for each transaction, so you can use those records to measure the CPU time used by each parser. If you are doing comparative measurements, make sure that you are not changing anything other than the XML parser being used.

With that information in hand, you are now able to make an informed decision about which is the best XML parser option for your environment. You might find that the cost of the XMLSS parser is higher, but you still decide to use it. That is fine - we are not opposed to the XMLSS parser, we just want to ensure that our readers are making their decisions based on as much accurate information as possible.

References

There are numerous sources of additional, and more detailed, information about COBOL. The following list is not comprehensive, but we believe that it will be a good starting point for anyone that wants to delve deeper into this topic:

IBM manual Enterprise COBOL for z/OS Performance Tuning Guide, SC27-9202. If you don’t read anything else about COBOL performance, this is the one book that you must read. Note that there is a new edition for every new release of COBOL, so make sure that you use the edition that is for your release of COBOL.

IBM manual Enterprise COBOL for z/OS Programming Guide, SC27-8714.

The IBM COBOL Documentation Library website. One stop shopping for the manuals for all levels of the COBOL compiler, all the way back to COBOL 3.1!

IBM manual CICS TS for z/OS Performance Guide.

The IBM CICS TS V5 Documentation Library website. This site has links to the CICS PDFs going back to CICS TS 5.1.

Cheryl Watson's Tuning Letter - 2018 No. 4 © 2019 Watson & Walker, Inc. Page 107

Any of Tom Ross’ many conference presentations, but in particular SHARE in St. Louis 2018, Session 23430, Elevating Application Performance with Latest IBM COBOL Offerings.

‘Optimizing Efficiency of COBOL V5 Load Processing’ from Tuning Letter 2015 No. 1.

‘User Experiences’, from Tuning Letter 2018 No. 2.

See the COBOL Hints and Tips slides in The Watson & Walker Roadshow from the 2018 IBM Systems Technical University.

Summary

Never let it be said that COBOL is boring. Fine tuning COBOL compiler options has moved from a dark art, practiced only by ‘strange’ people with reference cards and slide rules, to being the number one way to drive the maximum capacity from your CPC. For many years, the mainframe technical community has been able to deliver ever-more performance by moving to the latest CPCs. To a large extent, the application developers were blissfully ignorant of the changes to the underlying environment.

Even though backward compatibility is something that we have always taken for granted in the mainframe, it is not the default behavior on other platforms. How many times have you seen products or applications that require back levels of Java because they use some function that was ‘deprecated’ (a nice word for ripped out) in a newer release? While we still proudly support backward compatibility, the days when developers could just sit back and rely on the technicians to deliver more performance are over.

COBOL performance is a vast and complex topic. I’m sure that there is a newsletter somewhere that is dedicated to just COBOL. And Captain COBOL, Tom Ross, will have a job for as long as he still feels like working. The list of topics we covered in this article is far from comprehensive, and we haven’t even touched on the performance analysis or debugging tools that are available to developers. However, we hope that the article is sufficient to tweak your curiosity.

Perhaps one of the best investments you can make in optimizing your COBOL compile and runtime performance is to provide education for your application developers. In addition to the myriad options that are available in the latest compilers, your understanding of system performance can be key in helping them understand the difference their actions can make. If you are going to provide such a class, I think that Tom Ross’ upside-down pyramid in Figure 33 on page 96 would be an excellent graphic to open your session with.