Re: Async comm not timing out

Mark, 

>>What will the *PSSR buy me?  Remember, this code detects time-outs
>>except when the comm line actually goes down. With the immediate check 
>>of MAJMIN and the error indicator, I can use mainline code to direct
>traffic.  
-snip-
>>I generally use the *PSSR only for unexpected "catch-all" situations.
>>I find it much easier to handle errors by calling the proper subr from
>>the mainline.   Maybe this is an outdated way to do this sort of stuff?
>>What do the rest of the list think?
>
> It is the error subroutine.  Think of a timeout as a "hard" error.  If you
>don't monitor for it, the program will blow up, just as the line errors
>will.  Contrast this w/ a "soft" or expected error such as a CHAIN that
>doesn't get a hit.  Of course the CHAIN indicator traps the error, but I
>hope you see the difference.

Yes, I understand that *PSSR is the error subroutine.  When you refer to
the CHAIN indicator, I assume you mean (RPG III) columns 54-55: No
Record Found.  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.

Have you seen this sort of thing before, and does using the *PSSR make
a difference for you?

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
+---