"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/
