Print Solutions from Atac

Newsletter for Asia-Pacific Region

Fourth Quarter, 2002

Atac Pty Ltd

Australasian Distributor for Barr & Emtex

• Emtex - Printing AFP data on a Metacode Printer

• More DOS to NT (& Token-Ring to Ethernet) Upgrades

• Barr releases enhanced TCP/IP and FTP support

• Frequently Asked Questions

• Have your say

• Receive the latest catalogue

• Who else should get this newsletter?

• Unsubscribe

Your feedback is valuable to Atac and helps us provide the high standard of service which you have come to expect from us, and which we are proud to deliver.  Whether you have questions about our product range, a story to share regarding your experiences, or you would like to comment on our newsletter, just click here to send us an e-mail.

Recently, a large Melbourne-based print shop successfully completed testing of Emtex software’s AFP to Metacode functionality.  The AFP jobs usually print on Oce Pagestream continuous printers (A3 two-up duplex format).  This proved to be an issue for spoils/partial reprints, where often 50 feet of paper had to be threaded through the Oce equipment, simply to re-print a few pages which had been lost/destroyed.

The solution was to send the spoils jobs through Emtex, creating Metacode output which is then printed on cut-sheet Xerox equipment.  The Metacode jobs incorporate all the necessary resources, which are automatically deleted from the printer at job completion.  In order not to impact existing resources on the Xerox printers, specific (unused) filename prefixes for downloaded resource types were chosen.

Of course, an Emtex-supplied JSL is required to be loaded to the printer prior to printing the Metacode jobs.  As our print shop used existing Barr equipment to send the Emtex output to the Xerox printer(s), Emtex was configured to output to FILE, in Barr’s S/370 online channel format.

Several minor issues were overcome during testing, including 240 to 300 dpi barcode conversions, and resource substitution “on the fly” for one particularly difficult job.

Our customer chose their most difficult jobs for this testing, and all but one printed at full rated speed.  The remaining job printed at 95%+ of rated speed, and naturally ALL jobs passed rigorous post-print examination.

If you have print data in a particular format, and would like to print it on another type of printer, why not take advantage of Atac’s FREE conversion service to prove the technology for yourself.  Simply send us (up to) half a dozen of your most difficult jobs, and we’ll send you the print data back in the format you require.  This enables you to verify the functionality, with a minimum impact on your existing in-house resources.

Contact David Kirk at Atac today, to discuss this further.

More DOS to NT (& Token-Ring to Ethernet) Upgrades . . .

• The Singapore Inland Revenue department (IRAS) recently completed an exhaustive testing process on the Barr RJE/NT product, and successfully converted their three Barr DOS RJE machines to Windows 2000.  Live production continued on the new platforms, when they were cut over earlier this month, without a hitch.

IRAS also took the opportunity to eliminate their Token-Ring connectivity to their mainframe, and replace it with high-speed 100M’bit Ethernet.  Although technically the DOS to NT upgrade requires NO changes on the HOST, IRAS needed to reduce their frame sizes from 2k to 1k, to match the new topology. (Ethernet maximum frame size is around 1.5k).  However, the 100Mb Ethernet connection, combined with the enhanced RJE/NT performance, more than compensated for the frame size reduction.

• ANZ bank completed an upgrade to RJE/NT, of three production Barr machines at Mt. Waverley.  This was needed to fit in with their Windows 2000 roll-out, required to be complete by the end of August.  Atac was pleased to provide the solution for testing, and easily managed to proof and implement the upgrades with time to spare.

The new RJE connections were also implemented over 100M’bit Ethernet, instead of Token-Ring as in the old DOS system.  This resulted in the work from the mainframe coming down so quickly that the mainframe offloads are now completed in minutes instead of hours.  Naturally, print time is still the same, but operators now have the added benefit of being able to perform LOCAL restores and reprints from the Barr stations without any mainframe intervention at all.

Both IRAS and ANZ are now taking advantage of the extensive Security and Performance benefits of both the Windows 2000 platform and the Barr RJE/NT product.

• BARR/FTP (Beta release in 3.2.x *)

BARR/FTP is an FTP client module that is integrated with BEPS to allow fully automated FTP transfers both into and out of BEPS.  It is a client, not a server, because it goes out to user-configured FTP server sites to upload or download files.  It does not allow incoming FTP requests as a server would.

For upload, BARR/FTP ‘puts’ files into a pre-configured location on an FTP server.  Like all outputs from BEPS, this is configured as a printer in BARR/SPOOL.  For download, BARR/FTP polls a directory on the FTP server periodically.  Each time it polls, it asks for a directory listing, ‘gets’ all files listed, then deletes those files off the FTP server.  Clearly, you want to make sure it polls only the appropriate directory.

