RE: Max Records in Physical or Printer Files - To Max or Not To Max...

Rick,

I'm not sure that much has changed.  You do now have the ability to
define a low storage limit in the System Values (QSTGLOWLMT) and an
action to be taken when that limit is reached (QSTGLOWACN).  If you
research the actions allowed for the low storage actions, you may feel
that having maximums on some files is a good idea

        - Send message to system operator and system message queue
        - Send message to service users
        - Run registered exit programs
        - End system to restricted state
        - Immediately power down and restart system

Aside from writing some exit programs, these options are either the old
status quo (send a message) or they're very severe.

If by 'disk limitations parameters' you are referring to the MAXSTG
parameter on a user profile, I'm not sure that this would be preferable.
Generally when a file or spool is increasing out of control, it is not
owned by the user who is causing the problem, thus you would end up
creating another system-wide storage limit by user profile.  I'm not
sure what would happen when that limit is reached, but it would probably
be very severe because your database files would be limited once that
point was reached.  Is this the function you were referring to?

I can recall a system which exceeded its threshold one day.  The system
generated that critical storage condition message every half hour for a
day and a half, then the system died.  Aside for some severe
disciplining of the operations staff, IBM had to come in and install
more disk because the machine did not have enough free space to IPL.

Unless there is some functionality with which I'm not familiar, I would
not recommend your plan.  It would not take much time to identify those
files which are approaching some predetermined percent of their maximum
records.  Perhaps a monthly parsing of the DSPFD output?  For the spool
files, perhaps you could identify those print files which are associated
with large reports and give them a much larger limit.

Given the consequences of complete DASD utilization, I would not suggest
doing this.  Particularly if your system runs unattended.  The
consequences of filling up your drives are worth preventing.
Unrealistically high limits would be better than *NOMAX.

Regards,
Andy Nolen-Parkhouse

> I know way back in the days of the SYS38 you could "pin"
> a machine silly with a runaway file but doesn't the 400 handle this
now
> with ASP threshold and disk limitations parameters?
>
> We'd like to create all applicable file objects to size(*NOMAX) but
> perhaps
> someone can educate us first to any extenuating circumstances that
could
> arise from this decision.
>
> Thanks all and HAPPY NEW YEAR!
>
> Rick Rayburn