Conference vaxaxp::vmsnotes

209.0. "Process hangs in LIB$FIND_FILE and can't be stopped" by BIKINI::ADAE () Tue Feb 18 1997 13:31

Implementation                    =
    {
     [
     Name = VMS ,
     Version = "V5.5-2H4"
     ] ,
     [
     Name = DECnet-OSI for OpenVMS ,
     Version = "DECnet-OSI for OpenVMS Version V5.6B-11  5-DEC-1994 20:55:18.95"
     ]
    }

On a customer VAX/VMS V5.5-2H4 system the OFTP_POSTER process hangs somewhere
in the code of the routine LIB$FIND_FILE waiting for event flag 29 (Event flag
wait mask DFFFFFFF) at PC = 802A1C98, PSL  = 03C00004. The call frame on top is

Call Frame Information
----------------------
        Call Frame Generated by CALLS Instruction

Condition Handler       7FEAF524  00000000
SP Align Bits = 00      7FEAF528  2FFC0000
   Saved  AP            7FEAF52C  7FEAF61C
   Saved  FP            7FEAF530  7FEAF5E0
   Return PC            7FEAF534  0000DDFE ----------------------------------+
   .....                                                                     |
                                                                             |
                            Process activated images                         |
                            ------------------------                         |
                                                                             V
ICB       Start     End       Type            Image Name  Major ID,Minor ID
--------  --------  --------  --------------  -----------------------------
7FF8AEB0  00000200  00001DFF  MAIN            OFTP_POSTER  0,0
7FF8ADE8  00099800  000F47FF  GLOBAL     SHR  DECEDI$COMM_APPSHR  1,0
7FF8B700  0011E800  00135FFF  GLOBAL     SHR  VAXCRTL  4,3
7FF8ABA8  000F4800  0011E7FF  GLOBAL     SHR  MTHRTL  129,32780
7FF8B880  00066400  000997FF  GLOBAL     SHR  COBRTL  1,13
7FF8B8F0  00061400  000663FF  GLOBAL          CONVSHR  1,0
7FF8B960  00059600  000613FF  GLOBAL     SHR  FDLSHR  1,0
7FF8B9D0  0004C600  000595FF  GLOBAL     SHR  SORTSHR  2,28
7FF8BA40  00043C00  0004C5FF  GLOBAL     SHR  FORRTL  1,100
7FF8BAB0  0003B800  00043BFF  GLOBAL     SHR  LIBRTL2  1,12
7FF8BB20  0002D200  0003B7FF  GLOBAL     SHR  MAILSHR  1,0
7FF8BB90  00022E00  0002D1FF  GLOBAL PRT SHR  MAILSHRP  1,0
7FF8BC00  0001DA00  00022DFF  GLOBAL          RDBSHR  3,2
7FF8BC70  0001D800  0001D9FF  GLOBAL     SHR  RDMMSGSHR  0,0
7FF8BCE0  00001E00  000041FF  GLOBAL     SHR  SQL$INT  0,71
7FF8B7E0  00004200  0001D7FF  GLOBAL     SHR  LIBRTL  1,14 <-----------------+
7FF8C220  00177000  002233FF  MERGED     SHR  SQL$SHR  0,0
7FF8BF80  0022BC00  0022D5FF  GLOBAL     SHR  NCSSHR  16,7637828
7FF8BE30  00223400  0022BBFF  GLOBAL     SHR  LBRSHR  2,9
......

The hang occured when the routine was looking for a remote file
MHSX::COALBUAD:[300208620.RTS]*.RTS.

The 'session control port SCL$PORT$1208007F' shows an existing session 
owned by OFTP_POSTER using the transport port OSI$PORT_1_0208. This transport
port points to the Remote NSAP = 49::00-38:AA-00-04-00-03-E0:21 (LOCAL:.MHSX).
But the associated transport port on MHSX does not exist any
more.
	   
Further more, the 'session control port' was created at
1997-02-18-00:03:40. There is a corresponding accounting entry
on MHSX2 for a network process - user OFTP_ACCESS, default proxy access,
Start time: 18-FEB-1997 00:03:40.70, Finish time: 18-FEB-1997 00:04:25.89 -
which terminted abnormaly with 

           %SYSTEM-F-FILNOTACC, file not accessed on channel.


The open questions are:
=======================

a) why does 'session control port SCL$PORT$1208007F' still exist ?

	      This port should had been terminated at aprox. 00:04:26, when
              the network process aborted on the MHSX2.
              This was not the case, therefore the OFTP_POSTER did'nt receive
              this event and is still waiting for the response of the
              requested remote file access function.



b) To get rid of the OFTP_POSTER hang, the system has to be rebooted.
   Neither 'force to exit' system service nor STOP/ID leeds to an OFTP_POSTER
   termination.

   The process state before STOP/ID is

	Process status:  00141001   RES,WAKEPEN,PHDRES,LOGIN
	AST's enabled                KESU
	AST's active                 NONE


   After STOP/ID DELPEN is added.

   NCL> delete session control port SCL$PORT$1208007F
   is not accepted by NCL.
NCL>dele session control port SCL$PORT$1208007F
%NCL-E-CMLRCVFAILED, error receiving command request
-CML-E-EMAAPROB, error returned from VMS EMA agent
-SYSTEM-F-DEVNOTMBX, device is not a mailbox


	Is there another method do get rid of this process without reboot ?

c) Does LIB$FIND_FILE - or the underlaying RMS - have restrictions for
   remote file access ?
   I was told, the RMS system service manual states some notes for DECnet
   access restrictions


BTW: The MHSX2 system is
    Implementation                    =
       {
          [
          Name = VMS ,
          Version = "V5.5-2  "
          ] ,
          [
          Name = DECnet-OSI for OpenVMS ,
  Version = "DECnet-OSI for OpenVMS Version V5.6B-12 17-JAN-1995 22:04:58.20"
          ]
       }

   You're in the wrong conference -- you want the DECnet-Plus (OSI) or
   RMS notes conference.  HELP::DECNET-OSI_FOR_VMS, and VMSZOO::RMS_OPENVMS,
   respectively.  Given the continued existence of the port, I'd start by
   looking at the DECnet-Plus conference.

	--

   The version of OpenVMS involved is only supported if a prior-version
   contract is in place, and the version of DECnet-Plus is either in the
   same support status, or is entirely unsupported...