There are three or four minor modifications that usually need to be made to the .profile ("dot profile" or shell initialization) file for each user to set the necessary environment variables and optionally launch A-Shell automatically after login. All of this can be done interactively from the shell prompt each time a user logs in, but it is much cleaner to make it all happen automatically.
On the theory that an example is worth more than just an explanation, a typical user .profile (in this case for the Korn shell under AIX) is shown below, with A-Shell modifications, followed by explanations. Note that your .profile will probably be different, but similar.
PATH=/usr/bin:/etc:/usr/sbin:/vm/miame/bin:/usr/ucb:$HOME/bin:
MIAME=/vm/miame
TERM=am62a
export PATH MIAME TERM
set +o monitor
ashell main
exit
In the PATH statement, we just added the A-Shell executable directory (/vm/miame/bin), so that users could execute ashell (or more importantly, vue) from anywhere. You might argue that this is unnecessary in a turnkey system, since the only time users would ever launch ashell is from within this same file, in which case it would make just as much sense to call out the full /vm/miame/bin/ashell path on the last line. Similarly, even if you wanted to use the A-Shell vue editor instead of vi, you could always put a link to it in a directory that was already in the PATH, such as /usr/bin. However, adding it to the PATH is clearly preferable if you plan to go in and out of A-Shell many times. Note that the delimiter is the colon (:). It can also avoid a lot of confusion if you are having problems launching background sessions with XCALL AMOS or SUBMIT, and it may be necessary for certain utilities such as KILL and LOKUTL, which in turn execute native Unix commands (ashkill and lslk) which are expected to be in the PATH (and which are typically stored in the same directory as the ashell executable..
MIAME=/vm/miame defines the environment variable MIAME, which is used by A-Shell to locate miame.ini. Again, you could get by without defining this variable since you can always specify miame.ini on the startup command (e.g. ashell –i /vm/miame/miame.ini)
TERM=am62a is shown here for those cases where the login script (specifically the tset command) is not managing to set the TERM variable correctly. If you are using a known terminal type (am62a, am62c, am75, wyse50, hz1500, vt420) then it is essential that the TERM variable get set correctly to one of those names (using the spelling and case as given in the list above.) Otherwise, A-Shell will not recognize your terminal type, and will be forced to use the TERMINFO database, which is at best, not as good. Of course it is less than ideal to hard code your terminal type in your login script—it is much better to have the login routine prompt you—but this at least demonstrates the brute force approach.
If you want to use the am62a emulation with Unix utilities (such as the vi editor) then you will need to define a TERMINFO entry for it. Since am62a is not a standard Unix terminal type, we provide a TERMINFO source, am62a.tis which you can add to your TERMINFO database with the following command (execute as root from the /vm/miame directory): # tic –v am62a.tis
The export statement is needed to make the preceding environment variables visible to programs running outside of the shell (such as A-Shell).
set +o monitor is only needed when you are using PolyShell and a "job control" shell, such as the Korn Shell (ksh) or Born Again Shell (bash). It turns off the shell’s trapping of the job control signals so that PolyShell can use them itself.
ashell main launches A-Shell (assuming it is in the PATH and the MIAME environment variable defines the location of miame.ini) and tells it to execute CMD:MAIN (CMD or DO) as a startup command. If that command file brings up your main menu, and you want the user to go directly back to the Unix login prompt when exiting from your main menu, then add a HOST command at the end of your main.cmd file, as shown here:
:R
LOG DSK1:[20,0]
RUN MAIN
HOST
When HOST command is executed, the A-Shell session is terminated, returning execution control to the login profile script, where the next command to execute (based on the example above) is exit. This logs you out of Unix. Depending on the connection type, you may then go back into the Unix login prompt, or perhaps your Telnet connection window will close and disappear.
Another way to force the A-Shell session to terminate after the program completes is to use the –e switch on the A-Shell command line.
