Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Astronaut WorldVistA 0.7.3 is out, GUI-Scheduling should work.

64 views
Skip to first unread message

Ignacio Valdes

unread,
Aug 31, 2009, 6:47:15 PM8/31/09
to hardhats
Okay, I just uploaded and updated Astronaut WorldVistA 0.7.3
rpm/deb/windows appliance. Thanks to Sam's work, GUI-scheduling
should now work out of the box without the timeout problem (see
details in Changes). Great work, Sam! -- IV

Astronaut WorldVistA Installers for Linux Beta 0.7 (Falling with
Style!) (see WorldVistA license below)

Description: Installs WorldVistA EHR/VOE 1.0 via rpm (Fedora/RedHat)
or dpkg (.deb file Ubuntu/Debian)

Downloads: http://sourceforge.net/projects/worldvistaautoi/files/

Changes: GUI-Scheduling client probably will work in this release by
changing XUS1.m and adding IPv6 processing to BMXMON and XWBTCPM.
Monster release with fixes for TMG-GUI-Config that allows User
access/verify code management, pre-loads bmx and all the pieces needed
to run GUI-Scheduling.

Other changes: Latest Fidelity Information Services gtm V53004A "Rock
Solid, lightning fast.", gtm is now symlinked to /opt/lsb-gtm/gtm so
that it can be easily upgraded. All client installers upgraded with
the latest TMG-CPRS, TMG-GUI-Config and GUI-Scheduling. The p(atch)
subdirectory will now work correctly (which is in the eye of the
beholder) and is now populated with the results of many patches. mupip
man page is now installed.

Default ID's and passwords: System Linux id for an instance now follow
the VistA Standard Base spec of <branding>vista<instance> to avoid
conflict and allow multiple instances to run side by side. For example
worldvistaEHR is the default Linux id for rpm install with password
vista!123. The default VistA id is sys.admin vista!123.

Author: Ignacio Valdes <iva...@hal-pc.org>

Contributors of code, modules or other in Alphabetic order (Ommitted?
Don't want to appear? Let me know.)

Individuals:
Anthracite, Nancy -- Original install document, general knowledge.
Bodtke, Peter -- Testing, documentation.
Bhaskar, KS -- GT.M, Acculturation documentation, architecture, shell scripts.
Dorsey, Jon -- VistA Standard Base co-proposer.
Hagood, Eddie -- TMG-GUI-Config and fixes.
Habiel, Sam -- BMX functionality, GUI-Scheduling.
Landis, "Gus" -- VistA Standard Base co-proposer.
Noorden, Lars -- Mupip man page.
Meiling, Ben -- VistA Standard Base co-proposer.
Papillion, Anthony -- VistA Standard Base co-proposer.
Pardue, Andy -- OVID.
Self, Jim -- m2web
Tai, Jonathan -- GT.M knowledge, VistA Standard Base, rpm wizardry.
Timson, George -- Pointed out IHS fix for SSN problem.
Toppenberg, Kevin -- TMG-CPRS, TMG-GUI-Config, TMGIDE, general knowledge.
Trotter, Fred -- VistA Standard Base co-proposer.
Watson, Steve -- Testing, documentation, VistA Standard Base co-proposer.
Whitby, Bruce -- Testing, , VistA Standard Base co-proposer, Misc.
Whitten, David -- Global expertise, debugging, architecture.

Corporations:
Fidelity Information Services -- GT.M
Medsphere Systems Corp -- OVID, Other.
M/Gateway Developments Ltd -- EWD
WorldVistA -- Processed FOIA VistA/VOE.

Government:
Indian Health Service -- BMX, scheduling GUI.
Veterans Affairs -- FOIA VistA.

Problems, comments, bugs: Post problems or issues to the Hardhats
group: http://groups.google.com/group/Hardhats or to
<iva...@hal-pc.org>

License: Installer: Affero GNU GPL version 3. No warranties expressed
or implied, use at your own risk. (see WorldVistA license below)

This installer has been tested on Fedora 10 and Ubuntu 9.

To install on rpm based systems, log in as root:

# yum install -y --nogpg astronaut-<version info>.rpm

Will install all depencencies and then the rpm or somewhat independently:

# rpm -i astronaut-wv-server-installer-XXX-0.X-X.i386.rpm

IT IS NORMAL TO SEE A BUNCH OF ERROR MESSAGES DURING COMPILATION.

To uninstall:

# rpm -e astronaut-wv-server-installer-XXXX-0.X-X

(NOTE: the absence of .i386.rpm for uninstalling)

To install on .deb, dpkg apt-get based systems, use sudo or sudo su to
log in as root:

# dpkg -i astronaut-wv-server-installer-XXXX_0.X-0.X.deb

IT IS NORMAL TO SEE A BUNCH OF ERROR MESSAGES DURING COMPILATION.

To uninstall:

# dpkg -r astronaut-wv-server-installer-XXXX_0.X-0.X.deb

You can change the default installation parameters: location, port,
etc by creating a file called wv-rpm-defaults in /, (rpm apparently
can only find it in /):
vista_path="/opt/worldvista/EHR" # Full path with the last node being
the instance name.
vista_instance="EHR" # Same as the last node above in
/opt/worldvista/EHR
VISTAUSER=worldvista$vista_instance
VISTAGROUP=worldvista$vista_instance
port=9260 # Listening port. By convention 9260
Production, 9261 Training, 9262 Development
vista_port_old_rpc=9210 # Listening port for old rpc broker.
Defaults to 9210
vista_port_vistalink=8002

Alter the above parameters as desired before running the rpm and it
will override the above defaults.

Follow the next steps after the rpm install has run. This gets you to
the point of being able to login as a text or CPRS client. BOX:VOLUME
PAIR GETS AUTOMATICALLY SET! The pre-set Access Code is: sys.admin
with Verify Code: vista!123. You will have to re-set the verify code
upon first login. Download the Windows client installers which should
all work out of the box with this server. The pre-set Linux id is
vista.world password is vista!123 which you will also have to re-set
on first login to the Linux vista.world id. To start m2web simply
start or restart apache then go to step 10 here:
http://vista.vmth.ucdavis.edu/notebook/index/48.html

Features:

1) Conforms to VistA Standard Base 0.9 RC 10.
2) Quick install.
3) Automatically sets BOX:VOLUME pair!
4) Creates a text<instance> id, automatically edits, compiles and
installs Bhaskar's runzu so that text<instance> runs with no shell and
no home directory.
5) Relatively smaller download size 155Mb complete package containing all files.
6) Controller software such as vistactl.sh start | stop | restart,
xinetd listener automatically configured and installed.
7) Automatic vista startup with journaling on server start and
graceful shutdown. Bhaskar's code.
8) Automatically opens CPRS port.
9) Has a backup solution (some assembly required).
10) Latest WorldVistA and gtm V53004A
11) Installs /opt/worldvista/EHR
12) Creates default vista id automatically.
13) Management commands: copy_this_vista_to.sh and
change_client_port.sh and uninstall_this_vista.sh
14) Requires two-factor deletion to really delete an instance. rpm -e
only removes symlinks to log files, text-client id and auto-start
routines. Requires explicit rm -Rf to really delete it all. rpm -i
--force will NOT over-write an existing instance.
15) Checks for file wv-rpm-defaults and overrides default install
parameters for different locations for the install.
16) Port handling files correspond to worldvista name spaces.
17) Pre-installs m2web. Start or restart apache then go to step 10
here: http://vista.vmth.ucdavis.edu/notebook/index/48.html Turn off
and on SELinux between boots by: echo 0 >/selinux/enforce or echo 1
>/selinux/enforce
18) Refreshed: Pre-installs Kevin Toppenberg's debugger, see
http://vistapedia.net for activation.
19) Pre-installs EWD (currently broken).
20) Pre-installs OVID.
21) Pre-installs Victory Programming Environment, see
http://vistapedia.net for activation.
# 22) MSC Fileman 1034 Had to be removed as it was causing a problem.
Stay tuned!
23) TMG-CPRS support with all associated bug fixes.
24) TMG-GUI-Config now supports user management.
25) BMX RPC broker and necessary parts pre-loaded.
26) GUI-Scheduling components pre-loaded.
27) Man page for mupip command.

