Press ESC to close

To make the content on z/OS ADCD 1.13 (specifically the July 2012/2013 releases) work, you must properly extract the volume files, set permissions, and configure the device map for your emulation environment (like zPDT or ZD&T). 1. Extract and Prepare Volume Files

The ADCD system is typically distributed as a set of compressed volume images.

Define the Target Path: Export the path where you will unload the system. export ADCD_PATH=/your/local/directory Use code with caution. Copied to clipboard

Unzip Files: Extract the .gz or compressed files from the DVD or download package into your target directory.

Set Permissions: You must ensure the volume files (f*.bin) are executable and owned by the correct user (usually ibmsys1). chmod 755 f*.bin chown ibmsys1:ibmsys f*.bin Use code with caution. Copied to clipboard 2. Configure the Device Map (devmap)

The devmap file tells the emulator how to map Linux files to z/OS 3390 DASD devices.

Identify Volume Types: ADCD 1.13 includes various volumes such as Base system volumes, Stand-alone RES, and Distribution Libs.

Edit devmap: Add the newly unzipped volume files to your devmap.txt. Each entry should map a specific device address to the physical file path.

Verify LOADPARM: Ensure your IPL (Initial Program Load) parameters match the ADCD configuration. For example, ADCD systems often use specific LOADPARM options like 0A82N or similar to start specific subsystem configurations. 3. Initialize and Online Devices Once the emulator is running and z/OS is IPLed:

Check Online Status: Use the command D U,DASD,ONLINE to see if your new volumes are visible.

Vary Online: If a volume is offline, use the vary command: V

,ONLINE.

Initialize (if needed): Use the ICKDSF utility to initialize new volumes if they are blank Linux files rather than pre-formatted ADCD images. 4. Customization and Maintenance

Avoid System Datasets: When making changes, copy members from SYS1.* to USER.* datasets to keep your customizations separate from the base ADCD distribution.

System Request (SR): If you notice the system is "hanging" during startup, check the System Request (SR) option in SDSF to see if there are any outstanding console replies (like VTAM or DB2 prompts) that require your attention.

To effectively monitor and respond to system messages that might block your z/OS startup: IBM OS/390: Como añadir Opciones al SDSF The Mainframe Corner YouTube• May 12, 2023 Moving to the z/OS standard image and onward - ColinPaice

2.2 Storage Key Mismatch

z/OS uses storage protection keys to prevent one program from writing into another's area. If a program running in Key 8 (application) attempts to free a storage block allocated in Key 0 (system), the supervisor state logic triggers a 113-13 abend. In ADCD, some pre-configured started tasks may run with elevated privileges, accidentally crossing key boundaries.

Section 2: Root Cause Analysis – Why Does 113-13 Happen on ADCD?

Before diving into diagnostics, it is crucial to understand why this specific error plagues ADCD environments more than production systems.

2.1 Virtual Storage Constraint (a Common ADCD Issue)

ADCD distributions often come with a limited amount of virtual storage (below the 16MB line, also known as the "key 0" area) to mimic small-system configurations. When a program (e.g., a legacy assembler application or a vendor utility) issues a GETMAIN to obtain a work area, but then later issues FREEMAIN with a pointer that has shifted or become corrupted, the SVC 113 routine detects the mismatch. Reason code 13 is thrown precisely when the FREEMAIN target address does not match the start address originally returned by GETMAIN.

2. Key components

  • z/OS base (system services, USS)
  • TSO/E and ISPF
  • JES2 or JES3 (job entry subsystem)
  • RACF (security manager) with sample data
  • CICS TS (transaction server) — sample regions
  • Db2/IMS subsystems (if included in this ADCD build)
  • WebSphere Application Server / Liberty profiles (if present)
  • Sample datasets, COBOL and PL/I programs, JCL examples
  • z/VM or other hypervisor-specific control scripts for deployment

The Legacy: The ADCD Era

Historically, if you wanted to work with z/OS, you needed access to a mainframe. Since physical mainframes are expensive, IBM released ADCD packages—pre-configured z/OS systems distributed on tape (and later, as massive zipped files).

The workflow was notoriously difficult:

  1. Acquisition: You had to download gigabytes of data.
  2. Emulation: You needed hardware emulators like Flex-ES or zPDT to run the mainframe OS on a laptop or server.
  3. Configuration: Getting the system to "IPL" (boot) required deep knowledge of storage volumes and script tweaking.

While effective for learning, this model was static. It didn't reflect the dynamic, CI/CD-driven world of modern software development.