There is a KEEP option in Universe that will keep the spooler file open no matter what you do in BASIC, until the PRINTER OFF and PRINTER CLOSE.
So maybe try: SETPTR 0,132,66,0,0,3,NFMT,NHEAD,BANNER UNIQUE,BRIEF,OPEN, KEEP Althought looking at that command there, maybe thats what OPEN does... There is a shot in the dark. I don't know how different Unidata's SETPTR may be from Universe's. I just remember banging my head against the wall on the KEEP option some years ago, until I found it. On Fri, Jan 27, 2012 at 12:59 AM, Kevin King <precisonl...@gmail.com> wrote: > 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 > -- John Thompson _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
