|
View previous topic :: View next topic
|
| Author |
Message |
sonia10
New User
Joined: 11 Apr 2006
Posts: 3
|
|
|
|
The declaration of EIBCALEN is S9(04) COMP ( half word), meaning that it can store approx 32KB of data. This also limits the size of DFHCOMMAREA. Is it possible for the CICS system administrator to modify the size of EIBCALEN, say to a full word limit or something greter than S9(04) COMP.
Thx and Regards. |
|
| Back to top |
|
 |
steve
New User
.jpg)
Joined: 24 Mar 2005
Posts: 16
Location: Long Island
|
|
|
|
| I've one concern in connection to the sonia10, wht happens if the data received is greater than the size of DFHCOMMAREA declared? Does the data gets truncated or it gets abended? |
|
| Back to top |
|
|
sunish_sr
New User
Joined: 02 Jan 2006
Posts: 9
Location: Chennai
|
|
|
|
HI,
EIBCALEN is used to get the length of the COMMAREA passed from One program to another, only the length. Since it is declared as S9(04) COMP it can store up to 32,768.
For example..
If I am passing 1000 KB in my COMMAREA,
Only the value 1000 is stored in EIBCALEN field, not the data.
Sunish S |
|
| Back to top |
|
|
Marso
REXX Moderator
Joined: 13 Mar 2006
Posts: 1353
Location: Israel
|
|
|
|
To sonia10:
the COMMAREA is limited to 32K. If you need more, store data in TS.
To steve:
You will be able to access only what you have defined in the LINKAGE SECTION.
The rest will be unavailable, so in this case we have a truncation.
The best practice is to be accurate, as some cases may lead to storage violations. |
|
| Back to top |
|
|
sonia10
New User
Joined: 11 Apr 2006
Posts: 3
|
|
|
|
Thx for all the info.
But my qst is still unanswered. Wud it be possible for the CICS administrator to increase the size of DFHCOMMAREA and EIBCALEN so that it can store data > 32 K. |
|
| Back to top |
|
|
gsnvsr
New User
Joined: 06 Jul 2005
Posts: 40
|
|
|
|
No! it is not possible. Limit on DFHCOMMAREA is imposed by CICS. It can only be upto 32K. However, recommended max limit by IBM is 24k. Define other 01 levels in linkage and acquire memory manually if you need to pass more data.
Best regards |
|
| Back to top |
|
|
arunjosephaj
New User
Joined: 21 Mar 2006
Posts: 20
Location: India
|
|
|
|
| Dont worry there are newer versions of CICS which uses different methods.. 32K and 24K will be forgotten when they come.. |
|
| Back to top |
|
|
rameshraj.satyam
New User
Joined: 15 May 2006
Posts: 9
|
|
|
|
| EIBCALEN mns when u r passing values Main prg to sub in that time values r passing r not cheking whether EIBCALEN >0 mns values r passing main to sub |
|
| Back to top |
|
|
arunjosephaj
New User
Joined: 21 Mar 2006
Posts: 20
Location: India
|
|
|
|
Hey Ramesh,
Tht is just one use of EIBCALEN..
EIBCALEN means EIB CommArea LENgth.. Thtz all.. |
|
| Back to top |
|
|
gskulkarni
New User
Joined: 01 Mar 2006
Posts: 70
|
|
|
|
I have been in touch with IBM system analysts in the past and the answer to increase in size of commarea is a big NOOOOO.
Having said this, I really fail to understand as to what kind of system would require to pass more that 32k data from one pgm to another. if it is because of the similar type of data being passed for many occurances e.g. list of accounts and their demographic details, and more than 1000 accounts are retrieved. But in such cases generally "paging' logic is used. |
|
| Back to top |
|
|
sada_polaris
New User
Joined: 24 May 2006
Posts: 13
|
|
|
|
| Quote: |
I have been in touch with IBM system analysts in the past and the answer to increase in size of commarea is a big NOOOOO.
Having said this, I really fail to understand as to what kind of system would require to pass more that 32k data from one pgm to another. if it is because of the similar type of data being passed for many occurances e.g. list of accounts and their demographic details, and more than 1000 accounts are retrieved. But in such cases generally "paging' logic is used. |
We can replace the paging concept with the TSQ concept. If you use TSQ then you no need to worry about the size of data that can be stored. |
|
| Back to top |
|
|
gsnvsr
New User
Joined: 06 Jul 2005
Posts: 40
|
|
|
|
| Quote: |
We can replace the paging concept with the TSQ concept. If you use TSQ then you no need to worry about the size of data that can be stored. |
The above statement couldn't be entirely true. The length option of any CICS command is a half-word and hence theoritically can hold a value of 32,763. If exceeded, you would encounter a LENGERR conditiion. The records exceeding this upper limit might have to be written as different records in TSQ. However, same rule applies to the number of items in TSQ as well.
Comments welcome!
Cheers, P |
|
| Back to top |
|
|
karthick sivakumar
New User
Joined: 16 Mar 2006
Posts: 16
Location: india
|
|
|
|
Hi ,
if the size limitation is the problem in case of TSQs then Can we use TDQs and delete them after reading the queue.
Thanks and Regards,
Karthick |
|
| Back to top |
|
|
jacheter
New User
.jpg)
Joined: 15 Oct 2005
Posts: 9
Location: Clemson, SC
|
|
|
|
Old school:
1. Pass the address of a large storage area in the COMMAREA. By using the FLENGTH option of the GETMAIN command, a storage area larger than 32K can be acquired. This solution will only work in a single CICS address space.
2. Pass the name of a temporary storage queue in the COMMAREA. By placing the data in temporary storage more than 32K of data can be passed between programs or tasks. If the temporary storage queue is placed in a Temporary Storage Owning Region or the Coupling Facility, the data can be accessible across multiple CICS regions.
New school:
1. If using CICS Transaction Server 3.1 you can use the technique called "Enhanced Inter-Program Data Transfer Function" which involves utilizing "containers" and "channels". Channels are sets of containers, and containers are name blocks of data that hold information (only limited by CICS region size) to be passed between programs.
I am going to try this technique and will report back on the results. J. |
|
| Back to top |
|
|
calspach
New User
Joined: 05 May 2006
Posts: 32
Location: USA
|
|
|
|
| I know this is an old topic, but I was told recently by a CICS 'Expert' that the next release of CICS would be increasing the size of the COMMAREA up in the megabytes. This is because there are several CICS web apps being written these days that do require more than 32k of storage. I know, when I first heard that 32k was the limit, I thought the same as Bill, that should be enough for anyone! |
|
| Back to top |
|
|
karthick sivakumar
New User
Joined: 16 Mar 2006
Posts: 16
Location: india
|
|
|
|
hi,
i tried to execute the channels command , but it seems that the current version does not support it . it not even recognises the command
i had this problem when i tried to sent multiple 01 level linkage section variables as containers. so i had to go back and write the rest of the linkage varibles except the dfhcomm area in tsqs and read them back
if u are able to use containers and channels , let me know how. ( i use endevor to compile my programs , will the endevor recognise the channel command?)
regards,
karthick.s |
|
| Back to top |
|
|
jacheter
New User
Joined: 15 Oct 2005
Posts: 9
Location: Clemson, SC
|
|
| Back to top |
|
|
airan1981
New User
Joined: 11 Nov 2008
Posts: 6
Location: Bentonville, AR US
|
|
|
|
| In my environment, I can pass more than 32 K data to other programs. I think we use the newer version of CICS. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
airan1981,
as the DFHCOMMAREA? |
|
| Back to top |
|
|
airan1981
New User
Joined: 11 Nov 2008
Posts: 6
Location: Bentonville, AR US
|
|
|
|
We call the module like
CALL WS-PAUW032 USING DFHCOMMAREA,
LW2011-GUIDELINE-RECORD,
DCL-MIGRATE-HOME-ROP,
LDB2E-LINKAGE-AREA.
The length of LW2011-GUIDELINE-RECORD, DCL-MIGRATE-HOME-ROP, LDB2E-LINKAGE-AREA is far more than 32 K. |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
| calspach wrote: |
| I know this is an old topic, but I was told recently by a CICS 'Expert' that the next release of CICS would be increasing the size of the COMMAREA up in the megabytes. |
This would wreak havoc on current applications and I don't believe the expert's information is correct.
EIBCALEN would need to be redefined as a signed-fullword (currently, it's a signed-halfword). However, please understand that the current maximum value for EIBCALEN is 32763, with IBM encouraging a value of not more than 24576 (24K). Although the maximum value of a signed-halfword is 32767 (32K-1), IBM reserves a fullword (4-Bytes), resulting in 32763 (32K-5). A signed-halfword greater than 32767 will be considered a negative value (the high-order bit of the 1st-Byte is on) so keep this in mind. An unsigned-halfword has a maximum value of X'FFFF' (65535) and would be considered a negative one (-1) if it were addressed as a signed-halfword.
The current version/release of CICS/TS is 4.1 (released this past June) and EIBCALEN remains as it always has.
All of the offsets in DFHEIBLK would be off by 2-Bytes and the overall length of this DSECT would increase to decimal 87.
There are many DSECTS and Assembler labels which would need to be increased to accommodate this new DFHEIBLK, such as the commarea-DSECT for DFHPEP and the user-EIB commarea label in this commarea.
Having said this, IBM would need to back-fill previous releases to accommodate this increased EIBCALEN definition.
Also, when a commarea is passed from program to program, the address is not passed, rather the commarea gets recreated (via an internal CICS GETMAIN) upon each LINK and/or XCTL, would would cause a substantial increase in EUDSA if EIBCALEN were defined as a signed-fullword, maximum value of X'7FFFFFFF' and most likely (as with the halfword EIBCALEN), minus 4.
Please have the expert point us to some authentic IBM documentation and/or press releases (not just hearsay) so we can mull over this, but he'll probably come up short.
Bill |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
arian1981,
| Quote: |
| CALL WS-PAUW032 USING DFHCOMMAREA, |
as I thought. That is a COBOL Call.
What we are talking about are the CICS API's, XCTL,LINK,START.... |
|
| Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006
Posts: 1193
Location: Dublin, Ireland
|
|
|
|
....and we picked up a 3-year old thread for some reason??
Garry. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
| Quote: |
| ...I can pass more than 32 K data to other programs... |
maybe a My CICS is better than Yours contest  |
|
| Back to top |
|
|
|
|
