Read work file more than once in a program

I need to read part of a work file, say 20% and do edit checks on the data. Depending on the results of the edits I will notify the customer there might be a problem with the work file. This notification takes place with a pop up window. There is no stoppage of the program at his time. The customer can decide to go ahead with the processing or cancel out. If there are no problems or customer decides to go ahead anyway, I will return to the program and read from the beginning of the same work file again and actually store the records this time. Can this be done without asking the customer for the name of the input file again? I work in Natural 4.2.
Thanks for any assistance.

If your user decides to continue rather than cancel, then you could simply continue reading the Work file - the next READ WORK statement that is executed will return the next record on the file. To restart at the first record, execute a CLOSE WORK statement. The next READ WORK will re-open the file at the beginning.

Even if you have multiple READ WORK and READ WORK ONCE statements in your program, each executed for different logic paths, as long as they all specify the same work file number, then each one will return the next record in the file, until end of file is reached. Once you’re at end of file, then the next READ WORK statement will return the first record in the file.

I “read” the question different than Ralph.

If you start the job, then call the customer with the edit results, and the customer gives you a green light or a red light (while the program is paused) and then you continue the job or terminate it, you want Ralph’s answer.

I read the question as having a different time framework. You run “job 1” which does the analysis for 20% of the file. Job 1 ends. You send the customer an e-mail (or leave a voice mail). Sometime later, the customer gets back to you. Maybe with an e-mail that says “its okay, run it”; where “run it” means run Job 2 , which processes the full file from the beginning.

The problem, as I read it, is that there may be multiple jobs (and input files) from the same customer, and you probably have multiple customers.

If this is the problem, you need to get more information from the customer (e.g. Job Number, Input File Name) which uniquely identifies the Job 1 so you can now run a “matching” Job 2. Alternatively, you can provide the customer with the info, and have them return it when they get back to you.

This is now an administrative problem, not a programming problem. Probably harder to solve than the programming problem Ralph addressed (dependent on the users).

I agree with Steve. You need to take a step back & see the bigger picture.
How do you know that the “first 20%” of the file is a representative sample?
What if the first 20% is good & passes your edit checks but the next 80% is full of errors?
Would you still want to process & update then ?
I would recommend to pre-process the entire file (with updating disabled) in order to produce a full error report. Then the customer can make an informed decision: ie. whether to process the file “as is” or to clean up his data first.