ATE

This page is entitled “ATE” because that’s nice and short. The real title should be: “questions and answers that might be of interest to somebody considering the purchase of ATE.”

Question 1: Why should I use ATE instead of some cheaper/older/more familiar alternative?

First of all, we don’t know for sure that you should use ATE. What we do know is that there are things ATE can do in an A-Shell environment that other terminal emulators simply can’t do; those other emulators don’t “know” anything about A-Shell, but ATE does. If any of the ATE-specific features listed below are “must have” for your client, then ATE is the way to go. If none of the items on the list seem terribly important, then other emulators may be fine.

MicroSabio’s objective is for the client to have the best possible experience with A-Shell and the best possible working environment. It is our opinion (not fact, just an opinion) that those objectives will be best accomplished by using ATE as opposed to another emulator. But it’s you the reseller or consultant or systems integrator that will have to determine if ATE’s capabilities are actually helpful/useful/meaningful to your client and his/her particular situation.

Here is a list of the most important things that ATE can do and other emulators cannot or do not:

• Workstation identification:  since ATE and A-Shell “know” each other, they are able to exchange more identity information (Windows logon, machine ID, etc.) when the session starts.  This can be useful in tracking system activity, both in real time (e.g. SYSTAT), or for forensics (via the A-Shell log file).
• Integrated command and shell execute:  Dual interfaces—command line or “CLI” and application programmer’s or “API”—make it easy to launch Windows commands and file handlers from the server, including transferring the file from the server if necessary.
• File synchronization: ATSYNC.LIT makes it easy and efficient to distribute files from the server to each client.
• Interface customization: the application can easily modify the ATE menu bar to add capabilities, launch related apps, etc.  It can also enable/disable status bars, change the geometry (from 6×10 to 60×160), add floating dialogs, display messages in an auxiliary scrolling window, etc.
• APEX (optional add-on): a system printer that redirects output to the workstation for preview, printer selection/redirection, archive, etc. Includes a customizable Export-to-Excel function.
• Remote execution of subroutines: applications can create subroutines that execute remotely on the workstation, allowing for more complex integration capabilities.
• Integrated print screen utility with automatic capture of program name, version, user details, etc., option to annotate and email (very useful for tech support).
• Bi-directional file transfer via CLI or API, supporting SFTP and FTP,  as well as an internal protocol using terminal channel.
• Since A-Shell on server is aware of the ATE client GUI capabilities it can take advantage of them as appropriate, for example, displaying error messages in auxiliary windows rather than potentially lost in the text screen display.
• Full support for AMxxx emulations, including addressable top/bottom status lines, colors, line drawing and other special characters, area functions, etc.

Question 2: If I am using A-Shell with my existing terminal emulator, and it is working okay, why would I want to use ATE instead?

(There will obviously be some overlap with the previous question and answers.)

We were asked just that question recently. Here is the answer, written by A-Shell developer Jack McGregor, to one of our long-time A-Shell customers and friends.

Hi George–

I’m going to attempt to address the question of whether it would make sense for you to consider using ATE instead of GenTE (generic terminal emulator program for Windows). You can of course download a copy and “kick the tires”, but my sense is that it might be more sensible to first consider the higher-level issues and features that might be relevant. Unfortunately I don’t know much about your application or environment so I can’t really make a recommendation, but I can organize and outline the considerations that might be relevant. From there you can decide whether it seems worth a more detailed pursuit.

At the highest level, some possible categories of reasons to consider switching might be:

• You’re happy with GenTE but view it as a commodity and would like to lower the cost. I imagine we can address this if it is the issue, but since neither product is very expensive, I doubt that it is a major factor.
• You’re happy with the product and the price, but if it’s all the same, you’d rather direct the business at us. (Naturally we’d be thrilled to accommodate such a desire!)
• You’d like to simplify the license management. I’m not sure what’s currently involved for GenTE, but ATE licensing is particularly simple; a single, simultaneous-count license on the server and nothing on the devices.
• You’re not happy with the existing product. In this case obviously we’d need to discuss just what the problem is, in order to help you evaluate whether ATE would resolve the problems—and not just trade them for another set.
• You would like more control over the product, i.e. to customize/tailor it better to your environment. We’re probably in a stronger position to offer such flexibility, partly because ATE—being an A-Shell/Windows application—is naturally suited for customization/integration with other A-Shell applications, and partly because catering to developer requirements is one of our main areas of strength. This is a wide subject though, and would obviously merit more discussion.
• You’d like to go beyond plain text terminal emulation and enhance your application/user experience, possibly incorporating graphical elements and/or integrating more PC functionality into the application. ATE is probably strongest in this area.

The first three points are mainly administrative and can be worked out with Ty. The others are more technical, and I’d be happy to discuss any such technical issues with you, or you can read the docs and play with a copy to see if you can answer your own questions. Given that you’ve been using the Wyse50 emulation and GenTE emulator for many years, it’s quite likely that you haven’t really given that much thought to what additional features/capabilities you would like to use if they existed. So at the risk of sounding like a sales pitch, here’s an attempt at summarizing some of the technical similarities and differences between GenTE and ATE:

1. Terminal Emulation: GenTE is more of a traditional terminal emulator, supporting lots of emulations and loaded with emulation options in an attempt to appeal to a very wide audience. ATE in contrast, supports only a few emulations common in the AMOS world (AMxx, WYSE50, VTxxx), and offers a much more limited set of emulation-related menu options, relying instead on the more limited range of variations actually used in the AMOS-inspired world as well as the standardized TCRT system that encourages configuration by the application rather than by the end user.
2. Terminal configuration by the application: I’m not sure what GenTE offers in this area, but ATE is pretty strong, reflecting the tendency in the A-Shell world to shift configuration powers from the users to the application. For example, you can disable or remove any of the menu bar items, including the entire menu bar, and you can add your own items that generate either keystroke responses or shell executions. Similarly, you can add/remove the status lines individually, and also change the number of rows and columns up to 60×160 using the TCRTs -5,rows and 6,cols. Adjusting the rows and columns on a program-by-program basis is a particularly convenient way to deal with the need to add fields to already over-crowded screens.
3. Connection / login protocol: Most ATE users connect with SSH and use SFTP for file transfers. The login can be interactive or automated using standard name/password or a private key file. The configuration can also store additional text commands to send to the host on connection, allowing you to create different launch configurations even with the same login. Since this information is mostly stored in the Windows Registry, the host application can auto-configure it; see PC / application integration below. I’m not sure if that completely satisfies your SSO requirements, but we can probably customize it to support the desired SSO configuration.
4. Printing: Both products allow you to print to Windows printers via the aux port, i.e. TCRTs 82/83. Related features supported by ATE include: Windows printer selection by application,  Windows font/graphic support via GDI Print Directives, auto-font scaling (to fit page), PDF generation, raw or GDI printer interfacing, print preview and report archiving.
5. Graphical user interface: ATE supports the full range of A-Shell/Windows GUI capabilities, allowing you to create dialogs and/or embed individual GUI controls into a text screen. While you probably don’t relish the idea of completely converting your application to GUI, it often makes sense to selectively introduce dialogs or individual controls into an otherwise text-only application to improve the user experience and in some cases to simply programming. Some examples would be displaying images within a fixed area of a screen or floating as a modeless window; using a grid to display a large number of rows and columns without having to deal with scrolling within the application; using fonts to highlight titles or fine print; embedding hyperlinks; offering clickable buttons as an alternative to command keys; using a rich text control for integrated word processing; using a tree control to consolidate/navigate your menu system, etc., etc. The idea may seem strange at first to create a hybrid of plain text and graphic elements, but a number of our developers have used this approach quite successfully. Others have taken the approach of converting just specific functions to GUI. You can see some examples of what other developers have done on our AUI Gallery page.
6. PC / application integration: ATE supports a set of extended commands, either via the TAB(-10,x) interface interface or via XCALL wrappers, for bidirectional communication /control of the PC. Examples include commanding the PC to transfer a file via FTP/SFTP, launch another app, perform file operations, return information about the PC environment, create screen objects, update the Registry (where the ATE configuration is stored), etc. In fact, since ATE is actually an A-Shell/Windows application, it can run A-Shell/BASIC code (see Remote SBX Call as Function) transferred to it by the host. This opens up a wide range of possibilities for auto-configuring the workstation and for extending application functionality to the PC using familiar A-Shell/BASIC code.

If any of that seems interesting enough to justify further discussion or investigation, please let us know and we’ll figure out what the next step should be.