LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (June 2005)Back to main CICS-L pageJoin or leave CICS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:   Thu, 23 Jun 2005 16:10:50 -0600
Reply-To:   CICS List <CICS-L@LISTSERV.UGA.EDU>
Sender:   CICS List <CICS-L@LISTSERV.UGA.EDU>
From:   Frank Swarbrick <Frank.Swarbrick@EFIRSTBANK.COM>
Subject:   Re: Machine Instructions for Cobol statements
Content-Type:   text/plain; charset=US-ASCII

Hmm, interesting! I have just been working with something similar, though I only coded by LS area as PIC X(32767) and not 16M! Still, definately something to think about. I wonder if there's a way other than doing the PIC X way and no range checking. (Not that we use range checking, but... <g>).

Frank

--- Frank Swarbrick Senior Developer/Analyst - Mainframe Applications Development FirstBank Data Corporation - (303) 235-1403

>>> Mark.Laughton@UK.EXPERIAN.COM 6/23/2005 1:54:19 AM >>> Tara

I had some performance issues with some code (handling large XML messages) I wrote last year which hiighlited an interesting issue relating to large linkage section structures.

I had 3 x 16mb linkage structures defined as occurs depending on (ODO). The cpu / task was higher than I'd anticipated so I Strobe'd it and found that CICS API calls (even 'simple' things like ASSIGN) were using a very large % of the CPU. Further investigation revealed that the compiler (EC 3.2 at the time I think) was generating a loop to recalculate all the BLL cells for each structure in Linkage Section after every CALL (i.e. CICS API command).

For each 16mb structure there are 4096 BLL cells (addressing 4k / cell), hence a loop count of 4095!!

See extract (below) from an email I sent to a colleague at the time showing this code (the embedded comments are mine, not the compilers, of course! <grin>)

Ok - I can understand why its doing this. I hadn't even considered this when defining my 16mb structures, whjich I'd make 16mb simply 'because I could' to cator for the absolute largest possible message.

After some discussion with a colleague, because these structures are only referenced by reference modification (or via CICS API commands) we decided to code these as PIC X(1) and document the reason for this clearly in the code! This reduced the cpu / task from 6.5ms to 2ms per task - not bad imho! I think you need to SSRANGE (?) option turned off (which we do anyway) for this to work, iirc, otherwise the compiler checks the reference modification bounds also(?).

Perhaps worth checking if you're reviewing this.

hth Mark

