I have not written a subfile program in a while, but am having trouble when errors are encountered. As this is COBOL and the code can be lengthy to weed through on a forum, let me first spell out the scenario.
I have 32 records in a COBOL subfile, 11 per page. There is one input field per subfile record for the user to enter in a dollar amount.
I am performing an edit routine to look for 2 possible errors in data entry –
1) Entry must be a positive number
2) Entry must not be more than a variable value. The variable value is computed and stored as a hidden field for each subfile record.
I start reading the subfile at relative record number 1 and read until an error is encountered or until relative record number exceeds number of records in subfile.
When I am testing the first record in the subfile, all is well. It is when I enter an invalid dollar amount in subsequent subfile records that I get the CPF5011 error.
For example, if I enter an invalid dollar amount in the fifth record of the subfile –
The amount field for the fifth record is appropriately “reverse-imaged”, but there are 5 records in my message subfile at the bottom of the screen instead of one.
The first 4 errors seem to relate to the first 4 (unchanged) records of the subfile
CPF5011 Do change to subfile by GET for file XXX0166 in library TESTLIB.
CPF5011 Do change to subfile by GET for file XXX0166 in library TESTLIB.
CPF5011 Do change to subfile by GET for file XXX0166 in library TESTLIB.
CPF5011 Do change to subfile by GET for file XXX0166 in library TESTLIB.
then my expected error message is next –
“Amount exceeds xxxxx limit”
Cause text for CPF5011 reads, “Changes were not done before GET. Check the previous operation.”
Recovery text for CPF5011 reads, “Change the sequence of operations in program. Compile again. Try the command again.”
Is anyone familiar with CPF5011?

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: 6 &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

What do you mean when you say "I start reading the subfile at relative record number 1..."? That is, please show the COBOL READ statement that you use. Also, please show the statement that puts the subfile error indicator back out to a subfile record.
.
What does the SELECT statement look like for the subfile?
.
It might be difficult without seeing the logic of the code that does the subfile I/O. We don't need to see the validation code; that can be in a PERFORM subroutine. But the logic that loops through the subfile reading changed records (or all records) and rewriting subfile error indicators might be necessary.
.
Tom

To paraphrase Scarlett O'Hara, Today IS another day...to arm wrestle my subfile...
I have partially solved my problem getting rid of the CPF5011 error.
In wanting to reset the error condition (reverse image) I was rewriting the subfile record with the indicator turned off whenever the negative amount error was NOT found.
I deleted that bit of code with the following resulting scenario -
Entered negative amount on subfile record #3.
Reverse image and expected error message display (without additional CPF5011!).
Then, corrected subfile record #3 to valid positive amount and entered negative amount on subfile record #5.
Reverse image remained on corrected subfile record #3 and reverse image on subfile record #5 with expected error message.
So I still need to reset my reverse image indicator when correction is made to a subfile record that was previously in error. But how to do that without rewriting the subfile record every time a record is read...
I'm off to try and reset reverse image indicator and rewrite only for subfile record that was in error previously...

Is there a reason you do your edits by reading via RRN instead of with READ SUBFILE NEXT MODIFIED? After edits are clean, you could then read straight through sequentially to do whatever your database or other output will be. -- Tom

Tom - There is not a good reason. But since something with the rewriting of un-modified subfile records caused me problems here, I would like to try the read next modified in this and/or my next subfile adventure.
I still don't fully understand why resetting an indicator and rewriting the subfile record created a problem, but IT DID, so I will not be doing that again.
Thanks for your comments.

I don't have example code that uses straight RRN subfile code in COBOL. If I get time, I'll try to create a test.
.
But it shouldn't take more than a few minutes to change your code over. You shouldn't have to change anything but the single READ statement that you showed here; and when you do the REWRITE, you should set SFLNXTCHG on to mark it for re-edit. The rest of the code can be the same.
.
That is, I assume that you have a later PERFORM-loop that grabs the values after the editing is done. That would remain the same. RRN works fine for that.
.
I guess there's one extra possibility. Is it necessary to verify that every subfile record was modified by the user? Or is it only required that the test value is non-negative?
.
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!

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