Conference lassie::ucx

5536.0. "async peak read w/iolockbuf, rwast on abnrml exit" by VMSNET::K_DECOUX () Tue May 27 1997 12:47

    Hi, 
    
    My customer has an application, that when abnormally terminated,
    goes into RWAST state.    I've read notes 795 and 2088, and am not
    sure if this is a programming error, or an actual bug in UCX. 
    
    Can you look over this and let me know what you think?
    
    Thanks,
    
    Karen
    =============
    I have a program which issues an async read QIO with IOLOCKBUF and PEEK
    for 4 bytes.  The 4 bytes contains some consistency info and a length
    of the actual message.  So we wait for at least 4 bytes, peek to get
    the actual data length and then issue a formal read QIO to get the
    message.
    
    The problem is that when the process exists (usually abnormally)
    OpenVMS
    places the process in an RWAST.  I traced this down and found the RWAST
    was called from SYS$RUNDWN as part of deassigning the channel on the
    UCX (BGx) device. Even though VMS cancels the I/O request, the I/O
    does not complete hence the RWAST.  That is the bug and this is 100%
    reproducible.  The bug is on both VAX and Alpha. I happen to have
    Digital TCP/IP services installed on a DEC 3000 Model 500 running
    OpenVMS V6.1.  TCP/IP V4.1 ECO 2 is installed.  I have ECO 4 but
    problem.  The code
    snippet follows:
    
    
    XIO:    $QIO    EFN=60,-                ; queue four byte read to
    "PEEK"
                    FUNC=IO$_READLOCKBUF,-  ;   at the data in the buffer
    to
                    IOSB=PEEK_IOSB,-        ;   obtain the message header.
                    ASTADR=DO_MULTI_IO,-    ; DO_MULTI_IO AST is delivered
                    P1=MESSAGE_LEN,P2=4,-   ;   when the "PEEK" read has
    been
                    P4=UCX$M_MSG_PEEK       ;   been satisfied
    
    
    
    ;++
    .SBTTL  NET$QIO routine (asynchronous form)
    ; This is the asynchronous form of the NET$QIO call. The NET$QIO
    routine's
    ; logic must be invoked in an application to obtain the message length
    and
    ; to serialize any possible asynchronous I/Os queued via calls to
    NET$QIO.
    ;--
    ;--
            .IF NDF ALPHA
            .ENTRY  NET$QIO,^m<R2,R3,R4,R5> ; preserve R6 w/
    {EN/DIS}ABLE_ASTS
            .IF_FALSE
            .CALL_ENTRY     LABEL=NET$QIO,PRESERVE=<R2,R3,R4,R5>-
                            HOME_ARGS=TRUE,MAX_ARGS=QIO$_NARGS
            .ENDC
    
            MOVAL   -(SP),R0                        ; stack space for VM
    address
            REMQUE  @LOOKASIDE+HEAD,(R0)            ; get argument list
    storage
            BVC     10$                             ; was the request
    satisfied?
    
            $LIB_GET_VM_S   -                       ; get P0VA space to
    store
                    number_of_bytes=#XIO.K_LENGTH,- ;   the QIO argument
    list
                    base_address=(R0)
           BLBS    R0,10$                          ; success? continue
            RET                                     ; return with error
    status
    
    10$:    MOVL    (SP),R0                         ; get P0VA allocation
    address
            MOVC3   #<QIO$_NARGS+1>*4,-             ; copy argument list
                    (AP),XIO.R_ARGS(R0)
    
            CLRQ    @QIO$_IOSB(AP)                  ; ZAP the IOSB's
    contents
            INSQUE  @(SP)+,@QIO_HEADER+TAIL         ; insert at tail of
    queue
    
            .IIF DF,ALPHA,  .PRESERVE ATOMICITY
            BBSS    #QUEUE_PEEK,IO_STATE_MCH,20$    ; was the "PEEK" I/O
    queued?
            .IIF DF,ALPHA,  .NOPRESERVE ATOMICITY
    
            MOVZWL  QIO$_CHAN(AP),XIO+QIO$_CHAN     ; get socket channel
    number
            $QIO_G  XIO                             ; queue the "PEEK" read
            RET                                     ; return to caller with
    status
    
    20$:    MOVZWL  #SS$_NORMAL,R0                  ; yes!  say I/O queued
    OK!
            RET                                     ; back to the user
    
    The routine above merges the static QIO data structure found at label
    XIO
    with a program's QIO arguments.  The AST routine is never disturbed. By
    the way, I have placed a breakpoint on that AST routine and it is never
    called. Don't worry about the actual logic of the above routine, the
    operative code is the simple #QIO_G XIO that is being invoked.