What will be the LRECL if the RECFM=VB...

kumar_ngl · New User Joined: 05 Aug 2005 Posts: 50 Location: chennai

Hi friends,

I have faced this question in an interview....

What will be the LRECL if the RECFM=VB...

can anyone explain me???

kumar.p.v

Title changed from "RECFM=VB" to "What will be the LRECL if the RECFM=VB..." : Priyesh.

priyesh.agrawal · Posted: Fri Dec 30, 2005 12:06 pm

Rupesh.Kothari · Member of the Month Joined: 27 Apr 2005 Posts: 463

Hi
If You use Recfm= VB then LRECL (Record lenth) Should be LRECL+4.

Hope this helps

Regards
Rupesh

crrindia · Posted: Fri Dec 30, 2005 12:37 pm

Hi Friends, I would like to add one more point to this.
i.e., It should be (Actual REC Length + 4).
Here REC Length is the Largest record length in that file + 4 bytes.

If I am mistake please correct me.

Thanks!
Rat...

kumar_ngl · New User Joined: 05 Aug 2005 Posts: 50 Location: chennai

thanx to all

kumar.p.v

Frank Yaeger · Posted: Fri Dec 30, 2005 9:13 pm

Actually, for a VB data set, the LRECL can be equal to or greater than the largest record length + 4. For VB, LRECL is the maximum record length, so it can be larger than the actual maximum record.

mmwife · Super Moderator Joined: 30 May 2003 Posts: 1592

There's one other point that may be worth mentioning while we're on the subject and that is the AWO (Apply Write Only) compiler option.

When VB recs are written the access method calculates the # of bytes left in the block before attempting to write the next rec. With VB recs the AM uses the max rec len to do the calculation.

If the max rec len is > the bytes remaining, a new block is created to house the next rec and the current block is physically written.

So, take this scenerio:

LRECL 1004
BLKSIZE 1008

Intended file content rec sizes (rdw/bdws omitted):

100
100
100

(I use only 100 byte recs here to focus the discussion. In reality the file would contain recs of various sizes.)

Without AWO:

WRITE rec1 (bytes remaining in blk after write - 900 {1000 - 100})
AM calcs bytes remaining as 0 (1000 - 1000 = 0), physically writes prev blk1, starts a new blk

WRITE rec2 (bytes remaining in blk after write - 900)
AM calcs bytes remaining as 0, physically writes prev blk2, starts a new blk

WRITE rec3 (bytes remaining in blk after write - 900)
AM calcs bytes remaining as 0, physically writes prev blk3

In this case 3 physical writes are issued against the OP device.

With AWO:

WRITE rec1 (bytes remaining in blk - 900 {1000 - 100})
AM calcs bytes remaining as 900 {1000 - 100}, Queues rec1 in blk1 for physical writing when blk is full (no write is performed now)

WRITE rec2 (bytes remaining in blk - 800 {900 - 100})
AM calcs bytes remaining as 800 (900 - 100), Queues rec2 inblk1 for physical writing when blk is full (no write is performed now)

WRITE rec3 (bytes remaining in blk - 700 {800 - 100})
AM calcs bytes remaining as 700 (800 - 100), Queues rec3 inblk1 and writes physical blk

In this case only 1 physical write is issued against the OP device.

The point is that performing physical writes to an OP device is significantly more time consuming than queueing recs into a buffer. Therefore, AWO can sinificantly improve performance when creating VB files in a COBOL pgm.
.