Problems with Taskman, hung processes, ^ZJOB and ^ZSY

Kevin Toppenberg

unread,

Jan 26, 2023, 8:55:13 AM1/26/23

to Hardhats

Hey all, I had issues this morning with hung processes. The usual tools failed to help.

Our office uses a separate software package for billing. They don't provide a direct interface for extracting data to be used in VistA. So we have a script that outputs a batch report of 3 weeks worth of appts and billing codes etc that we then ingest this report weekly into VistA. The report file contains thousands and thousands of lines which are compared against the VistA database to see if the information is already known, and if not, then filed. My suspicion is that it is this process that was causing problems. (But I'm not sure, see more below.)

Last night I noticed that VistA was very sluggish, even from the roll-and-scroll interface. CPRS would allow log in, but then was unusable and eventually froze and had to manually aborted via Task Manager. I let this continue running overnight, but this morning, the situation was unchanged.

From past experience, I thought this was a problem with a Taskman task. I tried to shut taskman down, but it wouldn't. Here is monitor output:

Checking Taskman. Current $H=66500,22783 (Jan 26, 2023@06:19:43)
RUN NODE=66499,79187 (Jan 25, 2023@21:59:47)
Taskman is late by 29981 seconds. shutting down.
Checking the Status List:
Node weight status time $J
EHR:ubuntu64 RUN T-1@21:59:47 238795 Main Loop

Checking the Schedule List:
Taskman has 67 tasks scheduled.
17 of them are overdue. First task is 31783 seconds late.

Checking the IO Lists: Last TM scan: 33211 sec,
There are no tasks waiting for devices.

Checking the Job List:
There are 8 tasks waiting for partitions.

Checking the Task List:
There are 3 tasks currently running.
Checking Sub-Managers:
On node EHR:ubuntu64 there are no free Sub-Manager(s). Status: Stop

Enter monitor action: UPDATE//
==============================================================

When I told it to stop, and to instruct running tasks to stop, I got this output. There were 3 "busy" tasks.

Signaling active Tasks to STOP.
TASK: 8713261 Stop status: 0^Busy
TASK: 8739272 Stop status: 0^Busy
TASK: 8739343 Stop status: 0^Busy

==============================================================

I then tried ^ZJOB, but when I entered 'S' to get system status, I was told that "Someone else is running the System status now", and I couldn't proceed. Looking at the code, I see that the 'S' option runs ^ZSY. Looking at that code, I found this command.

L +^XUTL("XUSYS","COMMAND"):1 I '$T G LW

And it was this lock that seemed to be failing. I dumped out the ^XUTL("XUSYS",*) global and got this:

yottadb>zwr ^XUTL("XUSYS",*)
^XUTL("XUSYS",220662,0)="66499,73800"
^XUTL("XUSYS",220662,"LOCK")="^%ZTSCH(""TASK"",8713261)"
^XUTL("XUSYS",220662,"NM")="BTask 8713261"
^XUTL("XUSYS",238795,0)="66499,75925"
^XUTL("XUSYS",238795,"NM")="Taskman EHR 1"
^XUTL("XUSYS",238806,0)="66499,75950"
^XUTL("XUSYS",238806,"LOCK")="^%ZTSCH(""SUBLK"",""EHR:ubuntu64"",238806)"
^XUTL("XUSYS",238816,0)="66499,75951"
^XUTL("XUSYS",238816,"LOCK")="^%ZTSCH(""SUBLK"",""EHR:ubuntu64"",238816)"
^XUTL("XUSYS",238816,"NM")="Sub 238816"
^XUTL("XUSYS",238822,0)="66499,75955"
^XUTL("XUSYS",238822,"LOCK")="^%ZTSCH(""SUBLK"",""EHR:ubuntu64"",238822)"
^XUTL("XUSYS",238822,"NM")="Sub 238822"
^XUTL("XUSYS",238830,0)="66499,75955"
^XUTL("XUSYS",238830,"LOCK")="^%ZTSCH(""SUBLK"",""EHR:ubuntu64"",238830)"
^XUTL("XUSYS",238830,"NM")="Sub 238830"
^XUTL("XUSYS",238836,0)="66499,75958"
^XUTL("XUSYS",238836,"LOCK")="^%ZTSCH(""SUBLK"",""EHR:ubuntu64"",238836)"
^XUTL("XUSYS",238836,"NM")="Sub 238836"
^XUTL("XUSYS",238838,0)="66499,75958"
^XUTL("XUSYS",238838,"LOCK")="^%ZTSCH(""SUBLK"",""EHR:ubuntu64"",238838)"
^XUTL("XUSYS",238838,"NM")="Sub 238838"
^XUTL("XUSYS",238847,0)="66499,75958"
^XUTL("XUSYS",238847,"LOCK")="^%ZTSCH(""SUBLK"",""EHR:ubuntu64"",238847)"
^XUTL("XUSYS",238847,"NM")="Sub 238847"
^XUTL("XUSYS",238855,0)="66499,75958"
^XUTL("XUSYS",238855,"LOCK")="^%ZTSCH(""SUBLK"",""EHR:ubuntu64"",238855)"
^XUTL("XUSYS",238855,"NM")="Sub 238855"
^XUTL("XUSYS",238857,0)="66499,75958"
^XUTL("XUSYS",238857,"LOCK")="^%ZTSCH(""SUBLK"",""EHR:ubuntu64"",238857)"
^XUTL("XUSYS",238857,"NM")="Sub 238857"
^XUTL("XUSYS",238863,0)="66499,75958"
^XUTL("XUSYS",238863,"LOCK")="^%ZTSCH(""SUBLK"",""EHR:ubuntu64"",238863)"
^XUTL("XUSYS",238863,"NM")="Sub 238863"
^XUTL("XUSYS",238870,0)="66499,75958"
^XUTL("XUSYS",238870,"LOCK")="^%ZTSCH(""SUBLK"",""EHR:ubuntu64"",238870)"
^XUTL("XUSYS",238870,"NM")="Sub 238870"
^XUTL("XUSYS",238874,0)="66499,75958"
^XUTL("XUSYS",238874,"LOCK")="^%ZTSCH(""SUBLK"",""EHR:ubuntu64"",238874)"
^XUTL("XUSYS",238874,"NM")="Sub 238874"
^XUTL("XUSYS",238882,0)="66499,75965"
^XUTL("XUSYS",238882,"LOCK")="^%ZTSCH(""TASK"",8739272)"
^XUTL("XUSYS",238882,"NM")="Task 8739272"
^XUTL("XUSYS",238896,0)="66499,75947"
^XUTL("XUSYS",238896,"LOCK")="^%ZTSCH(""SUBLK"",""EHR:ubuntu64"",238896)"
^XUTL("XUSYS",238896,"NM")="Sub 238896"
^XUTL("XUSYS",238904,0)="66499,75965"
^XUTL("XUSYS",238904,"LOCK")="^%ZTSCH(""TASK"",8739343)"
^XUTL("XUSYS",238904,"NM")="BTask 8739343"
^XUTL("XUSYS",238943,0)="66499,76043"
^XUTL("XUSYS",238943,"LOCK")="^XUTL(""XUSYS"",238943,1)"
^XUTL("XUSYS",238943,"NM")="ip3.161:0"
^XUTL("XUSYS",336721,0)="66500,21072"
^XUTL("XUSYS",336721,"LOCK")="^XUTL(""XUSYS"",336721,1)"
^XUTL("XUSYS",336721,"NM")="ip3.164:0"
^XUTL("XUSYS","CNT")=19
^XUTL("XUSYS","COMMAND")="Status"

==============================================================

This didn't give me much more information. So I copied ZSY.m to TMGZSY.m and modified the code to ignore the failing locks, just so I could get more information, and got this output:

GT.M Mumps users on 26-Jan-23 06:58:01

