Re: CPYSRCF problem at V7R3

Hi, Rob,
Thanks for testing this.
The story gets even more convoluted -- at the client site, they somehow
found they had a data area named QSYS/QCPYSRCCHGD defined as a one byte
*CHAR data area containing a blank. When this data area is found on the
system, the CPYSRCF command ignores the value specified for
SRCCHGDATE(*FROMMBR) and always behaves as it did before there was a
SRCCHGDATE parameter, e.g. SRCCHGDATE(*NEW).
Removing or renaming this data area resolves the issue.
And, here is an old thread on this very list where some of us even
discussed this issue:
https://archive.midrange.com/midrange-l/201504/msg00016.html

I knew this issue seemed somehow vaguely familiar.
Just posting this information here, for the archives and for posterity.
All the best,
Mark S. Waterbury
On Friday, April 12, 2024 at 12:09:11 PM EDT, Rob Berendt <
robertowenberendt@xxxxxxxxx> wrote:

Not seeing that issue on 7.5.
File . . . . . . QCLSRC
Library . . . . QTEMP
Opt Member Date
AMGRSPIKE 12/26/02

Group ptfs updated 2024-03-04

"PTF_GROUP_CURRENCY","PTF_GROUP_ID","PTF_GROUP_TITLE","PTF_GROUP_LEVEL_INSTALLED","PTF_GROUP_LEVEL_AVAILABLE","LAST_UPDATED_BY_IBM","PTF_GROUP_RELEASE","PTF_GROUP_STATUS_ON_SYSTEM","PTF_GROUP_LAST_UPDATED_BY_IBM"
"UPDATE AVAILABLE","SF99958","SF99958 750 Group
Security",27,29,"2024-03-21","R750","INSTALLED","03/21/2024"
"UPDATE AVAILABLE","SF99959","SF99959 750 Group
Hiper",48,50,"2024-03-21","R750","INSTALLED","03/21/2024"
"UPDATE AVAILABLE","SF99679","SF99679 750 IBM MQ for IBM i -
v9.2.0/v9.3.0",13,14,"2024-03-08","R750","NOT APPLICABLE","03/08/2024"
"UPDATE AVAILABLE","SF99950","SF99950 750 DB2 for IBM
i",5,6,"2024-03-11","R750","INSTALLED","03/11/2024"
"UPDATE AVAILABLE","SF99953","SF99953 750 Performance
Tools",3,4,"2024-04-10","R750","INSTALLED","04/10/2024"
"UPDATE AVAILABLE","SF99954","SF99954 750 Backup Recovery
Solutions",11,12,"2024-04-02","R750","INSTALLED","04/02/2024"
"","SF99669","SF99669 750 Content Manager OnDemand for i - 5770-RD1
7.5",6,6,"2023-08-25","R750","RELATED GROUP","08/25/2023"
"INSTALLED LEVEL IS CURRENT","SF99671","SF99671 750 Db2 Web Query for i
V2.3.0",9,9,"2023-07-19","R750","INSTALLED","07/19/2023"
"INSTALLED LEVEL IS CURRENT","SF99673","SF99673 750 Db2 Web Query for i
V2.4.0",3,3,"2023-11-17","R750","INSTALLED","11/17/2023"
"INSTALLED LEVEL IS CURRENT","SF99676","SF99676 750 High Availability for
IBM i",7,7,"2024-01-19","R750","INSTALLED","01/19/2024"
"INSTALLED LEVEL IS CURRENT","SF99677","SF99677 750 750 TCP/IP
PTF",4,4,"2023-11-27","R750","INSTALLED","11/27/2023"
"INSTALLED LEVEL IS CURRENT","SF99750","Current Cumulative PTF Media
Documentation",23306,23306,"2023-11-16","R750","INSTALLED","11/16/2023"
"INSTALLED LEVEL IS CURRENT","SF99751","SF99751 750 All PTF Groups except
Cumulative PTF Package &
MQ",5,5,"2024-01-05","R750","INSTALLED","01/05/2024"
"INSTALLED LEVEL IS CURRENT","SF99951","SF99951 750 IBM Db2 Mirror for
i",5,5,"2023-11-15","R750","INSTALLED","11/15/2023"
"INSTALLED LEVEL IS CURRENT","SF99952","SF99952 750 IBM HTTP Server for
i",14,14,"2024-03-26","R750","INSTALLED","03/26/2024"
"INSTALLED LEVEL IS CURRENT","SF99955","SF99955 750
Java",9,9,"2024-03-19","R750","INSTALLED","03/19/2024"
"INSTALLED LEVEL IS CURRENT","SF99956","SF99956 750 Technology Refresh plus
Recommended Groups",1,1,"2022-12-01","R750","INSTALLED","12/01/2022"
"INSTALLED LEVEL IS CURRENT","SF99957","SF99957 750 Technology
Refresh",3,3,"2023-11-16","R750","INSTALLED","11/16/2023"

On Fri, Apr 12, 2024 at 11:34 AM Mark Waterbury <
mark.s.waterbury@xxxxxxxxxxxxx> wrote:

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.

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


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