File Issue (Declared in OUTPUT mode)

Hi All, A file (say FIL1) has been declared in outmode in a program A which is running continuously without ending and also writes the record in the file FIL1. There is an other program B which checks the record availablity in the file FIL1. But the problem is the problem A writes the record in FIL1 but not able to read the record in another program B . Is it possible to read the record only after ending the program A? Or do we have any other way to read the file without changing the file declaration in Program A?. All these programs are RPGLE.
Please advice me! Thanks in advance!

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy

Processing your response...

Discuss This Question: 14 &nbspReplies

There was an error processing your information. Please try again later.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy

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

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!!!

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.

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

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

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.

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

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

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy

Processing your reply...

Ask a Question

Free Guide: Managing storage for virtual environments

Complete a brief survey to get a complimentary 70-page whitepaper featuring the best methods and solutions for your virtual environment, as well as hypervisor-specific management advice from TechTarget experts. Don’t miss out on this exclusive content!

Share this item with your network:

To follow this tag...

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy