Al Kossow wrote: here's a reference. They were used as terminals for DEC's transaction processing system (TRAX) Newsgroups: comp.os.vms Path:cs.utk.edu!emory!europa.eng.gtefsd.com!MathWorks.Com!mvb.saic.com!info-vax Message-ID: <9408202049.AA16873 at uu3.psi.com> Date: Sat, 20 Aug 94 16:40:33 EDT From: Jerry Leichter <leichter at lrw.com> Subject: RE: What is block mode? This might be a dumb question but I see in the SET TERMINAL command a qualifier called /BLOCK_MODE. Can somebody please explain to me what this might be used for ? What software would one need on the VAX to talk to a block mode terminal ? "norris8016 at delphi.com" comments: That qualifier is a relic of the days when DEC sold the VT131 block mode terminal. How well VMS handled such beasts I don't know. while "CANTERA at cisv.jsc.nasa.gov" describes IBM's block mode terminals, which transmit and receive blocks of characters - often whole screenfuls - at a time. Both are more or less right. A bit of background. First, the reason the qualifier exists at all is to help one write portable software - portable among different terminals, that is. At one time, on many earlier DEC OS's and on VMS prior to perhaps V3 (I'm not sure of the timing), operating systems kept very little information about terminals. Programs issued "what are you" escape sequences to terminals and acted based on the reply. Unfortunately, new terminals issued new replies - and programs stopped working. Anyone who used screen-oriented programs on, say, RSTS or RSX in the early '80's will recall programs that worked fine on VT100's, but refused to work on the functionally identical VT102. The eventual solution was to (a) come up with a list of "relevent" terminal characteristics; (b) centralize (in SET TERM) the knowledge of the connection between particular terminals and these characteristics; (c) insist that programs ask the OS about the specific characteristics they needed to operate, rather than try to figure out exactly what kind of terminal they were talking to. In addition, (d), the terminal answerback sequences were re-designed so that terminals, in addition to identifying themselves as "VT100" or "VT200 series", also reported their support of particular feature classes. The escape sequences involved are long and messy, and few programmers bother to try to parse them - they rely on SET TERM/INQUIRE's ability to do so and set the appropriate OS characteristics. The /BLOCK characteristic is one of just those characteristics. As "CANTERA" notes, the protypical block mode terminals are used in IBM environments. The interaction looks very different from the typical interaction with an ANSI terminal: The host sends a large block of data defining a form with various fields to be filled in to the terminal. The user fills in the form. Nothing is sent back to the host: The terminal positions the cursor to various fields in the form, and can enforce various constraints (a field is required; a field can only contain digits; a field is can hold up to 10 characters; and so on). When the user has filled in all the fields, he hits "send". The terminal gathers all the data from all the fields into a large, structured block and sends it to a host controller which receives it as one block, taking only on interrupt (rather than an interrupt for each character, as is typical of a DEC ASCII environment). Where appropriate, this kind of terminal imposes much less load on the host - IBM mainframes that by today's standards were less powerful than a typical PC supported hundreds of such terminals. Of course, if you want to write a screen editor like EDT, such a terminal won't work. As far as I know, DEC only made one true block mode terminal: The VT61 (or was it the VT62? I can no longer remember?) The VT61 was designed to be used with a long-forgotten system called TRAX. TRAX was a PDP-11-based dedicated transaction-processing system. A special terminal interface connected VT61's to a TRAX system; communication was based on multi-drop polled DDCMP. The VT61 could do all sorts of fancy on-screen editing before sending data back in a single DDCMP packet. (The VT62 - or perhaps I have the numbers backward - was a VT61 that used standard async lines. I don't know what they were supposed to be used for, and it's not clear to me that DEC ever actually *sold* any. Both terminals were based on the VT52, and did an impressive amount of processing for their size, given the era in which they were built. Within DEC, VT62's were used as VT52 replacements. When used this way, their main advantage was that, unlike the VT52, they supported reverse video.) The VT130 and the VT131 that replaced it were "pseudo-block-mode" terminals. They were, in a way, like the VT62: ASCII terminals connected over async lines that were able to do local editing and could send "blocks" of data - which were typically received a character at a time using standard async interfaces. (In principle, you could build hardware to efficiently receive whole delimited blocks, but I don't think anyone ever did - certainly, DEC didn't.) No DEC software ever used the block mode features, but a few third party vendors did (for fill-in-the-form and similar applications). When the VT200 series was introduced, none of the terminals in the series supported block mode. VT13x users stayed with their existing terminals. By the time the VT300 series was being designed, there was a clear demand from those users for a new terminal to replace the aging VT13x's - which DEC was actually still selling, I believe. Given the changes in technology over the years, the designers decided that it wasn't worth it create a special block mode VT300. Instead, the block mode features of the VT13x, with a few additions, were made part of the definition of the VT330 and VT340. (I don't recall if the VT320, which wasn't a "from the ground up" re-design but mainly a cost-reduced VT220, supported block mode.) If you look in the VT330/340 documentation, you'll find a chapter on "local editing mode", a more accurate description of the feature than "block mode" - but it's the same thing. You'll also find a note that "software support is required to use these features." As far as I know, no DEC software has ever used these features for anything - they were included entirely for users of non-DEC software who had been relying on the VT13x's. BTW, while it's not simple - it takes several keystrokes - it's possible to use the VT130's local edit mode to pick up anything currently on the screen, edit it, then send it to the host (i.e., on-screen cut and paste). Handy sometimes - but it's been long enough that I no longer remember how to do it! -- Jerry [Who was there when the VT300 series was being designed.]

Al> From memory, they are used with DEC's typesetting system (DECset) Al> They were commonly used by newspapers. It's been too long, but I think DECset was a VMS-based typesetting system (it may have been renamed and/or canceled before shipping). That probably didn't use the VT61, only the VT71 -- which is a micro-PDP11 based editing terminal with a substantial chunk of local memory. (You would send it the whole article, edit locally, and send it back tot he host.) The VT61/t was the "low cost" terminal used with Typeset-11 -- which is what I worked on in my first job at DEC, 1978-1980. (Possibly it was also used with Typeset-8; I don't know that product.) It supports local editing as well as forms entry, but only on 24 lines at a time. The primary use for it was for classified ad entry; it was also used for other editing applications when the volume of text wasn't too large. So at the news side of a newspaper, the editors would certainly have VT71s but the reporters (who have far less volume to handle) might be stuck with VT61/t's if the newspaper was trying to save money. I don't know any details on the communication protocol between terminal and host. It's some sort of error checking protocol, perhaps inspired by primitive stuff like Bisync, but I never worked on that part of the system. It's definitely block oriented -- you'd type text to fill in the screen, and hit a transmit key to send all that to the host. (In the case of forms entry, the form labels of course would not be sent.) There's also a VT61 without the /t; probably something similar but not customized for typesetting applications. And the VT62, again probably similar, designed for the very short-lived TRAX-11 operating system. paul