Xerox Phaser 6500N and DCPS issues.

[Jan-Erik Soderholm]

Hi.

For many years we have been using DCPS and Xerox Phaser
printers without any issues. Two models are the small
3250 and the larger 6280N. This has worked well using
the IP_LPD option in DCPS. Something like 15-20
printers today.

A few days ago a Xerox Phaser 6500N was installed and
we set it up as we use to do with a Xerox Phaser in DCPS.

Nothing prints but there is a log in the logging part of
the printer itself just saying "error" with no expanation
on what the error might be. On VMS the print job finish
successfully both on the queue itself and in accounting.

Now, we are trying different changes and ideas, but I'd
thought I'd ask if someone else is running DCPS with this
line of Xerox printers and in particular the 6500N. And
if so, if there was any special handling of this one.

I remember whan we started with DCPS we sometimes had
trouble getting the printer to switch to PS emulation
and instead printed the PS source code in PCL mode.
I think we solved that my setting PS as the default
(idle) mode in the printer. Or maybe by some extra
setup module in the queue definitions...
Anyway, here nothing at all is printed.

Regards,
Jan-Erik.

[Paul Anderson]

In article <mdapsc$cgd$1...@news.albasani.net>, Jan-Erik Soderholm

<jan-erik....@telia.com> wrote:

> A few days ago a Xerox Phaser 6500N was installed and
> we set it up as we use to do with a Xerox Phaser in DCPS.
>
> Nothing prints but there is a log in the logging part of
> the printer itself just saying "error" with no expanation
> on what the error might be.

Do you use LPD spooling in DCPS? I don't recall that the Phasers
required it, but that many of the larger Xerox printers needed the byte
count for the whole job sent at the beginning of the job. This is
something that defining spooling (system-wide or by queue) does. Check
the DCPS documentation about defining the DCPS$SPOOL logical name.

Does this printer work with jobs from other environments? Does it have
PostScript? Is that the default? Unfortunately, LPD can fail silently
if there is a problem, which makes it harder to troubleshoot.

Paul

[Jan-Erik Soderholm]

Yes, DCPS$SPOOL is globaly setup.

How is it, are there a way to keep the DCPS spool file?
The files on the queue are deleted and they are also
non-directory scratch files, so that are a bit hard
to look at.

The DCPS spool file is after DCPS processing, right?

I have just asked about other environments, but that is
how some of the other printers are used. Thay also have
print queues on some Windows servers. Now, this one was
a totalt new install and I think the first 6500N (I'll
ask about that also...).

Some of the smaller table-top Xerox'es are only used
by DCPS.

Yes, is has the normal suite of emulatorns, PS, PCL5,
PCL6 and so on. I did not find any setting for "default
emulator" on this model. Maybe it is avaiable on the
front panel of the printer. I'll check.

We are looking for a new modell of the 3250 (3260)
for a test with another newer table-top modell...

Many thansk for your input!

Jan-Erik.

[Jan-Erik Soderholm]

Paul Anderson skrev den 2015-03-06 02:54:

Got a verification that the new 6500N printer works OK from
other sources, both Citrix based thin-clients and older
WinXP based clients (they might both share the same printer
server though...)

Do not know if they uses PCL or PS, depends on the Windows
driver I guess...

/Jan-Erik.

[abrsvc]

The fact that this printer works form other sources means nothing here. Those sources have their own drivers that are likely for this specific family of printer. OpenVMS doesn't work that way.

I had a similar problem with another printer setup in the past, and the "fix" was to change the default on the printer. IIRC, the default was PCL6 and the environment in my case required PCL5. In theory those should be compatible. In other words the PCL6 environment should accept PCL5 with no problems. However, in our case, we too had no printing until we changed the default.

Try changing the default settings on the printer itself. The other drivers usually send a "setup" sequence to the printer which will modify the default settings for that print job anyway, so changing the default should not cause any problems.

Dan

[Jan-Erik Soderholm]

abrsvc skrev den 2015-03-06 13:15:
> The fact that this printer works form other sources means nothing here.
> Those sources have their own drivers that are likely for this specific
> family of printer. OpenVMS doesn't work that way.
>

Of course. An interesting point to verify, anyway.
That the printer works at all...

> I had a similar problem with another printer setup in the past, and the
> "fix" was to change the default on the printer. IIRC, the default was
> PCL6 and the environment in my case required PCL5. In theory those
> should be compatible. In other words the PCL6 environment should accept
> PCL5 with no problems. However, in our case, we too had no printing
> until we changed the default.
>
> Try changing the default settings on the printer itself. The other
> drivers usually send a "setup" sequence to the printer which will modify
> the default settings for that print job anyway, so changing the default
> should not cause any problems.
>

Yes, that is one of the points I want to test. It could not be
changed from the web interface, as far as I could se. I'll ask
the guy on-site to check

Now, when we have had this problems before (the printer prints
in PCL mode instead of switching to PS), we got loads of Potscript
printouts (the source code it self). Now we get nothing.

Jan-Erik.