Caveats:

1) Beta installer.


WorldVistA EHR /VOE 1.0 Release 6-2008

IMPORTANT FOR ALL PROVIDERS:

All drugs that the provider may need must be entered into the database
BEFORE THE PROVIDER PRESCIBES THEM from WorldVistA EHR.THE DRUG FILE
INCLUDED HAS NOT BEEN PREVIOUSLY RELEASED. IT IS ALWAYS IMPERATIVE THAT
ANY AND ALL DRUG ORDERS AND PRESCRIPTIONS BE CAREFULLY REVIEWED BY THE
PRESCRIBING PHYSICIAN AND DISPENSING PHARMACIST TO INSURE ACCURACY. IF
PROBLEMS ARE FOUND, PLEASE REPORT THEM HERE

IN...@WORLDVISTA.ORG
OR
http://trac.opensourcevista.net/worldvistaehr

Please see this link for information about entering new drugs and drug
doseages:

<http://worldvista.org/World_VistA_EHR/license-and-readme/ReadMe%20-%20Wor
ldVistA%20Pharmacy%20Drug%20File%202008-01-31.pdf>

Please look for additional information and updates about this release
here:

<http://worldvista.org/World_VistA_EHR/license-and-readme>

All portions of this release that are modified from the original Freedom
of Informtion Act release provided by the Department of Veterans Affairs
carry the GPL license and are Copyright WorldVistA. See this URL for the

full text of the license:

http://worldvista.org/World_VistA_EHR/license-and-readme/WorldVistA%20EHR%
20GPL%20License.txt

YOU SHOULD CAREFULLY READ THE FOLLOWING TERMS AND CONDITIONS BEFORE USING
THIS PRODUCT. DOWNLOADING OR USING ANY PART OF THE SOFTWARE AND
DOCUMENTATION INDICATES THAT YOU ACCEPT THESE TERMS AND CONDITIONS. IF
YOU DO NOT AGREE TO THE TERMS AND CONDITIONS OF THIS AGREEMENT, DO NOT
PROCEED.

A. General Disclaimer. THE WORLDVISTA-EHR (WV-EHR) SOFTWARE IS
PROVIDED TO RECIPIENT HEREUNDER "AS IS" AND ANY USE OF WV-EHR SOFTWARE BY
REQUESTOR SHALL BE AT ITS OWN RISK. TO THE MAXIMUM EXTENT PERMITTED BY
APPLICABLE LAW, WORLDVISTA AND ITS CONTRACTORS, EMPLOYEES AND AGENTS
DISCLAIM ALL WARRANTIES WITH RESPECT TO WV-EHR SOFTWARE, EXPRESS, IMPLIED
AND STATUTORY, INCLUDING WITHOUT LIMITATION ANY IMPLIED WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, ACCURACY,
COMPLETENESS, TIMELINESS, NON INFRINGEMENT OF THIRD-PARTY RIGHTS, NON
INTERFERENCE, AND ERROR FREE SERVICE. WORLDVISTA TAKES NO RESPONSIBILITY

