Tony
... since IBM appears to have abandoned enhancements to it <MODCB -
actually I expect all of them!> for at least some access methods, and its
apparent goal of providing upward compatibility and control block
independence was never really met.
If VTAM is any guide, the abandonment happened about 30 years ago!
The story is as follows:
I used to write usually fairly trivial programs using the VTAM API. When I
needed to check the contents of an RPL after the call to VTAM, I started
out - late 70s - checking the control block. More and more I simplified my
programs by setting values in the control block(s) rather than relying on
the relevant macro operands.
Sometime in the early 80s, I decided that, if IBM supplied these xxxCB
macros, it must have a reason and so I took one of my trivial VTAM programs
and tried to modify it to use xxxCB macros rather than MVC, OI, NI, ST and
so on. I discovered - as John Gilmore said - something missing!
Where I happened to be working there were VTAM developers to hand and so I
asked one of them how to solve the problem, a question rather similar to
John Bodoh's original post. That's when he confessed that the xxxCB macros -
at least as far as VTAM was concerned - had been thrown on the scrap-heap.
Thereafter, I abandoned the executing - as opposed to control block - macros
completely since finally all the macros did for me was to put a code
corresponding to the macro name into the RPL prior to the call to VTAM.
Having fewer BALR 14,15 points calling VTAM made for a tidier program.[1]
By a strange coincidence, the same developer has moved to the "dark side" of
Communications Server and I happen at the moment to be working with him
again after all this time - rather more remotely! - cleaning up some
time-distorted text in the manuals relating to the generically named
TCPIP.DATA data set or file.
-
[1] I believe there are some in this list to whom this approach is some sort
of heresy! (Actually it's probably this sort of mind-set that caused John
actually to try to use the xxxCB macros!) My excuse is contained in a
comment one of my managers made to the effect, he had never seen such
extensively commented assembler programs and he was one of those managers
who really used to be happier as a technician. He was responsible for
"installing" - in the SE sense of the word - one of the first 360/67s.
-
Chris Mason
----- Original Message -----
From: "Tony Harminc" <t...@harminc.com>
To: <ASSEMBLER-LIST@LISTSERV.UGA.EDU>
Sent: Tuesday, February 07, 2012 11:57 PM
Subject: Re: VarIabLe DD names in VSAM.
On 7 February 2012 17:25, John Gilmore <johnwgilmore0...@gmail.com> wrote:
I am missing something here.
What form would you like a DDNAME value to take?
I imagine the difficulty is that on macros DCB and ACB, DDNAME=SYSUT1
uses SYSUT1 as the character value of the DDNAME, and not as the
symbolic address of the character string. But isomorphic DCB/ACB
keywords such as EXLST= and EODAD= use the supplied value as an
address.
So given that GENCB and MODCB also have a parameter DDNAME=,
documented as "DDNAME=character string", what is one to make of it? I
don't know, but a quick look at the macro suggests that there is a
notation that will do the job; the trick then is in interpreting the
documentation. I *think* that doc says that DDNAME=(*,<base
displacement address>) is what's needed, but given the state of the
surrounding text, I am not all that confident in my interpretation.
For this simple and common task, I would simply use the IFGACB (or
DCBD macro - they are, of course, compatible for this purpose) to map
the ACB, and then copy in the DDNAME, taking care that it is not open
at the time.
MVC ACBDDNM,<your field>
Whether MODCB is the right thing to use is an open question, since IBM
appears to have abandoned enhancements to it for at least some access
methods, and its apparent goal of providing upward compatibility and
control block independence was never really met.
Tony H.
