15 pts.
 Unable to override a PF member
Hi, I am trying to override a physical file using CL. The CL program is being called by a CBLLE program. In the CBLLE program, I want to process the overridden member.But,all the processing is going on the first member only.It looks like as soon as the CL program terminates DLTOVR gets executed automatically (though i am not sure). Please let me know how to get around this problem. Any help will be highly appreciated

Software/Hardware used:
ASKED: January 16, 2009  1:31 PM
UPDATED: October 22, 2011  1:25 AM

Answer Wiki:
Not a cobol guy but here's a thought - the Override must be executed before the open. The OVRDBF must also be at a previous call level (unless you specify otherwise on the OVRDBF command). The following will work :- PGM OVRDBF Youroverride details CALL YourProgram DLTOVR ENDPGM The following will NOT work PGM CALL Aprogram CALL YourProgram DLTOVR ENDPGM Where Aprogram runs the OVRDBF command. When the Aprogram program completes, the OVRDBF is removed, therefore it is not in effect for YourProgram. Regards, Martin Gilbert.
Last Wiki Answer Submitted:  January 16, 2009  2:58 pm  by  philpl1jb   44,630 pts.
All Answer Wiki Contributors:  philpl1jb   44,630 pts.
To see all answers submitted to the Answer Wiki: View Answer History.


Discuss This Question:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _


 

Martin
Thanks, you’re right for the OvrDbf might end with the call level.
To get it to work as described
1. File cannot be open when it’s issued
2. The COBOL program can call a CL to do the over ide
— the ovrdbf command needs the OVRSCOPE *JOB
Phil

 44,630 pts.

 

Alternatively, the CL program might be compiled as DFTACTGRP(*NO) ACTGRP(*CALLER) so that the override is in the same actvation group as the caller. That could avoid having the override affect other parts of the job that shouldn’t see it, i.e., parts that run in a different activation group.

Or the CL could be compiled only as a *MODULE. It could then be bound with the COBOL as a single *PGM object and called as a procedure.

The choice would depend on how the entire job is constructed and what behavior is needed.

Tom

 110,135 pts.