Re: Quick question about CRTBNDRPG defaults under V7

On 16 Oct 2013 09:04, James H. H. Lampert wrote:

On 10/16/13 8:50 AM, CRPence wrote:

A DSPOBJD of the *CMD object will reveal if that command's
defaults were changed since being created; i.e. the "APAR ID"
information [OutFile field ODAPAR] will show the value "CHGDFT"
to indicate that effect.

Hmm. And yet a private reply I got last night says that the
defaults I'm seeing are not the factory ones, but I don't see the
telltale sign you described.

A couple of replies already have stated effectively, that, which command is reviewed with DSPOBJD must be /the command/ that exposed the unexpected defaults; i.e. the specific *CMD command object, that when prompted, showed the changed defaults.

FWiW I failed to mention that beyond the "APAR ID" (ODAPAR) field having the value 'CHGDFT', the "User Modified" (ODUMOD) field should also indicate that the command object was changed; i.e. together they indicate that the CHGCMDDFT was performed against that *CMD object to modify a parameter default [sometime since the command was created; something that no IBM code should effect].

Of course *how* the apparent defaults were exposed\verified is very relevant. If for example, the determination of the /defaults/ was *not* by having prompted the command, then the inference of how the effect of ACTGRP(*CALLER) STGMDL(*INHERIT) was achieved in the OP scenario, might be misunderstood.

For example, the following prompted request could possibly _subtly_ make the apparent /defaults/ _appear to be_ the value specified for the respective parameter in the command string, but would not necessarily be the /parameter default/ for that parameter in the *CMD object being prompted; i.e. only the greater-than symbol [either between the prompt text and the input field, or between the parameter name and the input field] provides a visible indication that the value had been specified vs had been defaulted:

?crtbndrpg ??dftactgrp(*no) ??actgrp(*caller) stgmdl(*inherit)