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