On Thu, 29 Jul 2010 00:23:57 -0500, Barbara Nitz wrote:
>
>Gil,
>you said that you hate MVS and that you consider it archaic. I have seen your
>struggles with it (more willingness to understand than from a lot of others
>thatjj
>I have observed), so please do not take the following as an attack on you:
>
Thanks for your understanding.
>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. You have
Several sides to this problem. The middle layer is only trying to
help you. In the case of the C RTL, trying to translate from z/OS
jargon to Unix/C jargon. I hear from one side:
"What is this 'IEC143I 213-04', anyway!?"
as from the other:
What is this 'broken pipe', anyway!?"
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. I believe I even submitted a PMR
on the inaccuracy of the message. It went nowhere.
Conversion of completion status is generally pernicious. A FAQ on
TSO-REXX is, "How can I force an ABEND from a Rexx EXEC?" The
questioner wants either to flush remaining job steps or to force
a dump. Can't. The obvious technique, LINKMVS IEFDCH0, attempting
to force a SOC1 is trapped by the Rexx interpreter and reflected
to the caller as RC (-193).
>to go and search for it, and to do that you must have some idea how things
>work and/or work together. This is also why just about *any* problem (I have
>seen) caused by some application code misusing some services unintentionally
>goes in circles three hundred times until the customer escalates and finally
>someone with my attitude to finding problems in USS comes along. (Guilty as
>charged, I tend to escalate after the first circle. That is also why I know
>more
>about USS than I ever wanted to.)
>
>As for the attempt to remove a member in a PDS:
>dsn=datasetname(member),disp=(old,delete)
>is NOT the way to do it. While it is certainly possible to address a member of
>a
>PDS in the dsname, the DISPOSITION is always for the full dataset, NOT any
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. 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.
>member. What does the Language reference for remove() say what remove()
>is applicable for? Is the dataset type (PDS/HFS/PS...) mentioned anywhere? Or
>does the reference (however opaque) make it clear (what an oyxmoron) that
>remove only works for a file in a USS file system? (And please check the
>Language reference for z/OS, not any C or C++ reference). C/C++/Java 'in
>nature' do not have a clue about the construct named PDS/E, as that is
>unique to z/OS. And that distinction and the failure in the USS stuff to
>clearly
>say what you *cannot* do is another reason why I hate OMVS stuff.
>
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. (I need to ping IBM on this RCF again; it appears
to have gone idle.)
On the other side, IBM support once (attempted to) refute a PMR
with the assertion that my test case did not match any of the
examples in the manual. (I had invoked a utility (perhaps HLASM)
from a Rexx EXEC and all the examples showed invocation from JCL.)
Examples should not be considered restrictive.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
