social share alt icon
Thought Leadership
Banner Image
September 07, 2016
Do’s & Dont’s in IMS DB Applications
Pravinraj S

Note: This technical blog is more intended for IMS and Mainframe Developers only, since most of the terms and terminologies are in relation to IMS and Mainframe technologies.

As we all know that IMS stands for Information Management System and it came into existence around 1966. Till today, it is retaining its supremacy and that is only because of its well-organized hierarchical structure, non-existence of redundant data, enhanced data security at the segment level, auto-logging facility and the most important one for today’s market is, its ability to interact with open source technologies like JAVA, .Net and few others. So, when we have a powerful Mainframe database of that sort, it’s our responsibility to know the Do’s and Dont’s in it. Hence, for the benefit of the IMS developer, I have listed down few of the main Do’s and Dont’s in IMS DB Applications.

From DBD (Database Descriptor) perspective:

  1. Critical and very important data should always be at the top and the less important one, at the bottom.
  2. Data Grouping has to be done in such a way that data storage occupies less space, faster data access, efficient retrieval mechanism and enforces the security measures at the database/segment level.
  3. Efficient usage of Indexed Database, thereby reducing I/O calls.
  4. Segment occurrence can be limited by using FREQ parameter in DBD.
  5. Advisable to have an OVFLW (overflow) dataset in the DBD in order to handle the storage exception of the primary dataset.
  6. In case of Secondary Index, ensure LCHLD (Logical Child) is being defined in the Parent DBD for the respective segment of the Secondary Index DBD, with PTR (Pointer) parameter as INDX (Index). For Secondary Index DBD, access mode should always be INDEX and its LCHILD should refer to the Parent DBD segment for which secondary index is being set.
  7. For a DBD, one can create a maximum of 255 LCHILD, 32 XDFLD (Index Field) and total number of DBD fields (inclusive of XDFLD) should not exceed 255.
  8. For the best availability and huge data handling, HALDB (High Availability Large Databases) setup is a good option.
  9. For better transaction rates and high speed processing, DEDB (Data Entry Database) is always preferred.
  10. Upon successful DBD creation, DBDGEN has to be performed immediately.

From PSB (Program Specification Block) perspective:

  1. PSB name, Transaction name and the Program name has to be always the same.
  2. In case of BMP & MPP programs, the program name, PSB and the transactions have to be registered in respective IMS Control regions.
  3. Check whether PSB, Program and Transaction are in start mode before it is being executed.
  4. For Batch processing, the type parameter of first PCB should be ‘DB’ (Database) and in case of Online it should be ‘TP’ (Terminal/Transaction Processing)
  5. In case of multiple positioning on the same database, it is good to have two PCB’s (Program Control Block) for the same database with appropriate PROCOPT (Processing Options) options.
  6. Based on the IMS calls, appropriate PROCOPT option has to be selected for the respective PCB’s.
  7. Based on the Transaction criticality and availability, appropriate PLC (Processing Limit Count), Priority and Class have to be set for the MPP transactions.
  8. In case of BMP Checkpoint and Restart programs, ensure there is a PCB entry with GSAM (General Sequential Access Method) file type for the Checkpoint and the PSBGEN statement should contain the CMPAT parameter as YES.
  9. In case of MPP, especially for transaction switch programs, ALT-PCB should be the first entry within PSB followed by IO-PCB.
  10. Upon successful PSB creation, PSBGEN has to be performed immediately.

From Program perspective


  1. Any additional compiler option for a specific program has to be mentioned as comments and that too below in the Identification Division.
  2. Below the compiler option description, it is compulsory to have a short description about the Program function.
  3. In case of any changes to the program functionality, please append the comments as mentioned below but do ensure that they are commented.



  1. Adhere to the Project recommended configuration section.
  2. For Input/Output Section, especially for the File-Control statement,
  • Check whether DDNAMES of the input & output logical file names that are defined in the program are same as in the PSB.
  • Should not define the checkpoint file (GSAM) in the SELECT clause inspite of its definition in the PSB.


  1. Check if the sequence in which FD entries appear should coincide with the sequence of the SELECT statements in the File Section.
  2. Maximum length of the Report file should always be 133 bytes


  • Check if all the variables used in arithmetic calculations are defined in packed format (Binary or Packed decimal) and signed wherever applicable.
  • Check if the error messages are set up as data items or in a file, but not hard-coded as literals in the procedure division.
  • Check if IMS abend routine copybooks are included.
  • All the IMS segment copybooks and its associated SSA copybooks have to be included.
  • In case of MPP programs, copybooks of DIF (Device Input Field), DOF (Device Output Field), MID (Message Input Descriptor) and MOD (Message Output Descriptor) have to be included.
  • In case of Checkpoint programs, checkpoint associated parameters, such as Checkpoint-Id, Save areas and other parameters have to be clearly defined in the working storage section.

In LINKAGE Section, it is always a good practice to start as below,

  • Check whether all the required PCB’s are being added in the linkage section.
  • If the program is a subroutine, all its associated parameters needs to be declared in the linkage section.


  1. PCB entries in the procedure division/Entry statement must coincide with the PSB definitions.
  2. In case of ENTRY statement, it should always be accompanied with ‘DLITCBL’, along with the PCB entries.
  3. If the program is a subroutine, check if the PCBs and other parameters are in the same order as in the called program.
  4. Check if there is a description box before each PARA, describing its function.
  5. It is good to have a separate PARA for the Initialization (include variable initialization, Open files, date calculation etc.) and terminate action (Close files, write trailer record etc.)
  6. Set the switches/flags initialization in the INIT-PARA
  7. In case the program needs the current system date for it process, try to get the system date in the INIT-PARA itself.
  8. If a PARA is going to do the Perform loop based on a flag or a field value, validate whether that particular field has been initialized before the paragraph is being executed.
  9. If there are any switches/flags used inside a PARA, ensure that they are initialized before that PARA is being executed.
  10. Check whether the last line of each PARA ends with a period “.” separately.
  11. For every IF, EVALUATE, CALL and PERFORM, there must be a corresponding END-IF, END-EVALUATE, END-CALL and END-PERFORM.
  12. There should not be more than 3 nested IF’s and to avoid that breakdown, the IF’s based on the flags should be set in the previous IF.
  13. GOTO statements must be avoided.
  14. Check if the date calculations/verifications are used only through the standard Date routine as per project standards.
  15. Ensure the period “.” is being used at the end of the last parameter of the IMS call.
  16. Almost all the error and abend scenarios have to be handled in the program itself, thereby ensuring very little chances of abnormal termination.
  17. Before any Delete/Replace call, GHU call has to be issued.
  18. The Key of the IO-Area should not be altered between the GHU call and DLET/REPL calls.
  19. In case of IMS program that uses GSAM files, the OPEN, READ, WRITE and CLOSE statements must be issued through ‘CBLTDLI’ calls.
  20. To override the IMS default path, it is better to go for appropriate Command codes based on the DB operations.
  21. Too many secondary index database calls will slow down the application and system performance.
  22. Avoid using STOP-RUN or EXIT for the IMS program termination, instead, go for the GO-BACK statement for the proper IMS region shutdown.
  23. After the compilation of the IMS programs, ACBGEN must be done but ensure its DBDGEN and PSBGEN are already completed.

WRT BMP Programs (Batch Message Processing)

  1. In case of Checkpoint-Restart programs, XRST call should always be the first IMS call, with its respective parameters.
  2. Evaluation should be done on its DLI-STATUS code and the CHKP-ID should verify whether it’s a normal start or a restart.
  3. For every checkpoint, the key values can be stored in the respective checkpoint save areas, so that it will facilitate the DB reposition in case restart process.
  4. Maximum of seven checkpoint save areas can be used.
  5. Decide on which particular DB operation, the checkpoint counter has to be incremented.
  6. The length of checkpoint parameters and save-area parameters should always be calculated prior to CHKP call.

For MFS (Message Formatting Services):

  1. The TYPE parameter of DIV statement should have the below,
  • IN (Screen to receive inputs only)
  • OUT (Display Screen)
  • INOUT (Receive the inputs, process it and display the output)

2. For any display fields, DFLD (Device Field) should be associated with literals and position but not the label name.

3. For Response/Conversation transaction type, NEXT parameter has to be always filled in with respective transaction-id name.

4. In case of MFS editable fields, DFLD length should always be plus two from its original length, to accommodate the attribute function.

5. In case of any changes in the existing screens/fields, keep a close look on the field  position and the length such that it should not affect the existing MFS setup.

6. It is always good to have the hidden space in the MFS, for the future expansion and screen navigation.

7. GU call should always be the first IMS call for the MPP Programs, followed by the respective IMS calls.

8. Verify whether the output message length has been calculated and passed, before the ISRT call is issued.

9. In case of transaction or destination switch, IMS call sequence should be ISRT, CHNG and PURG IMS calls.

10. For any transaction and destination switch, it is mandatory to use  ALT-PCB along with other IMS call parameters.


  1. Always the EXEC step must have the PGM = DFSRRC00 followed by its PARM. This may vary in some of the projects.
  2. PARM should follow the below sequence,


3. Make sure the system Id, Application group name and DB2 system parameters are pointing to the correct regions.

4. DBDLIB, RESLIB, PSBLIB and ACBLIB must exist in JCL.

5. IMSLOGR file must for BMP Checkpoint-Restart programs.

6. In case of restart, key in the corresponding checkpoint-Id against the Checkpoint parameter provided in the above JCL PARM.

7. Validate whether the PSB and Program are in START mode before Restart is being done.

8. In case of DLI mode, please don’t hold the respective DBD and PSB otherwise it will end in contention issue.

I assume that by going through the above artifacts, any IMS developer, regardless of his/her experience level, will be equipped in handling IMS DB and DC applications, with a very minimal assistance. Moreover, this will enforce the developer to set the standards in their IMS coding, thereby resulting in high-quality deliverables for the end-clients.