Table of Contents
GT.M provides the mumps -run shell command to invoke application entryrefs directly from the shell. GT.M recognizes a number of environment variables to determine the starting characteristics of a process; these are described in the documentation and summarized in “Environment Variables”. In order to ensure that environment variables are set correctly, you should create a shell script that appropriately sets (and clears where needed) environment variables before invoking GT.M. When users should not get to the shell prompt from the application (either for lack of skill or because they are not sufficiently trusted), or when the application needs more access to the shell command line than that provided by the $ZCMDLINE ISV, you may need to package a GT.M application using techniques beyond, or in additional to, invocation from a shell script.
Since GT.M is designed to integrate with the underlying OS, you should consider the entire range of services provided by operating systems when packaging a GT.M applications. For example, you can use the host based access control provided by TCP wrappers, or various controls provided by xinetd (including per_source, cps, max_load protection, only_from, no_access, and access_times).
This appendix has two examples that illustrate techniques for packaging GT.M applications, neither of which excludes the other.
“Setting up a Captive User Application with GT.M”, such that when captive users login, they are immediately taken to the application, have no access to the shell or programmer prompt, and when they exit, are logged off the system.
“Invoking GT.M through a C main() program”: in addition to providing another technique for creating captive applications, invoking through a C main() is the only way that application code has access to the original argc and argv of a shell command used to start the application (the $ZCMDLINE ISV provides an edited version of the command line).