System for supporting an ERASE INPUT key with input suppression in a system for optimizing data transmission associated with addressable-buffer devices
BACKGROUND OF THE INVENTION 
     This invention relates to an improvement in a system for optimizing data transmission associated with addressable-buffer devices, such as that disclosed in co-pending U.S. Patent Application Serial No. 827,767, filed Feb 7, 1986,now U.S. Pat. No. 4,750,137 and assigned to the assignee of the present application. Said co-pending application is incorporated by reference herein. 
     The system disclosed in the above-cited co-pending application is one for optimizing the telecommunication of formatted data streams between a host computer, on the one hand, and a device that notes the data stream content in an addressable buffer, on the other. The device may be, for example, a screen-type display terminal, a printer, or other apparatus. The host and device may be in close physical proximity, as in the case of a local terminal at the site of the host, or they may be physically remote, as in the case of a dial-up terminal used to communicate with the host. 
     Data Streams 
     In many on-line computer applications, end-users utilize terminal devices to view selected data and sometimes to enter or update the data. A travel agent in Los Angeles, for example, might use a remote terminal to send a data stream to an airline reservtion host computer in Dallas requesting a display of all flights from Houston to New York. The host computer responds with a series of data streams containing the desired information. 
     Addressable Buffers 
     A number of common terminal devices use an addressable buffer associated, e.g., with a screen display or a printer. Generally speaking, a &#34;buffer&#34; is an organized group of updatable electronic memory cells reserved for a particular use. A display or print buffer is typically a buffer that holds information displayed on a terminal screen or a hard-copy printout. It could be said that the screen or printer serves as a &#34;viewer&#34; for examining the contents of the device buffer in much the same way that a microfiche viewer can be used to examine back issues of newspapers stored on fiche. 
     FIG. 1 shows a greatly simplified representation of a typical device buffer arrangement. The host computer sends a data stream to the terminal device over a telecommunications line. The device, preprogrammed with its own internal software of a kind well known to those skilled in the art, updates the contents of the display buffer in response to data streams generated either by the host computer or by the terminal user (e.g., through a keyboard). The display shows the updated contents of the device buffer. 
     Data Stream Protocols 
     The effectiveness of a communication system such as that represented in FIG. 1 is commonly enhanced by programming the host computer and the terminal device to handle data streams in accordance with a prespecified convention. Such a convention is known as a &#34;protocol.&#34; Protocols typically include specifications for treating some portions of a data stream as data and other portions as embedded commands. 
     In the example represented in FIGS. 1 and 2, an outgoing data stream from the host computer might include a command for the terminal device to prepare to write new data into the display buffer beginning at buffer address 7. The outgoing data associated with this command might then consist of the characters &#34;n o t&#34;. The terminal would process this command and modify the device buffer in accordance with the associated data. The display, which acts as a window on the buffer, would then read &#34;Now is not time .. .&#34; instead of &#34;Now is the time . . . .&#34; 
     Field Attribute Bytes 
     Some communications systems embed codes within the buffer itself that indicate to the terminal&#39;s internal software just how subsequent characters in the buffer should be presented on the display screen or printout. The IBM 3270 system is an example of such a system. In the simplified example shown in FIG. 3, the character at buffer address 1 is assumed to be a code that causes a terminal screen to display all subsequent characters (i.e., the characters stored at buffer addresses 2, 3, and so forth) extra bright on the screen. The code itself is displayed as a blank on the screen. All subsequent &#34;real&#34; characters are displayed extra bright until the brightness is turned off by another embedded code. In FIG. 3, a code representing &#34;normal&#34; display is shown at buffer address 6. The terminal causes subsequent &#34;real&#34; characters in the buffer (e.g., at addresses 7, 8, and so on) to be displayed on the screen at normal intensity. 
     In such a system, the data characters that occupy the elements of a device buffer between any two such control codes are commonly referred to as a field. The control code that occupies the buffer address immediately prior to the first character in a field is known as the field attribute character, or field attribute byte, for that field. In the simplified example of FIG. 3, the field attribute byte for the field containing the characters &#34;N o w&#34; is located at buffer address 1. 
     Techniques for controlling the field attribute byte are well known. Those skilled in the art will recognize that the IBM 3270 system, for example, utilizes known bit masking and shifting techniques to encode a number of different field attributes (brightness, etc.) into a single field attribute byte. One field attribute byte can thus control several attributes for any given field. 
     Modified Data Tag (MDT) Attribute 
     One of the field attributes provided for in some telecommunications systems, for example the IBM 3270 system, is known as a &#34;modified data tag&#34; (MDT) attribute. The MDT attribute works in conjunction with the terminal device&#39;s internal software or other control system: if the terminal notes that the MDT attribute flag for a given field is set, it includes the contents of the field in the next inbound data stream. 
     A host application can pre-set the MDT flag for a given field to ensure that the associated field data is transmitted inbound, whether or not it has been modified. Such a field is known as a &#34;pre-modified&#34; field. This technique may be useful, e.g., in a data base system where a host computer serves a number of devices, each of which is examining a particular record in a data base, by forcing each device to transmit certain portions of its buffer, e.g., the identifying number of the data base record. 
     System of Co-Pending Application 
     The optimizer system disclosed in the above-cited copending application is briefly summarized herein for convenience. A more detailed description thereof is contained in the co-pending application itself, which as noted above is incorporated herein by reference. 
     The optimizer system of the co-pending application is transparently interposed between a host computer application program and a telecommunications link connecting the host computer with an addressable-buffer terminal device such as a screen-display terminal, a printer, or other apparatus. The optimizer includes a computer program that remains resident in the host computer&#39;s memory. The program causes the computer (a) to divert outgoing data streams that would normally be transmitted to the device by the host; (b) to generate new optimized outgoing data streams conforming to the communications protocol in use; and (c) to hand back each optimized data stream back for further outgoing transmission in place of the corresponding original data stream. 
     Each incoming data stream reflects only the contents of the fields in the device buffer that have actually been modified. If the host has previously instructed the device to transmit all fields, however, whether or not modified, the host might attempt to retransmit the instruction or even take improper action. To prevent this, the optimizer creates a new incoming data stream, which conforms to the host&#39;s previously-noted expectations about the incoming data stream, and hands it back to the host in lieu of the data stream actually received. 
     The contents of an optimized outgoing data stream reflect the result of a comparison by the optimizer of (1) an image in random-access memory (RAM) of the &#34;updated state&#34; of the device buffer, namely the state assumed by the host application to exist in the device buffer after reception by the device of the original outgoing data stream; with (2) a similar RAM image of the assumed present state of the device buffer. The comparison is achieved by performing an exclusive-or (XOR) operation to generate a RAM image that indicates which characters in the updatedstate image reflect changes from the present-state image. In some systems, this XOR operation can be achieved by destructively superimposing the updated-state RAM image over the (no longer needed) present-state RAM image, thus eliminating the need for additional RAM for a third image. 
     The optimized data stream &#34;handed back&#34; by the optimizer thus represents the differences between the assumed present and updated states of the device buffer. Consequently, it is normally shorter than the usual displayrefreshing data stream which represents the entire updated state of the buffer, and it thus requires correspondingly less transmission time. 
     Modified Fields and ERASE INPUT Key Operation 
     When a buffer field in a remote device is changed by the operator, typically the remote device&#39;s internal programming causes the MDT attribute flag for that field to be set to the &#34;on&#34; state so that the field will be transmitted as part of the next inbound data stream. One particular type of change to a field, however, namely the ERASE INPUT key supported in some systems, does not cause the MDT flag to be set &#34;on.&#34; Instead it causes the MDT flag for all unprotected fields to be turned off. Even the MDT flags for pre-modified unprotected fields (i.e., MDT flags preset by the host application) are turned off by the ERASE INPUT key. Protected fields are unaffected. The term &#34;unprotected&#34; and &#34;protected&#34; refers to the state of a field attribute which respectively allows or does not allow changes to be made to the contents of the field. 
     In such systems, the ERASE INPUT key has two effects when pressed, caused by the internal programming which controls the remote device: (a) it &#34;zeroes out&#34; all fields in the device buffer whose attribute bytes do not indicate a &#34;protected&#34; state, i.e., it replaces the contents of each buffer memory location for those fields with nulls; and (b) it sets the MDT flag for those unprotected fields to the &#34;off&#34; state so that the zeroed-out fields will not be transmitted back to the host. 
     An example of a use of the ERASE INPUT key might be as follows. An operator of a remote device might wish to change the street address shown in a host-application database for a particular customer, but not that customer&#39;s city, state, or ZIP Code. Assume that all of these items are in unprotected fields. Once the existing information about the customer is displayed on the screen of the device, the ERASE INPUT key would zero out all unprotected fields to ease the keyboarding burden of erasing, then retyping, the data fields in question. Only the field in which the operator actually typed in new data, i.e., the street address, thereby turning &#34;on&#34; the MDT flag for that field, would be transmitted inbound to the host. The city, state, and ZIP Code would not be transmitted, even though the contents of those fields in the remote device buffer had been &#34;altered&#34; by being zeroed out. 
     Inbound Optimization and the ERASE INPUT Key 
     Inaccuracies can result when inbound optimization is used in a host-device system which supports an ERASE INPUT key of the kind just described. The inbound optimization referred to is of the type described in detail in the above-cited co-pending application. The inaccuracies arise from the fact that the optimizer&#39;s processing of an incoming data stream includes augmentation of the data stream with the contents of any pre-modified fields. In an unoptimized system, those contents would normally be transmitted inbound by the remote device, and which the host application therefore expects to be included in the incoming data stream. 
     When the ERASE INPUT key is pressed, however, not even pre-modified fields would be expected to be transmitted even in an unoptimized system (unless those fields were subsequently actually changed as described above). Under these circumstances, the augmented data stream created by the optimizer, which would include the contents of any pre-modified fields, would thus contain too much data and would not accurately represent the data stream that would have been transmitted inbound in an unoptimized system. Depending on the programming of the host application, this lack of &#34;transparency&#34; of the optimizer to the host application could result in errors or &#34;bugs.&#34; 
     SUMMARY OF THE INVENTION 
     In accordance with the present invention, an improved optimizer system is disclosed. The programming of the optimizer system of the above-cited co-pending application is altered so that the only MDT flags turned off in the optimized outgoing data stream are those associated with protected pre-modified fields. The programming is further altered so that when an incoming data stream is received by the optimizer, all unprotected fields in the present-state image are preprocessed prior to being updated from the incoming data stream to reflect the information available at the optimizer as to whether the ERASE INPUT key has been pressed. 
     If no unprotected fields were pre-modified in the original outgoing data stream created by the host application, or if all pre-modified fields in the original outgoing data stream are represented in the incoming data stream, then during such preprocessing the data portions of all unprotected fields in the present-state image are filled with the in-doubt character. This reflects the lack of information at the optimizer as to whether the ERASE INPUT key has been pressed, since it is possible that the key was pressed, and then all pre-modified fields were actually changed, thus turning the MDT flags back on. In such an event, non-premodified, unchanged fields would have been zeroed out at the remote device buffer, but would erroneously be represented in the present-state image as containing data. 
     On the other hand, if some unprotected fields were pre-modified, but less than all of them are included in the incoming data stream, it follows that all unprotected fields in the remote device buffer had at some point been zeroed out, and their MDT flags turned off, by an ERASE INPUT keystroke. All unprotected fields in the presentstate image are consequently filled with nulls during preprocessing to reflect this. 
     After either form of preprocessing, the present-state image is then used to construct a simulated, unoptimized incoming signal to be handed back to the host application, as described in detail in the co-pending application. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     In the drawings, FIGS. 1 through 7, described in more detail below, are reproduced from the drawings in the above-cited co-pending application for purposes of background information. 
     FIG. 1 is a simplified block diagram representing typical data telecommunications arrangements. FIGS. 2 and 3 are representations of maps of the contents of a display buffer. FIG. 4 is a simplified block diagram of a typical host application program as used in a telecommunication system. FIG. 5 is a simplified block diagram of the same system with an optimizer in accordance with the invention of the co-pending application interposed between the application program and the host communications device. 
     FIGS. 6A and 6C are flow charts of the operation of the optimizer of the co-pending application in processing an outgoing data stream. FIG. 6B is a block diagram of one of the operations represented in FIG. 6A. 
     FIG. 7 is a flow chart of the operation of the optimizer of the co-pending application in processing an incoming data stream. The reference numerals 70 and 75 have been added to the figure for ease of reference. 
     FIG. 8 is a flow chart illustrating the processing of an outgoing data stream; the method steps shown in FIG. 8 in connection with the present invention correspond to those of the co-pending application shown in FIG. 6C. FIG. 9 shows preprocessing steps performed in connection with the processing of an incoming data stream. 
     Throughout the following detailed description, similar reference numerals refer to similar elements in all Figures of the drawings. 
    
    
     DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS 
     In accordance with the present invention, the programming of the optimizer disclosed in the co-pending application is modified to support the use of an ERASE INPUT key. As pointed out in the co-pending application, the actual programming details may vary considerably depending on the kind of computer system used, the operating system, and so forth. 
     As shown in FIG. 8, protected fields in the outgoing optimized data stream are handled in a different manner than unprotected fields. Pre-set MDT flags are turned off prior to an outgoing transmission only for protected fields; such flags in unprotected fields are left alone. It will be noted that use of the ERASE INPUT key in a host-device system such as described above does not affect the MDT flags of protected fields, and so the optimization taught in the co-pending application need not be modified with respect to those fields. 
     Three possibilities exist with respect to unprotected pre-modified fields when an incoming data stream returns after such an outgoing transmission. First, in a special case, it may have been that no unprotected fields were pre-modified to begin with. Second, all pre-modified unprotected fields may indeed be included in the incoming data stream, i.e., the MDT flags for all such fields are turned on. Finally, less than all such fields may be included, i.e., some of the MDT flags for such fields are turned off. 
     In any of these three cases--i.e., any time ERASE INPUT key support is enabled in the optimizer--incoming data streams are preprocessed before being parsed as described in the co-pending application. Preprocessing in the first and second cases above, in which information is not readily available as to whether the ERASE INPUT key was actually pressed, are handled in a similar manner to each other. Preprocessing of the third case, in which the ERASE INPUT key is in fact known to have been pressed, is handled in a slightly different manner. 
     In the first and second cases above, the manner of handling of the incoming data stream is indicated by the absence of reliable information about the actual state of the remote-device buffer. This lack of information could adversely affect the next outgoing data stream. For example, the optimizer would ordinarily assume that any fields missing from the incoming data stream had their MDT flags turned off, meaning they had not been modified at the remote device since the previous outgoing transmission. On the next outgoing transmission, the optimizer might not include data for those fields in the optimized outgoing data stream (e.g., if the host application itself did not make changes), because of its assumption that those fields were unchanged at the remote device from the previous outgoing transmission. If the ERASE INPUT key had been pressed, however, those fields would indeed have been changed, by being zeroed out. The next outgoing data stream would thus include too little data; the zeroed-out fields at the remote buffer would incorrectly remain zeroed out. 
     Consequently, during preprocessing of incoming data streams in the first and second cases above, all unprotected fields in the present-state image are filled with the in-doubt character described in the co-pending application. This causes the present-state image to reflect the uncertainty about the contents of those fields. 
     In the third case above, incoming preprocessing is modified slightly. When not all pre-modified fields are included in the incoming data stream, it follows that the missing pre-modified fields must have had their MDT flags turned off. This in turn implies that the ERASE INPUT key must have been pressed, and that all unprotected fields must therefore have been &#34;zeroed out&#34; with respect to their contents at the remote device. Consequently, as shown in FIG. 9, all unprotected fields in the present-state image maintained by the optimizer are set to nulls. 
     After preprocessing in any of the three cases above, any actual changes in fields represented in the incoming data stream are then incorporated into the present-state image as described in the co-pending application. Any remaining nulls or in-doubt characters are omitted from the simulated unoptimized incoming signal as shown in FIG. 7. 
     The above-described optimizer support for ERASE INPUT key operation is preferably selectable by the user. Some remote devices may not have such an ERASE INPUT key, for example, in which case it would be preferable to deactivate optimizer support. This would result in all pre-set MDT flags in pre-modified fields being turned off, for maximum incoming optimization, as described in the above-cited copending application. 
     It will be appreciated by those skilled in the art having the benefit of this disclosure that this invention is believed to be capable of application in other situations. Accordingly, this description is to be construed as illustrative only and as for the purpose of teaching those skilled in the art the manner of carrying out the invention. As noted above, considerable variation can be expected in the actual manner of efficient implementation of the invention with respect to any particular computer system, operating system, etc. It is intended that the following claims be interpreted to embrace all such variations.