Jim Phillips wrote:
>
> I have a demo version of CSM (Compression Storage Manager) which is
> Solution Soft's product.  We have a 948 with 6 disk drives and a total
> of 14,943,488 sectors (roughly 3.8 GB) configured.  When I ran CSM
> to compress all files not accessed in the last 60 days, we gained 10%
> more free space (from 24% to 34%).  So it appears to save disk space.
>
> When I ran it the first time, I goofed and ran it to compress *all*
> files, which should not be a problem, as SSI (Solution Soft Inc) says
> that CSM is fully integrated with MPE/iX.  However, it compressed files
> in the IN.HPSPOOL group, which is where scheduled jobs reside.  As a
> result, our nightly backup job (which is self-streaming, that is,
> tonight's run streams tomorrow's) aborted because the job scheduler
> could not FOPEN the file.  It should have been able to because SSI says
> that a file is automatically uncompressed when it is FOPEN'ed (as long
> as you have run the PENABLE program - a TSR for MPE/iX?).  However, in
> this case (an already scheduled job waiting to run) it failed.  Again,
> this should not be a problem, because you really should only compress
> files that haven't been accessed for a while.
>
This turned out to be an OS related problem.  Prior to 5.5, opening of STDIN,
STDLIST, and STDERROR during job creation were disabled for CSM auto
decompression by the OS.  This limitation was removed with 5.5 OS.

Since it does not make sense for CSM to compress an input spool file (it will
be accessed soon) and as a workaround for pre-5.5 OS, CSM now ignore
@.IN.HPSPOOL for compression as of CSM version 1.19.

>
> Also, that first time I ran CSM, it compressed some files in the REGO
> account (Adager).  The next time I ran Adager, it aborted trying to
> open some library file (I forget which one).  I solved that by
> uncompressing all of REGO.  However, it *should* have worked because
> the auto uncompress was enabled.  But it *did not*.
>
The file Adager complaining about is ADAGER78.PUB.REGO.  Adager is calling
HPGETPROCPLABEL with AGAGER78 as the library.  This is a 4.0 only problem. Later
releases handle HPGETPROCPLABEL correctly.

To avoid confusion, 4.0 version of CSM now ignores ADAGER78 for compression as
of CSM version 1.19.  This workaround is absent for other OS releases, since it
works.

> Anyway, we have had old files compressed since 11/13/1996 with no
> problems other than those above.  All in all it appears to do what they
> claim it does, except as noted.  As always, YMMV.
>

We appreciate being made aware of unusual situations that come up when using
CSM. As we would like for those situations to never occur, reality says they
will and we want to respond as quickly as possible to provide the most trouble
free product we can.

Best Regards,

Wayne Sharp
SolutionSoft Systems, Inc.