Re: pre process command

On 30-Mar-2015 12:04 -0500, Karl Abbott wrote:

<<SNIP>> Using QIBM_QCA_CHG_COMMAND won't work for me because I
don't want to change the existing CRTDUPOBJ command at all.
<<SNIP>>

That is overly dismissive IMO; the exits could be used for the described scenario whereby an alternate command [name] is used. The Command Exit features could be implemented against the private version of the command, operating only against the custom command name. From the given example, that command name was CRTDUP; though I had suggested an alternate name such as DUPPFXTND. That usage of Exits against the custom command name would be irrespective the custom command being created as a duplicate of the system-supplied command [as unchanged or as modified to use a custom CPP] or the custom command being created from source [and perhaps being only somewhat similar to system command CRTDUPOBJ]. So, the Command Exits could be put to use and function in the described scenario; that is not a recommendation to do so, merely to clarify that they are not so easily dismissed as being incapable in the proposed context. That possibility to effect the intercepts of the custom command name via Exit Programs would enable using a _duplicate_ of the system-command while avoiding creation of a custom CPP. The additional work would be performed in\by the User Exit programs rather than within a CPP, and that work would be accomplished by invoking the original\unchanged and non-intercepted CRTDUPOBJ command.

However my recommendation instead was to create both a custom command and CPP, *not* to use the Exits; notably, that a custom command should probably drop the OBJTYPE parameter and narrow the scope of the FROMOBJ parameter possibly to a Physical File name such that perhaps also renaming that parameter to FROMPF so as to reflect that limitation [and possibly even making the parameter a qualified name so as to eliminate the separate FROMLIB parameter]. The idea being, that the custom command conspicuously would not serve as a replacement for CRTDUPOBJ, much as was hinted-at by the stated intent not "to change the existing CRTDUPOBJ command at all." Essentially I was suggesting, if a new command [name] and new effect(s) are desired, then why not just create both a new command object [specific to the task] and a new CPP program object for that new command.? To have any users potentially prompting a custom CRTDUP command that was created as a duplicate of CRTDUPOBJ command [even if those users are only programmers that would ever /see/ the command], is probably undesirable; the duplicate command would have the same prompt-text and help-text as the original CRTDUPOBJ command, yet the alternate\custom command [per the described intention] would operate quite differently than the system-command [as well as differently than what the Help suggests], and that could be problematic.

My course of action now will be to parse all of the incoming
parameters and put them into a QCMDEXC call to execute CRTDUPOBJ.

Yet if a decision was that a new CPP would be created for that custom command [despite the provenance of the *CMD object naming that CPP], which as noted just above is apparently the decision, then the additional work more sensibly would be performed in\by that CPP; the concept of using intercepts via Command Exits [pre and\or post] would be debased. Thus dismissing use of those Exits is quite sensible, because the obvious better choice for the additional work is clearly the custom CPP. Do consider however, also creating a custom command from source rather than /borrowing/ the existing command [by making and using a duplicate].