Case name bug in $SNDJBC or SHOW ENTRY

[Jeffrey H. Coffield]

If you submit a batch job using the SJC$_USERNAME option where the username is lower case, a SHOW ENTRY/USER=xxx does not show the job. Also a SHOW ENTRY by the logged in user does not show the job. Doing a SHOW ENTRY/USER="xxx" does show the job but then other jobs submitted by the user thru DCL don't show.

[Volker Halle]

Jeffrey,

OpenVMS usernames can be case-sensitive since OpenVMS V7.1, see the following chapter in the OpenVMS V7.1 Release Notes:

4.8.1 Changes and Enhancements
The following note describes a change in behavior related to external authentication.

4.8.1.1 OpenVMS User Name Prompt Accepts Case-Sensitive Terminal Input

V7.1

You can enter a case-sensitive user name at the OpenVMS user name prompt if you enclose it in quotation marks. If you do not enclose the user name in quotation marks, LOGINOUT converts the user name to uppercase characters.

OpenVMS and LAN Manager user names are not case-sensitive. Therefore, quotation marks are not necessary if you enter an OpenVMS user name or a LAN Manager user ID. In future releases, external authentication may support other authentication services that allow case-sensitive user names.

You can restore previous behavior on your OpenVMS system by setting the forced uppercase configuration bit in the SYS$SINGLE_SIGNON logical name. (See the OpenVMS Version 7.1 New Features Manual or the Managing System Access chapter in the OpenVMS Guide to System Security for more information.)


The handling of a lowercase username passed into $SNDJBC, as you are describing it, is at least questionable. If the username in SYSUAF in not stored in lowercase, $SNDJBC should probably reject it as an invalid username.

All the other effects you've described are expected. DCL converts your command line to all uppercase (with traditional parsing turned on), if you don't quote the string.

Volker.

[John Gillings]

Jeffrey,

The behaviour you describe seems correct to me. As Volker has said, usernames are case sensitive, so the entry really is owned by a different username.

I agree with Volker that the $SNDJBC should have failed with NOSUCHUSER or equivalent.

What I'm more interested in is, what happens when/if the entry executes? What username does it run under? If it does run under the uppercase username, then THAT is a bug.

I note that the DCL SUBMIT/USER command uppercases usernames, even in quotes (yet another latent bug? What will happen if mixed case usernames are ever allowed?).

The other lesson to take away is that you need to be precise when passing string to system services. You can't trust system services to do friendly things like trimming blanks or upcaseing arguments.

[Jon Pinkley]

I reproduced the observation with Hunter Goatley's BAT utility, which accepts DCL commands on the command line, generates a command file, and submits it using the $SNDJBC system service. You can get this utility with source (in BLISS) here: http://vms.process.com/scripts/fileserv/fileserv.com?BAT

BAT accepts /USER=username, and validates that it is a valid username with the $GETUAI system service. It appears that $GETUAI is case blind. I would argue that this is incorrect behavior as well, but changing it would undoubtedly cause existing software to break. The documentation for $GETUAI has only this to say about the usrnam argument

"Name of the user about whom $GETUAI returns authorization information. The usrnam argument is the address of a descriptor pointing to a character text string containing the user name. The user name string can contain a maximum of 12 alphanumeric characters."

If an extended $GETUAI is ever released, it should have a flags field to control case behavior and to allow for longer usernames.

$SNDJBC appears to pass stuff straight through to the queue database as long as a case blind compare of the username exists (what I specifically tested was that a if username PINKLEY exists in SYSUAF, then as long as uppercase(username) .eqs. "PINKLEY ", then $SNDJBC will not complain. If a non-existent username is specified, then $SNDJBC returns "%RMS-E-RNF, record not found". What is stored in the QUEUE database is what was passed to $SNDJBC, not the uppercased value. At the time the entry is released, the username is uppercased (at least this is the default case on Alpha VMS 7.3-2). See attachment for reproducer.

This may be similar to the cause of the behavior reported in 'problem with "reply/user" on a specific user'

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

Unfortunately, the poster never responded to any of the suggestions, so we don't really know what the cause was in that case.

Jon

[Volker Halle]

Jeffrey,

as you can see from the previous replies, there seem to be lots of inconsistencies in the area of lowercase/mixedcase username handling.

I would strongly suggest, that you try to change your program to always use uppercase usernames with $SNDJBC, this will cause you less trouble.

If lowercase or mixedcase usernames are a requirement at your site, log a call with HP, but don't expect any quick solution !

Volker.

[Jeffrey H. Coffield]

Thanks to all for their comments.

I already patched my job submission module to (for now) upper case the username before calling $SNDJBC. Case senesitive usernames are something I would avoid. I can just imagine the help desk saying "How do you spell Joe?"

Is there any way to pass this on to HP other than opening a case?

[Robert Brooks_1]

Is there any way to pass this on to HP other than opening a case?

--

Formally? No.

Informally? Possible, if an HP employee
spots this and feels motivated to alert someone in VMS Engineering.

I'll point this out to someone, but logging a call is the absolute best way to guarantee that it'll get looked at.

As Volker said, however, don't expect quick resolution. V8.4 is being readied for field test, and I imagine that the pervasiveness of this can be so widespread that it would require a lot of investigation before any solution arose.

-- Rob