| >
> We have come across a nasty problem with users attempting to print
>post script mail messages (created via say $mail foo.scp mrgate::a1::username)
>in ALL-IN-1 V3.0. Many of these print attempts give no error interactively but
>fail with %LPS-W-INVREST, invalidrestore: errors. The message text prints fine
>from DCL or if we print just the text from ALL-IN-1 (DT to VMS and back to a
>document). The failures we have seen so far are confined to CPS printers,
>(LN03-Rs and LPS40s) with the PS documents created by VAX DOCUMENT V2.0 or
>earlier.
>
> Is this a known problem? (with a solution?)
The problem is caused by applications creating PostScript files which
cannot be printed in the same print job with other PostScript files.
For example, you may have two PostScript files which can be printed
successfully using:
$ PRINT A.PS
$ PRINT B.BS
but if you do:
$ PRINT A.PS, B.PS
the printing of B will fail. I'm not a PostScript expert but understand
that these types of problem occur when PostScript code does not correctly
initialize and/or restore things, which can cause problems to following
PostScript files. The files will print in seperate jobs because a full
reset of the printer is performed between jobs. The printer is not reset
between files.
When ALL-IN-1 prints a PostScript message it formats the Message Header
into a PostScript output file and then appends the PostScript body file to
the output file. That is, it creates one 'physical' file containing two
'logical' PostScript files. When researching this type of problem I found
that creating two physical files made no difference - you still got exactly
the same errors.
You will not get any interactive errors because the errors are occuring in
the Print Server after ALL-IN-1 has created the print job.
When you printed the text from DCL or turned the message into a document
you were creating print jobs with a single file and therefore the problems
did not occur.
The solution to this problem is for applications to create PostScript files
which can be printed in the same job as other files.
The workarounds from ALL-IN-1 are:
1. If you have a PostScript message
Select the PostScript message, use the CD option, specify the 'New
document data type as 'PS', and the name of the output document. This
will create a document, as opposed to a message. When it is printed a
single file print job will be created.
The above has the same result as your DT to and from VMS, but is quicker
and does not require creating a temporary VMS file.
2. If you have PostScript attachments
Do an IA (Index of Attachments), select a single attachment, and print
it so that a single file print job is created.
> Some more information:
>
> 1. In our testing, all message files had a .PS extension with a dsab
> of PS. Printing was attempted to a generic queue w a print style
> of PS.
This looks correct. ALL-IN-1 has correctly identified that the message is
PostScript because the RMS file type is .PS and the ALL-IN-1 Data Type is
PS.
>
> 2. The testing was done on machines running both VMS 5.4-3 and A5.5-1
The version of VMS is unlikely to make any difference. It's the
application which generates the PostScript which is significant, and to a
lesser extent the printer, which is going to cause differences.
> 3. We created 24 messages from PS files I happened to have available.
> The files created by DECwrite, WPS-PLUS V4.0, WINDOWS PSCRIPT and
> VAX DOCUMENT V2.1-1 worked fine. Every file created by VAX DOCUMENT
> V2.0 or V1.2B failed with the INVREST error.
This shows that the problems in VAX DOCUMENT V2.0 and V1.2B have been fixed
in V2.1-1.
Richard
|
| Hi Richard
Many thanks for your speedy answer. Just a few more things:
I tried playing with two of the smaller .PS files, one that worked
(DECwrite) and one that did not (VAX DOCUMENT V2.0):
$ print decwrite.ps,document.ps
$ print document.ps,decwrite.ps
$ append document.ps decwrite.ps
$ print decwrite.ps
All three printouts were fine??
I then tried the same with a WPS-PLUS file (not a mail header) and a
DOCUMENT (V1.2B) file.
$ print wps-plus.ps,document.ps !INVREST after first doc
$ print document.ps,wps-plus.ps !Prints fine
$ append document.ps wps-plus.ps
$ print wps-plus.ps !INVREST after first doc
>When researching this type of problem I found
>that creating two physical files made no difference - you still got exactly
>the same errors.
Guess I just confirmed that.
>The solution to this problem is for applications to create PostScript files
>which can be printed in the same job as other files.
Could there be something (reset?) that WPS-PLUS is not doing here that
perhaps DECwrite, Windows PSCRIPT and DOCUMENT V2.1-1 are compensating for?
> Select the PostScript message, use the CD option, specify the 'New
> document data type as 'PS', and the name of the output document. This
> will create a document, as opposed to a message. When it is printed a
> single file print job will be created.
Yes, that works and it should be faster. Somehow I was thinking that
you couldn't CD a PS to PS.
>This shows that the problems in VAX DOCUMENT V2.0 and V1.2B have been fixed
>in V2.1-1.
Yes, that seems to be what we are saying so hopefully the problem will
go away at some time but right now the majority of what I see is generated by
VAX DOCUMENT V2.0 or 1.2B (16 out of the 24 that I tested). What we need is a
painless (to the user) way to detect the problem and fix it. If the header
PS file is lacking say a reset sequence, we could append that in and everything
would pretty much work except for the people who use GOLD G but thats another
story :-).
Thanks
John
|