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: SETPTR 0,132,66,0,0,3,NFMT,NHEAD,BANNER UNIQUE,BRIEF,OPEN This hold file is then generated and once it has been closed with: PRINTER OFF PRINTER CLOSE EXECUTE 'SP.CLOSE' ... 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 executed. 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. -Kevin http://www.PrecisOnline.com _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
