× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: rpg400-l-digest V1 #239
  • From: Pete <prmoore@xxxxxxxxxxxxxxxxxxxx>
  • Date: Wed, 29 Sep 1999 08:04:22 +0000
  • Organization: Globalnet UK

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. 
This begs the question about how to persuade managers that some rewrites
really are necessary. I've been lucky enough to have a few opportunities
to do some rejuvenation work - in many places this is seen as a perk !:(
 
I only wish that a measurement of the maintenance over-head costs of the
old-code had been accurately gathered to be compared with the new. I
suspect that managers have sometimes been bitten in the past by a less
experienced guy's desire to re-write a large function and in the process
to use every new trick in the book, including large-scale static binding
and too many procedures. The problem is that it takes several years for
a coder to establish a value system and a feel for code elegance, and
unfortunately the vast majority of coders (present company excepted) are
simply not interested.

Best regards
Peter Moore
MJS400
> I do have to take exception with the EXCPT vs UPDAT.  It's not an issue of
> right/wrong, but I would like to explain -why- we adopted an EXCPT standard.
> 
> Your example if IF, EVAL, EVAL, UPDAT is a nice and clear use.  Unfortunately
> when I've got a 150 page program listing in front of me and see that a file is
> processed for update, I flip to the last page and can see the fields being
> updated.  Otherwise I have to go through the whole darn thing and, well the 
>last
> guy probably wasn't as neat as you, I'll find EVAL/MOVE/Z-ADD  on pages 20, 
>38,
> 51, 62, 73, 85, 91, 104, etc.
> 
> Under RPGIII I could scan the first two positions of the result field for CU 
>or
> whatever, but not any more!  If I have a 200 field record being UPDAT'd I 
>have to
> search for every field name to see what is being changed. :(
> 
> Now to back off from my stand, in our WRK commands where the whole record is
> being displayed for user change, we do an UPDAT.  But that's about the only 
>time
> we use such a shotgun approach to record changes.  Like DFU would.
> 
> Regards,
> James W. Kilgore
> qappdsn@ibm.net
>
+---
| 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 thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.