Discussion:
EG Server File I/O error when processing large datasets.
(too old to reply)
Amber
2009-04-11 16:26:28 UTC
Permalink
Hi all, recentlly we have come to a very strange problem.
When we run a simle data step 'data xxx; set yyy;run;' , the following
error occurs:

There is an I/O error occured on file yyy,

And there are Windows System Event log entries logged by SAS:

Critical SAS error: z Read Access Violation In Task [ DOSSCHT )
Exception occurred at (ff3da3)

The compressed source dataset is about 5G, and we are using SAS 9.1.3
with SP4 on Windows 2003 Server Enterprise Edition R2. The physical
server is HP DL580 G5 machine, with a RIAD5 local array of 8 300G hard
disks. We create two partitions on the array, C: 200G, D: the left,
the Windows page file and SAS temporary files are all located on D:,
but the dataset can be processed correctlly when transfered to other
machines using FTP binary mode.
Michael Raithel
2009-04-11 17:18:46 UTC
Permalink
Dear SAS-L-ers,
Post by Amber
Hi all, recentlly we have come to a very strange problem.
When we run a simle data step 'data xxx; set yyy;run;' , the
There is an I/O error occured on file yyy,
Critical SAS error: z Read Access Violation In Task [ DOSSCHT
) Exception occurred at (ff3da3)
The compressed source dataset is about 5G, and we are using
SAS 9.1.3 with SP4 on Windows 2003 Server Enterprise Edition
R2. The physical server is HP DL580 G5 machine, with a RIAD5
local array of 8 300G hard disks. We create two partitions on
the array, C: 200G, D: the left, the Windows page file and
SAS temporary files are all located on D:, but the dataset
can be processed correctlly when transfered to other machines
using FTP binary mode.
Amber, that is strange indeed! You would seem to have a SAS temporary data library the size of Kansas, yet this looks a lot like a SAS space issue.

How about doing the following to help diagnose where the problem might be:

1. Double-check exactly where your SAS data library is actually being allocated. Is it indeed going to the D-drive? If so, has anybody hogged so much of the D-drive space that the SAS data set cannot uncompress out there?

2. Let's get rid of the possibility of some sort of permissions violation. Make sure that you can, indeed, open that SAS data set on the D-drive by coding the following:

options obs=100;
data xxx;
set yyy;
run;
options obs=max;

...so, if you are able to unload 100 observations from your compressed SAS data set to your D-drive A-OK, then that eliminates permission issues.

Amber, give these a whirl and let us know how you are faring. Best of luck!

I hope that this suggestion proves helpful now, and in the future!

Of course, all of these opinions and insights are my own, and do not reflect those of my organization or my associates. All SAS code and/or methodologies specified in this posting are for illustrative purposes only and no warranty is stated or implied as to their accuracy or applicability. People deciding to use information in this posting do so at their own risk.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Michael A. Raithel
"The man who wrote the book on performance"
E-mail: ***@westat.com

Author: Tuning SAS Applications in the MVS Environment

Author: Tuning SAS Applications in the OS/390 and z/OS Environments, Second Edition
http://www.sas.com/apps/pubscat/bookdetails.jsp?catid=1&pc=58172

Author: The Complete Guide to SAS Indexes

http://www.sas.com/apps/pubscat/bookdetails.jsp?catid=1&pc=60409

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Curious thing, habits. People themselves never knew they had them. - Agatha Christie
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Loading...