> Dan
>

[Paul Anderson]

In article <mdbsnq$c9a$1...@news.albasani.net>, Jan-Erik Soderholm

<jan-erik....@telia.com> wrote:

> How is it, are there a way to keep the DCPS spool file?

Define DCPS$SPOOL_KEEP.

> The DCPS spool file is after DCPS processing, right?

Yes. It's the complete DCPS job, so should be able to be re-queued.

If you fiddle with printer settings and it still doesn't work, you
could collect a DCPS trace file by defining the logical name
DCPS$TRACE, restarting the queue, printing the job, then stopping the
queue and deleting the logical name.

Paul

[Jan-Erik Soderholm]

Thanks! We'll try those.
I just now also saw the DCPS$TEST option...

Jan-Erik.

[Jan-Erik Soderholm]

Jan-Erik Soderholm skrev den 2015-03-06 13:38:

I think I wrote earlier that the printer didn't print
anything at all. Now, with another guy on-site, it seems
as that was wrong. The operator had simply tossed the
error-printout and said that "nothing was printed"... :-)

Here is a copy of what actualy *is* printed:
http://jescab2.dyndns.org/pub_docs/wp_20150310_10_26_18_pro.jpg

Picked up from the dustbin from last week... :-)

The queue looks like this (name and address protected):

$ sh que <queue_name>/fu
Printer queue <queue_name>, idle, on HV06::"IP_LPD/<IP-address>",
mounted form DEF_CHAR_SW (stock=DEFAULT)
/BASE_PRIORITY=4 /DEFAULT=(FEED,FORM=DEF_CHAR_SW (stock=DEFAULT))
/NOENABLE_GENERIC /LIBRARY=DCPS_LIB Lowercase /OWNER=[SYSTEM]
/PROCESSOR=DCPS$SMB /PROTECTION=(S:M,O:D,G:R,W:S) /SCHEDULE=(NOSIZE)
$

The test print was a simplt textfile:

$ type a.txt
Testfil... Testfil...
Testfil... Testfil...
Testfil... Testfil...
Testfil... Testfil...
Testfil... Testfil...
Testfil... Testfil...
Testfil... Testfil...
$

and it was printed using:

$ print/que=<queue_name> a.txt

This works OK using another queue with exactly the same setup,
apart from the IP-address, of course. But in that case there is
a Xerox 3250 instead of the new Xerox 6500.

To me it looks as some minor incompatibility between DCPS
and the new PS emulator in the Xerox 6500.

The 3250 says:
"PostScript Version PS3 1.94.06 12-22-2008"

The 6500 says:
"PostScript (PS) Interpreter Level 3 201103101130"

The "quick-fix" right now is to setup a 3250 besides of
the 6500 and use that for VMS printouts. But of course
they'd prefer to use the faster 6500 for all printouts...


Jan-Erik.

[Carl Friedberg]

Jan-Erik,

I am following this closely. I too have a couple of 6500's. They use a huge
amount of expensive toner, but have been good quality and reliable. I have
not been successful with DCPS either.

> _______________________________________________
> Info-vax mailing list
> Info...@rbnsn.com
> http://rbnsn.com/mailman/listinfo/info-vax_rbnsn.com
>

[Jan-Erik Soderholm]

Carl Friedberg skrev den 2015-03-10 12:24:
> Jan-Erik,
>
> I am following this closely. I too have a couple of 6500's. They use a huge
> amount of expensive toner, but have been good quality and reliable. I have
> not been successful with DCPS either.

OK, well nice (in a way) to hear... :-)
Do you get similar error printouts?
Any other symptoms?

Jan-Erik.

[Paul Anderson]

In article <mdmhoi$f1k$1...@news.albasani.net>, Jan-Erik Soderholm

<jan-erik....@telia.com> wrote:

> Jan-Erik Soderholm skrev den 2015-03-06 13:38:
>
> I think I wrote earlier that the printer didn't print
> anything at all. Now, with another guy on-site, it seems
> as that was wrong. The operator had simply tossed the
> error-printout and said that "nothing was printed"... :-)
>
> Here is a copy of what actualy *is* printed:
> http://jescab2.dyndns.org/pub_docs/wp_20150310_10_26_18_pro.jpg

So the 6500 chokes on the PostScript 'duplexmode' command. Seems to me
some other printers have done this in the past. Have to check on that.
I also wonder what '/e@#q!3&' is doing on the stack.

Do you have the DCPS$queue_PRODUCT_NAME logical name defined?

Paul

[Carl Friedberg]

Hi Paul,

I still have not tested. Here is a sample of what I have so far. For the
second printer I removed all of the comments to debug a DCL error message
(too many arguments).

$ write sys$output "Starting Xerox Phaser 6500 LaserPSX on Queue PSX"
$ DEFINE /EXECUTIVE_MODE /SYSTEM DCPS$PSX_PRODUCT_NAME "HPGENERIC"
$ IF .NOT. SETUP_MODE THEN @SYS$STARTUP:DCPS$EXECUTION_QUEUE -
psx - ! P1 - Execution queue name
"IP_RAWTCP/laserpsx.example.com:9100" - ! P2 - printserver node name
DCPS_LIB - ! P3 - Logical name for library(ies)
"" - ! P4 - Default queue parameters

