I use a subroutine called OPENER that spares me (any anyone else who uses
it) all of the verbose typing that is so cluttering in every program.
I'm not ignoring the ELSE clause. I'm just referencing the vast amount of
coding for such a small percentage of it being needed.
My OPENER is as follows:
SUBROUTINE OPENER(FILENAME, FILEHANDLE)
OPEN FILENAME TO FILEHANDLE ELSE
Do whatever you want in the world for an ELSE.
Notify the user.
Log the transgression.
Chain back to the menu.
STOP 201, FILENAME
Logoff
I don't really care.
END
RETURN
Just put all of the 'war & peace' stuff once, I repeat *ONCE* in the sub
instead of in the thousands of OPEN statements in the thousands of
application programs.
I'm was not suggesting OPEN FILE ELSE STOP blindly. Just spare yourself from
all the typing and me from all the reading 10 years from now when I get to
the program.
The only time I don't use OPENER is if I want to manage the ELSE condition
such as creating new files on the fly or processing something for the first
time the file is missing. That's the 56/100 % I was referring to. The 99 &
44/100's of the time it's just a regular OPEN. I also did mention its value
when first installing on a new environment.
Yes, it also works as CALL OPENER("DICT CUSTOMER", D.CUSTOMER) and with all
the D3 comma'd files. I wouldn't have offered it (nor would have Spectrum
printed an article about it) if it wasn't universally helpful.
Thanks
Mark Johnson
----- Original Message -----
From: "Timothy Snyder" <[EMAIL PROTECTED]>
To: <u2-users@listserver.u2ug.org>
Sent: Sunday, October 02, 2005 4:59 AM
Subject: Re: [U2] Good Programming Practice Question.........
> "Mark Johnson" <[EMAIL PROTECTED]> wrote on 10/01/2005 01:00:33
> AM:
>
> > Files that can't open are usually solved pretty quickly either after
> > installing the software or making the changes. The downstream elaborate
> > errmsgs for
> >
> > OPEN "CUSTOMER" TO F.CUSTOMER ELSE PRINT "CANNOT OPEN THE CUSTOMER FILE.
> > PLEASE CONTACT YOUR PROGRAMMER. PROGRAM TERMINATING" ; STOP
> > OPEN "INVENTORY" TO F.INVENTORY ELSE PRINT "CANNOT OPEN THE INVENTORY
> FILE.
> > PLEASE CONTACT YOUR PROGRAMMER. PROGRAM TERMINATING" ; STOP
> >
> > or whatever the verbose message/mechanism is, is just an exercise in
> typing.
> > 99.44% of the time the ELSE clause is not realized.
>
> So because it's not likely that an open will fail, it's not worth
> programming for? Can you guarantee that the files will never be placed on
> a network or external device that could fail? Or that the file could be
> deleted or otherwise rendered unusable? I realize that 99.44% is a
> reference to an old Ivory Soap ad, but imagine 56 opens out of 10,000
> failing - that would certainly be worth coding for. Even if there's one
> chance in a million that an open will fail, that's worth coding for. I
> cringe when I see OPEN ... ELSE STOP 201, 'WIDGET'. (I've also even seen
> it with just STOP, without even referencing the file name.) That means
> the poor user will be placed at the command prompt with no idea of what to
> do. (And, noting that you advocate doing OPENs in external subroutines,
> that could leave transactions partially committed. Even if performance
> isn't a concern for you, this should be enough justification to avoid that
> practice.)
>
> I worked with a customer once that had just installed UniData with RFS.
> Everything went well through months of development and testing. Then, on
> the first day running live, OPEN statements started hitting their ELSE
> clauses. It turned out that the N_AFT parameter hadn't been set high
> enough. For those not familiar with RFS, suffice it to say that there
> wasn't enough space in a table that maintains open recoverable files,
> causing the opens to fail. Fortunately, that customer had some
> intelligence built into their open routines, which logged the problems and
> got the users out fairly gently.
>
> One strategy that I like is to have the ELSE clause add the file name to a
> list. Then after all of the opens have been attempted, see if the list is
> empty - if not, report on the files that couldn't be opened, log them
> somewhere, and get the user back to a safe point such as a menu. It may
> require a bit of typing, but those few keystrokes seem well worth the
> effort.
>
>
> Tim Snyder
> Consulting I/T Specialist , U2 Professional Services
> North American Lab Services
> DB2 Information Management, IBM Software Group
> 717-545-6403
> [EMAIL PROTECTED]
> -------
> u2-users mailing list
> u2-users@listserver.u2ug.org
> To unsubscribe please visit http://listserver.u2ug.org/
-------
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
