RPGLE Challange for all "Smart" programmers - I need an advanced solution.
Ron Koudijs
I've got a challenge for you all!
Since I use RPGLE our users experience a "Target to small" error every
once in a while. I try to avoid such problems of course but I can't
define all result fields as long as "The Sky is the limit", as
specially in Management Report over several years I really can't
predict the maximum counts.
I could protect every EVAL-statement like this:
IF (A + B) <= Max_A
EVAL A = A + B
ELSE
EVAL A = Max_A
EXSR ReportProblem
ENDIF
But that's a lot of coding as specially when I'am 'really sure' that
the maximum while never be reached!
The Challenge:
I would like to build a function for this case.
I should 'look' something like "EVAL A = MAX(A + B)",
and the MAX function should give the result of (A + B) as long as this
result is less or equal to the maximum value for A or the maximum
value for A when the result for (A + B) is greater than the maximum
for A.
I any suggestion to get me going ...
Ron
--
Ron Kou...@IAEhv.Nl
Thomas Hauber
Bradley V. Stone
Instead of going to such extremes, why not just use the *PSSR to trap
the error. You can check the error code returned and if it's the
"target too small" error.
I do this in programs all the time. In interactive programs I display
an error such as "Mathematical error. Check values or contact the
Help Desk for further assistance." Of course I specify to continue on
at detail time so the screen is redisplayed after this error occurs.
No need for "advanced programming" in this case. If you wanted to,
you could simply write subprocedures for each. The function would
return a one character field (1 for error, 0 for good, or whatever you
want) and accept three fields (factor1, factor2, result). The call to
the procedure would look something like this..
if (MyAdd(factor1:factor2:result) = '1')
* display your favorite error here.
endif
Inside the MyAdd() function you would code a *PSSR to trap the error.
A *PSSR can be specified for each procedure withing a module. So, you
would most likely have MyAdd() and MyMult() inside one function. You
could expand on this idea as well to allow more than two factors.
This shouldn't be tough at all to do.
Bradley V. Stone
http://prairie.lakes.com/~bvstone
"Closing my my mouth before I scream. No one can shake my self-esteem." - YJM
Ron Koudijs
<nospa...@iname.com> wrote:
>You have answered your own question with your example above.
Sorry I need an other kind of "Smart" programmers ;-)
Ron
--
Ron Kou...@IAEhv.Nl
Ron Koudijs
wrote:
>Instead of going to such extremes, why not just use the *PSSR to trap
>the error. You can check the error code returned and if it's the
>"target too small" error.
>I do this in programs all the time. In interactive programs I display
>an error such as "Mathematical error. Check values or contact the
>Help Desk for further assistance." Of course I specify to continue on
>at detail time so the screen is redisplayed after this error occurs.
I like your soluition! But how do a return to the next statement?
When a use *DETL as ReturnPoint value, I restart my program ;-(
because we don't (hardly ever) use the RPG cycle.
When a use *BLANKS as ReturnPoint value, I give control to the default
exception handler and I receive the error message I'am trying to
avoid!
Ron
>No need for "advanced programming" in this case. If you wanted to,
>you could simply write subprocedures for each. The function would
>return a one character field (1 for error, 0 for good, or whatever you
>want) and accept three fields (factor1, factor2, result). The call to
>the procedure would look something like this..
>
>if (MyAdd(factor1:factor2:result) = '1')
>* display your favorite error here.
>endif
>
>Inside the MyAdd() function you would code a *PSSR to trap the error.
>A *PSSR can be specified for each procedure withing a module. So, you
>would most likely have MyAdd() and MyMult() inside one function. You
>could expand on this idea as well to allow more than two factors.
>This shouldn't be tough at all to do.
>
>
>Bradley V. Stone
>http://prairie.lakes.com/~bvstone
>"Closing my my mouth before I scream. No one can shake my self-esteem." - YJM
--
Ron Kou...@IAEhv.Nl
Ron Koudijs
wrote:
"Re: RPGLE Challange for all "Smart" programmers - I need an advanced
solution."
Gary Guthrie
> >Instead of going to such extremes, why not just use the *PSSR to trap
> >the error. You can check the error code returned and if it's the
> >"target too small" error.
> >
> >I do this in programs all the time. In interactive programs I display
> >an error such as "Mathematical error. Check values or contact the
> >Help Desk for further assistance." Of course I specify to continue on
> >at detail time so the screen is redisplayed after this error occurs.
Ron Koudijs wrote:
> I like your soluition! But how do a return to the next statement?
>
> When a use *DETL as ReturnPoint value, I restart my program ;-(
> because we don't (hardly ever) use the RPG cycle.
>
> When a use *BLANKS as ReturnPoint value, I give control to the default
> exception handler and I receive the error message I'am trying to
> avoid!
Ron,
The program status subroutine (*PSSR) is rudimentary, at best. For OPM programs, it was
about all there was in terms of exception handling, however with ILE you have much better
mechanisms for various types of exception handling.
Consider using ILE condition handlers. They'll take care of your problems and allow you to
resume processing at the instruction following the failing one, unlike the *PSSR which
forces you to branch to the top of a handful of return points (boundaries).
Gary Guthrie
Editor, The RPG Source
Technical Editor, NEWS/400 magazine
Gwecnal
In article <362DE051...@airmail.net>, Gary Guthrie <ggut...@airmail.net>
writes:
> Consider using ILE condition handlers. They'll take care of your problems and
> allow you to resume processing at the instruction following the failing one,
unlike
> the *PSSR which forces you to branch to the top of a handful of return points
> (boundaries).
Could you elaborate on 'ILE condition handlers' with respect to EVAL over/under
flow?
Douglas Handy
>No need for "advanced programming" in this case. If you wanted to,
>you could simply write subprocedures for each. The function would
>return a one character field (1 for error, 0 for good, or whatever you
>want) and accept three fields (factor1, factor2, result). The call to
>the procedure would look something like this..
>
>if (MyAdd(factor1:factor2:result) = '1')
>* display your favorite error here.
>endif
This is not as simple as you suppose. The problem is that there is no
equivalent for "operational descriptors" on numeric arguments hence
you cannot tell the size/decimals of the operands and the result
field. Without this crucial information you can't make the generic
subprocedure you propose.
This is one of the advantages real BIFs have over user written
subprocedures.
Doug
bmo...@ca.ibm.com
subroutine in a subprocedure is a useful tool in exception handling. It fits
the current problem exactly, if Ron follows Bradley's suggestion of writing a
subprocedure to handle the arithmetic. The code in the PSSR doesn't try to
return to the "mainline" of the subprocedure, it just handles the error and
returns an indication of "error"; control returns to the statement after the
call whether or not an error occurred. The "add" subprocedure would look
something like this: P myAdd B D myAdd PI 1N D result 5P 0 D arg1
5P 0 value D arg2 5P 0 value C eval result = arg1 + arg2 C return
'0' C *PSSR begsr C report the error C eval result = *HIVAL C
return '1' C endsr P E
I don't really agree that this is a good way to handle the given problem -
unless it's really ok to use the maximum for the result in any subsequent
calculations. But a subprocedure *PSSR IS a good tool for handling situations
where an error is expected and has a meaningful recovery, or can be
meaningfully ignored.
Using an ILE condition handler to handle the exception and continue at the
next instruction isn't very useful in my opinion - I recommend only using a
condition handler to do error reporting but to leave the exception unhandled.
The "next" instruction isn't necessarily the next RPG instruction - it's the
next compiler-generated low-level instruction. It's (almost?) impossible to
use ILE condition handlers to reliably set the result of a failed operation
to some default value. -- Barbara Morris (These are my opinions only, not
necessarily those of my employer.)
In article <362DE051...@airmail.net>,
Gary Guthrie <ggut...@airmail.net> wrote:
> ...
>
> Ron,
>
> The program status subroutine (*PSSR) is rudimentary, at best. For OPM
programs, it was
> about all there was in terms of exception handling, however with ILE you have
much better
> mechanisms for various types of exception handling.
>
> Consider using ILE condition handlers. They'll take care of your problems and
allow you to
> resume processing at the instruction following the failing one, unlike the
*PSSR which
> forces you to branch to the top of a handful of return points (boundaries).
>
> Gary Guthrie
> Editor, The RPG Source
> Technical Editor, NEWS/400 magazine
>
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Gary Guthrie
I'm aware that the PSSR is local to procedures. That being said here are a few comments...
For starters, it seems like overkill to have to code procedures for simple things like
adding numbers when we have clearly defined op-codes for that function, just so we can try
to use the PSSR to handle errors. I submit that this is contorted, contorted, contorted.
Surely it would be better to simply code our Eval statements like
C Eval MyResult = Arg1 + Arg2
than all the code required to prototype a procedure, perform the addition, and house the
PSSR so that we end up with
C Eval MyRtnCode = MyAdd( MyResult : Arg1 : Arg2 )
in our applications.
Also, in my experience, the sample you use (with the PSSR) will fail to be handled, ie.,
it will still signal a "target too small" exception, causing abend.
With respect to ILE condition handlers... It's interesting that you are opposed to having
the handler "handle" the condition and instead prefer to have them only report the
condition, yet in your PSSR example, you have it "handling" the condition by setting the
Result field to *HiVal. But, that's not my point of concern or interest. I'm aware that
the resume cursor is not necessarily the next HLL instruction, but rather the next
low-level instruction. I can also say that I believe it is highly unlikely that this would
present a problem for most (nearly all) situations we are likely to encounter in our
day-to-day. I am of the opinion that one of the selling-points of condition handlers is
that they represent a consistent, robust, and predictable method for exception handling,
irrespective of the HLL language, etc. As such, I defer to condition handlers.
I also find it interesting that you feel that using a condition handler to handle a
condition and continue at the next statement isn't very useful. Do you also feel like
using MONMSG in a CL program to trap errors and continue isn't very useful?
I have great respect for both your level of expertise and your participation in this
newsgroup, but I'm a little surprised by some of your statements this time.
How do you feel about ILE cancel handlers? I think they're groovy enough to include an
article in the upcoming (November/December) issue of The RPG Source. Just curious...
Gary Guthrie
Editor, The RPG Source
Technical Editor, NEWS/400 magazine
> Gary, I agree with you about the "main" *PSSR, but I think the *PSSR
Bradley V. Stone
>
>I like your soluition! But how do a return to the next statement?
>
>When a use *DETL as ReturnPoint value, I restart my program ;-(
>because we don't (hardly ever) use the RPG cycle.
>
>When a use *BLANKS as ReturnPoint value, I give control to the default
>exception handler and I receive the error message I'am trying to
>avoid!
>
>Ron
>
Use *GETIN as the returnpoint value.
Bradley V. Stone
The factors and result could all be 15,5 or something similar.
Specify VALUE as a keyword on the parameters and it won't matter what
size the input parameters are. And, there are now BIFs that would
solve the problem. So, in this case, writing your own is one of your
solutions.
Gary Guthrie
Brad,
Presume the following code (not real code, mind you, but you'll get the picture)...
C-spec 1
C-spec 2
C-spec 3
C-spec 4 containing a call to YourSubprocedureToAddNumbers
C-spec 5
C-spec 6
C-spec 7
Presume the subprocedure call at C-spec 4 fails with the overflow condition.
Can you post a working example where the subprocedure returns a 1-byte error value and
continues processing at C-spec 5? I'd be interested in seeing it. I'm also interested in
seeing the use of *GETIN as the returnpoint value in the subprocedure's PSSR.
Thanks.
John Barron
On Wed, 21 Oct 1998 14:24:47 -0500, Gary Guthrie
<ggut...@airmail.net> wrote:
>Hi Barbara,
>
>I'm aware that the PSSR is local to procedures. That being said here are a few comments...
>
>For starters, it seems like overkill to have to code procedures for simple things like
>adding numbers when we have clearly defined op-codes for that function, just so we can try
>to use the PSSR to handle errors. I submit that this is contorted, contorted, contorted.
>Surely it would be better to simply code our Eval statements like
>
>C Eval MyResult = Arg1 + Arg2
>
>than all the code required to prototype a procedure, perform the addition, and house the
>PSSR so that we end up with
>
>C Eval MyRtnCode = MyAdd( MyResult : Arg1 : Arg2 )
>
>in our applications.
>
I really like this idea, and can see myself using it in practice. Also
for jobs like READE with partial key and other kinds of file i/o,
sometimes with exception handling sometimes not.
With appropriate procedure and variable identifier naming policies, I
see this as being a way of producing highly readable, maintainable
code, and I don't see it as overkill to use procedures like this, nor
as unduly onerous to set up the prototype etc...
<snip>
--
John Barron <bar...@dawson.co.uk>
Analyst/Programmer
Dawson Systems Development
Any opinions are mine and not necessarily of my employer
Mike Cravitz
>Use *GETIN as the returnpoint value.
Unless I'm misunderstanding something here, this will bring you to the
point in the RPG cycle where reads are performed to primary/secondary
files. And if you're not using the cycle for input, it effectively
brings you to the first C specification. This is not the "next"
instruction necessarily.
Mike Cravitz
NEWS/400 Technical Editor
bmo...@ca.ibm.com
In article <362E34FF...@airmail.net>,
Gary Guthrie <ggut...@airmail.net> wrote:
> Hi Barbara,
>
> I'm aware that the PSSR is local to procedures. That being said here are a few
> comments ...
> For starters, it seems like overkill to have to code procedures for simple
> things like
> adding numbers when we have clearly defined op-codes for that function, just
> so we can try
> to use the PSSR to handle errors. I submit that this is contorted, contorted,
> contorted.
> Surely it would be better to simply code our Eval statements like
>
> C Eval MyResult = Arg1 + Arg2
>
> than all the code required to prototype a procedure, perform the addition, and
> house the
> PSSR so that we end up with
>
> C Eval MyRtnCode = MyAdd( MyResult : Arg1 : Arg2 )
>
> in our applications.
>
Sure, I agree. I don't advocate writing subprocedures to handle errors like
this - I may not have said it in my append, but I prefer letting the program
crash for errors like this. I was just using this example to point out that
the problem with the PSSR return point for the main program doesn't really
apply to subprocedures (which presumably usually include more than 1 line of
code) since the PSSR shouldn't have to do any more than error cleanup and
possibly return a "bad" error code, or meaningful result.
> Also, in my experience, the sample you use (with the PSSR) will fail to be
> handled, ie.,
> it will still signal a "target too small" exception, causing abend.
Them's fightin words :) See the end of this append for a working example and
its output.
>
> With respect to ILE condition handlers... It's interesting that you are
> opposed to having
> the handler "handle" the condition and instead prefer to have them only report
> the
> condition, yet in your PSSR example, you have it "handling" the condition by
> setting the
> Result field to *HiVal. ...
Using a PSSR to handle the exception is completely different from using an ILE
condition handler. The "next instruction" for PSSR is well-defined, and I can
set the result to *HIVAL reliably - do you know how to do this with an ILE
condition handler?
> .... But, that's not my point of concern or interest. I'm
> aware that
> the resume cursor is not necessarily the next HLL instruction, but rather the
> next
> low-level instruction. I can also say that I believe it is highly unlikely
> that this would
> present a problem for most (nearly all) situations we are likely to encounter
> in our
> day-to-day. ...
If you handle a decimal data error on an assignment using a condition
handler, the result will most likely have garbage stored into it. Over time,
your whole database can get corrupted if you continue ignoring the error.
(This is not just my theory - it happened ...)
> ... I am of the opinion that one of the selling-points of condition
> handlers is
> that they represent a consistent, robust, and predictable method for exception
> handling,
> irrespective of the HLL language, etc. As such, I defer to condition handlers.
>
> I also find it interesting that you feel that using a condition handler to
> handle a
> condition and continue at the next statement isn't very useful. Do you also
> feel like
> using MONMSG in a CL program to trap errors and continue isn't very useful?
No, because MONMSG is well-defined as to where it goes after it handles the
exception (to the EXEC line). Same with any HLL exception handling mechanism.
>
> I have great respect for both your level of expertise and your participation
> in this newsgroup,
Thanks (blush).
> but I'm a little surprised by some of your statements this time.
>
> How do you feel about ILE cancel handlers? I think they're groovy enough to
> include an
> article in the upcoming (November/December) issue of The RPG Source. Just
> curious...
Oh, I agree completely - I think cancel handlers are by themselves enough
reason to change from OPM to ILE. Way cool.
>
> Gary Guthrie
> Editor, The RPG Source
> Technical Editor, NEWS/400 magazine
--
Barbara Morris IBM Toronto Lab RPG Compiler Development
Here's the example I promised that shows (to my satisfaction at least) that
using a PSSR in a subprocedure this way will handle the error.
D myadd pr n
D result 5p 0
D p1 5p 0 value
D p2 5p 0 value
D res s 5p 0
C eval *in10 = myadd(res : 99999 : 99999)
C res dsply *in10
C eval *in10 = myadd(res : 1 : 2)
C res dsply *in10
C seton lr
p myadd b
D myadd pi n
D result 5p 0
D p1 5p 0 value
D p2 5p 0 value
C eval result = p1 + p2
C return '1'
C *pssr begsr
C eval result = *hival
C return '0'
C endsr
p myadd e
Output:
DSPLY 99999 0
DSPLY 3 1
(There IS a message in the joblog, but it's handled)
Douglas Handy
>>>The call to
>>>the procedure would look something like this..
>>>
>>>if (MyAdd(factor1:factor2:result) = '1')
>>>* display your favorite error here.
>>>endif
>The factors and result could all be 15,5 or something similar.
>Specify VALUE as a keyword on the parameters and it won't matter what
>size the input parameters are.
Um, first off if the third argument (the result field) is pased by
value then any changes made to it will not be seen by the caller.
This sorta defeats the purpose of the subprocedure. <g>
Secondly, the procedure still has no way of knowing when result field
overflow has occured (unless it exceeds the 15,5) to signal the error
condition. So you have to pass the number of digits or maximum value
allowed because operational descriptors or other automagic means are
not available.
Thirdly, I hope you don't think that 15,5 can always be used for
sizing without losing significant digits or decimals.
Again, one advantage of BIFs is that they aren't subject to these same
limitations.
>And, there are now BIFs that would
>solve the problem. So, in this case, writing your own is one of your
>solutions.
Please elaborate. What new BIFs solve this problem? Unless you mean
that you can use %len and %decpos to pass the size of the result field
as additional arguments.
I'm not trying to discourage the use of subprocedures -- I love them.
I just want to point out this is not as simple as it appears on the
surface.
Doug
Gary Guthrie
I'll intersperse with your intersperses! :)
> but I prefer letting the program
> crash for errors like this.
I can't say that I advocate letting programs crash. I much prefer to handle whatever error
in the best possible, graceful manner.
In the case of the current example of overflow on addition, my guess is that we are in
agreement that perhaps it might be best to handle this with additional logic in the
application to prevent the problem. But, if we want some sort of exception handler to take
care of it, then we need to examine the options.
> Them's fightin words :) See the end of this append for a working example and
> its output.
I'm sorry - I should have been more specific.
When you have all your field lengths all nice and neat (as you do in your example with 5,0
packed and with literals for your arguments to add) the PSSR method will not abend. Now
consider that instead of literals for arguments, you're using fields. Since the arguments
are passed by value, you can reasonably expect that you can use mismatched field types and
lengths as long as they are numeric. Let's now look at your code, slightly modified:
D myadd pr n
D result 5p 0
D p1 5p 0 value
D p2 5p 0 value
D res s 5p 0
D a1 S 5p 0 Inz(99999)
D a2 S 5p 0 Inz(99999)
D a3 S 5p 0 Inz(1)
D a4 S 5p 0 Inz(2)
D a5 S 10I 0 Inz(4)
D a6 S 10I 0 Inz(8)
D a7 S 10I 0 Inz(999999999)
D a8 S 10I 0 Inz(999999999)
* 1 - Like your 1st eval except using fields not literals
* Nice and neat example where arguments are 5,0 packed
* Overflow will occur and be handled by PSSR
C eval *in10 = myadd(res : a1 : a2)
C res dsply *in10
* 2 - Like your 2nd eval except using fields not literals
* Nice and neat example where arguments are 5,0 packed
* Overflow does not occur so all is well
C eval *in10 = myadd(res : a3 : a4)
C res dsply *in10
* 3 - A new eval I put in
* Not quite as nice and neat where arguments are 10,0 integer
* Overflow does not occur because arguments are small enough
C eval *in10 = myadd(res : a5 : a6)
C res dsply *in10
* 4 - A new eval I put in
* Not quite as nice and neat where arguments are 10,0 integer
* Overflow occurs because arguments are large numbers
* PSSR does NOT handle this - an abend occurs
C eval *in10 = myadd(res : a7 : a8)
C res dsply *in10
C seton lr
p myadd b
D myadd pi n
D result 5p 0
D p1 5p 0 value
D p2 5p 0 value
C eval result = p1 + p2
C return '1'
C *pssr begsr
C eval result = *hival
C return '0'
C endsr
p myadd
e
Here's the output:
DSPLY 99999 0 (with an expected receiver too small message in the joblog)
DSPLY 3 1
DSPLY 12 1
The target for a numeric operation is too small to hold the result (C G D F). (Along with
an expected receiver too small message in the
joblog)
Notice the fourth eval caused an abend. Hopefully, that clears up my earlier comments. Try
it and see if you get the same results I get.
> Using a PSSR to handle the exception is completely different from using an ILE
> condition handler. The "next instruction" for PSSR is well-defined, and I can
> set the result to *HIVAL reliably - do you know how to do this with an ILE
> condition handler?
The next instruction for condition handlers is well-defined, too. It is the next low-level
instruction. Granted this might not mean a lot to the majority of application programmers,
but it is defined. You can move the resume cursor (so that it is not the next low-level
instruction any longer) with the APIs to return to the procedure's caller. If you want to
set a value to *HIVAL (or whatever special processing you might desire in the case of an
overflow exception), consider decomposing the condition token and reacting appropriately
based on it's contents.
> If you handle a decimal data error on an assignment using a condition
> handler, the result will most likely have garbage stored into it. Over time,
> your whole database can get corrupted if you continue ignoring the error.
> (This is not just my theory - it happened ...)
I hope you didn't infer that I suggest ignoring the error. See my previous paragraph.
> No, because MONMSG is well-defined as to where it goes after it handles the
> exception (to the EXEC line). Same with any HLL exception handling mechanism.
Let's talk about HLL exception handlers - specifically the PSSR in RPG. Ignoring PSSR in
subprocedures for this part of the conversation, the PSSR is a throwback to the unit
record days of RPG. With return points that coincide with the beginning of points in the
cycle, I think that's fairly obvious. Perhaps if we were still reading cards from hoppers
and doing level break processing as our primary applications, it would make *some* sense
to have the return points coincide with cycle-related points. We've evolved from that,
though, and did so a few S3X systems back.
Don't misunderstand me. The PSSR can be helpful - it's just not the most robust method in
my opinion. Obviously, with subprocedures some of the woes disappear, but then there's the
type of issues raised by the above sample code.
We're wearing this topic out! :)
Gwecnal
In article <362F7658...@airmail.net>, Gary Guthrie <ggut...@airmail.net>
writes:
>We're wearing this topic out! :)
No you are not! This is a major deal to us. We have code streching back to
our 360/20 days (files called CARDIN and CARDOUT), stuff from our /34, /36, and
stuff from our first /400 (went live on 9/6/88). We just about can't use EVAL
because of overflow problems that we cannot trap but could ignore - mostly
reports where if an overflow occurs it must NOT stop the process. If the *pssr
had a *NXTC to return to the next calc we would be very happy campers. How
about it Barbara?
Gary Guthrie
> our 360/20 days (files called CARDIN and CARDOUT), stuff from our /34, /36, and
> stuff from our first /400 (went live on 9/6/88). We just about can't use EVAL
> because of overflow problems that we cannot trap but could ignore - mostly
> reports where if an overflow occurs it must NOT stop the process. If the *pssr
> had a *NXTC to return to the next calc we would be very happy campers. How
> about it Barbara?
I'm glad to know that somebody finds this dialogue informational/useful. It is for this
purpose that I continue.
Gary Guthrie
> either VALUE or CONST.
Uhm DH...
CONST is read-only pass-by-reference...
Gary Guthrie
> programs.
It won't always trap this error. See my post to Barbara M. and try it for yourself.
Gary Guthrie
> subprocedure with a *PSSR to catch the error, or to simply do the eval
> with a *PSSR subroutine in the program specifying *GETIN as the
> returnpoint value.
>
> In a subprocedure, or module, each procedure within can have its own
> *PSSR subroutine. If we were using the scenario where we used a
> procedure to figure the result, the *PSSR in the procedure would
> simply be coded as:
>
> C RETURN '1'
>
> if we designate '1' as an error.
Yeah, I know, but my concern is/was whether the questioner was following all this.
I'm sure you've read my other posts here about my estimation of PSSR return points - rigid
and fairly useless.
I'm also sure you've seen my comments about how procedure PSSR cannot be depended on
unless you are very careful about how you define and use fields (as I point out in a post
to Barbara M.). Otherwise, you get abends. And, I think the abends are likely.
Bradley V. Stone
>> Use *GETIN as the returnpoint value.
>
>Brad,
>
>Presume the following code (not real code, mind you, but you'll get the picture)...
>
>C-spec 1
>C-spec 2
>C-spec 3
>C-spec 4 containing a call to YourSubprocedureToAddNumbers
>C-spec 5
>C-spec 6
>C-spec 7
>
>Presume the subprocedure call at C-spec 4 fails with the overflow condition.
>
>Can you post a working example where the subprocedure returns a 1-byte error value and
>continues processing at C-spec 5? I'd be interested in seeing it. I'm also interested in
>seeing the use of *GETIN as the returnpoint value in the subprocedure's PSSR.
>
>Thanks.
>
>Gary Guthrie
>Editor, The RPG Source
>Technical Editor, NEWS/400 magazine
I think you misunderstood my post. I said to either use a
subprocedure with a *PSSR to catch the error, or to simply do the eval
with a *PSSR subroutine in the program specifying *GETIN as the
returnpoint value.
In a subprocedure, or module, each procedure within can have its own
*PSSR subroutine. If we were using the scenario where we used a
procedure to figure the result, the *PSSR in the procedure would
simply be coded as:
C RETURN '1'
if we designate '1' as an error.
Bradley V. Stone
Bradley V. Stone
>Bradley,
>
>>>>The call to
>>>>the procedure would look something like this..
>>>>
>>>>if (MyAdd(factor1:factor2:result) = '1')
>>>>* display your favorite error here.
>>>>endif
>
>>The factors and result could all be 15,5 or something similar.
>>Specify VALUE as a keyword on the parameters and it won't matter what
>>size the input parameters are.
>
>Um, first off if the third argument (the result field) is pased by
>value then any changes made to it will not be seen by the caller.
>This sorta defeats the purpose of the subprocedure. <g>
>
The values will be seen by the caller. I've done this before. If you
don't want to pass values, you can pass pointers to the values
instead. This especially comes in handy when you want to pass a data
structure as a parameter.
>Secondly, the procedure still has no way of knowing when result field
>overflow has occured (unless it exceeds the 15,5) to signal the error
>condition. So you have to pass the number of digits or maximum value
>allowed because operational descriptors or other automagic means are
>not available.
Good point! Maybe there would be a better way, like passing a pointer
(as stated above) to a datastructure with more variables including
each factor, the size and decimal position of each factor, and the
result and side and decimal position of the result. Anything is
possible! <BG>
>
>Thirdly, I hope you don't think that 15,5 can always be used for
>sizing without losing significant digits or decimals.
Of course not, that was just an arbitrary example, which, of course,
you showed would not work. C'mon, man! I'm flyin by the seat of my
pants at home here! ;)
>
>Again, one advantage of BIFs is that they aren't subject to these same
>limitations.
>
>>And, there are now BIFs that would
>>solve the problem. So, in this case, writing your own is one of your
>>solutions.
>
>Please elaborate. What new BIFs solve this problem? Unless you mean
>that you can use %len and %decpos to pass the size of the result field
>as additional arguments.
I'm sorry. Typo. Should have be NO bifs, not NOW bifs... heheh... I
was trying to say that, as far as I know, there are no bifs that do a
multiplication to avoid overflow. I do know there are keywords that
can be used. But those are V3R7 (maybe V4R1) and up. And, since we
do have a V4R2 developement machine, yet most of our production
machines are V3R2, I don't get to play with that stuff very much. :(
>
>I'm not trying to discourage the use of subprocedures -- I love them.
>I just want to point out this is not as simple as it appears on the
>surface.
That's why I'm throwing ideas into the air! :)
>
>Doug
Bradley V. Stone
>Hi Barbara,
>
>I'm aware that the PSSR is local to procedures. That being said here are a few comments...
>
>For starters, it seems like overkill to have to code procedures for simple things like
>adding numbers when we have clearly defined op-codes for that function, just so we can try
>to use the PSSR to handle errors. I submit that this is contorted, contorted, contorted.
>Surely it would be better to simply code our Eval statements like
>
>C Eval MyResult = Arg1 + Arg2
>
>than all the code required to prototype a procedure, perform the addition, and house the
>PSSR so that we end up with
>
>C Eval MyRtnCode = MyAdd( MyResult : Arg1 : Arg2 )
>
>in our applications.
>
>Also, in my experience, the sample you use (with the PSSR) will fail to be handled, ie.,
>it will still signal a "target too small" exception, causing abend.
The PSSR _will_ trap this error. I have used this example in a few
programs.
--snip---
Bradley V. Stone
>
>In article <362F7658...@airmail.net>, Gary Guthrie <ggut...@airmail.net>
>writes:
>
>>We're wearing this topic out! :)
>
>No you are not! This is a major deal to us. We have code streching back to
>our 360/20 days (files called CARDIN and CARDOUT), stuff from our /34, /36, and
>stuff from our first /400 (went live on 9/6/88). We just about can't use EVAL
>because of overflow problems that we cannot trap but could ignore - mostly
>reports where if an overflow occurs it must NOT stop the process. If the *pssr
>had a *NXTC to return to the next calc we would be very happy campers. How
>about it Barbara?
One thing that I find sort of amusing about this thread and topic, is
that we are starting to use eval, getting this error, and realizing
that some of our results have been wrong all this time. Well, at
least those of us who didn't check for this possibility in our
arithmatic.
For example, you have a sales report that prints totals at the end.
Did we know by looking that we were losing a couple signifigant
digits? Maybe not. Then, some poor Sales and Marketing person plugs
this into their database as the comany's yearly sales figure.
I smell trouble.... double trouble.... This could be more work than
Y2K. Is there a variable numeric field available yet? ;)
Douglas Handy
>The values will be seen by the caller. I've done this before. If you
>don't want to pass values, you can pass pointers to the values
>instead. This especially comes in handy when you want to pass a data
>structure as a parameter.
That's what happens when you pass by reference, i.e., do not specify
either VALUE or CONST. But then the arguments have to match exactly
in size/decimals/type (Packed/Zoned/Binary) because you do not have
the benefit of the compiler converting the fields for you.
>Good point! Maybe there would be a better way, like passing a pointer
>(as stated above) to a datastructure with more variables including
>each factor, the size and decimal position of each factor, and the
>result and side and decimal position of the result. Anything is
>possible! <BG>
Sure, you *could* get this to work but you'd probably want to use
additional arguments rather than a DS. Who wants to build the DS
contents just so you can call a subprocedure to perform an ADD?
And then the subprocedure would need lots of baggage code just to
perform the intended math. Hardly seems like progress.
>I'm sorry. Typo. Should have be NO bifs, not NOW bifs... heheh... I
OK, your comment makes more sense to me now.
>That's why I'm throwing ideas into the air! :)
And that's why I'm throwing them out! :)
Doug
Douglas Handy
>The PSSR _will_ trap this error. I have used this example in a few
>programs.
Of course it will. The problem is what to do after it does, and the
code is not in a subprocedure (which has made *PSSR more useful,
IMHO). Returning to *GETIN or *DETC is less than ideal, even when
using the cycle. (And let's not start that debate, OK?)
Doug
Douglas Handy
>I'm glad to know that somebody finds this dialogue informational/useful. It is for this
>purpose that I continue.
I dont think you're wearing it out either. I, for one, am always
grateful for your expertise and insight. Historically, many RPG
programmers have been complacent in their error handling methods
(IMHO), and these type of discussions give them food for thought.
Keep it up,
Doug
Paul Nicolay
Apart from the interesting discussion, I still don't see the point why you
would ignore an incorrect result.
If you add two invoices of $1200 and $300 ... you're happy when your
customer only has to pay $500 ? (just to give an example on small numbers,
but since ILE-RPG supports 30 numbers I can't think of any reasonable
overflow).
I consider the fact that my program crashes on this a major improvement !
At least now I know where to fix it.
Kind regards,
Paul
____________________
Gwecnal <gwe...@aol.com> wrote in article
<19981022180055...@ngol08.aol.com>...
>
> In article <362F7658...@airmail.net>, Gary Guthrie
<ggut...@airmail.net>
> writes:
>
> >We're wearing this topic out! :)
>
> No you are not! This is a major deal to us. We have code streching back
to
> our 360/20 days (files called CARDIN and CARDOUT), stuff from our /34,
/36, and
> stuff from our first /400 (went live on 9/6/88). We just about can't use
EVAL
> because of overflow problems that we cannot trap but could ignore -
mostly
> reports where if an overflow occurs it must NOT stop the process. If the
*pssr
> had a *NXTC to return to the next calc we would be very happy campers.
How
> about it Barbara?
>
The contents of this message express only the sender's opinion.
This message does not necessarily reflect the policy or views of
my employer, Merck & Co., Inc. All responsibility for the statements
made in this Usenet posting resides solely and completely with the
sender.
Douglas Handy
>> That's what happens when you pass by reference, i.e., do not specify
>> either VALUE or CONST.
>CONST is read-only pass-by-reference...
Sorry, I realized it came across wrong after I posted it. I should
have said it happens with VALUE and sometimes CONST.
Although you undoubtably know this, for the sake of others I will
clarify.
The original value is not always passed by reference with CONST. If
the variable does not match the prototype's declaration, then it is
more like being passed by VALUE. It is decimal aligned in a temporary
variable which matches the prototype and its address is passed to the
subprocedure.
So in this case if the "result field" argument matched the declaration
attributes (e.g. 15,5 packed), it would indeed be passed by reference
but otherwise would be passed by value.
I like to add Const to arguments I only use for input, because it
enables you to use constants or expressions on the call (as does
Value) and lets the compiler take care of adjusting field sizes when
necessary. Yet in those cases where a variable is used which matches
the prototype, it is simply passed by reference with no other overhead
(however minimal) for passing by value.
Doug
Douglas Handy
>It won't always trap this error. See my post to Barbara M. and try it for yourself.
I stand corrected (can I sit down now?).
I was thinking of Bradley's reference to mainline calcs, which do not
get the abend during the setup of temporary variables for pass by
value (ala your example).
Doug
Douglas Handy
>I consider the fact that my program crashes on this a major improvement !
>At least now I know where to fix it.
I agree even an ungraceful crash is better than dropping significant
digits. As you say, at least everyone knows it needs to be fixed!
I'm sure that is the rational behind not making Eval suppress overflow
errors. Intentional overflow is rarely good technique (date
conversions notwithstanding).
But I think we are all in agreement that graceful error handling is
better yet. Whenther that involves setting the result to *HiVal is
another matter entirely.
Doug
Gary Guthrie
> I stand corrected (can I sit down now?).
Doug, I hope I didn't offend you. I hope you know I wasn't trying to "correct" you. I
don't think you're offended, but I want to be double, extra sure!
> I was thinking of Bradley's reference to mainline calcs, which do not
> get the abend during the setup of temporary variables for pass by
> value (ala your example).
This whole thread has been kind of like a techno-roller coaster of sorts. I say that
because (and you reinforce it with your comment) it started out with Bradley talking about
subprocedures and the PSSR, and then he later talked about using *GETIN as the return
point of the PSSR. These are clearly 2 different things, except it was anything but clear
(in my opinion) in the thread.
And, oh yeah, go ahead and sit down! :)
Ron Koudijs
<removethis....@merck.com> wrote:
Hi, Paul
>Apart from the interesting discussion, I still don't see the point why you
>would ignore an incorrect result.
>
>If you add two invoices of $1200 and $300 ... you're happy when your
>customer only has to pay $500 ? (just to give an example on small numbers,
>but since ILE-RPG supports 30 numbers I can't think of any reasonable
>overflow).
>
>I consider the fact that my program crashes on this a major improvement !
>At least now I know where to fix it.
I (the poster of the original message) think your right as long as we
are talking about our invoice programs and stuff like that.
But ;-) Just one example ... I've got a statistics program that's
capable of comparing differences of totals over as many months or
years as the user wants!
How big do I have to make my calculation fields?
How many positions do I reserve for each column on my report?
My guess is: Multiply the numbers you know about your biggest office
by a hundred. In this case I've used the totals over a period of three
years. And then when this still gives an error! Don't let the report
crash but generates messages and fault reports for both the user and
the system operator.
Ron
--
Ron Kou...@IAEhv.Nl
Bradley V. Stone
--snip--
>
>>That's why I'm throwing ideas into the air! :)
>
>And that's why I'm throwing them out! :)
>
>Doug
Thanks, Doug, but I haven't seen a suggestion from you yet.
<BAFG> :)
tho...@inorbit.com
Maybe for those who use RPG IV day in/day out; but for some (many?) of us,
this is an extremely interesting thread.
Tom Liotta
In article <362F7658...@airmail.net>,
Gary Guthrie <ggut...@airmail.net> wrote:
> Hi Barb,
>
[ etc ]
>
> We're wearing this topic out! :)
>
> Gary Guthrie
> Editor, The RPG Source
> Technical Editor, NEWS/400 magazine
>
-----------== Posted via Deja News, The Discussion Network ==----------
bmo...@ca.ibm.com
Gary Guthrie <ggut...@airmail.net> wrote:
> ...
> When you have all your field lengths all nice and neat ...
> ...
> Notice the fourth eval caused an abend. Hopefully, that clears up my earlier
> comments. Try
> it and see if you get the same results I get.
Oops, yes, you're right. I was concentrating on discussing the use of the
PSSR in subprocedures, and lost sight of the problem at hand. (But your
counterexample only shows that the "MyAdd" solution doesn't work, not that a
PSSR in a subprocedure doesn't work.)
>
> > Using a PSSR to handle the exception is completely different from using an
> >ILE
> > condition handler. The "next instruction" for PSSR is well-defined, and I
> >can
> > set the result to *HIVAL reliably - do you know how to do this with an ILE
> > condition handler?
>
> The next instruction for condition handlers is well-defined, too. It is the
> next low-level
> instruction. Granted this might not mean a lot to the majority of application
> programmers,
> but it is defined.
I don't think you can say that it is well-defined when it can change with a
recompile. We don't guarantee that we will always generate the same code for
a particular opcode.
> You can move the resume cursor (so that it is not the next
> low-level
> instruction any longer) with the APIs to return to the procedure's caller. If
> you want to
> set a value to *HIVAL (or whatever special processing you might desire in the
> case of an
> overflow exception), consider decomposing the condition token and reacting
> appropriately
> based on it's contents.
Sure you can set "a value to *HIVAL", but do you know how to set the target of
the operation (when the target is a different variable each time) to *HIVAL?
In general, I agree that if the resume cursor is moved to a well-defined
location, it is indeed reasonable to handle exceptions (rather than percolate
them) in a condition handler.
But for most cases I think condition handlers are best used WITH (versus
instead-of) the high-level language handlers (like the PSSR).
--
Barbara Morris IBM Toronto Lab RPG Compiler Development
-----------== Posted via Deja News, The Discussion Network ==----------
bmo...@ca.ibm.com
doubt if you'll ever get overflow (you'd only get overflow if you needed 300
digits) and I think the accuracy will be sufficient for a statistical
application. -- Barbara Morris IBM Toronto Lab RPG Compiler Development
In article <3639bec5...@nntp.iaehv.nl>,
kou...@iaehv.nl (Ron Koudijs) wrote:
> ...
> I (the poster of the original message) think your right as long as we
> are talking about our invoice programs and stuff like that.
>
> But ;-) Just one example ... I've got a statistics program that's
> capable of comparing differences of totals over as many months or
> years as the user wants!
>
> How big do I have to make my calculation fields?
> How many positions do I reserve for each column on my report?
>
> My guess is: Multiply the numbers you know about your biggest office
> by a hundred. In this case I've used the totals over a period of three
> years. And then when this still gives an error! Don't let the report
> crash but generates messages and fault reports for both the user and
> the system operator.
> ...
Richard Knechtel
>
> Gary:
>
> Maybe for those who use RPG IV day in/day out; but for some (many?) of us,
> this is an extremely interesting thread.
>
> Tom Liotta
Yes, I am teaching myeself RPG IV and am learning a lot from reading the
experts bounce this around. I know how to do simple PSSR routines but
would love to learn how better to do error handling in RPG IV. If anyone
has a good general pupose Error handling routine in RPG IV they would
like to posst for me to learn from/play with It would be apprieciated.
(I have good CL error handling down now, from the thread I started
earlier).
Thanks much guys!
Gary Guthrie
1) Since a "specific" solution was being suggested for the questioner along with
"specific" code, I felt it might be advantageous to point out the fact that contrary to
the belief that this would "work", that it indeed wouldn't.
2) On a larger scale, I wanted to highlight my earlier comments that in my opinion the
PSSR, though sometimes useful, is weak in the grand scheme of handling errors. MyAdd
simply served as an example of how it is weak.
From comments I've seen in the newsgroup and in my personal mailbox, though, I'd say our
thread has been fairly well-received. That's the good thing. I don't have a personal stake
in the method folks choose, rather I simply point out alternative ideas, concerns, and
other food-for-thought, that they can use in making their choice.
Brainstorming is a good thing, and I for one, am glad you are here to brainstorm with,
Barbara.
Gary Guthrie
Editor, The RPG Source
Technical Editor, NEWS/400 magazine
Gary Guthrie
> >My example shows that MyAdd doesn't work for two reasons -
> >
> >1) Since a "specific" solution was being suggested for the questioner along with
> >"specific" code, I felt it might be advantageous to point out the fact that contrary to
> >the belief that this would "work", that it indeed wouldn't.
> >
Bradley Stone wrote:
> As the one who gave the so called "specific" solution and code, I have
> to correct you. I did not give either. I was simply "brainstorming",
> as you put it in this message. What I like to call "thinking aloud".
> (even though I'm typing).
>
> It's easy sometimes to give exact answers to some questions, but
> others require a spark to get the conversation going. Everyone does
> everything different (just a figure of speach), and we all get to
> share our ideas.
How about I correct you? For the record, I was referring to Barbara's specific MyAdd
solution. She included code and all. I even responded to her, including her code with
minor additions to point out how the solution would fail. In fact, if you look at the
thread you'll likely see the comments that seem to offend you, as a direct response to
Barbara.
Gary Guthrie wrote:
> >From comments I've seen in the newsgroup and in my personal mailbox, though, I'd say our
> >thread has been fairly well-received. That's the good thing. I don't have a personal stake
> >in the method folks choose, rather I simply point out alternative ideas, concerns, and
> >other food-for-thought, that they can use in making their choice.
Bradley Stone wrote:
> I don't recall any other ideas except using exception handlers. No
> solutions to the problem at hand. Just pointing out the facts, same
> as you. <BG>
I talked about several things other than just "use exception handlers." In fact, I
referred specifically to condition handlers, not exception handlers. I talked about PSSR,
I talked about the debugger, I talked about procedures, I talked about the silliness of
reinventing the ADD op-code,...
Just an FYI, the original questioner sent me email outside the group. He told me he got a
condition handler working and had questions about determining the source statement where
the failure occured (he later posted this on the group and graciously apologized for
sending me private email and asked me to respond on the NG), which I did. I mentioned that
he could consider using debug APIs to get the information perhaps, and pointed out a
scenario for his consideration. Barbara added the QMHRCVPM method for obtaining this
information and I commented on that.
No, I didn't write the fellow's code for him. He seemed quite capable. He asked all the
right questions, and seemed to understand the responses we all made. Had he asked me for a
sample I would have gladly put one together for him - the same one I put together to test
this all out and make sure I knew what I was talking about before I started talking about
it.
I'm sorry if my differing opinion on the appropriate solution offended you. My comments
were not made with that intent. My only intent is to provide info, hopefully helpful and
educational, for those who ask with which they can do what they wish.
Take care.
Bradley V. Stone
>My example shows that MyAdd doesn't work for two reasons -
>
>1) Since a "specific" solution was being suggested for the questioner along with
>"specific" code, I felt it might be advantageous to point out the fact that contrary to
>the belief that this would "work", that it indeed wouldn't.
>
As the one who gave the so called "specific" solution and code, I have
to correct you. I did not give either. I was simply "brainstorming",
as you put it in this message. What I like to call "thinking aloud".
(even though I'm typing).
It's easy sometimes to give exact answers to some questions, but
others require a spark to get the conversation going. Everyone does
everything different (just a figure of speach), and we all get to
share our ideas.
>2) On a larger scale, I wanted to highlight my earlier comments that in my opinion the
>PSSR, though sometimes useful, is weak in the grand scheme of handling errors. MyAdd
>simply served as an example of how it is weak.
I think you made it clear how you feel about the PSSR. :)
>
>From comments I've seen in the newsgroup and in my personal mailbox, though, I'd say our
>thread has been fairly well-received. That's the good thing. I don't have a personal stake
>in the method folks choose, rather I simply point out alternative ideas, concerns, and
>other food-for-thought, that they can use in making their choice.
I don't recall any other ideas except using exception handlers. No
solutions to the problem at hand. Just pointing out the facts, same
as you. <BG>
>
>Brainstorming is a good thing, and I for one, am glad you are here to brainstorm with,
>Barbara.
>
>Gary Guthrie
>Editor, The RPG Source
>Technical Editor, NEWS/400 magazine
>
>
I, too, would like to thank Barabara for her input here. Thanks! I
will continue to use the PSSR. It's working in our large operation
just fine. And in the same case, when the majority of production
machines can't take advantage of some of the suggestions for error
handling mentioned here, the PSSR is better than nothing.
Ron Koudijs
>Ron, this sounds like a perfect application for floating point fields. I
>doubt if you'll ever get overflow (you'd only get overflow if you needed 300
>digits) and I think the accuracy will be sufficient for a statistical
>application. -- Barbara Morris IBM Toronto Lab RPG Compiler Development
THIS MESSAGE IS ALSO POSTED AS U NEW TREAD WITH A SUBJECT:
"HOW TO USE FLOATING POINT FIELDS ON DISPLAY AND PRINTER FILES."
Okay great! ;-)
But how do I use floating point fields on my printer and / or display
file?
How much space do I need to reserve?
How do I print or display the precision the user ask for instead of a
unpredictable amount of numbers after the decimal point?
Just an other dilemma? ;-(
--
Ron Kou...@IAEhv.Nl