On Tue, 10 Aug 2010 18:28:00 -0500, John McKown wrote:
>> >
>> >+ARC0141I ERROR ALLOCATING OUTPUT DATA SET
>> >
>> It fails if the ENQ is held by a different address space; succeeds
>> if the ENQ is held by the TSO session that issues the HLIST command.
>> Does HLIST FREE the allocation and re-establish it afterwards?
>
>You're right! I'll need to rethink how ODS() works. And if it is a
>"reverse channel", I wonder why it's not used to output to SYSTSPRT in
>batch.
>
You don't even get a return code. (But how does HMIGRATE WAIT
EXTENDRC work?)
It's interesting to compare the effect of:
HLIST ODS('invalid.dsname') ...
and:
ALLOCATE DSN('invalid.dsname') NEW CATALOG
under both TSO and OMVS Rexx "address TSO ...", noting where the
error messages from catalog, allocation, and/or HSM appear.
>> >Again, you only get these messages on your TSO session. Perhaps the DFHSM
>> >people need to look at making some major changes!
>> >
>> Amen. But somehow the phrase "snowball in hell" comes to mind.
>
>Most likely. Or "nitrocellulose cat". But IBM seems to be "pushing" z/OS
>UNIX, so maybe ...
>
I don't know that one.
The custom of directing messages via TPUT to a TSO ID became
broken the instant it became possible to run the TMP in batch.
It became slightly worse when OMVS got the "tso" command (long
before OMVS Rexx got "address TSO").
I wonder how much of this could be repaired by generating a unique
identifier, distinct from any possible valid TSO ID, for such
transactions, and teaching TPUT to direct output for such IDs to
TSO, batch, or OMVS sessions as appropriate, and teaching RACF to
give such IDs permissions identical to the associated real user
ID? HSM itself need never know it's happening. I suppose it would
break other things even worse.
-- gil
----------------------------------------------------------------------
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
