Trouble with using OCONV is if the correlative contains a field number it
doesn't know what to do with it.
We have used REFORMAT to get data using dictionaries. Made a file per user,
and put the output into the file then read it back.
HTH, Kate
----- Original Message -----
From: "Timothy Snyder" <[EMAIL PROTECTED]>
To: <u2-users@listserver.u2ug.org>
Sent: Friday, September 01, 2006 1:57 PM
Subject: Re: [U2] Using DICT items in basic program
[EMAIL PROTECTED] wrote on 08/31/2006 07:03:29 PM:
The magic is to take the TCL statement, derive the filename (CUSTOMER)
and
using READNEXT, acquire each of the item id's from the SSELECT
statement.
Then I generate very tiny English statements of the form:
EXECUTE "LIST FILE "ID" NAME ID-SUPP COL-HDR-SUPP {any other necessary
suppressors}" CAPTURING X
If I'm reading this correctly, you're performing multiple executes for
each record in the file. In the example you provided, you would be
performing one execute each for NAME, CSZ, PHONE, CONTACT, and
AGED.BALANCE. If you're processing a million records, that means you'll
be performing FIVE-MILLION executes!!!
Maybe I've misunderstood what you're doing. But if not, I don't recommend
this approach. The overhead of performing that many executes is
staggering. I had a customer that had a process that was running in eight
hours, and they desperately wanted to get it down to four hours. It was
consuming an entire CPU and imposing significant I/O wait times that
impacted system-wide performance. I found where the program was spending
most of its time and CPU cycles - it was in a routine that was performing
executes to locate a value within an index and read through that. I
changed it to eliminate the executes and use intrinsic basic functions
instead - nothing else was changed. It went down to twenty minutes - much
better than they had hoped for. CPU and disk consumption became
insignificant. Executes are a wonderful thing, but they are very
expensive operations when performed many times. By adding the capturing
clause, you're adding even more overhead.
-------
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
-------
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
