Space announcement This documentation space provides the same content as before, but the organization of the content has changed. The content is now organized based on logical branches instead of legacy book titles. We hope that the new structure will help you quickly find the content that you need.

Common Setup screens of COBOL


If you selected option 1  (STANDARD) on the Environments Menu and entered SETUP on the environment test screen, the Standard Setup Menu screen shown in the following figure is displayed.

Standard Setup Menu Screen

Profile: DEFAULT ---------------- SETUP MENU --------------------------
OPTION ===>

        0  ENVIRONMENT  -  Execution environments menu
        1  LOADLIBS     -  Load module libraries
        2  DDIO         -  DDIO files
        3  INCLUDES     -  Test script libraries
        4  LOG          -  Session log dataset disposition
        5  SCRIPT       -  Test script dataset disposition
        6  DSNLOAD      -  DB2 system names and DSNLOAD libraries
        7  PANEXEC      -  PANEXEC load libraries






        C  CODE COVERAGE-  Code Coverage setup options
        D  DOCUMENT     -  Document dataset disposition
        E  EXTENDED     -  Extended Setup Menu
        A  ALL          -  Display all of the above in succession (except 0)

          Press ENTER to process  or  enter END command to terminate

 The Setup Menu is available for all execution environments. Many of the screens are optional. The choices always displayed on the Setup Menu are 0 through 5, D, E, and A. They are used to specify a test environment, load libraries, DDIO libraries, and test script libraries, as well as session log, test script, and document data set attributes. In addition, an extended setup menu can be selected or all setup screens can be displayed in order.

The screens for each of these options are described in the following subsections.

Load Module Libraries Screens

A load module library list is a set of partitioned data sets containing your link-edited application programs. Code Debug TSO searches the list for the modules you want to call or debug during the debugging session. The load module library containing any module you want to intercept (i.e., set a breakpoint on) must be listed on this screen.

The Load Module Libraries screens are used to enter the dsnames of common load libraries needed for most debugging sessions. Up to 32 libraries can be concatenated in this load library list (24 on the User Library list and 8 on the Installation Library list).

The first screen you see is one of three screens. On the first one (as shown in the following figure), there is room for eight user libraries and eight installation libraries.

First Load Module Libraries Screen

Profile: DEFAULT ----------------- LOAD MODULE LIBRARIES ---------------------
COMMAND ===>
COMMANDS:  DOWN (for additional User Libraries)
User Libraries:      --->>> Include ALL libraries your program requires <<<---
        (Even if the library is in LINKLST, ie. COBOL or LE runtime libraries)
     (1) ===> 'ASJUSR1.TEST.LOADLIB'
     (2) ===>
     (3) ===>
     (4) ===>
     (5) ===>
     (6) ===>
     (7) ===>
     (8) ===>
Installation Libraries: (Changes made to this list override installed defaults)
     (9) ===> 'COBOL.C2V130X.COB2LIB'
    (10) ===>
    (11) ===> 'XT.SLS61.LINKLIB'
    (12) ===>
    (13) ===>
    (14) ===>
    (15) ===>
    (16) ===>

          Press ENTER to Process  or  Enter END Command to Terminate

If you need to list additional user libraries, enter DOWN or press the PF8 key. A second screen appears. This screen lists the user libraries you have already entered and space for eight more libraries. DOWN is still active and you can also enter UP or press the PF7 key to return to the previous screen.

Enter DOWN to receive a third screen (See the following figure), which has space for eight additional user libraries and a list of the original installation libraries. On this third screen, you can enter the UP command to return to the previous screen.

Third Load Module Libraries Screen

Profile: DEFAULT ---------------- LOAD MODULE LIBRARIES ---------------------
COMMAND ===>
COMMANDS:  UP (for additional User Libraries)
User Libraries:
     (17) ===>
     (18) ===>
     (19) ===>
     (20) ===>
     (21) ===>
     (22) ===>
     (23) ===>
     (24) ===>
