On Tue, 15 Mar 2016 14:00:15 -0400, Tony Harminc wrote:
>
>And just to be completely clear on the original message
>
>IKJ56236I FILE STEPLIB INVALID, FILENAME RESTRICTED
>
>This really does mean just what it says. It's the four DDNAMEs JOBLIB,
>STEPLIB, JOBCAT, and STEPCAT themselves that are caught and rejected early
>on in dynamic allocation. It's not some more subtle "effective STEPLIB" or
>something; it's those exact DDNAMEs.
>
>Of course everyone remembers that FILENAME (and in some contexts FILE) is
>early TSO-speak for DDNAME... But this leads to a particularly confusing
>version of the message:
>
>alloc ddname(steplib) path('/usr/bin')
>IKJ56236I PATH /usr/bin INVALID, FILENAME RESTRICTED
>
>which is still complaining about STEPLIB, not '/usr/bin'.
>
>This surely calls for one of Gil's well formulated SRs. IBM has changed
>some of the sillier TSO messages over the years, so it's not that there's
>no hope at all.
>
That probably needs an RFE, not an SR. Really, it should clarify:
IKJ56236I PATH /usr/bin INVALID, FILENAME STEPLIB RESTRICTED
The one I love to hate is:
user@OS/390.25.00: rexx "say BPXWDYN( 'alloc path(''/tmp/foo/bar'') msg(2)'
)"
IKJ56228I PATH /tmp/foo/bar NOT IN CATALOG OR CATALOG CAN NOT BE ACCESSED
I can call that SR-worthy in that no catalog access was ever attempted or
failed. And:
Hey! I just tried:
user@OS/390.25.00: rexx "say BPXWDYN( 'alloc dsn(SYS1.LINKLIB) old msg(2)'
)"
IKJ56225I DATA SET SYS1.LINKLIB ALREADY IN USE, TRY LATER+
IKJ56225I DATA SET IS ALLOCATED TO ANOTHER JOB OR USER
IEFA110I DATA SET CONTENTION
DATA SET SYS1.LINKLIB IN USE BY
SYSNAME JOBNAME ASID
smf1 job01 0006
smf1 LLA 001B
A miracle! IEFA110I is new with 2.2!
Batch JCL doesn't tell you; it just waits.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
