RE: RE: creating a new procedure thatcallanexistingprocedurewithoneadditional parm

Not wanting to flog a dead thread, but...
 
Using the example:
 
MyProc(parm1:*omit);
MyProc(parm1);

If your procedure only has 2 parameters, there's NO good reason you would 
specify the second parameter as omittable anyway!
 
Omittable parameters are only really of any use as 'placeholders', where you 
may want to omit certain parameters in the middle of a *PLIST (e.g. pass 
parameters parm1 and parm3, but not parm2). In that case, defining parm2 as 
omittable (and adding code to your procedure to cater for this, obviously) is 
necessary.
 
But if you'll only ever pass parm1 OR parm1 and parm2 OR parm1 and parm2 and 
parm3, then making any of the parameters omittable is pointless - just make 
then *NOPASS and use %parms.
 
A good technique is to design your interfaces so you never need to use 
omittable parameters (but then I was using V4R5 until recently, so had to use 
CEETSTA rather than checking for %addr...). In my experience, it's rare that 
you NEED to have an omittable parameter.
 
MOST (but not all, I hasten to add) procedures can be defined with required 
parameters first and then everything else as *NOPASS. Hell, in some cases, I've 
designed a 'real' procedure which does some actual work and multiple 'wrapper' 
procedures which accept fewer parameters, and which pass dummy parameters to 
the real procedure. No-one ever explicitly calls the real procedure (which is 
never exported anyway), only the wrappers. If I change the real procedure 
parameters, I can change the internals of the wrappers, or add new ones. It's 
an alternative to using omittable parameters and I think it's cleaner...
 
Just my $0.02...
 
Rory