- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- DECC Library RTL and Documentation
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
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
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
10-16-2012 11:31 AM
10-16-2012 11:31 AM
Re: DECC Library RTL and Documentation
Hi Guenther:
The error experienced is always from the Fedex Server Side. There are no error messages except that it is noted that the audit trail of the communication between the OpenVMS client and the Fedex Server fails. The connection shows no receipt of data that is shown to be sent from OpenVMS to the Fedex Server.
for example normal functioning appears as follows: (for security reasons the meter is x'd out)
^^27-Sep-12 08:37 AM + Sending - '0,"50"1,"PID"498,"5xxxxx "1989,"04"99,""'40 <!! OpenVMS send
^^27-Sep-12 08:37 AM Received 0,"150"1,"PID"1000,"8.4.6"1000-2,"8.4.6"1000-3, <<!! Fedex Received to VMS
-7,"8.4.6"1000-8,"8.4.6"1000-9,"8.4.6"1989,"04"3128,"09-26-2007"3128-2,"09-26-2
8-5,"09-26-2007"3128-6,"09-26-2007"3128-7,"09-26-2007"3128-8,"09-26-2007"3128-9
2,"Fedex Broadcast Service"3129-3,"Fedex Communication"3129-4,"FedEx Global Shi
Sometimes, but not every time the TCP/IP timer runs out and and socket will automatically disconnect.
The 500+ connections are on the FEDEX side only. There are No Error messages from the RLT routine or the FEDEX server. The only way to reestablish communications is to restart the FEDEX Server application.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-16-2012 07:17 PM
10-16-2012 07:17 PM
Re: DECC Library RTL and Documentation
>> Which server am I to this on ?
>> There are seven of client VMS servers here and all are production.
Any two of them. Roll a dice. Just start looking already.
If the server on teh selected box hits more than 50% of the quota.. check the others.
30% of quota, check one more to be sure which way it is leaning.
If it does not come close, say 50 out of 500, then look for other causes.
Don't just talk about. Look.
You could have been done with all 7 already by now..
Hein.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-17-2012 05:56 AM
10-17-2012 05:56 AM
Re: DECC Library RTL and Documentation
I wish it were that easy.
Your absolutely correct, I could have been done already, however, there are corporate procedures and permissions to follow to upgrade any production server. There is no lab copy of the entire production environment.
I have no access to the FEDEX server and the logs that show the sockets open to the FEDEX server are not accessible by me and I am dependent on the FEDEX support tech to evaluate and supply this information.
Remember, reducing the amount of users from the OpenVMS side over 2 weeks ago; has resulted in no errors or remedial actions to affect the fedex server.
There is no anaylsis of the data which is available from the Fedex Tech to give me the VMS servers to which the 30-50% of the quota variants to which you recommend.
Let's take another approach, if the quota viloation is an error which I can monitor from the Client side or from OpenVMS, on the socket when sending data; what error messages would I be looking at that report the viloation that I would be able to email a message that would note the discrepency?
I am trying to work within a restrictive policy that has all but tied my hands and limits my response.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-17-2012 08:12 AM
10-17-2012 08:12 AM
Re: DECC Library RTL and Documentation
Unless I missed something here, it sounds like the 500 limit is on the FEDEX server side and not the OpenVMS side. Is this correct?
If so, then no amount of quota changes on the OpenVMS side will help other than to throttle down the total number of outbound sockets that you produce.
If you are running into the socket limit on the OpenVMS side, then we can examine the suggestions listed in previous replies easily and address them too.
Which side has the problem?
Dan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-19-2012 08:33 AM
10-19-2012 08:33 AM
Re: DECC Library RTL and Documentation
"Sometimes, but not every time the TCP/IP timer runs out and and socket will automatically disconnect."
If a process quickly creates new sockets and closes sockets the number of "hanging around" sockets increases. To avoid getting a new socket all the time there is a flag called REUSE_ADDR (sp?). It allows the process to re-use one of the dangling sockets.
This may help to keep the number of connections down.
/Guenther
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-31-2012 06:48 AM
10-31-2012 06:48 AM
Re: DECC Library RTL and Documentation
Sorry, got side tracked by other issues
abrscv
Yes you are correct the 500 user/socket limit "appears" to be the FEDEX server side. I say "appears" because I have no access to the actual program or server itself. As I stated previously it is a "black box" to the VMS side.
Guenther
You are closer to the issue than other contributors and I believe that your approach will have results, since limiting the number of connection sockets manually has a proven track record and definitive results.
So your instructions are noted.
Changing the production issue without permission is not possible at this time. Since the original VMS Basic program was written over 7 years ago, and there is supposedly a newer Fedex recommended data variant today, changing the older routine for it's own sake, would be a futile task. Once the upgrade is approved here, I will need to restructure the entire socket addressing design to reuse sockets and to limit them to transactions requiring the other Fedex server data only.
I do have have some questions.
Are unused sockets abandoned ? Once I open a socket if not every used again will it eventually close when the tcpip timer runs out ?
Do I need to specifically always have to follow communication protocol and issue a call to decc$gethostbyaddr and then a call to decc$send ? Will a call to decc$send only, open the socket ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-01-2012 08:58 AM
11-01-2012 08:58 AM
Re: DECC Library RTL and Documentation
The order is socket->bind->connect->recv/send->shutdown->close.
gethostbyaddr only translates an IP address into a host name and is therefore not required.
If a close has not been done then you can use a bind->connect to establich a new connection. If a close has been done you need to call socket first before the bind.
/Guenther
- « Previous
-
- 1
- 2
- Next »