|
> -----Original Message----- > From: Pete [mailto:prmoore@mail.globalnet.co.uk] > Sent: Wednesday, September 29, 1999 1:04 AM > To: rpg400-l@midrange.com > Subject: Re: rpg400-l-digest V1 #239 > > > James > > Obviously no one is creating 150 page programs anymore, and code that > updates data fields is concentrated in one place? I have > needed O-specs > for the last 6 years, I can't see me adopting them now. /* Titanic Snip */ Ok, I've taken the bait. 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 idea of reducing a task to "atomic" subtasks (always wanted to use "atomic" that way) and then bolting them together as a bunch of black boxes. If you design your programs that way, you or anyone else who does maintenance on them may never need to look at the low level code. Whether you do it with procedures, separate programs, or subroutines that use global variables doesn't matter too much. If the task is big, there's going to be a lot of code involved. It's also easy to write "modular" programs that are impossible to extend or maintain. I've probably written some, and I know I've had to do maintenance on some written by others. If the design is bad, it doesn't matter what philosophy the designer followed. 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. 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. +--- | 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.