|
View previous topic :: View next topic
|
| Author |
Message |
Vkp321
New User
Joined: 05 Jan 2009
Posts: 56
Location: Dublin
|
|
|
|
Hi
As per ibm manual recommended commarea size is 24KB why so, I tested with one cics subprogram and the 32KB (32763 bytes) data is successfully transferred and return to mainprogram. Please clarify
www.ibm.com/docs/en/cics-ts/6.1?topic=affinity-commarea
The length of a COMMAREA on a RETURN command can vary from transaction to transaction, up to a theoretical upper limit of 32 763 bytes. (However to be safe, you should not exceed 24 KB (1 KB = 1024 bytes), as recommended in the Application Programming Reference manual, because of a number of factors that can reduce the limit from the theoretical maximum.) |
|
| Back to top |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
| Why are you questioning this? IBM tells you that DFHCOMMAREA can be up to 32K-1 but they recommend not exceeding 24K as some facilities of CICS may reduce the maximum allowed DFHCOMMAREA size. So of course your test of a 32763 byte DFHCOMMAREA worked since none of the facilities that would reduce the maximum size were in effect for your code. If you keep exceeding 24K, sooner or later your program will fail when some facility in CICS reduces the maximum DFHCOMMAREA you are allowed. It may not be this year, it may not be next year -- but sooner or later when you ignore IBM recommendations you will get bit. |
|
| Back to top |
|
|
Vkp321
New User
Joined: 05 Jan 2009
Posts: 56
Location: Dublin
|
|
|
|
| Thank you Robert for your answer, I am not questioning however trying to understand the recommendation from IBM for non DPL process and for DPL the CICS version 5.6 allows up to 32K-1. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| understand the recommendation from IBM |
Why? IBM doesn't make recommendations without having a reason for them. They may not provide the reason(s) to you, but they do have reason(s). You can ask IBM, but usually their response will be along the lines of "that's the way it is" and you won't get more from them.
Accept IBM's recommendations (or not -- your choice) but go on and worry about a REAL issue, not a made-up issue that is NOT a problem and does not need to be investigated.
There are plenty of examples on this (and others) forum of people questioning something IBM tells you. This is generally a futile waste of time since IBM isn't likely to explain why they did what they did (and the original reason could go back to something in the S/360 dating back to 1964). The architecture is almost 60 years old at this point and there are plenty of quirks (or undocumented features if you want to call them that) that have popped up over time. IBM's commitment to backward compatibility often means they won't change something just because they've developed something better. The 24K recommendation for DFHCOMMAREA is an example of this -- containers have been around for a while, but DFHCOMMAREA won't be changed (probably not this decade) to maintain the backwards compatibility. |
|
| Back to top |
|
|
|
|