FOR MONITORING OR REGULATING THE USE OR ACCURACY OF WV-EHR SOFTWARE.
RECIPIENT ACKNOWLEDGES AND AGREES THAT WORLDVISTA IS UNDER NO OBLIGATION
TO VERIFY THE ACCURACY OF OR OTHERWISE UPDATE WV-EHR SOFTWARE OR ANY
CONTENT CONTAINED THEREIN OR TO NOTIFY RECIPIENT OF ANY INACCURACIES
THEREIN OR UPDATES THERETO THAT MAY COME TO THE ATTENTION OF OR BE
DEVELOPED BY WORLDVISTA. WV-EHR MAY BE UPDATED PERIODICALLY, AND IT IS
THE RESPONSIBILITY OF THE RECIPIENT TO OBTAIN UPDATED VERSIONS OF THE
WV-EHR RELEASE AS REQUIRED. WORLDVISTA BEARS NO RESPONSIBILITY FOR
PROVIDING UPDATES TO RECIPIENTS. PASSWORD IS asdTYU

B. LIMITATION OF LIABILITY. TO THE MAXIMUM EXTENT PERMITTED BY
APPLICABLE LAW, NEITHER WORLDVISTA NOR ANY OF ITS EMPLOYEES, AGENTS OR
CONTRACTORS SHALL BE LIABLE FOR ANY INDIRECT, INCIDENTAL, SPECIAL,
CONSEQUENTIAL OR PUNITIVE DAMAGES, INCLUDING WITHOUT LIMITATION DAMAGES
FOR LOST PROFITS OR REVENUES, GOODWILL, WORK STOPPAGE, SECURITY BREACHES,
VIRUSES, COMPUTER FAILURE OR MALFUNCTION, USE, DATA OR OTHER INTANGIBLE
LOSSES OR COMMERCIAL DAMAGES, EVEN IF ANY OF SUCH PARTIES IS ADVISED OF
THE POSSIBILITY OF SUCH LOSSES, ARISING UNDER OR IN CONNECTION WITH THIS
AGREEMENT, COMPLIANCE EFFECTIVENESS STUDY TOOLS, THE USE OF OR INABILITY
TO USE THE SAME, OR ANY OTHER SUBJECT MATTER HEREOF. IN ADDITION, TO THE
MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, NEITHER WORLDVISTA NOR ANY OF
ITS EMPLOYEES, AGENTS OR CONTRACTORS SHALL BE LIABLE FOR ANY LOSS OR
DAMAGE SUFFERED BY RECIPIENT WHICH ARISES OUT OF OR IN CONNECTION WITH
ANY INFORMATION OBTAINED BY RECIPIENT VIA OR IN CONNECTION WITH WV-EHR
SOFTWARE.

kdtop

unread,
Aug 31, 2009, 7:00:48 PM8/31/09
to Hardhats
Ignacio,

Again, fine work.

I think we need to start thinking about how to propagate these updates
to those who have already installed your earlier distros.

Kevin

David Whitten

unread,
Aug 31, 2009, 7:24:52 PM8/31/09
to hard...@googlegroups.com

I agree with Kevin. This is the essence of the SDLC that I keep
bringing up in our meetings/calls

David

JohnLeo Zimmer

unread,
Aug 31, 2009, 9:59:10 PM8/31/09
to hard...@googlegroups.com
AMEN to that.

jl.z

I, Valdes

unread,
Sep 1, 2009, 8:44:26 AM9/1/09
to Hardhats
Agree to the agreement :-) -- IV

On Aug 31, 8:59 pm, JohnLeo Zimmer <johnleo...@gmail.com> wrote:
> AMEN to that.
>
> jl.z
>

Jim Self

unread,
Sep 2, 2009, 4:57:49 AM9/2/09
to hard...@googlegroups.com
Ignacio Valdes wrote:
Okay, I just uploaded and updated Astronaut WorldVistA 0.7.3
rpm/deb/windows appliance.
Ignacio,
Thank you. I just installed 0.7.2.deb this last weekend on Ubuntu 9.04 (Jaunty Jackalope). Your M2Web configuration is very close to operational. I noted 4 issues with simple fixes in a response earlier this evening to a thread on astronaut install problems.

What, if any, changes are there in 0.7.3 related to M2Web or EWD?


17) Pre-installs m2web. Start or restart apache then go to step 10
here: http://vista.vmth.ucdavis.edu/notebook/index/48.html Turn off
and on SELinux between boots by:  echo 0 >/selinux/enforce or echo 1 /selinux/enforce
  

I did not notice SELinux issues with M2Web on Jaunty.

The vista.vmth.ucdavis.edu server is not currently operational since I retired from UC Davis, but it looks like there many not be any additional steps needed to get M2Web running once the few issues are resolved.


19) Pre-installs EWD (currently broken).

What exactly is the status of EWD as installed? How is it broken and what might be required to fix it?

slfed...@aol.com

unread,
Sep 2, 2009, 9:24:56 AM9/2/09
to hard...@googlegroups.com
Please take me off this list serve.
Stephen L Fedder MD

kdtop

unread,
Sep 2, 2009, 9:36:59 AM9/2/09
to Hardhats
Ignacio and I had a good conversation about this.

Although we all agree that this is vital, it is also a huge job. We
have some ideas about how to do this, but would appreciate input on
how other think this can be achieved.

Kevin

I, Valdes

unread,
Sep 2, 2009, 10:06:27 AM9/2/09
to Hardhats


