Installing EWD-FOSS from scratch

[seanatc...@googlemail.com]

(Part 1)

I'm in the process of installing the FOSS release of EWD and m_apache
and I thought I would share the experience...

Firstly I needed a clean virtual machine with Linux installed. I
decided to go with the Hardy version of Ubuntu JeOS since this is the
version Rob uses. You can grab an ISO from here...

http://cdimage.ubuntu.com/jeos/releases/8.04.2/release/

I also made sure I was up to date with the latest version of the free
VMWare Player...

http://www.vmware.com/download/player/

I don't have VMWare Workstation to create my own machines, but there
is a very cool way of doing so with just VMWare Player. The following
site provides the functionality to create and download an empty
virtual machine...

http://www.easyvmx.com/supersimple.shtml

All you need to do is fill out the four fields (ignore ISO section)
and hit "create virtual machine", here are the settings I used...

1. EWD_Machine
2. Ubuntu Linux
3. 320MB
3. 2GB

The download was only 3k. I unpacked this in the same folder as the
Ubuntu ISO folder.

Next I edited the unpacked .vmx file so that the CDROM section looks
like this...

# Settings for physical CDROM drive
#ide1:0.present = "TRUE"
#ide1:0.deviceType = "cdrom-raw"
#ide1:0.startConnected = "TRUE"
#ide1:0.fileName = "auto detect"
#ide1:0.autodetect = "TRUE"
ide1:0.present = "TRUE"
ide1:0.fileName = "jeos-8.04.2-jeos-i386.iso"
ide1:0.deviceType = "cdrom-image"

(change the fileName if you download a different ISO image)

I fired up the Player, navigated to the installation folder and
launched the machine. The machine automatically booted from the ISO
and I was prompted through the process of installing Ubuntu JeOS. Once
installed I removed the ISO and rebooted.

First thing I'm going to need is terminal and SFTP access so I logged
in and installed an openssh server...

sudo apt-get install openssh-server

A quick test and I have terminal and SFTP access.

So far so good, time to install GT.m...

Sean.

[seanatc...@googlemail.com]

(part 2)

I downloaded the latest version of GT.m (for Linux)...

http://sourceforge.net/project/showfiles.php?group_id=11026&package_id=10760

I then moved the download using filezilla into the following (new)
folder...

/opt/gtm

from which I unpack the download using

sudo tar xovf gtm_V53003_linux_i686_pro.tar

From that folder I install GT.m with the following command

sudo sh configure

into the following (new) folder...

/opt/gtm/V53003

and then clean up.

Ubuntu requires a small configuration change so that globals can
handle 32k, using vi I edit...

/etc/sysctl.conf

and add the following line

kernel.shmmax=134217728

I quick restart and the changes take affect.

To activate the default GT.m environment settings for my user login I
navigate to my home directory and run...

/opt/gtm/V53003/gtmbase

This updates my .profile, I logout and back in and test with the
following command

$gtm_dist/mumps -direct

GTM>w "Hello World"
Hello World
GTM>

Next up, Apache, m_apache and EWD...

Sean.

[rtweed]

Note that EWD's compiler ....in fact its DOM parser....requires
globals capable of holding records up to 32k in length, which requires
special configuration. You'll find the details in the EWD Virtual
Appliance portal document pages.

Also for Ubuntu, you'll need to ensure that you open up the
permissions of /tmp and /var or you'll get weird problems occurring -
again it's noted in the Virtual Appliance documentation pages.

Here's from the Asus Eee EWD installation readme file (I must update
that soon with the new build) where I describe a GT.M install for EWD:

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

4) Install GT.M

Download the latest version (GT.M-x86-Linux) from http://sourceforge.net/projects/fis-gtm

I fetched gtm_V53001A_linux_i686_pro.tar.gz

Create a new directory on the Eee : /gtmtmp

and copy the file into it


cd /gtmtmp

Then run the following:

gunzip gtm_V53001A_linux_i686_pro.tar.gz

followed by:

tar –xvf gtm_V53001A_linux_i686_pro.tar


Then, to install GT.M, type:

sh configure

and accept defaults for the answers. For the directory in which GT.M
is to be installed,
make sure you enter:

/usr/local/gtm


Ask the installer to remove the temporary files from the /gtmtmp
directory, then delete /gtmtmp



Now edit the file /etc/profile and append the line:

source /usr/local/gtm/gtmprofile



Important! : Open up 777 permissions for the /var and /tmp directories

Do this by:

cd /
chmod 777 var
chmod 777 tmp



Create the basic global directory and database in /usr/local/gtm
using:

cd /usr/local/gtm
source /usr/local/gtm/gtmprofile
$gtm
GTM> d ^GDE
GDE> EXIT

Then:

mupip create

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

Cheers

Rob

On 19 Feb, 18:25, "seanatconne...@googlemail.com"

<seanatconne...@googlemail.com> wrote:
> (part 2)
>
> I downloaded the latest version of GT.m (for Linux)...
>

>  http://sourceforge.net/project/showfiles.php?group_id=11026&package_i...

[st...@stevenowen.com]

Tks Sean! This will be a great howto...

[rtweed]

Just digging the info out of the Virtual Appliance so it's here in one
place. Here's how to create a global database suitable for EWD's DOM
processing, ie capable of handling records up to 32k long:

cd /usr/local/gtm/ewd
$gtm
GTM>d ^GDE
change -segment default -block=32256
change -region default -key=255 -record=32240
exit
mupip create


Note that, as Sean described earlier, if you use these settings, you
must increase the kernel shared memory to 134217728

On 19 Feb, 19:08, st...@stevenowen.com wrote:
> Tks Sean! This will be a great howto...
>

> seanatconne...@googlemail.com writes:
>
> > (part 2)
>
> > I downloaded the latest version of GT.m (for Linux)...
>

> >  http://sourceforge.net/project/showfiles.php?group_id=11026&package_i...

[Faustino]

Hello!

Have anyone tried this howto?

I'm getting:

You do not have access to this application

when I acess:

http://my_server/ewd/ewdMgr/index.mgwsi


Thanks guys.

[rtweed]

This is the ewdMgr application's security just doing it's job. It
doesn't recognise the IP address you're using as an authorised one.

From the Virtual Appliance's readme file:

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

Security : Access to the EWD Virtual Appliance Web Portal

When you first start the EWD Virtual Appliance and point a browser at
it, it will automatically set the security to only allow subsequent
browser access to the IP address of the browser you first used. You
can modify access and open it up to other browsers by clicking the
Security tab.

A problem can arise if the IP address of the machine you first used to
access the EWD Virtual Appliance changes its IP address. If this was
originally the only machine allowed to access the EWD Virtual
Appliance's web portal, then you'll have no way in, since the newly
allocated IP address will be blocked from accessing the web portal.

To get around this problem, you can reset the security of the EWD
Virtual Appliance by doing the following:

Log in to the EWD Virtual Appliance through the VMWare Player window
or a puTTY session with the username ewd and the appropriate password
(this is initially set to 1234567)

Type the following:
cd /usr/local/gtm/ewd
$gtm

GTM> d resetSecurity^%zewdGTM
GTM> h

You can log out if you wish

Next time you point your browser at the Virtual Appliance it will
automatically limit access to the browser's new IP address. Reset the
security via the web portal's Security tab.


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

Once you've gained access again, use the Security tab in the ewdMgr
application to configure individual IP addresses or ranges of IP
addresses that are allowed to access the ewdMgr application to avoid
this happening in the future.

Rob

[Faustino]

On more thing.

When a try using the virtual machine, Parallels Desktop in my case, I
got the same message :(

So.. Or We are missing something or I break my instalation and Virtual
Machine too :)

Bye.

[Faustino]

Thank you.

[rtweed]

What you're seeing is the ewdMgr application's security doing its job.

From the Virtual Appliance's readme file:

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

Security : Access to the EWD Virtual Appliance Web Portal

When you first start the EWD Virtual Appliance and point a browser at
it, it will automatically set the security to only allow subsequent
browser access to the IP address of the browser you first used. You
can modify access and open it up to other browsers by clicking the
Security tab.

A problem can arise if the IP address of the machine you first used to
access the EWD Virtual Appliance changes its IP address. If this was
originally the only machine allowed to access the EWD Virtual
Appliance's web portal, then you'll have no way in, since the newly
allocated IP address will be blocked from accessing the web portal.

To get around this problem, you can reset the security of the EWD
Virtual Appliance by doing the following:

Log in to the EWD Virtual Appliance through the VMWare Player window
or a puTTY session with the username ewd and the appropriate password
(this is initially set to 1234567)

Type the following:

cd /usr/local/gtm/ewd
$gtm

GTM> d resetSecurity^%zewdGTM
GTM> h

You can log out if you wish

Next time you point your browser at the Virtual Appliance it will
automatically limit access to the browser's new IP address. Reset the
security via the web portal's Security tab.

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

Use the ewdMgr portal application's security tab to define a range of
IP addresses that are allowed to access the ewdMgr application if
necessary. Click the little blue question mark in the pages for more
info,

Rob

On 19 Feb, 20:13, Faustino <faustino...@gmail.com> wrote:

[Faustino]

I made it..

GTM> d resetSecurity^%zewdGTM
GTM> h

