D3 and mvBase

I'm changing the UI of an app from a classic D3 character based UI to a Java Swing app using MVSP Java to talk to D3.

I've got a slight architectural problem I'm hoping someone might have some insight into.

All the character based programs include an unnamed common block which keeps file descriptors, screen and prompt info etc. All hotkeys can be defined to start a program, so if you are in any input field pressing a hotkey will start a new program and after that program finishes the screen is refreshed back to where you were. A unnamed common block works well, because when the hotkey program is executed, a level is pushed, and because the common block is unnamed, the pushed program gets it's own copy of common and can execute independently of the program that started the pushed program.

There a 2 issues: (1) a subroutine cannot declare an unnamed common if the calling program hasn't first, and (2) if you use named common, this is global for all pushed levels during a login session.

Using MVSP (1) is a problem because the MVSP main program running on D3 that responds to client requests obviously doesn't have an unnamed common block the same as my current app.
If I re-factor the D3 code to use a named common block, when I push a level, the pushed program will share the same common block as the root program, which will obviously screw up the open files and screen parameters held in common.

What I'd really like to do is be able to call a lot of the existing Basic programs from the current app from MVSP, which is clearly not possible now. The alternative is to have MVSP specific code which will obviously duplicate a bunch of functionality with the existing app, which is also clearly sub-optimal.

Wondering if anyone has any suggestions. I'm open to refactoring the existing code provided the bulk of the logic is maintained (this is code that has been running for 25 years, so is, touch wood,  reasonably bug free, and I don't want to refactor and unintentionally create new bugs).

Thanks.

------------------------------
Bryan Buchanan
------------------------------

Hello, Bryan. Brian here. Someone else ran into this issue a few years ago and I forgot what the resolution, if any, was. I'll get with Engineering to see what suggestions they may have.

------------------------------
Brian S. Cram
Principal Technical Support Engineer
Rocket Software
------------------------------

Original Message:
Sent: 10-28-2024 20:24
From: Bryan Buchanan
Subject: Named Common vs Global Common

I'm changing the UI of an app from a classic D3 character based UI to a Java Swing app using MVSP Java to talk to D3.

I've got a slight architectural problem I'm hoping someone might have some insight into.

All the character based programs include an unnamed common block which keeps file descriptors, screen and prompt info etc. All hotkeys can be defined to start a program, so if you are in any input field pressing a hotkey will start a new program and after that program finishes the screen is refreshed back to where you were. A unnamed common block works well, because when the hotkey program is executed, a level is pushed, and because the common block is unnamed, the pushed program gets it's own copy of common and can execute independently of the program that started the pushed program.

There a 2 issues: (1) a subroutine cannot declare an unnamed common if the calling program hasn't first, and (2) if you use named common, this is global for all pushed levels during a login session.

Using MVSP (1) is a problem because the MVSP main program running on D3 that responds to client requests obviously doesn't have an unnamed common block the same as my current app.
If I re-factor the D3 code to use a named common block, when I push a level, the pushed program will share the same common block as the root program, which will obviously screw up the open files and screen parameters held in common.

What I'd really like to do is be able to call a lot of the existing Basic programs from the current app from MVSP, which is clearly not possible now. The alternative is to have MVSP specific code which will obviously duplicate a bunch of functionality with the existing app, which is also clearly sub-optimal.

Wondering if anyone has any suggestions. I'm open to refactoring the existing code provided the bulk of the logic is maintained (this is code that has been running for 25 years, so is, touch wood,  reasonably bug free, and I don't want to refactor and unintentionally create new bugs).

Thanks.

------------------------------
Bryan Buchanan
------------------------------