DECC Library RTL and Documentation

[Tom Wetty]

Hello, 

I have four different questions for this software.

Can anyone give be a pointer to the DECC library functions? I am running an RX2660 server, using HP Basic,  on a Open VMS 8.4 Eco 3 environment and I am having great difficulty finding the documentation sub-set for these routines.

I am using my application to call a Federal Express server which is running Ship Manager for creating the carrier tracking numbers on packages.  

Additionally, Does anyone know if Open VMS requires any other special system configurations other than TCPIP V5.7 - ECO 3, and DECnet Plus to run these programs ? 

Finally, Is anyone aware of number of Sockets limits to the Ship Manager application ?  We are experiencing a problem where the number of sockets are approching 500 connections.  Is there a DECC function to close a socket until it is required at run time ?

[Tom Wetty]

Thanks for the quick reply.  Attached i s the guts of the calls from my application to the DECC routines. 

The programs that I am talking about  for "these programs"  as executing, is my application which is calling real time the DECC sub-routines.

This does work today.  It ran without issue for six years, and now as we approach over 500 user sockets (as reported by the Fedex Tech) the issue where the Fedex Server application  does not respond to the data requests from my application and the only thing that corrects the not receiving data issue is to restart the Fedex application service.

The topology consists of a single FEDEX Server located an off site data center behind our firewall, which is the same data center with one of the seven OpenVMS servers (the other six servers are spread throughout the Domestic US).  Each of the OpenVMS servers call the service (application = Ship Manager) on the single FEDEX Server.  The logic flow is open a connection to the Fedex Server,  Send data to the fedex server, Receive data from the fedex server.

The additional external logicals are as follow:

(LNM$GROUP_001045)

"WMS$$FDX_INIT" = "INIT"

"WMS$$FDX_IP" = "10.161.35.18"

"WMS$$FDX_METER" = "475064"

"WMS$$FDX_PORT" = "2000"

[John Gillings]

Tom,

   There's a SYSGEN parameter CHANNELCNT, with a default of 512. It limits the number of I/O channels you may open simultaneously. Each socket will consume one channel.

To check your value

$ MCR SYSGEN SHOW CHANNELCNT

If "Current" is at the default value, 512, then it will definitely limit you to around 512 sockets.

To update the value, have your system manager edit SYS$SPECIFIC:[SYSEXE]MODPARAMS.DAT and add a line like:

MIN_CHANNELCNT=2048   ! Allow Ship Manager to exceed 500 sockets Tom Wetty 12-Oct-2012

then execute AUTOGEN, review any other consequential parameter changes and reboot the system. 

(I've never seen conclusive evidence that allocations should be on powers of 2, but it seems to be the tradition).

[Hein van den Heuvel]

To check John's suspicions, aim SHOW PROC/CONT at the process and hit the Q character.

That will bring up a Quota display. Look for the line :  # open files remaining ...

Further details about actual channel usage can be found with ANALYZE /SYSTEM.

Again 'aim' for the process this time with SET PROC/IN=.. or SET PROC "your process name here"

And request SDA> SHOW PROCESS /CHAN

I looked at fedexcomm.TXT 43 KB

Free advice? (worth every penny right?) ... Ditch it.

Clearly this module begs to be (re)written in C directly, as every other line is related to calling C functions.

What value is BASIC offering other then easy parameters/variables for strings?

Good luck,

Hein

[Tom Wetty]

I appreciate the assistance.  However the number of users being 500 is not on the OpenVMS clients but on the Windows single server that I believe to be the problem.  We eliminated about 40 users on the OpenVMS side and the problem seems to have vanished.  Is there a way to adjust channels on XP ?

I do not believe adjusting the OpenVMS channels will allievate the problems.  I do not have an C or C++ licenses or compilers so that is not an option either.

[Hein van den Heuvel]

>> I do not believe adjusting the OpenVMS channels will allievate the problems. 

It doesn't matter what you believe.

Just look. Trust but verify,  as per earlier reply

>> I do not have an C or C++ licenses or compilers so that is not an option either.

Well, that's too bad isn't it.

IMHO calling CRTL routines directly, whiel likely to work, is a supported setup.

I do not believe ( :^) ) that calling the CRTL routines directly will be an issue.

The program largely works right? But why take the risk?

Cut out the middleman... call TCPIP services directly.

Use its data defintions (TCPIP$INETDEF.BAS)

http://h71000.www7.hp.com/doc/82final/6529/6529pro.html

http://h71000.www7.hp.com/doc/82final/6529/6529pro_012.html#socket_ref

Hein

[Tom Wetty]

Which server am I to this on ? 

There are seven of client VMS servers here and all are production.

The error has not happened since we reduced the number of users and the number of sockets.

[GuentherF]

Hi Tom!

"We are experiencing a problem where the number of sockets are approching 500 connections."

As has been asked before...what kind of problem and detected where? OpenVMS side? FEDEX server side?

Any error message?

And the "500 connections" are on the FEDEX server? Or the some of connections from all the production servers?

To fix "the problem" by just "shooting" connections is wishful hope for a quick fix.

/Guenther

[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