E8.4 - Submit-Command fails

[Karl Rohwedder]

Just to share my findings...

On E8.4 the SUBMIT command fails, if the /NAME qualifier is used and specifies a jobname, which is illegal filenamesyntax though a correct logfile is specified using /LOG.
E.g.:
submit/noprint/keep login.com/name="()()()"/log=login.log
Job ()()() (queue ZZW15_BAT_QUE_1_1, entry 383) started on ZZW15_BAT_QUE_1_1
ZZW15_Roh.
%%%%%%%%%%% OPCOM 9-DEC-2009 07:22:30.52 %%%%%%%%%%%
Message from user AUDIT$SERVER on ZZW15
Security alarm (SECURITY) and security audit (SECURITY) on ZZW15, system id: 57287
Auditable event: Batch process login failure
Event time: 9-DEC-2009 07:22:30.52
PID: 000003B1
Process name: BATCH_383
Username: ROHWEDDER
Process owner: [BO,ROHWEDDER]
Image name: $1$DKA300:[SYS0.SYSCOMMON.][SYSEXE]LOGINOUT.EXE
Posix UID: -2
Posix GID: -2 (%XFFFFFFFE)
Status: %RMS-F-SYN, file specification syntax error

regards Kalle

[Murali L.R.]

Hi,

Some observations..

If our current directory is sys$manager i.e.

$ sh def
SYS$SYSROOT:[SYSMGR]
= SYS$SYSROOT:[SYSMGR]
= SYS$COMMON:[SYSMGR]

and we try to submit our example com procedure then the command fails,

$ submit/noprint/keep ex.com/name="()()()"/log=m.log /noti
Job ()()() (queue SYS$BATCH, entry 62) started on SYS$BATCH
Job ()()() (queue SYS$BATCH, entry 62) terminated with error status
%RMS-F-SYN, file specification syntax error

OR

In general if we try to create a log file in SYS$MANAGER then the error comes..
_________________________________________________________

Where as if you specify correct directory specification for log qualifier by translating SYS$SYSROOT logical then it works fine.

i.e.

$ sh log sys$sysroot
"SYS$SYSROOT" = "USITY$DKB200:[SYS0.]" (LNM$SYSTEM_TABLE)
= "SYS$COMMON:"
1 "SYS$COMMON" = "USITY$DKB200:[SYS0.SYSCOMMON.]" (LNM$SYSTEM_TABLE)

Working conditions:

$submit/noprint/keep ex.com/name="()()()"/log=USITY$DKB200:[SYS0.SYSMGR]m.log /noti

Job ()()() (queue SYS$BATCH, entry 64) started on SYS$BATCH
Job ()()() (queue SYS$BATCH, entry 64) completed

$submit/noprint/keep ex.com/name="()()()"/log=USITY$DKB200:[SYS0.SYSCOMMON]m.log /noti
Job ()()() (queue SYS$BATCH, entry 65) started on SYS$BATCH
Job ()()() (queue SYS$BATCH, entry 65) completed


$ submit/noprint/keep ex.com/name="()()()"/log=USITY$DKB200:[SYS0]m.log /noti
Job ()()() (queue SYS$BATCH, entry 66) started on SYS$BATCH
Job ()()() (queue SYS$BATCH, entry 66) completed

Or even if we specify other directory also it works fine:

$ submit/noprint/keep ex.com/name="()()()"/log=USITY$DKB200:[murali]m.log /noti
Job ()()() (queue SYS$BATCH, entry 68) started on SYS$BATCH
Job ()()() (queue SYS$BATCH, entry 68) completed

Regards,
Murali

[Jon Pinkley]

I think the point was that something that works on 8.3 does not work on E8.4

I just tried this on an Alpha 8.3 system with patches current as of Nov 25, 2009.

This was run from the SYSTEM account.
Default: SYS$SYSROOT:[SYSMGR]
LGICMD: LOGIN

Login.com was the standard template login with some instrumentation added in the BATCH specific section.

See attachment.

While this type of regression may seem benign, it is an indication that some change was made where there were unintentional side effects. Perhaps the underlying cause is not in the submit code, it may be in some service that will affect other things besides the submit.

P.S.

I was surprised at the results on 8.3, it appears that the login.com is executed twice. Perhaps once for each element of the sys$sysroot logical name.

Just to be sure that this wasn't caused by sys$sylogin.com, I put an EXIT at the top of that command file. Same results, so it was not the sylogin.com.

Jon

[Hoff]

Looks like somebody tightened up the rules in a parser a notch or two too far, and skewed the behavior away from the documentation:

Names the job (and possibly the batch job log file). The job name
must be 1 to 39 alphanumeric characters. If characters other than
alphanumeric characters, underscores (_), or dollar signs ($)
are used in the name, enclose the name in quotation marks (" ").
The default job name is the name of the first file in the job.

[Volker Halle]

Kalle,

have you raised a problem report for this problem ? If so, please ask for the PTR number and report it here for reference.

$ submit/name="()()()"/log=login login.com/hold

