VistApedia - User contributions [en]

Basic GTM Journaling

2011-04-16T12:23:02Z

Bhaskar:

Here are the most basic instructions to turn on and use journaling. I suggest you do this for any database files that are not throw-away.

-- Turn on before image journaling:

<code>
$gtm_dist/mupip set -journal="enable,on,before" -file mumps.dat
</code>

-- Recover a database file using the journal:

<code>
$gtm_dist/mupip journal -recover -backward mumps.mjl
</code>

-- Create a new journal file (the old journal file has a name of the form mumps.mjl_yyyydddhhmmss where ddd is the day of the year, e.g., today, June 24, 2009, is day 175):

<code>
$gtm_dist/mupip set -journal="on,before" -file mumps.dat
</code>

This assumes that the database file is mumps.dat and the journal file is mumps.mjl. GT.M doesn't restrict the name, and databases can be multiple regions. But these three commands are the most basic. Please use them so that you don't need a rundown to recover your database after a system crash.

-- Backup database (creates a new journal file; substitute backup directory for /tmp/ in the following):

<code>
$gtm_dist/mupip backup "*" /tmp/
</code>

You should periodically review journal file usage and archive/delete previous generation journal files.

If you need anything more sophisticated, please go through the self-paced exercises in the [http://sourceforge.net/projects/fis-gtm/files/GT.M%20Acculturation%20Workshop/ GT.M Acculturation Workshop].

Migrating a VistA/GT.M installation from one platform to another

2007-07-30T19:29:16Z

Bhaskar:

These are instructions for copying a GT.M SemiVivA installation from one platform to another. For this discussion, the platforms are assumed to be of different endian-ness, e.g., x86 GNU/Linux and Sun SPARC Solaris).

== Notes ==
# Existing SemiVivA scripts use the bash shell, and assume that it is located at /bin/bash. Modify the location if bash is located elsewhere. Edit the scripts as needed to use other shells.
# The GT.M version in these examples is V5.2-001.
# The steps to change the endian-ness of database files, and to create new global directories is not needed if the source and target platforms have the same endian-ness.
# The VistA environments to be copied must be identified, along with the hierarchical structure (see [[Software Development (WG1) Version Control (T3)]]). In this example, the structure is assumed to be:
#* /usr/local/WorldVistAEHRvTEST20070616
#** /var/WorldVistAEHR
#** /home/vista/myWorldVistAEHR

== Steps ==

* Obtain and install GT.M for the new platform in a sub-directory of /usr/local, e.g., in /usr/local/gtm_V5.2-001.

