HP3000-L Archives

April 2003, Week 5

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Spellbinder Systems Group <[log in to unmask]>
Reply To:
Spellbinder Systems Group <[log in to unmask]>
Date:
Tue, 29 Apr 2003 22:09:02 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (40 lines)
No doubt someone else has come across this before but it was new to me.
It appears the way that records are loaded into KSAM/CM and KSAM/XL files
is different.  I created two KSAM files (one CM, the other XL).  With
identical key attributes:

   Record length: 44 bytes
   Primary key:   B,23,22,,DUP
   Secondary key: B,1,22,,DUP

In both cases I took a flat file with 44 byte records and sorted into the
KSAM files:

   :RUN SORT.PUB.SYS
   >IN  <flatfile>
   >OUT <ksamfile>
   >KEY 23,22
   >KEY 1 ,22
   >END

I then compared the results:

   :FCOPY FROM=<KSAMCM>;TO=<KSAMXL>;COMPARE=10

Lo and behold, I got compare error.  In looking at the files in QEDIT I
found some of the secondary keys out of order.  My expectation was that
both the chronological and primary key sequential orders would give me
identical results.

In other words, would KEY=0 or KEY=23 on the FCOPY make a difference?  And
what about opening the file in QEDIT - which mode would it be reading in.
But many, why ISN'T the file in key order?

Has anyone come across anything like this?

Thanx, Ric Goldman
Spellbinder Systems Group

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

ATOM RSS1 RSS2