Peter,
I know I dove into this thread late, and am lacking some detail re your
motives, but:
1) is this a genuine ancient KSAM file? if so, your native ksam calls are
likely getting subverted into CK calls by the file system at read time,
which it seems would take quite a bit of time.
2) removing the unused key won't affect much of anything (except new writes)
for an already-loaded file. remove the key, erase the file (or even better,
purge the file and build a new one with one key), presort the records, then
fill the file. The load will go fast, and a sequential read will be only a
little slower than a flat file. And since you're building a new file (which
should be done periodically, say every Sunday after your backup), make it XL
KSAM and use XL Cobol statements for both read & write.
To your real question, I don't know the fastest CPU. But I don't think the
CPU is what's taking all the time; more likely it's the ksam file, which has
been loaded randomly, creating messy indexes and messy data. Fast CPU won't
hurt, but better would be lots of memory available to both disk caching and
SL & XL segments.
Tracy
> -----Original Message-----
> From: Peter Smithson [mailto:[log in to unmask]]
> Sent: Thursday, September 30, 2004 7:47 AM
> To: [log in to unmask]
> Subject: Re: More COBOL ineptness? TIMER intrinsic
>
>
> I think the customers MPE machine must have been a very
> powerful one as
> removing the extra index isn't helping much. It hasn't
> finished the run
> yet but it doesn't look much faster. Removing the EXCLUSIVE keywords
> made it run a little quicker although, interestingly, still
> slower than
> the CK route.
>
> What's the fastest HP3000 in terms of CPU clock speed?
>
> Cheers
>
> Peter
>
> In article <[log in to unmask]>, [log in to unmask]
> says...
> > 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
>
> --
> 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 *
|
