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:
128rexx 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
