Losing File Overrides

From: Tim Phinney To: All

I'm trying to replace a S/36 procedure with a CL program. I have a procedure FILES with all my file statements in it. I tried to run my new FILESCL program from the "calling" procedure but I get open errors. Do Override Database File (OVRDBF) statements stay in effect after the CL program ends?

I realize I'm leaving a lot out, so examine my example in 5. It appears to me that the OVR-DBFs "go away" when the CL ends.

I realize I'm leaving a lot out, so examine my example in Figure 5. It appears to me that the OVR-DBFs "go away" when the CL ends.

From: Ernie Malaga To: Tim Phinney

That's precisely what's happening. The OVRxxxF commands perform overrides which remain in effect until the current call level ends. This means that if you execute several OVRxxxF commands in a CL program which you CALL from program X, the overrides will go away as soon as the CL program ends and control returns to X.

From: Tim Phinney To: Ernie Malaga

I assume, then, that there's no solution? Is there a way to include source so all I have to do is change FILESCL and recompile each program which uses it?

From: Pete Hall To: Tim Phinney

There is a way. Instead of including a procedure with the file overrides in it, you need to establish the overrides in a program that calls the program that uses them. If program A uses the overrides and program B establishes them, then B must call A. It's just the reverse of the way it's usually done on the S/36.

From: Tim Phinney To: Pete Hall

I have three main programs that all use the same files. I wanted to be able to do the overrides once and have them in effect even if you get back to the menu.

From: Michael Catalani To: Tim Phinney

You can do this by putting your overrides in a CL program and calling that CL program as your initial sign-on program. This will keep the overrides in effect until the person signs off. I have done this before, so I know it works.

From: Tim Phinney To: Michael Catalani

I had considered a "startup" program, but in this case it wouldn't work. My users skip around between offices and three "systems" on my machine. What I wanted to do was have a DTAARA in QTEMP with the system name and office code. I was going to do the OVRs only when one of those two changed.

TechTalk: Losing File Overrides

Figure 5 The Case of File Overrides

 Top level procedure: // IF ?M0005?/S36 FILES // IF ?M0005?/AS400 CALL PGM(FILESCL) * // LOAD CUSUPD // RUN Procedure FILES: // FILE NAME-CUSTOMER,DISP-SHR,LABEL-CUMAS // FILE NAME-BRANCH,DISP-SHR,LABEL-X.BRAN . . . etc. CL program FILESCL: OVRDBF FILE(CUSTOMER) TOFILE(CUMAS) OVRDBF FILE(BRANCH) TOFILE(X.BRAN) ... etc.