On Sep 2, 3:57 am, Jim Self <jas...@dcn.davis.ca.us> wrote:
> Ignacio Valdes wrote:
> > Okay, I just uploaded and updated Astronaut WorldVistA 0.7.3
> > rpm/deb/windows appliance.
>
> Ignacio,
> Thank you. I just installed 0.7.2.deb this last weekend on Ubuntu 9.04
> (Jaunty Jackalope). Your M2Web configuration is very close to
> operational. I noted 4 issues with simple fixes in a response earlier
> this evening to a thread on astronaut install problems.
>
> What, if any, changes are there in 0.7.3 related to M2Web or EWD?
>

None. 0.7.3 was a point release that fixed the timeout problem with
GUI-Scheduling.

> > 17) Pre-installs m2web. Start or restart apache then go to step 10
> > here:http://vista.vmth.ucdavis.edu/notebook/index/48.htmlTurn off
> > and on SELinux between boots by:  echo 0 >/selinux/enforce or echo 1 /selinux/enforce
>
> I did not notice SELinux issues with M2Web on Jaunty.
>

Yes, the vexing issue of SELinux :-(

> The vista.vmth.ucdavis.edu server is not currently operational since I
> retired from UC Davis, but it looks like there many not be any
> additional steps needed to get M2Web running once the few issues are
> resolved.
>

So I hear.

> > 19) Pre-installs EWD (currently broken).
>
> What exactly is the status of EWD as installed? How is it broken and
> what might be required to fix it?

Gus? -- IV

JohnLeo Zimmer

unread,
Sep 2, 2009, 10:14:24 AM9/2/09
to hard...@googlegroups.com
I'll start:

1. We need the ability to distribute KIDS automatically to a mailing
list of known installations.

2. ?

3. ... Well, I don't know <everything>. :)

jl.z

David Whitten

unread,
Sep 2, 2009, 11:01:25 AM9/2/09
to hard...@googlegroups.com
Well, to begin with, I think we should acknowledge what the things are that we are going to do, and what we are NOT going to do.  A discussion of "Why?" would be appropriate as well, so there is some principled approach to putting things into these categories.

Another aspect is what resources are available to accomplish things, and which we agree not to devote resources to do because those things can wait.  These resources include: time, energy, motivation,  skill, money, space, connectivity, interpersonal relationships, organizational acumen, blueprint, etc.

Generally, in this type of discussion, rights and responsibilities come in as well. An associated issue to the rights that people have, is the issue of ownership and licensing.  These are just ways to saying what people have permission to do and what they don't have permission to do.  Also, there is the discussion of what someone has the ability to do and what they can't do.

Finally, there is the continuing aspects of this, who will maintain and keep doing the things we need to do? It is useless to do it, and then not have it be useful when someone needs it.  This also includes clearly defining dependencies as well, so we know what could change and "break" this piece.

So to summarize:

We need to decide:
  for each part of the Software Development Life Cycle:
      What are the details of that part ?
      Why is it worth doing ?
      Do we have what we need to do it ?
      Who has permission to do it ?
      What will people get from it ?
      Who can we depend on to maintain it ?


Does this sound like a good outline of how to proceed?

Dave


On Wed, Sep 2, 2009 at 8:36 AM, kdtop <kdt...@gmail.com> wrote:

rtweed

unread,
Sep 2, 2009, 11:02:15 AM9/2/09
to Hardhats
Without having tried Ignacio's installer, I'd hazard a guess that a
GT.M database supporting 32k strings hasn't been defined (which, if
done, also requires a kernel memory increase).

All the configuration information for EWD installations is fully
documented in the portal application that is provided with the EWD
Virtual Appliance. I would suggest that this is consulted as it will
provide the answer to why it's broken!

Rob

Jonathan Tai

unread,
Sep 2, 2009, 1:12:01 PM9/2/09
to hard...@googlegroups.com
On Wed, 2009-09-02 at 07:14 -0700, JohnLeo Zimmer wrote:
> I'll start:
>
> 1. We need the ability to distribute KIDS automatically to a mailing
> list of known installations.

Having the KIDS builds themselves available is a good first step. For
OpenVista Server, we've begun to distribute KIDS builds separately[1]
from full-database releases to accommodate users who are upgrading. The
installation sequence can be found in the commit messages[2] of our open
repository.

> 2. ?

For #2, I would suggest that separating out the Linux components from
VistA itself, as we've done this with our OpenVista/GT.M Integration
Project[3], is vital. If the VistA management tools are separated from
VistA, you can attack making the tools upgradeable and making VistA
upgradable separately.

Making the tools upgradeable is relatively easy, since the tools don't
involve any configuration or patient data that must be preserved. Our
management tools from the OV/GT.M integration project have been
upgradeable from release to release since the first 0.8.0 release back
in May. In fact, you can upgrade from any older release to any newer
release (e,g. 0.8.0 => 0.8.2, 0.8.1 => 0.8.5), just like packages from
upstream Linux distributions.

