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

Dan:

I just ran a quick test on a V7R1 TR7 system, and when I created a data area QSYS/QCPSRCCHGD type *CHAR length 1 value blank, this had the effect you describe -- it overrides the behavior of CPYSRCF even when you specify SRCCHGDATE(*FROMMBR).

This certainly seems to be a defect, probably due to some old code that is still checking for that data area, from that "circumvention" that was put in place before there was a SRCCHGDATE parameter on the CPYSRCF command. I suggest you open a PMR (support incident) to report this to IBM, as it probably should be corrected.

Also, you can either delete or rename that data area QCPSRCCHGD in QSYS and that should resolve this issue for you.

HTH,

Mark S. Waterbury

> On 4/1/2015 11:04 AM, Dan wrote:

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