EWD and VistA basic mapping and convention questions.
Ignacio Valdes
installation working out of the box with Astronaut. Does EWD expect
its database to be the default in the .gld? I do see somewhat how to
'connect the dots' in the ewd.conf and how it maps to a .gld It is not
clear to me how I would do that coherently with a EWD database and a
VistA database. My assumption is that I will need a separate database
with different characteristics to install VistA and EWD side by side.
To that end, I have written the following preliminary bash
installation code to create an ewd database. If there are no
objections I will call the database file ewd.dat and prefix the region
and segment with, wait for it, ewd. As follows:
$gtm_path/mumps -r ^GDE << EOF
change -segment DEFAULT -file=$vista_path/g/mumps.dat
add -name ewd -region=ewdreg
add -region ewdreg -d=ewdseg
add -segment ewdseg -file=$vista_path/g/ewd
exit
EOF
$gtm_path/mumps -r ^GDE << EOF
change -segment ewdseg -block=32256
change -region ewdreg -key=255 -record=32240
exit
EOF
My ewd.conf once installed looks like this:
LoadModule m_apache_module
/opt/worldvista/EHR/web/ewdapps/m_apache/m_apache22.so
<Location /ewd>
SetEnv MGWSI_PORT 7041
SetEnv MGWSI_M_UCI /opt/worldvista/EHR/g/mumps.gld
SetEnv MGWSI_M_FUNCTION runPage^%zewdGTMRuntime
</Location>
<Location "/mgwsi/sys/">
# This is a reserved location used for the m_apache systems
facilities invoked through: /mgwsi/sys/system_functions.mgwsi
Order deny,allow
Allow from all
</Location>
So my question is what is the best way to have my mumps.dat and what I
am calling ewd.dat side by side. Should I have two separate .gld files
that map to each database or is there a way to tell ewd about a
particular database with one .gld file that contains the information
for both VistA (currently by default mumps.dat) and ewd?
-- IV
LD 'Gus' Landis
[ignacio: as you can tell, got distracted since our call].
You can have multiple database files in a GT.M Global
Directory. For a simple VISTA system, I use the first set
of commands. The "temp globals" (which are neither
journaled nor replicated), and are stored in tempgbl.dat.
For my larger GT.M infrastructure, I have a database
file/REGION for each "application". In the db.gde file
provided, "includes" the varous application .gde files.
I have included samples for EWD and VISTA. Others
(e.g. M/DB etc) are planned.
Note that there are limits in GT.M to how many database
files may exist, but the smallest that I know of is on AIX
which in the 32-bit version (pre V5.2 something) limits
you to 9 database files. With Linux there is a limit to the
number of database files, but it is "ridiculously" high.
Cheers,
--ldl
change -segment DEFAULT -file="/home/s0104/g/default.dat"
-allocation=200000 -block_size=4096 -lock_space=1000
-extension_count=10000
add -segment TEMPGBL -file="/home/s0104/g/tempgbl.dat"
-allocation=10000 -block_size=4096 -lock_space=1000
-extension_count=1000
change -region DEFAULT -record_size=4080 -key_size=255
add -region TEMPGBL -record_size=4080 -key_size=255 -dyn=TEMPGBL
add -name HLTMP -region=TEMPGBL
add -name TMP -region=TEMPGBL
add -name UTILITY -region=TEMPGBL
add -name XTMP -region=TEMPGBL
add -name XUTL -region=TEMPGBL
show -all
-------------------------------------------------------------------
./lsb-fws/instance-proto/ewd/g/
./lsb-fws/instance-proto/ewd/g/gde/
./lsb-fws/instance-proto/ewd/g/gde/vista.gde
./lsb-fws/instance-proto/ewd/g/gde/default.gde
./lsb-fws/instance-proto/ewd/g/gde/ewd.gde
./lsb-fws/instance-proto/ewd/g/db.gde
ldl@boGus:~$ cd lsb-fws/instance-proto/ewd/g
ldl@boGus:~/lsb-fws/instance-proto/ewd/g$ ls
db.gld gde
ldl@boGus:~/lsb-fws/instance-proto/ewd/g$ cat db.gde
@g/gde/default.gde
@g/gde/ewd.gde
show -all
ldl@boGus:~/lsb-fws/instance-proto/ewd/g$ cat gde/default.gde
!!!
! These are the specifications for the globals in DEFAULT
!
! A good default for VISTA systems is 4K (4096) blocks, which
! allows 4080 byte nodes. If you want to adjust this, be sure
! to keep the block_size on even disk block boundaries (e.g. a
! multiple of 512), and the record_size must be at least 16
! bytes less than the block_size.
!
! The maximum key_size is 255, so we'll use that. Feel free
! to reduce this is you want, but that is your call.
!
! It is easier to recover from a full database that it is to
! recover from a full disk drive. So, using an extension_count
! of 0 means that you'll need to keep an eye on how much free
! space you have (^%FREECNT). Change to auto extend with a
! extension_count=<blocks> at your own peril. All you'll need
! is one "run-away" job, or a bad error trap to convince you
! of the wisdom of not using a non-zero extension_count!!
!
change -segment DEFAULT -file="$DBINST/g/default.dat"
-allocation=20000 -block_size=4096 -lock_space=1000 -extension_count=0
change -region DEFAULT -record_size=4080 -key_size=255
!
! End of $Source$
ldl@boGus:~/lsb-fws/instance-proto/ewd/g$ cat gde/ewd.gde
!!!
! These are the specifications for EWD globals
!
! This is likely going to be revised. At present I expect
! to keep M/Gateway's M/DB in a separate area, so those will
! move. Also, I am not yet sure how I intend to handle the
! M/Gateway MGWSI element, as I think it should be separate
! also.
!
! Presently the M/Gateway DOM manipulation needs large global
! nodes, so these are all in a database file that has ~32K
! nodes.
!
add -segment EWDGBLS -file="$DBINST/g/ewdgbls.dat" -allocation=20000
-block_size=32256 -lock_space=1000 -extension_count=0
add -region EWDGBLS -record_size=32240 -key_size=255 -dyn=EWDGBLS
!
add -name %MGWSI -region=EWDGBLS
add -name %zewd -region=EWDGBLS
add -name %zewdIndex -region=EWDGBLS
add -name MDBConfig -region=EWDGBLS
add -name MDBErrors -region=EWDGBLS
add -name zewd -region=EWDGBLS
! End of $Source$
ldl@boGus:~/lsb-fws/instance-proto/ewd/g$ cat gde/vista.gde
!!!
! These are the specifications for VISTA globals
!
! The conventional settings for VISTA have been 4K blocks, with
! 255 byte keys. The relationship between block_size and the
! maximum record_size (maximum length of a node) is:
! record_size = block_size - 16
! so that leaves a record_size of 4080.
!
!--------------------------------------------------------------
! Official VISTA Temporary Globals
!
add -segment TEMPGBL -file="$DBINST/g/tempgbl.dat" -allocation=10000
-block_size=4096 -lock_space=1000 -extension_count=0
add -region TEMPGBL -record_size=4080 -key_size=255 -dyn=TEMPGBL
add -name HLTMP -region=TEMPGBL
add -name TMP -region=TEMPGBL
add -name UTILITY -region=TEMPGBL
add -name XTMP -region=TEMPGBL
add -name XUTL -region=TEMPGBL
!
!--------------------------------------------------------------
! Official VISTA Persistant Globals
!
add -segment VISTAGB -file="$DBINST/g/vistagb.dat" -allocation=200000
-block_size=4096 -lock_space=1000 -extension_count=0
add -region VISTAGB -record_size=4080 -key_size=255 -dyn=VISTAGB
add -name %Z -region VISTAGB
add -name %ZE -region VISTAGB
add -name %ZIS -region VISTAGB
add -name %ZISL -region VISTAGB
add -name %ZOSF -region VISTAGB
add -name %ZTER -region VISTAGB
add -name %ZTSCH -region VISTAGB
add -name %ZTSK -region VISTAGB
add -name %ZUA -region VISTAGB
add -name %ZUT -region VISTAGB
add -name ABS -region VISTAGB
add -name ACK -region VISTAGB
add -name AFJ -region VISTAGB
add -name ALPB -region VISTAGB
add -name ANRV -region VISTAGB
add -name APSPQA -region VISTAGB
add -name AUPNPAT -region VISTAGB
add -name AUPNPROB -region VISTAGB
add -name AUPNVCPT -region VISTAGB
add -name AUPNVHF -region VISTAGB
add -name AUPNVIMM -region VISTAGB
add -name AUPNVPED -region VISTAGB
add -name AUPNVPOV -region VISTAGB
add -name AUPNVPRV -region VISTAGB
add -name AUPNVSIT -region VISTAGB
add -name AUPNVSK -region VISTAGB
add -name AUPNVTRT -region VISTAGB
add -name AUPNVXAM -region VISTAGB
add -name AUTNPOV -region VISTAGB
add -name AUTTEDT -region VISTAGB
add -name AUTTEXAM -region VISTAGB
add -name AUTTHF -region VISTAGB
add -name AUTTIMM -region VISTAGB
add -name AUTTLOC -region VISTAGB
add -name AUTTSK -region VISTAGB
add -name AUTTTRT -region VISTAGB
add -name AWC -region VISTAGB
add -name BPS -region VISTAGB
add -name BPSC -region VISTAGB
add -name BPSECX -region VISTAGB
add -name BPSF -region VISTAGB
add -name BPSR -region VISTAGB
add -name BPST -region VISTAGB
add -name BPSTL -region VISTAGB
add -name CRHD -region VISTAGB
add -name DD -region VISTAGB
add -name DDA -region VISTAGB
add -name DENT -region VISTAGB
add -name DG -region VISTAGB
add -name DGAM -region VISTAGB
add -name DGBT -region VISTAGB
add -name DGCN -region VISTAGB
add -name DGCPT -region VISTAGB
add -name DGCR -region VISTAGB
add -name DGEN -region VISTAGB
add -name DGENA -region VISTAGB
add -name DGHT -region VISTAGB
add -name DGICD9 -region VISTAGB
add -name DGIN -region VISTAGB
add -name DGM -region VISTAGB
add -name DGMS -region VISTAGB
add -name DGMT -region VISTAGB
add -name DGNT -region VISTAGB
add -name DGP -region VISTAGB
add -name DGPF -region VISTAGB
add -name DGPM -region VISTAGB
add -name DGPR -region VISTAGB
add -name DGPT -region VISTAGB
add -name DGQE -region VISTAGB
add -name DGRO -region VISTAGB
add -name DGRU -region VISTAGB
add -name DGS -region VISTAGB
add -name DGSL -region VISTAGB
add -name DGTF -region VISTAGB
add -name DGWAIT -region VISTAGB
add -name DI -region VISTAGB
add -name DIA -region VISTAGB
add -name DIAR -region VISTAGB
add -name DIBT -region VISTAGB
add -name DIC -region VISTAGB
add -name DIE -region VISTAGB
add -name DIPT -region VISTAGB
add -name DIST -region VISTAGB
add -name DISV -region VISTAGB
add -name DIZ -region VISTAGB
add -name DMSQ -region VISTAGB
add -name DOPT -region VISTAGB
add -name DOQIT -region VISTAGB
add -name DOSV -region VISTAGB
add -name DPT -region VISTAGB
add -name DVB -region VISTAGB
add -name EAS -region VISTAGB
add -name EASPFS -region VISTAGB
add -name EC -region VISTAGB
add -name ECC -region VISTAGB
add -name ECD -region VISTAGB
add -name ECH -region VISTAGB
add -name ECJ -region VISTAGB
add -name ECK -region VISTAGB
add -name ECL -region VISTAGB
add -name ECP -region VISTAGB
add -name ECR -region VISTAGB
add -name ECT -region VISTAGB
add -name ECX -region VISTAGB
add -name EDR -region VISTAGB
add -name EEO -region VISTAGB
add -name ENCSN -region VISTAGB
add -name ENG -region VISTAGB
add -name ENGS -region VISTAGB
add -name ESP -region VISTAGB
add -name FB -region VISTAGB
add -name FB583 -region VISTAGB
add -name FB7078 -region VISTAGB
add -name FBAA -region VISTAGB
add -name FBAAA -region VISTAGB
add -name FBAAC -region VISTAGB
add -name FBAACNH -region VISTAGB
add -name FBAAI -region VISTAGB
add -name FBAAV -region VISTAGB
add -name FBHL -region VISTAGB
add -name FH -region VISTAGB
add -name FHEN -region VISTAGB
add -name FHING -region VISTAGB
add -name FHNU -region VISTAGB
add -name FHPT -region VISTAGB
add -name FHUM -region VISTAGB
add -name FSC -region VISTAGB
add -name FSCD -region VISTAGB
add -name GECS -region VISTAGB
add -name GMPL -region VISTAGB
add -name GMR -region VISTAGB
add -name GMRD -region VISTAGB
add -name GMT -region VISTAGB
add -name HBHC -region VISTAGB
add -name HDIS -region VISTAGB
add -name HDISF -region VISTAGB
add -name HDISV -region VISTAGB
add -name HL -region VISTAGB
add -name HLA -region VISTAGB
add -name HLB -region VISTAGB
add -name HLCS -region VISTAGB
add -name HLD -region VISTAGB
add -name HLEV -region VISTAGB
add -name HLMA -region VISTAGB
add -name HLS -region VISTAGB
add -name HOLIDAY -region VISTAGB
add -name IB -region VISTAGB
add -name IBA -region VISTAGB
add -name IBAM -region VISTAGB
add -name IBAT -region VISTAGB
add -name IBBAA -region VISTAGB
add -name IBBAD -region VISTAGB
add -name IBBAS -region VISTAGB
add -name IBCN -region VISTAGB
add -name IBCNR -region VISTAGB
add -name IBD -region VISTAGB
add -name IBE -region VISTAGB
add -name IBM -region VISTAGB
add -name IBQ -region VISTAGB
add -name IBT -region VISTAGB
add -name ICD -region VISTAGB
add -name ICD0 -region VISTAGB
add -name ICD9 -region VISTAGB
add -name ICDYZ -region VISTAGB
add -name ICM -region VISTAGB
add -name ICPT -region VISTAGB
add -name IMR -region VISTAGB
add -name IVM -region VISTAGB
add -name KMPD -region VISTAGB
add -name KMPR -region VISTAGB
add -name KMPS -region VISTAGB
add -name LAB -region VISTAGB
add -name LAC -region VISTAGB
add -name LAHM -region VISTAGB
add -name LAM -region VISTAGB
add -name LAR -region VISTAGB
add -name LBRY -region VISTAGB
add -name LEX -region VISTAGB
add -name LEXC -region VISTAGB
add -name LEXM -region VISTAGB
add -name LEXT -region VISTAGB
add -name LR -region VISTAGB
add -name LRD -region VISTAGB
add -name LRE -region VISTAGB
add -name LRO -region VISTAGB
add -name LRT -region VISTAGB
add -name MAG -region VISTAGB
add -name MAGD -region VISTAGB
add -name MAGDAUDT -region VISTAGB
add -name MAGDGEQR -region VISTAGB
add -name MAGDHL7 -region VISTAGB
add -name MAGDICOM -region VISTAGB
add -name MAGDINPT -region VISTAGB
add -name MAGDMLOG -region VISTAGB
add -name MAGDOUTP -region VISTAGB
add -name MAGDQR -region VISTAGB
add -name MAGDWLST -region VISTAGB
add -name MAGIXCVT -region VISTAGB
add -name MAGQUEUE -region VISTAGB
add -name MAGRT -region VISTAGB
add -name MCAR -region VISTAGB
add -name MDD -region VISTAGB
add -name MDK -region VISTAGB
add -name MDS -region VISTAGB
add -name MHV -region VISTAGB
add -name MPIF -region VISTAGB
add -name MR -region VISTAGB
add -name MXML -region VISTAGB
add -name NURQ -region VISTAGB
add -name NURSA -region VISTAGB
add -name NURSC -region VISTAGB
add -name NURSF -region VISTAGB
add -name NVS -region VISTAGB
add -name NVSTEMP -region VISTAGB
add -name OCXD -region VISTAGB
add -name OCXS -region VISTAGB
add -name OFM -region VISTAGB
add -name ONCO -region VISTAGB
add -name OOPS -region VISTAGB
add -name OR -region VISTAGB
add -name ORA -region VISTAGB
add -name ORD -region VISTAGB
add -name ORE -region VISTAGB
add -name ORRT -region VISTAGB
add -name ORYX -region VISTAGB
add -name PPP -region VISTAGB
add -name PRC -region VISTAGB
add -name PRCA -region VISTAGB
add -name PRCAK -region VISTAGB
add -name PRCD -region VISTAGB
add -name PRCF -region VISTAGB
add -name PRCH -region VISTAGB
add -name PRCN -region VISTAGB
add -name PRCP -region VISTAGB
add -name PRCS -region VISTAGB
add -name PRCT -region VISTAGB
add -name PRCU -region VISTAGB
add -name PRCV -region VISTAGB
add -name PRPF -region VISTAGB
add -name PRPFT -region VISTAGB
add -name PRSD -region VISTAGB
add -name PRSE -region VISTAGB
add -name PRSP -region VISTAGB
add -name PRSPC -region VISTAGB
add -name PRST -region VISTAGB
add -name PS -region VISTAGB
add -name PSB -region VISTAGB
add -name PSCST -region VISTAGB
add -name PSD -region VISTAGB
add -name PSDRUG -region VISTAGB
add -name PSI -region VISTAGB
add -name PSNDF -region VISTAGB
add -name PSNTRAN -region VISTAGB
add -name PSOARC -region VISTAGB
add -name PSRX -region VISTAGB
add -name PSUDEM -region VISTAGB
add -name PSX -region VISTAGB
add -name PSXARC -region VISTAGB
add -name PTX -region VISTAGB
add -name PX -region VISTAGB
add -name PXD -region VISTAGB
add -name PXRM -region VISTAGB
add -name PXRMD -region VISTAGB
add -name PXRMINDX -region VISTAGB
add -name PXRMPT -region VISTAGB
add -name PXRMXP -region VISTAGB
add -name PXRMXT -region VISTAGB
add -name QA -region VISTAGB
add -name RA -region VISTAGB
add -name RABTCH -region VISTAGB
add -name RADPT -region VISTAGB
add -name RADPTN -region VISTAGB
add -name RAMIS -region VISTAGB
add -name RAO -region VISTAGB
add -name RARPT -region VISTAGB
add -name RC -region VISTAGB
add -name RCD -region VISTAGB
add -name RCPS -region VISTAGB
add -name RCPSE -region VISTAGB
add -name RCPSS -region VISTAGB
add -name RCT -region VISTAGB
add -name RCXV -region VISTAGB
add -name RCY -region VISTAGB
add -name RGEQ -region VISTAGB
add -name RGEQASN -region VISTAGB
add -name RGEQEXC -region VISTAGB
add -name RGHL7 -region VISTAGB
add -name RGSITE -region VISTAGB
add -name RGSTAT -region VISTAGB
add -name RMIM -region VISTAGB
add -name RMPF -region VISTAGB
add -name RMPO -region VISTAGB
add -name RMPR -region VISTAGB
add -name RMPRA -region VISTAGB
add -name ROR -region VISTAGB
add -name RORDATA -region VISTAGB
add -name RT -region VISTAGB
add -name RTV -region VISTAGB
add -name SC -region VISTAGB
add -name SCE -region VISTAGB
add -name SCPT -region VISTAGB
add -name SCRS -region VISTAGB
add -name SCTM -region VISTAGB
add -name SD -region VISTAGB
add -name SDAM -region VISTAGB
add -name SDASE -region VISTAGB
add -name SDASF -region VISTAGB
add -name SDD -region VISTAGB
add -name SDSC -region VISTAGB
add -name SDV -region VISTAGB
add -name SDWL -region VISTAGB
add -name SOWK -region VISTAGB
add -name SPNL -region VISTAGB
add -name SRF -region VISTAGB
add -name SRO -region VISTAGB
add -name SRP -region VISTAGB
add -name SRS -region VISTAGB
add -name SRU -region VISTAGB
add -name TIU -region VISTAGB
add -name USC -region VISTAGB
add -name USR -region VISTAGB
add -name VA -region VISTAGB
add -name VAS -region VISTAGB
add -name VAT -region VISTAGB
add -name VDEFHL7 -region VISTAGB
add -name VEPER -region VISTAGB
add -name VIC -region VISTAGB
add -name VSIT -region VISTAGB
add -name WV -region VISTAGB
add -name XDRM -region VISTAGB
add -name XHD -region VISTAGB
add -name XHLP -region VISTAGB
add -name XIP -region VISTAGB
add -name XMB -region VISTAGB
add -name XMBPOST -region VISTAGB
add -name XMBS -region VISTAGB
add -name XMBX -region VISTAGB
add -name XMD -region VISTAGB
add -name XOB -region VISTAGB
add -name XPD -region VISTAGB
add -name XT -region VISTAGB
add -name XTID -region VISTAGB
add -name XTV -region VISTAGB
add -name XUCS -region VISTAGB
add -name XUSEC -region VISTAGB
add -name XUSSPKI -region VISTAGB
add -name XWB -region VISTAGB
add -name YS -region VISTAGB
add -name YSA -region VISTAGB
add -name YSCL -region VISTAGB
add -name YSD -region VISTAGB
add -name YSG -region VISTAGB
add -name YSR -region VISTAGB
add -name YSTX -region VISTAGB
add -name YTD -region VISTAGB
add -name YTT -region VISTAGB
add -name YTX -region VISTAGB
add -name ZZMKEDIT -region VISTAGB
!
! End of $Source$
-------------------------------------------------------------------
---
NOTE: If it is important CALL ME - I may miss email,
which I do NOT normally check on weekends nor on
a regular basis during any other day.
---
LD Landis - N0YRQ - de la tierra del encanto
3960 Schooner Loop, Las Cruces, NM 88012
651/340-4007 N32 21'48.28" W106 46'5.80"
“If a thing is worth doing,
it is worth doing badly.” –GK Chesterton.
An interpretation: For things worth doing: Doing them,
even if badly, is better than doing nothing perfectly (on
them).
"but I trust my family jewels only to Linux." -- DE Knuth
(http://www.informit.com/articles/article.aspx?p=1193856)
Funny Quote of the Day - Douglas Adams -
"I love deadlines. I like the whooshing sound they make
as they fly by."
I, Valdes
The mapping that EWD understands occurs here?
add -segment EWDGBLS -file="$DBINST/g/ewdgbls.dat" -allocation=20000 -
block_size=32256 -lock_space=1000 -extension_count=0
add -region EWDGBLS -record_size=32240 -key_size=255 -dyn=EWDGBLS
!
add -name %MGWSI -region=EWDGBLS
add -name %zewd -region=EWDGBLS
add -name %zewdIndex -region=EWDGBLS
add -name MDBConfig -region=EWDGBLS
add -name MDBErrors -region=EWDGBLS
add -name zewd -region=EWDGBLS
ewdgbls.dat than it should work?
-- IV
I, Valdes
looking at the under-pinnings of this. It seems like the creation of a
mumps database for ewd that runs alongside of the VistA database is
going to be the trick. Gus seems to be making progress on that but it
seems like a complicated process. I wonder if it is possible to create
the suitable database for EWD from commands or will I more or less
need to simply copy and use the mumps.dat and .gld in order to get it
installed from a rpm/deb? -- IV
rtweed
good idea to have it set up with its own database. I created it using
the standard mechanisms but making sure that it could handle 32k
string sizes in its globals.
The top-level documentation part of the EWD portal application that
comes up when you point a browser at the Virtual Appliance contains
all the configuration information you'll need. It explains all the
pieces I had to do in order to get EWD working on GT.M. Note that for
32k string support you also need to modify the kernel memory setting.
Of course, like you say, the alternative is to simply copy everything
in the /usr/local/gtm/ewd path (but you'll still have to change that
kernel memory setting)
Take a look at the /etc/init.d/mgwsi startup script file - you'll see
that it does a number of things to start the sub-components of EWD (eg
the Delegate proxy and setting up the GTM profiile), but most stuff
takes place in startVM^%zewdGTM
Cheers
Rob
KW Walker
The EWD Appliance seems to have two mumps.dat files.
One is /usr/local/gtm/mumps.dat
and the other is /usr/local/gtm/ewd/mumps.dat
What is the distinction ? Both are rundown in mgwsi.
Both are referenced by mumps.gld by an URL dependent upon the
current directory, ie simply mumps.dat without a path which seems a bit treacherous to me.
It got me for awhile and I am familiar with GTM's configuration mechanism.
The reference is buried in mumps.gld
I am an old MUMPSter converted to GTM and very excited about using EWD. Larry is working on my virtual site. I have an appliance working as I try to learn EWD myself.
I really appreciate what you have done in EWD and especially your making it open source.
Kirt Walker
rtweed
used by EWD.
Everything takes place in /usr/local/gtm/ewd
Rob
On 23 June, 12:51, KW Walker <kirtvi...@gmail.com> wrote:
> Rob:
>
> The EWD Appliance seems to have two mumps.dat files.
>
> One is /usr/local/gtm/mumps.dat
> and the other is /usr/local/gtm/ewd/mumps.dat
>
> What is the distinction ? Both are rundown in mgwsi.
>
> Both are referenced by mumps.gld by an URL dependent upon the
> current directory, ie simply mumps.dat without a path which seems a bit
> treacherous to me.
> It got me for awhile and I am familiar with GTM's configuration mechanism.
> The reference is buried in mumps.gld
>
> I am an old MUMPSter converted to GTM and very excited about using EWD.
> Larry is working on my virtual site. I have an appliance working as I try to
> learn EWD myself.
>
> I really appreciate what you have done in EWD and especially your making it
> open source.
>
> Kirt Walker
>
LD 'Gus' Landis
Yes.
FWIW, I recommend that you consider any *.gld file as
disposable... There is no easy way to get from the *.gld
to a specification that creates said *.gld file.
My convention is to have a *.gde file that is used by ^GDE
to create the *.gld file of interest. This way, you don't have
to remember what you did to create the *.gld file.
BTW, it is not really "complicated". Also, since VISTA and
EWD both have a set of globals that they use, I prefer to
"call out" each global that is expected by each package.
YMMV. But what I do is have DEFAULT catch all globals
that are not part of the "inventory" of application globals.
This way, if a global is not called out, and you use it, the
global shows up in DEFAULT. Also, should several applications
use the same global name, GDE will complain about duplicate
specifications for a global.. This has saved me time in the past
where different applications used the same global name, but
the global was completely different in use (e.g. VISTA vs a
non-VISTA application).
Although the above is a good starting point, once you know
what you have, you can always re-arrange and coalesce
the mappings into a different structure. To me, calling out
all globals needed for an application is a good way to not
have "collisions" of global names across different applications.
To Kirt's comment, the mumps.dat that is in /usr/local/gtm,
there is no mumps.dat in the GT.M distribution. There are
GT.M databases for utility help (gdehelp.gld/dat and the
gtmhelp.gld/dat). So it is likely an accidental creation.
Cheers,
--ldl
I, Valdes
wrapped my brain around the following: Again, the trick seems to be in
having the EWD and VistA db specified correctly in a gld so that they
co-exist and somehow share data. I am at a loss at how to specify a
gld that accomodates both databases so that they know about themselves
and one another but are able to coexist. They both seem to prefer to
be default, yet they probably(?) need to be specified in the same gld
as different segments.
How then to declare to both respective systems in a way that they
understand where their respective databases are and what they are
called in a single .gld?
-- IV
Steve Owen
routines in to the EWD virtual machine, but this approach is not practical
for a production setup. Ignacio's installer - excellent work BTW and tks for
the work you've done - makes it a breeze to get VistA up and running under
GT.M
JohnLeo Zimmer
appliance with an added slice for EWD, which would run in parallel to
VistA rather than atop it. The EWD appliance entangles EWD with gtm
and that needs to be tamed. But Gus may have solved that by now??
jlz
K.S. Bhaskar
Please internalize how a global directory file maps a global variable
name space to a set of database files. That is all that is needed to
put EWD and VistA together.
Regards
-- Bhaskar
Ignacio Valdes
-- IV
All --
Please internalize how a global directory file maps a global variable
name space to a set of database files. That is all that is needed to
put EWD and VistA together.
Regards
-- Bhaskar
K.S. Bhaskar
-- Bhaskar
Ignacio Valdes
ewd@mdb:/usr/local/gtm/ewd$ mupip integ -full
File or Region: mumps.dat
mumps.dat -> File already open by another process.
Resource temporarily unavailable
%GTM-I-MUSTANDALONE, Could not get exclusive access to mumps.dat
%GTM-E-INTEGERRS, Database integrity errors
-- IV
Default is just that - default. Simply map all EWD's global variables to the EWD database and the rest to VistA. You can run a mupip integ -full on the EWD database to get a list of global variables therein, or Rob can provide a list of global variable name patterns that EWD uses.
-- Bhaskar
rtweed
^zewd*
^%zewd*
^CacheTempEWD
The latter is a work/scratch global. The nomenclature is because on a
Cache system, it automatically maps to in-memory storage for
performance.
Rob
On 24 June, 16:19, Ignacio Valdes <ival...@hal-pc.org> wrote:
> Did a /etc/init.d/mgwsi stop as well as a mupip rundown just in case, then
> received this:
>
> ewd@mdb:/usr/local/gtm/ewd$ mupip integ -full
> File or Region: mumps.dat
> mumps.dat -> File already open by another process.
> Resource temporarily unavailable
> %GTM-I-MUSTANDALONE, Could not get exclusive access to mumps.dat
> %GTM-E-INTEGERRS, Database integrity errors
>
> -- IV
>
> > Default is just that - default. Simply map all EWD's global variables to
> > the EWD database and the rest to VistA. You can run a mupip integ -full on
> > the EWD database to get a list of global variables therein, or Rob can
> > provide a list of global variable name patterns that EWD uses.
>
> > -- Bhaskar
>
>
> >> Trying with gtm acculturation doc, but how do I resolve that both EWD and
> >> VistA seem to want to be Default?
>
> >> -- IV
>
K.S. Bhaskar
K.S. Bhaskar
EWD's globals are:
^zewd*
^%zewd*
^CacheTempEWD
The latter is a work/scratch global. The nomenclature is because on a
Cache system, it automatically maps to in-memory storage for
performance.
[KSB] Then I suggest using two database regions for EWD, one for ^zewd* and ^%zewd* and the other for ^CacheTempEWD, which is an MM database that is deleted and recreated on system bootup. Is ^CacheTempEWD the one that needs 32KB records?
Regards
-- Bhaskar
rtweed
MGWSI), but it's always a good idea to rundown the mumps.dat file
> received this:
>
> ewd@mdb:/usr/local/gtm/ewd$ mupip integ -full
> File or Region: mumps.dat
> mumps.dat -> File already open by another process.
> Resource temporarily unavailable
> %GTM-I-MUSTANDALONE, Could not get exclusive access to mumps.dat
> %GTM-E-INTEGERRS, Database integrity errors
>
> -- IV
>
> > Default is just that - default. Simply map all EWD's global variables to
> > the EWD database and the rest to VistA. You can run a mupip integ -full on
> > the EWD database to get a list of global variables therein, or Rob can
> > provide a list of global variable name patterns that EWD uses.
>
> > -- Bhaskar
>
>
> >> Trying with gtm acculturation doc, but how do I resolve that both EWD and
> >> VistA seem to want to be Default?
>
> >> -- IV
>
rtweed
%zewdSession would need 32k also. Basically assume that all EWD
globals potentially expect to hold up to 32k's worth of data, just
like Cache
Perhaps an example would help folks understand what you're
recommending, Bhaskar?
Rob
On 24 June, 16:35, "K.S. Bhaskar" <ksbhas...@gmail.com> wrote:
LD 'Gus' Landis
any idea (Rob) on how large things can get? What can one look
at to determine its max size?
The use of ^zewd is for an XML store... potentially persistent docs!
So, for EWD use, MM may work, but for other applications, it needs
to be durable "like a global".
Rob, what change did you make to accomodate George Lilly's XML
(CCR/CCD) which, IIRC, broke the 32K limits?
K.S. Bhaskar
I think that MM would be a good choice for CacheTempEWD, but
any idea (Rob) on how large things can get? What can one look
at to determine its max size?
The use of ^zewd is for an XML store... potentially persistent docs!
So, for EWD use, MM may work, but for other applications, it needs
to be durable "like a global".
[KSB] MM *is* Durable. Not just "like a global" - it is used for global variables! The difference is that -backward recovery is not supported for MM, only -forward recovery is. The other limitation with MM is that since it is mapped into the process address space, very large databases require a 64-bit GT.M.
Regards
-- Bhaskar
rtweed
that it makes during the compilation process, but you can create and
persist your own XML documents in their parsed DOM format in
^zewdDOM. Indeed that's precisely what happens in the new M/DB:X
database. So ^zewdDOM is an important global that should be
journalled if you're going to use it as a Native XML Database.
^%zewdSession contains transient, session state information, whose
lifetime is the duration of a user's session. It needn't be
journalled and can be mapped to memory quite reasonably.
Assume all other ^zewd* and ^%zewd* globals must be persisted and
journalled.
^CacheTempEWD is a throwaway global so don't journal it.
How big can CacheTempEWD get? As large as your largest XML file.
Assume that a DOM when parsed into ^zewdDOM will be between 5-10 times
larger than the original text file. This is due to all the pointers
and indexes that are needed in the DOM.
I can't remember George Lilly's problem but I suspect it was due to a
bug in the way the parser was handling very long text fields. If it
still breaks, let me know and send me an example please.
Rob
On 24 June, 16:49, "LD 'Gus' Landis" <ldlan...@gmail.com> wrote:
> I think that MM would be a good choice for CacheTempEWD, but
> any idea (Rob) on how large things can get? What can one look
> at to determine its max size?
>
> The use of ^zewd is for an XML store... potentially persistent docs!
> So, for EWD use, MM may work, but for other applications, it needs
> to be durable "like a global".
>
> Rob, what change did you make to accomodate George Lilly's XML
> (CCR/CCD) which, IIRC, broke the 32K limits?
>
>
>
Ignacio Valdes
On Wed, Jun 24, 2009 at 11:49 AM, LD 'Gus' Landis <ldla...@gmail.com> wrote:
I think that MM would be a good choice for CacheTempEWD, but
any idea (Rob) on how large things can get? What can one look
at to determine its max size?
The use of ^zewd is for an XML store... potentially persistent docs!
So, for EWD use, MM may work, but for other applications, it needs
to be durable "like a global".
[KSB] MM *is* Durable. Not just "like a global" - it is used for global variables! The difference is that -backward recovery is not supported for MM, only -forward recovery is. The other limitation with MM is that since it is mapped into the process address space, very large databases require a 64-bit GT.M.
Regards
-- Bhaskar
-- IV
Ignacio Valdes
> On Wed, Jun 24, 2009 at 11:31 AM, rtweed <rob....@gmail.com> wrote:
>>
>>
>> ^zewd*
>> ^%zewd*
>> ^CacheTempEWD
>>
>> The latter is a work/scratch global. The nomenclature is because on a
>> Cache system, it automatically maps to in-memory storage for
>> performance.
>
> ^%zewd* and the other for ^CacheTempEWD, which is an MM database that is
> deleted and recreated on system bootup. Is ^CacheTempEWD the one that needs
> 32KB records?
>
> Regards
> -- Bhaskar
>
Looks like 27 variables are present. Rob, any of these that I do not
need to have in place?
There was a mumps process running, I kill -9 'ed it, then
ewd@mdb:/usr/local/gtm/ewd$ mupip integ -full /usr/local/gtm/ewd/mumps.dat > out
Directory tree
Level Blocks Records % Used Adjacent
1 1 1 0.074 NA
0 1 27 1.323 NA
Global variable ^%MGWSI
Level Blocks Records % Used Adjacent
1 1 1 0.074 1
0 1 20 4.318 0
Global variable ^%eXtc
Level Blocks Records % Used Adjacent
1 1 1 0.074 0
0 1 0 0.049 0
Global variable ^%mgwPipe
Level Blocks Records % Used Adjacent
1 1 1 0.074 0
0 1 0 0.049 0
Global variable ^%work
Level Blocks Records % Used Adjacent
1 1 1 0.074 0
0 1 0 0.049 0
Global variable ^%zewd
Level Blocks Records % Used Adjacent
1 1 5 0.554 1
0 5 884 50.381 3
Global variable ^%zewdError
Level Blocks Records % Used Adjacent
1 1 1 0.074 0
0 1 0 0.049 0
Global variable ^%zewdIndex
Level Blocks Records % Used Adjacent
1 1 2 0.170 0
0 2 1314 51.161 0
Global variable ^%zewdLog
Level Blocks Records % Used Adjacent
1 1 1 0.074 0
0 1 0 0.049 0
Global variable ^%zewdSession
Level Blocks Records % Used Adjacent
1 1 1 0.074 0
0 1 580 76.556 0
Global variable ^%zewdTrace
Level Blocks Records % Used Adjacent
1 1 1 0.074 0
0 1 0 0.049 0
Global variable ^CacheTempCTProcessed
Level Blocks Records % Used Adjacent
1 1 1 0.074 0
0 1 0 0.049 0
Global variable ^CacheTempEWD
Level Blocks Records % Used Adjacent
1 1 1 0.074 0
0 1 0 0.049 0
Global variable ^CacheTempUserNode
Level Blocks Records % Used Adjacent
1 1 1 0.074 0
0 1 0 0.049 0
Global variable ^CacheTempWLD
Level Blocks Records % Used Adjacent
1 1 1 0.074 0
0 1 0 0.049 0
Global variable ^MDB
Level Blocks Records % Used Adjacent
1 1 1 0.074 0
0 1 0 0.049 0
Global variable ^MDBConfig
Level Blocks Records % Used Adjacent
1 1 1 0.074 0
0 1 1 0.148 0
Global variable ^MDBErrors
Level Blocks Records % Used Adjacent
1 1 1 0.074 0
0 1 3 0.688 0
Global variable ^MDBUAF
Level Blocks Records % Used Adjacent
1 1 1 0.074 0
0 1 0 0.049 0
Global variable ^ewdDemo
Level Blocks Records % Used Adjacent
1 1 1 0.074 0
0 1 0 0.049 0
Global variable ^ewdResults
Level Blocks Records % Used Adjacent
1 1 1 0.074 0
0 1 0 0.049 0
Global variable ^rltBreak
Level Blocks Records % Used Adjacent
1 1 1 0.074 0
0 1 0 0.049 0
Global variable ^rob
Level Blocks Records % Used Adjacent
1 1 1 0.074 0
0 1 0 0.049 0
Global variable ^robcgi
Level Blocks Records % Used Adjacent
1 1 1 0.074 0
0 1 0 0.049 0
Global variable ^robdata
Level Blocks Records % Used Adjacent
1 1 1 0.074 0
0 1 0 0.049 0
Global variable ^rt
Level Blocks Records % Used Adjacent
1 1 1 0.074 1
0 1 0 0.049 1
Global variable ^zewd
Level Blocks Records % Used Adjacent
1 1 1 0.074 1
0 1 13 1.258 1
Global variable ^zewdDOM
Level Blocks Records % Used Adjacent
1 1 1 0.074 0
0 1 0 0.049 0
No errors detected by integ.
Type Blocks Records % Used Adjacent
Directory 2 28 0.699 NA
Index 27 32 0.095 4
Data 32 2815 13.693 5
Free 139 NA NA NA
Total 200 2875 NA 9
%GTM-E-GTMSECSHRPERM, The gtmsecshr module in $gtm_dist does not have
the correct permission and uid
%SYSTEM-E-ENO22, Invalid argument
%GTM-E-CRITSEMFAIL, Error with semaphores for region
/usr/local/gtm/ewd/mumps.dat
%GTM-I-TEXT, sem_rmid of semid failed
%GTM-F-NOCHLEFT, Unhandled condition exception (all handlers
exhausted) - process terminating
Quit
K.S. Bhaskar
[KSB] <...snip...>
> %GTM-E-GTMSECSHRPERM, The gtmsecshr module in $gtm_dist does not have
> the correct permission and uid
> %SYSTEM-E-ENO22, Invalid argument
> %GTM-E-CRITSEMFAIL, Error with semaphores for region
> /usr/local/gtm/ewd/mumps.dat
> %GTM-I-TEXT, sem_rmid of semid failed
> %GTM-F-NOCHLEFT, Unhandled condition exception (all handlers
> exhausted) - process terminating
> Quit
[KSB] How did you install GT.M? Unless you really know what you are
doing, please use *as root* "sh ./configure" or "sudo sh ./configure"
to install GT.M.
Regards
-- Bhaskar
Ignacio Valdes
>
> On Wed, Jun 24, 2009 at 12:12 PM, Ignacio Valdes<iva...@hal-pc.org> wrote:
>
> [KSB] <...snip...>
>
>> the correct permission and uid
>> %SYSTEM-E-ENO22, Invalid argument
>> %GTM-E-CRITSEMFAIL, Error with semaphores for region
>> /usr/local/gtm/ewd/mumps.dat
>> %GTM-I-TEXT, sem_rmid of semid failed
>> %GTM-F-NOCHLEFT, Unhandled condition exception (all handlers
>> exhausted) - process terminating
>> Quit
>
> doing, please use *as root* "sh ./configure" or "sudo sh ./configure"
> to install GT.M.
>
> Regards
> -- Bhaskar
This is all on Tweed's un-altered ewd Virtual Machine appliance right now.
-- IV
K.S. Bhaskar
[KSB] <...snip...>
> Looks like 27 variables are present. Rob, any of these that I do not
> need to have in place?
>
> There was a mumps process running, I kill -9 'ed it, then
[KSB] Please use mupip stop <proc> to kill mumps processes. Unless
you like to juggle sharp knives like a hibachi restaurant chef.
[KSB] Something like the following can be used to create the necessary
global directory.
$ cat VistAEWD_GDE.txt
a -s EWD -bl=32768 -al=1000 -e=200 -f=ewd.dat
a -r EWD -d=EWD -s -k=255 -r=32752 -j=before
a -n %MGW* -r=EWD
a -n %eXtc* -r=EWD
a -n %mgw* -r=EWD
a -n %work -r=EWD
a -n %zewd* -r=EWD
a -n MDB* -r=EWD
a -n ewd* -r=EWD
a -n rob* -r=EWD
a -n rt* -r=EWD
a -n zewd* -r=EWD
a -s EWDTEMP -bl=32768 -ac=mm -al=1000 -e=200 -f=ewdtemp.dat
a -r EWDTEMP -d=EWDTEMP -s -k=255 -r=32752
a -n CacheTemp* -r=EWDTEMP
c -s DEFAULT -bl=4096 -al=50000 -e=10000 -f=mumps.dat
c -r DEFAULT -s -k=255 -r=4080 -j=before
$
You can provide it as an input to GDE:
$ mumps -run GDE
%GDE-I-GDUSEDEFS, Using defaults for Global Directory
/tmp/tmp/mumps.gld
GDE> @VistAEWD_GDE.txt
%GDE-I-EXECOM, Executing command file /tmp/tmp/VistAEWD_GDE.txt
GDE> exit
%GDE-I-VERIFY, Verification OK
%GDE-I-GDCREATE, Creating Global Directory file
/tmp/tmp/mumps.gld
$
Then you can create your database files:
$ mupip create
Created file /tmp/tmp/mumps.dat
%GTM-W-MUNOSTRMBKUP, Database /tmp/tmp/ewd.dat has a block size larger
than 32256 and thus cannot use stream (incremental) backup
Created file /tmp/tmp/ewd.dat
%GTM-W-MUNOSTRMBKUP, Database /tmp/tmp/ewdtemp.dat has a block size
larger than 32256 and thus cannot use stream (incremental) backup
Created file /tmp/tmp/ewdtemp.dat
$ ls -l
total 576
-rw-rw-rw- 1 kbhaskar gtc 32899584 2009-06-24 12:43 ewd.dat
-rw-rw-rw- 1 kbhaskar gtc 32899584 2009-06-24 12:43 ewdtemp.dat
-rw-rw-rw- 1 kbhaskar gtc 205267456 2009-06-24 12:43 mumps.dat
-rw-r--r-- 1 kbhaskar gtc 3584 2009-06-24 12:42 mumps.gld
-rw-r--r-- 1 kbhaskar gtc 494 2009-06-24 12:35 VistAEWD_GDE.txt
$
Regards
-- Bhaskar
rtweed
^%MGWSI Used by m_apache behind the scenes for its management.
Leave alone. Very small records. Probably not worth journalling
^%eXtc Not used any more. Indeed I'm not sure how/why you have that
on your system. What version of EWD did you use?
^%mgwPipe. A small, scratch, transient global. Don't journal
^%work Scratch global used in ewdMgr for CSP session display. Don't
journal. Small records
^%zewd Cross-system configuration information for EWD. Definitely
journal. In general small-ish records
^%zewdError Error log file. Delete and clear down as and when
required. EWD just dumps information into it. Will require up to 32k
records
^%zewdIndex. EWD page metadata index. Small records. Information
relating to a page is rebuilt when it is recompiled. Probably not
worth journalling
^%zewdLog Transient global used during compilation. Small records.
Don't journal
^%zewdSession Session storage global. Don't journal. Potentially
large records
^%zewdTrace Trace global used in "trace mode" to record what EWD's
run-time engine was doing. Don't journal. Small records. Can be
killed anytime you like.
Make sure you keep trace mode off most of the time: s ^zewd("trace")
=0 or k ^zewd("trace")
^CacheTempCTProcessed Scratch/work global used by EWD's compiler
during custom tag processing. Don't journal. Small records.
^CacheTempEWD Scratch/work global used when extracting contents of
EWD page files prior to processing. Don't journal. Large records
^CacheTempUserNode Scratch global. Don't journal. Looking at the
code, this needs removing from my logic!
^CacheTempWLD Scratch global used by compiler to build final routine
files. Potentially quite long records but unlikely to require 32k
strings. Don't journal
^MDB Not used or present in the EWD Virtual Appliance. This is the
main M/DB global.
^MDBConfig Also not part of the EWD appliance, but part of M/DB.
What appliance are you using???
^MDBErrors Ditto
^MDBUAF Ditto
^ewdDemo Sample data for on-board tutorial/demo application. Can be
deleted
^ewdResults Scratch global used during compilation. Don't journal.
small records
^rltBreak Shouldn't exist
^rob Ditto
^robcgi M/DB trace information, now superceded. Delete
^robdata Ditto
^rt Shouldn't exist. Delete
^zewd Namespace-specific EWD configuration data. Journal. Small
records
^zewdDOM Main DOM global. Journal. Large records
Hope this helps
Rob
glilly
Rob made a modification which allows us to store the XML file as an
array in ^CacheTempEWD(x) .. one line of xml per node. We can then
pass the array to the EWD parser. Storing XML text files in this way
means that ^CacheTempEWD fits nicely in a 32k per node limit.
gpl
Ignacio Valdes
load as well? If so then maybe creating from scratch is difficult and
I may just use your current mumps.dat -- IV
Ignacio Valdes
^%eXtc Not used any more. Indeed I'm not sure how/why you have that
on your system. What version of EWD did you use?
^MDBConfig Also not part of the EWD appliance, but part of M/DB.
What appliance are you using???
^MDBErrors Ditto
^MDBUAF Ditto
The current VM that is on and I downloaded from the M Gateway website. -- IV
K.S. Bhaskar
You can use the global directory to map global variables to existing database files.
-- Bhaskar
rtweed
However if you do this, then the first time you compile, it will ask
you for the basic configuration details it needs to know, such as the
application root path. The beauty of a Virtual Appliance is that you
can have made those decisions for a newbie who may not understand at
that stage what the parameters mean in the first place.
If you're pre-configuring paths for EWD source pages etc, then you
should at the very least add some kind of script that pre-builds the
^zewd("config") global. Just copy what's in this global node section
in the Virtual Appliance and you'll be OK.
Rob
On 24 June, 19:20, Ignacio Valdes <ival...@hal-pc.org> wrote:
> Great, thanks. Are there values to these globals that I would have to
> load as well? If so then maybe creating from scratch is difficult and
> I may just use your current mumps.dat -- IV
>
rtweed
able to list a lot of them. It appears that mupip integ discovers
"ghosts of the past" I assume as top level indexes with nothing
underneath them.
Bhaskar - is there a way to clear that leftover garbage out of the
mumps.dat?
The good news is that the latest EWD Virtual Appliance is clean. if
you do a ^%GD you'll see the small handful of globals that actually
exist in a "virgin" build.
Rob
On 24 June, 19:25, Ignacio Valdes <ival...@hal-pc.org> wrote:
K.S. Bhaskar
OK I see what it is. Most of those globals don't exist: you won't be
able to list a lot of them. It appears that mupip integ discovers
"ghosts of the past" I assume as top level indexes with nothing
underneath them.
Bhaskar - is there a way to clear that leftover garbage out of the
mumps.dat?
[KSB] Even if you Kill an entire global variable, the fact that it once existed will always be recorded in the database file. The only way to "erase" this record is to create a new database file and extract and load the globals from the old database file.
Regards
-- Bhaskar
Ignacio Valdes
LD 'Gus' Landis
What is the performance difference? I'll have to go back
to the docs on this. Never have used it.
K.S. Bhaskar
So, the MM is just using the UNIX memory map to file(s).
What is the performance difference? I'll have to go back
to the docs on this. Never have used it.
[KSB] YMMV
LD 'Gus' Landis
consider the .gld file disposable and have the real
spec in a .gde file (containing what Bhaskar has
in VistAEWD_GDE.txt.
My convention is: if I have db.gld, then I have a db.gde
which I use to create the db.gld file via:
$ export gtmgbldir=db.gld
$ mumps -run ^GDE < db.gde > db.gde.log
In the db.gde I usually include a "show -all" too,
so that I have a record of what I was expecting.
Bhaskar! "cat" *is* easier than "emacs"... Hmm ;-)
On Wed, Jun 24, 2009 at 10:44 AM, K.S. Bhaskar<ksbh...@gmail.com> wrote:
> On Wed, Jun 24, 2009 at 12:12 PM, Ignacio Valdes<iva...@hal-pc.org> wrote:
> [KSB] Something like the following can be used to create the necessary
> global directory.
>
> $ cat VistAEWD_GDE.txt
> a -s EWD -bl=32768 -al=1000 -e=200 -f=ewd.dat
> a -r EWD -d=EWD -s -k=255 -r=32752 -j=before
> a -n %MGW* -r=EWD
> a -n %eXtc* -r=EWD
> a -n %mgw* -r=EWD
> a -n %work -r=EWD
> a -n %zewd* -r=EWD
> a -n MDB* -r=EWD
> a -n ewd* -r=EWD
> a -n rob* -r=EWD
> a -n rt* -r=EWD
> a -n zewd* -r=EWD
> a -s EWDTEMP -bl=32768 -ac=mm -al=1000 -e=200 -f=ewdtemp.dat
> a -r EWDTEMP -d=EWDTEMP -s -k=255 -r=32752
> a -n CacheTemp* -r=EWDTEMP
> c -s DEFAULT -bl=4096 -al=50000 -e=10000 -f=mumps.dat
> c -r DEFAULT -s -k=255 -r=4080 -j=before
> $
>
---
LD 'Gus' Landis
I am assuming that you are starting from a (relatively) fresh
copy of Rob's appliance.. There are very few "extraneous"
global values.
From an EWD perspective, from the EWD virtual appliance:
$ mupip extract -sel=^* -format=zwr ewdgbls.zwr 2> ewdgbls.zwr.toc
where ewdgbls.zwr is zwr formatted data
and ewdglbs.zwr.toc is the "table of contents" of what was there.
Then you can suck those files out of the appliance and load them
into your instance.
Cheers,
--ldl
---
NOTE: If it is important CALL ME - I may miss email,
which I do NOT normally check on weekends nor on
a regular basis during any other day.
LD Landis - N0YRQ - de la tierra del encanto
3960 Schooner Loop, Las Cruces, NM 88012
651/340-4007 N32 21'48.28" W106 46'5.80"
LD 'Gus' Landis
On Wed, Jun 24, 2009 at 1:42 PM, Ignacio Valdes<iva...@hal-pc.org> wrote:
> Do you have the code for building the virgin database? If so, may I have it?
> -- IV
>
---
LD 'Gus' Landis
If a global is killed, the name is still in the root directory.
Until we here from the master (KSB).
On Wed, Jun 24, 2009 at 1:14 PM, rtweed<rob....@gmail.com> wrote:
>
> OK I see what it is. Most of those globals don't exist: you won't be
> able to list a lot of them. It appears that mupip integ discovers
> "ghosts of the past" I assume as top level indexes with nothing
> underneath them.
>
> Bhaskar - is there a way to clear that leftover garbage out of the
> mumps.dat?
>
> The good news is that the latest EWD Virtual Appliance is clean. if
> you do a ^%GD you'll see the small handful of globals that actually
> exist in a "virgin" build.
>
> Rob
>
--
I, Valdes
an IP address. The previous one downloaded a few days ago on the same
machine was able to acquire an IP address without problems. I read the
readme about looking at the host configuration but I'm not sure how to
enable bridging. -- IV
I, Valdes
the same globals present, total of 26. I would show them but I can
only get the console which doesn't allow cut/paste. -- IV
rtweed
Only 6 globals exist in the current, latest EWD Virtual Appliance when
you first download it and boot it up. I know: I did it yesterday
myself to check! Do the following:
d ^%GD
Then enter * and you'll see them listed. If you set up your own
custom build, I'd advise that you copy these globals. When I create a
new version of the Virtual Appliance, the last thing I run is a
routine that clears down everything *except* what is needed.
In fact, as Bhaskar has confirmed, GT.M still leaves a record that a
number of other globals once existed in the Mumps.dat file, but that
can be completely ignored. Just concentrate on the 6 that DO exist
please and forget about the rest. The others are just echoes of the
past that will do no harm and have no side effects.
However, when you start using the system, a number of globals WILL
begin to appear. Use that checklist I wrote earlier in this thread:
that gives a comprehensive coverage of all the globals you're likely
to find appearing, whether or not they should be journalled or mapped
to memory, and whether or not they'll likely need 32k string support.
As to your latest instance of the Virtual Appliance not setting itself
up on your network: The copies will be identical and there must be
some difference at your end to be making the difference. The Virtual
Appliance is pre-configured to use bridged networking and DHCP, but
you can use the VMWare console to change to either NAT or, worst case,
Local networking as alternatives. I do know that some multi-NIC PCs
have problems with Ubuntu running on VMWare but I have yet to have
found or be told a reliable solution. Try it on another PC if you
have one and see if that works.
Rob
JohnLeo Zimmer
network first try.
jlz
Using VMWare Server. Web interface.
LD 'Gus' Landis
Has the appliance changed? It looks like 6.0 is still
the current one (which has been there for some time,
right?).
Cheers,
--ldl
On Thu, Jun 25, 2009 at 4:33 AM, JohnLeo Zimmer<johnl...@gmail.com> wrote:
>
> In my hands a change from bridged to NAT allows EWD to find the
> network first try.
>
> jlz
>
> Using VMWare Server. Web interface.
>
---
rtweed
which is a little old. You can update it to the latest publicly
available EWD build 762 by downloading it separately (EWD for GT.M),
then follow the installation instructions that are included in the
download.
Rebuilding a new version of the Virtual Appliance is a non-trivial
task. Uploading it alone takes me over an hour. So I don't rebuild
them too often and as a result, the Virtual Appliances tend to be
behind the curve compared with the current releases of EWD. However
updating to a new build of EWD normally just involves replacing the
_zewd*.m files and rebooting the VM.
You should regularly check our web site or the main EWD Google Group
for announcements of new EWD releases.
Rob
On 25 June, 15:24, "LD 'Gus' Landis" <ldlan...@gmail.com> wrote:
> Rob,
>
> Has the appliance changed? It looks like 6.0 is still
> the current one (which has been there for some time,
> right?).
>
> Cheers,
> --ldl
>
LD 'Gus' Landis
at the current stuff, and I am Thanks!
On Thu, Jun 25, 2009 at 11:02 AM, rtweed<rob....@gmail.com> wrote:
>
> No the appliance hasn't changed. However it includes EWD build 755
> which is a little old. You can update it to the latest publicly
> available EWD build 762 by downloading it separately (EWD for GT.M),
> then follow the installation instructions that are included in the
> download.
>
> Rebuilding a new version of the Virtual Appliance is a non-trivial
> task. Uploading it alone takes me over an hour. So I don't rebuild
> them too often and as a result, the Virtual Appliances tend to be
> behind the curve compared with the current releases of EWD. However
> updating to a new build of EWD normally just involves replacing the
> _zewd*.m files and rebooting the VM.
>
> You should regularly check our web site or the main EWD Google Group
> for announcements of new EWD releases.
>
> Rob
>
>
---
I, Valdes
> Rebuilding a new version of the Virtual Appliance is a non-trivial
> task. Uploading it alone takes me over an hour. So I don't rebuild
> them too often and as a result, the Virtual Appliances tend to be
> behind the curve compared with the current releases of EWD. However
> updating to a new build of EWD normally just involves replacing the
> _zewd*.m files and rebooting the VM.
>
things: bulky, hard to upgrade, difficult to integrate with other
things, tough to figure out how they work, and difficult to reproduce
by others. Additionally, rpm's/deb's make building virtual machine
editions much easier. I hope to have a working rpm soon...
-- IV