Tweet
There's really no difference in handling 6-digit or 8-digit dates. Factor 1 of MOVE indicators the non-date format. So *YMD would indicate a 6-digit date, vs *ISO which would indicate an 8-digit date. The rest of the logic is the same. Also the DATE built-in functions work the same way. -Bob
-
-
Top 10 Bad Programming Practices in RPG IV
I do not agree with suggestion 4 A subroutine should be able to be an Isolated entity as much as possible with no need to go back and forth to the other part of the program. If I have some lines of code which is used in many programs and f i am using the /COPY directive, I would use it only once for the subroutine. With the abilty of search in SEU, there is no difference where the field is defined. but for the prgrammer that reads the code it is one less keystroke to search for the length of the field. That's interesting. Local variables implemented as C spec definitions. Yet another way RPG III can do much of RPG IV concepts that I never thought of quite that way.
rd
-
Top 10 Bad Programming Practices in RPG IV
There was a comment about the article assuming 8.0 dates in RPG III but often 7.0 dates were used instead. I had under a very tight deadline the requirement of making a large sales reporting system 53 week compliant for a 1600 store chain. After analyzing the code, I found 6.0, 7.0, and 8.0 in it. I had to do computations on the dates both forwards and backwards for sales comparisons based on fiscal calendar days and weeks. My solution was an RPG IV program that took a date in one parm, the type in another parm (6,7, or 8) and +/- for forwards or backwards and internally bringing to a standard 8.0 before dealing with RPG Date field manipulations. It then returned the + or - one year date answer in the incoming format. It was just a few extra subroutines to convert the different formats to 8.0 and back to handle all the various date formatting found in the RPG III code. The program was quite successful and a permanent solution going forward, even after the 53 week year was over. As we know, the odds that this system will still be being used another six years after that are quite good. rd
Comment
-
Top 10 Bad Programming Practices in RPG IV
It appears that this is a broken link. Is there any other way to get there.Comment
-
Top 10 Bad Programming Practices in RPG IV
I read and enjoyed your article. I started using ILE (RPG & C) around 1997. I had been doing work in RPG III until then, but i learned about ILE and spent quite some time working with it. Most of the 'bad' practices you've mentioned are considered obsolete by my for some years (although i used to code the 'B' type until today, mainly because it has become a habit over the years - it try to do better from now on). What really struck me was your remark about "lying to yourself that you are using ILE..." I've found over the years that a lot of IT managers, programmers and companies are actually doing this. They use the CVTRPGSRC command, and compile it, and after bearly tesing it (!) find the new code works, and they proudly boost to everyone in sight 'We have modernized our application to the latest ILE RPG standard' I am now working for a company that wants us (the programmers) to modernize the applications. And no mather what i try to tell them, they think running CVTRPGSRC will be all that is required. These programs where all written in RPG III, in 2001. Although i can read RPG II/III and maintain III, i would simply refuse to do new work in these languages. The generation of programmers that are still doing everything in RPG III is slowly disappearing, and in 10-15 years time, there will not be very many around to do the maintenance on these programs. In my (very personal) view, IBM is only * SUPPORTING * the Non-ILE versions of the language because of the huge amount of legacy code out in the world, and not endorsing it any longer. So you need to start overhauling your applications now, and not wait only the programmers that can breath it have been retired, and IBM announces that support will end.... Am i allone in this view, or are more people out there having the same experiences ?Comment
-
Top 10 Bad Programming Practices in RPG IV
The article makes no mention of why using ink* for monitoring f-keys is wrong? I have used the indds methods, but for simple programs where you are just waiting for the user to press 1 of 3 possible fkeys, why go through the extra trouble rather than just use the indicators the system has provided for you?Comment
-
Top 10 Bad Programming Practices in RPG IV
** This thread discusses the article: Top 10 Bad Programming Practices in RPG IV **
** This thread discusses the Content article: Top 10 Bad Programming Practices in RPG IV **
This is a discussion about Top 10 Bad Programming Practices in RPG IV.Comment
-
Top 10 Bad Programming Practices in RPG IV
** This thread discusses the article: Top 10 Bad Programming Practices in RPG IV **
A subroutine should be able to be an Isolated entity as much as possible with no need to go back and forth to the other part of the program. If I have some lines of code which is used in many programs and f i am using the /COPY directive, I would use it only once for the subroutine. With the abilty of search in SEU, there is no difference where the field is defined. but for the prgrammer that reads the code it is one less keystroke to search for the length of the field.Comment
-
Top 10 Bad Programming Practices in RPG IV
** This thread discusses the article: Top 10 Bad Programming Practices in RPG IV **
Most other languages allow data to be defined close to the procedure code. This saves a lot of time going back and forth to two different places in the program. I didn't think of mixing D-specs right in with C specs. I'll start taking advantage of that now. Very good article with lots of practical advice. LloydComment
-
Top 10 Bad Programming Practices in RPG IV
** This thread discusses the article: Top 10 Bad Programming Practices in RPG IV **
I whole heartedly support the use of date fields as identified in Suggestion 6. However, the way it is coded is a huge irritation for me. When I see this kind of code I change it immediately. When coming from a non-date field you do not know for sure the data is a valid date. I think it is, I believe it is but I can not KNOW it. RPG gets really crabby about date ops on invalid dates. So do a TEST first then do your date operations. TEST is a simple act of kindness for anyone who ever runs this programComment
-
Top 10 Bad Programming Practices in RPG IV
** This thread discusses the article: Top 10 Bad Programming Practices in RPG IV **
CodeComment
-
Top 10 Bad Programming Practices in RPG IV
** This thread discusses the article: Top 10 Bad Programming Practices in RPG IV **
I agree, I've had my share of explosions because of invalid dates. But I had another issue with that code example besides the assumption that the date is always valid: Why use ADDDUR when you can just use a standard expression with the %DAYS BIF (ShipDate = InvDate + %DAYS(5))? And why use MOVE when you can use the %DATE BIF (InvDate = %DATE(INVDTE : *ISO)? These new built in functions aren't very new anymore and they make code so much cleaner and more readable so why cling to the old date op codes?Comment
-
Top 10 Bad Programming Practices in RPG IV
** This thread discusses the article: Top 10 Bad Programming Practices in RPG IV **
Unfortunately, those that would benefit most from this article probably will not be reading it. The primary reason that there is so much bad code out there is that rather than study and try to improve, too many programmers are just trying to get through their 9 to 5. This is a great article Bob. I would hope that some people take it to heart.Comment
-
Top 10 Bad Programming Practices in RPG IV
** This thread discusses the article: Top 10 Bad Programming Practices in RPG IV **
It was a very good article, but I would like to add two entries to Bob's list: 11) Using C-Specs and 12) Using the MOVE operation. With the advent of free format coding in RPG-IV why would anyone continue to use C-Specs? RPG-III always looked like Assembly Language (BAL) to me and was about as easy to decipher. The ability to format and indent the code was a wonderful addition to the language. Those who use free format all the time will also find that the MOVE statement isn't valid. This is because MOVE is obsolete. Anything you did with MOVE can now be done with EVAL, especially date conversion operations. The %INT(), %DEC(), %CHAR(), %DATE(), %TIME(), and %TIMESTAMP builtin functions provide all the necessary functionality to convert back and forth between date/time and alpha/numeric fields. BTW: Did you know that you can convert RPG-IV C-Specs to free format using the latest version of WDSCi (v5.1.2). Just select the code that needs converting, right click and select "Convert Selection to Free-Format" and the editor will do the rest. (Just be warned that if you have any MOVE or other non-free-format operations in the code the end result will be pretty ugly.)Comment
-
Top 10 Bad Programming Practices in RPG IV
** This thread discusses the article: Top 10 Bad Programming Practices in RPG IV **
Bob, I'm surprised to you advocate this option instead of using an INDDS to allow dou exitPressed What;s your reasoning for not advocating INDDS? CharlesComment
Comment