Steve
I could say in a manner comparable to that which led me to abandon xxxCB
macros but over a much longer time since I wasn't tipped a wink that I was
on the wrong track, I abandoned execute forms of macro completely. Just a
raw SVC with an "equated" number and a reinforcing supporting comment such
as "ISSUE OPEN SVC" seemed entirely adequate.
Note that an intermediate stage was to prepare all the relevant data areas -
in dynamically acquired storage of course - and registers in such a way that
the execute form of the macro could be coded with the result that the macro
had no option - in most cases - but simply to spit out the SVC instruction.
("In most cases" because sometimes it was necessary to have a register be
"zeroed" or some other necessary adjustment just in front of the SVC.)
If IBM is committed to ensuring that the program will works from this point
on for evermore, how can the routines called by the SVC "know" whether or
not the SVC was assembled from programmer code[1] or macro code? Release x+n
cannot change what release x's macro created! What's all this nonsense about
"all bets are off"!?!
[1] Programmer code advised by observing what the macro produced - at the
release x level naturally - before it was replaced with raw code. A
programmer clever enough to follow the instructions in the IBM manual is
quite sufficiently well equipped to "copy" generated" code. Did I miss
something???
Chris Mason
----- Original Message -----
From: "Steve Comstock" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To: <[email protected]>
Sent: Saturday, March 17, 2007 4:55 PM
Subject: Re: Need help with Assembler accessing VSAM file in reentrant
LE-conforming program
Peter Relson wrote:
Openlist is defined in my DSECT area:
openlist open 0,mode=31,mf=l
+OPENLIST DC 0F'0'
+ DC AL1(128)
+ DC AL3(0)
+ DC A(0)
If truly in the "DSECT area", then that is the problem. Having something
with DC's in a "DSECT" does not do any initialization. Therefore it seems
logical to presume that the storage was not initialized.
Well, yes. I made that point in my OP. And I pointed
out the mf=(e,openlist) operand on my in-line OPEN,
which initializes the DSECT entry; but it does not
set the end-of-list bit, which was the cause of my
grief.
I get S0C4 that
points to the next instruction after my OPEN,
On most 0C4's, the PSW is the updated after-program-check PSW. You should
therefore look at the instruction before what the PSW points to in order
to
see the instruction that "caused" the PIC 4. It is extremely unlikely
that
the 0C4 was within OPEN processing itself (i.e., the SVC processing) yet
the PSW for the PIC 4 shows within your module. But if you are not
actually
looking at the time-of-error PSW, it is quite possible that the PSW for
your RB points to the instruction after the SVC.
Yes. I know how to read a SYSUDUMP. But, of course, this
was an LE dump. In any case, the instruction pointed at
by the dump routine was LTR 15,15 which I'm sure you'll
agree will never cause an 0C4. The instruction before that
is the SVC 19 from the OPEN expansion.
However, in the case of OPEN, you can just do an MVI
openlist,X'80' for an input file.
This is a very bad idea. The interface to services documented by macro is
the macro. If you "do it yourself" all bets are off.
But not totally for OPEN. Frankly, I think the execute
form of OPEN should set the end-of-list bit just as the
execute form of CALL, for example, does. Took me three
days and some help to find that piece of information.
I actually did an OI instead of an MVI, but that was
what made the code work. I don't think it's a "very
bad idea" at all. It made the code work in a way that
is unlikely to ever fail even if IBM were to change the
macro expansions in the future.
[snip]
Peter Relson
Kind regards,
-Steve Comstock
----------------------------------------------------------------------
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
