Why the length parameter is mostly declared as COMP in COBOL

OS/VS COBOL, COBOL II, Enterprise COBOL for z/OS. OpenCOBOL and OOCobol.
Post Reply
Rajesh Reddy
New Member
Posts: 5
Joined: Thu Dec 04, 2014 3:19 pm

Why the length parameter is mostly declared as COMP in COBOL

Post 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:

Code: Select all

S9(4) COMP 
Be it VARCHAR length, CICS length or something similar... is there some logical reason behind it?
nicc
Global Moderator
Global Moderator
Posts: 691
Joined: Wed Apr 23, 2014 8:45 pm

Re: Why the length parameter is mostly declared as COMP in C

Post 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.
Regards
Nic
Rajesh Reddy
New Member
Posts: 5
Joined: Thu Dec 04, 2014 3:19 pm

Re: Why the length parameter is mostly declared as COMP in COBOL

Post 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?
William Collins
Global Moderator
Global Moderator
Posts: 490
Joined: Sun Aug 25, 2013 7:24 pm

Re: Why the length parameter is mostly declared as COMP in COBOL

Post 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.
Post Reply

Create an account or sign in to join the discussion

You need to be a member in order to post a reply

Create an account

Not a member? register to join our community
Members can start their own topics & subscribe to topics
It’s free and only takes a minute

Register

Sign in

Return to “IBM COBOL, GnuCOBOL (OpenCOBOL), OOCobol.”