Checking values in the XCOM for z/OS default table
Article ID: 55414
Updated On: 09-26-2022
Products
Issue/Introduction
In an environment using r11.6 and below of 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 Broadcom support, chances are the technician will ask for some of these values.
Environment
Release: XCOM for MVS
Component: xcmvs
Resolution
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 default 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:
- 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.
- 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.
- 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 /*
- 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.
- 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.
Feedback