VistA is already upgradeable via KIDS, and a (relatively) small amount
of work could allow a series of KIDS builds to be installed quickly,
provided that your upstream is pushing out a reliable sequence of builds
(see #1, above).

> 3. ... Well, I don't know <everything>. :)

I don't know everything either, but for #3, I'd suggest that the
next-generation revision control tools I've ranted about[4] at length on
this list could be used to distribute upgrades. Having the revision
control tools in place would allow a site to consume more than one patch
stream at once (although care should be taken that the two streams do
not conflict with one another). In practice, production sites with no
developers on staff will probably want to consume just a single
"aggregate" stream (possibly provided by a VistA integrator), and the
development work required to ensure no conflicts, QA, etc. will be done
in the integrator's branch.

- Jon

[1] http://tinyurl.com/mkyt4f
http://sourceforge.net/projects/openvista/files/OpenVista%20Server/1.5SP2/openvistaserver-1.5.sp2-kids.zip/download

[2] http://tinyurl.com/netwru
http://bazaar.launchpad.net/~ov+server/openvista-server/mainline/revision/37

[3] http://medsphere.org/community/project/gtm

[4] http://tinyurl.com/m2yoja
http://medsphere.org/people/jon.tai/blog/2009/07/01/the-case-for-distributed-revision-control-in-the-vista-community

signature.asc

I, Valdes

unread,
Sep 2, 2009, 2:21:50 PM9/2/09
to Hardhats
We turn our eyes toward New Mexico for Gus answer... -- IV

JohnLeo Zimmer

unread,
Sep 2, 2009, 2:32:03 PM9/2/09
to hard...@googlegroups.com
> So to summarize:
>
> We need to decide:
>   for each part of the Software Development Life Cycle:

[jl.z] Begging David's pardon for ignoring the meat of his post,

Besides, I see that Jon has more substantial contributions to make
(and is typing faster than I)

1. KIDS (just one, essential tool)

>       What are the details of that part ?

We must have a better way of maintaining a repository of KIDS distributions.
And there should be an automated or semi-automated method of
distributing them to "subscribers".

I do not believe that this needs to be a central repository. But there
needs to be a complete listing of KIDS files however widely they may
be distributed physically. So, yes, a virtual central repository.

>       Why is it worth doing ?

The VA FOIA site remains an important resource and its patch stream is
unlikely to replace KIDS with something more "modern". So VistA users
will continue to need access to these patches. Those of us living
outside the firewall should be able to evolve reliable mechanisms for
using KIDS, to include notification of new entries

In addition there are other potentially valuable inputs to the patch
stream outside the VA firewall.

** on the Trac server one can find the work of the CCR/CCD group:
https://trac.opensourcevista.net/browser/ccr/trunk/archive/C0C_1_0_10_T1_GTM.KID

It also holds kdtop's work on TMG-CPRS:
https://trac.opensourcevista.net/browser/cprs/branches/tmg-cprs/Server_KIDS/TMG1-1.0-3.KIDS

** Medsphere is contributing work on several fronts, for example on
GTM integration:
http://code.launchpad.net/openvista-gtm-integration/mainline/0.8.5/+download/MSC_GTM_INTEG_8.KID

** There are things hanging out on Nancy's server:
http://opensourcevista.net:8888/NancysVistAServer/Scheduling/VWSD_1_0.KID
(just an example)

** I'd like to find somewhere (and perhaps a namespace) for my pipe
print device.


>       Do we have what we need to do it ?

Initially one individual could build a virtual repository, not of
files but of pointers to files.

>       Who has permission to do it ?

It's a free country. I would expect some vendor or the other to have
a hidden repository for its own purposes. But I could start from FOIA
and the other freely available sources listed here.

>       What will people get from it ?

Ask Kevin about the need for maintaining a patch stream up to date.
Until we start to maintain public lists of patches, we will miss
things.

>       Who can we depend on to maintain it ?

We'd better depend on ourselves.


Other relevant issues:

Synchronization within an organization's VistA servers
MailMan distribution
Versions for Cache vs GT.M,
The limitations of KIDS distributions.


jl.z

Jim Self

unread,
Sep 2, 2009, 3:17:53 PM9/2/09
to hard...@googlegroups.com
Rob,
Ignacio's astronaut installer completed in less than 3 minutes for me on a fresh install of Ubuntu Jaunty.

I am hoping to move Ignacio's installer (astronaut) forward so as to have both M2Web and EWD easily accessible on the same server immediately after a short package installation. This would help me to learn EWD and to discover how the best features of both could be combined.

I am wondering if it might not be difficult to remove the EWD dependency on 32KB strings stored as single value data nodes.

In M2Web the same effect of storing and getting very large strings (potentially much larger than 32KB) is accomplished with a pair of functions that isolate applications code from system-specific M-globals string length limits.

My question for Ignacio is - where did the EWD install break. What exactly is there (in astronaut) and what not?
Jim
---
-- 

---------------------------------------
Jim Self (http://www.vmth.ucdavis.edu/us/jaself)
M2Web (http://vista.vmth.ucdavis.edu/notebook)
---------------------------------------

Ben Mehling

unread,
Sep 2, 2009, 3:32:36 PM9/2/09
to hard...@googlegroups.com
On Wed, Sep 2, 2009 at 11:32 AM, JohnLeo Zimmer<johnl...@gmail.com> wrote:

>  >       Who has permission to do it ?
>
> It's a free country.  I would expect some vendor or the other to have
> a hidden repository for its own purposes. But I could start from FOIA
> and the other freely available sources listed here.

Wearing my "some vendor" hat for a moment:

1) The OpenVista repo is not hidden [1]
2) KIDS builds are available in a tarball [2] and an open, source code
management, repository [3]
3) Patch sequence is available in release documentation (ChangeLog)

- Ben

[1] http://bazaar.launchpad.net/~ov+server/openvista-server/mainline/files
[2] https://sourceforge.net/projects/openvista/files/OpenVista%20Server/1.5SP2/
(openvistaserver-1.5.sp2-kids.zip)
[3] http://bazaar.launchpad.net/~ov%2Bserver/openvista-server/mainline/files/head%3A/kids/

JohnLeo Zimmer

unread,
Sep 2, 2009, 4:18:17 PM9/2/09
to hard...@googlegroups.com
BEN, my friend!

I was <not> referring to Medsphere, currently the most open vendor we have. :-)