BARR/FTP supports standard FTP, but also supports the FTP connection that IBM offers to the JES2 input and output queues.  This allows BEPS to submit JCL to the JES2 input queue via FTP and to ‘get’ jobs down from the JES2 output queue.  In this mode, it can support text or line data, but not binary formats such as BARR/TRAN or Xerox Metacode, YET.

• BARR/PRINT TCP/IP Enhanced Support for Mainframe Printing

BARR/PRINT for TCP/IP (our LPD module) will support special features in IBM’s IP Printway and LRS’ VPS/LCDS packages on the mainframe.  The primary goal of the enhanced support is to allow mainframe print data, such as Xerox LCDS and Metacode, to be cleanly transferred from the mainframe to Barr without any conversions taking place. 

This is possible because these vendors now use a common record format that we call ‘Mainframe IP Record Format.’  This format is similar to IBM VBM or Barr S/370 format in that it uses a two byte record length field followed by carriage control and data.

In the case of IP Printway, the customer needs to define the LPR printer on the mainframe as a ‘Remote PSF.’  This will set IP Printway so that it transmits the Mainframe IP Record Format without any conversions on the data.  In the Barr software, a queue needs to be configured in LPD to use the Mainframe IP Record Format.  IP Printway has the additional advantage of sending header information such as Form name, Class and Destination when used in this way.

If the customer is using LRS’ VPS/LCDS software on the mainframe, then a socket connection needs to be configured on the Barr LPD side, also set for Mainframe IP Record Format.  VPS/LCDS sends a small header that has a Job name, but little else of interest, unfortunately.

• Summary

The two new TCP/IP based capabilities of BEPS will make it possible for many customers to move away from SNA based solutions to TCP/IP based solutions.  BARR/FTP will be useful to customers who need to submit JCL and receive line data reports from the host.  The enhanced BARR/PRINT for TCP/IP will be useful for customers who need to receive production print over TCP/IP from the mainframe.

* BEPS Version 3.2 is due out early November – David Kirk

Q.  Does Emtex's AFP input module require fully composed AFP files?

A.  No.  Emtex replaces IBM’s PSF and is therefore responsible for interpreting the AFP job stream and inserting resources where required.  If the AFP data is not “fully composed” (contains TAGS pointing at resources, not the actual resources themselves), then a directory accessible to Emtex must be established, where the AFP fonts etc. are placed.  A once only download of the required resources must be performed to establish the resource library.

Q.  Our BEPS system doesn't always display all the jobs in RETAIN which we expect to see.  How can this be corrected?

A.  Recent code revisions, implemented in BEPS 3.1.25.90 have corrected this fault.  Contact David Kirk for more details.

Q.  How fast can Emtex drive my printers?

A.  Emtex has been bench-marked at above 2500 ipm, but naturally the complexity of your jobs comes into play in a big way.  Additionally, this is the speed of a single Emtex Server; a fully blown client-server arrangement with multiple Emtex workstations will split the load among the workstations, providing as much processing power as required.  The Emtex client-server environment is scalable to virtually any size.  One site in America drives over 100 high-speed lasers via Emtex, in real-time.

Q.  While attempting to connect to our mainframe with our DOS RJE software, we get the error message "APPLID not available or invalid".  Other times we get the error message: "APPLID not available (NSPE)".  In both instances we were not able to connect to the host computer.  What do these error messages mean?

A.  There are several possible causes for these host-generated error messages that you are seeing.  Here are some of the possible scenarios:

If this is a new installation, or if changes have recently been made to the RJE software, this problem could be caused by improper settings in the BARR/RJE software.  For example, you could have entered an incorrect APPLID, LOGMODE, Remote Name or Password in the RJE Description menu when you configured the software.  It would be a good idea to verify the settings on this screen and compare them to the RJE Definition on the host you are trying to connect to.

Furthermore, a host-based security program could be intercepting the RJE logon attempt and is not authorizing the logon for some reason.  The host programmer/analyst can verify if this is the case.

Also, it is possible that there are no available SNA lines between VTAM and JES on the mainframe to log on to - thereby preventing the RJE logon attempt.  This can occur when VTAM is overloaded, when there are no active lines, or when JES is Inactive.  Have the host programmer verify that there are plenty of available SNA communication lines between VTAM and JES.  The lines must be "Active" and in a connectable state.  If the host programmer is not available, try the connection at a later time when the host is not so busy.

If you would like to receive a copy of the latest Barr or Emtex catalogue, click here to send Atac an e-mail.

If you would like us to send a copy of this newsletter to additional people, click here to send us an e-mail containing their e-mail address(es).

If you would prefer not to receive this newsletter, click here to send us an e-mail.

Atac is the distributor for Barr and Emtex in Australia, New Zealand and South-East Asia.  Based in Melbourne, Atac consults, installs and maintains Print and Communications products for corporate clients.