>>> On 2/17/2011 at 1:31 PM, in message
<20110218155212.223c0f58...@smtp.patriot.net>, "Shmuel Metz (Seymour J.)"
wrote:
> In <4d5bfc54.6f0f.008...@efirstbank.com>, on 02/16/2011
>at 04:30 PM, Frank Swarbrick said:
>
>>Let me give a very specific example. A change to a program has been
>>ma
In <4d5bfc54.6f0f.008...@efirstbank.com>, on 02/16/2011
at 04:30 PM, Frank Swarbrick said:
>Let me give a very specific example. A change to a program has been
>made to access a new file. The JCL with the new DD for whatever
>reason was not implemented. When the program runs and attempts to
In , on 02/16/2011
at 09:00 AM, Tom Marchant said:
>The invoked routine can only protect itself. It can not issue a
>message that includes the context in which it is called.
What prevents the invoked routing from displaying a traceback? For
PL/I that's been a standard capability for decades
Frank,
Error handling becomes much easier once you have a proper infrastructure to
report errors. Years ago I've convinced our CICS systems programmers to add
the following line to the standard CICS JCL
//PTRACEDD SYSOUT=*,DCB=(RECFM=V,BLKSIZE=137,DSORG=PS)
This DD is pointed to by the de
On Wed, 16 Feb 2011 16:30:18 -0700, Frank Swarbrick wrote:
>1) Issue a message to the console ...
>DISPLAY 'Invalid PARM2 in call to ROUTINE: ' PARM2 UPON CONSOLE
Are you suggesting that every error condition detected by a subroutine
should result in a message written to the console by that sub
> I'm not suggesting (god forbid!) that status codes not be checked. I am
> suggesting that status codes not be used at all; rather exceptions should be
> generated that cause everything to come to a halt, with some useful messages
> and a useful dump. That way the users of routines need not be
>>> On 2/16/2011 at 8:00 AM, in message
, Tom Marchant
wrote:
> On Tue, 15 Feb 2011 17:53:30 -0700, Frank Swarbrick wrote:
>
>>In my 15 years of application programming I've always hated the need
>>to check 'status result' fields for conditions that, well, should not occur.
>
>
> The point o
Chase, John
Sent: Wednesday, February 16, 2011 10:56 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: handling of errors
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick
>
> The following detail in the z/OS 1.13 announcement made me curious:
On Wed, 16 Feb 2011 08:55:49 -0600, Chase, John wrote:
>If the "offending" field in the above
>example would cause both a Protection Exception interrupt and a Data
>Exception interrupt, which interrupt is presented first?
It can't cause both. If a protection exception occurs, you can't access
t
On Tue, 15 Feb 2011 17:53:30 -0700, Frank Swarbrick wrote:
>In my 15 years of application programming I've always hated the need
>to check 'status result' fields for conditions that, well, should not occur.
The point of those return codes is that those conditions *do* occur.
Checking them is
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick
>
> The following detail in the z/OS 1.13 announcement made me curious:
> "Language Environment is planned to support recovery from additional
abends . . . for C/C++ programs, . . .."
>
> [ snip ]
>
>
On 2/15/2011 5:53 PM, Frank Swarbrick wrote:
The following detail in the z/OS 1.13 announcement made me curious:
"Language Environment is planned to support recovery from additional abends during
output and close operations for C/C++ programs, and to return to C/C++ programs
indicating that an
On 2/15/2011 7:53 PM, Frank Swarbrick wrote:
In the end I know a lot of people will disagree with this
philosophy right off. But I ask you, especially those who
write application code, would this not make life simpler?
And in most cases no less robust.
I've worked for a number of ISVs, and my
The following detail in the z/OS 1.13 announcement made me curious:
"Language Environment is planned to support recovery from additional abends
during output and close operations for C/C++ programs, and to return to C/C++
programs indicating that an I/O error has occurred rather than issuing an
14 matches
Mail list logo
