jesopen() should dynalloc the checkpoint and spool, as jesiropn() already does

[mgrossmann]

The problem

jesopen() (src/jes/jesopen.c:36,46) reaches the JES2 checkpoint and spool by
ddname:

cp = checkpoint_open("DD:HASPCKPT");
js = spool_open("DD:HASPACE1");

That pushes the allocation onto every caller's JCL, and with it the site-specific
UNIT and VOL=SER:

//HASPCKPT DD  DISP=SHR,DSN=SYS1.HASPCKPT,UNIT=3350,VOL=SER=MVS000
//HASPACE1 DD  DISP=SHR,DSN=SYS1.HASPACE,UNIT=3350,VOL=SER=SPOOL1

Every procedure that hosts a JES2 reader carries those volsers, and each copy is
wrong on a system whose spool lives elsewhere. They are also invisible to the
code that depends on them, which is how mvslovers/httpd#256 happened: httpd's
STC procedure dropped both DDs, and mvsMF's jobs API — a CGI running in httpd's
task, therefore against httpd's allocations — started answering 500 on every
job list, job lookup and spool read.

The precedent is in this library

jesiropn() already dynallocs its own INTRDR SYSOUT DD rather than requiring one
in the JCL. That is why job submit kept working through the httpd outage
while everything reading the spool failed. Same subsystem, same library, two
different contracts.

What this would change

