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.
Dig Deeper on IBM system z and mainframe systems
Related Q&A from Robert Crawford
For better mainframe capacity planning, how do I convert CPU hours to MIPS? And is there a way to calculate the relationship between MIPS and MSUs? Continue Reading
I have two years of experience in mainframe technology, currently working as a mainframe developer. I want to change to Java technology. Continue Reading
I want to replicate DB2 from the mainframe to an AIX box since it's cheaper and the copy can be used for testing. Is this possible? Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.