A-Shell applications can print via the ATE client by means of the A-Shell Printer Pseudo Device AUXLOC:, either by specifying "AUXLOC:" as the name of the printer in PRINT command or XCALL SPOOL operation, or by specifying the name of a logical printer whose Init file contains the command:
DEVICE = AUXLOC:{printername}
The AUXLOC: pseudo printer device causes the print file to be redirected to the auxiliary port on the current terminal or terminal emulator. If the emulator is ATE, it receives the print file, stores it temporarily on the local PC, then re-routes to print through the local A-Shell/Windows printer subsystem. If the optional printername is not specified in the DEVICE statement (above), then the choice of printer, along with various printer configuration options, will be determined by the Printer tab in the ATE profile configuration dialog. Otherwise, ATE accepts the printername specified in DEVICE statement and attempts to route the file to a printer by that name, which must have been pre-configured and visible to the ATE client PC.
When spooling via the AUXLOC: device, the {NO}FF, {NO}LANDSCAPE, {NO}PASSTHRU and AUTOFF switches are forwarded to ATE where they will override the options set either in the specified printer init file, or in the printer configuration dialog. This is mainly a convenience to allow forcing an option such as landscape without having to create a separate printer init file on the ATE client for it.
Notes
As is the case on the application server, ATE also first attempts to interpret the specified printer name as the name of printer init file (either SYS:printername.INI or ASHCFG:printername.PQI) or as the name of a printer known directly to the operating system. The only difference is that the SYS: and ASHCFG: devices defined to the ATE client will be local to the client PC, and ATE printers are always Windows printers known to the ATE client PC, whereas the application server printers will be those known to the application server.
ATE also recognizes the pseudo printer PROMPT:, so for example, if the host application printed to a logical printer called LOCAL, whose printer init file (e.g. ASHCFG:LOCAL.PQI) contained this statement:
DEVICE = AUXLOC:PROMPT:
then the file would be sent to the ATE client which would then print it to the pseudo-printer PROMPT: (in other words, it would display the standard Windows printer selection dialog and print to whatever printer the user selected). The same thing would happen with DEVICE=AUXLOC: (omitting the "PROMPT:") if the ATE Printer dialog had specified <Prompt> as the default printer. But by appending the desired printer to the end of the DEVICE=AUXLOC: command, the application server is able to override the local ATE printer settings.
See the A-Shell Setup Guide for full information on defining printers to the application server, and see TAB(-10,54) in the section on Extended TAB commands in the A-Shell Development Guide for more information about special ATE extensions of the auxiliary printing protocol.
History
2011 August, A-Shell 5.1.1228: The server now informs the client of the size of the file being printed, allowing ATE to display a proper progress bar if either the bottom status or system status lines are visible. This is mainly a benefit when printing files large enough to take more than a couple of seconds to transfer, so that user doesn't wonder if the connection is dead. Note that to get the benefit, both the server and client sides must be updated to 1228, but there is no harm in updating either without the other.
2009 February, A-Shell 5.1.1137
It is now more difficult to accidentally terminate aux port printing (mainly with big reports). Previously, a two second interruption in the data flow (which could be caused by suspending ATE processing by opening the menu bar), or a Ctrl+X would have closed the aux port channel, causing the remainder of the report to appear on the screen. Now, either case will prompt the user to confirm the abort, and in addition, the timeout logic is now smarter so it doesn't get fooled by ATE being busy or suspended.
For workstations running XP or higher and that have created any GUI objects since the start of the session, a small activity bar "marquee" will display in the lower right corner of the dialog or window during the printing. Clicking on the marquee acts like hitting Ctrl+X (i.e. prompts the user to confirm that they really want to abort printing.)
2008 December, A-Shell 5.1.1131
When ATE receives a file to print via the AUXLOC: device, it stores the file in the My Documents\APEX directory, appending a -# suffix to the name to make it unique. (This way, if you reuse the same report file name, APEX will be able to keep unique copies for reprint/review purposes.) So, for example, if the application printed a file call "abcdef.prt", ATE might store it as "abcdef-3.prt". In the case of APEX, the file may then be converted to "abcdef-3.apf" (APEX performs some preprocessing on the file to facilitate paging operations.) Previously, there was no guarantee that the suffixes of those two files would be the same, which caused some complications for applications that try to either trace files through the printing process, or which need to send auxiliary files to be associated with specific print files by name. Now, ATE assigns unique suffixes in such a way that they do not conflict with any existing APEX apf files, and thus APEX does not have to reassign the suffix.
Also: A new virtual printer, "NULL", can be specified in order to get the normal file capture and assignment of unique name in the APEX holding directory, without actually printing. You can use this technique to reverse the order described above, sending the metadata file first and then the print file, in this case using the "-#" suffix on the print file itself (in order to make it match up with the previously sent metadata file).
