Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

Register Log in
  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

PD6.2?

Status
Not open for further replies.
nxm150

nxm150

Programmer
May 22, 2002
78
0
0
US
Can someone tell me what PD6.2 equates to in terms of a COBOL PIC definition? Also, is there a website that is a beginners guide to SAS?

Thanks!
 
Sort by date Sort by votes
pd is Packed Decimal

the 6 is the width in bytes and the 2 is the number places beyond the decimal point

I do not remember enough of cobol --- sorry ---

so a variable defined pd6.2 is set to 6543.21 would look like this
000531
00642C

This help?
 
Upvote 0 Downvote
I am looking at some SAS statements. I have a field in COBOL defined as PIC S9(9)V99 COMP-3.

The same field is defined as PD6.2 in SAS.

I am thinking this definition is wrong and the SAS should say PD5.2
 
Upvote 0 Downvote
I REALLY hate to ask a stupid question, but have you looked at the data in hex?

I seem to remember that the way that the data is physically stored and how Cobol's output pic looked at things were two different animals - for example - the S for the sign --- physically it is stored with the C or the D in the end byte.

So - in other words - is the Cobol pic just how the variable is output or is that how it is input (sorry - been a LONG time for Cobol)?

In SAS you can also have ZD (zoned decimal) where the numeric data is really numbers in character format. how is the data stored?
 
Upvote 0 Downvote
looks like a pd6 to me --- so I think the SAS definition is right if this is 48.58

this all help??
 
Upvote 0 Downvote
OK. Thanks. It just looked weird as I thought the definition was wrong. I will look elsewhere in the SAS statements to see why it is not working correctly.
 
Upvote 0 Downvote
what kind of results are you getting (or not getting)? You can always post the code here for us to look at too...
 
Upvote 0 Downvote
Can you post your email address and I will send the error log? I don't want to post it publicly. Thanks!
 
Upvote 0 Downvote
would, but one of the policies here says 'don't post your e-mail address or phone numbers because it attracts spammers to the forums and we do NOT want them around.' and I use these forums ALOT for Crystal, Great Pains, SQL... so I don't want to do something wrong.

just put the message you are getting (not the whole log) --- my bet is that if you are getting an error that it is saying that a numeric is trying to be read and it can not be read (or some garbage like that). If you are uncomfortable with putting things out here do this - check the input record - if you are on a mainframe SAS environment is the record a FBA (where the input columns are what they look like when you view a file) or an VB (where the first bytes are the length of the record). Because you looked at in HEX, I am guessing that it is a mainframe (wow - long time going back to my mainframe days) and I remember that always messing my people up.
 
Upvote 0 Downvote
Our system is providing the user with a output file (VB). I have mapped this file and record in question against the COBOL copybook in fileaid and all the fields are in the correct position. We have also provided them with the SAS statements for their use but I guess the SAS has a bug in it. The users first error is not occurring until he reads record number 333.

NOTE: INVALID DATA FOR E01330000 IN LINE 333 429-441.
NOTE: INVALID DATA FOR SRVC_CNT IN LINE 333 544-545.
NOTE: INVALID DATA FOR LINEPMT IN LINE 333 599-604.
NOTE: INVALID DATA FOR LBENPMT IN LINE 333 605-610.
NOTE: INVALID DATA FOR LPRVPMT IN LINE 333 611-616.
NOTE: INVALID DATA FOR LDEDAMT IN LINE 333 617-622.
NOTE: INVALID DATA FOR LPRPDAMT IN LINE 333 624-629.
NOTE: INVALID DATA FOR COINAMT IN LINE 333 630-635.
NOTE: INVALID DATA FOR LLMTAMT IN LINE 333 636-641.
NOTE: INVALID DATA FOR LINT_AMT IN LINE 333 642-647.
NOTE: INVALID DATA FOR LBLD_DED IN LINE 333 660-661.
NOTE: INVALID DATA FOR LSBMTCHG IN LINE 333 662-667.
NOTE: INVALID DATA FOR LALOWCHG IN LINE 333 668-673.
NOTE: INVALID DATA FOR LAB_AMT IN LINE 333 684-689.
NOTE: INVALID DATA FOR MTUS_CNT IN LINE 333 694-695.
NOTE: INVALID DATA FOR ANSTHUNT IN LINE 333 703-704.
NOTE: INVALID DATA FOR DME_PURC IN LINE 333 715-720.
NOTE: INVALID DATA FOR NCSTY_MO IN LINE 333 721-722.
 
