I was sent this useful document from Dan Kalmar.
The IBM documentation on the initial logon to the ZD&T image in the “standard stock image” may not always work. The information below gives an alternative way of getting in.
Environment
- Emulator ZD&T Personal Edition 14.2.8 (z1091 1.12.59.17), Ubuntu host
- Image IBM z/OS 3.2 Dev & Test Stock Image for ZD&T PE 14.2.20 (built 2026-09-08)
- IPL ipl DE27 parm DE28A0M (SYSRES Z32VS1 at DE27, IODF/LOAD on OPEVS1 at DE28)
The problem
The stock image ships with a randomized IBMUSER password. IBM’s documented procedure for Personal sEdition is to edit the password-injection file on the ZDTDPY volume, include ZDTDPY in the device map and IPL with load parm NV:
pdsUtil ZDTDPY ZDT.PASSFILE/PASS0 --extract (edit line 1 of PASS0.txt, 8 chars)
pdsUtil ZDTDPY ZDT.PASSFILE/PASS0 --overlay
ipl DE27 parm DE28NV
On this system that did not work. ZDTDPY was online with the edited PASS0, the IPL used DE28NV, yet TSO IBMUSER still failed with:
IKJ56474I USERID OR PASSWORD IS INCORRECT OR NOT AUTHORIZED
No console message referred to ZDTDPY, so the injection step did not appear to run. RACF commands from the console are refused as well:
IRRV003I (<) YOU ARE NOT ALLOWED TO ISSUE THE LISTUSER COMMAND
AS AN OPERATOR COMMAND
so the password cannot be reset from the console, and the usual ADCD defaults (IBMUSER / ADCDMST) are rejected too. (Whether the 14.2.20 image needs the matching 14.2.20 emulator for the injection to run is an open question with IBM support.)
Caution: do not keep retrying logons — RACF will revoke the userid after a few failures.
The way in
The image ships two pieces that together allow a job to run with authority, without anyone logging on:
- SYS1.PROCLIB(SUBMIT) on OPEVS1 — a started task that copies a member to the internal reader. It is
started with S SUBMIT,DS=dsname,M=member.
- IBMUSER.JCL(SSHKYCP) on STGVS1 — a sample job (shipped to install an SSH key for IBMUSER). Its JOB card has no USER=, so the submitted job runs under the SUBMIT started-task user, which has enough authority to update IBMUSER.
The members can be read and rewritten from Linux with pdsUtil, the same way PASS0 is. So we replace the SSHKYCP member with a job that issues an ALTUSER, then let the shipped SUBMIT task run it at IPL time.
Key constraint: pdsUtil –overlay is an update-in-place — the replacement file must have exactly the same number of records as the original member. SSHKYCP is 26 records, so the replacement job is padded with comment lines to 26.
Procedure
All Linux commands run as the ZD&T user (ibmsys1). The volumes directory below is this system’s (/media/mybook6/z32/volumes) — substitute your own.
Step 1. Shut down z/OS and stop the emulator
awsstop
Step 2. Back up the volume that holds IBMUSER.JCL (STGVS1 here)
cd /media/mybook6/z32/volumes
cp STGVS1 ../STGVS1.bak
Step 3. Extract the SSHKYCP member and keep an untouched copy
mkdir -p ~/z32check && cd ~/z32check
pdsUtil /media/mybook6/z32/volumes/STGVS1 IBMUSER.JCL/SSHKYCP --extract
cp SSHKYCP.txt SSHKYCP.orig.txt
–extract writes SSHKYCP.txt (ASCII) into the current directory. Note the record count reported (26).
Step 4. Replace SSHKYCP.txt with the reset job, padded to 26 records
The job below runs ALTUSER under TMP/E (IKJEFT01). Keep it at exactly 26 lines. Put your own 8-character password (uppercase + digits) in place of NEWPASS1 on the ALTUSER line:
//PWRESET JOB CLASS=A,MSGCLASS=X
//* Reset IBMUSER password. Runs under the SUBMIT STC user (no USER=).
//* Start with: S SUBMIT,DS=IBMUSER.JCL,M=SSHKYCP
//*
//* --- padding so the member stays 26 records (pdsUtil --overlay rule) ---
//*
//*
//*
//*
//*
//*
//*
//*
//*
//*
//*
//*
//*
//*
//S1 EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
ALTUSER IBMUSER PASSWORD(NEWPASS1) NOEXPIRED RESUME
LISTUSER IBMUSER
/*
Confirm the count before writing it back:
wc -l ~/z32check/SSHKYCP.txt # must print 26
Step 5. Write the member back to the volume
cd ~/z32check
pdsUtil /media/mybook6/z32/volumes/STGVS1 IBMUSER.JCL/SSHKYCP --overlay
Success looks like: AWSPDS055I 26 records overlayed PDS member ‘SSHKYCP’. A record-count mismatch instead gives AWSPDS054E … RC=-10 — re-check the line count.
Step 6. IPL and run the job from the master console
cd /media/mybook6/z32 && sh runzpdt_z32
Once BASE Z/OS SUBSYSTEMS HAVE BEEN STARTED appears, on the master console:
S SUBMIT,DS=IBMUSER.JCL,M=SSHKYCP
Watch for $HASP395 PWRESET ENDED (and IEF404I PWRESET – ENDED). If no ICH/IRR error appears, the ALTUSER was accepted.
Step 7. Log on and verify
Dial a TSO terminal (the stock image uses devices 0062–0065 for VTAM; 0060/0061 are MCS consoles) and log on:
TSO IBMUSER (then the new password at IKJ56476I ENTER PASSWORD)
The PWRESET job output is held in class X — its LISTUSER confirms IBMUSER’s status.
Step 8. Restore the original member
Once in TSO, put the shipped SSHKYCP back so the image matches IBM’s.
Edit IBMUSER.JCL(SSHKYCP) in ISPF and paste the original contents (SSHKYCP.orig.txt), or re-run –overlay with the saved original while z/OS is down. Then change the password the normal way and delete the volume backup.
Why this works
The submitted job inherits the SUBMIT started task’s RACF identity (no USER= on the JOB card), and on this image that identity has enough authority to issue ALTUSER against IBMUSER. Nothing bypasses RACF: the job runs as an already-authorized started-task user, which is why it can set a password that console RACF commands are blocked from setting. Everything up to Step 6 is done offline with pdsUtil, the same utility IBM’s own PASS0 procedure uses.
Level independence and suspected root cause
This workaround is independent of the emulator and z/OS release. pdsUtil, SYS1.PROCLIB(SUBMIT), a no-USER= job inheriting the started task’s RACF identity, and ALTUSER are all stable across ZD&T and z/OS levels, so the method works whether or not the PASS0 injection mechanism is present on the image.
The likely reason IBM’s documented PASS0 procedure produced nothing here: the code that reads ZDT.PASSFILE(PASS0) at IPL may require a later emulator than 14.2.8. The image is built for ZD&T 14.2.20; this host runs the 14.2.8 emulator. That would explain why ZDTDPY was online with the edited PASS0 and the IPL used DE28NV as documented, yet no console message referred to the injection and the password was unchanged. This is a hypothesis, not confirmed by IBM — the open question is whether the 14.2.20 stock image requires the matching 14.2.20 emulator for PASS0 injection (and for other functions). If so, applying the 14.2.20 fix pack is the proper fix, and the procedure above is the bridge until then.
Note
This is shared as a working note — verify each step against your own entitlement and IBM documentation. Device numbers, volume serials and paths are specific to this ZD&T system.