Sorry I don't have a lot of hard data to back up my claim, but anecdotally,
a company I once worked for had a big customer file, and used KSAM for the
obvious partial-key lookups.  That involved having Name, Address,
CityStateZip or somthing? for the 3rd key; the objective was a customer
number.  Laying out the file with 3 keys,
Name    primary
Addr    secondary
CSZ     tertiary
Cust#
KSAM obviously has to maintain 3 separate indices, with ugly insertion times
for most.

We enjoyed vastly improved performance by rebuilding the file with one key
and 3 times as many records, with the key being one of Name Addr CSZ.  IIRC
we tacked a key-type field on the front, but I'm not convinced it was really
necessary.  Faster build, faster execution.

Again, pretty sketchy details here, but it seems valid.

You'll also discover that pre-sorting the records before loading them to
KSAM will vastly improve both load and execute time too.


btw I did actually read that quote in your orig post, but as it wasn't
credited to the TIMER intrinsic docs, I didn't give it much credence.  So
you get to laugh at me - I didn't bother to rtfm, I just guessed.

Tracy


> -----Original Message-----
> From: Peter Smithson [mailto:[log in to unmask]]
> Sent: Thursday, September 30, 2004 4:32 AM
> To: [log in to unmask]
> Subject: Re: More COBOL ineptness? TIMER intrinsic
>
>
>  Thanks for the reply but see this part of my posting -
>
> <I found the answer to this whilst making the posting but you
> might want
> to laugh at me anyway>
>
> and
>
>  "The system timer is reset to zero every 24-days at 12:00 midnight"
>
> I was unlucky on the 2nd run of the test program in that the system
> timer reset itself.  I was able to figure out the elapsed
> time with that
> info.
>
> The reasons for testing were covered in my original postings on the
> subject so I'll fill you in on what you've missed.  The code
> was written
> in September 2004 to emulate what an existing system does.
> It can test
> either the CK route or the COBOL VERB route.  Both routes are supposed
> to do the same thing.
>
> The customer is wanting to migrate to HPUX and wants to know how well
> both types of code will run on the migrated system.  He's got two ways
> of migrating and he wants to compare the two systems on HPUX.
>
> I've digressed slightly as I'm worried about the fact that he says the
> test program takes 1.5 hours to run on his MPE system but
> takes 18 hours
> on ours!  I didn't think our system was that old - it has a 180Mhz PA-
> RISC processor or two in there.  I'm worried that he won't go
> for either
> system as I doubt we'll get 1.5 hours on the new system although that
> isn't really the purpose of the test to compare HPUX with MPE (as
> they'll be using an RDBMS on HPUX so it's not really fair).  Still, if
> it's so much slower I doubt they'll be happy.
>
> What you've told me gives me an idea though.  The customer provided a
> build statement which created the files with two keys yet the
> COBOL code
> opens the file with only one key so it didn't work.  I had to
> change the
> COBOL code.  Perhaps I should have changed the BUILD
> statement if having
> 2 keys makes so much difference.
>
> I'll also run without those "exclusive" commands to see what
> difference
> that makes.  Just out of interest.
>
> Cheers
>
> Peter
>
> In article <[log in to unmask]>, [log in to unmask]
> says...
> > First off, make those comp fields S9(9) COMP, or better,
> S9(18) COMP, which
> > will ensure that you're not losing digits off the left end
> of your #s.
> >
> > Second, I can't tell what exactly your timers are looking
> at, but it seems
> > reasonable to guess that you ran the two programs in a job,
> back to back,
> > and the first number is your (Job) total wall time, and
> your second number
> > is (program) CPU secs.
> >
> > Just guessing, though.  you might want to check on what
> those intrinsics
> > really return - could be time of day, could be seconds
> after midnite, could
> > be what you want, maybe not.
> >
> > All that said, why bother with this testing?  You need to
> switch away from
> > CK intrinsics!  And if there's idiocy in the file design
> (duplicates on
> > primary key, or more than one key), redesign!  You can
> always always always
> > find a way to use ONE key on your KSAM file.  Multiple keys
> is the quickest
> > way to kill performance, in my experience.
> >
> > Tracy
> >
> >
> >
> >
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Peter Smithson [mailto:[log in to unmask]]
> > > Sent: Tuesday, September 28, 2004 4:47 AM
> > > To: [log in to unmask]
> > > Subject: More COBOL ineptness? TIMER intrinsic
> > >
> > >
> > >  Hi,
> > >
> > > <I found the answer to this whilst making the posting but you
> > > might want
> > > to laugh at me anyway>
> > >
> > > I've ran this benchmark program on MPE again but the extra
> > > code I added
> > > to print out the time taken seems to have gone wrong.
> > >
> > > The first time I ran the test the code reported that the test
> > > took about
> > > 18 hours -
> > >
> > > Time Taken :00065844
> > > CPU Time Taken :00064465
>
> --
> http://www.beluga.freeserve.co.uk
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *