• Design applications using a two-tier (or three-tier) programming model.

  CNS strongly encourages the use of the two-tier or three-tier programming models for all future CICS application development. The benefits to these techniques will surely payoff down the road.

  In the two-tier model, the presentation logic is separated from the business logic (in separate programs) and a COMMAREA (along with the EXEC CICS LINK command) is used to make them into a single transaction. For example, the program with the presentation logic would do all the 3270 mapping, both in and out. It presents the business logic program with a COMMAREA that contains all the relavent data retrieved from the screen. The business logic program then takes that COMMAREA and performs all of the processing. The result of that processing is passed back to the presentation logic program, which takes that response and builds the 3270 output screen.

  Once the business logic has been isolated from the presentation logic and given a communications area interface, it is available for use with different presentation methods. This method of coding will be useful in allowing the same business logic that currently supports 3270 transactions to be used (unchanged) with newer interfaces, such as web interfaces, external call interfaces, etc. In addition, if a type of web interface is chosen initially and a newer and better interface becomes available at a later date, the conversion from one interface to another will be easier.

  The three-tier model carries that approach one step further by separating the data accessing logic into a separate program which can be called or linked to by business logic modules. The advantage here is that if file layouts or data access methods are changed (ie: VSAM to DB2 conversions, etc), only the data access logic programs need be changed or recompiled.

• The Leap Year Rule:

  
      IF Year is evenly divisible by 4,000
  
      THEN Year is NOT a Leap Year
  
      ELSE IF Year is evenly divisible by 400
  
           THEN Year is a Leap Year
  
           ELSE IF Year is evenly divisible by 100
  
                THEN Year is NOT a Leap Year
  
                ELSE IF Year is evenly divisible by 4
  
                     THEN Year is a Leap Year
  
                     ELSE Year is NOT a Leap Year
  
      

• Check for all possible exceptional conditions after issuing a CICS command. It is always better to intercept abnormal conditions so you can give the terminal user a friendly message rather than letting a transaction ABEND. There are various ways to do this. The most common are the HANDLE CONDITION method and the RESP method. There is a very good discussion of this topic in the chapter on Dealing With Exceptional Conditions in the CICS/ESA Application Programmers Guide . Our recommendation is to use the RESP method, because it makes the application source code much easier to follow.

  How to use the RESP and RESP2 options.

  The argument of RESP is a user-defined fullword binary data area (long integer). On return from a command, it contains a value corresponding to the condition that may have been raised. Normally its value is DFHRESP(NORMAL).

  In COBOL, the use of RESP would look something like this:

  
      EXEC CICS WRITEQ TS FROM(abc)
  
                QUEUE(qname)
  
                NOSUSPEND
  
                RESP(xxx)
  
                END-EXEC.
  
  
  
      IF xxx=DFHRESP(NOSPACE) THEN ...
  
      

  In Assembler the test for the RESP value would look like this:

  
      CLC   xxx,DFHRESP(NOSPACE)
  
      BE    ...
  
      

  The RESP method of handling exceptional conditions is recommended for all new applications (rather than the HANDLE CONDITION method). It is the ONLY available choice for programs written in the C or C++ languages.

