View previous topic :: View next topic
|
Author |
Message |
lfat
New User
Joined: 06 Oct 2006 Posts: 3 Location: Eire
|
|
|
|
Hi all Mainframers, this is my 1st post to the site as I've always searhed thru before in the past and found what I require, but this time no such lick.
I have written a program to update produc on our system with a new price.
One input driver file, key is product code.
When I find a matching code I then go and update the existing price on the production file with the new price required.
However, my output field is a PIC 9(6)V9(3) COMP, and my new price comes out as garbage. I've tried everything from
Inspect/String/Unstring and cannot get anything to work.
My layout/file is as below:
01 PR_REC.
03 PRCODE PIC X(7).
03 FILLER PIC X.
03 NEWPRICE PIC 9(9).
Not when I have my input PIC 9(6)V9(3) COMP it reads my input as 0.00
0012345 000006250
Note the price is 6.250
When I move this out to the PIC 9(6)V9(3) I get a binary number out.
As I've said, I've tried everything I know. I'm working on a VAX machine and can't build the i/p file as I'd like.
It's come from another source in a .txt file which I am reading in to the pgm and matching the key to the main file.
Can anyone help?
When I do - string newprice(1;6), '.', NEWPRICE(7;3) and move out I get rubbish.
Much appreciated. . . . . . |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
What do you mean by garbage? When you move a value of 6250 to 9(6)V9(3) COMP you should have an 8-byte value in hex of '000000000000186A' -- if you have this and think it is garbage, you really need to read the COBOL Language Definition of what a COMP field is.
Quote: |
When I move this out to the PIC 9(6)V9(3) I get a binary number out. |
Yep -- COMP fields are binary. If you didn't get a binary number when you move to a COMP field, I would worry. So what it sounds like you're probably saying is that you don't understand COBOL formats for numbers and need to read the manual more.
Using STRING on the field makes no sense -- why would you do that? |
|
Back to top |
|
|
lfat
New User
Joined: 06 Oct 2006 Posts: 3 Location: Eire
|
|
|
|
Well I don't mean garbage, I mean my value in isn't my value out. I'm not looking for a fallout here, I'm raising a query. I don't expect to get the same o/p when I'm moving a different input format to that off the output.
My value on the o/p is +808464.432
What I'm saying is I think I've tried everything to get my value on output as value on input. But I can't seem to convert it anyway I try.
Thanks |
|
Back to top |
|
|
Arun Raj
Moderator
Joined: 17 Oct 2006 Posts: 2481 Location: @my desk
|
|
|
|
lfat,
It would be better if you post the COBOL declaration of your input and output fields, your actual output and the expected output with examples. |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
ignoring the fact that you are not using signed field convention-
if your input is declared as PIC 9(9) - when it is actually 9(6)V9(3), simply compute output-field = input-field / 1000 - which is probably easier than designing the input data layout properly. |
|
Back to top |
|
|
lfat
New User
Joined: 06 Oct 2006 Posts: 3 Location: Eire
|
|
|
|
Hi, I've just done that and I'm fine. Rushing a last min thing here. Thanks for all the replies guys. Apols if I wasted your time, I just overlooked what I was doing and missed the solution!!
Thanks again. |
|
Back to top |
|
|
|