Proc. id Proc. name PS Device Routine MODE CPU time
-------- --------------- --- -------- -------- -------
220662 BTask 8713261 hib LOCK+3^DILF -direct 00:03:07
/dev/null CLOSED :
0 OPEN RMS STREAM NOWRAP :
0-out OPEN RMS STREAM NOWRAP :

236183 S+ pts/0 +1^GTM$DMOD -dir 00:00:02
/dev/pts/0 OPEN TERMINAL NOPAST NOESCA NOREADS TYP

238795 Taskman EHR 1 hib RECORD+7^%ZTLOAD1 -direct 00:02:26
0 OPEN RMS STREAM NOWRAP :
0-out OPEN RMS STREAM NOWRAP :

238882 Task 8739272 hib RECORD+7^%ZTLOAD1 -direct 00:02:26
/dev/null OPEN :
0 OPEN RMS STREAM NOWRAP :
0-out OPEN RMS STREAM NOWRAP :

238904 BTask 8739343 hib RECORD+7^%ZTLOAD1 -direct 00:02:26
0 OPEN RMS STREAM NOWRAP :
0-out OPEN RMS STREAM NOWRAP :

238943 ip3.161:0 hib LOCK+3^DILF -run 00:02:26
/dev/null OPEN :
0 OPEN SOCKET NOWRAP TOTAL=1 CURRENT=0 :
SOCKET[0]=h1674698838000 DESC=0 CONNECTED
ZDELAY ZBFSIZE=1024 ZIBFSIZE=0 NO

========================================

And finally I can see 3 errant records which seem to be stuck at RECORD+7^%ZTLOAD1

This RECORD^%ZTLOAD1 is as below:

53 RECORD ;build record
54 S ZTINC=$G(^%ZOSF("$INC"),1) ;Set to 1 if this system has $INCREMENT, otherwise 0.
55 S ZTGOT=0
56 I 'ZTINC D ;For System that don't have $INC (GT.M, DTM, MSM)
57 . ;Find a free entry, Claim it and Lock it.
58 . L +^%ZTSK(-1):0 S ZTSK=^%ZTSK(-1) ;This is just a starting point
59 . F S ZTSK=ZTSK+1 I '$D(^%ZTSK(ZTSK)) D Q:ZTGOT
60 . . L +^%ZTSK(ZTSK):$G(DILOCKTM,3) Q:'$T ;Can we lock it
61 . . I $D(^%ZTSK(ZTSK)) L -^%ZTSK(ZTSK) ;Already claimed
62 . . S ^%ZTSK(ZTSK,.1)=0,^%ZTSK(-1)=ZTSK,ZTGOT=1 ;Claim it
63 . . Q
64 . L -^%ZTSK(-1) ;
65 . Q

and RECORD+7 seems to be line 60, which is an attempt to get a lock on ^%ZTSK(ZTSK)

I didn't evoke the command to get more information from the errant tasks, for fear that I would break something with my skipping over locks. So I wasn't able to get any further information, and I ultimately had to just manually abort the tasks from Linux in a way I'm not happy about. (See other thread discussion).

As I compose the post, I see JOBSET^ZSY is where the information is gotten from the other task:

JOBSET ;Get data from a Linux job
S (IMAGE,INAME,UNAME,PS,TNAME,JTYPE,CTIME,LTIME,RTN)=""
S (%J,PID,PROCID)=$P(%LINE,U)
S TNAME=$P(%LINE,U,2) S:TNAME="?" TNAME="" ; TTY, ? if none
S PS=$P(%LINE,U,3) ; process STATE
S PS=$S(PS="D":"lef",PS="R":"com",PS="S":"hib",1:PS)
S CTIME=$P(%LINE,U,4) ;cpu time
S JTYPE=$P(%LINE,U,6),ACCESS(JTYPE)=JTYPE
ZSYSTEM "mupip intrpt "_%J
S UNAME=$G(^XUTL("XUSYS",%J,"NM"))
S RTN="" ; Routine, get at display time
S SI=$S(MODE=0:PID,MODE=1:CTIME,1:PID)
I IMAGE D
. S INAME="mumps",I=$GET(SORT(INAME,SI))+1,SORT(INAME,SI)=I
. S SORT(INAME,SI,I)=PROCID_"~"_UNAME_"~"_PS_"~"_TNAME_"~"_JTYPE_"~"_CTIME_"~"_LTI
E S I=$GET(SORT(SI))+1,SORT(SI)=I,SORT(SI,I)=PROCID_"~"_UNAME_"~"_PS_"~"_TNAME_"~
S USERS=USERS+1
Q

