× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: CPF7354 Excessive Physical Members for a Logical
  • From: MacWheel99@xxxxxxx
  • 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
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.