|
The problem with that design is that anyone with access to your network can end the "never ending program" simply by sending the correct entry to your data queue. In today's world, where the Internet is used to network just about every computer in any business, this could be a big problem. A better design is to have a loop: 1) Wait on a data queue with a (for example) 30 second timeout. 2) If data was received, act upon that data. 3) If no data was received (the QRCVDTAQ call timed out) then check if the system has started a *CNTRLD shut down, and if so, end the program gracefully. 4) Continue looping with step 1. I don't know about other languages, but in RPG you can easily check for a *CNTRLD shutdown (issued either by the ENDJOB, ENDSBS or PWRDWNSYS commands) using the SHTDN op-code. On Wed, 21 Aug 2002, Doug Hart wrote: > > Years ago (likely System/38 days) I had a client who ran a great many never > ending job. These jobs would sit on a DATAQ wait. They were always active > but would "sleep" most of the time. To end them gracefully I coded some > routines that would watch for the subsystem or job ending. Then I would > send a unique string to the DATAQ that the waiting program would see and do > its own normal end. This was much better than just pulling the plug as > these were watching network transactions. >
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.