How to unlock TIU note?

[Kevin Toppenberg]

We have a laptop that we upgraded to Windows 10.  I thought it was working, but today CPRS has crashed twice.  Not a big deal to restart CPRS, and hopefully too much won't be lost since the last autosave.  But the problem is that the note gets locked, and I see "another session is editing the note", so it won't let me open or view the note.

It seems that I saw an option or function somewhere that would unlock such locked notes.  Does anyone know how to do this?  I know that I can bring down vistA and do a rundown on the database, or I can wait until the lock expires (I think).    But that is very inconvenient.  How is this done in the VA?

Kevin

[Kevin Toppenberg]

It seems that the timeout occurs in 15-20 minutes, as I went back and the note was unlocked.

But there still ought to be a way to do this manually, and I suspect there is.  Does anyone know?

Kevin

[Wiley]

Go to the operations menu, user management, find the user and then release the user. I think that will unlock it for you.

Select Operations Management Option: user Management Menu

 

 

   FIND   Find a user

   PXY    Proxy User List

          List users

          Print Sign-on Log

          Proxy (Connector) Detail Report

          Proxy (Connector) Inquire

          Release user

          User Inquiry

          User Status Report

[Kevin Toppenberg]

Thanks for this.

Looks like that menu option is 

  User Management Menu ... [XUOPTUSER]

And to release user it is: 

  Release user [XUSERREL]

This option description is:

  This option is used to clear the record that a user is signed on to

  another terminal.  It may seem that a user is signed on when there is

  an abnormal exit such as an error or entry into programmer mode.

And the entry point is X8^XUSMGR

Here is that code.

X8 ;Release user
 NEW DIC,DIR,J,X,Y,FDA,IEN,X1,X2,X3
X8A WRITE !!,"This will clear the user from the list of currently sign-on users." ; 
 WRITE !,"And/or release from invalid sign on lock."
 SET DIC="^VA(200,",DIC(0)="AEMQ" DO ^DIC SET IEN=+Y GOTO:Y<1 EX8
 SET (X1,X2,X3)=0
 IF $PIECE($GET(^VA(200,IEN,1.1)),"^",3) SET X1=1
 IF $PIECE($GET(^VA(200,IEN,1.1)),"^",5) SET X2=1
 IF $DATA(^XUSEC(0,"CUR",IEN)) SET X3=1
 IF '(X1+X2+X3) DO   GOTO X8
 . WRITE !!,$CHAR(7),"User is not currently recorded as being signed on the system!!!",!
 ;Show user info
 WRITE !,"User: ",$PIECE(Y,U,2)," is listed with the following connections."
 SET J=0 FOR   SET J=$ORDER(^XUSEC(0,"CUR",IEN,J)) QUIT:J'>0   DO
 . IF '$DATA(^XUSEC(0,J,0)) KILL ^XUSEC(0,"CUR",IEN,J) QUIT
 . SET X=^XUSEC(0,J,0)
 . WRITE !,"Connected: ",$$FMTE^XLFDT(J,"1"),?39," Device: ",$PIECE(X,U,2)
 . WRITE !,?2,"    Node: ",$PIECE(X,U,10),?39,"       IP: ",$SELECT($LENGTH($PIECE(X,U,11)):$PIECE(X,U,11),1:$PIECE(X,U,12))
 . QUIT
 IF $PIECE(^VA(200,IEN,1.1),U,5) WRITE !,"Locked out until ",$$FMTE^XLFDT($PIECE(^VA(200,IEN,1.1),U,5))," because of too many invalid attempts."
 ;
 SET DIR(0)="Y",DIR("A")="Release this user",DIR("B")="Yes" DO ^DIR
 IF 'Y GOTO X8A
 SET $PIECE(^VA(200,IEN,1.1),"^",3)=0,$PIECE(^VA(200,IEN,1.1),U,5)="" ;Clear flag,Lockout time
 SET J=0 FOR   SET J=$ORDER(^XUSEC(0,"CUR",IEN,J)) QUIT:J'>0   DO
 . SET FDA(3.081,J_",",3)=$$NOW^XLFDT,FDA(3.081,J_",",16)=1 DO UPDATE^DIE("","FDA")
 WRITE !,"User is RELEASED!!",!
