Chapter 2 Quiz: Virtual Storage Architecture

Section 1: Multiple Choice

1. What is the primary mechanism z/OS uses to provide address space isolation?

a) Software-based memory protection bits on each page b) Dynamic Address Translation (DAT) with separate page tables per address space c) Virtual machine hypervisor running each address space in a separate VM d) Encryption of each address space's storage contents

Answer: b) Dynamic Address Translation (DAT) with separate page tables per address space

Explanation: DAT is a hardware mechanism implemented in the CPU. Each address space has its own set of page tables, pointed to by control register 1 (CR1). When the dispatcher switches tasks between address spaces, it loads the new address space's page table origin into CR1. This means the same virtual address in two different address spaces maps to completely different real storage locations — the hardware enforces isolation without any software intervention. This is why z/OS address space isolation is considered extremely strong — it cannot be bypassed by application code.

2. The "bar" in z/OS virtual storage refers to:

a) The 16 MB boundary that separates 24-bit and 31-bit addressable storage b) The 2 GB boundary that is the maximum addressable range for AMODE 31 programs c) The 4 GB boundary that separates 32-bit and 64-bit storage d) The MEMLIMIT value configured for the address space

Answer: b) The 2 GB boundary that is the maximum addressable range for AMODE 31 programs

Explanation: The bar is at 2 GB (2^31 bytes) — the maximum address that a 31-bit address can represent. The 16 MB boundary is called the "line" (2^24 bytes, from the original MVS/370 24-bit addressing limit). The bar is a hardware constraint: an AMODE 31 program cannot generate an address above 2 GB. Storage above the bar is only accessible to AMODE 64 programs or through special 64-bit pointer mechanisms. This is why the bar is sometimes described as a "hard ceiling" — no tuning parameter, JCL change, or configuration option can make an AMODE 31 program address storage above 2 GB.

3. A COBOL batch job specifies REGION=0M. The job abends with S80A RC=04. Which action would NOT help resolve this abend?

a) Increasing REGION to a larger value b) Recompiling the program with LP(64) to move large tables above the bar c) Reducing working storage by using file-based processing instead of in-memory tables d) Increasing MEMLIMIT and using LE HEAP64 for above-bar allocation

Answer: a) Increasing REGION to a larger value

Explanation: REGION=0M already means "maximum available user region." Specifying any other value (e.g., REGION=2000M) would actually restrict the region to less than the maximum. The 80A RC=04 indicates that the private area's virtual storage is exhausted — the program needs more below-bar storage than is available after system areas (CSA, SQA, LSQA, nucleus) consume their share. The only solutions are to reduce below-bar consumption (option c), move storage above the bar (options b and d), or restructure the program. This is one of the most common misunderstandings in production COBOL operations.

4. What is the fundamental difference between an S80A abend and an S878 abend?

a) S80A is caused by COBOL logic errors; S878 is caused by JCL errors b) S80A indicates virtual storage exhaustion in one address space; S878 indicates real or auxiliary storage exhaustion system-wide c) S80A occurs only in batch; S878 occurs only in CICS d) S80A is a hard failure; S878 is a warning that can be overridden

Answer: b) S80A indicates virtual storage exhaustion in one address space; S878 indicates real or auxiliary storage exhaustion system-wide

Explanation: S80A is a local problem — one address space has run out of virtual storage in its user region. Other jobs on the same LPAR are unaffected. S878 (with reason codes 04 or 10) is a system-wide problem — z/OS cannot find real storage frames or auxiliary storage slots to back virtual storage requests. When you see S878 RC=04 or RC=10, all address spaces on the LPAR may be affected, and the response is to reduce system-wide real storage demand. The one exception is S878 RC=08, which means this specific job exceeded its MEMLIMIT for above-bar storage — that's a local problem with a local fix (increase MEMLIMIT).

5. In a CICS region, working storage for a COBOL program is allocated:

a) Once when the program is loaded, shared by all tasks b) Once per task from the CICS Dynamic Storage Area (ECDSA for AMODE 31) c) On the LE heap, shared across all tasks in the region d) In the Extended CSA, shared across all address spaces

Answer: b) Once per task from the CICS Dynamic Storage Area (ECDSA for AMODE 31)

