Record-Not-Found when using SUBMIT/USER

[Robert Atkinson]

I have set up a new account for user MNB. One of our applications
issues a SUBMIT/USER=, but this is failing with RNF, even though the UAF
account exists on each node.

This is something I've seen before, but I can't remember what caused it and
how we corrected it. Any ideas?


Rob.

ALPHA_ROB$$ PIPE SH SYS /CLUS | SEA SYS$PIPE QUE,ALPHA,BETA,GAMNEW
OpenVMS V7.2-2 on node ALPHA 29-SEP-2003 10:54:13.85 Uptime 8 18:12:19
20800416 QUEUE_MANAGER HIB 9 694782 0 00:54:51.62 814
618
2080043A SMTP_ALPHA_01 HIB 4 119602 0 00:00:13.85 709
459
208004BC MONIQUE LEF 5 581 0 00:42:46.39 1305
89 B
OpenVMS V7.2-2 on node BETA 29-SEP-2003 10:54:14.49 Uptime 8 18:06:39
20A00422 SMTP_BETA_01 HIB 4 10208 0 00:00:02.02 664
413
OpenVMS V7.2-2 on node GAMNEW 29-SEP-2003 10:54:14.52 Uptime 8 17:59:44
20C0011E TCPIP$LPD_QUEUE HIB 4 53 0 00:00:00.03 246
116
20C00123 SMTP_GAMNEW_01 HIB 4 6879 0 00:00:01.03 501
226


ALPHA_ROB$$ UAF SH MNB

Username: MNB Owner: Mark Buckley
Account: ITDEVMT UIC: [310,14] ([ITDEVMT,MNB])
CLI: DCL Tables: DCLTABLES
Default: SY0:[USERS.ITDEVMT.MNB]
LGICMD: LOGIN
Flags: Restricted
Primary days: Mon Tue Wed Thu Fri
Secondary days: Sat Sun
No access restrictions
Expiration: (none) Pwdminimum: 6 Login Fails: 0
Pwdlifetime: 90 00:00 Pwdchange: 29-SEP-2003 10:10
Last Login: 29-SEP-2003 10:12 (interactive), (none)
(non-interactive)
Maxjobs: 0 Fillm: 100 Bytlm: 64000
Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0
Maxdetach: 0 BIOlm: 150 JTquota: 4096
Prclm: 4 DIOlm: 150 WSdef: 2000
Prio: 4 ASTlm: 250 WSquo: 4000
Queprio: 0 TQElm: 10 WSextent: 16384
CPU: (none) Enqlm: 2000 Pgflquo: 200000
Authorized Privileges:
GROUP GRPPRV NETMBX SHMEM SYSGBL TMPMBX
Default Privileges:
GROUP GRPPRV NETMBX SHMEM SYSGBL TMPMBX
Identifier Value Attributes
VISTAUSER %X80010016
CMS_READONLY %X80010012
CMS_USER %X80010011


ALPHA_ROB$$ SUBUSER SYS$LOGIN:LOGIN.COM /USER=MNB
%SUBMIT-F-CREJOB, error creating job
-RMS-E-RNF, record not found
ALPHA_ROB$$

[labadie_1 · Accepted solution]

Hello

This error message means the queue manager "sees" a different UAF, you should check, on the node with the process queue_manager, do
$ ana/sys
sh proc/id='pid_of_queue_manager/chan
see if the sysuaf is the one you suppose or another one.

Regards

Gerard

[Hein van den Heuvel]

The queue manager keeps SYSUAF (and RIGHTSLIST) open forever. So if conceivably someone coudl have put a freshly converted SYSUAF in place or set up a system wide logical to point to a shared SYSUAF after queuemanager was started.

an other way to verify is:

$ pipe show dev /file sys$system | search sys$input sysuaf
QUEUE_MANAGER 0000020B [VMS$COMMON.SYSEXE]SYSUAF.DAT;2

Cheers,
Hein.

[Robert Atkinson]

Hein/Labadie,
this is exactly what is was.

I had read this 'possible cause' on Google and dismissed it, as I 'knew' that we only had once version of SYSUAF.

After rethinking and checking, I realised that we convert SYSUAF every weekend, but hadn't rebooted the system.

Many thanks for your help.


Robert.

[Rich Hearn]

I know this is old, but it fit's my situation perfectly. Is there a way to change the SYSUAF/RIGHTSLIST being used to where the logicals now point to - without a re-boot? Such as stopping the QUEUEMANAGER and then re-starting it?

Thanks for any thoughts,
Rich

[Volker Halle]

Rich,

in a cluster with a common SYSUAF and queue-manager database, you can manually fail over the QUEUE_MANAGER to another node:

$ SHO QUE/MANA/FULL

Note the node names after /ON=(node1,node2)

If the QUEUE_MANAGER is not running on the first node in the list, issue a START/QUEUE/MANAGER command to move it to that node.

If it's running on the first node, temporarily move it to another node with $ START/QUE/MANA/ON=(node2). Don't forget to re-establish the original /ON=(node1,node2) list with another $ START/QUE/MANA/ON=(node1,node2) command afterwards.

On a standalone node, I'm not sure, whether there is any way to achieve this short of STOP/ID and $ START/QUE/MANA - but this will stop all your batch jobs and queues...

Volker.

[John Gillings]

Rich,

There's no mechanism to force all processes to switch to a new UAF and RIGHTSLIST. You can restart the queue manager as Volker has suggested, but it will kill any currently executing jobs.

Consider that the files are just a collection of records. There's nothing to stop you from writing a trivial (privileged) program or procedure which changes the records. Delete any (all?) in the old files that you don't want and add any from the new that you do want. The effect is almost the same as using a new file, but with potentially less impact on the running system.

[Hein van den Heuvel]

As per John you could for example for the original problem use a sequence like:

$open/read/share=write current new_sysuaf
$open/read/write/share=write old old_sysuaf
$read/key="MNB" current record
$write/symbol record old
$close current
$close old

Of course this can be done in a loop going over all records. If one goes that route, then one should do a
$read/key=&key/err=write_new old old_record
to see if the record existed in the old file and when deemed used issue:
$ write/update old record

The old_sysuaf and new_sysuaf suggeste logical names or text substitutes as needed.

Leaving the old file active, you'll obviously miss out on quota/priv adjustments, and the last loging date will be in the wrong place. New passwords do not matter for the job controller.

And yes, I have a tool to 'compare' two indixed files such as thise SYSUAF file and generate 4 file with 'new, old, before and after images' for records which differ.
Those files can then automatically be applied to sync live files.

Cheers,
Hein

[Volker Halle]

re: John,


You can restart the queue manager as Volker has suggested, but it will kill any currently executing jobs.


Note that the above is not true, if you just fail over the QUEUE_MANAGER in a cluster. This does work and it will open the 'new' SYSUAF.DAT. Only if you STOP/ID the QUEUE_MANAGER, then you loose all executing batch jobs.

Volker.

[Robert Gezelter]

Rob,

This is a tangential question, but why the "convert SYSUAF every weekend"? Are accounts being inserted/deleted that often?

Perhaps an examination of the RMS paramters used to create the UAF are in order. While the defaults are quite acceptable for most, there is to the best of my recollection, nothing sacred about them (e.g., CONVERT/FDL).

- Bob Gezelter, http://www.rlgsc.com