× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.?


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.