I responded to Kim off-list. My recollection is that she typically works in Unix environments (AIX, if memory serves), though she didn't indicate what the specific situation was, nor whether this had to be a specific or general solution. I suggested a few Unix trix, reflecting my own biases. Mike's response details some of the powerful (aka obscure) depths of the SAS-MVS interface.

My general recommendation is to separate the systems aspects (filesize, resources, runtime, priority) from your SAS program to the greatest extent possible. Some environments provide a great deal of resource utilization information and/or control, others have no idea of the concept. In general, I'd experiment with the process/job scheduling and prioritization resources of my environment, rather than attempt replicating this in SAS code.

There are a number of job control/batch systems available for MVS, Unix, VMS, and NT; these may be bundled with the system, freely available, or third-party proprietary products. I'd suggest anyone with an interest in these issues explore the opportunities here rather than build a set of idiosyncratic and complex SAS code.

For Unix specifically, user resource limits can be controlled through the 'ulimit' facility, and job scheduling accomplished via 'at' or 'cron'. Beyond this, home-grown or third party scheduling tools are recommended.

> ---------- > From: Michael A. > Raithel[SMTP:MICHAEL.RAITHEL@RAITHM49.CUSTOMS.SPRINT.COM] > Reply To: MICHAEL.RAITHEL@RAITHM49.CUSTOMS.SPRINT.COM > Sent: Wednesday, January 27, 1999 1:27 PM > To: SAS-L@UGA.CC.UGA.EDU > Subject: (MVS) Re: CPU > > Kim LeBouton posted the following (very interesting) > question: > > >I'm trying to determine if my program has been using up > >too much CPU, and then I want to stop my SAS program. > <delitia>

> -- > Karsten M. Self (Karsten.Self@schwab.com) > Trilogy Consulting > > What part of "gestalt" don't you understand? > > WARNING: All e-mail sent to or from this address will be received by the > Charles Schwab corporate e-mail system and is subject to archival and > review by someone other than the recipient. > > This communication does not necessarily reflect the views or position of > The Charles Schwab Corporation, or any of its subsidiaries or their > affiliates. >