Re: Checking for missing parameters in CL -- MIDRANGE-L

Subject: Re: Checking for missing parameters in CL
From: Barbara Morris <bmorris@xxxxxxxxxx>
Date: Wed, 31 Jan 2018 17:32:57 -0500
List-archive: <https://archive.midrange.com/midrange-l/>
List-help: <mailto:midrange-l-request@midrange.com?subject=help>
List-id: Midrange Systems Technical Discussion <midrange-l.midrange.com>
List-post: <mailto:midrange-l@midrange.com>
List-subscribe: <https://lists.midrange.com/mailman/listinfo/midrange-l>, <mailto:midrange-l-request@midrange.com?subject=subscribe>
List-unsubscribe: <https://lists.midrange.com/mailman/options/midrange-l>, <mailto:midrange-l-request@midrange.com?subject=unsubscribe>

On 2018-01-31 12:14 PM, Tyler, Matt wrote:

We were told that MCH3601 was not as reliable as using CEETSTA API
... I think MCH3601 works well if you document that you never intend to have *NULL as a valid value passed to a param.

For a bound call, it's not safe to rely on MCH3601 to detect unpassed parameters. If there happens to be a pointer on the parameter stack from some previous call, your procedure wouldn't get an error if it tried to access the unpassed parameter. Testing %addr wouldn't be reliable either.

I think it's ok for a program call because (I assume, but don't know for sure), that the ILE CL program-entry-procedure initializes all the parameter pointers to either null or the address of the passed parameter before it calls the procedure.

As an Amazon Associate we earn from qualifying purchases.

This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.