RE: page n of x

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
+---