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/
