|
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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.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 on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.