DECC Library RTL and Documentation

[Tom Wetty]

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.

[Hein van den Heuvel]

>>  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.

[Tom Wetty]

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.

[abrsvc]

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

[GuentherF]

"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

[Tom Wetty]

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 ?

[GuentherF]

Yes, once the timer runs out the socket goes away. With SO_REUSEADDR a socket can be used again during this period.

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