Home > Archive > Cobol > April 2004 > exception handling for intrinsic functions
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
exception handling for intrinsic functions
|
|
| Frank Swarbrick 2004-04-15, 11:30 am |
| Can someone point me in the right direction to a section of a manual that
describes how to handle when an intrinsic function is called with invalid
data. For instance, I do the following:
move "1 23.4" to my-string
compute my-val = function numval-c(my-string)
This causes an LE COBOL runtime error of:
"IGZ0152S Invalid character 3 was found in column 5 in argument-1 for
function NUMVAL-C in program TEST6 at displacement X'0402'. From compile
unit TEST6 at entry point TEST6 at compile unit offset +00000402 at address
0060047A."
I guess my main question is, must I pre-validate my data before calling the
function or is there some way I can "capture" the run-time error and send a
sensible error message to my user? If the latter, how (in general) do I do
it?
I am using IBM COBOL for VSE/ESA, but I'm sure IBM Enterprise COBOL for z/OS
et al are similar, so answers based on that product would probably be OK.
Thanks!
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
| |
| JerryMouse 2004-04-15, 1:30 pm |
| Frank Swarbrick wrote:
> Can someone point me in the right direction to a section of a manual
> that describes how to handle when an intrinsic function is called
> with invalid data. For instance, I do the following:
>
> move "1 23.4" to my-string
> compute my-val = function numval-c(my-string)
>
> This causes an LE COBOL runtime error of:
> "IGZ0152S Invalid character 3 was found in column 5 in argument-1 for
> function NUMVAL-C in program TEST6 at displacement X'0402'. From
> compile unit TEST6 at entry point TEST6 at compile unit offset
> +00000402 at address 0060047A."
>
> I guess my main question is, must I pre-validate my data before
> calling the function or is there some way I can "capture" the
> run-time error and send a sensible error message to my user? If the
> latter, how (in general) do I do it?
>
> I am using IBM COBOL for VSE/ESA, but I'm sure IBM Enterprise COBOL
> for z/OS et al are similar, so answers based on that product would
> probably be OK.
>
Sigh.
It would be nice to have such a property, wouldn't it?
| |
| Joe Zitzelberger 2004-04-15, 7:30 pm |
| In article <c5m7bn$3dl1p$1@ID-184804.news.uni-berlin.de>,
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote:
> Can someone point me in the right direction to a section of a manual that
> describes how to handle when an intrinsic function is called with invalid
> data. For instance, I do the following:
>
> move "1 23.4" to my-string
> compute my-val = function numval-c(my-string)
>
> This causes an LE COBOL runtime error of:
> "IGZ0152S Invalid character 3 was found in column 5 in argument-1 for
> function NUMVAL-C in program TEST6 at displacement X'0402'. From compile
> unit TEST6 at entry point TEST6 at compile unit offset +00000402 at address
> 0060047A."
>
> I guess my main question is, must I pre-validate my data before calling the
> function or is there some way I can "capture" the run-time error and send a
> sensible error message to my user? If the latter, how (in general) do I do
> it?
>
> I am using IBM COBOL for VSE/ESA, but I'm sure IBM Enterprise COBOL for z/OS
> et al are similar, so answers based on that product would probably be OK.
>
> Thanks!
You could use an LE condition handler with a resume point. That is
something of a pain though.
I have found that a state machine that validates the input data to be a
valid numeric works well.
| |
| William M. Klein 2004-04-15, 7:30 pm |
| First, what happens with Intrinsic Functions given invalid inputs for an
ANSI/ISO '89 conforming compiler is UNFORTUNATELY "undefined". It fact, some
compilers are relatively forgiving and some are really QUITE unforgiving. IBM
(all of the compilers that I know) is (again unfortunately) in the latter
category and tends to ABEND when it happens.
The ISO 2002 COBOL Standard "fixes" this in two ways:
1) In general, there are "exceptions" raised - that can be tested and handled -
within a program for ANY intrinsinsic function "feed" an invalid argument.
2) For many (not all) of the Intrinsic Functions there are new "TEST-xxx"
functions. This includes all the NumVal-xxx and Date functions.
Frank - you and I have discussed (off-line) what to do about COBOL (and LE)
"requirements" and VSE. However, your VSE group, might be interested in two
SHARE requirements.
- SSLNGC0313599 "2002 ISO COBOL - TEST-xxxx Intrinsic Functions"
(this requirement was submitted last year and received a user priority of 3.1
of a possible 5)
- SSLNGC0413611 "ISO 2002 - Common exception processing"
(this requirement is currently "Out for Vote"
Implementation (by IBM or any other vendor) of BOTH of this specifications would
"solve" your problem quite nicely. Without them, you are required to "parse"
(using all the argument rules) all your arguments - which pretty much defeats
(IMHO) the benefit of the Intrinsic Functions.
If you need any detail on the current requirements (so they can be submitted
against IBM VSE compiler) let me know off-line.
--
Bill Klein
wmklein <at> ix.netcom.com
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:c5m7bn$3dl1p$1@ID-184804.news.uni-berlin.de...
> Can someone point me in the right direction to a section of a manual that
> describes how to handle when an intrinsic function is called with invalid
> data. For instance, I do the following:
>
> move "1 23.4" to my-string
> compute my-val = function numval-c(my-string)
>
> This causes an LE COBOL runtime error of:
> "IGZ0152S Invalid character 3 was found in column 5 in argument-1 for
> function NUMVAL-C in program TEST6 at displacement X'0402'. From compile
> unit TEST6 at entry point TEST6 at compile unit offset +00000402 at address
> 0060047A."
>
> I guess my main question is, must I pre-validate my data before calling the
> function or is there some way I can "capture" the run-time error and send a
> sensible error message to my user? If the latter, how (in general) do I do
> it?
>
> I am using IBM COBOL for VSE/ESA, but I'm sure IBM Enterprise COBOL for z/OS
> et al are similar, so answers based on that product would probably be OK.
>
> Thanks!
>
>
> ---
> Frank Swarbrick
> Senior Developer/Analyst - Mainframe Applications
> FirstBank Data Corporation - Lakewood, CO USA
| |
| Frank Swarbrick 2004-04-16, 11:30 am |
| How very discouraging. It seems like such a waste for me to validate a
field that the function is going to validate anyway!
Most of our current numeric data validation is pretty basic. We simple use
the CICS BIF DEEDIT to remove all non-numeric data, and we assume the user
has entered both dollars and cents. Some of our programs actually do a bit
more editing to check for existence a decimal point, but that's about it.
(Of course we always display the post-edited field back to the user and have
them verify that they entered what they meant to enter.)
I was thinking that NUMVAL or NUMVAL-C might be useful, but if I have to do
my own validation anyway I'm not sure I see the point! Ugh. Of course I
guess I could write a sub-routine that anyone could use, so maybe it will
still be worthwhile, but it's still frustrating.
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
Frank Swarbrick wrote:[color=darkred]
> Can someone point me in the right direction to a section of a manual
> that describes how to handle when an intrinsic function is called
> with invalid data. For instance, I do the following:
>
> move "1 23.4" to my-string
> compute my-val = function numval-c(my-string)
>
> This causes an LE COBOL runtime error of:
> "IGZ0152S Invalid character 3 was found in column 5 in argument-1 for
> function NUMVAL-C in program TEST6 at displacement X'0402'. From
> compile unit TEST6 at entry point TEST6 at compile unit offset
> +00000402 at address 0060047A."
>
> I guess my main question is, must I pre-validate my data before
> calling the function or is there some way I can "capture" the
> run-time error and send a sensible error message to my user? If the
> latter, how (in general) do I do it?
>
> I am using IBM COBOL for VSE/ESA, but I'm sure IBM Enterprise COBOL
> for z/OS et al are similar, so answers based on that product would
> probably be OK.
>
Sigh.
It would be nice to have such a property, wouldn't it?
| |
| Frank Swarbrick 2004-04-16, 11:30 am |
| LE condition handler, huh? I've yet to understand how these work, and why
they'd be worth the effort to even learn more about it. Does anyone
actually use this "fancy shmancy" LE stuff?
Frank
In article <c5m7bn$3dl1p$1@ID-184804.news.uni-berlin.de>,
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote:
[color=darkred]
> Can someone point me in the right direction to a section of a manual that
> describes how to handle when an intrinsic function is called with invalid
> data. For instance, I do the following:
>
> move "1 23.4" to my-string
> compute my-val = function numval-c(my-string)
>
> This causes an LE COBOL runtime error of:
> "IGZ0152S Invalid character 3 was found in column 5 in argument-1 for
> function NUMVAL-C in program TEST6 at displacement X'0402'. From compile
> unit TEST6 at entry point TEST6 at compile unit offset +00000402 at
address
> 0060047A."
>
> I guess my main question is, must I pre-validate my data before calling
the
> function or is there some way I can "capture" the run-time error and send
a
> sensible error message to my user? If the latter, how (in general) do I
do
> it?
>
> I am using IBM COBOL for VSE/ESA, but I'm sure IBM Enterprise COBOL for
z/OS
> et al are similar, so answers based on that product would probably be OK.
>
> Thanks!
You could use an LE condition handler with a resume point. That is
something of a pain though.
I have found that a state machine that validates the input data to be a
valid numeric works well.
| |
| Frank Swarbrick 2004-04-16, 11:30 am |
| Thanks for the input. I'm considering writing a WAVV requirement to
implement (as much as possible, anyway) the 2002 COBOL standard. I can't
imagine it would be useful to make a separate requirement for each little
feature of the new standard, can you? I mean, while there's some of it I
don't care much about there is also a huge number of new features I'd like
to see implemented; the ones you mention being two of them.
Frank
First, what happens with Intrinsic Functions given invalid inputs for an
ANSI/ISO '89 conforming compiler is UNFORTUNATELY "undefined". It fact,
some
compilers are relatively forgiving and some are really QUITE unforgiving.
IBM
(all of the compilers that I know) is (again unfortunately) in the latter
category and tends to ABEND when it happens.
The ISO 2002 COBOL Standard "fixes" this in two ways:
1) In general, there are "exceptions" raised - that can be tested and
handled -
within a program for ANY intrinsinsic function "feed" an invalid argument.
2) For many (not all) of the Intrinsic Functions there are new "TEST-xxx"
functions. This includes all the NumVal-xxx and Date functions.
Frank - you and I have discussed (off-line) what to do about COBOL (and LE)
"requirements" and VSE. However, your VSE group, might be interested in
two
SHARE requirements.
- SSLNGC0313599 "2002 ISO COBOL - TEST-xxxx Intrinsic Functions"
(this requirement was submitted last year and received a user priority of
3.1
of a possible 5)
- SSLNGC0413611 "ISO 2002 - Common exception processing"
(this requirement is currently "Out for Vote"
Implementation (by IBM or any other vendor) of BOTH of this specifications
would
"solve" your problem quite nicely. Without them, you are required to
"parse"
(using all the argument rules) all your arguments - which pretty much
defeats
(IMHO) the benefit of the Intrinsic Functions.
If you need any detail on the current requirements (so they can be
submitted
against IBM VSE compiler) let me know off-line.
--
Bill Klein
wmklein <at> ix.netcom.com
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:c5m7bn$3dl1p$1@ID-184804.news.uni-berlin.de...[color=darkred]
> Can someone point me in the right direction to a section of a manual that
> describes how to handle when an intrinsic function is called with invalid
> data. For instance, I do the following:
>
> move "1 23.4" to my-string
> compute my-val = function numval-c(my-string)
>
> This causes an LE COBOL runtime error of:
> "IGZ0152S Invalid character 3 was found in column 5 in argument-1 for
> function NUMVAL-C in program TEST6 at displacement X'0402'. From compile
> unit TEST6 at entry point TEST6 at compile unit offset +00000402 at
address
> 0060047A."
>
> I guess my main question is, must I pre-validate my data before calling
the
> function or is there some way I can "capture" the run-time error and send
a
> sensible error message to my user? If the latter, how (in general) do I
do
> it?
>
> I am using IBM COBOL for VSE/ESA, but I'm sure IBM Enterprise COBOL for
z/OS
> et al are similar, so answers based on that product would probably be OK.
>
> Thanks!
>
>
> ---
> Frank Swarbrick
> Senior Developer/Analyst - Mainframe Applications
> FirstBank Data Corporation - Lakewood, CO USA
| |
| William M. Klein 2004-04-16, 6:30 pm |
| SHARE has a "generic" requirement - but it explicitly acknowledges the fact that
implementing the "whole" 2002 Standard is a LOT of work and needs to be "phased
in". Therefore, SHARE has a bunch of individual requirements that give
"priorities" on which features we want implemented first.
I would think that WAVV might find this useful too. On the other hand, (given
past experiences) my GUESS is that IBM would implement COBOL features first
under z/OS - then under (recently previewed) z/VSE. I think that the VSE COBOL
is still "sourced" based on an earlier OS/390 compiler.
--
Bill Klein
wmklein <at> ix.netcom.com
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:c5org9$447bj$4@ID-184804.news.uni-berlin.de...
> Thanks for the input. I'm considering writing a WAVV requirement to
> implement (as much as possible, anyway) the 2002 COBOL standard. I can't
> imagine it would be useful to make a separate requirement for each little
> feature of the new standard, can you? I mean, while there's some of it I
> don't care much about there is also a huge number of new features I'd like
> to see implemented; the ones you mention being two of them.
>
> Frank
>
> First, what happens with Intrinsic Functions given invalid inputs for an
> ANSI/ISO '89 conforming compiler is UNFORTUNATELY "undefined". It fact,
> some
> compilers are relatively forgiving and some are really QUITE unforgiving.
> IBM
> (all of the compilers that I know) is (again unfortunately) in the latter
> category and tends to ABEND when it happens.
>
> The ISO 2002 COBOL Standard "fixes" this in two ways:
>
> 1) In general, there are "exceptions" raised - that can be tested and
> handled -
> within a program for ANY intrinsinsic function "feed" an invalid argument.
>
> 2) For many (not all) of the Intrinsic Functions there are new "TEST-xxx"
> functions. This includes all the NumVal-xxx and Date functions.
>
> Frank - you and I have discussed (off-line) what to do about COBOL (and LE)
> "requirements" and VSE. However, your VSE group, might be interested in
> two
> SHARE requirements.
>
> - SSLNGC0313599 "2002 ISO COBOL - TEST-xxxx Intrinsic Functions"
> (this requirement was submitted last year and received a user priority of
> 3.1
> of a possible 5)
>
> - SSLNGC0413611 "ISO 2002 - Common exception processing"
> (this requirement is currently "Out for Vote"
>
> Implementation (by IBM or any other vendor) of BOTH of this specifications
> would
> "solve" your problem quite nicely. Without them, you are required to
> "parse"
> (using all the argument rules) all your arguments - which pretty much
> defeats
> (IMHO) the benefit of the Intrinsic Functions.
>
> If you need any detail on the current requirements (so they can be
> submitted
> against IBM VSE compiler) let me know off-line.
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
> news:c5m7bn$3dl1p$1@ID-184804.news.uni-berlin.de...
> address
> the
> a
> do
> z/OS
>
>
>
>
| |
|
| Frank Swarbrick wrote:
> Can someone point me in the right direction to a section of a manual that
> describes how to handle when an intrinsic function is called with invalid
> data. For instance, I do the following:
>
> move "1 23.4" to my-string
> compute my-val = function numval-c(my-string)
>
> This causes an LE COBOL runtime error of:
> "IGZ0152S Invalid character 3 was found in column 5 in argument-1 for
> function NUMVAL-C in program TEST6 at displacement X'0402'. From compile
> unit TEST6 at entry point TEST6 at compile unit offset +00000402 at address
> 0060047A."
I'm not an IBM-er, but I don't think (in the COBOL 85 standard) you've
got such an ability. However, the 2002 standard provides intrinsic
validation functions so you can test the data before you pass it to the
picky function (or at least a draft I read somewhere had that in it).
> I guess my main question is, must I pre-validate my data before calling the
> function or is there some way I can "capture" the run-time error and send a
> sensible error message to my user? If the latter, how (in general) do I do
> it?
The former. You could come up with a module that you could call to do
the validation (a "pre-numval-c"), then you could start using it in
different programs...
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
| |
| Joe Zitzelberger 2004-04-17, 12:30 am |
| I've found a few uses for it. It actually isn't all that hard. You
provide a program that you want called in case of an exception.
When an exception happens, each program is called with the exception
code. At this point the program can ignore the problem and let another
program handle it, or it can correct the offending issue and reattempt
whatever caused the exception.
They can be strange, but if you think of them like a generic "ON
EXCEPTION" clause that can apply to any statement, they approach a
certain level of Cobolness.
In article <c5or7t$447bj$3@ID-184804.news.uni-berlin.de>,
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote:
> LE condition handler, huh? I've yet to understand how these work, and why
> they'd be worth the effort to even learn more about it. Does anyone
> actually use this "fancy shmancy" LE stuff?
>
> Frank
>
> In article <c5m7bn$3dl1p$1@ID-184804.news.uni-berlin.de>,
> "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote:
>
> address
> the
> a
> do
> z/OS
>
>
> You could use an LE condition handler with a resume point. That is
> something of a pain though.
>
> I have found that a state machine that validates the input data to be a
> valid numeric works well.
| |
| William M. Klein 2004-04-17, 1:30 am |
| Frank,
I know that you are under LE/VSE rather than z/OS, but if you want to see what
is involved in "catching" and recovering from something like
IGZ0152S
via an LE condition handler,
You might want to glance at:
3.5.4.2 Resuming Execution after an IGZ Condition Occurs
at
http://publibz.boulder.ibm.com/cgi-...eea2140/3.5.4.2
3.6.6.4 Handling a divide-by-zero condition in a COBOL program
at:
http://publibz.boulder.ibm.com/cgi-...eea2140/3.6.6.4
a SHARE presentation called
"Condition Handling with Language Environment"
at
http://ew.share.org/callpapers/atta...e/s8234jmwa.pdf
--
Bill Klein
wmklein <at> ix.netcom.com
"Joe Zitzelberger" <joe_zitzelberger@nospam.com> wrote in message
news:joe_zitzelberger-EB3782.23295216042004@corp.supernews.com...[color=darkred]
> I've found a few uses for it. It actually isn't all that hard. You
> provide a program that you want called in case of an exception.
>
> When an exception happens, each program is called with the exception
> code. At this point the program can ignore the problem and let another
> program handle it, or it can correct the offending issue and reattempt
> whatever caused the exception.
>
> They can be strange, but if you think of them like a generic "ON
> EXCEPTION" clause that can apply to any statement, they approach a
> certain level of Cobolness.
>
>
> In article <c5or7t$447bj$3@ID-184804.news.uni-berlin.de>,
> "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote:
>
| |
| S Comstock 2004-04-27, 11:30 am |
| Frank Swarbrick writes ...
>LE condition handler, huh? I've yet to understand how these work, and why
>they'd be worth the effort to even learn more about it. Does anyone
>actually use this "fancy shmancy" LE stuff?
>
Actually, the LE developers early on thought condition handling would be one of
the big attractions of LE. It hasn't seemed to work out that way. The most
widely used features seem to be date functions (sometimes indirectly through
compiler-generated calls), dynamic storage allocation (otherwise not available
in COBOL), and ease of inter-language communication (again, indirectly, since
all new compilers share this common run time). I've taught a ton of LE classes
over the last 6-7 years, but I don't have a feel that a lot of shops include
calls to CEE... routines in their applications.
Kind regards,
-Steve Comstock
800-993-9716
303-393-8716
www.trainersfriend.com
email: steve@trainersfriend.com
256-B S. Monaco Parkway
Denver, CO 80224
USA
|
|
|
|
|