>>The reason *I* hate OMVS is that those using it via some
>>C/C++/JAVA/whatever-clickable-stuff have no clue how things are
>>implemented in z/OS. So in case of an error they take any return
code/reason
>>code they get at face value. Unfortunately, that is the completely *wrong*
>>way to go about his. In my experience, the reason code given is completely
>>valid but at the same time completely obfuscates the real problem because
>>the first hint of trouble (aka the problem) is NOT shown anywhere.
>And I know enough about both worlds that I cringe when I see:
>
>128 rexx "say BPXWDYN( 'alloc path(''/tmp/nonesuch'') msg(wtp)')"
>08.26.36 STC07821 IKJ56228I PATH /tmp/nonesuch NOT IN CATALOG OR
CATALOG CAN NOT BE ACCESSED
>
>I'm confident that no CATALOG search was attempted and failed This is
>either an attempt to convert a UNIX completion status to terms familiar
>to legacy MVS programmers or an indolent inclination to recycle an existing
>message rather than invent a proper one.
You've provided me with an excellent example for my statement above.
Because that message is issued by TSO (IKJ prefix) or rather, by dynalloc
which uses some DAIR interfaces into TSO. I have always wondered about the
IKJ prefix, mainly because it is not in the book where the IEF messages (from
alloaction) are. Probably there is a reason behind this dating from very early
MVS times - please no historical discussion of that!
In a way, there was a 'catalog search' done, in the course of attempting to
allocate the dataset. BLDL ends up doing SVC12 which is called 'Catalog' SVC,
so you're right, the Catalog Search Interface (which came way later) was NOT
called, but there was some 'searching in the catalogues' going on. Hence the
IKJ message, which to someone from MVS says 'Dataset/File/Whatever not
found'.
> I believe I even submitted a PMR
>on the inaccuracy of the message. It went nowhere.
I am not surprised. :-) Every component answered strictly from their own point
of view, and they could not care less about the 'big picture'. From their own
narrow view, every component was right but as a whole, the stuff is useless.
And nobody wants to tackle this, as clarification requires mighty dollars that
IBM says 'whatever for? there are more important things to do.'
(I feel with you, I've been down that path numerous times. And have by now
given up to make them see the 'big picture'.)
>Well documented; inexcusably counterintuitive. I suspect the historical
>rationale is that 40+ years ago allocation couldn't muster the resources
>to perform a STOW to delete a member when the allocation had the form
>above.
In this case, I disagree. I agree with Gerhard Postpischil. This is something
architected, and just because this construct does not exist in another
architecture, does not mean MVS should change theirs, just because a
programmer wants to (come hell or high water) use his own way or the *nix
way of doing it. Also, I do NOT consider it counterintuitive, but then I grew
up
on MVS.
>Nowadays the only rationale, spurious, is that "it's always
>been that way." And ever shall be, as long as descendants of OS/360
>endure. But such anomalies give me neither high expectations nor good
>wishes for the destiny of z/OS.
Same argument as before: Changing this would require development dollars,
that IBM doesn't want to spend on this. But fear not, z/OS is going to be
clickable one of those days, and then you might get your wish! :-)
>Lately, I received in a reply to an RCF:
>
> "... The [...] book documents what is supported, not what is
> not being supported. if something is not mentioned, it should
> be assumed that it is not officially supported even though it
> may work. ..."
>
>Here, I largely sympathize with IBM. "what is not being supported"
>is an unbounded set, impossible to enumerate in a manual. My issue
>is that IBM did not document what is being supported, but merely
>supplied a handful of examples leaving the reader to extrapolate
>often with wishful thinking and a probable inference of internal
>implementation.
Always a dangerous thing. But it goes hand in glove with my first point above -
The OMVS world comes from a different perspective and architecture than the
MVS world. I remember the very first service transfer education for what is
now WAS (we called it 'component broken' then). There was some guy
standing there talking about 'the shasta' and a lot of other vocabulary that no
one in the audience had ever heard before. And if you think they would first
establish a definition for something before using it you can think again.
NOT establishing a firm definition of terms before using them is the big
problem
I see with the OMVS stuff. And I had my share of fundamentals discussions
when I wanted that clear definition from OMVS before using something. It does
Not help when A is 'defined' by using B (which has not been defined).
This also goes both ways - and is a reason why I hate OMVS. My MVS training
tends to trip me up and I just *expect* things to work like they do in the MVS
architecture. Sometimes I don't even realize that I made the wrong
assumption somewhere.
Best regards, Barbara
----------------------------------------------------------------------
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
