- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Programmatically enumerate open sockets
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-06-2008 01:10 AM
тАО11-06-2008 01:10 AM
SolutionOn re-reading this thread, I see that you are new(ish) to VMS, so I might not have been as helpful as I could've. Please see attached for an example of what Steven S was talking about. (Or if I'm wrong, I'm sure he'll correct me with his version.)
I would've given a more complete version but this has honestly taken over two full days and (unlike the IMM team that have cost centres galore - how's gSOAP going btw) I can't spend anymore "free" time on it :-(
Yes, I did imply that this was easy, and I stand corrected. Moving forward, here are some issues you should be aware of: -
. This example looks specifically at the BG driver. While Multinet and TCPWare both support the BG driver they also have other "lesser" drivers that are probably being used for Telnet, or FTP and so on. I don't have priv on DEATHROW to test it but maybe Richard W will give it a go?
. I successfully tested this on Alpha VMS 7.2-2 UCX 5.1 with no (visible) ill effects. Please be aware that with VAX/VMS 6.2 UCX 4.1 all your Telnet sessions stop working :-( Check the supportability of assigning an additional channel to a BG device that doesn't have ucx$c_share set.
. I haven't bothered with the IPv6 code for socket names but that won't be hard.
. I don't get IP address returned for Telnet connections for some reason?
. Full duplex close option doesn't seem identifyable
. I don't know if there is a ACP/QIO Stats call to get the number of I/Os bytes etc? a la mode de $UCX SH DEV/FULL
. Maybe this should all be done by walking some UCB chain?
OTY (or anyone else)
Cheers Richard Maher
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-10-2008 08:04 AM
тАО11-10-2008 08:04 AM
Re: Programmatically enumerate open sockets
Regards,
chorneck
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-10-2008 08:45 AM
тАО11-10-2008 08:45 AM
Re: Programmatically enumerate open sockets
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-11-2008 02:55 PM
тАО11-11-2008 02:55 PM
Re: Programmatically enumerate open sockets
> I don't have a COBOL compiler on my systems,
You should get out more :-)
> so I can't test Richard Maher's program
> on TCPware or MultiNet.
If anyone has SHARE privilege on the Deathrow cluster, I have put a copy of the code, and built an executable on GEIN: -
DISK$USERS:[USERS.TIER3]SOCKET_SCAN.EXE
Richard, could you also please tell me/everyone the API for getting this sort of statistics information from the socket: -
Total buffer alloc 0 0
Total buffer limit 70080 70080
Buffer or I/O waits 0 0
Buffer or I/O drops 0 0
I/O completed 5 23
Bytes transferred 148 1219
Cheers Richard Maher
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-18-2008 08:28 AM
тАО11-18-2008 08:28 AM
Re: Programmatically enumerate open sockets
The HP TCP/IP Services guide seems to suggest that it actually closes the port and clears all pending I/O operations if I am understanding this correctly.
To quote a bit...
After all communication is completed, use the $DASSGN system service to free an I/O channel. A $DASSGN operation executed on a channel associated with a network pseudodevice does the following:
* Ends all pending operations to send or receive data at $QIO level ($CANCEL system service).
* Clears the port associated with the channel. When executing the $DASSGN system service for TCP sockets, the socket remains until the connection is closed on both the local and remote sides.
* Ends all communications with the network pseudodevice that the I/O channel identifies.
* Frees the channel associated with the network pseudodevice. An I/O channel can be deassigned only from an access mode equal to or more privileged than the access mode from which the original channel assignment was made.
Does anyone have any insight on this? Am I just misunderstanding how this program is working?
Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-18-2008 03:36 PM
тАО11-18-2008 03:36 PM
Re: Programmatically enumerate open sockets
The HP TCP/IP Services guide seems to suggest that it actually closes the port and clears all pending I/O operations if I am understanding this correctly."
I have an application that hands off accepted connections to worker processes, which involves the listener process setting the socket shared and deassinging the channel after the worker has assigned its own channel to the BG device. Normally, rundown operations on devices are only triggered when the last channel is deassigned.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-19-2008 07:42 AM
тАО11-19-2008 07:42 AM
Re: Programmatically enumerate open sockets
1) I discovered that executing QIO requests on BG* devices that are owned by the TCPIP Ancillary Control Process is a bad idea. It seemed to cause random freezes in TCPIP services and no one else could log into the node via Telnet or SSH until the node was rebooted. Therefore, I put a check in so that the code does not execute the QIOW requests on devices where Owner PID == ACP PID.
2) Once I worked around problem 1, I discovered that Richard was right about the Telnet sessions. For some reason, I cannot seem to get their IP Addresses. SSH sessions are another story. I was able to get their addresses, but the end result was that the SSH sessions that I was able to retrieve information for stopped working. Apparently, the SSH sessions don't handle QIO requests well either.
Thank you to everyone for all the help!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-20-2008 01:56 PM
тАО11-20-2008 01:56 PM
Re: Programmatically enumerate open sockets
Short of opening a formal support call, you'd need someone with Richard Whalen's level of detailed knowledge to tell you, or access to the VMS sources for $UCX SHOW DEV
Cheers Richard Maher
PS. When you find out, please report back :-)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-26-2008 11:35 AM
тАО11-26-2008 11:35 AM
Re: Programmatically enumerate open sockets
The closest analogy is the MBA device, mailboxes, where you have to use a specific system call, CREMBX, to clone from MBA0 (yes, another template UCB device) before you can open a channel to it. While I won't swear to it, I think BG devices are similar except I don't know how to force a clone.
If you really created one, you could maybe see WHICH BG you got. Doing it that way means you get a fresh BG and don't have to try to share one. You also would then avoid interfering with arbitrary BG devices engaged in protocol exchange operations.
Or was that too simple-minded for what you were really looking at?
- « Previous
-
- 1
- 2
- Next »