Conference iosg::all-in-1_v30

613.0. "Menu Stack Exceeded with Multiple Menu Calls" by SLBLUZ::LEWIS () Thu Apr 30 1992 20:26

    I am placing this note in the conference in order to prevent others
    from going through the de-bugging headache I have had with this
    problem.  I would also like a reply to my question at the end, just for
    my own curiosity.

    I have a customer who is executing a UDP (customer written) which is
    failing on the 49th execution during the same ALL-IN-1 session.  The
    UDP calls the MAIN menu, then the WP menu, selects a document, invokes
    the editor, goes to the bottom, executes a GOLD G on the scratch pad,
    performs some editing, exits the document, deletes the scratch pad, and
    then creates a session on an IBM system using an SNA gateway to
    download info. with the print screen function to the Scratch Pad.  The
    UDP is then invoked again, multiple times.

    When the UDP fails, the user is returned to the WP menu from the GOLD G
    menu, instead of the edit session.  This causes all of the "editing"
    to be performed on the WP screen, instead of within the document.  The
    UDP can not be invoked again.

    Note that the size of the scratch pad document being included has a 
    direct effect on the number of times that this UDP can be executed.  The
    UDP fails at 49 executions with a Scratch Pad containing 25 lines of
    text (size of file after screen dump from IBM system).  If the scratch
    pad is bigger, it fails sooner; if smaller, it fails with 49+
    executions.

    Also note that if the user exits from ALL-IN-1, this problem clears
    itself.
    
    I have a trace of both a good and bad session.  On both traces, I
    notice that the menu stack has 22 WP menus (I assume this is a limit of
    TRACEARG).  If we use the OA$MENU_SHOW_STACK function, we see 49 levels. 
    This is the result of invoking the WP menu from the SPMENU, which is an
    overlay.  In other words, each time the MAIN and WP menus are called
    from SPMENU, a new menu level is created, and no "unwind" is performed.

    The fix to my problem was to use an Exit Screen (an {ADV} in the UDP)
    after the function accessing the IBM session was completed.  I suppose
    an "UNWIND" function would have been appropriate, too.  To make a long
    story short, make sure you are not inadvertently creating new menu
    levels by calling another menu from an overlay.  Sounds simple, but it
    took a while to arrive at the answer due to the other functions that were 
    going on.
    
    My question is this:  What affects the size of the menu stack?  Does
    ALL-IN-1 limit the amount of virtual memory for the stack?  As
    each WP menu is added, it is given a new (and higher) address.  Is
    there a point at which the combination of the scratch pad, buffers,
    DSAB stack, etc. exceeds the size/space allocated by ALL-IN-1?  It did
    not appear that UAF quotas affected this scenario.  In fact, I was able
    to duplicate/fix this problem on my system here at Digital, without the
    IBM stuff, and with different quotas set.

    (Running VMS V5.5/ALL-IN-1 V2.4)


    Thanks,
    Chris L.