RPG/dds question - CPF4737

[pagenbeast]

Hello All,

I'm having issue where a user is periodically receiving the error message CPF4737 (OUTPUT FILE file name IN LIBRARY library ON PROGRAM DEVICE device NOT DONE). This is being received on an EXFMT opcode in an RPGLE program. Note...the display file does use the INVITE keyword on a different display record other than what the EXFMT is attempting to display, and is conditioned. When I look at the values in debug, the invite indicator is off.

Not sure if error is due to user pressing a certain key too quickly for program/display file to handle??

Any ideas is appreciated.

Thanks,

Pagen

[MichaelCatalani]

Re: RPG/dds question - CPF4737

I've fixed this condition before back in the 90's, so I'm a little fuzzy on what I did. I remember conditioning the filel i/o with an error indicator. I cant remember what I did beyond that to make it work, but basically if the error indicator was on, I retried the operation. I may have split the exfmt into a read and a write, so if there was an error during the read, I would simply retry the read, and if there was an error on the write, to retry the write. I think what was happening is that there would be a condition of where the network would blip, causing the read part of the exfmt not to work, which would cause a hard error on the write. So by separating the exfmt into a read and a write, I could error condition on both, and retry the failing operation, which would keep the hard error on the write from ocurring.

[pagenbeast]

Re: RPG/dds question - CPF4737

Thanks Michael. I was able to re-create the issue (user was pressing a key on the invited record before another screen program is displayed, ensuring data was added to the display data queue but the main program wasn't processing the queue entry, until returning from another program and attempting to display the main program's display record) and implemented a fix which was to perform a READ on the display format that I was using the invite keyword for (when the error was received). This seems to fix the issue.

Thanks again.

Pag

I've fixed this condition before back in the 90's, so I'm a little fuzzy on what I did. I remember conditioning the filel i/o with an error indicator. I cant remember what I did beyond that to make it work, but basically if the error indicator was on, I retried the operation. I may have split the exfmt into a read and a write, so if there was an error during the read, I would simply retry the read, and if there was an error on the write, to retry the write. I think what was happening is that there would be a condition of where the network would blip, causing the read part of the exfmt not to work, which would cause a hard error on the write. So by separating the exfmt into a read and a write, I could error condition on both, and retry the failing operation, which would keep the hard error on the write from ocurring.