Article 94578 of comp.os.vms: Path: cs.utk.edu!emory!swrinde!elroy.jpl.nasa.gov!netline-fddi.jpl.nasa.gov!nnt p-server.caltech.edu!news.cerf.net!mvb.saic.com!info-vax From: CANTERA@cisv.jsc.nasa.gov Newsgroups: comp.os.vms Subject: What is block mode? Message-ID: <777330964.430000.CANTERA@cisv.jsc.nasa.gov> Date: Fri, 19 Aug 1994 16:16:04 -0500 (CDT) Organization: Info-Vax<==>Comp.Os.Vms Gateway X-Gateway-Source-Info: Mailing List Lines: 24 Newsgroups: comp.os.vms Subject: RE: What is block mode? Message-ID: <9408202049.AA16873@uu3.psi.com> Date: Sat, 20 Aug 94 16:40:33 EDT Organization: Info-Vax<==>Comp.Os.Vms Gateway X-Gateway-Source-Info: Mailing List Lines: 103 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@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@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.] Article 94686 of comp.os.vms: Path: cs.utk.edu!stc06.CTD.ORNL.GOV!rsg1.er.usgs.gov!jobone!newsxfer.itd.umich. edu!zip.eecs.umich.edu!yeshua.marcam.com!charnel.ecst.csuchico.edu!olivea!decwr l!pa.dec.com!src.dec.com!crl.dec.com!jac.zko.dec.com!gemcil.enet.dec.com!winals ki From: winalski@gemcil.enet.dec.com (Paul S. Winalski) Newsgroups: comp.os.vms Subject: Re: What is block mode? Date: 22 Aug 1994 19:29:11 GMT Organization: Digital Equipment Corporation, Nashua NH Lines: 47 Distribution: world Message-ID: <33aua7$7uj@jac.zko.dec.com> References: <777330964.430000.CANTERA@cisv.jsc.nasa.gov> Reply-To: winalski@gemcil.enet.dec.com (Paul S. Winalski) NNTP-Posting-Host: gemcil.zko.dec.com X-Newsreader: mxrn 6.18-20 In article <777330964.430000.CANTERA@cisv.jsc.nasa.gov>, CANTERA@cisv.jsc.nasa.gov writes: |> |>IBM has been the provider of block mode terminals. Block mode generally mean t |>the your terminal screen is updated one screenful at a time. Actually, block mode applies to input operations, not output operations. With a conventional ASCII terminal, each character is sent individually as you press the key. In contrast, a block mode terminal stores all the characters on the screen in a buffer, including those that the user types. When the user presses a key (typically ENTER or one of the PF keys on an IBM 327x block mode terminal), all of the characters that the user has input are sent to the computer as a block of data (actually, the ENTER or PF only signals the CPU that the data are available, and the data block is sent upon receipt of a "read modified" command to the I/O controller, but the end result is the same). |> The idea is to |>only update those screen areas that have been changed for the completion of a |>transaction. Block mode terminal generally have both a return (which tabs on |>to the next field, and an return key that send the entire screen update to th e |>host computer. |> |>The idea is to speed up screen updates and cut down on the trafic needed for |>the terminals. This is a very important considetation when running at 4800 |>baud or below. There are several potential advantages to block mode: 1) It cuts down dramatically on the number of I/O interrupts to the CPU. Normal asynch terminals interrupt at every keystroke by the user, and the OS or other software must echo the character (I'm assuming full-duplex here). Block-mode terminals do not require character echoing by the CPU and only interrupt once for the whole block of data. 2) Since block-mode terminals buffer their data, they do not have to operate in real time. They can be run under half-duplex situations or polled from the CPU. This allows their use in party-line sorts of situations and makes better use of low-bandwidth lines. 3) The blocks of data can be transmitted at channel speeds where the terminal controller is directly attached to an I/O channel. Block mode is most suitable to transaction processing styles of applications rather than highly-interactive applications (such as a text editor). --PSW Article 5337 of comp.terminals: Path: cs.utk.edu!stc06.ctd.ornl.gov!fnnews.fnal.gov!uwm.edu!lll-winken.llnl.gov !sol.ctr.columbia.edu!news.cs.columbia.edu!news.smarts.com!usenet From: Jerry Leichter Newsgroups: comp.terminals Subject: Re: block mode terminals Date: Tue, 23 Jan 1996 10:23:25 -0500 Organization: System Management ARTS Lines: 64 Message-ID: <3104FD6D.EFB@smarts.com> References: <4e0s41$jlm@gateway.gtech.com> NNTP-Posting-Host: just.smarts.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0b5 (X11; I; SunOS 5.4 sun4d) Michael Zarlenga wrote: > > Can someone pls explain what a block mode terminal is and how it > differs from a non-block mode terminal? Non-block mode terminals send a character at a time. If the host wants to view those characters as comprising lines, screens, whatever, it must group the characters together itself. Block-mode terminals send groups of characters in a "block". The definition of a block depends on the terminal, and can often be controlled by the host. For example, the terminal might gather up characters, doing local editing with (say) backspace and the arrow keys, until Return is hit. Then the entire line is sent to the host. Many block-mode terminals are used to support form-based applications. In this case, the host sends a complete form, and the terminal allows the user to fill in the fields of the form. The user can do local editing and move around from field to field. Often, the host can tell the terminal how to validate some of the fields. At a minimum, it can specify maximum field lengths. Often, it can specify things like "numerics only" and "left-" (or "right-") "justified field", which control the appearance of the field as it is entered. Some fields may be marked "required"; others, "optional". Eventually, the user hits a "send" key. If the terminal is satisfied - e.g., if all the "required" fields have been filled in - all the data in the form is sent to the host in one block. If you know HTML, think of the
markup. There are actually two subclasses of block-mode terminals: "True" block mode terminals use some kind of network protocol to send a complete block as one network packet, so that the host is only interrupted once for the entire block. This is common in the IBM world, and allows a host to support huge numbers of terminals. However, such terminals are really useful *only* for block mode - if they can be set to send individual characters at all, they pay a high overhead to do so because they have to wrap them in all their usual network layers. "Pseudo-block mode" terminals use normal asynch lines, so they still really send one character at a time; it's just that they do local editing and validation and, when they do send characters, they send them in large groups with a known format. Hosts often still receive an interrupt per character, though in some cases specialized front-end hardware knows how to recognize a whole group and produce only a single interrupt. Most pseudo-block-mode terminals can also be used as traditional ASCII terminals. In fact, the ANSI X.39 spec that is the basis for the VT100 and most modern ASCII terminal designs includes a large set of commands to allow the terminals to be used in pseudo-block mode. I don't think anyone has ever implemented the full ANSI pseudo-block mode spec. DEC has had pseudo-block mode terminals for years - the VT132 was an extension of the VT100 that had block mode. The VT200 series, as I recall, had no block mode version. With either the VT300 or the VT400 series - I can't recall which, I think it was the VT300 - block mode support was simply merged into all the terminals in the series - memory had gotten cheap enough that it no longer made sense to maintain a separate line of pseudo-block mode terminals. At least in the DEC world, the block mode features of the VT132 and later DEC terminals was little used. It has never been supported by any DEC software. However, it apparently was used by some large customers in data entry/form filling applications. -- Jerry