[Info-vax] Timeout in a write using QUIW.

[Dave Froble]

On 6/21/2023 5:36 PM, Jan-Erik Söderholm wrote:
> Den 2023-06-21 kl. 23:25, skrev Stephen Hoffman:
>> On 2023-06-21 20:45:12 +0000, Jan-Erik Sderholm said:
>>
>>> Now, here is a technical one...
>>>
>>> When doing a *read* from a terminal device using QIOW, one
>>> can use IO$M_TIMED and supply a timeout value in P3. That
>>> works perfectly and we use that a lot...
>>
>> I've never had great success...
>
>
> I'm sorry about that. As I wrote, it works perfectly. In the
> case of reads, of course, where it is supported.
>
> My question was about writes, and it has been confirmed that
> timeout paramaters are not supported there. Thanks Arne.
>
> Now we need to weight the coding work against getting
> network cables installed to the printers. Wired printers
> will also "solve" the issue with the current code. We have
> 15-20 older similar Zebra label printers, all wired, and
> we do not see these error scenarios with those.
> All using the same C routine for the QIOW calls.
>
>
> Jan-Erik.


Well, if you have an AST routine such as:

1       !************************************************
         !     Timer AST Timeout Handler to Cancel I/O
         !************************************************

         SUB TCP_TIMER(  LONG CH% , &
                         LONG Z2% , &
                         LONG Z3% , &
                         LONG Z4% , &
                         LONG Z5% )

         CALL SYS$CANCEL( Loc(CH%) By Value )

         SubEnd

And then in you program define the routine as external:

         EXTERNAL LONG FUNCTION TCP_TIMER                !  Timer AST routine

And then queue the timer routine:

         !***************** Set timer AST *****************
         Stat% = SYS$SETIMR( ,   WAIT.PRD ,              !  Delta time &
                                 LOC(TCP_TIMER) By Value , &
                                 CH% By Value , )        !  AST rtn and channel

         Stat% = SYS$QIOW(       ,                       !  Event flag &
                                 CH% By Value,           !  VMS channel &
                                 IO$_ACCESS By Value,    !  Operation &
                                 IOSB::Stat%,            !  I/O status block &
                                 ,                       !  AST routine &
                                 ,                       !  AST parameter &
                                 ,                       !  P1 &
                                 ,                       !  P2 &
                                 SERVER.ITEMLST::LEN%,   !  P3 - remote socket n^
                                 ,                       !  P4 - &
                                 ,                       !  P5 &
                                 )                       !  P6

         If      ( Stat% And SS$_NORMAL ) = 0%
         Then    Call VMSERR( Stat% , E$ )
                 E$ = "Unable to queue connect to host - " + E$
                 E% = -1%
                 SaveStat% = Stat%
                 GoTo Close_Socket
         End If

         If      ( IOSB::Stat% And SS$_NORMAL ) = 0%
         Then    If      IOSB::Stat% = SS$_ABORT &
                 OR      IOSB::Stat% = SS$_CANCEL
                 Then    E$ = "Timeout"
                 Else    Call VMSERR( IOSB::Stat% , E$ )
                 End If
                 E$ = "Unable to connect to host - " + E$
                 E% = -1%
                 SaveStat% = IOSB::Stat%
                 GoTo Close_Socket
         End If

Note, if the QIOW exits with the IOSB status of ABORT or CANCEL then you can 
assume it was the cancel in the AST routine.  However, I feel that some other 
reason might set that status.  Never bothered to look into it further.

My planning is that if this happens, then the QIOW failed, and it's time to move 
on, regardless of why it failed.

Note, the wait period can be set up with:

         WW% = W%                                        !  Set delta time
         Stat% = LIB$CVT_TO_INTERNAL_TIME( LIB$K_DELTA_SECONDS , WW% , WAIT.PRD )

Should be easy to figure out by reading the docs on the various system services 
and LIB$ routines.

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486