HP OpenVMS Systems

ask the wizard
Content starts here

Passing off FTP Connection?

» close window

The Question is:

TCP/IP V5.0A - ECO 3
Is there a way to relate an FTP TCPIP socket (i.e. BG device) to the child
 process (i.e. TCPIP$FTPCnnnn) which supports it ?
shows the socket to be owned by the FTP service process TCPIP$FTP.
tells you lots about the socket from a TCPIP perspective.
tells you all you might wish to know about the child process.
Is there a way to tie these entities together, so that if (e.g.) there is a
 rampant TCPIP$FTPCxxx process it can be related to a device, thence to a
 socket & finally to a remote client which can be dealt with ?

The Answer is :

    Not exactly and not really reliably -- and not supported.
    As you have discovered, the BG device is owned and operated by the
    FTP server process, which communicates with the child process via
    On a system which has numerous FTP connections, you can -- with
    reasonable confidence -- expect that the BG device and corresponding
    mailbox will occupy adjacent channel slots in the FTP server processes
    channel table -- note that this is probably not true for the first few
    FTP connections!.  So, looking at the open channels for the child
    process in question, determine the child's mailbox -- the last open
    channel; with the highest MBA mailbox unit number.  For example:
    SDA> show proc/chan/ind=37
    Process index: 0037   Name: TCPIP$FTPC00003   Extended PID: 20200337
    Channel  Window           Status        Device/file accessed
    -------  ------           ------        --------------------
      00F0  80DD2180                        $1$DKA0:[VMS$COMMON.SYSLIB]TCPIP$ACCESS_SHR.EXE;1 (section file)
      0100  00000000                        MBA39:
      0110  00000000                        MBA38:
      0120  00000000                        MBA1102:
    You are interested in MBA1102: here.  Now look at the channel list
    for the TCPIP$FTP process:
    SDA> show proc/chan/ind=21
    Process index: 0021   Name: TCPIP$FTP_1   Extended PID: 20200121
    Channel  Window           Status        Device/file accessed
    -------  ------           ------        --------------------
      00E0  80DD2180                       $1$DKA0:[VMS$COMMON.SYSLIB]TCPIP$ACCESS_SHR.EXE;1 (section file)
      00F0  80DD71C0                       $1$DKA0:[VMS$COMMON.SYSLIB]UCX$IPC_SHR.EXE
      0130  00000000             Busy       BG22:
      0140  00000000                        MBA38:
      0150  00000000                        MBA39:
      0160  00000000                        MBA40:
      0170  00000000             Busy       BG2135:
      0180  00000000             Busy       BG2145:
      0190  80DD1DC0                        $1$DKA0:[CLUSTER.SYSEXE]RIGHTSLIST.DAT;1
      01A0  00000000                        BG243:
      01B0  80FA44C0                        $1$DKA0:[TCPIP$FTP]TCPIP$FTP_ANONYMOUS.LOG;1
      01C0  00000000                        MBA1104:
      01D0  00000000             Busy       BG2141:
      01E0  00000000                        MBA1102:
      01F0  00000000                        BG2148:
      0200  00000000                        MBA1106:
    Note the BG device immediately preceeding the other end of the mailbox
    is BG2141:, this is probably the corresponding device.  Since the BG
    device will always be opened first, it will always have a lower
    channel slot than the corresponding MBA device. As can be seen from
    this display, these are not necessarily adjacent. In this example,
    MBA1104: and BG2145 are a pair. In a "steady state" system -- where
    the set of permanently open channels has settled down -- the BG/MBA
    pair will probably be added to the end of the open channel list.
    Note that the Wizard has deliberately left out details of finding the
    relevant processes in SDA. If you don't know how to do that without
    being told, then you shouldn't be playing with this stuff.
    Note that this entire implementation and the channel assignment
    algorithm is entirely undocumented and unsupported, and is subject
    to change without notice.

answer written or last revised on ( 1-JUL-2003 )

» close window