CICS Still As Popular As Ever

Even with the popularity of Web-based processing, CICS and the millions of lines of COBOL code that drive the transactions have continued to perform with more efficiency each year. If you think COBOL programming has disappeared, go to any of the popular job search websites and key in “CICS.” You’ll get 700 to 800 hits for CICS COBOL programmer and systems programmer openings around the country. Even though most of the “green screen” maps CICS used to send to 3270 terminals are gone, many of the Web inquiries you make return a browser page that’s still driven by CICS but presented as output via new presentation services.

User groups have historically been the “meeting place” for CICS folks wanting to hear of recent announcements, enhancements, war stories, etc. Remember when the CICS Project members were the last to leave SCIDS every night at SHARE? Of course, that’s when we were all much younger. User groups are still very important to the product, but many customers now hope to get more information without travel. Websites have sprung up to provide that information and link to other Websites for relevant content. Hopefully, this

e-newsletter will add to your existing resources for timely and helpful CICS topics.

Version Status

If you haven’t kept up with the IBM announcements, service will be discontinued for CICS TS 2.2 on April 30, 2008. This may still seem like a long way off, but customers running that release should have a plan to migrate this year or next. The big question is whether to migrate to CICS TS 2.3 or TS 3.1. One of the major issues many customers face in this decision process is the existence of an old version of COBOL, since that seems to be one of the significant differences in the two releases. According to IBM documentation:

CICS TS 2.3 supports the execution of OS/VS COBOL application program modules provided the OS/VS COBOL run-time is supported by IBM. This supported run-time is provided within the Language Environment (LE) libraries. CICS TS 2.3 is the last release of CICS to support the execution of OS/VS COBOL modules. CICS TS 3.1 won’t execute OS/VS COBOL modules.

So, if you have “critical applications” still executing with old OS/VS COBOL code, you’ll have to migrate to CICS TS 2.3. Of course, that’s a temporary solution, since IBM will eventually remove TS 2.3 from service. It’s best to include in your migration plan a strategy to upgrade those applications. Many customers choose to avoid the most recent release, since they don’t want to be on the “bleeding edge,” but TS 3.1 has been available for more than a year now, so that’s no longer an issue. We’ll have several topics in the coming issues to help with migration planning. 

New Function: CEKL Added for the KILL Function

Many times CICS development delivers new function via maintenance or the service process. Customers may not have noticed the new function, since it wasn’t available when the release was initially available (GA), and therefore didn’t show up in the release guide under the category “Summary of New and Changed Function.” One item in this category is the new CICS transaction CEKL. This transaction was added to CICS TS 2.3 via APAR PQ79277 titled “TRANSACTION CEKL ADDED FOR THE KILL FUNCTION.” While it can’t be found in the CICS TS V2.3 Release Guide (GC34-6218), it’s now documented in CICS TS V2.3 CICS Supplied Transactions (SC34-6230) and CICS TS 3.1 CICS Supplied Transactions (SC34-6432). 

This transaction is different from the existing CICS supplied transactions in several ways. The most obvious is that the transaction isn’t “installed” as a transaction definition as most CICS transactions are. The resource isn’t found in any IBM groups and won’t display as a result of the CEMT INQ TRANS command. Also, it isn’t executed from within a CICS region as other transactions are; it can be invoked only from an operating system console, which also doesn’t have to be defined to CICS. The most obvious way to determine if the function is available in any CICS region is to view the start-up messages that CICS produces during initialization and search for the following item:

DFHCQ0200I CICSP0 CEKL transaction enabled.    

The transaction must be initiated from an operating system console; the most common technique is to use the OS MODIFY command from an SDSF session. The syntax for using the MODIFY command to any CICS region would be to enter the following from the SDSF Command line:

/F CICSREG1,CEKL INQ TASK

CICSREG1 is the target CICS region. The output can be viewed within SDSF via the ULOG facility or within the CICS JES message log of the region, since the command output is mirrored back to the region log that was the target of the MODIFY command. The first line of the output will show:

DFHCQ0243I  CEKL INQUIRE: 00011 task(s) matched selection criteria.

This will be followed by the list of the 11 (or whatever number of) user tasks that currently exist in that region. You can restrict the content of the output to view selected tasks based on the options within the command that are TRANCLASS, RUNNING, DISPATCHABLE, or SUSPENDED. Refer to the CICS Supplied Transactions documentation for specific format. 

The purpose of the transaction is to purge transactions, such as CEMT PURGE or FORCEPURGE, that can’t be purged via normal methods. IBM recommends those options be attempted before using CEKL, since this last resort doesn’t guarantee integrity of any kind but allows the customer to free up a stalled region when other conventional methods fail. The previous methods have failed in the past for customers, since in order to execute the CEMT command, there must be resources available for the task to attach. If a region is truly SOS (Short on Storage) or “hung,” CEMT isn’t an option. After using CEKL to INQ on the tasks currently waiting in the region, you can use CEKL to SET the task to PURGE, FORCEPURGE, or KILL. Again, customers must realize this can produce integrity issues within the region but may be a last resort. 

Note that on the two messages for CEKL displayed above, DFHCQ0200I and DFHCQ0243I, the fourth and fifth letter in the message is CQ, which is the position in any CICS message that normally corresponds to the “component” or “domain” that produced the message. In this case, CQ stands for Console Queue. There’s now a dedicated CICS internal TCB (the CQ TCB), which enables CICS commands to be processed even when the rest of the CICS region is “non-dispatchable.” This dedicated TCB in CICS allows intervention and control of the region but isn’t available for any other functions, and is why this CICS transaction can be initiated only via the system console.