ATE, the A-Shell Terminal Emulator, was created to allow an A-Shell host to create and control a graphical user interface on a connected PC. A-Shell on the host "talks" to ATE on the PC, thereby making all the GUI capabilities of Windows available for A-Shell's use. The communications channel between the Linux/AIX host and the PC "terminal" may be used to relay reports—in this case a PDFX document—regardless of whether ATE's display capabilities are used for their original purpose.
Creating PDF documents via ATE is essentially the same as any other kind of ATE printing. The basic principle is that on the application server (i.e. the machine that ATE is being used to telnet/ssh to), you define a logical printer special pseudo device AUXLOC:, e.g.:
DEVICE=AUXLOC:
When a report is sent a logical printer defined using the AUXLOC: driver, A-Shell forwards it to the telnet client via the emulation of the auxiliary port terminal interface support by ATE, ZTERM and other terminal emulators. Typically, such terminal emulators then either prompt the user to select a Windows printer, or use a previously selected printer, to forward the output to. Any such terminal emulator could thereby generate PDF documents by routing the output to a PDF-generating printer driver. However among the available terminal emulators, only ATE would support A-Shell's GDI printing directives, and only ATE will be able to pass the necessary license code to the PDF-XChange driver to enable it. So if you want to use the //PDFX directives, and/or use A-Shell's license for the PDF-XChange driver, you will have to use ATE rather than another terminal emulator.
There are two ways to pre-configure the printing options in ATE:
| • | Use the printer configuration dialog (Settings..Connection Properties). Using this method for PDF generation, you can either set the printer choice to <prompt>, in which case it will prompt you each time for a printer, at which time you could choose the PDF-XChange driver when you wanted to create a PDF, or you could just set the printer choice to "PDF-XChange", in which case reports printed through the auxiliary interface would go directly to that printer. In either case, make sure to select the GDI printing radio button. |
| • | Create one or more printer init (PQI) files (logical printer definitions) and store them on the ATE client (in the 001007 directory). (The application on the server might do this under program control and arrange to have them sent automatically to the %MIAME%\DSK0\001007 directory on the ATE client in advance of printing, via ATSYNC.LIT, direct FTP, or other methods.) One the printer definitions have been stored on the ATE client, the host application can select them by appending the logical printer name to the DEVICE=AUXLOC: statement, e.g.: |
DEVICE=AUXLOC:PDF1
In the second case above, you would have multiple logical printer definitions on the application server, each corresponding to a printer definition on the ATE client (which, in the case of PDF printing, would look something like the example shown in the topic Create A-Shell PDF Printer. While this method is a bit more complex to set up, it allows the host application the same power and flexibility in selecting printers that are otherwise under ATE's control, as it can for printers that are directly accessible from the application server.
Note that when the PDF option is licensed on the application server, the license will automatically be distributed to ATE clients.
