RE: Checking object create dates -- MIDRANGE-L

Glad it's better.

My full solution to make sure my test environment matched production used API's, output written into a file and then the files compared. For all objects in the libraries I was concerned with I first determined the object type, then called an appropriate API (main RPG programs displays the objects in the library out to a file then reads the file and checks the type and calls subroutines):

*PGM QCLRPGMI (if ILE, also calls QBNLPGMI and outputted into a user space to flip though the modules).
Store source file name and library and member, and source update time for comparison for the program or each ILE module
*FILE QDBRTVFD (format FILD0200)
Store the level identifier (this API is no fun at all)
*DTAARA QWCRDTAA
Store the type, length and decimal positions if any
*DTAQ QMHQRDQD
Store the message length, key length, if sender id included, type, max entries and a couple other assorted
(Was somewhat lazy and omitted DDM data queues)

Then when the file is built with the above data from the production system I send it to the test system, run the same code over the test libraries into a different file and then compare the results. Anything that doesn't match I take an extra look at.

This gives me a good confidence my test libraries match production with the exception of objects actually being tested. Clearly I don't cover all object types and there certainly are ways that some differences could be missed, but I feel this is a good general regular accounting (I run it weekly) that tells me that objects aren't going into production without going through test first and/or that my environment does not reflect production - which are my main concerns. Of course in the file comparison mismatches are reported as well (on one system but not on the other).

Hope this helps

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 Steinmetz, Paul
Sent: Friday, 14 February 2014 1:53 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Checking object create dates

Jim,

In the query/400 that compares the 2 outfiles, I added a source date check, that worked.
Only 1 object remains on report.
May not be 100%, but much better than it was.

UODCDTYMD LT ODCDTYMD
AND T01.ODSRCD NE T02.ODSRCD

-----Original Message-----
From: Steinmetz, Paul
Sent: Thursday, February 13, 2014 6:50 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Checking object create dates

Mark,

I do use dspfd for some of my other utilities.
Time to regroup, this is no longer simple.

I remember many moons ago a CRTDUPOBJ PMR I had with IBM, questioning the create date and create user. I felt they should be the same, but that was not the case.
Maybe we need another IBM data area, one for CRTDUPOBJ, so we get the desired results.

CRTDUPOBJ is what's causing this issue.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Mark S Waterbury
Sent: Thursday, February 13, 2014 6:42 PM
To: Midrange Systems Technical Discussion
Subject: Re: Checking object create dates

Paul:

That is fine for a "top level" compare to identify objects that possibly might be different in some respects.

What I was trying to suggest was something like this --

For each such object with a different create date, you should then "drill down" to do some extra checks, such as comparing the source member last changed date/time stamps, and then, for *FILEs, you might want to issue DSPFD to generate the additional *OUTFILEs, to allow for a "deeper" comparison of all of the other attributes that could be changed, and that are not reflected in the create date or Record Format Level IDs.

Hope that helps,
Mark

On 2/13/2014 6:33 PM, Steinmetz, Paul wrote:
Mark,

I use dspobjd instead of dspfd because I need to account for all object types.
I do have two outfiles and I do use query/400 for the compare.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Mark S Waterbury
Sent: Thursday, February 13, 2014 6:29 PM
To: Midrange Systems Technical Discussion
Subject: Re: Checking object create dates

Paul:

For *FILEs, you can issue DSPFD ... TYPE(*ATR) OUTPUT(*OUTFILE)
OUTFILE(QTEMP/QAFDPRT)

Issue the DSPFD for the first file with OUTMBR(*FIRST *REPLACE) -- then issue the DSPFD again for the second file, with OUTMBR(*FIRST *ADD) ...

Then, you can write a program to read the two records and compare them, field by field, to determine what is "different" among the various printer file attributes.

You can do similar things for PFs, LFs, DSPFs, etc. -- pretty much all kinds of files.

If you do not want to write a program to to the analysis, you can use two separate *OUTFILEs and then use Query/400 or QM/400 or an SQL query to do the "compares" ...

Hope that helps,

Mark S. Waterbury

> On 2/13/2014 6:06 PM, Steinmetz, Paul wrote:

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.

--
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 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 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 was scanned for compliance with Foodstuffs North Island Limited email policies
######################################################################
This message has been sent from Foodstuffs North Island Limited (Foodstuffs).

The information contained in this message (including its attachments) is intended only for the person or entity
to which it is addressed and may contain confidential and/or privileged material.
If you received this message in error, please contact the sender immediately by return email and delete this message and your reply.
You must not use, disclose, distribute, print or copy any part of this message.

The views and opinions expressed in this message may be those of the individual sender and not necessarily those of Foodstuffs,
in which case the views are not given or endorsed by Foodstuffs.

Please note that this communication does not designate an
information system for the purposes of the Electronic
Transactions Act 2002.