|
HP OpenVMS Systemsask the wizard |
|
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 ? $ SHOW DEV/FULL BGnnnn shows the socket to be owned by the FTP service process TCPIP$FTP. $ TCPIP SHOW DEVICE/FULL BGnnnn tells you lots about the socket from a TCPIP perspective. $ SHOW PROC/ALL TCPIP$FTPCxxxxx 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
mailboxes.
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.
|