> 01 server-out. > 03 filler occurs 1 to 16777215 > depending on server-out-tot-len pic x. > > > > 000-main section. > > exec cics assign userid(userid) applid(local-applid) > > program(wtra-pgmname) end-exec > > > > set element-stack-namespace-idx(1) to nst > > > results in: > > > 002D38 9601 D084 OI 132(13),X'01' > DSAFIXD+132 > 000641 *000-MAIN > > 000644 CALL > > * the actual EXEC CICS ASSIGN command > 002D3C D21D D338 8414 MVC 824(30,13),1044(8) > TS2=32 PGMLIT AT +916 > 002D42 4120 D338 LA 2,824(0,13) > TS2=32 > 002D46 5020 D328 ST 2,808(0,13) > TS2=16 > 002D4A 4120 7230 LA 2,560(0,7) > USERID > 002D4E 5020 D32C ST 2,812(0,13) > TS2=20 > 002D52 4120 7238 LA 2,568(0,7) > LOCAL-APPLID > 002D56 5020 D330 ST 2,816(0,13) > TS2=24 > 002D5A 5830 9164 L 3,356(0,9) > BLW=2 > 002D5E 4120 332C LA 2,812(0,3) > WTRA-PGMNAME > 002D62 5020 D334 ST 2,820(0,13) > TS2=28 > 002D66 9680 D334 OI 820(13),X'80' > TS2=28 > 002D6A 4110 D328 LA 1,808(0,13) > TS2=16 > 002D6E 58F0 8000 L 15,0(0,8) > V(DFHEI1 ) > 002D72 4100 A1B8 LA 0,440(0,10) > CLLE@=1 > 002D76 58C0 9080 L 12,128(0,9) > TGTFIXD+128 > 002D7A 05EF BALR 14,15 > > 002D7C 58C0 90E8 L 12,232(0,9) > TGTFIXD+232 > 002D80 5820 9158 L 2,344(0,9) > BL=1 > 002D84 40F0 2008 STH 15,8(0,2) > RETURN-CODE > * a loop > 002D88 5820 9198 L 2,408(0,9) > BLL=12 > 002D8C 4120 2000 LA 2,0(0,2) > > 002D90 5020 9198 ST 2,408(0,9) > BLL=12 > 002D94 58F0 80C8 L 15,200(0,8) > PGMLIT AT +72 > 002D98 41E0 9198 LA 14,408(0,9) > BLL=12 > 002D9C GN=407 EQU * > > 002D9C 5E20 80C4 AL 2,196(0,8) > PGMLIT AT +68 > 002DA0 4AE0 80A2 AH 14,162(0,8) > PGMLIT AT +34 > 002DA4 5020 E000 ST 2,0(0,14) > > 002DA8 46F0 B3E4 BCT 15,996(0,11) > GN=407(002D9C) > * another loop > 002DAC 5830 9140 L 3,320(0,9) > TOV=8 > 002DB0 5820 31B8 L 2,440(0,3) > BLL=8212 > 002DB4 4120 2000 LA 2,0(0,2) > > 002DB8 5020 31B8 ST 2,440(0,3) > BLL=8212 > 002DBC 58F0 80C8 L 15,200(0,8) > PGMLIT AT +72 > 002DC0 41E0 31B8 LA 14,440(0,3) > BLL=8212 > 002DC4 GN=408 EQU * > > 002DC4 5E20 80C4 AL 2,196(0,8) > PGMLIT AT +68 > 002DC8 4AE0 80A2 AH 14,162(0,8) > PGMLIT AT +34 > 002DCC 5020 E000 ST 2,0(0,14) > > 002DD0 46F0 B40C BCT 15,1036(0,11) > GN=408(002DC4) > * and another > 002DD4 5830 9130 L 3,304(0,9) > TOV=4 > 002DD8 5820 31B8 L 2,440(0,3) > BLL=4116 > 002DDC 4120 2000 LA 2,0(0,2) > > 002DE0 5020 31B8 ST 2,440(0,3) > BLL=4116 > 002DE4 58F0 80C8 L 15,200(0,8) > PGMLIT AT +72 > 002DE8 41E0 31B8 LA 14,440(0,3) > BLL=4116 > 002DEC GN=409 EQU * > > 002DEC 5E20 80C4 AL 2,196(0,8) > PGMLIT AT +68 > 002DF0 4AE0 80A2 AH 14,162(0,8) > PGMLIT AT +34 > 002DF4 5020 E000 ST 2,0(0,14) > > 002DF8 46F0 B434 BCT 15,1076(0,11) > GN=409(002DEC) > * and yet another still!! > 002DFC 5830 9130 L 3,304(0,9) > TOV=4 > 002E00 5820 3198 L 2,408(0,3) > BLL=4108 > 002E04 4120 2000 LA 2,0(0,2) > > 002E08 5020 3198 ST 2,408(0,3) > BLL=4108 > 002E0C 58F0 80C0 L 15,192(0,8) > PGMLIT AT +64 > 002E10 41E0 3198 LA 14,408(0,3) > BLL=4108 > 002E14 GN=410 EQU * > > 002E14 5E20 80C4 AL 2,196(0,8) > PGMLIT AT +68 > 002E18 4AE0 80A2 AH 14,162(0,8) > PGMLIT AT +34 > 002E1C 5020 E000 ST 2,0(0,14) > > 002E20 46F0 B45C BCT 15,1116(0,11) > GN=410(002E14) > > 000653 SET > > 002E24 D203 787C A2A0 MVC 2172(4,7),672(10) > ELEMENT-STACK-NAMESPACE-IDX() NST > 000656 MOVE >

Find out about The Experian Conference 2005 at www.experian.co.uk/conference2005

========================================================================= Information in this e-mail and any attachments are confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other binding commitment through the use of this electronic communication unless it is issued in accordance with the Experian Limited standard terms and conditions of purchase or other express written agreement between Experian Limited and the recipient Experian Limited (registration number 653331) Registered office: Talbot House, Talbot Street, Nottingham NG80 1TH

Although Experian has taken reasonable steps to ensure that this communication and any attachments are free from computer virus, you are advised to take your own steps to ensure that they are actually virus free.


Back to: Top of message | Previous page | Main CICS-L page