|
All,
I recently encountered a problem at a customer site that could also cause
problems for other sites, so I want to ask if anyone else has seen this
issue on V7R3 (or on V7R4 or V7R5).
The CPYSRCF command has the parameter:
SRCCHGDATE(*FROMMBR)
Source change date . . . . . . . SRCCHGDATE *FROMMBR
the default *FROMMBR specifies to copy the source member, and retain the
source last changed date of the "From" member.
But, on at least one of my client's systems, this does NOT work.
The CPYSRCF command is behaving as if SRCCHGDATE(*NEW) was specified.
But it is not specified.
I have tested this with this customer, and even when we "hard-code"
SRCCHGDATE(*FROMMBR), it still stamps the copied member with the current
date/time when the CPYSRCF ran.
This causes trouble for change management tools that verify the integrity
of compiled objects by checking to ensure that the compiled object source
member last changed date/time stamp "matches" the actual date/time stamp of
the corresponding source physical file member.
You can quickly test this by creating a file in QTEMP, e.g.:
CRTSRCPF QTEMP/QCLSRC
Then WRKMBRPDM QGPL/QCLSRC (or any QCLSRC file), and then press F14 to
see the member dates, or type an "8" next to a member to see the "last
changed" date for the member. (This is the date updated by SEU or RDi etc.
when you edit the source member.)
Then, prompt the CPYSRCF command as shown below:
CPYSRCF FROMFILE(QGPL/QCLSRC) +
TOFILE(QTEMP/QCLSRC) +
FROMMBR(QSTRUP) +
SRCCHGDATE(*FROMMBR)
Press enter to perform the copy.
Then, issue WRKMBRPDM QTEMP/QCLSRC and type an "8" next to the member.
You should see something like this (for example):
Member . . . . . . . . : QSTRUP
File . . . . . . . . . : QCLSRC
Library . . . . . . . : QTEMP
Member type . . . . . . : CLP
Creation date . . . . . : 04/12/24
Creation time . . . . . : 11:05:27
Change date . . . . . . : 03/07/14
Change time . . . . . . : 15:52:27
If you have this particular issue, you will see, e.g.:
Member . . . . . . . . : QSTRUP
File . . . . . . . . . : QCLSRC
Library . . . . . . . : QTEMP
Member type . . . . . . : CLP
Creation date . . . . . : 04/12/24
Creation time . . . . . : 11:05:27
Change date . . . . . . : 04/12/24 <---<<<
Change time . . . . . . : 11:05:27 <---<<<
I suspect some "PTF in error" that is relatively recent, because I do not
see this issue on my "test" V7R3 system, but on the client system, they
have a few group PTFs that are slightly newer than what our "Test" system
currently has.
Please reply, either on-list, or privately, to let me know if anyone else
is seeing this issue.
(I cannot open a "case" for this with IBM because it is not happening on
my system.)
Thanks in advance.
All the best,
Mark S. Waterbury
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
