Lindy,
here is some more
>> 2. Those horrible S0C4's. First one was a S0C4-10, unknown module,
>> and happened on the OPEN. How could I have debugged this? The
>> problem that I found from reading (yes reading the docs, I do) the
>> docs carefully, was that DCB's have to be in 24 bit mode storage.
>> Whoops. Where (and what kind of) in the dump would show that
>> information?
If you look at the expansion of the DCB macro...you will see that EODAD
is stored in a 3 byte fields. I know that the VSE LNKEDT does tell you
that the module you try to link with an attribute of RMODE ANY/31 does
have addresses that use only 3 bytes. I have no clue why the BINDER
does not behave the same...wait, it could be that you had RMODE in the
control-information for the LNKEDT/binder in which case the
system determines...if s/he demands it...no need to complain - (he
knows what he is doing).
>> 3. A S0C4-11 because I coded an MVC incorrectly. I coded this:
MVC INOUTBUF(80),=C'Test record'
You did realy want the machine to move everything starting at the
location where "Test record" is in a length of 80 to INOUTBUF?
Apparently you crossed a page boundary between used and not used storage
(very likely in this case- very unlikely usualy)... this is
where the hardware kicks in....with those S0C4
>> A change to MVC INOUTBUF(11),='Test record' works just fine.
And MVC INOUTBUF,=CL(L'INOUTBUF)='Test record' would have worked as
well.
Much better solution is what (ITIR) Ed J. uses ... a MACRO called
MVCSL (or so) which means MVC in sender length.
--
Martin
Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
more at http://www.picapcpu.de
