"Service Transport TCP is busy" (5485)

[ERPgal]

This one has me scratching my head. I'm not sure where to start.
This happens whenever anyone logs into the application.

"Service Transport TCP is busy" (5485)

Any suggestions?

 

[ERPgal]

Does anyone know where the Socket Server is and how to set it? I ran the following nestat command and found that the port is in use by something else.

I need to use a different port number, but I do not know how or where to set it.

cmd: netstat -an | findstr 5485

 

[TomBascom]

You need to change the -S startup parameter. It might be either a number (5485) or the name of a port. If it is a name then it is being translated by looking it up in /etc/services.

 

[ERPgal]

You need to change the -S startup parameter. It might be either a number (5485) or the name of a port. If it is a name then it is being translated by looking it up in /etc/services.

Tom, the mfgsys.pf file's -S value = 63.
I also opened and looked at all the *.pf file's on the DLC and not a single one has a -S value equal to 5485; some port numbers vary in some files, but they all are numeric, not alpha.

 

[TomBascom]

What OS is this and what version of Progress?

I think you may be confusing -s with -S. Case matters. 63 is a common, albeit obsolete, value for -s (lower case).

-S may not be in a .pf file -- it could also be on the command line. You could use "ps -ef | grep _mprosrv" to check and see what is actually specified on the command line (assuming that the server is some UNIX variant).

 

[ERPgal]

Tom,

The database version is as follows

Database Version : PROGRESS Version 9.1D0920 as of Tue Oct 19 20:04:28 EDT 2004

Progress is installed on a Windows 2003 Server SE SP2

Here are the contents of my .pf file:

-Mm 4096 -mmax 4000 -Bt 200 -s 63 -yy 1970 -stsh 31 -inp 12288

I just made the following change about an hour ago:

-Mm 4096 -Mn 73 -mmax 4000 -Bt 200 -s 63 -yy 1970 -stsh 31 -inp 12288

 

[tamhas]

Nowhere here are you showing a value for -S. Is this client/server or are you running self-service ChUI clients on the server?

That 5485 is just the error number, btw.

 

[ERPgal]

Nowhere here are you showing a value for -S. Is this client/server or are you running self-service ChUI clients on the server?

That 5485 is just the error number, btw.

I am connected to the actual server via a Remote Desktop Connection.


Progress is the backend DB for Vantage.
Vantage's -S parameter is set in a .MFG file
The connection options references -S and it looks like this:

ConnectOptions=-N TCP -H vanserv1 -S 6100 -ld MFGSYS

Net stat shows that this TCP is Listening on this port.

 

[TomBascom]

9.1D. Ancient. Obsolete. Unsupported. Upgrade.

It sounds like you have found where -S is being set for at least one half of the conversation. You need to make sure that all of the clients and the server are using the same port and that no other process is.

Is this .mfg file a client parameter file or a server file? Or both? (Whatever it is it is a Vantage thing not a Progress thing.)

You can check to see what port the server is using by looking in the .lg file. Each time you start the db the current values of server startup parameters are written to the log. Verify the -S port by looking at the last startup sequence.

 

[ERPgal]

No offense Tom, but this DB just seems like crap. We were considering upgrading the ERP solution and that would mean upgrading the DB, but we must consider moving to a completely different ERP solution and Database.

The final insult is this error message. It popped up all of a sudden. After a week of pulling my hair out, there is no solution in sight.




" msgopen:unable to open message file: PROMSGS "

The file is there but has a bunch of funky, alarming messages inside. There is no record of when these errors happened.

