Considerations

Be aware that certain considerations apply to using IMS Batch Terminal Simulator.

Subsections:

Execution time

IMS Batch Terminal Simulator does not simulate the execution times that could be experienced in an IMS production environment. Application program execution times under IMS Batch Terminal Simulator can be affected by the following factors:
  • Machine speed
  • Application program processing
  • Mix of other jobs within the machine

Virtual storage requirements

The IMS Batch Terminal Simulator program modules require 2 MB of virtual storage. This virtual storage is in addition to the storage that is required by IMS, and the amount of virtual storage IMS Batch Terminal Simulator must acquire dynamically by issuing GETMAINs. More virtual storage might be required depending on other products in your environment, such as Db2®, IBM® MQ, and Language Environment®, and on the storage requirements of individual application programs.

Insufficient storage problems might occur when a large number of transactions are run. These problems are due to storage fragmentation after many attaches of IMS. To avoid these problems, consider taking the following actions:
  • Increase the region size.
  • Increase the value for PLC on the ./T command.
  • Use multiple job steps.

The requirements summarized in the following table can help you estimate the amount of virtual storage required for running a particular IMS application with IMS Batch Terminal Simulator.

Table 1. Application-dependent main storage requirements
BTS queue Storage requirements
./T Transaction Data Queue 162 bytes per (./T) command. This space remains for the duration of the BTS run.
./P Patch Data Queue or ./E Maximum of 160 bytes per (./P or ./E) command. After a Patch Data Queue element has been used, the element is dequeued and the space is freed. This queue is also used to manage the SPAs that are passed to application programs. There is no maximum length for an SPA on this queue. After the SPA is passed to the application program, the element is dequeued and the space is freed.
./S SNAP Data Queue 48 bytes per (./S) command. When the use count is reduced to zero, the associated SNAP queue element is dequeued and its space freed. The SNAP queue is also used to queue requests for a particular status code on a DL/I call.
Message Queue For secondary transactions only; (segment length + 28) per segment. (Multi-segment messages are processed one segment at a time.) The message queue is managed dynamically. When an element causes an application program to be scheduled, the element is dequeued and its space is freed. The scheduled program, however, might add elements to the queue.
Statistics Queue 288 bytes per PCB against which any IMS calls are made by an application program.
3270 Teleprocessing Buffer Enough space to contain the largest I/O message of the application program.
Format Block Pool Enough space for an input area for the FORMAT data set.
Internal 3270 Screen Image 3 x lines x columns of the I/O PCB device type. The device type is specified by the ./D command.
Input Message Work Area Two times maximum input message length.
Output Message Work Area Sum of LRECL + BLKSIZE for the queue data sets.

Applications that update databases

If you are debugging an application program that updates a database, it is generally easier to have exclusive use of that database. That way you have better control of the test and the test results (exclusive use is not a requirement.) Dynamic Backout as well as Database Data Set Recovery considerations apply as they would for online updates by any other dependent region.

LRECL value for BTSOUT data set for 3270 formatting

The LRECL value specified for the BTSOUT data set can affect the output IMS Batch Terminal Simulator produces. IMS Batch Terminal Simulator checks the BTSOUT LRECL when it writes an output record. If the output is greater than the LRECL value, the output is broken up into two or more records. Normally this is not a matter of concern because the recommended value of 133 gives the best results. However, if the IBM 3278 Model 5 with the 132 character line is being simulated, some problems might occur. In supporting the Model 5, IMS Batch Terminal Simulator attempts to produce only one line of output for each line on the screen image. If the LRECL is 133, the framing characters indicating the line numbers are not shown. Also the first half byte of any field attribute character in column 1 is not shown. If the LRECL is 132 or less, IMS Batch Terminal Simulator shows all characters and framing, and two lines are produced for every line of the screen. If your printer has a large enough print line, consider setting the LRECL to 141. This setting allows all Model 5 screen image information on one print line.

Whenever you change terminal type, the screen image might appear different depending on the LRECL of the BTSOUT data set and terminal screen size. For example, after a switch from a 3278-2 (24 x 80) to a 3278-5 (27 x 132), the screen images might appear to be inconsistent with each other. This condition is caused by IMS Batch Terminal Simulator using the default screen rows and screen length from TSO for a particular terminal. In this example (3278-2 to 3278-5), to keep the screen image the same, specify the 'TERMINAL SCRSIZE(24,80)' in the TSO command language used for the application. Also, specify the ./D command similar to the following example: 
    ./D TYPE=3270-A2 SIZE=(24,80)

To make full use of the 3278-5 screen size, the MOD and the DOF must be generated again with the DEV statement of the MOD indicating TYPE=(3270,7). A ./D TYPE=3270-A7 SIZE=(27,132) command is also necessary.

Termination prior to end of job

Termination of an IMS Batch Terminal Simulator simulation run prior to normal end of job (EOJ) imposes considerations identical to the considerations in a production IMS application run. There are no logging or security functions provided by IMS Batch Terminal Simulator. However, all recovery or restart procedures, inherent in the installation's mode of operation with respect to IMS applications, are applicable to an IMS Batch Terminal Simulator run. Databases are modified with or without logging.

Note: If the application program ends abnormally and output has been inserted to alternate logical terminals, this output is lost. Correct the application program and rerun to see the output.

Using the log data set for database recovery

The following considerations apply when using the log data set for database recovery:
  • The log data set can be used for forward recovery of an IMS database data set.

    The log data set is suitable for input to the IMS Database Data Set Recovery Utility, the IMS Change Accumulation Utility, and other log utilities (including Database Recovery Control DFSLOG) whose function is to provide for forward recovery.

  • The log data set can be used to back out database changes made by a transaction that did not complete successfully.

    The log data set can be input to the IMS Batch Backout Utility where the CHECKPOINT ID is not specified. In the Batch Backout Utility JCL, either do not supply SYSIN DD statement or specify SYSIN DD DUMMY. This returns the database to its state at the last successful checkpoint written to the log.

    Related reading: See DL/I synchronization for information about application sync point.

  • In general, the log data set cannot be used to back out database changes made by transactions that completed successfully.

    In general, the log data set cannot be input to the IMS Batch Backout Utility where a CHECKPOINT ID is specified.

To enable the IMS logging facility, you must specify the IEFRDER DD statement.