by John Santo » Mon, 31 Aug 2009 12:12:51
In article <h7bsbg$3ka$ XXXX@XXXXX.COM >,
XXXX@XXXXX.COM says...>
The correct solution depends on whether VMS usernames are case-blind
or case-preserving (if those are the correct terms.) By case-blind,
I mean VMS doesn't care what case you use to specify a username, it
always works. In that case, it could either preserve the case you
specify in the submit, but always do case-blind compares when you
examine it, or it could standardize the case when you submit the
job, and standardize the case of the value for the /user=<value>
qualifier on show entry. If it is case-preserving, it should change
the case to match the way it is specified in the UAF, and then do
case-blind matching in show entry/user. (It has to check the username
parameter on the SUBMIT against the UAF to determine if it's valid,
and it does a case-blind compare, so all it has to do is use the
UAF version when creating the queue entry.)
I've never seen a VMS username that wasn't UPPERCASE, but maybe
that's because you need to use quotes to create a lowercase or
mixed case UserName, and I've never tried that.
The other possibility is case-sensitive usernames, which seems to
be the way show entry is acting, and which is clearly wrong and
a bug... VMS is not case-sensitive when you log in, and mail
(both local VMS mail and SMTP) explicitly treat user names
as case-blind.
(I bet this bug has been there forever, but no one noticed it
because with DCL parse-style set to traditional, DCL would always
upcase the username unless you quoted it, and people using $SNDJBC
just assumed they needed to upcase the username, or just never
noticed...)
--
John Santos
Evans Griffiths & Hart, Inc.