• Subject: Re: Async comm not timing out
  • From: Buck Calabro <mcalabro@xxxxxxxxxxxx>
  • Date: Wed, 24 Dec 1997 09:30:27 -0500

Mark,

>>Yes, there's a *PSSR, but I'm not using it in this case: I have indicators
>>on EOF and ERROR.  What happens is the line is dropping and the READ
>>is never satisfied.  By that, I mean that the code sits at ICFW (the only
>>READ
>>in the program!) and never executes the tests for MAJ/MIN, EOF or ERROR.
>>
>>Here's the code snippet:
>>     C                     SETOF                     80               
>>     C           *IN80     DOWEQ*OFF                                  
>>     C                     WRITEINVITE                 81             
>>     C                     READ DMSMTXFM               8180           
>>     C   80                LEAVE                                      
>>     C* Timed out; drop out                                           
>>     C           MAJCOD    IFEQ '03'                                  
>>     C                     MOVEL'Y'       PMTERR                      
>>     C                     LEAVE                                      
>>     C                     ENDIF                                      
>>     C* Comm error; drop out                                          
>>     C           *IN81     IFEQ '1'                                   
>>     C                     MOVEL'Y'       ERRFLG                      
>>     C                     LEAVE                                      
>>     C                     ENDIF                                      
>>     C* Process result
>>
>>81 is ERROR, 80 is EOF.
>>
>>I am wondering if the line wierdness is generating XOFF characters
>>that are hosing up the READ...
>
> I think you s/b using the *PSSR and test for the maj/min codes in there.
>Also, use the factor 2 function on the ENDSR to control the logic.

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.  
If I use the *PSSR, then won't I need to do something like this?

     C* Top of calcs...
     C           CNDCDE    CABEQ'T'       READRC                     
     C           CNDCDE    CABEQ'E'       CLOSEF                     
     C* rest of calcs...


     C* Read a record
     C           READRC    TAG
     C                     WRITEINVITE                                
     C                     READ DMSMTXFM                 80           
     C* rest of calcs...


     C* Close up shop
     C           CLOSEF    TAG
     C                     CLOSEDMSMTXFM                 
     C* rest of calcs...


     C           *PSSR     BEGSR
     C* check status...
     C           MAJCOD    IFEQ '03'                                  
     C                     MOVEL'T'       CNDCDE      
     C                     MOVEL'*GETIN'  ACTCDE
     C                     GOTO PSSREN                                 
     C                     ENDIF                                      
     C* Rest of PSSR...
     C           PSSREN    ENDSRACTCDE

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?

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


This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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 [javascript protected email address].