Re: Objects and Source

Hi gang -

>Date: Wed, 02 Feb 2000 20:24:41 -0500
>From: John Hall <jhall@hillmgt.com>
>Subject: Re: Objects and Source
>
>Ken you may find this hard to believe but we use almost the exact same
>library structure.  The only difference I can see is that the template
>files for qtemp are not in the database library.  We had problems with
>some people doing improper overrides and writing data to the template
>file.

John, I didn't say we USED this structure.  Actually, the library structure
we more-or-less use, but the packaged software has hard-coded library names
up the wazzoo for the end-of-day and end-of-month libraries, so there are
certain functions that we can't run in the test environment.

For handling work files created from template files, I created two commands
... CRTDUPFSET (CReaTe DUPlicate File SET) and DLTFSET (DeLeTe File SET).
CRTDUPFSET creates a copy of a physical file and its associated logical
files in another library, and creates job level overrides.  There are a lot
of parameters, but when specified with CRTDUPFSET [physicalfilename]
allowing all other parameters to default, it looks for the original physical
file in *LIBL, creates the new file set in QTEMP, deletes the file set if
already exists in QTEMP, creates the override, does not copy any data that
may exist in the original file, and creates all associated logical files
(which must exist in the same library as the physical file).  DLTFSET
[physicalfilename] with all other parameters defaulting deletes the file set
from QTEMP and deletes the job level overrides.

So the following code ...

CRTDUPFSET WORKFILE
CALL LOADWORK
CALL PRINTWORK
DLTFSET WORKFILE

will ensure that the QTEMP version of the work file is used.

>One of the data areas in our database library is called TESTENV  and is
>either a 1 or a 0.  This 
>can be retrieved to alter processing for test purposes.  For example one
>of our processes FTP's a file to an outside vendor.  When the program
>reaches that point it checks the TESTENV to see if it should really send
>the file.  Our CPYLIB procedure automatically forces TESTENV to 1 on a
>copy.  

Based on Paul's comments (see below) there might be a better way to do this.
Get the database library name and compare it.  For example, all of our
production database libraries start with WSFILE and all of the test database
libraries start with WSTEST.

In fact, while writing this message I just had a brain storm (or at least a
drizzle) where I could use this method to get around having a special set of
CL programs in my "changed objects" test library all the time so that when I
run test invoices they don't go to the regular outq.

>Date: Thu, 3 Feb 2000 10:24:14 -0500
>From: pcunnane@learningco.com
>Subject: Re: Objects and Source
>
>     I like this approach.  One change I would make (because I'm a paranoid

>     SOB, and I rarely trust the contents of data areas unless absolutely 
>     necessary) -- instead of reading the contents of the data area, do a 
>     RTVOBJD on it, and check the RTNLIB.  Or use an API.  Or something.  
>     otherwise, I could see some genius copying a library and forgetting to

>     change the data area contents.
 
Good point, Paul!  We are not using either method at the moment, but if/when
we get to the point where we are, I'll use this method.

>Date: Thu, 03 Feb 2000 03:13:31 -0800
>From: "James W. Kilgore" <qappdsn@attglobal.net>
>Subject: Re: Objects and Source
>
>Paul,
>
>I concur, we have a file that is mandatory for the application to execute
and we
>retrieve it's library name.  Having a manually controlled date area, or
writing a
>command that does the library duplication and data area maintenance is just
one
>more thing to manage.

James, if/when we get to the point of using this, I think I'll stick with a
data area (but use its return library not its contents) rather than one of
the application files.  That way if I need that file in a "changed objects"
test library, that doesn't change my pointer to the database library.  If I
do want the pointer changed to the "changed objects" test library, I just
create the data area in there.

Ken
Southern Wine and Spirits of Nevada, Inc.
Opinions expressed are my own and do not necessarily represent the views of
my employer or anyone else.

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---