Mysay - Achieving Smooth Integration of Mysay between Top-Level Execs and Called Execs

If you have a top-level Rexx which only puts out a line or two of output, you probably don't need to convert it!

Lower-level execs that MAY be called by mysay-converted execs WILL need conversion. If you don't convert them, their 'say's will wreck your display panel.

  1. TOP-level execs can call lower-level external execs and all of the mysay output WILL go nicely into the top-level scrolling panel. But it takes a little bit of work on your part ...

    To ensure multi-exec mysays work, do the following:

    1. Only the top-level exec should call mysay0 or mysay9.
      • If you allow a low-level exec to call mysay0, the "aboutme" blurb will be changed, and WORSE, since the mysay0 call initializes the store of mysay output and accepts the calling exec name (its only compulsory parameter), your store of mysay output DISAPPEARS along with any vital error messages that you just glimpsed but didn't have time to read.
      • So even IF your low-level exec calls mysay9 to review the outputs, you won't see those which were issued before by the calling exec. So calling mysay9 in a low-level exec should only be done when debugging, if at all.
      • If your low-level exec calls mysay9, you might be able to review some useful mysay output from THAT exec only, but everything that went before disappears. Then when it returns to the top level exec, that exec calls mysay9 and comes up with ... nothing. Not the way to impress your boss.
    2. If you (like me) write execs which do double duty as both top-level execs AND low-level execs in different circumstances, you will need to pass a flag to them to tell them whether they are top-level or not. If they detect that they ARE top-level, then they should call mysay0/mysay9, otherwise NOT. So for all such execs, you need to put an 'if' test around these two calls.

    Design Options for controlling the calling of mysay

    By default, every mysay call results in a display (of course)

    Consider the call rv=mysay(...) Mysay does not allow for its parameter values to turn off the display. It will display a line in panel 'scroller'.

    You COULD dig around in the code of mysay and perhaps find a way to do this (I have coded in mysay a flag called _quiet, but it doesn't always work, and there is the danger that once you turn _quiet on in a subroutine and it gets saved in the pool, it will still be turned on for later calls of mysay when you don't want that, and working execs suddenly stop producing any output.)

    You may wish to UTTERLY, TOTALLY suppress 'say' and therefore 'mysay' output from a low-level Rexx.

    The idea is, when the Rexx is run as a top-level Rexx, you display the output, but when run as a low-level Rexx, you are not interested to see any output.

    I prefer the following:

    Change all calls to external mysay into calls to an internal routine (let's call it dmysay):

    C 'rv=mysay(' 'rv=dmysay(' all

    I then insert a paragraph/routine somewhere inline called dmysay

    dmysay : procedure expose debug parse arg p1,p2,p3,p4,p5,p6,p7,p8,p9 if (debug = 0) then /* i.e. only display this if debug is set */ return 0 return mysay(p1,p2,p3,p4,p5,p6,p7,p8,p9)

    You may wish to CONDITIONALLY issue mysays.

    I have used variations of the above technique using a variable 'quiet' instead of 'debug'. I change rv=mysay to rv=cmysay everywhere and change the return statement to if (quiet) then return

    I change all calls to external mysay into calls to internal routine cmysay:

    C 'rv=mysay(' 'rv=cmysay(' all

    I then insert a paragraph/routine somewhere inline called cmysay

    cmysay : procedure expose quiet parse arg p1,p2,p3,p4,p5,p6,p7,p8,p9 if (quiet) then return 0 return mysay(p1,p2,p3,p4,p5,p6,p7,p8,p9)