×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
I would debate with Rory Hewitt on using a "variant" for the third parm.
This is a common trap for expediency, but by not calling what something
really is - You are not encapsulating logic, but confounding it - you
are not using prototypes as they were intended - and you are leaving
confusion behind for the next maintenance programmer to understand.
If you end up cramming a numeric into an alpha field, is it left
justified, right justified ?
Within our programs, we are trying to write re-usable code, so are you
going to put the SELECT statement inside a /COPYBOOK - or inside another
procedure? You may even end up with a SELECT to load the field into the
interface, and then a SELECT to strip it out of the interface in the
receiving program.
It would just be better to just pass 4 blank fields and the one defined
field with a value and forget about using *OMIT than to confuse the
interface logic with a variant.
-==========================-
If you're only going to pass one of the last 5 parms, why not simply
have 4 required parms:
P S#CHKUSR B Export
D S#CHKUSR PI N
D UserProfile 10A
D AppSys 5A
D IDFld 1A
D IDType 1A
and have a SELECT in there to say e.g.
when IDType = 'E';
EcisSSN = IDFld; // IDFld is EcisSSN
when IDType = 'T';
ThrdSsn = IDFld; // IDFld is ThrdSsn
...
and you'd call it as:
C eval retfield = S#chkusr(USR:DEPT:F1:'E'); // 3rd parm
is EcisSsn
C eval retfield = S#chkusr(USR:DEPT:F1:'B'); //3rd parm is
BnkID
As an Amazon Associate we earn from qualifying purchases.