Setting DGS Options

Before starting DGS, you can set options that enable you to dictate how AMB handles log files, user exits, diagnostic files, and performance monitoring.

Logfiles

DGS provides several options for the generation of logfiles. You can set a maximum length for a logfile and set DGS to copy full logfiles to a backup filename and location. Each time a logfile becomes full, it is copied off and logging continues in a new logfile. This feature enables you to save all of your log information without creating very large and cumbersome logfiles, and can be especially useful if your system has a file size limit.

You can also set up a user exit to execute when a logfile becomes full.

User Exits

In addition to the user exit you can specify to execute when a logfile becomes full, you can also specify a user exit to execute when you start DGS and a user exit to execute when you stop DGS. You can either have your user exits execute in the background, or you can specify that they execute and show in a window. You can also set a timeout interval to specify how much time DGS should wait before executing a user exit.

Diagnostics

DGS creates several diagnostic files you can view to help you in debugging, and stores registry values as well. By default, diagnostic files and values are deleted when you regenerate your application. However, you can set DGS to save diagnostics so you can have them for future reference and to compare current generation diagnostics with previous diagnostics. DGS creates the following types of diagnostic files:

• Job Submission - .sub and .lst files stored in the JOBQUEUE directory
• Project Shadow Group - files downloaded from the mainframe into the current User Area
• User Area

DGS stores Registry Work Group values as well.

Performance Monitoring

The Performance Monitoring feature of DGS enables you to capture statistics for every task that executes during application or program generation. This information can help you to adjust your system for optimal performance. For example, one of the statistics captured by DGS performance monitoring is the amount of time it takes to execute a particular task. If a great deal of time is being spent on searching for files in the PDS order specified in your Work Group, you can adjust the PDS search order to enable DGS to find files more quickly.

Performance statistics for each job are saved in the APSFTWRK directory of your user test area in a file named performance.log. This file is overwritten each time you kick off a generation. However, you can also set your DGS options to back up the existing performance.log file before it is overwritten. DGS copies the existing performance.log file to a directory you specify, renaming the file using a convention that shows the type of object generated, the name of the object, the date it was generated, and the time it was generated as follows:

objType_objName_ddmmmyyyy_hhmmss.txt

For example, if you kicked off the generation of a screen named MASTX at noon on the 25th of December, 2020, the backup performance log filename would be:

SCREEN_MASTX_25DEC2020_120000.txt

MQ Options

You can set DGS MQ options to enable automatic reconnection to WebSphere MQ in the event that the connection between DGS and WebSphere MQ is interrupted during processing.

By default, when DGS loses its connection to WebSphere MQ, AppMaster Builder writes an error to the Logger window, disconnects the DGS from the MQ interface, and switches the Server to an AppMaster Builder Batch Server. When WebSphere MQ is once again available, you must manually restart DGS.

DGS MQ options enable you to set parameters that specify how many times the DGS should attempt to reconnect, and how much time it should wait between attempts. If a reconnection is made within the specified parameters, the DGS continues processing where it left off. If no reconnection is made, AppMaster Builder switches the Server from DGS to AppMaster Builder Batch Server. In this case, when WebSphere MQ is once again available, you must manually restart the DGS.