Kbase 33415: Investigating Errors 748 and 1334
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/05/1998 |
|
Solution ID: P3415
FACT(s) (Environment):
SCO OpenServer
Progress 8.x
Progress 9.x
Citrix MetaFrame (for Windows NT 4.0 Terminal Server)
SYMPTOM(s):
The server or the system has no more resources. Try a larger -n. (748)
Rejecting login - too many users for this server. (1334)
CAUSE:
Error 748 means that an attempt was made to exceed the limit for the number of users making a connection to the database.
Error 1334, means that either the limit of the servers spawned (Mn), or the limits imposed by the specific client environment setup have been reached, so a new server cannot be spawned for new client connection(s).
FIX:
1) The number of remote clients is limited by the lesser of: -n and the product of multiplying -Mn and -Ma. Check the settings of these parameters against the client connection requirements and the license agreement.
2) promon -> R&D (1: Status Displays, 3: Services). Make sure all the ports in the range from -minport to -maxport or the default ports used by Progress are free for connection and are not being blocked for any network device or ports communication software. Progress recommends a minport > 2000, as these are usually the ports reserved for O/S processes.
3) One explanation, specific to this particular environment, is that you could be hitting a limitation on SCO OpenServer relative to the number of TCP connections that can be made to that machine. The install default is 256.
4) In addition to checking the Services | Host files (outlined in P2916, "Corrective Measures for Error 748" ), if the clients are using .pf files to connect, it is worth verifying that:
A) The content of these are correct. Uppercase and lowercase entries are the usual culprits.
B) The location of these are correct, particularly when using mapped drives.
5) The machine that the Progress server is running on may have run out of processes or semaphores. In this case it may be possible to reconfigure the machine to provide more processes at a time and to provide more semaphores.
The size of the connection table could be the value being called into question:
usrtbl = the number of users (-n),
+ the number of servers (-Mn),
+ one(1) reserved for proshut.
Whatever size is computed for the connection table (usrtbl), that is the number of semaphores needed -- one per connection.
The kernel settings for number of processes that can run at a time, and number of semaphores provided should be examined. The change to support multiple semaphore sets in Version 8.3 and later, may be causing the system to behave differently. P2916 explains these in more detail, initial recommendations are:
Total number of semaphores allowed for the system [SEMMNS] (=10872?)
Max. number of semaphores allowed per semaphore identifier [SEMMSL] (=453?), SEMMNU (=SEMMNS)
The maximum size of a single shared memory segment [SHMAX] (=128MB)