RM/Panels pgm calling other RM/Panels pgm 1

[razalas]

Anybody out there working w/ RM/Panels experiencing any issues with RM/Panels programs calling other RM/Panels programs?

Working on a home-grown order processing app built on RM/Cobol and RM/Panels running on SCO Unix 5.0.6 environment. Recent changes have certain high-use Panels programs calling other high-use panels programs directly. When the panels-to-panels calling sequence is 1 deep, we are ok. But when second level programs call multiple third level panels programs, we start getting data reference 107 errors in RUNPAN2 (RM/Panels panels manager program).

Official line from Liant is to regenerate all the working storage definitions of panels and recompile all the programs. We've tried that but we are still getting the same error. I am hoping somebody here may have some experience with RM/Panels that might be helpful. "Code what you mean,
and mean what you code!
But by all means post your code!"

Razalas

 

[k5tm]

Are you obeying the rules presented in Appendix B of the RM/Panels manual? Normally there should exist only one physical RMP--PARAMETERS, which should be used by all the programs in your run unit. Tom Morrison

 

[razalas]

No, I guess we are not. Each of the programs in the sequence allocates its own copy of RMP--PARAMETERS in local working storage. I will try changing that to see if it helps.

It seems odd that the state of the last panel displayed would affect the display of subsequent panels downstream. In fact, we are generally "hiding" the last panel before calling the next program in the sequence. And in fact, the error occurs after returning from the called program(s) when we are attempting to redisplay the "hidden" panel.

Thanks for the suggestion. I will let you know if it helps. "Code what you mean,
and mean what you code!
But by all means post your code!"

Razalas

 

[razalas]

I tried changing the all of the programs in the calling sequence to share the same copy of RMP--PARAMETERS passed down through linkage from the top level program, but I am still getting the same error from the same line #.

Of course, it's possible that the error is now due to a problem with sharing the "state" of panels across the various programs, but I would tend to discount that possibility as I would expect to get a different error if that were the case.

Any other thoughts or suggestions would be most welcome. "Code what you mean,
and mean what you code!
But by all means post your code!"

Razalas

 

[k5tm]

Can you reduce this to a simple test case involving just the panels in question (i.e. no other program logic) which still causes the 107 error, then email it to Liant support. Let me know... Tom Morrison

 

[razalas]

Tom,

I have tried paring down the programs to minimal code that will still result in the same error. But this is rather difficult due to the complexity of the programs. So instead I've tried creating minimal programs from scratch that will recreate the problem.

Unfortunately, I am unable to recreate the problem using this minimalist approach. That would seem to indicate that the problem is somehow related to the complicated logic of the original programs or perhaps to some kind of runtime storage limits, although I am more inclined to expect the former rather than the latter. If I manage to recreate the problem with the minimal program, I will certainly forward them to Liant support.


All of which brings me back to my original request. I feel that we are likely violating some GAPP associated with RM/Panels, but am having a hard time spotting it. These programs are not doing any esoteric Panels stuff. They pretty much stick to the following pattern:

PERFORM RMP--CAF-panel-name
PERFORM RMP--IAF-panel-name
load fields on the panel
SET RMP--SHOW-FIELDS TO TRUE
PERFORM RMP--DP-panel-name
PERFORM WITH TEST AFTER
    UNTIL terminating condition is met
        PERFORM RMP--DAF-panel-name
        MOVE "field-name" TO RMP--NEXT-FIELD
        PERFORM RMP--EE-panel-name
        EVALUATE TRUE
            WHEN condition-1
                do condition 1 stuff
            WHEN Fxx-KEY
                CALL RMP--RUNTIME USING RMP--E-HDP
                                        RMP--PARAMETERS
                                        panel-name-WS
                CALL new-program USING parm-list
                PERFORM RMP--DP-panel-name
            ....
        END-EVALUATE
END-PERFORM
PERFORM RMP--RP-panel-name
GOBACK

One of the programs loops on an accept (RMP--AF-) for particular fields rather than using the execute event loop structure. The only other thing being done from a Panels perspective is some enabling (RMP--EFI-) and disabling (RMP--DFI-) of fields for input and changing of display attributes (RMP--SFA-). There is no duplicate use of the same panels libraries by multiple programs in the calling chain, no sharing of panels working storage between programs, no dynamic creation/modification of panels, no modeless operation, no use of DTF.

If anyone has any helpful hints regarding RM/Panels, any advice would be welcome. In the meantime, I guess I'm stuck picking apart these programs piece by piece till I can find some cause and effect relationship. "Code what you mean,
and mean what you code!
But by all means post your code!"

Razalas

 

[k5tm]

Razalas,

You wrote:
Unfortunately, I am unable to recreate the problem using this minimalist approach. That would seem to indicate that the problem is somehow related to the complicated logic of the original programs or perhaps to some kind of runtime storage limits, although I am more inclined to expect the former rather than the latter.

I agree; I strongly doubt this has to do with storage limits. '107' errors are specific to reference modification, which RM/Panels is using internally to move things around. This fact is probably what led the support group to suggest a regenerate/recompile, suspecting that a field had changed size.

In your 3-level architecture, do you ever get 107 on the first level-3 program? Are the level-3 programs all independent of each other? Tom Morrison

 

[razalas]

Tom,

no, the 107 error always occurs near the top of the chain (depending upon the depth and breadth of the chain), but never in any of the bottom most leaves of the tree (sorry about mixing metaphors). I understand what you are saying about ref. mod. but what is so darn perplexing is that there is no apparent connection between the working storage definitions of the panels in all of the programs. At least not thru linkage, unless Panels has some way of magically connecting the various programs that are calling it.

Each of the programs are basically independent displays of customer data that communicate by passing either a simple customer number or a copy of the customer record thru linkage. "Code what you mean,
and mean what you code!
But by all means post your code!"

Razalas

 

[k5tm]

Probably need to take this off-forum.

My email is t.morrison at the obvious domain.com (if in doubt, see my profile). Tom Morrison

 

[razalas]

Tom,

very kind of you to offer to take this elsewhere. E-mail will be easier but for now I don't feel that I have any additional clues to offer. I'll drop you a line. If you have any further thoughts, they would be most welcome.

In the meantime I am thinking to knock together a web page where I can post the full source code to this problem for easier access and reference. I'll let you know, when its available. Web pages are not area, so it'll be rough, but I should be able to cobble something together.

D.Salazar "Code what you mean,
and mean what you code!
But by all means post your code!"

Razalas

 

[k5tm]

Problem resolved. Tom Morrison

 

[razalas]

Tom here's a star for helping me resolve my problem.

Much thanks to Tom & support team at Liant for their help. "Code what you mean,
and mean what you code!
But by all means post your code!"

Razalas

 

[fredericofonseca]

Hi Tom & Razalas,

Can you clarify what was the problem and/or the solution as this may happen to others?

Frederico

 

[k5tm]

Hi, Frederico, nice to 'see' you here on Tek-Tips.

The problem was resolved by switching from using the (somewhat deprecated) Hide Panel function in favor of the almost identical Remove Panel function. Razalas was at first concerned about this change, due to a lot of caution in the published manual, but in fact the change was almost totally without problem.

Tom Morrison

 

[on5ex]

Most interesting thread for a RM/Panels user as myself. Tnx.
Johan

 

[k5tm]

Johan, OM,

73!

Tom Morrison