problem with "reply/user" on a specific user

[CyrilA]

Hi,
I have a problem when i use "reply/user" on a specific user: This user doesn't receive the message.

He receives it when i use "reply/all" and other users receive the message with common "reply/user".


For information, Broadcasts are enabled for all classes and no flag has been put on the SYSUAF account.

I'm opened to any idea that can help....
Thx in advance
Cyril

[marsh_1]

hi,

can you give details on architecture/vms version etc.
have you checked in the users login.com for any thing strange they may have set up in there ?


hth

[marsh_1]

...specifically $ set broad=none

fwiw

[Fekko Stubbe]

Did you specify the username in uppercase
f.e. reply/user="system" does not work and
repl/user=system does (dcl upcases)
and repl/user="SYSTEM" also (is uppercase)

Fekko

[Jon Pinkley]

CyrilA,

Is there anything odd about the username? Does it follow the standard rules for usernames that SYSUAF expects?

In other words is it a username that is
1-12 characters in length and composed of the characters {[A-Z]|[0-9]|$|_} ?

Jon

[Hoff]

You've eliminated the likelihood that the OPCOM process and the broadcast setting on the terminal and the broadcast mask setting in the process are triggering this in the original post.

Interesting. See if you have a logical name that's visible in the context of the process issuing the REPLY /USER command that matches the target username. This logical name could be in any of the logical name tables configured for the process.

If that's not it, post the numbers of SYSUAF files, the SHOW TERMINAL /FULL and related for the processes. And the usual recommendation to upgrade to current and to then ECO to current applies.

[Jan van den Ende]

Cyril,

one thing that has not been mentioned yet:

Is the username perhaps equal to an existing Logical Name? As seen from your process, or somewhere in system context?

fwiw

Proost.

Have one on me.

jpe

[Jan van den Ende]

Cyril,

excusez moi.

I should have noticed you are new here.

WELCOME to the VMS forum!

Proost.

Have one on me.

jpe

[CyrilA]

Hi all,

sorry for the delay but i didn't get the notifications of your replies (blocked by anti-SPAM) and i forgot that thread.

Anyway, I still have this problem and here are some more informations:

1. we are on OpenVMS 7.3-2 and this is a cluster with 2 nodes

2. Nothing has change in login.com

3. The replies work again after reboot but it fails after a couple of weeks (quota somewhere?)

4. same behaviour with uppercase than in lowercase

5. UAF> sho cov_prod

Username: COV_PROD Owner:
Account: EXPLOIT UIC: [250,4] ([INFO,PRODUCTION])
CLI: DCL Tables: DCLTABLES
Default: D$PROD:[PRODUCTION]
LGICMD: LOGIN
Flags:
Primary days: Mon Tue Wed Thu Fri
Secondary days: Sat Sun
No access restrictions
Expiration: (none) Pwdminimum: 6 Login Fails: 0
Pwdlifetime: (none) Pwdchange: 3-MAR-2003 15:49
Last Login: 19-NOV-2009 07:55 (interactive), 19-NOV-2009 09:14 (non-interactive)
Maxjobs: 0 Fillm: 700 Bytlm: 6000000
Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0
Maxdetach: 0 BIOlm: 32767 JTquota: 65536
Prclm: 15 DIOlm: 32767 WSdef: 30000
Prio: 4 ASTlm: 32767 WSquo: 35000
Queprio: 0 TQElm: 700 WSextent: 100000
CPU: (none) Enqlm: 32767 Pgflquo: 810000
Authorized Privileges:
ACNT ALLSPOOL ALTPRI AUDIT BUGCHK BYPASS
CMEXEC CMKRNL DIAGNOSE DOWNGRADE EXQUOTA GROUP
GRPNAM GRPPRV IMPERSONATE IMPORT LOG_IO MOUNT
NETMBX PFNMAP PHY_IO PRMCEB PRMGBL PRMMBX
PSWAPM READALL SECURITY SETPRV SHARE SHMEM
SYSGBL SYSLCK SYSNAM SYSPRV TMPMBX UPGRADE
VOLPRO WORLD
Default Privileges:
BYPASS GROUP IMPERSONATE NETMBX OPER PRMMBX
SETPRV SHARE SYSLCK SYSNAM SYSPRV TMPMBX
WORLD
UAF>

