Difference between revisions of "CPRS NETCALL ERROR"

From VistApedia
Jump to: navigation, search
(Created page with " A CPRSChart.exe Netcall Error can sometimes be a sign that the VistA system has a problem with the number of Users allowed to sign in to the processor. If you run ^XUS (fr...")
 
 
Line 7: Line 7:
 
  Volume set: EHR:VVVVV  UCI: EHR  Device: /dev/pts/8
 
  Volume set: EHR:VVVVV  UCI: EHR  Device: /dev/pts/8
 
  Device: /dev/pts/8
 
  Device: /dev/pts/8
  <style "fontcolor:yellow">Maximum number of users already signed on to this processor. </style>
+
  '''Maximum number of users already signed on to this processor.'''
 +
 +
This is the same message seen by [[Ignacio]] on the [[Episode37]].
 +
 
 +
Editing the [[FILE 8989.3|KERNEL SYSTEM PARAMETER File #8989.3]] in the VOLUME SET Field #41 subfile #8989.304 and then Field #2 (MAX SIGNON ALLOWED) as he did may solve your problem.
 +
 
 +
 +
Select OPTION: ENTER OR EDIT FILE ENTRIES
 +
Input to what File: KERNEL SYSTEM PARAMETERS//  File #8989.3  (1 entry)
 +
EDIT WHICH FIELD: ALL// VOLUME SET    (multiple)
 +
EDIT WHICH VOLUME SET SUB-FIELD: ALL//
 +
THEN EDIT FIELD:
 +
Select KERNEL SYSTEM PARAMETERS DOMAIN NAME: `1
 +
Select VOLUME SET: EHR// ?
 +
Answer with VOLUME SET:
 +
EHR
 +
    You may enter a new VOLUME SET, if you wish
 +
    Answer with the name of other CPUs or Volume sets, or Directories.
 +
Your answer must be unique.
 +
Select VOLUME SET: EHR//
 +
  VOLUME SET: EHR//
 +
  MAX SIGNON ALLOWED: 9999// ?
 +
    Type a number between 0 and 10000, 0 Decimal Digits
 +
  MAX SIGNON ALLOWED: 9999// ??
 +
    This field defines the maximum number of jobs that XUS or RPC Broker will
 +
    allow to sign-on to this VOLUME SET or CPU.
 +
  MAX SIGNON ALLOWED: 9999//
 +
  LOG SYSTEM RT?: NO// ^
 +
 +
If your MAX SIGNON ALLOWED is already 9999 then you can use this MUMPS code:
 +
SET $PIECE(^XTV(8989.3,1,4,1,0),"^",3)=99999
 +
 +
This will make the value very high, and unlikely to be an issue, but you should
 +
also find out why the system has too many users.
 +
The most likely case is that the global ^XUTL("XUSYS","CNT")  has too large a value.
 +
 +
MUMPS>D CLEAR^XUSCNT(1)
 +
 +
Current Job Count: 10343
 +
1 Job: 300 Lock Fail Not Active: Removed
 +
2 Job: 302 Lock Fail Not Active: Removed
 +
3 Job: 304 Lock Fail Not Active: Removed
 +
4 Job: 306 Lock Fail Not Active: Removed
 +
5 Job: 308 Lock Fail Not Active: Removed
 +
6 Job: 310 Lock Fail Not Active: Removed
 +
7 Job: 312 Lock Fail Not Active: Removed
 +
8 Job: 1997 Lock Fail Not Active: Removed
 +
9 Job: 1998 No Lock node Not Active: Removed
 +
10 Job: 1999 Lock Fail Not Active: Removed
 +
11 Job: 2000 Lock Fail Not Active: Removed
 +
12 Job: 2001 Lock Fail Not Active: Removed
 +
13 Job: 2003 Lock Fail Not Active: Removed
 +
14 Job: 2008 No Lock node Not Active: Removed
 +
15 Job: 2009 Lock Fail Not Active: Removed
 +
...
 +
10341 Job: 32764 Lock Fail Not Active: Removed
 +
10342 Job: 32766 Lock Fail Not Active: Removed
 +
New JOB count: 51
 +
 +
The CLEAR^XUSCNT entry point will clean as it prints its progress unless COUNT^XUSCNT has been decommissioned such as by [[PATCH XU_8-0_10002|patch XU*8.0*10002 from OSEHRA]].

Latest revision as of 05:51, 14 July 2020

A CPRSChart.exe Netcall Error can sometimes be a sign that the VistA system has a problem with the number of Users allowed to sign in to the processor.
If you run ^XUS (from Direct mode, or from a tied login script)
and see this message:

Volume set: EHR:VVVVV  UCI: EHR  Device: /dev/pts/8
Device: /dev/pts/8
Maximum number of users already signed on to this processor.

This is the same message seen by Ignacio on the Episode37.
Editing the KERNEL SYSTEM PARAMETER File #8989.3 in the VOLUME SET Field #41 subfile #8989.304 and then Field #2 (MAX SIGNON ALLOWED) as he did may solve your problem.


Select OPTION: ENTER OR EDIT FILE ENTRIES
Input to what File: KERNEL SYSTEM PARAMETERS//  File #8989.3   (1 entry)
EDIT WHICH FIELD: ALL// VOLUME SET    (multiple)
EDIT WHICH VOLUME SET SUB-FIELD: ALL//
THEN EDIT FIELD:
Select KERNEL SYSTEM PARAMETERS DOMAIN NAME: `1
Select VOLUME SET: EHR// ?
Answer with VOLUME SET:
EHR
    You may enter a new VOLUME SET, if you wish
    Answer with the name of other CPUs or Volume sets, or Directories.
Your answer must be unique.
Select VOLUME SET: EHR//
  VOLUME SET: EHR//
  MAX SIGNON ALLOWED: 9999// ?
    Type a number between 0 and 10000, 0 Decimal Digits
  MAX SIGNON ALLOWED: 9999// ??
    This field defines the maximum number of jobs that XUS or RPC Broker will
    allow to sign-on to this VOLUME SET or CPU.
 MAX SIGNON ALLOWED: 9999//
 LOG SYSTEM RT?: NO// ^

If your MAX SIGNON ALLOWED is already 9999 then you can use this MUMPS code:
SET $PIECE(^XTV(8989.3,1,4,1,0),"^",3)=99999

This will make the value very high, and unlikely to be an issue, but you should
also find out why the system has too many users.
The most likely case is that the global ^XUTL("XUSYS","CNT")  has too large a value.

MUMPS>D CLEAR^XUSCNT(1)

Current Job Count: 10343
1 Job: 300 Lock Fail Not Active: Removed
2 Job: 302 Lock Fail Not Active: Removed
3 Job: 304 Lock Fail Not Active: Removed
4 Job: 306 Lock Fail Not Active: Removed
5 Job: 308 Lock Fail Not Active: Removed
6 Job: 310 Lock Fail Not Active: Removed
7 Job: 312 Lock Fail Not Active: Removed
8 Job: 1997 Lock Fail Not Active: Removed
9 Job: 1998 No Lock node Not Active: Removed
10 Job: 1999 Lock Fail Not Active: Removed
11 Job: 2000 Lock Fail Not Active: Removed
12 Job: 2001 Lock Fail Not Active: Removed
13 Job: 2003 Lock Fail Not Active: Removed
14 Job: 2008 No Lock node Not Active: Removed
15 Job: 2009 Lock Fail Not Active: Removed
...
10341 Job: 32764 Lock Fail Not Active: Removed
10342 Job: 32766 Lock Fail Not Active: Removed
New JOB count: 51

The CLEAR^XUSCNT entry point will clean as it prints its progress unless COUNT^XUSCNT has been decommissioned such as by patch XU*8.0*10002 from OSEHRA.