I even used http://code.launchpad.net/openvista-gtm-integration/mainline/0.8.5/+download/MSC_GTM_INTEG_8.KID
as an example of a KIDS distribution that should be included.

"I would expect some <other> vendor(s) to maintain their own repository."

Highest regards,
jl.z -- Rock solid (not counting the right knee).
Lightning fast (except for that prostate thingy).

I, Valdes

unread,
Sep 2, 2009, 5:34:05 PM9/2/09
to Hardhats


On Sep 2, 2:17 pm, Jim Self <jas...@dcn.davis.ca.us> wrote:
> Rob,
> Ignacio's astronaut installer completed in less than 3 minutes for me on
> a fresh install of Ubuntu Jaunty.
>
> I am hoping to move Ignacio's installer (astronaut) forward so as to
> have both M2Web and EWD easily accessible on the same server immediately
> after a short package installation. This would help me to learn EWD and
> to discover how the best features of both could be combined.
>
> I am wondering if it might not be difficult to remove the EWD dependency
> on 32KB strings stored as single value data nodes.
>
> In M2Web the same effect of storing and getting very large strings
> (potentially much larger than 32KB) is accomplished with a pair of
> functions that isolate applications code from system-specific M-globals
> string length limits.
>
> My question for Ignacio is - where did the EWD install break. What
> exactly is there (in astronaut) and what not?

Jim, The issue as I understand it is that you have the 32Kb limit in
EWD and that VistA is inherently not that. Therefore you have to have
two mumps databases one EWD and one VistA that inter-communicate
through a process being worked out by Gus Landis. I will be the first
to say that there are others that are far more knowledgeable about
this than I. I'm something of a generalist and on purpose try not to
get too deeply involved in things other than installation since there
is too much to know. When Gus has things worked out, I think that is
when install progress will occur. -- IV

Ben Mehling

unread,
Sep 2, 2009, 5:40:09 PM9/2/09
to hard...@googlegroups.com
On Wed, Sep 2, 2009 at 1:18 PM, JohnLeo Zimmer<johnl...@gmail.com> wrote:
>
> I was <not> referring to Medsphere, currently the most open vendor we have. :-)
>
> I even used  http://code.launchpad.net/openvista-gtm-integration/mainline/0.8.5/+download/MSC_GTM_INTEG_8.KID
> as an example of a KIDS distribution that should be included.

Phew! Thank goodness! Removing that hat then -- besides, it doesn't
fit very well. ;-) -Ben

Jim Self

unread,
Sep 2, 2009, 9:18:56 PM9/2/09
to hard...@googlegroups.com
So, is the EWD install currently stalled at the very first step because of the 32KB problem or somewhere beyond that? If so, where might we begin to try to pick up the pieces?

What I was trying to say below is that there may be a simple fix for that problem that does not require 32KB global blocks.

I, Valdes

unread,
Sep 2, 2009, 10:18:20 PM9/2/09
to Hardhats
On Sep 2, 8:18 pm, Jim Self <jas...@dcn.davis.ca.us> wrote:
> So, is the EWD install currently stalled at the very first step because
> of the 32KB problem or somewhere beyond that?

Stalled at the 32Kb problem. While that isn't the only hurdle,
everything after that is minor.

>If so, where might we
> begin to try to pick up the pieces?
>

The answer to that is currently above my pay grade.

-- IV

rtweed

unread,
Sep 3, 2009, 3:52:47 AM9/3/09
to Hardhats
Jim

You have to understand that (like most software that I anticipate
ending up in GT.M over coming years) EWD was originally developed on
Cache where 32k strings are the norm. Much of EWD's compiler
functionality has been designed and relies on the fact that 32k
strings are available in global storage. I dare say I could mess
about and re-code stuff to make do with a lot less, but

a) I don't have the time (or rather can't justify it),
b) I don't want to risk de-stabilising EWD unecessarily and
c) 32k string handling seems entirely reasonable in this day and age
and if there's one thing about GT.M I don't understand it's the dogged
stance on the paltry default string size being sufficient for 21st
century applications. This is particularly the case when you consider
that InterSystems have now pushed global storage capabilities in Cache
to way beyond the 32k limit, largely due to customer demand.

See my comments about this issue in the following thread:

http://groups.google.co.uk/group/comp.lang.mumps/browse_thread/thread/75b7e01f9d51d7d3/b7e463cdcc05ff8a

So here's my suggestion - why not turn it on its head and use 32k
global strings as the norm for VistA's database? Nothing will break
in VistA by doing so (will it?), and both memory and disk are so cheap
these days that any wasted overhead is going to be largely
irrelevant. And EWD will then just work. Or am I missing something?

Rob

K.S. Bhaskar

unread,
Sep 3, 2009, 9:35:20 AM9/3/09
to hard...@googlegroups.com
Smaller block sizes (as long as they are multiples of the natural block
size of the underlying operating system) are more efficient than larger
block sizes. For VistA on Linux, 4KB block sizes are optimal, IMHO.

The counter argument is that, for the needs we are discussing (demos,
and VistA at the clinic / practice level) performance mostly doesn't
matter as long as you're running on a relatively new PC (i.e., built in
the last ten years or so).

The best answer is simply to partition the database to put the EWD
globals in a region with a 32KB block size, and the rest of VistA in a
region with a 4KB block size. That's what global directories are for.

Regards
-- Bhaskar

GT.M - Rock solid. Lightning fast.
_____________

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.
_____________

OldMster

