protect a screen when called from another pgm

I have an app, when the user presses F2 a call is sent to another pgm and that pgm's screen is displayed.  The problem is that the data on the screen can be maintained and I want to protect  the data.

1. I can put indicators on the fields and test for pgm "A" calling pgm "B" (in pgm "B"), and if so turn the indicator on and use the protect keyword.  My preference is to not do this.  I am looking for the easiest way.

Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

Mind_nlConnect With a Mentor Commented:
You could add a parameter in pgmB ( value 2 for edit / 5 for display) and change the call in pgmA to include parameter 5. If you have pgmB only check if the parameter is 5(display) and let it run in edit mode for all other values of the parameter you don't have to change any other programs calling pgmB now.
I'm pretty sure you've essentially already listed the "easiest" way. If you don't change PGMB to display in an inquiry mode instead of maintenance mode, any alternatives are going to be significantly more difficult.

E.g., you _could_ create a sockets application which connected to the telnet server, send appropriate sockets data to logon and call PGMB and then receive the telnet data stream back. (Or use native virtual terminal APIs for a similar effect.) From that, you could 'screen scrape' and display sanitized output back in PGMA, etc... but it seems a little ridiculous.
Hmmm... come to think of it, there is at least one potential way... Issue STRDBG making sure UPDPROD(*NO) is in effect and the files are in TYPE(*PROD) libraries. Then call PGMB. _If_ PGMB is written as needed and the data being changed is in files and the library hasn't already been opened, etc., you might get the effect you want. Issue ENDDBG after the call to PGMB completes.

Authority for STRDBG, etc., would probably have to be carried in the calling program.

Also note that if you're resigned to changing PGMB to switch between maintenance/inquiry mode based on an _additional_ parm, rather than overloading an existing parm for example, there might be significant problems for programs that are already calling PGMB.

To handle an additional _optional_ parm (assuming you aren't intending to track down and change everywhere PGMB is being called now), PGMB should be an ILE program or written in a language that can handle optional parms.

If PGMB can't reasonably handle an optional parm and you can't take the time to make it do so, you can use an external object instead of a parm. For example, you could create a data area in QTEMP and PGMB could check for its existence. If found, then switch to inquiry mode. Delete the data area after the call to PGMB. Or you _might_ be able to use a job switch -- if switch 1 is on, run in inquiry mode, otherwise normal maintenance mode. (Job switches might already be in use.)

Probably best is indeed to use an additional parm since it can be clearly documented and explained; but be aware that existing program calls to PGMB are at risk.

what I would do is as Mind_NL has stated, Tom is correct in pgm b parm list causing problems.

if you  need to check how many parms have been sent to the program, this is done via the program status data structure

IPSDS       SDS                                                      
I                                     *PARMS   PARM                  

or in le you can use the %parms Built in function


All Courses

From novice to tech pro — start learning today.