Portal | Manuals | References | Downloads | Info | Programs | JCLs | Mainframe wiki | Quick Ref

Author Message
rdasari

New User

Joined: 09 Aug 2006
Posts: 5

 Posted: Fri Sep 29, 2006 11:24 pm    Post subject: After the MOVE, the value contains an extra zero 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

Active Member

Joined: 22 Nov 2005
Posts: 700
Location: Troy, Michigan USA

 Posted: Sat Sep 30, 2006 1:54 am    Post subject: Re: MOVE startment problem 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

 Posted: Sat Sep 30, 2006 1:57 am    Post subject: Re: MOVE startment problem 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

Moderator

Joined: 14 Oct 2005
Posts: 1190
Location: Bangalore,India

 Posted: Sat Sep 30, 2006 10:51 am    Post subject: 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

 Posted: Sat Sep 30, 2006 7:11 pm    Post subject: 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

 Posted: Mon Oct 02, 2006 7:49 pm    Post subject: replay 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

Posted: Mon Oct 02, 2006 8:15 pm    Post subject: Re: After the MOVE, the value contains an extra zero

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

Define target field as:
 Code: 01  VAR-Y.                                            05 var-y1             PIC 9(15).                  05 var-y2             PIC 9 BLANK WHEN ZERO.
rdasari

New User

Joined: 09 Aug 2006
Posts: 5

 Posted: Mon Oct 02, 2006 8:24 pm    Post subject: Re: After the MOVE, the value contains an extra zero 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

Posted: Mon Oct 02, 2006 9:01 pm    Post subject: Re: After the MOVE, the value contains an extra zero

No new insight but few pointers:

Needless to say here are alignment rules:

 Code: Alignment rules                                                                                                                                        The standard alignment rules for positioning data in an elementary item    depend on the category of a receiving item (that is, an item into which    the data is moved; see "Elementary moves" in item MOVE).                                                                                                Numeric                                                                              For such receiving items, the following rules apply:                                                                                                    1.  The data is aligned on the assumed decimal point and, if                    necessary, truncated or padded with zeros.  (An assumed                    decimal point is one that has logical meaning but that does                not exist as an actual character in the data.)                                                                                                      2.  If an assumed decimal point is not explicitly specified, the               receiving item is treated as though an assumed decimal point               is specified immediately to the right of the field.  The                    data is then treated according to the preceding rule.                                                                                    Numeric-edited                                                                        The data is aligned on the decimal point, and (if necessary)               truncated or padded with zeros at either end, except when             editing causes replacement of leading zeros.

Few things to consider:

- Use copybook and define field with Blank Zero and this way you are consistent with its usage.
- Consider definition of field, why is defined a 9, in our shop we define field as 9's only when it is truly numeric. If field is some kind of indentifier (like Account identifier(number) etc) then it is defined as X.
mmwife

Super Moderator

Joined: 30 May 2003
Posts: 1592

 Posted: Tue Oct 03, 2006 7:51 am    Post subject: 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

 Posted: Tue Oct 03, 2006 8:38 pm    Post subject: 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.
 All times are GMT + 6 Hours
 Page 1 of 1

Search our Forum:

 Topic Author Forum Replies Posted Similar Topics RMM Cannot move a volume from SHELF l... tspr52 IBM Tools 0 Thu Mar 01, 2018 3:48 pm how can i move s9(9) to s9(9) usage comp HARENDRA CHOUDHARY COBOL Programming 3 Mon Nov 06, 2017 12:10 am Move from Comp3 variable to Edited Va... Revathy.nair0485 COBOL Programming 7 Fri Nov 03, 2017 3:30 pm Move from Comp3 variable to Edited Va... sreekusr COBOL Programming 8 Thu Aug 10, 2017 4:20 pm Extra character appears in file when ... Balu5491 All Other Mainframe Topics 1 Wed Jul 26, 2017 2:39 pm

 © 2003-2017 IBM MAINFRAME Software Support Division
 Job Vacancies | Forum Rules | Bookmarks | Subscriptions | FAQ | Polls | Contact Us