Installation Libraries: (Changes made to this list override installed defaults)
    (25) ===> 'COBOL.C2V130X.COB2LIB'
    (26) ===>
    (27) ===> 'XT.SLS61.LINKLIB'
    (28) ===>
    (29) ===>
    (30) ===>
    (31) ===>
    (32) ===>

      Press ENTER to Process or Enter END Command to Terminate


Values for the two fields on these screens are described as follows.

User Libraries

You can specify up to 24 libraries. Normal concatenation rules are in effect. Libraries specified first will be searched first, and buffer space for Code Debug’s task library will be determined by the first library specified.

Installation Libraries

The installer entered the DSNAMEs of common load libraries that should be allocated to any debugging session. Usually, only COBOL subroutines and in-house utility libraries are listed here. You can override installed default libraries by specifying new libraries in these fields.

The application load libraries entered in the User Libraries fields are concatenated on top of any libraries entered in these fields.

Usage Note

Even if your application programs would normally find any required Language dependent run-time subroutines (including LE - Language Environment), without being included in the JOBLIB/STEPLIB of the batch JCL (usually from the LINKLIST or (E)LPA), the libraries must still be specified as part of the test session setup. This will ensure that Code Debug’s Task Library will be properly configured.

DDIO Files Screen

The DDIO Files screen (See the following figure) is used to enter the names of your DDIO libraries.

Important

If a program was pre-processed with Common Shared Services and the listing output still resides in the original DDIO/Shared Directory file, you do not need to supply a DDIO/Shared Directory file name in Code Debug TSO’s setup because this information is contained within the program load module directory data in compressed format.

BMC Source Support Best Practices recommends that source Shared Directories (SSD) be paired with each load library, and the SSD data set name match the load library name with either the last qualifier changed to SSD or SSD appended to it. If this process is followed, Code Debug will automatically derive the SSD name for each needed listing from the program’s load library name.

DDIO Files Screen

Profile: DEFAULT ---------------------- DDIO FILES ------------------------------
COMMAND ===>

User Libraries:

     (1) ===> 'ASJUSR1.XPEDITER.DDIO'
     (2) ===>
     (3) ===>
     (4) ===>
     (5) ===>
     (6) ===>

Installation Libraries: (Changes made to this list override installed defaults)

     (7) ===> 'AXPQA.SLS8920.DDIO'
     (8) ===>
     (9) ===>




          Press ENTER to process  or  enter END command to terminate

The fields on the DDIO Files screen are:

User Libraries

Some sites find it useful to create multiple DDIO libraries based on user, project, or some other criteria. You can enter the name of your DDIO data set in these fields.

You may fill in the data set name of the DDIO file that contains the source listing member for your program (load module). In addition to the original DDIO data set names, you may also specify Shared Directory data set names and/or LP database data set names.

Installation Libraries

If your site has a common DDIO data set, the installer entered its dsname in this field. Up to three libraries can be concatenated.

Test Script Libraries Screen

The test script library contains sets of Code Debug TSO command streams used to set up, run, or rerun a debugging session. You can copy these command streams into a debugging session with the INCLUDE command. Each script data set must be partitioned, and is allocated to the XINCLUDE ddname.

While you are executing or debugging your program, Code Debug TSO automatically generates a script of all the commands entered during the debugging session.

 Test Script Libraries Screen

Profile: DEFAULT ------------------ TEST SCRIPT LIBRARIES ----------------------
COMMAND ===>

User Libraries:

     (1) ===>
     (2) ===>
     (3) ===>

Installation Libraries: (Changes made to this list override installed defaults)

     (4) ===> 'AXPQA.TSO.INCLUDE'
     (5) ===>
     (6) ===>







          Press ENTER to Process  or  Enter END Command to Terminate

 You are not required to provide the dsname of a test script library unless you specify an Initial or Post Script on the Test Script Libraries screen (above figure), or use the INCLUDE command referencing a member not contained in a site-wide library (specified at installation).

