Re: Illogical Mess

Al,
  We find  ANZDBF (Analyse database files) useful for finding problems with file
relationships.

We are planning to change from our current set up to have all logicals in the 
same
library as the physical and not use the user files library for this as it causes
so many problems.

We are using BPCS 6.0.02, OS/400 4.3 and purchased TAATOOLS from Jim Sloan.

Hope this helps.
   Alison

MacWheel99@aol.com wrote:

> Some more dumb questions from Al Macintyre at Central Industries where we have
> BPCS 405 CD on AS/436 just upgraded to V4R3, with no TAATOOLS, ROBOT, etc.
>
> Logical vs. Physical - does *LIBL & security "magically" control which
> physical a logical is looking at, so that if a logical which is in the user's
> library list is crossed, pointing at a physical that is not in the user's
> library list, then the user will effectively not see any data?
>
> I think I had better do some dump of *FILE statistics in the major BPCS file
> libraries then a query to tell me if any logicals there are pointing at any
> physical in a different library & if any physicals there are having logicals
> pointing at them from a different library - which OS/400 command would be the
> appropriate DSP to do this safety check?
>
> Compile Question vs. Environments - If I happen to be in one environment when
> I compile a program, using standard BPCS commands like RPG & CRTCLP, should
> everything refer to *LIBL & *JOBD in such a way that if that program is
> subsequently executed in a different environment than the one I was in when I
> compiled it, it should not be pointing at any objects unique to the compile
> environment?
>
> I had been assuming that compilation & execution were *LIBL independent.
>
> Compile Question vs. Methods - If a BPCS program was compiled from IBM
> defaults, such as 14 from WRKMBRPDM, instead of BPCS defaults, is there
> something easy to check that will tell us what if anything is wrong?  e.g.
> WRKOBJ - specific attribute - aha ... this needs to be recompiled thru BPCS.
>
> I am suspecting that some of our contract programmers might not have been
> using the BPCS compilers.  One of the consultants told me that we only need to
> use the BPCS compilers for BPCS modifications, not Queries.  Also, there does
> not appear to be a BPCS compiler for RPG that has SQL inside.
>
> OS/400 question = If DSPPGMREF is run for one library for programs pointing at
> objects in other libraries not in its library list, but for which the user is
> authorized to access, and in which those object names exist in multiple
> libraries, how does DSPPGMREF determine how to identify linkages?
>
> I was in BPCS & F3 to OS/400 without the BPCS test or live environment lists,
> but due to SSA user group security I was authorized to look at stuff in both
> environments.  Then I ran DSPPGMREF on one of the libraries & it seemed to
> helter skelter point at both test & live environment objects --- I was
> wondering if that was an artifact of DSPPGMREF rather than what the picture
> appeared to paint.
>
> When we get a BMR which adds a logical, how should it be installed?  I had
> been copying the logical object to target library, before any IBM schooling,
> but now think what I ought to do is recompile the source into the target
> library, if the source came with the BMR, retroactively for all BMRs, just in
> case.  After we test some modification in our development library, I recompile
> the source into the modification library - I do not copy objects, like PRTF.
>
> Our library lists are setup identical except for objects unique to the
> environment:
>
> Our Modifications - shared by environment, software should always use *LIBL,
> never library-specific
> User-Files unique to environment
> User-Objects unique to environment
> Work-Around library = copies of objects that worked before PTF-1 broke them
> Various BBRs - checked against Work-Around contents during testing
> PTF-1 library - shared by environment
> Files unique to environment
> Objects unique to environment
> Our Queries
> Various Q-stuff scattered around
>
> Although 99% of the stuff in the vanilla objects library is common *LIBL there
> are a tiny fraction that are unique to environment that some time I want to
> split out so we can cut down on duplication of disk space consumption. My
> understanding has been that software SHOULD get from JOBD or some data
> structure the *LIBL specifics, so that it accesses the correct environment
> files corresponding to the user library list.
>
> Safety rules I want to work towards:
> All logicals should be in the same file as their physical - we might have dual
> source QxxxSRC if from SSA & QxxxMOD if internal modification;
> When there are artifacts that cannot use *LIBL, such as Query & Job Scheduler,
> then we need to structure stuff so that objects desired for one environment or
> the other are in libraries unique to each environment.
>
> However, I now have a bad case of nerves after having run DSPPGMREF looking
> for one thing & finding some other stuff I did not expect.  What I was looking
> for is which programs updated a file where I had found where some non-Y2K
> compliant data had been re-introduced into our Y2K-compliant achievements.  I
> suspect some careless modification, or a hole in our Y2K-testing.
>
> I ran DSPPGMREF for *ALL programs *ALL types in a particular library.  To my
> great dismay, I found multiple cases of where a program apparently referenced.
>
> Y = correct - they all should be that way
> 1 = problem I need to fix, after I figure out what is causing it
> 2 = problem to deal with after 1 is behind me
>
> Y = another program in *LIBL
> Y = data area via *LIBL
> 1 = a logical in the test environment
> 1 = a logical in the live environment
> 1 = DSPF in the unfinished development library
> 2 = a print file in a specific environment
> 2 = a print file in which the library field is blank
>
> I did not see ANY logicals pointing at *LIBL
>
> Al
> +---
> | This is the BPCS Users Mailing List!
> | To submit a new message, send your mail to BPCS-L@midrange.com.
> | To subscribe to this list send email to BPCS-L-SUB@midrange.com.
> | To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner: dasmussen@aol.com
> +---

--
Alison Quinton
Xyratex
Alison_Quinton@uk.xyratex.com
http://www.xyratex.com/


+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---