Newsgroups: bit.listserv.ibm-main
Date:         Mon, 27 Jul 1992 16:53:00 PDT
From:         Leonard D Woren <LDW@USCMVSA.BITNET>
Subject:      Re: Esoteric Device Message in ESA 4.2

On Mon, 27 Jul 1992 14:53:00 PDT,
   Dave Friedman 510-642-5823 <SPGDNF@UCBCMSA.BITNET> said:
> (...)
> If the dataset is cataloged via UNIT=DISK and DISP=(,CATLG) in jcl, the
> catalog shows a DEVICETYPE of X'3010200F'.  The same thing happens if we

3010200F is the UCB device type for 3390.

> catalog the dataset using IDCAMS DEFINE ... NONVSAM DEVTYPE(3390), and
> if we catalog the dataset with a WYLBUR command (apologies to Leonard).

Whether it's JCL, IDCAMS, or Wylbur (a horse is, uh, oh never mind),
it's the CATALOG SVC that's doing the real work, so getting the same
value in the catalog entry is to be expected.

> However, if we catalog the dataset using IDCAMS DEFINE ... NONVSAM
> DEVTYPE(DISK), the catalog shows a DEVICETYPE of X'0003200'.

However, in this particular case (the same would happen with IEHPROGM),
the program has no way of knowing the correct device type.  Duh, why
not scan the online volumes to locate it?  Because this logic hasn't
changed since most disks were removable, and they had to make it work
for non-mounted disks.  An interesting exercise would be to try to get
IBM to fix IDCAMS and IEHPROGM to look for an online volume in the
specified unit group and pick up the correct device type.  Good luck.
(Why do I have to specify UNIT= *at all* if I specify VOL=SER= for an
online disk???  That's one of my pet peeves with MVS.)

> I guess the first question is why is IDCAMS using X'0003200'?  However,

This is documented somewhere, but I don't remember where.  The X'20'
in the third byte is the device type (dasd), the same as in 3010200F.
The first halfword (0003) is the relative entry number in your
UNITNAME macros of the UNITNAME DISK.

> this is also true in our ESA 3.1.1 system, and it does not generate any
> JES2 messages there.

Must be a new feature, or maybe just a higher maintenance level.

>     IEF348I dsname WAS FOUND TO BE CATALOGED USING ESOTERIC DISK
>             INSTEAD OF A GENERIC

Well, that's true.

> The ESA 4.2 messages manual says that this is to warn the user in case
> the system I/O configuration changes.

Yep.  If you change the *relative* position of the UNITNAME=DISK in
your gen, all datasets cataloged using 00032000 will likely get
catalog errors when access is attempted.

> The manual seems to be advising
> the systems programmer to recatalog the dataset using a generic.

You should apar the manual (i.e., send in a reader comment form) if
that's what it says.  The person responsible for creating the dataset
should fix it.

> In our shop the systems programmer does not mess around with
> application files.

That's probably the norm.

> Anyway, it would be a never-ending task, since we recommend to
> our application staff that they use esoterics rather than generics.

Esoterics are definitely preferable for creating new datasets.  But
for cataloging existing datasets, the actual device type should
*always* be used, for exactly the above reason.

> ...  However, I wonder if anyone else has encountered this problem and
> found a way to suppress the JES2 message.

Maybe you could use console automation to intercept the message and
recatalog the dataset correctly?  Then you'd only get the message once
per incorrect catalog entry, and there would be no ongoing manual
effort involved in correcting them.

> Is there some reason why JES2 should be giving people this "reminder"
> every time they access a file cataloged with IDCAMS and an esoteric?

Yep.

> It seems like nagging.

Yep.  Using an esoteric in IDCAMS or IEHPROGM should be considered an
error.  This is IBM's way of convincing you to do it right, without
actually making it fail.

> Is this message a result of the IBM
> orientation toward SMS?  We are not yet an SMS shop.

Either that or a response to constant problems caused by the UNITNAME
positions changing.  The manual says that the systems programmer can
never move or delete UNITNAMEs once they're defined, because it'll
cause problems.  Most systems programmers don't know this.  I've
always ignored it, because I've always considered those catalog
entries to be erroneous.  When I first came here, I recataloged
thousands of incorrectly cataloged datasets so that I could clean up
the UNITNAMEs.

/Leonard
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU