NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/bit/listserv/ibmmain/2699

Text File | 1992-11-23 | 3.5 KB | 71 lines

Comments: Gated by [e-mail]
Path: sparky!uunet!paladin.american.edu!auvm!STANFORD.BITNET!M.LAWRENCE
Message-ID: <[e-mail]>
Newsgroups: bit.listserv.ibm-main
Date:         Mon, 23 Nov 1992 11:11:10 PST
Sender:       IBM Mainframe Discussion list <[e-mail]>
From:         "Mark C. Lawrence" <[e-mail]>
Subject:      MVS treatment of DISP=MOD (was: IEFBR14)
Comments: To: [e-mail]
Lines: 59

REPLY TO 11/22/92 01:04 FROM [e-mail] "IBM Mainframe Discussion
list": Re: IEFBR14

On SUN 11/22/92 Leonard D Woren <[e-mail]> said,
>On Sat, 21 Nov 1992 18:41:07 EST,
>   Jerry Bryan <[e-mail]> said:
>> I am not sure why you consider this behavior of MVS to be broken.
>> It is exactly what would happen if you said (OLD,CATLG) and did not
>> open the data set, for example by running IEFBR14.
>
>I consider it broken because MOD will be treated as NEW if the dataset
>doesn't exist, OLD-Extend if it does exist, unless you point to a
>specific volume, in which case it's only treated as OLD-Extend.  ...
>Specifically, why will MOD create the dataset on a generic/esoteric
>unit, but not on a specific volume???  The only other organization
>that can write arcane rules like that is the IRS, and we know
>*they're* unreasonable.  This behaviour is a *perfect* example of why
>users consider MVS too complicated.

Actually the rule is very simple:  If *no volume information is available*,
the data set is treated as NEW; if volume information *is* available, the data
set is treated as old-extend.  It is neither complicated nor arcane.  I can't
be sure of the reasoning behind it--perhaps some old IBM'er will enlighten
us--but my assumption is that it was specifically designed to handle object
files written by compilers.  Look in any compile or compile/link proc, for any
language, and you'll see something like

         //SYSLIN DD DSN=&&LOADSET,DISP=(MOD,PASS),UNIT=SYSDA,
         //  SPACE=...,DCB=...

(btw, these haven't changed since early OS/360 except to add the second
ampersand when symbolic parameters were introduced).

If you stack multiple compile steps, the first one sees this as NEW,PASS and
creates (and passes) a temporary file.  Second and subsequent steps find it in
the pass queue and treat it as MOD.  Since the most common use of temporary
files passed between steps was for object modules, it's easy to believe that
the rule was written just to make that process easy.

As to why they decided to test "is volume known" rather than "is dataset in
catalog/pass queue" consider the alternatives.  You can't base it on whether
the data set is on the volume, because the initiator doesn't do the
OBTAIN...OPEN does that.  Suppose you say "if in catalog or pass queue treat
as old-extend, else treat as new".  Then, suppose we want to MOD an existing
data set:  If we refer to it via the catalog, it gets treated as MOD, but if
we specify unit/vol, the system will try to treat it as NEW.  Keep in mind
that it was common to have uncataloged data sets that were referred to by
specific volume in the JCL.  My installation didn't *allow* ordinary users to
catalog there files until the mid-70s.

I think it's reasonable to assume that the MOD stuff was never intended as a
way to optionally create a *permanent* data set.

Mark C. Lawrence
Systems Programmer     Internet: [e-mail]
Stanford Data Center     Bitnet: M.Lawrence@STANFORD
Stanford, CA 94305-4136     Tel: [phone]

To:  [e-mail]