jam@moncskermit.UUCP (05/14/87)
>"Andrew J. Grigor" <flash@brl-lvax.ARPA> wrote > Earlier someone called the print symbiont brain dead since it insisted > on sending a <FF> to the printer after configuring the printer using > specified modules in the control library. It is merely paranoid. The > print symbiont has no idea how the modules in the control library will > affect the printer. By performing a <FF> the printer is in a known > state (upper left hand edge...whereever it may be). > We have a QMS Lasergrafix with the QUIC command controller. ... > I am currently living with the blank pages. I can sleep at night since > the extra scrap generated goes to the Boy Scout's paper drive and is not > totally wasted. There is no need to live with these blank pages forever. Just apply this simple patch (:-) : -------------------------- smbsrvshr.com ------------------ $ patch/jou smbsrvshr.exe ! Patch the File Flag routine to not supply a form feed. (null instead) ! VMS 4.4 fiche 369 K10, 371 H6 def file_flag=7c1 rep/i file_flag+90 ' MOVB #0C,(R3)' exit ' MOVB #0,(R3)' exit update exit ----------------------------------------------------------- At Monash we have a QMS 800 (QUIC) printer driven by a font manager print symbiont (TFMSMB) from Talaris. The printer is located inside our job reception area and runs at just under 1000 pages per day and so it is important to have job flag pages but little wastage. When it was first set up we were spitting out a lot of blank paper, and now after a few iterations on the problem we waste very few. I think we get one blank page when the queue gets started, and perhaps a blank page if you do a print/noflag. It was almost a year ago that I last touched this problem so I can't remember all the details but here goes: I fiddled with TALDEVCTL.TLB (the device control library) a little bit for local conditions but dont think't that decreased the number of blank pages. I changed QTEX (the QUIC TeX printer driver) for A4 size pages and to omit the "^," (throw a page command) at the end of the job. I also hacked the plot packages (NCAR etc.) so that they produced as few blank pages as possible. The major problem is the number of FFs that the Print Symbiont wants to generate itself. I read the fiche in VMS V4.3 days and determined where they all came from. In the VMS V4.4 manuals starting at PSM-27 descriptions of the input routines that generate FFs are referenced by PSM$K_FILE_FLAG, PSM$K_FILE_SETUP_2, PSM$K_FILE_TRAILER, PSM$JOB_COMPLETION, PSM$K_JOB_FLAG, PSM$K_JOB_SETUP, and PSM$K_JOB_TRAILER. See page PSM-16 for the order in which the PSM input routines will be called if required. There is some new_page code (in the formatter) that looks at the data stream and if it sees a formfeed and if it thinks that the printer is already at line 1 column 1 then it decides the FF is superflous and throws it away. In our environment, FORM_SETUP moved the virtual print position away from line 1 column 1, and so the FF at the beginning of FILE_FLAG caused a page throw. My solution (the patch given above) excises the FF from the FILE_FLAG subroutine. This solution did not require any changes to Talaris' TFMSMB. Most of our other printer symbionts print over a terminal network and their queues are only started when they are not empty. In this case our output subroutine tricks the new_page, column 1, line 1 logic to avoid the blank page when the queue is started. Some of our other symbionts have had their JOB_SETUP and JOB_COMPLETION routines replaced by the dummy: --------------------- no_ff.for ----------------------------- integer function no_ff (context, work_area, func, func_desc, 1 func_arg) implicit none integer context, work_area, func, func_desc, func_arg external psm$k_read, psm$_eof, psm$_funnotsup if (func.eq.%loc(psm$k_read)) then no_ff = %loc(psm$_eof) else no_ff = %loc(psm$_funnotsup) endif return end ------------------------------------------------------------ I don't think the print symbiont is brain dead or paranoid. I think the developers did make an improvement on the VMS V1/2/3 symbionts, perhaps they got a bit too worn out to cater for all non-DEC printers. John Mann PS. Anyone tried using the VMS include-a-file-here escape sequence in a device control library to include a setup module without changing the virtual print position? -- --- John Mann, Computer Centre, Monash University, Victoria 3168, Australia ACSnet: jam@moncskermit.oz Phone: +61 3 565 4774 UUCP: ...!{seismo,hplabs,mcvax,ukc,nttlab}!munnari!moncskermit.oz!jam ARPA: jam%moncskermit.oz@seismo.CSS.GOV "Any code from DEC with an IF statement in it is fair game for Patch"
gregg@a.cs.okstate.edu (Gregg Wonderly) (05/14/87)
in article <8705130050.AA15148@ucbvax.Berkeley.EDU>, "Andrew J. Grigor" <flash@brl-lvax.ARPA> says: > > > > Earlier someone called the print symbiont brain dead since it insisted > on sending a <FF> to the printer after configuring the printer using > specified modules in the control library. It is merely paranoid. The > print symbiont has no idea how the modules in the control library will > affect the printer. By performing a <FF> the printer is in a known > state (upper left hand edge...whereever it may be). > > We have a QMS Lasergrafix with the QUIC command controller. Any QUIC > command (configuration command) causes the printer to advance one line. > I can reset the print position to (0,0) by sending more commands or by > performing a <FF>. The symbiont developers apparently decided to take > the safe route and always put a <FF>. Even though I think I understand > why the <FF> was added I believe it should be a qualifier to a queue's > setup to perform a <FF> or not when using control libraries. > > I am currently living with the blank pages. I can sleep at night since > the extra scrap generated goes to the Boy Scout's paper drive and is not > totally wasted. > > - Andy Grigor > This problem is relatively easy to fix using the PSM$ (Print Symbiont Modification) routines. Below is a simple FORTRAN program that should do the trick. The result is that you no longer have the extra page. If you have problems with the line counter on the printer advancing, then you should not use this unless you can add codes to your setup module to reset the printer back to the top of the page without a page eject. implicit none include '($psmdef)' ! You may have to look for these definitions ! in sys$library:starlet.mlb/lib.mlb. integer status, psm$print, psm$replace, setup_2 external sys$exit, pms$print, psm$replace, setup_2 status = pms$replace (PSM$K_FILE_SETUP_2, setup_2) if ((status .and. 1) .ne. 1) call sys$exit (%val(status)) status = pms$print (16,,) call sys$exit (%val(status)) stop end function setup_2 (req_id, work_area, func, fdesc, farg) implicit none include '($psmdef)' integer req_id, work_area, func, fdesc, farg external SS$_NORMAL ! The normal action of the FILE_SETUP_2 module is to insert ! a <FF> into the output stream. The output formatter normally ! removes this <FF> because it realizes that the printer has ! just received a <FF> character from one or more of the previously ! executed modules. When SETUP modules are used, the output ! formatter says "Hey, I'm not at the top of the page anymore, ! I better send this <FF> out". Replacing FILE_SETUP_2 with this ! function should keep the extra formfeed from appearing in the ! output stream. setup_2 = PSM$K_FUNNOTSUP if ((func .eq. PSM$K_OPEN) .or. (func .eq. PSM$K_CLOSE)) then ! Let OPEN and CLOSE complete normally. setup_2 = %loc(SS$_NORMAL) else if (func .eq. PSM$K_READ) then ! No data is ever placed into the buffer to be added to the ! output stream. setup_2 = PSM$K_EOF endif end For more information, you should review the PSM docs in Vol 8a of the VAX/VMS 4.x manuals. ----- Gregg Wonderly Department of Computing and Information Sciences Oklahoma State University UUCP: {cbosgd, ea, ihnp4, isucs1, mcvax, uokvax}!okstate!gregg ARPA: gregg@A.CS.OKSTATE.EDU