| When the system is upgraded and the V2.4 Print files are converted to the V3.0
files informational and warning messages can be written to the installation
log. Did the log contain any of these messages? The
OA$LIB:UPDATE_PRINTERS.SCP file is run to peform this conversion.
Was the V2.4 system using customized versions of the print sub-system
scripts and forms, and in particular had Digital supplied elements been
modified? If so, are any of these being used instead of the V3.0 versions
of the elements.
> Day 3, post V3.0 upgrade. Under V2.4 customer had TONS of custom .PRA
> files with specialized printing sequences coded in them. For instance,
> printer TYPE L140 prints in Landscape mode, 140 characters max per line.
> All a user used to have to do is select their printer, tab to the TYPE
> field and enter the custom format. There is a .PRA file for every type
> they used (as opposed to just having some keywords coded inside the PRA
> file).
This should still work on V3.0.
> Now, under V3.0-1, the printers come up with stuff like SYSTEM_PRINTER, and
> trying to use L140 (etc) in the field comes up as Invalid.
What form and field are you referring to?
> The newer
> printing subsystem uses SMPRINTDESTTYPE and SMPRINTERS, etc, and the Format
> type is no longer the same as the Destination type. This has broken
> printing in almost every app the customer has (in use by 1000 users), plus
> Lotus 1-2-3 for A1 also is broken in printing.
In V2.4 the Format type and Destination type fields referenced the same
dataset but got different information from the dataset, so they were never
really the same. In V3.0 the Format and Destination information are stored
in two different datasets. The upgrade procedure should create new entries
in both the datasets for the customer created types found in the V2.4 file.
Have these entries been created?
> To make it all worse, they use a custom, downloadable logo font in their
> LN03s using simple code written over 4 years ago. I verified that the
> logos are being D/L'd to the printer memory. But now when A1V3.0 prints
> something, it is apparently flushing out the added fonts before it prints.
> All their dept. letterhead forms with logos are now broken.
Without more information about the method was used to download a font it is
difficult to diagnose why this is not happening on V3.0.
Richard
|
| �When the system is upgraded and the V2.4 Print files are converted to the V3.0
�files informational and warning messages can be written to the installation
�log. Did the log contain any of these messages? The
�OA$LIB:UPDATE_PRINTERS.SCP file is run to peform this conversion.
I don't remember seeing any log errors or warnings, etc, but I'll review
the file first thing this morning when I get in. I'm at home right now.
�Was the V2.4 system using customized versions of the print sub-system
�scripts and forms, and in particular had Digital supplied elements been
�modified? If so, are any of these being used instead of the V3.0 versions
�of the elements.
I will also check for this. We had already removed an old WPPRINT script
so it at least is using the correct new script. WPPARG is coming now from
OAFORM. Any other particular files/scripts that we should look for?
�> Day 3, post V3.0 upgrade. Under V2.4 customer had TONS of custom .PRA
�> files with specialized printing sequences coded in them. For instance,
�> printer TYPE L140 prints in Landscape mode, 140 characters max per line.
�> All a user used to have to do is select their printer, tab to the TYPE
�> field and enter the custom format. There is a .PRA file for every type
�> they used (as opposed to just having some keywords coded inside the PRA
�> file).
�This should still work on V3.0.
�> Now, under V3.0-1, the printers come up with stuff like SYSTEM_PRINTER, and
�> trying to use L140 (etc) in the field comes up as Invalid.
�What form and field are you referring to?
On WPPARG in the PTRTYP field (2nd field). I don't know what the V2.4 code
used for /RECOG and /VALID, etc, but the V3.0 code references
OA$PRINTSTYLES DSAB and SMPRINTERS.DTYPE. This lookup appears to be where
our old link to the customized .PRA files is now missing.
�> The newer
�> printing subsystem uses SMPRINTDESTTYPE and SMPRINTERS, etc, and the Format
�> type is no longer the same as the Destination type. This has broken
�> printing in almost every app the customer has (in use by 1000 users), plus
�> Lotus 1-2-3 for A1 also is broken in printing.
�In V2.4 the Format type and Destination type fields referenced the same
�dataset but got different information from the dataset, so they were never
�really the same. In V3.0 the Format and Destination information are stored
�in two different datasets. The upgrade procedure should create new entries
�in both the datasets for the customer created types found in the V2.4 file.
�Have these entries been created?
As far as I know the printer conversion phase ran ok. They have a TON of
printers, and I saw about 4+ pages of logfile showing all the print queue
names that were converted.
�> To make it all worse, they use a custom, downloadable logo font in their
�> LN03s using simple code written over 4 years ago. I verified that the
�> logos are being D/L'd to the printer memory. But now when A1V3.0 prints
�> something, it is apparently flushing out the added fonts before it prints.
�> All their dept. letterhead forms with logos are now broken.
�Without more information about the method was used to download a font it is
�difficult to diagnose why this is not happening on V3.0.
4+ yrs ago when I was resident there, I wrote the D/L stuff. I coded 4
simple LN03-specific print files (.LIS) that are simply queued to the LN03
using GET OA$DCL="$ PRINT/QUEUE=" # PRINT_PRINTER " KOA$PRINT_DIR:LOGO.LIS"
so at this point A1 is really not involved. The .LIS file has the escape
sequences in it to cause the LN03 to load the desired font (included in the
.LIS file) into its memory. I even gave DECUS Symposium presentations on
this 3 yrs ago. We verified the fonts in memory by pushing the white test
button on the back and getting the status sheet. It shows the fonts. So we
ruled out the D/L phase of the problem. But when we then printed a dept.
document using a letterhead control block in WPS-PLUS, the sheet came out
with no logos, and an immediate Test sheet from the printer (white button)
showed that all the newly-loaded fonts were now gone. No other print jobs
were printed before our attempt. This indicates to us that something in
the way printer initialization is handled under A1 V3 / WPS-PLUS V4.1 is
different than the prior version of each of those products.
As soon as I get in there in an hour or so I'll check for old code, etc and
recheck the install log, but I don't think that is the main problem.
Regards,
Al
|
| Some corrections to the errors reported - there was a miscommunication on
exactly what was broken.
It appears that when printing using normal A1 print functions the old
Format Types like L140 etc still do work. What *IS* broken is the
newly-upgraded Lotus 1-2-3 for ALL-IN-1 (V1.5) is failing to use the print
forms, etc. My apologies for the confusion here - it wasn't clearly given
to me yesterday.
However, the Logo issue in .0 and .2 is still a major problem, and that
*IS* an A1 issue.
We have logged a support call on both the Lotus issue (surprisingly, CSC
does support the Lotus integration in A1), and the logo issue.
Al
|
| > I will also check for this. We had already removed an old WPPRINT script
> so it at least is using the correct new script. WPPARG is coming now from
> OAFORM. Any other particular files/scripts that we should look for?
You should review the usage of any customized print completion scripts,
such as WPPSYSTEM, but this is probably not the immediate cause of your
problems. Versions of these scripts for V2.4 will continue to work but will
not support the new Printing settings.
> On WPPARG in the PTRTYP field (2nd field). I don't know what the V2.4 code
> used for /RECOG and /VALID, etc, but the V3.0 code references
> OA$PRINTSTYLES DSAB and SMPRINTERS.DTYPE. This lookup appears to be where
> our old link to the customized .PRA files is now missing.
In V2.2 and earlier versions of ALL-IN-1 the PTRTYP field on WPPARG
referenced the WPS-PLUS Printer table files directly, and validated using
an OA$DIR to the KOA$PRINT_DIR directory.
In V2.3 and V2.4 the PTRTYP field on WPPARG referenced entries in the
SMPRINTERTYPES dataset, and the name of the WPS-PLUS Printer Table file was
obtained from the SMPRINTERTYPES PT_DEVICE field.
In V3.0 the field is validated against the OA$PRINTSTYLES dataset, which is
a special code level dataset which combines together the SMPRINTERTYPES and
USERPRINTSTYLES datasets. If the user does not have any User Print styles
then then only SMPRINTERTYPES will be examined which is equivalent to the
V2.4 method, although the V3.0 SMPRINTERTYPES does contain many more
fields.
The direct reference from the WPPARG PTRTYP field to the WPS-PLUS
Printer Table files was removed in ALL-IN-1 V2.3. Did your customer have a
customization in order to continue to use direct referencing in V2.3 and
V2.4? If so, then there would not be any V2.4 Printer Type entries to
convert into the new format.
> As far as I know the printer conversion phase ran ok. They have a TON of
> printers, and I saw about 4+ pages of logfile showing all the print queue
> names that were converted.
That's the log file information I was referring to. Do you still have a
copy of this log file?
> 4+ yrs ago when I was resident there, I wrote the D/L stuff. I coded 4
> simple LN03-specific print files (.LIS) that are simply queued to the LN03
> using GET OA$DCL="$ PRINT/QUEUE=" # PRINT_PRINTER " KOA$PRINT_DIR:LOGO.LIS"
> so at this point A1 is really not involved. The .LIS file has the escape
> sequences in it to cause the LN03 to load the desired font (included in the
> .LIS file) into its memory. I even gave DECUS Symposium presentations on
> this 3 yrs ago. We verified the fonts in memory by pushing the white test
> button on the back and getting the status sheet. It shows the fonts. So we
> ruled out the D/L phase of the problem. But when we then printed a dept.
> document using a letterhead control block in WPS-PLUS, the sheet came out
> with no logos, and an immediate Test sheet from the printer (white button)
> showed that all the newly-loaded fonts were now gone. No other print jobs
> were printed before our attempt. This indicates to us that something in
> the way printer initialization is handled under A1 V3 / WPS-PLUS V4.1 is
> different than the prior version of each of those products.
When are the LN03-specific print files queued to the printer? Is it done
as part of every print operation?
The WPS-PLUS Formatter will normally create LN03 listing files which
contain an initialization sequence which contains a printer rese, which may
be removing the downloaded fonts. Did you have to modify WPS-PLUS Printer
Tables to prevent this?
Richard
|