Explanation: CICS's quasi-reentrant model requires that each task gets its own copy of working storage. The program code is shared (one copy, read-only), but working storage is per-task. For AMODE 31 programs, these working storage copies are allocated from the Extended CICS Dynamic Storage Area (ECDSA). This is why working storage size is critical in CICS: a program with 500 KB of working storage running 200 concurrent tasks consumes 100 MB of ECDSA. A batch programmer who creates a 50 MB working storage table and deploys it to CICS with 100 concurrent tasks would consume 5 GB — far exceeding any realistic ECDSA allocation.

6. The LE runtime option STORAGE(00,FE,00) does what?

a) Allocates 00 bytes of heap, FE bytes of stack, and 00 bytes of working storage b) Initializes heap storage with X'00', fills freed storage with X'FE', initializes stack with X'00' c) Sets the maximum heap to X'00FE00' bytes d) Configures storage below the line at address X'00FE00'

Answer: b) Initializes heap storage with X'00', fills freed storage with X'FE', initializes stack with X'00'

Explanation: STORAGE(xx,yy,zz) controls storage initialization patterns. The first parameter (00) sets the initial fill byte for heap storage — all newly allocated heap bytes are filled with X'00' (binary zeros). The second parameter (FE) sets the fill byte for freed storage — when LE frees a heap segment, it fills it with X'FE'. This makes use-after-free bugs obvious in dumps (you see X'FEFEFEFE' instead of valid data). The third parameter (00) sets the initial fill for stack storage. The overhead is 2-5% of runtime — a worthwhile trade-off for production reliability.

7. What LE runtime option produces a storage utilization report at program termination?

a) STORAGE(ON) b) RPTSTG(ON) c) STGMON(ON) d) HEAPRPT(ON)

Answer: b) RPTSTG(ON)

Explanation: RPTSTG(ON) (Report Storage) tells LE to produce a detailed storage report at program termination. The report shows total heap usage, stack usage, number of heap segments, high-water mark, total LE-managed storage, region size, and available storage at termination. This is the single most important diagnostic tool for storage capacity planning. CNB runs with RPTSTG(ON) quarterly for all critical batch jobs to track storage growth trends and catch potential 80A conditions before they become production failures.

8. An AMODE 31 COBOL program compiled with LP(64) — where does its program code execute?

a) Above the bar in 64-bit addressing mode b) Below the bar in 31-bit addressing mode c) It alternates between 31-bit and 64-bit mode depending on the instruction d) In AMODE 64 always, with backward compatibility for 31-bit data

Answer: b) Below the bar in 31-bit addressing mode

Explanation: LP(64) does not make the COBOL program itself a 64-bit program. The program code still executes in AMODE 31, below the 2 GB bar. What LP(64) enables is the ability to allocate data items above the bar — specifically, large working storage items and LE heap segments can be placed in 64-bit addressable storage. The CPU transparently switches addressing modes when accessing above-bar data through 64-bit pointers. This design maintains backward compatibility: existing COBOL program logic works unchanged, but large data structures escape the 2 GB constraint.

Section 2: True/False

9. True or False: Setting REGION=2048M gives a batch job access to the full 2 GB below the bar.

Answer: False

Explanation: REGION controls the user region size, not the total address space. The total address space is always 2 GB below the bar, but system areas (nucleus, CSA, SQA, LSQA, SWA) consume ~400 MB before the user region begins. REGION=2048M would actually be treated the same as REGION=0M — it requests the maximum available. And the maximum available user region is approximately 1.6 GB, not 2 GB. Furthermore, many installations configure the IEFUSI exit to impose additional limits.

10. True or False: A CSA storage leak affects only the address space that caused the leak.

Answer: False

Explanation: CSA (Common Service Area) is shared across ALL address spaces on the LPAR. A CSA leak reduces the CSA available to every address space, not just the leaker. As CSA fills, system services that need CSA allocation fail, potentially causing widespread abends and even system failures. This is why CSA leaks are considered system-wide emergencies and why CSA utilization is monitored continuously. A private-area storage leak, by contrast, affects only the leaking address space.

11. True or False: Demand paging means that all of a COBOL program's working storage is loaded into real storage when the program starts.

Answer: False

Explanation: Demand paging means pages are brought into real storage on demand — only when first referenced. When a COBOL program starts, its working storage is allocated in virtual storage, but the corresponding real storage pages are not assigned until the program actually accesses each page. A 500 MB working storage section does not consume 500 MB of real storage at initialization — real storage consumption grows gradually as the program references each 4 KB page for the first time. This is why virtual storage capacity planning and real storage capacity planning are separate disciplines.

12. True or False: The TLB (Translation Lookaside Buffer) caches recent DAT translations to avoid repeated page table lookups.

Answer: True

Explanation: The TLB is a hardware cache within the CPU that stores recent virtual-to-real address translations. When the same virtual page is accessed repeatedly (which is the common case — programs exhibit strong locality of reference), the TLB provides the real address in 2-5 nanoseconds without walking the page tables. The TLB is invalidated when the dispatcher switches to a different address space (different page tables), which is one reason why excessive dispatching can cause performance degradation — TLB misses increase, and each miss requires a full page table walk.

13. True or False: An S0C4 abend always indicates a storage protection violation caused by a COBOL subscript out of range.

Answer: False

Explanation: While subscript-out-of-range is the most common cause of S0C4 in COBOL programs, it is not the only cause. S0C4 (protection exception) occurs whenever a program attempts to access storage it is not authorized to access. Other causes include: uninitialized pointers (SET ADDRESS OF with an invalid pointer), calling a subprogram that wasn't properly loaded, storage overlay that corrupts adjacent control blocks, and attempting to write to read-only storage (e.g., modifying a literal in the program's code area). The diagnosis requires examining the PSW instruction address and mapping it to the COBOL source.

14. True or False: In a Parallel Sysplex, virtual storage is shared between LPARs through the coupling facility.

Answer: False

Explanation: Virtual storage is completely private to each address space on each LPAR. The coupling facility provides shared structures (lock structures, group buffer pools, signaling areas), but these are not part of any address space's virtual storage. Each LPAR has its own real storage and its own page tables. An address space on CNBPROD1 cannot access virtual storage belonging to an address space on CNBPROD2. Cross-LPAR data sharing is accomplished through the coupling facility's shared structures and through shared DASD — never through shared virtual storage.

Section 3: Short Answer

15. Explain in three sentences why the COBOL compiler option SSRANGE is valuable during testing but typically removed for production. What does it check, and what is the performance cost?

Answer: SSRANGE (subscript range checking) causes the compiled COBOL program to verify that every subscript, index, and reference modification value falls within the declared boundaries before each access. If a violation is detected, the program produces a clean error message identifying the exact line and subscript value, rather than allowing the access to proceed and potentially causing a cryptic S0C4 abend at a seemingly unrelated location. The performance cost is 5-15% additional CPU time due to the bounds-checking instructions inserted before every table access and reference modification, which is acceptable in testing but significant in production batch jobs that process millions of records.

16. A COBOL program's RPTSTG report shows "Maximum storage used: 1,580,000,000 bytes" and "Region size: 1,702,887,424 bytes." Calculate the headroom percentage and explain why this program is at risk.

Answer: Headroom = (1,702,887,424 - 1,580,000,000) / 1,702,887,424 = 122,887,424 / 1,702,887,424 = 7.2%. This program is at serious risk because only 7.2% of the user region remains available. Any growth in working storage (new fields, expanded tables), heap usage (additional subprogram calls), buffer allocation (new files), or system area expansion (CSA growth after z/OS maintenance) could push the program past the region limit and cause an S80A abend. Industry best practice is to maintain at least 15-20% headroom. This program should be immediately reviewed for LP(64) migration to move large data structures above the bar.

17. Explain the relationship between MEMLIMIT and the LE HEAP64 runtime option. When would you increase one versus the other?

Answer: MEMLIMIT controls the total amount of above-the-bar virtual storage the address space can allocate — it is the z/OS-level ceiling. HEAP64 (the last two parameters of the HEAP runtime option) controls the initial size and increment of LE's 64-bit heap segments — it is the LE-level allocation strategy. Increase MEMLIMIT when the total above-bar storage requirement exceeds the current limit (the equivalent of S878 RC=08). Increase HEAP64 initial/increment sizes when LE is performing too many individual IARV64 requests (too many small above-bar heap segments, causing overhead from repeated system calls). The two work together: MEMLIMIT sets the cap, and HEAP64 determines how efficiently LE uses the space within that cap.

