I do like your use of the word 'strategy'. That probably better defines a programmer's approach to solving any particular problem, especially given the diverse environments one may encounter.
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/
