Minor z/OS notes
This chapter is not intended as a general z/OS guide, or as a guide to the AD-CD systems. However, several common questions or problems are discussed here.
12.1 How much storage for z/OS?
Starting with z/OS 2.3 a minimum of 2 GB storage (memory) is required1 when running z/OS under zPDT. (A minimum of 8 GB is required on other systems.) This does not mean that 2 GB is a practical system; it very much depends on what you are running with z/OS. The 2 GB size might be practical for a simple TSO system, with a few users and with no major subsystems running. It is probably not a practical system for someone using WebSphere, DB2, and significant Java applications. As always, paging levels in z/OS and the base Linux should be monitored. We observe that most zPDT users have at least 8 GB for z/OS and some are much larger.
12.2 zEDC emulation
zPDT GA9 provides limited zEDC emulation for z/OS. The limitations are these:
1. The compressed (“deflated”) data produced by the emulated zEDC is likely to be a different size than what would be produced with a hardware zEDC feature. The emulated zEDC compressed files are often smaller than those produced with the “real” hardware.
2. Data compressed with the zPDT emulated zEDC cannot be uncompressed (“inflated”) by a hardware zEDC feature. However, data compressed by a “real” zEDC can be inflated by the zPDT emulation.
3. Use with z/VM (or z/OS running under z/VM) is not supported.
Other than these limitations, the zPDT zEDC functions in the same way as a hardware zEDC feature on a large z System. This includes the automatic deflation and inflation during routine data use by z/OS, assuming DFSMS is properly set up. In general, the only time actual deflated data is seen is when dumping data or volumes with ADRDSSU or a similar product. The second limitation means that data dumped with ADRDSSU (or a similar product) cannot be moved to a “real” zEDC system and inflated there. Otherwise, zEDC usage is the same as it would be on a large z System.
To use zEDC the devmap needs a stanza such as the following:
[pcipchid]
name awszedc 120 zedc
function 0c0 3
The “120” in the example is a pchid number, the “0c0” is a function identifier, and the “3” is a virtual function number. The pchid and function identifiers are 3 or 4 arbitrary hex digits and the virtual function number must be in the range 1 to 15. These values are used internally in zEDC emulation but have no connection to any other configuration parameters. If more than one emulated zEDC is defined, the pchid and function identifiers must differ.
We have found that the zEDC does not need to be included in the IODF; z/OS discovers it automatically. To use zEDC, a software feature must be enabled in PARMLIB member IFAPRDxx, as follows:
PRODUCT OWNER('IBM Corp')
NAME('z/OS')
ID(5650-ZOS)
VERSION(*) RELEASE(*) MOD(*)
FEATURENAME(ZEDC)
STATE(ENABLED)
We also specified PARMLIB member IQPPRM00 as follows, and added an IQP=nn statement to the relevant IEASYSxx member:2
ZEDC,MAXSEGMENTS=4,DEFMINREQSIZE=4,INFMINREQSIZE=16
Once started, z/OS commands D IQP, D PROD,REG,FEATURENAME(ZEDC), and D PCIE can be used to verify that z/OS has detected it correctly.
12.3 Maintenance for AD-CD z/OS systems
Users of the AD-CD z/OS systems have long requested a method of downloading PTFs. A method is in place to allow bulk downloading of PTFs in a format somewhat equivalent to the “PUT tapes” that were formerly used for z/OS maintenance. (These are no longer in tape format, but the terminology remains. PUT stands for Program (or product) update tape.3) These downloads are not provided by zPDT; they are provided by the AD-CD team. In principle, anyone who has authority to download the z/OS AD-CD volumes from the IBM Dallas site can also download the material described here.
This optional service provides software maintenance for the products in the z/OS AD-CD package. This service is for experienced z/OS systems programmers and is not intended for casual AD-CD users. Most AD-CD users will elect to obtain z/OS product maintenance through the periodic AD-CD releases as they have in the past. This facility might not be appropriate for all zPDT users for two key reasons:
•The PUTs are large, typically in the range of 8 GB for each PUT. The PUTs are not cumulative, meaning that you might need to download and maintain multiple PUT releases.
•Substantial SMP/E skills are needed to use the materials. There are multiple ways the material can be handled by the user and by SMP/E.
Each PUT is divided into several approximately 1 GB files on the Dallas site. These files would normally be concatenated for use by z/OS.4 PUTs have names such as PUT1812 representing PUT number 12 for 2018.
The Dallas site is at this address:
A user name and password are required; this user name is unique to the Dallas download site and must be authorized for AD-CD z/OS downloads to be accessed. The Dallas group intends to maintain eight PUT levels on this site, but circumstances might vary this number. Navigating this site provides selection of various PUT levels, such as PUT1811 for example. Selecting a PUT level lists the download files for that level, as in this example:
‘HTTPD1.fz206.f140.PUT1812.TRS10.BIN’
These can be downloaded through your browser download function. We suggest you rename the files when downloading them.5 As an example, one recent PUT file contain 999 PTFs in 78 million records, and is typical of recent PUTs. The large size of these files is usually due to very large PTFs for UNIX System Services programs, especially for Java functions.
At the time of writing, the first file in a PUT level is small and contains only ALIAS statements for SMP/E. The remaining files tend to be large and are separated at PTF boundaries. After the multiple files for a given PUT are downloaded to Linux, they should be transferred (with FTP) to z/OS files in a specific format. The receiving z/OS file (from the FTP transfer) must be RECFM=FB and LRECL=1024; the block size does not matter. The FTP transfer must be binary. After transferring each file to z/OS, each must be processed by AMATERSE.
We found the easiest way to download the PUT files is to allocate a single receiving data set (RECFM=FB, LRECL=1024) for FTP. After each FTP we ran an AMATERSE job to uncompress the data set and assign it a logical dataset name. The first data set in the PUT (in the TRS1 file) contains SMP/E ALIAS statements and this data set is RECFM=VB, LRECL=255. The remainder of the data sets (containing the PTFs) are RECFM=FB, LRECL=80. The job we use is as follows:
//UNPK JOB 1,OGDEN,MSGCLASS=X
// EXEC PGM=AMATERSE,PARM=UNPACK
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DISP=SHR,DSN=OGDEN.PUTUP
//SYSUT2 DD DISP=(NEW,CATLG),UNIT=3390,VOL=SER=WORK09,
// DCB=(LRECL=80,RECFM=FB,BLKSIZE=8000), for PTF files
// SPACE=(CYL,(1500,50),RLSE),DSN=PUT1812.TRS2
//* DCB=(LRECL=255,RECFM=VB,BLKSIZE=8000) for TRS1 file only
We use FTP to transfer a file from Linux to OGDEN.PUTUP (which was allocated with 1500 cylinders, RECFM=FB, LRECL=1024); we then alter the AMATERSE job to have the right output data set name, and run the job. We repeat this cycle for all the files in the PUT. The final result is a series of data sets, PUT1812.TRS1, PUT1812.TRS2, and so forth. For a different PUT level we create a new high level qualifier, such as PUT1901 and so forth.
12.4 z/OS CP and memory display
The z/OS d m=cpu and d m=stor commands display information similar to the following examples:
d m=cpu
ID CPU SERIAL
00 + 000971090
CPC SI = 1090.306.IBM.02.000000000000097
 
d m=stor
REAL STORAGE STATUS
ONLINE-NOT RECONFIGURABLE 0M-3500M
In the example, 1090 is the z System machine type and 00097 is the z System serial number assigned by our 1090 USB hardware key. Each zPDT hardware key assigns a different z System serial number.6
12.5 Java performance
z/OS Java performance might be a problem under zPDT. The basic cause lies with the very heavy system overhead (CPU and I/O) involved when starting z/OS Java applications, especially applications that load many classes. The following notes might help improve performance in some cases; the improvements can be substantial in some cases.
General base system
Even simple Java applications tend to perform heavy zFS I/O during startup, as the Java virtual machine loads the class libraries from the disk archives. If this I/O is contained mostly in the zFS cacne and/or the Linux disk cache, general performance is improved. In other words, more PC memory can help. There are no specific Linux parameters for tuning the disk cache. The Linux free -m command can be used to monitor PC memory use, although interpretation of the data produced can be a little difficult.
The raw performance of the base PC is an obvious concern, as is anything that can detract from this such as virutalization at the Linux level or at the z/VM level.
Basic Java tuning
There are a variety of approaches to tune the JVM start-up, depending on your application characteristics, deployment pattern and performance metrics. JVM features, like Quick Start and Sharedclasses caching, along with tuning of garbage collection settings, can improve https://jazz.net/wiki/bin/view/Main/SetupBuildForPerformance#Java_startup_time_and_ant_tuning
Current Java implementations use SIMD (“vector”) instructions to accelerate string, crypto and arithmetic operations on “real” hardware. The performance of these instructions varies with zPDT and, in some cases, Java performance might be better if the SIMD instructions are not used. This can be done by including the statement -Xjit:disableAutoSIMD in the jvm.options parameters used for your Java application.
DBB release 1.03 (and later) contain a persistent JVM that can substantially improve performance. Verify that you are at least at level 1.03.
RTC usage
We have noted that LAN performance between an RTC client system (that is, a separate PC) and the RTC server (z/OS) can be very dependent on LAN speed -- much more so than you might expect. We suggest you review the material in 7.6, “Performance problems” on page 142.
RESOLVER timeouts
With current z/OS Java levels an unexpected Java performance problem can occur if you enable the z/OS RESOLVER, specifying one or more external name server IP addresses, and if the RESOLVER fails to connect to the name servers. In this case any Java application that is started (including javac) hangs until the RESOLVER experiences a time out trying to connect to the name servers. This is true even for Java applications that have no LAN or TCPIP usage. The length of the application hang depends on the timeout parameter in the RESOLVER, but is typically something like 60 seconds.
This issue can be resolved by simply not running the RESOLVER, or by not specifying external IP addresses of name servers for it, or by verifying it connects to a working name server. With IBM SDK for z/OS, Java Technology Edition, Version 8 SR5 FP35 (8.0.5.35) or newer, the JVM option -XX:-ReadIPInfoForRAS will instruct the JVM to not query IP information during start up, and will bypass this RESOLVER issue
zOSMF
Recent z/OS AD-CD systems automatically start zOSMF. This startup, using default parameters, takes considerable time (both CPU and elapsed). If you do not want zOSMF started automatically, you can take two approaches:
•Prevent any zOSMF startup. To do this, edit member IZUPRMNO in the ADCD PARMLIB to read as follows:
AUTOSTART(CONNECT)
AUTOSTART_GROUP(‘NONE’)
•Allow zOSMF to connect to a running zOSMF elsewhere in your sysplex (if it exists), but do not permit it to start on your current z/OS. To do this, use PARMLIB member IZUPRM00
In both cases, edit the IEASYSxx member(s) that you use in the ADCD PARMLIB, and change the IZU=xx parameter to IZU=NO or IZU=00.
If you want to use zOSMF there are a number of tuning steps that can help performance depending on exactly how you want to use zOSMF. You can reduce zOSMF startup time by reducing the number of plugins and/or removing the help function. Removing the help function can be done as follows (working within OMVS):
cd /usr/lpp/zosmf/installableApps
mv izughelp.ear izughelp.ear.bak
We found this change reduced the zOSMF startup CPU time by about 50% and the elapsed startup time by about 40%. It also resulted in more of the elapsed time working in a single thread mode and having less effect on other system activity. At the time of writing, APAR PH06678 was planned to address the startup time associated with the help function and this might be incorporated in AD-CD systems released in 2019.
One of the tables used with zOSMF can be increased in size, reducing zOSMF startup time substantially. In /var/zosmf/configuration/local_override.cfg add the following line:
JVM_OPTIONS=-Xscmx72m -Xscmaxaot30m
Additional Java tuning options specific to zOSMF are in the following OMVS file:
/var/zosmf/configuration/servers/zosmfServer/jvm.options
This file is in ASCII. Within OEDIT the commands SOURCE ASCII and RESET SOURCE can be used to work with ASCII data.7
12.6 Excessive Health Checker messages
The Health Checker is started automatically under z/OS 2.1 and later version. It is a useful tool, but it might check for details that are not relevant to zPDT users. As an example, when running a parallel sysplex system8 we might see the following message on the MVS console:
05.38.33 S0W1 STC00783 HZS0002E CHECK(IBMXCF,XCF_CF_STR_NONVOLATILE):
IXCH0222E A coupling facility structure user request for non-volatility
and failure-isolation from connectors is not satisfied.
The message is repeated at intervals. You can delete this health check as follows:
1. In the AD-CD z/OS 2.1 system IBMUSER has only read access to the Health Checker controls.9 You need update access. Issue the following commands (when logged on as IBMUSER) in the ISPF option 6 panel:
PERMIT HZS.** CLASS(XFACILIT) ID(IBMUSER) ACC(CONTROL)
SETROPTS RACLIST(XFACILIT) REFRESH
2. Go the SDSF primary option menu and select option CK to access the Health Checker. Scroll through checks looking at the Status column on the right of the screen. This column contains text such as SUCCES, INACTI, and EXCEPT. Enter the letter “S” at the beginning of any line to see more detail about it. The EXCEPT text means that the Health Checker found a problem with this item.
3. Find the check for the NONVOLATILE condition and enter the letter “H” on the line to make the check inactive or “P” to delete the check.
12.7 z/OS spin loop timeouts
A z/OS spinloop might time out and produce an S071 ABEND. This can be triggered by many different circumstances. You can change this time value by creating or altering member EXSPATxx in PARMLIB:
member EXSPAT00
SPINRCVY ABEND
SPINTIME=60
The most common reasons for SPINLOOP problems are an overcommitted virtual environment, disk cache writes when very large PC memory is used, or very high I/O rates from multiple application tasks. In rare cases, a situation with Hyper-Threading has produced SPINLOOP delays.
12.8 Larger 3270 display
The x3270 terminal emulator can be started with an optional parameter, as follows:
$ x3270 -port 3270 -oversize 133x60 localhost &
This produces a 3270 window with 133 columns and 60 lines. (Other sizes may be specified; this is simply an example.) Basic TSO does not use the “extra” window space. ISPF can use it if max is specified for the window format in the ISPF option 0 panel.10 (ISPF does not use the extra width unless a data set being displayed or edited has records that can use the extra width.)
Another method is to define a model 5 3270 terminal:
$ x3270 -model 3270-5 localhost:3270 & (ampersand not needed if in devmap)
However, the “standard” 3279-5 has only 27 lines.
12.9 z/OS disk STORAGE space
In some circumstances, z/OS functions use STORAGE volumes11 for disk allocations. The distributed z/OS AD-CD systems generally have only a single STORAGE volume, usually named xxSYS1. For anything beyond trivial z/OS usage, we strongly recommend that at least one additional 3390 volume should be defined and mounted as a STORAGE volume. A STORAGE volume is created by statements in the VATLSTxx member in PARMLIB. For example,
VATDEF IPLUSE(PRIVATE),SYSUSE(PRIVATE) <===default values; do not change
D2SYS1,0,0,3390 ,Y
GEORGE,0,0,3390 ,N <==we added this
WORK* ,0,0,3390 ,N <==we added this
The format is fixed and the spaces shown are important. Briefly, the parameters for volumes are:
1. The volume serial number, in six columns. An asterisk matches any volser with the specified characters.
2. The first ‘0’ is the mount attribute and is normally set to ‘0’ unless there are complex mount circumstances.
3. The second ‘0’ is the use attribute. This is important. The value ‘0’ defines a STORAGE volume. Value ‘1’ defines a PUBLIC volume and value ‘2’ defines a PRIVATE volume. The VATDEF statement sets the default use attribute to PRIVATE.
4. The device type, in eight columns, left justified and padded with blanks.
5. An indicator whether z/OS should issue a MOUNT request for the volume. The value ‘Y’ indicates that z/OS will request this volume to be mounted at IPL time if it is not already mounted. Generally, ‘N’ is appropriate for local STORAGE volumes.
The placement of SVC dump dataset can create a problem. By AD-CD default they are on the xxSYS1 volume.12 An MVS command can be used to direct SVC dumps to new volume(s); the command would be similar to DUMPDS ADD,VOL=(volser,volser,volser). Much more sophisticated controls are available through SMS functions, but these require administrative work to create the desired environment.
12.10 Stand-alone z/OS dump
The z/OS stand-alone dump (SAD) is a program that is started (IPLed) from tape or disk. It does not run under z/OS. However, it assumes that z/OS is present in z System memory at the time the stand-alone dump is started. The stand-alone dump program is sensitive to the release of z/OS that is being used and must match the z/OS release. A new version of the stand-alone dump program should be generated whenever a new release of z/OS is installed.
This section describes a simplified use of stand-alone dump based on the AD-CD z/OS system release 2.2, but the comments should apply to any recent z/OS release. The dump program is placed on an “IPLable” disk volume and the dump output must be directed to a different disk volume. The stand-alone dump program (and dumped output) can be used with tape volumes, but this is not further described here.
Disk volumes
Two disk volumes are referenced here. One is for the dump program itself, which is relatively small (about 100 tracks). This volume also contains IPL text to start the stand-alone dump program. This volume must be mounted as PRIVATE to run the dump generation job, but can be in any mount status when IPLing the dump program. An additional rule is that the SAD IPL volume cannot contain a paging dataset for the system being dumped.
The other volume is for the dump itself.13 A stand-alone dump can be large: hundreds of cylinders up to many thousands of cylinders. In our example we assume a suitable volume is mounted at address AC0. Before using the stand-alone dump program, you must create the dump output data set on this volume using an IPCS or REXX utility function.
The dump program (that you IPL) cannot be on the same volume that is to receive the dump data.
12.10.1 Generating a stand-alone dump program
The following job generates the stand-alone dump program and writes it on volume LOCAL1. You later IPL it from this volume when you want to take a stand-alone dump.
//SADBILL JOB 1,OGDEN,MSGCLASS=X,REGION=40M
// EXEC PGM=AMDSAOSG
//SYSLIB DD SYS1.MACLIB,DISP=SHR
// DD SYS1.MODGEN,DISP=SHR
//DSFSYSIN DD DSN=&DSFSYSIN,DISP=(,PASS),
// SPACE=(80,(9,1)),UNIT=SYSDA
//TRK0TEXT DD DSN=&TRK0TEXT,DISP=(,PASS),
// SPACE=(4096,(4,1)),UNIT=SYSDA
//GENPRINT DD SYSOUT=*
//GENPARMS DD *
AMDSADMP IPL=D3390,VOLSER=LOCAL1,CONSOLE=(700,3279),OUTPUT=DAC0
END
/*
//PUTIPL EXEC PGM=ICKDSF
//IPLDEV DD DISP=OLD,UNIT=3390,
// VOL=(PRIVATE,RETAIN,SER=LOCAL1)
//TRK0TEXT DD DSN=&TRK0TEXT,DISP=(OLD,DELETE)
//SYSIN DD DSN=&DSFSYSIN,DISP=(OLD,DELETE)
//SYSPRINT DD SYSOUT=*
Check the JES2 output when the job ends to ensure that it completed correctly. This is a somewhat unusual job. If there are error messages (perhaps about PUTIPL SYSIN problems or a message from ICKDSF) you must delete the dump program data set (on volume LOCAL1 in this example) before trying the job again. It will have data set name SYS1.PAGEDUMP.VLOCAL1. The format of the GENPARMS input conforms to basic assembly language rules, with the continuation indicator in column 72 and the continued text starting in column 16.
If you have already written IPL text on the dump program volume (LOCAL1 in this example), there will be an operator message and reply needed before the IPL text is replaced. Remember that this volume (LOCAL1 in the example) must be mounted PRIVATE when this job is run.
The error messages (or non-zero return codes) seen when attempting to run this job are not always helpful. There appears to be three common problems:
•The target volume for the dump program (the “IPL volume”) must be mounted PRIVATE while installing the dump program.
•The dump program and the target for the dump output cannot go on the same volume. You will always have at least two disk volumes involved. In the example job, the IPL text and dump program are placed on volume LOCAL1. The dump output is placed on the volume at address AC0. This volume must have preallocated space for the dump output.
•The dump program (on the IPL volume you designate) must be deleted before you can try the job again.
12.10.2 Stand-alone dump output dataset
Output (“the dump”) from the Stand Alone Dump program requires a preallocated dataset. This can be created with IPCS or with a REXX program named AMDSADDD. Briefly, the REXX program can be used by going to ISPF option 6, entering “AMDSADDD” and replying to the prompts as follows:
What function do you want .....
define
Please enter the volume serial ....
BIGVOL (assume BIGVOL is at address AC0 in our example)
Please enter device type .....
3390
Please number number of cylinders.....
3000 (this might be a reasonable size...)
Do you want the dataset cataloged...
n
Specify the DSNTYPE. Reply BASIC, or LARGE or EVTREQ...
large
Specify additional attributes
no
 
Data set SYS1.SADMP is allocated on volume BIGVOL
As described here the dump dataset can be used for only one dump. To reuse it you must reset or clear it. This is done with the same AMDSADDD program, selecting a different option at the first prompt.
12.10.3 Operating a stand-alone z/OS dump
We assume you have been running z/OS and need to take a stand-alone dump for some reason:
$ stop all (stop the CPs)
$ ipl AB3 (assume volume LOCAL1 is mounted at this address)
Wait about 10 seconds and press Enter on the 3270 console at address 700. This produces console messages similar to these:
AMD083I AMDSADMP: STAND-ALONE DUMP INITIALIZED. IPLDEV: 0580 LOADP:
AMD001A SPECIFY OUTPUT DEVICE ADDRESS (1): (press Enter)
AMD101I OUTPUT DEVICE: 0AC0
SENSE ID DATA: FF 3490 10 3490 40 BLOCKSIZE: 29,120
AMD011A TITLE=my dump stuff
AMD005I DUMPING OF READ STORAGE NOW IN PROGRESS
AMD005I DUMPING OF PAGE FRAME TABLE COMPLETED
etc
AMD029D REPLY W TO WAIT AFTER NEXT FULL SCREEN, ELSE REPLY N; REPLY=n
etc
12.11 Moving 3390 volumes
The following text describes a generic method of moving 3390 volumes between z/OS systems (including z/OS on zPDT). Another method, using a client/server application provided with zPDT, is described in Chapter 15, “DASD volume migration” on page 295.
zPDT-emulated DASD volumes can be transferred to other systems in several ways. Sending a volume to another zPDT system is especially easy. The Linux file that holds the emulated 3390 volume can simply be copied.14 Optionally, the copy could be compressed (with gzip, for example) for transmission. The transmission could be by FTP, by a USB thumb drive, by burning a CD or DVD, or by various other means. The key concept is that a large Linux binary file is being transferred.
Moving an emulated 3390 volume to (or from) a non-zPDT system is a little more complex, because it must be handled in a z System format instead of a Linux format. The traditional method is to dump the volume to tape (using the ADRDSSU program) and then restore the tape on the target system. This method can also be used with emulated tapes (in awstape format), provided that both the sending and receiving systems can use this format.
The following example assumes both systems cannot use awstape format (otherwise we would use the easier method of creating a dump tape in awstape format). We assume there is a network connection between the source z/OS and the target z/OS system. We also assume that the target system is a zPDT system, although this is not a requirement for the technique described. See Figure 12-1.
Figure 12-1 Overview of our example
Preparation
We need z/OS disk space to hold a 3390 volume dump and to hold a reformatted volume dump. These can be large data sets. You might have sufficient space on existing z/OS volumes; we elected to create three new volumes for holding large temporary data sets. We did this using normal zPDT techniques. First we created three new emulated 3390 volumes using the alcckd command (done while zPDT is not operational). The placement (/z directory), model (3390-3), and names of the files (TEMPnn) are all arbitrary.
$ alcckd /z/TEMP01 -d3390-3
$ alcckd /z/TEMP02 -d3390-3
$ alcckd /z/TEMP03 -d3390-3
We then added these volumes to our devmap. The addresses specified (AA0, AA1, and AA2) are unused address that are known as 3390 devices for our z/OS. (That is, z/OS has these addresses specified as 3390 devices in the IODF it uses during IPL. The AAx addresses are suitable for the default IODF in the z/OS AD systems.)
[manager]
name awsckd 0001
....
....
device AA0 3390 3990 /z/TEMP01
device AA1 3390 3990 /z/TEMP02
device AA2 3390 3990 /z/TEMP03
We then started zPDT and IPLed z/OS. During z/OS startup the new devices are recognized as uninitialized volumes and are varied offline. When z/OS was ready, we ran a job to initialize the volumes:
//BILL123 JOB 1,OGDEN,MSGCLASS=X
// EXEC PGM=ICKDSF,REGION=40M
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
INIT UNIT(AA0) NOVALIDATE NVFY VOLID(TEMP01) PURGE -
VTOC(0,1,05)
INIT UNIT(AA1) NOVALIDATE NVFY VOLID(TEMP02) PURGE -
VTOC(0,1,05)
INIT UNIT(AA2) NOVALIDATE NVFY VOLID(TEMP03) PURGE -
VTOC(0,1,05)
/*
The z/OS operator must reply U to a ICK003D message for each volume. The volsers (TEMP01, and so forth) are the same as the Linux file names; this is not required but is a good practice. After the volumes are initialized, they can be varied online to z/OS, using the MVS console:
vary aa0-aa2,online
12.11.1 Create a source dump
A normal ADRDSSU job is used to dump the source volume. Our example uses WAS001 as the volser of the source volume:
//BILL456 JOB 1,OGDEN,MSGCLASS=X
// PGM=ADRDSSU,REGION=40M
//SYSPRINT DD SYSOUT=*
//IN DD UNIT=3390,VOL=SER=WAS001,DISP=SHR
//OUT DD UNIT=3390,VOL=SER=TEMP01,DISP=(NEW,CATLG),
// DSN=OGDEN.OUT.DUMP,SPACE=(CYL,(200,200))
//SYSIN DD *
DUMP INDD(IN) OUTDD(OUT) ADMINISTRATOR COMPRESS OPTIMIZE(4)
/*
The space specified in the output DD statement might need to be adjusted, depending on the contents of the source volume. We next created another data set with specific DCB attributes.15 (This step could be done using ISPF 3.2 functions, but we used a batch job to provide better documentation.)
//BILL567 JOB 1,OGDEN,MSGCLASS=X
// PGM=IEFBR14
//MAKEIT DD UNIT=3390,VOL=SER=TEMP02,DISP=(NEW,CATLG),
// DSN=OGDEN.XMIT.DUMP,SPACE=(CYL,(200,200)),
// DCB=(LRECL=80,RECFM=FB,BLKSIZE=3120)
We then used the TSO xmit command to reformat the dump:
xmit x.y ds('ogden.out.dump') outdsn('ogden.xmit.dump')
This command can take considerable time if a full volume is being processed. The result of these steps is a volume dump in a format known to z/OS, but also in a format (fixed block) that can be handled by FTP. The x.y positional operand is needed in xmit, but is meaningless in this example. Note that the terse program could be used instead of xmit.
It is important to understand the reason for the xmit step. In the general case, FTP does not understand the block and record structure of a z/OS file (such as the ADRDSSU output file). This information is lost during FTP and the resulting file is not usable. The xmit program changes the ADRDSSU dump file into a fixed block, fixed record format. The general FTP process does not understand this either. However, if the transferred (with FTP) file is stored in the receiving z/OS with the same fixed block and LRECL size, the file is usable.
Some FTP situations allow additional parameters such that the original block and record characteristics of a file are retained and the xmit step could be skipped. This can be done in a z/OS to z/OS FTP transfer. The method presented in this section assumes the more general case in which the FTP transfer does not retain the original block/record information.
12.11.2 Send dump to Linux
We then sent the xmit-formatted dump to Linux, using an FTP connection from Linux to z/OS. We used the zPDT tunnel facility for the connection in our example, but any TCP/IP connection to z/OS could be used. The IP address for z/OS is 10.1.1.2 in this example:
$ ftp 10.1.1.2
Name (10.1.1.2:ibmsys1): ibmuser
Password: xxxxxx
Remote system type is MVS
ftp> cd 'ogden'
ftp> lcd /tmp
ftp> bin
ftp> get 'xmit.dump'
ftp> bye
This example has the FTP connection initiated from the Linux side. It could be done from the z/OS side, provided the Linux system has an FTP server running.
The dump is now in /tmp/xmit.dump as a normal (large) Linux file. It can be transmitted elsewhere using any technique suitable for a large Linux file. It could be compressed (using gzip, for example.) At this point the dump (OGDEN.OUT.DUMP) and the reformatted dump (OGDEN.XMIT.DUMP) on the source z/OS system can be deleted if disk space is a concern.
You can skip this intermediate Linux step if there is a direct FTP connection between the source z/OS system and the target z/OS system.
12.11.3 Receive dump
There are fewer complications if two data sets are preallocated on the receiving z/OS system. One data set is the target of an FTP transfer from Linux (or some other source) and the other is for the output of the TSO RECEIVE function. This last data set is then the input to a RESTORE job.
//BILL678 JOB 1,OGDEN,MSGCLASS=X
// PGM=IEFBR14
//D1 DD UNIT=3390,VOL=SER=TEMP01,DISP=(NEW,CATLG),
// SPACE=(CYL,(200,200)),DSN=OGDEN.XMITR.DUMP,
// DCB=(LRECL=80,RECFM=FB,BLKSIZE=3120)
//D2 DD UNIT=3390,VOL=SER=TEMP02,DISP=(NEW,CATLG),
// SPACE=(CYL,(200,200)),DSN=OGDEN.UNXMIT.DUMP
The dump file can be sent from Linux to z/OS using FTP. (If the file was compressed in Linux it must be uncompressed before sending it to z/OS.) Our example uses IP address 10.1.1.2 for z/OS because, for demonstration purposes, we used the same zPDT z/OS system that we used to create the dump volume. In practice, this is likely to be a different z/OS system that might not be in a zPDT environment.
$ ftp 10.1.1.2
Name (10.1.1.2:ibmsys1): ibmuser
Password: xxxxxx
Remote system type is MVS
ftp> cd 'ogden'
ftp> lcd /tmp
ftp> bin
ftp> put xmit.dump xmitr.dump
ftp> bye
We then used TSO to reformat the dump into the original format created by ADRDSSU:
receive indsn('ogden.xmitr.dump')
(reply to the prompt with) DSN('ogden.unxmit.dump')
Finally, the volume can be restored in z/OS:
//BILL890 JOB 1,OGDEN,MSGCLASS=X
// PGM=ADRDSSU,REGION=40M
//SYSPRINT DD SYSOUT=*
//IN DD UNIT=3390,DSN=OGDEN.UNXMIT.DUMP,DISP=SHR
//OUT DD UNIT=3390,VOL=SER=TEMP03,DISP=OLD
//SYSIN DD *
RESTORE INDDNAME(IN) OUTDDNAME(OUT) PURGE ADMINISTRATOR COPYVOLID
/*
You might not want the COPYVOLID parameter in this job, depending on your circumstances. You cannot have two disk volumes with the same volser online to z/OS at the same time. If you do not specify COPYVOLID, the existing volser (TEMP03 in the example) is retained. If you specify COPYVOLID and a volume with this volser is already online, the restored volume is taken offline after the restore operation is complete. (In our example, the restored volser would be WAS001.)
Comments
Many variations are possible in this general process. For example, some of the z/OS preallocation of data sets can be skipped if your FTP supports site and locsite subcommands. While perhaps a bit longer than absolutely necessary, we think the process shown here should work in almost any situation.
12.12 IODF Changes with zPDT
When working with a larger z System, IODF and IOCDS creation are almost always done at the same time, working with HCD. This typically starts as follows:
HCD (usually started from an ISPF panel)
1. Define, modify, or view configuration data
3. Processors
4. Control Units
5. I/O Devices
The HCD functions verify that an allowable configuration is specified. That is, the processor (type and model), CHPIDs, and I/O devices must all be mutually allowable. This is a useful check for a larger z System, but it creates problems with zPDT.
A zPDT system does not use an IOCDS and does not understand many hardware CHPID details. Furthermore, typical zPDT configurations are not compatible with the normal HCD verification and processing we would use with a larger z System. At the time of writing, I/O device configuration for a z/OS system on zPDT consists of a software only IODF generation, followed by the creation of a matching devmap. Many z/OS users are not immediately familiar with a software only IODF and we provide an overview of the topic here; it is considerably simpler than a “normal” IODF.
Assume we want to add 15 OSA devices starting at address 410 and an OSAD device at address 41F. Using the IODF99 that is provided with the current z/OS AD-CD system16, we could proceed as follows:
HCD (started via ISPF menu item M.4)
1. Define, modify, or view configuration data
I/O DEFINITION FILE 'SYS1.IODF99'
1. Operating System Configuration
/ OS390 (select configuration named 'OS390')
7. Work with attached devices
(This should produce a list of current devices)
F11 - Add
At this point you should have a panel to enter a new work IODF name. We entered the name SYS1.IODF77.WORK and volser C2SYS1 in this panel. The data set name should follow this pattern (although the 77 portion of the name is arbitrary) and the volser should be the volume that is specified in the IPL parameter (C2SYS1 in the z/OS 2.2 AD system).
This is followed by a panel to add devices to the new work IODF. We entered the following information:
Specify or revise the following values.
 
Device number. . . . . . . 410 + (0000 - FFFF)
Number of devices . . . . 15
Device type. . . . . . . . OSA +
Serial number. . . . . . .
Description. . . . . . . .
Volume serial number . . . ______ (for DASD)
Connected to CUs . . ____ ____ ____ ____ ____ ____ ____ ____
Press Enter and again select (with a / character) the OS390 configuration. Select option 1 (to connect or change the new I/O devices). This is followed by a panel allowing you to alter default device parameters; you should take the default options unless you have a particular reason for changing them. Press Enter. This is followed by a panel to associate esoteric names with the new devices; you might use this for DASD or tape devices but probably not for any other types of devices. Press Enter and then select (with a / character) the OS390 configuration again.
Press F3 to return to the device list, and you should now see 410,15 in the list. Again select F11 (to add devices) and add a single OSAD device at address 41F, following the same steps used for the 15 OSA devices.17
When your new I/O devices have been added to the list, use F3 three times to return to the initial HCD menu. You then need to process your new IODF file.
2. Activate or process configuration data
I/O DEFINITION FILE 'SYS1.IODF77.WORK'
1. Build production I/O definition file
(This may produce some warning messages, usually about esoteric
tokens. Ignore these messages. F3 to exit the warning panel.)
 
Command ==>
 
Date & Time . . . . . . : 2008-07-14 13:14:51
User . . . . . . . . . .: IBMUSER
I/O Definition file. . .: SYS1.IODF77.WORK
Change reference number.: 00018
****** ************************TOP OF DATA **************************
.......
****** ************************BOTTOM OF DATA ***********************
 
Press F3 to exit this panel. The next panel allows you to name the new production IODF file:
Specify the following values, and chose how to continue.
Work IODF name . . . . . . : 'SYS1.IODF77.WORK'
Production IODF name . .: 'SYS1.IODF77'
Continue using as current IODF:
1 1. The work IODF in use at present
2. The new production IODF specified above (not valid for zPDT)
The next panel allows you to specify or revise these values; press Enter. This should produce the message PRODUCTION IODF SYS1.IODF77 CREATED. Use F3 several times to exit from HCD.
To use the new IODF you must alter one or more of the LOADxx members in SYS1.IPLPARM to refer to the new IODF. For example, edit member LOAD00 in SYS1.IPLPARM:18
IODF 99 SYS1 <--change this line
SYSCAT Z9SYS1113CCATALOG.Z19.MASTER
SYSPARM 00
IEASYM 00
NUCLST 00
PARMLIB USER.PARMLIB Z9SYS1
PARMLIB ADCD.Z112.PARMLIB Z9RES1
PARMLIB SYS1.PARMLIB Z9RES1
NUCLEUS 1
SYSPLEX ADCDPL
Change the 99 in the first line to 77 (or whatever number you used for your IODF). The format of this statement is odd, but it results in the name SYS1.IODF77. Be certain to place your changed characters in the same columns as the original characters. Do not change anything else in the LOADxx member unless you are certain about your actions.
The new IODF is now ready to use the next time you IPL z/OS with the parameter:
$ ipl 0a80 0a8200 (The 00 corresponds to the LOAD00 member)
Assuming you are satisfied with the results, you will probably want to change all the LOADxx members that you use. You must also change your devmap to use the new devices you added to your z/OS system.
12.13 Many COBOL Compilations
If you run a large number of COBOL compilations every day you can substantially improve compiler performance by moving some compiler modules into LPA. For COBOL 6.2 we moved IGYCPGEN, IGYCSCAN, IGYDRV, IGYQCBE, and IGYZQDRV to LPA and removed them from the IGY620.SIGYCOMP library.19 It is necessary to remove them from this library because the library is used as a STEPLIB during compilation and a STEPLIB is searched before LPA. The named modules use about 1500 tracks and are program objects, not load modules. They cannot be simply placed in one of the LPA libraries; instead they can be handled by “LPA” statements in a PROG member in PARMLIB.
12.14 Local printing
There is often less need for hard copy printed output in today’s working environments, but it is sometimes needed. There are a variety of ways to approach this. The following material describes only one of these ways.
Background
Basic z/OS printing is closely related to the hardware available on the original S/360 machines. The most common printer at that time was the IBM 1403. It printed lines with 120 characters (or 132 characters, with an optional feature) and was normally set to print 6 lines per inch on fan-fold paper that was 11 inches long. This meant a full page held 66 lines. In practice, many programs counted output lines and skipped to a new page after 60 or 61 lines.
Much of the utility software with the system, such as JCL processors, assemblers, compilers, system report programs, and so forth was designed to fit these pages. That is, they printed lines of up to 120 characters (sometimes up to 132 characters) with about 60 lines per page. This default convention is still with us today.
Later hardware replaced the line printers (such as the 1403) with laser printers. These were devices such as the IBM 3800, 3820, 3825, 3900, and so forth. These could accept a variety of paper sizes, but were most commonly used with “letter size” paper.20 With proper programming, these printers can produce sophisticated output using many fonts and graphics components. However, the system utilities (compilers, for example) continued to produce listings in “1403 format.” Software for these laser printers can accept this 1403-format data and list it. These listings typically are two-sided, landscape mode, and contain up to 66 lines of 132 characters on each page.
Real 1403 printers are historical items, but there are many uses for pseudo-1403 devices. z/OS and JES2 still support 1403 printers and zPDT can emulate 1403 printers. This is all that is needed for printed output from utilities, compilers, and many existing applications.
Using a PC printer
Our goal was to use a common PC laser printer and have utility output produced in the format just described: landscape mode, 66 lines per page, 132 characters per line. If the PC printer provides duplex printing (printing on both sides of the paper), this would be used. The flow is illustrated in Example 12-2.
Our tests used a Lexmark OptraS1250 and Optra L printers (both with duplex printing features). We have not tried the techniques described here with other printers, but we expect the same or similar techniques could be used. However, remember that z/OS printed output typically contains separator pages, JCL listings and messages, and so forth; the smallest job usually has multiple pages of printed output. This may not be suitable for use with a small inkjet printer. We assume the use of a fairly heavy-duty laser printer for z/OS printing.
Figure 12-2 General flow for printing
12.14.1 Setup
We need to provide the setup for Linux, the zPDT devmap, a shell script, and JES2.
Linux setup
We first configured our (very old) Lexmark Optra S1250 for Linux. This printer has a parallel input; our computer had no parallel ports. We purchased a USB-to-parallel cable and this provided the needed connectivity. We used YAST (running under openSUSE) to configure the printer.21 A print queue named optras1250 was created automatically by YAST. We verified that the printer worked by using commands such as:
$ lpr /home/ibmsys1/prof12 (to print one of our devmaps)
Devmap setup
We added the appropriate 1403 definition to the zPDT devmap:
[manager]
name awsprt 4321 --windows
device 00E 1403 2821 /tmp/1403a
The --windows option is needed to place CR/LF characters in the output; without this option, NL characters are used and a PC printer may not be happy with NL characters. The output file name (/tmp/1403a in the example) is arbitrary. In our case, we did not expect much printed output and /tmp seemed a reasonable place to put it. The output file may also be assigned or changed with the awsmount command.
Shell script
We created a Linux shell script named prt00E (the name is arbitrary) and placed it in our home directory (/home/ibmsys1, in our case). The shell script contained the following lines:
CTL=”3310533501636016061665666671507056166
601636014212433461546115761163655664143
5561606060132”
CTL2=”1433105”
(/bin/echo -ne $CTL; cat /tmp/1403a; /bin/echo -ne $CTL2) | lpr -P optras1250
The CTL and CTL2 definition constants are printer control characters, written in octal.22 The octal format was the most convenient for use in a shell script. If you have good script writing skills you can do this several ways. The particular control characters shown here are for the Lexmark printers we mentioned. Your printer may require different controls. If you are printing to the default Linux printer you do not need the -P parameter (and queue name) of the lpr command.
The logic in the shell script is simple. It sends data (via a pipe and lpr) to the queue we defined earlier. It sends the CTL string (using echo), then sends the print data from the output file we named in the devmap or awsmount command (using cat), and then sends the CTL2 string (using echo) to flush the printer buffer and reset the printer.
The CTL control string (for our Lexmark printers) resets the printer, switches to a fixed font, sets a small type size pitch, changes to 8 lines/inch, uses a Courier font, uses landscape, duplex printing, uses 5.4/48 line height, and a small line offset to better center the data. The only unique requirement is that the format must use exactly 66 lines per page in order to synchronize with the pages produced by the 1403 emulator.
In the following strings 33 is the ESC character that is used to begin printer command strings, and this is shown as a bold-face E in the character equivalents of the string. The octal constants are the equivalent of the characters shown and the CTL string could be written with characters (except for the ESC byte).
The CTL commands are as follows:
OCTAL constant....... Characters Comment
33105 EE Reset printer
335016360160 E(s0p Use a fixed font,
6166566667150 16.67h with 16.67 inch character pitch
7056166 8.v with 8 lines/inch characteristics
6016360142124 0s0bT using upright, medium Courier
334615461157 E&l1o Use landscape format
61163 ls with duplex printing, long edge
655664143 5.4c 5.4/48 inch line height
5561606060132 -1000Z line offset
The CTL2 commands are as follows:
1433105 Force last page, reset printer
The CTL string was produced after some experimentation. It works for our printers, but it may contain unnecessary elements. Notice that we hard-coded the file name (/tmp/1403a) in the shell script; more skilled users may want to make this a command-line variable.
JES2 setup
Normal z/OS printing flows through JES2 and printers must be known to JES2. Recent AD-CD systems do not have a printer defined for JES2. We need to define a 1403 at address 00E for JES2. (We use device number 00E because it is the traditional address for a 1403 printer and because it is already defined in the AD-CD IODF.) Edit the AD-CD PARMLIB member JES2PARM to contain the following line:
PRT(1) WS=(W,R,Q,PMD,LIM/F,T,C,P),UNIT=00E,CLASS=C
If you scroll through the existing JES2PARM (in the AD-CD system) you will find commented lines similar to this. You can insert a new line, as shown, or convert the commented lines into active lines.23 The print class (CLASS=C) is arbitrary; we selected class C because nothing defaults to this class.
We added the printer definition to JES2 and did another IPL of z/OS. (There are various ways to do the same task without the re-IPL.) We verified that the printer was online (d u,,,00E,1) and then issued a JES2 command to start it ($SPRT1). Use a $SPRT1 command as the response to requests to mount forms and so forth.
12.14.2 Operational technique
We then ran jobs that sent output to SYSOUT=C. For example,
//OGDEN1 JOB 1,OGDEN,MSGCLASS=C
// EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSUT1 DD DSN=SYS1.PARMLIB(IEASYS00),DISP=SHR
//SYSUT2 DD SYSOUT=*
After submitting this job, you should see z/OS console messages about jobs sent to PRT1. If JES2 requests a setup function for the printer, reply $SPRT1. If the emulated printer is started (for JES2), the printed output is immediately sent to the “printer.” As described here, this is file /tmp/1403a in Linux. Additional output (from multiple jobs) is simply added to the file. The emulated printer cannot distinguish where one job ends and the next begins; the JES2 separator pages are needed for this.
At some point you can stop the JES2 printer ($PPRT1) and print the accumulated output under Linux. (You do not need to stop the JES2 printer if you are certain no additional output will be sent to it.)
Disconnect the output file (/tmp/1403a) from the emulated printer:
$ awsmount 00E -u
You then run the shell script:
$ cd /home/ibmsys1 (Directory containing the shell script)
$ ./prt00E (Execute the shell script)
The printer begins printing output. Notice that the output includes all the job separator pages produced by JES2. When it finishes, you can use awsmount to provide an empty output file for the emulated printer:
$ rm /tmp/1403a (Delete the old output file)
$ touch /tmp/1403a (Start a new output file; same name)
$ awsmount 00E -m /tmp/1403a (Connect new output file)
We deleted the output file (assuming we do not want to print the same jobs again). We then re-created the same file (because the name is hard-coded in the shell script) and “mounted” it on the emulated printer, ready for more output.
If you stopped the JES2 printer, you need to start it again ($SPRT1).
12.15 SYS1.LOGREC full
Maintaining SYS1.LOGREC is a normal z/OS system programmer’s task. There is nothing unique to zPDT or the AD-CD distribution. Production installations, using larger z System machines, often keep ordered histories of LOGREC data and study any new material in LOGREC. It includes data about hardware and software failures, IPL statistics, volume use statistics, and so forth.
Most zPDT users simply ignore SYS1.LOGREC until they receive messages that it is full. These messages do no harm, but it is a good idea to clear LOGREC when such messages are received. There is at least one job in the AD-CD libraries to do this, but the job name (and library name) may change from time to time. The following is a job to clear SYS1.LOGREC. The particular format shown here is quite old and should be used exactly as shown.
//BILLCL JOB 1,OGDEN,MSGCLASS=X
// EXEC PGM=IFCEREP1,PARM='CARD'
//SERLOG DD DISP=SHR,DSN=SYS1.LOGREC
//DIRECTWK DD UNIT=SYSDA,SPACE=(CYL,5,,CONTIG)
//EREPPT DD SYSOUT=*,DCB=BLKSIZE=133
//ACCDEV DD DUMMY
//TOURIST DD SYSOUT=*,DCB=BLKSIZE=133
//SYSIN DD *
SYSUM
ACC=Y
ZERO=Y
/*
You may find slightly different jobs that perform the same function and any of these should be acceptable. Never attempt to “clear” SYS1.LOGREC by simply deleting and reallocating it, or by removing records with a text editor.
You can edit IEASYSxx members (in PARMLIB) to say LOGREC=IGNORE to avoid the LOGREC full problems.
12.16 Lost MVS console
MVS does not like to lose its operator console (and this is not unique to zPDT operation!) If you accidently close the TN3270e session that contains the MVS operator console, you might try the following recovery.
First, simply try to re-establish the session. This might be easier if the MVS console has an LUname in the devmap, as in this example:
$ x3270 -port 3270 mstcon@localhost &
Depending on exactly what was happening when the console was lost, the TN3270e connection to the aws3174 device manager may still be active and you cannot make a “new” connection to it. You can force the console session to completely disconnect by this command in a Linux window:
$ awsmount 700 -d (assuming your MVS console is address 700)
You might then be able to connect the TN3270e session to address 700. You need to have the TN3270e session connected before proceeding with additional recovery.
When MVS lost the console it probably started issuing messages in the Linux window used to start zPDT. These are “HMC hardware console” messages. You can attempt to reactivate the MVS console on 700 (assuming you have a TN3270e connection to 700) as follows:
$ oprmsg v 'cn(*),activate' (activate the "hardware console" for commands)
$ oprmsg v 700,offline
$ oprmsg v 700,offline,force (if the simple vary offline fails)
$ oprmsg v 700,online
$ oprmsg v 700,console
$ oprmsg v 'cn(*),deactivate' (optional)
This might not always work. Also, it might produce a console in 3270-2 (24 lines) mode, but this is better than no console. The single quotation marks in the commands are needed to prevent the Linux shell from directly using the parenthesis characters in the commands.
12.17 Unable to start ISPF
When logging onto TSO, the following message is sometimes seen when attempting to start ISPF:
%%% UNABLE TO ALLOCATE OR CREATE ISPF PROFILE DATASET
ISPF003 FOLLOWING FILE WAS NOT PREALLOCATED
ISPPROF
The most common reason for this problem is that the required ISPF profile data set was uncataloged for some reason. This can happen when attempting to use the same profile data set from two different z/OS instances, such as in a Parallel Sysplex environment, that was not configured for such use. Crashing z/OS at just the wrong moment might also do this.
You need to recatalog the profile data set. Assuming you are logging on as IBMUSER, the data set you want (in all recent AD-CD releases) is IBMUSER.ISPF.ISPPROF. You can log on with another userid (ADCDMST is convenient for this purpose) and recatalog the data set. The easiest way to recatalog the data set is to list the volume (ZCSYS1, for example) using ISPF 3.4 and to use a C line command to catalog the data set. (The C is entered at the beginning of the line for that data set in the ISPF 3.4 display.)
Another solution, after ISPF fails to start, is to preallocate the data set (using basic TSO commands) and then start ISPF again. To do this, use the following TSO command:
READY alloc da('ibmuser.ispf.ispprof') f(ispprof) shr vol(zcsys1) unit(3390)
READY ispf (start ISPF again)
You need to use the volser that matches your current system, of course.
12.18 Customized Offering Driver (COD)
The Customized Offering Driver (COD) is a small preconfigured z/OS system that is delivered on a set of DVDs. The COD is intended as a base for installing a z/OS ServerPac or CBPDO. The COD, at the time of writing, included the following characteristics:
•Three 3390-9 volumes are used, each distributed as a set of files on its own DVD. A separate DVD is included containing documentation.
•A very wide range of addresses (device numbers) for 3390s and local 3270 consoles are included, with a smaller range of addresses for SNA 3270-X, 3590 (tape), OSA, CTC, and SCTC devices.
•TCP/IP is usable with some configuration work.
•Instructions are included for working as a z/VM guest.
Why would a zPDT user want to use the COD? The reasons might include:
•A desire to work with a more “basic” z/OS system than the AD-CD z/OS system. The AD-CD z/OS system contains a considerable amount of customization making it easier for many people to use it. Systems programmer training might include starting with a much more basic z/OS level and the COD could be a more appropriate starting point.
•A simple practice platform before using the COD on a large Z system.
The COD is not part of zPDT deliverables and cannot be obtained through zPDT or AD-CD channels.
The following example is based on the SUSE Leap42.2 Linux system. Your Linux might have slight differences; for example the DVD drive might be named something other than /dev/sr0. The installation example here assumes you are working with Linux userid ibmsys1. This is arbitrary, as is the directory name /mnt/ibmdvd; we use these to provide specific installation examples. We use su to work as root; you could use sudo instead if your Linux system is configured for it.
Before starting, create a Linux directory named /mnt/ibmdvd that can be accessed by user ibmsys1.
# su (switch to root)
# mkdir /mnt/ibmdvd (create a mount point for COD DVDs)
# exit (leave root)
Create three 3390 volumes. At the time of writing the volsers were named D9ECAT, D9ESY1, and D9ESY2, and these are used in our example. We created our emulated volumes in directory /z, but this is arbitrary, as are the Linux names we used to contain the volumes.
$ alcckd /z/D9ECAT -d3390-9
$ alcckd /z/D9ESY1 -d3390-9
$ alcckd /z/D9ESY2 -d3390-9
We created a zPDT devmap named devcod, as follows:
[system]
memory 8G
processors 1 #You can specify 3 processors if they are available
3270port 3270
command 2 x3270 localhost:3270
 
[manager]
name aws3274 0002
device 00A1 3270 3274 #MVS console
device 00C0 3270 3274 #TSO
 
[manager]
name awsckd 0004
device 0170 3390 3990 /z/D9ESY1
device 0171 3390 3990 /z/D9ESY2
device 0172 3390 3990 /z/D9ECAT
Each of three 3390 volumes are installed in the same way; the following text illustrates installing the D9ECAT volume.
(insert the D9ECAT DVD and assume Linux will automount it.)
# su (switch to root)
# umount /dev/sr0 (unmount the dvd; name may vary)
# mount -t iso9660 -o ro,map=o /dev/sr0 /mnt/ibmdvd
# exit (leave root)
$ ls /mnt/ibmdvd (should see CAT)
$ ls /mnt/ibmdvd/CAT (should see multiple files)
$ awsstart devcod (start zPDT)
$ ipl_dvd /mnt/ibmdvd/CAT/DFSMSDSS.INS (upper case is important)
$ Enter ‘y’ to continue.....
$ y (reply y. Wait a few seconds))
$ Memory loaded. 0x20A0 Bytes at address 0x0
$ Memory loaded. 0x3FFC0 Bytes at address 0x20000
(After a few seconds press Enter on the 3270 screen.)
(You should see a message to clear the screen. Use ONLY the 3270 clear
operation at this point.)
$ ADRY005E DEFINE INPUT DEVICE, REPLY ‘DDDD,CCUU’ OR ‘CONSOLE’
$ ENTER INPUT/COMMAND:
$ CONSOLE (your response)
$ ADRY006E DEFINE OUTPUT DEVICE, REPLY ‘DDDD,CCUU’ or ‘CONSOLE’
$ ENTER INPUT/COMMAND:
$ CONSOLE (your response)
$ ENTER INPUT/COMMAND:
$ RESTORE FROMDEV(DVD) TOADDR(0172) PATH(‘/CAT’) FULL NOVERIFY
$ ADRY003D 0172 REPLY Y TO ALTER VOLUME, ELSE N
$ ENTER INPUT/COMMAND:
$ y (your response)
(After a pause a number of progress messages should appear.)
$ FILE CAT001 has been processed with 0125806839 Bytes
etc
(Clear the screen if requested.)
$ ADRY0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
$ awsstop
We stopped zPDT between restoring volumes and unmounted the current dvd:
$ su
# umount /dev/sr0
# eject
We then processed the other DVDs with the only change being the ipl_dvd and RESTORE commands:
ipl_dvd /mnt/ibmdvd/SY1/DFSMSDSS.INS
RESTORE FROMDEV(DVD) TOADDR(0170) PATH(‘/SY1’) FULL NOVERIFY
ipl_dvd /mnt/ibmdvd/SY2/DFSMSDSS.INS
RESTORE FROMDEV(DVD) TOADDR(0171) PATH(‘/SY2’) FULL NOVERIFY
The correct PATH operand is critical. The restore command can be entered in lower case if you prefer. Upper or lower case is critical for Linux commands but is usually ignored for z/OS commands, including the stand-alone utilities.
After restoring the COD, we added a second command statement to the devmap to automatically start a second 3270 session:
command 2 x3270 -geometry +1100+10 -model 3279-2 localhost:3270
The VTAM modtabs provided with the COD support only 24x80 sessions for VTAM and TSO. If we use default x3270 screens (43x80) it is easy to mistake a partly-filled screen (which can be scrolled forward) for the end of a list. The MVS console automatically adapts to the 43x80 screen size.
After starting zPDT, we proceeded as follows:
$ ipl 0170
After a few seconds the MVS console interaction (with the 3270 at address 00A1) went as follows:
IEA101A SPECIFY SYSTEM PARAMETERS FOR Z/OS 02.01.00 HBB7790
r 00,clpa,sysp=00
....messages...
01 ICH502A SPECIFY NAME FOR PRIMARY RACF DATASET SEQUENCE 001 OR ‘NONE’
r 01,SYS1.RACF
02 ICH502A SPECIFY NAME FOR BACKUP RACF DATA SET ....
r 02,NONE
....lots of messages....
03 $HASP426 SPECIFY OPTIONS - JES2 z/OS 2.1
r 03,COLD,NOREQ
(you might have a message to allow bypassing the multi-member
integrity lock. If so, reply Y.)
04 $HASP441 REPLY ‘Y’ TO CONTINUE INITIALIZATION ......
r 04,Y
...lots of messages....
(Wait until you see the OMVS INITIALIZATION COMPLETE message)
d u,,,0C0 (verify our TSO terminal is online)
s vtam (start vtam & wait a few seconds)
s tso (start TCAS)
v net,act,id=d0c00df (appropriate for address 0c0)
The “d0C00df” in this command is the name of a VTAMLST member related to local 3270 address 0C0; this information is provided in the COD documentation. On your TSO terminal (address 0c0) you should see THIS TERMINAL IS LOGGED ON TO UNFORMATTED SYSTEM SERVICES.
Move to the TSO terminal session and enter LOGON DRVUSER. The password is also DRVUSER. This should produce a CustomPac Master Application Menu. The “P” option should start a normal ISPF session.
To shut down z/OS cleanly, logoff from TSO and use the following commands at the MVS console:
p tso (stop TSO)
z net,quick (stop VTAM)
p lla
p vlf
(Wait a few seconds for messages)
$pjes2,term
(Wait a few seconds for messages)
z eod
Subsequent IPLs do not need to CLPA or COLD start JES2.
12.18.1 TCP/IP connection
We wanted to establish a TCP/IP connection to the COD z/OS system. The COD contains many OSA definitions and we arbitrarily decided to use OSA addresses 0300-0302. The profile parameters for TCPIP are in TCPIP.SEZAINST, the VTAMLST parameters are in SYS1.VTAMLST, and the TCPIP procedure is in SYS1.PROCLIB. We proceeded as follows to create a TCP/IP tunnel link to our base Linux (which is 10.1.1.1 for the tunnel):
•Add OSA definitions to our devmap (and restart zPDT):
[manager]
name awsosa 0006 --path=A0 --pathtype=OSD --tunnel_intf=y
device 0300 osa osa
device 0301 osa osa
device 0302 osa osa
•IPL the COD and start TSO (in a local 3270 session), as described above. We examined the default TCPIP profile in TCPIP.SEZAINST(PROFILE) and found it too complex. We created member PROFILE2 as follows:
ARPAGE 20
AUTOLOG 5
FTPD JOBNAME FTBD1
ENDAUTOLOG
PORT
7 UDP MISCSERV
(copy all the PORT statements from PROFILE)
3389 TCP MSYSLDAP
SACONFIG
;
DEVICE PORTA MPCIPA
LINK ETH1 IPAQENET PORTA
HOME 10.1.1.2 ETH1
BEGINRoutes
ROUTE 10.1.1.0 255.255.255.0 = ETH1 MTU 1500
ROUTE DEFUALT 10.1.1.1 ETH1 MTU DEFAULTSIZE
ENDRoutes
TCPCONFIG RESTRICTLOWPORTS
UDPCONFIG RESTRICTLOWPORTS
IPCONFIG NODATAGRAMFWD
START PORTA
•We altered SYS1.PROCLIB(TCPIP) so that the PROFILE DD statement points to member PROFILE2 instead of member PROFILE.
•We added member SYS1.VTAMLST(OSATRL1) as follows:
OSATRL1 VBUILD TYPE=TRL
OSATRLE1 TRLE LNCTL=MPC,READ=(0300),WRITE=(0301), X
DATAPATH=(0302),PORTNAME=(PORTA), X
MPCLEVEL=QDIO
(Be certain the continuation marks are in column 72)
•We edited member SYS1.VTAMLST(ATCCON00) member as follows:
TSOAPPL,TCPAPPL,OSATRL1
•We then reIPLed z/OS. After the startup process described above we entered z/OS commands as follows”
v 300-302,online (Bring the OSA ports online)
s tcpip
s tn3270
At this point we could ping 10.1.1.2 from Linux. Starting a new x3270 session connected to 10.1.1.2 we received an UNFORMATTED SYSTEMS SERVICES prompt and could logon to TSO. (We needed to first logoff from the local 3270 session because we had only a single TSO userid.) When shutting down z/OS you should also stop TN3270 and TCPIP.
LAN configuration can be frustrating because there are so many details that must be exactly correct. The steps described here create a link to the base Linux TCP/IP; this is probably the most basic TCP/IP configuration possible with the COD and zPDT. It is a good starting point before attempting to configure an external TCP/IP link.
12.19 WLM and AD-CD
The recent z/OS AD-CD systems are provided with a WLM service definition already installed. While there is nothing wrong with the supplied WLM definition, it might not be overly useful with typical zPDT usage. As a practice exercise we created another WLM service definition. The following brief description of the process might be useful to a new zPDT owner who has not previously worked with WLM.
WLM service definitions are created and used in the WLM coupling dataset(s). It is possible, although not required, to then extract and write the WLM service definition to a PDS. A number of PDS members are created when doing this, and the data is not in a “human” format. The same PDS can later be installed in the coupling dataset (overwriting what is there) and then activated. At the time of writing the WLM coupling dataset is SYS1.ADCDPL.WLM.CDS01 (and CDS02); the PDS copy is ADCD.Z22C.WLM.
WLM definitions can be quite complex, but can also be fairly simple if only simple controls are needed and this is likely to be the case for a zPDT system. A complete WLM definition is a service definition. A service definition contains one or more service policies. A service policy involves workloads, service classes, and classification rules. A simple WLM definition might contain only these elements. Only one service definition can be installed for WLM at any one time24 and only one policy within that service definition can be active at any one time. However, you can work on an additional service definition (using ISPF) in the coupling dataset while a different service definition is being used.
We designed a service definition named BASEAD, having a single policy named BASEAD1, with the characteristics shown in the table.
Table 12-1 Trivial WLM definition
Workload
Name
Service Class
Name
Imp
Service class goal
Classification
HIGH
FAST
1
90% velocity
LDAP LSFM STC TCP
TSO
TSO
2
90% in .25 seconds
TSO
CICS
CICS
3
80% in 1 second
EWLM CICS IMS
SERVERS
MEDIUM
3
50% velocity
CB ASCH DB2 DDF IWEB MQ SOM
BATCH
SLOW
 
Discretionary
JES
The workload names and service class names are arbitrary. With a more complex definition there are common naming conventions, but we used our own names for this trivial example. The “Imp” column is the “importance” specification for the service class. If multiple service classes are not meeting their goals, then WLM adjustments are made in the order of importance (with 1 being the most important). The “90% velocity” indicates work in this service class is expected to run at 90% of the processor speed. The “90% in .25 seconds” indicates that 90% of the transactions in this class should complete in .25 seconds or less. Discretionary means there is no specific goal and usually indicates the lowest performance class.
Our service definition is a little odd in that it places TSO importance above that of servers such as DB2, CICS, IMS, MQ, and so forth. This unusual definition suited us because we were using TSO to monitor other work and wanted our monitoring activity to have priority over most other work. The CICS and SERVERS definitions are separate only because WLM rules prevent assigning a velocity goal to CICS, IMS, and EWLM; if this were not the case we would have placed all these in the SERVERS workload.
There are many IBM manuals, IBM Redbooks publications, and third-party documents discussing WLM parameters in great detail; we do not attempt to repeat any of this material. The purpose of the discussion here is to describe the mechanics of creating and using your own WLM service definition, using our trivial example. As with most z/OS administrative activities, there are many ways to go about it and we describe a very basic approach that can be used as a starting point for more complex work.
We proceeded as follows (using a recent z/OS AD-CD system):
•Decide on the basic design of your service definition, including initial workload names and service class names. You can expand these later.
•Create a small PDS to save your workload once you have defined it. Each service definition requires a separate PDS for saving it. We suggest 5 tracks, 5 directory blocks, LRECL 80, RECFM FB.
•Go to ISPF option M.14 to start a WLM interactive dialog. Select option 3 to create a new definition.
•On the next panel enter a service definition name of your choice and a brief description. Then select option 1 to specify a policy name of your choice. (PF3 twice to return to the main WLM menu.)
•Select option 2 to create a workload name. (PF3 twice to return to the main menu.) Select option 2 again to create additional workload names. (Within the workload panel, use option 1 to create a new name.)
•After defining your initial workload names, use option 4 to define service classes. For each assign a service class name and the name of the corresponding workload that you previously created. Then position the cursor to the Action field and enter I (for Insert new period). This opens a small panel where you can select the a goal for this service class, such as a velocity percentage, an importance parameter, and a duration (to be used if there are multiple periods for this service class).25 If you entered a duration parameter, then you should Insert another period specification. The last (or only) period for a service class does not have a duration. You should assign a service class for each of your workload names.
•After defining your workloads and service classes, use option 6 for Classification Rules. This displays a panel with about 17 predefined classifications. Do not attempt to create new classifications unless you understand how the whole z/OS system relates to WLM. For each line in the panel, select option 3 (Modify). In the following panel tab to the Service DEFAULTS field and enter the name of one of your service classes, followed by PF3. If you do not associate one of your service classes with each of the classifications, it will default to a SYSTEM level service class, which is an automatically provided high-level service class.
•When you have assigned all the classifications, PF3 to the main menu and select the Utility option at the top of the screen. You can validate your new definitions using one of the options. (The validate function appears to check syntax, but makes no attempt to do more than that.)
•Use PF3 to leave the WLM dialog. You should receive a panel offering to save your definition to a dataset. Use this option to save to the PDS you defined for it. At this point you could also use option 3 to discard all your work! This can be useful if you are experimenting with the WLM dialog panels.
•There are many other choices in the WLM dialog panels, but the options we described are sufficient to create a basic WLM service definition.
If you followed these steps you now have your service definition saved in a PDS. To use it, start the WLM dialog again (M.14) and select option 1 to read a saved definition. The resulting panel might already have the name you used to save your definition. If you enter a question mark in this field, you should see the names of other saved WLM service definitions; this is likely to include ADCD.Z22C.WLM or a similar name.
•Select one of the saved names; you will probably select your own dataset or the ADCD dataset if you want to revert to the default AD-CD WLM service definition.
•You should then see the main WLM dialog panel. Select the Utilities option in the top line of the screen, and select option 1 to Install the service definition. You will then see a subpanel asking permission to overwrite whatever service definition is currently installed. Reply YES to this question.
•If you use the D WLM operator command you will see that the previous service policy is still being used. In the WLM dialog select Utilities again, and select option 3 (Activate Service Policy). Select a service policy from the list presented. This will activate the service policy and a D WLM command should confirm this.
Is there any point to building your own WLM service definition when working with an AD-CD system on zPDT? There is no simple answer. WLM is most effective in a system running sustained mixed workloads. For practical purposes, most WLM actions result in changing z/OS dispatching priorities and this is most meaningful if the system has a sustained workload approaching 100% CPU utilization. Adjustments are made at something like 10 second intervals. A zPDT system with a few TSO users editing, compiling, and unit testing modules presents an erratic workload that does not respond to WLM very well. However, a heavy test workload that involves batch, DB2, and perhaps extensive (simulated) terminal interaction might respond to WLM very well.
12.20 RMF Monitor III
Recent releases of the AD-CD system might not start IBM RMF™ Monitor III correctly, with a failure finding a module. This can be corrected by adding GDDM.SADMMOD to the link list. (Consider adding it to all the PRODxx members in PARMLIB.)
12.21 OTELNET
z/OS AD-CD releases typically allow you to connect to TCP/IP port 1023 with a simple telnet command connection. From a Linux command prompt this might be as follows, if you have a tunnel connection to your z/OS system using the address 10.1.1.2 for the z/OS system as described in this book.:
$ telnet 10.1.1.2 1023
The 1023 port may not be configured for some releases. If your connection fails, edit TCPIP.ETC.SERVICES and insert the following information in the appropriate place:
telnet 23/tcp
otelnet 1023/tcp
Current z/OS AD-CD releases might not automatically start inetd, which is needed for telnet. To start it, enter S INETD on the z/OS operator console. (This function is not required for using SSH.)
12.22 Compressing PARMLIB
We typically make many PARMLIB changes (usually to the current AD-CD PARMLIB) while adjusting the AD-CD system to our individual needs.26 We then need to compress PARMLIB to recover space and prevent unexpected expansion into multiple extents. With some AD-CD releases, a simple compress (using the Z option in the ISPF 3.4 panel) fails because the PARMLIB is being used by another job. Pressing PF1 twice (when this error message is received) displays the name of the conflicting job (or jobs). The conflict may be from zFS. The following MVS console command stops zFS and permits compression of the PARMLIB:
f omvs,stoppfs=zfs
This should be done when there are no UNIX System Services users, of course.
12.23 Burning 3390 volumes on CD
If we wanted to preserve a 3390 volume on CD (or DVD), we could use the following command to make a compressed copy:
$ gzip -c /z/C2RES1 > /z/C2RES1.gz
We could then burn the compressed file on CD or DVD by using a normal Linux CD/DVD burning application.
12.24 Delete logstreams
The default location for log streams (for the AD-CD system) is the xxSYS1 volume (or the equivalent, for other releases). These streams can sometimes grow to fill the volume. A typical job for deleting a log stream is as follows:
//BILL1 JOB 1,OGDEN,MSGCLASS=X
// EXEC PGM=IXCMIAPU
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
DATA TYPE(LOGR) REPORT(YES)
DELETE LOGSTREAM NAME(WAS.ERROR.LOG)
/*
This should be done only if the log stream file is not being managed; that is, it is not represented in current couple data sets.
12.25 SMF
Some of the recent AD-CD z/OS releases produce excessive SMF output. This is especially true if type 99 records that are included. In these cases the default parameters were as follows:
SYS(NOTYPE(14:19,62:69),EXITS(IEFU83,IEFU84,IEFACTRT,IEFUSI,IEFUJI,
IEFU29),NOINTERVAL,NODETAIL)
If you have absolutely no interest in SMF data, we suggest you alter the SMFPRMxx members in PARMLIB and change the first line from ACTIVE to NOACTIVE. If you might have some interest in SMF job data (type 30) and perhaps RMF data (types 70 - 79) we suggest the following line to produce minimal recording:
SYS(TYPE(30,70:79),EXITS(IEFU83,IEFU84,IEFACTRT,IEFUSI,IEFUJI,
IEFU29),NOINTERVAL,NODETAIL)
Recent AD-CD system process full SMF datasets automatically, discarding the output. If you want to process SMF data yourself, remove the IEFU29 exit that appears twice in the default SMFPRMxx parameters. (We suggest that you eliminate recording of SMF record types that you do not want before doing this.)
The uses of the various exits specified in the SMF parameters, if present, is beyond the scope of this book. If you have access to Cheryl Watson’s Tuning Letters, the 2009 letters contain a useful and practical introduction to SMF usage.27
If you use logstreams for SMF and want to determine the quantity of each SMF type being collected, you might use the following job:
//OGDEN101 JOB 1,OGDEN,MSGCLASS=X
// EXEC PGM=IFASMFDL,REGION=0M
//OUT DD DUMMY
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
LSNAME(IFASMF.GENERAL,OPTIONS(DUMP))
OUTDD(OUT,TYPE(0:255))
/*
This job assumes your LOGSTREAM for SMF is named IFASMF.GENERAL, which is the name used in the parallel sysplex system for zPDT described in other documents. Your name might differ.
If you want to list a few details about the status of the LOGSTREAM, you might use the following job:
//OGDEN102 JOB 1,OGDEN,MSGCLASS=X
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
DATA TYPE(LOGR) REPORT(NO)
LIST LOGSTREAM NAME(IFASMF.GENERAL) DETAIL(YES)
/*
12.26 Disabled waits
You might sometimes see a message in your zPDT Linux window such as this example:
Warning! Disabled Wait CPU 0
$ d psw <--you can issue this command
PSW for CPU 0 000A0000 00000xxx (24/32 bit mode)
PSW FOR cpu 0 00020000 00000000 00000000 00000XXX (64-bit mode)
When you receive such a message, you can issue a command to display the PSW. The last three characters of the PSW should contain a wait state code; an extended code may be also present in other characters of the PSW. The following list provides abbreviated information about standard wait state codes. See the System Codes manual for more complete information about each code. Note that some wait states are restartable; again, see the System Codes manual for more information.
Partial list (see the notes at the end of the list)
002 - During IPL, an I/O operation was not initiated (1)
003 - IPL cannot continue; subchannel is not operational for IPL or IODF device (1)
004 - During initialization, I/O not initiated (1)
005 - I/O interruption during IPL and unit check (2)
006 - I/O error during IPL processing; SYSRES or IODF volume (2)
007 - During initialization console not available (3)
009 - System build error. (z/OS problem; should be rare)
00A - Cannot find SYS1.LINKLIB or SYS1.CSSLIB in catalog (4)
00B - Master scheduler abended (4)
00D - Master scheduler abended (4)
00E - Problem on SYSRES volume (SYS1.NUCLEUS) (2)
00F - IPL volume does not contain IPL text (5)
013 - Error during NIP (6)
014 - Recursive program checks (6)
017 - Unit check during IPL (2,5)
019 - IPL program in error (6). Also seen if IPLing an older operating system (that does not support CZAM) on a z14 operating in the normal CZAM mode.
01B - SLIP requests wait (7)
01C - Recursive abend in FRR (8)
020 - Reconfiguration initialization failed (9)
022 - Page fault - devices quiesced or not ready (10)
023 - Trace initialization failed (11)
025 - Duplicate entry point in nucleus (6)
02E - ASM detected too many I/O errors (10)
030 - ABEND during NIP (6)
031 - No UCB for SYSRES (1, 2)
032 - NIP module missing (6)
033 - I/O error in BLDL during NIP (6)
035 - Could not find entry point in nucleus (6)
037 - DSCB for SVCLIB, PARMLIB, LINKLIB could not be read (12)
038 - Not enough main storage (11)
039 - DASD mount conflict (1,13)
03A - Error building LPA (6)
03B - Required module is not in LPA (6, 14)
03C - ASM found not enough paging storage (15)
03D - Error building page tables (11)
03E - Not enough page slots to back master scheduler initialization (15)
03F - NIP function invoked incorrectly (6)
040 - ABEND during NIP (6)
044 - Machine check during NIP (6) (Try IPLing again, at least once!)
045 - NIP could not initialize RTM (6)
046 - Program check during NIP (6)
04A - TOD clock in error (16)
050 - Alternate CPU recovery (ACR) entered recursively (16, 6)
051 - ACR had error (software) (6)
052 - ACR error (hardware) (16)
053 - PC or PC/AUTH failed (17)
054 - Error in member loaded into nucleus (6,14)
055 - IPL cannot find necessary member in SYS1.NUCLEUS (14)
056 - NIP error (6)
059 - Unidentified return code for BLDL during NIP (6)
05A - ACR tried to remove last CP (16)
05C - NIP cannot find catalog pointer in nucleus (18,12)
05D - During NIP, could not find DSCB for catalog (12)
05E - Error reading master catalog (2)
060 - ASM detected errors in page tables (6)
061 - TOD clock errors during STCK instruction (16)
062 - Channel path error (16)
063 - NIP storage problem. SQA too small? (4)
064 - NIP error and RTM not initialized (6)
065 - NIP issued type 3 or 4 SVC before they were available (6)
06F - I/O problem - unusual (1,2,10,13)
070 - NIP: insufficient contiguous main storage (6,11)
071 - System or operator initialized a restart
072 - No more workspace for IPL (6,11)
073 - IPL program waiting for I/O or external interrupt (16)
074 - IPL program contains a logic error (6)
075 - IPL program could not load a module (4,14,6)
076 - IPL found non-fullword relocatable address constant (6)
077 - SVC entry point cannot be resolved (6)
078 - Master catalog could not be opened (2,4,6)
07B - Required processor facility not available (19)
07C - Initialization error, configuration problem. (18,1,see Codes manual)
07D - IEASYSxx PARMLIB member is bad; in error (4)
07E - Unable to obtain LSQA storage for SVC (11,6)
081 - SYS1.NUCLEUS occupies more than one extent
082 - System joining sysplex needs maintenance
083 - Incorrect address in PSA (16)
084 - RTM error (17,6)
085 - ASM warm start problem (1,10,20)
087 - System removed from sysplex (normal situation)
088 - IPL: error in LOADxx or NUCLSTxx (18,4,6)
089 - NIP found an error in a UCB (6)
08A - WTO error going to wait state
08C - WLM has recurring error (6)
08E - SYSEVENT error (6)
08F - Failure rebuilding work queues (6)
09x - SPINLOOP problem (See Codes manual for more information)
0A1 - Excessive SPINLOOP unresolved (21)
0A2 - XCF encountered cross system problem
0A3 - Unable to join global GRS
0A4 - ETR problem
0A5 - HCD problem (remember: zPDT does not support dynamic reconfiguration)
0A7 - Insufficient ESQA or ECSA storage (11)
0B0 - Could not recognize IODF specified in LOADxx (18,1)
0B1 - LOADxx member problem (18,1)
0B2 - No devices in IODF (18, or you created a bad IODF)
0B3 - Incorrect information in IPL parameter
0B4 - UIM specified unidentified device number (22)
0E0 - SIGNAL failed during NIP (16)
0E1 - SIGP STOP failed because processor was not operational (16)
0E3 - Insufficient virtual storage to initialize CSA (4)
0E8 - During NIP, the machine check handler failed (6)
101 - Program in supervisor state requested too much SQA (6)
102 - Program in supervisor state requested more pages of SQA than available (6)
104 - While provessing ABEND SVC, program check occurred recursively (6)
110 - System detected hot I/O from device other than DASD (16; note MVS console messages)
111 - System detected hot I/O on DASD device (16, note MVS console messages)
112 - System detected hot I/O on reserved DASD (16, note MVS console messages)
113 - Failure during channel path recovery (16)
114 - Previous error affected SMP operation. See manual.
115 - DASD containing paging dataset is unavailable. (10)
116 - During restart, detected missing interrupt for paging device (16)
11A - Error during SVC 26 (6)
201 - Failure while creating COMMTASK (6)
202 - During system initialization, creation of console communications failed (6)
204 - Error during allocation (6)
205 - Attempted to load a module that was not in LINKST (6)
206 - Sysplex initialization operator message prompt
5C7 - Error during processor or system termination (6)
A00 - DAT error for system address space (16,6)
A01 - Error on only online processor (16)
A18 - Unsolicited Device end on paging volume; AVR failed. (complex)
A19 - Can no longer perform I/O (16)
A1E - Time-of-day clock failed (16)
A1F - Processor controller not available; TOD sync cannot occur (16)
A20 - System found page in FLPA that is not fixed (6)
A21 - Segment table entry for MLPA, PLPA, FLPA, or xFLPA is incorrect (6)
A22 - Error (probably hot I/O) invoked disabled console communication facility (see manual)
A23 - Program check during machine check handling on only online processor (16)
A24 - Loop while running machine check handler on only online processor (6,16)
A26 - Machine check on only online processor; interruption code incorrect (16)
A27 - Problems during machine check interruption handling
A28 - DAT-off machine check handler cannot start DAT-on machine check handler (6,16)
A29 - Problems stopping processor after program or machine check (6)
A2A - System detected LPA page that is not on paging data set (6)
A2B - Error in extended storage (16)
A70 - Console unavailable during NIP (3)
A71 - Reconfiguration problem (9; see codes manual)
A7A - Service processor interface failed (16,9)
B01-B1D Wait states used by the 3203/3211 utility
B20-B24 Wait states used by the stand-alone IOCP program
CCC - Wait state generated by QUISECE command
D0D - SMF had resource shortage (too much SMF output requested? Memory too small?)
E02 - Should never happen (16)
EC7 - Severe error in Unix System Services (6)
FFx - Non-IBM program created a wait state
The suggested actions provided by the following notes assume you are using z/OS (probably the AD-CD system) in a normal manner. That is, we have these assumptions:
•You have not modified the system.
•You are not working with authorized programs or code.
•You have not installed middleware that operates as authorized code.
•You are not actively disrupting the hosting Linux environment for zPDT.
Review these notes:
1. Check that your devmap contains the necessary volumes and that they are at addresses supported by the IODF of your z/OS system. For example, with an AD-CD z/OS system have your 3390 volumes addresses in the range A80 -AEF. Restart zPDT and try again. If necessary, verify your emulated 3390 volumes (using an alcckd xxxx -rs command.)
2. Verify that your IPL parameters point to the correct volumes for SYSRES and the IODF volume. With the typical AD system these are addresses A80 and A82. Possibly these volumes are corrupted. Verify your emulated 3390 volumes (using an alcckd xxxx -rs command), restart zPDT and try to IPL again.
3. z/OS wants a NIP console. This is address 700 in existing AD-CD z/OS systems. Be certain a 3270 session is connected to this address (or whatever NIP console address is specified for your z/OS system). Also be certain the Linux window you used to start zPDT is open, as this could provide an alternative, limited NIP console function in some cases. If a 3270 session at address 700 is available, try to IPL again.
4. Have you altered a working system? Changed key PROCLIB members? Changed the catalog line in the LOADxx member in SYS1IPLPARM? This is not recoverable. You must IPL another z/OS system (or restore volumes for this z/OS.)
5. Ensure you IPL the correct volume. Verify your devmap and try again.
6. Internal z/OS problem. Probably not your fault unless the volume is corrupted. Try doing an IPL of z/OS again. You might need to IPL another z/OS system or restore volumes for this z/OS system.
7. Someone set a SLIP trap. This is probably a user-caused wait and whoever set the SLIP trap should know how to proceed. System can be restarted.
8. Typically a system error, but might be an error in a software product. Try doing an IPL of z/OS again, possibly without starting recently installed middleware.
9. You attempted a reconfiguration option that is not available for zPDT.
10. Possible devmap or PC disk error or emulated 3390 corruption error. Stop zPDT and verify 3390 emulated volume formats with alcckd xxxx -rs commands.
11. Be sure you defined enough memory for your z System. Try increasing the memory size in your devmap and restart zPDT. (Consult zPDT documentation to understand the maximum z System memory definition recommended for your configuration.) Most zPDT users run z/OS with at least 4000 MB z System memory defined.
12. Did you IPL the correct volume? Has someone deleted data sets on this volume? Has someone deleted system data sets?
13. Check your devmap carefully. Are two 3390 definitions pointing to the same file? Verify that the 3390 devmap entries point to the correct Linux files. Fix your devmap and restart zPDT.
14. Be sure no one deleted members in any system libraries. This is probably not recoverable. You need to IPL another z/OS system and possibly repair this z/OS system.
15. You may have started a large program (such as WAS) and you do not have enough space in your paging data sets. You might add paging data sets.
16. Restart zPDT. If the error persists, contact your zPDT provider.
17. Probably due to bugs in a software product. Were you starting a new product when this happened? This is not recoverable. Re-IPL and try again.
18. Verify whether anyone modified SYS1.IPLPARM and whether you are using a new LOADxx member in this library. If so, the new member has an incorrect catalog line. IPL with a “standard” load parameter (to use a “standard” LOADxx member).
19. See the zPDT documentation for information about what facilities and functions are available through zPDT. If you are unable to resolve the problem, contact your zPDT provider.
20. Try a cold start (CLPA).
21. Try restarting zPDT with fewer processors defined in your devmap. Contact your zPDT provider if the problem persists with fewer devmap processors defined than you have real processors in your PC.
22. Check your devmap. Devmap and IODF must have compatible device addresses. Are you attempting to use an unsupported device?
 
1 “Required” is perhaps too strong; a console message is produced if the system is below the 2GB (or 8GB) size and the operator can elect to continue operation.
2 These are default values, but we specified them for completeness.
3 “PUT tape” is redundant, because it means program update tape tape, but the terminology is often used. “PUT” and “PUT tape” are used interchangeably.
4 Another option is to combine the files into a single DSNTYPE=LARGE data set.
5 Single quotation marks can be part of the file names on the download site. These single quotation marks must be “escaped” when used as Linux file names and it is best to avoid this complication.
6 Or the serial number may be provided by a UIM server.
7 The equivalent commands for OBROWSE are SOURCE ASCII and DISPLAY RESET.
8 The parallel sysplex system is described in IBM Redbooks publication SG24-8386.
9 It appears that user ADCDMST has update access to the relevant IBM RACF® profile. You can log on with this userid and skip the RACF change.
10 You might need to scroll down in the ISPF option 0 panel to see the appropriate options.
11 Generally, a STORAGE volume is used when creating a permanent dataset and no volume is specified, although the exact details involved can be a little more complex.
12 You can look for data sets with names such as SYS1.ADCD.DMPnnnnn and delete them (assuming you are not working on a problem that involves these dumps). The exact data set name pattern for SVC dumps is set in the appropriate COMMNDxx member in PARMLIB.
13 The dump output can be directed to tape instead of a disk volume. Our discussion here concentrates on disk output.
14 Do this when z/OS is not running, of course.
15 These DCB attributes are used by XMIT.
16 This example is based on the z/OS 2.2 AD-CD system, but later releases should be similar.
17 OSA/SF (which uses an OSAD entry in the IODF) is no longer available with current z/OS releases. A partial replacement, QUERYINFO, is not supported under zPDT/
18 This example is from z/OS 1.9 and 1.12. Other details in your LOADxx member will differ from this example. The key point here is in the first line of the member.
19 Actually, we simply renamed the modules in the SIGYCOMP library.
20 The “letter size” (or A4 elsewhere) paper can be cut sheets or fanfold paper, depending on exactly which printer is being used.
21 Red Hat Linux has a different configuration process, but the end results are about the same.
22 CTL is shown as three lines here, but it is actually created as one long line containing 38 octal constants.
23 If you convert the commented lines into active lines, be especially careful with the /*....*/ comment indicators; be certain you remove matching pairs.
24 Only one service definition can be installed in the WLM coupling dataset at any one time. The keyword is “installed;” this means a policy within it can be activated. A completely different service definition can be concurrently built (using ISPF) in the same coupling dataset, but it is not “installed” at this point.
25 As already noted, there is a huge body of documentation about detailed WLM definitions. You can search this material for information about goals, durations, and other groupings.
26 This is not a good practice, but it is very common. A better method is to first copy the target PARMLIB member to USER.PARMLIB, and then make the changes there. USER.PARMLIB is concatenated before the normal ADCD PARMLIB.
27 For more information, see http://www.watsonwalker.com.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.12.108.236