Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Write statements being queued instead of written?

Status
Not open for further replies.

Fooch

Programmer
Dec 19, 2005
63
0
0
US
I have a program that is pretty straight forward as far as my changes. As I am walking through it in debug and it goes over the "WRITE" line it completes it successfully and goes through the fields but it doesn't actually write the record(s) until I back completely out of the program...any idea why? It's driving me nuts. It's like the out file is locked. Or being queued.
 
As I am walking through it in debug and it goes over the "WRITE" line it completes it successfully and goes through the fields but it doesn't actually write the record(s) until I back completely out of the program
What type of file? Display file? Subfile within a display file? Printer file? IFS?

Depending on the type of file (and optionally how the file was created), the system may not appear to "write" when you tell it to.

Subfiles are a great example of this.

What is it that you're trying to accomplish?
 
Assuming you are talking about a disk file:

Either use the FEOD <filename> opcode immediately after the WRITE, or add the BLOCK(*NO) keyword to the F-spec for the file.

Tibi gratias agimus quod nihil fumas.

 
Yeah it is a Disk File. And I have never had this issue before I narrowed it down to something this companies menu system is doing. It must be releasing something to allow it to then write. So weird. But all I am trying to do is blindly write records into a data file. That's it. A simple F-spec and a write command...only two lines in the whole program reference the file.
 
When you enter debug, try Shift ATTN 3 14 (open files).

Is this program called directly from the menu (or command line), or is it called via another program?

Possibly, the data is being written to a different member in the file or a copy of the file in another library & then being "committed" or copied upon exiting the program.
 
No it is a new file that I created. I am the only program that references it. It is jsut a file to keep track of customer name changes. I have stepped through debug and watched the open files and it is opening the right file. The BLOCK(*NO) keyword worked though. So there legeacy stuff must somehow been blocking the file, I don't know how because it was brand new unless it is a generic kind of "lock all" thing. But that solution works for me, I wish I had the time to go back and find out the cause of the block because it's going to drive me crazy lol. Thanks guys.
 
RPG automatically blocks the file for you, in the name of efficiency and speed - but you can override it with BLOCK(*NO) (but things will likely run slower).

You have to be careful if your program needs to process a record you just wrote to disk. BLOCK(*NO) means that the record is written to disk immediately (and is available to be read and processed immediately), instead of waiting for the write cache to get full.

Tibi gratias agimus quod nihil fumas.

 
Also, if you are journalling the file, you might not see new records until COMMIT is processed (or pgm ends).
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top