The mechanism seems to be to issue an interrupt to the other task. That task then uses its own value for $ZINTERRUPT do determine what to do. My environmental setup file exports this:

export gtm_zinterrupt='I $$JOBEXAM^ZU($ZPOSITION)'

And this code is as follows:

JOBEXAM(%ZPOS) ;
N %reference S %reference=$REFERENCE
S ^XUTL("XUSYS",$J,0)=$H,^XUTL("XUSYS",$J,"INTERRUPT")=$G(%ZPOS)
I %ZPOS["^" S ^XUTL("XUSYS",$J,"codeline")=$T(@%ZPOS)
K ^XUTL("XUSYS",$J,"JE")
I $G(^XUTL("XUSYS","COMMAND"))'="EXAM" ZSHOW "SD":^XUTL("XUSYS",$J,"JE")
I $G(^XUTL("XUSYS","COMMAND"))="EXAM" ZSHOW "*":^XUTL("XUSYS",$J,"JE")
I $G(^XUTL("XUSYS",$J,"CMD"))="HALT" ;To do.
Q 1

So apparently the interrupt looks for a command in a global, and outputs results of ZSHOW back to the global for review.

By the way, ^XTER doesn't have any information because no actual error state was caught.

Questions:

1) What do you all think the underlying problem was? A race condition with Taskman?

2) ^ZSY is dependent on getting a lock, because every task looks to a common point when interrupted. But in my case, this prevented the utility from helping me. I would like to modify my code such that I can proceed despite lock failure. My system is small and I know there is no on else using ^ZSY

3) Why did my database fail to get a lock in the first place? Is there some overlap between this ^ZSY system and Taskman? They seem to be using the same global for communication. I notice from the Taskman monitor, I can enter 'S' to get system status. So perhaps ^ZSY is originally a Taskman utility.

3) What should I do in this situation in the future?

Thanks

Kevin T

Sam Habiel

unread,

Jan 26, 2023, 11:18:44 AM1/26/23

to hard...@googlegroups.com

Can you show us the output of LKE -show, or did you fix the situation already?

$ lke show -all
%YDB-I-LOCKSPACEINFO, Region: DEFAULT: processes on queue: 0/880; LOCK
slots in use: 0/597; SUBSCRIPT slot bytes in use: 0/28072
%YDB-I-NOLOCKMATCH, No matching locks were found in DEFAULT
%YDB-I-LOCKSPACEUSE, Estimated free lock space: 100% of 220 pages

--Sam

> --
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/d/msgid/hardhats/37295e1b-5c33-4c62-8867-98fa9dd103d4n%40googlegroups.com.

Kevin Toppenberg

unread,

Jan 26, 2023, 11:29:21 AM1/26/23

to Hardhats

Sam,

Here is my output. But I have taken down VistA, done a rundown of the database, and brought it back up. So I don't know if this will be helpful.

Thanks

Kevin

kdt@zz:~$ lke show -all

