ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

When DSPLY doesn't display

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

  • When DSPLY doesn't display

    Hello.

    I've read all around, gone through IBM's site, and still cannot come up with the definitive answer as to why DSPLY sometimes doesn't display at the workstation for an interactive job.

    I'm using DSPLY with factor 1 only.

    I've read the following post but it doesn't have a definitive answer: http://www.code400.com/forum/forum/i...essage-problem

    I know it has something to do with the message queue and *EXT, but can't put my finger on it.

    Does anyone know?

    Thanks in advance,

    Mike

  • #2
    Originally posted by mlopez01 View Post
    ...sometimes doesn't display at the workstation for an interactive job.
    Can you define "sometimes"?

    AFAIK, it always 'displays', but it often happens too fast to see it. It doesn't 'display-and-wait-for-F-key', it just flashes the message and goes to the next program instruction. If you want it to linger, you need to specify a reply.

    However, when the program runs from being called from a PDM command line for example, the PDM command line program's display file is in control of the display and of handling messages sent to the display. The message can then stay until {Enter} is pressed. Depending on characteristics of the DSPF that is in control of message handling, the message display will either flash past as fast as all components can handle it or will stay until some valid F-key is pressed. (Or something closely related to all of that.)

    It's been too many years since I needed to know the details, so I'd need to check docs and probably do some experimenting for a reasonably definitive answer. This might be enough to spark memories/comments from someone with more current memory.
    Tom

    There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

    Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?

    Comment


    • #3
      Hi, Tom. Yes, it's been a long time for me too, and quite honestly I've never cared to know the reason. But I've been asked to pursue this.

      "Sometimes" means that the "Display Program Messages" screen doesn't always appear, e.g. calling the program using a CALL statement from the main menu. However, if I run STRPDM, wherein a new DSPF is opened, and then call the program the screen breaks and "Display Program Messages" shows. I then press Enter to continue.

      So I think you're on the right track when you describe PDM's command line program being in charge.

      Thanks for the feedback. I'm moving on!

      Mike

      Comment


      • #4
        Hi again, Tom. You're right, it does display (very quickly) but it doesn't suspend the program when called from the main menu's command line.

        So, according to DSPLY documentation, the dspf used to show the program messages at that point should have RSTDSP(*YES) specified.

        Interesting.

        Mike

        Comment


        • JonBoy
          JonBoy commented
          Editing a comment
          The screens used within PDM, which is where most folks not using RDi will spend their time, all have the required RSTDSP option - but command lines don't and neither do many other screens.

          I tend to code my DSPLYs with a result field of a single character so that it will always wait for a response. So:

          Dsply 'This is my message' ' ' Wait; // Where "Wait" is a one character field.

          Since displays are limited in length anyway, losing that one character doesn't make any difference. If doing a series of displays do the first set without the result field and add it just to the last one.

      • #5
        That sounds familiar. Again, I don't recall if it will actually "stick" if the next program actions bring DSPF activity. I haven't used DSPLY concurrently with a DSPF much ever, definitely not in a couple decades. Fortunately, CHGDSPF RSTDSP() can be done almost whenever needed if the attribute wasn't set appropriately at compile-time.
        Tom

        There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

        Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?

        Comment

        Working...
        X