Vertical Forms Control -- Revisited
by Stuart Baker
Since OS/32 R06-02, the BIOC driver has supported VFC. You may have noticed that writes to the terminal end with a carriage return, instead of a carriage return/line feed combination. The line feed comes from the next write or read operation. This is necessary to support VFC requests such as the plus (+) overprint. The display resulting from intermixed ASCII and IMAGE writes is the same as it used to be. An advance flag achieves correct interaction between ASCII and IMAGE writes. BIOC sets the advance flag for ASCII requests and resets it for IMAGE. The BIOC driver checks the advance flag before performing the next ASCII or IMAGE operation. A line feed is output preceding the operation for a set flag.
Now comes VFC operations. When BIOC receives a VFC request it checks the first character to determine the operation to perform. Note that VFC operations explicitly define the type of carriage control to perform. BIOC sets the advance flag after a VFC "advance before printing" request. BIOC resets the advance flag after a VFC "advance after printing" request. The normal VFC request is a space, which says advance one line before printing. This sounds like an ASCII write with the advance flag set to ON. You can see that ASCII and VFC requests will interact in a logical fashion.
The catch comes when IMAGE requests are intermingled with VFC requests. One might ask who would be dumb enough to intermix VFC and IMAGE 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 a line feed proceeds each task executing prompt. Since each FORTRAN VFC write explicitly requests an advance of one line before printing, the final output will be double spaced. This is definitely not what the programmer intended.
The MTM PREVENT PROMPT command will eliminate the problem. A good place to issue this command would be the USERINIT file that gets executed at every user signon. A second method of avoiding the problem requires an MTM sysgen. To remove the task executing prompt from your system, include the following statement in your MTMPARMS file.
MACRO PRMTSEQ (STANDARD,(*,),(,),(>,),(B>,))
A system generated in this manner will appear to always be running in the mode established by the PREVENT PROMPT command.
While this problem was easily sidestepped, don't let your guard down yet. The undesirable interaction between VFC and IMAGE requests can affect programs in more subtle ways. A typical example would be a FORTRAN program that issues SYSIO calls to do writes to a graphics display. If these writes are intermixed with FORTRAN VFC writes, we are in for trouble. Since FORTRAN attempts to assign logical units with the VFC option, ASCII SYSIO calls produce VFC operations. The result is that the first character will perform unexpected carriage control. The graphics display device malfunctions horribly. The CARCON statement controls when to use VFC in assignments. This should allow you to avoid this pitfall also.
With all of these problems, what good came out of VFC? Well, FORTRAN can now perform the plus (+) overprint formatting operation. With option BIOC enabled, EDIT32 handles horizontal tabs in a manner that is much more user friendly. Files can contain overprinting to allow boldface and underline operations. The spooler VFC option allows you to print these files. Before VFC, it was impossible to take enhanced output from a PC word processor and send to a OS/32 system. Now there exist production programs what will convert PC formatted files into OS/32 VFC files.
If you use TEXT32, the Interchange library contains a program that will increase its flexibility considerably. The FMTTEXT program allows you to convert an output file produced by TEXT32 to a VFC format file. Martin Arrambide developed this program in FORTRAN. The file produced by this operation is usually much shorter than the formatted TEXT32 file. TEXT32 should provide an option to produce VFC output. However, I doubt any of us live long enough to see any enhancements to TEXT32.
A VFC file is an ideal way to distribute documentation. The file can contain overprinting and boldfacing information. This allows you to distribute documentation that will give a very polished appearance when printed. VFC options improved the versatility and flexibility of the system a lot. If you feel like experimenting with VFC, refer to the Systems Level Programmer Reference Manual Appendix B. This Appendix contains a complete list of VFC codes. Try it, you might like it.
This SBSW.COM page has been optimized for printing.