FBS and VBS work the same as FB and VB except for records spanning into the next block. They all ignore track size.
In all my years, I've only seen VBS used once (I think it is SMF data). The biggest advantage for VBS was that the size for all physical records except the last would be the blocksize. If you specified blocksize 32760, then each track would contain one physical record of 32760 bytes and the rest of the track. To make it optimal, you specified a blocksize of half a track. Jon Perryman. ----- Original Message ----- > From: Robert A. Rosenberg <[email protected]> > > I feel that part of the problem with answering this issue is that IMO FB > support > is BAD (Broken As Designed). FB files (as opposed to FBS files) are allowed > to > have imbedded short blocks. If I write a VBS file to DASD, the write support > has > the smarts to check how much room is left on the current track and to fill it > up > by writing a short segment before writing the rest to the next track(s). Why > when I declare the PDS as FB (but not FBS) can the support figure out the > remaining room on the track and write two blocks (one the size of the > remaining > room and the second for the the rest of the BLKSIZE)? If this was done this > would be a non-issue since if a full sized block would not fit on the track 2 > shorter blocks would be written. The check for remaining room is I assume > done > for the first block of a member since the number of BLKSIZE records that fit > on > a track is not necessarily the same as for the track with the first block of > a > member due to the prior member's EOM record taking up space. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
