sponsored links

Collapse

Announcement

Collapse
No announcement yet.

Sndpgmmsg

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

  • Sndpgmmsg

    Good morning all,
    I have tried everything I could think of; various combinations of *TOPGMQ & *MSGTYPE, used message id CPF9898, created my own message and I simply cannot get a program message to display on line 24. It shows instead in the job log only!

    IE:
    A menu option is an interactive program. At initialization, a call to another program determines if a user has authority to run the program (in-house authority file consisting of a pgm name, user name, and a field: y/n). If the field is n, that second program calls a third program that is supposed to display a message on line 24 of the menu screen indicating that the user doesn't have authority to the menu option program - this doesn't happen.

    As I said, I've tried all combinations and all I can get is a full screen message when I use *INFO. Never has it appeared on line 24.

    Did I slip into the twilight zone....
    Does it have something to do with the progression of calls?

    Any ideas would be greatly appreciated.
    Mike.
    Everyday's a school day, what grade are you in?

  • #2
    Do you have a Message Subfile in your DSPF dds?

    If so, do you have SFLPGMQ defined in your DSPF dds?

    Are you writing out the Message Subfile Control record before displaying your screen?

    Walt

    Comment


    • #3
      Here's an MC Press Online article about it: https://www.mcpressonline.com/it-inf...ges-on-line-24

      (I haven't tried exactly what this article says, but I recall that MSGTYPE(*STATUS) and TOPGMQ(*EXT) are necessary.

      Comment


      • #4
        A status message won't appear in the joblog, they are for informational messages. This may be what you are after however, if you want the message to be added to the joblog and seen on the screen, you need to ensure you are sending the message to the correct program queue.
        Also depending on how your menu is created, whether it's via something like GO <menu name> or a program is displaying it, this will determine where you send the message.

        Comment


        • #5
          Gentlemen,
          I can (sometimes) get a *COMP message with *EXT to show on line 24, but it's rare.

          There is no sub file or message sub file involved.

          I don't care if the message goes to the job log - now, that's the only place i see the message while debugging to see if the message was sent at all. I want it to show on line 24 so the users stop telling everyone around them "his programs stink - they don't work" when it's really because they don't have permission to run the menu option (program) but they don't know it because they don't get the message on line 24....
          Everyday's a school day, what grade are you in?

          Comment


          • #6
            To summarize the article in the link that Barbara provided, since you have no message subfile in the menu program the easiest way to display a message on line 24 is to send a status message, something like SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA('Not authorized to program') TOPGMQ(*EXT) MSGTYPE(*STATUS). That message will remain on the screen until another status message is sent.

            Comment


            • #7
              Originally posted by Brian Rusch View Post
              To summarize the article in the link that Barbara provided, since you have no message subfile in the menu program the easiest way to display a message on line 24 is to send a status message, something like SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA('Not authorized to program') TOPGMQ(*EXT) MSGTYPE(*STATUS). That message will remain on the screen until another status message is sent.
              I have no idea why some of you think there is a sub file involved. I never said anything about a sub file.
              I created a menu using STRSDA option 2.
              Everyday's a school day, what grade are you in?

              Comment


              • #8
                I'm not sure why you thought that my reply indicated there was a message subfile involved because I said "since you have NO message subfile in the menu program". That being said, if you're using an SDA generated menu, then another alternative to sending a status message would be to send a program message to the previous message queue of the program that the menu option calls. The command would look like:

                SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA('Not authorized to program') TOPGMQ(*PRV (&CALLER)) MSGTYPE(*INFO)

                I'm assuming that the program name that the menu option calls is being passed as a parameter to the second (authority checking) program, but it also needs to be passed to the third (send message) program (which in the above command would be contained in the &CALLER variable).

                Comment


                • #9
                  Originally posted by Brian Rusch View Post
                  I'm not sure why you thought that my reply indicated there was a message subfile involved because I said "since you have NO message subfile in the menu program". That being said, if you're using an SDA generated menu, then another alternative to sending a status message would be to send a program message to the previous message queue of the program that the menu option calls. The command would look like:

                  SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA('Not authorized to program') TOPGMQ(*PRV (&CALLER)) MSGTYPE(*INFO)

                  I'm assuming that the program name that the menu option calls is being passed as a parameter to the second (authority checking) program, but it also needs to be passed to the third (send message) program (which in the above command would be contained in the &CALLER variable).
                  Brian,
                  wegrace referenced a message sub file and in your post, I misread it in my haste.

                  Mike.
                  Everyday's a school day, what grade are you in?

                  Comment


                  • #10
                    *STATUS is to show a message while the program is running.
                    *COMP is to show a normal (non-error) message when the program ends.
                    *ESCAPE is to show a failure (error) message when the program ends.

                    If you send one of these messages to the program stack level prior to your program, it should show up at the appropriate time. So if you're called from a menu, it will show at the bottom of the menu.

                    If its only in the job log, to me that indicates that you sent it to the wrong stack level.

                    Comment


                    • #11
                      Originally posted by Scott Klement View Post
                      *STATUS is to show a message while the program is running.
                      *COMP is to show a normal (non-error) message when the program ends.
                      *ESCAPE is to show a failure (error) message when the program ends.

                      If you send one of these messages to the program stack level prior to your program, it should show up at the appropriate time. So if you're called from a menu, it will show at the bottom of the menu.

                      If its only in the job log, to me that indicates that you sent it to the wrong stack level.
                      Scott,

                      I initially tried...
                      - *EXT with *COMP and that works sometimes but not always (puzzling)
                      - I've tried *EXT with ESCAPE and that didn't work
                      - I've also tried *EXT with *INFO and got a full screen message which, is just too overpowering for a user.

                      That's why I asked if this behavior was due to the depth of the call stack but it has not been addressed.

                      I just tried the *PRV *INFO combination and that gave me the desired result - on line 24.

                      I assumed from the command help that *EXT was used to communicate with the external user but it seems I'm either using it incorrectly or setup the command wrong.

                      Thanks,
                      Mike
                      Everyday's a school day, what grade are you in?

                      Comment


                      • #12
                        One caveate to sending an *ESCAPE message is that if it is sent to the previous program in the call stack, then the execution of the program sending the message immediately stops (it's like coding a RETURN after the SNDPGMMSG). If it's sent to a different program in the call stack, then execution of that program and all programs in the stack after the program that the escape message is sent to are also immediately terminated. So in redvan's scenario, if the escape message was sent to the menu progam, then the third (send message) program, second (check authority) program, and the menu option program would all be terminated and control would return to the menu program.

                        Comment


                        • #13
                          Originally posted by redvan View Post

                          I have no idea why some of you think there is a sub file involved. I never said anything about a sub file.
                          I created a menu using STRSDA option 2.
                          Redvan,

                          It was not indicated in the original post that IBM menus were being used.

                          And, IBM menus have not been used in any shop at which I have worked in the last 25 years.

                          Therefore I inferred that the system on which you are working had created their own custom menu system, as has been my experience.

                          And, a custom menu system with its own display files would necessitate a message subfile in order to easily display messages.

                          Just to be clear, message subfiles are different than regular subfiles, so I'm not sure why you keep referring to regular subfiles.


                          Walt

                          Comment

                          sponsored links

                          Collapse

                          Working...
                          X