unread,
Sep 4, 2009, 1:02:52 PM9/4/09
to Hardhats
I agree totally with Rob, even 32k is more limiting than I really
like, but i have learned to live with it. With all due respect to
Bhaskar, the days of coding for efficiency of the machine are long
gone. The cost and performance of modern systems exceed even my poor
programming abilities to overwork. As I have previously stated,
efficiency should no longer be a top development concern - Stability,
Reliability, and Readability are the top three we work on today in my
shop. Adding extra code to chop and reassemble real world data into
arbitrary size limits for storage does not support any of these
goals. One of the strengths of Mumps has always been its ability to
store 'real world data' without excessive manipulation (ie breaking
it up into multiple SQL tables to store logically connected data). As
processing, data storage/retrieval, and particularly communication
technologies have advanced, the amount and types of real world data we
process has increased, and the total size of the those objects we
process has grown. Failure to recognize, adapt, and adopt has always
been a criticism of the M community, and in my not so humble opinion,
is one of the leading reasons M has been ignored and ridiculed over
the years. How many of you still use 3 character variable names?
Take it as a point of pride that you can write a line of code using
the fewest characters possible? Still string code together in lines
that look to even M knowledgeable programmers like an alphabet
explosion instead of well formed, readable, supportable code?
Continuing these practices, and the constant refusal to move forward
will doom M to a continued slide into oblivion.
I'm now donning my Nomex suit.......
Mark
> >http://groups.google.co.uk/group/comp.lang.mumps/browse_thread/thread...

K.S. Bhaskar

unread,
Sep 4, 2009, 1:28:00 PM9/4/09
to hard...@googlegroups.com
Mark --

Nothing stops you from just using 32KB block sizes for everything and
not having to care. If you care about performance, GT.M let's you tune
for performance. We cater to all needs! (Since the computer systems at
some of our high end users are in the million dollar range and up,
saving a few percentage points in performance is pretty real money.)

Nomex not needed here!

Regards
-- Bhaskar

GT.M - Rock solid. Lightning fast.

_____________

rtweed

unread,
Sep 4, 2009, 1:44:17 PM9/4/09
to Hardhats
..and given that most VistA implementations *won'*t be on multi-
million dollar hardware, I'd reiterate my suggestion: configure VistA
for 32k blocks for everything and you'll all be able to use EWD
immediately without any further unecessary delays or expenditure of
everyone's expensive time, and with pretty much un-noticeable
performance overheads.

Jim Self

unread,
Sep 4, 2009, 2:16:18 PM9/4/09
to hard...@googlegroups.com
A second MUMPS data file, say EWD.dat,  for storing EWD data with 32KB blocks would seem to be easily accommodated within Astronaut.

Jim Self

unread,
Sep 4, 2009, 3:01:46 PM9/4/09
to hard...@googlegroups.com
rtweed wrote:
Jim

You have to understand that (like most software that I anticipate
ending up in GT.M over coming years) EWD was originally developed on
Cache where 32k strings are the norm.  Much of EWD's compiler
functionality has been designed and relies on the fact that 32k
strings are available in global storage.  I dare say I could mess
about and re-code stuff to make do with a lot less, but

a) I don't have the time (or rather can't justify it),
b) I don't want to risk de-stabilising EWD unecessarily and
  

I was hoping that the 32KB assumption was not scattered all over the EWD code. If not, direct global gets and sets for very long strings might be easily replaced with a pair of function calls.



c) 32k string handling seems entirely reasonable in this day
I agree, but even 32KB, or 64KB, or 128KB, etc. is not large enough to handle all the strings one might need to store. GT.M allows 1MB strings in local variables and functions. What happens when a string exceeds the 32KB limit? Do you prohibit that or crash or resort to chunking then?

Back in the bad old days following the demise of Datatree, Micronetics, and the MUMPS User Group and before GT.M was Free (Open Source), we implemented M-globals for PERL on the B-tree module of BerkeleyDB. BerkeleyDB offered 8-bit clean associative array keys and data values of unlimited length but its performance was not in the same class as any of the existing MUMPS implementations.

Nancy Anthracite

unread,
Sep 4, 2009, 8:08:55 PM9/4/09
to hard...@googlegroups.com
Speed is VERY important to caregivers.
--
Nancy Anthracite

fred trotter

unread,
Sep 8, 2009, 3:12:48 PM9/8/09
to hard...@googlegroups.com
The speed differences between any approach we are discussing here should (<- said hopefully) never be noticeable to a user. It might theoretically increase hardware costs, but those increased costs should balance out any real-world performance issues. Thankfully, Bhaskar's tag line is very much correct, GTM MUMPS is lighting fast, so fast that is worth thinking about slowing it down to "bullet" speeds in order to simplify development.

-FT


On Fri, Sep 4, 2009 at 7:08 PM, Nancy Anthracite <nanth...@earthlink.net> wrote:

Speed is VERY important to caregivers.




--
Fred Trotter
http://www.fredtrotter.com

rtweed

unread,
Sep 9, 2009, 4:50:05 AM9/9/09
to Hardhats
Jim

Yes you're right that whatever cut-off point you use for string length
handling will never be enough and conversely you could therefore
theoretically downsize to accommodate any small string length. The
point is that EWD has been designed around the original Cache 32k
limit and has been tested to death in real world commercial web
application development situations for 6 or more years and is known to
cope with anything that's been thrown at it to date. I've made it
available to the marketplace as a free open source product knowing
that I'm unlikely to see any immediate commercial return for doing so
and therefore I have pretty much zero incentive to spend any of my
otherwise busy time fixing something that ain't broke and I certainly
don't have any motivation to do anything to EWD that would
unecessarily risk destabilizing it in the short term.

