Re: Change date & time for source member copied to a new file

CRPence <CRPbottle@xxxxxxxxx> wrote:

So that implies [again, as in the OP] the "Change date" and "Change time"

values that are presented with PDM option-8="Display description" [thus the
"Display Member Description" panel]?

Unfortunately the PDM does not explicitly state "Source Change Date" and

"Source Change Time", despite those are what the PDM shows for PF-SRC
members; there are "Change Date" and "Change Time" attributes that are
tracked separately for the Member (*MEM) object, and those values may be
presented with other interfaces. The Display File Description (DSPFD) for
TYPE(*MBR) Type of information, for example, provides both Last Change
Date/Time information and Last Source Update Date/Time information.

You implied correctly. However, I just now did DSPFD and it reports the
members' last change date and time the same as does PDM's option 8.

I always use *REPLACE when copying members. Obviously, I would expect the
behavior you described if I were *ADDing records to an existing member.

Both SI52642 and SI52733 are applied here. QSYS/QCPSRCCHGD data area has a
value of blank (x'40'). DSPOBJD on this object showed "Days used count" to
be zero before I did DSPDTAARA on it, so I don't know if that means that it
is *never* used, or if "usage" isn't updated when system applications use
it.

From the cover letter for both of the aforementioned PTFs, it appears that

it is the mere presence of the QSYS/QCPSRCCHGD data area forces the copied
member's change date/time to be set to the current date/time. Was this
prior to when the SRCCHGDATE parameter was implemented in CPYSRCF?



*APAR Error Description / Circumvention *
-----------------------------------------------
CPYSRCF with SI29538 + dtaara QSYS/QCPSRCCHGD don't update the
new created members to the current date/time

CORRECTION FOR APAR SE34017 :
-----------------------------
The data area will be check in the code to ensure we honor the
CPYSRCF if the data area is present.

- Dan