I understand your motivation to do this;
our site specific CALL macro also sets the high order bit on every
parameter address list (even fixed length), although nobody checks it;
it's merely for dump reading purposes.

But: if you recall the posting of the ATTACH macro description,
you are (and we are) in conflict with the recommendation of IBM,
which says that the VL bit should only be set on variable length
parameter lists. But even the IBM recommendations are not very
consistent, as the other poster pointed out ...

Kind regards

Bernd


Am 11.04.2012 16:07, schrieb McKown, John:
At present, all my HLASM code checks for the high order bit to be '1'b. Even 
for fixed length parameter lists. Why? Because I don't trust the programmers 
using my code to call it correctly. Therefore, I do as many validations as I 
can before performing any operations. I got into this habit due to a really 
messy HLASM subroutine that I had to rewrite. It had a tendency to not validate 
anything. And did some amazing memory overlays in CICS, some of which crashed 
CICS itself.

If a validation error occurs, I either return a return code which is architected as 
meaning "either the wrong number of parameters or an invalid parameter value has 
been detected.", or I force an ABEND. I only ABEND when I update an existing program 
which was not designed to return a return code, because I know the calling code will not 
check it. In the past, I caused an S0C3 via an EX of itself. I have changed this to an 
S0C1 by doing a BRC to *+2 (Jcond *+2) because I have changed my assembly technique to 
use relative addressing as well as being LE enabled (in most cases).

I actually prefer LE enabled assembler in most cases. Mainly because: (1) it 
interoperates better with HLLs like COBOL, PL/I, FORTRAN, and C/C++, both as 
caller and as callee; (2) I can use subroutines written in those languages 
easily; and (3) if I abend in my assembler code, I get a CEEDUMP. This latter 
is very nice when I am writing a UNIX shell command because it puts the CEEDUMP 
in a uniquely named file in the current directory. It's difficult to get a 
SYSUDUMP type abend dump from a UNIX shell command. And the CEEDUMP is usually 
sufficient for my debugging.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Reply via email to