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!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
PD6.2?
- Thread starter nxm150
- Start date
- Thread starter
- #3
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?
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?
- Thread starter
- #5
- Thread starter
- #7
- Thread starter
- #9
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.
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.
- Thread starter
- #11
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.
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.
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
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
- Thread starter
- #13
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).
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).
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.
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.
- Thread starter
- #15
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.-
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.-
- Thread starter
- #17
- Thread starter
- #18
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.
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.
(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.
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.
- Status