topic Re: printing zero block length files in Operating System - OpenVMS

printing zero block length files

Rich Hearn — Wed, 30 Dec 2009 18:22:31 GMT

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
_

Re: printing zero block length files

Jim_McKinney — Wed, 30 Dec 2009 19:17:29 GMT

> 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.

Re: printing zero block length files

Rich Hearn — Wed, 30 Dec 2009 20:19:22 GMT

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
_

Re: printing zero block length files

Jim_McKinney — Wed, 30 Dec 2009 20:32:35 GMT

> 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...

Re: printing zero block length files

David B Sneddon — Thu, 31 Dec 2009 00:57:44 GMT

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

Re: printing zero block length files

Jan van den Ende — Thu, 31 Dec 2009 08:13:16 GMT

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

Re: printing zero block length files

Rich Hearn — Thu, 31 Dec 2009 18:37:37 GMT

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
_

Re: printing zero block length files

Jim_McKinney — Thu, 31 Dec 2009 19:23:29 GMT

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.

Re: printing zero block length files

Jan van den Ende — Fri, 01 Jan 2010 14:46:43 GMT

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

Re: printing zero block length files

Rich Hearn — Wed, 13 Jan 2010 16:07:19 GMT

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
_

Re: printing zero block length files

Wim Van den Wyngaert — Sun, 17 Jan 2010 05:54:12 GMT

Are you sure it's being caused by the zero blocks ? You never have stalled queues with other files ? Do some of the zero files pass ?

How does Cache print the file ? We used DSM and there the applic wrote to "1" which was a logical name pointing to an LTA device that was spooled to a queue. But we didn't have any problems with it.

Wim

Re: printing zero block length files

Rich Hearn — Mon, 18 Jan 2010 14:14:59 GMT

Wim,

Interesting... Back when we ran DSM, (Alpha 8200's, Ovms 7.3-2, DSM) I don't recall us running into this problem. Since CachÃ©, we seem to have. I've not seen us "stall" for other than HW problems with the current systems. I've never known of a zero length file "passing", because if it doesn't stall the queue, I don't hear of it.

CachÃ© (to the best of *my* knowledge) is given a printer name (by the user) which points to an NLP device associated with a common spooled device (IDXSPOOL = Sys$SpoolDevice:[IDXSPOOL]} and it's own queue by the same name as the printer (aee attached for example).

Thanks for the interest and the perspective.
Rich
_