My example was purely fictional. I just wanted to illustrate the situation.
My real problem is the following:
People at work are creating multi-functional programs. The commarea must be big in order to support the data passing from program A to B.
What I really need to know is whether the size of the commarea is static or dynamic.
If I have a commarea that fully filled is 16k but I only fill 1k of it, what will CICS transfer from program A to B? Will it transfer always 16k (the maximum size of my commarea) despite only 1k of it is populated?
I imagine that Cics will always transfer 16k because it doesn't know that I have only filled pieces of my commarea.
I already know that a commarea can't be bigger than 32k and smaller that 4k, and my second question is: the bigger the commarea, the more it is resource-consuming for Cics?
Joined: 18 Jul 2007 Posts: 2146 Location: At my coffee table
Quote:
What I really need to know is whether the size of the commarea is static or dynamic.
It is dynamic, when you send a commarea, you specify the length of the commarea. When you receive a commarea, IIRC, you get the commarea length in the EIB.
Quote:
If I have a commarea that fully filled is 16k but I only fill 1k of it, what will CICS transfer from program A to B? Will it transfer always 16k (the maximum size of my commarea) despite only 1k of it is populated?
CICS will preserve whatever length of commarea that you told CICS to take care of.
Quote:
can't be bigger than 32k and smaller that 4k
A restriction on minimum length? I think not.
Quote:
the bigger the commarea, the more it is resource-consuming for Cics?
Resources yes, consuming no, just a little more storage (and that is all just virtual ).....
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
When a given program is passed a commarea, CICS issues an internal GETMAIN before the receiving program addresses the commarea and the SENDING commarea is then moved to the RECEIVING commarea. If you've ever looked at a TRACE, you'll see this GETMAIN. It is done to ensure proper AMODE addressability/compliance (24 or 31). The GETMAIN is based upon the value in EIBCALEN. Theoretically, you can have a variable-length commarea, specifying the actual length of the commarea as the first 2-bytes (halfword) or 4-bytes (fullword if you prefer) followed by the actual commarea-data itself.
Then after receiving control, the program can use CA-LGTH as the actual length of CA-DATA and you'd address CA-DATA using reference modification, using CA-LGTH as the addressable data-length.
Defining CA-LGTH as a halfword (same picture clause as EIBCALEN), would mean that the minimum value in EIBCALEN is 3 and the maximum value is 32761 (as illustrated).
Note that there's a misnomer regarding the maximum value of a commarea length (EIBCALEN). It's actually 32763, because CICS owns the other 4-byte fullword.
My preference would be to define CA-LGTH as a binary-fullword, in order to avoid high-order truncation when it's defined as a binary-halfword, which can occur when the TRUNC(OPT) option is used during compilation. If the fullword is used, then the minimum value of EIBCALEN is 5 and the maximum picture clause length of CA-DATA is reduced to 32759.
Having said this, if your compiler supports COMP-5 (native binary), then there aren't any issues regarding high-order trunction when CA-LGTH is defined as a halfword (or fullword for that matter).
There's a way to get around the 32K-4 commarea limitation and that's by using CHANNELS/CONTAINERS. These were introduced with CICS/TS 3.1 and you can load them with several MEG's of data.
There are two other methods which could help; issue a CALL to the recipient (receiving) program, passing a parmlist which would then allow you to address 16MB-1 worth of data per parm as the only thing that's passed is the ADDRESS of the data. Also, there's EXTERNAL WS data, which also has this same level of addressability.
).....