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

On 31-Mar-2015 14:55 -0500, Dan wrote:

On 31-Mar-2015 13:58 -0500, Dan wrote:

Since starting in this new shop a few months ago, I found that
copying a source member from one source file to another results in
the member's Change date and time (observable via WRKMBRPDM option
8 "Display Member Description") to be set to current system date
and time, so that it matches the Creation date and time. In my
previous shop, also at v7.1, doing this would result in the copied
source member keeping the same Change date and time as the
original.

Is this a configurable thing? A PTF? I've found it to be useful to
have copied source members retain the Change date and time from
the original member.

That has been the effect since some PTF level on v5r3 and on v5r4, and since the OS base-release for IBM i 6.1 (v6r1).

I just prompted the CPYSRCF command using option 3 in WRKMBRPDM and
F4=Prompt, and the SRCCHGDATE parameter defaults to *FROMMBR.

I just tested by explicitly specifying SRCCHGDATE(*FROMMBR) in the
command, and the copied member's Change date and time has the same
as when it was created.

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.

The capability of CpySrcF to carry the Source Change Date (SRCCHGDATE) information to the To Member (TOMBR) from the From Member (FROMMBR) is limited to when either the Member Option (MBROPT) specifies *REPLACE or when the *ADD specification on that parameter effects creation of the named TOMBR; i.e. if the TOMBR already exists and the MBROPT(*ADD) was specified, then the effect will be the same as if SRCCHGDATE(*NEW) had been specified.

PTF?

Nothing conspicuous. The latest code probably should come with SI52642 and SI52733 on C4283710; as inferred from mention of the Copy Source File (CPYSRCF) command mentioned on superseded PTF SI41371, and QDBCLOSE mentioned on superseded PTF SI39951.

I did find, that in the older releases where the default behavior changed [so unsure if the code became part of new releases], a data area implementation allowed overriding the new default to force reverting to the old behavior. The existence of a data area [no mention of authority requirements] QCPSRCCHGD in QSYS may cause the feature to operate incorrectly; that surely would be a defect on any release where the SRCCHGDATE parameter is available. Oddly, there is a mention of the DtaAra support in a PTF IBM i 6.1 [R610 SI32155 for SE34017 written in apparent Chenglish, so impossible to infer what the PTF provides], so maybe the code was [incorrectly] copied there... which could mean the same incorrect code might also be in IBM i 7.1 such that the existence of the Data Area could vitiate the requested behavior.? I do not have any /newer/ releases on which to test the effects with that data area being present.