[Posted by Bhaskar, from an e-mail sent by Bill Ackerman]
I am in the process (starting/learning/guessing/pulling out my
hair) of writing bash script. What I would like to know is
what is the easiest way to get a basic GT.M system
working. Simply, what are the exact steps you would do to
install and configure a new GT.M system.
What I want to do is to create a complete script to setup a
complete installation much the same way MSM did. I would like
to create several script to start and stop GT.M from the
/etc/rc.d/init.d directory so that if the user takes the system
down GT.M will exit cleanly and restart when the system comes
back up. And last a /usr/local/bin utility to allow any user
with the right permissions to start GT.M from their own account
like cache does for user of a given group. Last but not least,
setup a script to allow anyone to login into a mapped account
directly into GT.M and let a MUMPS routines handle logins.
This is the way most VA/VMS/DSM system work. the user would
type vista at the username prompt and then be sent to the VA
login routine ^ZU to handle the actual sign-on process within
VISTA. My goal is to provide the simplest way for anyone to
install and start using GT.M with out having to dive into the
manuals. The only exception would be the more tech issues such
system Admin (journaling, backups...) Then we can take this
400 page Admin Guide and condense it to a thin Installation
Guide and then only those who need the more advanced function
or what more details will need to even open the Admin Manual.
So, what I am asking is can you provide me with a simple 123,
ABC system install with all the required stuff and how it
should be set. I will then start work on scripts and send you
the results so that you can do what you feel is the best course
of action with them.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Bill's issues get at the heart of some of the differences between
GT.M and other M implementations. GT.M is more like the open
environment of a programming language, such as C, and not like the
more cloistered environments of other M implementations. While
this simplifies system administration and provides fewer
opportunities for things to go wrong, it does increase the learning
curve for anyone migrating to GT.M from other M implementations.
GT.M has no daemon and no centralized control. The processes
accessing a database cooperate with one another to read and write
from the database. The first process to open a database file sets
up the shared memory control structures for accessing that file,
and the last one out tears everything down. (Yes, there is a
special program called gtmsecshr that has a couple of setup and
teardown functions, but it is not a daemon as in other databases.)
So, there is nothing to be done to "start" GT.M except to start the
first M process, and nothing that is required to be done to "stop"
GT.M except to exit the last M process normally. As a precaution
against processes that may have terminated, or been terminated,
abnormally, a mupip rundown is recommended when shutting down a
system or when things are known to have gone bump in the night.
GT.M uses the security model of the underlying operating system --
it neither adds to that security, nor takes away from it. The GT.M
process has whatever file access permissions for the database file
that the operating system provides.
Thus, while the differences between GT.M vs. MSM can be made
transparent to an end user, for the system administrator, they
cannot. Further comments are embedded.
> I am in the process (starting/learning/guessing/pulling out my
> hair) of writing bash script. What I would like to know is
> what is the easiest way to get a basic GT.M system
> working. Simply, what are the exact steps you would do to
> install and configure a new GT.M system.
Copy the distribution file from Source Forge using binary FTP to
your Linux PC. Working with a copy in a temporary directory, type
something like tar zxvf <filename> to extract it.
In the directory into which it is extracted, running as root, type
"sh configure" to install it. Install it somewhere convenient like
/usr/local/gtm or /usr/local/gtmv42ft05 (the latter may be
preferable, since you may well have multiple versions of GT.M on
your PC).
When you execute GT.M process, $gtm_dist must point to the
directory in which GT.M is installed. This is a safety precaution
against shooting yourself in the foot, if you happen to have a
machine with multiple versions of GT.M installed. You can run a
mumps process either by including $gtm_dist in your shell's $PATH
or by explicitly executing $gtm_dist/mumps (you can create an alias
for mumps to be $gtm_dist/mumps).
For your initial experimentation, set $gtmroutines to be
". $gtm_dist" and set $gtmgbldir to be mumps.gld.
With the directory in which you will be experimenting with GT.M as
the current working directory, type "$gtm_dist/mumps -run GDE exit"
to create a default global directory. Create a default database
file with "$gtm_dist/mupip create".
Type "$gtm_dist/mumps -dir" to get to the GT.M direct (interactive)
mode with the "GTM>" prompt.
Try something like: w "Hello, world"
To access the database try: s ^hello="Hello, World" w ^hello
Note that the global directory defaults are appropriate for
initial playing with GT.M, and are not suitable for production
applications.
Unlike other M implementations, programs (source and object code)
are stored as Linux files, and are not stored in the database.
> What I want to do is to create a complete script to setup a
> complete installation much the same way MSM did. I would like
> to create several script to start and stop GT.M from the
> /etc/rc.d/init.d directory so that if the user takes the system
> down GT.M will exit cleanly and restart when the system comes
As discussed, you don't need to do anything to start and stop GT.M.
If you want to create the equivalent of a "bulletproof" database,
you will have to do a little more configuration work, but that's a
topic for another day.
> back up. And last a /usr/local/bin utility to allow any user
> with the right permissions to start GT.M from their own account
> like cache does for user of a given group. Last but not least,
For two users to have read/write access the same database, ensure
that both of them point to the same global directory with
$gtmgbldir and that their Linux ids give them read/write access to
the database file(s).
> setup a script to allow anyone to login into a mapped account
> directly into GT.M and let a MUMPS routines handle logins.
> This is the way most VA/VMS/DSM system work. the user would
> type vista at the username prompt and then be sent to the VA
> login routine ^ZU to handle the actual sign-on process within
> VISTA. My goal is to provide the simplest way for anyone to
> install and start using GT.M with out having to dive into the
No problem. Create "vista" to be a Linux userid with no password.
As part of the startup script for that user (depending on the
shell, probably a file such as ~vista/.login), set up $gtm_dist,
$gtmgbldir and $gtmroutines, and then execute $gtm_dist/mumps -run
^ZU to get into ^ZU as part of the login process.
> manuals. The only exception would be the more tech issues such
> system Admin (journaling, backups...) Then we can take this
> 400 page Admin Guide and condense it to a thin Installation
> Guide and then only those who need the more advanced function
> or what more details will need to even open the Admin Manual.
> So, what I am asking is can you provide me with a simple 123,
> ABC system install with all the required stuff and how it
> should be set. I will then start work on scripts and send you
> the results so that you can do what you feel is the best course
> of action with them.
Hope this helps! Please do ask further questions if it doesn't.
Do submit queries under Support -- answers can be more easily
accessed by those who come much later and have the same questions.
-- Bhaskar
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
[Posted by Bhaskar, from an e-mail sent by Bill Ackerman]
I am in the process (starting/learning/guessing/pulling out my
hair) of writing bash script. What I would like to know is
what is the easiest way to get a basic GT.M system
working. Simply, what are the exact steps you would do to
install and configure a new GT.M system.
What I want to do is to create a complete script to setup a
complete installation much the same way MSM did. I would like
to create several script to start and stop GT.M from the
/etc/rc.d/init.d directory so that if the user takes the system
down GT.M will exit cleanly and restart when the system comes
back up. And last a /usr/local/bin utility to allow any user
with the right permissions to start GT.M from their own account
like cache does for user of a given group. Last but not least,
setup a script to allow anyone to login into a mapped account
directly into GT.M and let a MUMPS routines handle logins.
This is the way most VA/VMS/DSM system work. the user would
type vista at the username prompt and then be sent to the VA
login routine ^ZU to handle the actual sign-on process within
VISTA. My goal is to provide the simplest way for anyone to
install and start using GT.M with out having to dive into the
manuals. The only exception would be the more tech issues such
system Admin (journaling, backups...) Then we can take this
400 page Admin Guide and condense it to a thin Installation
Guide and then only those who need the more advanced function
or what more details will need to even open the Admin Manual.
So, what I am asking is can you provide me with a simple 123,
ABC system install with all the required stuff and how it
should be set. I will then start work on scripts and send you
the results so that you can do what you feel is the best course
of action with them.
Bill's issues get at the heart of some of the differences between
GT.M and other M implementations. GT.M is more like the open
environment of a programming language, such as C, and not like the
more cloistered environments of other M implementations. While
this simplifies system administration and provides fewer
opportunities for things to go wrong, it does increase the learning
curve for anyone migrating to GT.M from other M implementations.
GT.M has no daemon and no centralized control. The processes
accessing a database cooperate with one another to read and write
from the database. The first process to open a database file sets
up the shared memory control structures for accessing that file,
and the last one out tears everything down. (Yes, there is a
special program called gtmsecshr that has a couple of setup and
teardown functions, but it is not a daemon as in other databases.)
So, there is nothing to be done to "start" GT.M except to start the
first M process, and nothing that is required to be done to "stop"
GT.M except to exit the last M process normally. As a precaution
against processes that may have terminated, or been terminated,
abnormally, a mupip rundown is recommended when shutting down a
system or when things are known to have gone bump in the night.
GT.M uses the security model of the underlying operating system --
it neither adds to that security, nor takes away from it. The GT.M
process has whatever file access permissions for the database file
that the operating system provides.
Thus, while the differences between GT.M vs. MSM can be made
transparent to an end user, for the system administrator, they
cannot. Further comments are embedded.
> I am in the process (starting/learning/guessing/pulling out my
> hair) of writing bash script. What I would like to know is
> what is the easiest way to get a basic GT.M system
> working. Simply, what are the exact steps you would do to
> install and configure a new GT.M system.
Copy the distribution file from Source Forge using binary FTP to
your Linux PC. Working with a copy in a temporary directory, type
something like tar zxvf <filename> to extract it.
In the directory into which it is extracted, running as root, type
"sh configure" to install it. Install it somewhere convenient like
/usr/local/gtm or /usr/local/gtmv42ft05 (the latter may be
preferable, since you may well have multiple versions of GT.M on
your PC).
When you execute GT.M process, $gtm_dist must point to the
directory in which GT.M is installed. This is a safety precaution
against shooting yourself in the foot, if you happen to have a
machine with multiple versions of GT.M installed. You can run a
mumps process either by including $gtm_dist in your shell's $PATH
or by explicitly executing $gtm_dist/mumps (you can create an alias
for mumps to be $gtm_dist/mumps).
For your initial experimentation, set $gtmroutines to be
". $gtm_dist" and set $gtmgbldir to be mumps.gld.
With the directory in which you will be experimenting with GT.M as
the current working directory, type "$gtm_dist/mumps -run GDE exit"
to create a default global directory. Create a default database
file with "$gtm_dist/mupip create".
Type "$gtm_dist/mumps -dir" to get to the GT.M direct (interactive)
mode with the "GTM>" prompt.
Try something like: w "Hello, world"
To access the database try: s ^hello="Hello, World" w ^hello
Note that the global directory defaults are appropriate for
initial playing with GT.M, and are not suitable for production
applications.
Unlike other M implementations, programs (source and object code)
are stored as Linux files, and are not stored in the database.
> What I want to do is to create a complete script to setup a
> complete installation much the same way MSM did. I would like
> to create several script to start and stop GT.M from the
> /etc/rc.d/init.d directory so that if the user takes the system
> down GT.M will exit cleanly and restart when the system comes
As discussed, you don't need to do anything to start and stop GT.M.
If you want to create the equivalent of a "bulletproof" database,
you will have to do a little more configuration work, but that's a
topic for another day.
> back up. And last a /usr/local/bin utility to allow any user
> with the right permissions to start GT.M from their own account
> like cache does for user of a given group. Last but not least,
For two users to have read/write access the same database, ensure
that both of them point to the same global directory with
$gtmgbldir and that their Linux ids give them read/write access to
the database file(s).
> setup a script to allow anyone to login into a mapped account
> directly into GT.M and let a MUMPS routines handle logins.
> This is the way most VA/VMS/DSM system work. the user would
> type vista at the username prompt and then be sent to the VA
> login routine ^ZU to handle the actual sign-on process within
> VISTA. My goal is to provide the simplest way for anyone to
> install and start using GT.M with out having to dive into the
No problem. Create "vista" to be a Linux userid with no password.
As part of the startup script for that user (depending on the
shell, probably a file such as ~vista/.login), set up $gtm_dist,
$gtmgbldir and $gtmroutines, and then execute $gtm_dist/mumps -run
^ZU to get into ^ZU as part of the login process.
> manuals. The only exception would be the more tech issues such
> system Admin (journaling, backups...) Then we can take this
> 400 page Admin Guide and condense it to a thin Installation
> Guide and then only those who need the more advanced function
> or what more details will need to even open the Admin Manual.
> So, what I am asking is can you provide me with a simple 123,
> ABC system install with all the required stuff and how it
> should be set. I will then start work on scripts and send you
> the results so that you can do what you feel is the best course
> of action with them.
Hope this helps! Please do ask further questions if it doesn't.
Do submit queries under Support -- answers can be more easily
accessed by those who come much later and have the same questions.
-- Bhaskar