RE: Match program object to source member; CAN'T use source last update timestamp in object

I think it can be achieve using old-Api QSCMATPG. This Api extract program 
object information into a physical file.
Information are organized in different section :

PT section: program creation template
AS section: associated space
TX section: object description
SC section: service data
AU section: authority bits

I suppose that if you compile a source to a different library and QSCMATPG the 
created program object you can compare it to the QSMATPGed production program.
You just have to compare PT and AS sections (and even TX ?) but not SC and AU 
as they are too much object specific.

Am I in a right way ?


QSCMATPG description, thanks to Simon Coulter.

QSCMATPG

   ���������������������������������������������
   � 1 � Program name    � Input   � CHAR(10)  �
   ���������������������������������������������
   � 2 � Library name    � Input   � CHAR(10)  �
   ���������������������������������������������
   � 3 � File name       � Input   � CHAR(10)  �
   ���������������������������������������������
   � 4 � File library    � Input   � CHAR(10)  �
   ���������������������������������������������
   � 5 � Member name     � Input   � CHAR(10)  �
   ���������������������������������������������
   � 6 � Member option   � Input   � CHAR(8)   �
   ���������������������������������������������

The Materialize Program (QSCMATPG) API retrieves the program template for an OPM
program and places it in the specified file member.

Program name: The name of the program to materalize.

Library name: The name of the library containing the program. Special values are
not supported.

File name:    The name of the output file.  This is a physical file with a
record length of 80 bytes.  The file must exist before the API is called.

File library: The name of the library containing the output file.

Member name:  The name of the member to receive the program template.   Special
values are not supported.

Member option: *ADD or *REPLACE




Jean-Michel Penasse
EXPERIA Europe
jmpenasse@experia.com
+33(0)4.76.67.07.70
www.experia.com

> -----Original Message-----
> From: mi400-admin@midrange.com [mailto:mi400-admin@midrange.com]On
> Behalf Of Dan Bale
> Sent: Friday, April 26, 2002 2:26 AM
> To: midrange-l@midrange.com; MI400@midrange.com
> Subject: [MI400] Match program object to source member; CAN'T use source
> last update timestamp in object
>
>
> This is a re-submit from last week when all the gurus were off
> having fun at
> COMMON.  Now that you're all back... <g>
>
> This particular mini-project I'm working on is killing me.  It is
> mind-numbing, teeth-grinding grunt work, but someone's gotta do it.  It's
> not an everyday task, but I get called upon to do this enough
> that I always
> know I'll be exhausted by the end of a day from working on this stuff.  I
> posted this to both the MI400 list (because I suspect that MI will be
> involved in any possible solution) and the Midrange-L list (to cover the
> wider audience who might have some insight to this).
>
> *Background*
> We're finding a lot of program (and, sometimes, display file) objects on a
> client's system that we are unable to "definitively" match to source.
> Typically, I'd use DSPOBJD LIB/OBJ *objtype  DETAIL(*SERVICE) to see what
> source was used to compile the object.  Unfortunately, what I
> find is that a
> lot of the objects were originally compiled from source in
> so-called user or
> test libraries.  The compile works, it gets tested, and then the that
> compiled object gets *MOVED* into production.  The source member is then
> *COPIED* into the production source file, which sets the copied source
> member's timestamps (both create & change) to the current date & time.  If
> it were me, after testing, I'd move the source member into the production
> source file and compile it into the production library from there.
> Otherwise, it would be nice if it were possible to *easily* MOVE a source
> member so that the member's timestamps carry over to the new location.
>
> *Looking for this kind of solution*
> Given what I've described above, IT WOULD BE NICE if I could run some kind
> of "magic box" command that would take a specified object and a specified
> source member and be able to return a result that tells whether compiling
> that source will produce a new object that is operationally
> identical to the
> specified object.  "Operationally identical" is the key phrase here, as
> using the same source member to compile two different objects will create
> binary differences that I am unable to discern (I have tested this,
> comparing DMPOBJ's on the two program objects).  (Sidenote:  The Ohio
> company that sells a decompiler supposedly has this exact tool, as I've
> described it here, but only for a huge sum.  I exchanged several
> emails with
> someone there suggesting that making this tool available for free
> or nearly
> free might be a good sales generator for the the decompiler product, but
> they didn't bite.  Oh well.)
>
> *NOT looking for...*
> Please, no advice on change management systems.  1, it ain't gonna happen
> and 2, my work begins long after the problem seeds are sown.
>
> TIA,
>
> - Dan Bale
> (I am *NOT* "Dale"
> http://archive.midrange.com/midrange-l/200105/msg00281.html )
> SAMSA, Inc.
> 989-790-0507
> DBale@SAMSA.com
>   Quiquid latine dictum sit altum viditur.
>   (Whatever is said in Latin seems profound.)
>
> _______________________________________________
> This is the MI Programming on the AS400 / iSeries (MI400) mailing list
> To post a message email: MI400@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/mi400
> or email: MI400-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/mi400.
>
>