jesopen() dynallocs SYS1.HASPCKPT and SYS1.HASPACE itself (catalog lookup,
or the JES2 checkpoint's own record of the spool volumes) and frees them in
jesclose(). Callers then need no JES2 DDs at all, and the volsers stop being
copied into procedures across the ecosystem.

Consumers to check before changing the contract: mvsmf (jobsapi.c, three call
sites), httpd's STC procedure, and test/mvs/tstjeslg.c plus
jcl/tstjeslg.jcl, which allocate the DDs explicitly.

Not urgent — httpd 4.0.1 restores the DDs and documents them. This removes the
class of failure rather than the instance.

[mgrossmann]

Measured 2026-08-27 — and the issue is smaller and larger than it looks

Smaller, because the dynalloc code already exists. Larger, because the data set
name is not a constant.

1. The dynalloc path is written and unreachable

__cpopen() (src/clib/@@cpopen.c) and __jsopen() (src/clib/@@jsopen.c)
both branch on a "DD:" prefix. The else branch is allocate_checkpoint() /
allocate_spool() — full SVC 99 with __txdsn + __txshr + return-ddname.
src/jes/jesopen.c:37,47 is the only reason it never runs.

Called directly for the first time on MVSCE, it works:

(3) checkpoint_open("SYS1.HASPCKPT")
    OPENED - #142's minimal form works on this stand
      hct._SPOOL               'SPOOL1'

So the minimum form of this issue is two string literals plus __dsfree() in
jesclose() — not a new allocation layer.

2. The catalog carries one stand and misses the other

	MVSCE (mvsdev)	TK5 (drnmig3a)
cataloged	both, in SYS1.VSAM.MASTER.CATALOG	neither
ALLOC DA('SYS1.HASPCKPT') SHR	ok → SYS00001	IKJ56228I ... NOT IN CATALOG
LISTCAT ENT(...)	VOLSER MVS000 / SPOOL1	IDC3012I ENTRY NOT FOUND

Jobs JOB02606 (MVSCE) and JOB00029 (TK5). So a catalog-only implementation
would work on MVSCE and fail on TK5.

3. The SSVT route is dead — and it fails silently

Worth recording because it is the obvious idea and it is a trap.
ssct_find("JES2") → ssctssvt reaches HASPSVT in CSA cleanly, and
svhct (+0x17C) is documented "ADDRESS OF HASP HCT". Measured:

ssctssvt       = 00BD6460
svhct          = 00095000          <- private area
fetch of 204 bytes SUCCEEDED
VERDICT: DIFFERENT in 57 of 204 bytes

The HCT lives in the JES2 private area and 3.8j has no cross-memory, so the
fetch reads our address space at that address. It does not abend — it returns
zeros that agree with the real HCT in 147 of 204 bytes. A route that abends is
harmless; one that returns 72 %-plausible data is the one that ships. Do not use it.

4. OBTAIN by DSN over the online volumes is cheap

__listvl() + __dscbdv() ignores the catalog by construction, so it is the
route that reaches an uncataloged checkpoint:

(4) 16 volumes online
    HIT  MVS000  (OBTAIN rc=0) after 2 OBTAINs

5. The full bootstrap runs with no JCL DD at all

Scan → __dsalcf(dsname=,disp=shr,volser=MVS000) → SYS00003 →
checkpoint_open("DD:SYS00003"):

_CHKPT  MVS000    _CHKPT2 MVS000    _SPOOL  SPOOL1    _NUMDA 2

Note _SPOOL (include/hasphct.h:30): only the checkpoint needs discovery.
Once it is open the spool volume comes out of it, and _NUMDA gives the count.
_CHKPT is inside the checkpoint and can never help find it — that asymmetry is
the design, not a gap.

6. The data set name is not a constant — this is the real obstacle

Read out of SYS1.HASPSRC. $HCT:310:

$DSNPRFX DC    CL8'SYS1'           DATA SET NAME PREFIX FOR

HASPMISC:5279-5289 builds the name at run time:

MVC   SPLDSNAM(8),$DSNPRFX    SET PREFIX (DEFAULT = 'SYS1')
LA    R1,SPLDSNAM             SCAN FOR
SKIP90 LA R1,1(,R1)             FIRST BLANK
       CLI 0(R1),C' '            FOLLOWING
       BNE SKIP90                PREFIX
MVC   0(8,R1),=CL8'.HASPACE'  SET DSNAME FOR HASPACE
TM    SPLFLG1,SPL1CKPT        TEST FOR SYS1.HASPCKPT
MVC   5(4,R1),=CL4'CKPT'      ELSE SET DSNAME AND DDNAME

And HASPINIT:4273 makes the prefix an initialization parameter:

$PTENT ,&&DSNPRFX,NPLJCL,EBCDIC,,,(1,L'$DSNPRFX)     &DSNPRFX STATEMENT

So: the suffix .HASPACE / .HASPCKPT is an assembled literal and
invariant. The HLQ is $DSNPRFX, 1-8 chars, default SYS1, settable per
site. (HASPNUC:1687 also uses it as the minor name of the checkpoint
RESERVE ($CKPTVOL,$DSNPRFX,E,8,SYSTEMS).)

$DSNPRFX lives in the HCT, so by §3 it cannot be read from outside JES2.

The OBTAIN scan does not help here. It takes an exact DSN, exactly like the
catalog does; it buys catalog-independence and nothing else. A
prefix-independent search would mean scanning each VTOC for *.HASPCKPT, and
libc370 has no such call — __listds() goes through __listc()/IDCAMS LISTCAT
(catalog-based), and __dscbdv/__dscbav/__dscbv all take an exact key.

Worth keeping in proportion: today's code has the same exposure. DD:HASPCKPT
makes the site name the data set in its JCL. #142 does not create the prefix
problem — it only has to avoid breaking on it.

Where that leaves the design

Discovery order for the volume: catalog first (cheap, works on MVSCE), OBTAIN
scan second (2 of 16 volumes, works uncataloged). Both need the name.

For the name: default to SYS1., and keep the DD as an override rather
than going dynalloc-only. A site running the default needs no JCL any more; a
site that set DSNPRFX keeps exactly what it has today, and no consumer breaks
on upgrade. Probably also worth a way to pass the DSN without JCL — e.g.
jesopen_ex(const char *ckptdsn) with jesopen() as a NULL wrapper — because
a DD is awkward for a CGI consumer like mvsMF.

One diagnostic requirement: if the SYS1. attempt finds nothing on any volume,
the message must say both possible causes (non-default prefix / no JES2
checkpoint present), or it sends the next reader the wrong way.

Still open — deliberately deferred

• No probe run on TK5. The one thing it would add is §4 on an uncataloged
  stand. Blocked on an unrelated problem: PUT /restfiles/ds/{dsn} to that
  stand fails on larger bodies with Internal server error (abend recovery),
  the trigger size drops with each attempt (8800 bytes succeeded and then
  failed minutes later), and a failed PUT deletes the target data set. That is
  an mvsMF/httpd matter, not a jesopen() should dynalloc the checkpoint and spool, as jesiropn() already does #142 one, and it needs its own issue.
• The HCT deserves one more look. §3 rules out svhct from an ordinary
  address space; it does not rule out some other reachable copy.
• More source archaeology. SYS1.HASPSRC answered the DSN question
  outright; it may also say whether anything in common storage carries the
  prefix or the volumes.

Artefacts

test/mvs/tstjesda.c + jcl/tstjesda.jcl — the probe behind §3-§5, run as
JOB02625 on mvsdev, CC 0000, deliberately with no HASPCKPT/HASPACE1 DD in
the JCL.