|
Point 1: I was really talking about whether size matters or not. I think good design is more important. Matter of taste, really. As James remarked, you can have ten 15 page programs or one 150 page program. Bad design can come in all shapes and sizes. If you're talking about 150 pages of source, that is over 8000 lines of code assuming no forced page breaks. If there are no comments, that's a monster. If there are no comments, it's probably bad code too. Where I work we have several interactive programs in that size range. We have at least one that is that big not counting the programs it calls. That one is pretty easy to modify. (No, I didn't write it.) Some of the others aren't. Point 2: I didn't always do much exception output to files. For a batch job that runs several hours, exception output can give you a performance boost that makes a difference provided you don't have the option of unkeyed sequential I/O. For programs that run in a few minutes, or interactive programs I rarely use it. Point 3: My personal taste runs to O specs over print files for columnar output. I may be one of the few people in the world who feels that way. I think modifying print files is about the same as modifying O specs. I try not to use O specs when I need to do absolute position on the page. > -----Original Message----- > From: Pete [mailto:prmoore@mail.globalnet.co.uk] > Sent: Wednesday, September 29, 1999 1:41 PM > To: rpg400-l@midrange.com > Subject: Re: rpg400-l-digest V1 #241 > > > Hi Joel > > Just to be provocative (a sad hobby, I know) > > From: Joel Fritz <JFritz@sharperimage.com> > > Subject: RE: rpg400-l-digest V1 #239(except vs update and > modular design) > > 1. It's easy to write a simple report that produces a 150 > page listing, > > especially if you count the cross reference. It's also > very easy to make > > that "monster" easy to read and maintain. Modular design > is based on the > > It's certainly 'easy' to generate too much code, usually by repeating > large chunks, and too much code is part of my definition of illegible. > To be clearer I think 150 pages of -source- is far too much for a > member. Maybe not if you're writing a Java compiler in RPG or > something. If code is getting too big, perhaps the RPG isn't > the 'right' > tool for the job. We are talking database programs? One program per > screen context? > > > 2. Exception output has some legitimate uses. If you're > updating a few > > fields in a large record format in a batch process on a > large file, you can > > get a performance boost by using exception output. > Obviously the best > > performance comes from using sequential input and output to > a new file that > > replaces the original (using write), but you don't always > have that luxury. > I'm not persuaded by most machine-efficiency arguments. > Anyway are you saying that the compiler generates less code > via O-specs > than field moves? > > > 3. I like O specs for printer output in a lot of > situations. For a simple > > report that has a heading and detail data in columns, O > specs are just as > > easy to understand as print files and very simple to write > and maintain. You > > can't do a lot of fancy formatting, but it's a question of > using the right > > tool for the job. > Ah those 'simple' reports, how often they get 'improved' over > the space > of a decade. But that's the next guy's problem :) > > Pete > +--- > | This is the RPG/400 Mailing List! > | To submit a new message, send your mail to RPG400-L@midrange.com. > | To subscribe to this list send email to RPG400-L-SUB@midrange.com. > | To unsubscribe from this list send email to > RPG400-L-UNSUB@midrange.com. > | Questions should be directed to the list owner/operator: > david@midrange.com > +--- > +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.