Checking values in the CA-XCOM for MVS defaults table

Document ID : KB000055414
Last Modified Date : 14/02/2018
Show Technical Document Details

In an environment using r11.6 and below of CA-XCOM for MVS, you may sooner or later face a situation where you need to know what are the values stored in the XCOMDFLT table.

This table is generated by the assembly/link of macro #DFLTAB and stored in a load module that is loaded at runtime by XCOM. The default name of this module is XCOMDFLT, but XCOM can be used, via a JCL parameter, to load a different module at startup.

The task of gathering the default values in use may be a bit challenging. This knowledge document discusses the ways available to XCOM personnel to determine these values whenever the need arises. This can happen, for example, when a user wonders why XCOM behaves in a given way or what may have caused the error message. Should you need to contact CA support, chances are the technician will ask for some of these values.

Ideally, you will have a tidy and clean environment and will easily be able to locate the JCL that was used to assemble and link the only defaults table in use at your site. Otherwise, you'll need to perform some extra work to determine this information. The method for gathering these values depends on the XCOM component in question.

The XCOM started task is friendly in this aspect. It has the ability to report on the default values in use. It does so at startup and prints the report to ddname XCOMLOG . Through the operator command interface, any user with the proper authority can produce the same report by entering the operator command PDFLT (issue it with MVS command '/F stcname,PDFLT').

This facility has two important drawbacks:

  • It does report ONLY over a subset of the values loaded from the defaults table and, therefore, might not show the data you are looking for and,

  • It does not report over the defaults table itself, but over the values that were copied to XCOM control blocks during initialization, resulting in some inaccurate values being reported. An example is the value for USEROVR setting (that indicates whether the XCOMJOB batch interface is going to allow a request to be entered under a userid different than the one who submitted the job.) Since this value is of no use for the started task, it does not copy the value from the default table during initialization and, therefore, what is reported is the hard coded program default.

