HP3000-L Archives

September 2002, Week 3

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:
Tracy Pierce <[log in to unmask]>
Reply To:
Tracy Pierce <[log in to unmask]>
Date:
Tue, 17 Sep 2002 14:55:48 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (100 lines)
[Roy B, please keep your tongue in your cheek ;-), I know there's a better
way: steer completely clear of btrees!  But they're a feature, so I'm trying
to use that (since it's already in use and sometimes works nicely.]

Can some Image internals person (Stan 'wrote the code but doesn't use it' ?)
please take a look?  It's not THAT involved...

MasterSet                DetailSet    Search          Sort (supr-style FORM
SETS)
ACT-TYPES(indexed) ACT-CODES    ACT-TYPE (x2)   ACT-CODE (x6)

DetailSet          Search       Sort       MasterSet
ACT-CODES          !ACT-TYPE    ACT-CODE   ACT-TYPES(indexed)
                   ACT-CODE                ACT-CODE-AUTO

more detail:  the master set contains
01, 02, 04, 05, 06, etc, ... 27 of them.  they're linked to the detail via
act-type of course (x2); the detail set contains ACT-TYPE(x2)ACT-CODE(x6),
specifically

0101001 , 0101002 , 0101003 , ... 0202001 , 0202002 , ... 0202999 , 0404001
, ...

record0 , record1 , record2 , ... record19, record20, ... record47,
record48, ...

----------------------------------------------------------------------------
------
Having sorted and reloaded the detail set for ease of debug, I'm basically
doing
MOVE 1 TO IMAGE-MODE
MOVE 'ACT-CODES' TO IMAGE-SET
MOVE 'ACT-TYPE'  TO IMAGE-SEARCH
MOVE '@'             TO IMAGE-ARG
PERFORM DBFIND (returns status=0, 1182 recs, last=1182, 1st=0, all perfect.)
MOVE 5 TO IMAGE-MODE
PERFORM DBGET (returns status=0, rec=0, prev=0, next=1)
PERFORM UNTIL NOT DB-OK
  MOVE IMAGE-BUFFER TO ACT-CODES-BUFFER
  IF ACT-CODE ( 1 : 2 ) <> PREV-TYPE
     MOVE ACT-CODE ( 1 : 2 ) TO IMAGE-ARG
     MOVE 7     TO IMAGE-MODE
     MOVE ACT-TYPES TO IMAGE-SET
     PERFORM DBGET (returns just fine)
     display the heading
     MOVE ACT-TYPE TO PREV-TYPE
   END-IF
   display the detail record *2
   MOVE 5 TO IMAGE-MODE
   MOVE 'ACT-CODES' TO IMAGE-SET
   PERFORM DBGET (returns status=0, rec=1, prev=0, next=2, all perfect.)
END-PERFORM
GOBACK
this works just great, but I notice that every time I get to a break in
ACT-CODE ( 1 : 2 ) (a switch in the contents of ACT-TYPE), then DBGET(5)
returns next=0.  As long as I do no further messing around, the superchain
remains intact, and though there are several ACT-TYPE groups and I see
next=0 several times, the program runs to completion, reporting all 1182
ACT-CODES records and does the heading break 22 times, once for each
ACT-TYPES record.  Lovely, isn't it?

QUESTION 1: can anybody explain the seemingly anomalous next=0 at the DBGET
breakpoints?  this occurs whether or not I go after the appropriate header
record or not, and coincides with switches to the next real entry in the
master set aka 'chink in the chain'.  And yes, the program works, so far.

QUESTION 2: I'm trying to enhance the program by adding a subpgm call at
"*2".  That subpgm will do some goofing around in the same detail set, so
I've carefully added 'typical' save-my-place code:  After each
DBGET(5,ACT-CODES) I save IMAGE-RECORD-NUMBER, and before the next
DBGET(5,ACT-CODES), I do

MOVE 1 TO IMAGE-MODE
MOVE 'ACT-CODES' TO IMAGE-SET
MOVE 'ACT-TYPE'  TO IMAGE-SEARCH
MOVE '@'             TO IMAGE-ARG
PERFORM DBFIND
which re-establishes the same superchain, including all 1182 records; then I
do
MOVE SAVE-RECORD-NUMBER TO IMAGE-ARGUMENT-I2
MOVE 4 TO IMAGE-MODE
MOVE 'ACT-CODES' TO IMAGE-SET
PERFORM DBGET (which really does get back the previous record, and
which would ordinarily (ie no btrees) re-establish my exact position on the
chain.  But the subsequent DBGET mode 5 returns record 19, not record 48;
that produces a loop.  Note the subprogram is not there yet, just the
save-my-place code.

Also note that record 19 is the first record on the 2nd real chain, and that
record 48 is the first record on the 3rd real chain.  obviously something vs
btrees, but what?

TIA

Tracy Pierce
415-923-2266

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

ATOM RSS1 RSS2