|
View previous topic :: View next topic
|
| Author |
Message |
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
| Prasanya wrote: |
I have already mentioned its a FBA file and am sure about this. I do have a proper understanding if the system that am working in. Please keep in mind that its a log file created by SAS.
Do you need some kind of proof to be sure that its an FBA file?
Hi Arun,
I have already tried using position 3 but i dint get a match for 'ERROR:' |
Yes, i would like to see some proof if it is a FBA file.
The SAS log is normally a VBA dataset. |
|
| Back to top |
|
 |
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
| Quote: |
Please keep in mind that its a log file created by SAS.
|
the answers You got were because we kept that in mind
from the SAS manual
| Quote: |
SAS Log File
The SAS log file is a temporary physical file that has a DDname of SASLOG in both the SAS cataloged procedure and the SAS CLIST. In batch mode, the SAS cataloged procedure assigns default data control block (DCB) characteristics to this file as follows:
BLKSIZE=141
LRECL=137
RECFM=VBA |
repeat on
and that explain why..
the first sample (input) looks right,
the second sample (output) looks wrong
it' s what happens when You process a VB dataset with a FB dcb |
|
| Back to top |
|
|
Prasanya
New User
Joined: 04 Jun 2007
Posts: 34
Location: Chennai
|
|
|
|
This is the datset information of the SAS log file
| Code: |
General Data Current Allocation
Management class . . : DEV Allocated blocks . : 2
Storage class . . . : DEV1000 Allocated extents . : 1
Volume serial . . . : 9SDS6D
Device type . . . . : 3390
Data class . . . . . : ADDDSORG Current Utilization
Organization . . . : PS Used blocks . . . . : 1
Record format . . . : FBA Used extents . . . : 1
Record length . . . : 255
Block size . . . . : 27795
1st extent blocks . : 2
Secondary blocks . : 300
Data set name type : SMS Compressible : NO
Creation date . . . : 2010/02/03 Referenced date . . : 2010/02/10
Expiration date . . : ***None***
|
|
|
| Back to top |
|
|
Prasanya
New User
Joined: 04 Jun 2007
Posts: 34
Location: Chennai
|
|
|
|
| I tried copying the input file to a VB file as well and my output still looks similar to the previous output. |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
Looks FBA to me.
Now i would like to see the JCL allocation of this dataset. |
|
| Back to top |
|
|
Prasanya
New User
Joined: 04 Jun 2007
Posts: 34
Location: Chennai
|
|
|
|
| This file is created by a third party production system so i cant view the JCL |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
Can you execute the following IDCAMS and show the output ?
| Code: |
// EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=A
//indd DD DSN= ... (describes the input data set)
//SYSIN DD *
PRINT -
INFILE(indd) -
DUMP -
COUNT(4)
/*
|
|
|
| Back to top |
|
|
Prasanya
New User
Joined: 04 Jun 2007
Posts: 34
Location: Chennai
|
|
|
|
This was the 1st record in the spool.
| Code: |
0RECORD SEQUENCE NUMBER - 1
000000 000140C6 000000FF 81F1F139 8DE38885 40E2C1E2 40E2A8A2 A385941B 9EF0F17A *.. F.....11..T.. SAS S.......01:*
000020 F0F040E3 A485A284 81A86B40 C6858299 A48199A8 40F26B40 F2F0F1F0 787978FE *00 T......, F....... 2, 2010....*
000040 00C2D5D6 E3C57A40 C39697A8 99898788 A3404D83 5D40F2F0 F0F260F2 F0F0F340 *.BNOTE: C........ (.) 2002-2003 *
000060 82A840E2 C1E240C9 95A2A389 A3A4A385 40C99583 4B6B40C3 8199A86B 40D5C36B *.. SAS I........ I..., C..., NC,*
000080 40E4E2C1 4B78BA00 98D5D6E3 C57A40E2 C1E2404D 995D40F9 4BF1404D E3E2F1D4 * USA.....NOTE: SAS (.) 9.1 (TS1M*
0000A0 F35D78E4 06AFD389 838595A2 858440A3 9640C2C1 D5D240D6 C640C1D4 C5D9C9C3 *3).U..L....... .. AAAAAAAAAAAAAAA*
0000C0 C140D5C1 6B40E289 A38540F0 F0F5F3F4 F4F8F0F0 F14B78C7 00AAD5D6 E3C57A40 *A NA, S... 0053448001..G..NOTE: *
0000E0 E38889A2 40A285A2 A2899695 4089A240 85A78583 A4A38995 87409695 40A388 *T... ....... .. ......... .. .. *
|
Do you want the other records as well? |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
Looks like the first 4 bytes are a BDW and the second 4 bytes are the RDW (FF = 255 = lrecl)
So i conclude that the file is NOT a FBA file, and the supplier used the
wrong DCB values for the external SASLOG dataset. |
|
| Back to top |
|
|
Prasanya
New User
Joined: 04 Jun 2007
Posts: 34
Location: Chennai
|
|
|
|
Hi PeterHolland,
Thank you. Your conclusion was right, i confirmed with the third party system and they said that they have given file format as FBA inthe JCL creating the file.
But they will not be able to change it as the system has been in production for a few years. So is there any way to process this file |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
| Prasanya wrote: |
Hi PeterHolland,
Thank you. Your conclusion was right, i confirmed with the third party system and they said that they have given file format as FBA inthe JCL creating the file.
But they will not be able to change it as the system has been in production for a few years. So is there any way to process this file |
Not be able to change their JCL????
I wouldnt trust a company that delivers f.....d up data.
There are of course solutions to process that dataset, but I dont know
what kind of tooling is at your disposal.
If i had been confronted with this mess, i would have used Easytrev, SAS, IDCAMS, REXX.
And that would have been trial and error attempts. I vaguely remember
being confronted once with the same problem, but dont remember exactly
how i solved that. I think i used before mentioned tools.
But do insist on that 3rd party to supply valid data.
Cause we have here a SISO situation.l |
|
| Back to top |
|
|
Prasanya
New User
Joined: 04 Jun 2007
Posts: 34
Location: Chennai
|
|
|
|
| Thanks for your reply. Among the tools that you have mentioned, I can use Easytrieve and IDCAMS. PLease let me know if you remember how you solved a similar problem. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
| From the posted data record, it appears to be some type of SAS database. In that case, there are probably no independent tools (other than SAS) that will be able to make sense of the data. SAS formats are proprietary to SAS and can be very complex. Neither Easytrieve nor IDCAMS would do much good with a SAS database. |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
| Robert Sample wrote: |
| From the posted data record, it appears to be some type of SAS database. In that case, there are probably no independent tools (other than SAS) that will be able to make sense of the data. SAS formats are proprietary to SAS and can be very complex. Neither Easytrieve nor IDCAMS would do much good with a SAS database. |
Hello Robert,
this is NOT SAS data. This is just a SASLOG (normally sysout data) routed
to a external file with the wrong DCB information supplied in the JCL.
So the internal data is VBA while the DCB info says its FBA.
So processing this data is possible.
Has nothing to do with internal SAS data and/or formats. |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
Prasanya
i have some doubts now after reflecting your problem and my answer.
Can you run that idcams again with DCB=RECFM=U added to your input,
and show me the dump output? |
|
| Back to top |
|
|
mmwife
Super Moderator
Joined: 30 May 2003
Posts: 1592
|
|
|
|
| I think it's a DCB merge problem where the SAS pgm has the file defined as variable. That will overide whatever the JCL may contain. |
|
| Back to top |
|
|
Prasanya
New User
Joined: 04 Jun 2007
Posts: 34
Location: Chennai
|
|
|
|
Hi PeterHolland,
This is the first record in the spool, with DCB=RECFM=U
| Code: |
0RECORD SEQUENCE NUMBER - 1
000000 000140C6 000000FF 81F1F139 8DE38885 40E2C1E2 40E2A8A2 A385941B 9EF0F17 *.. F.....11..T.. SAS S.......01:*
000020 F0F040E3 A485A284 81A86B40 C6858299 A48199A8 40F26B40 F2F0F1F0 787978F *00 T......, F....... 2, 2010....*
000040 00C2D5D6 E3C57A40 C39697A8 99898788 A3404D83 5D40F2F0 F0F260F2 F0F0F34 *.BNOTE: C........ (.) 2002-2003 *
000060 82A840E2 C1E240C9 95A2A389 A3A4A385 40C99583 4B6B40C3 8199A86B 40D5C36 *.. SAS I........ I..., C..., NC,*
000080 40E4E2C1 4B78BA00 98D5D6E3 C57A40E2 C1E2404D 995D40F9 4BF1404D E3E2F1D * ABC.....NOTE: SAS (.) 9.1 (TS1M*
0000A0 F35D78E4 06AFD389 838595A2 858440A3 9640C2C1 D5D240D6 C640C1D4 C5D9C9C *3).U..L....... .. AAAAAAAAAAAAAA*
0000C0 C140D5C1 6B40E289 A38540F0 F0F5F3F4 F4F8F0F0 F14B78C7 00AAD5D6 E3C57A4 *A NA, S... 0053448001..G..NOTE: *
0000E0 E38889A2 40A285A2 A2899695 4089A240 85A78583 A4A38995 87409695 40A3888 *T... ....... .. ......... .. ...*
|
|
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
rereading the whole thread..
| Quote: |
| Thank you. Your conclusion was right, |
we had suggested the same conclusion a log time ago but looks like we simply wasted time by being respectful of your stubborness about being sure of... and not trusting our advice
while the second four bytes might represent a VB record
the first four bytes look like garbage
and the whole record content are the SASLOG lines all junked up
but wouldn' t it be time to ask Your support about the whole thing ???
doing remote debugging is very difficult more that fifty posts without resolving the issue are a proof
also a forum is not the best place to find a solution for a poor design .. the third party supplying f****d up data
we have been telling for a long time that Your perception is just wrong
even if the organization is FB, the content is not the one of a proper FB formatted dataset
look carefully in the data You provided an You will see some non printable bytes |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
Hi Enrico,
| Quote: |
look carefully in the data You provided an You will see some non printable bytes
|
Thats because a lot of characters are lowercase.
For the rest i said the same in one of my comments.
But the 3rd party that f*****d up royally doesnt want to
change their methods (thats what the TS said).
So after seeing the second output their is no way to recover the data.
Maybe the TS can force on management level the 3rd party in supplying
valid data. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
Hi Peter!
I have noticed the lower case thing but ,
there are also some x'00' chars spread around, look before the "NOTE" chars
that' why I said that the mess is a SASLOG all junked up
unless they change the DCB, analyzing by any mean junked up data will not be easy |
|
| Back to top |
|
|
|
|