The fields on the Test Script Libraries screen are:

User Libraries

The user test scripts library is created by you. You can create a member by copying the script data set created during a debugging session.

Installation Libraries

The installer may have entered the DSN of a test script library included on the installation tape. These sample INCLUDE scripts can be used during installation of Code Debug TSO and for subsequent verification and training.

Log, Script, and Document Data set Screens

The Log Data set, Script Data set, and Document Data set screens contain the same fields, so the fields displayed on each set of screens are discussed only once. When the text in this section and the next refer to session log or the session log data set, you can assume it refers also to script and document, if any of these three screens are involved.

Although session log, script, and document data sets are automatically created for every debugging session, they each contain a different kind of information at the end of the debugging session:

  • The session log  contains a record of the Code Debug TSO commands entered during the debugging session and the responses to them.
  • The script data set  contains each executable command entered in the debugging session. Before the debugging session is terminated, Code Debug TSO lets you copy the test script into a test script library. This predefined stream of Code Debug TSO commands can then be used to set up, run, or rerun another debugging session. The script data set is a sequential data set used for output, and the test script library is a partitioned data set used for input.
  • The document data set  remains empty unless used for diagnostic purposes under the direction of Code Debug Technical Support.

The Log Data set, Script Data set, and Document Data set screens let you display and modify the default values for the session log, script, and document data sets. Default values are supplied for the dsname and allocation parameters. The disposition of the session log, test script, and document data sets before and after a debugging session must be specified because a session log, test script, and document data set are created for every session.

Important

You can also scroll down on the Document Data set screen to enter jobcard, FTP, and customer contact information for use with the DOCUMENT command.

Log/Script/Document Data set Screen

--------------------------------- LOG DATASET --------------------------
COMMAND ===>

Log Dataset Name:           (DSNAME will be generated if blank)
          DSNAME ===>

Allocation Parameters:               Process Options:  A (Append)
      Data Class ===>                                 D (Delete)
     Space Units ===> TRK                             K (Keep)
         Primary ===> 2                              PD (Print-Delete)
       Secondary ===> 2                              PK (Print-Keep)
   Storage Class ===>                                 ? (Prompt)
            Unit ===>
          Volume ===>

Disposition After the Test:
  Process Option ===> K     (D, K, PD, PK, or ?)

Disposition Before the Test:
  Process Option ===> ?     (A, D, or ?   Used only if DSNAME is specified)
                            (Under Multi-Batch, ? = Append)


          Press ENTER to process  or  enter END command to terminate

 The screen fields shown in above figure are described as follows:

Log Data set Name

If you leave the DSNAME field blank, Code Debug TSO generates a session log, script, or document data set dsname of:


    • ' userid .XPLOG.mondd.Thhmmss' (for a session log data set),
    • 'userid.XPSCR. mondd.Thhmmss' (for a script data set), or
    • 'userid.XPDOC. mondd.Thhmmss' (for a document data set)

where mon is a 3-character abbreviation for the current month, dd is the date in the month, and hhmmss is the hour, minute, and second the data set is created.

Under Batch Connect, you must retain the session log, script, and document data sets if you want to be able to do a Step or Checkpoint restart. To retain these data sets, you must specify a name in the DSNAME field. See the Disposition After the Test for additional requirements and Checkpoint/Step Restart for more information on Checkpoint/Step restart.

Allocation Parameters

The session log, script, and document data sets are created for each debugging session. Values for the Space Units, Primary, and Secondary fields are required . Valid default values for allocation of a session log, script, or document data set are as follows:

Data Class

If required, enter the data class name defined by your site that contains the data set attributes related to the allocation of the data set. A data class is displayed only when SMS (Storage Management Subsystem) is being used.

Space Units

