Newsgroups: bit.listserv.ibm-main
Date:         Wed, 29 Jul 1992 21:37:00 PDT
From:         Leonard D Woren <LDW@USCMVSA.BITNET>
Subject:      Re: UNIT and VOLUME specification

On Wed, 29 Jul 1992 12:25:37 EDT, BENSON@POKVMCR3.VNET.IBM.COM said:
> Leonard, in answer to you comments - (a) SMS is our strategic
> direction and our desire is that everyone use it, (b) I can't
> speak for the future but that is certainly true today, (c) no.

Then you have to fix it so that sysres can be SMS managed.  This means
replacing the SYS% conversion silliness with something that can
actually be used.  How many shops have *every* dataset on sysres named
SYS1.something???  Until CBIPO ships the system that way, *I* never
will.  And I don't think you want to limit things that way anyway.
A more general solution is needed.  I'd suggest some prefixing method
to specify the volser.  This limits the dsnames to less than the full
44 characters, but this shouldn't be a problem for sysres datasets.
For example, let me define an index level, say, altres, such that any
reference to altres.SYS1.LINKLIB means SYS1.LINKLIB on ALTRES.
(Actually, what would be really nice would be the ability to specify
any volser via syntax like "ALTRES:SYS1.LINKLIB".  I won't hold my
breath...)

Until sysres can be cleanly SMS managed, and until *all* other IBM
utilities can work with SMS volumes, IBM cannot reasonably state that
SMS is the strategic direction.  IBM finally fixed the problem of
IDCAMS BUILDIX requiring its internally-created IDC work files to be
on non-SMS by answering an old unrelated SHARE requirement -- allow
external sort to be used.  This was actually a good solution for that
particular case.  But IBM's answer to complaints that IEHMOVE doesn't
work on SMS volumes of "IEHMOVE is obsolete, use IEBCOPY and DFDSS" is
inappropriate for one glaring reason -- users will have IEHMOVE-
unloaded datasets for a long time, and they need to be able to reload
them.  IEHMOVE could be fixed rather easily -- THROW AWAY the silly
code that does the manipulation of its work datasets via SVC 32, and
either allocate them with SVC 99, or (best) allow them to be specified
in the JCL.  Also, change the creation of the output dataset from SVC
32 to SVC 99.  If these reasonably simple changes were made, many
advantages would result.  IEHMOVE could run without APF authorization.
Performance would be improved, since VIO work files could be used.
And unloaded datasets from obsolete device types could be reloaded to
VIO and then converted over to current dasd.  Have I submitted a SHARE
requirement?  No.  Why bother, when IBM has made it clear that they
don't understand, and have no intention of fixing IEHMOVE?  If you can
assure me that the requirement will be accepted when submitted, and
targetted for near-term delivery, then I'll submit it.  Otherwise, why
should I waste my time?


On Wed, 29 Jul 1992 13:32:08 EDT,
   Jerry Bryan <BRYAN@WVNVM.WVNET.EDU> said:
> >Specifically, if ALTRES (for example) is permanently resident, why
> >do the following fail without UNIT=nnnn?

> (...)
> I think the simple answer is not quite so simple.  The real reason
> (at least historically under OS/360) is that ALTRES might be a tape.

Irrelevant.  Note that I specifically was referring to PERMANENTLY
RESIDENT disks.

> For example, vary ALTRES offline.  Should the JCL be parsed
> any differently while ALTRES is offline?  If ALTRES were offline,
> how on earth could you figure out what the proper device type was?

Well, someone else already commented on the JCL parsing issue.  I
assume you just meant "should it mean something different if ALTRES is
offline?"  Yes!  It's quite simple.  VOL=SER= without a UNIT= should
work only for permanently resident dasd.  If you reference a
non-mounted disk volume without UNIT=, the job should fail just as it
does now if you omit the UNIT=.  All I'm asking for is that UNIT=
should be implicitly assigned by MVS if the VOL=SER= refers to a
permanently resident dasd.  Quite simple, if the designers had any
imagination.  In fact, this is so simple that a JES2 internal text
exit could be easily written to do exactly that!  Hmmm...

/Leonard
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Subject: (no subject given)