I was delighted to find the BPAM support for HFS directories in z/OS v1r5. So I
quickly coded an IRXJCL job with an HFS directory containing Rexx EXECs as
my SYSEXEC DD. Alas, it fails with:
IRX0551E The exec load file SYSEXEC must be allocated to either
a partitioned or sequential data set.
I opened a PMR on this. Support explained, correctly, that this can be
circumvented (I don't consider it a solution) by concatenating a temporary,
empty, PDS in front of the HFS directory. But I believe this is not the
sort of wart that should be permitted to grow on an operating system. It appears
that IRXJCL does an SVC 99 query and erroneously enforces some constraints on
the DSORG of SYSEXEC. I asked Support:
"Why not simply omit the SVC 99 and the test?"
"Then an ABEND [S213?] might occur."
"Works for me; a failure is a failure."
"We try to avoid ABENDs [reasons stated, but obscure to me]."
Support suggested that I override the HFS directory DD statement to DSORG=PO.
This results in a JCL error. They suggested that I open a Requirement to
remove the mutex between PATH and DSORG. This sounds good, but I wonder,
How many OS components would this affect: Allocation, SVC 99, JCL parser,
TSO ALLOCATE parser, BPXWDYN, other (specify). They suggested that I
open a Requirement that SVC 99 query should return DSORG=PO for an HFS
directory (it currently returns Unknown). This sounds good, but how many
other programs would be broken by such a change in behavior of SVC 99?
My first thought was that instead of attempting to pre-validate in a world
of changing rules (the Red Queen plays Calvinball?) they should simply attempt
the OPEN and take suitable action on error Completion Code from OPEN.
I RTFM. It doesn't even list completion codes from OPEN. WHY!? (I know,
I started a discussion here lately on the merits of RC<>0 vs ABEND.) This
is clearly a case where it would better for for OPEN to return bad status
rather than ABENDing. If there's a requirement, it should be for an
"ERROR_RETURN=YES" operand on the OPEN macro.
Given that the design objective is to avoid the ABEND, I constructed a case
in which the ABEND occurs (second SYSEXEC catenand is an HFS basefile), and
opened another PMR on failure to prevent the ABEND. So IRXJCL fails both
ways: it reports an error and fails to OPEN a valid SYSEXEC DD, and for another,
invalid, SYSEXEC DD it fails to detect the error and ABENDs.
My latest suggestion to them, in view of the failures both ways, is that they
abandon the attempt to pre-validate; set an ESTAE, trap the S213, and report
it. Thus the onus of error checking could revert to OPEN, which appears
already to do the checking correctly. But I don't know what collateral
effects the ESTAE approach might have.
Any comments?
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In <LISTSERV%200504101415326111.024F@no-spam>, on 04/10/2005
at 02:15 PM, Paul Gilmartin <gilmap@no-spam> said:
>Any comments?
I don't recall whether it still exists, or how much information it
provided, but OPEN used to support a 213 exit in the exit list.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
