"An NEP waiting on a PF with EOFDLY(1) is a nice technique - even simpler
than waiting on data queues, for some things."
Just make sure the file does NOT reuse deleted records! IIRC, the 'wait' is for a new record at the end of the file. There might even be a system restriction to prevent such a thing...
As far as trusting NEPs goes-- we have a subsystem chock full of NEPs-- 208 of them in production if I counted right; 255 on our test system. Some use the EOF wait, some wait for messages, others feed off of DTAQs. And they all do their job without complaint!
As a means of protection, we have a data file that contains all of the information needed to start and stop each NEP-- the job name to submit it as, the JOBD, the commands to start and stop the job, and a status flag to indicate if the job should be active or suspended.
When we start these jobs the job name on the file is the name used to submit the jobs. A job runs through the file every 30 minutes to make sure all of the jobs that should be running still are running. Since we know the job name we can check to see if there's a job out there with that name. And we run it every 30 minutes, not because we don't trust them, but because we've been known to have 'program malfunctions,' or because we need to temporarily end one for some reason but forget to re-start it.
If a job has been suspended, the 'checkup' job sends a warning eMail so that 'someone' knows that a job is suspended.
This mailing list archive is Copyright 1997-2019 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