VMXLCK1386I Process VMSECURE #### SYSTEM has a shared NUC-AGENT lock.
search cancel

VMXLCK1386I Process VMSECURE #### SYSTEM has a shared NUC-AGENT lock.

book

Article ID: 397126

calendar_today

Updated On:

Products

VM:Secure for z/VM

Issue/Introduction

You IPL'd 2 members of an SSI cluster. VMSECURE won't start on one of the members and displays the license info then sits.

You suspect this is because the other member that was IPL'd is the master and has a NUC-AGENT lock. 

Oddly, this also happened on another 2 member SSI. Same issue.

No new recent maintenance to VMSECURE.  These systems have been IPL'd twice since the last maintenance was applied, so you're not sure what's causing the locks now.

Environment

VM:Secure for z/VM r3.2

Cause

The internal traffic between the VMSECURE MASTER and the AGENTs is not always obvious. In particular any directory update is going to cause a synchronous directory update to all SSI members.
If that occurs coincidental to your SHUTDOWN it could certainly result in this problem ... an orphaned NUC-AGENT lock.

If there was any processing going on (on another member) when you SHUTDOWN, a synchronous directory update certainly could have happened at the "wrong time".

Resolution

VMSECURE LOCAL END FORCE was issued on the system holding the lock. Then autologged vmsecure on that system. The lock cleared and the systems came back up. 

Additional Information

The safest thing to do is make sure you END VMSECURE before the SHUTDOWN. That way you know the VMSECURE server has completed any work it may have queued or in progress. If you haven't implemented SIGNAL SHUTDOWN (also see the END UserEXIT) in VM:Secure then SIGNAL SHUTDOWN is also an option.