ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

Recursive calling dilemma?

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

  • Recursive calling dilemma?

    Given that PGMA calls PGMB which calls PGMC which calls PGMD. If the user press F3 to exit PGMD, I want to re-display the subfile in PGMA. Is there a way to do this without stair stepping back from PGMD-->PGMC-->PGMB-->PGMA, perhaps having PGMD call PGMA recursively or some variation of that. PGMA and PGMC are CLLE programs, PGMB and PGMD are RPGLE programs. To complicate matters, we have a change management tool that does not handle sub procedures unless they are imbedded (don't get me started on the topic of our CM tool). IT seems that I saw a possible solution online that involved making PGMA actgrp(*CALLER) and PGMD actgrp(*NEW) and calling PGMA from PGMD. Obviously, I would have to make PGMA an RPGLE program.

    Would this work, or anyone with an idea that would work?


  • #2
    Originally posted by gregwga50 View Post
    Given that PGMA calls PGMB which calls PGMC which calls PGMD. If the user press F3 to exit PGMD, I want to re-display the subfile in PGMA. Is there a way to do this without stair stepping back from PGMD-->PGMC-->PGMB-->PGMA, perhaps having PGMD call PGMA recursively or some variation of that. PGMA and PGMC are CLLE programs, PGMB and PGMD are RPGLE programs.
    I don't understand why you don't want to exit back to PGMA. This sounds a lot simpler to me vs. calling PGMA recursively.

    Originally posted by gregwga50 View Post
    To complicate matters, we have a change management tool that does not handle sub procedures unless they are imbedded (don't get me started on the topic of our CM tool).
    I don't understand why you brought this up. How would having a non-embedded subprocedure help? As far as I can tell, this has nothing to do with the question.

    Originally posted by gregwga50 View Post
    IT seems that I saw a possible solution online that involved making PGMA actgrp(*CALLER) and PGMD actgrp(*NEW) and calling PGMA from PGMD. Obviously, I would have to make PGMA an RPGLE program.
    Seems to me, you'd want PGMA to be ACTGRP(*NEW), and PGMB, C, D would all be *CALLER. That way you can call PGMA recursively if you wish, and when it ends it'll clean up the other programs it called.

    Why does PGMA need to change to be an RPG program? I don't understand.

    Comment


    • #3
      Have you set the parameter RSTDSP (Restore display) to *YES for the display file for PGMA?

      Comment


      • #4
        Originally posted by Scott Klement View Post

        Why does PGMA need to change to be an RPG program? I don't understand.
        I will follow your suggestion, but PGMA is a CLLE program. Is there away to may it ACTGRP(*NEW)?

        Comment


        • Scott Klement
          Scott Klement commented
          Editing a comment
          Of course. Use CRTCLMOD and CRTPGM, on CRTPGM specifify ACTGRP(*NEW)

      • #5
        Originally posted by Scott Klement View Post

        I don't understand why you brought this up. How would having a non-embedded subprocedure help? As far as I can tell, this has nothing to do with the question.
        I read somewhere yesterday that you can perform recursive calls in sub procedures. Since our CM tool is limited as mentioned in my original post and PGMA is a CLLE program, this would not be an option.

        Comment


        • Scott Klement
          Scott Klement commented
          Editing a comment
          Ok, so are you saying you'll eliminate the program calls entirely and rewrite it so that you use subprocedures, instead? That would allow recursive calls, and if you kept the subprocedures in-line, it'd work with your CM tool. Though, as I said before, recursion isn't a good solution to begin with, exiting back to the start and redisplaying the subfile is a much better solution, so as long as you're rewriting the whole thing, why not fix the architectural problem?

          But, assuming you're stuck with the programs as-is, then being able to call subprocedures recursively doesn't help you.

      • #6
        I think I will just take the stair step back approach. I was just trying to avoid modifying PGMB and PGMC to keep track of which command key was pressed in PGMD

        Comment


        • #7
          I've decided to take the stair stepping backward from PGMD to get to PGMA approach. This has turned into and RPG problem now. Here's the problem. PGMB invokes PGMC via ATTN from a display in PGMB. PGMC calls PGMD. When I am finished with PGMD, I want to redisplay the screen in PGMA that started the whole process. I don't want to re-display the screen in PGMB that the ATTN key was executed in and then have to hit another key to ket back to PGMA. But when I exit PGMD it returns control to PGMC which returns control to PGMB at the EXFMT stmt the ATTN key was invoked at.

          So, how do I get the program to go back to PGMA without stopping along the way. Maybe stair stepping backward was the wrong choice of words

          Comment


          • #8
            One interesting bit of information that you might be able to make use of in this situation is that if you send an *ESCAPE message to a specific program up the call stack, then all programs after the target program are immediately terminated. So in your situation you would have PGMD send an *ESCAPE message to PGMA. In PGMA you would have to put a MONMSG right after the call to PGMB to keep PGMA from showing an error message. You might have to condition the sending of the escape message from PGMD if it can be called from other programs besides the one you described in your scenario.

            Code:
            In PGMA:
            CALL       PGM(PGMB)
            MONMSG     MSGID(CPF9898)
            
            In PGMD:
            SNDPGMMSG  MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA('Return +
                         to PGMA') TOPGMQ(*SAME (PGMA)) MSGTYPE(*ESCAPE)

            Comment

            Working...
            X