EX8 QUIT ; 
 ;

From what I can see looking through this, I don't see it doing any unlocking of ^TIU(8925,

Thanks

Kevin

[Skip]

Kevin on this page under System Mang. there are some Lock utilities:

http://www.hardhats.org/tools/MUtilframe.html

On Thursday, September 3, 2015 at 3:01:49 PM UTC-4, Kevin Toppenberg wrote:

[David Whitten]

If I remember correctly, this is called a LOCK but it actually just
sets a "LOCK" node in a global. The MUMPS LOCK command isn't involved
at all.

> --
> --
> http://groups.google.com/group/Hardhats
> To unsubscribe, send email to Hardhats+u...@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "Hardhats" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to hardhats+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Sam Habiel]

Kevin, there are two kinds of locks in VISTA. M Locks and software
locks coordinated via globals located in ^XTMP. M Locks are done
mainly to prevent write contention in the database. Occasionally
though, they are done to prevent users from caring for the same
patient at the same time (e.g. pharmacists and doctors can't place
orders at the same time). Software locks are done via node in ^XTMP.
They are used mainly to prevent users from caring for the same patient
at the same time, as they live between processes; M Locks die with the
process if the process gets killed.

You can see the M Locks using the program lke on GT.M:

sam@icarus:/var/local/foia201502$ lke
LKE> show
%GTM-I-NOLOCKMATCH, No matching locks were found in C0CRXN
%GTM-I-LOCKSPACEUSE, Estimated free lock space: 100% of 100 pages

DEFAULT
^%ZTSCH("SUBLK","ROU:icarus",26273)
Owned by PID= 26273 which is an existing process
^%ZTSCH("TASK",1676) Owned by PID= 7251 which is an existing process
^%ZTSCH("TASK",1677) Owned by PID= 7307 which is an existing process
^XMBPOST("POST_Mover") Owned by PID= 7251 which is an existing process
^XMBPOST("POST_Tickler") Owned by PID= 7307 which is an existing process
^XOB(18.01,"VistALink Listener","ROU","VAH","ROU:icarus",51502)
Owned by PID= 13437 which is an existing process
^XTMP("PXRM PXK EVENT26635 3150904.104515")
Owned by PID= 26635 which is an existing process
^XTMP("PXRM PXK EVENT26635 3150904.104531")
Owned by PID= 26635 which is an existing process
^XTMP("PXRM PXK EVENT26635 3150904.104628")
Owned by PID= 26635 which is an existing process
^XUTL("XQORM","4732;ORD(101,","XQORM PROTECT",26635)
Owned by PID= 26635 which is an existing process
%GTM-I-LOCKSPACEUSE, Estimated free lock space: 99% of 1000 pages
%GTM-I-NOLOCKMATCH, No matching locks were found in TEMPGBL
%GTM-I-LOCKSPACEUSE, Estimated free lock space: 100% of 1000 pages

You can zwrite ^XTMP 0 nodes to see the software locks. There's one here:

FOIA 2015-02>zwrite ^XTMP(:,0)
^XTMP("K2VC",0)="3150904^3150903^KIDS to Version Control"
^XTMP("PXLCKUSR",0)="3150904^3160903^PCE Encounter Lock"
^XTMP("PXVBKUP",0)="3151031^3150901"
^XTMP("PXVP210",0)="3160902^3150903"
^XTMP("PXVSKB",0)="3151031^3150901"
^XTMP("PXVSKX",0)="3151130^3150901"
^XTMP("XOB VISTA INFO ROU:icarus 13452",0)="3150909^3150902^VistALink
Connection Information [$JOB =13452]"
^XTMP("XOB VISTA INFO ROU:icarus 28423",0)="3150911^3150904^VistALink
Connection Information [$JOB =28423]"
^XTMP("XPDI",0)="3150910^3150903"
^XTMP("XTECLIPS",0)=3120211

--
Sam Habiel, Pharm.D.
VISTA Expertise Network

[Steven McPhelan]

The record lock depends on where in CPRS you are seeing this.  TIU almost exclusively uses M locks.  OE/RR uses both M locks and global nodes in ^XTMP as David mentioned.  M systems should clear the M lock table so that when you restart M the record lock should be released.  Most (if not all) VistA software that allows for UNLOCKING a record are using global node settings.  So stopping and starting a M system WILL NOT clear that type of locking records.

Word of warning: on a real system one should only release locks, like the routine you looked at, ONLY IF you are absolutely certain some legitimate user does not currently own that.  For example, sites that I worked at had over 3,000 simultaneous users.  Obviously locking a portion of a patient's record could change legitimate hands many times in one minute.  It will take one much longer than that just to find the "offending lock" in a global or in the M system lock table.  So you could end up releasing a lock that some other user legitimately has.

Steve

We have no government armed with the power capable of contending with human passions, unbridled by morality and true religion. Our constitution was made only for a moral and religious people. It is wholly inadequate to the government of any other. - John Adams

[Kevin Toppenberg]

Well, since the lock ended up auto-releasing after 15 minutes or so, I didn't have to do anything.  I guess the answer is to just wait.

Kevin 

[Steven McPhelan]

This looks like this was a M-lock situation and not the set a global node locking method.  Your CPRS GUI crashed.  Most likely, the corresponding M RPC job was still active in a FOR loop doing a READ waiting for the GUI to send something.  There are several VistA settings that can affect how long that "orphaned" VistA M process will stay around.  The inactivity time out finally triggered and the process HALTed which would release the M lock.  There has been an issue with the Broker for years not intercepting the exception that the TCP/IP handler throws notifying subscribers that the connection was broken.  Thus the M-side Broker processes keeps on listening waiting for a response.

In this situation at your site you have a small number of users.  You could have used System Status displays looking for the XWB routines in a nearly constant READ state.  It would not have been difficult to identify the "orphaned" M process.  You could have reviewed that processes symbol table for further confirmation like the DUZ value was yours.  There are tools that make this examination much easier.  The larger the system, the bigger the cluster, the greater number of simultaneous users all make this approach more and more difficult because of the size.

[Kevin Toppenberg]

This looks like good advice.  Next time this happens, I'll try these tools.

Thanks

Kevin

[Matt King]

"There are several VistA settings that can affect how long that "orphaned" VistA M process will stay around." In my experience, the most important setting governing the RPC link to CPRS after it crashes is this parameter:
Select PARAMETER DEFINITION NAME:    ORWOR TIMEOUT CHART

It is set in seconds:

------- Setting ORWOR TIMEOUT CHART  for System: BETA.VISTA-OFFICE.ORG -------
Timeout (GUI Chart): 900// 1500

ORWOR TIMEOUT CHART may be set for the following:

     1   User          USR    [choose from NEW PERSON]
     3   Division      DIV    [VOE OFFICE INSTITUTION OLD]
     5   System        SYS    [BETA.VISTA-OFFICE.ORG]

[Kevin Toppenberg]

Matt, 

Thanks for this.

A quick side question: When looking at parameters as you posted, which takes priority: User, Division, or system, if a given user had all three?  I could see the system being set up either way.  It could be institutional defaults with user overrides, or it could be that a system policy is absolute, and universally enforced.

Thanks

Kevin

[Steven McPhelan]

As with all Parameters, PRECEDENCE determines that.

[Calvin Woolwine]

Having dealt with general parameters alot over the past 8 years, I have learned that a user's setting is primary and will override any system setting.  It goes in this order:

User

Location

Service

Division

System

Package

Most parameters are set at the system or package level, which spreads across to all users.  As you move up the list, it allows for customization all the way down to the user level.  At the state hospital I worked at, I would often use the parameter ORWOR WRITE ORDERS LIST to assign order menus to the nurses and doctors.  Using the Location setting, I could assign each ward a different menu tailored to their needs.  Then, if a doctor wanted something specific that another didn't, I could copy the menu, rename it, and assign it to the doctor himself so that he is the only one who could access it, regardless of which location he was working at.

Some parameters, including ORWOR TIMEOUT CHART, can only be set by a few of these options.  ORWOR TIMEOUT CHART has a hierarchy of:

User

Division

System

So, a user's setting overrides the division setting and the system's setting.  The division setting would override the system's setting.   I am not aware of any parameter that allows a system or package setting to override a user's setting.  

