Astronaut WorldVistA 0.7.3 is out, GUI-Scheduling should work.
Ignacio Valdes
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
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
I agree with Kevin. This is the essence of the SDLC that I keep
bringing up in our meetings/calls
David
JohnLeo Zimmer
jl.z
I, Valdes
Jim Self
Okay, I just uploaded and updated Astronaut WorldVistA 0.7.3 rpm/deb/windows appliance.
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
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).
slfed...@aol.com
kdtop
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
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?
>
GUI-Scheduling.
> > 17) Pre-installs m2web. Start or restart apache then go to step 10
>
> 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?
JohnLeo Zimmer
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
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
rtweed
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
> 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
I, Valdes
JohnLeo Zimmer
>
> 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
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
> > 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
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
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?
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
>
> 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
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
> So, is the EWD install currently stalled at the very first step because
> of the 32KB problem or somewhere beyond that?
everything after that is minor.
>If so, where might we
> begin to try to pick up the pieces?
>
-- IV
rtweed
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
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
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
K.S. Bhaskar
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
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
Jim Self
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
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
Nancy Anthracite
fred trotter
-FT
Speed is VERY important to caregivers.
Fred Trotter
http://www.fredtrotter.com
rtweed
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
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
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
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
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
rtweed
> [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.
applications for the last 15 years for most of InterSystems' largest
customers and their largest applications worldwide. I would go so far
as to say that there is nobody in the worldwide Cache/Mumps community
with more expertise or experience in web/Ajax application
development. I think I *might* have an inkling of what's involved.
> 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.
>
Like I say all I seem to hear is reasons NOT to use EWD.
See http://www.slideshare.net/george.james/missioncritical-ajaxmaking-test-ordering-easier-and-faster-at-quest-diagnostics?type=powerpoint
for the kind of timescales that are my expected norm for major EWD-
based applications. I have seen no reason to date why web enablement
of VistA using EWD should be any different, but what do I know, eh?
> 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 (seehttp://lwn.net/Articles/348341/0
Why do I bother?
_____________
K.S. Bhaskar
GT.M - Rock solid. Lightning fast.
On 09/09/2009 11:46 PM, OldMster wrote:
[KSB] <...snip...>
> 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.
[KSB] I almost agree. After correctness, the goal of good code is
maintainability / readability (depending on business needs, it may be
third after performance). To that end, coding style should fit with the
culture. So, when I post code examples to a VistA forum, where the
culture - and over 20000 existing routines - use abbreviated keywords, I
use them. When my audience is programmers in general, I spell things out.
Post conditionals are an interesting point. I tend to use them even
when my audience is a general programming group because I think that
properly used, they improve readability.
> 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.
[KSB] Since GT.M searches linearly within a block (to take advantage of
key compression), there are CPU efficiencies to smaller block sizes.
From an IO perspective, multiples of 4KB are best for Linux (a 4KB
write writes the entire block, a 4095 byte write involves a
read-modify-write cycle). So, in general, my philosophy for optimizing
performance is to minimize block sizes, but keep them a multiple of the
underlying page size.
For VistA, maximum record sizes are on the order of 1KB. So, 4KB, as
the smallest multiple of the natural block size on most Linux file
systems is what I suggest for VistA.
> 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.
[KSB] As the saying goes, all sweeping generalizations are worthless! 8-)
JohnLeo Zimmer
2.) I <have> been a member of the MUMPS community for almost as long as I've been in medicine. I have often been privileged to watch while people with professional chops do what they do... People like Rob Tweed, and Greg Kreis, Tom Ackerman, KS Bhaskar, George Timpson, Kevin Toppenburg, Brian Lord, (once started, the list tends to go on, Jon Tai, Jim Self... I digress.)j
3.) EWD deserves more than we have given it to date. I watched Rob at RMU last year and assumed that we would be seeing real examples of EWDification of VistA within six months. I expected some tools to emerge that would allow a experienced dilettante such as myself (cf. #1) to start to play with EWD-over-VistA.
So I do understand Rob's frustration, but I don't understand exactly where we've failed. Unless it is that no one on the VistA side has invested the time needed to be the hero in this arena.
I think it may be an indication of just how thin our community is spread. We are trying to get our hooks into this mountain of code that is VistA and it is easier to get lost in some crack or crevice of the legacy code than to dig into something so different.
JL.Z
Butch
When it comes to reading code, I like to be able to gloss over it and
have some idea of whats going on, not have to sit and wade through
line by line, I'm not strictly a programmer, ( I try to avoid it) as
being a Solaris Admin is a more than full time job some days.
I wasn't making the assertion that comments add bloat, quite the
contrary, if a script (or in this case M) is written cleanly, and well
commented, I'm a lot more likely to put it to use, than if I have to
go through it with a fine tooth comb, and a translator.
As far as Bhaskars comment on 4k block sizes being optimal, it's
optimal in the sense of the out of the box Linux filesystems use a 4k
stipe size. This includes I do believe ext3, ReiserFS, and XFS
(haven't worked with them much for a few years now). You can
recompile the code and make the default stripe whatever you like as
far as that goes, but it's hardly worth the effort, unless you have
some REALLY high performance computing needs.
r...@rcresearch.us
Pittsburgh. This has been a tumultious year with a lot going on. Yes, we
made great progress with the Face-to-Face meeting in Pittsburgh. We just
had a Face-to-Face meeting in Sacramento and we had only a very few people
show up. Money is tight and the best progress has happened when everyone
can travel. Rob's presence in Pittsburg was very powerful and we had a
good over-view and a chance to ask questions there with him present. We
were able to have good Linux support there as well. The possibilities are
there, but the demands of the day-to-day world drag us all back to our
need to pay our Mortgages and feed our children. Help us get some grant
money where we can travel and get more done. I was there in Pittsburg and
Sacramento on my vacation time from work. I was not paid for to be there.
Speaking for myself, there are only so many vacation days a year for me
to draw on. The meeting at the National Library of Medicine ate another
hunk of my vacation time.
Sorry if we aren't moving faster, but the reality of the day job thins
out our efforts. Funding would help. I would love to be doing this
development and tools work full time, but it is unlikely in this
ecconomy.
Peace; Chris
Butch
is what are the upper limits on block sizes for GT.M as well as other
M implementations?
Butch
at or tried using EWD is they are not familiar with the underlying
language. Personally I don't even know exactly what the underlying
language(s) is. Not because I think that web development is a bad way
to do things it's actually a pretty good one. I wrote a shipping log,
and an inventory database app in PHP for a former empoyer, just to
see if I could. I could, I did (and for someone who had never
programmed in anything more than bash it was difficult, but worth
it).
Web interfaces when done well are a beautiful thing, when done poorly,
are a nightmare. When no one is even trying to develop anything...we
all lose out in the long run. I'm not a developer, I'm an admin, so I
look at these things differently than I think 95% of the people in
this group. Though like Rob, all I'm seeing is that people are giving
lots of reasons to not use EWD. Seems a lot like the people who
insist on not using Java. How many people have actually tried? How
many people who are giving reasons to not use EWD, Java, etc. are
saying this based on their own experience with the platform, and not
preconceived notions of how it's going to work, or how slow it's going
to be?
I do recall when I first joined this group, I had a few face to face
discussions with a couple of people about using web interfaces. Let
me tell ya, there are some people with serious misconceptions of what
web interfaces are all about.
There are options other than EWD. However, EWD is ready, it's here,
it's part of the packaged installer, (fully functional soon I hope)
and Rob is also part of the group...If you don't like what you get
working with EWD, take what you've learned and move on to something
else. In the end using python, php, etc, may be a better way to go,
but if someone doesn't start using it, then it's not going to matter
since we will never know.
Speaking in terms of software development in general, the real concern
(from the admin view of things) is that a lot of people, (speaking
generally) have the attitude of "Just put some code out there we can
secure it later". I don't much care what language the program is
written in, that mindset is going to cause problems for me, and for
the users, and in the long run, the developer who is going to have me
hovering over their shoulder ready to crack them in the back of the
head with a shovel for not paying attention, and making my job
difficult lol.
On Sep 10, 4:15 am, rtweed <rob.tw...@gmail.com> wrote:
> On 10 Sep, 03:08, "K.S. Bhaskar" <ks.bhas...@fnis.com> wrote:
>
> > [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.
>
> Bhaskar I have specialised in developing web interfaces for legacy
> applications for the last 15 years for most of InterSystems' largest
> customers and their largest applications worldwide. I would go so far
> as to say that there is nobody in the worldwide Cache/Mumps community
> with more expertise or experience in web/Ajax application
> development. I think I *might* have an inkling of what's involved.
>
> > 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.
>
> Sure it does, but is anyone even developing prototypes using EWD yet?
> Like I say all I seem to hear is reasons NOT to use EWD.
>
Nancy Anthracite
about 5000 processes running at once. Doesn't shared memory usage matter with
those sorts of numbers?
Nancy Anthracite
Nancy Anthracite
on.
Mike Clayton
I think you are in danger here of losing one of the best resources you
have. Rob has built a wonderful tool and made it open source for you
and people are quibbling about 32K strings?
It really is this easy:
1. Deal with 32K strings by making your database handle them, it's not
hard
OR
2. If you are really concerned about this, then PAY Rob to make it
work with less.
This is the simple no-brainer compromise! All development is about
compromise, nothing is perfect, and as far as compromises go, this is
as easy as they come.
On 10 Sep, 09:33, Butch <jwhit...@gmail.com> wrote:
> Rob, I think that part of the reason that many people haven't looked
> at or tried using EWD is they are not familiar with the underlying
> language. Personally I don't even know exactly what the underlying
> language(s) is.
> Web interfaces when done well are a beautiful thing, when done poorly,
> are a nightmare. When no one is even trying to develop anything...we
> all lose out in the long run. I'm not a developer, I'm an admin, so I
> look at these things differently than I think 95% of the people in
> this group. Though like Rob, all I'm seeing is that people are giving
> lots of reasons to not use EWD. Seems a lot like the people who
> insist on not using Java. How many people have actually tried? How
> many people who are giving reasons to not use EWD, Java, etc. are
> saying this based on their own experience with the platform, and not
> preconceived notions of how it's going to work, or how slow it's going
> to be?
the BEST AJAX tool for developing web pages and ONLY one I know of
that's written in M.
This should be our Nirvana and we're worried about 32K strings?
> There are options other than EWD.
No offense but whilst you're all waiting for the absolutely perfect
tool the world is spinning.
(Sorry Butch, I'm not really having a go at you, yours was just the
last post)
> Speaking in terms of software development in general, the real concern
> (from the admin view of things) is that a lot of people, (speaking
> generally) have the attitude of "Just put some code out there we can
> secure it later". I don't much care what language the program is
> written in, that mindset is going to cause problems for me, and for
> the users, and in the long run, the developer who is going to have me
> hovering over their shoulder ready to crack them in the back of the
> head with a shovel for not paying attention, and making my job
> difficult lol.
apps right 'out of the box'.
I work for Quest and we use EWD for all of our development now. It has
made us tremendously productive and our web facing application has
tens of thousands of consecutive users. Security is obviously a major
concern of ours, we have our app regularly checked by 3rd parties.
HOWEVER, the great thing that Rob's tool gives us is that we can just
code our pages without even worrying about that, the security is taken
care of.
All I'm saying is that are you really sure you want to p*** off Rob
over trivialities?
OldMster
Since the only 'production use' ready M systems I know of today are
GT.M and Cache, I only know them, and don't claim to be an expert yet
on GT.M. In Cache, there is only one block size, 8k. It allows
storage of global nodes up to slightly less than 32k. It handles the
large global nodes with a new block type 'big string block', that
allows it to store the 32k record across multiple blocks. The
splitting and recombining of the string is invisible to the Mumps
programmer, which is in keeping with the spirit of M. Globals freed
us from spending a great deal of time mucking about with how to store
things, and focus on making applications that solved user problems.
I have tried Java, and frankly don't like it at all. I could get
stuff done with it, but it was time consuming, and difficult to debug,
and didn't offer me anything I need that isn't supplied by the other
languages I use. I have been looking at Python lately, and I do like
what I have seen so far, but have not yet looked closely at the GUI
interface tools/frameworks.
100% agreement on security, and I should have included it in my top 3
things I code for. It is much easier, and more secure, to build the
security in as you develop the code than to go back and 'add it
later'.
Bhaskar,
Ok, you convinced me that 4k is probably the most efficient block size
on GT.M. My performance testing with 32k blocks in a less than
optimum storage platform has not caused me any speed concerns
however.
Nancy,
Since I don't yet have a complete understanding of how GT.M handles
shared memory, I can't answer your question. With 5000 processes, I
don't think anything less than a large 64bit machine with 64bit GT.M
and lots of memory is going to work, whether it is 4k or 32k blocks.
I certainly wouldn't want to try it with Cache on a single 32bit box,
and with Cache would probably prefer a 2 tier ECP network to a single
box, even with 64bit platforms. Since Vista doesn't have much in the
way of a web interface yet, it would only be 2 tiers, not 3 tiers as
Intersystems talks about.
Mark
On Sep 10, 8:51 am, Nancy Anthracite <nanthrac...@earthlink.net>
wrote:
K.S. Bhaskar
GT.M - Rock solid. Lightning fast.
On 09/10/2009 08:54 AM, Butch wrote:
>
> Ok to your point I mis spoke on that one. What I was actually asking,
> is what are the upper limits on block sizes for GT.M as well as other
> M implementations?
[KSB2] Block sizes in GT.M are multiples of 512 bytes, from 512 through
65024. As discussed elsewhere, for efficient IO, block sizes should
also be multiples of the natural block size of the underlying IO subsystem.
In GT.M, a MUMPS global node (variable plus subscripts plus value) must
fit in a block. There is a 16-byte overhead, so with a 4096 byte block,
the largest node is 4080 bytes.
Different database files can have different block sizes, so different
global variables can have different maximum record sizes.
rtweed
> Rob, I think that part of the reason that many people haven't looked
> at or tried using EWD is they are not familiar with the underlying
> language. Personally I don't even know exactly what the underlying
> language(s) is.
you write your scripts in Mumps code.
EWD was developed and designed specifically to allow Mumps developers
to create web/Ajax applications from within the environment they're
familiar with, and in particular to web-enable legacy Mumps
applications. That's why I made it available to this community in the
first place, It's tailor made for what you need instead of some
lashed up bits and pieces of Open Source stuff that look like they
*might* do the job, which, from where I sit, is what everyone appears
hell bent on doing.
Anyway it's up to you guys. If you don't or won't take advantage of a
proven product based around 15 years of Mumps/Cache-based enterprise-
scale web development expertise and still believe there's something
better or more appropriate out there for your needs, well, at least I
know I tried.
K.S. Bhaskar
GT.M - Rock solid. Lightning fast.
On 09/10/2009 10:04 AM, Nancy Anthracite wrote:
>
> BTW, that is M processes alone. That doesn't count whatever else may be
> going
> on.
>
> On Thursday 10 September 2009, Nancy Anthracite wrote:
> > Being no expert on this, I have heard that medium sized VA hospitals have
> > about 5000 processes running at once. Doesn't shared memory usage matter
> > with those sorts of numbers?
[KSB2] 5000 processes per se is no big deal. I have (as a stress test)
started 2000 concurrent GT.M processes on my laptop, and had perfectly
acceptable interactive response time.
In this case, the discussion was about CPU efficiency. I do know that
in high end application benchmarks, we can measure the extra CPU used by
larger than needed block sizes, but I don't think that has ever been
enough to affect overall throughput by more than a small number of
percentage points. We have had deployments that acknowledged the
inefficiency and then accepted it.
I don't see 5000 VistA processes as being a challenge either. However,
I would use 64-bit GT.M and put the object code in shared libraries to
deploy at that scale.
At the high end, what ultimately limits scalability is usually IO
throughput. CPU and memory have scaled with Moore's Law. IO speed has
not (disk capacity has scaled up remarkably well; throughput less so).
geky
EWD I was convinced that this software is the way to go, escpecially
for people who are using MUMPS and like me don't have the time
or don't want to learn a lot of other technologies.
I don't have the skills or the knowledge to install and configure EWD
in a way that it works with Vista or I would make it by myself and
share it. So I can at this time only watch Ignacio's efforts to build
his Installer and hope he will soon succeed to make it happen. But
I know that a lot members of this community have the knowledge
to help Ignacio. It would be beneficial for all to help him in this
direction to have at least a basic working configuration to experiment
with.
The key to start using EWD (for me but maybe for some others too)
is I think the possibility to have it "automatically" installed like a
lot
of other software out there, and Ideally an Intergration with Vista
Infrastructure (I mean FileMan at minimum) or at least to have some
working examples how to start with it using the FileMan api.
Thanks
fred trotter
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.
Working with the FOSS health community can be very trying. I fully understand how you feel. I felt that way in the early days of FreeB, which has still not been adopted by the VistA community.
Here are some basic insights about how to get things done in the FOSS Health IT community.
- You have to be prepared to fully ignore the peanut gallery. There will always be people who have no idea what it means to develop making comments as though they were developers. This is actually a negative side-effect of something positive: this community basically treats clinical users and software administrators as equals. That is a wonderful thing but it means that contributors like you have to learn to ignore people who are not really in your target audience.
- Your audience is developers, a small subset of this community. Developers are typically very circumspect group and are often lurkers on Hardhats and elsewhere (I am a notable exception to that rule).
- Developers never have any spare time, we always have something worthwhile that we are working on. That means for your software to get attention, it must win out over other interesting projects for any given developer.
Without presuming to speak for the rest of the development community here, I personally cannot afford to spend time on time-sink projects. Frankly, until Astronaut arrived -as a shared development environment- VistA as whole fell into this category for me. Once you get EWD working in Astronaut then it will be a different ball-game. Then a developer like me, who has very little time, can still afford to evaluate your library for potential projects. If you want an even wider audience, you should try to get EWD included, fully working, out-of-the-box in OpenVistA. Not every developer feels this way, some of them are entranced with the hard way, preferring to compile everything they can themselves from scratch just to be able to say they did.
For VistA there are two phases of adoption, first the VistA platforms, and then the developers who rely on those platforms. You are still at the first stage, and you should expect that only the VistA Demigods will even look at your stuff before the platforms adopt it. There are very very few VistA Demigods, which explains the reaction that you are seeing. Once the platforms have adopted your code, mere mortals like myself will consider using it for various projects. There are lots of mere mortals in the FOSS Health community. Do not get discouraged about how things are going now. You should only be discouraged after about a year of inactivity -after- the VistA platforms include your code. At that point I would assume that some other webify-VistA strategy had won out.
This is -not- a criticism or meant to imply that you have failed at anything. You have done some great work, and that is true if your code becomes popular or not. Sadly, the best code does not always make the most popular projects or vice-versa. FreeB eventually became popular, but it was certainly not because it was good code. Success in Open Source is very often an accident of history. Your code might not take off the way other code has. It is important to note, however, that no one has control over that. Even people with successful projects did not -know- that they would be successful. Everyone has to do just what you did, put your code out there and see what happens.
For my part, I have as much respect for you as I do for the pioneers of our movement. People like Torvalds, Larry Wall, Stallman, and that ilk. It is worth keeping in mind that they got famous because their technical approaches -happened- to win out. But when they started they had to stick there necks out there just like you are. I will not lie and tell you that the reputation gains that you will get will ever approach the benefits that those people enjoy. Even if you are a success here the best you can hope for reputation wise in the FOSS Health movement is a LinuxMedNews award, and even that will probably not happen unless your project succeeds. For every project that "wins" there are ten that die on the vine (even more if you look at the stats on sourceforge) do not be offended if that happens to you, it means nothing.
Community members who have a clue about this will still give you plenty of credit for your work, and you will be surprised how loyal even a small group of users can be. You may have people seeking you out for years to get consulting on EWD, even if it never really gets off the ground! In any case, those of us who have gone through what you are going through will always be quick to recognize a fellow contributer and give you the respect and appreciation that your work deserves. They will do this because the recognize that your actions take courage, and unless lots of people continiously find the courage to risk what you have, our community will begin to rot.
To sum up: Do not let the turkeys get you down, be patient, and if your project ultimately fails remember to make like Obi-Wan Kenobi. http://www.youtube.com/watch?v=rjCyZ2P9bCA
-FT
fred trotter
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.
rtweed
rtweed
web site since November 2006 as a fully working, pre-installed, pre-
configured reference platform, complete with full documentation in an
easy to access/read web portal format that explains exactly how it was
configured.
Kin Ho
[snip]...
I have tried Java, and frankly don't like it at all. I could get
stuff done with it, but it was time consuming, and difficult to debug,
and didn't offer me anything I need that isn't supplied by the other
languages I use. I have been looking at Python lately, and I do like
what I have seen so far, but have not yet looked closely at the GUI
interface tools/frameworks.
[snip]...
Usually I read the hardhats messages only...
I don't like Java too. I am exploring ColdFusion and it seems fairly
productive.
I export my antique COSTAR mumps to MySQL/ColdFusion and it is worth
exploring IMO.
Regards,
Kin
I, Valdes
The structure for VistA documents and note template's is nearly
identical to how Python based Zope does things. -- IV
Nancy Anthracite
different types of processes, correct??), 64 bit or not (which I believe makes
better use of memory, correct??), and how much memory do you have on your
machine?
I am asking because I thought this was mainly supposed to be a memory issue
for this particular comparison.
Nancy Anthracite
K.S. Bhaskar
MUMPS processes, not VistA processes. No, I am not using shared
libraries, I can do it with 32- or 64-bit GT.M since they're small
processes. The intent is to show that the OS and GT.M can handle a
large number of concurrent processes.
My laptop has a dual core 64-bit CPU, runs 64-bit Linux and has 4GB of
RAM. However, I have previously run the experiment on a 32-bit 1.8GHz
Pentium M with 1.5GB RAM.
-- Bhaskar
GT.M - Rock solid. Lightning fast.
On 09/10/2009 03:26 PM, Nancy Anthracite wrote:
>
> Same processes or different types ( so they can't share memory if they are
> different types of processes, correct??), 64 bit or not (which I believe
> makes
> better use of memory, correct??), and how much memory do you have on your
> machine?
>
> I am asking because I thought this was mainly supposed to be a memory issue
> for this particular comparison.
_____________
Nancy Anthracite
intention to not use what Rob has donated because of the 32K strings.
What is not getting through in all of this basically intellectual curiosity
based discussion is that the reason it EWD is not getting used more actively
is that the volunteer resources that work on these projects are stretched to
the limit . The businesses who are most interested in using it are really
just getting rolling and/or are facing the bad economic times everybody is and
they don't have a heck of a lot of cash to throw at projects that don't have
specific contracts associated with them.
There was a good turnout at the first coding meeting, but folks flew in largely
on their own nickel and paid for lodging themselves and woopie-do, got some
free cookies, coffee and lunch from a few donors in exchange while their
families were probably wondering which screw they had that was loose to give
up their vacation for this!
So please Rob, take the turnout at the first meeting as the sign that the
community really DOES appreciate what you have donated very much, and don't
give up on us now. Heck, if fast and all of that is what was required for
VistA to succeed, VistA would have never made it out of the VA and this great
mailing list would be a figment of the imagination.
I certainly hope that you are in this with us for the long haul, because we
are counting on you to hang in there. Knowing that you might abandon us can
only make things less likely to move forward. There are a lot of really hard
working, devoted people in this group. Please don't abandon them.
I think you and Bhaskar can commiserate. GT.M is extremely important to many
of us, yet Bhaskar is undoubtedly still waiting to have the donation of GT.M
to the open source community "pay off" for Fidelity.
Nancy Anthracite
Jim Self
The VMTH at UC Davis is no doubt very small in comparison to VA hospitals. In my experience of it 2000 users might log in through M2Web every day with 200+ users concurrently active most of the time. If long-lived connections such as RPC or telnet were involved, that might translate to 200-3000 user processes, but M2Web processes are short-lived (typically under a second) so most of the time there are only 20 user processes running.
It would be interesting to know number of users and user processes and the type of processes running in the VA hospitals and in other VistA related sites.
Nancy Anthracite wrote:
Being no expert on this, I have heard that medium sized VA hospitals have about 5000 processes running at once.
--------------------------------------- Jim Self (http://www.vmth.ucdavis.edu/us/jaself)
Jim Self
Good to hear from you again. If you still have MUMPS based CoStar, I would be interested in downloading - especially if adapted to GT.M - and exploring possibilities for accessing it with M2Web and EWD.
I looked for you and CoStar on the web a few years back but the old links were dead.
Jim
-- --------------------------------------- Jim Self (http://www.vmth.ucdavis.edu/us/jaself)
Nancy Anthracite
On Thursday 10 September 2009, K.S. Bhaskar wrote:
Nancy Anthracite
Jim Self
I am just trying to help move Ignacio's Astronaut installer forward and to understand how EWD is put together and what state it is in as installed. It would be helpful to have a simple install of VistA with EWD and M2Web included as Ignacio has been trying to achieve. This is my preferred starting point for keeping up with new versions of Linux, Apache, GT.M, VistA, EWD, etc.
Astronaut installed for me on a fresh install of Ubuntu(Jaunty) in 3 minutes with only a few minor glitches that had to be fixed before M2Web became operational. This is my personal minimum comfortable computing development environment and base for exploring/adopting new-to-me technologies like EWD.
I was pleased to find that EWD routines were included and are viewable in hypertext via M2Web. Many of the EWD functions and API's can also be called from the web based MUMPS programmer shell in M2Web.
I found no EWD globals except ^%zewd and ^zewd.
I ran install^%zewdGTM and then attempted to run compileAll("ewdMgr"). This failed with a set of a string of 15000 characters.
I set maxlen=3500 (instead of 15000) in ^%zewdHTMLParser. That seems to have eliminated one source of EWD errors.
shellCommand^%zewdGTM is broken. It constructs a zsystem command that calls back to GT.M with a shell pipe to capture results of shell commands. It is broken at least in part because "mumps" alias is not defined, but it would be better to open a pipe device from the current process. I will try fixing that next.
The EWD version is 762 from 2009-05-06. Has that been fixed in a newer version?
I found that the 32KB issue was discussed on the EWD and VistA group back in May and June when I wasn't paying attention (I decided it was time to leave the VMTH then.)
http://groups.google.com/group/ewd-and-vista/browse_frm/thread/6ca436784e8aa79e/a0b7944527c8ef3a?q=ewd+vista#a0b7944527c8ef3a
When I attempt to list all globals I see an error at the end of the list that EWD.dat is missing - an indication that Ignacio intended to include it, presumably with 32KB blocks.
rtweed wrote:
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. On 4 Sep, 20:01, Jim Self <jas...@dcn.davis.ca.us> wrote:rtweed wrote:JimYou 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, buta) I don't have the time (or rather can't justify it), b) I don't want to risk de-stabilising EWD unecessarily andI 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 dayI 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.
Jim Self
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.
Jim,
Without presuming to speak for the rest of the development community here, I personally cannot afford to spend time on time-sink projects. Frankly, until Astronaut arrived -as a shared development environment- VistA as whole fell into this category for me. Once you get EWD working in Astronaut then it will be a different ball-game.
fred trotter
-FT
Oops, that was Rob responding to my findings and questions about getting EWD working from an Astronaut install.
Butch
horribly. As soon as SSD drives become more stable, they will be a
great way to go. Sadly it's going to be a couple of years before they
really work out the problems with reliability. Seems that right now
the emphasis is on making them cheap, and the consequence is they are
indeed cheap, and highly unreliable.
Jim Self
I don't know much about Web development, but since I looked at EWD I was convinced that this software is the way to go, escpecially for people who are using MUMPS and like me don't have the time or don't want to learn a lot of other technologies. I don't have the skills or the knowledge to install and configure EWD in a way that it works with Vista or I would make it by myself and share it. So I can at this time only watch Ignacio's efforts to build his Installer and hope he will soon succeed to make it happen. But I know that a lot members of this community have the knowledge to help Ignacio. It would be beneficial for all to help him in this direction to have at least a basic working configuration to experiment with.
The key to start using EWD (for me but maybe for some others too) is I think the possibility to have it "automatically" installed like a lot of other software out there, and Ideally an Intergration with Vista Infrastructure (I mean FileMan at minimum) or at least to have some working examples how to start with it using the FileMan api.
FWIW, I have made serious attempt at providing understandable working examples of accessing VistA data and functionality on the web. The patient registration project (/patreg) in M2Web was specificaly developed as an example of a general framework for using Fileman API's in a web application. The intention was to bootstrap a discussion of the possibilities and problems related to patient registration and some of the commonalities and tradeoffs of different approaches towards open source development of a comprehensive modern user interface for VistA.
Jim Self
On 10 Sep, 03:08, "K.S. Bhaskar" <ks.bhas...@fnis.com> wrote:[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.
Bhaskar I have specialised in developing web interfaces for legacy applications for the last 15 years for most of InterSystems' largest customers and their largest applications worldwide. I would go so far as to say that there is nobody in the worldwide Cache/Mumps community with more expertise or experience in web/Ajax application development. I think I *might* have an inkling of what's involved.
You and I apparently started at this (MUMPS to Web development) about the same time, 1994. I remember your voice on comp.lang.mumps from almost that far back as the primary other voice advocating web oriented development. Often it seemed that few others seemed to understand either of us.
I find it difficult to understand the stumbling blocks, except as Fred Trotter noted, limitations of time and effort of learning (and forgetting and re-learning) unfamiliar technologies. I believe that M2Web has a much smaller barrier for MUMPS programmers to get started, but even there I continue to be amazed at how early in the process people stumble and silently stop.
is anyone even developing prototypes using EWD yet?
What happened with Steve Owen's development efforts?
What of the works-in-progress from the recent Pennsylvania meeting?
At the recent meeting in Sacramento, it seemed that everyone was interested and excited about EWD, but they were stumbling with installation issues and limited expertise.
I myself had not dealt with these issues for several years beyond helping others with M2Web.
-- --------------------------------------- Jim Self (http://www.vmth.ucdavis.edu/us/jaself
) M2Web (url in transition) ---------------------------------------
Jim Self
EWD deserves more than we have given it to date. I watched Rob at RMU last year and assumed that we would be seeing real examples of EWDification of VistA within six months. I expected some tools to emerge that would allow a experienced dilettante such as myself (cf. #1) to start to play with EWD-over-VistA.I would like to see even some of the in-progress stuff. I recall discussing here some of the ideas that had been worked on but I don't recall any links to download anything. I remember that Steve Owen seemed to be making great progress but again, if I remember correctly, no downloads.
At the recent meeting in Sacramento, interest was focused almost exclusively on web interfaces to VistA. People attending were particularly excited about EWD but hardly knew where to begin.
We did have access to a remote server with EWD that LD Landis setup and there was an attempt to demonstrate development and operation of a basic application with login.
I ended up giving some impromptu talks on the basics of HTML and HTTP and how those are supported in M2Web. I was surprised at the interest and apparent need for these low-level layers of web applications.
My major accomplishment of the weekend was getting Ubuntu and Astronaut installed on my MacBook and M2Web working with it. This was my first attempt to connect with anything M or VistA since I retired from UC Davis.
This is a huge consideration. It seems that everyone's expertise and time is already stretched to maximum.
So I do understand Rob's frustration, but I don't understand exactly where we've failed. Unless it is that no one on the VistA side has invested the time needed to be the hero in this arena.
I think it may be an indication of just how thin our community is spread. We are trying to get our hooks into this mountain of code that is VistA and it is easier to get lost in some crack or crevice of the legacy code than to dig into something so different.
rtweed
enablement of your web applications for you, I really struggle to
understand how much more help you all expect me to provide for free
with respect to getting to grips with EWD, and why you all seem to
find it so difficult to get going with it. I have gone out of my way
to provide copious amounts of clear information on how to install,
configure and use EWD:
- the EWD Virtual Appliance provides a fully working reference
implementation with copious configuration information.
- the EWD Virtual Appliance includes a comprehensive tutorial,
complete with worked examples that will quickly show you exactly how
to get started with EWD and understand its concepts
- our web site provides detailed instructions on how to install and
configure EWD on GT.M systems
- our web site provides an entire section with numerous worked and
working examples of EWD techniques
- I have set up a Google Group for EWD users (http://
groups.google.co.uk/group/enterprise-web-developer-community) which,
if you search it, will provide answers to most newbie questions and
contains numerous threads where I've provided detailed notes on all
manner of aspects of using EWD.
- I provided training at the meeting in Pittsburgh which I believe was
recorded on video by Chris Richardson.
BTW, all the collateral I've created was done in my spare time,
weekends and vacations (and I still had time to create M/DB, M/DB:X,
learnt Python and created a set of working Python libraries, ExtJS,
YUI, Dojo and other custom tag libraries which in turn involved
studying and learning YUI, ExtJS and Dojo in great detail), so I'm
sorry but the hand-wringing excuses about how little time you all have
wear very thin with me.
For those who don't know, our web site is at www.mgateway.com. Can I
suggest some of you start RTFMs?
fred trotter
Your appliances are toys to people like me. I need to have a reasonable assumption that I am on "the path" as far as VistA functionality goes. Your appliance is probably an impressive engineering feat, but it is off "the path".
Your appliance probably does not work with the various improved versions of CPRS. It probably does not work with a graphic scheduler.
In fact while your appliance is great if my -only- goal was to experiment with EWD, it is useless if I want to experiment with EWD in the context of an otherwise reliable instance of VistA. I cannot use your appliance as a starting point for collaboration. Why?
- The systems are different - I cannot easily parse what is in and what is not in your appliance. Are you using dependencies that I do not know of? I cannot use your appliance as a real VistA server, which means that I must study the differences between your -entire system- and my -entire system-
- The VistA installs are different - there are about a thousand minor, unimportant decisions that you have made to get your appliance to work. There is no simple way for me to know what you decided on those decisions. I am not smart enough to look at an error and go "Oh, well we clearly have a different Box - Volume pair setting" I have no idea what that means and an error of that nature will stop a competent web developer like myself dead in my tracks.
- We could isolate VistA from the system using standard system packaging tools like rpm and deb. By doing that, we use the capacity of rpms and debs to define exactly what other software must be installed in order for your VistA stuff to work. This way we have a formal, exact, well understood and almost universally adopted method for abstracting system requirements. Using rpm and deb packages we can make good assumptions that systems are "close enough" that we do not need to be concerned with any other differences.
- We could create a standard way of installing VistA which the rpm and deb would implement, which would enable us to isolate and quantify exactly how a series of arbitrary VistA configuration decisions have been handled. This way we can not only rely on the fact that the rpms will install identically, we can know that we can understand exactly what decisions were made, and why. We can assume that if I am trying to get EWD to work on the latest rpm, and you are using the same rpm, that the differences between are results are the result of how we configured EWD, rather than one of -thousands- of other decisions that you have to make when installing VistA.
I am thrilled that you are making these points. The one thing you have not done is to get EWD working with Astronaut (not a criticsm, I know you have been working with people to get that going, it just has not happened yet). I predict that after EWD works with Astronaut and/or OpenVistA, development using EWD will accelerate probably ten-fold.
I hope and pray that if this does in fact happen that the WorldVistA leadership will recognize that this is an -instance- of a -pattern- and that any recommendation to install VistA using either instructions or appliance images -subtancially- hampers development.
There is a scientific component to FOSS. I have a theory which generates a prediction in advance. If that prediction comes to pass (i.e. EWD development accelerates by people other than me and Ignacio, after being integrated with Astronaut or OpenVistA), then the WorldVistA leadership needs to seriously question its current positions.
Lets see what happens.
-FT
rtweed
> Your appliance probably does not work with the various improved versions of
> CPRS. It probably does not work with a graphic scheduler.
> In fact while your appliance is great if my -only- goal was to experiment
> with EWD, it is useless if I want to experiment with EWD in the context of
> an otherwise reliable instance of VistA. I cannot use your appliance as a
> starting point for collaboration. Why?
>
> I cannot use your appliance as a real VistA server, which means that I must
> study the differences between your -entire system- and my -entire system-
into the EWD Virtual Appliance and got it all working pretty easily.
Is Steve around? Would he care to comment on this?
>The one thing you have not done is to get EWD working with Astronaut
thing for themselves.
Nancy Anthracite
than you have. Please be patient with us. We appreciate what you have done
and would like to use it, but we are pulled in many directions. For the most
part, we, too, are volunteers. Please do not take these posts as being
critical of you or what you have contributed in any way.
Nancy Anthracite
Steve O
Still here and still developing with EWD in the day job (VA). We have
used EWD as part of a password/email authentication/new user
notification system that is backended by VistA on Cache/VMS. I
recently replaced a manual fax/scan and data entry process with
fillable pdf webpage that EWD processes into VistA. The VistA/Cache
database is in D.C., the Web Server in Florida and the clients are all
over the US. That same VistA database currently uses a Delphi/RPC
Broker thick client for the main interface and I'll be replacing that
as well with an EWD web based client. We also hope to get funded by
the VA Innovations group for an additional EWD based data registry
project.
It's easy to develop with EWD on a VistA Cache system. I do
everything on my laptop. WAMP server, Cache, and a VistA development
CACHE.DAT. Compile with EWD, drop the pages on the webserver, move
routines to the production system and I'm done.
Ignacio's Astronaut installer has been a great step to making
development as easy on GT.M and Linux. What I don't get is why 4k vs
32k thing is the issue blocking EWD from being implemented with
Astronaut. In fact, I've seen several folks mention that it would be
simple to do. Ok, I don't know GT.M that well, so for me it would
not be simple and I don't have the time to pursue it so I will
continue to develop with EWD and Cache. If someone would post those
simple instructions step, by step, I'd be happy to give it a try on
one of my Astronaut installations. Sorry, I don't have time to read
the manual on this one.
This is all a long way of saying I've put development with WorldVistA
and EWD on hold till the development environment catches up. Like
most of the folks who work with WorldVistA development I only have a
limited amount of time I can devote. Astronaut is the biggest step
forward for development I've seen with this group. Drop a working EWD
into that mix and you've got dyn-o-mite
JohnLeo Zimmer
It is not Rob Tweed's role to make <his> tool set work with <our> VistA.
EWD (with M/DB) as far as I have seen, is a mature technology that is making its way through the world, thank you. Tweed has been doing just fine without any help from Hardhats, WorldVista, Medsphere or any of our community. After he took the step of releasing a mature product under an open license, I am not going to criticize Rob for not staying up late trying to do our work. I don't criticize Bhaskar for not producing a PIP/VistA interface for me. I don't complain that Kevin has not switched away from Delphi for his CPRS work. Or Fred for not giving us an integrated billing package. We each choose his/her own itch. (Watch for a new version of XUSHSH soon.)
Personally, I have not made the committment to sit down with EWD (the appliance is running on this machine right now) and work through the learning curve necessary to move it into our enviroment. Personally I am hopeful that Jim Self will be more up to the task anyway. But that depends on where Jim's itch takes him. And it looks like Steve O is on the job.
Those who attended the RMU technical meeting know full well the contribution that Rob Tweed made to this community by 1.) releasing his code to open source, 2.) crossing the pond to attend that meeting, 3.) applying his impressive skills to demonstrating EWD's potential in support of a web interface to all of VistA. It is not for <any> of us to be telling him what step 4.), 5.), and 6.) needs to be.
Sincerely,
JL.Z
Steve O
Yup, a year, maybe two, dumped everything from a WorldVistA GT.M
installation into your appliance and it worked fine.
Now, since Rob has been kind enough to donate his time and a whole LOT
of code to the effort, how bout a GT.M expert tell us how to get past
the 4k/32k thing-a-ma-jig (like I said, I'm not a GT.M expert) and
make it work with Ignacio's most excellent installer. People keep
saying it's easy, so someone please show me how. Hell, I'll even ante
up a bounty of 100 bucks for the best working solution!
K.S. Bhaskar
Give me a list of the global variables in the EWD database, and in about
5 minutes I'll create you a set of commands you can use to edit your EWD
global directory to map the EWD and VistA globals into one logical M
namespace. I can optionally also tell you how to edit your VistA global
directory to map the EWD globals.
This assumes that the EWD and VistA global variable names don't overlap.
One cautionary note: EWD currently runs as root. I have not had the
time to take it apart figure out why it is set up that way and put it
back together. As a matter of policy, I don't run things as root unless
there is a specific requirement to do so. To me, this is the issue, not
mapping global variables - it takes longer to walk to the receptionist's
desk and get a box of paper clips than to modify the global directory
and map the globals.
Regards
GT.M - Rock solid. Lightning fast.
Nancy Anthracite
Nancy Anthracite
K.S. Bhaskar
directory (since he does not use GT.M), should I be mortified that there
are so many Hardhatters supposedly putting GT.M into production (and
without support at that!) who are not familiar with that most basic
aspect of database configuration - mapping global variables to files?
GT.M - Rock solid. Lightning fast.
On 09/11/2009 10:11 AM, Nancy Anthracite wrote:
>
> If you are Bhaskar ....
[KSB] <...snip...>
Steve Owen
Excellent Bhaskar! I will get the details together this evening and post back to the list. Contact me off list for the bounty.
On Fri 11/09/09 9:52 AM , "K.S. Bhaskar" ks.bh...@fnis.com sent:
Steve --
Give me a list of the global variables in the EWD database, and in about
5 minutes I'll create you a set of commands you can use to edit your EWD
global directory to map the EWD and VistA globals into one logical M
namespace. I can optionally also tell you how to edit your VistA global
directory to map the EWD globals.
This assumes that the EWD and VistA global variable names don't overlap.
One cautionary note: EWD currently runs as root. I have not had the
time to take it apart figure out why it is set up that way and put it
back together. As a matter of policy, I don't run things as root unless
there is a specific requirement to do so. To me, this is the issue, not
mapping global variables - it takes longer to walk to the receptionist's
desk and get a box of paper clips than to modify the global directory
and map the globals.
Regards
-- Bhaskar
GT.M - Rock solid. Lightning fast.
Steve Owen
A Bhaskar clone? : )
On Fri 11/09/09 10:11 AM , Nancy Anthracite nanth...@earthlink.net sent:
If you are Bhaskar ....
On Friday 11 September 2009, K.S. Bhaskar wrote:
--
Nancy Anthracite
K.S. Bhaskar
If you post this evening, it will likely be next week before I can
respond. I'm off camping this weekend with boy scouts.
Regards
-- Bhaskar
GT.M - Rock solid. Lightning fast.
On 09/11/2009 10:19 AM, Steve Owen wrote:
>
> Excellent Bhaskar! I will get the details together this evening and post
> back to the list. Contact me off list for the bounty.
_____________
Steve O
the zip code of your local council (BSA) I'll pass that bounty off to
them. Use to be a scout myself....
Sam Habiel
Rob Tweed posted all the globals in explicit detail:
http://groups.google.com/group/ewd-and-vista/msg/449d798afb73f0ca?hl=en
For that matter, Bhaskar posted the instructions to map globals to
databases in the same thread.
Sam
K.S. Bhaskar
it. Sorry and thanks.
Steve, I'll work with you offline to get VistA and EWD connected.
If anyone doesn't know how to do map VistA and EWD to the same M global
variable name space after reading the post, please ask on Hardhats.
Regards
-- Bhaskar
GT.M - Rock solid. Lightning fast.
Steve Owen
Kin Ho
Hi Jim,
I have a link to the DTM CoStar at: http://kin.mscostar.com/ms/mscentry.htm
I don’t know if it would be any good in relation to WorldVistA.
I explored the WorldVista some months back. It is interest, but too big for a single person.
The installation instructions are clear enough to guide a user setup a system.
The stuff that follows is just too much for self exploring, I think. The user access code, the provider keys, institution and ward setup, etc.
Wonder how much time Nancy and the gang have put in for the WorldVista project!
Regards,
Kin
From:
hard...@googlegroups.com [mailto:hard...@googlegroups.com] On Behalf Of Jim
Self
Sent: September-10-09 1:45 PM
To: hard...@googlegroups.com
Subject: [Hardhats] Re: Astronaut WorldVistA 0.7.3 is out, ...
Kin Ho,
Good to hear from you again. If you still have MUMPS based CoStar, I would be
interested in downloading - especially if adapted to GT.M - and exploring
possibilities for accessing it with M2Web and EWD.
I looked for you and CoStar on the web a few years back but the old links were
dead.
Jim
Jim Self
What is the status of CoSTAR now? What sort of updates and upgrades has it received since the 80's? What relevance does it have now to the needs of clinicians, patients, and medical information systems in general? If it is still relevant, what sort of development does it need?
Jim.
-- --------------------------------------- Jim Self (http://www.vmth.ucdavis.edu/us/jaself
) M2Web (url) ---------------------------------------
Jim Self
Hi Jim! Still here and still developing with EWD in the day job (VA).
Ignacio's Astronaut installer has been a great step to making development as easy on GT.M and Linux. What I don't get is why 4k vs 32k thing is the issue blocking EWD from being implemented with Astronaut.
That would be a matter of a few minutes for anyone who remembers the appropriate commands and the commands to review the global mapping in /opt/worldvista/EHR/g/mumps.dat Unfortunately, I don't and I don't have access to the resources I previously used to refresh my memory.
I am not yet convinced that EWD actually needs to store 32KB node values. That is actually a small and arbitrary limit frequently exceeded by the strings encountered in working with web applications. There must be provision(s) in the code for when this length is exceeded. I found and fixed an instance where maxlen=15000.
Jim Self
It is not the only issue, just the first one noted. A simple fix for that might be simply to create a new file /opt/worldvista/EHR/g/ewd.dat configured for 32KB. The Astronaut installed globals directory /opt/worldvista/EHR/g/mumps.dat seems to be expecting it.
The installed globals directory is /opt/worldvista/EHR/g/mumps.gld.
The one installed data file is /opt/worldvista/EHR/g/mumps.dat
Jim Self
The globals ^zewd and ^%zewd already exist in mumps.dat
Please refresh our memories on the current location of the relevant documentation and the commands to review the mappings.
What is the effect of repeating commands in your script that have already completed?
K.S. Bhaskar wrote:
So he did, and so did I, as you noted, Sam. I had forgotten all about it. Sorry and thanks. Steve, I'll work with you offline to get VistA and EWD connected. If anyone doesn't know how to do map VistA and EWD to the same M global variable name space after reading the post, please ask on Hardhats. Regards -- Bhaskar GT.M - Rock solid. Lightning fast. On 09/11/2009 12:45 PM, Sam Habiel wrote:Steve, Bhaskar, et al., Rob Tweed posted all the globals in explicit detail: http://groups.google.com/group/ewd-and-vista/msg/449d798afb73f0ca?hl=en For that matter, Bhaskar posted the instructions to map globals to databases in the same thread.
r...@rcresearch.us
problem with the way that the patients were being stored (10000 per
global) and the way that they have for the storing of time and date was a
major issue (basically, their scheme ran out as the calendar advanced.
Now there was a variant, CONSTAR that might have addressed these issues,
but I have lost contact with them as well.
> Thanks Kin, I will take a look at it. There was a time when I was quite
> familiar with it.
>
> What is the status of CoSTAR now? What sort of updates and upgrades has
> it received since the 80's? What relevance does it have now to the needs
> of clinicians, patients, and medical information systems in general? If
> it is still relevant, what sort of development does it need?
> Jim.
>
> Kin Ho wrote:
>>
>>
>>
>> Hi Jim,
>>
>>
>>
>> I have a link to the DTM CoStar at:
>> http://kin.mscostar.com/ms/mscentry.htm
>>
>> I don't know if it would be any good in relation to WorldVistA.
>>
>>
>>
>> I explored the WorldVista some months back. It is interest, but too
>> big for a single person.
>>
>> The installation instructions are clear enough to guide a user setup a
>> system.
>>
>> The stuff that follows is just too much for self exploring, I think.
>> The user access code, the provider keys, institution and ward setup,
>> etc.
>>
>>
>>
>> Wonder how much time Nancy and the gang have put in for the WorldVista
>> project!
>>
>>
>>
>> Regards,
>>
>> Kin
>>
>>
>>
>>
>>
>> *On Behalf Of *Jim Self
>> *Sent:* September-10-09 1:45 PM
>> *To:* hard...@googlegroups.com
>> *Subject:* [Hardhats] Re: Astronaut WorldVistA 0.7.3 is out, ...
Steven McPhelan
system. If that all one really wants, then there are other more
appropriate software to do that. VistA is a complex electronic
medical record system designed to run on enterprise quality database
management systems. Most end users do not want to be serious DBMS
managers. They just want to use the software to get their job done
which is providing medical care to their patients.
Steve
You can satisfy a man's hunger by giving him a fish. You can feed him
for his entire life by teaching him how to fish.
Richard Maley
I have spent the last 25 years using, designing and tuning almost every name brand database on the market.
I am an award winning developer Application of the Year .
I am not intimidated by the complexity and importance of this information and system.
I am mortified (to use your term) by the undue complexity.
IT SHOULD BE SIMPLER. IT CAN BE SIMPLER. THE FACT THAT IT IS NOT SIMPLER IS BAD DESIGN.
Dick Maley
Steven McPhelan
care to patient. My statement referenced most clinicians. They are
not developers. Most do not care what the back end database is. They
just want a software product they can use to get their job done more
efficiently. I believe most clinicians do not care about the backend
database structure or providing proper maintenance or upkeep.
Richard Maley
They are most interested in ease of use.
Dick
Kin Ho
I hope CoStar doesn't become a distraction.
The link to the DTM CoStar Mumps code mentioned in last e-mail doesn't differ much to the public
domain version in the 80's. It was modified for the Multiple Sclerosis clinic in Vancouver.
It has some modification specific to the DTM 'screen addressing.' I tried to turn the 'roll and
Scroll' to GUI and WEB interface using Visual Basic and Weblink at different time.
The project was terminated since 2005 due funding shortage. I got involved again recently
only because the replacement system cannot provided the data/information COSTAR used to
be able to furnish :-).
CoStar actually can handle thousand of patients (one site in Vancouver has over 200,000.)
The global glows automatically from AA to AB and so on. Date can be tricky since it was stored to three characters
at certain algorithm. It behaves well up-to now, but yes it can be problematic soon.
I think CONSTAR is based at the neighbouring province in Canada supporting commercial CoStar.
I do believe Vista is more worthwhile to explore for sure.
Kin
-----Original Message-----
From: hard...@googlegroups.com [mailto:hard...@googlegroups.com] On Behalf Of r...@rcresearch.us
Sent: September-12-09 8:11 AM
To: hard...@googlegroups.com
Subject: [Hardhats] Re: Astronaut WorldVistA 0.7.3 is out, ...
From my exposure to COSTAR, (admittedly decades ago) there was a major
problem with the way that the patients were being stored (10000 per
global) and the way that they have for the storing of time and date was a
major issue (basically, their scheme ran out as the calendar advanced.
Now there was a variant, CONSTAR that might have addressed these issues,
but I have lost contact with them as well.
> Thanks Kin, I will take a look at it. There was a time when I was quite
> familiar with it.
>
> What is the status of CoSTAR now? What sort of updates and upgrades has
> it received since the 80's? What relevance does it have now to the needs
> of clinicians, patients, and medical information systems in general? If
> it is still relevant, what sort of development does it need?
> Jim.
>
---~----~----~------~----~------~--~---
K.S. Bhaskar
messages on repeats (e.g., the second time you add the same thing, you
will be appropriately informed.
Regards
-- Bhaskar
GT.M - Rock solid. Lightning fast.
On 09/12/2009 05:01 AM, Jim Self wrote:
> It appears that Ignacio was also involved in that discussion and that he
> partially completed the instructions given. File
> /opt/worldvista/EHR/g/ewd.dat does not exist, but globals directory
> /opt/worldvista/EHR/g/mumps.gld seems to be expecting it.
>
> The globals ^zewd and ^%zewd already exist in mumps.dat
>
> Please refresh our memories on the current location of the relevant
> documentation and the commands to review the mappings.
>
> What is the effect of repeating commands in your script that have
> already completed?
_____________