|
Michael, At the risk of starting a religious war, the only thing you're missing is "the point". What you've written is perfectly acceptable RPG II. It is not acceptable RPGIV. Conditioning indicators are simply a big no-no because they are easily missed during maintenance. The explicit IF is quickly seen. Likewise using a named indicator instead of numbered. The point isn't that RPGIV takes less lines of code to do a given "something". In fact, RPG IV will take more lines initially. The benefit comes when you start to reuse procedures. For example: c if not (DateIsOk(PRMSDT:PRMFMT) and DateIsOk(PRMEDT:PRMFMT)) c eval PRMERR = *ON c endif p DateIsOk b d DateIsOk pi n d pDate 8s 0 value d pFmt 5a value c select c when pFmt = cDATE_FORMAT_ISO c *ISO test (D) pDate c when pFmt = cDATE_FORMAT_USA c *USE test (D) pDate c endsl c return not %error p DateIsOk e The point is to write the code to validate a date once, sick it in a service program and use it anyplace you need to validate a date. Which is quicker and easier to understand, my 3 lines of code or your 6. Additionally, you'll need to keep writing 6 lines of code, while I'll only need to write 3. HTH, Charles > -----Original Message----- > From: Michael Naughton [mailto:michael_naughton@xxxxxxxxxxxx] > Sent: Wednesday, August 18, 2004 11:50 AM > To: RPG programming on the AS400 / iSeries > Subject: Re: Indicators > > > I've tried to stop using indicators, too, but sometimes they just seem > really handy. The other day, I came across a situation where I just > couldn't see _not_ using them. I wanted to test two 8,0 > fields to see if > they held valid date values, based on either *ISO or *USA > format, and if > either one of them was bad I wanted to set an error flag. > > My code ended up looking like this: > > * Test passed date & set error flag if bad > C Select > C When (PRMFMT = '*YYMD') > C *ISO TEST (D) PRMSDT 99 > C N99*ISO TEST (D) PRMEDT 99 > C When (PRMFMT = '*MDYY') > C *USA TEST (D) PRMSDT 99 > C N99*USA TEST (D) PRMEDT 99 > C EndSL > C 99 Eval PRMERR = *ON > > The shortest non-indicator version I could come up with was this: > > * Test passed date & set error flag if bad > C Select > C When (PRMFMT = '*YYMD') > C *ISO TEST (DE) PRMSDT > C If NOT %Error > C *ISO TEST (DE) PRMEDT > C Endif > C When (PRMFMT = '*MDYY') > C *USA TEST (DE) PRMSDT > C If NOT %Error > C *USA TEST (DE) PRMEDT > C Endif > C EndSL > C If %Error > C Eval PRMERR = *ON > C Endif > > which is a difference of 16 lines instead of 9. Is there a > better way to > do it? Or is there some other reason why avoiding indicators > in this case > is "better"? I fully agree that in many (most?) situations there are > better ways, but "most" is not "all", and I'm not sure that indicators > won't remain useful in the future. . . . > > Am I missing something? > > (PS: don't bother telling me that when I switch to /free I > won't be able > to use indicators. I know that. If I'm forced to switch, I'll give up > indicators, but IMHO that's not a good reason. So far, I find > the benefits > of /free underwhelming, and I'm a guy who has done a fair amount of > programming in Visual Basic and DIBOL -- both very free-format.) > > Ron writes: > >Yes I stopped using numbered indicators a while ago, > > > Mike Naughton > Senior Programmer/Analyst > Judd Wire, Inc. > 124 Turnpike Road > Turners Falls, MA 01376 > 413-863-4357 x444 > mnaughton@xxxxxxxxxxxx >
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.