pshell {-a ashell cmd}{-hp}{-j jobname}{-l}{-l2}{-t}{-u}{-x}{-f optionfile}{-1} {other ashell args}
Note that PolyShell is an extra-cost option available for A-Shell running in non-Windows environments.
PolyShell is a multi-tasking "shell" that allows a user to run and switch between multiple instances of A-Shell on a single workstation. It does not currently support running anything other than A-Shell. This can be considered both a limitation and an advantage. It is almost certainly too limiting for power users and system operators who may prefer a multi-tasking mechanism, such as multiple X windows, or the multi-screen console, that allows anything to be executed in any of the windows. On the other hand, it may be just perfect for users who are only interested in running an application under the control of A-Shell, since it effectively forces each window to run just that application.
One other advantage of PolyShell over more "powerful" multitasking mechanisms is the low amount of processing overhead. Since A-Shell already tracks the screen contents, there is no additional overhead required for maintaining and restoring screen contents. In fact, when a process is in background, its output is simply sent to /dev/null (i.e. thrown away) since it has already passed through the A-Shell/TRACKER screen mapping system anyway. This is considerably more efficient that installing a pseudo-terminal and directing output through a "reverse terminal driver" to maintain a logical map of the screen's contents.
Furthermore, by using the "job control" signal mechanism built into most versions of Unix (it is contained in the POSIX.1 and FIPS 151-1 standards) there is no additional overhead for filtering of keyboard characters to watch for the hot key(s). However, one disadvantage of this approach is that you cannot run PolyShell under the control of a Unix shell that traps job control signals, because such shells interfere with PolyShell's ability to trap those signals. The standard Bourne shell (sh) does not trap job control signals; while the Korn (ksh) does (but may be turned off using set +o monitor.) The C shell (csh) may or may not, depending on the version. Consult your shell documentation or local Unix guru for information on how to disable the job control signal handler in shells that support it.
The bash shell under Unix does not appear to allow you to turn off trapping of job control signals. So we recommend using the Korn shell instead.
One additional advantage of PolyShell in an application environment is that it permits certain A-Shell utilities, such as SEND.LIT and CHAT.LIT to be more effective by automatically routing the messages to the job that is in foreground. (In contrast, if you wanted to SEND a message to another user who had multiple telnet sessions running, you would have no way of knowing which one of those was actually occupying the foreground context for that user.) Messages sent via SEND.LIT to a user running under PolyShell are intercepted by PolyShell; the current process is switched into background (where it can continue to run unbothered by the message), and the user is switched to menu mode where the message is displayed. This way the recipient cannot fail to see the message, and yet it does not interfere in any way with a running process.
Operationally, PolyShell is more or less self-explanatory. The menu options are limited to opening, closing, switching among, and displaying the status of the child instances. The only non-obvious operation is the hot key used to switch back to the menu or between instances. This is defined via the POLYKEY and SWAPKEY settings in miame.ini.
Subtopics