• Verify the length and content of COMMAREAs. Many programmers check for the presence of a COMMAREA by simply checking to see if EIBCALEN is greater than zero and, if true, moving the LINKAGE SECTION item DFHCOMMAREA into a WORKING STORAGE area. This technique may seem proper on the surface, but it is not. CICS has no knowledge of the length of the LINKAGE SECTION item DFHCOMMAREA. The length and layout of this item are set at compile time. At execution time, the actual length passed from the invoking program is provided in the EIB item EIBCALEN. It is the called program's responsibility to insure that EIBCALEN matches the compile time length of DFHCOMMAREA. Failure to verify that EIBCALEN matches the length of the DFHCOMMAREA passed can lead to ASRA 0C4 ABENDs, storage overlays, or invalid data being moved into the working storage area of a program.

  Rather than checking for a COMMAREA like this:

  
      WORKING-STORAGE SECTION
  
      01 WS-COMMAREA PIC X(200)
  
      LINKAGE SECTION.
  
      01  DFHCOMMAREA PIC X(200).
  
      PROCEDURE DIVISION.
  
      IF EIBCALEN > +0
  
         MOVE DFHCOMMAREA TO WS-COMMAREA.
  
      

  Verify the length like this:

  
      IF EIBCALEN = +200
  
          MOVE DFHCOMMAREA TO WS-COMMAREA.
  
  

  or

  
      IF EIBCALEN = LENGTH OF DFHCOMMAREA
  
         MOVE DFHCOMMAREA TO WS-COMMAREA.
  
      

  An alternate example which will also yield bullet-proof COMMAREA manipulation is:

  
      WORKING-STORAGE SECTION
  
      01  WS-COMMAREA PIC X(200)
  
      LINKAGE SECTION.
  
      01  DFHCOMMAREA.
  
      05 FILLER OCCURS 1 TO 200 DEPENDING ON EIBCALEN PIC X.
  
      PROCEDURE DIVISION
  
      IF EIBCALEN > +0
  
         MOVE DFHCOMMAREA TO WS-COMMAREA.
  
      

  It is also a good idea to have some identifiable data in the COMMAREA that can be checked to determine the validity of the COMMAREA as well as the length.

• When working with VSAM datasets, you can avoid deadlocks by following these rules:
  • An application must end all browses on a file by means of ENDBR commands (thereby releasing the VSAM lock) before issuing a READ UPDATE, WRITE, or DELETE (without RIDFLD) to the file.

  • All applications that update multiple resources should do so in the same order. For example, if a transaction is updating multiple records in a dataset, it can do so in ascending key order. A transaction that is accessing more than one file should do so in the same predefined sequence of files.

  • An application that issues a READ UPDATE command should follow it with a REWRITE, DELETE (without RIDFLD), or UNLOCK to release the position before doing anything else to the file.

  • A sequence of WRITE MASSINSERT requests must terminate with the UNLOCK command to release the position. No other operation should be performed before the UNLOCK command has been issued.

• Do not design funnels in your applications. An example of a funnel would be making all transactions read or update the same record for information or totals.

• Hold resources only as long as required, rather than waiting until the task is terminated to let CICS release them for you. Resource contention is always a big performance problem. Transactions which do not release resources can hold up the processing of other transactions. The transactions which are held up are also holding resources which may be needed by other transactions. Eventually the whole system can grind to a halt.

• Do not expect the TERMID or NETNAME to be repeatable each time a device logs on. For most devices, the TERMID is selected by the terminal autoinstall program at logon time by selecting the first available value in a table. The NETNAME is repeatable for SNA devices, but not for virtual LUs such as those used by TPX or TCP/IP terminals. The trend continues to move toward more use of virtual LU names and away from SNA devices. A more complete discussion of CICS TERMID and VTAM NETNAME is available on a separate page within this web site.

• Please notify the CICS systems group of obsolete programs, transaction ids, mapsets, files, and queues so that their definitions may be removed from the CICS tables. Allow the memory which these definitions occupy within the region to be returned for use by running applications, thus relieving storage constraints and providing improved CICS performance.

• In COBOL, when LINKing to the same program within the same transaction, dynamic CALL (a CALL using an identifier) is much more efficient. The first CALL issues an EXEC CICS LOAD, sets up the environment, and branches to the CALLed program resulting in approximately the same processing as LINK. All subsequent CALLs will only need to branch to the existing loaded program, resulting in a great saving in CPU resources. Some differences are that the working storage is in the last used state for all subsequent calls and the program storage does not appear in a transaction dump.

• Use RETURN IMMEDIATE instead of START. Sometimes you need to execute a sequence of particular tasks in succession. In earlier releases of CICS, this was normally done using the START command. CICS/ESA introduced a new option on the RETURN command, RETURN IMMEDIATE, which also allows you to do this. With RETURN IMMEDIATE, CICS initiates a task to execute the transaction named in the TRANSID option immediately, before honoring any other waiting requests for a task at that terminal and without accepting input from the termninal. The old task can even pass data to the new one. The new task accesses this data with a RECEIVE, as if the user had initiated the task with unsolicited input, but no input/output occurs.

  The advantages of using the RETURN IMMEDIATE command versus the START commands are many.

  • The next transaction is initiated immediately, regardless of any other transaction which may be queued to start for that terminal. If a START is used and a pending message or another started transaction is queued for the terminal, it will interrupt the flow of tasks.

  • The transition from TRNA to TRNB is much faster.

  • When using START commands, there is a period of time between TRNA and TRNB when the terminal operator may hit the keyboard and prevent TRNB from being initiated. There is no exposure to this type of problem using RETURN IMMEDIATE commands.

  • STARTed transactions can not participate in dynamic routing. Once the START is issued, the transaction must run in the predetermined region. Transactions initiated via RETURN IMMEDIATE can participate in dynamic routing, making the move to parallel systems easier.

  One thing to be aware of when changing from START to RETURN IMMEDIATE in an existing application is that the method for transferring data between transactions is different between the two methods. STARTed transactions must RETREIVE the data, while those invoked by RETURN IMMEDIATE may access any data passed via the COMMAREA.

• Use care when creating and maintaing your VSAM files.
  • Use LISTCAT to analyze your files regularly. Reorg your files frequently.

    • Make note of splits, CISIZEs, FREESPACE, and dataset extents.

    • Avoid CA splits, which can cause excessive arm movement on the DASD device, increase response time, and may use additional OSCOR. If CA splits occur often, increase CA FREESPACE.

    • Avoid multiple extents (fragmentation), which may also cause excessive arm movement and increase response time. Increase primary allocation parameter to get the file into a single extent, if possible.

  • Alter % of CA/CI FREESPACE to avoid CA/CI splits.

  • For random insertion use more CI FREESPACE.

  • For non-random insertion use more CA FREESPACE.

  • If not inserting records online, use zero FREESPACE. If inserting online, allow enough FREESPACE to avoid splits.

  • Allocate space by CYLINDERS rather than by RECORDS. Allocating space by RECORDS can cause a CA to be smaller than 1 cylinder.

  • Always specify CISIZE for the DATA component of a VSAM dataset. The recommended data CISIZE is 4096 (4K). IDCAMS will probably pick a larger size than is optimum for our online system if you let the DATA component CISIZE default.

  • Let IDCAMS pick the INDEX CISIZE for you; that is, let the INDEX CISIZE default. IDCAMS does a good job of picking the best CISIZE for INDEX components. If you prefer to specify your own INDEX CISIZE, 1K is preferred because CNS has a large number of 1K buffers specified in the CICS LSR pool.

  • Buffer space is wasted if CISIZEs are chosen which do not have matching buffer sizes in the CICS LSR pool. The only available buffer sizes in the LSR pool at CNS are 512, 1K, 2K, 4K, 8K, 12K, 20K, and 32K. A dataset with a CISIZE other than one of these will use the next larger buffer size, thus wasting the unused space in the buffer.

  • All alternate index datasets should be defined with the UPGRADE option to force VSAM to maintain all pointers to new records and keys.

  • SHAREOPTIONS(2,3) is recommended for dataset integrity purposes. There are absolutely no data integrity guarantees when using SHAREOPTIONS(3,3) - neither READ integrity nor WRITE integrity. Datasets can become corrupted and data can be lost. If you still choose to bet your data on the use of this option, in spite of the warnings, do so at your own risk (and keep your resume updated).

  • Use NOWRITECHECK when defining VSAM files.

  • Use SPEED when defining KSDS datasets and RECOVERY when defining ESDS datasets.

  • Avoid MASSINSERT if possible. If MASSINSERT is used, request that the file NOT be placed in the CICS LSR pool.

  • VSAM AIX paths should be READ ONLY. Perform all updates, insertions, and deletions against a base cluster. Updating via an alternate index is not allowed in CICS at CNS.

  • When requesting CICS table definitions for AIX paths, be sure to identify them as such in the memo. There is a parameter in the FCT which associates a path with its base cluster and should be defined properly to insure data integrity.

Back to CNS CICS Home Page Back to CNS Home Page Back to UF Home Page

Last updated: April 17, 2006 by Barry Brooks.