How To Tell What Record My Job is Reading in a PF

[cwscholbe@dstsystems.com]

I have a job that has been running for 9 days, and still has some time to go. The input file has just over 80 Million records. When I display the open files for the job the Relative record count shows as ++++++ because it has passed 1Million. Is there a way to see just how far into the file this job has progressed? Thanks Chris (hoping this job doesn't abend) Scholbe

[B.Myrick]

Chris, I had an issue like this for an airline one time. What I did was embed some code that sent me a message every 100,000 records. It's kind of a non tech way to do it, but it was cheap in time spent. 'Course this doesn't help you now, but since I don't know how to do what you want, its the best I could come up with. -bret

[Guest.Visitor]

display the job, look at the open files(opt 14) hit F11 and look at the relative record number for the file. That will tell you what rrn you have just read(reading). Now if you are not reading the file by RRN you will need to find the accesspath value for that record, finding it by RRN,. You should then be able to tell where the program is in the file. Or if the program is not blocking you can look at the I/O count on the file, if it is reading and updating you need to divide by 2 (if it only updates once). If it is blocking and you know the blocking factor you can also get a close indication of where the program is in the file. HTH

[cwscholbe@dstsystems.com]

Greg, The RRN is ++++++ and has been for a number of days. Any other ideas?

[J.Panzenhagen]

SEVERAL DAYS!?! Sounds like one of my jobs. If the file is opened for I/O and there is a lock on the file, you could use the DSPRCDLCK command for the file. If the file is a logical, you would have to specify the physical file that the logical is based on. Good Luck! John Panzenhagen

[cwscholbe@dstsystems.com]

I tried the DSPRCDLCK and it says that no records are locked. That is because the input file is open only for input and not being updated. The job says that it is RUNning. QBATCH QSYS SBS .0 DEQW W01_UPDATE CHRIS BCH 12.4 PGM-W01_UPDATE RUN I look at the call stack and it changes, acting like it really is doing something. Am I confused? Well, I am confused, but am I confused??

[B.Myrick]

Chris, Is there any output with this program, such as printer or new records being written? Does it normally take this long to run? -bret

[cwscholbe@dstsystems.com]

Well, there is good news and bad news.(Isn't that always the case?) The good news: This is a job we put together to "fix" one of our files that didn't get updated correctly. This "should" be the only time we ever need to run this. We are going to be taking this database and our application up to the Benchmark center in Rochester to see how it all runs on the AS/400 with 7,000 users. If all goes well, we will continue the test with 14,000 users. The bad news???: I do see the record count on the output file changing, it is over 400 Million records and climbing slowly. Unfortunately, I can't tell from the output file how far along I might be in the input file.

[Guest.Visitor]

How many records are in the input file? Could you tell by looking at a record if the program has made changes? If so use EZview or DBU if you have one of them and work back until you find the first changed record. It may be a pain but it would work, again only if you can tell if a record was updated.

[Guest.Visitor]

Sounds like you're updating a HUGE file. I think the only way you're gonna be able to tell is to write a quickie to use the retrieve job APIs to get the record count. The returned data structure should have the correct value (it's just displaying ++++++s because the display file doesn't have enough room to display all the digits. The slowness may be due to rebuiling of access paths for LFs built over the PF. Any chance you can delete some of the LFs while the update is running??

[cwscholbe@dstsystems.com]

The input file has just over 80 Million records. I think you might be right about the indexes on the output file. There are only three but..... I'm not much with API's, will the RTVJOBA have the same information in it?

[Guest.Visitor]

It may be possible to start a service job to debug the program that is executing, if you can 'break' into the executing program you may be able to detemine where it is in the file it is processing. Assuming the program is compiled to allow debug. Good luck