In a recent note, "Shmuel Metz (Seymour J.)" said:
> Date: Sun, 15 Jan 2006 16:24:38 -0500
>
> >Look, guys, the silicon has already identified the conflicting keys.
>
> You're looking at the wrong side of the interface. DAIRFAIL does not
> have access to the relevant data. In order to provide the relevant
> data in the message, you need interface changes for DYNALLOC and for
> DAIR. By all means submit a requirement, but it's not as trivial as it
> looks.
>
I don't understand how these pieces fit together. Is DAIRFAIL a
sort of reporting component, analogous to SYNADAF? Is the Request
Block Extension available to DAIRFAIL? I took another
look at:
# 26.3.2 "z/OS V1R7.0 MVS Authorized Assembler Services Guide"
... where I see:
(2) The information reason code contains the value of the key
that caused the error.
??? For a mutually exclusive error, shouldn't there be two key
values reported, not one? Might S99ERSN, otherwise unused for
this error code, be overloaded with the other key value?
The description of DYNALLOC is frightening with in-use and not-in-use
allocations, and the possibility of reusing an existing allocation
rather than creating a new one. It states there is a performance gain
for reusing an existing allocation. Where? Can it bypass catalog
lookup or VTOC lookup? Does the SYSDSN ENQ remain in effect while an
allocation is not-in-use? If not, what happens if another job
deletes (and perhaps even recreates and catalogues) a data set
associated with a not-in-use allocation? Does the TSO FREE command
actually remove the allocation, or merely set the not-in-use flag?
It states that an allocation associated with an HFS path is not
eligible for reuse (why not?) Is this the reason that the TSO
ALLOCATE command makes PATH and REUSE mutually exclusive? But
why, then, can the REUSE keyword be used successfully when the
existing allocation is to an HFS path and the new allocation to a
Classic data set? Naive users perceive that REUSE simply has the
effect of freeing an existing allocation, if necessary, to permit
reuse of the same DD name in a newly requested allocation. Wouldn't
it be a valuable favor to customers to support this behavior even
when the new request is for an HFS path?
> I'll take the opportunity to plead that any new interfaces include
> adequate feedback for producing useful error messages. It's really
> easier to do it right the first time than to fix it later.
>
Such as, reporting both mutually exclusive keys?
-- 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
