RE: Problem with creating a LF.. -- MIDRANGE-L

First of all, you are getting different answers because if you have multiple
members in a physical file and you do not specify the member, it creates one
logical path over all the members based on sort key order. If you specify
the member name, the logical path is only built over the records in that
member only. 

Following are just my opinions(which I seem to have a lot of). Do not relate
to the answer to your question. Thanks.

Deeper question, why are you using multiple members? Multiple members in a
physical files (Production, not Source) is something that has not been done
in years. 

Techniques that would be used today would be to put the interactive job id
in the high order key like so.

1) Job ID 
2) UAACT - Account Number
3) UAUTL - Utility Type

Then you just get the Job id you need. 

Other technique to create a separate library for each Job Id which almost
sounds like what you are trying to do with the multiple members.

Unless this is an existing system that you cannot change, don't use multiple
members. They are an absolute nightmare to maintain because of just the
problem you demonstrated above. You need to build an access path over X
member but forget and end up building it over all the logicals. I know, I
had to deal with just that situation and it was nothing less than a
nightmare. 

We had a system with one member for each doctor's office we were billing for
in each table file. Figure 30 or 40 doctor's per file so one logical per
member per doctor. Forget and we were building one logical over 40 members
and then having to undo and rebuild 40 members and then over 20 or 30
different tables. Don't think that was'nt fun! 

My own personal opinion is that multiple members should never have been put
on the System 38-AS/400 in the first place. Source should have been put into
a special library just like QDOC and the whole member thing should never
have existed. The nightmares that have been created because of that decision
are unbelieveable. 

For what is it worth, the only other thing I might suggest is normalize your
data structure if you can. What you trying to do would probably be a piece
of cake with a properly normalized tables. 
 
-----Original Message-----
From: Graap, Ken [mailto:keg@exchange.gasco.com]
Sent: Wednesday, November 17, 1999 4:26 PM
To: 'Midrange'
Subject: Problem with creating a LF..


Has anyone else noticed this strangeness with CRTLF...:

We are on Version 4 Release 4 of OS/400....


When we build a logical file over an entire physical file (no physical file
member is 
specified), then  the logical file is created as expected. If we specify a
physical file member, 
however, the file is created differently.

Example: Logical file UAGNPTX is created over physical file UAGN. 
The UAGN file has 6 "buckets" that represent the different aging periods on
the system. 

A sample layout would be:

1) UAACT - Account Number
2) UAUTL - Utility Type
3) UAAG1 - Aging Bucket 1
4) UAAG2 - Aging Bucket 2
5) UAAG3 - Aging Bucket 3
6) UAAG4 - Aging Bucket 4
7) UAAG5 - Aging Bucket 5
8) UAAG6 - Aging Bucket 6
9) UAPT1 - Payment Priority 1
10) UAPT2 - Payment Priority 2
11) UAPT3 - Payment Priority 3
12) UAPT4 - Payment Priority 4
13) UAPT5 - Payment Priority 5
14) UAPT6 - Payment Priority 6

Each account would have multiple utility records.

Logical file UAGNPTX exists to put the aging buckets in payment priority
order. 
It has six formats arranged like:

1) UAACT 
2) UAUTL
3) PRTY1        RENAME(UAPTx)
4) AMT1 RENAME(UAAGx)

Where "x" represents bucket 1-6.

When we create the physical file in library QTEMP, and then create the
logical file over it, 
the logical file has 6 records for every record in UAGN (one for each
priority). This is what
I would expect.

If we create the physical file in one of our files libraries, and this file
has multiple members
(one for each interactive job id on the AS/400), the resulting UAGNPTX file
only has one 
record for every record in UAGN. This makes the payment allocation by
priority feature
of our application fail. 

The only difference between how the files are created are the following
parameters on the
CRTLF command:
        
                (this works)

Physical file data members:                      
  Physical file  . . . . . . . .   *ALL                 Name, *ALL
    Library  . . . . . . . . . .                        Name, *CURRENT
  Members  . . . . . . . . . . .                        Name, *NONE
        
                (this doesn't)

Physical file data members:                      
Physical file  . . . . . . . .   UAGN                   Name, *ALL
Library  . . . . . . . . . .           P1FILES             Name, *CURRENT
Members  . . . . . . . . . . .   QPADEV00H8       Name, *NONE

        
Kenneth

****************************************
Kenneth E. Graap
IBM Certified Specialist
AS/400 Professional
Systems Administrator
NW Natural (Gas Services)
keg@nwnatural.com
Phone: 503-226-4211 x5537
FAX:    603-849-0591
****************************************


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