DCPS and line per page

[Denis Michaud]

With DCPS, I try to print report produced by cobol (report writer).

The number of line printed does not respect the program. That is the title of then second page in printed at end of the first.

All pages are shifted


Denis Michaud

[Hoff]

There are a few variables here.

DCPS version.

The particular printer and potentially even its firmware.

The (likely) ASCII to Postscript conversion.

This could easily be a COBOL-level error, an ill-formatted ASCII construction in the file, or a conversion error, or a printer set-up issue.

Start by posting the OpenVMS version and patches, the DCPS version, the vendor and model identity of the printer, the DCL command(s) or details of whatever is submitting the job to the printer, the printer queue characteristics and configuration details, and (if it can be sufficiently sanitized) attach a zipped (via \zip "-V"\) copy of whatever document you're trying to print to a reply here.

If you're using any custom printer set-up modules, you'll want to identify those, too.

[Denis Michaud]

The version of VMS : VMS831H1I
Last Update : V7.0
Cobol : V2.9
DCPS : V2.7

Attached : document to print (backup saveset)

[Denis Michaud]

The VMS command that I used:

$ print /param=(data_type=ansi,PAGE_SIZE=a4,side=2,number_up=2,page_orientation=landscape)-
/que=impexp07_dcps xx.xx

[Denis Michaud]

I Assigned the queue to "HPGENERIC"

Denis M

[Hoff]

Which printer vendor and printer model?

SHOW QUEUE/FULL for the queue?

If the printer supports ASCII, try going directly via telnet or the lpr/lpb paths.

And FWIW, I'd asked for zip "-V" because I know that format gets through the quagmire of intervening systems, where the usual results of a BACKUP saveset transfer tends to a file corruption somewhere between slightly and seriously. You've now asked me for more work to get to your reproducer, in other words.

[Denis Michaud]

Printer queue IMPEXP07_DCPS, idle, on SSQ11::"IP_LPD/10.3.95.1:VMS_Usager", mounted form DCPS$DEFAULT (stock=DEFAULT)
/BASE_PRIORITY=4 /DEFAULT=(FORM=DCPS$DEFAULT (stock=DEFAULT)) /NOENABLE_GENERIC /LIBRARY=DCPS_LIB Lowercase /OWNER=[SYSTEM]
/PROCESSOR=DCPS$SMB /PROTECTION=(S:M,O:D,G:R,W:S) /SCHEDULE=(NOSIZE)

Here we use a printer server that can print report on any printer but often it's an HP 4345 MFP

[Hoff]

What is this "printer server" device here? Is there some additional device between the OpenVMS box and the LaserJet 4345mfp series printer? Maybe some sort of a host or controller that's processing and forwarding print jobs?

What happens if you start removing some pieces from this configuration, and (for instance) send the print job directly to the LaserJet MFP 4345 via, say, LPR/LPD queue?

[Denis Michaud]

I test DCPS 2.7 on a test environment and I cannot acces directly the printer.

However, I did a test on environment with the printer in the network and DCPS 2.6 on ALPHA. It's the same problem.

Printer queue IMPEXP07_DCPS, idle, on SSQ7::"IP_RawTCP/10.17.0.52:9100"

Denis

[Hoff]

Get DCPS completely out of the way. You're not really using that for anything other than converting ASCII to Postscript.

Set up a print queue via TCP/IP Services directly into the LaserJet 4345mfp (via LPR, most likely), send the ASCII text file directly, and see if that works. This LaserJet reportedly supports US ASCII directly, so...

Better yet, if you have the option, call up HP support and have them sort this all out; this looks to involve HP gear end-to-end, and it's not working, so....

[Paul Anderson_7]

Using a non-DCPS queue wouldn't produce the NUMBER_UP or LANDSCAPE characteristics of the output, but it would be interesting to see if an LPD or Telnet queue produces the same "shifting".

[tsgdavid]

Could this be an issue with the VFC (Variable with fixed length control) record format? I am thinking that is what COBOL uses. It is the same as what is used for BATCH .LOG files. Do you have similar issues when printing BATCH .LOG files?

Possibly providing a DIR/FULL output for the file in question and partial DUMP of the file would shed some light.

VFC encodes a count of the number of blank lines rather than the blank lines themselves. I have seen a situation where COBOL reports would not print correctly. The encoded character printed as a space and the number of blank lines did not match the original document.

My solution was to create a "dummy" queue and create a process to convert the file format before printing to the actual print queue.

The issue I had was due to the fact that the file was using a TCPIP print que to a server that did not understand the VFC record format.

Dave Williams

[Hoff]

Could well be VFC, yes. Could be most anything. Which is why I'm looking to start slicing hunks of code and tools off of the problem space. Divide and conquer debugging, et al.

[Denis Michaud]

I print with DATA_TYPE=ANSI and transmit the ANSI code 62t by the setup module of the form.

Thanks