6. dir sysuaf* /dat

Directory SYS$COMMON:[SYSEXE]

SYSUAF.DAT;2 20-OCT-2005 22:20:27.22
SYSUAF.DAT;1 20-OCT-2005 17:32:25.53
SYSUAF.TEMPLATE;1 1-OCT-2003 21:24:22.95
SYSUAFCOV.DAT;2 9-MAR-1996 12:16:36.57


7. sho term/full
Terminal: _TNA20: Device_Type: VT102 Owner: _TNA20:
Username: SYSTEM
Remote Port Info: Host: Port: 3337

Input: 9600 LFfill: 0 Width: 80 Parity: None
Output: 9600 CRfill: 0 Page: 24

Terminal Characteristics:
Interactive Echo Type_ahead No Escape
Hostsync TTsync Lowercase Tab
Wrap Scope No Remote No Eightbit
Broadcast No Readsync No Form Fulldup
No Modem No Local_echo No Autobaud Hangup
No Brdcstmbx No DMA No Altypeahd Set_speed
No Commsync Line Editing Overstrike editing No Fallback
No Dialup No Secure server No Disconnect No Pasthru
No Syspassword No SIXEL Graphics No Soft Characters Printer port
Numeric Keypad ANSI_CRT No Regis No Block_mode
Advanced_video Edit_mode DEC_CRT No DEC_CRT2
No DEC_CRT3 No DEC_CRT4 No DEC_CRT5 No Ansi_Color
VMS Style Input

8. sho log *cov_prod*

(LNM$PROCESS_TABLE)

(LNM$JOB_820F5580)

(LNM$GROUP_000001)

(LNM$SYSTEM_TABLE)

(LNM$SYSCLUSTER_TABLE)

(DECW$LOGICAL_NAMES)
%SHOW-S-NOTRAN, no translation for logical name *COV_PROD*


Thanks for any help on this issue.
Cyril

[labadie_1]

Hello

Can you post the result of the command

$ show broa

regards

Gérard

Ps: you can post on http://fr.openvms.org/forum/ too.

[CyrilA]

show broa
Broadcasts are enabled for all classes

[Hoff · Accepted solution]

The SET BROADCAST and SHOW TERMINAL and the UAF entries shown all look OK, of course.

Your settings and your description of a cluster and of a two week or so delay before this misbehavior arises point to a bug in OPCOM, or to a leak somewhere.

Here, I'd start with the ECO kits, as behavior such as this has shown up over the years, and various of these were fixed by patch. If the box is not current on ECO kits, then (if this disrupts production to warrant it) get the kit patched to current. (Or look to upgrade OpenVMS and to patch V8.3 to current, this given how old V7.3-2 is.)

Also watch the OPCOM process quotas and watch the username quotas associated with this target username over time, too. A quota leak (application or system or in the OPCOM process) could show up as described.

The other approach toward both debugging and toward recovering (both a diagnostic and a workaround when this arises) is to STOP /ID the OPCOM process, then restart it via @SYS$SYSTEM:STARTUP OPCOM or such, and see if this behavior clears.

