Re: Oh where has my disk space gone?

from Al Macintyre

Great advice from Steve ... I am going to adjust my stuff based on his tips.
However, before implementing Bill's suggestion, I would check with the
MAPICS_L list to find out if there are any files on your version of MAPICS
that ought not go through any IBM reorg.

We never left MAPICS I but were seriously considering MAPICS II before we
switched to BPCS.  We were in touch with other neighbor factories on other
versions of MAPICS & BPCS.

There was a problem with the Bill of Materials file at an earlier version of
MAPICS.
If you used the IBM reorg to get rid of the deleted records, you ended up
with a file that did not work right on MAPICS ... it was neccessary to use
the MAPICS reorg on that file, which took longer, for good reason.

We have a problem with certain BPCS files if we use the IBM reorg on them to
get rid of deleted records, because the sequence numbering is not reset in
the IBM reorg ... basically you have some files that are accessed within some
item customer operation etc. index record-1 record-2 record-3 etc. & suppose
record-2 is deleted ... there are ERP programs reading record 1 2 3 etc. that
if they cannot find record-2 they quit right then & not get to record 3.

Some MAPICS files were accessed using relative record numbers, not any index
of item customer etc. so if you reorganize those files by some technique
other than the MAPICS reorg, you have just corrupted how MAPICS can access
them.

Basically some file would get at something else using relative record number
of that other file & MAPICS did this a lot ... I think they were called CHAIN
FILES.

I know MAPICS has been re-written several times since this reality.
This may no longer be a factor.
This is why you have to ask the MAPICS-L or someone who knows the version of
MAPICS that you are on.

PRTDSKINF more informative for the overall picture like which libraries are
eating how much space, but I find the *OUTFILE to be essential for analysis
of our very heavily used production files.  I guess we are using this for
different functions.

> From: ERHARDT@BaldwinHQ.com (Bill Erhardt)

>  When was the last time you did a RGZPFM to reclaim deleted records?
>
>  > -----Original Message-----
>  > From:  Steve Richter
>  >
>  > Rebecca,
>  >
>  > To get answers now, if at all possible,  instead of waiting for RTVDSKINF
>  > to run later, you should run Dspobjd *all/*all *all to an outfile as
>  > suggested in an earlier reply.
>  >
>  > Use WRKQRY to create two queries, one by object size descending,
>  > the other a library summary with an object size total.
>  > The guilty parties then show themselves:
>  > too many objects in qrplobj ( need to ipl ), library qspl has a
>  > lot of space used ( too many spooled files, need to rplsplstg ),
>  > save files
>  > have not been cleared ( need to get tough and break some arms ), ....
>  >
>  > Dspobjd may run for a while ( 30 minutes ). You should run it in batch as
>  > qsecofr. Also the outfile might reach its default capacity.  I get around
>  > that by running DSPOBJD to an outfile on a single object.
>  > Call the outfile "qgpl/dspobjd".
>  > After running the dspobjd on the single object, CHGPF
>  > QGPL/DSPOBJD Size(*NoMax).
>  >
>  > Good luck,
>  >
>  > Steve Richter

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)
BPCS 405 CD Manager / Programmer @ Global Wire Technologies Incorporated
http://www.globalwiretechnologies.com = new name same quality wire
engineering company: fax # 812-424-6838