Valid values are TRK, CYL, or a block size (1-32760).

Primary

Valid values are 0-32760.

Secondary

Valid values are 0-32760.

Storage Class

If required, enter the storage class name defined by your site that contains the data set attributes related to the storage occupied by the data set. A storage class is displayed only when SMS (Storage Management Subsystem) is being used.

Unit

Enter the unit if required at your site. Otherwise, leave blank for defaults.

Volume

Enter the volume if required at your site. Otherwise, leave blank for defaults.

The session log, script, and document data sets remain open throughout the current session. If you modify the above parameters after these data sets have been allocated, the new values take effect the next time you begin a debugging session.

Disposition After the Test

A value is required for Process Option. The action specified is taken when you END from the test screen.

Under Batch Connect, you must retain the session log, script, and document data sets if you want to be able to do a Step or Checkpoint restart. Use either the K or PK process option to retain the data set. See the Log Data set Name for additional requirements and Checkpoint/Step Restart for more information on Checkpoint/Step restart.

Specify any of the following process options to indicate the disposition of the session log, script, or document data set after the debugging session:

D

Delete the data set without printing it. (Under Batch Connect, the data set is automatically printed, then deleted.)

K

Keep the data set without printing it.

PD

Print and delete the data set.

PK

Print and keep the data set.

?

You will be prompted to select a process option each time you exit the test screen. For more information, see Data Set Disposition Screen After a Test.

Under Batch Connect, the data set is automatically printed. If a name was specified in the DSNAME field, the data set is then saved with that name. If no name was specified, the data set is then deleted.

Disposition Before the Test

A value for Process Option is required only if a DSNAME is specified. Use any of the following process options to indicate the disposition of an existing session log, script, or document data set before the debugging session begins:

A

Append the new data set to the end of the old data set.

D

Delete the old data set and reuse the same DSNAME.

?

Displays the Data Set Disposition screen shown in Data Set Disposition Screen Displayed Before the Debugging Session Begins before the beginning of a debugging session so you can specify whether to append (option A) the new data set to the end of the existing session log, script, or document data set or to delete (option D) the existing data set before creating the session log, script, or document data set for this debugging session.

Note: Attempting to allocate a data set with the same name as an existing data set causes a file allocation error. This Data Set Disposition screen lets you specify what to do when that situation occurs.

The DDNAME field on the Data Set Disposition screen contains the ddname to which this data set is about to be allocated. For example, the session log data set is always allocated to the XPOUT ddname. The dsname you entered on the previous screen is pre-filled in the DSNAME field.

Under Batch Connect, if the data set does not exist, a step is added to your converted JCL to allocate it with DISP=(MOD,CATLG,CATLG) without displaying the Data Set Disposition screen. If the data set already exists, you must enter option A or D. If option A is specified, a step is added to your converted JCL to allocate the data set with DISP=(MOD,KEEP,KEEP). If option D is specified, two allocation steps are added to your converted JCL, the first with DISP=(OLD,DELETE,DELETE), the second with DISP=(MOD,CATLG,CATLG).

Data Set Disposition Screen Displayed Before the Debugging Session Begins

--------------------------------- DATA SET DISPOSITION -----------------------
COMMAND ===>


DATA SET DISPOSITION:
    Process Option ===>   Valid Options: A (Append new data to end of file)
                                         D (Delete old data set and reuse)



                DDNAME: XPOUT
                DSNAME: 'ASJUSR1.LOG.TEST'

The above file was to be allocated as a new output file, but it already exists.







          Press ENTER to Process  or  Enter END Command to Terminate

 Data Set Disposition Screen After a Test

Code Debug displays the Data Set Disposition screen shown as follows in the following figure after you END from the test screen so you can select a disposition process option. The data set’s dsname and the ddname to which it is allocated are pre-filled on this screen.

 Data Set Disposition Screen Displayed After the Debugging Session is Ended

