Page 1 of 1
Why the length parameter is mostly declared as COMP in COBOL
Posted: Thu Sep 03, 2015 3:02 pm
by Rajesh Reddy
Hi,
I've seen that the length parameter is mostly declared as COMP in COBOL. For example, it's usally defined as:
Be it VARCHAR length, CICS length or something similar... is there some logical reason behind it?
Re: Why the length parameter is mostly declared as COMP in C
Posted: Thu Sep 03, 2015 5:01 pm
by nicc
Because that is what the receiving program is expecting. It is historical back when memory was expensic=ve and in short supply and machines were not so fast so you did not want to do unnecessary conversions.
Re: Why the length parameter is mostly declared as COMP in COBOL
Posted: Mon Sep 07, 2015 3:23 pm
by Rajesh Reddy
Thank you nic. Can you please tell me about the "unnecessary conversions" you are referring in your post?
But it all is because of history, there is no as such rule behind it?
Re: Why the length parameter is mostly declared as COMP in COBOL
Posted: Mon Sep 07, 2015 4:31 pm
by William Collins
If the data is going "outside" of your program (to CICS, to DB2) you need to define it how it is specified. In these cases it is best if a PIC 9(4) binary is expected, to make it COMP-5. COMP PIC 9(4) has a maximum value of 9999. COMP-5 of the same size has a maximum value of 32767.
The conversions runs like this. If you have a PIC 9(4) (so, USAGE DISPLAY) and you wanted to add one to it, code would be generated to convert it to packed-decimal, then add one to it, then convert it back to a zoned-decimal.
If, instead, it were COMP/COMP-4/BINARY it would be just a single instruction (generally). COMP-5 does less well from a performance point of view, but use it where you need to.
If the same USAGE DISPLAY field is used as a subscript, it has to be first packed, then converted to binary. If it were binary originally. you avoid the packing and converting.