Re: Where is CHGCMDDFT data stored? -- MIDRANGE-L

Vern,

I think that's an important capability to have. It should be included as part of an API.

-mark

At 2/11/2011 07:43 PM, you wrote:

I like the idea of a DCR for this, because it'd be useful in documenting
customer changes to commands in our products, say. That would help with
upgrades - I've ended up doing the XML output as I build a product and
distributing it with the product, then comparing when doing an upgrade.
I'll probably put in a requirement through my ISV channels - someone
else could submit a COMMON requirement or a DCR through the regular
process. If anyone else cares, that is! But this would be a way to keep
user changes even after and update of the operating system.

I don't believe there is a history - only the original default value and
whatever it is now, if changed.

Regards
Vern

On 2/11/2011 5:46 PM, CRPence wrote:
> I was thinking maybe the original and changed default were present in
> the *CMD object, and thus why I thought maybe that information could
> appear as some detail in the XML output; not as a history though. I
> figure that the current parameter default would be extracted and be
> included as detail in the XML output, so if the original parameter
> default is also available [and different than the current], then why not
> include that detail in the XML output so as to document that original
> parameter default? I would think a better approach than parsing each MI
> *CMD space object [internals] might be to ask in a DCR, that IBM make an
> enhancement to include the original parameter default information [if
> since-changed to have a new parameter default] in the XML output.?
>
> Regards, Chuck
>
> On 2/11/11 3:28 PM, Vern Hamberg wrote:
>> That API does not present any history - it shows only the current
>> defaults, if present. I seem to recall that a DMPOBJ might have the
>> value - yes, just ran a test.
>>
>> If you DMPOBJ on a command, the default values are presented together
>> at an offset I didn't take time to work out. Then I ran CHGCMDDFT -
>> the original defaults are all in the same place, with a 2-byte length
>> before each value - the change is at another location.
>>
>> I assume there's a template somewhere for this - could it be made
>> public? The MI list members may know.
>>
>> On 2/11/2011 3:32 PM, CRPence wrote:
>>> On 2/11/11 9:41 AM, Mike Wills wrote:
>>>> Like an idiot, I forgot to keep track of some key CHGCMDDFT
>>>> commands when I created them. How do I go back and look those up
>>>> so we can make sure they are there after we upgrade the system? I
>>>> know I have seen how to do this in the past. Google didn't turn
>>>> anything up for me. I'll add this to the Wiki when I get the
>>>> answer.
>>>>
>>> I've not used the feature to extract a command definition as XML,
>>> but that may provide information describing what specific
>>> default(s) were changed; i.e. beyond knowing only that at least one
>>> command parameter default was changed on the command according to
>>> the 'CHGDFT' value in the ODAPAR field of the DSPOBJD output file
>>> for that command object.?