Hello all,

I have recently upgraded my system from GTM to yottadb, as part of a larger migration to a more recent version of Ubuntu LTS.

I got a notice today that one of my hard drives was almost full. Researching this, I found that that my journal files were quite large, 3 GB generated in 1 day. That is much more than I have experienced in the past. My scripts delete journal files
older than 2-3 days, as I recall. So several days of journal files are adding up.

I opened the .mjl file with an editor to see if I could get any ideas, and while much of the data is unreadable, there were many string entries referencing taskman tasks, and the %ZTSCH global. (This yottadb is supporting a VistA EMR).

I seem to remember years ago when setting up my prior GT.M, that I configured the database to exclude journaling on certain globals that are subject to much churning, including ^TMP.

I tried scanning through the journal information in the yottadb operation guide, here: https://docs.yottadb.com/AdminOpsGuide/ydbjournal.html
It seem that when turning on journaling, it is done for "regions." But I am not sure how regions of the database correspond to particular globals.

Summary:
-- How to stop journaling for particular globals?

Thanks
Kevin Toppenberg.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

For my future reference, I found in the AdminOpsGuide that a better way to view the contents of the .mjl file is via the command

mupip journal -extract=-stdout -forward

And after pressing [enter], I am prompted for the name of the journal file.

Kevin

On Sunday, July 11, 2021 at 4:51:20 PM UTC-4, kdtop wrote:

Hello all,

I have recently upgraded my system from GTM to yottadb, as part of a larger migration to a more recent version of Ubuntu LTS.

I got a notice today that one of my hard drives was almost full. Researching this, I found that that my journal files were quite large, 3 GB generated in 1 day. That is much more than I have experienced in the past. My scripts delete journal files

older than 2-3 days, as I recall. So several days of journal files are adding up.

I opened the .mjl file with an editor to see if I could get any ideas, and while much of the data is unreadable, there were many string entries referencing taskman tasks, and the %ZTSCH global. (This yottadb is supporting a VistA EMR).

I seem to remember years ago when setting up my prior GT.M, that I configured the database to exclude journaling on certain globals that are subject to much churning, including ^TMP.

I tried scanning through the journal information in the yottadb operation guide, here: https://docs.yottadb.com/AdminOpsGuide/ydbjournal.html
It seem that when turning on journaling, it is done for "regions." But I am not sure how regions of the database correspond to particular globals.

Summary:
-- How to stop journaling for particular globals?

Thanks
Kevin Toppenberg.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, July 11, 2021 at 5:48:45 PM UTC-4, kdtop wrote:

For my future reference, I found in the AdminOpsGuide that a better way to view the contents of the .mjl file is via the command

mupip journal -extract=-stdout -forward

And after pressing [enter], I am prompted for the name of the journal file.

Kevin
On Sunday, July 11, 2021 at 4:51:20 PM UTC-4, kdtop wrote:

Hello all,

I have recently upgraded my system from GTM to yottadb, as part of a larger migration to a more recent version of Ubuntu LTS.

I got a notice today that one of my hard drives was almost full. Researching this, I found that that my journal files were quite large, 3 GB generated in 1 day. That is much more than I have experienced in the past. My scripts delete journal files

older than 2-3 days, as I recall. So several days of journal files are adding up.

I opened the .mjl file with an editor to see if I could get any ideas, and while much of the data is unreadable, there were many string entries referencing taskman tasks, and the %ZTSCH global. (This yottadb is supporting a VistA EMR).

I seem to remember years ago when setting up my prior GT.M, that I configured the database to exclude journaling on certain globals that are subject to much churning, including ^TMP.

I tried scanning through the journal information in the yottadb operation guide, here: https://docs.yottadb.com/AdminOpsGuide/ydbjournal.html
It seem that when turning on journaling, it is done for "regions." But I am not sure how regions of the database correspond to particular globals.

Summary:
-- How to stop journaling for particular globals?

Thanks
Kevin Toppenberg.

Kevin,
The gritty details are in the admin/ops manual, but the basics are you define a new segment and region for the the globals you don't want journalled, then 'point' the global names at that region in the 'Name' section.
If you can still run GDE on the old GTM system, you should be able to list the old global directory to see how it was done. It hasn't changed unless you are on a very old version of GTM.

Mark

Mark

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Kevin –

https://docs.yottadb.com/AcculturationGuide/acculturation.html#global-directories-point-to-global-variables shows how a region defines a set of global variables to be mapped to a database file.

