This being a long post, except for those passionately interested in the background to this topic, I can imagine that eyes might glaze over at an early stage. Thus I have picked out a sentence from deep within what follows because it may have practical relevance:
"It so happens that (according to SNA Character String (SCS) rules), if an NL immediately follows NL, it is ignored." To continue: Unfortunately I didn't pay attention to the beginning of this thread - probably I tried to understand the first post but got lost in the translations - later confessed to have been unintentionally misleading. Now I see it is all very simple - as long as you pick out the key point Shmuel mentioned, namely that EBCDIC invented the "new line" (NL) in order to avoid any mess which might result from juggling the ASCII "carriage return" (CR) and "line feed" (LF). Unfortunately the world in its wisdom insists on using ASCII and so this NL<>CRLF conversion issue arises time and again. I bothered to check through the whole thread only because Shmuel brought up "SCS" and "3270". That sort of talk rings my bell.[1] I'll get the terms defined to be sure everything is understood. The terms are obvious when spelled out but I haven't seen any explanation so far and it might help. "Line Feed" (LF) is used to cause the printer mechanism of the typewriter to move down one line - at the same position across the page. Maybe the layout of the document you want to print allows not having the printing mechanism move to the left margin stop before printing the next line so making the printing process quicker - maybe. "Carriage Return" (CR) is used to cause the printer mechanism of the typewriter to begin movement to the left margin stop - while being positioned one the same line where it may have printed some characters already. This is definitely handy if you want to overtype in order to cause the characters to appear "bold*. The ink density will be approximately doubled and if the overtyping is not quite precise, the characters may even be slightly larger. Of course, you have a choice - probably a better one - which is to print a character, "back space" (BS), and print the same character again. This gives less chance for misalignment. "New Line" (NL) is used to cause the logic generating characters on the presentation surface to begin rendering on the next lower line and starting at the left boundary. You'll see I have deliberately used language which has cut loose from teletypes and allows the presentation surface to be a two-dimensional display. Of course, the presentation surface can also be a page in a printer. However it assumes that there is a buffer between the data stream on the transmission medium and the printing mechanism so that "null" characters do not need to be inserted.[2] I hardly need to point out that NL is superior to the CR and LF combination. Probably all the sages who have contributed so far know the above very well - except perhaps for the lack of ASCII NL. I'm only mentioning this because I have recently been accused of "teaching my grandmother ...". My riposte is that there may be those who are still ever so slightly moist where their mothers encourage them to wash and that these antique wonders need to be mentioned. Now, having got the ground work out of the way, I can concentrate on what I really wanted to cover. Indeed, NL<>CRLF matters for the SNA Character String (SCS). One instance is when an USS, that is, Unformatted System Services, message is to be sent to an X.3 PAD device through NCP/NPSI. The EBCDIC string which would otherwise have used NL characters has to have each NL replaced by CR, LF. However if double-spacing was required, each NL, blank, NL character sequence could be replaced by CR, LF, LF. "Why a 'NL, blank, NL character sequence'?", I hear you ask, "Why not NL, NL?". It so happens that, if an NL immediately follows NL, it is ignored. All this applies when the SSCPFM operand of the LU statement specifies USSNTO - the same requirement applied to ASCII devices connected through NTO. The EBCDIC data stream is translated to ASCII by the NCP before being sent. In addition the LU statement needs to have TERM=TWX specified so that an application, such as TSO, can detect (though INQUIRE DEVCHARS, "device characteristics") that the apparently LU type 1 device normally using SCS requires those NL>CRLF conversions. Since the NCP performs the EBCDIC to ASCII translation, why doesn't it perform the NL>CRLF conversion as well? That is, the equivalent of that "q" conversion in the pax command. Well, it was never considered that the 3704/5 instruction set should ever have to perform storage-to-storage moves such as would be required to insert additional characters. Thus those pesky NL>CRLF conversions have to be anticipated in the VTAM application or in the USS table message text. Actually, reviewing the Shmuel post that alerted me to look into this topic, the issues are all related to SCS and there's nothing in addition that relates to the 3270 data stream - or is there? Paul Gilmartin says that "IBM has done its best to confuse us on this point." I assume he means the "new line". I would rather say that IBM has tried to improve the situation. If anyone wants a point of departure it is IBM's decision to employ EBCDIC rather than ASCII. NL<>CRLF just happens to be (one of) the most prominent problem(s) associated with having the two character sets. Shmuel stated on yet another issue surrounding CR and LF which is how ASCII communicating partners responding to characters received from the keyboard "echo" the characters to the printer mechanism or display when operating "full duplex". This is another area where confusion can reign and it's all down to having two characters where one should really have been sufficient. Chris Mason [1] Another of those fascinating ASCII characters associated with teletype machines. <g> [2] Nevertheless, one mustn't lose sight of this issue.[3] It's important to match the secondary outbound pacing value to the buffer size for an LU type 1 printer, that is, where the SNA character stream (SCS) is used. [3] "Issue" used as it will be found in a Morocco-bound Webster's rather than the peculiar euphemism for "problem" I find so oddly used these days. Ha, I checked. "5 a : a final outcome that usually constitutes a *solution* (as of a problem) or resolution (as of a difficulty) " (my asterisks) ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