Upvote 0 Downvote
ah Fileaid - I knew it well -- loved it

look at records 330-335 in fileaid or in just a straight browse --- anything weird changing? I would specifically look at the record length as well as the position of var E01330000

this really looks like a data problem to me and not a sas issue
 
Upvote 0 Downvote
Position 427 is the beginning of the variable part of my record. I notice in my COBOL defintion for one of my OCCURS clause it says 'OCCURS 0 - 30 times' but the SAS is set up for 99 OCCURANCES. Should the SAS be changed to 30 OCCURANCES? The other OCCURS clause and the SAS definiton have the same number of occurances.

IF CNT GT 0 THEN DO;
ARRAY IND{*} $ 1 ND01-ND99;
ARRAY CD{*} $ 2 CD01-CD99;
ARRAY DT{*} $ 8 DT01-DT99;
DO _I_ = 1 TO CNT;
INPUT
IND{_I_} $CHAR1.
CD {_I_} $CHAR2.
DT{_I_} $CHAR8.
@;
END;
END;

COBOL definition -

06 GRP OCCURS 0 TO 30 TIMES
DEPENDING ON CNT
OF REC.
08 IND PIC X.
08 CD PIC XX.
08 DT PIC 9(8).
 
Upvote 0 Downvote
all the array is doing is reading in the number of variables up to whatever CNT is --- none of those would have anything to do with the invalid data.
plus - this is reading in char data --- not numeric

what does CNT look like on the record or where did it come from?

when the rest of the record is not used (say we really only have 20 occurances) is the rest of the occurances hex 0 or are they numeric 0
000000 000000
000000 -or 00000C

If it looks like the first, SAS is trying to read the last half of the byte for the sign and giving you an error.
 
Upvote 0 Downvote
CNT is in the fixed portion of the record.

FF
01
 
Upvote 0 Downvote
so - count is a char 1 (you read it is as a ZD2.0 in SAS?)

check record 333 - is the second number that is suppose to be read in hex 0 (no C or D at the end and true varying record length) or are all of the fields past that point looking like numbers, but 0?

Fileaid is smart enough to stop at the end of the variable record, go into TSO browse on the file and turn hex on - that will show you... if you are telling SAS to read in a number (pd6.2) and the record is hex 0 (null) at that point you need to do some fancy stepping to get it to read the variable record.-
 
Upvote 0 Downvote
Count is
@414 CNT 2.

I am not following your 2nd sentence.

The fields that SAS defines as PD6.2 show up as
000000
00000C
when zeroes

 
Upvote 0 Downvote
We have figured out the problem. I was looking at the SAS code that we had on the mainframe, not what he downloaded. Apparantly a line was added when he downloaded his file

IF CNT GT 0 THEN DO;
ARRAY IND{*} $ 1 IND01-IND99;
ARRAY CD{*} $ 2 CD01-CD99;
ARRAY DT{*} $ 8 DT01-DT99;
DO _I_ = 1 TO CNT;
INPUT
IND{_I_} $CHAR1.
CD {_I_} $CHAR2.
E01330000 <==================== extra line
DT{_I_} $CHAR8.
 
Upvote 0 Downvote
(sry missed the response before this one - no email, hmmm)

kewl - always fun to debug other's code...even when they tell you that you are looking at the right stuff.

It took me back a few years to think about a lab work database, sas and a mainframe --- back to the real world now.
 
Upvote 0 Downvote
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top