Actually I think I worded that wrong. KEEP in Universe will keep the same spooler file open until you do a PRINTER CLOSE, or SP CLOSE, if I remember correctly... Its been a while.
On Fri, Jan 27, 2012 at 9:27 AM, John Thompson <jthompson...@gmail.com>wrote: > 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 > -- John Thompson _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
