Human (and/or others) (follow on to the "porint Micro Focus" topic, but limited to split keys)

My memory from when I last looked at it, was that Micro Focus and the ISO Standard's support for "split keys" is EXACTLY the sam functionally, but different in the syntax used.

Is this correct (from what you have looked at) or are there any funcitonal differences between the two?

The only syntax difference for split keys is SOURCE IS in ISO:
to = in MF/ACU
Functional difference for alternate keys (including split keys or not):
In ISO (and ACU) all keys have to be identical used in all programs, Quote: From the other thread I guesses it's not true for MF. This is the reason why I wrote that behaviour should NOT change by default but via an environment entry or config/compile flag. I just read the same rule in MF docs but there's a sentence added, Quote: --> This is the way it should be done in OC, too.

Simon 'human' Sobisch

As you say, the "identical" thing is NOT limited to split keeys. In fact, IBM mainframes (which I think is still the largest base of COBOL programs) does NOT enforce the "same number and location of alternate keys" requirment.

As I have (always?) read the STandard, it does (and HAS) defined how things work if the keys are identical (same number, location, etc) but does NOT define what happens if they are not.

There are two (at least) possible behaviors when there are mismatches.

1) Get FS=39 on an OPEN when the keys don't match (for OPEN INPUT or I-O, maybe OUTPUT). However, FS=39 really is an implmentor defined condition as to WHICH "permanent file attributes" need to be checkede.

2) If you WRITE to a file in a program without one (or more than one) possible alternate keys, then it may or may not be possible to use them again in a program that DOES have them.

On IBM mainframes "IDCAMS" and related software make certain that alternate keys that are defined for a file when it is defined, are ALWAYS available to any program using the file. However, I do not think this is "universal" among COBOL implementations.