Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Call/Parm

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

  • Call/Parm

    In the s/36 environment, when I call a program from a screen program, the second program doesn't run. It returns to the first program with the LR indicator on from the called pgm. If I call a screen pgm from a non-screen program, it works just fine. On the s/36, these same call/parms work properly. Any suggestions?

  • #2
    Call/Parm

    If your called program returned with *INLR "on", then the program ran. It just did not do what you expected! Without knowing anything more than you stated, it sounds as if there is a problem with the values of your parameters that are being passed to the called program. Can we get a better description of what these parameters are, and what the values are, and how they are being passed? Dave

    Comment


    • #3
      Call/Parm

      My calling program asks the user to enter an invoice #. I use the invoice # as the Parm, and the called program is supposed to display the detail for that particular invoice. If I create a simple program where I use the same call, but just plug in an invoice number (no user involvement), the called program works and displays the proper screen. If I use my original program (where the user enters invoice #), and my called program is not a display, but just a report, it also returns with LR on and doesn't print the report. To summarize, if the calling program uses a display, the called program whether it uses a display or not, returns with LR on. If the calling program does not use a display, the called program works correctly. This is only in the s/36 environment of the as/400. It works just great on the s/36.

      Comment


      • #4
        Call/Parm

        Does the called program look for numerics. This could potentially be a problem. Here's one idea, there are many others: Have the calling and called programs send and receive all values as character values, as opposed to numerics. Move the value to a numeric field within the program. In this fashion, you can't get into a "packed" syndrome. You could also run the called program in debug mode, to determine what the values of the fields are, as parameters are passed to the program. Dave

        Comment


        • #5
          Call/Parm

          Tried changing my parm from numeric to alpha - still didn't work. Tried the debug in the called program. Weird thing, I get no output at all. And yes, it is set up correctly.

          Comment


          • #6
            Call/Parm

            At this point, I would need to see code snippets to get a better idea of what is going on. Perhaps someone else following the thread could chime in. Dave

            Comment


            • #7
              Call/Parm

              Linda, can you post the values of the parameters in the calling program just before the call (use DSPPGMVAR OUTFMT(*HEX)), and the values of the parameters in the called program just after the call (ADDBKP '/1'). Also can you post the definitions of the parameters in the calling and called programs from the cross-reference section of the listing. If you could display the parameters for the called program in both the good and bad cases, that would be interesting too. Barbara Morris

              Comment

              Working...
              X