Q

Not clear on reading TSQs with multiple records

I am not clear on reading TSQs with multiple records. From what I gather, using the item number value, a program

can position itself to a specific record, kind of a keyed read. From that point, readnext can be executed as necessary. Is this undestanding correct?



Your understanding is correct: it's a point not made super clear in the
manuals. However, the behavour may not be what you are expecting!

To illustrate, this, I've created a TSQ (without any TSQModels interfering)
and I put 9 records in it (it does not matter if the TSQ is in MAIN or
AUX).

In a 1st transaction of CECI I did: READQ TS QU(B) ITEM(3) and got back, as
expected '3333' with NUMITEMS(9)

In the same CECI I then did a READQ TS QU(B) NEXT and got back, as expected
'4444' with NUMITEMS still at (9)
and repeated this to get back '5555' - as expected.

Leaving the 1st CECI active, I then started up another CECI on a different
terminal and did
READQ TS Q(B) NEXT and got back '6666' with NUMITEMS still at (9).

And then switching back to the initial terminal, I continued with another
READQ TS QU(B) NEXT and got back '7777'
with NUMITEMS still at (9).

I then killed off both CECIs, and started another one doing a READQ TS
QU(B) NEXT and got back '8888' with NUMITEMS(9).

This is, perhaps, unexpected behavour for you. Temporary Storage saves the
last ITEM addressed at the Queue Level - not the transaction - and so
reading the TSQ sequentially is shared across all CICS Transactions.

This provides a certain flexability in processing TSQs that is enjoyed by
lots of users. If the TSQ is being used as a FIFO stack, then it should
always be accessed with NEXT - a transaction will always get a record that
has not been accessed by anyone else.

If you are using the TSQ on behalf of a single transaction (and so not
sharing the name around), then you can either use ITEM(n) explicitely or
always use NEXT.

If using the TSQ in a keyed fashion, then ITEM should always be used to get
the record of interest.

So, you can get into a position whereby usage of NEXT will return an
ITEMERR condition indicating that there are no more records to read, but as
you started reading the TSQ later than the 1st record (ITEM(3) say) not all
of the records will have been processed (numbers 1 & 2). Again, I stress
that this function applies at the TSQ level - it is not just at the
transaction.

This was first published in September 2002

Dig deeper on Mainframe operating systems and management

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchWindowsServer

SearchEnterpriseLinux

SearchServerVirtualization

SearchCloudComputing

Close