I have a client running an SB+ application who has been experiencing a very
strange issue with Unidata 7.2.8.  The situation is a little complex, but
let me try to explain.

We have this program that issues this SETPTR command and then captures the
hold file number:


This hold file is then generated and once it has been closed with:


... the hold file is picked up and sent to a forms processor (Unform) for
formatting, barcodes, and release to a specific printer.  All this is
working just fine by itself.

Following this (within the same SB+ login session), if the client runs any
report (written in BASIC or SB+ /RD), the PCL for the report and the report
content are sent to the printer in two separate spooler files, but only for
the first run.  The printer receives the PCL document, sets up the printer,
then there's nothing after that so it resets the printer, the next job
prints without the PCL header and the fonts are the printer default rather
than what was requested by the PCL.  If the report is run a second time,
the PCL and content are output to the same spooler file and the report
prints with the correct font.  If the customer drops to the colon TCL
prompt between the first report and the second, the second report prints to
a single hold file without any problems.

We have traced this to the following:

a) The subroutine that prints the report calls another subroutine that
calls SH.PRINT.MANAGER which does a PRINTER ON, sends the PCL at the start
of the job, and then PRINTER OFF (but no PRINTER CLOSE).  This subroutine
then issues a PRINTER ON for the coming report.  The parameters sent into
SH.PRINT,MANAGER basically cause the printer select window to be displayed
where the printer and options can be selected.
b) Back in the main subroutine, an EXECUTE 'GET-LIST something*' *is
c) The program then processes the records and prints the output.  When the
first PRINT statement occurs, a second spooler entry is opened.

Now here's where it gets weird.  If that first report with the
SETPTR/SP.CLOSE combination is not run immediately before the second
report, the second report will print to a single spooler file as expected.
 Also, if the main program does not issue the EXECUTE command - any EXECUTE
command (I've tried several) - the PCL and content are output in the same
spooler file.  Note that the EXECUTE is happening after the PRINTER ON,
though I have tried a PRINTER OFF before the EXECUTE with a PRINTER ON
after it with the exact same (2 spooler file) result.  I have also tried
temporarily relocating the PRINTER ON to follow the EXECUTE, and it still
creates two spooler files.

The subroutine that is being called from this report program is a
vendor-written routine that is literally called from all over the system.
 We have no ability to change this routine (other than for limited
testing), at least not without impacting dozens if not hundreds of reports
that use this routine.  Besides, the routine itself doesn't seem to have
any issue.  Rather, the problem comes when there is a PRINTER ON followed
by a PRINTER OFF followed by another PRINTER ON, but *only* if that
original SETPTR/SP.CLOSE command was used to capture the hold file
immediately prior to running any report.

I've checked SETPTR at various stages of this testing and have found that
the SETPTR settings when it works (generating a single spooler file) is
identical to the SETPTR settings when it doesn't (generating two printer
files).  Furthermore, the SETPTR settings when running the second report
alone, without running this other one first, are identical to the settings
if the SETPTR/SP.CLOSE report is run first.

So if you've stuck with me for this long, please allow me to ask a couple
of direct questions:

* What is SP.CLOSE *really* doing?
* Could it be that the original SETPTR or SP.CLOSE command is setting some
flag somewhere in memory that is causing the next PRINTER OFF (i.e. the one
in SH.PRINT.MANAGER that outputs the PCL) to implicitly do a PRINTER CLOSE?

Any input or assistance would be most appreciated.

U2-Users mailing list

Reply via email to