Defining picture clause for a var having more than 31 digits

sindhuvava · New User Joined: 05 Dec 2006 Posts: 17 Location: Chennai

hi,

Can anyone help me , what picture clause have to be defined for a variable having a value more than 31 digits.To my knowledge i am aware that cobol will supports only up to 18 digits to the maximum in a variable.
In my requirement i have a value havin 18 digits before decimal point and 17 digits after decimal point.
I tried with many options but so far nothin have worked out.

William Thompson · Posted: Thu Jan 18, 2007 8:14 pm

If you are going to need to do arithmetic against it, you can't directly. If you de need to you could split it up, say s9(18) and s9v9(17) and do the math on each and resolve the extra position in the decimal one back to the other.

UmeySan · Posted: Thu Jan 18, 2007 8:52 pm

Hi !

I remember the compiler option ARITH(EXTEND).

With that COBOL for OS/390 supports 31 digit numbers. Packed and zoned decimal numbers may contain up to 31 digits.

I never tried it, cause there had been no need to do so.

So, plse search for that option.

Regards, UmeySan

dick scherrer · Posted: Thu Jan 18, 2007 9:54 pm

Hello,

Please post some sample data that shows what kind of numbers you are working with that require both 18 digits before the decimal and 17 digits after the decimal.

An alternative is to use floating-point.

sindhuvava · New User Joined: 05 Dec 2006 Posts: 17 Location: Chennai

hi,

this is the sample data which i am presently trying

00000000000000000.0485817382812
00000000000000000.0027688476562
00000000000000000.0000525390625

In this i have to check whether the usage value is negative and if it is negative i have to multiply it by -1.so if the value is negative i have to multiply the integer part by -1.so if fir eg i have a value as
-00000000000000000.0485817382812,and if i am splittin the value in to two parts based on the decimal,then i shd do -1*00000000000000000 and it will give a result 0.but i wants it as 00000000000000000.

can anyone help in this one

dick scherrer · Posted: Fri Jan 19, 2007 10:48 am

Hello,

Will the value to the left of the decimal ever be non-zero?

If the result of an arithmetic operation is zero it is the same whether it is 0 or 00000000000000000. The code won't know the difference. The difference in which value you "see" will depend on what picture you use to format the number.

I may be misunderstanding what is needed and if so, please clarify.

sindhuvava · New User Joined: 05 Dec 2006 Posts: 17 Location: Chennai

hi,

the left of the decimal may or may not be zeroes...it will depends upon the usage value gettin frm the input.actually as per the reqiirement its not possible to consider 00000000000000 will be equal to 0.the output of the program is further send to another feed for future billing purposes and there ,it will be defined to accept 0000000000000.we shd not get the result as 0.0485817382812 instead of 00000000000000000.0485817382812.
if the value before decimal is something like 00000000000000230.0485817382812 then th e result shd be the same.

William Thompson · Posted: Fri Jan 19, 2007 2:46 pm

Am I missing something or are you just looking for negative values and when found, making it positive?

sindhuvava · New User Joined: 05 Dec 2006 Posts: 17 Location: Chennai

The compiler option ARITH(EXTEND) is working fine.
Thanks

William Thompson · Posted: Fri Jan 19, 2007 3:09 pm

UmeySan · Posted: Fri Jan 19, 2007 3:19 pm

Hi !

That's what i mentioned, and so what, it works !
Anyway, everywhere at some point there's a final cut.

Regards, UmeySan

mmwife · Super Moderator Joined: 30 May 2003 Posts: 1592

Sindy didn't say if the dec pt was implied or not, but counting the digits in the values he supplied, I get 30 digits and the # of digits is what's important here.

I use this old trick to force a positive value:

Define the variable as PIC 9(n)V9(n) (or redefine the orig PIC). Don't use the "S".
Then move the variable to itself (use the redef name if you redefed it). This strips the sign and doesn't require an IF stmt.

Technically, the result is "unsigned", but it's treated as a positive #.