At 12:46 -0600 on 12/09/2015, John McKown wrote about Re: Inquire
intrdr default job class:
On Wed, Dec 9, 2015 at 12:29 PM, Shmuel Metz (Seymour J.) <
[email protected]> wrote:
In
<CAAJSdjh-Oh==ZxzZ=ZgZowG=708CPtcHZoxmy3p3Lz2za1=j...@mail.gmail.com>,
on 12/09/2015
at 11:48 AM, John McKown <[email protected]> said:
> OK, I've managed to confuse myself. You want the ENQ for SYSDSN
>to include the volser if and only if the DSORG is a PDS, otherwise
>to omit it?
No; the queestion is whether the original code was a design flaw, not
whether it is feasible to correct it today, and ISPF, not Allocation.
ÐThat's where I went sidewise. Thanks for the enlightenment. I totally
agree with you that SPFEDIT should have included the volser in the case of
a PDS. I would _guess_ it is a design flaw due to the ISPF person thinking
(as I was) about how SYSDSN was done and deciding to be similar. It might
even had been a good decision for non-PDS data sets as well.
rname==volser||dsn||member (where member=8C' ' if non-PDS?)
I totally agree.
There is however the issue of what type of ENQ to make for SYSDSN of
a PDS/PDSE. You need to issue a SHR while editing or the SPFEDIT is
useless. Note that for Non-PDS files you should be going SYSDSN/EXC
and no SPFEDIT is needed.
As to why SPFEDIT is VOLSER-LESS I agree with you about the ISPF
person in error using SYSDSN's RNAME as a model. At this point in
time there is little that can be done to fix the situation.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
