assoc.formqs.devices Article/Article


Command assoc.formqs.devices Article/Article
Applicable release versions: AP
Category Article (24)
Description Associating Spooler Form Queues and Device Types.

by Mark Brown
(Original Article ran in PickWorld Magazine)

A question came up the other day, someone wanted to know why he got perfect print when he attached a terminal to his printer port, but got garbage when he hooked up his HPii laser printer. The answer is both simple and complex.

The simple answer is that the terminal producing the output and the terminal imitating a printer were the same make and model. The HPii was different, and so none of the control strings which turn on bold font and underscore were recognizable. The complex answer explains why this is so.

There is a piece of the system called SYSTEM.CURSOR which controls all of the terminal and printer control functions. It calculates what @(-1) means and where @(10,12) is on a terminal, and defines what underscore and bold font mean to the printer. Whenever a user executes a TERM command, a binary item from a file is placed into a special work space called the Cursor Control Block (CCB). Then, whenever a program, PROC or other terminal manipulating software needs cursor control, the CCB item is scanned and the proper control string is generated.

There is another work space called the Printer Cursor Control Block (PCCB). This space is assigned when the user executes an ASSIGNFQ command (this associates a form queue with a device control item) and an SP-ASSIGN (to assign the user to the proper form queue and make the connection between user and device). ASSIFNFQ alone will not do. You must do the SP-ASSIGN afterwards to establish the PCCB.

The TERM and ASSIGNFQ/SP-ASSIGN command structures perform the exact same functions, on the CCB and PCCB respectively. When a process executes any cursor control (for example, print @(-1)), SYSTEM.CURSOR is evoked. It checks to see of a PCCB has been assigned and if we are printing to a spooler entry. If so, we setup to the PCCB; otherwise we setup to the CCB. Always one or the other. Then we fetch the control string. We obtained good results with the terminal attached to the computer because the terminal which produced the output and the terminal he attached were identical and so they both understood the rules. The HPii did not. This is why one user who called Technical Support complained about this problem: when he converted from a PC to an RS/6000, his printers stopped recognizing form feeds. Actually, he had installed a number of new IBM 3151 terminals, which use an ESCape "L" (x'1b',x'4C'), to clear the screen. And he was printing @(-1). His old system used Viewpoint terminals, which generate a formfeed (x'0C') to clear the screen.

So, if you are having problems getting your printer to recognize certain graphics commands, the first thing to try is to:

ASSIGNFQ formqueue,devicename (C
SP-ASSIGN Fformqueue

This will setup a PCCB item and force your process to reconize it. The C option forces the ASSIGNFQ process to compile the PCCB item from the device definition file. Pick Systems distributes the DEVICES, but we do not have one of every kind of printer or terminal defined in the file. And until someone uses it, the binary item (which gets converted into the CCB or PCCB) is not created. You should need to compile them only once.