Hi.
I just setup a new queue against a "Xerox WCP 35".
Or "Workcentre Pro 35" as it's also called, at least
I *guess* that it's the same printer !

"Xerox WCP 35" is in the list of supported printers
in the DCPS management manual.

When printing (a text file printed as "ANSI") we get
an Postscript error from the printer. It's a page
with only the following text printed :

 > ERROR: rangecheck
 > OFFENDING COMMAND: setpagedevice
 > STACK: --dict--,

Nothing else on the page and nothing after the ending ",".

The DCPS$xxx_PRODUCT_NAME logical is def as "Xerox WCP 35".
(But it didn't make any change when defined...)

And the DCPS$xxx_PARAMETER is def as "DATA_TYPE=ANSI".
(Didn't change anything either...)

Now, while looking for solutions I thought I'd post
a question here about it also at the same time. In case
someone else has seen this before...



Best Regards
Jan-Erik.

Jan-Erik S�derholm wrote:
> Hi.
> I just setup a new queue against a "Xerox WCP 35".
> Or "Workcentre Pro 35" as it's also called, at least
> I *guess* that it's the same printer !
> 
> "Xerox WCP 35" is in the list of supported printers
> in the DCPS management manual.
> 
> When printing (a text file printed as "ANSI") we get
> an Postscript error from the printer. It's a page
> with only the following text printed :
> 
>  > ERROR: rangecheck
>  > OFFENDING COMMAND: setpagedevice
>  > STACK: --dict--,
> 
> Nothing else on the page and nothing after the ending ",".
> 
> The DCPS$xxx_PRODUCT_NAME logical is def as "Xerox WCP 35".
> (But it didn't make any change when defined...)
> 
> And the DCPS$xxx_PARAMETER is def as "DATA_TYPE=ANSI".
> (Didn't change anything either...)
> 
> Now, while looking for solutions I thought I'd post
> a question here about it also at the same time. In case
> someone else has seen this before...
> 
> 
> 
> Best Regards
> Jan-Erik.

I shold have added that we uses "IP_LPD/nnn.nnn.nnn.nnn" and
DCPS$SPOOL is defined. Other IP_LPD printers works fine on the
same system, including other Xerox printes, both running
Postscript and PCL. This is the first "WCP 35" printer...

Jan-Erik.

In article <iKjNk.3585$U5.23382@newsb.telia.net>,
 Jan-Erik S�derholm <jan-erik.soderholm@telia.com> wrote:

> I just setup a new queue against a "Xerox WCP 35". Or "Workcentre Pro 
> 35" as it's also called, at least I *guess* that it's the same 
> printer !

Yes, the "Xerox WCP 35" (PostScript product name) is the Xerox 
WorkCentre Pro 35 (marketing name), and is supported by DCPS V2.5 and 
later.  What version of DCPS are you running?  (DCPS V2.6 ECO 3 is 
current.)

Your definitions of DCPS$queuename_PRODUCT_NAME and DCPS$SPOOL appear 
correct.  Did you start the queue after defining the PRODUCT_NAME 
logical name?

Do you get any OPCOM messages at the start of the queue or job?  If the 
printer is somehow not recognized by DCPS, you'd get an OPCOM message 
saying so.

Paul

-- 
 Paul Anderson
  OpenVMS Engineering
  Hewlett-Packard Company

Paul Anderson wrote:
> In article <iKjNk.3585$U5.23382@newsb.telia.net>,
>  Jan-Erik S�derholm <jan-erik.soderholm@telia.com> wrote:
> 
>> I just setup a new queue against a "Xerox WCP 35". Or "Workcentre Pro 
>> 35" as it's also called, at least I *guess* that it's the same 
>> printer !
> 
> Yes, the "Xerox WCP 35" (PostScript product name) is the Xerox 
> WorkCentre Pro 35 (marketing name), and is supported by DCPS V2.5 and 
> later.  What version of DCPS are you running?  (DCPS V2.6 ECO 3 is 
> current.)

"DCPS$VERSION" = "V2.6 ECO 3"

> Your definitions of DCPS$queuename_PRODUCT_NAME and DCPS$SPOOL appear 
> correct.  Did you start the queue after defining the PRODUCT_NAME 
> logical name?

I think I did, several times. Or I at least made a stop/que
and re-run the DCPS startup command file to make some changes
to the queue. (And the changes *was* made to the queue...)


> 
> Do you get any OPCOM messages at the start of the queue or job?

Nothing in operator.log, at least.

Everything on VMS looks fine. No retained entry or anything.
It's just the error message on the printer that is printed.
I got a scanned copy of the message and has put it up here:

http://www.jescab.se/upload/ps-message.pdf

Below are the queue setup commands tried. Both are
currently commented out since we had to back out
to the old printer using a printserver and the
standard LPD symbiont...

$!
$! ON ERROR THEN CONTINUE
$! IF .NOT. SETUP_MODE THEN @SYS$STARTUP:DCPS$EXECUTION_QUEUE -
$!   GODSMOT_TL -                    ! P1
$!   "IP_LPD/10.32.141.224" -        ! P2
$!   DCPS_LIB -                      ! P3
$!   "DATA_TYPE=ANSI" -              ! P4
$!   "/DEF=(form=DEF_CHAR_SW) /SEPARATE=(NOBURST,NOFLAG,NOTRAIL)"
$!   "" -                            ! P6
$!   "" -                            ! P7
$!   ""                              ! P8
$!
$!
$! ON ERROR THEN CONTINUE
$! IF .NOT. SETUP_MODE THEN @SYS$STARTUP:DCPS$EXECUTION_QUEUE -
$!   GODSMOT_TL -                    ! P1
$!   "IP_LPD/10.32.141.224" -        ! P2
$!   DCPS_LIB -                      ! P3
$!   "DATA_TYPE=PCL" -               ! P4
$!   "/DEF=(form=SET_ISO11) /SEPARATE=(NOBURST,NOFLAG,NOTRAIL)"
$!   "" -                            ! P6
$!   "" -                            ! P7
$!   ""                              ! P8
$!

I've tried both ANSI and PCL (both are used on others
Xerox printers and works). DEF_CHAR_SW is a module
with an ANSI charset sequence. SET_ISO11 is a module
with a PCL charset command (not realy needed since in
that case it's included in the print-stream from the
application).

Many thanks for your time !
Jan-Erik.


> If the 
> printer is somehow not recognized by DCPS, you'd get an OPCOM message 
> saying so.
> 
> Paul
> 

Jan-Erik S�derholm wrote:

>  > ERROR: rangecheck
>  > OFFENDING COMMAND: setpagedevice
>  > STACK: --dict--,


setpagedevice is one of the commands that accept a dictionary (think of
a dictionary as an array of variables) where each variable is printer
specific (although there are common ones).

So that error would indicate that one of the variables in the dictionary
would have a value invalid for that printer (rangecheck). For instance,
if that printer is only able to have 8*10 paper and you are asking it to
rasterize on 11*17).


The following info came from Paul Anderson some time ago:
--------------------------
 A DCPS "diag" file helps diagnose the communication between the OpenVMS
system and the printer.

To create a DCPS diag file, define this logical name:

    $ DEFINE /EXECUTIVE_MODE /SYSTEM DCPS$TEST 1

and then stop and start the DCPS queue(s).

Print with the following command:

    $ PRINT /NOTIFY /PARAMETERS=(your_parameters,DIAG=FILE=BOTH) file

Diag files contain all data sent between the host and the printer in
files called:

    SYS$LOGIN:DCPS$JOB_entry_DIAG_FROM.LOG
    SYS$LOGIN:DCPS$JOB_entry_DIAG_TO.LOG

Diag files contain all print data information, so be cautious if the
files being printed contain confidential information.

--------------------------------


So print something simple that generates the error message. Then look at
the log files (won't be pretty because the VMS engineers purposefully
stripped comments and formatting of the postscript code to make it ugly
to spite *me* :-) and you may get an idea of the parameters being passed
to setpagedevice and then check against the printer manual to see which
one would cause the rangecheck.


Since the job aborts at the setpagedevice command, this should be
towards the end of the job (but DCPS is likely to send a "reset" group
of commands at the end of the job).

JF Mezei wrote:
> Jan-Erik S�derholm wrote:
> 
>>  > ERROR: rangecheck
>>  > OFFENDING COMMAND: setpagedevice
>>  > STACK: --dict--,
> 
> 
> setpagedevice is one of the commands that accept a dictionary (think of
> a dictionary as an array of variables) where each variable is printer
> specific (although there are common ones).
> 
> So that error would indicate that one of the variables in the dictionary
> would have a value invalid for that printer (rangecheck). For instance,
> if that printer is only able to have 8*10 paper and you are asking it to
> rasterize on 11*17).
> 

All printing over here is in A4.

$ sh log dcps$sheet_size
    "DCPS$SHEET_SIZE" = "A4" (LNM$SYSTEM_TABLE)


> 
> The following info came from Paul Anderson some time ago:
> --------------------------
>  A DCPS "diag" file helps diagnose the communication between the OpenVMS
> system and the printer.
> 
> To create a DCPS diag file, define this logical name:
> 
>     $ DEFINE /EXECUTIVE_MODE /SYSTEM DCPS$TEST 1
> 
> and then stop and start the DCPS queue(s).
> 
> Print with the following command:
> 
>     $ PRINT /NOTIFY /PARAMETERS=(your_parameters,DIAG=FILE=BOTH) file
> 
> Diag files contain all data sent between the host and the printer in
> files called:
> 
>     SYS$LOGIN:DCPS$JOB_entry_DIAG_FROM.LOG
>     SYS$LOGIN:DCPS$JOB_entry_DIAG_TO.LOG
> 
> Diag files contain all print data information, so be cautious if the
> files being printed contain confidential information.
> 
> --------------------------------
> 
> 
> So print something simple that generates the error message. Then look at
> the log files (won't be pretty because the VMS engineers purposefully
> stripped comments and formatting of the postscript code to make it ugly
> to spite *me* :-) and you may get an idea of the parameters being passed
> to setpagedevice and then check against the printer manual to see which
> one would cause the rangecheck.
> 
> 
> Since the job aborts at the setpagedevice command, this should be
> towards the end of the job (but DCPS is likely to send a "reset" group
> of commands at the end of the job).
> 

I didn't know about the DCPS$TEST logical !
(And it's not in the manuals...)

 > and then stop and start the DCPS queue(s).

I guess that it's enough to re-start the offending queue ?
All queues are running it's own DCPS symbiont (so far).

I'll try that romorrow morning on the actual site.

Many thanks for that one !

Jan-Erik.

Here is snippet of one example of the setpagedevice (taken from an
LPS$$HPCLJ9500_INITPSDEVICE)

----
lps$lpsdict
begin/lps$systemdict 1 dict def/lps$current-size{save 3 dict
begin/N/lettertray def currentpagedevice/PageSize get aload pop 2 copy
gt{exch}if/Y exch def/X exch def mark/11x17tray 792 1224/a3tray 842
1191/a4tray 595 842/a5tray 420 595/b5tray 499 709/c5envelopetray 459
649/com10envelopetray 297 684/dlenvelopetray 312 624/doublepostcardtray 420
567/executivetray 522 756/jb4tray 729 1032/jb5tray 516 729/legaltray 612
1008/lettertray 612 792/monarcenvelopetray 279 540 counttomark 3 idiv{Y sub
abs 5 le exch X sub abs 5 le and{/N exch def exit}if pop}repeat cleartomark
N exch end restore}def/3.875x7.5tray/monarcenvelopetray
def/4.125x9.5tray/com10envelopetray def/b4tray/jb4tray def/b5tray/jb5tray
def/c5tray/c5envelopetray def/dltray/dlenvelopetray
def<</Policies<</OutputType 0/Staple 0>>>>setpagedevice
----

lps$lpsdict begin -> starts a named dictionary

/lps$systemdict 1 dict def -> creates a dictionary with space for one
variable and its value.
{ and }  enclose multiple commands to create a single object.

/variable_name  is used to define the variable.

/variable value def  -> a specific value set to a variable

mark (or <<)  /variable value /variable value /variable value >> will
create a dictionary on the stack and define all those variables with
those values.

so in the above example, setpage device is given a dictionary (the
outermost >>) which contains another dictionary inside the innermost >>)



It is a real shame that the VMS engineers ran some program to
purposefully make that code difficult to read.

OK, I installed DCPS 2.6 and ECO3 on my alpha.

The LPS$$XEROXWCP modules don't contain a setpagedevice in the INITPSDEVICE

But it contains them in other modules such as:

LPS$$XEROXWCP_SETINPUTTRAY
LPS$$XEROXWCP_SETOUTPUTTRAY
LPS$$XEROXWCP_SETSTAPLE

The INITPSDEVIDE apperas to be setting up a dictionary, but not using
setpagedevice to set it. Possibly done by the DCPS software itself
outside of the library modules. Your logs of communications should show
how this is being done.

JF Mezei wrote:
> OK, I installed DCPS 2.6 and ECO3 on my alpha.
> 
> The LPS$$XEROXWCP modules don't contain a setpagedevice in the INITPSDEVICE
> 
> But it contains them in other modules such as:
> 
> LPS$$XEROXWCP_SETINPUTTRAY
> LPS$$XEROXWCP_SETOUTPUTTRAY
> LPS$$XEROXWCP_SETSTAPLE

Seems logical since it's an Xerox WCP printer we're using.

> 
> The INITPSDEVIDE apperas to be setting up a dictionary, but not using
> setpagedevice to set it. Possibly done by the DCPS software itself
> outside of the library modules. Your logs of communications should show
> how this is being done.

OK.
I tried to fake using a "Xerox WCP 35" on my HP LJ 2015n
office printer, by setting the product_name logical.

Now I *do* get a DCPS$JOB_994_DIAG_TO.LOG file, but
with no setpagedevice in it. Weird.

When I did the same without the product_name logical, I
get a LOG file with 4 or 5 setpagedevice in it. Weird.

The DIAG_FROM logs are always empty, since IP_LPD is
uni-directional, I guess.

Note that this wasn't on the production system at the client
site, but I would have expected the same output. V2.6 ECO3
in both places.

I'm lost... :-)

Jan-Erik.

On Mon, 27 Oct 2008 13:54:22 GMT, Jan-Erik S?derholm <jan-erik.soderholm@telia.com> wrote:
> Hi.
> I just setup a new queue against a "Xerox WCP 35".
> Or "Workcentre Pro 35" as it's also called, at least
> I *guess* that it's the same printer !

> "Xerox WCP 35" is in the list of supported printers
> in the DCPS management manual.

> When printing (a text file printed as "ANSI") we get
> an Postscript error from the printer. It's a page
> with only the following text printed :

>  > ERROR: rangecheck
>  > OFFENDING COMMAND: setpagedevice
>  > STACK: --dict--,

> Nothing else on the page and nothing after the ending ",".

> The DCPS$xxx_PRODUCT_NAME logical is def as "Xerox WCP 35".
> (But it didn't make any change when defined...)

> And the DCPS$xxx_PARAMETER is def as "DATA_TYPE=ANSI".
> (Didn't change anything either...)

> Now, while looking for solutions I thought I'd post
> a question here about it also at the same time. In case
> someone else has seen this before...

I've read the rest of the thread, and I don't know the
printer itself, so I just have some random thoughts on printers:

1. The printer probably has a web interface that allows you
to tweak settings.  Are there relevant settings in the
Postscript setup, for example, Postscript level accepted?

2. You can probably get more detailed info about the error
from the printer itself.  I found one document on the
Xerox site "Retrieving fault codes from Xerox multifunction
devices".

3. Is the printer set to autodetect whatever stream it receives
(postscript, pcl, xerox printer language, straight ascii, ...)
or is it set to expect only postscript?  If only postscript,
perchaps DCPS is sending non-postscript in this case (since
you're printing PAR=(DATA=ANSI) ).

4. You have other printers that work.  Are there differences
that stand out in the printer setup (comparing the setup
shown on a working printer's web page versus the xerox's
web page)?

5. Does the Xerox printer have the latest software/firmware?
(I have a Toshiba e-studio 35 coper with a plug-in module that
allows use as a printer/scanner/fax, and I needed to get the
latest firmware (an embedded Linux system) to get it to
work with the various systems on our lan.)

-- 
Dale Dellutri <ddelQQQlutr@panQQQix.com> (lose the Q's)

In article <iMqNk.3613$U5.23438@newsb.telia.net>,
 Jan-Erik S�derholm <jan-erik.soderholm@telia.com> wrote:

> I didn't know about the DCPS$TEST logical ! (And it's not in the 
> manuals...)

Shhhh, it's a secret.

> I guess that it's enough to re-start the offending queue ?

Yes.

> All queues are running it's own DCPS symbiont (so far).

Having the logical name DCPS$MAX_STREAMS undefined or set to 1 helps in 
this case, since the DCPS$TEST logical name is interpreted when a new 
symbiont process starts.  If a symbiont process can control more than 
one queue by having DCPS$MAX_STREAMS set to more than 1, you're not 
guaranteed of getting a new symbiont process when you start a queue.

> I'll try that romorrow morning on the actual site.

Since you're running spooled LPD to this printer, you can, instead of 
using DCPS$TEST, define the logical name DCPS$SPOOL_KEEP (or 
DCPS$queuename_SPOOL_KEEP) to be TRUE and then the temporary spool file 
created in DCPS$SPOOL_DIRECTORY will be kept after printing instead of 
being deleted.  This file is the actual data being sent to the printer 
so it could be copied to another type of system and sent from there for 
debugging purposes.

The queue does not have to be stopped or restarted after defining 
DCPS$SPOOL.  And all these logical names should be defined 
/EXECUTIVE_MODE /SYSTEM.

(The files created with the DCPS$TEST logical name contain some 
interpreted control characters; for example a ^T character would be the 
text string "Ctrl/T" in the file.  That's easier to see but not to 
print.)

Shhhh, that logical name is a secret too.

Paul

-- 
 Paul Anderson
  OpenVMS Engineering
  Hewlett-Packard Company

On 2008-10-27 22:57, "JF Mezei" wrote:

> [...]
> 
> mark (or <<)  /variable value /variable value /variable value >> will
> create a dictionary on the stack and define all those variables with
> those values.
> 
> [...]
> 
> It is a real shame that the VMS engineers ran some program to
> purposefully make that code difficult to read.

Not neccessarily -- there _is_ a simpler syntax to create dictionaries
"on the fly", but this _requires_ a compliant "PostScript Level *2*"
interpreter:

|  /NamedDictionary
|  << /Object1 Value1
|     /Object2 Value2
|     ...
|  >> def

Michael

-- 
Real names enhance the probability of getting real answers.
My e-mail account at DECUS Munich is no longer valid.

In article <49063ada$0$12403$c3e8da3@news.astraweb.com>,
 JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

> It is a real shame that the VMS engineers ran some program to 
> purposefully make that code difficult to read.

The PostScript code compression was done so that it could be sent faster 
over slow lines to the printer.  These days I suspect that savings is 
unimportant.

Paul

-- 
 Paul Anderson
  OpenVMS Engineering
  Hewlett-Packard Company

Paul Anderson <paul.anderson@hp.com> writes:
>  JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> 
>> It is a real shame that the VMS engineers ran some program to 
>> purposefully make that code difficult to read.
> 
> The PostScript code compression was done so that it could be sent faster 
> over slow lines to the printer.  These days I suspect that savings is 
> unimportant.
> 
> Paul

I think you should make that DCPS_DIET tool available for general use . . .

-- 

Rob Brooks    MSL -- Nashua			brooks!cuebid.zko.hp.com

In article <cBPox3qsYlmy@cuebid.ovms.usa.hp.com>,
 brooks@cuebid.ovms.usa.hp.nospam (Rob Brooks) wrote:

> I think you should make that DCPS_DIET tool available for general use . . .

I just yelled at Rob for making this suggestion.  But he's sometimes 
right about things, so I wonder if there's interest in having DCPS ship 
a "reference copy" of the DCPS library in an uncompressed, more readable 
form.  I think we'd keep the existing library compressed in case someone 
needs some extra speed on their serially-attached LN03.

The tool, by the way, is called PSCom and it was written by Ned 
Batchelder over twenty years ago.  It does lots more stuff, like allow 
for conditional execution of code, via IF/ENDIF and INCLUDE statements, 
stripping of comments and (as noted) compression of PostScript code.

Paul

-- 
 Paul Anderson
  OpenVMS Engineering
  Hewlett-Packard Company

Paul Anderson wrote:

> The tool, by the way, is called PSCom and it was written by Ned 
> Batchelder over twenty years ago.  It does lots more stuff, like allow 
> for conditional execution of code, via IF/ENDIF and INCLUDE statements, 
> stripping of comments and (as noted) compression of PostScript code.

I would find this *extremely* useful.   I write code that takes a
Postscript template file, "fills in the blanks", and sends it to the
printer.   Since I like my templates to be easy to read & modify,
they get rather large.   I think this will speed things up.

Also, the IF/ENDIF functionality would make my life a lot easier.
Can they be nested?

Please make this tool available.

Thanks,
Alan

In article <paul.anderson-3E949B.16134228102008@usenet01.boi.hp.com>, Paul Anderson <paul.anderson@hp.com> writes:
>In article <cBPox3qsYlmy@cuebid.ovms.usa.hp.com>,
> brooks@cuebid.ovms.usa.hp.nospam (Rob Brooks) wrote:
>
>> I think you should make that DCPS_DIET tool available for general use . . .
>
>I just yelled at Rob for making this suggestion.  But he's sometimes 
>right about things, so I wonder if there's interest in having DCPS ship 
>a "reference copy" of the DCPS library in an uncompressed, more readable 
>form.  I think we'd keep the existing library compressed in case someone 
>needs some extra speed on their serially-attached LN03.

Mine is running over a 300baud pennywihistle.  :)



>The tool, by the way, is called PSCom and it was written by Ned 
>Batchelder over twenty years ago.  It does lots more stuff, like allow 
>for conditional execution of code, via IF/ENDIF and INCLUDE statements, 
>stripping of comments and (as noted) compression of PostScript code.

Please ship a refernece library.  It would be quite useful and inform-
ative.
-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.

Paul Anderson wrote:
> so I wonder if there's interest in having DCPS ship 
> a "reference copy" of the DCPS library in an uncompressed, more readable 
> form. 


YES ! YES ! YES !

Consider this current problem the user is having. Having human readable
postcript code would greatly help debug such problems.

I would personally prefer pure postscript (with the #IFDEF etc
processed) so that it makes it easier to look at the actual postscript
code and not have to guess what is really being sent to the printer.

Paul Anderson wrote:
> In article <iMqNk.3613$U5.23438@newsb.telia.net>,
>  Jan-Erik S�derholm <jan-erik.soderholm@telia.com> wrote:
> 
>> I didn't know about the DCPS$TEST logical ! (And it's not in the 
>> manuals...)
> 
> Shhhh, it's a secret.
> 
>> I guess that it's enough to re-start the offending queue ?
> 
> Yes.
> 
>> All queues are running it's own DCPS symbiont (so far).
> 
> Having the logical name DCPS$MAX_STREAMS undefined or set to 1 helps in 
> this case, since the DCPS$TEST logical name is interpreted when a new 
> symbiont process starts.  If a symbiont process can control more than 
> one queue by having DCPS$MAX_STREAMS set to more than 1, you're not 
> guaranteed of getting a new symbiont process when you start a queue.
> 
>> I'll try that romorrow morning on the actual site.
> 
> Since you're running spooled LPD to this printer, you can, instead of 
> using DCPS$TEST, define the logical name DCPS$SPOOL_KEEP (or 
> DCPS$queuename_SPOOL_KEEP) to be TRUE and then the temporary spool file 
> created in DCPS$SPOOL_DIRECTORY will be kept after printing instead of 
> being deleted.  This file is the actual data being sent to the printer 
> so it could be copied to another type of system and sent from there for 
> debugging purposes.
> 
> The queue does not have to be stopped or restarted after defining 
> DCPS$SPOOL.  And all these logical names should be defined 
> /EXECUTIVE_MODE /SYSTEM.
> 
> (The files created with the DCPS$TEST logical name contain some 
> interpreted control characters; for example a ^T character would be the 
> text string "Ctrl/T" in the file.  That's easier to see but not to 
> print.)
> 
> Shhhh, that logical name is a secret too.
> 
> Paul
> 

OK. xxx_SPOOL_KEEP works OK.

Just a question...

If a DCPS queue is set to PCL by having "DATA_TYPE=PCL"
in the DCPS$STARTUP file (and the DCPS$<que>_PARAMETER
logical is setup to "DATA_TYPE=PCL" just fine), does it
still print some PS code to the printer ?

I get a bunch of PS code in the spool file, and then :

<ESC>%-12345X@PJL
@PJL ENTER LANGUAGE = PCL

before the actual printout (which I want to be
printed).

When testing earlier this week I think we got the
correct printout but also a couple of pages before
and after it with plain PS code.

I was think9ng that by running DCPS in "PCL-mode"
one could use non-PS printers also. Maybe wrong...

I also setup the queue to print PS (DATA_TYPE=ANSI)
and now I get a PS-only spool file. The weired
think is that I can not find any "setpagedevice"
in the spool file created today. "setpagedevice"
was what the printer barfed at on Tuesday...

I have to wait for the on-site guy to return tomorrow
morning to check what the printer actuals have printed.
I'm 170 Km away from the site myself...

Anyway, thanks for listening!

Jan-Erik.

Jan-Erik S�derholm wrote:

> If a DCPS queue is set to PCL by having "DATA_TYPE=PCL"
> in the DCPS$STARTUP file (and the DCPS$<que>_PARAMETER
> logical is setup to "DATA_TYPE=PCL" just fine), does it
> still print some PS code to the printer ?

Perhaps Mr Anderson can confirm this, but my gut tells me that DCPS
would send its own postscript code to setup the printer and get page
count, then switch to PCL code to send your print file, and then switch
back to postscript to get the new page count.





> I also setup the queue to print PS (DATA_TYPE=ANSI)

DATA_TYPE=ANSI invokes the ascii to postscript translator.
DATA_TYPE=POSTSCRIPT should pass your postscript to the printer
untranslated. (but still with the DCPS header and footer).


> and now I get a PS-only spool file. The weired
> think is that I can not find any "setpagedevice"
> in the spool file created today. "setpagedevice"
> was what the printer barfed at on Tuesday...

What was the person printing ?

For instance, if I create some postcript job on my macintosh that is
spooled via LPD to my alpha and then DCPS to the printer, the Mac
generated postscript will have a complete setup by itself, including
setpagedevice etc since the Mac will have likely used a .PPD file to
read all the characteristics of the printer and know the valid setup
commands.

so, when sending to the printer, DCPS would send it own setup commands
and then the original postscript file which would have various commands
, including the setpagedevice to get the printer to act in the exact way
that the Mac application wanted it to act.

Now, if the user on a Mac were to pretend he had a fancy Linotype
printer and use the linotype .PDD file, this would result in the Mac
application generating poscript code which may cause the Xerox to barf
at some of the printer-specific commands (such as setpagedevice).


If the files to be printed are simple text files that are being
translated to postscript by DCPS, then the faulty  setpagedevice would
come from DCPS.

In article <w71Ok.3678$U5.23828@newsb.telia.net>,
 Jan-Erik S�derholm <jan-erik.soderholm@telia.com> wrote:

> If a DCPS queue is set to PCL by having "DATA_TYPE=PCL" in the 
> DCPS$STARTUP file (and the DCPS$<que>_PARAMETER logical is setup to 
> "DATA_TYPE=PCL" just fine), does it still print some PS code to the 
> printer ?

Yes.

> I get a bunch of PS code in the spool file, and then :
> 
> <ESC>%-12345X@PJL
> @PJL ENTER LANGUAGE = PCL
> 
> before the actual printout (which I want to be printed).

DCPS controls the print job with PostScript.  If the user file is PCL, 
DCPS tells the printer to switch to PCL with the code you mentioned 
above.  Then it will switch back to PostScript to finish the job.

> I was think9ng that by running DCPS in "PCL-mode" one could use 
> non-PS printers also.

You can't use DCPS with a printer that does not have PostScript.

> I also setup the queue to print PS (DATA_TYPE=ANSI) and now I get a 
> PS-only spool file.

Since the printer doesn't understand ANSI, DCPS translates your ANSI 
file to PostScript.

> The weired think is that I can not find any "setpagedevice" in the 
> spool file created today. "setpagedevice" was what the printer barfed 
> at on Tuesday...

Then something else must be different about the queue setup or file you 
are printing.

When printing with bi-directional protocols like RawTCP, DCPS sends some 
PostScript code called prologues to the printer and stores them on the 
printer so they don't have to be sent each time.  This would make the 
first job printed to the printer after power-up larger as it contains 
these prologues.  But with a uni-directional protocol like LPD, 
prologues are not checked since the printer can't respond to the DCPS 
query about whether the prologues exist.  So the prologues are sent each 
time and, in your case, a 'setpagedevice' command that's in one LPD job 
should also be in another LPD job.

Paul

-- 
 Paul Anderson
  OpenVMS Engineering
  Hewlett-Packard Company

JF Mezei wrote:

> What was the person printing ?

We have two kind of printouts.
They are both text files, one without and one
with embeded PCL commands. We does not create
*any* PS files of our own. *All* PS code
sent to the printer(s) comes from DCPS.

This comment from Paul :

 > You can't use DCPS with a printer that does not have PostScript.

tells me that I had missunderstood that. I thought that
the "DATA_TYPE=PCL" was a way to use the DCPS "infrastructure"
to print PCL on non-PS printers. Guess not...

Seems as I have to get back to the drawingboard to take
a second look on the whole printing setup on this system...

Jan-Erik.

Jan-Erik S�derholm wrote:

> tells me that I had missunderstood that. I thought that
> the "DATA_TYPE=PCL" was a way to use the DCPS "infrastructure"
> to print PCL on non-PS printers. Guess not...

The error message you posted here is typical of a POSTSCRIPT printer. I
would be willing to bet a chocolate bar that the printer does support
Postcript.

As you have seen in the postscript modules sent to the printer, there
are many postscript commands sent to the printer prior to a
setpagedevice command. A PCL-only printer would likely have complained
well before getting to a setpagedevice, and it would have had no concept
of a stack and that a dictionary had been put on the stack just before
calling setpagedevice.

JF Mezei wrote:
> Jan-Erik S�derholm wrote:
> 
>> tells me that I had missunderstood that. I thought that
>> the "DATA_TYPE=PCL" was a way to use the DCPS "infrastructure"
>> to print PCL on non-PS printers. Guess not...
> 
> The error message you posted here is typical of a POSTSCRIPT printer. I
> would be willing to bet a chocolate bar that the printer does support
> Postcript.

Of course it does. *That* printer, that is...
But it also supports PCL with auto-switch
between PS and PCL, so I expect it to also
accept a plain PCL file.

But there are a lot of non-PS printers at the same site,
My hope was to be able to manage them all through DCPS.
Seems not.


> 
> As you have seen in the postscript modules sent to the printer, there
> are many postscript commands sent to the printer prior to a
> setpagedevice command. A PCL-only printer would likely have complained
> well before getting to a setpagedevice, and it would have had no concept
> of a stack and that a dictionary had been put on the stack just before
> calling setpagedevice.

A PCL only printer would usualy print a few pages of PS code.