Data Transmission Optimizer Including Device-Specific Attribute Elmination

This application is one of five related co-pending applications filed simultaneously, namely: (1) Ser. No. 255,034, for Improved Data Transmission Optimizer, Including Query Suppression Feature, by Philip V. Wiles, Jr. and Thomas A. Harper; (2) Ser. No. 255,030, for Improved Data Transmission Optimizer, Including Multi-Pass Symbol Buffer Optimization, Trial Generation Feature, and MDT Reset Voting Feature, by Thomas A. Harper and Philip V. Wiles, Jr.; (3) Serial No. 225,033, for Improved Data Transmission Optimizer, Including Dark-Field Elimination Feature, by Carol R. Harper and Philip V. Wiles, Jr.; (4) Ser. No. 224,922, for Improved Data Transmission Optimizer, Including Device-Specific Attribute Elimination, by Thomas A. Harper, Philip V. Wiles, Jr., and Carol R. Harper; and (5) Ser. No. 224,895, for Improved Data Transmission Optimizer, Including Programmable Symbol Code Point Sorting Feature, by Theodore R. Ernst and Thomas A. Harper. All of the foregoing applications are assigned to the assignee of this application.

This application is also related to Ser. No. 140,293, which is a continuation of Ser. No. 827,767, now U.S. Pat. No. 4,750,137, issued Jun. 7, 1988, to Harper et al., assigned to the assignee of this application and incorporated herein by reference (hereinafter the '137 patent).

This application is additionally related to co-pending Ser. No. 948,150, filed Dec. 31, 1986, by Wiles et al., now U.S. Pat. No. 4,837,679, issued Jun. 6, 1989, assigned to the assignee of this application (hereinafter the '150 application), also incorporated herein by reference.

This invention relates to improvements in a system for optimizing data transmissions such as that disclosed in the '137 patent.

Referring to FIGS. 1 and 2, the '137 patent and the '150 application disclose mapping-type optimizing systems for optimizing data exchanges between a host unit 25 (e.g., a data base application program running on a programmable computer) and a peripheral device 15 that has an addressable buffer (e.g., a terminal device). The addressable buffer may be a screen buffer 16 and/or one or more programmable symbol buffers 17.

Generally speaking, if the host unit 25 attempts to send any signal to the peripheral device 15 (e.g., a signal that would cause an erasure and a subsequent rewriting of the device's buffer), the optimizing system:

(1) intercepts or blocks the attempt;

(2) compares (i) a present-state map of the existing information contents of the buffer with (ii) an intended-state map of those information contents as expected to exist after receipt of the signal by the peripheral device 15;

(3) constructs a new signal that, instead of erasing and rewriting the buffer, "surgically" changes only those portions of the buffer that need changing; and

(4) sends the new signal to the peripheral device 15 in place of the original signal from the host unit 25.

As shown in FIG. 2, the map comparison step generally consists of performing an exclusive-or (XOR) process, using the present-state map and the intended-state map as operands, to generate a difference map. In the difference map, null characters signify locations where the present-state map and the intended-state map are identical; non-null characters signify locations where they differ. From this information, the new signal is constructed.

Many types of peripheral device 15 include one or more programmable symbol buffers 17, each of which has a specified number of memory blocks or "slots" for storage of bit-mapped symbol images. Typically, for example, a peripheral device 15 supporting the IBM 3270 protocol may include several symbol buffers; a host unit 25 can program any given slot with a specific bit-mapped symbol image.

The host unit 25 can then cause graphic shapes to be displayed on the peripheral device 15 by ordering particular symbol images (identified by "code point" designators) to be displayed at specific points on the screen of the peripheral device 15.

FIG. 3 shows an example of two slots in a programmed symbol buffer. A slot 46 contains a bit-mapped image of a straight vertical line; a slot 49 contains a similar image of an upward caret. A vertical arrow can be displayed on the screen of the peripheral device 15 by ordering the slot 46 to be displayed at two places on the screen, one above the other, with the slot 49 being displayed just above that.

As shown in FIG. 4, some peripheral devices 15 have the capability to display symbols in color through the use of separate buffer planes for separate colors. For example, a peripheral device 15 may have a "red" plane, a "blue" one, and a "green" one. Various colors (see Appendix 10) can be displayed by setting selected bits in the appropriate planes; for example, a portion of a symbol can be displayed on the screen in white by setting the corresponding bits in all three color planes of the symbol buffer.

In accordance with the present invention, an optimizer performs additional optimization in conjunction with the optimization system of the '137 patent.

A QUERY SUPPRESSION routine is performed to suppress redundant device-capability queries sent by a host unit applications program 25 to a peripheral device 15. Whenever such a query command is initiated by the host unit applications program 25, the optimizer checks its own saved information to determine whether the information requested by the host unit has already been obtained. If so, the QUERY SUPPRESSION routine writes a minimal substitute query command. When the reply comes back from the peripheral device, the optimizer "fills in the blanks," using its previously stored information, to provide the reply signal expected by the host unit.

A READ BUFFER SUPPRESSION routine is performed to suppress commands requesting that the peripheral device 15 transmit the entire contents of its screen buffer 16 inbound. Whenever such a command is initiated by the host unit applications program 25, the optimizer checks its own saved information to determine whether the information requested by the host unit has already been obtained. If so, the READ BUFFER SUPPRESSION routine writes a minimal substitute command. When the reply comes back from the peripheral device, the optimizer "fills in the blanks," using its previously stored information, to provide the reply signal expected by the host unit.

The optimizer performs a multi-pass scan to optimize multiple-plane symbol buffers. A total of seven scanning passes of the difference map planes is made: A triple-plane scan in search of white characters; three dual-plan scans in search of turquoise, yellow, and pink characters, respectively; and three single-pass scans in search of red, blue, and green characters, respectively. This minimizes the length of the output signal required to effect the changes to the multiple planes.

A DARK FIELD ELIMINATION routine is performed: protected "dark" fields are overwritten with nulls in the present-state and intended-state maps, so that the contents of the dark fields are not included in the outgoing signal.

A DEVICE-SPECIFIC ATTRIBUTE ELIMINATION routine is performed: if the peripheral device 15 is not capable of displaying information in different attributes (e.g., some display devices are not capable of displaying data in a blinking manner), all such attributes in the present-state and intended-state maps are overwritten with nulls, so that the attributes are not included in the outgoing signal.

An MDT-reset voting routine is performed to determine whether selective setting of modified data tags (MDTs) can be done more effectively by (a) clearing all MDTs and individually setting desired MDTs, or (b) individually clearing desired MDTs. The approach resulting in the shorter signal is utilized.

For each triplet of non-null, null, and non-null character sequences in the map being scanned, the optimizer tests whether a shorter signal would result from (a) writing two separate subsignals, one for each of the non-null character sequences, or (b) writing a single signal encompassing all three sequences as a single concatenated sequence. The approach resulting in the shorter signal is utilized.

A present-state list of values of programmed symbols already downloaded to a peripheral device 15 is sorted, and to be downloaded is likewise sorted. A search is performed to detect any commonalities that might exist between the present-state and intended-state programmed-symbol values, even under differing programmed-symbol designators. When such a commonality is detected, the intended- state designator is altered to be equal to the present-state designator; thus, that particular programmed symbol value need not be redownloaded.

FIG. 1 is a simplified block diagram of a typical host unit applications program as used in a telecommunications system, having an optimizer in accordance with the present invention interposed between the applications program and a signal routing unit.

FIG. 2 is a block diagram of the exclusive-or (XOR) process used in the '137 patent to generate a difference map signifying changes in a buffer of a peripheral device.

FIGS. 3A and 3B together is a sketch of two programmed symbol buffer slots. FIG. 4 is a sketch of an arrangement of three color-related buffer planes in a programmed symbol buffer.

FIG. 5 is a diagrammatic overview of certain processes in accordance with the invention.

FIG. 6 is a simplified representation of the contents of a screen buffer with a "dark field" included.

FIG. 7 is a simplified representation of a scan map as used in the TEST SIGNAL routine (Appendixes 25-27).

Throughout the following description, like numerals refer to like parts in all drawings.

Referring to FIG. 1, a telecommunications system is shown in which incoming and outgoing signals are exchanged between a peripheral device 15 and a host computer 20. (An incoming signal is defined here as a signal transmitted from the peripheral device 15 to the host computer 20, and vice versa.) The peripheral device 15 includes a screen buffer 16 and one or more programmable symbol buffers 17.

The host computer 20 typically executes multiple computer programs substantially concurrently (e.g., in a multiprogramming environment such as provided by the IBM MVS system). As shown in FIG. 1, the host computer 20 executes host unit application programs 25 and a signal-routing unit program 30 which handles communications between the host computer 20 and the peripheral device 15.

An optimizer 35 monitors communications between the host units 25 and the peripheral device 15 by intercepting incoming and outgoing signals. As shown in FIG. 1, the optimizer 35 is interposed between the host units 25 and the signal-routing unit 30.

The optimizer 35 may be implemented by programming the host computer 20 to perform the functions described herein as shown in FIG. 1. For purposes of illustration, the discussion below refers periodically to programming of a computer operating in conjunction with the well-known IBM 3270 communications protocol and MVS operating system.

Alternatively, of course, the optimizer 35 could be implemented in, or as, a machine separate from the host computer 20, interposed between the host computer 20 and the peripheral device 15.

Appendixes 1 through 30 set forth a generalized pseudocode outline, in a "structured English" format, of an exemplar design for a computer program in accordance with the invention. The pseudocode is intended as a general description and is not meant to be limiting. For example, it uses the term "data structure" somewhat loosely, to describe generically a simple variable in memory, a complex data structure, a disk file, or other means for storing data. For convenience of illustration, the pseudocode is broken down into a number of routines. However, those skilled in the art will appreciate that some of the routines may be combined, and others may be broken down still further.

The actual optimum organization and structure of an computer program in accordance with the invention will depend greatly on the characteristics of the system on which the invention is implemented. Certain functions described in the pseudocode may not be available on a given machine and must be simulated; or, a group of functions described here may be able to be collapsed into fewer functions on another machine.

The pseudocode is only an outline and does not necessarily set forth a complete program listing. For example, testing for boundary conditions is sometimes described explicitly in the pseudocode and sometimes is referred to only implicitly. By and large, the pseudocode does not set forth error trapping/ handling or similar functions.

It will be recognized by those of ordinary skill that, given the benefit of this disclosure, the implementation of an optimizer 35 on any given model of computer running any given operating system, to take advantage of the features of the computer and operating system, is a matter of conventional programming by those familiar with the particular computer and operating system.

The general design approach of the optimizer 35 for outgoing signals may be described as follows: an outgoing signal generated by a host unit applications program 25 is parsed into what may be termed component parts. Commands in the outgoing signal that would affect the screen buffer 16 are processed, and substitute component-part commands are generated. Likewise, commands affecting any symbol buffers 17 are processed, and substitute component-parts for those commands are generated. Finally, a substitute signal is constructed from the substitute component parts.

Some telecommunications protocols (e.g., the IBM 3270 protocol) permit a host unit 25 to use a query command to interrogate the peripheral device 15 as to the peripheral device's characteristics (e.g., screen colors supported, symbol buffer availability, etc.). Upon receipt of such a query, the peripheral device 15 responds with a signal specifying the requested information.

Some host units 25 may be programmed to send such a query with every outgoing signal. This can result in needless repetitive transmission of the same requested information.

To reduce such repetitive transmissions, the optimizer 35 may include a QUERY SUPPRESSION routine, e.g., as is set forth in Appendix 4.

As shown in Appendix 4, when a host unit 25 generates a query signal, the QUERY SUPPRESSION routine checks whether the requested information has already been received. If not, the optimizer 35 passes the query signal on unchanged. When the response to the query signal is received from the peripheral device 15, the optimizer 35 saves the contents of the response. (See Appendix 30.)

Upon subsequent query signals to the same peripheral device 15, the optimizer 35 in essence converts the query signal to the minimum query signal that can be generated (see Appendix 4). In an IBM 3270-type system, for example, a query signal may be a READ PARTITION QUERY command. If the requested information about the peripheral device 15 has already been received, the QUERY SUPPRESSION routine converts this command to a READ PARTITION QUERY LIST NULL command. Upon receipt of the peripheral device 15's response to the query signal, the optimizer 35 converts the response to conform to the query signal initiated by the host unit 25.

Some telecommunications protocols allow a command to be transmitted to a peripheral device 15 that causes the peripheral device 15 to transmit inbound the entire contents of the device's screen buffer 16 (and perhaps the contents of its symbol buffer(s) 17). In the IBM 3270 protocol, for example, the READ BUFFER command performs this function.

If the contents of the screen buffer 16 are already available, such a command results in inefficient use of telecommunications resources. The optimizer 35 may include a READ BUFFER SUPPRESSION routine, e.g., as shown in Appendixes 5 and 30, to suppress such commands. The operation of this routine is generally like that of the QUERY SUPPRESSION routine discussed above.

The optimizer 35 may include routines to optimize signals directed to programmable symbol buffers. One such routine, SYMBOL BUFFER COMMAND PROCESSING, is set forth in Appendixes 6 through 12.

The SYMBOL BUFFER COMMAND PROCESSING routine operates generally in the manner of the optimizing system of the '137 patent; it includes an advantageous approach to handling devices that support multiple color-plane loading.

The SYMBOL BUFFER OPTIMIZATION routine (called by the SYMBOL BUFFER COMMAND PROCESSING routine) performs its optimizing scanning of three difference-map color planes (red, blue, green) in a manner to minimize the size of the outgoing data signal. (Scanning of difference maps is done to locate points where the intended state of the peripheral device 15's buffers differ from the present state of those buffers, i.e., where changed-character sequences exist.)

The SYMBOL BUFFER OPTIMIZATION routine performs a total of seven scanning passes: a triple-plane pass to pick up all three-color (i.e., white) changed-character sequences; three successive dual-plane passes to pick up all two-color (turquoise, yellow, pink) changed-character sequences; and three successive single-plane passes to pick up all one-color (red, green, blue) changed-character sequences.

This approach may result in longer computation time than a single scan of each of the three planes. However, it can advantageously minimizes the number of commands (e.g., LOAD PROGRAMMED SYMBOLS structured fields in the IBM 3270 protocol) that must be written. In the IBM 3270 protocol, for example, for a white changed-character sequence, a single LOAD PROGRAMMED SYMBOLS structured field can include a command which specifies changing all three color planes at that address. This is advantageous over scanning each plane separately, where three separate such structured fields (one for each color plane) must be written for a white changed-character sequence.

Sorting of a programmed symbol set in order of symbol value, prior to optimization as described above, is sometimes advantageous. The advantage arises when (1) a host unit 25 orders the downloading of a programmed symbol set to a peripheral device 15, (2) many of the programmed symbol bit-mapped images are the same as before, but (3) the still-the-same images are designated for storage in different slots Within the peripheral device 15's symbol buffer than before. Without sorting, a programmed symbol image is wastefully downloaded to a peripheral device 15, even though the same image is already present at the device in a different slot within the symbol buffer.

The sorting process (not shown in the Appendixes) is accomplished by creating (1) a map of the present state of the bit-mapped symbol images stored in the different slots of the symbol buffer, identified by slot designator; and (2) a similar map of the symbol buffer as it would exist after receipt of the outgoing signal generated by the host unit 25.

The maps are then searched for possible commonality of bit-mapped symbol images between pairs of slots in the respective maps. For example, a slot 5 in the present-state map may contain the same bit-mapped symbol image as a slot 8 of the intended-state map. Retransmission of this symbol image would be wasteful of telecommunications resources.

It will likely be advantageous to sort each map, e.g., in ascending order of symbol value, prior to commencing the search. (The pattern of on- and off bits in the bit-mapped symbol image can be treated as a binary symbol value and sorted accordingly.)

A variety of search techniques may be used, as will be appreciated by those of ordinary skill having the benefit of this disclosure. For example, the value of a symbol image in the sorted intended-state map may be used as the search target in a scan of the present-state map: if the scanned values in the present-state map become greater than the value of the target, the starch has failed as to that target.

Whenever such commonalities (and potential waste) are found, the optimizer 35 substitutes the existing slot designator (slot 5) in the new outgoing signal in place of the slot designator specified by the host unit 25 (slot 8). This substitution causes designator conflicts if the host unit 25 also used the existing slot designator (slot 5) to designate a different symbol image; a suitable hashing-type algorithm is therefore used to prevent such conflicts.

The optimizer 35 may alter the map(s) of the screen buffer 16 to permit implementation of additional optimization techniques. (See Appendixes 16-21.) Generally, this alteration entails overwriting certain fields in the map of the intended information content of the screen buffer 16 to permit more efficient information transmission.

Both the present-state map (which represents the information content of the peripheral device 15's buffers as "perceived" by the host unit application program 20) and the intended-state map are so altered just prior to the exclusive-or generation of a difference map (see FIG. 2). For integrity purposes, the only fields that are so altered are protected fields (i.e., fields that cannot be modified by a user at the peripheral device 15).

Specific alterations to the map are discussed in more detail below.

One of the routines that may be called by the IMAGE ALTERATION routine is the BLANK-TO-NULL CONVERSION routine (Appendix 17).

Blanks and nulls usually have the same appearance (i.e., no appearance at all) on a display screen. Therefore, if a run of characters to be transmitted to a peripheral device 15 consists entirely of intermingled blanks and nulls, it is advantageous to convert the run to a homogeneous sequence, thus allowing the use of a repeat-to-address command.

(As those of ordinary skill are aware, a repeat-to-address command instructs the peripheral device 15 to display a specified number of a particular character, usually at a savings in signal length. For example, such a command may require 5 characters to instruct the peripheral device 15 to display 27 consecutive spaces, plainly a savings of 22 characters in the signal.)

To this end, the BLANK-TO-NULL CONVERSION routine converts all protected-field blanks in the map of the screen buffer 16 to nulls.

An exception is made in certain systems in order to maintain transparency with certain screen-print routines. In such systems, when a screen is printed, the printing of lines on the screen having no characters other than nulls is suppressed. Thus, if a screen is displaying 25 lines, and one line contains all nulls, that line would not be printed.

To maintain transparency, the BLANK-TO-NULL CONVERSION routine keeps track of screen line boundaries. If a line on a screen consists entirely of characters which would be converted to nulls, and at least one blank character, then at least one blank character is left in the intended-state map at a location "on" that line. Thus, if the screen image resulting from the outgoing signal generated by the optimizer 35 is printed, the printed screen image will reflect null-line suppression if and only if the outgoing signal initiated by the host unit applications program 25 would have produced such a screen image.

Another image-altering routine may be a DARK FIELD ELIMINATION routine (Appendix 18).

Some host unit application programs 25 include one or more "dark fields" in an outgoing signal. As shown in FIG. 6, a dark field is typically a string of characters (e.g., an error message) that are downloaded to a peripheral device 15 for writing to the screen buffer 16, but are delimited by a non-display field attribute (shown as PDFCS in FIG. 6).

The characters in the dark field are thus present in the screen buffer 16. Because of the non-display attribute, however, they are not visible on the screen of the peripheral device 15.

A dark field can be activated, so to speak, by overwriting the non-display attribute with a suitable display attribute (e.g., an attribute that causes the error message, already in position, to be suddenly displayed in flashing characters, in red, etc.). If a host unit application program 25 is also designed to refresh the screen buffer 16 every time an outgoing signal is transmitted, then the repetitive transmission of such a dark field is inefficient.

The optimizer 35 may be designed to perform a DARK FIELD ELIMINATION routine (Appendix 18) to prevent any transmission of a protected dark field.

The dark field may subsequently be activated by the host unit 25 through initiation of a suitable outgoing signal. It this disclosure that in this event, the dark field will appear in the difference map as a sequence of non-null characters. Its contents will therefore be transmitted to the peripheral device 15 as part of the new outgoing signal constructed by the optimizer 35.

A FIELD MERGE routine may be called by the IMAGE ALTERATION routine.

As shown in Appendix 19, if two successive protected fields have the same field attribute byte, the field attribute byte for the second protected field is redundant and can be eliminated.

For some peripheral devices 15, e.g., printers, the attribute byte essentially serves no purpose. The DEVICESPECIFIC ATTRIBUTE ELIMINATION routine (Appendix 20) checks previously-stored information (see INITIALIZATION (OUTGOING) routine, Appendix 2) to determine whether the peripheral device associated with the particular communications session requires attributes. If no attributes are required, the routine overwrites all character sequences designating such attributes with nulls.

A NULL FIELD ATTRIBUTE ELIMINATION routine (Appendix 21) may be called by the IMAGE ALTERATION routine.

As noted above, null characters ordinarily are not visible on a screen. Thus, if a protected field consists of nulls (e.g., which may result from the BLANK-TO-NULL CONVERSION routine), any attributes defining the field are superfluous, provided of course that the attribute does not follow (and therefore delimit) an unprotected field. For example, nulls do not appear as bright characters, and so therefore a bright attribute for a null field is surplusage in an outgoing signal.

The NULL FIELD ATTRIBUTE ELIMINATION routine searches the map in question and overwrites any attribute bytes for null fields with null characters.

A RESET-MDT VOTING routine (Appendix 22) may be called from the IMAGE ALTERATION routine. To be precise, the RESET-MDT VOTING routine does not involve alteration of a buffer map, and therefore may equally well be called from the MAIN (OUTGOING) routine.

Additional background information can appropriately be mentioned here. As described in more detail in the '137 patent, an MDT is typically a specific bit flag within a field attribute byte. This flag is ordinarily set when the associated field is modified; it may also be preset by a host unit application program 25 as part of an outgoing data signal (thus "premodifying" the associated field as premodified). If a field is premodified, the peripheral device 15 will transmit its contents inbound whether or not the user of the peripheral device 15 has actually modified the field.

Some protocols (e.g., the IBM 3270 protocol) provide that an MDT at a peripheral device 15 remains set until cleared. The MDT can typically be cleared either by an MDT reset command or by a buffer-erase command, in either case transmitted outbound by a host unit applications program 20.

Thus, once a field is modified (or premodified), its contents will be transmitted inbound with every subsequent inbound signal--whether or not those contents have been modified in connection with the subsequent signals after the first one--until the MDT is cleared. In effect, such a field, with a left-over MDT that remains, becomes "premodified" with respect to all subsequent signals until the MDT is cleared.

As described in the '137 patent and the '150 application, the optimizer 35 clears the MDT for certain premodified fields. This may require the optimizer 35 to generate a signal to clear any left-over MDTs that remain set.

The MDT-reset command is a quick, cheap, brute-force way to clear all MDTs at the peripheral device 15. Its use may result in a net increase in the size of the outgoing signal, however: in some circumstances, certain MDTs must remain set, and so if an MDT-reset command is used, those MDTs must be set again.

It may be that more MDTs are to be set again after an MDT-reset command than would need to be cleared if an MDT-reset command were not used. In such a situation, the size of the outgoing signal is likely to be shorter if an MDT-reset command is not used.

The RESET-MDT VOTING routine (Appendix 22, 24) permits selective use of the MDT reset command. The routine examines all field attribute bytes in the present-state and intended-state maps of the screen buffer 16. It counts the state changes, if any, between the present state and the intended state, of the MDTs in the various field attribute bytes.

If fewer MDTs go from set to cleared than from cleared (or set) to set, then a shorter data stream will result from not using an MDT-reset command, and instead individually clearing the desired MDTs. Conversely, if more MDTs must be cleared than set, it more economical to use an MDT-reset command, and then to individually set again any MDTs that need it.

When image alteration is complete, the optimizer 35 performs a SIGNAL GENERATION (OUTGOING-SCREEN) routine (Appendix 23). This routine makes two successive calls to a TEST SIGNAL routine, which generates two test signals for potential transmission to the peripheral device 15; the shorter of the two signals is ultimately transmitted.

The first call to the TEST SIGNAL routine is preceded by the writing of an erase-buffer command to the first test signal. This means that the first test signal must completely rewrite the screen buffer 16 with the contents of the intended-state map.

The second call to the TEST SIGNAL routine is not preceded by writing an erase buffer command. In the second test signal, therefore, every character sequence in the screen buffer 16 that is to be changed must be individually modified with a set-buffer-address and a write command.

Before making these calls to the TEST SIGNAL routine, the SIGNAL GENERATION (OUTGOING-SCREEN) routine performs an MDT-RESET VOTE COUNT routine (Appendix 24) to determine whether or not to use an MDT-reset command.

The TEST SIGNAL routine (Appendix 25) may call a NULL/NON-NULL STRING DELIMITATION routine (Appendix 26) to scan the intended-state map (if an erase-buffer command is used) or the difference map in search of triplets of character sequences S1, S2, and S3. As shown in FIG. 7, each such triplet consists of two sequences S1 and S3 of non-null characters separated by a sequence S2 of null characters.

The TEST SIGNAL routine then may call a TRIAL GENERATION routine (Appendix 27) to generate two trial signals for each triplet so located. In the first trial signal, the TRIAL GENERATION routine treats the triplet as a single character sequence: it calls an OUTPUT STRING GENERATION routine (Appendix 28) to write a single set-buffer-address command for the triplet, then copy all characters (both non-null and null) from the map being scanned to the trial signal As explained in the '137 patent, all characters in the map that represent a field attribute or other code sequence are reconverted back to the proper code sequence in the process.

In the second trial signal, the TRIAL GENERATION routine deals with non-null sequences S1 and S3 in the same manner, but separately, with each of S1 and S3 being the subject of a call to OUTPUT STRING GENERATION. Whichever of the two trial signals is shorter is used as the signal for that triplet.

The OUTPUT STRING GENERATION routine may be designed to test each sequence for multiple consecutive occurrences of the same character, and in such event to utilize a repeat-to-address command in lieu of the multiple occurrences. Such a test and repeat-to-address command are conventional and are not described here.

The OUTPUT STRING GENERATION routine utilizes a device display mask to take advantage of information known about the display characteristics of the peripheral device 15.

Many peripheral devices can process extended-attribute commands that designate, e.g., different colors for the screen buffer 16. Not all such devices can display all extended attributes, however. For example, a particular device may be able to accept an extended-attribute command designating the color orange for display, but may only be able actually to create a black-and-white display.

The OUTPUT STRING GENERATION routine tests for this possibility. In doing so, it looks up a device-display mask created by the SIGNAL GENERATION (INCOMING) routine. Upon receipt of an incoming signal containing a response to a query command (see QUERY SUPPRESSION routine), the SIGNAL GENERATION (INCOMING) routine builds a device-display bit mask to indicate the extended attributes, if any, that can be displayed by the particular peripheral device 15.

In writing an output string from a character sequence, the OUTPUT STRING GENERATION routine determines whether a particular character represents a command character sequence. If so, and if the sequence is an extended-attribute command, it performs an AND result represents those extended attributes specified by the operation between the command and the device-display mask. The result represents those extended attributes specified by the output signal that are actually displayable at the peripheral device 15.

When optimization of screen-buffer and symbol-buffer signal components is complete, the optimizer 35 generates a substitute signal from the components created by the optimization process. A convenient way to generate a substitute signal is to scan the original signal (generated by the host unit application program 25) and, for each component part of the original signal, substitute the new component part(s) generated by the optimizer 35.

The substitute signal itself may be further optimized to take advantage of buffer wraparound features.

In some systems, a wraparound occurs if characters are written to the screen buffer 16 beginning near the end of the buffer, and continuing past the end: instead of being lost, the characters written past the end of the buffer are wrapped around to the beginning of the buffer. This can be advantageous in writing to the beginning of the buffer.

Ordinarily, such writing is accomplished by including a set-buffer-address command in the outgoing (or substitute) signal, designating the beginning of the buffer as the location to commence writing characters.

Consider, however, the situation where, after receipt by the peripheral device 15 of the substitute signal, both the beginning and the end of the screen buffer 16 each contain an arbitrary sequence of characters to be written. Ordinarily, two set-buffer-address commands will be generated, one to write to the beginning of the buffer, one to write to the end.

The optimizer 35 takes advantage of buffer wraparound capability by testing whether the above situation exists. If so, the substitute signal is altered so that the first set-buffer-address command in the signal is removed, and the characters to be written to the beginning of the buffer are moved within the signal to follow the characters to be written to the end of the buffer.

The beginning characters will thus be written to the "end" of the buffer, but will wrap around to the beginning. The size of the substitute signal is consequently reduced by the size of the set-buffer-address designating the beginning of the buffer.

This approach can be particularly advantageous when both the end and the beginning of the screen buffer 16 contain runs of identical characters, perhaps with neither separate run being big enough to justify compression using a repeat-to-address command. By utilizing the wraparound feature, a repeat-to-address command may be usable where it was not before.

After completion of the foregoing signal processing, the substitute signal generated by the optimizer 35 is delivered to the signal routing unit 30 for routing to the peripheral device 15.

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 in which the hardware and software work in substantially the same way to achieve essentially the same result. Some of these situations have been expressly described here (as examples and not as limitations), and others will be recognized by those of skill. 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.

It is also to be understood that various modifications and changes may be made, e.g., in the shape, size, and arrangement of components, operating steps, and so forth, without departing from the spirit and scope of the invention as set forth below in the claims.

For example, on some computer systems it may be preferable from a cost-effectiveness standpoint to adapt preexisting macros or modules to accomplish the functions described here, albeit perhaps in a different order than described.

Or, in some circumstances it may be desired to implement the system in conjunction with an existing computer program system of another type, with the possible result that the functions described here may be merged with other functions.

The system described here is organized in various routines; on some computer systems, it may be preferable to implement the system's functions through the use of, e.g., macros to avoid the overhead associated with a subroutine call.

It is intended that the following claims be interpreted to embrace all such modifications and changes.