Operating System - OpenVMS
1748228 Members
4206 Online
108759 Solutions
New Discussion юеВ

Re: Another COBOL Local Buffers Question

 
Ramondo
Advisor

Another COBOL Local Buffers Question

Hi all,

I would like to do some optimizing tests on COBOL programs. There was a similar question recently, but this one is more specific to seeing the contents of RAB$_MBF from COBOL.

Currently, none of the select statements in our application (included from a library) use the RESERVE n AREAS clause. I would like to see how many buffers are currently allocated for each file before setting this value and doing some performance tests.

There are no process or system multibuffer counts defined, and we do not use global buffers.

I can├в t get an RAB$_MBF value returned from the attached COBOL program:
- when I run ├в as is├в
- when I set the indexed buffer value from DCL
- when I specify the number of areas on the select statement.

The source came from either here or an HP manual. Can anyone see anything wrong?

I├в ve also included a dump of the FAB and RAB.

Any input would be appreciated.

Also, can anyone tell me if it is worth specifying the RESERVE n AREAS value when writing to a large sequential (extract) file? I alread have DEFERRED WRITE enabled.
(Is the amount of data written to disk with DEFERRED WRITE related to the multibuffer count or RESERVE n AREAS, or is it when the ALLOCATION value has been reached?)

Thanks,

Ramondo.
5 REPLIES 5
Hein van den Heuvel
Honored Contributor

Re: Another COBOL Local Buffers Question

Interesting... those RAB & FAB look like the ones I wrote in 1986 in France:

==========================================
Note 230.1 How do you Create/Map Private sections ? 1 of 6
BISTRO::HEIN "Hein van den Heuvel, Valbonne." 109 lines 29-OCT-1986 03:06
-< Example of FAB and using SYS$OPEN. >-
----------------------------------------------------
:
05 FAB_ID PIC S9(9) COMP VALUE 20483.
05 FOP PIC S9(9) COMP.
05 STS PIC S9(9) COMP.
:

I did not recognize the STS value as it is a cute one I never run into:
%RMS-S-FILEPURGED, oldest file version purged

Anyway....

The RAB MBF and and MBC fields are INPUT only. Ditto for the XABITM multibuffer count: RMS REF Manual: "You cannot sense the value stored in the XAB$_MULTIBUFFER_COUNT XABITM, and any attempt to sense this value leaves the user buffer unchanged."


>> I would like to do some optimizing tests on COBOL programs.

:
>> There are no process or system multibuffer counts defined, and we do not use global buffers.

So you are not really interested as those two statements are in contradiction.
Changing the default system setting for SET RMS is one of teh more efficient ways to help optimize some. Global buffers are BY FAR the most likely simple change to get a lot of performance. BY FAR.

>> I would like to see how many buffers are currently allocated for each file

You will have to use ANALYZE/SYSTEM
SDA> SET PROC 'test' ... SHOW PROC/RMS=BDBSUM

>> Also, can anyone tell me if it is worth specifying the RESERVE n AREAS value when writing to a large sequential (extract) file? I alread have DEFERRED WRITE enabled.

Makes no sense. Deferred write uses locking and is a horrible performance overhead for simple, unshared tasks. You want to use write-behind, which is a default option in Cobol and you want to use BLOCK CONTAINS (or whatever it is called) to grow the buffer size (MBF) rather than the number of buffer (MBC). Of course it is MUCH easier to just use SET RMS/SEQ/BUF=4/BLOCK=127 (or 112 or 64 or...) in the context of the process.

DEFERRED write only postpones writing. The IOs are synchroneous. It is greate for REWRITE and DELETE and WRITE to SHARED INDEXED files.
WRITE BEHIND initiates IOs A-synchroneously as soon as a buffer fills. That's typically what you want to write sequential files.


Come to the OpenVMS bottcamp and I'll explain you all about it! (Tell Sue I send you :-)

Hope this helps some,
Hein van den Heuvel (at gmail dot com)
HvdH Performance Consulting



Hein van den Heuvel
Honored Contributor

Re: Another COBOL Local Buffers Question

>> There was a similar question recently,

For the benefit of other readers...

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1212698

It describes the default buffer allocation for index file. It is actually:
"as many as the deepest index is deep + 2"
XABKEY->xab$b_lvl

Note that for freshly created files such as in this example this may short-change the application if it does not re-open.

Hein.


Ramondo
Advisor

Re: Another COBOL Local Buffers Question

Hein,

Thanks for pointing out my incorrect use of Deferred Write, and the fact that COBOL already does what I was trying to do.

>>So you are not really interested as those two statements are in contradiction

What I was getting at was there are no SET RMS system settings for buffers and we dont use DCL batch scripts here (old ported application) so no process level either. My only option, as I see it, is to use RESERVE n AREAS in the Cobol SELECT statement to set the Multibuffer Count value for individual files (or possibly set in the RAB).

But I get the impression it may not be worth the effort.

And as intriguing as it sounds, I wont be able to make it to bottcamp this time.

Cheers.
Hein van den Heuvel
Honored Contributor

Re: Another COBOL Local Buffers Question

RESERVE AREAS is the perfect way to control this, but it is tedious. And in my experience I hav seen more folks hurt by well meant intentions 10+ years ago, then helped by careful settings today.

The default settings are on the low side, let's say 5 (very typical). So a smart developper 15 years ago my have picked 10, on a box with 5MB per users. Now the applications runs with 20MB/user available. You would easily have then memory to give 20 buffers / per file. Well, folks do not go back to the cobol to fix that. They live with it.

By all means, use SET RMS.
Choose a higher system wide default, save in SYSGEN:
/SEQ/BLO=64/BUF=2/EXT=2048
/IND/BUF=10
And choose a higher process default for certain application users, perhaps based on UIC group:
/SEQ/BLO=127/BUF=4
/IND/BUF=20

Great potential, low risk.

The biggest potential gains however are in global buffers. For local buffers the XFC is such a super catch-all!

Regards,
Hein.

Ramondo
Advisor

Re: Another COBOL Local Buffers Question

Closing this call.