Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

length of commarea

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> CICS
View previous topic :: :: View next topic  
Author Message
jctgf
Currently Banned

Active User


Joined: 04 Nov 2006
Posts: 109

PostPosted: Sun Mar 01, 2009 12:10 am    Post subject: length of commarea
Reply with quote

Code:

01 dfhcommarea.
     03 product-code          pic s9(09) comp.
     03 array.
          05 part-code          pic s9(09) comp occurs 1000.


hi there,

will I use more Cics resources when I fill all the occurrences of the array, than when I only fill the first occurrence?

does "length of commarea" assure that only the filled part of it will be passed?

thanks.
Back to top
View user's profile Send private message

Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Sun Mar 01, 2009 12:53 am    Post subject: Reply to: length of commarea
Reply with quote

In your example, you've defined the total length of the commarea as 4004. So, it doesn't matter if you populate the entire commarea or not.

What do you need 1000 binary-fullwords for (if I may ask)?

Are you loading them with a bunch of addresses?

If not, what's the maximum value that a given single occurrence (of the 1000 entry array) can hold?

Enquiring minds want to know icon_wink.gif

Regards,
Back to top
View user's profile Send private message
jctgf
Currently Banned

Active User


Joined: 04 Nov 2006
Posts: 109

PostPosted: Sun Mar 01, 2009 4:39 am    Post subject:
Reply with quote

Hi,

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?
Back to top
View user's profile Send private message
CICS Guy

Senior Member


Joined: 18 Jul 2007
Posts: 2150
Location: At my coffee table

PostPosted: Sun Mar 01, 2009 5:15 am    Post subject:
Reply with quote

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 icon_lol.gif ).....
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Sun Mar 01, 2009 5:17 am    Post subject: Reply to: length of commarea
Reply with quote

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.

For example -

Code:

01  DFHCOMMAREA.
    03  CA-LGTH PIC S9(04) COMP.
    03  CA-DATA PIC X(32761).

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.

HTH....

Regards,
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> CICS All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Length of Tape file Mohan Kothakota JCL & VSAM 9 Thu Apr 20, 2017 10:24 pm
No new posts Sort Large record length cmsmoon DFSORT/ICETOOL 14 Tue Apr 11, 2017 5:49 pm
No new posts COMMAREA and CHANNELS menonkiran CICS 4 Tue Apr 04, 2017 8:14 am
No new posts Count the length of the record & ... sreekusr DFSORT/ICETOOL 4 Thu Mar 23, 2017 7:52 pm
No new posts Writing on to GSAM variable length rohanthengal JCL & VSAM 6 Fri Mar 03, 2017 7:46 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us