Printing using DCPS

[Russ Carraro]

Customer has some Vax and Alpha systems (V6.2 and V7.1) that print to queues using the RawTCP option in DCPS V2.3. They are printing files which have a form feed () in position 1 of the first record and that's all that's in the first line. When printing to an HP8000 or Declaser3250 the FF is ignored; i.e. data from the file starts printing on line 1 of the first page of the output. If they print to a XEROX Docucenter, then they get a leading blank page, as I would expect due to the FF. If a character, such as a blank, preceeds the FF then the blank pages will be generated on all printers.

Any one know why DCPS is not creating the blank page?

If it helps, the following lines are from a diagnostic log file (DCPS$JOB_xxx_DIAG.log) from a job when the blank page is created by placing a blank character before the FF. These lines preceed the lie "%!PS-Adobe":


%%[ status: idle ]%%


%%[ status: idle ]%%

[Karl Rohwedder]

I think, DCPS tries to avoid empty pages without output by checking, if the printer is at top of page. This seems to fail with the XEROX.

regards Kalle

[Ian Miller.]

You may need a later version of DCPS to properly handle the Xerox Docucenter. I think V2.5 is current.

[Karl Rohwedder]

According to the SPD the following XEROX printers are supported on V2.5:

DocuPrint N24
DocuPrint N32
DocuPrint N40
DocuPrint N2025
DocuPrint N2125
DocuPrint N2825
DocuPrint N3225
DocuPrint N4025
DocuPrint N4525
Phaser 4500
Phaser 6250
Phaser 7300
Phaser 7750
Phaser 8400

Regards Kalle

[Dave Gudewicz]

I agree with Ian. I'd install the latest version of DCPS, which is v2.5. And you might want to add your name to the field test site list when the time comes. Perhaps Paul Anderson can let this forum know when v2.6 will be ready for field testing.

Dave...

[Paul Anderson_7]

DCPS does appear to ignore a form feed character when it appears at the beginning of the file. I've not looked at the code to offer any other explanation. I suspect it does so to correctly handle files intended for simplex text printers that would issue a form feed to make sure the previous job was completely printed before starting the new one.

Such form feeds are unnecessary with DCPS and with modern printers and/or symbionts.

The ^T and ^D commands as well as the status reply from the printer, as seen in your "diag" file are irrelevant. If you do a DIFFERENCES on the two log files, you'll see extra PostScript code in the job that has the leading space before the FF. This code produces the extra page.

Other symbionts, such as LPD and Telnet from TCP/IP Services, may process leading FFs differently. There's a logical name in the Telnet symbiont that affects this behavior.

The Xerox DocumentCentre printers are not supported by DCPS and are not planned for support in any future release. There is code in V2.5 that handles some of the issues with these printers, but the printers remain unsupported. There are some new Xerox models being added to V2.6, however, and field test should start later this month.

Paul

[Paul Anderson_7]

DCPS does appear to ignore a form feed character when it appears at the beginning of the file. I've not looked at the code to offer any other explanation. I suspect it does so to correctly handle files intended for simplex text printers that would issue a FF to make sure the previous job was completely printed before starting the new one in case the last job didn't include a trailing FF.

Such FFs are unnecessary with DCPS and with modern printers and/or symbionts.

The ^T and ^D commands as well as the status reply from the printer, as seen in your "diag" file are irrelevant. But if you do a DIFFERENCES on the two log files, you'll see extra PostScript code in the job that has the leading space before the FF. This code produces the extra page.

Other symbionts, such as LPD and Telnet from TCP/IP Services, may process leading FFs differently. There's a logical name in the Telnet symbiont that affects this behavior.

The Xerox DocumentCentre printers are not supported by DCPS and are not planned for support in any future release. There is code in V2.5 that handles some of the issues with these printers, but the printers remain unsupported. There are some new Xerox models being added to V2.6, however, and field test should start later this month.

Paul

[comarow]

Am I gathering that DCPS does some unusal
things when it attempts to print a zero
block length file (yes, we know it should be doing that, but sometimes it happens).
This in turn has led to stalls on
network based remote LPR/LPD printers.

Is that what I'm gathering?

[Russ Carraro]

Thanks to all who replied. The customers Xerox queue uses UCX$LPD_SMB, not DCPS; the HP8000 and DEClaser3250 use DCPS. They have report files (not zero block files) where the first record is a "". The UCX$LPD_SMB queue prints a blank page, the DCPS queue does not. Change the first line to " " and the DCPS queue does print a blank page.

The question is: does DCPS purposely ignore a "FF" when it is the first charater it sees or is this an "undocumented feature"?

[Paul Anderson_7 · Accepted solution]

I've found that DCPS suppresses a form feed if it is the first character in the file. This is true for files of all formats, including, in this case, ANSI.

This change was made in 1989 for CPS V2.1 (CPS was the predecessor to DCPS) so it's been the behavior since then. I didn't find any place in the documentation that mentions this.

Paul

[Russ Carraro]

Paul,

Thanks, that's what I needed to know.

[Russ Carraro]

Paul was able to verify that DCPS does suppress a leading FF.