------------------------------- DATA SET DISPOSITION ---------------------
COMMAND ===>

             DDNAME: XPOUT
             DSNAME: 'ASJUSR1.LOG.TEST'

 DATA SET DISPOSITION: VALID PROCESS OPTIONS: B (Browse)  K (Keep)
    Process Option ===> D                     C (Copy)    M (Move)
      SYSOUT Class ===> A                     D (Delete) PD (Print-Delete)
  Local Printer ID ===> XEROX01               E (Edit)   PK (Print-Keep)
                                                          R (Rename)
 For Process Options C, M, or R:
            DSNAME ===>
       Member Name ===>

  JOB CARD INFORMATION:             (Required for system printer)
  ----*----1----*----2----*----3----*----4----*----5----*----6----*----7--
  //ASJUSR1Y JOB (ASJUSR1),'SUE',CLASS=A,MSGCLASS=Z
  //*
  //*
  //*

          Press ENTER to Process  or  Enter END Command to Terminate

 The fields on the screen shown in above figure are:

Process Option

Any of the following process options can be specified:

B

Browse the session log, script, or document data set.

C

Copy the session log, script, or document data set to the partitioned data set named in the DSNAME field. The PDS member name must be entered in the Member Name field.

D

Delete the session log, script, or document data set without printing it.

E

Display the session log, script, or document data set so you can edit it before copying it to another data set.

K

Keep the session log, script, or document data set without printing it. The file is saved as a sequential data set by the same name.

M

Move the session log, script, or document data set to the partitioned data set named in the DSNAME field. The PDS member name must be entered in the Member Name field.

PD

Print and delete the session log, script, or document data set.

PK

Print and keep the session log, script, or document data set.

R

Rename a sequential data set and enter its new name in the DSNAME field. No member name is required because only a sequential data set can be specified for the Rename option.

Under Batch Connect, you must retain the session log, script, and document data sets if you want to be able to do a Step or Checkpoint restart. Use either the K or PK process option to retain the data set. See the Log Data set Name for additional requirements and Checkpoint/Step Restart for more information on Checkpoint/Step restart.

SYSOUT Class

A default SYSOUT class can be entered for Code Debug TSO data sets. If specified, it is used when process option PD (print and delete) or PK (print and keep) is entered. The SYSOUT class can be A-Z, 0-9, or *.

If the SYSOUT class is to be used to direct printing to the appropriate output device, JOB CARD INFORMATION must also be specified.

Local Printer ID

A default local printer ID can be specified for the Code Debug TSO data set. If specified, it is used when process option PD (print and delete) or PK (print and keep) is selected. The local printer ID is the name your installation assigned to a local IBM 328x printer (for example, XEROX01, as shown in Data Set Disposition Screen Displayed After the Debugging Session is Ended).

DSNAME

Required for process options C, M, and R. Enter the name of the partitioned data set into which the session log, script, or document data set is to be copied, moved, or renamed.

Member Name

Required for process options C and M. Enter the name of the PDS member.

JOB CARD INFORMATION

Required if SYSOUT Class is specified. Enter up to four default job statements to submit a background job to print the session log, script, or document data set when the current debugging session ends.

Db2 System Name and DSNLOAD Libraries Screen

Establishing the connection to Db2 requires a Db2 system ID and access to the Db2 programs that reside in the DSNLOAD data set that was created when Db2 was installed. The Db2 system name can be defaulted, and the DSNLOAD data sets can be placed in the installation LPALIB or LINKLIST. The DB2 System Name and DSNLOAD screen is used to define required or additional Db2 system IDs and DSNLOAD data sets for access to Db2.

Access to multiple Db2 systems and multiple DSNLOAD data sets is controlled by the entries on this screen. If your site defined a default Db2 system ID and the Db2 DSNLOAD data set is permanently allocated when Code Debug TSO is activated, then this screen can be left blank.

DSNLOAD LIbraries Screen

