philpl1jb Jul 26, 2012   3:10 AM GMT

Don't know if this would help, but it always seems like it should. OVRDBF FRCRATIO Specifies the number of insert, delete, or update operations that can occur on records before they are forced into auxiliary (permanent) storage. More information on this parameter is in commonly used parameters. More information on journal management is in the Backup and Recovery book. This parameter overrides the force-write ratio specified in the database file, in the program, or in other previously issued OVRDBF commands. *NONE: There is no force write ratio; the system determines when the records are written to auxiliary storage. number-of-write-operations-before-force: Specify the number of operations. If a physical file associated with this database file is journaled, specify a larger force-write ratio.   Phil

54,090 pointsBadges:

philpl1jb Jul 26, 2012   3:25 AM GMT

odd, I posted a discussion item that seems to have been sucked off the page by dark energy! Well I think you might find a solution in OVRDBF FRCRATIO Records to force a write Integer, *NONE Optional

54,090 pointsBadges:

TomLiotta Jul 26, 2012   4:46 AM GMT

...program B which checks the record availablity in the file FIL1.   What kind of file is FIL1 -- PF or LF? Is FIL! keyed? How does Program B "check the record availablity"?   Tom

125,585 pointsBadges:

BigKat Jul 26, 2012   11:30 AM GMT

or in your program after theWRITE FIL1FMT; you can code an FEOD(N) FIL1;

9,110 pointsBadges:

NickHutcheson1 Jul 26, 2012   4:30 PM GMT

Trigger on Fil1 - when records are written to the file, pgm B does whatever.More information may help us help you.

1,485 pointsBadges:

frmdeva Jul 26, 2012   7:26 PM GMT

The file FIL1 is a PF and there is no Key on it. Durng debug mode, I have checked the file WRITE operation completed with out any error and in another session, I tried to SQL it but the query doesn't display record. If I come out of the program (mean to say *INLR = *ON), then I can able to see the record which was written earlier. So records are written in the file when program runs but able to see the reocrd only end of the program. In my case, I declared the file in OUTPUT in the program which ends when they do IPL.  If I change the declarartion from OUTPUT to Input with Record addition, then I can able to see the records when the program runs too. Is it the behaviour of output mode or something I am doing wrong in compilation? Thanks for all your response!!!

365 pointsBadges:

frmdeva Jul 26, 2012   9:50 PM GMT

I am providing more info here, Currently we are having V6R1M0 version. So I took the file which was compiled with V5R4M0 version and declared in the same program with output mode. When I checked the data during the program runs, I can able to fetch the data and also able to SQL it. Then I took the same DDS and compiled with recent version V6R1M0 and compiled the same RPGLE program, I couldn't see the record after it is written into the file when program runs. I can able to  see the written records only after ending the program. Please help me on this very strange scenario.

365 pointsBadges:

TomLiotta Jul 26, 2012   10:00 PM GMT

Is the file journaled? Is any session that is using the file running under commitment control? What options are specified on the SQL statement?   Tom

125,585 pointsBadges:

philpl1jb Jul 27, 2012   12:03 AM GMT

On a write, RPG doesn't necessarily send the update immediately to db2 unless the file demands every record, ie (unique key, key constraint, certain setting on the file, certain setting on the override) or the program forces it.      The program loads an output buffer and sends multiple records to the db when the buffer is full or the program ends with *INLR on.   So you recompiled the database..did you use all the parameter settings that it had previously?  And you changed to 6.1 which might change the buffer size/logic.    You have four options.  Change parameters on the PF to force writes.  Apply an override to force writes, change the rpg code F-spec to Insert-Add, add a c-spec after the write to force the write.  \   We always try to confuse, but don't alway succeed. Phil

54,090 pointsBadges:

frmdeva Jul 27, 2012   8:49 PM GMT

Hi All, thanks for all your reponse. Resolved the issue by following ways. 1. Compiling the PF with FRCRATIO as 1 2. declared the file  in output mode along with BLOCK(*NO) Special Thanks to Phil and Tom  

365 pointsBadges:

TMACDB2COE Sep 20, 2012   7:03 PM GMT

You do NOT need to force the change to auxiliary to have it be visible by other jobs. You do need to it get flushed out of your program buffer into the file or table to be available to be accessed by others. Setting force write ratio in the file is the wrong way to solve this problem, especially on the file since now every time the DB does a change we synchronously write that change. You should turn off blocked writes at the program level if you want the row immediately visible by others. 

10 pointsBadges:

BigKat Sep 21, 2012   5:18 PM GMT

if you want to use FRCRATIO(1), use it as an OVRDBF parameter in a wrapper CL program for your job.  FRCRATIO(1) compiled on the file itself will SEVERELY impact the performance of CPYF's, restores, and all the other things you might need to do when staging data for testing

9,110 pointsBadges:

TomLiotta Sep 21, 2012   8:25 PM GMT

As of yet, we don't know enough to say whether FRCRATIO() on the file or in an override or some different approach is better. This file might simply be one record per batch number or it might be all records for a batch with any numbers of records possible. We don't know processing requirements. We don't have a clue why multiple programs are adding AND deleting from this file nor anything else useful. The OP is not giving us information we can use to give reliably appropriate responses. -- Tom

125,585 pointsBadges:

TomLiotta Sep 21, 2012   8:32 PM GMT

Ignore most of that last comment of mine in this thread. It was confused by a different thread. -- Tom

125,585 pointsBadges: