× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



It is the UNIQUE constraint that causes this effect.

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"The efficiency of our criminal jury system is only marred by the difficulty
of finding twelve men every day who don't know anything and can't read."
-- Mark Twain
Also - is it unique keys, or any keys? I'm guessing any, but I thought
I'd verify.

Thanks,
Kurt



Are there unique keys on the table? That will change it to single
record
I/O.

On Mon, Jun 7, 2010 at 4:22 PM, Kurt Anderson
<kurt.anderson@xxxxxxxxxxxxxx>wrote:

I have a file defined in a program as:

FFileA O A E K Disk

From my understanding, writes to this file should be blocked.
However
when I look at the I/O for the job, the I/O count and the RRN is
always
equal. For comparison, reading a file that's blocked has a lower I/O
count
than the current RRN.

Is this a matter of me not understanding the I/O screen (when looking
at
the job as it is running), or is this file actually writing a single
record
at a time?

According to this document, I feel that these writes should be
blocked.

https://www-
912.ibm.com/s_dir/slkbase.NSF/1ac66549a21402188625680b0002037e/d6738e1c
d37e1f33862565c2007cef79?OpenDocument
"All high-level language programs (HLLs) use blocking at certain
times and
use single record I/O at other times, based on program
specifications.
Because blocking takes less system resources to perform a single I/O,
a
program that blocks performs better and uses less system resources.
The
default for the HLL uses record blocking if opening a file for output
only
(write) or input only (read)."



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.