Also, instead of typing mupip journal -extract=-stdout -forward and waiting to be prompted for a journal file name, you can type mupip journal -extract=-stdout -forward <journalfilename> all on the command line.

Regards
– Bhaskar

On Sunday, July 11, 2021 at 5:48:45 PM UTC-4, kdtop wrote:

For my future reference, I found in the AdminOpsGuide that a better way to view the contents of the .mjl file is via the command

mupip journal -extract=-stdout -forward

And after pressing [enter], I am prompted for the name of the journal file.

Kevin
On Sunday, July 11, 2021 at 4:51:20 PM UTC-4, kdtop wrote:

Hello all,

I have recently upgraded my system from GTM to yottadb, as part of a larger migration to a more recent version of Ubuntu LTS.

I got a notice today that one of my hard drives was almost full. Researching this, I found that that my journal files were quite large, 3 GB generated in 1 day. That is much more than I have experienced in the past. My scripts delete journal files

older than 2-3 days, as I recall. So several days of journal files are adding up.

I opened the .mjl file with an editor to see if I could get any ideas, and while much of the data is unreadable, there were many string entries referencing taskman tasks, and the %ZTSCH global. (This yottadb is supporting a VistA EMR).

I seem to remember years ago when setting up my prior GT.M, that I configured the database to exclude journaling on certain globals that are subject to much churning, including ^TMP.

I tried scanning through the journal information in the yottadb operation guide, here: https://docs.yottadb.com/AdminOpsGuide/ydbjournal.html
It seem that when turning on journaling, it is done for "regions." But I am not sure how regions of the database correspond to particular globals.

Summary:
-- How to stop journaling for particular globals?

Thanks
Kevin Toppenberg.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bhaskar,

Thanks for this. I will need to study it.

Kevin

On Monday, July 12, 2021 at 5:21:45 PM UTC-4, K.S. Bhaskar wrote:

Kevin –

https://docs.yottadb.com/AcculturationGuide/acculturation.html#global-directories-point-to-global-variables shows how a region defines a set of global variables to be mapped to a database file.

Also, instead of typing mupip journal -extract=-stdout -forward and waiting to be prompted for a journal file name, you can type mupip journal -extract=-stdout -forward <journalfilename> all on the command line.

Regards
– Bhaskar
On Sunday, July 11, 2021 at 5:48:45 PM UTC-4, kdtop wrote:

For my future reference, I found in the AdminOpsGuide that a better way to view the contents of the .mjl file is via the command

mupip journal -extract=-stdout -forward

And after pressing [enter], I am prompted for the name of the journal file.

Kevin
On Sunday, July 11, 2021 at 4:51:20 PM UTC-4, kdtop wrote:

Hello all,

I have recently upgraded my system from GTM to yottadb, as part of a larger migration to a more recent version of Ubuntu LTS.

I got a notice today that one of my hard drives was almost full. Researching this, I found that that my journal files were quite large, 3 GB generated in 1 day. That is much more than I have experienced in the past. My scripts delete journal files

older than 2-3 days, as I recall. So several days of journal files are adding up.

I opened the .mjl file with an editor to see if I could get any ideas, and while much of the data is unreadable, there were many string entries referencing taskman tasks, and the %ZTSCH global. (This yottadb is supporting a VistA EMR).

I seem to remember years ago when setting up my prior GT.M, that I configured the database to exclude journaling on certain globals that are subject to much churning, including ^TMP.

I tried scanning through the journal information in the yottadb operation guide, here: https://docs.yottadb.com/AdminOpsGuide/ydbjournal.html
It seem that when turning on journaling, it is done for "regions." But I am not sure how regions of the database correspond to particular globals.

Summary:
-- How to stop journaling for particular globals?

Thanks
Kevin Toppenberg.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bhaskar (or others),

I'm just now getting to study this document. As I follow along, I typed in GDE --> show -region.

show -region

*** 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



The output wraps around, around, like the display width is too narrow. So I drag the putty window out wide, and it still does it. So it must be the definition of the display width is incorrect in yottadb. I tried logging into VistA to set up the
terminal parameters. But then GDE won't launch, giving the following message

yottadb>do ^GDE

%YDB-E-COLLDATAEXISTS, Collation type cannot be changed while subscripted local data exists
%GDE-I-NOACTION, Not updating Global Directory /opt/worldvista/EHR/g/mumps.gld

yottadb>kill


But after I issue a KILL, it will run.

So how do I set up the terminal properly?

Thanks
Kevin


On Monday, July 12, 2021 at 5:21:45 PM UTC-4, K.S. Bhaskar wrote:

Kevin –

