Re: Migrating ISAM to Relational Database



On 17 Apr, 13:04, "Roger While" <s...@xxxxxxxxxxxx> wrote:
"William M. Klein" <wmkl...@xxxxxxxxxxxxxxxxx> schrieb im Newsbeitragnews:_Z0Vh.410616$8a4.65355@xxxxxxxxxxxxxxxxxxxxxxxxx





Roger and Rick,
I do NOT think it should matter with this specific code, but are both of
you using ODOSLIDE or NOODOSLIDE?

I think there MIGHT be more of a difference if you

A) Put in some nested ODO's and/or data following the ODO (this would be
in the ODO structure - while adding the "same" data after the fixed OCCURS
or a nested OCCURS in the other example)

AND THEN tried it with both ODOSLIDE and NOODOSLIDE.

In other words have something like:
01 fixed-table.
03 fixed-entry occurs max-size
indexed by ft-index.
05 Field1 Pic X.
05 Nest1 occurs max-size
indexed by n1-index.
07 elem Pic x.
05 Field2 Pic X.

and

01 variable-table.
03 variable-entry pic x occurs 0 to max-size
depending on vt-length
indexed by vt-index
05 Field3 Pic X.
05 Nest2 occurs 0 to max-size
depending on vt-length2
indexed by n2-index.
07 elem2 Pic x.
05 Field4 Pic X

and make certain you move something to Field2 and field4 in the test
loops. (I would *expect* ODOSLIDE to be slower, - for variable occurrence
tables. However, only "real world" tests will prove me right or wrong.)

P.S. For *NON* Micro Focus users, the use of a 78-level for "max-size"
allows what LOOKS LIKE a variable name in the occurs depending on clause.
If you want to compile this in a "Standard" compiler

- delete 78 max-size value 8192
and
- change max-size to 8192 in the OCCURS clauses.

--
Bill Klein
wmklein <at> ix.netcom.com
"Roger While" <s...@xxxxxxxxxxxx> wrote in message
news:f01sjs$s28$03$1@xxxxxxxxxxxxxxxxxxxx

"Rick Smith" <ricksm...@xxxxxxx> schrieb im Newsbeitrag
news:1327rcs6m9u7207@xxxxxxxxxxxxxxxxxxxxx

"Alistair" <alist...@xxxxxxxxxxxxxxxxxxxxx> wrote in message
news:1176753130.901742.232580@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On 15 Apr, 03:26, "Pete Dashwood" <dashw...@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:

Huh?!! The processor time to deal with ODO is outrageous...compared
to
fixed
length.

I don't wish to get caught in the crossfire between the ODO:Fixed
Length:RDB camps but I have worked with ODO (and had no problems with
it except for the continual need to recalculate field positions, etc.,
and dumps) but has any one got any empirical data to prove their case?

Not my case to prove; but ...

Using Micro Focus COBOL 3.2.24 (Jun 1994)
-----
identification division.
program-id. A27B08.
data division.
working-storage section.
01 t-start.
03 t-start-hour pic 99.
03 t-start-minute pic 99.
03 t-start-second pic 99v99.
01 t-end.
03 t-end-hour pic 99.
03 t-end-minute pic 99.
03 t-end-second pic 99v99.
77 t-elapsed pic 9(7)v99.
77 t-elapsed-display pic z(6)9.99.

78 max-size value 8192.
01 fixed-table.
03 fixed-entry pic x occurs max-size
indexed by ft-index.
77 vt-length pic 9(4) comp-5 value max-size.
01 variable-table.
03 variable-entry pic x occurs 0 to max-size
depending on vt-length
indexed by vt-index.
77 repeat-count pic 9(8) comp-5 value 100000.
procedure division.
begin.
accept t-start from time
perform test-fixed-table
repeat-count times
accept t-end from time
display "fixed " with no advancing
perform display-elapsed
accept t-start from time
perform test-variable-table
repeat-count times
accept t-end from time
display "variable " with no advancing
perform display-elapsed
stop run
.
test-fixed-table.
perform varying ft-index from 1 by 1
until ft-index > max-size
move space to fixed-entry (ft-index)
end-perform
.
test-variable-table.
perform varying vt-index from 1 by 1
until vt-index > max-size
move space to variable-entry (vt-index)
end-perform
.
display-elapsed.
if t-start > t-end
move 86400 to t-elapsed
else
move 0 to t-elapsed
end-if
compute t-elapsed = t-elapsed
+ (t-end-hour - t-start-hour) * 3600
+ (t-end-minute - t-start-minute) * 60
+ (t-end-second - t-start-second)
end-compute
move t-elapsed to t-elapsed-display
display t-elapsed-display
.
-----

Results (in seconds)::
----- with BOUND directive
fixed 5.32
variable 4.89
----- with NOBOUND directive
fixed 4.89
variable 4.94
-----

ODO appears to be slightly faster with bounds
checking and slightly slower without.

Hmm, MF SE 2.2 on Linux :
simlinux:~ # cob -u -C BOUND dw.cob
simlinux:~ # cobrun ./dw
fixed 2.97
variable 2.97
simlinux:~ # cobrun ./dw
fixed 2.97
variable 2.97
simlinux:~ # cob -u -C NOBOUND dw.cob
simlinux:~ # cobrun ./dw
fixed 2.98
variable 2.97
simlinux:~ # cobrun ./dw
fixed 2.98
variable 2.98

No measurable difference there.

OK. Just tacked on another 03 field after the original 03 occurs entries and
moved something to that field in the perform loops -
simlinux:~ # cob -u -C BOUND -C NOODOSLIDE dw.cob
simlinux:~ # cobrun ./dw
fixed 2.99
variable 2.97
simlinux:~ # cob -u -C BOUND -C ODOSLIDE dw.cob
simlinux:~ # cobrun ./dw
fixed 2.98
variable 6.07

As Bill surmised, a considerable difference.

Roger- Hide quoted text -

- Show quoted text -

So definitely end of argument. ODO is a cpu hog.

.



Relevant Pages