We already have improvements to cut the open/close/free overhead.
The ca. 800 little tables are put into 8 large containers, which have
a (sort of) directory at the beginning, so that there is only one open
for the container. The open is done only once, and the containers stay
open throughout the whole process (all day long). So open/close/free
is no concern. Same goes for Windows/Linux/Unix.
I have still to examine if the z/OS record sizes fit well to the fread
sizes.
I did not do the customization to z/OS, only the original design for the
other platforms. z/OS Unix is an option, but there are customers out
there, that want the files to be "classic" OS files.
(there are 18 different platforms where this applications runs on,
including Solaris and BS/2000).
Kind regards
Bernd
Am 21.05.2013 14:38, schrieb Paul Gilmartin:
On Tue, 21 May 2013 09:55:51 +0200, Bernd Oppolzer wrote:
Slightly drifting topic:
We use fseek / ftell / fread to do the file I/O. The files are normal sequential
OS files.
Sounds like the worst of both worlds. Have you tried it with normal
z/OS UNIX files? The kernel may do the caching for you.
I've found that for large numbers of small files z/OS UNIX files
vastly outperform legacy data sets. The allocate/open/close/free
overhead is brutal.
-- 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
