date:20110215

Re: z/OS 1.13 preview

2011-02-15 Thread Ed Gould

--- On Tue, 2/15/11, August Carideo  wrote:

VSE has come a long way since what a lot used to know it as
not up to par w/ Z/os for something's esp with right OEM s/w beats it in
others
( just my opinion , and yes I know what opinions are like no need to remind
me )

I cannot remember where my first run in with VSE was. It was a LONG time ago. 
Probably im the mid 70's (???). I think it was in St Louis at an IBM school 
there.We were trying to set up a 4331 for our New York Office. It was either 
there or out in the LA IBM office. All I can remember is that I did not like it 
in general. It was not consistant on how it handled "things" (control cards and 
the like) its been so long that the abiortion must have reconcieved. I dio 
remember thinking IBM was out of their gourd for propegatting it and it shouuld 
have been put on suicide watch (I would have helped pull ther trigger).
I hated St Louis and I disliked LA. I know I was even brought out for several 
interviews and they would not take no for an answer. One time I was out in the 
high desert west of LA in the middle on nowhere. They now use it to land the 
shuttle I think. at least they used a civilized OS there even though it was 
supposedly top secret and we couldn't even ask for IBM help.
I know dos had a die hard following but IBM should jave just said no more.


                                                                           
             Rob Schramm                                                   
                                                              To 
             Sent by: IBM              IBM-MAIN@bama.ua.edu                
             Mainframe                                                  cc 
             Discussion List                                               
                              Re: z/OS 1.13 preview               
                                                                           
                                                                           
             02/15/2011 11:09                                              
             AM                                                            
                                                                           
                                                                           
             Please respond to                                             
               IBM Mainframe                                               
              Discussion List                                              
                                                            
                                                                           
                                                                           




I think VM is cool too.  I don't really have an opinion about VSE.
 Although, it has been my experience that each of the Operating Systems out
there have their "cool points".  I just am really excited about the 1.13
things... and I am not finished reading the whole thing.

Rob

On Tue, Feb 15, 2011 at 11:02 AM, August Carideo
wrote:

> I like VM/VSE better
> Ok now don't beat me up here
> LOL
>
>
>
>
>             Rob Schramm
>                      L.COM>                                                     To
>             Sent by: IBM              IBM-MAIN@bama.ua.edu
>             Mainframe                                                  cc
>             Discussion List
>                      .edu>                     Re: z/OS 1.13 preview
>
>
>             02/15/2011 10:59
>             AM
>
>
>             Please respond to
>               IBM Mainframe
>              Discussion List
>                            .edu>
>
>
>
>
>
>
> Does anyone else think that working with z/OS is completely the coolest
> thing since the invention of "sliced bread"?
>
> I am reading thru the 1.13 announcement and there is alot of really cool
> stuff. It is hard to just select a few things to talk about.
>
> Rob Schramm
>
> On Tue, Feb 15, 2011 at 10:07 AM, Steve Comstock
> wrote:
>
> > Today the IBM announcements newsletter included the
> > preview for z/OS 1.13.
> >
> > One point that caught my eye immediately:
> >
> >  * Support is planned for in-stream data sets
> >    to be used within JCL procedures and for
> >    include statements.
> >
> > Well! That's been a long time coming. But I'm sure
> > more than a few on this list will appreciate it.
> > (Note: announced for JES2 only)
> >
> >
> > Another interesting change:
> >
> >  * Support is planned for job return codes.
> >    This support will be designed to allow you
> >    to specify that the job return code be set
> >    to the highest return code encountered by
> >    any step, the last step, or a specified
> >    step in the job. This will help make it
> >    simpler to interpret the results of job
> >    execution.
> >
> >
> > For ISPF:
> >
> >  * Line command level Edit macros
> >
> >
> > There are _tons_ of other enhancements li

Re: handling of errors

2011-02-15 Thread Steve Comstock

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 I/O error has occurred rather than issuing an abend. This is intended
to provide a more predictable recovery environment for C/C++ programs when I/O errors are
encountered."

I don't know any specifics on what is being referred to here, nor do I have XL C/C++ to
test anything. But it makes me wonder about others general philosophy on handling what
I'll call "unexpected conditions".

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. Most (not
all, of course!) of the time its going to be the case that the application is
simply going to have some code to check for expected status conditions, and if
the status is not expected print out an error message and exit (hopefully with
a 'non-successful' exit code of some sort) or force an abend. So why not just
allow the invoked routine to abend itself?

I am actually working on some small subroutines to check for error conditions resulting from DL/I calls, DB2 calls, and COBOL
file I/O. The routine will allow for one "expected unsuccessful" result (such as "no more data",
"record not found", etc.), and in any other case it will use the LE CEESGL routine to signal an error with a useful
error message. For batch I will then have a global USRHDLR that will query the operator as to what they want to do, with options
such as "create a CEEDUMP", "percolate" the condition (in the end abending with U4038), continue processing
(if the condition is I, W or E, but not S or C), etc. In CICS the handler will not give the user an option to do anything but
percolate, but it will display the formatted reason to the screen (assuming invoked from a terminal, of course!).

By doing all of this it seems to me the applications will need a lot less checking for errors from which the
application cannot recover anyway. Like logic errors that should happen only when testing (trying to read
from a file that is not open, or whatever). These are cases where obviously if you "expected" it
it would not occur, because you will have the appropriate logic in place. I'm also going to change called
subroutines to signal error conditions. Why should an application have to check to make sure that it called
the routine with the proper data. The caller should always call a routine with valid data. If not it's
pretty much a "logic error". Should not the subroutine signal an error, thus not requiring the
caller to check for situations which "should never occur", and if they do occur must be fixed by
fixing the code so that it is not calling with bad data?

It looks like LE, to some degree, follows this same line of thought. In fact, when calling an LE
routine you have the option of checking the result inline (by providing a "feedback code"
area) or just having the routine signal the error and, generally, aborting the program (assuming
it's not handled). Unless you're actually using the routine to not only act on your data as a data
validator as well (which is reasonable in some cases), what point is there of having the routine
return back to your code when all your code is going to do is say "unexpected error in call to
xxx" and terminate/abend.

CICS conditions are the same. NOHANDLE is both good and bad. It's good because HANDLE
CONDITION is not locally scoped to a single EXEC CICS command, while NOHANDLE is. But
it's bad in that you have to have a not of error checking for those unexpected
conditions. Wouldn't it be better to, on an EXEC CICS tell CICS what conditions you'd
like to handle programatically and have CICS do the proper abend for all other cases?
Then if it turns out there is a case you should be handling but were not aware of at
design time you can add it and handle it appropriately. I've actually submitted this
very requirement to IBM as a result of their recent CICS "what do you want?"
survey.

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.

Frank

Frank,

I have to tell you: one of the first times I taught my
course, now called "Using LE Services in z/OS" was at
the IBM Santa Teresa lab (now Silicon Valley); the audience
was LE level 2 and 3 support, with some of the developers
dropping in; very scary to teach to that audience.

61 matches

Mail list logo