* Copy the identified directories, including subdirectories from the originating machine to the target machine. Object files (.o) should not be copied, and if they are, they should be deleted e.g., for the top level directory of each working environment (as root for the top level :
cd <directory>
find . -type d -name o -exec chmod u+w {} \;
find . -name \*.o -exec rm -f {} \;
* Change the endian-ness of the database (see [http://www.fidelityinfoservices.com/user_documentation/targets/GTM_Database_Endian_Conversion.html Technical Bulletin: GT.M Database Endian Conversion - UNIX] for more information) in the top level release environment, from which other environments are derived (in this example, /usr/local/WorldVistAEHRvTEST20070616). As root:
cd /usr/local/WorldVistAEHRvTEST20070616/gtm_V5.2-001
chmod u+w g
cd g
gzip -d mumps.dat.gz
source /usr/local/gtm_V5.2-001/gtmprofile
mupip endiancvt mumps.dat
gzip mumps.dat
cd ..
chmod a-w g
* Change the endian-ness of the database in each working environment (/var/WorldVistAEHR and /home/vista/myWorldVistAEHR in this example). As the normal user for each working environment:
source /usr/local/gtm/gtm_V5.2-001/gtmprofile
cd /var/WorldVistAEHR/gtm_V5.2-001/g
mupip endiacvt mumps.dat
:and
source /usr/local/gtm/gtm_V5.2-001/gtmprofile
cd /home/vista/myWorldVistAEHR/gtm_V5.2-001/g
mupip endiacvt mumps.dat
* Replace the global directory in the top level release environment. As root:
source /usr/local/gtm_V5.2-001/gtmprofile
cd /usr/local/WorldVistAEHRvTEST20070616/gtm_V5.2-001
chmod u+w g
cd g
rm mumps.gld
mumps -run ^GDE
change -segment DEFAULT -block=4096 -alloc=75000 -ext=2000 -glob=2048 -file=$vista_home/$gtmver/g/mumps.dat
change -region DEFAULT -rec=4080 -key=255 -std
exit
cd ..
chmod -R a-w g
* Copy this global directory file to each working environment. As the normal user for each environment:
rm -f /var/WorldVistAEHR/gtm_V5.2-001/g/mumps.gld
cp /usr/local/WorldVistAEHRvTEST20070616/gtm_V5.2-001/g/mumps.gld /var/WorldVistAEHR/gtm_V5.2-001/g/
:and
rm -f /home/vista/myWorldVistAEHR/gtm_V5.2-001/g/mumps.gld
cp /usr/local/WorldVistAEHRvTEST20070616/gtm_V5.2-001/g/mumps.gld /home/vista/myWorldVistAEHR/gtm_V5.2-001/g/
* Recompile the object files in the top level release environment (ignore compilation errors; remember that some directories may not be empty this script takes care of the general case where there may be files in the different source directories). As root:
source /usr/local/gtm_V5.2-001/gtmprofile
cd /usr/local/WorldVistAEHRvTEST20070616/gtm_V5.2-001
chmod u+w o
cd o
find ../../r -type f -name \*.m -print -exec mumps {} \;
find ../../p -type f -name \*.m -print -exec mumps {} \;
find ../r -type f -name \*.m -print -exec mumps {} \;
find ../p -type f -name \*.m -print -exec mumps {} \;
cd ..
chmod -R a-w o
cd add-ons
chmod u+w o
cd o
mumps ../../../add-ons/*/{r,p}/*.m
mumps ../*/{r,p}/*.m
cd ..
chmod -R a-w o
* Object files in the working environments will be automatically recompiled as needed. In the event you wish to recompile them, e.g., to not see compilation errors when using VistA, do the following as the normal user in each environment (ignore compilation errors and complaints about files not found):
source /usr/local/gtm/gtm_V5.2-001/gtmprofile
cd /var/WorldVistAEHR/gtm_V5.2-001/o
mumps ../../{r,p}/*.m
mumps ../{r,p}/*.m
cd ../add-ons/o
mumps ../../../add-ons/{r,p}/*.m
mumps ../*/{r,p}/*.m
:and
source /usr/local/gtm/gtm_V5.2-001/gtmprofile
cd /home/vista/myWorldVistAEHR/gtm_V5.2-001/o
mumps ../../{r,p}/*.m
mumps ../{r,p}/*.m
cd ../add-ons/o
mumps ../../../add-ons/{r,p}/*.m
mumps ../*/{r,p}/*.m
* Create new journal files in each working environment. As the normal user for each environment:
source /usr/local/gtm/gtm_V5.2-001/gtmprofile
cd /var/WorldVistAEHR/gtm_V5.2-001/g
mupip set -journal="enable,on,before" -file mumps.dat
rm mumps.mjl_*
:and
source /usr/local/gtm/gtm_V5.2-001/gtmprofile
cd /home/vista//myWorldVistAEHR/gtm_V5.2-001/g
mupip set -journal="enable,on,before" -file mumps.dat
rm mumps.mjl_*
* Verify each environment. As the normal user for each environment:
/var/WorldVistAEHR/gtm_V5.2-001/run
:and
/home/myvista/myWorldVistAEHR/gtm_V5.2-001/run

Migrating a VistA/GT.M installation from one platform to another

2007-07-26T20:43:54Z

Bhaskar:

These are instructions for copying a GT.M SemiVivA installation from one platform to another. For this discussion, the platforms are assumed to be of different endian-ness, e.g., x86 GNU/Linux and Sun SPARC Solaris).

== Notes ==
# Existing SemiVivA scripts use the bash shell, and assume that it is located at /bin/bash. Modify the location if bash is located elsewhere. Edit the scripts as needed to use other shells.
# It is assumed that the GT.M version is the same, V5.2-001. In practice, they need not be the same, but must use the same database format. If the versions are different, rename the V5.2-001 subdirectory of each VistA environment, and change the gtm symbolic link to point to the actual GT.M installation directory.
# The VistA environments to be copied must be identified, along with the hierarchical structure (see [[Software Development (WG1) Version Control (T3)]]). In this example, the structure is assumed to be:
#* /usr/local/WorldVistAEHRvTEST20070616
#** /var/WorldVistAEHR
#** /home/vista/myWorldVistAEHR

== Steps ==

* Obtain and install GT.M for the new platform in a sub-directory of /usr/local, e.g., in /usr/local/gtm_V5.2-001.

* Copy the identified directories, including subdirectories from the originating machine to the target machine. Object files (.o) should not be copied, and if they are, they should be deleted e.g., for the top level directory of each working environment (as root for the top level :
cd <directory>
find . -type d -name o -exec chmod u+w {} \;
find . -name \*.o -exec rm -f {} \;
* Change the endian-ness of the database (see [http://www.fidelityinfoservices.com/user_documentation/targets/GTM_Database_Endian_Conversion.html Technical Bulletin: GT.M Database Endian Conversion - UNIX] for more information) in the top level release environment, from which other environments are derived (in this example, /usr/local/WorldVistAEHRvTEST20070616). As root:
cd /usr/local/WorldVistAEHRvTEST20070616/gtm_V5.2-001
chmod u+w g
cd g
gzip -d mumps.dat.gz
source /usr/local/gtm_V5.2-001/gtmprofile
mupip endiancvt mumps.dat
gzip mumps.dat
cd ..
chmod a-w g
* Change the endian-ness of the database in each working environment (/var/WorldVistAEHR and /home/vista/myWorldVistAEHR in this example). As the normal user for each working environment:
source /usr/local/gtm/gtm_V5.2-001/gtmprofile
cd /var/WorldVistAEHR/gtm_V5.2-001/g
mupip endiacvt mumps.dat
:and
source /usr/local/gtm/gtm_V5.2-001/gtmprofile
cd /home/vista/myWorldVistAEHR/gtm_V5.2-001/g
mupip endiacvt mumps.dat
* Recompile the object files in the top level release environment (ignore compilation errors; remember that some directories may not be empty this script takes care of the general case where there may be files in the different source directories). As root:
source /usr/local/gtm_V5.2-001/gtmprofile
cd /usr/local/WorldVistAEHRvTEST20070616/gtm_V5.2-001
chmod u+w o
cd o
find ../../r -type f -name \*.m -print -exec mumps {} \;
find ../../p -type f -name \*.m -print -exec mumps {} \;
find ../r -type f -name \*.m -print -exec mumps {} \;
find ../p -type f -name \*.m -print -exec mumps {} \;
cd ..
chmod a-w o
cd add-ons
chmod u+w o
mumps ../../../add-ons/*/{r,p}/*.m
mumps ../*/{r,p}/*.m
cd ..
chmod a-w o
* Object files in the working environments will be automatically recompiled as needed. In the event you wish to recompile them, e.g., to not see compilation errors when using VistA, do the following as the normal user in each environment (ignore compilation errors and complaints about files not found):
source /usr/local/gtm/gtm_V5.2-001/gtmprofile
cd /var/WorldVistAEHR/gtm_V5.2-001/o
mumps ../../{r,p}/*.m
mumps ../{r,p}/*.m
cd ../add-ons/o
mumps ../../../add-ons/{r,p}/*.m
mumps ../*/{r,p}/*.m
:and
source /usr/local/gtm/gtm_V5.2-001/gtmprofile
cd /home/vista/myWorldVistAEHR/gtm_V5.2-001/o
mumps ../../{r,p}/*.m
mumps ../{r,p}/*.m
cd ../add-ons/o
mumps ../../../add-ons/{r,p}/*.m
mumps ../*/{r,p}/*.m
* Create new journal files in each working environment. As the normal user for each environment:
source /usr/local/gtm/gtm_V5.2-001/gtmprofile
cd /var/WorldVistAEHR/gtm_V5.2-001/g
mupip set -journal="enable,on,before" -file mumps.dat
:and
source /usr/local/gtm/gtm_V5.2-001/gtmprofile
cd /home/vista//myWorldVistAEHR/gtm_V5.2-001/g
mupip set -journal="enable,on,before" -file mumps.dat
* Verify each environment. As the normal user for each environment:
/var/WorldVistAEHR/gtm_V5.2-001/run
:and
/home/myvista/myWorldVistAEHR/gtm_V5.2-001/run

Migrating a VistA/GT.M installation from one platform to another

2007-07-26T17:48:48Z

Bhaskar:

These are instructions for copying a GT.M SemiVivA installation from one platform to another. For this discussion, the platforms are assumed to be of different endian-ness, e.g., x86 GNU/Linux and Sun SPARC Solaris).

== Notes ==
# Existing SemiVivA scripts use the bash shell, and assume that it is located at /bin/bash. Modify the location if bash is located elsewhere. Edit the scripts as needed to use other shells.
# It is assumed that the GT.M version is the same, V5.2-001. In practice, they need not be the same, but must use the same database format. If the versions are different, rename the V5.2-001 subdirectory of each VistA environment, and change the gtm symbolic link to point to the actual GT.M installation directory.
# The VistA environments to be copied must be identified, along with the hierarchical structure (see [[Software Development (WG1) Version Control (T3)]]). In this example, the structure is assumed to be:
#* /usr/local/WorldVistAEHRvTEST20070616
#** /var/WorldVistAEHR
#** /home/vista/myWorldVistAEHR

== Steps ==

* Obtain and install GT.M for the new platform in a sub-directory of /usr/local, e.g., in /usr/local/gtm_V5.2-001.

* Copy the identified directories, including subdirectories from the originating machine to the target machine. Object files (.o) should not be copied, and if they are, they should be deleted e.g., for the top level directory of each working environment (as root for the top level :
cd <directory>
find . -type d -name o -exec chmod -v {} \;
find . -name \*.o -exec rm -rv {} \;
* Change the endian-ness of the database (see [http://www.fidelityinfoservices.com/user_documentation/targets/GTM_Database_Endian_Conversion.html Technical Bulletin: GT.M Database Endian Conversion - UNIX] for more information) in the top level release environment, from which other environments are derived (in this example, /usr/local/WorldVistAEHRvTEST20070616). As root:
cd /usr/local/WorldVistAEHRvTEST20070616/gtm_V5.2-001
chmod u+w g
cd g
gzip -d mumps.dat.gz
source /usr/local/gtm_V5.2-001/gtmprofile
mupip endiancvt mumps.dat
gzip mumps.dat
cd ..
chmod a-w g
* Change the endian-ness of the database in each working environment (/var/WorldVistAEHR and /home/vista/myWorldVistAEHR in this example). As the normal user for each working environment:
source /usr/local/gtm/gtm_V5.2-001/gtmprofile
cd /var/WorldVistAEHR/gtm_V5.2-001/g
mupip endiacvt mumps.dat
:and
source /usr/local/gtm/gtm_V5.2-001/gtmprofile
cd /home/vista/myWorldVistAEHR/gtm_V5.2-001/g
mupip endiacvt mumps.dat
* Recompile the object files in the top level release environment (ignore compilation errors; remember that some directories may not be empty this script takes care of the general case where there may be files in the different source directories). As root:
source /usr/local/gtm_V5.2-001/gtmprofile
cd /usr/local/WorldVistAEHRvTEST20070616/gtm_V5.2-001
chmod u+w o
cd o
find ../../r -type f -name \*.m -print -exec mumps {} \;
find ../../p -type f -name \*.m -print -exec mumps {} \;
find ../r -type f -name \*.m -print -exec mumps {} \;
find ../p -type f -name \*.m -print -exec mumps {} \;
cd ..
chmod a-w o
cd add-ons
chmod u+w o
mumps ../../../add-ons/*/{r,p}/*.m
mumps ../*/{r,p}/*.m
cd ..
chmod a-w o
* Object files in the working environments will be automatically recompiled as needed. In the event you wish to recompile them, e.g., to not see compilation errors when using VistA, do the following as the normal user in each environment (ignore compilation errors and complaints about files not found):
source /usr/local/gtm/gtm_V5.2-001/gtmprofile
cd /var/WorldVistAEHR/gtm_V5.2-001/o
mumps ../../{r,p}/*.m
mumps ../{r,p}/*.m
cd ../add-ons/o
mumps ../../../add-ons/{r,p}/*.m
mumps ../*/{r,p}/*.m
:and
source /usr/local/gtm/gtm_V5.2-001/gtmprofile
cd /home/vista/myWorldVistAEHR/gtm_V5.2-001/o
mumps ../../{r,p}/*.m
mumps ../{r,p}/*.m
cd ../add-ons/o
mumps ../../../add-ons/{r,p}/*.m
mumps ../*/{r,p}/*.m
* Create new journal files in each working environment. As the normal user for each environment:
source /usr/local/gtm/gtm_V5.2-001/gtmprofile
cd /var/WorldVistAEHR/gtm_V5.2-001/g
mupip set -journal="enable,on,before" -file mumps.dat
:and
source /usr/local/gtm/gtm_V5.2-001/gtmprofile
cd /home/vista//myWorldVistAEHR/gtm_V5.2-001/g
mupip set -journal="enable,on,before" -file mumps.dat
* Verify each environment. As the normal user for each environment:
/var/WorldVistAEHR/gtm_V5.2-001/run
:and
/home/myvista/myWorldVistAEHR/gtm_V5.2-001/run

Migrating a VistA/GT.M installation from one platform to another

2007-07-26T17:45:55Z

Bhaskar:

These are instructions for copying a GT.M SemiVivA installation from one platform to another. For this discussion, the platforms are assumed to be of different endian-ness, e.g., x86 GNU/Linux and Sun SPARC Solaris).

== Notes ==
# Existing SemiVivA scripts use the bash shell, and assume that it is located at /bin/bash. Modify the location if bash is located elsewhere. Edit the scripts as needed to use other shells.
# [http://xinetd.org xinetd] is assumed to control th
# It is assumed that the GT.M versions use the same database format.
# The VistA environments to be copied must be identified, along with the hierarchical structure (see [[Software Development (WG1) Version Control (T3)]]), e.g.
#* /usr/local/WorldVistAEHRvTEST20070616
#** /var/WorldVistAEHR
#** /home/vista/myWorldVistAEHR

== Steps ==

* Obtain and install GT.M for the new platform in a sub-directory of /usr/local, e.g., in /usr/local/gtm_V5.2-001.

* Copy the identified directories, including subdirectories from the originating machine to the target machine. Object files (.o) should not be copied, and if they are, they should be deleted e.g., for the top level directory of each working environment (as root for the top level :
cd <directory>
find . -type d -name o -exec chmod -v {} \;
find . -name \*.o -exec rm -rv {} \;
* Change the endian-ness of the database (see [http://www.fidelityinfoservices.com/user_documentation/targets/GTM_Database_Endian_Conversion.html Technical Bulletin: GT.M Database Endian Conversion - UNIX] for more information) in the top level release environment, from which other environments are derived (in this example, /usr/local/WorldVistAEHRvTEST20070616). As root:
cd /usr/local/WorldVistAEHRvTEST20070616/gtm_V5.2-001
chmod u+w g
cd g
gzip -d mumps.dat.gz
source /usr/local/gtm_V5.2-001/gtmprofile
mupip endiancvt mumps.dat
gzip mumps.dat
cd ..
chmod a-w g
* Change the endian-ness of the database in each working environment (/var/WorldVistAEHR and /home/vista/myWorldVistAEHR in this example). As the normal user for each working environment:
source /usr/local/gtm/gtm_V5.2-001/gtmprofile
cd /var/WorldVistAEHR/gtm_V5.2-001/g
mupip endiacvt mumps.dat
:and
source /usr/local/gtm/gtm_V5.2-001/gtmprofile
cd /home/vista/myWorldVistAEHR/gtm_V5.2-001/g
mupip endiacvt mumps.dat
* Recompile the object files in the top level release environment (ignore compilation errors; remember that some directories may not be empty this script takes care of the general case where there may be files in the different source directories). As root:
source /usr/local/gtm_V5.2-001/gtmprofile
cd /usr/local/WorldVistAEHRvTEST20070616/gtm_V5.2-001
chmod u+w o
cd o
find ../../r -type f -name \*.m -print -exec mumps {} \;
find ../../p -type f -name \*.m -print -exec mumps {} \;
find ../r -type f -name \*.m -print -exec mumps {} \;
find ../p -type f -name \*.m -print -exec mumps {} \;
cd ..
chmod a-w o
cd add-ons
chmod u+w o
mumps ../../../add-ons/*/{r,p}/*.m
mumps ../*/{r,p}/*.m
cd ..
chmod a-w o
* Object files in the working environments will be automatically recompiled as needed. In the event you wish to recompile them, e.g., to not see compilation errors when using VistA, do the following as the normal user in each environment (ignore compilation errors and complaints about files not found):
source /usr/local/gtm/gtm_V5.2-001/gtmprofile
cd /var/WorldVistAEHR/gtm_V5.2-001/o
mumps ../../{r,p}/*.m
mumps ../{r,p}/*.m
cd ../add-ons/o
mumps ../../../add-ons/{r,p}/*.m
mumps ../*/{r,p}/*.m
:and
source /usr/local/gtm/gtm_V5.2-001/gtmprofile
cd /home/vista/myWorldVistAEHR/gtm_V5.2-001/o
mumps ../../{r,p}/*.m
mumps ../{r,p}/*.m
cd ../add-ons/o
mumps ../../../add-ons/{r,p}/*.m
mumps ../*/{r,p}/*.m
* Create new journal files in each working environment. As the normal user for each environment:
source /usr/local/gtm/gtm_V5.2-001/gtmprofile
cd /var/WorldVistAEHR/gtm_V5.2-001/g
mupip set -journal="enable,on,before" -file mumps.dat
:and
source /usr/local/gtm/gtm_V5.2-001/gtmprofile
cd /home/vista//myWorldVistAEHR/gtm_V5.2-001/g
mupip set -journal="enable,on,before" -file mumps.dat
* Verify each environment. As the normal user for each environment:
/var/WorldVistAEHR/gtm_V5.2-001/run
:and
/home/myvista/myWorldVistAEHR/gtm_V5.2-001/run

Migrating a VistA/GT.M installation from one platform to another

2007-07-26T15:50:39Z

Bhaskar:

These are instructions for copying a GT.M SemiVivA installation from one platform to another. For this discussion, the platforms are assumed to be of different endian-ness, e.g., x86 GNU/Linux and Sun SPARC Solaris).

== Notes ==
# Existing SemiVivA scripts use the bash shell, and assume that it is located at /bin/bash. Modify the location if bash is located elsewhere. Edit the scripts as needed to use other shells.
# [http://xinetd.org xinetd] is assumed to control th
# It is assumed that the GT.M versions use the same database format.
# The VistA environments to be copied must be identified, along with the hierarchical structure (see [[Software Development (WG1) Version Control (T3)]]), e.g.
#* /usr/local/WorldVistAEHRvTEST20070616
#** /var/WorldVistAEHR
#** /home/vista/myWorldVistAEHR

== Steps ==

* Obtain and install GT.M for the new platform in a sub-directory of /usr/local, e.g., in /usr/local/gtm_V5.2-001.

* Copy the identified directories, including subdirectories from the originating machine to the target machine. Object files (.o) should not be copied, and if they are, they should be deleted e.g., for the top level directory of each working environment (as root for the top level :
cd <directory>
find . -type d -name o -exec chmod -v {} \;
find . -name \*.o -exec rm -rv {} \;
* Change the endian-ness of the database (see [http://www.fidelityinfoservices.com/user_documentation/targets/GTM_Database_Endian_Conversion.html Technical Bulletin: GT.M Database Endian Conversion - UNIX] for more information) in the top level release environment, from which other environments are derived (in this example, /usr/local/WorldVistAEHRvTEST20070616). As root:
cd /usr/local/WorldVistAEHRvTEST20070616/gtm_V5.2-001
chmod u+w g
cd g
gzip -d mumps.dat.gz
source /usr/local/gtm_V5.2-001/gtmprofile
mupip endiancvt mumps.dat
gzip mumps.dat
cd ..
chmod a-w g
* Change the endian-ness of the database in each working environment (/var/WorldVistAEHR and /home/vista/myWorldVistAEHR in this example). As the normal user for each working environment:
source /usr/local/gtm/gtm_V5.2-001/gtmprofile
cd /var/WorldVistAEHR/gtm_V5.2-001/g
mupip endiacvt mumps.dat
:and
source /usr/local/gtm/gtm_V5.2-001/gtmprofile
cd /home/vista/myWorldVistAEHR/gtm_V5.2-001/g
mupip endiacvt mumps.dat
* Recompile the object files in the top level release environment (ignore compilation errors; remember that some directories may not be empty this script takes care of the general case where there may be files in the different source directories). As root:
source /usr/local/gtm_V5.2-001/gtmprofile
cd /usr/local/WorldVistAEHRvTEST20070616/gtm_V5.2-001
chmod u+w o
cd o
find ../../r -type f -name \*.m -print -exec mumps {} \;
find ../../p -type f -name \*.m -print -exec mumps {} \;
find ../r -type f -name \*.m -print -exec mumps {} \;
find ../p -type f -name \*.m -print -exec mumps {} \;
cd ..
chmod a-w o
cd add-ons
chmod u+w o
mumps ../../../add-ons/*/{r,p}/*.m
mumps ../*/{r,p}/*.m
cd ..
chmod a-w o
* Object files in the working environments will be automatically recompiled as needed. In the event you wish to recompile them, e.g., to not see compilation errors when using VistA, do the following as the normal user in each environment (ignore compilation errors and complaints about files not found):
source /usr/local/gtm/gtm_V5.2-001/gtmprofile
cd /var/WorldVistAEHR/gtm_V5.2-001/o
mumps ../../{r,p}/*.m
mumps ../{r,p}/*.m
cd ../add-ons/o
mumps ../../../add-ons/{r,p}/*.m
mumps ../*/{r,p}/*.m
:and
source /usr/local/gtm/gtm_V5.2-001/gtmprofile
cd /home/vista/myWorldVistAEHR/gtm_V5.2-001/o
mumps ../../{r,p}/*.m
mumps ../{r,p}/*.m
cd ../add-ons/o
mumps ../../../add-ons/{r,p}/*.m
mumps ../*/{r,p}/*.m

Migrating a VistA/GT.M installation from one platform to another

2007-07-26T15:23:08Z

Bhaskar:

Migrating a VistA/GT.M installation from one platform to another

2007-07-26T14:32:02Z

Bhaskar:

Migrating a VistA/GT.M installation from one platform to another

2007-07-26T14:30:34Z

Bhaskar:

Main Page

2007-07-26T14:00:59Z

Bhaskar: /* Installation Guides */

This wiki covers questions regarding the VistA software, the various components of that software, and configuration and installation of the same. It incorporates information from many people. We have been repeatedly vandalized by people trying to advance their google page rank, hence this is now a closed community wiki.

To get access, contact David Whitten ( whitten at worldvista.org ) through an e-mail,
or phone 713 870 3834 to get an account.
Please send a contact telephone number with your e-mail, and/or
have an e-mail address ready when you call. (I need both.)
Please decide on your preferred User name.
We have provided a [[User Status|page]] for new users and their current status.
Thank you.

__TOC__

Configuration is the process of changing details about a VistA package.
These details are fine level controls over the behaviour of the package.

=== Overview of VistA ===
* [[Basic Questions]]
* [[Frequently Asked Questions]]
* [[VistA System Components]]
* [[Documentation Overview]]
** [[Glossary of Terms]] ([[Glossary Template]])
* [[Programming Languages Overview]]
** [[MUMPS Overview]]
** [[Delphi Overview]]
** [[Java Overview]]
** [[SQL Overview]]
** [[XML Overview]]
* [[Programming VistA Issues]]
* [[FileMan Overview]] (with details also)
* [[Kernel Overview]]
* [[Operating Systems Overview]]
* [[VistA Packages Overview]]
** [[CPRS Overview]]
* [[M2Web Overview]]

=== Projects Information ===
* Information is available at the [[Projects_List]] page

=== Installation Guides ===
* [[Installation Overview]]
* [[Installation How To VistA GT.M Linux]]
* [[Installation How To VistA GT.M Ubuntu Linux | Installation How To VistA GT.M Ubuntu Linux including VistALink (Java)]]
* [[Migrating a VistA/GT.M installation from one platform to another]]
* [[Installation How To VistA/Cache]]
* [[Introducing VistA VivA 0.1]]
* [[Hardware Issues]]
* [[CPRS Installation]]
* [[VistALink]]

=== Installation of Demos ===
* [[Installation How To VistA/GT.M coLinux]]
* [[Using the VistA Appliance]]

=== Installation of Programmer Tools ===
* [[Victory Programmer Environment (VPE) Installation]]

=== Configuration of Packages ===
* [[Configuration Overview]]
* [[Register a Patient]]
* [[HL7 Multi-Listener]]

=== Collaboration Tools ===
* [[OpenForum]]
* Message Board (read only): http://www.mail-archive.com/hardhats-members@lists.sourceforge.net/

* [[CHC Corner]] for ''' Community Health Centers ''' discussion/wish list/collaboration/etc.

* [[From Hardhats Listserve:]]

=== Volunteer Opportunities with WorldVistA ===
* [[Volunteer Coordinator]]
* [[Planning for VistA Advances]]
* [[Advocating VistA]]
* [[Documenting VistA]]
* [[Organization and Planning For VistA Community Meeting]]
* [[Recording Results Of A VistA Community Meeting]]
* [[Categorizing Needs For New VistA Packages]]
* [[Developing New VistA Packages]]
* [[Administration Of OpenForum]]
* [[VistA Community Weekly Conference Call]]

=== Working Groups ===
*[[Software Development (WG1)]]
*[[Education and Training (WG2)]]
*[[Finance (WG3)]]
*[[Membership and Community (WG4)]]
*[[International (WG5)]]

=== [[Community Meeting]] ===
* [[VistA Community Meeting Q1 2007]]
* [[VistA Community Meeting Q2 2007]]
* [[VistA Community Meeting Q1 2006]]
* [[VistA Community Meeting Q2 2006]]
* [[VCM Boston 2005]]

=== [[Weekly Conference Calls]] ===

=== Details about this page ===
To limit vandalism, this page has been write-protected. If you need to make modifications to this page,
contact DavidWhitten, who will help you make changes. Thank you for your support.
=== Details of this website's software ===

This Wiki is based on the mediawiki software. [[Unique Features of Forum Wiki]]

Please see [http://meta.wikipedia.org/wiki/MediaWiki_i18n documentation on customizing the interface]
and the [http://meta.wikipedia.org/wiki/MediaWiki_User%27s_Guide User's Guide] for usage and configuration help.

Editing help see http://meta.wikimedia.org/wiki/Help:Editing#Sections.2C_paragraphs.2C_lists_and_lines

Installation Overview

2006-01-26T17:01:31Z

Bhaskar: /* Getting the software */

The documentation for VistA and OpenVistA can be classified in several groups:
== Getting the software ==
This is the VA ftp site for VistA: ftp://ftp.va.gov/VistA/ --ftp here requires IE not FireFox.
The <tt>gftp</tt> client on Linux also works.

This link is specifically for software: ftp://ftp.va.gov/VistA/Software/

For the open source free software stack for VistA: http://sourceforge.net/projects/worldvista

== Installation Documentation created by WorldVistA and volunteers in the VistA Community. ==

=== Getting up and running with the VistA open source free software ([http://en.wikipedia.org/wiki/Free_and_Open_Source_Software FOSS]) stack ===

The complete FOSS stack for VistA consists of VistA on [http://www.sanchez-gtm.com GT.M] on [http://www.wikipedia.org/wiki/Linux GNU/Linux] on industry standard x86 server hardware. Although it is certainly possible to install this stack by downloading VistA, and installing it on GT.M on x86 GNU/Linux, it is much easier to start with a pre-configured software stack. There are (at least) two flavors of VistA, and two types of packages of VistA on GT.M.

VistA flavors:

*'''FOIA VistA''' is VistA as periodically released by the [http://www.va.gov US Department of Veterans Affairs] under the [http://www.usdoj.gov/oip/foia_updates/Vol_XVII_4/page2.htm Freedom of Information Act (FOIA).] This is sometimes referrd to as the "gold standard". Prior versions of this software at the [http://sourceforge.net/projects/worldvista WorldVistA project page at Source Forge] are labelled OpenVistA FOIA Gold. FOIA VistA releases are numbered by the date on which they are released under FOIA, e.g., 20051021 for Oct 21, 2005.

*'''Leonardo da VistA''' is FOIA VistA as enhanced by the VistA community. '''Leonardo da VistA is used here as strictly an interim, temporary, just-until-the-new-name-is-announced name.''' This software was previously known to the community first as "Hui OpenVistA", and then as just "OpenVistA". The subsequent grant by the US Patent and Trademark Office of a registered trademark of that name to a corporation has triggered a search for a replacement name, and Leonardo da VistA is used here until the new name is announced. Prior releases of this software at the [http://sourceforge.net/projects/worldvista WorldVistA project page at Source Forge] are labelled OpenVistA. Leonardo da VistA releases have numbers such as 0.4.

*'''OpenVistA VA Demo''' is a one-of release of a configuration of VistA intended to demonstrate the CPRS GUI, but not to be otherwise useful, and not part of a family of releases.

In the future, it is hoped that there will be other flavors, e.g., VistA Office EHR.

Types of packages:

*A '''SemiVivA''' package consists of VistA and GT.M bundled together and ready to be installed on an x86 GNU/Linux server.

*A '''VivA''' or '''VivitA'''package is a [http://en.wikipedia.org/wiki/Linux_live_cd live CD (or DVD)] that can be booted on any x86 architecture server to run the entire VistA FOSS stack. VivitA releases are created by mastering [http://damnsmalllinux.org DSL] and the VivA releases are created by remastering either [http://knopper.net/knoppix/index-en.html Knoppix] or [http://morphix.org Morphix].

SemiVivA packages expect to find [http://xdialog.dyns.net Xdialog] on the computer. To use a SemiVivA package, download it to a temporary directory (e.g., as <tt>/tmp/LeonardoDaVistASemiVivA0.4.tgz</tt>). Then, '''as root''' execute:

cd /usr/local
tar zxvf /tmp/LeonardoDaVistASemiVivA0.4.tgz

This will install VistA and GT.M. To use it, an environment with an initial copy of the database must be created with the command:

/usr/local/LeonardoDaVistA/vista --install ''directory''

In the above, substitute the actual VistA release name (e.g., OpenVistA, FOIAVistA) for LeonardoDaVistA. ''directory'' is the full path name of a directory (without a trailing slash) where the environment with the initial copy of the database is to be created, e.g., <tt>/home/vista/myVistA</tt>. To subsequently run VistA, VivitAs again have an option from the mouse on the background. For VivAs, use:

/usr/local/LeonardoDaVistA/vista --run ''directory''

To use a VivA or VivitA package, read/write storage is required for the database. The current distributions can use a Linux file system (e.g., ext3, reiserfs) or a FAT file system (Windows 95/98/ME) but not an NTFS file system (Windows NT/2000/XP/2003). The live CD/DVDs have tools needed to partition a hard drive and create a new file system. The easiest way to proceed is to simply plug a 512MB or bigger USB flash or thumb drive (or a USB hard drive) into the USB port (USB 2.0 preferred) of an x86 server, and boot the CD/DVD. The instructions below are for USB drives, but apply equally well - with appropriate names for the read/write storage - for IDE and SCSI drives.

*After booting the operating system, you will need to mount the read/write storage. For Knoppix based VivA releases, right click on the icon for the drive and mount the drive. This mounts it read-only. Right click again, choose Actions and change the mode to read/write. Note the name of the drive; it will probably be something like <tt>/mnt/uba1</tt> or <tt>/mnt/sda1</tt>. For DSL based VivitA releases, there is a small window in the lower right of the screen with a mounting applet. Immediately after boot up, it will say ''floppy''. Click on the arrow icons within the applet to choose ''sda1'' or other read/write storage, and then click on the icon in the applet to mount the drive. For (older) Morphix based releases, execute:

sudo insmod usb-storage
mount /mnt/sda1

*You will need to create an environment with an initial copy of the database. VivitAs have an option from the "start menu" from clicking the right mouse button on the background. On VivA releases, start a shell, and execute (as before, use the actual name of your VistA):

/usr/local/LeonardoDaVistA/vista --install ''directory''

*To subsequently run VistA, VivitAs again have an option from the mouse on the background. For VivAs, use:

/usr/local/LeonardoDaVistA/vista --run ''directory''

When the GT.M prompt (<tt>GTM></tt>) appears, you have a VistA environment that is ready to start configuring.

== Installation Documentation from sofware and hardware vendors of VistA and OpenVistA. ==

== Installation Documentation from the [[VistA Documentation Library]] (VDL) ==

=== Clinical ===
<TABLE summary="This table is for formatting purposes only." class = "toc" cellpadding="5" border="">
<TR>
<td>[[Installation of Admission Discharge Transfer (ADT)]]</TD>
<td>[[Installation of Electronic Wait List]]</TD>
<td>[[Installation of Medicine]]</TD>
<td>[[Installation of Pharmacy Prescription Practices (PPP)]]</TD>
</TR><TR>
<td>[[Installation of Ambulatory Care Reporting]]</TD>
<td>[[Installation of Functional Independence Measurement (FIM)]]</TD>
<td>[[Installation of Mental Health]]</TD>
<td>[[Installation of Primary Care Management Module (PCMM)]]</TD>
</TR><TR>
<td>[[Installation of Beneficiary Travel]]</TD>
<td>[[Installation of Group Notes]]</TD>
<td>[[Installation of Nursing]]</TD>
<td>[[Installation of Prosthestics]]</TD>
</TR><TR>
<td>[[Installation of Care Management]]</TD>
<td>[[Installation of Home Based Primary Care (HBPC)]]</TD>
<td>[[Installation of Oncology]]</TD>
<td>[[Installation of Quality Audiology Speech Anal & Rpting (QUASAR)]]</TD>
</TR><TR>
<td>[[Installation of Clinical Case Registries]]</TD>
<td>[[Installation of Immunology Case Registry (ICR)]]</TD>
<td>[[Installation of Patient Care Encounter (PCE)]]</TD>
<td>[[Installation of Radiology / Nuclear Medicine]]</TD>
</TR><TR>
<td>[[Installation of Clinical Procedures]]</TD>
<td>[[Installation of Incomplete Records Tracking (IRT)]]</TD>
<td>[[Installation of Pharmacy Automatic Replenish / Ward Stock (AR/WS)]]</TD>
<td>[[Installation of RAI/MDS]]</TD>
</TR><TR>
<td>[[Installation of Computerized Patient Record System (CPRS)]]</TD>
<td>[[Installation of Intake and Output]]</TD>
<td>[[Installation of Pharmacy Bar Code Medication Administration (BCMA)]]</TD>
<td>[[Installation of Remote Order Entry System (ROES)]]</TD>
</TR><TR>
<td>[[Installation of CPRS Adverse Reaction Tracking (ART)]]</TD>
<td>[[Installation of Laboratory Anatomic Pathology]]</TD>
<td>[[Installation of Pharmacy Benefits Management (PBM)]]</TD>
<td>[[Installation of Scheduling]]</TD>
</TR><TR>
<td>[[Installation of CPRS Authorization Subscription Utility (ASU)]]</TD>
<td>[[Installation of Laboratory Blood Bank]]</TD>
<td>[[Installation of Pharmacy Consolidated Mail Outpatient Pharmacy]]</TD>
<td>[[Installation of Social Work]]</TD>
</TR><TR>
<td>[[Installation of CPRS Clinical Reminders]]</TD>
<td>[[Installation of Laboratory Blood Bank Workarounds]]</TD>
<td>[[Installation of Pharmacy Controlled Substances]]</TD>
<td>[[Installation of Spinal Cord Dysfunction]]</TD>
</TR><TR>
<td>[[Installation of CPRS Consult/Request Tracking]]</TD>
<td>[[Installation of Laboratory Electronic Data Interchange (LEDI)]]</TD>
<td>[[Installation of Pharmacy Data Management (PDM)]]</TD>
<td>[[Installation of Surgery]]</TD>
</TR><TR>
<td>[[Installation of CPRS Health Summary]]</TD>
<td>[[Installation of Laboratory Emerging Pathogens Initiative]]</TD>
<td>[[Installation of Pharmacy Drug Accountability]]</TD>
<td>[[Installation of VISTA Imaging System]]</TD>
</TR><TR>
<td>[[Installation of CPRS Problem List]]</TD>
<td>[[Installation of Laboratory National Laboratory Tests/ LOINC Request Form]]</TD>
<td>[[Installation of Pharmacy Electronic Claims Management Engine (ECME)]]</TD>
<td>[[Installation of Visual Impairment Service Team (VIST)]]</TD>
</TR><TR>
<td>[[Installation of CPRS Text Integration Utility (TIU)]]</TD>
<td>[[Installation of Laboratory Universal Interface]]</TD>
<td>[[Installation of Pharmacy Inpatient Medications]]</TD>
<td>[[Installation of Vitals / Measurements]]</TD>
</TR><TR>
<td>[[Installation of Dentistry]]</TD>
<td>[[Installation of Laboratory]]</TD>
<td>[[Installation of Pharmacy National Drug File (NDF)]]</TD>
<td>[[Installation of Women's Health]]</TD>
</TR><TR>
<td>[[Installation of Dietetics]]</TD>
<td>[[Installation of Lexicon Utility]]</TD>
<td>[[Installation of Pharmacy Outpatient Pharmacy]]</TD>
</TR></TABLE>
=== Infrastructure ===
<TABLE summary="This table is for formatting purposes only." class = "toc" cellpadding="5" border="">
<TR>
<td>[[Installation of Capacity Management Tools]]</TD>
<td>[[Installation of Kernel Delphi Components (KDC)]]</TD>
<td>[[Installation of Minimal Patient Dataset (MPD)]]</TD>
<td>[[Installation of SlotMaster (Kernel ZSLOT)]]</TD>
</TR><TR>
<td>[[Installation of Duplicate Record Merge- Patient Merge]]</TD>
<td>[[Installation of Kernel Installation and Distribution System (KIDS)]]</TD>
<td>[[Installation of Name Standardization]]</TD>
<td>[[Installation of SQL Interface (SQLI)]]</TD>
</TR><TR>
<td>[[Installation of Electronic Error and Enhancement Reporting (E3R)]]</TD>
<td>[[Installation of Kernel Toolkit]]</TD>
<td>[[Installation of National Online Information Sharing (NOIS)]]</TD>
<td>[[Installation of Standard Files and Tables]]</TD>
</TR><TR>
<td>[[Installation of FileMan]]</TD>
<td>[[Installation of Kernel Unwinder]]</TD>
<td>[[Installation of National Patch Module]]</TD>
<td>[[Installation of Statistical Analysis of Global Growth (SAGG)]]</TD>
</TR><TR>
<td>[[Installation of FileMan Delphi Components (FMDC)]]</TD>
<td>[[Installation of List Manager]]</TD>
<td>[[Installation of Network Health Exchange (NHE)]]</TD>
<td>[[Installation of Survey Generator]]</TD>
</TR><TR>
<td>[[Installation of HL7 (VistA Messaging)]]</TD>
<td>[[Installation of M-to-M Broker]]</TD>
<td>[[Installation of Patient Data Exchange (PDX)]]</TD>
<td>[[Installation of VistA Data Extraction Framework (VDEF)]]</TD>
</TR><TR>
<td>[[Installation of Institution File Redesign (IFR)]]</TD>
<td>[[Installation of MailMan]]</TD>
<td>[[Installation of Remote Procedure Call (RPC) Broker]]</TD>
<td>[[Installation of XML Parser (VistA)]]</TD>
</TR><TR>
<td>[[Installation of Kernel]]</TD>
<td>[[Installation of Master Patient Index (MPI)]]</TD>
<td>[[Installation of Resource Usage Monitor]]</TD>
</TR></TABLE>
=== Financial-Administrative ===
<TABLE summary="This table is for formatting purposes only." class = "toc" cellpadding="5" border="">
<TR>
<td>[[Installation of Accounts Receivable (AR)]]</TD>
<td>[[Installation of Engineering (AEMS / MERS)]]</TD>
<td>[[Installation of IFCAP]]</TD>
<td>[[Installation of Patient Representative]]</TD>
</TR><TR>
<td>[[Installation of Auto Safety Incdnt Surv Trak Sys (ASISTS)]]</TD>
<td>[[Installation of Enrollment Application System]]</TD>
<td>[[Installation of Incident Reporting]]</TD>
<td>[[Installation of Personnel and Accounting Integrated Data (PAID)]]</TD>
</TR><TR>
<td>[[Installation of Automated Information Collection System (AICS)]]</TD>
<td>[[Installation of Equipment / Turn-In Request]]</TD>
<td>[[Installation of Income Verification Match (IVM)]]</TD>
<td>[[Installation of Police and Security]]</TD>
</TR><TR>
<td>[[Installation of Automated Medical Information Exchange (AMIE)]]</TD>
<td>[[Installation of Event Capture]]</TD>
<td>[[Installation of Integrated Billing (IB)]]</TD>
<td>[[Installation of Quality Management Integration Module]]</TD>
</TR><TR>
<td>[[Installation of Clinical Monitoring System]]</TD>
<td>[[Installation of Fee Basis]]</TD>
<td>[[Installation of Integrated Patient Funds]]</TD>
<td>[[Installation of Record Tracking]]</TD>
</TR><TR>
<td>[[Installation of Compensation & Pension Records Interchange (CAPRI)]]</TD>
<td>[[Installation of Generic Code Sheet (GCS)]]</TD>
<td>[[Installation of Library]]</TD>
<td>[[Installation of Release of Information (ROI) Manager]]</TD>
</TR><TR>
<td>[[Installation of Current Procedural Terminology (CPT)]]</TD>
<td>[[Installation of Health Eligibility Center (HEC)]]</TD>
<td>[[Installation of Missing Patient Register]]</TD>
<td>[[Installation of Veterans Identification Card (VIC/PICS)]]</TD>
</TR><TR>
<td>[[Installation of Decision Support System (DSS) Extracts]]</TD>
<td>[[Installation of Hospital Inquiry (HINQ)]]</TD>
<td>[[Installation of Occurrence Screen]]</TD>
<td>[[Installation of Voluntary Service System (VSS)]]</TD>
</TR><TR>
<td>[[Installation of Diagnostic Related Group (DRG) Grouper]]</TD>
<td>[[Installation of ICD-9-CM]]</TD>
</TR></TABLE>

Software Development (WG1) Version Control (T3)

2005-11-22T20:04:30Z

Bhaskar: /* VistA Development Directories */

== Setting up a VistA Development Environment ==

=== Overview ===

This is a description of how VistA development environments should be configured.

<tt>Monospaced text</tt> designates program names, directory names, command line parameters, etc., that are intended to be typed in at a Linux shell or a GT.M prompt, e.g. <tt>/bin/bash</tt>. ''Italic text'' is a descriptor of something whose actual value must be determined when the command is typed, e.g., ''gtmver''.

=== Theory ===

A release is a collection of routines and global variables. The canonical packaging of a release, which is suitable for importation into any standard M distribution, is a collection of M source code routines and a database extract in ZWRite format. When installed on a system, to run with an M implementation, a release may have pre-compiled object files, database files, shell scripts, global directories, etc.

Below is a diagram of the “roll-up” by which a VistA release (“Release A”) gets converted into another VistA release (“Release B”) by a development team. A and B could be from different families, e.g., Release A could be a FOIA release and Release B could be a Leonardo da VistA release.

[[Image:051112-1WorldVistADevelopmentEnvironment_html_26096dee.gif|
"Roll up" model of VistA releases]]

Once Release A is installed, it remains frozen and unchanged except for any essential patches that may become available independent of the development process for creating Release B and without which the release lacks some required functionality. This means, for example, that KIDS patches should be applied in an integration environment rather than a release environment.

At any given time, there can be multiple development projects underway based on Release A. In other words, there may well be a Release C that is also based on Release A, but which has its own integration and development areas.

To start the development process, an integration directory is created and initialized with a copy of the global variables from Release A, as well as shell scripts, global directories, etc. The integration directory may well have a different name from Release A and Release B. For example, Release A may be FOIAVistA_20051021, Release B may become LeonardoDaVistA_0.4 (at the time that the integration area is created, the name and version of Release B may not even be decided yet), and the integration and development areas may be named Greenbelt_200510. There is no need to copy routines, since the GT.M search path will be set up to look for routines in the integration area before looking in Release A; hence only routines that are different between Release A and the new release need to be duplicated.

Actual development does not take place in the integration area. Development occurs in development areas, typically in the directories of individual developers; however, there may be a shared development area if two developers are collaborating on making changes to the very same module (i.e., their code changes overlap). A development area is set up by creating a directory structure, shell scripts, etc. Note that development areas can be hierarchical so that development subtasks 1a and 1b can be developed separately and integrated into development task 1, prior to integration into the integration area, etc.

During this development process, developers develop code in individual sand boxes (development areas), but normally share the database (global variables) in the integration area – there may typically be no need to create a separate database. However, if some global variable changes are tied to code changes being made in a development area, a copy of those global variables can be placed in a separate database file in that development area, and a global directory for that development area can map those global variables to the database in that development area, with all other global variables mapped to the database in the integration area.

When a developer has code that is ready for integration, the new versions of the modified routines are promoted to the integration area. Any global variables tied to the code being promoted that are in a database in the development area must be merged, reconciled or otherwise integrated with the global variables in the database in the integration area and the global directory in the development area modified accordingly. Note that there needs to be a process, e.g., involving code reviews, by which a development task is considered complete enough to be promoted. These, and other quality gates, are not discussed herein.

Creating a release is minimally the process of creating the directory structure for Release B, copying the routines from Release A, overlying the routines with those from the integration area, and copying the global variables from the integration area.

Normally, Release A, the integration area and development areas would all use the same GT.M version. However, this is not a requirement.

'''It is strongly recommended that database files in integration and development environments be journaled, and backed up regularly. It is also strongly recommended that a version control system such as CVS or subversion be used for integration areas.'''

=== Practice ===

==== Shell ====

The standard shell for VistA community scripting is bash (installed as <tt>/bin/bash</tt> on Debian GNU/Linux systems).

==== GT.M Release Directories ====

Each release of GT.M is installed its own subdirectory of <tt>/opt</tt> (preferred) or <tt>/usr/local</tt> (acceptable). Each directory name starts with <tt>gtm</tt> followed by a release number separated from the release name by an underscore (<tt>_</tt>). Thus, for example, GT.M V5.0-000C would be installed in <tt>/opt/gtm_V5.0-000C</tt>. <tt>/opt/gtm</tt> is a relative symbolic link to the latest version, set up with a command sequence such as:

cd /opt
rm -f gtm
ln -s gtm_V5.0-000C gtm

When installing GT.M, the file gtmprofile should be edited so that the line:

EDITOR="/bin/vi"; export EDITOR

is modified to read:

export EDITOR=${EDITOR:=/bin/vi}

==== VistA Release Directories ====

Each release is installed in its own sub-directory of a standard system location, such as <tt>/opt</tt> (preferred) or <tt>/usr/local</tt> (acceptable). Each directory has a release family name followed by a release / version number suffix separated from the release name by an underscore. Directories for releases without version numbers, such as FOIA releases, have a date suffix of the form ''yyyymmdd'' (and where appropriate just ''yyyymm''). For example, an August 25, 2005 FOIA release might be in <tt>/opt/FOIAVistA20050825</tt>, an October 21, 2005 release in <tt>/opt/FOIAVistA20051021</tt>, an OpenVistA 0.3 release in <tt>/opt/OpenVistA0.3</tt> and a Leonardo da VistA 0.45 release in <tt>/opt/LeonardoDaVistA0.45</tt>.

The normal protection on all directories and files in a release directory should be read-only. To install files in the <tt>p</tt> subdirectory, it should be made read-write, the source file(s) for the patch copied in, the object file(s) generated, and the directory and its contents again made read-only.

For each release family, the release directory contains subdirectories <tt>g</tt>, <tt>o</tt>, <tt>r</tt> and <tt>p</tt>, symbolic link <tt>gtm</tt>, a script <tt>install</tt>, scripts <tt>run</tt>, and <tt>cprs_direct</tt> that are not executable in a release directory, but which are used when copied to integration directories and made executable. A file <tt>env</tt> is used to set up the execution environment.

Other files and shell scripts may be created for various maintenance purposes (and ideally would be documented here).

*Subdirectory <tt>g</tt> contains a global directory file <tt>mumps.gld</tt> and a compressed database file <tt>mumps.dat.gz</tt>. The global directory maps all global variables to a single database file <tt>$vista_home/g/mumps.dat</tt> (i.e., the environment variable <tt>$vista_home</tt> is used at run-time to point a GT.M process to the location of the database file, so that different processes can actually use the same global directory to refer to entirely different database files).

*Subdirectories <tt>o</tt> and <tt>r</tt> correspond to directories for files containing routine object code and routine source code respectively. Each file in <tt>r</tt> ends in <tt>.m</tt> and has a corresponding file in <tt>o</tt> with a newer time stamp and which ends in <tt>.o</tt>.

*Subdirectory <tt>p</tt> contains source and object code for patches to a release (generated outside the scope of the work for creating Release B) and which are deemed to be essential for the proper functioning of the release.

*The symbolic link <tt>gtm</tt> points to the GT.M directory used for this VistA directory.

*The file <tt>env</tt> sets up the GT.M environment:

<pre>
# env - file to be sourced to create VistA environment
#
# This temporary version of the commands to set up the VistA
# environment assumes that the parent and child use the same
# version of GT.M.

if [[ -d parent ]] ; then
pushd parent 1>/dev/null
source ./env
popd 1>/dev/null
fi

if [[ -n $routines ]] ; then
export routines="$PWD/p $PWD/o($PWD/r) $routines"
else
export routines="$PWD/p $PWD/o($PWD/r)"
fi
if [[ -f $PWD/g/mumps.dat ]] ; then export vista_home=$PWD ; fi

source gtm/gtmprofile
export gtmgbldir=$PWD/g/mumps.gld
export gtmroutines="$routines $gtm_dist"
</pre>

*The script <tt>install</tt> creates a new integration directory to be used in creating a new release from this release. Normally, the initial database file of the integration directory is created by uncompressing <tt>mumps.dat.gz</tt>. Here is the script <tt>install</tt>:

<pre>
#!/bin/bash
#
# install - create new VistA environment as child of current environment
#
# This temporary version of the install script assumes that both
# have the same GT.M version. Also, there is no error handling yet,
# and no provision yet for a separate database on the child.
#
# Set up standard environment to run VistA

# Set up the environment for VistA
pushd `dirname $0` 1>/dev/null
export parent=$PWD
source ./env
popd 1>/dev/null
echo "Parent is" $parent

# Create the directory structure for the child
mkdir -p $1/{g,o,r,p,tmp}

# Link the child to the parent
ln -s $parent $1/parent

# Give the child the same GT.M version as the parent
ln -s $parent/gtm $1/gtm

# Copy other files in this directory
find $parent/ -maxdepth 1 -type f \! -name \*~ -exec cp {} $1/ \;

# Make run & cprs_direct executable because it may not be executable for the parent
chmod u+x $1/run $1/cprs_direct
find $1 -maxdepth 1 $ -name run -o -name cprs_direct $ -perm -4 -exec chmod o+x {} \;
find $1 -maxdepth 1 $ -name run -o -name cprs_direct $ -perm -40 -exec chmod g+x {} \;

# Give the child a global directory, for now the same as the parent
cp $parent/g/mumps.gld $1/g/mumps.gld

# Give the child a database
if [[ -e $parent/g/mumps.dat.gz ]] ; then
echo "Unzipping from parent to create initial database"
gzip -d <$parent/g/mumps.dat.gz >$1/g/mumps.dat
$gtm_dist/mupip set -journal="enable,on,before" -file $1/g/mumps.dat
chmod o+r,o-w,g+w $1/g/mumps.{dat,mjl}
else
echo "Using parent database in this environment"
fi

# Make files except database files, journal files & directories read-only
find $1 -type f \! -name \*.dat \! -name \*mjl -exec chmod a-w {} \;
find $1 -type d -exec chmod 775 {} \;

echo "Default permission for development environment is for all to read and group to write - please fix if needed"
</pre>

In a future enhancement, option <tt>--newgtm</tt> ''gtmver'', will specify that the integration directory is to be configured to run a different version of GT.M (as specified by the directory ''gtmver'') from the one used by the release. If <tt>--newgtm</tt> ''gtmver'' is used, the default assumption will be that the database will need to be extracted with the version of GT.M used by Release A, and loaded into a new database created with the version of GT.M to be used in the integration directory. When <tt>--newgtm</tt> ''gtmver'' is used, a an additional optional option <tt>--nonewdb</tt> will be available to specify that the releases of GT.M have compatible database formats, and that database from Release A can be used unchanged in the integration directory. Note that the use of <tt>--newgtm</tt> ''gtmver'' will almost certainly result in a command that takes a long time, because the database may need to be extracted and reloaded, and the routines recompiled.

Here is a listing of a top level release directory:

<pre>
bhaskar@Makaira:~$ ls -l /opt/FOIAVistA20051021
total 912
dr-xr-sr-x 2 root staff 4096 Sep 15 13:19 CPRS_Gui
-r-xr-xr-x 1 root staff 216 Nov 22 09:21 cprs_direct
-r--r--r-- 1 root staff 583 Nov 22 09:21 env
dr-xr-xr-x 2 root staff 4096 Oct 27 14:00 g
lrwxrwxrwx 1 root staff 18 Nov 22 09:26 gtm -> /opt/gtm_V5.0-000C
-r-xr-xr-x 1 root staff 1832 Nov 22 10:44 install
dr-xr-xr-x 2 root staff 446464 Nov 22 07:10 o
dr-xr-sr-x 2 root staff 4096 Nov 22 09:22 p
dr-xr-xr-x 2 root staff 446464 Oct 27 13:38 r
-r--r--r-- 1 root staff 252 Nov 22 09:21 run
-r-xr-xr-x 1 root staff 3633 Oct 30 06:42 vista
</pre>

==== VistA Integration Directories ====

Here is an example of creating an integration environment from a release environment:

<pre>
vista@Makaira:~$ /opt/FOIAVistA20051021/install LeonardoDaVistA0.1
Parent is /opt/FOIAVistA20051021
Unzipping from parent to create initial database
%GTM-I-JNLCREATE, Journal file /home/vista/LeonardoDaVistA0.1/g/mumps.mjl created for database file /home/vista/LeonardoDaVistA0.1/g/mumps.dat with BEFORE_IMAGES
%GTM-I-JNLSTATE, Journaling state for database file /home/vista/LeonardoDaVistA0.1/g/mumps.dat is now ON
Default permission for development environment is for all to read and group to write - please fix if needed
vista@Makaira:~$
</pre>

A VistA integration directory is similar to a VistA release directory, with the following differences.

*Subdirectory <tt>g</tt> contains a database file, <tt>mumps.dat</tt>, rather than a compressed database file, <tt>mumps.dat.gz</tt>.

*The symbolic link <tt>parent</tt> points to the release directory from which this integration directory was created. A release directory does not have a symbolic link called parent. (The recommended way for a script to determine whether a directory is a release directory or an integration / development directory is to test for the existence of <tt>parent</tt>.)

*A script <tt>run</tt> which invokes and runs VistA in that integration environment. Note that a VistA release may physically include a <tt>run</tt> script, but it will not work because it is not possible to directly run VistA from a release directory. Here is the <tt>run</tt> script:

<pre>
#!/bin/bash
#
# run - run this instance of VistA

# Set up the environment for VistA
pushd `dirname $0` 1>/dev/null
export parent=$PWD/parent
source ./env
popd 1>/dev/null

if [[ -n $1 ]] ; then
$gtm_dist/mumps -run $1
else
$gtm_dist/mumps -dir
fi
</pre>

*The <tt>cprs_direct</tt> script handles connection requests from CPRS GUI client processes that come in via <tt>inetd</tt>/<tt>xinetd</tt>:

<pre>
#!/bin/bash
#
# cprs_direct - start a process to serve the CPRS Gui client

# Set up the environment for VistA
export HOME=/home/`whoami`
cd `dirname $0`
export parent=$PWD/parent
source ./env

# Run the server for the CPRS GUI client
cd tmp
$gtm_dist/mumps -run GTMLNX^XWBTCPM
</pre>

*When the <tt>install</tt> script is executed, it will create a development directory.

*Except for database files, journal files, and directories, the normal protection on all directories and files in an integration directory should be read-only. When promoting code to the integration directory from a development directory, or to install externally generated patches in the <tt>p</tt> subdirectory, needed directories should be made read-write, sources copied in, object file(s) generated, and directories again made read-only.

Below is a listing of the directory of an integration environment created from the release in the example above. Notice <tt>parent</tt> link pointing to the directory of the parent environment. (In this case, the <tt>gtm</tt> link points to the <tt>gtm</tt> link in the parent, rather than <tt>/opt/gtm_V5.0-000C</tt>. It doesn't matter either way.)

<pre>
bhaskar@Makaira:~$ ls -l /home/vista/LeonardoDaVistA0.1
total 48
-r-xr-xr-x 1 vista vista 216 Nov 22 09:28 cprs_direct
-r--r--r-- 1 vista vista 583 Nov 22 09:28 env
drwxrwxr-x 2 vista vista 4096 Nov 22 10:11 g
lrwxrwxrwx 1 vista vista 26 Nov 22 09:28 gtm -> /opt/FOIAVistA20051021/gtm
-r-xr-xr-x 1 vista vista 1832 Nov 22 10:44 install
drwxrwxr-x 2 vista vista 8192 Nov 22 09:33 o
drwxrwxr-x 2 vista vista 4096 Nov 22 09:28 p
lrwxrwxrwx 1 vista vista 22 Nov 22 09:28 parent -> /opt/FOIAVistA20051021
drwxrwxr-x 2 vista vista 8192 Nov 22 09:32 r
-r-xr-xr-x 1 vista vista 252 Nov 22 09:28 run
drwxrwxr-x 2 vista vista 4096 Nov 22 09:28 tmp
-r-xr-xr-x 1 vista vista 3633 Nov 22 09:28 vista
</pre>

==== VistA Development Directories ====

A development directory is like an integration directory, except that it does not normally have its own database file or global directory. Here is an example of creating a development environment from the integration environment:

<pre>
bhaskar@Makaira:~$ ~vista/LeonardoDaVistA0.1/install LeonardoDaVistA0.1
Parent is /home/vista/LeonardoDaVistA0.1
Using parent database in this environment
Default permission for development environment is for all to read and group to write - please fix if needed
bhaskar@Makaira:~$
</pre>

Note that there is hardly anything in the directory of a development environment:

<pre>
bhaskar@Makaira:~$ ls -lR LeonardoDaVistA0.1/
LeonardoDaVistA0.1/:
total 40
-r-xr-xr-x 1 bhaskar vista 216 Nov 22 14:09 cprs_direct
-r--r--r-- 1 bhaskar vista 583 Nov 22 14:09 env
drwxrwxr-x 2 bhaskar vista 4096 Nov 22 14:09 g
lrwxrwxrwx 1 bhaskar vista 34 Nov 22 14:09 gtm -> /home/vista/LeonardoDaVistA0.1/gtm
-r-xr-xr-x 1 bhaskar vista 1832 Nov 22 14:09 install
drwxrwxr-x 2 bhaskar vista 4096 Nov 22 14:09 o
drwxrwxr-x 2 bhaskar vista 4096 Nov 22 14:09 p
lrwxrwxrwx 1 bhaskar vista 30 Nov 22 14:09 parent -> /home/vista/LeonardoDaVistA0.1
drwxrwxr-x 2 bhaskar vista 4096 Nov 22 14:09 r
-r-xr-xr-x 1 bhaskar vista 252 Nov 22 14:09 run
drwxrwxr-x 2 bhaskar vista 4096 Nov 22 14:09 tmp
-r-xr-xr-x 1 bhaskar vista 3633 Nov 22 14:09 vista

LeonardoDaVistA0.1/g:
total 4
-r--r--r-- 1 bhaskar vista 1024 Nov 22 14:09 mumps.gld

LeonardoDaVistA0.1/o:
total 0

LeonardoDaVistA0.1/p:
total 0

LeonardoDaVistA0.1/r:
total 0

LeonardoDaVistA0.1/tmp:
total 0
bhaskar@Makaira:~$ du -sh LeonardoDaVistA0.1/
48K LeonardoDaVistA0.1/
bhaskar@Makaira:~$
</pre>

The ability to create a development environment that can be isolated from the integration environment with an overhead of 48K bytes makes it easy to create many development environments as sand boxes to simplify the development process.

As discussed earlier, it may be entirely appropriate for a development directory to have database files when there is a need to isolate certain globals.

Indeed, since development directories are hierarchical – a development directory is an integration directory for development directories below it, and itself contributes to an integration directory above it, an integration directory is really nothing more than a development directory that does not itself contribute to an integration directory above it, but instead is used to create a release.

Note that although a GT.M database file can be opened by only one GT.M version at a time, it is quite easy to create a directory structure where Release A, the integration area, and each development area use different versions of GT.M. In the most common case, where the integration and development areas use a different version of GT.M from Release A, the only additional configuration requirement is to create a directory in the integration area for object files generated from the source files in Release A with the version of GT.M used for integration and development of Release B

Software Development (WG1) Version Control (T3)

2005-11-22T19:56:23Z

Bhaskar: /* VistA Integration Directories */

== Setting up a VistA Development Environment ==

=== Overview ===

This is a description of how VistA development environments should be configured.

<tt>Monospaced text</tt> designates program names, directory names, command line parameters, etc., that are intended to be typed in at a Linux shell or a GT.M prompt, e.g. <tt>/bin/bash</tt>. ''Italic text'' is a descriptor of something whose actual value must be determined when the command is typed, e.g., ''gtmver''.

=== Theory ===

A release is a collection of routines and global variables. The canonical packaging of a release, which is suitable for importation into any standard M distribution, is a collection of M source code routines and a database extract in ZWRite format. When installed on a system, to run with an M implementation, a release may have pre-compiled object files, database files, shell scripts, global directories, etc.

Below is a diagram of the “roll-up” by which a VistA release (“Release A”) gets converted into another VistA release (“Release B”) by a development team. A and B could be from different families, e.g., Release A could be a FOIA release and Release B could be a Leonardo da VistA release.

[[Image:051112-1WorldVistADevelopmentEnvironment_html_26096dee.gif|
"Roll up" model of VistA releases]]

Once Release A is installed, it remains frozen and unchanged except for any essential patches that may become available independent of the development process for creating Release B and without which the release lacks some required functionality. This means, for example, that KIDS patches should be applied in an integration environment rather than a release environment.

At any given time, there can be multiple development projects underway based on Release A. In other words, there may well be a Release C that is also based on Release A, but which has its own integration and development areas.

To start the development process, an integration directory is created and initialized with a copy of the global variables from Release A, as well as shell scripts, global directories, etc. The integration directory may well have a different name from Release A and Release B. For example, Release A may be FOIAVistA_20051021, Release B may become LeonardoDaVistA_0.4 (at the time that the integration area is created, the name and version of Release B may not even be decided yet), and the integration and development areas may be named Greenbelt_200510. There is no need to copy routines, since the GT.M search path will be set up to look for routines in the integration area before looking in Release A; hence only routines that are different between Release A and the new release need to be duplicated.

Actual development does not take place in the integration area. Development occurs in development areas, typically in the directories of individual developers; however, there may be a shared development area if two developers are collaborating on making changes to the very same module (i.e., their code changes overlap). A development area is set up by creating a directory structure, shell scripts, etc. Note that development areas can be hierarchical so that development subtasks 1a and 1b can be developed separately and integrated into development task 1, prior to integration into the integration area, etc.

During this development process, developers develop code in individual sand boxes (development areas), but normally share the database (global variables) in the integration area – there may typically be no need to create a separate database. However, if some global variable changes are tied to code changes being made in a development area, a copy of those global variables can be placed in a separate database file in that development area, and a global directory for that development area can map those global variables to the database in that development area, with all other global variables mapped to the database in the integration area.

When a developer has code that is ready for integration, the new versions of the modified routines are promoted to the integration area. Any global variables tied to the code being promoted that are in a database in the development area must be merged, reconciled or otherwise integrated with the global variables in the database in the integration area and the global directory in the development area modified accordingly. Note that there needs to be a process, e.g., involving code reviews, by which a development task is considered complete enough to be promoted. These, and other quality gates, are not discussed herein.

Creating a release is minimally the process of creating the directory structure for Release B, copying the routines from Release A, overlying the routines with those from the integration area, and copying the global variables from the integration area.

Normally, Release A, the integration area and development areas would all use the same GT.M version. However, this is not a requirement.

'''It is strongly recommended that database files in integration and development environments be journaled, and backed up regularly. It is also strongly recommended that a version control system such as CVS or subversion be used for integration areas.'''

=== Practice ===

==== Shell ====

The standard shell for VistA community scripting is bash (installed as <tt>/bin/bash</tt> on Debian GNU/Linux systems).

==== GT.M Release Directories ====

Each release of GT.M is installed its own subdirectory of <tt>/opt</tt> (preferred) or <tt>/usr/local</tt> (acceptable). Each directory name starts with <tt>gtm</tt> followed by a release number separated from the release name by an underscore (<tt>_</tt>). Thus, for example, GT.M V5.0-000C would be installed in <tt>/opt/gtm_V5.0-000C</tt>. <tt>/opt/gtm</tt> is a relative symbolic link to the latest version, set up with a command sequence such as:

cd /opt
rm -f gtm
ln -s gtm_V5.0-000C gtm

When installing GT.M, the file gtmprofile should be edited so that the line:

EDITOR="/bin/vi"; export EDITOR

is modified to read:

export EDITOR=${EDITOR:=/bin/vi}

==== VistA Release Directories ====

Each release is installed in its own sub-directory of a standard system location, such as <tt>/opt</tt> (preferred) or <tt>/usr/local</tt> (acceptable). Each directory has a release family name followed by a release / version number suffix separated from the release name by an underscore. Directories for releases without version numbers, such as FOIA releases, have a date suffix of the form ''yyyymmdd'' (and where appropriate just ''yyyymm''). For example, an August 25, 2005 FOIA release might be in <tt>/opt/FOIAVistA20050825</tt>, an October 21, 2005 release in <tt>/opt/FOIAVistA20051021</tt>, an OpenVistA 0.3 release in <tt>/opt/OpenVistA0.3</tt> and a Leonardo da VistA 0.45 release in <tt>/opt/LeonardoDaVistA0.45</tt>.

The normal protection on all directories and files in a release directory should be read-only. To install files in the <tt>p</tt> subdirectory, it should be made read-write, the source file(s) for the patch copied in, the object file(s) generated, and the directory and its contents again made read-only.

For each release family, the release directory contains subdirectories <tt>g</tt>, <tt>o</tt>, <tt>r</tt> and <tt>p</tt>, symbolic link <tt>gtm</tt>, a script <tt>install</tt>, scripts <tt>run</tt>, and <tt>cprs_direct</tt> that are not executable in a release directory, but which are used when copied to integration directories and made executable. A file <tt>env</tt> is used to set up the execution environment.

Other files and shell scripts may be created for various maintenance purposes (and ideally would be documented here).

*Subdirectory <tt>g</tt> contains a global directory file <tt>mumps.gld</tt> and a compressed database file <tt>mumps.dat.gz</tt>. The global directory maps all global variables to a single database file <tt>$vista_home/g/mumps.dat</tt> (i.e., the environment variable <tt>$vista_home</tt> is used at run-time to point a GT.M process to the location of the database file, so that different processes can actually use the same global directory to refer to entirely different database files).

*Subdirectories <tt>o</tt> and <tt>r</tt> correspond to directories for files containing routine object code and routine source code respectively. Each file in <tt>r</tt> ends in <tt>.m</tt> and has a corresponding file in <tt>o</tt> with a newer time stamp and which ends in <tt>.o</tt>.

*Subdirectory <tt>p</tt> contains source and object code for patches to a release (generated outside the scope of the work for creating Release B) and which are deemed to be essential for the proper functioning of the release.

*The symbolic link <tt>gtm</tt> points to the GT.M directory used for this VistA directory.

*The file <tt>env</tt> sets up the GT.M environment:

<pre>
# env - file to be sourced to create VistA environment
#
# This temporary version of the commands to set up the VistA
# environment assumes that the parent and child use the same
# version of GT.M.

if [[ -d parent ]] ; then
pushd parent 1>/dev/null
source ./env
popd 1>/dev/null
fi

if [[ -n $routines ]] ; then
export routines="$PWD/p $PWD/o($PWD/r) $routines"
else
export routines="$PWD/p $PWD/o($PWD/r)"
fi
if [[ -f $PWD/g/mumps.dat ]] ; then export vista_home=$PWD ; fi

source gtm/gtmprofile
export gtmgbldir=$PWD/g/mumps.gld
export gtmroutines="$routines $gtm_dist"
</pre>

*The script <tt>install</tt> creates a new integration directory to be used in creating a new release from this release. Normally, the initial database file of the integration directory is created by uncompressing <tt>mumps.dat.gz</tt>. Here is the script <tt>install</tt>:

<pre>
#!/bin/bash
#
# install - create new VistA environment as child of current environment
#
# This temporary version of the install script assumes that both
# have the same GT.M version. Also, there is no error handling yet,
# and no provision yet for a separate database on the child.
#
# Set up standard environment to run VistA

# Set up the environment for VistA
pushd `dirname $0` 1>/dev/null
export parent=$PWD
source ./env
popd 1>/dev/null
echo "Parent is" $parent

# Create the directory structure for the child
mkdir -p $1/{g,o,r,p,tmp}

# Link the child to the parent
ln -s $parent $1/parent

# Give the child the same GT.M version as the parent
ln -s $parent/gtm $1/gtm

# Copy other files in this directory
find $parent/ -maxdepth 1 -type f \! -name \*~ -exec cp {} $1/ \;

# Make run & cprs_direct executable because it may not be executable for the parent
chmod u+x $1/run $1/cprs_direct
find $1 -maxdepth 1 $ -name run -o -name cprs_direct $ -perm -4 -exec chmod o+x {} \;
find $1 -maxdepth 1 $ -name run -o -name cprs_direct $ -perm -40 -exec chmod g+x {} \;

# Give the child a global directory, for now the same as the parent
cp $parent/g/mumps.gld $1/g/mumps.gld

# Give the child a database
if [[ -e $parent/g/mumps.dat.gz ]] ; then
echo "Unzipping from parent to create initial database"
gzip -d <$parent/g/mumps.dat.gz >$1/g/mumps.dat
$gtm_dist/mupip set -journal="enable,on,before" -file $1/g/mumps.dat
chmod o+r,o-w,g+w $1/g/mumps.{dat,mjl}
else
echo "Using parent database in this environment"
fi

# Make files except database files, journal files & directories read-only
find $1 -type f \! -name \*.dat \! -name \*mjl -exec chmod a-w {} \;
find $1 -type d -exec chmod 775 {} \;

echo "Default permission for development environment is for all to read and group to write - please fix if needed"
</pre>

In a future enhancement, option <tt>--newgtm</tt> ''gtmver'', will specify that the integration directory is to be configured to run a different version of GT.M (as specified by the directory ''gtmver'') from the one used by the release. If <tt>--newgtm</tt> ''gtmver'' is used, the default assumption will be that the database will need to be extracted with the version of GT.M used by Release A, and loaded into a new database created with the version of GT.M to be used in the integration directory. When <tt>--newgtm</tt> ''gtmver'' is used, a an additional optional option <tt>--nonewdb</tt> will be available to specify that the releases of GT.M have compatible database formats, and that database from Release A can be used unchanged in the integration directory. Note that the use of <tt>--newgtm</tt> ''gtmver'' will almost certainly result in a command that takes a long time, because the database may need to be extracted and reloaded, and the routines recompiled.

Here is a listing of a top level release directory:

<pre>
bhaskar@Makaira:~$ ls -l /opt/FOIAVistA20051021
total 912
dr-xr-sr-x 2 root staff 4096 Sep 15 13:19 CPRS_Gui
-r-xr-xr-x 1 root staff 216 Nov 22 09:21 cprs_direct
-r--r--r-- 1 root staff 583 Nov 22 09:21 env
dr-xr-xr-x 2 root staff 4096 Oct 27 14:00 g
lrwxrwxrwx 1 root staff 18 Nov 22 09:26 gtm -> /opt/gtm_V5.0-000C
-r-xr-xr-x 1 root staff 1832 Nov 22 10:44 install
dr-xr-xr-x 2 root staff 446464 Nov 22 07:10 o
dr-xr-sr-x 2 root staff 4096 Nov 22 09:22 p
dr-xr-xr-x 2 root staff 446464 Oct 27 13:38 r
-r--r--r-- 1 root staff 252 Nov 22 09:21 run
-r-xr-xr-x 1 root staff 3633 Oct 30 06:42 vista
</pre>

==== VistA Integration Directories ====

Here is an example of creating an integration environment from a release environment:

<pre>
vista@Makaira:~$ /opt/FOIAVistA20051021/install LeonardoDaVistA0.1
Parent is /opt/FOIAVistA20051021
Unzipping from parent to create initial database
%GTM-I-JNLCREATE, Journal file /home/vista/LeonardoDaVistA0.1/g/mumps.mjl created for database file /home/vista/LeonardoDaVistA0.1/g/mumps.dat with BEFORE_IMAGES
%GTM-I-JNLSTATE, Journaling state for database file /home/vista/LeonardoDaVistA0.1/g/mumps.dat is now ON
Default permission for development environment is for all to read and group to write - please fix if needed
vista@Makaira:~$
</pre>

A VistA integration directory is similar to a VistA release directory, with the following differences.

*Subdirectory <tt>g</tt> contains a database file, <tt>mumps.dat</tt>, rather than a compressed database file, <tt>mumps.dat.gz</tt>.

*The symbolic link <tt>parent</tt> points to the release directory from which this integration directory was created. A release directory does not have a symbolic link called parent. (The recommended way for a script to determine whether a directory is a release directory or an integration / development directory is to test for the existence of <tt>parent</tt>.)

*A script <tt>run</tt> which invokes and runs VistA in that integration environment. Note that a VistA release may physically include a <tt>run</tt> script, but it will not work because it is not possible to directly run VistA from a release directory. Here is the <tt>run</tt> script:

<pre>
#!/bin/bash
#
# run - run this instance of VistA

# Set up the environment for VistA
pushd `dirname $0` 1>/dev/null
export parent=$PWD/parent
source ./env
popd 1>/dev/null

if [[ -n $1 ]] ; then
$gtm_dist/mumps -run $1
else
$gtm_dist/mumps -dir
fi
</pre>

*The <tt>cprs_direct</tt> script handles connection requests from CPRS GUI client processes that come in via <tt>inetd</tt>/<tt>xinetd</tt>:

<pre>
#!/bin/bash
#
# cprs_direct - start a process to serve the CPRS Gui client

# Set up the environment for VistA
export HOME=/home/`whoami`
cd `dirname $0`
export parent=$PWD/parent
source ./env

# Run the server for the CPRS GUI client
cd tmp
$gtm_dist/mumps -run GTMLNX^XWBTCPM
</pre>

*When the <tt>install</tt> script is executed, it will create a development directory.

*Except for database files, journal files, and directories, the normal protection on all directories and files in an integration directory should be read-only. When promoting code to the integration directory from a development directory, or to install externally generated patches in the <tt>p</tt> subdirectory, needed directories should be made read-write, sources copied in, object file(s) generated, and directories again made read-only.

Below is a listing of the directory of an integration environment created from the release in the example above. Notice <tt>parent</tt> link pointing to the directory of the parent environment. (In this case, the <tt>gtm</tt> link points to the <tt>gtm</tt> link in the parent, rather than <tt>/opt/gtm_V5.0-000C</tt>. It doesn't matter either way.)

<pre>
bhaskar@Makaira:~$ ls -l /home/vista/LeonardoDaVistA0.1
total 48
-r-xr-xr-x 1 vista vista 216 Nov 22 09:28 cprs_direct
-r--r--r-- 1 vista vista 583 Nov 22 09:28 env
drwxrwxr-x 2 vista vista 4096 Nov 22 10:11 g
lrwxrwxrwx 1 vista vista 26 Nov 22 09:28 gtm -> /opt/FOIAVistA20051021/gtm
-r-xr-xr-x 1 vista vista 1832 Nov 22 10:44 install
drwxrwxr-x 2 vista vista 8192 Nov 22 09:33 o
drwxrwxr-x 2 vista vista 4096 Nov 22 09:28 p
lrwxrwxrwx 1 vista vista 22 Nov 22 09:28 parent -> /opt/FOIAVistA20051021
drwxrwxr-x 2 vista vista 8192 Nov 22 09:32 r
-r-xr-xr-x 1 vista vista 252 Nov 22 09:28 run
drwxrwxr-x 2 vista vista 4096 Nov 22 09:28 tmp
-r-xr-xr-x 1 vista vista 3633 Nov 22 09:28 vista
</pre>

==== VistA Development Directories ====

A development directory is like an integration directory, except that it does not normally have its own database file or global directory. However, as discussed above, it may be entirely appropriate for a development directory to have database files and global directories.

Indeed, since development directories are hierarchical – a development directory is an integration directory for development directories below it, and itself contributes to an integration directory above it, an integration directory is really nothing more than a development directory that does not itself contribute to an integration directory above it, but instead is used to create a release.

Note that although a GT.M database file can be opened by only one GT.M version at a time, it is quite easy to create a directory structure where Release A, the integration area, and each development area use different versions of GT.M. In the most common case, where the integration and development areas use a different version of GT.M from Release A, the only additional configuration requirement is to create a directory in the integration area for object files generated from the source files in Release A with the version of GT.M used for integration and development of Release B

Software Development (WG1) Version Control (T3)

2005-11-22T19:50:25Z

Bhaskar: /* VistA Integration Directories */

== Setting up a VistA Development Environment ==

=== Overview ===

This is a description of how VistA development environments should be configured.

<tt>Monospaced text</tt> designates program names, directory names, command line parameters, etc., that are intended to be typed in at a Linux shell or a GT.M prompt, e.g. <tt>/bin/bash</tt>. ''Italic text'' is a descriptor of something whose actual value must be determined when the command is typed, e.g., ''gtmver''.

=== Theory ===

A release is a collection of routines and global variables. The canonical packaging of a release, which is suitable for importation into any standard M distribution, is a collection of M source code routines and a database extract in ZWRite format. When installed on a system, to run with an M implementation, a release may have pre-compiled object files, database files, shell scripts, global directories, etc.

Below is a diagram of the “roll-up” by which a VistA release (“Release A”) gets converted into another VistA release (“Release B”) by a development team. A and B could be from different families, e.g., Release A could be a FOIA release and Release B could be a Leonardo da VistA release.

[[Image:051112-1WorldVistADevelopmentEnvironment_html_26096dee.gif|
"Roll up" model of VistA releases]]

Once Release A is installed, it remains frozen and unchanged except for any essential patches that may become available independent of the development process for creating Release B and without which the release lacks some required functionality. This means, for example, that KIDS patches should be applied in an integration environment rather than a release environment.

At any given time, there can be multiple development projects underway based on Release A. In other words, there may well be a Release C that is also based on Release A, but which has its own integration and development areas.

To start the development process, an integration directory is created and initialized with a copy of the global variables from Release A, as well as shell scripts, global directories, etc. The integration directory may well have a different name from Release A and Release B. For example, Release A may be FOIAVistA_20051021, Release B may become LeonardoDaVistA_0.4 (at the time that the integration area is created, the name and version of Release B may not even be decided yet), and the integration and development areas may be named Greenbelt_200510. There is no need to copy routines, since the GT.M search path will be set up to look for routines in the integration area before looking in Release A; hence only routines that are different between Release A and the new release need to be duplicated.

Actual development does not take place in the integration area. Development occurs in development areas, typically in the directories of individual developers; however, there may be a shared development area if two developers are collaborating on making changes to the very same module (i.e., their code changes overlap). A development area is set up by creating a directory structure, shell scripts, etc. Note that development areas can be hierarchical so that development subtasks 1a and 1b can be developed separately and integrated into development task 1, prior to integration into the integration area, etc.

During this development process, developers develop code in individual sand boxes (development areas), but normally share the database (global variables) in the integration area – there may typically be no need to create a separate database. However, if some global variable changes are tied to code changes being made in a development area, a copy of those global variables can be placed in a separate database file in that development area, and a global directory for that development area can map those global variables to the database in that development area, with all other global variables mapped to the database in the integration area.

When a developer has code that is ready for integration, the new versions of the modified routines are promoted to the integration area. Any global variables tied to the code being promoted that are in a database in the development area must be merged, reconciled or otherwise integrated with the global variables in the database in the integration area and the global directory in the development area modified accordingly. Note that there needs to be a process, e.g., involving code reviews, by which a development task is considered complete enough to be promoted. These, and other quality gates, are not discussed herein.

Creating a release is minimally the process of creating the directory structure for Release B, copying the routines from Release A, overlying the routines with those from the integration area, and copying the global variables from the integration area.

Normally, Release A, the integration area and development areas would all use the same GT.M version. However, this is not a requirement.

'''It is strongly recommended that database files in integration and development environments be journaled, and backed up regularly. It is also strongly recommended that a version control system such as CVS or subversion be used for integration areas.'''

=== Practice ===

==== Shell ====

The standard shell for VistA community scripting is bash (installed as <tt>/bin/bash</tt> on Debian GNU/Linux systems).

==== GT.M Release Directories ====

Each release of GT.M is installed its own subdirectory of <tt>/opt</tt> (preferred) or <tt>/usr/local</tt> (acceptable). Each directory name starts with <tt>gtm</tt> followed by a release number separated from the release name by an underscore (<tt>_</tt>). Thus, for example, GT.M V5.0-000C would be installed in <tt>/opt/gtm_V5.0-000C</tt>. <tt>/opt/gtm</tt> is a relative symbolic link to the latest version, set up with a command sequence such as:

cd /opt
rm -f gtm
ln -s gtm_V5.0-000C gtm

When installing GT.M, the file gtmprofile should be edited so that the line:

EDITOR="/bin/vi"; export EDITOR

is modified to read:

export EDITOR=${EDITOR:=/bin/vi}

==== VistA Release Directories ====

Each release is installed in its own sub-directory of a standard system location, such as <tt>/opt</tt> (preferred) or <tt>/usr/local</tt> (acceptable). Each directory has a release family name followed by a release / version number suffix separated from the release name by an underscore. Directories for releases without version numbers, such as FOIA releases, have a date suffix of the form ''yyyymmdd'' (and where appropriate just ''yyyymm''). For example, an August 25, 2005 FOIA release might be in <tt>/opt/FOIAVistA20050825</tt>, an October 21, 2005 release in <tt>/opt/FOIAVistA20051021</tt>, an OpenVistA 0.3 release in <tt>/opt/OpenVistA0.3</tt> and a Leonardo da VistA 0.45 release in <tt>/opt/LeonardoDaVistA0.45</tt>.

The normal protection on all directories and files in a release directory should be read-only. To install files in the <tt>p</tt> subdirectory, it should be made read-write, the source file(s) for the patch copied in, the object file(s) generated, and the directory and its contents again made read-only.

For each release family, the release directory contains subdirectories <tt>g</tt>, <tt>o</tt>, <tt>r</tt> and <tt>p</tt>, symbolic link <tt>gtm</tt>, a script <tt>install</tt>, scripts <tt>run</tt>, and <tt>cprs_direct</tt> that are not executable in a release directory, but which are used when copied to integration directories and made executable. A file <tt>env</tt> is used to set up the execution environment.

Other files and shell scripts may be created for various maintenance purposes (and ideally would be documented here).

*Subdirectory <tt>g</tt> contains a global directory file <tt>mumps.gld</tt> and a compressed database file <tt>mumps.dat.gz</tt>. The global directory maps all global variables to a single database file <tt>$vista_home/g/mumps.dat</tt> (i.e., the environment variable <tt>$vista_home</tt> is used at run-time to point a GT.M process to the location of the database file, so that different processes can actually use the same global directory to refer to entirely different database files).

*Subdirectories <tt>o</tt> and <tt>r</tt> correspond to directories for files containing routine object code and routine source code respectively. Each file in <tt>r</tt> ends in <tt>.m</tt> and has a corresponding file in <tt>o</tt> with a newer time stamp and which ends in <tt>.o</tt>.

*Subdirectory <tt>p</tt> contains source and object code for patches to a release (generated outside the scope of the work for creating Release B) and which are deemed to be essential for the proper functioning of the release.

*The symbolic link <tt>gtm</tt> points to the GT.M directory used for this VistA directory.

*The file <tt>env</tt> sets up the GT.M environment:

<pre>
# env - file to be sourced to create VistA environment
#
# This temporary version of the commands to set up the VistA
# environment assumes that the parent and child use the same
# version of GT.M.

if [[ -d parent ]] ; then
pushd parent 1>/dev/null
source ./env
popd 1>/dev/null
fi

if [[ -n $routines ]] ; then
export routines="$PWD/p $PWD/o($PWD/r) $routines"
else
export routines="$PWD/p $PWD/o($PWD/r)"
fi
if [[ -f $PWD/g/mumps.dat ]] ; then export vista_home=$PWD ; fi

source gtm/gtmprofile
export gtmgbldir=$PWD/g/mumps.gld
export gtmroutines="$routines $gtm_dist"
</pre>

*The script <tt>install</tt> creates a new integration directory to be used in creating a new release from this release. Normally, the initial database file of the integration directory is created by uncompressing <tt>mumps.dat.gz</tt>. Here is the script <tt>install</tt>:

<pre>
#!/bin/bash
#
# install - create new VistA environment as child of current environment
#
# This temporary version of the install script assumes that both
# have the same GT.M version. Also, there is no error handling yet,
# and no provision yet for a separate database on the child.
#
# Set up standard environment to run VistA

# Set up the environment for VistA
pushd `dirname $0` 1>/dev/null
export parent=$PWD
source ./env
popd 1>/dev/null
echo "Parent is" $parent

# Create the directory structure for the child
mkdir -p $1/{g,o,r,p,tmp}

# Link the child to the parent
ln -s $parent $1/parent

# Give the child the same GT.M version as the parent
ln -s $parent/gtm $1/gtm

# Copy other files in this directory
find $parent/ -maxdepth 1 -type f \! -name \*~ -exec cp {} $1/ \;

# Make run & cprs_direct executable because it may not be executable for the parent
chmod u+x $1/run $1/cprs_direct
find $1 -maxdepth 1 $ -name run -o -name cprs_direct $ -perm -4 -exec chmod o+x {} \;
find $1 -maxdepth 1 $ -name run -o -name cprs_direct $ -perm -40 -exec chmod g+x {} \;

# Give the child a global directory, for now the same as the parent
cp $parent/g/mumps.gld $1/g/mumps.gld

# Give the child a database
if [[ -e $parent/g/mumps.dat.gz ]] ; then
echo "Unzipping from parent to create initial database"
gzip -d <$parent/g/mumps.dat.gz >$1/g/mumps.dat
$gtm_dist/mupip set -journal="enable,on,before" -file $1/g/mumps.dat
chmod o+r,o-w,g+w $1/g/mumps.{dat,mjl}
else
echo "Using parent database in this environment"
fi

# Make files except database files, journal files & directories read-only
find $1 -type f \! -name \*.dat \! -name \*mjl -exec chmod a-w {} \;
find $1 -type d -exec chmod 775 {} \;

echo "Default permission for development environment is for all to read and group to write - please fix if needed"
</pre>

In a future enhancement, option <tt>--newgtm</tt> ''gtmver'', will specify that the integration directory is to be configured to run a different version of GT.M (as specified by the directory ''gtmver'') from the one used by the release. If <tt>--newgtm</tt> ''gtmver'' is used, the default assumption will be that the database will need to be extracted with the version of GT.M used by Release A, and loaded into a new database created with the version of GT.M to be used in the integration directory. When <tt>--newgtm</tt> ''gtmver'' is used, a an additional optional option <tt>--nonewdb</tt> will be available to specify that the releases of GT.M have compatible database formats, and that database from Release A can be used unchanged in the integration directory. Note that the use of <tt>--newgtm</tt> ''gtmver'' will almost certainly result in a command that takes a long time, because the database may need to be extracted and reloaded, and the routines recompiled.

Here is a listing of a top level release directory:

<pre>
bhaskar@Makaira:~$ ls -l /opt/FOIAVistA20051021
total 912
dr-xr-sr-x 2 root staff 4096 Sep 15 13:19 CPRS_Gui
-r-xr-xr-x 1 root staff 216 Nov 22 09:21 cprs_direct
-r--r--r-- 1 root staff 583 Nov 22 09:21 env
dr-xr-xr-x 2 root staff 4096 Oct 27 14:00 g
lrwxrwxrwx 1 root staff 18 Nov 22 09:26 gtm -> /opt/gtm_V5.0-000C
-r-xr-xr-x 1 root staff 1832 Nov 22 10:44 install
dr-xr-xr-x 2 root staff 446464 Nov 22 07:10 o
dr-xr-sr-x 2 root staff 4096 Nov 22 09:22 p
dr-xr-xr-x 2 root staff 446464 Oct 27 13:38 r
-r--r--r-- 1 root staff 252 Nov 22 09:21 run
-r-xr-xr-x 1 root staff 3633 Oct 30 06:42 vista
</pre>

==== VistA Integration Directories ====

A VistA integration directory is similar to a VistA release directory, with the following differences.

*Subdirectory <tt>g</tt> contains a database file, <tt>mumps.dat</tt>, rather than a compressed database file, <tt>mumps.dat.gz</tt>.

*The symbolic link <tt>parent</tt> points to the release directory from which this integration directory was created. A release directory does not have a symbolic link called parent. (The recommended way for a script to determine whether a directory is a release directory or an integration / development directory is to test for the existence of <tt>parent</tt>.)

*A script <tt>run</tt> which invokes and runs VistA in that integration environment. Note that a VistA release may physically include a <tt>run</tt> script, but it will not work because it is not possible to directly run VistA from a release directory. Here is the <tt>run</tt> script:

<pre>
#!/bin/bash
#
# run - run this instance of VistA

# Set up the environment for VistA
pushd `dirname $0` 1>/dev/null
export parent=$PWD/parent
source ./env
popd 1>/dev/null

if [[ -n $1 ]] ; then
$gtm_dist/mumps -run $1
else
$gtm_dist/mumps -dir
fi
</pre>

*The <tt>cprs_direct</tt> script handles connection requests from CPRS GUI client processes that come in via <tt>inetd</tt>/<tt>xinetd</tt>:

<pre>
#!/bin/bash
#
# cprs_direct - start a process to serve the CPRS Gui client

# Set up the environment for VistA
export HOME=/home/`whoami`
cd `dirname $0`
export parent=$PWD/parent
source ./env

# Run the server for the CPRS GUI client
cd tmp
$gtm_dist/mumps -run GTMLNX^XWBTCPM
</pre>

*When the <tt>install</tt> script is executed, it will create a development directory.

*Except for database files, journal files, and directories, the normal protection on all directories and files in an integration directory should be read-only. When promoting code to the integration directory from a development directory, or to install externally generated patches in the <tt>p</tt> subdirectory, needed directories should be made read-write, sources copied in, object file(s) generated, and directories again made read-only.

Below is a listing of the directory of an integration environment created from the release in the example above. Notice <tt>parent</tt> link pointing to the directory of the parent environment. (In this case, the <tt>gtm</tt> link points to the <tt>gtm</tt> link in the parent, rather than <tt>/opt/gtm_V5.0-000C</tt>. It doesn't matter either way.)

<pre>
bhaskar@Makaira:~$ ls -l /home/vista/LeonardoDaVistA0.1
total 48
-r-xr-xr-x 1 vista vista 216 Nov 22 09:28 cprs_direct
-r--r--r-- 1 vista vista 583 Nov 22 09:28 env
drwxrwxr-x 2 vista vista 4096 Nov 22 10:11 g
lrwxrwxrwx 1 vista vista 26 Nov 22 09:28 gtm -> /opt/FOIAVistA20051021/gtm
-r-xr-xr-x 1 vista vista 1832 Nov 22 10:44 install
drwxrwxr-x 2 vista vista 8192 Nov 22 09:33 o
drwxrwxr-x 2 vista vista 4096 Nov 22 09:28 p
lrwxrwxrwx 1 vista vista 22 Nov 22 09:28 parent -> /opt/FOIAVistA20051021
drwxrwxr-x 2 vista vista 8192 Nov 22 09:32 r
-r-xr-xr-x 1 vista vista 252 Nov 22 09:28 run
drwxrwxr-x 2 vista vista 4096 Nov 22 09:28 tmp
-r-xr-xr-x 1 vista vista 3633 Nov 22 09:28 vista
</pre>

==== VistA Development Directories ====

A development directory is like an integration directory, except that it does not normally have its own database file or global directory. However, as discussed above, it may be entirely appropriate for a development directory to have database files and global directories.

Indeed, since development directories are hierarchical – a development directory is an integration directory for development directories below it, and itself contributes to an integration directory above it, an integration directory is really nothing more than a development directory that does not itself contribute to an integration directory above it, but instead is used to create a release.

Note that although a GT.M database file can be opened by only one GT.M version at a time, it is quite easy to create a directory structure where Release A, the integration area, and each development area use different versions of GT.M. In the most common case, where the integration and development areas use a different version of GT.M from Release A, the only additional configuration requirement is to create a directory in the integration area for object files generated from the source files in Release A with the version of GT.M used for integration and development of Release B

Software Development (WG1) Version Control (T3)

2005-11-22T18:15:34Z

Bhaskar: /* VistA Release Directories */

== Setting up a VistA Development Environment ==

=== Overview ===

This is a description of how VistA development environments should be configured.

<tt>Monospaced text</tt> designates program names, directory names, command line parameters, etc., that are intended to be typed in at a Linux shell or a GT.M prompt, e.g. <tt>/bin/bash</tt>. ''Italic text'' is a descriptor of something whose actual value must be determined when the command is typed, e.g., ''gtmver''.

=== Theory ===

A release is a collection of routines and global variables. The canonical packaging of a release, which is suitable for importation into any standard M distribution, is a collection of M source code routines and a database extract in ZWRite format. When installed on a system, to run with an M implementation, a release may have pre-compiled object files, database files, shell scripts, global directories, etc.

Below is a diagram of the “roll-up” by which a VistA release (“Release A”) gets converted into another VistA release (“Release B”) by a development team. A and B could be from different families, e.g., Release A could be a FOIA release and Release B could be a Leonardo da VistA release.

[[Image:051112-1WorldVistADevelopmentEnvironment_html_26096dee.gif|
"Roll up" model of VistA releases]]

Once Release A is installed, it remains frozen and unchanged except for any essential patches that may become available independent of the development process for creating Release B and without which the release lacks some required functionality. This means, for example, that KIDS patches should be applied in an integration environment rather than a release environment.

At any given time, there can be multiple development projects underway based on Release A. In other words, there may well be a Release C that is also based on Release A, but which has its own integration and development areas.

To start the development process, an integration directory is created and initialized with a copy of the global variables from Release A, as well as shell scripts, global directories, etc. The integration directory may well have a different name from Release A and Release B. For example, Release A may be FOIAVistA_20051021, Release B may become LeonardoDaVistA_0.4 (at the time that the integration area is created, the name and version of Release B may not even be decided yet), and the integration and development areas may be named Greenbelt_200510. There is no need to copy routines, since the GT.M search path will be set up to look for routines in the integration area before looking in Release A; hence only routines that are different between Release A and the new release need to be duplicated.

Actual development does not take place in the integration area. Development occurs in development areas, typically in the directories of individual developers; however, there may be a shared development area if two developers are collaborating on making changes to the very same module (i.e., their code changes overlap). A development area is set up by creating a directory structure, shell scripts, etc. Note that development areas can be hierarchical so that development subtasks 1a and 1b can be developed separately and integrated into development task 1, prior to integration into the integration area, etc.

During this development process, developers develop code in individual sand boxes (development areas), but normally share the database (global variables) in the integration area – there may typically be no need to create a separate database. However, if some global variable changes are tied to code changes being made in a development area, a copy of those global variables can be placed in a separate database file in that development area, and a global directory for that development area can map those global variables to the database in that development area, with all other global variables mapped to the database in the integration area.

When a developer has code that is ready for integration, the new versions of the modified routines are promoted to the integration area. Any global variables tied to the code being promoted that are in a database in the development area must be merged, reconciled or otherwise integrated with the global variables in the database in the integration area and the global directory in the development area modified accordingly. Note that there needs to be a process, e.g., involving code reviews, by which a development task is considered complete enough to be promoted. These, and other quality gates, are not discussed herein.

Creating a release is minimally the process of creating the directory structure for Release B, copying the routines from Release A, overlying the routines with those from the integration area, and copying the global variables from the integration area.

Normally, Release A, the integration area and development areas would all use the same GT.M version. However, this is not a requirement.

'''It is strongly recommended that database files in integration and development environments be journaled, and backed up regularly. It is also strongly recommended that a version control system such as CVS or subversion be used for integration areas.'''

=== Practice ===

==== Shell ====

The standard shell for VistA community scripting is bash (installed as <tt>/bin/bash</tt> on Debian GNU/Linux systems).

==== GT.M Release Directories ====

Each release of GT.M is installed its own subdirectory of <tt>/opt</tt> (preferred) or <tt>/usr/local</tt> (acceptable). Each directory name starts with <tt>gtm</tt> followed by a release number separated from the release name by an underscore (<tt>_</tt>). Thus, for example, GT.M V5.0-000C would be installed in <tt>/opt/gtm_V5.0-000C</tt>. <tt>/opt/gtm</tt> is a relative symbolic link to the latest version, set up with a command sequence such as:

cd /opt
rm -f gtm
ln -s gtm_V5.0-000C gtm

When installing GT.M, the file gtmprofile should be edited so that the line:

EDITOR="/bin/vi"; export EDITOR

is modified to read:

export EDITOR=${EDITOR:=/bin/vi}

==== VistA Release Directories ====

Each release is installed in its own sub-directory of a standard system location, such as <tt>/opt</tt> (preferred) or <tt>/usr/local</tt> (acceptable). Each directory has a release family name followed by a release / version number suffix separated from the release name by an underscore. Directories for releases without version numbers, such as FOIA releases, have a date suffix of the form ''yyyymmdd'' (and where appropriate just ''yyyymm''). For example, an August 25, 2005 FOIA release might be in <tt>/opt/FOIAVistA20050825</tt>, an October 21, 2005 release in <tt>/opt/FOIAVistA20051021</tt>, an OpenVistA 0.3 release in <tt>/opt/OpenVistA0.3</tt> and a Leonardo da VistA 0.45 release in <tt>/opt/LeonardoDaVistA0.45</tt>.

The normal protection on all directories and files in a release directory should be read-only. To install files in the <tt>p</tt> subdirectory, it should be made read-write, the source file(s) for the patch copied in, the object file(s) generated, and the directory and its contents again made read-only.

For each release family, the release directory contains subdirectories <tt>g</tt>, <tt>o</tt>, <tt>r</tt> and <tt>p</tt>, symbolic link <tt>gtm</tt>, a script <tt>install</tt>, scripts <tt>run</tt>, and <tt>cprs_direct</tt> that are not executable in a release directory, but which are used when copied to integration directories and made executable. A file <tt>env</tt> is used to set up the execution environment.

Other files and shell scripts may be created for various maintenance purposes (and ideally would be documented here).

*Subdirectory <tt>g</tt> contains a global directory file <tt>mumps.gld</tt> and a compressed database file <tt>mumps.dat.gz</tt>. The global directory maps all global variables to a single database file <tt>$vista_home/g/mumps.dat</tt> (i.e., the environment variable <tt>$vista_home</tt> is used at run-time to point a GT.M process to the location of the database file, so that different processes can actually use the same global directory to refer to entirely different database files).

*Subdirectories <tt>o</tt> and <tt>r</tt> correspond to directories for files containing routine object code and routine source code respectively. Each file in <tt>r</tt> ends in <tt>.m</tt> and has a corresponding file in <tt>o</tt> with a newer time stamp and which ends in <tt>.o</tt>.

*Subdirectory <tt>p</tt> contains source and object code for patches to a release (generated outside the scope of the work for creating Release B) and which are deemed to be essential for the proper functioning of the release.

*The symbolic link <tt>gtm</tt> points to the GT.M directory used for this VistA directory.

*The file <tt>env</tt> sets up the GT.M environment:

<pre>
# env - file to be sourced to create VistA environment
#
# This temporary version of the commands to set up the VistA
# environment assumes that the parent and child use the same
# version of GT.M.

if [[ -d parent ]] ; then
pushd parent 1>/dev/null
source ./env
popd 1>/dev/null
fi

if [[ -n $routines ]] ; then
export routines="$PWD/p $PWD/o($PWD/r) $routines"
else
export routines="$PWD/p $PWD/o($PWD/r)"
fi
if [[ -f $PWD/g/mumps.dat ]] ; then export vista_home=$PWD ; fi

source gtm/gtmprofile
export gtmgbldir=$PWD/g/mumps.gld
export gtmroutines="$routines $gtm_dist"
</pre>

*The script <tt>install</tt> creates a new integration directory to be used in creating a new release from this release. Normally, the initial database file of the integration directory is created by uncompressing <tt>mumps.dat.gz</tt>. Here is the script <tt>install</tt>:

<pre>
#!/bin/bash
#
# install - create new VistA environment as child of current environment
#
# This temporary version of the install script assumes that both
# have the same GT.M version. Also, there is no error handling yet,
# and no provision yet for a separate database on the child.
#
# Set up standard environment to run VistA

# Set up the environment for VistA
pushd `dirname $0` 1>/dev/null
export parent=$PWD
source ./env
popd 1>/dev/null
echo "Parent is" $parent

# Create the directory structure for the child
mkdir -p $1/{g,o,r,p,tmp}

# Link the child to the parent
ln -s $parent $1/parent

# Give the child the same GT.M version as the parent
ln -s $parent/gtm $1/gtm

# Copy other files in this directory
find $parent/ -maxdepth 1 -type f \! -name \*~ -exec cp {} $1/ \;

# Make run & cprs_direct executable because it may not be executable for the parent
chmod u+x $1/run $1/cprs_direct
find $1 -maxdepth 1 $ -name run -o -name cprs_direct $ -perm -4 -exec chmod o+x {} \;
find $1 -maxdepth 1 $ -name run -o -name cprs_direct $ -perm -40 -exec chmod g+x {} \;

# Give the child a global directory, for now the same as the parent
cp $parent/g/mumps.gld $1/g/mumps.gld

# Give the child a database
if [[ -e $parent/g/mumps.dat.gz ]] ; then
echo "Unzipping from parent to create initial database"
gzip -d <$parent/g/mumps.dat.gz >$1/g/mumps.dat
$gtm_dist/mupip set -journal="enable,on,before" -file $1/g/mumps.dat
chmod o+r,o-w,g+w $1/g/mumps.{dat,mjl}
else
echo "Using parent database in this environment"
fi

# Make files except database files, journal files & directories read-only
find $1 -type f \! -name \*.dat \! -name \*mjl -exec chmod a-w {} \;
find $1 -type d -exec chmod 775 {} \;

echo "Default permission for development environment is for all to read and group to write - please fix if needed"
</pre>

In a future enhancement, option <tt>--newgtm</tt> ''gtmver'', will specify that the integration directory is to be configured to run a different version of GT.M (as specified by the directory ''gtmver'') from the one used by the release. If <tt>--newgtm</tt> ''gtmver'' is used, the default assumption will be that the database will need to be extracted with the version of GT.M used by Release A, and loaded into a new database created with the version of GT.M to be used in the integration directory. When <tt>--newgtm</tt> ''gtmver'' is used, a an additional optional option <tt>--nonewdb</tt> will be available to specify that the releases of GT.M have compatible database formats, and that database from Release A can be used unchanged in the integration directory. Note that the use of <tt>--newgtm</tt> ''gtmver'' will almost certainly result in a command that takes a long time, because the database may need to be extracted and reloaded, and the routines recompiled.

Here is a listing of a top level release directory:

<pre>
bhaskar@Makaira:~$ ls -l /opt/FOIAVistA20051021
total 912
dr-xr-sr-x 2 root staff 4096 Sep 15 13:19 CPRS_Gui
-r-xr-xr-x 1 root staff 216 Nov 22 09:21 cprs_direct
-r--r--r-- 1 root staff 583 Nov 22 09:21 env
dr-xr-xr-x 2 root staff 4096 Oct 27 14:00 g
lrwxrwxrwx 1 root staff 18 Nov 22 09:26 gtm -> /opt/gtm_V5.0-000C
-r-xr-xr-x 1 root staff 1832 Nov 22 10:44 install
dr-xr-xr-x 2 root staff 446464 Nov 22 07:10 o
dr-xr-sr-x 2 root staff 4096 Nov 22 09:22 p
dr-xr-xr-x 2 root staff 446464 Oct 27 13:38 r
-r--r--r-- 1 root staff 252 Nov 22 09:21 run
-r-xr-xr-x 1 root staff 3633 Oct 30 06:42 vista
</pre>

==== VistA Integration Directories ====

A VistA integration directory is similar to a VistA release directory, with the following differences.

*Subdirectory <tt>g</tt> contains a database file, <tt>mumps.dat</tt>, rather than a compressed database file, <tt>mumps.dat.gz</tt>.

*The symbolic link <tt>parent</tt> points to the release directory from which this integration directory was created. A release directory does not have a symbolic link called parent. (The recommended way for a script to determine whether a directory is a release directory or an integration / development directory is to test for the existence of <tt>parent</tt>.)

*A script <tt>run</tt> which invokes and runs VistA in that integration environment. Note that a VistA release may physically include a <tt>run</tt> script, but it will not work because it is not possible to directly run VistA from a release directory.

*When the <tt>install</tt> script is executed, it will create a development directory.

*The normal protection on all directories and files in an integration directory should be read-only. When promoting code to the integration directory from a development directory, or to install externally generated patches in the <tt>p</tt> subdirectory, needed directories should be made read-write, sources copied in, object file(s) generated, and directories again made read-only.

==== VistA Development Directories ====

A development directory is like an integration directory, except that it does not normally have its own database file or global directory. However, as discussed above, it may be entirely appropriate for a development directory to have database files and global directories.

Indeed, since development directories are hierarchical – a development directory is an integration directory for development directories below it, and itself contributes to an integration directory above it, an integration directory is really nothing more than a development directory that does not itself contribute to an integration directory above it, but instead is used to create a release.

Note that although a GT.M database file can be opened by only one GT.M version at a time, it is quite easy to create a directory structure where Release A, the integration area, and each development area use different versions of GT.M. In the most common case, where the integration and development areas use a different version of GT.M from Release A, the only additional configuration requirement is to create a directory in the integration area for object files generated from the source files in Release A with the version of GT.M used for integration and development of Release B

Software Development (WG1) Version Control (T3)

2005-11-22T17:45:50Z

Bhaskar: /* VistA Release Directories */

Software Development (WG1) Version Control (T3)

2005-11-22T04:32:27Z

Bhaskar: /* VistA Release Directories */

Installation Overview

2005-11-17T21:51:55Z

Bhaskar:

The documentation for VistA and OpenVistA can be classified in several groups:
== Getting the software ==
This is the VA ftp site for VistA: ftp://ftp.va.gov/VistA/

This link is specifically for software: ftp://ftp.va.gov/VistA/Software/

For the open source free software stack for VistA: http://sourceforge.net/projects/worldvista

== Installation Documentation created by WorldVistA and volunteers in the VistA Community. ==

=== Getting up and running with the VistA open source free software ([http://en.wikipedia.org/wiki/Free_and_Open_Source_Software FOSS]) stack ===

The complete FOSS stack for VistA consists of VistA on [http://www.sanchez-gtm.com GT.M] on [http://www.wikipedia.org/wiki/Linux GNU/Linux] on industry standard x86 server hardware. Although it is certainly possible to install this stack by downloading VistA, and installing it on GT.M on x86 GNU/Linux, it is much easier to start with a pre-configured software stack. There are (at least) two flavors of VistA, and two types of packages of VistA on GT.M.

VistA flavors:

*'''FOIA VistA''' is VistA as periodically released by the [http://www.va.gov US Department of Veterans Affairs] under the [http://www.usdoj.gov/oip/foia_updates/Vol_XVII_4/page2.htm Freedom of Information Act (FOIA).] This is sometimes referrd to as the "gold standard". Prior versions of this software at the [http://sourceforge.net/projects/worldvista WorldVistA project page at Source Forge] are labelled OpenVistA FOIA Gold. FOIA VistA releases are numbered by the date on which they are released under FOIA, e.g., 20051021 for Oct 21, 2005.

*'''Leonardo da VistA''' is FOIA VistA as enhanced by the VistA community. '''Leonardo da VistA is used here as strictly an interim, temporary, just-until-the-new-name-is-announced name.''' This software was previously known to the community first as "Hui OpenVistA", and then as just "OpenVistA". The subsequent grant by the US Patent and Trademark Office of a registered trademark of that name to a corporation has triggered a search for a replacement name, and Leonardo da VistA is used here until the new name is announced. Prior releases of this software at the [http://sourceforge.net/projects/worldvista WorldVistA project page at Source Forge] are labelled OpenVistA. Leonardo da VistA releases have numbers such as 0.4.

*'''OpenVistA VA Demo''' is a one-of release of a configuration of VistA intended to demonstrate the CPRS GUI, but not to be otherwise useful, and not part of a family of releases.

In the future, it is hoped that there will be other flavors, e.g., VistA Office EHR.

Types of packages:

*A '''SemiVivA''' package consists of VistA and GT.M bundled together and ready to be installed on an x86 GNU/Linux server.

*A '''VivA''' or '''VivitA'''package is a [http://en.wikipedia.org/wiki/Linux_live_cd live CD (or DVD)] that can be booted on any x86 architecture server to run the entire VistA FOSS stack. VivitA releases are created by mastering [http://damnsmalllinux.org DSL] and the VivA releases are created by remastering either [http://knopper.net/knoppix/index-en.html Knoppix] or [http://morphix.org Morphix].

SemiVivA packages expect to find [http://xdialog.dyns.net Xdialog] on the computer. To use a SemiVivA package, download it to a temporary directory (e.g., as <tt>/tmp/LeonardoDaVistASemiVivA0.4.tgz</tt>). Then, '''as root''' execute:

cd /usr/local
tar zxvf /tmp/LeonardoDaVistASemiVivA0.4.tgz

This will install VistA and GT.M. To use it, an environment with an initial copy of the database must be created with the command:

/usr/local/LeonardoDaVistA/vista --install ''directory''

In the above, substitute the actual VistA release name (e.g., OpenVistA, FOIAVistA) for LeonardoDaVistA. ''directory'' is the full path name of a directory (without a trailing slash) where the environment with the initial copy of the database is to be created, e.g., <tt>/home/vista/myVistA</tt>. To subsequently run VistA, VivitAs again have an option from the mouse on the background. For VivAs, use:

/usr/local/LeonardoDaVistA/vista --run ''directory''

To use a VivA or VivitA package, read/write storage is required for the database. The current distributions can use a Linux file system (e.g., ext3, reiserfs) or a FAT file system (Windows 95/98/ME) but not an NTFS file system (Windows NT/2000/XP/2003). The live CD/DVDs have tools needed to partition a hard drive and create a new file system. The easiest way to proceed is to simply plug a 512MB or bigger USB flash or thumb drive (or a USB hard drive) into the USB port (USB 2.0 preferred) of an x86 server, and boot the CD/DVD. The instructions below are for USB drives, but apply equally well - with appropriate names for the read/write storage - for IDE and SCSI drives.

*After booting the operating system, you will need to mount the read/write storage. For Knoppix based VivA releases, right click on the icon for the drive and mount the drive. This mounts it read-only. Right click again, choose Actions and change the mode to read/write. Note the name of the drive; it will probably be something like <tt>/mnt/uba1</tt> or <tt>/mnt/sda1</tt>. For DSL based VivitA releases, there is a small window in the lower right of the screen with a mounting applet. Immediately after boot up, it will say ''floppy''. Click on the arrow icons within the applet to choose ''sda1'' or other read/write storage, and then click on the icon in the applet to mount the drive. For (older) Morphix based releases, execute:

sudo insmod usb-storage
mount /mnt/sda1

*You will need to create an environment with an initial copy of the database. VivitAs have an option from the "start menu" from clicking the right mouse button on the background. On VivA releases, start a shell, and execute (as before, use the actual name of your VistA):

/usr/local/LeonardoDaVistA/vista --install ''directory''

*To subsequently run VistA, VivitAs again have an option from the mouse on the background. For VivAs, use:

/usr/local/LeonardoDaVistA/vista --run ''directory''

When the GT.M prompt (<tt>GTM></tt>) appears, you have a VistA environment that is ready to start configuring.

== Installation Documentation from sofware and hardware vendors of VistA and OpenVistA. ==

== Installation Documentation from the [[VistA Documentation Library]] (VDL) ==

=== Clinical ===
<TABLE summary="This table is for formatting purposes only." class = "toc" cellpadding="5" border="">
<TR>
<td>[[Installation of Admission Discharge Transfer (ADT)]]</TD>
<td>[[Installation of Electronic Wait List]]</TD>
<td>[[Installation of Medicine]]</TD>
<td>[[Installation of Pharmacy Prescription Practices (PPP)]]</TD>
</TR><TR>
<td>[[Installation of Ambulatory Care Reporting]]</TD>
<td>[[Installation of Functional Independence Measurement (FIM)]]</TD>
<td>[[Installation of Mental Health]]</TD>
<td>[[Installation of Primary Care Management Module (PCMM)]]</TD>
</TR><TR>
<td>[[Installation of Beneficiary Travel]]</TD>
<td>[[Installation of Group Notes]]</TD>
<td>[[Installation of Nursing]]</TD>
<td>[[Installation of Prosthestics]]</TD>
</TR><TR>
<td>[[Installation of Care Management]]</TD>
<td>[[Installation of Home Based Primary Care (HBPC)]]</TD>
<td>[[Installation of Oncology]]</TD>
<td>[[Installation of Quality Audiology Speech Anal & Rpting (QUASAR)]]</TD>
</TR><TR>
<td>[[Installation of Clinical Case Registries]]</TD>
<td>[[Installation of Immunology Case Registry (ICR)]]</TD>
<td>[[Installation of Patient Care Encounter (PCE)]]</TD>
<td>[[Installation of Radiology / Nuclear Medicine]]</TD>
</TR><TR>
<td>[[Installation of Clinical Procedures]]</TD>
<td>[[Installation of Incomplete Records Tracking (IRT)]]</TD>
<td>[[Installation of Pharmacy Automatic Replenish / Ward Stock (AR/WS)]]</TD>
<td>[[Installation of RAI/MDS]]</TD>
</TR><TR>
<td>[[Installation of Computerized Patient Record System (CPRS)]]</TD>
<td>[[Installation of Intake and Output]]</TD>
<td>[[Installation of Pharmacy Bar Code Medication Administration (BCMA)]]</TD>
<td>[[Installation of Remote Order Entry System (ROES)]]</TD>
</TR><TR>
<td>[[Installation of CPRS Adverse Reaction Tracking (ART)]]</TD>
<td>[[Installation of Laboratory Anatomic Pathology]]</TD>
<td>[[Installation of Pharmacy Benefits Management (PBM)]]</TD>
<td>[[Installation of Scheduling]]</TD>
</TR><TR>
<td>[[Installation of CPRS Authorization Subscription Utility (ASU)]]</TD>
<td>[[Installation of Laboratory Blood Bank]]</TD>
<td>[[Installation of Pharmacy Consolidated Mail Outpatient Pharmacy]]</TD>
<td>[[Installation of Social Work]]</TD>
</TR><TR>
<td>[[Installation of CPRS Clinical Reminders]]</TD>
<td>[[Installation of Laboratory Blood Bank Workarounds]]</TD>
<td>[[Installation of Pharmacy Controlled Substances]]</TD>
<td>[[Installation of Spinal Cord Dysfunction]]</TD>
</TR><TR>
<td>[[Installation of CPRS Consult/Request Tracking]]</TD>
<td>[[Installation of Laboratory Electronic Data Interchange (LEDI)]]</TD>
<td>[[Installation of Pharmacy Data Management (PDM)]]</TD>
<td>[[Installation of Surgery]]</TD>
</TR><TR>
<td>[[Installation of CPRS Health Summary]]</TD>
<td>[[Installation of Laboratory Emerging Pathogens Initiative]]</TD>
<td>[[Installation of Pharmacy Drug Accountability]]</TD>
<td>[[Installation of VISTA Imaging System]]</TD>
</TR><TR>
<td>[[Installation of CPRS Problem List]]</TD>
<td>[[Installation of Laboratory National Laboratory Tests/ LOINC Request Form]]</TD>
<td>[[Installation of Pharmacy Electronic Claims Management Engine (ECME)]]</TD>
<td>[[Installation of Visual Impairment Service Team (VIST)]]</TD>
</TR><TR>
<td>[[Installation of CPRS Text Integration Utility (TIU)]]</TD>
<td>[[Installation of Laboratory Universal Interface]]</TD>
<td>[[Installation of Pharmacy Inpatient Medications]]</TD>
<td>[[Installation of Vitals / Measurements]]</TD>
</TR><TR>
<td>[[Installation of Dentistry]]</TD>
<td>[[Installation of Laboratory]]</TD>
<td>[[Installation of Pharmacy National Drug File (NDF)]]</TD>
<td>[[Installation of Women's Health]]</TD>
</TR><TR>
<td>[[Installation of Dietetics]]</TD>
<td>[[Installation of Lexicon Utility]]</TD>
<td>[[Installation of Pharmacy Outpatient Pharmacy]]</TD>
</TR></TABLE>
=== Infrastructure ===
<TABLE summary="This table is for formatting purposes only." class = "toc" cellpadding="5" border="">
<TR>
<td>[[Installation of Capacity Management Tools]]</TD>
<td>[[Installation of Kernel Delphi Components (KDC)]]</TD>
<td>[[Installation of Minimal Patient Dataset (MPD)]]</TD>
<td>[[Installation of SlotMaster (Kernel ZSLOT)]]</TD>
</TR><TR>
<td>[[Installation of Duplicate Record Merge- Patient Merge]]</TD>
<td>[[Installation of Kernel Installation and Distribution System (KIDS)]]</TD>
<td>[[Installation of Name Standardization]]</TD>
<td>[[Installation of SQL Interface (SQLI)]]</TD>
</TR><TR>
<td>[[Installation of Electronic Error and Enhancement Reporting (E3R)]]</TD>
<td>[[Installation of Kernel Toolkit]]</TD>
<td>[[Installation of National Online Information Sharing (NOIS)]]</TD>
<td>[[Installation of Standard Files and Tables]]</TD>
</TR><TR>
<td>[[Installation of FileMan]]</TD>
<td>[[Installation of Kernel Unwinder]]</TD>
<td>[[Installation of National Patch Module]]</TD>
<td>[[Installation of Statistical Analysis of Global Growth (SAGG)]]</TD>
</TR><TR>
<td>[[Installation of FileMan Delphi Components (FMDC)]]</TD>
<td>[[Installation of List Manager]]</TD>
<td>[[Installation of Network Health Exchange (NHE)]]</TD>
<td>[[Installation of Survey Generator]]</TD>
</TR><TR>
<td>[[Installation of HL7 (VistA Messaging)]]</TD>
<td>[[Installation of M-to-M Broker]]</TD>
<td>[[Installation of Patient Data Exchange (PDX)]]</TD>
<td>[[Installation of VistA Data Extraction Framework (VDEF)]]</TD>
</TR><TR>
<td>[[Installation of Institution File Redesign (IFR)]]</TD>
<td>[[Installation of MailMan]]</TD>
<td>[[Installation of Remote Procedure Call (RPC) Broker]]</TD>
<td>[[Installation of XML Parser (VistA)]]</TD>
</TR><TR>
<td>[[Installation of Kernel]]</TD>
<td>[[Installation of Master Patient Index (MPI)]]</TD>
<td>[[Installation of Resource Usage Monitor]]</TD>
</TR></TABLE>
=== Financial-Administrative ===
<TABLE summary="This table is for formatting purposes only." class = "toc" cellpadding="5" border="">
<TR>
<td>[[Installation of Accounts Receivable (AR)]]</TD>
<td>[[Installation of Engineering (AEMS / MERS)]]</TD>
<td>[[Installation of IFCAP]]</TD>
<td>[[Installation of Patient Representative]]</TD>
</TR><TR>
<td>[[Installation of Auto Safety Incdnt Surv Trak Sys (ASISTS)]]</TD>
<td>[[Installation of Enrollment Application System]]</TD>
<td>[[Installation of Incident Reporting]]</TD>
<td>[[Installation of Personnel and Accounting Integrated Data (PAID)]]</TD>
</TR><TR>
<td>[[Installation of Automated Information Collection System (AICS)]]</TD>
<td>[[Installation of Equipment / Turn-In Request]]</TD>
<td>[[Installation of Income Verification Match (IVM)]]</TD>
<td>[[Installation of Police and Security]]</TD>
</TR><TR>
<td>[[Installation of Automated Medical Information Exchange (AMIE)]]</TD>
<td>[[Installation of Event Capture]]</TD>
<td>[[Installation of Integrated Billing (IB)]]</TD>
<td>[[Installation of Quality Management Integration Module]]</TD>
</TR><TR>
<td>[[Installation of Clinical Monitoring System]]</TD>
<td>[[Installation of Fee Basis]]</TD>
<td>[[Installation of Integrated Patient Funds]]</TD>
<td>[[Installation of Record Tracking]]</TD>
</TR><TR>
<td>[[Installation of Compensation & Pension Records Interchange (CAPRI)]]</TD>
<td>[[Installation of Generic Code Sheet (GCS)]]</TD>
<td>[[Installation of Library]]</TD>
<td>[[Installation of Release of Information (ROI) Manager]]</TD>
</TR><TR>
<td>[[Installation of Current Procedural Terminology (CPT)]]</TD>
<td>[[Installation of Health Eligibility Center (HEC)]]</TD>
<td>[[Installation of Missing Patient Register]]</TD>
<td>[[Installation of Veterans Identification Card (VIC/PICS)]]</TD>
</TR><TR>
<td>[[Installation of Decision Support System (DSS) Extracts]]</TD>
<td>[[Installation of Hospital Inquiry (HINQ)]]</TD>
<td>[[Installation of Occurrence Screen]]</TD>
<td>[[Installation of Voluntary Service System (VSS)]]</TD>
</TR><TR>
<td>[[Installation of Diagnostic Related Group (DRG) Grouper]]</TD>
<td>[[Installation of ICD-9-CM]]</TD>
</TR></TABLE>

Installation Overview

2005-11-17T21:34:33Z

Bhaskar: /* Installation Documentation created by WorldVistA and volunteers in the VistA Community. */

The documentation for VistA and OpenVistA can be classified in several groups:
== Getting the software ==
This is the VA ftp site for VistA: ftp://ftp.va.gov/VistA/

This link is specifically for software: ftp://ftp.va.gov/VistA/Software/

For the open source free software stack for VistA: http://sourceforge.net/projects/worldvista

== Installation Documentation created by WorldVistA and volunteers in the VistA Community. ==

=== Getting up and running with the VistA open source free software ([http://en.wikipedia.org/wiki/Free_and_Open_Source_Software FOSS]) stack ===

The complete FOSS stack for VistA consists of VistA on [http://www.sanchez-gtm.com GT.M] on [http://www.wikipedia.org/wiki/Linux GNU/Linux] on industry standard x86 server hardware. Although it is certainly possible to install this stack by downloading VistA, and installing it on GT.M on x86 GNU/Linux, it is much easier to start with a pre-configured software stack. There are (at least) two flavors of VistA, and two types of packages of VistA on GT.M.

VistA flavors:

*'''FOIA VistA''' is VistA as periodically released by the [http://www.va.gov US Department of Veterans Affairs] under the [http://www.usdoj.gov/oip/foia_updates/Vol_XVII_4/page2.htm Freedom of Information Act (FOIA).] This is sometimes referrd to as the "gold standard". Prior versions of this software at the [http://sourceforge.net/projects/worldvista WorldVistA project page at Source Forge] are labelled OpenVistA FOIA Gold.

*'''Leonardo da VistA''' is FOIA VistA as enhanced by the VistA community. '''Leonardo da VistA is used here as strictly an interim, temporary, just-until-the-new-name-is-announced name.''' This software was previously known to the community first as "Hui OpenVistA", and then as just "OpenVistA". The subsequent grant by the US Patent and Trademark Office of a registered trademark of that name to a corporation has triggered a search for a replacement name, and Leonardo da VistA is used here until the new name is announced. Prior releases of this software at the [http://sourceforge.net/projects/worldvista WorldVistA project page at Source Forge] are labelled OpenVistA.

Types of packages:

*A '''SemiVivA''' package consists of VistA and GT.M bundled together and ready to be installed on an x86 GNU/Linux server.

*A '''VivA''' or '''VivitA'''package is a [http://en.wikipedia.org/wiki/Linux_live_cd live CD (or DVD)] that can be booted on any x86 architecture server to run the entire VistA FOSS stack. VivitA releases are created by mastering [http://damnsmalllinux.org DSL] and the VivA releases are created by remastering either [http://knopper.net/knoppix/index-en.html Knoppix] or [http://morphix.org Morphix].

SemiVivA packages expect to find [http://xdialog.dyns.net Xdialog] on the computer. To use a SemiVivA package, download it to a temporary directory (e.g., as <tt>/tmp/LeonardoDaVistASemiVivA0.4.tgz</tt>). Then, '''as root''' execute:

cd /usr/local
tar zxvf /tmp/LeonardoDaVistASemiVivA0.4.tgz

This will install VistA and GT.M. To use it, an environment with an initial copy of the database must be created with the command:

/usr/local/LeonardoDaVistA/vista --install ''directory''

In the above, substitute the actual VistA release name (e.g., OpenVistA, FOIAVistA) for LeonardoDaVistA. ''directory'' is the full path name of a directory (without a trailing slash) where the environment with the initial copy of the database is to be created, e.g., <tt>/home/vista/myVistA</tt>. To subsequently run VistA, VivitAs again have an option from the mouse on the background. For VivAs, use:

/usr/local/LeonardoDaVistA/vista --run ''directory''

To use a VivA or VivitA package, read/write storage is required for the database. The current distributions can use a Linux file system (e.g., ext3, reiserfs) or a FAT file system (Windows 95/98/ME) but not an NTFS file system (Windows NT/2000/XP/2003). The live CD/DVDs have tools needed to partition a hard drive and create a new file system. The easiest way to proceed is to simply plug a 512MB or bigger USB flash or thumb drive (or a USB hard drive) into the USB port (USB 2.0 preferred) of an x86 server, and boot the CD/DVD. The instructions below are for USB drives, but apply equally well - with appropriate names for the read/write storage - for IDE and SCSI drives.

*After booting the operating system, you will need to mount the read/write storage. For Knoppix based VivA releases, right click on the icon for the drive and mount the drive. This mounts it read-only. Right click again, choose Actions and change the mode to read/write. Note the name of the drive; it will probably be something like <tt>/mnt/uba1</tt> or <tt>/mnt/sda1</tt>. For DSL based VivitA releases, there is a small window in the lower right of the screen with a mounting applet. Immediately after boot up, it will say ''floppy''. Click on the arrow icons within the applet to choose ''sda1'' or other read/write storage, and then click on the icon in the applet to mount the drive. For (older) Morphix based releases, execute:

sudo insmod usb-storage
mount /mnt/sda1

*You will need to create an environment with an initial copy of the database. VivitAs have an option from the "start menu" from clicking the right mouse button on the background. On VivA releases, start a shell, and execute (as before, use the actual name of your VistA):

/usr/local/LeonardoDaVistA/vista --install ''directory''

*To subsequently run VistA, VivitAs again have an option from the mouse on the background. For VivAs, use:

/usr/local/LeonardoDaVistA/vista --run ''directory''

When the GT.M prompt (<tt>GTM></tt>) appears, you have a VistA environment that is ready to start configuring.

== Installation Documentation from sofware and hardware vendors of VistA and OpenVistA. ==

== Installation Documentation from the [[VistA Documentation Library]] (VDL) ==

=== Clinical ===
<TABLE summary="This table is for formatting purposes only." class = "toc" cellpadding="5" border="">
<TR>
<td>[[Installation of Admission Discharge Transfer (ADT)]]</TD>
<td>[[Installation of Electronic Wait List]]</TD>
<td>[[Installation of Medicine]]</TD>
<td>[[Installation of Pharmacy Prescription Practices (PPP)]]</TD>
</TR><TR>
<td>[[Installation of Ambulatory Care Reporting]]</TD>
<td>[[Installation of Functional Independence Measurement (FIM)]]</TD>
<td>[[Installation of Mental Health]]</TD>
<td>[[Installation of Primary Care Management Module (PCMM)]]</TD>
</TR><TR>
<td>[[Installation of Beneficiary Travel]]</TD>
<td>[[Installation of Group Notes]]</TD>
<td>[[Installation of Nursing]]</TD>
<td>[[Installation of Prosthestics]]</TD>
</TR><TR>
<td>[[Installation of Care Management]]</TD>
<td>[[Installation of Home Based Primary Care (HBPC)]]</TD>
<td>[[Installation of Oncology]]</TD>
<td>[[Installation of Quality Audiology Speech Anal & Rpting (QUASAR)]]</TD>
</TR><TR>
<td>[[Installation of Clinical Case Registries]]</TD>
<td>[[Installation of Immunology Case Registry (ICR)]]</TD>
<td>[[Installation of Patient Care Encounter (PCE)]]</TD>
<td>[[Installation of Radiology / Nuclear Medicine]]</TD>
</TR><TR>
<td>[[Installation of Clinical Procedures]]</TD>
<td>[[Installation of Incomplete Records Tracking (IRT)]]</TD>
<td>[[Installation of Pharmacy Automatic Replenish / Ward Stock (AR/WS)]]</TD>
<td>[[Installation of RAI/MDS]]</TD>
</TR><TR>
<td>[[Installation of Computerized Patient Record System (CPRS)]]</TD>
<td>[[Installation of Intake and Output]]</TD>
<td>[[Installation of Pharmacy Bar Code Medication Administration (BCMA)]]</TD>
<td>[[Installation of Remote Order Entry System (ROES)]]</TD>
</TR><TR>
<td>[[Installation of CPRS Adverse Reaction Tracking (ART)]]</TD>
<td>[[Installation of Laboratory Anatomic Pathology]]</TD>
<td>[[Installation of Pharmacy Benefits Management (PBM)]]</TD>
<td>[[Installation of Scheduling]]</TD>
</TR><TR>
<td>[[Installation of CPRS Authorization Subscription Utility (ASU)]]</TD>
<td>[[Installation of Laboratory Blood Bank]]</TD>
<td>[[Installation of Pharmacy Consolidated Mail Outpatient Pharmacy]]</TD>
<td>[[Installation of Social Work]]</TD>
</TR><TR>
<td>[[Installation of CPRS Clinical Reminders]]</TD>
<td>[[Installation of Laboratory Blood Bank Workarounds]]</TD>
<td>[[Installation of Pharmacy Controlled Substances]]</TD>
<td>[[Installation of Spinal Cord Dysfunction]]</TD>
</TR><TR>
<td>[[Installation of CPRS Consult/Request Tracking]]</TD>
<td>[[Installation of Laboratory Electronic Data Interchange (LEDI)]]</TD>
<td>[[Installation of Pharmacy Data Management (PDM)]]</TD>
<td>[[Installation of Surgery]]</TD>
</TR><TR>
<td>[[Installation of CPRS Health Summary]]</TD>
<td>[[Installation of Laboratory Emerging Pathogens Initiative]]</TD>
<td>[[Installation of Pharmacy Drug Accountability]]</TD>
<td>[[Installation of VISTA Imaging System]]</TD>
</TR><TR>
<td>[[Installation of CPRS Problem List]]</TD>
<td>[[Installation of Laboratory National Laboratory Tests/ LOINC Request Form]]</TD>
<td>[[Installation of Pharmacy Electronic Claims Management Engine (ECME)]]</TD>
<td>[[Installation of Visual Impairment Service Team (VIST)]]</TD>
</TR><TR>
<td>[[Installation of CPRS Text Integration Utility (TIU)]]</TD>
<td>[[Installation of Laboratory Universal Interface]]</TD>
<td>[[Installation of Pharmacy Inpatient Medications]]</TD>
<td>[[Installation of Vitals / Measurements]]</TD>
</TR><TR>
<td>[[Installation of Dentistry]]</TD>
<td>[[Installation of Laboratory]]</TD>
<td>[[Installation of Pharmacy National Drug File (NDF)]]</TD>
<td>[[Installation of Women's Health]]</TD>
</TR><TR>
<td>[[Installation of Dietetics]]</TD>
<td>[[Installation of Lexicon Utility]]</TD>
<td>[[Installation of Pharmacy Outpatient Pharmacy]]</TD>
</TR></TABLE>
=== Infrastructure ===
<TABLE summary="This table is for formatting purposes only." class = "toc" cellpadding="5" border="">
<TR>
<td>[[Installation of Capacity Management Tools]]</TD>
<td>[[Installation of Kernel Delphi Components (KDC)]]</TD>
<td>[[Installation of Minimal Patient Dataset (MPD)]]</TD>
<td>[[Installation of SlotMaster (Kernel ZSLOT)]]</TD>
</TR><TR>
<td>[[Installation of Duplicate Record Merge- Patient Merge]]</TD>
<td>[[Installation of Kernel Installation and Distribution System (KIDS)]]</TD>
<td>[[Installation of Name Standardization]]</TD>
<td>[[Installation of SQL Interface (SQLI)]]</TD>
</TR><TR>
<td>[[Installation of Electronic Error and Enhancement Reporting (E3R)]]</TD>
<td>[[Installation of Kernel Toolkit]]</TD>
<td>[[Installation of National Online Information Sharing (NOIS)]]</TD>
<td>[[Installation of Standard Files and Tables]]</TD>
</TR><TR>
<td>[[Installation of FileMan]]</TD>
<td>[[Installation of Kernel Unwinder]]</TD>
<td>[[Installation of National Patch Module]]</TD>
<td>[[Installation of Statistical Analysis of Global Growth (SAGG)]]</TD>
</TR><TR>
<td>[[Installation of FileMan Delphi Components (FMDC)]]</TD>
<td>[[Installation of List Manager]]</TD>
<td>[[Installation of Network Health Exchange (NHE)]]</TD>
<td>[[Installation of Survey Generator]]</TD>
</TR><TR>
<td>[[Installation of HL7 (VistA Messaging)]]</TD>
<td>[[Installation of M-to-M Broker]]</TD>
<td>[[Installation of Patient Data Exchange (PDX)]]</TD>
<td>[[Installation of VistA Data Extraction Framework (VDEF)]]</TD>
</TR><TR>
<td>[[Installation of Institution File Redesign (IFR)]]</TD>
<td>[[Installation of MailMan]]</TD>
<td>[[Installation of Remote Procedure Call (RPC) Broker]]</TD>
<td>[[Installation of XML Parser (VistA)]]</TD>
</TR><TR>
<td>[[Installation of Kernel]]</TD>
<td>[[Installation of Master Patient Index (MPI)]]</TD>
<td>[[Installation of Resource Usage Monitor]]</TD>
</TR></TABLE>
=== Financial-Administrative ===
<TABLE summary="This table is for formatting purposes only." class = "toc" cellpadding="5" border="">
<TR>
<td>[[Installation of Accounts Receivable (AR)]]</TD>
<td>[[Installation of Engineering (AEMS / MERS)]]</TD>
<td>[[Installation of IFCAP]]</TD>
<td>[[Installation of Patient Representative]]</TD>
</TR><TR>
<td>[[Installation of Auto Safety Incdnt Surv Trak Sys (ASISTS)]]</TD>
<td>[[Installation of Enrollment Application System]]</TD>
<td>[[Installation of Incident Reporting]]</TD>
<td>[[Installation of Personnel and Accounting Integrated Data (PAID)]]</TD>
</TR><TR>
<td>[[Installation of Automated Information Collection System (AICS)]]</TD>
<td>[[Installation of Equipment / Turn-In Request]]</TD>
<td>[[Installation of Income Verification Match (IVM)]]</TD>
<td>[[Installation of Police and Security]]</TD>
</TR><TR>
<td>[[Installation of Automated Medical Information Exchange (AMIE)]]</TD>
<td>[[Installation of Event Capture]]</TD>
<td>[[Installation of Integrated Billing (IB)]]</TD>
<td>[[Installation of Quality Management Integration Module]]</TD>
</TR><TR>
<td>[[Installation of Clinical Monitoring System]]</TD>
<td>[[Installation of Fee Basis]]</TD>
<td>[[Installation of Integrated Patient Funds]]</TD>
<td>[[Installation of Record Tracking]]</TD>
</TR><TR>
<td>[[Installation of Compensation & Pension Records Interchange (CAPRI)]]</TD>
<td>[[Installation of Generic Code Sheet (GCS)]]</TD>
<td>[[Installation of Library]]</TD>
<td>[[Installation of Release of Information (ROI) Manager]]</TD>
</TR><TR>
<td>[[Installation of Current Procedural Terminology (CPT)]]</TD>
<td>[[Installation of Health Eligibility Center (HEC)]]</TD>
<td>[[Installation of Missing Patient Register]]</TD>
<td>[[Installation of Veterans Identification Card (VIC/PICS)]]</TD>
</TR><TR>
<td>[[Installation of Decision Support System (DSS) Extracts]]</TD>
<td>[[Installation of Hospital Inquiry (HINQ)]]</TD>
<td>[[Installation of Occurrence Screen]]</TD>
<td>[[Installation of Voluntary Service System (VSS)]]</TD>
</TR><TR>
<td>[[Installation of Diagnostic Related Group (DRG) Grouper]]</TD>
<td>[[Installation of ICD-9-CM]]</TD>
</TR></TABLE>

Installation Overview

2005-11-17T19:55:05Z

Bhaskar: /* Getting the software */

Software Development (WG1) Version Control (T3)

2005-11-16T22:45:47Z

Bhaskar: /* Theory */

Software Development (WG1) Version Control (T3)

2005-11-16T22:41:51Z

Bhaskar: /* Theory */

Software Development (WG1) Version Control (T3)

2005-11-16T22:39:55Z

Bhaskar: /* Overview */

Software Development (WG1) Version Control (T3)

2005-11-16T22:38:24Z

Bhaskar: /* VistA Development Directories */

== Setting up a VistA Development Environment ==

=== Overview ===

This is a description of how VistA development environments should be configured.

'''Bold text''' designates program names, directory names, command line parameters, etc., that are intended to be typed in at a Linux shell or a GT.M prompt, e.g. '''/bin/bash'''. ''Italic text'' is a descriptor of something whose actual value must be determined when the command is typed, e.g., ''gtmver''.

=== Theory ===

A release is a collection of routines and global variables. The canonical packaging of a release, which is suitable for importation into any standard M distribution, is a collection of M source code routines and a database extract in ZWRite format. When installed on a system, to run with an M implementation, a release may have pre-compiled object files, database files, shell scripts, global directories, etc.

Below is a diagram of the “roll-up” by which a VistA release (“Release A”) gets converted into another VistA release (“Release B”) by a development team. A and B could be from different families, e.g., Release A could be a FOIA release and Release B could be a Leonardo da VistA release.

[[Image:051112-1WorldVistADevelopmentEnvironment_html_26096dee.gif|
"Roll up" model of VistA releases]]

Once Release A is installed, it remains frozen and unchanged except for any essential patches that may become available independent of the development process for creating Release B and without which the release lacks some required functionality.

At any given time, there can be multiple development projects underway based on Release A. In other words, there may well be a Release C that is also based on Release A, but which has its own integration and development areas.

To start the development process, an integration directory is created and initialized with a copy of the global variables from Release A, as well as shell scripts, global directories, etc. The integration directory may well have a different name from Release A and Release B. For example, Release A may be FOIAVistA_20051021, Release B may become LeonardoDaVistA_0.4 (at the time that the integration area is created, the name and version of Release B may not be decided yet), and the integration and development areas may be named Greenbelt_200510. There is no need to copy routines, since the GT.M search path will be set up to look for routines in the integration area before looking in Release A; hence only routines that are different between Release A and the new release need to be duplicated.

Actual development does not take place in the integration area. Development occurs in development areas, typically in the home directories of individual developers; however, there may be a shared development area if two developers are collaborating on making changes to the very same module (i.e., their code changes overlap). A development area is set up by creating a directory structure, shell scripts, etc. Note that development areas can be hierarchical so that development subtasks 1a and 1b can be developed separately and integrated into development task 1, prior to integration into the integration area, etc.

During this development process, developers develop code in individual sand boxes (development areas), but normally share the database (global variables) in the integration area – there may typically be no need to create a separate database. However, if some global variable changes are tied to code changes being made in a development area, a copy of those global variables can be placed in a separate database file in that development area, and a global directory for that development area can map those global variables to the database in that development area, with all other global variables mapped to the database in the integration area.

When a developer has code that is ready for integration, the new versions of the modified routines are promoted to the integration area. Any global variables tied to the code being promoted that are in a database in the development area must be merged, reconciled or otherwise integrated with the global variables in the database in the integration area and the global directory in the development area modified accordingly. Note that there needs to be a process, e.g., involving code reviews, by which a development task is considered complete enough to be promoted. These, and other quality gates, are not discussed herein.

Creating a release is minimally the process of creating the directory structure for Release B, copying the routines from Release A, overlying the routines with those from the integration area, and copying the global variables from the integration area.

Normally, Release A, the integration area and development areas would all use the same GT.M version. However, this is not a requirement.

=== Practice ===

==== Shell ====

The standard shell for VistA community scripting is bash (installed as <tt>/bin/bash</tt> on Debian GNU/Linux systems).

==== GT.M Release Directories ====

Each release of GT.M is installed its own subdirectory of <tt>/opt</tt> (preferred) or <tt>/usr/local</tt> (acceptable). Each directory name starts with <tt>gtm</tt> followed by a release number separated from the release name by an underscore (<tt>_</tt>). Thus, for example, GT.M V5.0-000C would be installed in <tt>/opt/gtm_V5.0-000C</tt>. <tt>/opt/gtm</tt> is a relative symbolic link to the latest version, set up with a command sequence such as:

cd /opt
rm -f gtm
ln -s gtm_V5.0-000C gtm

When installing GT.M, the file gtmprofile should be edited so that the line:

EDITOR="/bin/vi"; export EDITOR

is modified to read:

export EDITOR=${EDITOR:=/bin/vi}

==== VistA Release Directories ====

Each release is installed in its own sub-directory of a standard system location, such as <tt>/opt</tt> (preferred) or <tt>/usr/local</tt> (acceptable). Each directory has a release family name followed by a release / version number suffix separated from the release name by an underscore. Directories for releases without version numbers, such as FOIA releases, have a date suffix of the form ''yyyymmdd'' (and where appropriate just ''yyyymm''). For example, an August 25, 2005 FOIA release would be in <tt>/opt/FOIAVistA_20050825</tt>, an October 21, 2005 release in <tt>/opt/FOIAVistA_20051021</tt>, an OpenVistA 0.3 release in <tt>/opt/OpenVistA_0.3</tt> and a Leonardo da VistA 0.45 release in <tt>/opt/LeonardoDaVistA_0.45</tt>.

The normal protection on all directories and files in a release directory should be read-only. To install files in the <tt>p</tt> subdirectory, it should be made read-write, the source for the patch copied in, the object file(s) generated, and the directory again made read-only.

For each release family, the release directory contains subdirectories <tt>g</tt>, <tt>o</tt>, <tt>r</tt> and <tt>p</tt>, symbolic link <tt>gtm</tt>, and a script <tt>install</tt>. Other shell scripts may be created for various maintenance purposes (and ideally would be documented here).

*Subdirectory <tt>g</tt> contains a global directory file <tt>mumps.gld</tt> and a compressed database file <tt>mumps.dat.gz</tt>. The global directory maps all global variables to a single database file <tt>$vista_home/g/mumps.dat</tt> (i.e., the environment variable <tt>$vista_home</tt> is used at run-time to point a GT.M process to the location of the database file, so that different processes can actually use the same global directory to refer to entirely different database files).

*Subdirectories <tt>o</tt> and <tt>r</tt> correspond to directories for files containing routine object code and routine source code respectively. Each file in <tt>r</tt> ends in <tt>.m</tt> and has a corresponding file in <tt>o</tt> with a newer time stamp and which ends in <tt>.o</tt>.

*Subdirectory <tt>p</tt> contains source and object code for patches to a release (generated outside the scope of the work for creating Release B) and which are deemed to be essential for the proper functioning of the release.

*The symbolic link <tt>gtm</tt> points to the GT.M directory used for this VistA directory.

*The script <tt>install</tt> creates a new integration directory to be used in creating a new release from this release. Normally, the initial database file of the integration directory is created by uncompressing <tt>mumps.dat.gz</tt>. Option <tt>--newgtm</tt> ''gtmver'', specifies that the integration directory is to be configured to run a different version of GT.M (as specified by the directory ''gtmver'') from the one used by the release. If <tt>--newgtm</tt> ''gtmver'' is used, the default assumption is that the database will need to be extracted with the version of GT.M used by Release A, and loaded into a new database created with the version of GT.M to be used in the integration directory. When <tt>--newgtm</tt> ''gtmver'' is used, a an additional optional option <tt>--nonewdb<//tt> is used to specify that the releases of GT.M have compatible database formats, and that database from Release A can be used unchanged in the integration directory. Note that the use of <tt>--newgtm</tt> ''gtmver'' will almost certainly result in a command that takes a long time, because the database may need to be extracted and reloaded, and the routines recompiled.

==== VistA Integration Directories ====

A VistA integration directory is similar to a VistA release directory, with the following differences.

*Subdirectory <tt>g</tt> contains a database file, <tt>mumps.dat</tt>, rather than a compressed database file, <tt>mumps.dat.gz</tt>.

*The symbolic link <tt>parent</tt> points to the release directory from which this integration directory was created. A release directory does not have a symbolic link called parent. (The recommended way for a script to determine whether a directory is a release directory or an integration / development directory is to test for the existence of <tt>parent</tt>.)

*A script <tt>run</tt> which invokes and runs VistA in that integration environment. Note that a VistA release may physically include a <tt>run</tt> script, but it will not work because it is not possible to directly run VistA from a release directory.

*When the <tt>install</tt> script is executed, it will create a development directory.

*The normal protection on all directories and files in an integration directory should be read-only. When promoting code to the integration directory from a development directory, or to install externally generated patches in the <tt>p</tt> subdirectory, needed directories should be made read-write, sources copied in, object file(s) generated, and directories again made read-only.

==== VistA Development Directories ====

A development directory is like an integration directory, except that it does not normally have its own database file or global directory. However, as discussed above, it may be entirely appropriate for a development directory to have database files and global directories.

Indeed, since development directories are hierarchical – a development directory is an integration directory for development directories below it, and itself contributes to an integration directory above it, an integration directory is really nothing more than a development directory that does not itself contribute to an integration directory above it, but instead is used to create a release.

Note that although a GT.M database file can be opened by only one GT.M version at a time, it is quite easy to create a directory structure where Release A, the integration area, and each development area use different versions of GT.M. In the most common case, where the integration and development areas use a different version of GT.M from Release A, the only additional configuration requirement is to create a directory in the integration area for object files generated from the source files in Release A with the version of GT.M used for integration and development of Release B

Software Development (WG1) Version Control (T3)

2005-11-16T22:37:02Z

Bhaskar: /* VistA Integration Directories */

Software Development (WG1) Version Control (T3)

2005-11-16T22:24:56Z

Bhaskar: /* Practice */

Software Development (WG1) Version Control (T3)

2005-11-16T21:58:54Z

Bhaskar: /* Theory */

Software Development (WG1) Version Control (T3)

2005-11-16T21:55:41Z

Bhaskar:

File:051112-1WorldVistADevelopmentEnvironment html 26096dee.gif

2005-11-16T21:42:49Z

Bhaskar: "Roll up" VistA sofware development model

"Roll up" VistA sofware development model

Software Development (WG1) Version Control (T3)

2005-11-16T21:40:47Z

Bhaskar: