|
Hello Peter, How far do you go? Well, it depends on what you're after. My view is that in-house code can get away with assuming things about the environment but software-house code can't. (I just wish more software houses thought that way!!!!) I think it reasonable that the program at least check to ensure that the data it is about to print can actually be printed successfully given the current spooled file attributes. For example, if the report is designed for 132 column width but is actually printed on 80 column width, the program can take one of three options. 1/ Print anyway and blame the environment for the problem 2/ Check the printer file width and complain if below the expected width 3/ Open multiple printer files and print as much as will fit in the width and then print the rest in additional spooled files (much like Query Management does). I think option 1 is a cop-out, the haven of lazy programming. Option 3 involves quite a bit of work and is not so easy to do from RPG (other languages have better support for dynamic files). Option 2 seems a good compromise and doesn't take much effort to implement. Similar choices are available for page length. Here though the complaint would occur only when the page size was reduced to below that required for the headings and one group of detail records. As I explain to my students when they ask similar questions, this stuff is only difficult the first time you have to think about it. After that, it becomes second nature and the same basic approach can be implemented by cloning. I think coping with this sort of stuff (along with exception handling, encapsulation, variable scoping, complex data structures, and other things) is the difference between being an average programmer and being a good programmer. Regards, Simon Coulter. «»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«» «» FlyByNight Software AS/400 Technical Specialists «» «» Eclipse the competition - run your business on an IBM AS/400. «» «» «» «» Phone: +61 3 9419 0175 Mobile: +61 0411 091 400 «» «» Fax: +61 3 9419 0175 mailto: shc@flybynight.com.au «» «» «» «» Windoze should not be open at Warp speed. «» «»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«» //--- forwarded letter ------------------------------------------------------- > X-Mailer: Microsoft Outlook Express 5.00.2314.1300 > Date: Sat, 11 Dec 1999 13:41:20 -0800 > From: "Peter Dow" <pcdow@yahoo.com> > To: RPG400-L@midrange.com > Reply-To: RPG400-L@midrange.com > Subject: PRTF Overflow > > Just after I sent that it occurred to me that if you're worried about > someone changing the printer file used by your programs, do you also handle > changed page widths, font sizes, etc.? How far do you go? > > ----- Original Message ----- > From: Simon Coulter <shc@flybynight.com.au> > To: <RPG400-L@midrange.com> > Sent: Saturday, December 11, 1999 3:25 AM > Subject: Re: PRTF Overflow > > > > > > Hello Peter, > > > > It doesn't matter if the groups are fixed sizes or not. The real problem > is that the program > > cannot assume the page length. If I follow your example and someone > alters the page size of > > the printer file used by my program I will have groups of records spanning > pages because the > > rules changed. Anytime you are printing blocks of records you should use > the feedback area > > because things can change outside your program -- and your program should > still cope -- belts > > and braces -- bug-free and all that! > > > > Regards, > > Simon Coulter. +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.