To all interested in this topic, particularly, for the first topic, Norbert Friemel (for Gilbert Saint-Flour), Phil Smith and Edward Jaffe
Would someone be so kind as to explain why the two flavours for the operation of IND$FILE are tied to "Control Unit Terminal" (CUT) type and "Distributed Function Terminal" (DFT) type? I smelled a rat when this was first mooted and with each repetition the smell grew stronger! I can find nothing in the 3174 Functional Description Manual which forbids a CUT from being defined to support "Write Structured Field" (WSF).[1] Have I missed some subtlety in reading the manual? See later for a "subtlety" I managed to appreciate while composing all of this. For the benefit of any who may not be sufficiently familiar with what CUT and DFT may mean, I have taken the liberty to include a footnote to cover this point.[2] - I am not at all familiar with the internal workings of IND$FILE but have gathered from this discussion within this thread that there are two flavours: - 1. one which does *not* employ WSF - 2. one which does employ WSF and possibly depends on capabilities determined following an exchange of WSF-Read Partition-Query and Query Reply stimulated by the application noting that bit 0 of byte 1 of the presentation services field of the BIND image as found in the CINIT request unit is set to one It may be that the "capability" which prevents using the "WSF technique" - as we may now more accurately describe it perhaps - is detected in the "Query" exchange. Nothing in the "Query Reply" sections in the 3174 Establishment Controller Functional Description jumps out as a description what "capability" this might happen to be so I am again dependent on the "gurus" for enlightenment! - Gilbert Saint-Flour's way of describing the 3270 commands is a bit odd. In the 3174 Establishment Controller Functional Description, Write Structured Field is classified as a Write command in precisely the same way as the ones he mentioned: http://publibz.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/cn7a7003/2.1.1 <quote> 2.1.1 Introduction ... Write commands ... - Write - Erase/Write - Erase/Write Alternate - Erase All Unprotected - ... - Write Structured Field </quote> - Incidentally a sometime source of shaky information suggested that the PSERVIC operand of the MODEENT macro in the mode table entry corresponding to the BIND "image" used for the SNA session had to specify X'0280'. This is fine when the SNA session can be LU type 2 as for the SNA-oriented TELNET server, but is nonsense when the SNA session is required to be LU type 0 as is required even when the SNA session is used in conjunction with an OSA-ICC or similar equipment simulation a 3272 and its descendants. Also the context of this advice was wrong. The quoted discussion concerned the flavour of IND$FILE which did *not* employ "Write Structured Field" (WSF). But in order to act upon bit 0 of byte 1 of the presentation services string, WSF *must* be supported - logical really! - I have done a bit of 3270 data stream programming in the distant past. One point I noticed researching the topic was that if the arriving data overflows the presentation space dimensions, the address of the data simply has the maximum subtracted. (The influence of attributes is, in a sense, similarly propagated - whether or not arriving data overflows.) Unfortunately I cannot find a reference in 3174 Establishment Controller Functional Description in order to support this "memory". Perhaps someone reading this can. Assuming this is the case, it would seem to drive a coach and horses through the following: >...> Also, then IND$FILE transfer is limited to the size of your TSO screen. However I can see that this would necessarily apply to a work station playing the role of a CUT display device *coax-attached to a 3270 controller*. Although we are talking about configurations involving a TELNET server supporting 3270 data streams, ideally TN3270E protocols, the IND$FILE server logic has to assume the "worst"! What this means is that, unless the "Query" exchange is permitted, the IND$FILE server program is obliged to allow for the possibility that a 3270 control unit is a feature of the configuration and so the data handled by the IND$FILE client is quite simply whatever has been agreed/implied as the dimensions of the presentation space. - My first comment regarding a possible limitation imposed by the presentation space dimensions - before the coax-attached aspect dawned - was that presentation space dimensions have only a tenuous relationship to the number of bytes sent by an application when building outbound data. A single byte might need 3 bytes in order to set an address, two bytes to define attributes and, finally, a byte of data - a total of 6 bytes - unrealistic when scaled up but I hope the point is made! - The practical conclusion would now appear to be not to confuse readers with the reference to CUT and DFT but simply to advise that any emulator supporting IND$FILE will - ought to! - support WSF together with the "Query" exchange and so bit 0 of byte 1 of the PSERVIC operand of the MODEENT macro in the mode table entry used for the SNA session should be set to one[3] in order to benefit from the "WSF technique". Perhaps this advice will permit Laurence Tsai's IND$FILE transfers to be speeded up! - [1] The simple test was to see if there were any "hits" for "DFT" in the "2.2 Topic 3. 3270 Structured Fields", section numbers "2.2....". There are none - but don't take my word for it! [2] From 3174 Establishment Controller Functional Description: http://publibz.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/cn7a7003/2.4.1 <quote> 2.4.1 Introduction ... Two types of 3270 display stations can be attached to the 3174: Control Unit Terminals (CUTs) rely on the 3174 to interpret the data stream. Keyboards attached to 3270 displays enable the operator to change, edit, or create character displays except within fields defined by attribute characters as protected from local functions by the program. As messages are being composed or modified by local function, the changes are inserted in the buffer and then displayed. When the operator completes an operation and uses the Enter function or an AID generating function, an I/O pending interruption occurs. ... Distributed Function Terminals (DFTs) interpret the data stream because they have a control program downstream-loaded to them from the 3174 (the 3290, for example) or because of a control program loaded in their diskette drive or fixed disk (the 3270PC, for example). As a result, the 3174 simply passes the data stream between the host and the DFT without modification. Thus, the responsibility for data stream interpretation is distributed to these terminals. How the DFTs interpret the 3270 data stream is described in their individual description books. ... For DFTs, such as the 3290, the 3174 merely passes the data stream because the DFT can interpret the data stream independently. But for CUTs, such as the 3278, that are communicating with the 3270 host, the 3174 interprets every keystroke that is entered at the display stations. ... </quote> [3] And the penultimate byte should be set to X'03' - but that's another story! - Chris Mason On Fri, 21 Sep 2012 17:39:06 -0700, Edward Jaffe <[email protected]> wrote: >On 9/19/2012 5:39 AM, McKown, John wrote: >> With TSO IND$FILE, you must encode and decode all your data into a 3270 data >> stream. Which, due to TSO, is half duplex (like the old walkie talkies, only >> one side talks at a time). You then IP connect your TN3270 emulator to a >> TN3270 server which encodes the 3270 data stream. Also, then IND$FILE >> transfer is limited to the size of your TSO screen. I.e. send one screen of >> encoded data (at most 80x24, or 1920, bytes for a -2; 27*132==3564 for a >> -5); wait and decode the response (protocol overhead); wash, rinse, repeat >> until all data is transferred. The protocol and data translation (if any) >> overhead on ftp is much less. >> >> The above is just my SWAG based on some knowledge of how IND$FILE works >> internally. > >You've described the old CUT-mode interface. Somewhere around the early 1980s, >DFT mode was introduced. It does not encode the data, use a screen to send it, >or any of that. It simply wraps the binary data in a 3270 structured field >envelope and sends it via the WSF (write-structured-field) command. Any 3270 >emulator that still uses the CUT-mode interface for IND$FILE should be tossed >on >the trash heap of history... > >-- >Edward E Jaffe ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
