|
Gary, You and Dave Leland make a good point that the 2-pass approach is not 100% accurate 100% of the time. But you also wrote: "The measure of a solution is not in terms of the effort required to code the solution, but rather in terms of the robustness of the solution." I'm afraid that is not correct. The measure of a solution is in terms of the *cost* of the solution, plain and simple. You talked about the penalty for I/O intensive jobs that run for 12 hours. Buck Calabro's job would be a good case where it *would NOT be advisable* to use the 2-pass approach. I believe this is the exception to the rule. I don't recall any other posts that mentioned a 12-hour print job. How many of these print jobs we're talking here are closer to 12 seconds vs. 12 hours. Where you say your solution is robust, I would take it you mean more accurate. The 2-pass solution is more robust because it worked the first time. There were about a dozen lines of code so there was no debugging involved. That's robust. My opinion may be in the minority, but I prefer as solution of 12 lines of code over a solution that requires a magazine article to explain. But the main point you didn't discuss is what is the most efficient use of *programmer time*. Computer time became cheaper than programmer time many, many years ago. You need a 12-hour print job to run many times in order to re-coup the expense involved in programming your solution. Now, I agree completely if you're saying the effort required is not the *only* measure of a solution. That gets back to my first point: The measure of a solution is in terms of the *cost* of the solution. Robustness is once piece of the cost. As is maintainablilty, and accuracy. You do have to include the cost of computer resources, but it's just as important to include the cost to develop the code. The KISS method usually wins out when you consider all these, but not always. If you want to sum the whole thing up in one sentence then it has to be: the measure is the cost. It's a mistake to single out one piece of the equation to decide which solution is "weak". IMO, jt -----Original Message----- From: owner-rpg400-l@midrange.com [mailto:owner-rpg400-l@midrange.com]On Behalf Of Gary Guthrie Sent: Thursday, September 07, 2000 11:30 AM To: RPG400-L@midrange.com Subject: Re: page n of x Sure it's a simple-to-code solution. Often, weak solutions are. And, this is indeed a weak solution. Two obvious flaws are 1) There's no guarantee that the data has not changed between runs of the report. This means incorrect output. 2) If the report is created from I/O intensive (or for that matter, anything that runs for a LONG time) attributes such as reading a few HUGE files, there is a penalty. If the report takes 12 hours to produce now, it will take 24 hours to produce with the simple-to-code solution. The measure of a solution is not in terms of the effort required to code the solution, but rather in terms of the robustness of the solution. Gary Guthrie REAL Solutions Technical Support NEWS/400 Technical Editor jt wrote: > > John Hall, > > I had created a test RPGIV to see how well John Carr's two-pass approach > would work. I also had attempted to use an external indicator to suppress > printing on the first pass (I used QSYSPRT). But as you said, it didn't > work in RPGIV (returned total pages of zero when indicator was off). > > As far as overriding to NULL device, you can override to an OUTQ that is not > attached to a writer, and then delete the printout from the first pass. > > I sure don't understand the benefit of using an API, just to get the total > pages to print. It took me longer to write these posts, than it did to code > the test programs. And the 2-pass solution _worked the first time_. Can > you say that of the API approach? Maybe I'm missing something. > > jt > > -----Original Message----- > From: owner-rpg400-l@midrange.com [mailto:owner-rpg400-l@midrange.com]On > Behalf Of John Hall > Sent: Thursday, September 07, 2000 8:48 AM > To: RPG400-L@midrange.com > Subject: Re: page n of x > > You can also use an external indicator on the printer file to suppress > output on the first pass. This will not work in all situations. > Results will vary depending on RPG version and printer file type but if > you handle page breaks within the program you can call the program with > the external indicator off, return the total page count, then call the > program with the indicator on. I think RPGIII will a program described > printer file will handle the overflow correctly regardless of the > external indicator but I couldn't get RPGIV with an external printer > file to update the INFDS with the external indicator off. > > Another possibility might be to override the file to a NULL device - > anybody know how to do this ? > > John Hall > +--- > | 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 > +--- > > +--- > | 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 > +--- +--- | 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 +--- +--- | 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-2024 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.