In every shop I've been in, the Cobol file status codes are always included with the message. To not provide them would take me some getting used to. I'm not saying it's wrong to do it that way, it would just take some getting used to.

Still, Micro Focus has many implementer defined file status codes, in the form of 9x, where x is a binary number between 0 and 255. I wouldn't want to interrogate that and make a message for each one. Especially since the software is ported to a dozen different platform's Cobol vendors for each release. It's good to be generic.

We convert the binary number to a display number and include it in the message. That has sufficed in all cases.

Also, there is at least one Cobol vendor that returns 0x status codes, where x is any letter from A to M (upper and lower case). In my mind, I'm happy with "00" telling me that it was successful. I don't need 0x telling me why it was successful. But there's a vendor that does. It's in the ISO specifications for them.

Here I thought I'd seen every Cobol compiler in the world. Which vendor does this?

I am a little lost here, 'The end user' only will see what messages etc, that the programmer has specified.

The programmer should be aware of how s/he's logic works and create suitable user messages accordingly.

The actual status code produced by the compiler is totally immaterial other than to the programmer assuming of course that it complies with the Cobol standards which OC does.

A good work around, thanks.

I hope the ISO Cobol committee realizes that, of the entire ISO Cobol specifications document, the only part that the end user sees is the table of file status codes.

The file status codes should be user friendly and complete.

Then why not just show them a "Beginning of file:" message, then they won't go looking for a 10 or 11 they will hopefully relaize they have reached the "beginning of the file".

Yes, thank you for your reply. And also, thank you for all the work you do for the Cobol community.

The "end of logical sequential processing" means a great deal to us developers. I get it. Hopefully all Cobol vendors interpret it the same way.

But that quote means nothing to an end user. It is jargon. It will confuse them.

The issue that I have is when some developer, such as myself, needs separate messages for beginning and ending of file. They have to use a separate code, in my case "11".

When a customer pushes the F-key for read previous, and gets the "Beginning of file: 11" message, they may look up "11" in their Cobol book. They will not find "11". Then they call customer support, asking "what's this?" Then we have to tell them that Cobol doesn't have a separate beginning of file code, so we made one up.

Not having a beginning of file status code adds an element of confusion that I would hope the ISO committee would at least consider.

To make Cobol friendlier to the end users there should be a code reserved for read previous.

Quote:
I think that makes you a junior member.

READ PREVIOUS (and other related features WERE new in the '02 Standard, but they are there now (and have been for a decade).

File Status "10" for "end of logical sequential processing" has been in the Standard since long before I knew COBOL.

You could ask for a different FS for reaching the beginning on backwards sequential processing, but I do not (personally) think there is any chance at all you would get it.

Does this answer everything addressed to me?

Sorry,

but status 10 IS in the standard and has been since ANSI'74.

As far as I know all vendors use it, well the main one's anyway eg, MF, IBM heck even ICL did.

You raise a good point. It's a logical end either way.

Having different file-status codes for end and begin is nice to have, not a requirement. As shown in the example, I handle it with my own Move "11" to file-status.

Even if ISO Cobol picks "10" for a beginning file-status, they should at least put it in the standard so that all vendors can follow it. Right now, I think that the standard does not say anything at all about what to do at the beginning of a file. The standard should pick something that all vendors can agree to.

Small point, status 10 is actually 'There is no next logical record. You have reached the end od file.'

So, by reading reverse the last record (which is actually the first held in the file) IS the last record.

Does not a programmer that does a read reversed not expect such logic or am I just being a 65 year old (OK, not till the 23rd June anyway!!) M/F programmer again and having another brain fart.

As for a screen message that should be the responsibility of the programmer to create and word correctly.

Vincent