Problem in READNEXT

amitc23 · New User Joined: 05 Nov 2014 Posts: 95 Location: India

Hi
I am getting slight problem in EXEC CICS READNEXT. I am reading a file from start and reading upto 50 records (If there are more than 50) and sending them out through MQ. The receiving system in turn sends me back the last record it has received and i start reading after that and again send 50 records until all the records have been sent.

For this initially I am getting a record with keys as zeroes from the external system and I am doing a STARTBR on my file with that key , followed by READNEXT.

But for the second time when I recieve the key of the 50th record sent, I am following the same STARTBR and READNEXT, but it reads the 50th record again and sends back, so effectively sending the 50th record twice.

As a workaround , currently I am adding 1 to the key when i get it ( first time and subsequent times ) , but that does not look good to me.

Is there any other method I can achieve this. This is a CICS VSAM file with keylength 35.

Thanks

Bill Woodger · Posted: Wed Mar 16, 2016 12:47 pm

You have a "guessed" key-value (which won't be on the file) and an actual key-value (which will). You need "current request not equal to intial request guessed key" and do something different. It doesn't especially matter what, as long as it is clear why.

Bill O'Boyle · Posted: Wed Mar 16, 2016 5:11 pm

I'm confused. When you receive your second set of keys, is this a new task or the same task? If it's the same task, you don't need another STARTBR, just continue with a REANEXT until your next set of keys or EOF. Internally, VSAM is keeping the CRP (Current Record Pointer) for you.

Have your SYSPROG define a suitable LSR Pool for this file, regardless.

Long Browses on NSR (non-LSR) Files can be unsuitable for the QR-TCB, which can cause a monopoly.

Rohit Umarjikar · Posted: Thu Mar 17, 2016 9:10 pm

amitc23 · New User Joined: 05 Nov 2014 Posts: 95 Location: India

Hi

I implemented the workaround then, as the task is terminated and started again. I incremented the key by 1 and it seems working fine because that would anyways be the next key value.

Thanks All

Rohit Umarjikar · Posted: Fri Mar 18, 2016 8:52 pm

RahulG31 · Active User Joined: 20 Dec 2014 Posts: 446 Location: USA

The other team is returning you the last processed record (i.e. 50th) and you are doing a STARTBR with that key. I am sure you must be using a GTEQ in STARTBR and then, since that key (i.e. 50th record) is found, you get that record (which is a duplicate to process).
To overcome this you added 1 to the key BUT that is a bad practice.

So, after reading for the first time you should check whether what you received from the other team is equal to what you get after that first READNEXT. If same then skip. And also check that It's not equal to zeroes before skipping, otherwise you won't get the initial record.

.