Stuart Baker Software offers high quality consulting services and products to users of IBM PCs and compatibles (DOS and Windows)
    as well as Interdata, Perkin-Elmer and Concurrent Computer Corporation 3200 series machines (OS/32).

Insidious Interaction


The Insidious Interaction of VFC and IMAGE Writes

by Stuart Baker
Stuart Baker Software
9370 Golondrina Drive
La Mesa, CA 91941-5654
(619) 466-8811

While attending Interchange 83, I answered many questions relating to the BIOC CRT driver. Most of these questions were from FORTRAN users and pertained to the interaction between IMAGE writes and VFC writes. Having gone through a detailed explanation on multiple occasions at Interchange 83, I decided that some clarification was needed that could be distributed to the entire user community.

Observant users of OS32 R06.02 may have noticed that normal writes to the terminal now end with just a carriage return, instead of the carriage return/line feed combination. The line feed now comes from the next write or read operation. This change was necessary to create a driver that could support the new VFC I/O requests such as the plus (+) overprint. The display resulting from interactions between ASCII and IMAGE writes will be identical to the way it used to be. The method used to achieve the proper interaction between ASCII and IMAGE I/O is the maintenance of an advance flag that is checked upon initiation of the next I/O request. This advance flag will be set to ON following any ASCII I/O and will be set to OFF following any IMAGE I/O. The next ASCII or IMAGE I/O request checks the state of the advance flag and will precede that operation with a line feed if the advance flag is set to ON.

Now comes VFC I/O ... When a VFC I/O request is received, the driver checks the first character of the request to determine the operation that needs to be performed. Note that VFC operations explicitly define the type of carriage control to be performed, regardless of the state of the advance flag. Also note that the advance flag will be set to ON following a VFC "advance before printing" request and set to OFF following a VFC "advance after printing" request. The normal VFC request for terminal I/O will be a space which says to advance one line before printing (sounds like an ASCII write with the advance flag set to ON, doesn't it?). With a little bit of head-scratching, one can see that ASCII and VFC I/O requests will interact with each other in a logical fashion.

The catch comes when IMAGE I/O requests are intermingled with VFC requests. One might ask who would be dumb enough to intermix VFC and IMAGE I/O requests. The answer is -- MTM would -- behold, the dash (-) task executing prompt is an IMAGE write. Let us now construct a possible scenario: A FORTRAN program does a series of VFC writes with a space (advance one line before printing) as the first character. Each VFC write will leave the advance flag set to ON, therefore each task executing prompt will be preceded by a line feed. Since each new line from the FORTRAN program explicitly requests an advance of one line before printing, the final output will be double spaced. This double-spacing is definitely not what was intended by the programmer, and in this simple example, the problem can be fixed by issuing the MTM command "PREVENT PROMPT". A good place to issue this command would be the "USERINIT" file that gets executed at every user signon.

While this problem was easily sidestepped, the undesirable interaction between VFC and IMAGE I/O can affect existing programs in more subtle ways. A typical example would be a FORTRAN program that issues SYSIO calls to do writes for graphics displays and intermixes them with FORTRAN VFC writes. Since FORTRAN attempts to assign logical units with the VFC option, SYSIO calls that do a normal ASCII write will be treated as VFC requests with the result that the first character will either perform unexpected carriage control or simply be eaten by the driver if it is not a valid VFC character. In either case, the graphics display device will probably be thoroughly confused. The CARCON statement in FORTRAN can be used to control whether a device is assigned with VFC or not. It is likely, with the advent of OS32 R06.02 and VFC, that existing applications will need to be rewritten with an eye toward this interaction in order to accomplish the task that they once performed prior to VFC.

What good came out of all this? Well, FORTRAN can now perform the plus (+) overprint formatting operation. EDIT32 now handles horizontal tabs in a manner that is much more user-friendly when option BIOC has been turned on. Editable files can be made up that contain overprinting to allow boldface and underline operations. These files can be printed through the spooler using the VFC option. Prior to the advent of VFC, it was impossible for me to take enhanced output of my IBM PC word processor and send it over the phone lines to our Perkin-Elmer computer for printing on its letter-quality printers. All in all, the versatility and flexibility of the system have been greatly improved. I hope the sacrifices that have to be made at the user level will not overshadow the flexibility that has been added for future applications.

Return to Index
Article Copyright 1987 Stuart J. Baker

This SBSW.COM page has been optimized for printing.
Web Content Copyright © 1997 - 2010 Stuart Baker Software. All rights reserved.

Please use our Feedback form to submit questions or comments about this web site.
Web Content Copyright © 1997 - 2010 Stuart Baker Software. All rights reserved.
This site was last modified: Wednesday, December 29, 2010