DEFAULT
^%ZTSCH("SUBLK","EHR:ubuntu64",449362)
Owned by PID= 449362 which is an existing process
^TIU(8925,739614) Owned by PID= 440055 which is an existing process
^TMG(22708,67) Owned by PID= 443314 which is an existing process
^XUTL("XUSYS",399648,1) Owned by PID= 399648 which is an existing process
^XUTL("XUSYS",400840,1) Owned by PID= 400840 which is an existing process
^XUTL("XUSYS",438783,1) Owned by PID= 438783 which is an existing process
^XUTL("XUSYS",440055,1) Owned by PID= 440055 which is an existing process
^XUTL("XUSYS",447066,1) Owned by PID= 447066 which is an existing process
^XUTL("XUSYS",449264,1) Owned by PID= 449264 which is an existing process
%YDB-I-LOCKSPACEINFO, Region: DEFAULT: processes on queue: 0/160; LOCK slots in use: 76/120; SUBSCRIPT slot bytes in use: 1480/5052
%YDB-I-LOCKSPACEUSE, Estimated free lock space: 36% of 40 pages

Sam Habiel

unread,

Jan 26, 2023, 11:52:01 AM1/26/23

to hard...@googlegroups.com

I know the immediate cause, but I am less sure about what caused that.

The immediate cause is that you ran out of lock space. That was caused
by a lot of VistA processes running, or being stuck, or whatever. This
may be normal; but you never noticed it before as the processes
finished with no problems before (perhaps).

I am pretty sure from the symptoms you are describing that the default
lock space used is too small; and you may run into this problem in the
future. I ran into this problem with Jordan on GT.M; but we found out
about it during training before go-live.

https://www.hardhats.org/projects/New/InstallVistAOnGTM.html describes
how you have to change the default lock space in GDE for VistA. But I
know you created your VistA system before I even wrote that page; and
prior to Jordan coming on line.

I am going to be traveling, so I can't help you much further right
now; but I would do the following steps:

Make sure you have a back-up before the next step.

Using "dse all -dump", find the column "Lock Space" for the default
region. See if it is indeed the default value (it's in hex). Use
printf to check the decimal value; or you are a graphics programmer,
you can probably do it in your head.

Change it using mupip set
(https://docs.yottadb.com/AdminOpsGuide/dbmgmt.html#lock-space). This
may require the database to be in standalone mode (no other users
using it). Make sure to update your GDE script if you have a copy of
it.

--Sam

> To view this discussion on the web visit https://groups.google.com/d/msgid/hardhats/a0f9255e-27a6-4f28-baa8-0c2bb54bf764n%40googlegroups.com.

Kevin Toppenberg

unread,

Jan 26, 2023, 11:56:12 AM1/26/23

to Hardhats

Sam,

Thank you. I get this:

Lock space 0x00000028

So it looks like I gave 40 locks ($28)

I wonder how many I need? 100? 500?

Thanks

Kevin

Sam Habiel

unread,

Jan 26, 2023, 11:57:59 AM1/26/23

to hard...@googlegroups.com

I am surprised you lasted this long with this miniscule value.

500-1000 would be good for your system.

--Sam

> To view this discussion on the web visit https://groups.google.com/d/msgid/hardhats/0a8cf340-a92e-48ca-9f7e-5af6557d74e2n%40googlegroups.com.

Kevin Toppenberg

unread,

Jan 26, 2023, 3:44:17 PM1/26/23

to Hardhats

Thanks for this information.

However, this isn't sitting well with me, as it seem like a fragile solution. As I mentioned, we are processing thousands of lines in the report, and because the overall job was bogging down the system when run in the foreground, we are setting up each line as a taskman task (as I recall). Will Taskman then try to process these all at once, and then 500-1000 still wouldn't be enough? I guess if I have gotten by for 10 yrs with 28, its not very often that this becomes a problem.

Is there a limit to the number of tasks that Taskman will work on simultaneously? It must be so. And it seems that I need to base the number of needed available database locks based on that. But then I guess each task could request multiple locks while running, so that will be factor also.

I'll still work to increase my locks to 1000.

Thanks

Kevin

K.S. Bhaskar

unread,

Jan 26, 2023, 4:52:58 PM1/26/23

to Hardhats

In case it is not clear: the actual number of locks held by processes is determined by the application code. Since the lock space is the amount of memory allocated to hold lock structures, in 512-byte pages, allocating a larger lock space than necessary just means that some memory is going unused. Having too small a lock space means that lock operations become very slow, and functionality that depends on M locks runs correspondingly slowly.

Regards

– Bhaskar

Kevin Toppenberg

unread,

Jan 26, 2023, 8:05:56 PM1/26/23

to Hardhats

Thanks Bhaskar.

If code can't get a lock, it might just fail instead of running slowly. I.e. the code might decide to give up and not keep trying. But I see what you mean.

Thanks!

Kevin

K.S. Bhaskar

unread,

Jan 26, 2023, 10:10:22 PM1/26/23

to Hardhats

Unless there is a timeout, running out of lock space should just cause lock acquisition to run like molasses, not allow a process to get a lock that it is not entitled to. What release of YottaDB are you running?

Regards

– Bhaskar

Kevin Toppenberg

unread,

Jan 27, 2023, 8:48:18 AM1/27/23

to Hardhats

Bhaskar,

I was thinking of code like this found in ^ZSY

;GT.M/VA %SY utility - status display
;From the top just show by PID
N IMAGE,MODE
W !,"GT.M system status ",! ;"//kt added ! (linefeed) to end of line

L +^XUTL("XUSYS","COMMAND"):1 I '$T G LW

S IMAGE=0,MODE=0 D WORK
Q
;

This times out after 1 second and then aborts out. But I don't know how Taskman is set up, so you are probably correct that it just sits and waits until the lock become available.

Regarding version, I see this.

yottadb>w $ZVER
GT.M V6.3-008 Linux x86_64
yottadb>

I am a bit confused because I am fairly sure I am running yottadb, not GTM. But perhaps there is a different variable I am supposed to check instead of $ZVER.

Thanks for your feedback.

Kevin

K.S. Bhaskar

unread,

Jan 27, 2023, 9:56:10 AM1/27/23

to Hardhats

Kevin, $zyrelease ($zyre) tells you the YottaDB release. $zversion tells you which GT.M version is merged into the code base, and we retain the $zversion to ensure drop-in upward compatibility.

YDB>write $zyrelease
YottaDB r1.36 Linux x86_64
YDB>

Since YottaDB is essentially continuously released (at least for development and testing environments; not for production - see https://yottadb.com/yottadb-continuous-integration-continuous-delivery/), you can even get the git commit:

$ yottadb -version
YottaDB release: r1.36
Upstream base version: GT.M V6.3-014
Platform: Linux x86_64
Build date/time: 2022-12-29 13:27
Build commit SHA: 31b5a92f2122b81fae315c2a59f4b3d1c975942d
$

Regards

– Bhaskar

Kevin Toppenberg

unread,

Jan 27, 2023, 12:07:02 PM1/27/23

to Hardhats

OK. Thanks

yottadb>w $ZVER
GT.M V6.3-008 Linux x86_64

yottadb>w $ZYRE
YottaDB r1.30 Linux x86_64
yottadb>

Kevin Toppenberg

unread,

Jan 29, 2023, 10:17:18 AM1/29/23

to Hardhats

OK, I had to wait until I had time to work on this and we had a FULL DATABASE BACKUP.

Here is my output

//=============================================

kdt@zz:~$ sh runAV

YottaDB VistA Startup Script
---Starting Setup_env script---
vista_home=/opt/worldvista/EHR
gtm_dist=/opt/worldvista/EHR/m
---Done with Setup_env script---
Entering YottaDB system now...
BLASTING OFF......
WITH
ASTRONAUT
VISTA!

yottadb>do ^GDE
%GDE-I-LOADGD, Loading Global Directory file
/opt/worldvista/EHR/g/mumps.gld
%GDE-I-VERIFY, Verification OK

GDE> change -segment DEFAULT -file="$vista_home/g/mumps.dat" -lock_space=1000
GDE> show -all

*** TEMPLATES ***
Std Inst
Def Rec Key Null Null Freeze Qdb Epoch LOCK
Region Coll Size Size Subs Coll Jnl on Err Rndwn Taper AutoDB Stats Crit
----------------------------------------------------------------------------------------------------------------------
<default> 0 256 64 NEVER N N N N Y N Y Sep

Segment Active Acc Typ Block Alloc Exten Options
------------------------------------------------------------------------------
<default> * BG DYN 1024 100 100 GLOB =1024
LOCK = 40
RES = 0
ENCR = OFF
MSLT =1024
DALL = YES
AIO = OFF
<default> MM DYN 1024 100 100 DEFER
LOCK = 40
MSLT =1024
DALL = YES

*** NAMES ***
Global Region
------------------------------------------------------------------------------
* DEFAULT

*** REGIONS ***
Std Inst
Dynamic Def Rec Key Null Null Freeze Qdb Epoch LOCK
Region Segment Coll Size Size Subs Coll Jnl on Err Rndwn Taper AutoDB Stats Crit
-------------------------------------------------------------------------------------------------------------------------------------------
DEFAULT DEFAULT 0 256 64 NEVER N N N N Y N Y Sep

*** SEGMENTS ***
Segment File (def ext: .dat)Acc Typ Block Alloc Exten Options
-------------------------------------------------------------------------------------------
DEFAULT $vista_home/g/mumps.dat
BG DYN 1024 100 100 GLOB=1024
LOCK=1000
RES = 0
ENCR= OFF
MSLT=1024
DALL= YES
AIO = OFF

*** MAP ***
- - - - - - - - - - Names - - - - - - - - - -
From Up to Region / Segment / File(def ext: .dat)
--------------------------------------------------------------------------------------------------------------------------
% ... REG = DEFAULT
SEG = DEFAULT
FILE = $vista_home/g/mumps.dat
LOCAL LOCKS REG = DEFAULT
SEG = DEFAULT
FILE = $vista_home/g/mumps.dat
GDE> save
%GDE-E-KEYWRDBAD, SAVE is not a valid verb in this context

GDE> exit
%GDE-I-VERIFY, Verification OK

%GDE-I-GDUPDATE, Updating Global Directory file
/opt/worldvista/EHR/g/mumps.gld

yottadb>

yottadb>h

Leaving YottaDB, returning to Linux...

kdt@zz:~$ dse all -dump

File /opt/worldvista/EHR/g/mumps.dat
Region DEFAULT

File /opt/worldvista/EHR/g/mumps.dat
Region DEFAULT
Date/Time 29-JAN-2023 10:12:04 [$H = 66503,36724]
Access method BG Global Buffers 7000
Reserved Bytes 0 Block size (in bytes) 4096
Maximum record size 32767 Starting VBN 129
Maximum key size 510 Total blocks 0x003A19CB
Null subscripts NEVER Free blocks 0x0007654A
Standard Null Collation FALSE Free space 0x00006000
Last Record Backup 0x0000000000000001 Extension Count 20000
Last Database Backup 0x0000000004C8B6AA Number of local maps 7437
Last Bytestream Backup 0x0000000000000001 Lock space 0x00000028
In critical section 0x00000000 Timers pending 1
Cache freeze id 0x00000000 Flush timer 00:00:01:00
Freeze match 0x00000000 Flush trigger 6563
Freeze online FALSE Freeze online autorelease FALSE
Current transaction 0x00000003BBF4A1DC No. of writes/flush 7
Maximum TN 0xFFFFFFFFDFFFFFFF Certified for Upgrade to V6
Maximum TN Warn 0xFFFFFFFF5FFFFFFF Desired DB Format V6
Master Bitmap Size 64 Blocks to Upgrade 0x00000000
Create in progress FALSE Modified cache blocks 2
Reference count 4 Wait Disk 0
Journal State ON Journal Before imaging TRUE
Journal Allocation 2048 Journal Extension 100
Journal Buffer Size 2312 Journal Alignsize 4096
Journal AutoSwitchLimit 8388548 Journal Epoch Interval 300
Journal Yield Limit 8 Journal Sync IO FALSE
Journal File: /opt/worldvista/EHR/j/mumps.mjl
Mutex Hard Spin Count 128 Mutex Sleep Spin Count 128
Mutex Queue Slots 1024 KILLs in progress 0
Replication State OFF Region Seqno 0x0000000000000001
Zqgblmod Seqno 0x0000000000000000 Zqgblmod Trans 0x0000000000000000
Endian Format LITTLE Commit Wait Spin Count 16
Database file encrypted FALSE Inst Freeze on Error FALSE
Spanning Node Absent FALSE Maximum Key Size Assured FALSE
Defer allocation TRUE Spin sleep time mask 0x00000000
Async IO OFF WIP queue cache blocks 0
DB is auto-created FALSE DB shares gvstats TRUE
LOCK shares DB critical section FALSE Read Only OFF
Recover interrupted FALSE
Reorg Sleep Nanoseconds 0
kdt@zz:~$

//==============================================

Questions

1) Why does my dse output still show --> Lock space 0x00000028 (40 decimal)

2) When I do a show --all in GDE, it ouputs the following (more above). There is a 'N' under 'Jnl'. Does this mean I am not journaling?? I thought I had this turned on?

GDE> show -all

*** TEMPLATES ***
Std Inst
Def Rec Key Null Null Freeze Qdb Epoch LOCK
Region Coll Size Size Subs Coll Jnl on Err Rndwn Taper AutoDB Stats Crit
----------------------------------------------------------------------------------------------------------------------
<default> 0 256 64 NEVER N N N N Y N Y Sep

Thanks

Kevin

Kevin Toppenberg

unread,

Jan 29, 2023, 10:30:54 AM1/29/23

to Hardhats

When I post this, I am changing the font to a fix-width font, so the columns line up.

But the forum software seems to be stripping all that out. I seem to recall being able to include formatting int he past. Has something changed??

Kevin

Nancy Anthracite

unread,

Jan 29, 2023, 10:37:24 AM1/29/23

to Hardhats, Kevin Toppenberg

Put it in a text document and send it to me and I will post it with a URL for
people to pick it up.

--
Nancy Anthracite

> >>>>>>>>> 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.
> >>>>>>>>> >> >> > To view this discussion on the web visit
> >>>>>>>>> https://groups.google.com/d/msgid/hardhats/
37295e1b-5c33-4c62-8867-98fa9dd103d4n%40googlegroups.com.
> >>>>>>>>>
> >>>>>>>>> >> >

> >>>>>>>>> Google Groups "Hardhats" group.
> >>>>>>>>> >> > To unsubscribe from this group and stop receiving emails from
> >>>>>>>>> it, send an email to hardhats+u...@googlegroups.com.
> >>>>>>>>> >> > To view this discussion on the web visit
> >>>>>>>>> https://groups.google.com/d/msgid/hardhats/a0f9255e-27a6-4f28-baa8-0c2bb54bf764n%40googlegroups.com.
> >>>>>>>>>
> >>>>>>>>> >

Kevin Toppenberg

unread,

Jan 29, 2023, 10:40:10 AM1/29/23

to Hardhats

Thanks for the offer. I'll consider that if I get everything working.

Kevin

Sam Habiel

unread,

Feb 22, 2023, 12:26:43 PM2/22/23

to hard...@googlegroups.com

Kevin,

I am replying now way after the fact as I am back now.

Questions

1) Why does my dse output still show --> Lock space 0x00000028 (40 decimal)

2) When I do a show --all in GDE, it ouputs the following (more above). There is a 'N' under 'Jnl'. Does this mean I am not journaling?? I thought I had this turned on?

I think I mentioned in an earlier email that GDE changes do not apply to the current database, but to any future database. The ONLY GDE change you make that will apply to the current database is global mapping changes. Sadly, this is more complexity than most people are expecting, but this is a long standing GT.M thing.

--Sam

To view this discussion on the web visit https://groups.google.com/d/msgid/hardhats/4c757985-a430-46ee-aa6a-737fc0f197b9n%40googlegroups.com.

Reply all

Reply to author

Forward