MAXIMUM LIMIT OF BG DEVICES

[Ana M. García Olivencia]

Hi all.

I have a question about how to determine the maximum number of concurrent BG devices an OpenVMS system can have.

I think that this figure is determined by the 'net' subsystem parameter 'ovms_unit_limit', but I have read in other technical documentation that there is another way to see this value, through SDA:

$ANALYZE/SYSTEM
SDA>TCPIP SHOW INETCB/STAT
....
ACT/PEAK/MAX_SOCKET (xxx./yyy./zzzz)
....

The maximum number of sockets would be 'zzzz'.

The problem is that in my OpenVMS 7.3-2 system
'ovms_unit_limit' is 9998 and the MAX_SOCKET value from SDA is 32767.

However, in an OpenvMS 8.2 the'ovms_unit_limit' is 32766 and the MAX_SOCKET value is 10000.

And finally, in an OpenVMS 8.3, there is no 'ovms_unit_limit' parameter (at least, at the 'net' subsystem); only the 'ovms_unit_maximum' parameter to 0, and the MAX_SOCKET value is 10000.

If the above is true, can anybody explain the discrepancy between both values?.

Thanks in advance.

Regards.

Ana

[Hein van den Heuvel · Accepted solution]

CHeck out the recent discussion in comp.os.vms:
http://groups.google.com/group/comp.os.vms/browse_thread/thread/0c87cb1cf206a592#

It referes back to :

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1074590

See if that answers your questions?!

hth,
Hein.

[Wim Van den Wyngaert]

ovms_unit_limit" (currently set to 9998)

This is a status and not a config parameter.
It shows the calculated maximum number of concurrent BG device units
that can coexist at any given time.
You cannot modify this parameter.

Wim

[Ana M. García Olivencia]

Heim.

From the TCPIP 5.4 documentation, the 'ovms_unit_maximum'specifies the highest numbered device unit and you can specify a value from 9999 to 32767. The 'ovms_unit_limit' parameter I talked about in my post calculates its value from that parameter and 'ovms_unit_minimum', (and, yes, Wim, it's not configurable).

In my OpenVMS 7.3-2 system:

ovms_unit_limit=9998
ovms_unit_minimum=2
ovms_unit_maximum=9999

In my OpenVMS 8.2 system:

ovms_unit_limit=32766
ovms_unit_minimum=2
ovms_unit_maximum=32767

In my OpenVMS 8.3 system:

ovms_unit_maximum=0


In the three systems the value of DEVICE_NAMING parameter is 0.

If I have understood well, it seems that this parameter establishes an upper limit for the number of devices (with 0 value it would be 32767) but, in reality, is limited by the ovms_unit* values in 'net' subsystem. This would be for 7.3-2 and 8.2, but not for 8.3 where there is only 'ovms_unit_maximum' to 0 that I don't know what it really means (sorry I don't have access to HP docu in this moment). That would be the reason of the creation of 5-numbers BG devices.

On the other hand, I keep on not understanding the values from the SDA output.

Thanks.

Ana

[The Brit]

Ana,
The main reason for 5-digit mailbox numbers is that some apps use very large numbers of mailboxes, and 9999 just wasn't enough. (The increase to 32766 is quite recent).

Also, I don't know if a value of '0' for "vms_unit_maximum" automatically defaults to "maximum" (i.e. 32767), it might be safer to define it explicitly.

Dave

[The Brit]

Ana,
The main reason for 5-digit mailbox numbers is that some apps use very large numbers of mailboxes, and 9999 just wasn't enough. Processes which cant find an available Mailbox will go into a RWMBX state, and eventually it is not unusual for this to bring the system to a hang. Identifying the process which is representing the log jam can be difficult, and therefore these situations often result in a system reboot/forced crash. (The increase to 32766 is quite recent).

Also, I don't know if a value of '0' for "vms_unit_maximum" automatically defaults to "maximum" (i.e. 32767), it might be safer to define it explicitly.

Dave

[Andy Bustamante]

TCPIP 5.4 in VMS 7.3-2 introduces the performance kernel as an option. Enabling this options sets ovms_unit_maximum attribute to 32767, among other changes. The performance kernel is designed for multi CPU systems. See http://h71000.www7.hp.com/doc/732FINAL/TCP_RN/tcp_rnpro.html#scalable_enable.

In later versions of TCPIP, the performance kernel is the standard.


Andy Bustamante

[Hoff]

What might you be up to here? (I understand the immediate question; some background on why you're looking at this detail would be very useful to better targeting an answer. Either a direct answer, or a potential alternative to this approach.)

V5.4 had this mechanism as optional. V5.5 and later have this built in and (from the perspective of TCP/IP Services) enabled. In either case, the OpenVMS device_naming system parameter setting (also) controls the upper limit; the wrap at 9999 or at 32767.

With some added background, we might be able to provide a more specific answer to your question; to the particular problem you're working on here.

[Ana M. García Olivencia]

Thank you for all your answers.

>>>With some added background, we might be >>>able to provide a more specific answer to >>>our question; to the particular problem >>>you're working on here.

No, I don't have a problem; only I felt curiosity to know the reason of the discrepancies between the parameters values and the values shown through SDA.

With the information all of you have given to me I can understand it better.

Thanks again.

Regards.

Ana