VMS V8.3 Sysgen> DEVICE_NAMING parameter

[Richard J Maher]

Hi,

Saw what could be intersting behaviour the other day. On an 8.3 machine with the Device_Naming parameter set to the default zero, there were oodles of _TNA: device with 5 digit names that started annoying a whole lot of code that expected a maximum of 9999.

To me, it looks like a bug 'cos bit 1 is not set so the "new" rules should not come into affect but, going forward, would setting Device_Naming to 4 or 5 solve the problem?

Cheers Richard Maher

[Karl Rohwedder]

According to the help:

DEVICE_NAMING

(Alpha and I64) DEVICE_NAMING is a bit mask indicating whether
port allocation classes are used in forming SCSI device names.

this parameter has nothing to do with TNA devices. TCPIP V5.6 introduced the higher limit (from the V5.6 release notes):

1.11 TELNET Server Device Limit

The TELNET server is no longer limited to 9999 sessions or
TN devices.

regards Kalle

[Richard J Maher]

Hi,

As device drivers that support 5 digit (or up to 32767 devices) appear to be being trickled thru by HP as releases come along, you may wish to consider setting this parameter to 4 until you know if there is an issue.

Regards Richard Maher

$ mc sysgen
SYSGEN> HELP SYS_P DEVICE_NAM

Sys_Parameters

DEVICE_NAMING

(Alpha and I64) DEVICE_NAMING is a bit mask indicating whether
port allocation classes are used in forming SCSI device names.

Following is the bit definition:

Bit Definition

0 If 1, enable new naming.

1 Must be 0. This bit is reserved for use by HP.

2 If 1, cloned device unit numbers wrap after 9999.

[STEPHEN CONWAY_1]

RE: "this parameter has nothing to do with TNA devices." - not any more.

TCP/IP version 5.6 uses sysgen param
DEVICE_NAMING, bit 2, aka "10K bit", to determine when device numbers wrap. This is true for both TNA and BG devices.

So yes, setting it to 4 or 5 will restore
the original behavior. You could argue that the sense of the bit is wrong, but someone must have decided that more people would be glad than would be upset (about having more devices).

The is a _completly unsupported_ way to set the highest BG unit number:

$ type TCPIP$ETC:sysconfigtab.dat
..........
net:
ovms_unit_maximum=0x7ffff
..........

[Volker Halle]

TCPIP V5.6 has a known problem with TELNET logins getting hung and not providing a Username: prompt, if the TNA device unit number exceeds 4 digits. LOGINOUT - being started on such a device - fails with %RMS-F-CHN, as can be seen through the login failure security audit/alarm.

As a workaround: set DEVICE_NAMING = 4, which will limit TNA (and other device) unit numbers to 9999 and prevent this problem from happening.

Volker.

[Hoff]

DEVICE_NAMING set to zero selects the new rules. Setting bit 2 in the bitmask selects the old rules and the old behavior; having bit 2 lit restricts devices to 9999 units.

"In the past, OpenVMS would never create more than 10,000 cloned device units, and unit numbers would wrap after 9999. This had become a limitation for some devices, such as mailboxes or TCP/IP sockets.

Starting with OpenVMS Version 7.3-2, OpenVMS will create up to 32,767 devices if the DEV$V_NNM bit is clear in UCB$L_DEVCHAR2 and if bit 2 is clear in the DEVICE_NAMING system parameter. This does not require any device driver change. However, programs and command procedures that are coded to assume a maximum device number of 9999 may need to be modified."

I'll toss some text into the next edition of the FAQ, as Mr Maher isn't the only one that has commented on this.

[Volker Halle]

The DEVICE_NAMING sysgen parameters is 'overloaded'. The individual bits control individual behaviour.

The 'new naming' mentioned in the SYSGEN help only applies to SCSI devices and port allocation classes and this is only controlled by bit 0.

Bit 2 is the '10k' bit and is not related to the setting of bit 0.

Volker.

[Accullise]

hi friends,

can anyone know vax phone problem in openvms8.3?

Vax phone utility doesn't work with TNA devices after 9999.

In 8.3,By default, bit 2 is cleared, and this allows the increase unit number to wrap at 32K.


If you want openvms phone utility you must wrap after 9999.

if you try to use the phone after 9999 the following error messages are coming..

*The persons terminal cannot be used as a telephone.

*%SYSTEM-W-NOSUCHDEV, no such device available


In 7.3-2 also having this problem if you have not wrap after 9999. By default it automatically wraps.


some more information abt this parameter please find the enclosed document.....


Regds,
Acullise

[Volker Halle]

Aculisse,

if you have a support contract with HP, please report this problem with the PHONE utility (probably as a low-priority call).

Volker.

[Accullise]

yes i have a support.

I have already logged a call regarding this issue. They didnt give a solution for that and they told me to set the DEVICE_NAMING to 5.\


Regds,
Acullise.

[David B Sneddon]

They DID give you the answer. The value of they suggest for the parameter will cause the unit numbers to wrap at 9999.

$ MCR SYSGEN HELP SYS_PARA DEVICE_NAMING

Dave

[Accullise]

why the VMS phone utility doesn't work after 9999 ?

Regds,
Acullise

[Volker Halle]

Acullise,

you have received workaround from HP to prevent the PHONE problem from showing up. A real solution would be to fix the PHONE utility ! You should explicitly ask HP to address the apparent problem in PHONE with TN device units numbers exceeding 4 digits.

Volker.

[Richard J Maher]

God bless you for being interested in why the phone utility doesn't like more than 4 digits! Feel free to continue but I have to close this thread so I don't keep getting e-mails about replies.

Good-luck.

Richard Maher

[Hoff]

Why does this happen? There's a device name limit within PHONE, and specifically within some device name parsing code. That's what this thread discusses.

Why does this happen? Because most folks aren't using PHONE, and nobody noticed the device name parsing error during the typical tests? (That this incompatibility has been around as it has been -- the device name change was a while ago -- certainly points to few folks using PHONE.)

Why does this happen? Because all businesses have resource limits and software development bandwidth limits, and businesses must prioritize what they can do with their software, and where they can recoup those investments. Ask HP to open-source PHONE, and somebody out here will fix it. Or move to Jabber or irc or such; to protocols and clients that are seeing more active development than PHONE is clearly receiving.

[Accullise]

Thank you friends....


regds,
Acullise

[Volker Halle]

Please also note that patch VMS83A_SYS-V0500 enables device unit numbers to increase up to 65472.

This feature can be prevented by setting bit 3 in DEVICE_NAMING. Unit numbers will then wrap after 32767.

Volker.

[Volker Halle]

Hi,

please also look at the following thread for the PHONE variant of this problem:

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1386301

Volker.