|
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
As an Amazon Associate we earn from qualifying purchases.
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.