https://docs.yottadb.com/AcculturationGuide/acculturation.html#global-directories-point-to-global-variables shows how a region defines a set of global variables to be mapped to a database file.

Also, instead of typing mupip journal -extract=-stdout -forward and waiting to be prompted for a journal file name, you can type mupip journal -extract=-stdout -forward <journalfilename> all on the command line.

Regards
– Bhaskar
On Sunday, July 11, 2021 at 5:48:45 PM UTC-4, kdtop wrote:

For my future reference, I found in the AdminOpsGuide that a better way to view the contents of the .mjl file is via the command

mupip journal -extract=-stdout -forward

And after pressing [enter], I am prompted for the name of the journal file.

Kevin
On Sunday, July 11, 2021 at 4:51:20 PM UTC-4, kdtop wrote:

Hello all,

I have recently upgraded my system from GTM to yottadb, as part of a larger migration to a more recent version of Ubuntu LTS.

I got a notice today that one of my hard drives was almost full. Researching this, I found that that my journal files were quite large, 3 GB generated in 1 day. That is much more than I have experienced in the past. My scripts delete journal files

older than 2-3 days, as I recall. So several days of journal files are adding up.

I opened the .mjl file with an editor to see if I could get any ideas, and while much of the data is unreadable, there were many string entries referencing taskman tasks, and the %ZTSCH global. (This yottadb is supporting a VistA EMR).

I seem to remember years ago when setting up my prior GT.M, that I configured the database to exclude journaling on certain globals that are subject to much churning, including ^TMP.

I tried scanning through the journal information in the yottadb operation guide, here: https://docs.yottadb.com/AdminOpsGuide/ydbjournal.html
It seem that when turning on journaling, it is done for "regions." But I am not sure how regions of the database correspond to particular globals.

Summary:
-- How to stop journaling for particular globals?

Thanks
Kevin Toppenberg.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, July 15, 2021 at 9:22:20 AM UTC-4, kdtop wrote:

Bhaskar (or others),

I'm just now getting to study this document. As I follow along, I typed in GDE --> show -region.

show -region

*** 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

The output wraps around, around, like the display width is too narrow. So I drag the putty window out wide, and it still does it. So it must be the definition of the display width is incorrect in yottadb. I tried logging into VistA to set up the

terminal parameters. But then GDE won't launch, giving the following message

yottadb>do ^GDE

%YDB-E-COLLDATAEXISTS, Collation type cannot be changed while subscripted local
data exists
%GDE-I-NOACTION, Not updating Global Directory /opt/worldvista/EHR/g/mumps.gld

yottadb>kill

But after I issue a KILL, it will run.

So how do I set up the terminal properly?

Thanks
Kevin

On Monday, July 12, 2021 at 5:21:45 PM UTC-4, K.S. Bhaskar wrote:

Kevin –

https://docs.yottadb.com/AcculturationGuide/acculturation.html#global-directories-point-to-global-variables shows how a region defines a set of global variables to be mapped to a database file.

Also, instead of typing mupip journal -extract=-stdout -forward and waiting to be prompted for a journal file name, you can type mupip journal -extract=-stdout -forward <journalfilename> all on the command line.

Regards
– Bhaskar
On Sunday, July 11, 2021 at 5:48:45 PM UTC-4, kdtop wrote:

For my future reference, I found in the AdminOpsGuide that a better way to view the contents of the .mjl file is via the command

mupip journal -extract=-stdout -forward

And after pressing [enter], I am prompted for the name of the journal file.

Kevin
On Sunday, July 11, 2021 at 4:51:20 PM UTC-4, kdtop wrote:

Hello all,

I have recently upgraded my system from GTM to yottadb, as part of a larger migration to a more recent version of Ubuntu LTS.

I got a notice today that one of my hard drives was almost full. Researching this, I found that that my journal files were quite large, 3 GB generated in 1 day. That is much more than I have experienced in the past. My scripts delete journal

files older than 2-3 days, as I recall. So several days of journal files are adding up.

I opened the .mjl file with an editor to see if I could get any ideas, and while much of the data is unreadable, there were many string entries referencing taskman tasks, and the %ZTSCH global. (This yottadb is supporting a VistA EMR).

I seem to remember years ago when setting up my prior GT.M, that I configured the database to exclude journaling on certain globals that are subject to much churning, including ^TMP.

I tried scanning through the journal information in the yottadb operation guide, here: https://docs.yottadb.com/AdminOpsGuide/ydbjournal.html
It seem that when turning on journaling, it is done for "regions." But I am not sure how regions of the database correspond to particular globals.