18. Why can't a COBOL program directly call GETMAIN/FREEMAIN? What layer manages storage on the program's behalf, and why is this important for storage accounting?

Answer: LE (Language Environment) manages all storage allocation for COBOL programs. COBOL programs do not issue GETMAIN/FREEMAIN directly — LE intercepts all storage needs (working storage allocation, heap expansion, stack growth) and issues GETMAIN/FREEMAIN on the program's behalf. This is important because LE maintains its own storage accounting: it tracks heap segments, stack segments, and high-water marks, enabling the RPTSTG diagnostic report. If programs bypassed LE and issued GETMAIN directly, LE's accounting would be inaccurate, CEEDUMP storage reports would be incomplete, and LE's ability to manage storage across subprogram calls would be broken. The one exception is legacy assembler-era programs that predate LE — these may use GETMAIN directly, which creates storage management challenges that LE cannot track.

Section 4: Applied Scenario

19. Ahmad Rashidi at Pinnacle Health Insurance receives an alert: the claims processing batch job (PNCLM500) has been running for 3 hours instead of the usual 45 minutes. The job has not abended — it's still running. Investigation reveals:

• CPU utilization for the job: 2% (normally 40%)
• Page fault rate for the job's address space: 2,300 per second
• Real storage allocated to the address space: 45 MB (normally 800 MB)
• The LPAR's total real storage utilization: 98%

Using the virtual storage concepts from this chapter: a) Explain what is happening. Why is the page fault rate so high? b) Why is CPU utilization so low even though the program is "running"? c) Is this an S80A situation? An S878 situation? Or something else? d) What immediate action should Ahmad take? What long-term fix?

Answer: a) The LPAR is under extreme real storage pressure (98% utilization). RSM has stolen most of the real page frames from this job's address space (only 45 MB allocated vs. normally 800 MB). The program's virtual pages are being paged out to auxiliary storage. Every time the program accesses a page that's been paged out, a page fault occurs — 2,300 per second indicates the program is thrashing. b) CPU utilization is low because the program spends most of its time waiting for page-in I/O to complete — each page fault requires ~1ms to read from auxiliary storage. The CPU is idle while waiting for I/O, so the program's CPU utilization drops to 2% even though it's technically active. c) This is neither S80A nor S878 — the program has not abended. It's a real storage contention problem — the system has enough virtual storage and enough auxiliary storage, but real storage is overcommitted. This is the "thrashing" condition described in Section 2.1. d) Immediate: identify what is consuming real storage on the LPAR (possibly a runaway job or a DB2 buffer pool expansion). Cancel or reduce lower-priority workloads to free real storage. Long-term: review real storage capacity — the LPAR may need more real storage (hardware upgrade) or workload rebalancing across Sysplex LPARs.

20. Sandra Chen at Federal Benefits Administration is planning a storage modernization project. She has 45 critical COBOL batch programs. Here is the storage profile:

a) Which programs should be migrated to LP(64) first? Why? b) For the 3 "emergency" programs exceeding 1.5 GB — they are currently running. How is this possible if the user region is ~1.6 GB? c) Propose a quarterly migration plan for all 45 programs over 18 months. d) What LE runtime option would you standardize across all 45 programs to facilitate ongoing storage monitoring?

Answer: a) The 3 "emergency" programs (>1.5 GB) should be migrated first — they are running with essentially zero headroom and could fail with any data growth, system area increase, or LE version change. Next priority: the 5 "critical" programs (1-1.5 GB), which have dangerously low headroom. b) The 3 programs are likely running because they don't reference all of their working storage simultaneously — they have large OCCURS tables that are partially filled, or sections of working storage that are only used in certain code paths. Also, their actual high-water mark may be lower than the declared working storage size (OCCURS DEPENDING ON tables). They're running on luck — any change that increases actual storage usage will cause failure. c) Q1: Migrate 3 emergency + 5 critical programs (8 total). Q2: Migrate 10 high-risk programs (500 MB - 1 GB). Q3: Migrate 12 moderate programs (200-500 MB) — not strictly necessary but provides future-proofing. Q4-Q6: Monitor, optimize, and document. Leave the 15 low-risk programs as-is unless growth trends warrant conversion. d) RPTSTG(ON) — run quarterly for all 45 programs to establish storage baselines and track growth trends. The storage reports feed directly into capacity planning and migration prioritization.