|
Mark, >> I'm *not* using those columns on my READ to the async >>device. Rather, I'm using columns 56-57: I/O error to trap the timeout. >>This way, I can check *STATUS and MAJMIN right in the mainline code >>rather than jump out to *PSSR. >> >>Now, recall that this code works perfectly to detect "normal" timeouts. >>It does not blow up or issue any "white messages" under any conditions. >>When the line fails, the timeout simply does not seem to occur. >>It sits on the READ and control does not return to the RPG program at all. > > The way I understand it, if the program is already in the *PSSR, then the >timeout can't be trapped by your READ w/ error indicator. Right you are. Unfortunately, the code isn't in the *PSSR when it fails; it's at the READ. I can guarantee this because all the *PSSR does is DUMP, send a message and terminate. Oh, well. I guess I'll have to try a work-around, like setting another process to watchdog my communications. Sigh. Buck Calabro Commsoft +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to "MIDRANGE-L@midrange.com". | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
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.