Summary:
-- How to stop journaling for particular globals?

Thanks
Kevin Toppenberg.

Kevin, YottaDB does not respond to dynamic terminal window resizing (which would need a handler for SIGWINCH to be implemented, much as there exists a handler for SIGUSR1/SIGUSR2). From the shell maximize your terminal window before going into YottaDB.
You can also examine a global directory directly from a shell using the command: yottadb -run GDE <<<"show -command"

For example:

$ yottadb -run GDE <<<"show -command"
%GDE-I-LOADGD, Loading Global Directory file
/tmp/test/r1.32_x86_64/g/yottadb.gld
%GDE-I-VERIFY, Verification OK



TEMPLATE -REGION -NOAUTODB
TEMPLATE -REGION -COLLATION_DEFAULT=0
TEMPLATE -REGION -EPOCHTAPER
TEMPLATE -REGION -NOINST_FREEZE_ON_ERROR
TEMPLATE -REGION -JOURNAL=(ALLOCATION=2048,AUTOSWITCHLIMIT=8386560,BEFORE_IMAGE,BUFFER_SIZE=2312,EXTENSION=2048)
TEMPLATE -REGION -KEY_SIZE=1019
TEMPLATE -REGION -LOCK_CRIT_SEPARATE
TEMPLATE -REGION -NULL_SUBSCRIPTS=ALWAYS
TEMPLATE -REGION -NOQDBRUNDOWN
TEMPLATE -REGION -RECORD_SIZE=1048576
TEMPLATE -REGION -STATS
TEMPLATE -REGION -STDNULLCOLL
!
!
TEMPLATE -SEGMENT -ACCESS_METHOD=BG
TEMPLATE -SEGMENT -ALLOCATION=10000
TEMPLATE -SEGMENT -NOASYNCIO
TEMPLATE -SEGMENT -BLOCK_SIZE=2048
TEMPLATE -SEGMENT -DEFER_ALLOCATE
TEMPLATE -SEGMENT -NOENCRYPTION_FLAG
TEMPLATE -SEGMENT -EXTENSION_COUNT=20000
TEMPLATE -SEGMENT -GLOBAL_BUFFER_COUNT=2000
TEMPLATE -SEGMENT -LOCK_SPACE=220
TEMPLATE -SEGMENT -MUTEX_SLOTS=1024
TEMPLATE -SEGMENT -RESERVED_BYTES=0
!
TEMPLATE -SEGMENT -ACCESS_METHOD=MM
TEMPLATE -SEGMENT -ALLOCATION=20000
TEMPLATE -SEGMENT -NOASYNCIO
TEMPLATE -SEGMENT -BLOCK_SIZE=1024
TEMPLATE -SEGMENT -DEFER
TEMPLATE -SEGMENT -DEFER_ALLOCATE
TEMPLATE -SEGMENT -NOENCRYPTION_FLAG
TEMPLATE -SEGMENT -EXTENSION_COUNT=40000
TEMPLATE -SEGMENT -GLOBAL_BUFFER_COUNT=1000
TEMPLATE -SEGMENT -LOCK_SPACE=220
TEMPLATE -SEGMENT -MUTEX_SLOTS=1024
TEMPLATE -SEGMENT -RESERVED_BYTES=0
!
TEMPLATE -SEGMENT -ACCESS_METHOD=BG
!
DELETE -REGION DEFAULT
DELETE -SEGMENT DEFAULT
ADD -REGION DEFAULT -DYNAMIC_SEGMENT=DEFAULT -JOURNAL=(FILE_NAME="$ydb_dir/$ydb_rel/g/yottadb.mjl") -KEY_SIZE=255 -NULL_SUBSCRIPTS=NEVER -RECORD_SIZE=4080
ADD -REGION YDBAIM -AUTODB -DYNAMIC_SEGMENT=YDBAIM -NOJOURNAL -KEY_SIZE=992 -RECORD_SIZE=1008
ADD -REGION YDBOCTO -DYNAMIC_SEGMENT=YDBOCTO -JOURNAL=(FILE_NAME="$ydb_dir/$ydb_rel/g/%ydbocto.mjl")
!
ADD -SEGMENT DEFAULT -ALLOCATION=5000 -BLOCK_SIZE=4096 -EXTENSION_COUNT=10000 -FILE_NAME="$ydb_dir/$ydb_rel/g/yottadb.dat" -GLOBAL_BUFFER_COUNT=1000
ADD -SEGMENT YDBAIM -ACCESS_METHOD=MM -FILE_NAME="$ydb_dir/$ydb_rel/g/%ydbaim.dat"
ADD -SEGMENT YDBOCTO -FILE_NAME="$ydb_dir/$ydb_rel/g/%ydbocto.dat"
!
LOCKS -REGION=DEFAULT
ADD -NAME %ydbAIM* -REGION=YDBAIM
ADD -NAME %ydbAIm* -REGION=YDBAIM
ADD -NAME %ydbAiM* -REGION=YDBAIM
ADD -NAME %ydbAim* -REGION=YDBAIM
ADD -NAME %ydbOCTO* -REGION=YDBOCTO
ADD -NAME %ydbOCTo* -REGION=YDBOCTO
ADD -NAME %ydbOCtO* -REGION=YDBOCTO
ADD -NAME %ydbOCto* -REGION=YDBOCTO
ADD -NAME %ydbOcTO* -REGION=YDBOCTO
ADD -NAME %ydbOcTo* -REGION=YDBOCTO
ADD -NAME %ydbOctO* -REGION=YDBOCTO
ADD -NAME %ydbOcto* -REGION=YDBOCTO
ADD -NAME %ydbaIM* -REGION=YDBAIM
ADD -NAME %ydbaIm* -REGION=YDBAIM
ADD -NAME %ydbaiM* -REGION=YDBAIM
ADD -NAME %ydbaim* -REGION=YDBAIM
ADD -NAME %ydboCTO* -REGION=YDBOCTO
ADD -NAME %ydboCTo* -REGION=YDBOCTO
ADD -NAME %ydboCtO* -REGION=YDBOCTO
ADD -NAME %ydboCto* -REGION=YDBOCTO
ADD -NAME %ydbocTO* -REGION=YDBOCTO
ADD -NAME %ydbocTo* -REGION=YDBOCTO
ADD -NAME %ydboctO* -REGION=YDBOCTO
ADD -NAME %ydbocto* -REGION=YDBOCTO
!

