Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

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

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> JCL & VSAM
View previous topic :: :: View next topic  
Author Message
kumar_ngl
Warnings : 1

New User


Joined: 05 Aug 2005
Posts: 50
Location: chennai

PostPosted: Fri Dec 30, 2005 11:43 am    Post subject: What will be the LRECL if the RECFM=VB...
Reply with quote

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.
Back to top
View user's profile Send private message

priyesh.agrawal

Senior Member


Joined: 28 Mar 2005
Posts: 1452
Location: Chicago, IL

PostPosted: Fri Dec 30, 2005 12:06 pm    Post subject: Re: RECFM=VB
Reply with quote

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


It should be (Actual REC Length + 4).

Regards,

Priyesh.
Back to top
View user's profile Send private message
Rupesh.Kothari

Member of the Month


Joined: 27 Apr 2005
Posts: 464

PostPosted: Fri Dec 30, 2005 12:10 pm    Post subject: Re: RECFM=VB
Reply with quote

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

Hope this helps

Regards
Rupesh
Back to top
View user's profile Send private message
crrindia

Active User


Joined: 02 Jul 2005
Posts: 124
Location: Gurgaon

PostPosted: Fri Dec 30, 2005 12:37 pm    Post subject: Re: What will be the LRECL if the RECFM=VB...
Reply with quote

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...
Back to top
View user's profile Send private message
kumar_ngl
Warnings : 1

New User


Joined: 05 Aug 2005
Posts: 50
Location: chennai

PostPosted: Fri Dec 30, 2005 2:08 pm    Post subject:
Reply with quote

thanx to all

kumar.p.v
Back to top
View user's profile Send private message
Frank Yaeger

DFSORT Moderator


Joined: 15 Feb 2005
Posts: 7130
Location: San Jose, CA

PostPosted: Fri Dec 30, 2005 9:13 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
mmwife

Super Moderator


Joined: 30 May 2003
Posts: 1592

PostPosted: Mon Jan 02, 2006 12:55 am    Post subject:
Reply with quote

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.
.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> JCL & VSAM All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Copy RECFM =VB TO FB file with RECL =... sahil41352 DFSORT/ICETOOL 3 Wed Dec 28, 2016 11:29 pm
No new posts PL/I: opening file w/ dynamically det... Sam Dodgers PL/I & Assembler 6 Wed Jul 27, 2016 4:05 pm
No new posts SORT Format should be RECFM=VB,LRECL=350 senthamizh SYNCSORT 8 Fri Jan 15, 2016 8:20 pm
No new posts Concatenate different LRECL GDG's Rohit Umarjikar DFSORT/ICETOOL 6 Wed Nov 18, 2015 3:30 am
No new posts converting RECFM=U file to VB or FB file kenshin JCL & VSAM 6 Tue Oct 20, 2015 12:06 am


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us