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

Reply via email to