Same problem :(

restart apache/mgwsi, reboot the machine and.... same message.

So I continue looking for a soluction.

Any news I'will post here, bye.

[rtweed]

Try using the IP address rather than the domain name in the URL

Rob

[Faustino]

I have already tried it.

But anyway... I did it and work ok...

cd /usr/local/gtm/ewd/
$gtm

> s ^%zewd("config","security","validSubnet","10.211.55.2")=""

Thank for you time.

[LD Gus Landis]

Rob,

Which globals require the 32K records?

For a production db for a VISTA system,
which is doing before image journaling, as
is done with GT.M replication, I suspect
that for an active database, the journal
files would grow at an unnecessary rate
for most updates.

Cheers,
--ldl

[rtweed]

Let me just clarify some things where there seems to be some
confusion. The directory paths that I used in the Virtual Appliance
should not be considered to be where you *must* put EWD code files.
EWD is designed to be completely configurable and if you're building
your own system, you can put it all wherever you like. Here's a bit
of hopefully useful background information that will help you with
this process:

There's two parts to EWD

- the compiler
- the run-time

Compiler:
=======

The compiler's job is pretty straightforward - it takes each of your
EWD source files and converts it into a corresponding GT.M routine
file. The conversion takes place by it converting the EWD source file
into an XML DOM, transforming that DOM and then spitting it out as a
routine file.

So, the compiler needs to know the path in which you hold your source
EWD application files. In the Virtual Appliance that's pre-configured
to be /usr/ewdapps but you can use any path you like

It also needs to know the path into which it will save the generated
Mumps ewdWL*.m routine files. Again you can set that to whatever you
like.

During the compilation, the source file is turned into a DOM which is
held in the global ^zewdDOM. This is one global that definitely needs
to be capable of storing 32k strings

After compilation, the DOM is deleted from ^zewdDOM so there's little
need to journal this global.

The configuration information used by EWD at compile time is held in
the global ^zewd("config") but is initially automatically set for you
in the dialogue you get when you first run compilePage or compileAll.
Otherwise I'd recommend you modify the configuration via the
appropriate ewdMgr application page, since I reserve the right to
modify EWD's internal global structures, but APIs will remain
unchanged.

The compiler also needs to know where to save the Javascript and CSS
files that it creates. This again is up to you to decide.

You don't need to run the compiled routines on the same GT.M machine
that you used to compile them. Treat the run-time environment as a
logically (and potentially physically) separate environment from the
compilation one. Of course in the Virtual Appliance, they're both
collapsed together.


Run-time
=======

At run-time, m_apache routes the incoming request to the appropriate
GT.M path and triggers the EWD page dispatch module (in ^
%zewdGTMRuntime). This figures out what compiled EWD routine to invoke
and passes control to it.

Which GT.M routine and global database (instance) you use at run-time
is again entirely up to you and configured via the m_apache config.
Of course the %zewd* routines must be accessible from this GT.M
instance and the generated ewdWL*.m routine files must be accessible
there too.

During runtime, EWD maintains its Session using the global ^
%zewdSession. I'd recommend that this is configured to support 32k
strings too otherwise it will be too restrictive to be useful. ^
%zewdSession is transient and probably doesn't need to be journalled.

That's basically it in a nutshell!

Rob

[Sean Connelly]

(part 3)

On Robs advice I'm opening up /var and /tmp permissions to 777

I'm going to install EWD-FOSS in two parts. I will start with an
installation and test of m_apache and then move on to the EWD engine.

Before that I'm going to need an installation of apache, I'm going for
version 2.0 for now...

sudo apt-get install apache2

I'm leaving the machine on a dynamic IP address for now. A quick test
and I can see Apache is working...

http://192.168.245.128/

The EWD-FOSS download unpacks with three folders, ewdMgr, m_apache and
routines. In the parent folder there is an EWD_FOSS_readme.pdf
document. There is a secion in the document on installing m_apache.

In the m_apache folder is the source file for m_apache (m_apache.c),
this includes a large section of comments also on installing m_apache.

The m_apache installation is in two parts. The m_apache?.so object
needs to be installed as an Apache module. The _ZMGWSI.m and
_ZMGWSIS.m routines need to be installed as a GT.m service.

I create the folder...

/usr/mgwsi/bin

into which I move the module m_apache2.so (which looks to be the
version I need for Apache 2.0).

Next I need to locate the apache2.conf to register m_apache2.so and
some other settings, its located in...

/etc/apache2/apache2.conf

(I'm adding all changes to the end of the apache2.conf file)

I need to add the following line so that apache loads the object at
the start-up of apache...

LoadModule m_apache_module /usr/mgwsi/bin/m_apache2.so

It looks like .mgwsi and .ewd are hardcoded into the object so I dont
need to define these, if I want to add my own file types then it
should be as simple as adding...

MGWSIFileTypes .mumps .rocks

I'm going to set up a test project called cobalt. This will have its
own GT.m instance. Into which I want to redirect any /cobalt url's

of type *.mgwsi. I'm going to set up a _ZMGWSI service in this
instance that will listen on port 7041. I want the requests to go to
request^cobaltHTTP. Here is what I add to the .conf file...

<Location /cobalt>
SetEnv MGWSI_PORT 7041
SetEnv MGWSI_M_FUNCTION request^cobaltHTTP
</Location>

There are some other settings that I could add. I don't think I need
MGWSI_M_SERVER as this should default to the same machine. Currently
I'm not sure what affect MGWSI_M_UCI will have on the service???

I restart apache...

sudo /etc/init.d/apache2 restart

but I'm getting a signature error connected with the m_apache2.so
module, perhaps I need to use m_apache22.so, although I thought this
would need apache 2.2 installed. Lets give it a go (Rob/Chris maybe
you could clarify the dependancies here).

I've copied over m_apache22.so and updated the LoadModule reference. I
quick Apache restart and there are no errors, hopefully a good sign!

The _ZMGWSI service is not up and running yet, but I'm curious if I
get a meaningful error when trying to connect to the following...

http://192.168.245.128/cobalt/test.mgwsi

sure enough, I get a "Service unavailable" message, a quick look in
the m_apache.c source code and and I can confirm this message has come
from the m_apache service. So far so good.

Next I want to install the _ZMGWSI routines. Instead of a monolithic
installation I want to configure the installation so that common
library code such as this and EWD can be shared amongst many GT.m
instances. I've chosen to create the following folder location for
common libraries...

/opt/gtmlib/

within which I create

/opt/gtmlib/mgateway/mgwsi

and drop in the files

_ZMGWSI.m
_ZMGWSIS.m

Next I need to create a GT.m instance...

Sean.

[Sean Connelly]

> Which globals require the 32K records?

Just a quick thought on this.

In a real world deployment, would large storage requirements (streams
etc) be kept in a separate GT.m .dat file to the small storage
requirements. In which case can they can be optimised independently?

Maybe Bhaskar has some thoughts on this?

With regards to EWD, I guess its only the development environment that
needs 32k if the intermediary .m code is deployed...

Sean.

[rtweed]

Sean

Yes as you've found, if you're using Ubuntu and Apache2, you need the
pre-built m_apache22.so module. Chris may be able to explain the
differences. I just tried them out till I found the one that
worked! :-)

Sounds like you're definitely making progress!

Rob

[rtweed]

Just a comment on virtual machine memory. I use VMware for pretty
much everything now - my work "machine" is actually an Windows XP
virtual machine. I've found that, at least for a WinXP VM running on
a Vista host with 4Gb of RAM, if you push the memory for the VM beyond
1.5 Gb, then massive amounts of disk thrashing begins to occur. When
I Googled this, others report it too and someone recommended trimming
back to 1.5Gb. After I did that it all settled down. It doesn't seem
to make much sense, but running with 2Gb configured for the XP VM
rendered it pretty much unusable.

Not sure if you'll get the same effect with Ubuntu - I suspect not,
particularly with a server implementation, but something to perhaps
watch out for.

Rob

On 19 Feb, 16:56, "seanatconne...@googlemail.com"

[Chris Munt]

From the command line:

root@mdb:/# apache2 -v
Server version: Apache/2.2.4 (Ubuntu)
Server built: Feb 4 2008 20:30:42

And from the docs:

Apache v1.3.x: m_apache13.so
Apache v2.0.x: m_apache2.so
Apache v2.2.x: m_apache22.so


Chris.

[rtweed]

I think I'd recommend allowing ^%zewdSession to be capable of saving
long strings too. There's nothing in EWD itself that requires this,
but I can imagine many situations where I'd want the session to be
persisting long strings of data.

Indeed I'm surprised how limited the standard default global record
size is in GT.M - in this day and age it's way too limiting in my
view. Even 32k can be a problem, and of course it's interesting to
see Cache's new increased configurable maximum string length in that
respect.

Rob

[Sean Connelly]

Thanks Chris, that makes things clear.

In my case apache2 -v gives me...

Server version: Apache/2.2.8 (Ubuntu)
Server built: Jun 25 2008 13:50:52

therefore I actually installed version 2.2.8 (not 2.0) when I used...

sudo apt-get install apache2

Cheers,
Sean.

[Sean Connelly]

(part 4)

It's been a few months since I last created a new GT.m instance so I'm
referring to the GT.m Administration and Operations Guide
(AdminOperationsManGTM.pdf) which is available for download from the
GT.m sourceforge site.

My fictitious project "cobalt" now needs a minimum of one global
directory, one global dat file and a default location to keep mumps
source code. Once again I'm trying to keep away from a monolithic
installation so I'm going to create a structure that should provide
some flexibility further down the roads. I've created a new folder...

/opt/gtmdat

within which I add...

/opt/gtmdat/cobalt

I realise that everything I've done in /opt is owned by root so I've
decided to change the ownership of all /opt sub folders and files to
my default user account for now. I need to figure out a better
strategy for this at a later point.

First I need to create the global directory. To do this I need to set
up an environment variable pointing to its intended location. I do
this from the command line and export it...

gtmgbldir=/opt/gtmdat/cobalt/mumps.gld
export gtmgbldir

I can now launch mumps direct mode, run ^GDE and use the 32k settings
that Rob posted earlier to create a .gld file.

/opt/gtmdat/cobalt$ mumps -direct

GTM>D ^GDE

%GDE-I-GDUSEDEFS, Using defaults for Global Directory
/opt/gtmdat/cobalt/mumps.gld

GDE> change -segment default -block=32256
GDE> change -region default -key=255 -record=32240
GDE> exit
%GDE-I-VERIFY, Verification OK

%GDE-I-GDCREATE, Creating Global Directory file
/opt/gtmdat/cobalt/mumps.gld

This has created the default global directory, now I need to create
a .dat for it.

/opt/gtmdat/cobalt$ mupip
MUPIP> CREATE
Created file /opt/gtmdat/cobalt/mumps.dat

:/opt/gtmdat/cobalt$ ls -l
total 64
-rw-rw-rw- 1 sean sean 3323904 2009-02-20 02:33 mumps.dat
-rw-r--r-- 1 sean sean 1024 2009-02-20 02:33 mumps.gld

Whilst I have all the correct environment variables set up I go into
mumps -direct mode and test that I can read and write to the globals.
No problems found and 32k does not appear to be an issue either.

The source / object code for my projects will live in

/opt/projects

within which I create

/opt/projects/cobalt

I can now create a shell script called cobaltprofile that will create
my cobalt instance environment variables, it looks like this...

#!/bin/sh
#cobalt environment variables

gtm_dist="/opt/gtm/V5"
export gtm_dist

gtmgbldir="/opt/gtmdat/cobalt/mumps.gld"
export gtmgbldir

gtmroutines=". $gtm_dist /opt/gtmlib/mgateway/mgwsi"
export gtmroutines

gtm="$gtm_dist/mumps -direct"
export gtm

set path=$PATH:$gtm_dist

Once these environment variables are loaded I make sure that I am in
the root of this GT.m instance

/opt/projects/cobalt

and fire up mumps -direct

Straight away there is a problem writing to the global dat file.
Whilst I have set up the environment variable gtmgbldir to point to
the correct .gld, the .gld file itself has created a default .dat
reference to mumps.dat, which will default into the folder that I
fired up mumps in. I have to go back to the ^GDE utility and change
the reference to a full path using...

CHANGE -segment DEFAULT -file=/opt/gtmdat/cobalt/mumps.dat

(btw, I am no expert on ^GDE so please let me know if anyone thinks
this is not the correct way to change this reference).

This was slightly more long winded than a default installation, but
this pattern should give me more flexability to share routines or data
between instances.

I now need to create the request^cobaltHTTP method that will accept
the incoming m_apache requests. I create the following mumps routine
in my /opt/projects/cobalt folder...

cobaltHTTP ;

;main entry point for /cobalt/*.mgwsi requests
request(cgi,data)
write "HTTP/1.1 200 OK",!
write "Content-type: text/plain",!!
write "Hello World :)"
quit

start ;start the background zmgwsi process
job START^%ZMGWSI(7041)
quit

I then fire up mumps for the cobalt instance and run...

start^cobaltHTTP

which should start up ZMGWSI as a background process listening on port
7041.

I go back to my web browser and test the following request...

http://192.168.245.128/cobalt/test.mgwsi

and I get the following response back...

PHPh^P^LOCAL##0###2.0.46#0^W^000Ku 18request^cobaltH

hmmm, something's not right... ???

Sean.

[rtweed]

It may be your use of ! instead of $c(13,10). Try

request(cgi,data)
write "HTTP/1.1 200 OK"_$c(13,10)
write "Content-type: text/plain"_$c(13,10,13,10)
write "Hello World :)"_$c(13,10)
write !
quit

Also put a bit of trace code in there to check if it's getting in at
all.

Rob

[K.S. Bhaskar]

GT.M limits: Local variables strings can be 1MB long. Global variable
nodes must fit within a database block. Permitted block sizes are
multiples of 512 bytes from 512 through 65024 bytes. Each block has a
16 byte overhead, so the maximum record size (variable name plus value)
is 65008 bytes. Popular block sizes are 4KB and 8KB.

If a small number of global variables need extra large block sizes, it
is common practice to organize (partition) the database so that those
global variables go into one file with a large block size and other
global variables go into another file with a more typical block size.
This is part of normal tuning for performance.

As a practical matter, for a development environment on today's
computers, performance is not a major concern. Production of course is.

Rob, as for comparisons between GT.M and other MUMPS implementations, in
the open source business, even more so than in the proprietary software
business, we do the development that attracts funding by being worth
something to someone who is using it to generate revenue in turn.

Regards
-- Bhaskar

[Sean Connelly]

Hi Rob,

Yes, ! and $c(13,10) turned out to be an obvious issue on Linux (doh).
Symptoms of using ! is a blank response.

I'm not sure what caused the original strange response. I cleaned the
pipes so to speak and everything is working, WAHOOO!

I found looking at the %MGWSI global helped to see what was going on.

There were a couple of gotcha's whilst I was trying to sort this
out...

1. Forgetting to run the the database down after a system restart, for
anyone needing to know how...

$gtm_dist/mupip rundown -FILE /opt/gtmdat/cobalt/mumps.dat

2. Updating the GT.m routine and not seeing the changes in the
browser. As you've mentioned before this is due to the ZMGWSI process
holding on to the object image of the routine. I've added a simple
restart method to my routine, it calls the STOP method of %ZMGWSI and
then starts the process back up on my port...

cobaltHTTP ;

;main entry point for /cobalt/*.mgwsi requests
request(cgi,data)

write "HTTP/1.1 200 OK",$c(13,10)
write "Content-type: text/plain",$c(13,10,13,10)
write "m_apache is working!",$c(13,10)

quit

start ;start the background zmgwsi process
job START^%ZMGWSI(7041)
quit

restart ;
d STOP^%ZMGWSI
d start
quit

Btw, could you clarify the following from m_apache.c...

> "By default, m_apache will attempt to communicate with a server running on the local machine. The server, in this context, can be either the M/Gateway MGWSI Gateway (which is freely available but is not Open Source) or directly to an M installation."

I assumed that I had installed the Gateway but then it dawned on me
that all this is working without any of the management screens that
normally live in the cgi-bin.

Bhaskar: Thanks for the response, this type of tuning sounds very
logical, something that I should try simulating. I do wonder what the
difference would be to store a large stream in many 4k blocks as
opposed to one 32k block (apart from having to code around it).

Next up, installing EWD and building an EWD page...

Sean.

[rtweed]

On 20 Feb, 16:28, Sean Connelly <seanatconne...@googlemail.com> wrote:

> I assumed that I had installed the Gateway but then it dawned on me
> that all this is working without any of the management screens that
> normally live in the cgi-bin.

The FOSS m_apache is a standalone module that has no management
interface so there's nothing to go in cgi-bin

It can be hooked into MGWSI to provide the full-blown management
interface, but remember that MGWSI is not FOSS. A full new MGWSI kit
including the new m_apache module will be made available soon.

When things go wrong with m_apache, just restart Apache:

sudo /etc/init.d/apache2 restart

Rob

[K.S. Bhaskar]

On 02/20/2009 11:28 AM, Sean Connelly wrote:

[KSB] <...snip...>

> 1. Forgetting to run the the database down after a system restart, for
> anyone needing to know how...
>
> $gtm_dist/mupip rundown -FILE /opt/gtmdat/cobalt/mumps.dat

[KSB] My strong recommendation is to run before image journaling on the
database, and as part of bootup to perform a mupip journal -recover
-backward. If the database was cleanly shut down, this is effectively a
no-op; if it was not cleanly shut down, it recovers the database.
Remember to delete old journal files to save space on the virtual disk.
See /etc/init.d/wvehr on the virtual machine on the VistA Tour CD
(http://downloads.sourceforge.net/fis-gtm/VistATour20081118.iso) for an
example of how this is done.

Rundown after a dirty shut down can mask database damage caused by
shutting down the system while the database is still active, and should
be followed by a mupip integ. Not recommended for a virtual machine demo.

<...snip...>

> Bhaskar: Thanks for the response, this type of tuning sounds very
> logical, something that I should try simulating. I do wonder what the
> difference would be to store a large stream in many 4k blocks as
> opposed to one 32k block (apart from having to code around it).

[KSB] In a virtual machine, you may not see much difference. The
overhead of going through two file systems will probably overwhelm any
other difference.

Regards
-- Bhaskar

[LD Gus Landis]

Hi,

I have (or appear to) successfully built an EWD capable
VM (from "scratch") under ESX using Ubuntu 8.04.2 server.

I "punted" on the "LSB" (Linux Standard Base) conformance
for the time being and merely "harvested" the ewd related
items from ewd_va_6_0. I left everything in the same
places (/usr/ewd, /usr/ewdapps, /usr/local/gtm/ewd, /home/ewd
etc) where the virtual appliance had them.

Starting next Saturday (Feb 28, through Tue Mar 3) a
WorldVistA technical meeting is happening at RMU (Robert
Morris University) in Pittsburgh, PA. If you cannot make it
in person, we would like remote participation. There is NO
fee for this event... Contact me (mailto: ldla...@gmail.com)
and I'll send you a registration link for the event.

Cheers,
--ldl

[LD Gus Landis]

Hi Sean,

It is my intention to focus on these types of
elements at the RMU WorldVistA tech meeting
(Feb 28- Mar 3).

The short answer is: Yes.

Why: Running a GT.M in production means
that you are journaling and replication (for me
anyway). Not all globals need to be journaled
nor replicated. If journaled/replicated, you want
"before image" journaling. If you are running
several million transations per 5 minute period
(as some systems I manage do), 32K before
images can be too much.

Fortunately...

From a comment I received from Rob, there is
one global (sorry don't recall) that requires 32K
records, BUT that global should not be journaled
nor replicated since it is a "temp" global.

I am working with the VISTA (from the VA) stuff,
and there are several other globals that are "temp"
globals there too. Since GT.M has journaling
enabled at the database file level (unlike DSM,
Cache and others that allow journal enabling at
the global level). This means that you probably
want at least two database data files. One for
journaled globals, and another for globals that
do not have journaling.

I hope to have intermediate drafts relative to
these items during the conference. I expect
that during the meeting, we'll host these and
other results on the development machine...
So stay tuned!!

BTW, any and all reading this list are
invited to attend the technical meeting.
There is no fee to attend, and we are hoping
for a number of "remote" workers... We want
to start working regularly as a group without
requiring travel... SO if you are interested send
me a note, and I'll point you to the registration
page for the WorldVistA technical conference
being held Feb 28 - Mar 3, 2009 at RMU in
Pittsburgh, PA... Hope to see many of you
there!

Cheers,
--ldl

[LD Gus Landis]

Rob,

Let's plan to make a trip to the local store in
Pittsburgh to get you a 2nd hard drive so that
we can get you to a real system on the desktop
(and have the safety net of your existing disk
until you are willing to "ditch" the training wheels!).

I'll be glad to help make this so... You need to
"reverse" the order... Run some UNIX on as the
primary OS and use a VM to run Microsoft
Windows XP when needed.. rather than the way
you are now!!!

Cheers,
--ldl

[LD Gus Landis]

SAC (VA VISTA) says 512 bytes max...

But the defaults for GT.M are rearly used... Maybe we
talk to Bhaskar about changing the defaults.

FWIW, I *always* create a mumps.gde from which
I create the mumps.gld file. So, I recommend that
you NEVER manually go into GDE to make any
changes!!! ALWAYS use a script to create a new
mumps.gld. That way you know what you have.

At least some recommendations on how to live
"Life with GT.M" (a diddy I am writing) are included
in the RMU Meeting documentation.

[LD Gus Landis]

Sean,

I would strongly encourage you to NOT put anything
in the gtm directory. Leave it pristine, exactly as it
was given to you by Fidelity.

Do not add any routines or directories to it. There is
no heed (unlike some other implementations of
MUMPS). This way you have your stuff separated
out...

Remember, what you are building needs to change
as needs change. GT.M is updated several times a
year, you should want to be able to move to new
releases easily, even if you don't happen to need
the latest features (yet). Get and stay "current",
or risk being faced with a major piece of work if
you don't "maintain" things properly. Maintenance
is work! Not just a concept.

The technique, exemplified in ewd where GT.M is
installed in /usr/local/gtm (not LSB conformant) and
/usr/local/gtm/ewd is an instance home (where the
database files are stored)... is very very restricting
when you update GT.M.

When living "Life with GT.M", you want to have the
independence that GT.M provides. Separate things
out so you can update easily.
- Put GT.M in a place like you have (/opt/gtm/V5xxxx
or one of Bhaskar's other suggestions).
- Put your data and journal files somewhere else
(e.g. an instance home like /home/ewd or /var/...
or /srv/..., etc, something that is LSB conformant)
- Put your administrative scripts in another, switchable
place (e.g. use symlinks, GT.M is NOT confused by
these wonderful creations as some other MUMPS
implementations are).

More to come.. Ask any questions that this comment
may have raised.

Cheers,
--ldl

[LD Gus Landis]

Sean,

> (btw, I am no expert on ^GDE so please let me know if anyone thinks
> this is not the correct way to change this reference).

Always have a script to create your mumps.gld file.
Trust that script. Make one of your first actions in that
script:
$ rm mumps.gld
Then fire up GDE and send it the directives to create
the mumps.gld you want.

IMO, you want to ALWAYS delete (or maybe archive)
the existing mumps.gld... If you don't then you are making
changes to the existing mumps.gld. You don't want to do
that. You want to "start over from scratch" so you can
have a reliable method for making the mumps.gld you
want. Starting over every time, using a script driven process
is the way to do this!

Never modify the mumps.gld using an interactive session!
Too easy to make a mess.

Script it so you can have a reliable mechanism. Also,
use a SCM (Source Code Management) tool so that as
you make changes to that script, you have a history of
what you've done. Very very useful over the long haul.

BTW, it looks like you have done a good thing by
creating /opt/gtmdata rather than putting it under
/opt/gtm/V5xxxx as I think I saw earlier! GOOD MOVE!

(There is more to say about how to lay things
out, but since you now have the data out from under
the GT.M product install... You are on your way).

Cheers,
--ldl

On 20 Feb, 07:26, Sean Connelly <seanatconne...@googlemail.com> wrote:

[LD Gus Landis]

GRRR; mailto: l d l a n d i s @ g m a i l . c o m

On 21 Feb, 22:58, LD Gus Landis <ldlan...@gmail.com> wrote:
> Hi,
>
>   I have (or appear to) successfully built an EWD capable
>   VM (from "scratch") under ESX using Ubuntu 8.04.2 server.
>
>   I "punted" on the "LSB" (Linux Standard Base) conformance
>   for the time being and merely "harvested" the ewd related
>   items from ewd_va_6_0.  I left everything in the same
>   places (/usr/ewd, /usr/ewdapps, /usr/local/gtm/ewd, /home/ewd
>   etc) where the virtual appliance had them.
>
>   Starting next Saturday (Feb 28, through Tue Mar 3) a
>   WorldVistA technical meeting is happening at RMU (Robert
>   Morris University) in Pittsburgh, PA.  If you cannot make it
>   in person, we would like remote participation. There is NO

>   fee for this event... Contact me (mailto: ldlan...@gmail.com)

[rtweed]

Getting this level of detailed technical knowledge about GT.M
management and configuration is great!

What would be good is to re-design the EWD Virtual Appliance so it
reflects good GT.M practice as well as correct m_apache and EWD
practice.

Any contributions or suggestions gratefully accepted

Rob

[K.S. Bhaskar]

Since we all three hope to be in Pittsburgh next weekend, let's try to
design a new EWD virtual appliance in time that is not taken up with
VistA work.

Regards
-- Bhaskar

[Sean Connelly]

(part 5)

I've installed the EWD compiler into a common library location

/opt/gtmlib/mgateway/ewd

and compiled all with mumps *.m

I then installed the ewdMgr into its own projects folder

/opt/projects/ewdmgr

I want to compile the ewd manager into the same location as the ewd
compiler so that both the ewd compiler and ewd manager object code can
be linked from the same place. The idea is that I can have many GT.m
instances all pointing to the same compiler and manager. This should
remove the need for installing the compiler and manager each and every
time I create a new instance, instead I can just add the path in the
gtmroutines environment variable.

I attempt to compile the ewd manager code using...

d compileAll^%zewdAPI("ewdMgr")

which prompts me for a number of source location paths. This compile
fails and I realise that the compiler has hardcoded the location /
ewdMgr and not /ewdmgr. I change the project folder name to...

/opt/projects/ewdMgr

delete out the ^zewd global and start the compile again.

The ewd manager pages are now discovered but I am getting an error,
ewdTemplate.ewd not found.

After a while picking through the compiler code I realise that there
must be a problem running the $$fileExists function which calls out to
Linux. Eventually I spot that my profile script is not correctly
setting up my PATH environment variable to include the GT.m
installation location. I correct this and the compiler now completes
without error. A distracting problem at first but it has been a useful
exercise. It would seem there is lots of file handing code in the ewd
library that could be useful for other projects. I wonder what other
gems can be found in the library!

I'm still not seeing the output code in /opt/gtmlib/mgateway/ewd
though. After a few more attempts I finally realise that the code is
going into /opt/gtmlib/mgateway and not /opt/gtmlib/mgateway/ewd. It
would seem that I need the trailing forward slash in the ^zewd
configuration. I edit the global instead of entering all the
information again. I clean up and re-compile. This time the generated
code is dropping into the correct location.

My apache2.conf file is pointing /cobalt at my own script,
request^cobaltHTTP. I want to run the manager from /cobalt so I'm
going to need to change the .conf file to point to

runPage^%zewdGTMRuntime

Ideally I would like to run both EWD pages as well as my own request
handlers. Eventually, if I want to run both then I guess I will need
to forward .ewd pages onto zewdGTMRuntime from my own catch all
script. Maybe it would be nice to map not just a path in apache to a
routine but also a path plus extension type to a routine. This would
allow for multiple handlers on the same listener.

The other idea / requirement request would be to register functions as
an ewd page without needing a page. That function would pick up all of
the security of ewd pages but the function would be responsible for
all of the output. It would be like having an ewd page with rawcontent
that only has one function call within it.

Time to see if I can get the manager screen up...

http://192.168.245.128/cobalt/ewdMgr/gtmHome.mgwsi

getting some odd errors again. I restart both Apache and the listener
and I finally get output from the manager. Its an ewd manager error
page...

"The specified application (ewdMgr) or page (gtmHome) does not exist"

I turn on the ewd trace to see what page its trying to call

^zewd("trace")=1

and then inspect the trace global...

^%zewdTrace(1)="Unable to find routine ewdWLewdmgrgtmhome.m"

I dig into the %zewdGTMRuntime and I realise that the code is
performing a $$fileExists on the file name without any prefixed
path...

i '$$fileExists^%zewdAPI(rouName_".m") d QUIT

I guess this will only work if this code runs from the folder the
routine lives in.

Maybe this section of code needs ^zewd("config","routinePath","gtm")
prefixed to the rouName variable.

Whilst I was looking at the value of ^zewd
("config","routinePath","gtm") I noticed something odd. Below is the
output of me re-setting up the zewd global. Notice that I inspect the
global twice after the compilation. In the first view the global
reflects what I entered. Between the second view I attempt to access
an ewd page in a browser. After which the second view shows this path
has been changed to the hard-coded value of /usr/local/gtm/ewd/.

I suspect there are a few places in the code that will need to change
to allow EWD to be configured in any way other than the way used in
the EWD virtual appliance.

Sean.

______________________________________________________

GTM>k ^zewd

GTM>d compileAll^%zewdAPI("ewdMgr")

Installing/Configuring Enterprise Web Developer (Build 755)

Note: hit Esc to go back at any point


Application Root Path (/usr/ewdapps): /opt/projects
Routine Path (/usr/local/gtm/ewd/): /opt/gtmlib/mgateway/ewd/
Javascript and CSS File Output Path (/var/www/resources/): var/www/
ewdresources/
Javascript and CSS File URL Path (/resources/): /ewdresources/

Enterprise Web Developer (Build 755) is configured and ready for use

/opt/projects/ewdMgr/about.ewd
/opt/projects/ewdMgr/applianceAbout.ewd
/opt/projects/ewdMgr/compilePage.ewd
/opt/projects/ewdMgr/compilePageResults.ewd
/opt/projects/ewdMgr/compiler.ewd
/opt/projects/ewdMgr/compilerResults.ewd
/opt/projects/ewdMgr/config.ewd
/opt/projects/ewdMgr/configDaemon.ewd
/opt/projects/ewdMgr/configMenu.ewd
/opt/projects/ewdMgr/configSettingsSaved.ewd
/opt/projects/ewdMgr/customTags.ewd
/opt/projects/ewdMgr/dataTypes.ewd
/opt/projects/ewdMgr/deleteCustomTag.ewd
/opt/projects/ewdMgr/deleteDataType.ewd
/opt/projects/ewdMgr/docParams.ewd
/opt/projects/ewdMgr/docPurpose.ewd
/opt/projects/ewdMgr/docRetVal.ewd
/opt/projects/ewdMgr/docTypCall.ewd
/opt/projects/ewdMgr/documentation.ewd
/opt/projects/ewdMgr/domDocumentation.ewd
/opt/projects/ewdMgr/domDocumentationDetail.ewd
/opt/projects/ewdMgr/editCustomTag.ewd
/opt/projects/ewdMgr/editDataType.ewd
/opt/projects/ewdMgr/errors.ewd
/opt/projects/ewdMgr/ewdAjaxError.ewd
/opt/projects/ewdMgr/ewdAjaxErrorRedirect.ewd
/opt/projects/ewdMgr/ewdDocs.ewd
/opt/projects/ewdMgr/ewdErrorRedirect.ewd
/opt/projects/ewdMgr/ewdMgr.ewd
/opt/projects/ewdMgr/gtmHome.ewd
/opt/projects/ewdMgr/gtmMenu.ewd
/opt/projects/ewdMgr/gtmSecurity.ewd
/opt/projects/ewdMgr/index.ewd
/opt/projects/ewdMgr/initialPage.ewd
/opt/projects/ewdMgr/initialSecurity.ewd
/opt/projects/ewdMgr/invalidAccess.ewd
/opt/projects/ewdMgr/invalidAccessMessage.ewd
/opt/projects/ewdMgr/invalidvaaccess.ewd
/opt/projects/ewdMgr/listError.ewd
/opt/projects/ewdMgr/listPage.ewd
/opt/projects/ewdMgr/listSession.ewd
/opt/projects/ewdMgr/login.ewd
/opt/projects/ewdMgr/loginForm.ewd
/opt/projects/ewdMgr/logout.ewd
/opt/projects/ewdMgr/mainMenu.ewd
/opt/projects/ewdMgr/mapacheConfig.ewd
/opt/projects/ewdMgr/newCustomTag.ewd
/opt/projects/ewdMgr/newDataType.ewd
/opt/projects/ewdMgr/relink.ewd
/opt/projects/ewdMgr/reloadCustomTags.ewd
/opt/projects/ewdMgr/reloadDataTypes.ewd
/opt/projects/ewdMgr/reloadSecurity.ewd
/opt/projects/ewdMgr/security.ewd
/opt/projects/ewdMgr/sessions.ewd
/opt/projects/ewdMgr/showCustomTagNotes.ewd
/opt/projects/ewdMgr/showDataTypeNotes.ewd
/opt/projects/ewdMgr/user.ewd
/opt/projects/ewdMgr/vaConfig.ewd
/opt/projects/ewdMgr/vaConfigApache.ewd
/opt/projects/ewdMgr/vaConfigArchitecture.ewd
/opt/projects/ewdMgr/vaConfigEWD.ewd
/opt/projects/ewdMgr/vaConfigExit.ewd
/opt/projects/ewdMgr/vaConfigGTM.ewd
/opt/projects/ewdMgr/vaConfigIP.ewd
/opt/projects/ewdMgr/vaConfigKB.ewd
/opt/projects/ewdMgr/vaConfigLinuxGTM.ewd
/opt/projects/ewdMgr/vaConfigMGWSI.ewd
/opt/projects/ewdMgr/vaConfigMenu.ewd
/opt/projects/ewdMgr/vaConfigUsernames.ewd
/opt/projects/ewdMgr/vaInitialPage.ewd
/opt/projects/ewdMgr/xref.ewd
/opt/projects/ewdMgr/xrefPageFromPage.ewd
/opt/projects/ewdMgr/xrefPageFromScript.ewd
/opt/projects/ewdMgr/xrefPageFromTag.ewd
/opt/projects/ewdMgr/xrefPageToPage.ewd
/opt/projects/ewdMgr/xrefPageToScript.ewd
/opt/projects/ewdMgr/xrefPageToTag.ewd

GTM>d ^%G

Output device: <terminal>:

List ^zewd
^zewd("config","applicationRootPath")="/opt/projects"
^zewd("config","backEndTechnology")="m"
^zewd("config","defaultFormat")="pretty"
^zewd("config","defaultTechnology")="gtm"
^zewd("config","frontEndTechnology")="gtm"
^zewd("config","jsScriptPath","gtm","mode")="fixed"
^zewd("config","jsScriptPath","gtm","outputPath")="var/www/
ewdresources/"
^zewd("config","jsScriptPath","gtm","path")="/ewdresources/"
^zewd("config","routinePath","gtm")="/opt/gtmlib/mgateway/ewd/"
^zewd("config","sessionDatabase")="gtm"

List ^zewd
^zewd("config","RootURL","gtm")="/ewd/"
^zewd("config","applicationRootPath")="/opt/projects"
^zewd("config","backEndTechnology")="m"
^zewd("config","defaultFormat")="pretty"
^zewd("config","defaultTechnology")="gtm"
^zewd("config","frontEndTechnology")="gtm"
^zewd("config","jsScriptPath","gtm","mode")="fixed"
^zewd("config","jsScriptPath","gtm","outputPath")="/var/www/resources"
^zewd("config","jsScriptPath","gtm","path")="/resources/"
^zewd("config","routinePath","gtm")="/usr/local/gtm/ewd/"
^zewd("config","sessionDatabase")="gtm"

[George Lilly]

Is there a reason not to make a KIDS file of EWD? And let KIDS manage the storage and implied compilation of the .m files?

[rtweed]

Remember that there's no reason other than convenience why you can't
copy the generated ewdWL*.m routines and move them to the place you
need them to run. As I've said elsewhere, EWD has two logically
separate roles - the compiler and the run-time. Provided the ^%zewd*
routines are accessible to the generated ewdWL* ones, it shouldn't
matter where they go and there's nothing else they should need apart
from read/write access to the ^%zewdSession global.

However if you figure out changes to the config setting/utilisation
code that I should make to the next build that would add to the
"convenience factor", let me know.

Rob

[LD 'Gus' Landis]

Hi,

LOL!

So... everyone, when you see the "modernization"
of the GT.M defaults, you'll know that GT.M owners
are in the disk drive business!!!

Cheers,
--ldl

On Fri, Feb 20, 2009 at 8:28 AM, K.S. Bhaskar <ks.bh...@fnis.com> wrote:
> ...

> Rob, as for comparisons between GT.M and other MUMPS implementations, in
> the open source business, even more so than in the proprietary software
> business, we do the development that attracts funding by being worth
> something to someone who is using it to generate revenue in turn.
>
> Regards
> -- Bhaskar
>
> On 02/20/2009 06:27 AM, rtweed wrote:

>>...

>> Indeed I'm surprised how limited the standard default global record
>> size is in GT.M - in this day and age it's way too limiting in my
>> view. Even 32k can be a problem, and of course it's interesting to
>> see Cache's new increased configurable maximum string length in that
>> respect.
>>
>

--
---
NOTE: If it is important CALL ME - I may miss email
---
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)

[LD 'Gus' Landis]

Sean,

One should always run MUMPS (GT.M, M21, Cache, etc),
with the default for globals being "journalling enabled".

For globals that are journalled in GT.M, you should enable
"before image" journals, which, write the block that is being
changed to the journal "before" it is changed. This allows
efficient recovery.

Now, every SET and KILL causes the block in which the
global node is located (and any block splits/merges, etc)
to be written to the journal before the SET or KILL is done.

If you are running a production system, it is not unusual
to see transaction rates of several million per 5 minute
interval... So, at that rate, is it clear that writing some
number of many several millions of transactions per hour,
that having 4k blocks vs 32k blocks makes a difference.

Also, GT.M enables/disables journalling at the data
base file level. Therefore reasons for having separate
database files (and hence, journals) are for such things
as:
- journalling requirements
- block sizes
- insertion/deletion styles
- other factors (size of a global).

Also, with GT.M, a global must exist entirely within
a single database data file... so for a large global,
you may want a separate data file just for that global.
Currently, GT.M does not support the concept frequently
called "subscript level mapping", which allows a global
to be spread across several database files.

There are many things to consider at the lower (DBA)
level of all MUMPS implementations.

Cheers,
--ldl

On Fri, Feb 20, 2009 at 9:28 AM, Sean Connelly
<seanatc...@googlemail.com> wrote:
> ...

> Bhaskar: Thanks for the response, this type of tuning sounds very
> logical, something that I should try simulating. I do wonder what the
> difference would be to store a large stream in many 4k blocks as
> opposed to one 32k block (apart from having to code around it).
>
> Next up, installing EWD and building an EWD page...
>
> Sean.
>

--

[Sean Connelly]

> Remember that there's no reason other than convenience why you can't
> copy the generated ewdWL*.m routines and move them to the place you
> need them to run

Which is what I've been trying to do. I've pointed out a problem in
the previous post, where this line in routine %zewdGTMRuntime...

i '$$fileExists^%zewdAPI(rouName_".m") d QUIT

appears to check for the existence of a routine without a path.
Therefore the page will not run unless the routine is in the same
directory as the instance. Therefore I can not place the routine
anywhere but the default instance.

I've also pointed out an oddity where this global entry defaults back
to a hard coded path during the execution of a page...

^zewd("config","routinePath","gtm")="/usr/local/gtm/ewd/"

> However if you figure out changes to the config setting/utilisation
> code that I should make to the next build that would add to the
> "convenience factor", let me know.

I'm happy to help improve the design of future releases but I think
you might want to take a look a these issues for the current release.

Sean.

[Sean Connelly]

Hi George,

What is KIDS? (i tried google'ing it)

Sean.

[George Lilly]

KIDS is part of the VistA Kernel and is used to distribute Packages, which can include MUMPS routines, Fileman Files, Fileman Options, Print, sort and other Templates, along with Package dependencies, Pre-install, Install, and Post Install instructions, and other very useful things.

You can read about it here:

http://www.hardhats.org/kernel/KRNkids.html

gpl

[LD 'Gus' Landis]

Rob,

Glad to help. I am not sure how much time I'll
have before getting to RMU. It is coming right
up, and I have lots of things going on.

BUT, I don't have lots to offer in the VISTA area
other than this lower level stuff... I am currently
focussing on being a Kernel/Fileman level person,
but am very early in that process... So my emphasis
is to:
- Support the Chewy-Gooey server as needed
- Get security right (e.g. mode 777 is not acceptable!)
- Get things well integrated into the VISTA
environment (configuring to support a variety of
block sizes, journalling, etc).
- Allow multi-hosting so that several EWD targets
can be hosted on a single server.
- Establish a roadmap for short term integration with
VISTA.

Cheers,
--ldl

[LD 'Gus' Landis]

Bhaskar,

Relative to the RMU conference, the server is
currently up and running. I "punted" on the LSB
conformance, and am using ewd_va_6_0 layout.

It is running in a VMWare ESX VM using the
Ubuntu 8.04.2 server. At this point, I plan to
only make changes that are required for the
conference to be a success. While we are at
the conference, we can make any changes
needed.

It is my intention to not worry about the LSB
conformant implementation until after the
conference (getting started during so that
Rob, et al have input).

Cheers,
--ldl

On Sun, Feb 22, 2009 at 7:40 AM, K.S. Bhaskar <ks.bh...@fnis.com> wrote:
>

[LD 'Gus' Landis]

Sean,

There are some hardwired paths in the code.

I expect that we'll (attendees at RMU) will be
discussing changes to that. It is part of the
LSB conformance.

Cheers,
--ldl

[LD 'Gus' Landis]

George,

Yes. We'll be working these issues at the RMU
conference. One thing is getting a name and
number space for EWD. I think we can accomdate
things, but may be somewhat "odd".. We'll let
Rick address these issues.

Getting EWD to be KIDS-compliant is a definite
goal, IMO.

Cheers,
--ldl

On Mon, Feb 23, 2009 at 11:08 AM, George Lilly <gli...@glilly.net> wrote:
> Is there a reason not to make a KIDS file of EWD? And let KIDS manage the
> storage and implied compilation of the .m files?
>
>>
>
>
> >
>

[LD 'Gus' Landis]

Rob,

Let's have this be on the list for RMU. I suspect that
we'll have to carve out some time to do this as I suspect
you'll have your hands full getting folks going (depending
on how much they get acquainted this week).

I failed to get things working last week so folks lost that
time.

Cheers,
--ldl

[LD 'Gus' Landis]

Sean,

I haven't confirmed, but suspect the the env var
gtmroutines is searched for the path to the
routine.

Do an "echo $gtmroutines" to see what is there.
If in MUMPS code, GT.M supports:
> W $ZRO
for that same value. One item you'll have to be
careful about is getting the path that was used to
find the routine.. Bhaskar, I forget, what is the way
to see which path element in gtmroutines produced
the hit for where the routine found is stored?

Cheers,
--ldl

[Sean Connelly]

In this case I think the code was performing an ls -l to then filter
for the existence of a file. If it was looking at gtmroutines then it
would have found the file since this includes the path to the file.
Thats why the file needs to be in the same directory as the GT.m
instance (the one I started the process from).

Cheers,
Sean.

[LD 'Gus' Landis]

Sean,

GT.M only looks at the gtmroutines environment
variable for locating routines. For sure, unless you
have "." in the gtmroutines path list, you won't even
find routines in the "current working directory".

Cheers,
--ldl

[K.S. Bhaskar]

On 02/23/2009 05:42 PM, LD 'Gus' Landis wrote:

[KSB] <...snip...>

> find the routine.. Bhaskar, I forget, what is the way
> to see which path element in gtmroutines produced
> the hit for where the routine found is stored?

[KSB] I believe you want SILENT^%RSEL() - see
http://www.fidelityinfoservices.com/user_documentation/html/rn_tb/GTM_V5.1-000A_Release_Notes.html#ch.hi.id.03
for more information.

Regards
-- Bhaskar

_____________

The information contained in this message is proprietary and/or confidential. If you are not the
intended recipient, please: (i) delete the message and all copies; (ii) do not disclose,
distribute or use the message in any manner; and (iii) notify the sender immediately. In addition,
please be aware that any message addressed to our domain is subject to archiving and review by
persons other than the intended recipient. Thank you.
_____________

[Sean Connelly]

My gtmroutines looks like this...

GTM>w $zro
. /opt/gtm/V5 /opt/gtmlib/mgateway/mgwsi /opt/gtmlib/mgateway/ewd

The routine that EWD is looking for is in /opt/gtmlib/mgateway/ewd

Looking at the code again its the fileSize function that uses ls -l,
the fileExists looks like...

fileExists(path)
o path:(readonly:exception="g fileNotExists")
c path
QUIT 1

path would be set to just the file name.

Sean.

On 23 Feb, 23:05, "LD 'Gus' Landis" <ldlan...@gmail.com> wrote:
> Sean,
>

[I, Valdes]

What if you already have an existing database? Do you have to start
over? -- IV

On 19 Feb, 14:24, rtweed <rob.tw...@gmail.com> wrote:
> Just digging the info out of the Virtual Appliance so it's here in one
> place.  Here's how to create a global database suitable for EWD's DOM
> processing, ie capable of handling records up to 32k long:
>
> cd /usr/local/gtm/ewd
> $gtm
> GTM>d ^GDE
> change -segment default -block=32256

> change -region default -key=255 -record=32240

> exit
> mupip create
>
> Note that, as Sean described earlier, if you use these settings, you
> must increase the kernel shared memory to 134217728
>
> On 19 Feb, 19:08, st...@stevenowen.com wrote:
>
> > Tks Sean! This will be a great howto...
>
> > seanatconne...@googlemail.com writes:
>
> > > (part 2)
>
> > > I downloaded the latest version of GT.m (for Linux)...
>
> > >  http://sourceforge.net/project/showfiles.php?group_id=11026&package_i...
>
> > > I then moved the download using filezilla into the following (new)
> > > folder...
>
> > >  /opt/gtm
>
> > > from which I unpack the download using
>
> > >  sudo tar xovf gtm_V53003_linux_i686_pro.tar
>

> > > From that folder IinstallGT.m with the following command

[K.S. Bhaskar]

You shouldn't have to. But a process that uses EWD will need a
different global directory (pointed to by $gtmgbldir) and routine search
path (pointed to by $gtmroutines). Unless you are running replication,
traditional VistA processes can continue to run side by side with
processes that access both EWD and VistA.

-- Bhaskar

On 04/09/2009 01:29 PM, I, Valdes wrote:
>
> What if you already have an existing database? Do you have to start
> over? -- IV
>
> On 19 Feb, 14:24, rtweed <rob.tw...@gmail.com> wrote:
> > Just digging the info out of the Virtual Appliance so it's here in one
> > place. Here's how to create a global database suitable for EWD's DOM
> > processing, ie capable of handling records up to 32k long:
> >
> > cd /usr/local/gtm/ewd
> > $gtm
> > GTM>d ^GDE
> > change -segment default -block=32256
> > change -region default -key=255 -record=32240
> > exit
> > mupip create
> >
> > Note that, as Sean described earlier, if you use these settings, you
> > must increase the kernel shared memory to 134217728
> >
> > On 19 Feb, 19:08, st...@stevenowen.com wrote:
> >
> > > Tks Sean! This will be a great howto...
> >
> > > seanatconne...@googlemail.com writes:
> >
> > > > (part 2)
> >
> > > > I downloaded the latest version of GT.m (for Linux)...
> >
> > > >
> http://sourceforge.net/project/showfiles.php?group_id=11026&package_i

> <http://sourceforge.net/project/showfiles.php?group_id=11026&package_i>...

[Ignacio Valdes]

So I assume that you would have two gld's? If so, then what would be the syntax for the env variable for two gld's? For example, my current one is:

export gtmgbldir="$vista_path/g/mumps.gld"

-- IV

On Thu, Apr 9, 2009 at 12:39 PM, K.S. Bhaskar <ks.bh...@fnis.com> wrote:

You shouldn't have to.  But a process that uses EWD will need a
different global directory (pointed to by $gtmgbldir) and routine search
path (pointed to by $gtmroutines).  Unless you are running replication,
traditional VistA processes can continue to run side by side with
processes that access both EWD and VistA.

-- Bhaskar

On 04/09/2009 01:29 PM, I, Valdes wrote:
>

> What if you already have an existing database? Do you have to start
> over? -- IV
>
> On 19 Feb, 14:24, rtweed <rob.tw...@gmail.com> wrote:
>  > Just digging the info out of the Virtual Appliance so it's here in one
>  > place.  Here's how to create a global database suitable for EWD's DOM
>  > processing, ie capable of handling records up to 32k long:
>  >
>  > cd /usr/local/gtm/ewd
>  > $gtm
>  > GTM>d ^GDE
>  > change -segment default -block=32256
>  > change -region default -key=255 -record=32240
>  > exit
>  > mupip create
>  >
>  > Note that, as Sean described earlier, if you use these settings, you
>  > must increase the kernel shared memory to 134217728
>  >
>  > On 19 Feb, 19:08, st...@stevenowen.com wrote:
>  >
>  > > Tks Sean! This will be a great howto...
>  >
>  > > seanatconne...@googlemail.com writes:
>  >
>  > > > (part 2)
>  >
>  > > > I downloaded the latest version of GT.m (for Linux)...
>  >
>  > > >
>  http://sourceforge.net/project/showfiles.php?group_id=11026&package_i

> <http://sourceforge.net/project/showfiles.php?group_id=11026&package_i>...

[K.S. Bhaskar]

The environment variable for other $gtmgbldir would point to the other
file name.

On 04/09/2009 02:26 PM, Ignacio Valdes wrote:
> So I assume that you would have two gld's? If so, then what would be the
> syntax for the env variable for two gld's? For example, my current one is:
>
> export gtmgbldir="$vista_path/g/mumps.gld"
>
> -- IV

_____________

[I, Valdes]

I did the following, restarted httpd, but I'm still getting 404 Not
Found on http://192.168.1.101/ewd/ewdMgr/index.mgwsi
netstat on 7041 shows it is listening:

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

GDE> change -segment default -block=32256
GDE> change -region default -key=255 -record=32240
GDE> exit
%GDE-I-VERIFY, Verification OK

%GDE-I-GDUPDATE, Updating Global Directory file
/opt/worldvista/EHR/g/mumps.gld
[vista@dune ~]$ mupip create
Error opening file /opt/worldvista/EHR/g/mumps.dat
: File exists
%GTM-F-DBNOCRE, Not all specified database files, or their associated
journal files were created

[K.S. Bhaskar]

Ignacio --

You have two different threads going on two different groups on the same
topic.

Also, I am afraid you are shooting from the hip and hoping that your
random shots will find a target. If you want to configure GT.M
databases, you really need to understand how GT.M databases are
configured. I have spent time creating a GT.M Acculturation live CD
with a bunch of exercises that include database configuration. Please
refer to that.

I reproduce below something I posted to hardhats a couple of years ago.
Sometimes half knowledge is less than ideal.

Regards
-- Bhaskar

------------------------------------------------------------
In high school biology, I was expert at dissection. In the late 1960s,
I was impressed by the pioneering heart transplant work of Drs.
Christiaan Barnard, Denton Cooley and Michael Debakey. Since the
mechanics of transplanting hearts seemed simple, since I was so handy
with the scalpel, and since frog hearts keep beating for an impressively
long time on their own in Ringers solution, one evening I attempted side
by side frog heart transplants, exchanging the hearts of two frogs I
caught in my back yard. Neither of my victims awoke from surgery, and
the most important thing I learned was how much there was that I didn't
know. It wasn't that I couldn't learn enough to be a heart surgeon -
the fact was that I didn't know enough to be a heart surgeon.
------------------------------------------------------------

On 04/09/2009 05:17 PM, I, Valdes wrote:
>
> I did the following, restarted httpd, but I'm still getting 404 Not
> Found on http://192.168.1.101/ewd/ewdMgr/index.mgwsi
> netstat on 7041 shows it is listening:
>
> GTM>D ^GDE
> %GDE-I-LOADGD, Loading Global Directory file
> /opt/worldvista/EHR/g/mumps.gld
> %GDE-I-VERIFY, Verification OK
>
>
> GDE> change -segment default -block=32256
> GDE> change -region default -key=255 -record=32240
> GDE> exit
> %GDE-I-VERIFY, Verification OK
>
> %GDE-I-GDUPDATE, Updating Global Directory file
> /opt/worldvista/EHR/g/mumps.gld
> [vista@dune ~]$ mupip create
> Error opening file /opt/worldvista/EHR/g/mumps.dat
> : File exists
> %GTM-F-DBNOCRE, Not all specified database files, or their associated
> journal files were created

[KSB] <...snip...>

[Ignacio Valdes]

Yes Bhaskar, I know that I am cross-posting. I have only limited time to get these things done that will benefit the community (and you) so I have to be expedient. Picasso said that you have to know how to paint well before you can paint badly. I know how to paint well.  So the surgeon example and you lecturing a double degreed computer scientist and physician who is the son of a surgeon on shooting from the hip just slows me down. There are purposeful reasons that I am painting badly now one of which is that I cannot know the specifics of everything which is why I am asking domain experts to show me the way inside of an ecosystem for benefit of all.

You are just going to have to trust me. Do you know of a solution on getting EWD to work with WorldVistA on GTM beyond RTFM?

-- IV

> I did the following, restarted httpd, but I'm still getting 404 Not
> Found on http://192.168.1.101/ewd/ewdMgr/index.mgwsi
> netstat on 7041 shows it is listening:
>
> GTM>D ^GDE
> %GDE-I-LOADGD, Loading Global Directory file
>         /opt/worldvista/EHR/g/mumps.gld
> %GDE-I-VERIFY, Verification OK
>
>

> GDE> change -segment default -block=32256

> GDE> change -region default -key=255 -record=32240
> GDE> exit
> %GDE-I-VERIFY, Verification OK
>
> %GDE-I-GDUPDATE, Updating Global Directory file
>         /opt/worldvista/EHR/g/mumps.gld
> [vista@dune ~]$ mupip create
> Error opening file /opt/worldvista/EHR/g/mumps.dat
> : File exists
> %GTM-F-DBNOCRE, Not all specified database files, or their associated
> journal files were created

[KSB] <...snip...>

[K.S. Bhaskar]

Ignacio --

I can see from your posts that you are struggling with concepts. It is
not an efficient use of my time - or yours for that matter - to try to
teach you concepts in a series of posts when I have already created and
posted tutorials on the concepts.

Getting EWD packaged with VistA is no big deal, but I have not yet done
it. So if you want to be the first, I see no way but for you to master
the concepts.

So, Read The Fine Manuals is the best advice I can offer at this time.
If something is not clear in them, please do ask.

-- Bhaskar

[Rob Tweed]

I'm happy to provide consultancy to get you up and running but.....not for free :-)

Rob

2009/4/9 K.S. Bhaskar <ks.bh...@fnis.com>

--
Rob Tweed
Director
M/Gateway Developments Ltd

The Pursuit of Productivity : http://www.mgateway.com

[Ignacio Valdes]

I pay exactly as much as I am being paid for this which is: 1) Benefit society. 2) A better health care system for my 3 young boys. -- IV

On Thu, Apr 9, 2009 at 5:20 PM, Rob Tweed <rob....@gmail.com> wrote:

I'm happy to provide consultancy to get you up and running but.....not for free :-)

Rob

2009/4/9 K.S. Bhaskar <ks.bh...@fnis.com>

[Fernando Telesca]

Ignacio,

Sorry if it´s already pointed out, but did you setup m_apache on your
virtual host:

LoadModule m_apache_module /usr/mgwsi/bin/m_apache22.so

<Location /ewd>
SetEnv MGWSI_M_FUNCTION runPage^%zewdGTMRuntime
</Location>

Rgds,

Fernando

On 9 abr, 19:25, Ignacio Valdes <ival...@hal-pc.org> wrote:
> I pay exactly as much as I am being paid for this which is: 1) Benefit
> society. 2) A better health care system for my 3 young boys. -- IV
>
>
>
> On Thu, Apr 9, 2009 at 5:20 PM, Rob Tweed <rob.tw...@gmail.com> wrote:
> > I'm happy to provide consultancy to get you up and running but.....not for
> > free :-)
>
> > Rob
>

> > 2009/4/9 K.S. Bhaskar <ks.bhas...@fnis.com>

> >> >      > Found onhttp://192.168.1.101/ewd/ewdMgr/index.mgwsi

> > The Pursuit of Productivity :http://www.mgateway.com- Ocultar texto entre aspas -
>
> - Mostrar texto das mensagens anteriores -

[Ignacio Valdes]

I see your 250-something-Mb Live Acculturation CD (which I'm re-downloading now to re-read the document which I lost) and I raise it with my only about 160 Mb WorldVistA Auto Installer Beta 4 rpm http://sourceforge.net/project/downloading.php?group_id=255113&filename=wvehr-server-installer-Beta-0.4-4.i386.rpm which contains a somewhat working M2Web config as well as a broken EWD pre-load adapted to WorldVistA with everything turned on and configured as the document says but still doesn't work. -- IV

On Thu, Apr 9, 2009 at 5:23 PM, K.S. Bhaskar <ks.bh...@fnis.com> wrote:

Ignacio --

I can see from your posts that you are struggling with concepts.  It is
not an efficient use of my time - or yours for that matter - to try to
teach you concepts in a series of posts when I have already created and
posted tutorials on the concepts.

Getting EWD packaged with VistA is no big deal, but I have not yet done
it.  So if you want to be the first, I see no way but for you to master
the concepts.

So, Read The Fine Manuals is the best advice I can offer at this time.
If something is not clear in them, please do ask.

-- Bhaskar

On 04/09/2009 06:01 PM, Ignacio Valdes wrote:

[I, Valdes]

Affirmative, it is on. Baked into my auto-installer actually:
http://sourceforge.net/project/downloading.php?group_id=255113&filename=wvehr-server-installer-Beta-0.4-4.i386.rpm

> > > The Pursuit of Productivity :http://www.mgateway.com-Ocultar texto entre aspas -

[I, Valdes]

I too have now progressed to the 'Service unavailable. Please try
again later.' message. This is on Fedora 9 OS. This is apparently
generated by m_apache Progress, but I am at a loss as what to do next
since the listener is on and SELinux in permissive mode is responding
when I try to get to the page saying that mumps is trying to get to
things. Note that SELinux is in permissive mode so it is not
preventing things from happening, just reporting that they are
happening.

-- IV

On Feb 20, 6:34 am, Sean Connelly <seanatconne...@googlemail.com>
wrote:
> Thanks Chris, that makes things clear.
>
> In my case apache2 -v gives me...
>
>  Server version: Apache/2.2.8 (Ubuntu)
>  Server built:   Jun 25 2008 13:50:52
>
> therefore I actually installed version 2.2.8 (not 2.0) when I used...
>
>  sudo apt-get install apache2
>
> Cheers,
> Sean.
>
> On 20 Feb, 11:25, "Chris Munt" <c...@cmunt.demon.co.uk> wrote:
>
> > From the command line:
>
> > root@mdb:/# apache2 -v
> > Server version: Apache/2.2.4 (Ubuntu)
> > Server built:   Feb  4 2008 20:30:42
>
> > And from the docs:
>
> >       Apache v1.3.x: m_apache13.so
> >       Apache v2.0.x: m_apache2.so
> >       Apache v2.2.x: m_apache22.so
>
> > Chris.

[K.S. Bhaskar]

There is a thread (started by Larry Landis) in yet another discussion
group: http://tinyurl.com/cvmnv2 - it is important to note that what
Larry discusses and what Ignacio is attempting here are apples and
oranges, web enabling two different parts of VistA with EWD with two
different techniques.

On the Acculturation live CD, please remember the errata I wrote about
earlier: when you get to the dd command (it will be obvious when you get
there) use count=800000 rather than count=716800 as noted in the
documentation.

Cheers
-- Bhaskar

P.S. I never was very good at poker. I was able to master tic-tac-toe
(which we called noughts and crosses), but that was about as good as I got.

[Ignacio Valdes]

That sounds really good what you are saying I'm trying to do which I hadn't thought about or even tried but I'll take credit for it if you like. I'm just trying to get EWD working per the install document in the ewd_756 download in a easy, VSB compliant, repeatable way as a convenience for others. For some odd reason people seem to shy away from rpm, deb or even bash automated installers for their Linux products, instead doing these nasty (in this case 6 pager) install instructions. I KNOW how to tar -zxvf, unzip, cp, mv, chmod, chown, su, mkdir and all that jazz, /etc/init.d/whatever restart, I DO NOT like to do it to install things. Spending 2 days and counting on installing and getting working something like this is just absurd. These automated install vehicles are not that hard to do. I hope to spare others the same ordeal. -- IV

On Thu, Apr 9, 2009 at 9:55 PM, K.S. Bhaskar <ks.bh...@fnis.com> wrote:

There is a thread (started by Larry Landis) in yet another discussion
group: http://tinyurl.com/cvmnv2 - it is important to note that what
Larry discusses and what Ignacio is attempting here are apples and
oranges, web enabling two different parts of VistA with EWD with two
different techniques.

On the Acculturation live CD, please remember the errata I wrote about
earlier: when you get to the dd command (it will be obvious when you get
there) use count=800000 rather than count=716800 as noted in the
documentation.

Cheers
-- Bhaskar

P.S. I never was very good at poker.  I was able to master tic-tac-toe
(which we called noughts and crosses), but that was about as good as I got.

On 04/09/2009 07:06 PM, Ignacio Valdes wrote:

[rtweed]

Grafting a working EWD environment onto your already existing GT.M
VistA configuration is clearly causing you grief and in order to get
it working you inevitably need to understand both GT.M and EWD in
considerably more detail than currently appears to be the case.

So let me make a suggestion to make life simpler for you.

There are two parts to EWD - 1) the compiler, 2) the run-time
environment

Most of the complexity you're seeing is in getting the compiler to
run. At the end of the day, all the compiler generates is a set of
GT.M routine files. So why not use the EWD Virtual Appliance - which
requires zero effort to get working (but took me man-months to design
and get right I'll hasten to add, all at my expense) - as the platform
on which you develop and compile your web pages. Then just copy the
routines across to your working system.

The Virtual Appliance can also be configured to provide the Apache
front end to your VistA system - there's no need to have it all
running on the one box. m_apache will happily connect to a GT.M
system on a separate IP address.

All you'll then have to do is install the EWD routines on your VistA
machine to provide the run-time orchestration and session management
for your EWD-generated routines. Indeed if you really wanted to make
it simple, wrapper your existing VistA methods as REST-based web
services and then you don't need to install EWD on your VistA system
at all - use the Virtual Appliance as a separate self-contained web
app environment that invokes your web services.

However if you really want to graft EWD into your environment, then
yes, the install and configure is not ideal. But then again you now
have access to it all, including the source, as Free Open Source
software, and like you I'm not being paid anything for its use, so
don't be surprised if there are things you need to do in order to make
it work for you. Indeed the whole essence of releasing something like
EWD to Open Source is to let people like you help the cause and write
the stuff that you believe is missing and would help others. It's
also the reason for me setting up and spending my time administering
this group - to foster a community of collaborators. I would
appreciate it if you could take these issues into account before you
launch into a tirade of complaints.

Rob

On 9 Apr, 23:25, Ignacio Valdes <ival...@hal-pc.org> wrote:
> I pay exactly as much as I am being paid for this which is: 1) Benefit
> society. 2) A better health care system for my 3 young boys. -- IV
>

> On Thu, Apr 9, 2009 at 5:20 PM, Rob Tweed <rob.tw...@gmail.com> wrote:
> > I'm happy to provide consultancy to get you up and running but.....not for
> > free :-)
>
> > Rob
>

> > 2009/4/9 K.S. Bhaskar <ks.bhas...@fnis.com>

> >> >      > Found onhttp://192.168.1.101/ewd/ewdMgr/index.mgwsi

[Ignacio Valdes]

Tirades are good for you :-) As the late Paul Pausch said your critics are your best friends they actually care enough to point out mistakes and problems.

I have downloaded your VM and will look at it. My unsolicited opinion is that I don't like VM's that much, they are brittle solutions that make derivative works difficult to do. They solve one problem but make it harder to solve others, deploy on other or newer distros and in the cloud.  They are also bulky downloads. Furthermore, my experience is that doing a straight installer makes VM's easier to build for self and others.

While this isn't near what you have done with the VM, here is some incomplete, simple bash code from my rpm that installs this per the document, but doesn't work. I have now progressed to the 'service unavailable' message that appears to be m_apache generated but do not know what to do next. Please help me with that.  I will share the finished code with thiis community once it is working which may make your life easier.

whereRwe=`pwd`
gtm_path=/opt/lsb-gtm/V53003
vista_path=/opt/worldvista/EHR
VISTAUSER="vista"
VISTAGROUP="vista"
vista_instance="EHR"

# Create m2web and ewd subdirectories first so that compilation and GDE work.
cd $vista_path/web
tar -zxf $whereRwe/$m2web_file
mv w m2web

cd $vista_path/web
tar -zxf $whereRwe/$ewd_file
mv ewd ewdapps

# Begin EWD installation.
cd $vista_path/web/ewdapps
cp ./m_apache/_ZMGWSI.m ./routines
cp ./m_apache/_ZMGWSIS.m ./routines
mkdir /var/www/resources
cp -Rf ./ewdMgr/resourceFiles/* /var/www/resources
chown -R $VISTAUSER:$VISTAGROUP /var/www/resources
chmod -R g+rw /var/www/resources
chown -R $VISTAUSER:$VISTAGROUP $vista_path/web/ewdapps
cd $vista_path/o
find ../web/ewdapps/routines/ -iname \*.m -exec $gtm_path/mumps {} \;
chown -R $VISTAUSER:$VISTAGROUP $vista_path/web/ewdapps
chown -R $VISTAUSER:$VISTAGROUP $vista_path/o
cd $vista_path/web/ewdapps/

routines
$gtm_path/mumps -direct <<EOF
D compileAll^%zewdAPI("ewdMgr")
$vista_path/web/ewdapps
$vista_path/web/ewdapps/routines
/var/www/resources
/resources/
h
EOF
sed -e s!/usr/mgwsi/bin!$vista_path/web/ewdapps/m_apache!g -e s!/usr/local/gtm/ewd!$vista_path/g!g<$whereRwe/ewd.conf>/etc/httpd/conf.d/ewd.conf
chmod -R g+rw $vista_path/*
$gtm_path/mumps -direct <<EOF
d START^%ZMGWSI(7041)
h
EOF

# End EWD Installation.

> I pay exactly as much as I am being paid for this which is: 1) Benefit
> society. 2) A better health care system for my 3 young boys. -- IV
>

> On Thu, Apr 9, 2009 at 5:20 PM, Rob Tweed <rob.tw...@gmail.com> wrote:
> > I'm happy to provide consultancy to get you up and running but.....not for
> > free :-)
>
> > Rob
>

> > 2009/4/9 K.S. Bhaskar <ks.bhas...@fnis.com>

> >> >      > Found onhttp://192.168.1.101/ewd/ewdMgr/index.mgwsi

[Fernando Telesca]

Ignacio,

 

Have you set app root path before compiling ewdMgr app, eg.:

 

d setApplicationRootPath^%zewdAPI(“/vista/web/ewdapps")

Also, after compiling can you see the generated routines: ewdWLewdmgr*.m ?

 

Rgds,

 

Fernando

 

2009/4/10 Ignacio Valdes <iva...@hal-pc.org>

[I, Valdes]

On 10 Apr, 10:45, Fernando Telesca <ferna...@telesca.com.br> wrote:
> Ignacio,
>
> Have you set app root path before compiling ewdMgr app, eg.:
>
> d setApplicationRootPath^%zewdAPI(“/vista/web/ewdapps")
>

Tried this, may or may not have helped. I have progressed to browser
saying: 'Enterprise Web Developer (Build 756) An Error has occurred
The specified application (ewdMgr) or page (index) does not exist.'
for http://192.168.1.101/ewd/ewdMgr/index.mgwsi

> Also, after compiling can you see the generated routines: ewdWLewdmgr*.m ?

In my /opt/worldvista/EHR/o which contains all the objects, there are
multiple _zewsMgr*.o present.

-- IV

[I, Valdes]

Latest installer code incorporating all the suggestions. You can more
or less ignore the m2web stuff.

whereRwe=`pwd`
gtm_path=/opt/lsb-gtm/V53003
vista_path=/opt/worldvista/EHR
VISTAUSER="vista"
VISTAGROUP="vista"
vista_instance="EHR"

# Create m2web and ewd subdirectories first so that compilation and
GDE work.
cd $vista_path/web
tar -zxf $whereRwe/$m2web_file
mv w m2web

cd $vista_path/web
tar -zxf $whereRwe/$ewd_file
mv ewd ewdapps

# Begin m2web Installation.
cd ../o
find ../web/m2web -iname \*.m -exec $gtm_path/mumps {} \;
chown -R $VISTAUSER:$VISTAGROUP $vista_path/web/m2web
cd $vista_path/web/m2web

echo "before GDE"
$gtm_path/mumps -r ^GDE << EOF
change -segment DEFAULT -file=$vista_path/g/mumps.dat
change -segment default -block=32256

change -region default -key=255 -record=32240

exit
EOF
echo "after GDE"

$gtm_path/mumps -run htCGI <<EOF
h
EOF


echo "before mupip load."
$gtm_dist/mupip load -format=binary m2web_20041220.gtmbinary
echo "pwd2: `pwd`"
mkdir /var/www/vista
sed -e s!vista_path!$vista_path!g<$whereRwe/m2web-vista-cgi>/var/www/
vista/m2web.cgi
chown -R vista.vista /var/www/vista
chmod 700 /var/www/vista/m2web.cgi
#chmod 700 /var/www/cgi-bin/m2web-vista-cgi
sed -e s!/var/log/apache2!/var/log/httpd!g -e s!/usr/local/m2web/w/
icon/!$vista_path/web/m2web/icon/!g -e s!/usr/local/m2web/!$vista_path/
web/m2web/!g -e s!/usr/local/m2web!$vista_path/web/m2web/!g<m2web-
vista-site>m2web-vista-site.tmp
rm -f m2web-vista-site
#mv -f m2web-vista-site.tmp /etc/httpd/conf.d/m2web-vista-site.conf
# End m2web Installation.

# Begin EWD installation.
cd $vista_path/web/ewdapps
cp ./m_apache/_ZMGWSI.m ./routines
cp ./m_apache/_ZMGWSIS.m ./routines
mkdir /var/www/resources
cp -Rf ./ewdMgr/resourceFiles/* /var/www/resources
chown -R $VISTAUSER:$VISTAGROUP /var/www/resources
chmod -R g+rw /var/www/resources
chown -R $VISTAUSER:$VISTAGROUP $vista_path/web/ewdapps
cd $vista_path/o
find ../web/ewdapps/routines/ -iname \*.m -exec $gtm_path/mumps {} \;
chown -R $VISTAUSER:$VISTAGROUP $vista_path/web/ewdapps
chown -R $VISTAUSER:$VISTAGROUP $vista_path/o
cd $vista_path/web/ewdapps/routines
$gtm_path/mumps -direct <<EOF
D compileAll^%zewdAPI("ewdMgr")
$vista_path/web/ewdapps
$vista_path/web/ewdapps/routines/

/var/www/resources/
/resources/
d setApplicationRootPath^%zewdAPI("$vista_path/web/ewdapps")
d START^%ZMGWSI(7041)

[Fernando Telesca]

Ignacio,

 

When you compile "ewdMgr" app (D compileAll^%zewdAPI("ewdMgr")), EWD looks for the app pages in /ApplicationRootPath/ewdMgr/*.ewd and generates the supporting routines for MGWSI/Apache: ewdWLewdmgr* (NOT %zewdMgr*, which are app routines, not page ones). So, you have to setup ApplicationRootPath and RoutinePath parameters, othwerwise there are no pages for EWD to compile and then no routines for MGWSI/Apache ro run.

 

Rgds,

 

Fernando

2009/4/10 I, Valdes <iva...@hal-pc.org>

[rtweed]

>I have downloaded your VM and will look at it. My unsolicited opinion is
>that I don't like VM's that much, they are brittle solutions that make
>derivative works difficult to do. They solve one problem but make it harder
>to solve others, deploy on other or newer distros and in the cloud. They
>are also bulky downloads. Furthermore, my experience is that doing a
>straight installer makes VM's easier to build for self and others.

Ignacio

With all due respect, you appear to be trying to fly an airliner
without having had any experience in the simulator. Little wonder you
are having trouble getting off the tarmac.

Please take my advice that I've reiterated now several times: spend
some time with the EWD Virtual Appliance and use it (like a simulator)
to learn how EWD works, to study its configuration requirements and to
discover what happens along the way as you build, compile and run web
apps. EWD works right out of the box if you fire up the appliance and
the appliance and the tutorial and detailed documentation that is
included will allow you to gain an understanding of the inner workings
of EWD. THEN you may be in a position to build an installer for your
specific purposes. Please put the cart before the horse and maybe
you'll get somewhere.

Rob

[Jai Singh VistA]

Hello Everyone,

While installing EWD Application in RHEL 8.4 (having Apache/2.4.37). we are unable to restart httpd services. We are getting below-mentioned error. 

Can someone please help us for this?.

# httpd -v
Server version: Apache/2.4.37 (Red Hat Enterprise Linux)
Server built:   Oct  6 2021 12:45:04

On Restarting the httpd reservice

httpd[4057286]: httpd: Syntax error on line 62 of /etc/httpd/conf/httpd.conf: Cannot load /usr/lib64/ht>tpd/modules/m_apache22.so into server: /usr/lib64/httpd/modules/m_apache22.so: undefined symbol: ap_log_error

[chris....@gmail.com]

This is because m_apache22.so is built for Apache v2.2.x whereas the web server you have is Apache v2.4.x.

 

You will need to rebuild the Apache module from source using the Apache Group’s procedures for v2.4.x.

 

Chris.

--
You received this message because you are subscribed to the Google Groups "Enterprise Web Developer Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to enterprise-web-develope...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/enterprise-web-developer-community/16bb669b-51c6-4944-b2cf-815d324fa1d2n%40googlegroups.com.

[Jai Singh VistA]

Thanks Chris,

Finally, this issue got resolved using below mentioned steps.