Open Internal Linked

[John]

Has anyone used the ",Linked" parameter on a Open Internal file statement? In what situation did you use it? What value is it? What does it do?

-John

[dmeenen]

John,

Linked is useful for having a large transaction file linked to an Employee master file, for example. As I understand it, Linked internally keeps the transactions linked to each other, without having to maintain a sequence number or Next Transaction Address (NTA - from Advanced Computer Systems, remember that?) in the Transaction file.

I have used it way back when, but not recently.

Don't know if it is still supported or not.

[John]

That helps Doug! But I'm still confused by this...

Let me see if I have this right:

So any internal file can be opened with ,Linked (and a kps and kln etc) and it'll do an on the fly index of it so that the records return in that order? and then you can still reference it with Key= and Key>=, etc, without ever having specified a KFName=


-John

[dmeenen]

I believe so, yes.
Gordon or Luis may have to provide the details on this one.

[gordon]

Linked Files are described on page 68 of the advanced capabilities manual. The same information is described in the BR help files available at:

http://www.ads.net/brules/download.html#OTHERUTILITIES

Get ADV-HELP.ZIP.

This information was 'feathered into' the wiki manual, scattered about, but the comprehensive description of linked files was omitted. Linked files are still supported, but the facility reserves the first eight bytes of the subject records.

[gtisdale]

Linked is a VERY useful item in the right situation.

A linked file is an internal relative file. The first 8 positions of which ar the previous record and next record indicators. The first record in a linked list contains blank for the prior record. The last record contains balnk for the next record. You cannot (that is should not) write to the first 8 characters of the record or you will really mess things up.

Typically the linked list is tied to a "Master file" by record number. That is the master file contains a field that holds the record number of the linked list file that is the base record for that naster file item. When you read the master file you then go to a routine that reads the linked file at that record. From then on you simply read the linked file as though it were a sequential file and it keeps reading the records in the list until it hits the one with a blank in the "next record" field. At that point you get an end of file event.

Similarly you can write records to the linked file by setting the link and the writing to the linked file.

OPEN #CHLNK: "name="&SREP$(FILENAME$,".txt",".lnk")&",recl=3600,linked,replace",INTERNAL,OUTIN,RELATIVE

is an example of opening a linked file

I use a linked file in my program that writes manuals. I read the text file, find a title record and save it to an array element. I then write all of the subsequent non-title reocids to a linked file until I hit another title record. That closes the list and adds another element to my array and starts another list. I keep doing this until I have finished the input file (the manual) I then display the titles and can rearrange them in the list as well as change the title level. When done I write the array elements out to a new text file by writing the element then "dumoing the list that is anchord to that element, then the next totle reord and it's related list etc.

This could also be used with service call notes or other situations where your detail expands and contracts and is tied to master record.

The following writes the record to the detail file

03320 WRITE #CHLNK, USING "form x 8,c 3,V 2,c 3500": A$(1:X-1),SREP$(A$(1:X-1),"N",""),A$ !:
! ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿!:
! ³ Write non-title lines to linked file with an anchor record ³!:
! ³ noted in the AREC matrix ³!:
! ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ!

The following is the routine to read the linked file

04220 FOR A=COX TO COX+0 ! DNX
04230 LET X=0
04240 RESTORE #CHLNK,REC=AREC(A):
04250 LET X+=1
04260 READ #CHLNK,USING "form x 13,v 3500": A$ EOF 4290
04270 IF X=1 THEN PRINT #NEWCHAP: TRIM$(ALVL$(A))&"|"&TRIM$(ATXT$(A)) ELSE PRINT #NEWCHAP: A$
04280 GOTO 4250
04290 NEXT A

In my situation I added 5 characters after the linked list 8 character field to hold a "safety net. Just in case the linked list messed up I have a field within the list record from which I could rebuild the list

[John]

So do linked files get all screwed up if you delete some records and then copy them -d or is BR! smart enough to rearrange the record pointers?

Is there a maximum number of records for these linked files?

-John

[gtisdale]

BR is smart enough as long as you give it a fighting chance. If the deletion is done on a file opened “LINKED” then the linkage in the first 8 characters is updated and the copy –D does not screw anything up.
Just in case something does get screwed up include a field in your linked record that can be used to rebuild the linkage.

The 4 character fields would limit the number of records that could be referenced, but a B 4 field can probably handle more records than you would ever throw at a linked file.

The beauty of a linked file is that once you access the link stream for a base record the file acts as if it were a single file dedicate to only that linkage, so reading sequentially follows the link chain and creates an EOF flag at the end, etc.

For what sort of application are you considering a linked list?

FNGeorge

[Susan Smith]

George,

I have never used a linked file, though I remember that they were much more common in the earlier days of BR. Currently are there reasons why you might still want to use a linked file over an indexed file, or are indexed files now sufficiently fast that it makes no sense to use linked files in most cases?

Also, the linked files are sequential right? They always are accessed in the order written?

You mentioned that you can use COPY -D on a linked file in the right circumstances (if the deletion was done on a file opened as a LINKED file). But does the COPY -D actually fix the pointer in the master record if the first record in the chain is deleted? How would that work with COPY -D?

Can you create an index file for a linked file in the event that you want to access records in another order? I'm thinking perhaps of a telephone log application where you normally would call up a customer and see all telephone calls that came into a customer service center. But maybe, at some point, you want to see all calls made by a specific OPERATOR rather than a specific CUSTOMER.

-- Susan

[gtisdale]

You need to assess why you are using a linked file rather than some other type of file access. Linked files came into vogue in the early days of databases because they made the primary database more efficient. Rather than haveing a whole bunch of records in the database you could branch out and carry the detail in an external sequentially read bucket.

In the linked list you can insert records into and delete records from a linked list. The insertion does not have to be at the end as I recall. In this way you can record notes and outlines for example tied to master titles or customers. The records are read sequentially when doing a read so a "conversation" can flow properly.

In terms of reviewing calls by customer vs. calls by operator you would need to look at the access time. The SORT utility in BR has become significantly enhanced an may yield an address sort more efficiently than an indexed read. OR, on a datafile that is constantly changing a record sort to grab a snapshot of the dynamic file may be more efficient.

There is no reason that you can not set a key within a linked file and index it as well as create the linked list. Just stay away from the first 8 characters. In this way you could run your report from the keyed field(s) as well as the linked order. However, you run the risk of accidentally opening the file at some time without opening it BOTH as linked and as keyed. Should you do that you have broken either the key or the link. The key of course can be rebuilt with an INDEX command. The link will leave orphan records because the first 8 charaters will not contain the previous and next record numbers. Also, if you resort a linked file (record sort replace) you have just destroyed your linked list and will have to use some embedded key and a separate program to rebuild the linkage.

ALso, if you are using FILEIO check with Gabriel to see how linked lists are supported in that environment.

FNGeorge

[Susan Smith]

Excellent points George. Thank you so much!

Aside from linked lists, I had forgotten all about "record out" sorts. If those operate quicker these days, that may be a very useful tool in many places. I haven't done a "record out" sort in forever.

-- Susan