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)
midrange.com
