MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » January 2013

Re: USRPRF parm changed on CRTCLPGM



fixed

On 24 Jan 2013 08:39, Gqcy wrote:
SECOND TIME IN A YEAR THIS HAS HAPPENED!?!?

we run USRPRF(*OWNER) here.

we change all the CRT* commands to USRPRF(*OWNER) at upgrade time.

last week we noticed that the default changed back to (*USER).
Only on the CRTCLPGM command (the other commands are still (*OWNER)).

The following comments are only to stimulate ideas; i.e. not intended to explain what transpired... even if they might help in that regard. And any questions are to be viewed as being one's own rather than as my having asked... I desire no response.

Is it known or only presumed which copy of CRTCLPGM was being used. There may have been others, and may still be others. PDM I believe uses *NLVLIBL/CRTCLPGM for option-14 and command-line invocations that are unqualified use *LIBL/CRTCLPGM. And unqualified names on the CMD() specification of the CHGCMDDFT uses *LIBL.

I looked at the object description of the command, and it shows a
last change date of June, 2012 (when I last had this trouble...)

The APAR ID in the service attributes? This would be relevant only if recalled from that specific DSPOBJD, or could be found in a spooled copy that remains from prior to the most recent change.

I changed the command default again this morning, and now the object
description shows today as the last change date.

After a new CHGCMDDFT the APAR ID should now show CHGDFT. Other DSPOBJD CRTCLPGM information like the restore date\time and all of the Creation information might be of interest beyond just the Change date; IIRC however, a restore would have also updated the change date... just as would a move or a rename.

I would collect and store a copy of DMPOBJ of the CRTCLPGM command that has been changed [as noted in the above quoted text]; for easier viewing, also a copy of both *SERVICE and *FULL object description for that same object. These can be compared to the same doc collections taken if\when the problem happens again.

this happened in the middle of the month, no PTF activity.

Was the prior change to the command default made using *LIBL as name qualifier, and that was a copy that was previously in a library before QSYS that was being used, and so perhaps a DLTCMD had effected the change? Or a command exit point was implemented and since removed?

I tried to look at the audit log, but I don't see anything useful.

May be worth issuing CHGOBJAUD CRTCLPGM *CMD *ALL to ensure explicit changes [i.e. not corruption of the object] are logged [if object auditing is enabled]. Unless that had been active, I do not expect much would have turned up in a review of the auditing.?

Doubtful an issue, but a review of the STRSST D/A/D "Alter Log" could rule out a storage alteration.






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot 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 here. If you have questions about this, please contact