"/default=(form=dcps$default,feed)/separate=(NOFLAG,NOBURST,NOTRAILER)" -
"" - ! P6 - Communication speed
"" - ! P7 - Device characteristics
"" ! P8 - Verify on/off
$!
$!
$ write sys$output "Starting Xerox Phaser 6500 LaserPSY on Queue PSY"
$ DEFINE /EXECUTIVE_MODE /SYSTEM DCPS$PSY_PRODUCT_NAME "HPGENERIC"
$ IF .NOT. SETUP_MODE
$ THEN
$ @SYS$STARTUP:DCPS$EXECUTION_QUEUE psy -"IP_RAWTCP/
laserpsy.example.com:9100" DCPS_LIB "" -

"/default=(form=dcps$default,feed)/separate=(NOFLAG,NOBURST,NOTRAILER)" ""
"" ""
$ endif

Do you have any suggestions (the TCPIP pirnters run on Multinet).

What is the best way to handle a multi-architecture (AXP/I64) cluster. Is
this done by DCPS (processor qualifier?) The DCPS$STARTUP procedure doesn't
bother queues that are already running, so it seems to do OK, but I worry
about situations like this where there are different executable images
involved on the different architectures.

Later today I will report on how it is running based on i64 architecture.
On AXP I saw the same errors as Jan-Eric reported, if I remember correctly.

Thanks,

Carl

[Jan-Erik Soderholm]

No, no DCPS$queue_PRODUCT_NAME logicals are defined, for any
queue or for any printer type.

Jan-Erik.

[Carl Friedberg]

Hi Paul and Jan-Erik,

%DCPS-W-UNDEF, undefined: Name not known - offending command is duplexmode

Copying by hand from the printed page:

ERROR: undefined
OFFENDING COMMAND: duplexmode

STACK
/Duplex
-dictionary-
/e@#q!3&
0
/duplexmode
false
/lps$physical -duplex?

[abrsvc]

One thing I did notice and I don't know if this is relevant or not...

The 3250 has double sided printing capability where the 6500N does not. I wonder whether or not the printer can handle the DUPLEX directive at all. If not, that is a fault in the printer's processing of the Postscript. I would love to see if the 6500DN can handle the DUPLEX directive. The 6500DN can print double sided.

Since the 6500N can only print single sided, the DUPLEX directive should be ignored. I would question Xerox about this. Perhaps the drivers for the 6500N strip out this directive?

Dan

[Jan-Erik Soderholm]

Well, it's an option on the 6500N but was not mounted on
this specific printer. The on-site support guy said he
would look for a duplex unit to mount, but he never
come back for that test. I'll ask him about that.

Now, DCPS doesn't know what printer is out there.
All printing is done with generic PS. And, I think the
6500N is newer than the DCPS kit anyway, so it can't
know about it.

B.t.w, I didn't know that the 3250 had duplex printing as
standard, I thought it was a normal cheap modell... :-)


Jan-Erik.

[abrsvc]

DCPS is not the problem. I think that the postscript processor within the printer is the problem. The printer receives the data stream and interprets it to print. I'm suggesting that the 6500N should be ignoring the DUPLEX completely since it is not supported on that printer. Instead, it is stating that it is not a valid directive. With DUPLEX=OFF, the printer should be printing in "normal" mode. With DUPLEX=ON, the printer should throw an error as that option isnot supported. In this case, the DUPLEX itself is throwing an error. This is wrong (in my opinion) and is an error within the printer.

Dan

[Paul Anderson]

In article <4dd1e0b8-78f1-42ce...@googlegroups.com>,

abrsvc <dansabr...@yahoo.com> wrote:

> In this case, the DUPLEX itself is throwing an error. This is wrong
> (in my opinion) and is an error within the printer.

This is my opinion also. But DCPS must deal with something called
"reality" and ignore how things "should" work sometimes.

In my experience, the PostScript used in Xerox printers is interesting
in this way. Whether it is in strict compliance with Adobe standards,
I can't say, because sometimes the standard is not so strict or can be
interpreted in different ways.

There are some device control modules that deal with this. I forget
the knob that controls this, but this issue with duplex or duplexmode
has come up before, so I believe it can be solved.

I am at home now, not at work, so I can check tomorrow.

Paul

[Jan-Erik Soderholm]

Hi.

I do not want to rush you, but just saying that we are still
interested in if you found the right "knob" to turn... :-)

Jan-Erik.

[Jan-Erik Soderholm]

Just FYI...

After a couple of mails with Paul, a solution suggested by him
solved the issues.

Defining the logical DCPS$queuename_PRODUCT_NAME to the name of
a similar (but known by DCPS) printer, "Phaser 6250N" in our
case, the error went away.

Thanks Paul and VSI!

Regards, Jan-Erik.