Regardless, load the UPDATE kits as a start. (I'd expect the OPCOM stuff has long ago been rolled into the UPDATE kits, given the age of V7.3-2.)

Now the other potential trigger that can arise here (and completely unrelated to the OPCOM discussion above, but that can manifest with symptoms similar to those described) is a bug in an application running under this particular username; applications can associate broadcast mailboxes and process broadcasts, and applications can (of course) sometimes get confused. This could be a process quota issue, or some application-level bug.

[labadie_1]

The latest OPCOM image is in this kit

ftp://ftp.itrc.hp.com/openvms_patches/alpha/V7.3-2/VMS732_OPCOM-V0200.txt

Put it and reboot, to see if it fixes your problem.

Regards

Gérard

[CyrilA]

this patch is included in the UPDATE V15 which is installed on the cluster
Should i install it again?

[CyrilA]

Hoff,

I will focus on the OPCOM process (tune).

Now all is ok cause the cluster did reboot yesterday.

As i said, the UPDATE V19 will be installed by the end of the month

I will put news when the bug will come back
Thanks very for the help

[Hoff]

Rule of thumb when dealing with bugs: patch (ECO) the box to current before calling in support, and also seek and collect a reproducer or some data or a trend or a crashdump or whatever the manifestation of the problem; data that points to and/or that confirms the bug.

If you are not patched to current and not ready with supporting materials (eg: SHOW BROADCAST and SHOW TERMINAL, et al, for this particular case), the handling within the support call can (almost inevitably) be delayed.

If you have current patches loaded and if you have some or all of this data collected and readily available, then the support call tends to go faster; there's rather less for the support folks that are receiving the support call to work through in their support scripts, and rather more data available for them to find the right path to a resolution within the support script, or to get the support call escalated along to the OpenVMS engineers.

[Graham Burley]

> 7. sho term/full
> Terminal: _TNA20: Device_Type: VT102 Owner: _TNA20:
> Username: SYSTEM

Isn't this your terminal rather than the user you're having problems REPLYing to?

Likewise the SHOW BROADCAST output, not sure how you'd see those settings for another user without grubbing around in SDA.

Next time the reply starts failing can you post the following:
$ SHOW USER problem_user/FULL
$ SHOW TERM a_terminal_from_show_user/FULL

[Hein van den Heuvel]

What Graham said!

What terminal is this going TO ?

$SHOW USER xxx/FULL

This would not happen to be an other incident of the terminal unit number being larger than 999, 9999, or some such magic number?

Having a logical name out there was my first guess, but it looks like that option is dispelled.


Regards,
Hein.


$ reply/user = abc "testing"
$ define abc hein
$ reply/user = abc "testing"
$

Reply received on XXXXXX from user HEIN at _XXXXXX$VTA193: 12:17:02
testing

$
User HEIN has been notified on XXXXXX (2 terminals).

[John Gillings]

Cyril,

One other thing worth checking is if the target user has run any identity changing utilities to flip usernames around.

Over the years OpenVMS has accumulated some severe non-normalisation of the identity data structures, with many fields repeated in different places. Attempts to change usernames or identities on the fly sometimes miss some of those places, with results that "work" for most things, but fail in obscure areas. This may be one such.

Try logging your target user in with /NOCOMMAND and try to send a broadcast message before executing anything.

[CyrilA]

Hoff,
I will monitor the OPCOM process (tune).

Graham and Hein,
Actually the replies are launched by batch processes. the "show term/full" i have posted is the term from where i test the bug. here is the term where i should get the replies:

sho term/full
Terminal: _TNA43: Device_Type: VT102 Owner: _TNA43:
Username: COV_PROD
Remote Port Info: Host: 172.20.0.52 Port: 1057

Input: 9600 LFfill: 0 Width: 80 Parity: None
Output: 9600 CRfill: 0 Page: 24

Terminal Characteristics:
Interactive Echo Type_ahead No Escape
Hostsync TTsync Lowercase Tab
Wrap Scope No Remote No Eightbit
Broadcast No Readsync No Form Fulldup
No Modem No Local_echo No Autobaud Hangup
No Brdcstmbx No DMA No Altypeahd Set_speed
No Commsync Line Editing Overstrike editing No Fallback
No Dialup No Secure server No Disconnect No Pasthru
No Syspassword No SIXEL Graphics No Soft Characters Printer port
Numeric Keypad ANSI_CRT No Regis No Block_mode
Advanced_video Edit_mode DEC_CRT No DEC_CRT2
No DEC_CRT3 No DEC_CRT4 No DEC_CRT5 No Ansi_Color
VMS Style Input




sho user COV_prod/full
OpenVMS User Processes at 20-NOV-2009 09:10:30.24
Total number of users = 1, number of processes = 38

Username Node Process Name PID Terminal
COV_PROD PROD1 BATCH_950 2060358C (Batch)
COV_PROD PROD1 BATCH_977 206035CB (Batch)
COV_PROD PROD1 COV_PROD 20601046 TNA62:
(Host: 172.20.15.154 Port: 3000)
COV_PROD PROD1 COV_PROD_11969 20603595 (subprocess of 2060091B)
COV_PROD PROD1 COV_PROD_32340 20603474 (subprocess of 206009B9)
COV_PROD PROD1 COV_PROD_35180 20603477 (subprocess of 206009B9)
COV_PROD PROD1 COV_PROD_40384 20603596 (subprocess of 2060091B)
COV_PROD PROD1 COV_PROD_42063 20602C75 (subprocess of 206009B9)
COV_PROD PROD1 COV_PROD_46270 20603583 (subprocess of 2060091B)
COV_PROD PROD1 _RTA1: 2060160C RTA1: (PROD1::SYSTEM)
COV_PROD PROD1 _TNA102: 206021E2 TNA102:
(Host: 172.20.11.20 Port: 3714)
COV_PROD PROD1 _TNA114: 20602058 TNA114:
(Host: 172.20.17.158 Port: 2913)
COV_PROD PROD1 _TNA118: 20602A25 TNA118:
(Host: 172.20.16.35 Port: 1794)
COV_PROD PROD1 _TNA30: 2060091B TNA30:
(Host: 172.20.15.78 Port: 2907)
COV_PROD PROD1 _TNA41: 206009B9 TNA41:
(Host: 172.20.17.48 Port: 3632)
COV_PROD PROD1 _TNA50: 20600D2A TNA50:
(Host: 172.20.17.117 Port: 1678)
COV_PROD PROD1 _TNA70: 206018B3 TNA70:
(Host: 172.20.15.154 Port: 3778)
COV_PROD PROD1 _TNA81: 20601DF0 TNA81:
(Host: 172.20.0.44 Port: 1656)
COV_PROD PROD1 _TNA8: 2060044A TNA8:
(Host: 172.20.17.117 Port: 1133)
COV_PROD PROD2 BATCH_705 20801904 (Batch)
COV_PROD PROD2 BATCH_896 20800DD4 (Batch)
COV_PROD PROD2 COV_PROD 208019FC TNA40:
(Host: 172.20.15.82 Port: 2368)
COV_PROD PROD2 COV_PROD_16566 208018A9 (subprocess of 20800455)
COV_PROD PROD2 COV_PROD_18525 20801931 (subprocess of 20801905)
COV_PROD PROD2 COV_PROD_21934 208019FE (subprocess of 208019FC)
COV_PROD PROD2 COV_PROD_37437 20801907 (subprocess of 20801905)
COV_PROD PROD2 COV_PROD_51465 20800961 (subprocess of 20800455)
COV_PROD PROD2 COV_PROD_527 20801A0F (subprocess of 208019FC)
COV_PROD PROD2 COV_PROD_52837 20800E79 (subprocess of 20800455)
COV_PROD PROD2 COV_PROD_59018 20801A00 (subprocess of 208019FC)
COV_PROD PROD2 COV_PROD_60968 208019FD (subprocess of 208019FC)
COV_PROD PROD2 COV_PROD_62172 20801906 (subprocess of 20801905)
COV_PROD PROD2 _TNA12: 20800455 TNA12:
(Host: 172.20.15.154 Port: 3808)
COV_PROD PROD2 _TNA15: 2080061B TNA15:
(Host: 172.20.17.48 Port: 1551)
COV_PROD PROD2 _TNA24: 208008A4 TNA24:
(Host: 172.20.15.78 Port: 4807)
COV_PROD PROD2 _TNA35: 20801905 TNA35:
(Host: 172.20.16.35 Port: 1795)
COV_PROD PROD2 _TNA3: 20800440 TNA3:
(Host: 172.20.17.158 Port: 4752)
COV_PROD PROD2 _TNA43: 20801A9F TNA43:
(Host: 172.20.0.52 Port: 1057)


John,
my target user COV_PROD did not run any identity changing utility. the fact that the this user is noticed by replies after reboot and for a couple of weeks, makes me thing of a quota problem but i can't figure out...


Today all is OK cause the cluster did reboot yesterday.

As i said, the UPDATE V19 will be installed by the end of the month

I will put news when the bug will come back
Thanks very much guys for the help

Cyril

[Hoff]

Most sites have a daily (nightly) maintenance job (or three) around; add a little logic into that to snapshot the OPCOM process quota usage, and to snapshot the quota usage of this user's (long-running?) jobs.