Re: CPF7354 Excessive Physical Members for a Logical

Al,

Boy this goes a long way back, but I used to work for an insurance company that 
uses multiple member files to segregate their monthly transcations. Premium 
transactions used to be member PM9901 for Jan or 1999 and claim transactions 
used to be member CL9901, again for Jan of 1999 . Daily members were PM990113 
and CL990113. Logicals over multiple member files were always created with 
*MEMBERS *NONE for the reason you listed. The 32 physical limit is nice if you 
are creating a multiple member work file of 2 years or so, cause you could 
create the logical and pull all the members into one logical. 

We had logicals over the multiple member physicals, but they were added, at 
creation, and always contained the member name of the physical for obvious 
reasons.

Multiple member work files, based on workstation name, is a quick and easy way 
to keep work files segregated, but they can be a growth nightmare like you have 
mentioned.

We used to have a utility that did a DSPFD *MBRLIST to an outfile and a CL 
program that would read through it and first delete the logical, then the 
physical is the number of records were *Zero and the lst used date was over 30 
days old. As most work files get recreated, if they are not there, deleting an 
often used one is not a problem, if the user doesn't mind waiting the 30 
seconds for them to be created again. 

Multiple members are neet, but for other than work files, I would not use them 
again. SQL doesn't like them unless you do an override first.

Jay

---------- Original Message ----------------------------------
From: MacWheel99@aol.com
Reply-To: MIDRANGE-L@midrange.com
Date: Tue, 27 Mar 2001 11:25:02 EST

>from Al Macintyre
>
>There is stuff I do not do every day & thus forget key nuances.
>I am non V4R3 (soon to upgrade to V4R5) without any 3rd party tools to speak 
>of & no access to Ops Nav ... coworkers have Client Access, but I work from 
>Twinax.  I can do some SQL stuff but I'm no expert.
>
>Our ERP creates work areas named after user sessions & over time there is an 
>evolution of work station addresses, including some we will never ever use 
>again, so this leads to a growth in unwanted empty members of files, and data 
>areas, and other stuff in need of clean up, and until we implement some 
>system for periodic clean up, it can complicate other efforts.
>
>We have some BPCS CD programs with massive excess volume of data, that we do 
>not want to print, such as the cost of work-in-process.  I defined a logical 
>via DDS to narrow selection to just the records wanted in some of these 
>programs.
>R IPF500OD   PFILE(FOD)
>K ODPRD
>K OORD
>K OOPNO
>K OWRKC
>S ODID     CMP(EQ 'ID')
>   OOPNO COMP(LT 999)
>
>This compiled without any errors but joblog reported what I interpreted as 
>failure
>CPF7354 total # all members specified on DTAMBRS parameter cannot be greater 
>than 32
>I had a hell of a time tracking down DTAMBRS ... I now suspect that after a 
>logical is compiled, there is an implied ADDLFM to add to it all the members 
>that the physical file has & it is DTAMBRS in ADDLFM that this error message 
>is complaining about
>
>This logical now existed but with zero members.
>Several BPCS files have hundreds of members
>in most cases we need 20-40 members
>
>I'd like to get rid of empty members on work station addresses that are 
>history, but I think this requires
>
>a) kill all logicals on a physical
>b) kill unwanted members
>c) recompile logicals
>
>thus first make sure I know where all relevant source is, have a CL to manage 
>this because it won't be a one time requirement, and plan on desk checking CL 
>before all future runs, because the logicals & members will have evolved in 
>the interim.
>
>I cross posted this topic to BPCS_L under "405 CD Excess Members" asking if 
>there were existing BPCS programs to manage some of this & basically was only 
>warned that BPCS software assumes *FIRST is the member named after the file, 
>but in Y2K testing they got members dated before when the file was created & 
>they became the new *FIRSTs.
>
>Questions
>
>Is there a simpler way to make unwanted members go away without having to 
>kill / recompile logicals?
>e.g. what is the function of EXPDATE parameter of a member?  Can I change 
>that with CHGMBRPF or some such command, to cause a member to expire & go 
>away quitely?
>
>DSPFD & DSPDBR seem to show:
>what logicals connect to the physical;
>what formats & members the physical has.
>
>What tells me which formats & members are in which logicals?
>
>Is there a PDM-14 F4 combination to have new logical include a specific 
>member such as physical *FIRST?
>
>Do we have to do ADDLFM only whenever physical has more than 32 members?
>I think this could be mentioned in CPF7354 hints ... where do I suggest that 
>to IBM?
>
>Is it a fair assumption that when a member is added to a physical we cannot 
>assume all its logicals are also there unless we explicitly ADDLFM them?
>
>I am in no big rush here.  I have got a bunch of projects on my plate.
>I can work on others while digging into this one.
>
>MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)
>AS/400 Data Manager & Programmer for BPCS 405 CD Rel-02 mixed mode (twinax 
>interactive & batch) @ http://www.cen-elec.com Central Industries of 
>Indiana--->Quality manufacturer of wire harnesses and electrical 
>sub-assemblies - fax # 812-424-6838
>
>+---
>| 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
+---