Hi,

I don't think there are many duplicate keys involved.  I had trouble
defining a primary key with duplicates using ACU's vutil application and
loaded the data anyway.  Not many records were rejected.  I've since
found that I can create a primary key with duplicates using COBOL.

I'm not sure what "NM KSAM" is (except that NM stands for Native mode
and I think KSAM XL uses it - I think).  I know theres KSAM 3000 and
KSAM XL.  I used KSAM XL.

The test can either use CK intrinsics or COBOL verbs or a mixture.  I
couldn't get the program to open the KSAM file I'd created on MPE using
the COBOL verbs (some error to do with the program not matching the file
or something).  This is a bit worrying as they provided the test program
and the JCL to create the files.  I had the same problem on HP-UX but
got round it by adding the alternate key in the COBOL SELECT statement.
I got a compilation error using the same syntax on MPE (I'm no COBOL
expert).

So I used CK intrinsics on MPE.  I'm hoping that it doesn't make much
difference as it'll all come down to FREAD, FWRITE etc in the end on
MPE.  Would that be right?

I used COBOL verbs on HP-UX.

I am worried that the customer got the test to run in 1.5 hours.  They
used COBOL verbs - could that account for such a huge difference?

I've been involved in migrations before and you get two things happening
-

1) Data access is quicker because the hardware is so much newer and
faster.

2) Data access is slower as they move to RDBMS in the process.

Factor 1 has won out over all in the system as a whole so it's never
been a concern.  This is the first time I've tried to compare like with
like.  The customer isn't interested in this as they're going to Oracle
but I was curious.

Cheers

Peter

In article <[log in to unmask]>,
[log in to unmask] says...
> One factor affecting HP3000 Ksam performance is inserting, updating and
> deleting records where a lot of the records have the same key value.   I
> once improved a program's performance by over 90% simply by eliminating
> duplicate keys.
>
> I've not tested how Acucobol performs in this respect.
>
> I assume you were using NM Ksam on the HP3000 using HP Cobol and the native
> mode intrinsics (or just the standard cobol verbs) and Acucobol's own cobol
> and vision files on Unix.
>
> With my migration hat on,  I'm pleased that you're getting better
> performance on the Unix platform.
>
> However, are you saying that the same test application only takes 1.5 hours
> on the customer's MPE box ?
>
> -----Original Message-----
> From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On Behalf
> Of Peter Smithson
> Sent: 23 September 2004 11:33
> To: [log in to unmask]
> Subject: [HP3000-L] Comparing speed of KSAM app on MPE vs HPUX
>
>  Hi,
>
> I've been doing some searching on the internet and on usenet but I've not
> found anyone comparing the speed of an application that does a lot of KSAM
> work running on MPE vs HPUX.
>
> I've been given a benchmark which does some KSAM testing.  I know it's not
> ideal - it's not multi user and it's heavily CPU bound as it just re-reads
> two index files repeatedly.  So it's of limited use but not of no use as a
> comparision.  It uses a mixture of searching, reading, re- writing and just
> writing.
>
> I'd be interested in comments, especially on how to speed it up on MPE as
> the customer says it takes 1.5 hours on their MPE system.  Maybe our MPE
> system is a bit old.
>
> No other users were on the machines but an incremental backup did kick off
> on the hpux machine.  The files were stored using the ACUCOBOL indexing
> system on HPUX.
>
> HPUX 11 running on a 160Mhz PA-RISC CPU using ACUCOBOL 6.0 takes 8.3 hours.
>
> MPE 7 on a twin 180Mhz PA-RISC CPU using KSAMXL files takes 18.3 hours.
>
> I know the 2nd processor on the MPE machine is of little use in this test so
> I consider them roughly equal in processing power although the MPE system

--
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 *