Storage problem

rackshit · New User Joined: 19 Dec 2009 Posts: 16 Location: Mumbai

Hi,

i have a storage related problem. So needed suggestion for it.

i have one CICS screen which displays one table. the table is currently defined in COMM-AREA with 200 OCCURS clause.

Now what is happening is due to increase in data we have a need to increase the OCCURS clause, but to bring a permanent solution, we are trying to store the data in VSAM file and retrieve the data to be displaced on the screen when page up and page down is pressed.

So what is the best way to do this?
1) Use VSAM file to store the table
2) I have a vague idea about TDQ and TSQ
3) or any other way to do this ?

Im new to CICS programming, simultaneously im reading TDQ and TSQ to get more idea about what it is.

Thanks a lot in advance

Robert Sample · Posted: Tue Apr 19, 2011 3:56 pm

You need to talk to your team leader, coworkers, or site support group. Most sites have some standard method for paging in CICS that they expect you to follow. Going off on your own is not typically a good idea.

rackshit · New User Joined: 19 Dec 2009 Posts: 16 Location: Mumbai

Robert Sample · Posted: Tue Apr 19, 2011 8:17 pm

1. TSQ names are 8 bytes (if you use QUEUE) or 16 bytes (if you use QNAME). 4 of those bytes could be the terminal identifier -- which will be unique for that user in that region. Typically, terminal identifier is combined with something to make a unique name for the TSQ.

2. VSAM locks at the CI level, depending on the SHROPTIONS. If you're doing nothing but reads, there won't be any locking involved. If you are doing updates, as long as the updates are in different CI you're okay. Otherwise, the second task to attempt to lock the CI (usually) waits for the CI to be released (depending on how you code the program). The VSAM Demystified Redbook can be very helpful in understanding concepts for VSAM files.

Bill O'Boyle · Posted: Tue Apr 19, 2011 8:49 pm

Adding to Robert's reply, if accessing the TSQ/QNAME is to be done by multiple concurrent tasks, then to ensure data integrity, you'll need ENQ/DEQ API's for serialisation in all program's which access the QUE.

Bill

rackshit · New User Joined: 19 Dec 2009 Posts: 16 Location: Mumbai

Bill O'Boyle · Posted: Tue Apr 19, 2011 11:20 pm

If for some reason, the terminal gets logged-off and the TSQ remains, there's the possibility that the terminal could be reused (via terminal Autoinstall) and attached to the same transaction, the program may "Think" the TSQ data is correct.

So, whenever the logic in your process knows that this is the initial TSQ creation, first issue a DELETEQ (with NOHANDLE), to ensure you're starting from scratch with a new TSQ.

This is where the 16-Byte QNAME could come in handy as you could build the QNAME with EIBTRNID, then EIBTRMID and finally EIBTASKN (Unpacked as a PIC 9(08)).

EG: TRN1TRM100123456

Also -

MAX NUMBER OF ITEMS ===> 32767 (Signed Halfword)

MAX ITEM LENGTH ===> 32763 (Signed Halfword)

Bill

dbzTHEdinosauer · Posted: Wed Apr 20, 2011 1:08 am

if the table does not have an index,
after design of a paging method,
create one.

basic concept: do not think that you are saving time by storing everything that the user may want to see. learn to save the current first and last of the display, and based on PF7 or PF8 get the next or get the previous.

no user is going to go thru 10 or 15 screens looking at garbage.
if the data needs to be extracted and downloaded, use unload and com:direct.

the problems

of orphan queues
user not paging down or back

preclude the unnecessary waste of resources to build everything in memory ahead of time. That is why we have cursors. they can be reopened at some starting point.

anyone who is telling you to use TSQ's or commarea, to build it all,
does not have the skills to write a professional program.

yes this is a personal opinion. and opinions are like assholes,
and i am an asshole,
i have no time for rookie bullshit.