Effective initialization of internal tables in COBOL

Initializing internal tables in COBOL:

Click Here to Search This Site

If the internal table size is too high and the number of bytes to be initialized is very large then initialization of the internal table would be CPU intensive.

For optimizing this initialization process, a recommendation is explained below with an example

Eg: Consider an internal table- SAMPLE-TABLE which has 50,000 rows, with 100 bytes in each row. Lets say only 10 rows of the internal table are loaded with values, before initializing the table. If we use the command - INITIALIZE SAMPLE-TABLE for initializing, total of 50,000 rows would be moved with low-values or zeros with respect to their picture clause.
So here 50,000x100=50,00,000 bytes would be processed for initialization.

Instead we can have a counter variable to get the number of rows being loaded in the internal table and use the counter variable in a PERFORM loop to initialize only the rows which have been loaded. Syntax for this could be found below -

Counter Variable - CNTR would have the value 10.
we need to have the following PERFORM loop for efficient way of initializing
PERFORM INITIALIZE SAMPLE-TABLE(INDEX) until CNTR is greater than 10.

By doing so, only 10x100=1000 bytes would be processed for initializing the table and processing of 4,99,000 bytes would be avoided in initialization. If the initialization process comes in a perform loop of 10 executions, then 49,90,000 bytes would have been skipped in initializing process.

Replacing SEARCH with SEARCHALL in cobol

Click Here to Search This Site

Replacing SEARCH with SEARCHALL :

LINEAR search will be used when SEARCH keyword is used to find a particular row of an internal table. Here, every row of the internal table will be searched to check if it satisfies the required condition. Thus it degrades the performance of the job step which executes the SEARCH command. If the size of the internal table is very large, the CPU consumption by the SEARCH command will also be very high.
SEARCH ALL could be the better replacement of SEARCH command as it uses BINARY search for its search operation. Clear idea about Binary search could be found in the link - http://en.wikipedia.org/wiki/Binary_search_algorithm . There are some conditions to be satisfied for replacing the SEARCH logic with SEARCH ALL logic as listed below -

• To perform SEARCH ALL, the internal table should be in sorted order of a key field
• The key field should be defined in the declaration of the internal table
• The search function over the internal table should be performed only through key of the internal table.
• While mentioning the condition in when clause of the SEARCH ALL command, the internal table key field should be at the left side of " equal to" symbol and the value to be matched with key field should be at right side.
• Before performing SEARCH ALL logic, high values should be moved to the entire internal table(if key is defined as ascending key in the declaration)
• Before performing SEARCH ALL logic, low values should be moved to the entire internal table(if key is defined as descending key in the declaration)
• only one condition can be checked in the when clause of the search all command and it should be based on the key of the internal table
• If there are duplicate keys exist in an internal table, after positioning the row which has the required key, we can have external if checks to eliminate the rows having duplicate keys.

VSAM to IAM conversion

Click Here to Search This Site

IAM definition:

Innovation access method(IAM). It is an enhanced file format of VSAM through which we can improve the performance of the jobs which reads, updates or loads the file without any impact on the existing outputs of the jobs.

Purpose:

VSAM file has three components - CLUSTER , DATA , INDEX
IAM file has only one component - CLUSTER

As IAM format doesn’t have DATA and INDEX components, the I/Os used to access those components in VSAM format could be avoided. This reduces 2/3^rd of EXCP count and results in a considerable amount of elapsed time and CPU time savings. The savings in IAM format is proportional to the number of records in the files and the number of attempts to access the file in a job. This could be strongly realized in load jobs of the files.

Changes required:

The keyword OWNER($IAM) should be included in the cluster definition of VSAM to convert it to IAM.

VSAMCNTL cards are used to define a VSAM file in delete/define jobs. The appropriate card should be selected to include the keyword- OWNER($IAM).
Referring job log details in SAR is a better way of getting the correct del/define card of a file, as JCL overrides could be easily identified in SAR display.

The files which don’t have any scheduled reorg jobs, FRMDSN should be executed to convert the file to IAM.

Testing:

1. Del/define and load steps should be executed for both VSAM and IAM with the same cluster definition except OWNER($IAM) included for IAM. There shouldn’t be any errors in creating and loading the IAM file.
2. Any program which reads the file should be executed with the VSAM and IAM formats of the file. There shouldn’t be any records mismatch in the compare results of the outputs generated with VSAM and IAM.
   

Savings collection:

1. Use SARBCH program to obtain the CPU time and elapsed time of the jobs for its execution with VSAM as well as with IAM.
2. Reformat the output obtained in the previous step by executing the program SARPGM2.
3. Convert the savings details collected into scorecard format.
   

Cases where VSAM can’t be converted to IAM:

The VSAM which are all being used in RLS(record level sharing) mode can not be converted to IAM. The file should have STORAGE CLASS- SCRLS and DATA CLASS–DCRLS for being used in RLS mode. IAM file can not be defined with the above mentioned attributes.

Things to be kept in mind while converting a VSAM file to IAM:

1. If the file selected for IAM conversion is referred as MODEL in definition of another VSAM file which need not to be converted to IAM, then we need to include OWNER(****) to retain the file as VSAM.
2. While considering CPU savings, having data and index buffers for VSAM is more efficient than converting a VSAM to IAM. Because data and index buffers wouldn’t be effective in IAM format, as IAM don’t have data and index components.
   
3. Some times converting a VSAM which has defined with buffers to IAM may lead to negative CPU savings. Eg: IAM conversion of IRAMASTR file resulted in negative CPU savings as it is used with buffers. But this file has been left out as IAM itself by considering large elapsed time savings in critical path.
4. UARTOTAL may be calculated from the DATA component of VSAM file. As the DATA component will not exist after the file has been converted to IAM following changes should be done-
   (1) New DDNAME - SYSPRINT of the JCL step should be replaced with DDNAME – IAMPRINT.
   (2) FRMUAR should be created to get the info required for UARTOTAL from the CLUSTER of the file itself. This FRMUAR was added to refer the word “TOTAL RECORDS” from DDNAME – IAMPRINT instead of referring the word “REC-TOTAL” from DDNAME – SYSPRINT.
   
5. All the jobs which del/defines the file should be run with IAM changes, otherwise IAM files may be converted back to VSAM

Link for better understanding about IAM files -
http://www.ibmmainframes.com/about5359.html