How to Replace Display Files While They Are In Use

If you recompile a program while someone’s running it, it’s no big deal. The system moves the old object into library QRPLOBJ and the user never knows the difference. However, creating a display file is a different situation. You can’t replace a display while someone has a lock on it. Here’s a way to replace a display file, even while people are using it.

To illustrate, assume a high-level program, MYHLLPGM, that uses display file MYDSPF. Most likely MYHLLPGM would be written in RPG or maybe COBOL. A user takes a menu option that calls MYHLLPGM, and the system locks MYDSPF.

The trick is to make the program use its own copy of the display file. Here’s some CL code that shows how it’s done.

CHKOBJ     OBJ(QTEMP/MYDSPF) OBJTYPE(*FILE)
MONMSG     MSGID(CPF9801) EXEC(DO)
CRTDUPOBJ  OBJ(MYDSPF) FROMLIB(*LIBL) OBJTYPE(*FILE) +
             TOLIB(QTEMP)
ENDDO

OVRDBF     FILE(MYDSPF) TOFILE(QTEMP/MYDSPF)
CALL       PGM(MYHLLPGM)

The Check Object (CHKOBJ) command looks to see if there’s a copy of MYDSPF in QTEMP. If not, the Create Duplicate Object (CRTDUPOBJ) command creates one.

The Override with Display File (OVRDSPF) command causes the HLL program to use the display file in QTEMP, rather than the one in the production library.

Now you can recreate the production display file while people are using it.

You can have the CL program delete the display file after the program ends. I usually leave the file in QTEMP, since most days I don’t recreate the display file. If a user gets a level check on the display file after I’ve recreated it, I tell him to sign off and on again.

–R

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot