DELE/RMD/RNTO hold the identity window across a whole IDCAMS run

[mgrossmann]

Follow-up to #79 (PR #86), which made the identity windows mutually exclusive.
Three of them are far longer than the rest:

Window	Contents	Order of magnitude
RETR/STOR	fopen — dynalloc ENQ + VTOC I/O	milliseconds
STOR (new)	__dsalcf/__dsfree — two SVC 99	milliseconds
LIST (PDS)	__listpd — BPAM OPEN + directory read	milliseconds
MKD	alloc_new_dataset	milliseconds
JES submit	jesiropn()	milliseconds
DELE / RMD / RNTO	idcams() — load and run a program	seconds

Now that the windows serialize, an IDCAMS window blocks every other session's
data set access for its whole duration. Before #86 that was a correctness
problem (a seconds-wide window in which siblings authorized as the wrong
user); now it is a throughput one.

Direction

Replace idcams() with the direct services:

• DELE / RMD — SCRATCH (SVC 29 via CAMLST) plus the catalog delete
• RNTO — RENAME (SVC 30 via CAMLST) plus the catalog re-entry

That drops the window to a couple of SVCs, and removes a program load from
under a switched identity. The PDS-member case in DELE (DELETE 'dsn(mbr)')
needs a different route than SCRATCH — probably a STOW disconnect — so it is
the part to design first.

Worth knowing before starting

• All three already pre-check ALTER via check_dataset_access(), so the
  authorization story does not change; only the mechanism does.
• IDCAMS reports failures as text ftpd currently discards; the direct services
  return codes, which would make the 550 replies more specific than
  "could not be deleted".
• This is a rewrite of three commands against a live catalog. It wants its own
  test pass on the target, not a "looks right" merge — the failure mode is a
  half-deleted or orphaned catalog entry.

Not urgent: it costs throughput on the least frequent commands, and only while
another session is doing data set work at the same moment.

[mgrossmann]

Measured on mvsdev against the merged series (a5b1256), and the premise of
this issue is wrong by an order of magnitude. I wrote "seconds" from the
assumption that idcams() loads and runs a program; I never timed it.

Two parallel sessions, 126 operations in 10.3s, all round-trip times from the
client (so they include the data connection where there is one):

Command	n	min	median	max
DELE (IDCAMS, no data connection)	10	0.12s	0.13s	0.15s
STOR	25	0.09s	0.10s	0.18s
RETR	15	0.09s	0.09s	0.09s
LIST	15	0.17s	0.18s	0.22s

DELE is the closest thing to a pure window measurement here — no data
connection, so the 0.13s is essentially the identity window plus the reply.
That is the same order as a LIST, not seconds.

So the throughput argument this issue rests on does not hold: an IDCAMS window
excludes other sessions for about as long as a directory listing does. What
remains of the case for CAMLST is smaller and different:

• it removes a program load from under a switched identity, which is one less
  thing running as someone else;
• SCRATCH/RENAME return codes would make the 550 replies specific, where
  IDCAMS text is currently discarded.

Neither is urgent. Leaving this open at low priority for the error-message
improvement, unless you would rather close it — the performance motivation is
gone.

[mgrossmann]

Confirmed on the correct library pairing. The first measurement above ran
against a module linked with a libc370 predating d44cfea; repeated after the
sysroot was refreshed and the production module redeployed:

Command	n	min	median	max
DELE (IDCAMS window)	10	0.11s	0.11s	0.15s
STOR	25	0.09s	0.10s	0.12s
RETR	15	0.09s	0.09s	0.10s
LIST	15	0.17s	0.18s	0.22s

126 operations across two parallel sessions in 10.2s, zero replies outside
2xx/3xx, zero 451s (so zero ABEND recoveries). The conclusion is unchanged and
now rests on the pairing that actually ships: the IDCAMS window is shorter than
a LIST, and the throughput argument for CAMLST is gone.

[mgrossmann]

Looked at this properly, and it ends here — but it produced a real bug next
door (#92).

The throughput case is gone, measured: the IDCAMS window is 0.11s median,
shorter than a LIST.

And for data sets there is no direct route to switch to. libc370 uses
CAMLST in exactly two places, @@locate.c (LOCATE) and @@dscbdv.c (OBTAIN) —
both read-only. There is no SCRATCH (SVC 29) and no catalog (SVC 26) wrapper,
so "use CAMLST instead" would mean building those first, and on a system with a
VSAM user catalog — SYS1.UCAT.TSO is in the RAKF profiles on our test system
— the uncatalog half is not a small job. Disproportionate for a 0.11s window.

For members it is a different story, and not about speed: libc370 already
ships __stow() and __renmem(), and the member paths need them for
correctness. Renaming a member turned out to be impossible — __locate()
ignores (member), so RNFR accepted members that do not exist and RNTO
rejected every member of an existing PDS as "already exists", and IDCAMS ALTER
could not have renamed a directory entry anyway. That is #92, fixed in #93 with
__renmem().

What is left of this issue is the error-message improvement, and that no longer
needs CAMLST: idcams() returns a return code we already have, so mapping it
to a specific 550 is a small change in the DELE and RMD paths whenever someone
wants it.

Closing. Reopen or file a fresh one if the message mapping is worth doing on
its own.