Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Top 10 Bad Programming Practices in RPG IV

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Top 10 Bad Programming Practices in RPG IV

    ** This thread discusses the article: Top 10 Bad Programming Practices in RPG IV **
    Didn't know a thing about INDDS, but you got me curious. I found the following from techtarget.com. Indicator Data Structure By default, the indicators 01 to 99 on a display or print file are mapped to the indicators 01 to 99 in an RPG program. But when we use the file keyword INDDS (Indicator Data Structure), they are mapped to a data structure instead of the indicators. In other words, the 99 indicators used with the display or print file are now associated with the data structure instead of the indicators *IN01 to *IN99 in the program. The code below shows an example of using the INDDS. The indicators for the display file are mapped to the data structure DspInd. DspInd is a 99 byte data structure, with each byte corresponding to one of the 99 indicators for the display file. This means that for the display file, we MUST use the indicators in the data structure and NOT the numbered indicators. For example, in this program, if we turned on indicator *IN31, it would have no impact on the display file. The program logic must refer to the indicator Error in order to have an impact on the display file. Named indicators are a lot easier to decipher! The use of INDDS requires the use of the file level keyword INDARA in the DDS for the display/print file. In most cases, changing a file to use INDARA will have no effect unless a RESET or CLEAR operation is used. In this case it will now be necessary to also RESET/CLEAR the associated indicators.
    Code

    Comment


    • #17
      Top 10 Bad Programming Practices in RPG IV

      ** This thread discusses the article: Top 10 Bad Programming Practices in RPG IV **
      Honestly, after programming on these systems for 25+ years. I see most "past" programmers as continuing the same practices that are now a part of their everyday habits from the past. A move is obsolete? I don't think so. EVAL is great but in some scenerios it does not work without a blowup (granted in existing code). Lets say when the 2 fields are different in length. Anyway, today we are under so much pressure to finish the job, that frankly and unfortunately-researching the better way to do it, is not the top priority! If there are not any examples of this is how it was and this is how it is. You will always see old stuff, simply because that is what is remembered in the heat of the moment.

      Comment


      • #18
        Top 10 Bad Programming Practices in RPG IV

        ** This thread discusses the article: Top 10 Bad Programming Practices in RPG IV **
        Sometimes it's convenient to code a subfield by its position in the data structure rather than relying on it arriving at the correct position by having the previous subfields coded correctly. An example of this is API documentation that specifies the subfields by their position. You may only want to define a few subfields spread out through the structure. Rather than use from-and-to positions for this, use OVERLAY(data_structure_name : position). That allows you to define the subfield using length notation while still specifying the position. (See raw code 1) This is also useful for INDDS definitions. (See raw code 2)
        Code

        Comment


        • #19
          Top 10 Bad Programming Practices in RPG IV

          ** This thread discusses the article: Top 10 Bad Programming Practices in RPG IV **
          I have noticed that every time I see an example calc of a date duration it is always assumed the file should or would have 8.0 or 8 character date field. In reality most everything I have worked on is still 6.0 with another field for the century 1.0 or 2.0. I have a routine to calculate a date 90 days prior. Does anyone have a better way of getting the century and the 6.0 date then what is shown here for result YMD_90prev? see example raw code
          Code

          Comment


          • #20
            Top 10 Bad Programming Practices in RPG IV

            ** This thread discusses the article: Top 10 Bad Programming Practices in RPG IV **
            > Anyway, today we are under so much pressure > to finish the job, that frankly and unfortunately- > researching the better way to do it, is not the > top priority! I call this the "I'm too busy bailing the boat to plug the leak" syndrome, and it has been around as long as humanity. We need to recognise this as a weakness that needs to be overcome. --buck

            Comment


            • #21
              Top 10 Bad Programming Practices in RPG IV

              ** This thread discusses the article: Top 10 Bad Programming Practices in RPG IV **
              What would you suggest would be the proper way to overcome this so called weakness? Force management to allow training time or have management purchase the required books in order to develop in a better fashion? I am all ears! I think you may be out of touch somewhat with reality, but hey I do the best I can in getting the news or what should be going on with the code - or I wouldn't be on this site (in my spare time!).

              Comment


              • #22
                Top 10 Bad Programming Practices in RPG IV

                ** This thread discusses the article: Top 10 Bad Programming Practices in RPG IV **
                > What would you suggest would be the proper > way to overcome this so called weakness? I personally spend my own time learning new stuff. Lunch, an hour before and an hour after work aren't too hard to scratch up. > Force management to allow training time > or have management purchase the required > books in order to develop in a better fashion? I buy my own books and consider it the price of being a programmer. As to forcing management to allow training time, relying on your boss to advance your career doesn't work in the real world. Your boss will use you as long as you are useful. It is in your own best interest to invest your spare time to become more valuable to your employer. > I think you may be out of touch somewhat > with reality I've never worked for Union Carbide, GE, IBM or any of those really large companies who have a training budget and actually take employees to training courses. I've always worked for smaller companies who value the skills I currently bring to the table, not potential skills that I may develop in the future. So the reality that I live in may indeed be different from yours (and that's not a slur; only a recognition that large companies are different than small companies.) Self training has worked for me since 1978, and when my current employer runs up against a problem that can be solved with a computer, they come to me. Not because I'm a genius - far, far from it. What sets me apart is the fact that I take the time to read, learn and try new fangled stuff before it's necessary to the business. When the business catches up (and small businesses tend to be behind the curve a bit), I've generally got some templates or test programs in my library that I can roll out quickly to demo a proof of concept. I think this is reasonably practical advice even though it is NOT easy. I've raised 2 kids and have a 2 year old at home, so I'm very much aware of the time taken away from my family to improve my standing in the programming community. But I think the higher standard of living we now enjoy was worth the effort. Good luck and best regards, --buck

                Comment


                • #23
                  Top 10 Bad Programming Practices in RPG IV

                  ** This thread discusses the article: Top 10 Bad Programming Practices in RPG IV **
                  Yes, I agree with all that. Yes, I buy books etc. But the majority of "PAST Programmers" do not take the time on their own for example to create a whole process or program based on new practices. But my orginal comment was based on the fact that we pick up new things, as we go (we don't go back and fix old stuff very often) i.e. when working with software packages or whatever. This is bits and pieces at a time. It is great the you have developed your own tool set of standards. This is not the real world as far as developing with new techniques. "PAST" programmers do lots of things to save time! i.e. copy code from existing code, old routines that need to be revamped but never are, etc. Surely you agree there is lots of existing code being reused because it is there and saves time and is a reconized process or for whatever reason this stuff is used! I am mostly referring to maintenance programming as the article was based and how programmers continue to use old coding skills and why (or better why don't they change it then and there!). I can't tell you how many times I have heard "it works, doesn't it"? Development is a different animal (hopefully most of the time, again not always). I am telling you things are done to save time, not because it is the best way. When a manager (let alone a manager with background programming knowledge) says "I don't care how you do it, get it done by tomorrow" is a scenerio - that I think a lot of us have been through and probably will have to continue to live with. I am also telling you they say they want the best, but the end result is what they really want! If you do not have that problem thats great for you and your company. We do what we can, Thats all I am saying. OK I am through with this, have a happy life!

                  Comment


                  • #24
                    Top 10 Bad Programming Practices in RPG IV

                    ** This thread discusses the article: Top 10 Bad Programming Practices in RPG IV **
                    > But the majority of "PAST Programmers" do not take > the time on their own for example to create a whole > process or program based on new practices. Yes, this is true. > But my orginal comment was based on the fact that > we pick up new things, as we go (we don't go back > and fix old stuff very often) i.e. when working with > software packages or whatever. This is also true. > This is bits and pieces at a time. Yes, but that is the very nature of maintenance programming, or programming in general. It's very rare to swap out an entire system for another all in one go. Much more common is the evolution by a thousand modifications approach. > It is great the you have developed your > own tool set of standards. I guess I'm not sure who _hasn't_ developed their own tools? > This is not the real world as far as > developing with new techniques. I think this is where we differ. I've made many thousands of tiny, incremental improvements in the code bases that I've been in over the years, and I've pretty much been able to apply new techniques as I went along. Sub-procedures are an excellent recent example of that. Again, focussing on maintenance rather than R&D type of programming, about the ONLY way to get new techniques in place is to have some practise with your own library so that you can be confident that the changes you are introducing to production code will be stable. > "PAST" programmers do lots of things to save time! > i.e. copy code from existing code, old routines that > need to be revamped but never are, etc. Surely you > agree there is lots of existing code being reused > because it is there and saves time and is a reconized > process or for whatever reason this stuff is used! I sure do agree with you! But this problem won't be addressed without changing the programmer's habits. And that's the idea behind Bob's article .> I am also telling you they say they > want the best, but the end result is > what they really want! You are exactly right. That's why I called it a weakness to go with the flow. It's up to us as good programmers to push our employers to do the right thing whether they like it or not. > We do what we can, Thats all I am saying. > > OK I am through with this, have a happy life! Well thanks! You too! --buck

                    Comment


                    • #25
                      Top 10 Bad Programming Practices in RPG IV

                      ** This thread discusses the article: Top 10 Bad Programming Practices in RPG IV **
                      In my opinion, staying within the standards of the program being maintained overrides desire to use personally preferred methodology. We've seen the magic that buck rolls out here from time to time and those prototypes he speaks of are perfect for starting out a new programming module in a new methodolgy. Also the example that buck gives of adding a subprocedure to an RPG IV program is a good one. But in general, I believe programs should stay consistent with the way they were written as the best form of readable and understandable code. I would extend this even to new programs in a module, even though many new programs in RPG/400 modules are written in RPG IV. I think all this stuff is close enough, or as KVincent says, it works, that for example if the module has many standalone programs with *INLR left off to be called again, I would add another one rather than using a new methodology such as adding a service program. I think it's the customer/client/employer's call whether enhancements with new modules should follow standards or introduce new methodologies. In general, I think there should be more emphasis on cost effectiveness for the business than what the programmer likes or thinks is good for his resume. As a consequence, I haven't written a service program for production but I could write all I want on my own if I cared to find out what I could do with them. And soon enough, they will show up in a prototype that will go into production as buck does. rd

                      Comment


                      • #26
                        Top 10 Bad Programming Practices in RPG IV

                        ** This thread discusses the article: Top 10 Bad Programming Practices in RPG IV **
                        I've usually found IBM's documentation difficult to follow. If I was a complete novice at something (say, HTTP config directives or installing an SSL certificate) I found the documentation to be challenging at best. It's as if you have to be very knowledgeable about the subject or don't even bother. The stuff is generally not written for beginners. I can see where a novice would want to rely on Forums and Email List Services to at least get a start. Sometimes the IBM documentation is just too frustrating. Third party books (like Cozzi's) are invaluable in "translating" IBM's stuff.

                        Comment


                        • #27
                          Top 10 Bad Programming Practices in RPG IV

                          ** This thread discusses the article: Top 10 Bad Programming Practices in RPG IV **
                          > I can see where a novice would want to rely on > Forums and Email List Services to at least get a > start. Sometimes the IBM documentation is just > too frustrating. With the greatest respect, this reliance is generally misplaced for several reasons. 1) The answers given on a web forum range from ridiculous to sublime. How does a newcomer tell the difference? 2) The senior people (those who give the best answers for lack of a better phrase) are almost invariably at work, and their free time is difficult to come by. Participating in web forums is a gift back to the community. A new person will require a lot of an expert's time as he wanders semi-randomly from topic to topic as he encounters them. Thus, a new person may never see the big picture, because the expert simply can't write a tutorial for each and every new person who asks. 3) The time factor is considerable. Trying to teach via email can take weeks for such simple things as subfiles, again because the expert hasn't got the time to devote more than a few minutes each day to the task. 4) The frustration level is high on both sides. The new person feels like the expert is holding back valuable information and the expert feels put upon to drop everything and teach someone who can't be bothered to learn it on his own. (These are feelings, and not necessarily accurate depending on the stress levels!) 5) As frustrating as it may be, everyone needs to be able to navigate, use and understand the IBM reference materials. I've been doing this since 1978, and it's a rare day I don't use an IBM manual. 6) Experts tend to give advice, that is, general concepts and ideas to get things moving, like pseudo-code. Newcomers tend to hear that advice as an exact checklist 'Use this code snippet and your problem is solved.' When an expert does give out working, tested code, the newcomers use it without trying to understand it. Neither of these situations is good for the company the newcomer works for. Here is some advice from a well known programmer, Eric S. Raymond. http://www.catb.org/~esr/faqs/smart-questions.html Respectfully, --buck

                          Comment


                          • #28
                            Top 10 Bad Programming Practices in RPG IV

                            ** This thread discusses the article: Top 10 Bad Programming Practices in RPG IV **
                            Note that while the DS in the example is there to ephasize the point of avoiding from/to columns, it turns out that I have the from/to positions of the MSGID subfield wrong. It should be from 9 to 15 -Bob

                            Comment


                            • #29
                              Top 10 Bad Programming Practices in RPG IV

                              ** This thread discusses the article: Top 10 Bad Programming Practices in RPG IV **
                              The thing about the built-ins for DATE stuff is that they are not available on all releases. I tend to try to reach the entire audience and assume they can upgrade the example on their own installation.

                              Comment


                              • #30
                                Top 10 Bad Programming Practices in RPG IV

                                ** This thread discusses the article: Top 10 Bad Programming Practices in RPG IV **
                                The INDDS is there largely to allow you to map DSPATR and other keywords conditioned by indicators to fields. CUSTERR vs *IN32. It can be used to map the CF01(xx) indicators as well and certainly may be used for that. I simply prefer to avoid the use of indicators when ever possible. Not hide them, but avoid them altogether.

                                Comment

                                Working...
                                X