Steve
I see that this thread became focused on the structure of the OPEN list.
However, here's a "FWIW" on the subject of GENCB and its siblings which may
be relevant given that you are responsible for teaching material and
presumably you want to be sure you teach only what is current:
Back in the early '80s one time I was experimenting with the assembler
programming of an API - as you appear to be doing. Specifically I was
interested in the VTAM API as you - for the moment - appear to be interested
in the VSAM API. I believe the two APIs were created at much the same time
and have a similar control block - and associated macro - design with the
hope - rather than the eventuality I expect - that there could be some
synergy between the operation of the two APIs.
Like you now I was writing a reentrant program[1] and I thought I'd try out
GENCB, MODCB, SHOWCB and TESTCB. In essence I discovered that, far from
aiding coding, use of these macros was a very clumsy way to program in
comparison with bit testing and setting instructions.
But, but, but, I hear you say, what about the quality of the documentation?
My answer to that would be that just using my standard approach always to
explain what is going on from column 40 onwards and the use of symbolic
field names and bit equates is quite adequate for the poor programmer who
might come along later after I have departed and who dares to amend my
masterpiece!
Specifically with VTAM RPL programming - I can't say for VSAM - the bit to
be set may be derived from a variable following the operation of the SNA
protocol rather than a constant. Trying to fit this into the use of xxxCB
macros became just hopeless. They weren't designed to cope with that level
of flexibility. Essentially, I found myself having to manipulate the bits
within the expansion of the list form of the TESTCB macro which was directly
equivalent to what I thought I was doing with the RPL - obviously a total
waste of my time and the computer's time.
Finally I found that a field I wanted to control wasn't covered by the xxxCB
macro I wanted to use.
Fortunately I worked in a location where all were assignees from within IBM
and that included VTAM developers. So I walked round a partition and put the
issue to a man who could be expected to take responsibility for my
frustrations.
"Well" he said, slightly embarrassed "We don't actually support xxxCB any
more." Recall this is about 25 years ago.
Whether this was because it was understood that nobody used those macros as
being too cumbersome or simple neglect I didn't find out. Whatever the
reason, I threw out the xxxCB macros with gusto and went on happily coding
my reentrant program purely with the basic macros and manipulated my control
blocks "to bits"!
Chris Mason
[1] The subject of reentrancy and VTAM programs deserves some comment. In
general, there will only be one VTAM server-like application program running
on an operating system instance at any one time. Thus the main part of the
program - the part which manages the opening and closing of the ACB and any
necessary definition of the ACB, using GENCB or otherwise - will not need to
be reentrant. On the other hand the part of the program which handles each
session will need to be reentrant - again, in general, since, if all
processing is performed in VTAM exits - not usually possible - the
reentrancy requirement can be relaxed.
In any case as a sort-of cultural preference, I prefer all programming to be
reentrant since it imposes the discipline of separating logic from data
despite Turing[2] and the fact that both occupy the same address space and
can be mixed.
[2] I thought I'd better check this so I found
http://www.turing.org.uk/publications/cambridge1.html
which contains "Computer programs, operating on data, are themselves data;
and Turing was eager to put this idea into application as soon as it could
be embodied in electronics."
----- Original Message -----
From: "Steve Comstock" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To: <[email protected]>
Sent: Friday, March 16, 2007 8:20 PM
Subject: Need help with Assembler accessing VSAM file in reentrant
LE-conforming program
Been working on this several days, driving me nuts.
The basic setup:
LE-conforming, reentrant Assembler program intended
to run as a CGI and access a KSDS by key.
In the program, my call to BPXWDYN is working fine.
Next, I use GENCB to generate an ACB dynamically.
Then I issue OPEN against that ACB: I get S0C4 that
points to the next instruction after my OPEN, which
is an LTR 15,15; so it looks like the abend is being
generated in OPEN.
The code in the vicinity:
la 2,genparm1
gencb blk=acb,ddname=meals,macrf=(key,dir,in),
loc=any,am=vsam,
rmode31=all,mf=(g,(2),genlen)
ltr 15,15
jnz bad_gencb
lr 10,1 pick up address of built acb
open ((10)),mode=31,mf=(e,openlist)
ltr 15,15
The following fields are defined in a DSECT; (this
DSECT is set up as part of the DSA so that
addressability is provided by R13):
acbstart acb am=vsam
acbend ds 0f
acblen equ acbend-acbstart
ds 0f
genparm1 ds cl(genlen)
---------------------------
My guess is that actually the gencb parameters may
not be correct, but I can't see it.
Any suggestions for this?
---------------------------
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
----------------------------------------------------------------------
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