On Thursday, September 3, 2015 at 3:01:49 PM UTC-4, Kevin Toppenberg wrote:

[Steven McPhelan]

As I stated the PRECEDENCE value in the PARAMETER DEFINITION file determines which ENTITY value supersedes which ENTITY on a PARAMETER DEFINITION by PARAMETER DEFINITION basis.

In this example, USR has a precedence of 1 which is a higher precedence than DIV or SYS.

[Kevin Toppenberg]

Thanks Calvin and Steven,

Here is a sample record from my system:

Record# 1169, in FILE: 8989.51

   .01-NAME : ORWG GRAPH SIZING

   .02-DISPLAY TEXT : CPRS Graph Position and Sizes

   .03-MULTIPLE VALUED : Yes

   .04-INSTANCE TERM : Setting

   .05-VALUE TERM : Settings

   1.1-VALUE DATA TYPE : free text

   6.1-INSTANCE DATA TYPE : free text

   6.2-INSTANCE DOMAIN : 2:30

    20-DESCRIPTION :

  This parameter is used internally to save positions of graph forms.

    30-ALLOWABLE ENTITIES :

       Multiple Entry #1

       .01-PRECEDENCE : 1

       .02-ENTITY FILE : USER (`200 in #8989.518)

       Multiple Entry #2

       .01-PRECEDENCE : 5

       .02-ENTITY FILE : PACKAGE (`9.4 in #8989.518)

So in this case, the user has precedence.  But I don't see where the actual value is stored.  It is possible that this entry just doesn't have data?  Or is it stored in a different file?  Will there ever be a time when PACKAGE is stored to, since there will always be a user?  

Kevin

[Steven McPhelan]

The PARAMETER DEFINITION file is 8989.51.  The ENTITY file is 8989.518.  The PARAMETER file is 8989.5.  All parameter values are stored in 8989.5.  You should never use FILEMAN to edit the parameter file.  Use the XPAR APIs to add, edit, and delete entries in the PARAMETER file.  The ENTITY file is controlled by the developers.  It is not designed to be added, edited, or deleted using Fileman.  XPAR is heavily hard-coded to specific entries in the ENTITY file.  One may be able to add an ENTITY once you understand how all the DDs are related and how XPAR uses that file.

[Calvin Woolwine]

Here is an example of me using XPAR as Steven is recommending for ORWOR WRITE ORDERS LIST.  I have this set at the division level for the 6 clinics I work for, dictating separate write orders menu for each one:

Enter '^NML' to read your new messages.

Select DIVISION: FHAINC//      WV  OC        020

          Core Applications ...

          Device Management ...

          Menu Management ...

          Programmer Options ...

          Operations Management ...

          Spool Management ...

          Information Security Officer Menu ...

          Taskman Management ...

          User Management ...

   ADD    Drug Enter/Edit

   FM     VA FileMan ...

   REG    Register a Patient

          Application Utilities ...

          Capacity Planning ...

          HL7 Main Menu ...

          Manage Mailman ...

          MAS Parameter Entry/Edit

You have PENDING ALERTS

          Enter  "VA to jump to VIEW ALERTS option

Select Systems Manager Menu <TEST ACCOUNT> Option: gp  General Parameter Tools

   LV     List Values for a Selected Parameter

   LE     List Values for a Selected Entity

   LP     List Values for a Selected Package

   LT     List Values for a Selected Template

   EP     Edit Parameter Values

   ET     Edit Parameter Values with Template

   EK     Edit Parameter Definition Keyword

You have PENDING ALERTS

          Enter  "VA to jump to VIEW ALERTS option

Select General Parameter Tools <TEST ACCOUNT> Option: ep  Edit Parameter Values

                         --- Edit Parameter Values ---

Select PARAMETER DEFINITION NAME: ORWOR WRITE ORDERS LIST     Write Orders (Inpa

tient)

ORWOR WRITE ORDERS LIST may be set for the following:

     1   User          USR    [choose from NEW PERSON]

     2   Location      LOC    [choose from HOSPITAL LOCATION]

     2.3 Service       SRV    [choose from SERVICE/SECTION]

     2.7 Division      DIV    [choose from INSTITUTION]

     3   System        SYS    [BETA.VISTA-OFFICE.ORG]

     4   Package       PKG    [ORDER ENTRY/RESULTS REPORTING]

Enter selection: 2.7  Division   INSTITUTION

Select INSTITUTION NAME: PINEVILLE FHA    WV  OCS  020A5

-------- Setting ORWOR WRITE ORDERS LIST  for Division: PINEVILLE FHA --------

Select Sequence: ?

Sequence  Value

--------  -----

10        OR ADD MENU CLINICIAN PINEVILLE

Select Sequence:

I agree with Steven that here is where you need to specify where your parameters should be set.  If you wish, shoot me an email or give me a call and I can go over this with you more and answer your questions more directly to where you can understand it a bit better.  I know Eddie has my number.

[Matt King]

User takes precedence; then I'm not sure, but suspect division and lastly system.

[Steven McPhelan]

Calvin's explanation is not correct.  The value of sequence has no bearing on PRECEDENCE as to which ENTITY supersedes which ENTITY.

A PARAMETER DEFINITION is stored in file 8989.51.  No values are stored here.  Values are stored in the PARAMETER file 8989.5.  The option that Calvin cited allows one to edit a specific PARAMETER value.  It has nothing to do with PRECEDENCE.

What is a PARAMETER DEFINITION?  It defines the characteristics for a PARAMETER to store values.  Unfortunately, the word 'value' has multiple, significantly different meanings which has confused many people for many years.  A PARAMETER DEFINITION has 6 main components and other fields supporting those main fields or components.

PARAMETER DEFINITION file (8989.51)

1.  There must be a unique name, ^DD(8989.51,.01)

2.  There must be an INSTANCE data type, ^DD(8989.51, fields .04, 6.1, 6.2, 6.3, 7, 8)

3.  There must be a VALUE data type, ^DD(8989.51, .05, 1.1, 1.2, 1.3, 2, 3)

4.  Is the PARAMETER MULTIPLE VALUED, ^DD(8989.51, .03)

5.  There must be one or more associated ALLOWABLE ENTITIES, ^DD(8989.51,30) which is a Fileman multiple containing two fields, PRECEDENCE and ENTITY

No end user, ADPAC, or CAC has authority to alter a PARAMETER DEFINITION.  PARAMETER DEFINITIONS are either imported from a KIDS Install or hand-entered by developer/programmer.

The NAME is just free text.

The two groups of fields for INSTANCE and VALUE define the characteristics to be used by the XPAR routines to set up a ^DIR call.  So these two sets of fields allows the developer to define their Fileman data types such as set of codes, date field, free text, numeric, pointer-type, word processing, etc.

MULTIPLED VALUED determines how many 'values' can be stored in the PARAMETER file.  The PARAMETER file does not have a Fileman Key defined on it but the XPAR routines ensure a key is enforced.  This is where MULTI-VALUED comes into play.

• In the PARAMETER file the combination of the three fields PARAMETER, ENTITY, INSTANCE must be unique across the entire PARAMETER file.
• PARAMETER is just a pointer to the PARAMETER DEFINTION file and is thus the name of the parameter.
• ENTITY is a pointer the ENTITY file (8989.518) screened to allow selection of only those ENTITIES defined in the PARAMETER DEFINITION file for the PARAMETER selected.
• INSTANCE is just the 'value' entered to a DIR call where the DIR call is defined by the data entered in the various INSTANCE fields in the PARAMETER DEFINTION file for the parameter selected.
• If MULTI-VALUED is NO then XPAR ensures that the combination of PARAMETER and ENTITY is unique across the entire PARAMETER file.
• If MULTI-VALUES is YES then XPAR ensures that the combination of PARAMETER, ENTITY, and INSTANCE is unique.

Now to the ALLOWABLE ENTITIES multiple

• The .01 field of the multiple is PRECEDENCE which is a number.  The lower the PRECEDENCE value (i.e., number) the higher the precedence of that ENTITY.  So 1 supersedes 2 which supersedes 3.
• The .02 field of the multiple is ENTITY which is just a pointer to the ENTITY file (8989.518)
• The ENTITY file has two main fields, .001 called FILE NUMBER which has a special screen so that on certain Fileman file numbers can be selected.  The second field is the .01 NAME field.  So the Entity called Division which has a .001 value of 4 which is the INSTITUTION file.

PARAMETER file (8989.5)

The PARAMETER file (8989.5) is completely driven and controlled by the PARAMETER DEFINITION file.  The PARAMETER file has exactly 4 components to it.

The .01 field is ENTITY which is a Fileman variable pointer to the FILE OF FILES file

The .02 field is PARAMETER which is a pointer field to the PARAMETER DEFINITION file with a screen that only param_defs can be selected which have the ENTITY (.01 field value) in the ALLOWABLE ENTITIES multiple.

The .03 field is INSTANCE which is free text but must pass the Fileman field attributes as defined in the various Instance fields in the corresponding PARAMETER (.02 field value), i.e, PARAMETER DEFINITION

The PARAMETER 'value' can be stored in one of 3 fields defined in the PARAMETER file (8989.5) depending upon the Fileman field attributes as defined in the various Value fields in the corresponding PARAMETER (.02 field value).

Now back to Calvin's example.  He is running an OPTION that calls an XPAR routine that allows for the add, edit, delete of entries in the PARAMETER file (8989.5)

Select PARAMETER DEFINITION NAME: ORWOR WRITE ORDERS LIST     Write Orders (Inpatient)   [a .01 field value in file 8989.51]

ORWOR WRITE ORDERS LIST may be set for the following:   [XPAR routine is now showing the list of ALLOWABLE ENTITIES for the selected PARAMETER NAME]

     1   User          USR    [choose from NEW PERSON]

     2   Location      LOC    [choose from HOSPITAL LOCATION]

     2.3 Service       SRV    [choose from SERVICE/SECTION]

     2.7 Division      DIV    [choose from INSTITUTION]

     3   System        SYS    [BETA.VISTA-OFFICE.ORG]

     4   Package       PKG    [ORDER ENTRY/RESULTS REPORTING]

     Since the ALLOWABLE ENTITIES has a .001 field defined, the api shows Precedence, Entity name [^DD(8989.518,.01)], and PREFIX [^DD(8989.518,.02)]

Enter selection: 2.7  Division   INSTITUTION

Select INSTITUTION NAME: PINEVILLE FHA    WV  OCS  020A5

-------- Setting ORWOR WRITE ORDERS LIST  for Division: PINEVILLE FHA --------

Select Sequence: ?    [Sequence is the DIR("A") value taken from the INSTANCE TERM field for the Parameter selected]

Sequence  Value

--------  -----

10        OR ADD MENU CLINICIAN PINEVILLE

What is 10?  10 is just a data value in a Fileman file that has no bearing on PRECEDENCE.

The PARAMETER DEFINITION field INSTANCE HELP has this value:

Enter the relative sequence for this order in the list box.

The description of this PARAMETER DEFINITION states:

***This parameter has been superseded by ORWDX WRITE ORDERS LIST.***
 Currently, the GUI references only for backward compatibility reasons.
 
 This parameter is used do list the order dialog names that should appear in
 the Write Orders list box of the CPRS GUI.  This is the list of dialogs that
 should be used in the inpatient setting.

The XPAR utilities really expanded the multi-dimensionality of the Fileman DBMS.  Because of M, Fileman naturally allowed for multiple values in a single cell of a traditional relational database.  XPAR expands this multi-value in that it allows for each of the multi-values in a single cell to be a different database type.

SO, the PARAMETER file has no influence on PRECEDENCE other that being the repository for values for which PRECEDENCE will be applied according to the rules defined the PARAMETER DEFINTION file.

Side-note.  The Value fields in the PARAMETER DEFINTION file do not necessarily mean that this is the "pertinent value" of an entry in the PARAMETER file.  Mull this over.

A PARAMETER entry has two fields defining the type of entry where those two fields are PARAMETER NAME and ENTITY,  For each combination of PARAM-ENTITY there are two degrees of freedom to associate Fileman data information with that pair, namely INSTANCE and VALUE. 

[Kevin Toppenberg]

This area has been an unexplored mystery to me for awhile.  Thanks for explaining.

Kevin