Slightly drifting topic:
could it be that all this mess is responsible for z/OS file I/O not being
able to compete with (for example) Unix file I/O on different platforms?
We have a large application which needs high volumes of read only data.
In Unix and Windows environment, this data comes from files through a
table system with a main storage cache. In z/OS, up until now, we used DB2.
Now, to save CPU, we tried the Unix/Windows solution on z/OS too. The
result was: the CPU time was 25 % less, but elapsed time was significantly
higher, due to waits on the file I/O - although there was not much file
I/O -
most of it was reduced by the main storage cache. Anyway: we have to
experiment with larger cache sizes, but it appears that the z/OS file I/O
is the bottleneck.
We use fseek / ftell / fread to do the file I/O. The files are normal
sequential
OS files.
Kind regards
Bernd
Am 20.05.2013 22:13, schrieb Paul Gilmartin:
On Mon, 20 May 2013 13:45:46 -0500, Mike Schwab wrote:
Our section uses and IEBGENER proc to SYSOUT=(A,,INTRDR) and works just fine.
I have an EDIT macro that does very similar. _And_ it allocates the INTRDR
with attributes of the data set being submitted; it doesn't quietly truncate
my data to 80 columns.
--On Mon, 20 May 2013 21:39:01 +0200, Thomas Berg wrote:
3. We have always done like this, therefore it must be good.
http://www.thealders.net/humour/work/wk49.html
Yes, there is the presumed overallocation with release solution. But many (if
not most) allocations don't work with release at allocation.
In most cases this causes waste of space and still x37's.
And z/OS UNIX "cp" command allocates its output data set with RLSE,
then opens it several times. The first time it writes no data, guaranteeing
an x37 shortly thereafter. IBM took an APAR. First they suggested
secondary extents, then they agreed to provide a NORLSE option, with
RLSE remaining the default, just to be inconsistent with almost all MVS
allocation. cp() generates the RLSE TU only if the programmer specifies
SPACE. Go figger.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