%GDE-I-NOACTION, Not updating Global Directory /tmp/test/r1.32_x86_64/g/yottadb.gld
$

You can put the command file under version control, for example, and you can load a command file into GDE. Details at https://docs.yottadb.com/AdminOpsGuide/gde.html

Regards
– Bhaskar

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, July 15, 2021 at 11:16:44 AM UTC-4, K.S. Bhaskar wrote:

On Thursday, July 15, 2021 at 9:22:20 AM UTC-4, kdtop wrote:

Bhaskar (or others),

I'm just now getting to study this document. As I follow along, I typed in GDE --> show -region.

... snip --

The output wraps around, around, like the display width is too narrow. So I drag the putty window out wide, and it still does it. So it must be the definition of the display width is incorrect in yottadb. I tried logging into VistA to set up the

terminal parameters. But then GDE won't launch, giving the following message

- snip -

Kevin, YottaDB does not respond to dynamic terminal window resizing (which would need a handler for SIGWINCH to be implemented, much as there exists a handler for SIGUSR1/SIGUSR2). From the shell maximize your terminal window before going into YottaDB.

You can also examine a global directory directly from a shell using the command: yottadb -run GDE <<<"show -command"

-snip-

Regards
– Bhaskar

Bhaskar,

I understand that SIGWINCH event handler is not yet implemented. Maybe someday...

Making the window big BEFORE opening YottaDB seemed to do the trick, as you said.

Thanks
Kevin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Pada Senin, 12 Juli 2021 pukul 03.51.20 UTC+7, kdtop menulis:

Hello all,

I have recently upgraded my system from GTM to yottadb, as part of a larger migration to a more recent version of Ubuntu LTS.

I got a notice today that one of my hard drives was almost full. Researching this, I found that that my journal files were quite large, 3 GB generated in 1 day. That is much more than I have experienced in the past. My scripts delete journal files

older than 2-3 days, as I recall. So several days of journal files are adding up.

I opened the .mjl file with an editor to see if I could get any ideas, and while much of the data is unreadable, there were many string entries referencing taskman tasks, and the %ZTSCH global. (This yottadb is supporting a VistA EMR).

I seem to remember years ago when setting up my prior GT.M, that I configured the database to exclude journaling on certain globals that are subject to much churning, including ^TMP.

I tried scanning through the journal information in the yottadb operation guide, here: https://docs.yottadb.com/AdminOpsGuide/ydbjournal.html
It seem that when turning on journaling, it is done for "regions." But I am not sure how regions of the database correspond to particular globals.

Summary:
-- How to stop journaling for particular globals?

Thanks
Kevin Toppenberg.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)