Duplicates not showing in index file 1

[seeker5]

Hello everyone...

Can anyone provide some insight here...

I am writing to a indexd file:

ORGANIZATION INDEXED
ACCESS DYNAMIC
RECORD KEY REPORT-KEY
STATUS IS FILE-STATUS

Duplicate names and social security numbers get written to the file but when I try and read the file no duplicates display. This is confusing. I even tried using DUPLICATES on the REPORT-KEY but that still didn't work. I am working on an old program written in Microfocus Cobol.

Anyone have any ideas why this might be happening?

Thanks

-Mike

 

[seeker5]

Okay...I figured it out.

Ironically enough, the ENTIRE record with all its different fields can have at times identical fields.

I simply added a sequence number field the record and that fixed problem. The seq no. field would always be different regardless of the other identical fields.

Thanks...

-Mike

 

[WMK]

Just so you know, having duplicate PRIMARY KEYS (which is an "acceptable" Micro Focus extension) is NOT portable and often leads to "odd" results.

The use of duplicate ALTERNATE keys is "standard" and has predictable results.

Bill Klein

 

[seeker5]

Thanks Bill,

I'll certainly keep that in mind.

-Mike

 

[Dimandja]

Bill,

I'm surprised at this "extension" from Microfocus.

Can you think of a possible usefulness of this feature?

Thanks.

Dimandja

 

[k5tm]

Dimandja,

If you don't have the need to do a random update of a record, allowing duplicate primary key values can be a convenience. One would not have to use the common sequence number technique to guarantee a unique value (I've known times where this was a real pain).

Tom Morrison

http://www.liant.com

 

[fredericofonseca]

It's not only MicroFocus. RM and IBM also have it.

It's only usefull if you NEVER access that file for a direct read.
Fine if you need to access the file ordered, but you don't have a way of using a unique key easily.

Apart form the above I had to many problems with some customers using this , and then complaining that their programs would update the wrong record!!

So this is an "avoid if possible" feature.



Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

 

[Dimandja]

I mean, if don't need to randomly update records, why would I want to specify a primary key in the first place?

Relative files can fill the dual need, I thought, by using alternate keys.

I feel like I'm still missing something.

Dimandja

 

[fredericofonseca]

The fact that you don't need to update a record doesn't mean you don't add more, unordered.

If you then need to create a report from this file, e.g. just the records with dates between two periods, if you have that field as a key, you can just do a normal start/read next loop.




Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

 

[WMK]

Frederico,
You may (probably are) be correct about RM, but this is DEFINITELY not a valid extension for IBM (any platform - well I don't know about OS/400 - but certainly not PC, AIX, or mainframe)

Primary keys MUST be unique

Bill Klein

 

[fredericofonseca]

Bill,

AS/400 COBOL/400 and ILE-COBOL both allow this.




Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

 

[Dimandja]

Frederico,

My point is alternate keys handle this situation very well. Allowing duplicate "Primary keys" is not only limiting (not portable), but creates a bewildering array of potential problems.

That is why I am questioning its usefulness: from a technical and practical point of view.

I think "START/READ NEXT" on alternate keys is very normal and works unambiguously.

I am sure there is a very good reason for this "extension". That's what I am trying to find out.

Dimandja

 

[fredericofonseca]

Dimandja,

As Tom mentioned it is sometimes a real pain to add a unique key to a file. The sequence number is easy to get, but it can slow down the system more than you wish, specially if that file is part of On-line systems.

It would be great if we could use an internal COBOL function to create a serial key the same way Databases do.

As for the reason I don't know personally, but it is probably related to the possibility of doing this in some databases.

Maybe one of the COBOL vendors on this group will have a better idea of the reason behind this.




Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

 

[k5tm]

Frederico hints, "Maybe one of the COBOL vendors on this group will have a better idea of the reason behind this."

Hmmm.

Well, I think that this vendor added it for ---

COMPATIBILITY!
​

Tom Morrison

http://www.liant.com

 

[Dimandja]

Allowing duplicate primary keys should qualify as the worst "extension" to hit COBOL. I have seen bad ones, but this one takes the cake. Undoubtedly designed by someone who does not understand the COBOL file system implementation. This type of things usually happens when non-COBOL programmers are hired to code COBOL compilers.

Dimandja

 

[k5tm]

Dimandja,

I'll take that as a compliment, since my first job (outside of university) was converting a major corporation's financial system from Autocoder to COBOL.

The compiler writer (I'm on the runtime side) also had a COBOL-using first job. We've been doing COBOL compilers for about 30 years, so I think we understand the COBOL file system implementation.

That said, this duplicate primary key thing came fairly recently to our product, due to the need to be compatible with another vendor's offering to ease the conversion efforts of a new customer.

Tom Morrison

http://www.liant.com

 

[Dimandja]

Tom,

Do not take my diatribe against bad COBOL "extensions" personnally. I have been asked to code some hare-brained stuff in my time, too.

Dimandja