MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » February 2014

RE: Checking object create dates



fixed

Rob,

I did one more test.
Save prtf to savf
Restore object from savf to another library
File level identifiers are the same.

Maybe under the covers this is what CRTDUPOBJ should do.
Then you truly have a duplicate object, everything remains equal, create date, created by, etc

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Steinmetz, Paul
Sent: Thursday, February 13, 2014 6:06 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Checking object create dates

Rob,

Good point.
Prtf identifiers could be the same, but the prtf have different attributes.

I just did some tests.
1) CRTDUPOBJ of prtf creates a new file level identifier.
2) Restore of a prtf from a different system keeps the same file level identifier.
3) Changing the attribute of a prtf does NOT change the file level identifier.

I'm not seeing a solution.


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Thursday, February 13, 2014 4:31 PM
To: Midrange Systems Technical Discussion
Subject: RE: Checking object create dates

What value would change of the format level id if you ran a CHGPRTF PAGESIZE(67)? Probably none. Is it important to catch that? Or related changes? HOLD(*YES)? Would the users care if you rolled out a new version and clobbered all of those settings?


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Jim Wiant <Jim.Wiant@xxxxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 02/13/2014 04:21 PM
Subject: RE: Checking object create dates
Sent by: midrange-l-bounces@xxxxxxxxxxxx



True, there is also CHGMOD for programs.

But such changes should be tracked with some kind of change control I would think. So source change date for programs is the best I've been able to find. I'm sure that there is always a way that would not be picked up.
Using the API's to go through the module(s) individually might get you closer.

For printer files, how about the Format Level Identifier (shown in a DSPFD)?

James P. Wiant
Test System Administrator

FOODSTUFFS
NORTH ISLAND LIMITED

DD: 09 621 0774 | M: 027 463 4159| P: 09 621 0600 DX Box CX 15021 or PO Box 27480 Mount Roskill, Auckland 1440, New Zealand

Fast is fine. Accuracy is everything
Earp, Wyatt


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Friday, 14 February 2014 10:09 AM
To: Midrange Systems Technical Discussion
Subject: RE: Checking object create dates

That's a false assumption.
Lots of objects get changed outside of the source. Especially printer
files. Hey, let's run a CHGPRTF to change... A good change management
system will flag you when something was changed outside of the change
management system.
We were running into issues where we would promote a new printer file
change, miss the CHGPRTF issues, and users got upset.
Other possible issues: CHGOBJOWN, CHGAUT, etc.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: "Steinmetz, Paul" <PSteinmetz@xxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'"
<midrange-l@xxxxxxxxxxxx>
Date: 02/13/2014 04:03 PM
Subject: RE: Checking object create dates
Sent by: midrange-l-bounces@xxxxxxxxxxxx



Maybe
Crtdupobj carries the original source date, thus both source dates are
equal.
Problem is that my utility uses dspobjd detail(*full) output(*outfile),
source dates are not in the outfile.
If I change my utility to use detail(*service), I see the source dates in
the outfile.

So, would it be correct to say that if two objects have different create
dates, but the source dates are equal, the objects are equal.

Fix library
Creation date/time . . . . . . . . . : 08/15/11 10:41:44
Source file date/time . . . . . . . : 04/01/11 01:52:05
Std library
Creation date/time . . . . . . . . . : 08/28/11 10:49:35
Source file date/time . . . . . . . : 04/01/11 01:52:05


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Briggs, Trevor
(TBriggs2)
Sent: Thursday, February 13, 2014 3:44 PM
To: midrange-l@xxxxxxxxxxxx
Subject: RE: Checking object create dates

If you do a DSPOBJD with DETAIL(*SERVICE) it shows the Source file
date/time. Will this work for you?

Trevor Briggs
Analyst/Programmer
Lincare, Inc.
(727) 431-1246
TBriggs2@xxxxxxxxxxx

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Steinmetz, Paul
Sent: Thursday, February 13, 2014 3:31 PM
To: 'midrange-l@xxxxxxxxxxxx'
Subject: Checking object create dates

I'm working on a utility to find objects that exist in a custom/emergency
fix library that would have a create date lt the create date of the object

in the standard library, thus sign of an issue.
Utility done, working.
However, I found a scenario where we received a new object (*prtf) for an
upgrade. Because we change some print attributes on a few of these, we
place a copy of these prtf file objects in the fix library.
The upgrade is done, replacing the objects in the standard library.
Here's the issue.

The prtf object in the fix library was created with crtdupobj, prior to
the upgrade being done.
Creation date/time . . . . . . . . . : 08/15/11 10:41:44
The prtf object in the standard library has a create date for the day of
the upgrade.
Creation date/time . . . . . . . . . : 08/28/11 10:49:35

The objects are valid, but being flagged because of the create date issue.
I'm looking for some other field on the object, not finding any.

Many of our upgrade processes do this. The upgrade process does a
crtdupobj, thus the object loses its original info, (create date, created
by user)

Thank You
_____
Paul Steinmetz
IBM i Systems Administrator

Pencor Services, Inc.
462 Delaware Ave
Palmerton Pa 18071

610-826-9117 work
610-826-9188 fax
610-349-0913 cell
610-377-6012 home

psteinmetz@xxxxxxxxxx
http://www.pencor.com/

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.

************************************************************************************************************************************************************************************************************
This message originates from Lincare Holdings Inc. It contains information

which may be confidential or privileged and is intended only for the
individual or entity named above.
It is prohibited for anyone else to disclose, copy, distribute or use the
contents of this message.
All personal messages express views solely of the sender, which are not to

be attributed to Lincare Holdings Inc., and may not be copied or
distributed without this disclaimer.
If you received this message in error, please notify us immediately at
MailAdmin@xxxxxxxxxxx or (800) 284-2006.
************************************************************************************************************************************************************************************************************

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact