After the MOVE, the value contains an extra zero

rdasari · New User Joined: 09 Aug 2006 Posts: 5

Hi,

I am trying to move a 15 digit value from PIC X(16) to PIC 9(16), after the move the value contains an extra zero in the right most digit. Can any one tell how to avoid getting the zero?

DavidatK · Posted: Sat Sep 30, 2006 1:54 am

If you are using ecobol you can use the numval function

COMPUTE VAR-9 = FUNCTION NUMVAL (VAR-X)

See link NUMVAL

Dave

rdasari · New User Joined: 09 Aug 2006 Posts: 5

I tried this,

COMPUTE VAR-9 = FUNCTION NUMVAL (VAR-X)

then it is adding zero at left most digit of the destination varible. I tried NUMVAL-C, Integer functions too but no use.

guptae · Posted: Sat Sep 30, 2006 10:51 am

HI rdasari,

After moving X(16) TO 9(16) Move it to Z9(15).

Hope it will work.

Let us know ur result

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

Hi rdasari,

As far as I can see, the NUMVAL solution should work. Perhaps the last pos in VAR-X doesn't contain a space, but a non-printable char (binary zeros?).

Display the VAR-X and turn hex on in SDSF and take a look. Who knows?

rdasari · New User Joined: 09 Aug 2006 Posts: 5

Hi,

The var-x is containing a space X'40', still if I use var-y=numval(var-9) its adding a zero at the begining of var-9.

var-x pic x(16) value is '123456789123456'
var-y pic 9(16).

var-x= numval(var-y)
then var-y contains '0123456789123456'

If do not use numval and i do normal move operaton then var-y contains
'1234567891234560'

both are not deserved results
thanks

MFRASHEED · Active User Joined: 14 Jun 2005 Posts: 186 Location: USA

Try this if target field can be modified and you always don't want zero at the end.

Define target field as:

rdasari · New User Joined: 09 Aug 2006 Posts: 5

Hi,

I tried 'BLANK WHEN ZERO' too.. the problem with this is

01 VAR-X PIC 9(16) BLANK WHEN ZERO
01 VAR-Y PIC 9(16)
01 VAR-Z PIC 9(16)

VAR-X = 123456789123456
MOVE VAR-X TO VAR-Y.
gives good result with VAr-Y. i.e 123456789123456 and a blank.

but when I move VAR-Y TO VAR-Z, the story repeats
VAR-Z contains on extra zero at the end. I could have used BLANK WHEN ZERO for VAR-Y too but I want to know why in a simple move between two varibles of 9(16), the value is changing. adding a zero at the end makes so much difference, is COBOL can't accomidate this simple move.

MFRASHEED · Active User Joined: 14 Jun 2005 Posts: 186 Location: USA

No new insight but few pointers:

Needless to say here are alignment rules:

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

Hi rdasari,

Sorry, I miss-read your 2nd post. The reason you get the trailing zero on the MOVE is that the receiving field is unsigned and requires an X'Fn' formatted char in the sign position. The move function changes the X'40' to X'F0' via an OI (or immediate) assembler inst to force an "unsigned" low order digit.

You might try this to by-pass the sign "fixing":

MOVE VAR-X TO VAR-9(1:)

CAN YOU TELL US WHY YOU WOULD WANT A SPACE IN A NUMERICALLY DEFINED FIELD? WHY NOT USE PIC X(16)? i DON'T THINK YOU CAN SUCCESSFULLY PERFORM ARITH OPS USING A PIC 9 FIELD W/A SPACE IN IT.

rdasari · New User Joined: 09 Aug 2006 Posts: 5

Hi,

This sounds funny but the requirement is like that. They want to use 9(16) for primary key which is an acct#. As of the this feild will contain only 15 digits and may be 16 digit in future.

We are sure that we are not going to perform any arthimetic operations with this feild, but still they want it to be numeric. I am just programer, its problem with HLD & LLD people.

Thanks,
RDasari.