Re: creating a command with a return value

On 15-Nov-2013 11:29 -0800, rob@xxxxxxxxx wrote:

CRPence on 11/15/2013 02:07 PM wrote:

On 15-Nov-2013 04:45 -0800, rob@xxxxxxxxx wrote:

I once submitted a DCR that IBM include TGTRLS in an H spec when
compiling RPG. They shot it down as once it gets to that level of
the compiler it can't back out and restart. I think that might be
some similar argument in CRTCMD.

I could see that as a conspicuous issue for Target Release
specification, because that actually directs the CPP
*which compiler* gets invoked.

That the Command-object /compiler/ diagnoses the condition with
CPD0281, seems to suggest that the compiler has access to the
list of specified ALLOW() values [passed by the CPP] for further
validation, and thus should be able to be [re]designed to modify
that list when effecting the actual creation of the *CMD object.

But that's after it's already inside the code. Using your logic
wouldn't the need for CRTSQLRPGI be unnecessary since the mere
presence of SQL within the source should be enough? No need to
differentiate the source member types?

I do not understand the implication about my logic. In my estimation, it was your logic that implied the source could be used to decide which compiler to invoke. So let me try again...

With regard to Target Release, I am alluding to processing by the CPP for the CRTxxx *before* the compiler ever gets invoked. The CPP is not [necessarily] the compiler. If I invoke CRTxxx TGTRLS(*PRV), the CPP translates the special value /previous/ into the specific V#R#M#, and then invokes the compiler from that release; in effect, but not necessarily the implementation, the product compiler code from a previous-release that was installed\restored into a library LPP_V#R#M# gets invoked instead of the current-release compiler in the library LPP.

Thus the decision about what the target release is, must be fully resolved\known before the compiler gets called, before the compiler had even opened the source. The compiler need not and likely does not know what the TGTRLS() specification was... because the compiler that was invoked, is the compiler specific to that earliest release. To enable an H-spec for TGTRLS, the CPP would have to open the source and review for that H-spec to decide which compiler; something the CPP does not do, if it is not also the compiler. Or the invoked compiler would have to feedback to the CPP, that a wrong compiler was invoked, and that the CPP should recover by invoking the correct compiler; having read the H-spec to learn this, it could even feedback what the /correct/ compiler would be.

With the CRTCMD compiler however, the Allowed environments in which a command can be invoked is being passed from the CPP into the compiler [or the CPP may even be the compiler], conspicuously obvious because the compiler issues a diagnostic about the ALLOW value(s) that conflict with RTNVAL specification(s). Thus I am suggesting that, given the CMD compiler obviously has the necessary information, information that it currently even validity checks, the compiler could directly use that information to effect the creation of the command according to what reflects a more logical definition, rather than being so dogmatic in enforcing the restriction.