ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

*inzsr if rpgle all free

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

  • *inzsr if rpgle all free

    Is it still a good idea to use *inzsr to start programs and does anyone know how to code it in all free? 

    What do you use instead of inzsr?

  • #2
    To code *INZSR in free-form:
    Code:
    begsr *inzsr;
    ...
    endsr;
    *INZSR is part of the RPG cycle. It's possible to have a "linear main" RPG program that doesn't use the RPG cycle. Here's the section in the manual that compares a cycle-main module to a linear-main module: http://www.ibm.com/support/knowledge...ycvslinear.htm

    Comment


    • #3
      The alternative to *INZSR would be your own initialization routine. In *SRVPGM, I'll do something like this:

      Code:
      Dcl-s lInit ind static;
      
      If not lInit;
        Initialize();
        lInit = *on;
      Endif;

      Comment


      • #4
        IMHO, before we can have a good discussion about whether *INZSR is (or isn't) a good choice, we'd need to know what you plan to use it for.

        Personally, I prefer to use the INZ keyword on DCL (or D-spec) whenever possible.

        Since I don't generally use the cycle, I almost never find *INZSR useful. Simply put first time initializations at the appropriate place in your your calcs -- easy to follow and logical. Of course, you could argue that this doesn't work with the RESET opcode... but I generally avoid the RESET opcode because it's usually nicer for the programmer to actually see which value is assigned vs. having to look at other code to figure out what it'll be reset to.

        That's not to say, however, that there aren't times when *INZSR is a good choice. For example, when using the cycle, it's great. Or when you really need to do some complex calcs to get an initial value and don't want to have to repeat them, then *INZSR and RESET work well. In my expeirence, this is very rare, but I certainly wouldn't shy away from them if the situation arises.

        Comment


        • #5
          Personally, I don't do any logic cycle programming, but I make extensive use of *INZSR. It's habit mostly. The only practical difference I can see would be in the event of an error. A getin (G) response will resume at the beginning of the C-specs (are they still C-specs when there's no longer the "C"?). If your setup code is at the top, you may have issues with that.

          Comment


          • #6
            Well, if your program fails with an error, and you tell it to continue at *GETIN, then you're going to restart the program from the top, not where you left off. Unless you're using the cycle, that basically means "start my whole program over again". And, if you want to start it over again, wouldn't you also want it to reinitialize?

            Comment


            • #7
              Originally posted by Scott Klement View Post
              Well, if your program fails with an error, and you tell it to continue at *GETIN, then you're going to restart the program from the top, not where you left off. Unless you're using the cycle, that basically means "start my whole program over again". And, if you want to start it over again, wouldn't you also want it to reinitialize?
              Let's say your mainline looks like this.
              Code:
              Read MyFile;
              Dow not %eof(MyFile);
                //  do stuff
                Read MyFile;
              Enddo;
              Close MyFile;
              Return;
              A *GETIN would read the next row and continue processing. That's closer to a resume than a start-over. In my mind a start-over would be if MyFile started with the first row again.

              Comment


              • jtaylor___
                jtaylor___ commented
                Editing a comment
                For a start-over, I'd cancel back to the calling CLLE and take a retry there.

            • #8
              Yeah, I could see that working if your program is really simple. Since you don't know where it failed, this does open the chance that some of the processing was completed prior to the crash, and some was not, so moving on to the next row would not necessarily be safe.

              As I said in an earlier reply, I could see myself using *INZSR under the right circumstances. But, I find they don't come up very often.

              Comment


              • #9
                A lot of excellent opinions here....

                I believe that some form of *INZSR routine is useful in situations where a program has to do something like getting last week's Sunday through Saturday dates to select a subset of records (or some other sort of subset, like all employees from a certain department, etc., etc., etc.). I tend to agree that an *INZSR routine is not really useful in all situations, however, it is nice to know that there is an *INZSR routine available should it be needed.

                Like any other tool in your own programming toolbox, I'd think that however you use a particular tool (in this case, some form of an *INZSR routine), as long as you use it consistently and in an orderly manner, you'll find you will have less frustration in the long term. Putting an *INZSR routine into a program "just because you can" may create confusion to another programmer (or even yourself) should the program need to be modified at some distant future date and time.

                Best Regards and Good Luck!
                Fred Williams

                Comment


                • #10
                  The difference between *INZSR and a DIY init routine aren't great (*GETIN was the only example I could come up with). If you don't have the RPG cycle (e.g. NoMain *PGM, or a *SRVPGM), *INZSR isn't an option.

                  Like I said, I make extensive use of *INZSR but it's mostly habit. In most cases, I could just as easily put the code at the top of the mainline.

                  Comment


                  • Whitecat27
                    Whitecat27 commented
                    Editing a comment
                    JTaylor,

                    I agree that if you have put some form of *INZSR (DIY or no) into your established method of doing things... that this is a good idea. Your method of doing that is one of the basic methods I learned way back in my noobish SYS/34 programming days. I'm sure that you can understand my original confusion when presented with a 122 key NASA style of keyboard back in those days.

                    However, with our current methods available, and everything that is available to us today... can be both beneficial, or a pain in the butt, depending on how such a thing is applied to our programming efforts.

                    When I first started programming back in the dinosaur age, a "First" subroutine was mandatory for the shop I worked at, as IBM never let us experts use *INZSR... so my "First" subroutine was included in every program I wrote, even if all it did was SETON *IN99. With today's programming on our favorite machine, this kind of thinking is not always used, or even necessary.

                    With the *INZSR not really affecting performance (unless it does some extensive and intense pre-processing for the program)... I can agree with Scott's opinion on how he writes about where is to be used.

                • #11
                  When I started (late in the AS/400 days), initialization I saw was typically like this (forgive my bad spacing):
                  Code:
                  N01     OPEN   MYFILE
                  ...
                  N01     SETON     01
                  I'd guess that using NoMain would be considered ideal these days, so *INZSR wouldn't be an option. NoMain would be considered a lunatic fringe idea here, so I continue to use *INZSR without the logic cycle.

                  Comment


                  • #12
                    I can probably count on my fingers the times I've used *INZSR when writing a program. I typically like seeing the logic for everything - if I need to do an initialization at the beginning I'll either do it there or call a subroutine/subprocedure and call it. That way the entire logic is laid out - no need to see if an *INZSR routine is there.... but this is personal preference.

                    Comment

                    Working...
                    X