Profile: DEFAULT -------------- DSNLOAD LIBRARIES -----------------------
COMMAND ===>


        NAME      DSNLOAD DSNAME

(1) ===> D310 ===> 'DB2.V310X.DSNLOAD'
(2) ===> D220 ===> 'DB2.V220X.DSNLOAD'
(3) ===>      ===>
(4) ===>      ===>
(5) ===>      ===>
(6) ===>      ===>
(7) ===>      ===>
(8) ===>      ===>





 Note: Changes made to this screen override installed defaults

          Press ENTER to Process  or  Enter END Command to Terminate

The fields on the above figure are described as follows:

NAME

Defines Db2 system ID names that can be used at your site to connect to a Db2 system. DSNLOAD data sets can also be associated with the Db2 system IDs on this screen. If you use more than one Db2 system, then each should be defined on this screen.

For standard debugging sessions, specify a specific Db2 system ID to be used when activating Db2. This value becomes the system parameter option for the DSN command, and the associated DSNLOAD data sets are included in XTASKLIB.

For dialog box debugging sessions, the DSNLOAD data sets are included in XTASKLIB, but you must issue the DSN if it is required.

For IMS and BTS debugging sessions, the DSNLOAD data sets are allocated to DFSESL, as well as XTASKLIB. IMS also connects through the IMS/Db2 interface module DSNMTV01.

DSNLOAD DSNAME

Associates the Db2 system ID name with the DSNLOAD data sets. For each name, one or more DSNLOAD data sets can be defined. The following example shows four possible Db2 connections with various DSNLOAD data set combinations:

        NAME       DSNLOAD DSNAME
(1) ===> DSNX  ===> 'DSNX.LOADLIB'
(2) ===> DSNX  ===> 'DSNX.RUNLIB'
(3) ===> DSNY  ===>
(4) ===> DSNZ  ===> 'DSNZ.LOADLIB'
(5) ===>       ===> 'DSNY.LOADLIB'

The Db2 system identified by DSNX has two DSNLOAD data sets allocated to XTASKLIB.

The Db2 system identified by DSNZ has one DSNLOAD data set allocated.

The system identified by DSNY does not have any DSNLOAD data sets allocated.

A Db2 test with no system specified is allocated on the DSNLOAD data set.

PANEXEC Libraries Screen

The PANEXEC Libraries screen (See the following figure) is used to enter the library names and control card file data sets necessary to debug your application programs using PANEXEC.

PANEXEC Libraries Screen

Profile: DEFAULT -------------- PANEXEC LIBRARIES --------------------
COMMAND ===>

PANEXEC (Program Product) Load Library DSNAMEs (DDNAME PANESRL):

     (1) ===>
     (2) ===>
     (3) ===>
     (4) ===>

PANEXEC Control Card File DSNAMEs:

  DDNAME ===> PECNTL
     (1) ===>
     (2) ===>
     (3) ===>
     (4) ===>

 Note: Changes made to this screen override installed defaults


          Press ENTER to process  or  enter END command to terminate

 The fields on the PANEXEC Libraries screen are:

PANEXEC Load Library DSNAMEs

Enter the data set name normally allocated to ddname PANESRL.

PANEXEC Control Card File DSNAMES

Enter the default ddname associated with your PANEXEC control cards. The default is PECNTL.

If you normally direct your PECNTL (or site default PANEXEC control cards ddname) to a data set rather than to instream data, enter that data set in the next field.

Extended Setup Menu Screen

If you selected option E (Extended Setup Menu) from the Setup Menu, the Extended Setup Menu screen shown in the following figure is displayed.

Extended Setup Menu Screen

Profile: DEFAULT ------------------- SETUP MENU  --------------------------
OPTION  ===>

   Extended Setup Menu

         N  NEW          - NEW dataset Allocations for this TEST Profile
         W  WORK         - WORK dataset Allocations for this TEST Profile

         D  Difference   - Display Difference from Installation Defaults

         I  Inquire      - Display Test Settings for this TEST PROFILE




          Press ENTER to process  or  enter END command to terminate


The Extended Setup Menu options allow you to modify NEW and WORK data set allocation values assigned by the installer of the Code Debug product.

If the installation defaults have been changed, a warning message is issued when a test profile is selected. The D (Difference) option can be selected to report on the disparity between the options specified in the current Code Debug profile member and those specified by the installer. An example of the display is shown in the following figure.

Code Debug Test Profile Differences Screen

-------------------------  TEST PROFILE DIFFERENCES   ------------------------
COMMAND ===>

  The following is a list of areas where there are differences between the
  site defaults PROFILE and the current TEST PROFILE. The use of the RESTORE
  command will restore the installation defaults over the TEST profile options
  that have been modified.

    *****************************************************
     TEST SESSION LOAD LIBRARIES
     DB2 SYSTEM NAMES AND DSNLOAD DATA SETS


    *****************************************************

 To display the current profile’s options, type I  (Inquire) on the command line and press Enter. The resulting display includes specific options set for this test session and options obtained from the installation defaults. An example is shown in the following figure.

Test Profile Options Display

Menu  Utilities  Compilers  Help
-------------------------------------------------------------------------------
BROWSE    SYS06059.T101826.RA000.PFHABC0.R0185613    Line 00000000 Col 001 080
Command ===>                                                  Scroll ===> PAGE
********************************* Top of Data **********************************

                            XPEDITER/TSO/IMS
                          Test Profile Options
                               Release 7.7
                              09/03/12 16:02
*----------------------------------------------------------------------------*

DSName Qualifier Exit:     (Executed for first test session for a user)
       Exit ===>

General Exit:              (Executed for every test session)
Before Test ===>
 After Test ===>

New Profile Exit:          (Executed when creating new default profile)
       Exit ===>

Job Statement Exit:        (Executed before batch job submission)

The N (New) option can be selected to modify the installation values for the allocation of new, temporary, or SYSOUT data sets. Selecting this option will display the New Data sets screen (See the following figure).

New Data sets Screen

Profile: DEFAULT ---------------  NEW DATASETS  ------------------------------
COMMAND ===>

For New Datasets:
             Data Class ===>
 Space Allocation Units ===> CYL
       Primary Quantity ===> 5
     Secondary Quantity ===> 5
   Opt. Blocking Factor ===> 23476

          Storage Class ===>
              Unit Name ===>
        Volume Required ===> NO
  List of Valid Volumes ===> ______    ______    ______    ______    ______
          Unit Required ===> NO
    List of Valid Units ===> ________  ________  ________  ________  ________
          GDG Stability ===> YES

For SYSOUT Files:
   Default SYSOUT Class ===> A    (A-Z, 0-9)

 Note: Changes made to this screen override installed defaults
       Press ENTER to process  or  enter END command to terminate


The fields on the above screen are:

For New Data sets

The New Data sets area of the screen contains the following fields:

Data Class

Enter the data class defined by your site that contains the data set attributes to be used for new data sets. This field can be any name up to 8 characters. The Data Class field is applicable only if you use the Storage Management Subsystem (SMS).

Space Allocation Units

Enter TRK, CYL, or a specific block size. Use your site’s recommended default for allocating new testing data sets.

Primary Quantity

Enter a number from 0 through 32768. Use your site’s recommended default for allocating new testing data sets.

Secondary Quantity

Enter a number from 0 through 32768. Use your site’s recommended default for allocating new testing data sets.

Opt. Blocking Factor

Enter a number from 1 through 32768. Use your site’s recommended optimum for allocating new testing data sets. If your system is set up to calculate the optimal block size, set this value to zero.

Storage Class

Enter the storage class name defined by your site that contains the data set attributes to be used for new data sets. This can be any name up to 8 characters. The Storage Class field is applicable only if you use the Storage Management Subsystem.

