START on sequential fixed-length records file in COBOL

[Andrzej Chojnowski]

Hi,

I am newbie on ITRC forums although I've been reading them for some time as a guest :-)

My problem is with COBOL @ OpenVMS. Maybe first some introduction before the actual question.

I am trying to make program written in COBOL fast forward on huge (circa 10^8 records, ~0,5kB each, huge enough to have asterisks instead of size in DIR results :-) sequential fixed-length records. The built-in command START command allows only indexed and relative file organizations.

At OpenVMS RMS level this operation is easy, just call SYS$FIND with appropriate arguments and the next SYS$GET will be already there. But not in COBOL.

My plan is to retrieve FAB/RAB from COBOL program using DCOB$RMS_CURRENT_FAB and DCOB$RMS_CURRENT_RAB and use them to call SYS$FIND on them (via tiny C module). All file processing would stay at COBOL (opening, reading - I don't rewrite the file, just read it, closing). But there is a problem: the HP docs says:

"The FAB/RAB is a structure used internally by the HP COBOL run-time system to implement COBOL semantics. Modification of FAB/RAB fields can result in abnormal program behavior, including unexpected program termination."

Of course I am preserving the fields as much as I can - in fact to call SYS$FIND I only need to temporarily set the key buffer pointer, the key size and the access method - "by key". I retain the old values in hold variables and reset them after call. And, I know, the SYS$FIND modifies the RFA fields.

I've made some experiments. The file opened by COBOL's "OPEN INPUT" with ACCESS IS SEQUENTIAL is opened in block access mode with some performance bits set, including SQO. I've found out it from observation of values in FAB/RAB retrieved from COBOL program. The I/O buffer size is set to maximal value: 63,5kB. All this suggests the COBOL uses SYS$READ, not SYS$GET and separates records internally "hy hand". I cannot use SYS$FIND then. And this SQO bit set... The file opened in I-O mode or merely "OPEN INPUT ... ALLOWING READERS" makes COBOL compiler to change its mind and revert to record access mode and SYS$GET. The external SYS$FIND works!

Here go my questions:
Have anyone implemented such solution: COBOL program calling RMS functions externally on files it governs?
What do you think about risk of this solution?

The remarks on HP docs worry me a bit. The program works fine so far. And I am aware that the situation may change with any upgrade, either COBOL compiler or OpenVMS.

Regards,
Andrzej

[John Gillings]

Andrzej,

It sounds to me like you've done as much as you can to keep COBOL happy. If your code works to your satisfaction, and you're confident you are correctly restoring the RAB after playing with it, I'd guess your risks are fairly low. In COBOL you can mostly assume nothing tricky like recursion or asynconous calls, so you're pretty much in control.

However, if you find any kind of strange behaviour, then you're on your own!

If the built in COBOL I/O can't be convinced to do exactly what you want, then I'd strongly recommend implementing an I/O module in some other language, (or COBOL) using the exact RMS calls you really want to perform. Present COBOL with the API your application really wants, implementing each operation as a routine:

CALL "ANDRZEJOPEN" USING BY DESCRIPTOR FILE-NAME.
CALL "ANDRZEJSTART" USING BY DESCRIPTOR RECORD-NUM.
CALL "ANDRZEJGET" USING BY DESCRIPTOR RECORD-BUFFER.
CALL "ANDREZJCLOSE".

hide the details of how you achieve the operation inside the module.

[Hein van den Heuvel]

>> I am newbie on ITRC forums although I've been reading them for some time as a guest :-)

Ah, a lurker! Welcome.

>> huge enough to have asterisks instead of size in DIR results :-)

You know how to fix that right?
... DIR /WID=SIZE=9

>> sequential fixed-length records.

So RMS could do keyed=RRN access.

>> The built-in command START command allows only indexed and relative file organizations.

Ashame really... but that's how it is

A> t OpenVMS RMS level this operation is easy, just call SYS$FIND with appropriate arguments and the next SYS$GET will be already there. But not in COBOL.

Correct.

>> My plan is to retrieve FAB/RAB from COBOL program using DCOB$RMS_CURRENT_FAB and DCOB$RMS_CURRENT_RAB and use them to call SYS$FIND on them (via tiny C module).

Been there, done that. Works... mostly.

>> I retain the old values in hold variables and reset them after call. And, I know, the SYS$FIND modifies the RFA fields.

That's the right approach.

>> I've made some experiments. The file opened by COBOL's "OPEN INPUT" with ACCESS IS SEQUENTIAL is opened in block access mode with some performance bits set, including SQO.

Right, this is a performance optimization for 'simple', unshared, sequential files.
The cost of going into exec mode for RMS to read a simple record was found too high.
SORT and the C-RTL do the same thing.

>> I've found out it from observation of values in FAB/RAB retrieved from COBOL program.

Nicely done.
ANAL/SYST... SHOW PROC /RMS=(FAB,RAB,BDBSUM)

>> ALLOWING READERS" makes COBOL compiler to change its mind and revert to record access mode and SYS$GET. The external SYS$FIND works!

Right. A cheaper alternative to force record IO is to set the logical name "COB$USE_RECORD_IO" in the program environment.

>> Have anyone implemented such solution: COBOL program calling RMS functions externally on files it governs?

Yes.

>> What do you think about risk of this solution?

It only gets a little ugly when you hit EOF.
That does not sount like a problem in your case.

>> The remarks on HP docs worry me a bit.

That's the intend.
HP want you to think twice, and test three times before going there. You did.

Regards,
Hein.
HvdH Performance Consulting

[Phil.Howell]

Have you tried defining this file in your program as relative? RMS treats relative files and fixed-length sequential in a similar way.
Phil

[Robert Gezelter · Accepted solution]

Andrzej,

I concur with Hein. With John's comment, I would amplify that there is no problenm with bypassing the COBOL runtime environment completely and calling all of the RMS calls directly. It is fully supported.

The problem is when you are sharing structures with the language run time in ways that the language run time does not expect. This can cause difficulties, although on OpenVMS it is rare.

My personal preference, for cleanliness reasons, would be to do all of the RMS calls manually for this particular file.

- Bob Gezelter, http://www.rlgsc.com

[Jan van den Ende]

Andrzej,

WELCOME to the VMS forum!

If you think you have been helped, check

http://forums1.itrc.hp.com/service/forums/helptips.do?#33

for the way to thank those that helped.

Proost. ( = Na zdrowie )

Have one on me.

jpe

[Andrzej Chojnowski]

Thank you for your assistance!

Finally I've chosen rewriting I/O operations on this particular file in C/RMS. COBOL will merely call the external funcations. I can feel this design is much safer because I retain full control over it.

John, Robert,
You have reassured me it will be a cleaner solution.

Hein,
Thanks for valuable input.

Phil,
We have tested your interesting idea. Unfortunately COBOL doesn't recognize sequential file as relative. I could of course CONVERT my file to relative organization prior to start my executable but I cannot afford it for perfomance reasons - the file's huge.

I've assigned you some points and I think I will close the thread now.

Andrzej

[Phil.Howell]

if the file size is an issue, then you could try converting it to an indexed file, data and index compression can save quite a bit of space - depending on the data of course.
Phil