64 bit COBOL for CICS

I have used cics shared table tables in the past for vsam files. I think the largest such file took 10Gig of memory. It saved a large amount of cpu, especially by eliminating mro file function ships. The idea to source cics shared data with DB2 table data would help save some cpu also so I will discuss with my co-workers. However, I was hoping to place the DB2 data in a large incore table in Grande storage to obtain the absolute optimal performance. It would avoid the potential drawdowns of using cics shared tables which would require switching to the QR MVS tcb (my application runs 95% of its code on L8 mvs tcbs), and I believe each EXEC CICS READ access to a shared data table could only pickup one 32K hunk of data. For a 3 Gig table, that would require 91553 EXEC CICS READ accesses. My shop could trial the use of a cics shared data table to replace the consistent DB2 accesses and see if the increased QR mvs tcb requirements are acceptable. I suppose if the QR was being overwhelmed, we could increase the number of cloned AORs to get more QR mvs tcbs available, but then again, i suppose such an increase in number of regions would slightly increase cpu needs also. I guess I should really be asking the COBOL language guys if they ever expect to make Cobol AMODE64 capable.

As far as a data cache is concerned, CICS has shared data tables, where the data is held in up to 100 data spaces, so up to 200 GB can be stored. So if the DB2 data could be stored in a data table, that provides fast access.

My shop has several 3 Gig DB2 tables that have data that is repeatedly accessed by several cics application programs used by most cics tasks. The data values held in these DB2 tables are typically not changed for several days. So, if we could build an incore table in 64bit Grande storage with a copy of this DB2 data, and then access the 64bit incore table via the linkage section of COBOL AMODE64 programs... CPU usage would drop significantly by eliminating many repeated DB2 calls.

Whilst this requirement is valid, based on our current plans and priorities, it is not likely that this could be implemented in the next 12 months, or in the next CICS TS release. Correspondingly this requirement is being declined at this point. The requirement will be kept in the RFE system and might be reassessed in the future. You also have an opportunity to resubmit in twelve months time if you wish it to be reconsidered then.

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Transaction Processing
Product - CICS Transaction Server

For recording keeping, the previous attributes were:
Brand - WebSphere
Product family - Transaction Processing
Product - CICS Transaction Server

RMODE(64) is an even longer term item. We have to get to amode(64) first. Rmode(64) requires changes in binder, DFSMS and elsewhere. So to answer your question whne/if we get to amode(64), it will not support rmode(64) at that time.

I had a general follow up question related to this RFE for CICS development. If/When IBM does support 64 bit COBOL, would we be able to put 64 bit COBOL load modules in the GCSA (above the bar shared common memory, like ECSA). My understanding is that the GCSA (if that is the correct term) is between 2 terabytes and 512 terabytes in the 64 bit address space based on a little research on my part. If that is incorrect, please let me know. We currently have exhausted our use of putting application load modules in the ECSA from a practical stand point, and would leverage the GCSA, if that would be available in the future for 64 bit COBOL load modules in CICS.

Thanks,
Tim

Providing Amode(64) support is a long term aim for CICS which will not be realised in the short term, probably not in the next two releases. We require compiler and language environment support to be in place.

Hello,

We have a CICS COBOL application called TBA (which stands for Total Benefits Administration) that stores user session data in ESDSA. This session data is around 2 Mb - 4 Mb per user. This data originally comes from DB2 and then can be modified as the user selects options on the web page, GUI panel, etc. This data is kept in ESDSA because the user is making multiple calls of a non-conversational nature into the CICS region. Keeping the data in ESDSA allows the data to stay resident in the CICS memory without having to save it off to DB2 when a call ends. If this session data was in EUDSA, CICS would FREEMAIN it when the task ended. Once the user session is over (which could take a half hour or longer), the relevant session data is saved to DB2 and then the TBA application will FREEMAIN the ESDSA session data. When we are busiest, we can have around 25,000 users on our system. 25,000 x 3Mb = 54 gig of storage. With the other memory requirements for a TBA region, a region can support about 400 Mb for the total session data. So this requires us to go wide with our CICS regions.

The application does not use EXEC CICS calls to access the data. The application just uses standard COBOL logic to access the data. In between trips the application saves virtual addresses to where this data is located in a CICS data table so that when a subsequent call is made for a user, the application can find where their session data is located in the region.

The application team that supports TBA is looking at ways to take this session data and change their approach so it is allocated in EUDSA and then saved off to some other medium (currently looking at CICS data tables/dataspaces) in between application calls. However, this is a very extensive coding project to do this, and will probably take them years to accomplish this. If CICS would support 64-bit COBOL, they would not need to change one line of their code (potentially). Instead their code could be recompiled and then their ESDSA GETMAIN SHARED calls could allocate memory above the bar and their code would have 8 byte pointers to reference it. This would also be ideal as it would not require the CPU and memory overhead to save the data to another storage medium like they are currently researching.

Let me know if you need any other information.

Thanks,
Tim

In order to help us assess how we might be able to address this requirement it would be extremely useful to better understand the nature of the CICS virtual storage constraint. Specifically the ESDSA is mentioned in this RFE as the constrained DSA but we would like to understand what type and size of data is being getmained and managed there? What is the original data source and what EXEC CICS commands are used to access the data there? (e.g. read, write, get, put, etc, ..)