A few days ago, /leonard and I both used some controversial adjectives
which are again applicable to the IBM developers. I get:
17 *-* RC = bpxwdyn( 'alloc dsn(X.Y) path(''/dev/null'') msg(2)' )
IKJ56876I DATA SET X.Y NOT ALLOCATED, MUTUALLY EXCLUSIVE PARAMETERS SPECIFIED
M&C refers me to "z/OS V1R7.0 MVS Authorized Assembler Services Guide",
which in turn tells me:
Application Programmer Action: Consult the
descriptions of the keys specified and
determine which should be used.
Look, guys, the silicon has already identified the conflicting keys.
Don't require the expensive and error-prone carbon to re-perform the
analysis. Name the offending keys in the message.
I recognize that (probably) at the point of error detection DAIRFAIL
has no better information than the key codes. Fine. Put them in the
message in hex -- I can at least get a start by looking those up in
TFM. In fact, DAIRFAIL has better information than that. If I
swap the offending keys, I get:
16 *-* RC = bpxwdyn( 'alloc path(''/dev/null'') dsn(X.Y) msg(2)' )
IKJ56876I PATH /dev/null NOT ALLOCATED, MUTUALLY EXCLUSIVE PARAMETERS SPECIFIED
... so DAIRFAIL can translate either key to meaningful text. All it
needs to do is put out in this case:
IKJ56876I PATH /dev/null NOT ALLOCATED, MUTUALLY EXCLUSIVE PARAMETER DATA SET
SPECIFIED
Another case where I'd prefer a "self-explanatory" message to the
information (useless in this case) in M&C.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
