A new A-Shell client, who is converting from an older system, asks several questions:
| • | Do we really need to use ZTERM, or is connecting to the host using any ssh client and starting A-Shell from there sufficient? I ask this because previously the users connected to the AMOS box using an ssh tunnel and ZTERM on top of that. I want to get rid of that scheme in favor of something simpler which I think it could be done just by an ssh session. |
| • | In the same topic, the FTP configuration is something I would like to change to a SFTP connection to the host box (Linux in this case) with an user jailed to the disk directories of A-Shell. Do you think this approach would have a problem when comparing to using the TCP/IP support of AMOS? Again I am trying to prevent the tunneling and going straight to the box using the ssh stack as much as possible. |
| • | Does A-Shell printing depend on any particular terminal emulation(s)? |
Following are extended discussions on each of these topics.
I'm glad you asked about ZTERM, because I was under the impression that the client was actually committed to it. We still sell it due to a long-time agreement with the developer, but because he stopped doing any support or development on it more than a decade ago, we decided to create our own emulator. That A-Shell-based emulator is called ATE (A-Shell Terminal Emulator), and we fully support it as well as modernize/enhance the capabilities as time goes by. One of those being proper SSH2 / SFTP support! Another is the enhanced printing capabilities, both in redirecting Linux print requests via the Windows system, as well as supporting preview, print-to-PDF, print-to-email, etc., that I may have referred to in a previous message.
Perhaps the biggest enhancements are in the area of GUI support, but I gather that the client's application currently has no need for GUI. Whether they are interested in adding some GUI enhancements to the application, I have no idea, and it may not be your concern either. But if you or the client expect to be using the application for a long time into the future, those GUI capabilities become ever more important. So take note!
But even apart from "GUI-fyng" the application per se, there may be areas where they might benefit from improved communication capabilities between the application running on Linux and the resources of the Windows environment. There is a reasonably coherent summary of ATE on the MicroSabio ATE page, and there is a list of extended TAB(-10,x) functions in the A-Shell reference to give some idea of the kinds of server-to-client commands that are available. Many of these overlap the ZTERM ESCAPE Sequence commands, in which case ATE also supports the same ESCAPE sequences for upward compatibility.)
Most of the A-Shell/ZTERM users have migrated to ATE, and nearly all of the new A-Shell/Linux users choose ATE. But, it is a commercial product with a cost associated; you can see the prices on our website. To avoid those costs, or due to prior preference, some sites use other emulators, ranging from commercial ones like Anzio and AlphaLAN, to free/open-source emulators like Putty. As long as the emulator supports an emulation that is compatible with A-Shell and the features used by the application, it should work. The specific emulations that A-Shell supports are AM62A, AM62C, AM65, AM75, and WYSE50. It also supports a "generic" terminal emulation that works through the Linux TERMINFO database, allowing emulations that are known to Linux, such as VT220, VT320, etc. to function, although the capabilities are generally pretty limited. (The AMOS terminal driver system was quite advanced for its time and encouraged applications to take advantage of terminal features; the scheme was theoretically terminal independent, except that they then came out with their own line of terminals which certain tweaked capabilities to coerce most users into buying the more expensive AMOS terminals.) I haven't seen your application, so I don't know what features are being used, except that I do know that it uses the protected fields, i.e. TAB(-1,13) and TAB(-1,14), which probably rules out the use of generic emulations. Other features that are common in AMOS applications but possibly dependent on the AMOS terminal emulations are insert/delete, line drawing, save/restore, and status lines. Although it may be somewhat self-serving, my general opinion is that the difference in cost between ATE and a free emulator typically isn't worth the effort to identify and work around these issues, not to mention losing access to some of the really useful features, like printing.
Regarding printing, no, A-Shell does not depend on any terminal emulator for printing. Printers can be defined to Linux, similar to how they are defined to AMOS, and A-Shell can print to those printers via PRINT.LIT or XCALL SPOOL, just like it does under AMOS. A text configuration file is used to associate the logical printer name known to the application, with the system print queue name known to the Linux operating system. The ability to print back to the terminal, for redirection to real or virtual Windows print devices, is just a bonus.
Regarding the SSH tunnel and SFTP, I agree that getting rid of the tunnel would make your life easier. Since ATE (and other emulators like Putty) support SSH2, there is no need to use a tunnel; just SSH directly to the server. In the case of ATE, you can launch SFTP transfers via the same SSH terminal channel/port, which also simplifies firewalls. Jailing or sandboxing the users is possible in the normal way, based on the way you configure the SFTP service on the server, but if the application is driving those transfers (using the ZTERM ESCAPE sequences), then it probably assumes that the SFTP home directory is the real home directory, so re-homing might require some slight modification to that code, if it exists.
One feature which ATE does not offer, but ZTERM does, is an interactive file transfer user interface. We deliberately excluded that because we felt that in most cases, it was an invitation to abuse, i.e. it was better to limit file transfers via the application logic, rather than to encourage users to transfer files back and forth unsupervised. But if that's the way you like to work, we recommend using one of the free SFTP-capable file transfer clients, such as FileZilla. One of our A-Shell developers also makes available a free one called MadFTP which has some features to make it integrate slightly better with A-Shell, i.e. sharing the login, knowledge of A-Shell directories, etc. But it isn't quite as sophisticated/powerful as FileZilla. Either one can be put on to the ATE menu bar via a simple application startup command, so further integrate it into the terminal environment, if so desired.
Another detail I forgot to mention earlier about file transfers: A-Shell supports the ZTXFER.LIT command that may be used from the AMOS dot prompt (or A-Shell dot prompt) to transfer files, as an alternative to the application-driven transfer method. ZTXFER with no arguments gives the help info:
.ZTXFER
ZTXFER usage:
To send from Host to PC:
ZTXFER{/switches} host-name PC-name or ZTXFER{/switches} host-name
To send from PC to Host:
ZTXFER{/switches}{a host-name=PC-name or ZTXFER{/switches} =PC-name
Switches:
/A forces ASCII mode
/2 requests new FTP/SFTP implementation if avail (faster)
/ATE use ATE terminal channel (automatic for PC -> ATSD)
Source file name may contain * wildcard (ATE/Unix only; no /2)
For example:
.ZTXFER AAA.BBB c:\temp\AAA.BBB
.ZTXFER CCC.DDD = c:\temp\AAA.BBB
The above would transfer the AAA.BBB file from the current directory to c:\temp\aaa.bbb, and then transfer it back to ccc.ddd.
The file transfer protocol and authentication would be determined by terminal emulator configuration; for ZTERM it would be FTP; for ATE it would be SFTP.
But, as I mentioned before, the assumption within ZTXFER is that the current directory as seen by the application, matches the directory as it would be seen by the {S}FTP server. If that were not true because of jailing/sandboxing/re-homing, an adjustment would have to be made somewhere to convert from one to the other. (It wouldn't be too difficult, but would require some tinkering.)