Unit Name

Enter your site’s recommended unit name for allocating new data sets.

Volume Required

Enter YES if your site requires the specification of a volume (VOL=SER=??????) when allocating new testing data sets from TSO. Otherwise, enter NO .

List of Valid Volumes

If your site has a limited number of volumes on which new testing data sets can be allocated from TSO, enter the list here. Otherwise, leave these fields blank.

Unit Required

Enter YES if your site requires the specification of a unit (UNIT=??????) when allocating new testing data sets from TSO. Otherwise, enter NO .

List of Valid Units

If your site has a limited number of units on which new testing data sets can be allocated from TSO, enter the list here. Otherwise, leave these fields blank.

GDG Stability

Enter YES if your site’s Generation Data Group (GDG) data sets are to be referenced by relative generation numbers that refer to the same generation for the life of the job or the TSO session. Otherwise, enter NO .

For SYSOUT Files

The For SYSOUT Files area of the screen contains the following field:

Default SYSOUT Class

Enter the SYSOUT class where interactively produced SYSOUTs are to be queued (by default). An asterisk (*) causes the values defined in UADS or RACF to be used.

Work Files Screen

The Work Files screen shown in the following figure is used to specify the maximum block size for your load libraries, and to specify the XDYNAMIC allocation parameters.

Work Files Screen

Profile: DEFAULT ----------------  WORK FILES  --------------------------------
COMMAND ===>

Maximum BLKSIZE:

 Of Load Module Libraries ===> 32760


Work Datasets Default:
            Storage Class ===>
                     Unit ===> SYSDA


XDYNAMIC Allocation Parameters:      (Temporary load library)
               Data Class ===>
   Space Allocation Units ===> TRK
         Primary Quantity ===> 15
       Secondary Quantity ===> 10
         Directory Blocks ===> 15
             Dataset Type ===> PDS       (L=Library/PDSE, P=PDS, or blank=PDS)
 Note: Changes made to this screen override installed defaults

         Press ENTER to process  or  enter END command to terminate


The fields on the Work Files screen are:

Maximum BLKSIZE

The Maximum BLKSIZE area of the screen contains the following field:

Of Load Module Libraries

If your site allows concatenated user load libraries, enter the maximum BLKSIZE of the load library. Otherwise, enter the maximum BLKSIZE supported at your site.

Work Data sets Default

The Work Data sets Default area of the screen contains the following fields:

Storage Class

Enter the storage class name defined by your site that contains the data set attributes to be used for Code Debug work file allocations. This can be any name up to 8 characters. The Storage Class field is applicable only if you use the Storage Management Subsystem (SMS).

Unit

Define the DASD unit name to be used for Code Debug work file allocations. This should be a VIO eligible unit.

XDYNAMIC Allocation Parameters

The XDYNAMIC Allocation Parameters area of the screen contains the following fields:

Data Class

Enter the data class name defined by your site that contains the data set attributes to be used for the XDYNAMIC data set. This can be any name up to 8 characters. The Data Class field is not applicable unless you use the Storage Management Subsystem.

Space Allocation Units

Enter TRK, CYL, or a specific block size. Use your site’s recommended default for allocating new testing data sets.

Primary Quantity

Use your site’s recommended default for allocating new testing data sets. Provide for enough space for all modules named on an intercept screen plus modules listed with a SET DYNAMIC.

Secondary Quantity

This is usually left at zero.

Directory Blocks

Provide enough directory blocks for all modules that will go into XDYNAMIC. Allow one block for every 5 modules.

Data set Type

Enter the type of data set to be allocated for the XDYNAMIC data set. An L will cause the data set to be allocated as a PDSE file. Entering a P or blanks will cause the data set to be allocated as a PDS file. It is recommended that you specify L if you are using program objects instead of load modules. The default value is PDS.


 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*