printing zero block length files

[Rich Hearn]

Hi all,

If this is not the correct forum, please let me know of the appropriate one. I've tried a couple of forum searches, but didn't find anything. This is not printer model specific, tho' HP printers (our most common vendor) seem
to be the most susceptible to the following...

Environment:
Openvms v8.3 alpha, Extended 2-node ES47 cluster, each node has it's own system disk that's MSCP shared, EVA5000 - common data disks

Problem:
Has anyone else ever run into the problem of an application (Caché) every once in a while generating print jobs with 0 Blks (zero) that stall some printers and not others?

Questions:
How does VMS handle printing a zero length file? Is it an actual file filled with "null" characters? Is it just a "name" in the directory? Why does it even try? Is there something "obvious" that I'm failing to recognize here? Is it a question only the app vendor can answer? Has anyone ever tried to print a 0 block file?

thoughts welcome,
Rich
_

[Jim_McKinney]

> Is it an actual file filled with "null" characters?

No.

> Is it just a "name" in the directory?

Yes, just a name in the directory and the disk's INDEXF.SYS. Only this meta-data exists. No data blocks are allocated.

> Why does it even try?

Many symbionts will print header / flag / banner / trailer pages. It is entirely possible to have a these delimit a job with no other output - at least then you will know that the print job was processed.

> Has anyone ever tried to print a 0 block file?

With separating banner pages I've not had problems.

[Rich Hearn]

Jim,

Thanks for the response and the information.

It's interesting in regards to the banner pages - ours are all turned off, so they don't ever get sent - folks don't like the extra paper getting used.

I may just be "out of luck" in that regard
Tnx,
Rich
_

[Jim_McKinney]

> that stall some printers and not others?

Are you using print queues or writing directly to the printers? If a queue, does "SHOW QUEUE/FULL" report "STALLED"? If not, then what? Are the printers addressed via the network? TCP perhaps? If so, you might consider using TCPDUMP to view the conversation between the host and printer - sometimes this is informative? If the printers are older and attached to serial ports on terminal servers you might consider "watching" the port status as jobs are processed. fwiw...

[David B Sneddon · Accepted solution]

Have you tried setting the queues to /BLOCK_LIMIT=(1,"")
This will prevent the zero block jobs being sent
to the printer although they will remain in the queue
and require cleaning up at some point.

Dave

[Jan van den Ende]

Dave,

A fine trick!

I will need to try (sometime, currently seeking a VMS job) if that will also help with the issue I have encountered:
A printjob to print all files fitting a certain wildcard spec.
Sometimes one of them was zero lenght, apparently with the same issue Rich has.

VERY curious if your trick also helps there too. [purely academic now :-( ]

Proost.

Have one on me.

jpe

[Rich Hearn]

Jim,

Thanks for the questions - I am using VMS queues - one for each printer. A "show que/all/full PQxx" will show the queue stalled with the "offending job" at the top of the list. The printers either have built-in Ethernet interfaces (HP/Canon/Xerox) or external print servers (HP[non internal]/OkiData) Printer names have DHCP reservations, so we access them via Multinets (v5.2) TCP/Ip. The problem is too "sporadic" to have TCPDUMP monitoring an address to a logfile, but it's still worth keeping in mind.

What I did as a "work-around" was to create a .com that "monitors" a specific PQ queue once a minute and if a zero length job causes it to stall, the .com does a stop/reset for that queue, kill the job, start the queue, and send an e-mail to the user whose job had the problem.

Dave,
Never "knew/heard of/thought of" doing something like that. What a thought! I'll have to try it next week and see how it goes. Clean up could be done once a day - less overhead than what I'm doing now. Tnx!

Jan,
Were you using Caché from GE/IDX? even if not, I'll post the results of Dave's suggestion to let everyone know.

Thanks everyone, & have a Happy New Year!!!
Rich
_

[Jim_McKinney]

Perhaps at some convenient time you could pause your cleanup job and manipulate a stalled job manually - stop the queue, startup a TCPDUMP, and then restart the job and see what MultiNet is sending and how the printer responds (and then maybe compare this to a successful print if nothing obvious jumps out). It could be that this would be solved by sending a down the pipe - of course that would consume a sheet of paper and likely take a change from the folks at PSC to be able to conditionally do this.

An alternative to setting a block limit for jobs on the queue might be to use the old EXECSYMB freeware to process the jobs prior to delivering them to the MultiNet queue - this would permit you to reject the zero block files and send mail notification to your users.

[Jan van den Ende]

Rich,

>>>
Jan,
Were you using Cachà © from GE/IDX? even if not, I'll post the results of Dave's suggestion to let everyone know.
<<<

No. - never even seen a site were it is used.

But maybe some more info:

The report generator of the application generates zero or (maybe many) more one-page files, same name, in the users SYS$LOGIN. Upon finishing they get printed in one wild-card file spec print/delete command.
But, if the user (or the network connection) for some interrupts the query/generate output phase, a file may have been opened and not yet written to. Application cleanup includes checking for, and printing, any output files.
The user receives his files up to the highest version, so everything seems OK. But the printer is left stalled on a zero-length file.

Anyway, not my concern anymore, nor any way to find out if even the appl is still used...

Proost.

Have one on me.

jpe

[Rich Hearn]

ok, takes long enough for these things to show up, here's an example (see attachment) of what Dave suggested. Seems to work nicely - other than the user has no idea that their job "got lost". Still it does work nicely - Thanks Dave

Jim, it may take a bit trying to implement your suggestion using TCPDUMP, but I like the idea.

Rich
_