If you used LRECL=1, then you did have a record boundary of 1, so it was doing fwrite() with a length of 1. This is because todsn() always uses QSAM. As it turns out, even with a rational DCB, the C library is more expensive than direct QSAM macros. For this reason, it is likely that a future version of Co:Z will bypass the C library for QSAM I/O.
On Fri, Oct 10, 2008 at 8:42 AM, John McKown <[EMAIL PROTECTED]> wrote: > On Fri, 10 Oct 2008 21:16:53 +0800, David Crayford <[EMAIL PROTECTED]> wrote: > >> >>CELHVnnn is an XPLINK condition handler. For example CELHV003 is the >>XPLINK runtime environment. Im not familiar with CELHV002 but it could >>be that the SSL hashes are a CPU hog. If you sending a file that's in a >>zFS or HFS cached it may not I/O bound... > > I got some advice on another forum about this. The output is a "byte stream" > with no record boundries, pe se. In my job, I had > DCB=(RECFM=FB,LRECL=1,BLKSIZE=0). I changed that to > DCB=(RECFM=U,BLKSIZE=27998). The CPU usage on the exact same job went from > 45.82 minutes to 1.33 minutes. Curiously, the elapsed time actually went up > somewhat. Probably due to increased usage on the system during the second > test. > > -- > John > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
