IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

What does PIC'(10)9V9T' mean?


IBM Mainframe Forums -> PL/I & Assembler
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
r2k1984

New User


Joined: 21 Jun 2005
Posts: 69
Location: chennai

PostPosted: Mon Dec 12, 2011 11:51 pm
Reply with quote

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
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Tue Dec 13, 2011 12:02 am
Reply with quote

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
View user's profile Send private message
Akatsukami

Global Moderator


Joined: 03 Oct 2009
Posts: 1787
Location: Bloomington, IL

PostPosted: Tue Dec 13, 2011 12:06 am
Reply with quote

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
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Tue Dec 13, 2011 12:43 am
Reply with quote

the real culprit is the picture clause
Code:

PIC '(10)9.9'


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
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Tue Dec 13, 2011 1:11 am
Reply with quote

I stand corrected, thx Robert,
it will compile in COBOL and probably PL1.

my fault for the postings, wrong forum.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA

PostPosted: Tue Dec 13, 2011 1:26 am
Reply with quote

On the other hand, (10)9V99 is a three byte variable compared to 9(10)V99.
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Tue Dec 13, 2011 1:30 am
Reply with quote

ok, i'll bite:
why is (10)9V99 a three byte variable?
how does the compiler treat the (10) ?
Back to top
View user's profile Send private message
Akatsukami

Global Moderator


Joined: 03 Oct 2009
Posts: 1787
Location: Bloomington, IL

PostPosted: Tue Dec 13, 2011 1:49 am
Reply with quote

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
View user's profile Send private message
r2k1984

New User


Joined: 21 Jun 2005
Posts: 69
Location: chennai

PostPosted: Tue Dec 13, 2011 4:45 am
Reply with quote

Thanks for your inputs.

So final outcome of this discussion is the field has to be defined as S9(10)V99?
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Tue Dec 13, 2011 5:18 am
Reply with quote

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
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Tue Dec 13, 2011 5:36 am
Reply with quote

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
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Tue Dec 13, 2011 6:11 am
Reply with quote

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
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Tue Dec 13, 2011 6:41 am
Reply with quote

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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> PL/I & Assembler

 


Search our Forums:

Back to Top