%gSYSTEM ERROR: Maximum key length exceeded. (59) %GSYSTEM ERROR: fmsrt - invalid data type. (60) %LBackward scan (61) %GSYSTEM ERROR: fmprnt - invalid data type. (62) %gSYSTEM ERROR: Input data too large, try to increase -s or/and -stsh. (63) %GSYSTEM ERROR: fminpt - invalid data type. (64) 010568%gSYSTEM ERROR: copditm -- maxdlen, data item too large, try to increase -s%GSYSTEM ERROR: fmeval: bad data type for function %d. (66) %LBlock alignment max # %d shifts of %d size (67) %gSYSTEM ERROR: fmprnt -- maxdlen. (68) 010569%gSYSTEM ERROR: Error in decimal expansion. Destination not large enough t** On DOS, the DOS statement must be used. (70) ** The value input for %s is not valid. (71) ** %s is ambiguous with %s.%s and %s.%s (72) %GSYSTEM ERROR: bfcr called with no template. (73) ** Value %s cannot be displayed using %s. (74) ** Decimal point appeared more than once in numeric input. (75) ** Invalid character in numeric input %c. (76) ** Sign appeared more than once in numeric value. (77) ** Value too large for integer. (78) ** Year is out of range or 0. (79) ** The month of a date must be from 1 to 12. (80) ** Day in month is invalid. (81) ** Starting position for SUBSTRING, OVERLAY, etc. must be 1 or greater. (82)

 

[tamhas]

The PROMSGS file isn't a list of errors on your system. It is a list of all possible error messages so that the application can just display error 1001, for example, and it will come up in the appropriate language for the site.

The error message you are seeing is telling you that either someone changed the permissions on the file or you have an incorrect environment variable or an incorrect setup. I presume this is not something that has been going on all along, so the obvious question is what changed and under what conditions are you getting it.

Don't blame Progress or the ERP vendor for the current performance and behavior. You just need to get things set up correctly and tuned and vaguely modern and it would be a day and night difference. The same would be true of any application and any technology you would purchase. It is the equivalent of an old car with water in the gas tank, never tuned for 100,000 miles, dirty oil and air filters, and wondering why it doesn't go like a race car.

Perhaps you should conisder bringing in a consultant to get you set up properly and headed down the right path.

 

[TomBascom]

Umm, like Thomas said that isn't what PROMSGS is.

One reason that people sometimes get that message is virus scanners that lock files when the scan them. Those virus scanners also play havoc with backups. You may have a problem there too.

I can understand your frustration and it seems fairly obvious to me that you need some help. At the very least you need some training or mentoring or some such sort of thing. A good consultant would get your immediate problems taken care of pretty quickly. Doing it one frustration at a time via online forums is going to get old fast.

 

[ERPgal]

The PROMSGS file isn't a list of errors on your system. It is a list of all possible error messages so that the application can just display error 1001, for example, and it will come up in the appropriate language for the site.

The error message you are seeing is telling you that either someone changed the permissions on the file or you have an incorrect environment variable or an incorrect setup. I presume this is not something that has been going on all along, so the obvious question is what changed and under what conditions are you getting it.

Don't blame Progress or the ERP vendor for the current performance and behavior. You just need to get things set up correctly and tuned and vaguely modern and it would be a day and night difference. The same would be true of any application and any technology you would purchase. It is the equivalent of an old car with water in the gas tank, never tuned for 100,000 miles, dirty oil and air filters, and wondering why it doesn't go like a race car.

Perhaps you should conisder bringing in a consultant to get you set up properly and headed down the right path.

My issue is not with the tool itself. Coming from a techincal background, I understand that many software issues are a result of faulty configuration.

My concern is the lack of support that I have been able to get. This is a database that should be tried, tested and true. It has been on the market for years. Any lessons learned should easily be identifiable. It has taken over a week - and the problem has not been resolved.

We run a business here. A multi million dollar business and we also pay thousands for support. With other software systems, whether it be Oracle, DB2, SQLServer, if there is an error, there are tons of resources available to identify the cause and squash it.

I am having a hard time justifying why Progress is a good solution for us moving forward. Support is key! You telling me not to "blame" the software, surely does not help.

 

[ERPgal]

Umm, like Thomas said that isn't what PROMSGS is.

One reason that people sometimes get that message is virus scanners that lock files when the scan them. Those virus scanners also play havoc with backups. You may have a problem there too.