Neither the XCOMJOB interface (used both in batch and in the ISPF interface) nor the CICS interfaces provide a parameter report facility. In these cases, and whenever the parameter report provided by the started task is not enough, do the following:

  1. Check the PARM statement in the EXEC card in the JCL that executes the XCOMJOB or XCOMXFER for the parameter DFLTAB. This gives the name of the defaults module that XCOM will load during initialization. If none is specified, it defaults to XCOMDFLT.

  2. Look for that module in the STEPLIB chain for the job step. If none, look for it in the JOBLIB chain for the job. If none, look for it in the MVS LINKLIST chain. Note the library name that holds the module.

  3. Dump the contents of the module by the following JCL:
    //DUMPT EXEC PGM=AMASPZAP
    //SYSPRINT DD SYSOUT=*
    //SYSLIB DD DISP=SHR,DSN=library.holding.xcomdflt
    //SYSIN DD *
     DUMPT XCOMDFLT XCOMDFLT
    /*
    
  4. Produce an assembly listing of the options load module. Find a JCL model in member ASM#TBLS in the samples library. Note that ONLY the assembly listing is required, so it is QUITE IMPORTANT to comment out the link edit step to ensure that no existing defaults load module is overwritten. If this happens, it can lead to problems for any job or started task that would use it as it would have its default values unexpectedly changed.

  5. Find the value in effect by checking the XCOMDFLT CSECT dumped in step 3 against the assembly listing produced in step 4.

Checking a DUMPT of a load module against an assembly listing may look challenging, but in fact it can be achieved with some understanding of what we look at. In any case, CA support technicians will be glad to assist in this task if required.

Let's see an example.

A typical XCOMDFLT assembly listing looks this way:

  Loc  Object Code    Addr1 Addr2  Stmt   Source Statement                                  HLASM R4.0  2002/04/08 11.55
                                      1 *********************************************************************** 00000010
                                      2 *  XCOM/MVS DEFAULT OPTIONS TABLE                                       00000020
                                      3 *********************************************************************** 00000030
                                      4       #DFLTAB ,                   GENERATE WITH ONLY DEFAULTS           00000040
000000                00000 001ED     5+XCOMDFLT CSECT                                                          01-#DFLT
000000 E7C3D6D4C4C6D3E3               7+DFLPGM1    DC    CL9'XCOMDFLT'                                          02-#VER 
000009 F0F461F0F861F0F2               8+DFLDAT1    DC    CL9'04/08/02'                                      #AA 02-#VER 
000012 F1F14BF5F5                     9+DFLTIM1    DC    CL5'11.55'                                         #AA 02-#VER 
000017 40D9F34BF1404040              10+DFLVRS1    DC    CL8' R3.1   '                                      #C1 02-#VER 
00001F E7C3D6D4C1D7D7D3              11+DFLAPPL  DC    CL8'XCOMAPPL'           ACBNAME                          01-#DFLT
000027 E7C3D6D4D4D6C4C5              12+DFLMODE  DC    CL8'XCOMMODE'           LOGMODE                          01-#DFLT
00002F E7                            13+DFLDUMPC DC    CL1'X'                  DUMP CLASS                       01-#DFLT
000030 E2E8E2C1D3D3C4C1              14+DFLUNIT  DC    CL8'SYSALLDA'           UNIT                             01-#DFLT
000038 404040404040                  15+DFLVOL   DC    CL6'      '             VOL SER                          01-#DFLT
00003E 03E8                          16+DFLCKPT  DC    H'1000'                 Check Point Count    #B6 LO87047 01-#DFLT
000040 0000000A                      17+DFLPRI   DC    F'10'                   PRIMARY SPACE ALLOCATION         01-#DFLT
000044 00000005                      18+DFLSEC   DC    F'5'                    SECONDARY SPACE ALLOCATION       01-#DFLT
000048 00                            19+DFLSECUR DC    AL1(DFLSECN)            SECURITY FLAG                    01-#DFLT
000049 E8                            20+DFLCATF  DC    CL1'Y'                  CATALOG FLAG                     01-#DFLT
00004A E8                            21+DFLLOGF  DC    CL1'Y'                  LOG FLAG                         01-#DFLT
00004B E7                            22+DFLLOGCL DC    CL1'X'                  LOG CLASS                        01-#DFLT
00004C 4040404040404040              23+DFLLOGDS DC    CL8'        '           LOG DESTINATION                  01-#DFLT
000054 D5                            24+DFLSMFF  DC    CL1'N'                  SMF FLAG                         01-#DFLT
000055 00                              +                                                                                
000056 00C0                          25+DFLSMFN  DC    H'192'                  SMF RECORD ID                    01-#DFLT
000058 0000EA60                      26+DFLTOUT  DC    F'60000'                TIMEOUT VALUE 1/100 SEC          01-#DFLT
00005C E7C3D6D4C1D7D7D3              27+DFLNETN  DC    CL8'XCOMAPPL'           NETNAME                          01-#DFLT

We see that each field has a hexadecimal offset into the load module ('loc' column) and a value that is shown in hexadecimal in the column 'object code'. This value is the result of assembling the corresponding source statement, which is shown in the column 'source statement'. The statement itself includes the parameter that has been passed to #DFLTAB macro or the default value if none has been specified.

Each 'human readable' value is translated into hexadecimal depending on each field type. Type 'C' (character) goes as hex EBCDIC value, while the other types are considered numeric and go as hex values of the required length.

The DUMPT output of the module generated by the above assembly looks this way:

 AMASPZAP  INSPECTS, MODIFIES, AND DUMPS CSECTS OR SPECIFIC DATA RECORDS ON DIRECT ACCESS STORAGE.
 DUMPT XCOMDFLT XCOMDFLT                                                00025029
**CCHHR- 08A700050A   RECORD LENGTH- 0001F0         MEMBER NAME  XCOMDFLT  CSECT NAME  XCOMDFLT
 000000   E7C3 D6D4  C4C6 D3E3  40F0 F461  F0F8 61F0     F240 F1F1  4BF5 F540  D9F3 4BF1  4040 40E7   *XCOMDFLT 04/08/0*
               OC         MVZ   STH        SRP           PACK MVO   SH         MVCK SH    STH  STH    *2 11.55 R3.1   X*
 000020   C3D6 D4C1  D7D7 D3E7  C3D6 D4D4  D6C4 C5E7     E2E8 E2C1  D3D3 C4C1  4040 4040  4040 03E8   *COMAPPLXCOMMODEX*
               NC    XC   MVZ        NC    OC           UNPKU UNPKU MVZ        STH  STH   STH         *SYSALLDA      .Y*
 000040   0000 000A  0000 0005  00E8 E8E7  4040 4040     4040 4040  D500 00C0  0000 EA60  E7C3 D6D4   *.........YYX    *
                                     MVCIN STH  STH      STH  STH   CLC             UNPKA      OC     *    N......-XCOM*
 000060   C1D7 D7D3  0004 E7C3  D6D4 4040  4040 03E8     0000 003C  0000 0007  C3D5 E8E3  0000 0028   *APPL..XCOM    .Y*
               XC               OC   STH   STH                                      MVCIN             *........CNYT....* 

We can see that:

  • The identifying core mark at offset 0 'XCOMDFLT 04/08/0 2 11.55 R3.1'.

  • At offset 1F, there is the value of ACBNAME (character 'XCOMAPPL'or hex 'E7C3D6D4C1D7D7D3')

  • At offset hex 40, there is the 4-byte value of primary space allocation (hex 0000 000A, which equals decimal value 10)

  • And so on and so on...

With this method, we can say for sure what the options in effect at XCOM execution are. An even safer method would be to take a dump of the XCOM address space, locate the core mark in the dump and gather the values from whatever is found in storage. This is even safer because it removes the chances of finding a wrong version of the module when searching through the libraries.

These are the methods you can use to gather the values of XCOM default parameters. The best being: to have a tidy and clean environment so you can always find the source in use for the XCOM defaults.