Create a printer queue without a Form

[Toine_1]

Hi,

Is it possible to create a printer queue on the OpenVMS platform (I64) without a form?
I also don't want the DEFAULT form.

Or can I create a form that is not adding any linefeed or formfeed when I print documents. The application is handling the linefeeds and formfeeds.

$ Printer queue PBEPQP117, idle, on NVJ::"PBEPRP117:9100", mounted form MEMO
(stock=DEFAULT)
/BASE_PRIORITY=4 /DEFAULT=(FORM=MEMO (stock=DEFAULT)) Lowercase
/OWNER=[SYSTEM] /PROCESSOR=TCPIP$TELNETSYM /PROTECTION=(S:M,O:D,G:R,W:S)
/SCHEDULE=(NOSIZE)

Thanks,

/Toine

[John Gillings]

Toine,

No, a printer queue must have a mounted form. If you don't specify one, you'll get the default.

Fairly obviously, if you don't want the DEFAULT form, you'll have to create one that suits your needs.

You'll need to experiment. Try DEFINE/FORM/NOWRAP/NOTRUNCATE

[Hoff · Accepted solution]

The TCPIP$TELNETSYM critter would be my primary search target here. This particular critter has known behaviors and oddities and particularly when combined with a remote box that also thinks it knows something of page lengths and paginations. A review of various of the knobs and settings available for this critter would certainly be in order here.

http://h71000.www7.hp.com/doc/732final/6526/6526pro_051.html

[Bojan Nemec]

Toine,

Can you replace the command how the jobs are printed?

If so just try with: $ PRINT/PASSALL

Bojan

[Toine_1]

Hi,

I tries the print/passall but it had no effect.

I have set these logicals on the OpenVMS system.

"TCPIP$TELNETSYM_RAW_TCP" = "1"

"TCPIP$TELNETSYM_SUPPRESS_FORMFEEDS" = "35"

The formfeed at the end of the job is gone but I still get two linefeeds at the beginning of each printer job.

The form I use has these margins:
margin=(top=0,bottom=0,left=0,right=0)

Is there any way to tell Telnetsym not to print any linefeeds?
It just should forward all the characters to the printer and the printer will understand the codes.


/Toine

[Jon Pinkley]

Toine,

What is the behavior you are trying to avoid? Are the reports printing double-spaced when you want them to be single-spaced?

What created the reports? For example were these generated on VMS, or were they generated on another system and copied to VMS to be printed?

If you do a directory/full of the reports, what does it show for record format?

What do you mean by "Is there any way to tell Telnetsym not to print any linefeeds?". Taken literally, that implies everything would be on a single line. Do you mean "Is there any way to tell Telnetsym not to ADD any linefeeds?"

If you edit the files, do they show up with or or at the end of each record?

If you type the files on a terminal, does the formatting look correct?

My guess is that there are imbedded CR/LF characters and the symbiont is inserting a newline per record.

The easiest way to fix this is to process the files so they don't have the imbedded formatting characters. That may be as "simple" as changing the record format with set file/attributes before they are printed (this is if these files came from another system).

Specifically one of (RFM:STM, RFM:STMCR, RFM:STMLF).

Some other options if the files came from another system. Possibly change the way the files were transferred. Try ASCII mode FTP, or use some of the "formatting" capabilities of zip/unzip to transform the "end of line" delimiters.

Good luck.

Jon

[Jon Pinkley]

Toine,

Can you share output of

$ show queue /form /full

Is there a setup module?

What type of printer is on the other end?

Is it possible the print server is inserting characters?

If it is a dot matrix printer, is it possibly set to skip over perferations (in other words, it may be inserting line feeds itself).

http://h71000.www7.hp.com/doc/83final/6526/6526pro_055.html

Read 25.5.2 Setting Up Error Logging

specifically the section about using bit 2 of TCPIP$TELNETSYM_DEBUG to log the bytes sent and received over TCP/IP link.

Good luck,

Jon

[Toine_1]

Some more info.

We have a printer Tally Matrix printer. We print Odette labels to this printer from a Fortran Application on OpenVMS.
The printer understands Magnum code.

Until last week we used a serial (LAT) port to this printer. Our application did send a text file to this LAT port and it was printed correctly on this printer. (We didn't use the queue manager for this.)
This worked OK for 10 years.

We have added a serial to IP box to this printer. So now the same printer is connected to the network via IP.
I have created a Telnet queue on OpenVMS and now we submit the same file to the printer queue.

It looks like the telnet queue prints two extra empty lines before it start to print the odette label.

I don't want this two extra lines.

This the form I use:

$ sho queu/form tally/fu
Form name Number Description
--------- ------ -----------
TALLY (stock=DEFAULT) 55 TALLY
/LENGTH=36 /STOCK=DEFAULT /TRUNCATE /WIDTH=512

This is the file I use.

PBEPQP117_TEST.TXT;1 File ID: (139259,520,0)
Size: 5/16 Owner:
[DVEC,RDB$REMOTE51]
Created: 24-JAN-2011 10:39:12.16
Revised: 24-JAN-2011 12:51:07.54 (2)
Expires:
Backup:
Effective:
Recording:
Accessed:
Attributes:
Modified:
Linkcount: 1
File organization: Sequential
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 16, Extend: 0, Global buffer count: 0
No version limit
Record format: Variable length, maximum 0 bytes, longest 45 bytes
Record attributes: Fortran carriage control
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:RE, World:
Access Cntrl List: None
Client attributes: None

Total of 1 file, 5/16 blocks.


/Toine

[RBrown_1]

So you have changed two things. It is always recommended that you only change one thing at a time. (I do not always follow this rule, and usually regret it.)

I would not try using a print queue yet. You were not using a queue before, so why start now? First try having your application, or even an interactive session, talk directly to the device to try to find out who is messing up your data stream.

Where did the LAT device that your application was talking to before come from?

If you created it using LATCP, then the corresponding command ought to be TELNET/CREATE_SESSION.

If your application created the LAT port using QIO, then refer to the documentation for your IP stack. If you are using HP TCPIP Services for VMS, then the _Sockets API and System Services Programming_ manual has a section on "TELNET port driver $QIO interface".

Have fun!

[Jon Pinkley]

Toine,

Have you eliminated the print server (the ip-serial converter) as the source of the extra line feeds?

Try the following (=ctrl-M; =ctrl-J; =ctrl-L)

$ telnet PBEPRP117 9100

and then type in 001012345678002012345678003012345678004012345678005012345678006012345678 (these may or may not echo to you terminal, depending on your print server)

Then type the telnet escape sequence (by default ctrl-]) to get back to the TELNET> prompt, then type EXIT.

Then see if the printed label has three lines at the top of first label (actually should print at "current location")

001012345678
002012345678
003012345678

As long as the Tally printer can handle mechanical form feeds, it should advance to the top of the next "page" then print three more lines

004012345678
005012345678
006012345678

If this does not work, then I would start looking at something other than TCPIP$TELNETSYM as the source of the additional line feeds.

Are you sure that the form length and lines per inch are set consistently on the Tally printer? I don't have any experience with the tally printers, but HP PCL and if I remember correctly, Epson ESC P have interaction between form length and vertical spacing (lines/in).

I am guessing that is probably set correctly if nothing was changed, and the FORTRAN program generates FF (I am assuming that a "1" in position 1 causes a character to be sent when the file is sent to the printer, i.e. RMS would treat it as an implied Form Feed).

However, as Hoff hinted, there are "intelligent" print servers that are not just TCP/IP stream to serial converters, and if they are interpreting characters, they can affect the formatting of the printed characters.

Jon