Works fine on V8.2. SUBMIT/HOLD also works fine on E8.4 and SHOW ENTRY/FULL shows the same information as on V8.2. If the job is being released, it works on V8.2 and fails on E8.4 with %RMS-F-SYN. So the submit code itself seems to be o.k., It's LOGINOUT (or the underlying services e.g. RMS), which seems to be failing.

As this is clearly a regression, i.e. something which has worked as documented before and now fails with E8.4, this needs to be fixed ! It doesn't make sense to try argue, HOW one could work around the problem by specifying different log file name strings on the SUBMIT command. If an upgrade breaks an application, this is a severe problem - especially if the behaviour is as documented.

Volker.

[John Gillings]

All that said...

yes this is a bug,
yes it should be reported
yes it should be fixed

BUT, when you've got rules about valid character sets contingent on which qualifiers are present, I'd STRONGLY recommend sticking with the most restrictive character set for all cases, regardless of what the documentation says.

Why set yourself up for failures such as reported in this thread?

(and don't be too surprised if the "fix" is a change in the documentation!)

[Karl Rohwedder]

Volker,

I reported this to the Email-adress vms84ftptr@hp.com, but received no answer so far.

regards Kalle

[Jon Pinkley]

What is interesting about this problem is that there seems to be in interaction with search list based directory specifications.

As far as parsing is concerned, this is all under Alpha 8.3 with OSD-2 system disk

OT$ sho proc/parse

11-DEC-2009 08:39:32.23 User: SYSTEM Process ID: 202029FA
Node: OMEGA Process name: "SYSTEM"

Soft CPU Affinity: off

Parse Style: Traditional
OT$ write sys$output f$parse("login.com")
SYS$SYSROOT:[SYSMGR]LOGIN.COM;
OT$ write sys$output f$parse("login.com","abc")
SYS$SYSROOT:[SYSMGR]LOGIN.COM;
OT$ write sys$output f$parse("login.com","[sysexe]")
SYS$SYSROOT:[SYSEXE]LOGIN.COM;
OT$ write sys$output f$parse("login.com","()()()")

OT$ write sys$output f$parse("login.com",,"abc")
SYS$SYSROOT:[SYSMGR]LOGIN.COM;
OT$ write sys$output f$parse("login.com",,"[sysexe]")
SYS$SYSROOT:[SYSEXE]LOGIN.COM;
OT$ write sys$output f$parse("login.com",,"()()()")
OT$ set proc/parse=ext
OT$ sho proc/par

11-DEC-2009 08:40:48.32 User: SYSTEM Process ID: 202029FA
Node: OMEGA Process name: "SYSTEM"

Soft CPU Affinity: off

Parse Style: Extended
OT$ write sys$output f$parse("login.com")
SYS$SYSROOT:[SYSMGR]login.com;
OT$ write sys$output f$parse("login.com","abc")
SYS$SYSROOT:[SYSMGR]login.com;
OT$ write sys$output f$parse("login.com","[sysexe]")
SYS$SYSROOT:[SYSEXE]login.com;
OT$ write sys$output f$parse("login.com","()()()")

OT$ write sys$output f$parse("login.com",,"abc")
SYS$SYSROOT:[SYSMGR]login.com;
OT$ write sys$output f$parse("login.com",,"[sysexe]")
SYS$SYSROOT:[SYSEXE]login.com;
OT$ write sys$output f$parse("login.com",,"()()()")
OT$

So it appears that parsing itself is probably not be the root cause, because on 8.3 passing "()()()" as a default of related specification causes the parse to fail anyway.

Kalle/Volker

If you turn on auditing for the system account, does the audit provide any useful information about the file specification RMS is complaining about?

RE:"Why set yourself up for failures such as reported in this thread?"

Isn't one of the main reasons for field test to have people stress test things? I doubt Kalle uses such a construct in his production jobs, but it is always a good testing stratedgy to present the unit under test with abnormal conditions, and see how it handles these conditions. Now that this case has been found, it seems like a good candidate for part of the standard regression testing suite.

There is a lot of software that "works" correctly in the eyes of the person that did the programming, since many programmers only test their "enhancements" to see if the new functionality they have added works like they expected it to. Many times they are unaware of side effects they have created that cause other things to break.

BTW, I downloaded and watched the 8.4 field test presentation recorded on Dec 2, 2009(really just powerpoint and audio, but it is a .wmv file, 25 MB, 35 minutes in length). I felt it was worth the time listening to it. You can download the powerpoint and the .wmv from

http://h21007.www2.hp.com/portal/site/dspp/menuitem.863c3e4cbcdc3f3515b49c108973a801?ciid=50a3545d05ee4210VgnVCM200000a460ea10RCRD

Slide 6 discusses reasons for a Field test, The first and the second bullets:

Increase Quality

o We can't imagine all the ways people will use OpenVMS!

Recieve Feedback on Features/Functionality

o Avoid "Works as coded"

[Ian Miller.]

The bug report has arrived at HP :-)

[Karl Rohwedder]

Since HP knows the bug and the fix had to come from HP I close this thread.