|
View previous topic :: View next topic
|
| Author |
Message |
r2k1984
New User
.jpg)
Joined: 21 Jun 2005
Posts: 69
Location: chennai
|
|
|
|
Hi,
I have a field declaration for the one of the input file where it is having 11 digit number and a character at last for this field.
I have moved the value to another field with declaration as PIC '(10)9.9'
Is that correct?
For example value for the input field is "00000008692G" and i'm getting output as 869.2 .
Regards,
Ram |
|
| Back to top |
|
 |
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
I guess it is the gold-old-sign. If you look at the value with HEX ON you'll see C8?
You are then chopping off your second decimal place when moving it to the other field. Whether or not that is what you want, I have no idea. |
|
| Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1787
Location: Bloomington, IL
|
|
|
|
| The "T" is an overpunched zoned decimal digit (one of those things that doesn't get a lot of use these days). As Sr. Woodger says, it's an actual digit, so you're losing significance. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
the real culprit is the picture clause
it is not signed and it should be......
as well as the PIC Clause (10)9... is invalid and will not compile.
actually you also need to define the source field with a sign,
something like S9(10)V9
and then move to an Z(09)9.9-
using a negative sign will only display those that are negative,
which makes it easier to read. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
I stand corrected, thx Robert,
it will compile in COBOL and probably PL1.
my fault for the postings, wrong forum. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
| On the other hand, (10)9V99 is a three byte variable compared to 9(10)V99. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
ok, i'll bite:
why is (10)9V99 a three byte variable?
how does the compiler treat the (10) ? |
|
| Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1787
Location: Bloomington, IL
|
|
|
|
| dbzTHEdinosauer wrote: |
ok, i'll bite:
why is (10)9V99 a three byte variable?
how does the compiler treat the (10) ? |
I believe this to be a misinterpretation of how PL/I handles the declaration (it may be different in COBOL). I wrote:
| Code: |
FOO: PROC OPTIONS (MAIN) REORDER;
DCL I PIC '(10)9.9';
DCL P FIXED DEC (11,1) INIT (-123.4);
I = P;
END FOO; |
In the automatic variable map it gives:
| Code: |
OFFSET (HEX) LENGTH (HEX) NAME
98 10 #MX_TEMP1
A8 6 P
B0 C I
BC D _temp1 |
I occupies 12 bytes, as expected. Using a V instead of a period would give 11 bytes, since the decimal point is only assumed (PL/I period in a picture has alignment power, IIRC). |
|
| Back to top |
|
|
r2k1984
New User
Joined: 21 Jun 2005
Posts: 69
Location: chennai
|
|
|
|
Thanks for your inputs.
So final outcome of this discussion is the field has to be defined as S9(10)V99? |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
What you gave in the subject for this topic seems valid PL/I for describing your data field on you file. In Cobol, the equvaltent would be S9(10)V99. I don't know if there is a different way to define it in PL/I.
What you do with it then, depends on you. It is a signed numeric field with 10 digits in front of an implied decimal place, and two digits after the implied decimal place. The "letter" is how a positive 8 is represented in either of those fields (the PL/I or the Cobol).
If you "move" the field to something that has only one decimal place, you will "loose significance" as has been said. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| dbzTHEdinosauer wrote: |
ok, i'll bite:
why is (10)9V99 a three byte variable?
how does the compiler treat the (10) ? |
Looks like you were kinda right the first time.
| Language Reference wrote: |
An unsigned nonzero integer enclosed in parentheses immediately following any of these symbols specifies the number of consecutive occurrences of that symbol.
|
The symbols are the usual suspects for the PIC clause. None in front of the "(10)". Seems to be "valid" but does not actually do anything.
Of course. A bug which doesn't cause anything to go wrong. It'll be an "Undocumented IBM Extension". |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
It seems that this bag-o-rubbish
| Code: |
| 01 WEIRD-MAN-WEIRD PIC (1)(2)(50)(2)999. |
quite happily compiles without even a hint of a scrinch of any sort of problem. Gives you a three-byte numeric, which behaves like a three-byte numeric.
EDIT: Not limited to numerics, everything seems to not go to pot. It would seem that to get this to not compile you'd have to exceed 50 characters in the PICTURE string.
Definitely an Undocumented IBM Extension. I don't know if it is a Recorded Undocumented IBM Extension, I can't locate it with google but haven't tried IBM :-) |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
I'm sure this used to give a "warning" in VS-COBOL.
| Code: |
PIC 9(6).99.
PIC (6)Z.99. |
I received a spec for a program over the 'phone from my boss, the report was needed the following day. He said the results of testing looked good, it was a pity that one field wasn't edited, but that could wait.
I thought I'd "fix" the field before I went home, and wacked it into production (different days, no "cycle"). I knew I got a warning in the compile, but they don't matter, do they?
Damn thing said "PICTURE CLAUSE INVALID UNLESS" and then something to do with a PIC for old UK pounds, shillings and pence currency (I'm glad I missed out on them). "PIC 9 ASSUMED" the message ended. Having driven 250 miles home, my boss had to come in and fix it having rung up the operators at 4am to check it was OK.
I found the compile listing on my desk in the morning with a huge red circile around the message... boss didn't turn up until 11am.
I always checked warnings after that. |
|
| Back to top |
|
|
|
|