Let's be clear: getting EWD to work with GT.M and VistA is not
difficult or rocket science - either configure a 32k database for its
specific use, or configure the entire environment to work with 32k
strings. I'm not sure I understand the resistance to doing this or
the apparent inability being demonstrated to make this happen.

Can I ask the question: 9 months after having one out of my way to
make it available as Free Open Source to try to provide this community
with a state of the art tool for Ajax development, is *anyone*
actually using EWD with VistA yet? I have to be honest and say that I
do wonder sometimes why I bothered. All I seem to hear is reasons why
people haven't used it or don't use it.

Butch

unread,
Sep 9, 2009, 9:35:57 PM9/9/09
to Hardhats
"the days of coding for efficiency of the machine are long gone."

Really? While I agree that stability reliability and readability are
extremely important, this is not a good philosophy to approach any
software project with. I'm not saying lose sleep over using 2 or 3
more clock cycles than are absolutely necessary, but don't let coding
for readability, become bloating for readability.

I do agree though that the extra bits for adapting to the underlying
filesystem is not a good way to have to do things. For the sake of
curiosity, is this a limitation of other non-cache based M?

K.S. Bhaskar

unread,
Sep 9, 2009, 9:50:34 PM9/9/09
to hard...@googlegroups.com

GT.M - Rock solid. Lightning fast.


On 09/09/2009 09:35 PM, Butch wrote:

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

> I do agree though that the extra bits for adapting to the underlying
> filesystem is not a good way to have to do things. For the sake of
> curiosity, is this a limitation of other non-cache based M?

[KSB] This is an interesting use of the English language. GT.M lets you
use 32KB block sizes for all your global variables. It also lets you -
optionally - use different block sizes for different global variables.
And this is termed a "limitation"?

Regards
-- Bhaskar

K.S. Bhaskar

unread,
Sep 9, 2009, 10:08:42 PM9/9/09
to hard...@googlegroups.com

GT.M - Rock solid. Lightning fast.


On 09/09/2009 04:50 AM, rtweed wrote:

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

> Let's be clear: getting EWD to work with GT.M and VistA is not
> difficult or rocket science - either configure a 32k database for its
> specific use, or configure the entire environment to work with 32k
> strings. I'm not sure I understand the resistance to doing this or
> the apparent inability being demonstrated to make this happen.
>
> Can I ask the question: 9 months after having one out of my way to
> make it available as Free Open Source to try to provide this community
> with a state of the art tool for Ajax development, is *anyone*
> actually using EWD with VistA yet? I have to be honest and say that I
> do wonder sometimes why I bothered. All I seem to hear is reasons why
> people haven't used it or don't use it.

[KSB] Rob, I think you underestimate the difficulty of recreating a new
graphical user interface for VistA. I suspect that simply mapping the
breadth of functionality that must be exposed may be a daunting task,
and if you consider CPRS reverse engineering the functionality therein
is a major project. I doubt that even with a corporation behind it,
Medsphere's portable dotNet client took a substantial chunk of work.

It has been said that it takes three times as long to create an
application as it does to create a prototype, and three times as much
yet again to create that application as an integrated part of a complete
system.

Remember that what EWD does is make Javascript toolkits easier to
integrate with MUMPS - it is infrastructure, rather than a design studio
for creating graphical user interface applications.

Incidentally, since there are a number of MUMPS programmers who also
know Python, I wonder if Pyjamas (see http://lwn.net/Articles/348341/0
and http://pyjs.org/) might make it easier for MUMPSters to develop GUIs
and hook them up to MUMPS applications with EWD.

OldMster

unread,
Sep 9, 2009, 11:46:36 PM9/9/09
to Hardhats
Butch,

To clarify, when I said "the days of coding for efficiency of the
machine are long gone." I should have phrased it "the days of coding
for primarily for efficiency of the machine are long gone."
Adding extra 'bloat' for the sake of 'bloat' is not good for anything,
and can make the code harder to read, so I think we agree.

However, I still regularly have discussions with 'old' mumpsters who
still assert that all the code in a 'line' versus vertically arranged
is more 'efficient', or that comments will slow down and 'bloat' the
code. If the mumps you are using is still a strictly interpreted
implementation, that would be the case. In a 'compiled' mumps like
GT.M or Cache, this is just silly. All it does is make someone who
has been trained in other languages run screaming for the hills when
they see the alphabet jungle that most mumps routines look like. I
don't necessarily agree with their assessment, but first impressions
do count. This is why in any example I post here, or on the
comp.lang.mumps group, or even in the Cache group, I don't abbreviate
the commands/functions, I avoid post conditionals unless absolutely
required, and I tend to put one operation on a line.

I didn't read in Rob's post anywhere that he thought the 32k issue was
a GT.M problem, only an issue with how Vista is currently deployed on
GT.M. GT.M handles 32k record sizes just fine, as I have found in my
benchmarking, and other than increased amount of shared memory needed
for buffers, doesn't have any downsides that I have found yet. I
would be like to understand the reasons that Bhaskar considers 4k as
the 'optimum' block size for GT.M. I can understand how for a given
application a particular block size may be 'optimum', but as a general
statement I am somewhat skeptical. For my primary application, larger
block sizes are more efficient, since many of the data structures
easily exceed 4k in size. With this data, multiple 4k reads would be
required to retrieve the whole collection of data I need and can
usually get with a single 32k block read. If I wasn't planning to use
replication, I would consider the 64k blocks that GT.M also enables.

I also think that 3x the time/effort for an application vs prototype
is an significant underestimation - prototypes I have thrown together
in a week have taken up to a year to turn into an application. Of
course, other prototypes have been deployed as working applications,
so as usual, general rules prove poor insight into a specific
occasion.

Mark