RAF@NIHCU.BITNET (Roger Fajman) (04/01/88)
Can someone tell me if any of the available TN3270 implementations for the IBM PC (e.g., Berkeley, FTP Software, IBM) support printing from the IBM host to the PC printer (i.e., by emulating a 328x printer)? Is such a thing even supported by the protocol? Such a facility is quite important to some of our users who are using IMS applications that do printing. Thanks in advance.
jbvb@VAX.FTP.COM (James Van Bokkelen) (04/01/88)
As I understand the handling of an attached printer on a real 3270 (which isn't perfectly), the mechanism used to send the screen image to the printer is at the SNA or BSC level, rather than at the 3270 data stream level. The printer is another SNA or BSC device, and is subject to all the polling, etc. that that implies. Because TN3270 operates at the 3270 data stream level, and doesn't run SNA or BSC over the Telnet connection (the polling would be far, far worse than keepalives), there doesn't seem to be much chance of implementing a 328x emulation. Any IBM types understand exactly how IMS would try to request a 'Copy'? How would the UCLA ACP (for MVS) or Wiscnet (if you can run IMS on VM) deal with the request? What might it decide to send out the TCP connection? jbvb
BRUCE@UMDD.BITNET (Bruce Crabill) (04/01/88)
Actually, it should be possible. There are such things as 3270 printers and the hosts talk to them using 3270 data streams. In release 5 of CP, the LDSF (Logical Device Support Facility) (which is what most VM TELNET servers use to create pseudo terminals) was enhanced to support the following printers: 3286, 3284, 3286, 3287, 3288, 3289, and 3289 model 4. CP was enhanced in many other ways to support these including allowing a logical device to be attached to a virtual machine. Using these facilities, it would be fairly easy to modify the TELNET server running VM to support these printers (on the order of a few line addition to a table). After connecting to the server, I think you could direct your COPY key to the logical device that was created. How one indentifies which logical device was yours, is not clear to me at the moment, but it could be worked out. You could even attach the logical device to RSCS and use it as a remote printer. That has a lot of possibilities. I'll have to do some playing around with this concept. But the bottom line is, the data streams and at least VM will support 3270 type printers connected thru TCP/IP (Roger is probably more interested in MVS, but I would guess that something simular is available there too). On the PC end, all you would need is a 3270 printer emulator (which is a whole lot easier than a 3270 terminal emulator). I think there might be a market for such a facility. Bruce
SIMXT@UOTTAWA.BITNET (Lew Shepherdson) (04/05/88)
Printing is done on 328x printers in one of two ways: 1) Either a 'local copy' operation initiated by the COPY key. This is handled by the 3x74 controller without any interaction with the host. 2) By a host application writing directly to the printer. This is the more interesting case, and is used extensively by a number of host applications, such as CICS and IMS. Typically the way this works is that the host issues a VTAM request to 'acquire' the printer (contrast to a 3278 terminal which typically 'logs onto' the host application and the application 'accepts' the logon). If the printer is available, a session is then established between the application and the printer, and printer data streams can be sent to it. (Implementors note that there are two kinds of 328x printers...LU1 and LU3...do LU1 first, everything supports it.) All a TN3270 implementation has to do is distinguish printer sessions from terminal sessions, and then handle the printer data streams (either LU1 SCS (SNA Character Set) or LU3 DSP (mumble mumble)). The tricky part is on the host. On VM, the Logical Device Facility now supports printers. The TELNET server would have to create a logical printer and then 'ATTACH' it to the correct application (however that is determined). On VTAM implementations, the TELNET server has to 'open' an LU with the right printer name, and wait for it to be acquired by an application. In both cases, there has to be some way to associate the TN3270 printer with the 'correct' host printer. There are also problems with knowing when the printing is finished, and when to release the 'virtual' printer. So, the good news is that it can be done (we did it for a non-TN3270 implementation)...the bad news is that it requires a lot of host kludges and tradeoffs (choose carefully to match the application and how the users want to use the printers). Lew Shepherdson Simware Inc. (SIMXT@UOttawa.Bitnet)