Re: PDM or CPYSRCF new member has old date - Bug or Feature ?

> Rob Berendt 'said' on 7/12/05
>       Now, if you knew the affected object(s) by this new ptf, you could
do the same. 
>         Then on the affected machine do 
>                DSPOBJD OBJ(xxxxxxxx) OBJTYPE(*PGM) DETAIL(*SERVICE)
>       and see if you have ptf SI17661 on it.
>           See if the working machines have the same, a different ptf, or
no ptf on it.


>From Dave Pate:

>From the Job Log below, the affected objects are:

        QDBFFCPY        QDBFFEXT        QDBSSUDF


Our software vendor just today asked us to apply this PTF.

After applying the PTF both the create and change date are the same for a
member replaced by a copy
The source member copy (opt 3) deleted the member and re-added it.
It seems it would be better if the OS changed the create date to today's
date but 
Left the change date as the date the object was actually changed via the
editor.
This way you know when the statements were actually changed not just copied

So it seems there are 3 ways to look at this. (There are 3 kinds of people
in the world: Those that can count and those that can't)

1. Original way - both dates are persevered from the member being copied
2. PTF SI17661 way - member is deleted and recreated and both dates have
today's date
3. What would be helpful is where the create date is today but the change
date is preserved from the copied member


Any thoughts: So is this an optional PTF or is this really fixing a bug ?



Job results of applying PTF

LODPTF LICPGM(5722SS1) SELECT(SI17661) 
Superseded PTFs were applied. 
Object QPZA009709 in QSYS type *PGM moved to library QRPLOBJ. 
Object QPZA009709 in QRPLOBJ type *PGM renamed QSI1584101. 
Object QPZA009710 in QSYS type *SRVPGM moved to library QRPLOBJ.
Object QPZA009710 in QRPLOBJ type *SRVPGM renamed QSI1584102. 
PTF 5722SS1-SI15841 V5R3M0 permanently applied to library QSYS. 
Superseded PTFs were applied. 
Object QDBFFCPY in QSRV type *PGM renamed QPZR011367. 
Object QPZR011367 in QSRV type *PGM moved to library QSYS. 
Object QDBFFEXT in QSRV type *PGM renamed QPZR011368. 
Object QPZR011368 in QSRV type *PGM moved to library QSYS. 
Object QDBSSUDF in QSRV type *SRVPGM renamed QPZR011369. 
Object QPZR011369 in QSRV type *SRVPGM moved to library QSYS. 
PTF 5722SS1-SI17661 V5R3M0 loaded into library QSYS. 
Library QSRV cleared. 
APYPTF LICPGM(5722SS1) SELECT(SI17661) DELAYED(*NO) 
Ownership of object QPZR011367 in QSYS type *PGM changed. 
Primary group of object QPZR011367 in QSYS type *PGM changed. 
Ownership of object QPZR011368 in QSYS type *PGM changed. 
Primary group of object QPZR011368 in QSYS type *PGM changed. 
Ownership of object QPZR011369 in QSYS type *SRVPGM changed. 
Primary group of object QPZR011369 in QSYS type *SRVPGM changed. 
Object QDBFFCPY in QSYS type *PGM renamed QPZA011367. 
Object QPZR011367 in QSYS type *PGM renamed QDBFFCPY. 
Object QDBFFEXT in QSYS type *PGM renamed QPZA011368. 
Object QPZR011368 in QSYS type *PGM renamed QDBFFEXT. 
Object QDBSSUDF in QSYS type *SRVPGM renamed QPZA011369. 
Object QPZR011369 in QSYS type *SRVPGM renamed QDBSSUDF. 
PTF 5722SS1-SI17661 V5R3M0 temporarily applied to library QSYS. 



Dave Pate
SC DDS - Information Technology
(803) 896-6061
Dave.Pate@xxxxxxx <mailto:Dave.Pate@xxxxxxx> 



PDM or CPYSRCF new member has old date

- <javascript:void(0);>         *       From: Neil Palmer
<neilpalmer400mr@xxxxxxxx> 
*       Date: Mon, 11 Jul 2005 21:00:20 -0400 (EDT)     
 <<...OLE_Obj...>> 
OK - we have a customer with V5R3.  When you use PDM
to copy a source member, the new member should have
the current date (the date you created it), yet it has
the date of the member you copied.  Works the same
(wrong) way with the CPYSRCF command.

Now, I did see PTF SI17661 (released 2005/05/05 and
not yet on any PTF cumulative package) that addresses
this problem.  Here's the strange part.  We have other
V5R3 customers, WITHOUT PTF SI17661, that do not
exhibit this problem.  Also, APAR SE19615 shows
there's also a V5R2 PTF for this same problem
(SI17660):
http://www-912.ibm.com/n_dir/nas4apar.nsf/c79815e083182fec862564c00079d117/3
4315b64034910e386256fc70042aac2
<http://www-912.ibm.com/n_dir/nas4apar.nsf/c79815e083182fec862564c00079d117/
34315b64034910e386256fc70042aac2> 

SO - obviously there are MANY systems out there without
a PTF for APAR SE19615 that are not exhibiting this
problem.  So does anyone have a clue what causes it,
or under what conditions this problem occurs, and what
other PTF(s) may have fixed this problem?


Neil Palmer, Cambridge, Ontario, Canada
(This account not monitored for personal mail,
remove the last two letters before @ for that)

****************************************************************************
********************

Re: PDM or CPYSRCF new member has old date

- <javascript:void(0);>         *       From: rob@xxxxxxxxx 
*       Date: Tue, 12 Jul 2005 09:33:15 -0500   
 <<...OLE_Obj...>> 
Could be any number of things.  For example, on an unrelated object, if I 
do
DSPOBJD OBJ(QCMDEXC) OBJTYPE(*PGM) DETAIL(*SERVICE)
I'll see:
PTF number . . . . . . . . . . . . . :   SI15146

Now, if you knew the affected object(s) by this new ptf, you could do the 
same.  Then on the affected machine do the DSPOBJD thingy and see if you 
have a ptf on it.  See if the working machines have the same, a different 
ptf, or no ptf on it.

In summary, you may be at different ptf levels on the machines.  One ptf 
may be in error and causing you grief.  Or, it may be a ptf that causes 
things to work the way you are and some people may have wanted it that 
way.  Just like the ptf to change DSPJOB OPTION(*OPNF) to not default to 
showing you the activation group first.  A ptf that will never make it to 
a cume.

Rob Berendt