here is the COBOL code which calls a procedure:
move 'MSTR-READ' to ws-ch80.
call linkage type is procedure "cp800_PrintLog_cp800mstrp"
using by reference minc, ws-ch80.
thanks,
-Steve
On the CALL either specify "OMITTED" for each parameter to omit, or
where its omission is obvious as either the latter parameter(s) or the
only parameter, just omit naming a parameter. See "By phrase" portion
of the syntax diagram found later in the "CALL Statement - Format 2" for
the documentation; with "Notes: IBM Extension" indicated:
http://publib.boulder.ibm.com/infocenter/systems/topic/rzasb/sc092539547.htm
FWiW CEEHDLR CEEDATE CEEDAYS examples are likely to show omitted
parameters. For example:
http://publib.boulder.ibm.com/infocenter/systems/topic/apiref/apiexusdata.htm
thread: http://archive.midrange.com/cobol400-l/200110/msg00038.html
In SPECIAL NAMES specifying LINKAGE TYPE of PROCEDURE with "USING ALL
DESCRIBED" establishes Operational Descriptor such that sufficient
information exists to determine the detail of the parameters passed and
omitted on the procedure call. See also CEETSTA API, and "ADDRESS OF"
compares to NULL for testing in a procedure if a parameter was omitted:
http://publib.boulder.ibm.com/infocenter/systems/topic/rzasb/sc092539551.htm
thread: http://archive.midrange.com/cobol400-l/200011/msg00014.html
Regards, Chuck
If I understand correctly, you're saying that Steve could handle an
omitted final parameter by coding either this
call linkage type is procedure "cp800_PrintLog_cp800mstrp"
using by reference minc, OMITTED.
or this
call linkage type is procedure "cp800_PrintLog_cp800mstrp"
using by reference minc.
It's not correct to code the second way. Usually, you can't simply
leave off the omissible parameters. This is always true for APIs with
omissible parameters. (The only time you _can_ leave them off is when
there is another way for the called procedure to know how many
parameters were passed, _and_ the called procedure does actually figure
out how many parameters were passed.)
The APIs with omissible parameters assume that all the parameters are
always passed. If an API has three parameters, and only two are passed,
and a pointer happens to be hanging around on the stack where the API
expects to find the third parameter, the API will assume the parameter
was indeed passed and use or update whatever storage the pointer happens
to point to.
When omissible parameters are just left off, sometimes it happens that
the error goes undetected for years, with the API always getting a null
pointer at the unpassed parameter. And then something changes in the
environment (program called from a different menu, recompile, system
PTF, new release etc) that causes a non-null pointer to be there. This
can lead to subtle and hard-to-find bugs.
<code>
Declare Parm3Pos Type(Integer) value(3);
If %parms()>=Parm3Pos & Parm3Addr<>NULL
then do; /* Parm3 was passed */
Parm3LclAddr=Parm3Addr; /* Addr stg of caller */
end;
else do; /* Parm3 was not passed */
Parm3LclAddr=%addr(Parm3Dft); /* Addr stg of Parm3 defaults */
end;
</code>
Regards, Chuck
that worked. thanks.