Telon Application Generator generates code for Thread safe CICS applications

Products

• Telon Application Generator

Issue/Introduction

Does Telon Application Generator generate code for Thread safe CICS applications?

 

Environment

Telon Application Generator, release 5.1

Resolution

In order to make a Telon CICS program thread safe, it cannot call any multi-purpose Telon field edits, abend routines, line optimization routines, etc. The  program needs to use BMS mapping instead of Telon mapping. Field edits cannot be referenced in the program's field definitions, because Telon always generates CALLs for them. The program can only use LINEOPT=2, since LINEOPT=3 is not valid for use with BMS and LINEOPT=1 causes CALLs to TLRAMRx subroutines. It also must EXEC CICS LINK to your own CICS-specific field edits, abend routines, etc., and include no CALLs to COBOL subroutines.

If you want to make a Telon program thread safe, please generate the program, examine the generated COBOL code to identify the CALLs that need to be eliminated, and make the necessary changes to eliminate all CALLs.

When an EXEC CICS LINK command is used to link from one program to another, the program link stack level is incremented. However, calling Telon subroutines (whether statically or dynamically called) does not involve the CICS command level interface, and so does not cause the program link stack level to be incremented. Statically calling Cobol routines involves a simple branch and link to an address that is resolved at link-edit time. A dynamically called subroutine is loaded by the Language Environment, then a simple branch and link is executed. So when a routine is called by either of these methods, CICS does not consider this a change of program; the calling program is still considered to be executing, so the calling program is still considered to be the current one.

By this definition, Telon-generated programs are not necessarily thread safe. Telon-generated programs invoke subroutines (field edits, abend routines, line optimization, I/O) with a CALL rather than an EXEC CICS LINK. This is because many of them are multi-purpose: they are designed to be used by TSO, IMS/DC and batch programs as well as CICS. Accordingly, those subroutines cannot contain CICS-specific code, nor can they be accessed via EXEC CICS LINK.