I can understand your frustration and it seems fairly obvious to me that you need some help. At the very least you need some training or mentoring or some such sort of thing. A good consultant would get your immediate problems taken care of pretty quickly. Doing it one frustration at a time via online forums is going to get old fast.

Thanks Tom, is there a website that can point me to excellent Progress consultants?

 

[TomBascom]

You might try this one

Insightful Articles, Free Downloads, Powerful Tools and Consulting Services for your Progress OpenEdge Databases.

http://www.wss.com

 

[tamhas]

So, where besides here are you going for support?

Progress' own technical support tends to be quite good. Do you have a case open with them?

Support from ERP vendors vary, but even when reasonably good in terms of the product it is often wanting a bit in terms of database tuning and performance issues. For that, there is a short list of acknowledged top consultants ... and Tom is one of them.

 

[ERPgal]

So, where besides here are you going for support?

Progress' own technical support tends to be quite good. Do you have a case open with them?

Support from ERP vendors vary, but even when reasonably good in terms of the product it is often wanting a bit in terms of database tuning and performance issues. For that, there is a short list of acknowledged top consultants ... and Tom is one of them.

We have a support contract with the ERP provider. But they don't know how to solve this and because of that they are unresponsive.

I was told in the summer that we cannot get direct support from Progress, and that we must go through our ERP provider. As a result, I did not attempt to contact Progress' Help Desk Support directly. They told me to download the Knowledgebase :lol:. I'll call them again and hope to get lucky.

 

[TomBascom]

Progress is most often used as an "embedded database" product. That is the case when you buy something from an application partner. In that situation the partner is responsible for support. That's part of the trade-off that partners make to earn their cut on Progress licenses and maintenance fees.

If you're paying fro support from the application vendor then they are indeed responsible. If they aren't providing adequate support you really ought to beat them up and demand your money's worth.

None the less I agree that it gives PSC a black eye. I think it would be in their interest to support you anyway and then go back to their "partner" and straighten them out -- unfortunately it doesn't work that way.

Having said all of that... as Thomas points out ERP (and other) vendors are notoriously bad at performance and scalability support. They usually do a decent job of supporting product functionality, after all they wrote it and they presumably understand the problem domain. But they often start small and some of their customer's outgrow them. When that happens they are like deer in the headlights... if they aren't simply roadkill that never even knows what hit them (an awful lot of them don't even know that they don't know what they are talking about...) PSC doesn't really have much of a professional services organization these days. They've got a bit but it is extremely expensive (even worse than me -- I'm merely very expensive) and, IMHO, not as good as the independents.

Anyhow, as I said, a consultant could come in, get you on your feet, do a little mentoring and get you going fairly quickly. Or you can hang out here, or at PEG or PSDN and try to bootstrap yourself.

 

[tamhas]

I'm an AP myself and have always provided 99.999% of support for our customers ... they like the single point of reference. Most of the time, I could provide the support on my own, but, as needed, I would open a support call with PSC on the customer's behalf. But, a couple of times over the last 20+ years we ran into issues where it became more effective for the customer to talk with PSC directly and PSC has never had an issue about that.

Which said, tuning is really a tech support issue. If there is a specific problem, they can address that, e.g., they could have clarified the PROMSGS issue, but overall tuning issues really tend to need an expert in the area ... or a lot of poking about one one's own with the help of forum friends.

 

[doom1701]

But they don't know how to solve this and because of that they are unresponsive.

Not to beat a dead horse, but that's your problem--and it may justify moving to another ERP solution. I've never worked with a solution that used Progress that included direct support to Progress--support was always through the ERP vendor. If that vendor doesn't have a solution for a DB issue, they are responsible for doing whatever it takes to get a solution.

It is a different thought process, especially for those of us that also develop apps for MS SQL Server. We have some third party products that work with our ERP system that use SQL Server. For those apps, I am expected to provide a licensed, working installation of SQL--the vendor just supports the application, and not the database solution.