|
View previous topic :: View next topic
|
| Author |
Message |
srajendran2
New User
Joined: 13 May 2008
Posts: 56
Location: Chennai
|
|
|
|
Currently the program/JCL is createing a VBS file and it has to be changed to a VB file as per the request from customer. The code on COBOL and JCL are given below. If i change the recording mode to "V" and change VBS to VB in JCL, will it work? or should i take care of anything else within the program or JCL?
COBOL
| Code: |
FD SYS230-VAR-OUT
RECORD IS VARYING DEPENDING ON 800-SYS230-RDW
RECORDING MODE IS S
LABEL RECORDS ARE STANDARD
BLOCK CONTAINS 0 RECORDS
DATA RECORD IS SYS230-VAR-OUT-REC.
01 SYS230-VAR-OUT-REC.
05 PIC X(01) OCCURS 1 TO 32756 TIMES
DEPENDING ON 800-SYS230-RDW.
|
JCL
| Code: |
//SYS230 DD DSN=TEST.OUTPUT,
// DISP=(,CATLG,DELETE),
// SPACE=(CYL,(1,1),RLSE),
// DCB=(RECFM=VBS,LRECL=32760,BLKSIZE=32760)
|
I saw a post related to this. But it just mentioned about changing the JCL from VBS to VB and no mention of recording mode. |
|
| Back to top |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| If i change the recording mode to "V" and change VBS to VB in JCL, will it work? |
It should, but be aware that the size of the data set could increase significantly. A VBS data set will have blocks that have no more than 4 bytes unused in the block, whereas a VB data set will have blocks that may have almost the LRECL of unused bytes. The specifics will vary depending upon the data, but expect the space required to go up. |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
BLKSIZE=32760 is a poor choice for disk. You just get one physical record per track and 35% or 40% of the track will not be used. Most load module data sets are RECFM=U, BLKSIZE=32760. This works for two reasons.- You rarely find 32K records, much less records that approach 32K. Most of the time a long text record will be followed by one or more 256 byte records; these records are usually related to the text record, though the last one will have information about the next text record.
- The Binder is smarter than you think about text record sizes. If it sees the remaining space on a track is 12K, for example, it will write a 12K record. I am impressed by this undocumented feature, but I also have my doubts about it. When I discovered what the binder is doing, I wrote a PDS copy for FB or VB data sets that replicated this feature. It worked fine, but the net savings for real data sets was less impressive than I had hoped. I don't use the program.
RECFM=VB,LRECL=32760,BLKSIZE=32760 will not be accepted. In VB, you must allow 4 bytes for a BDW (Block Descriptor Word); for BLKSIZE=32760, the max LRECL you can specify is 32756. Remember, too, that with RECFM=VB or VBS, LRECL specifies the maximum record in the data set. Many records can be smaller. SMF is a major user of RECFM=VBS. It starts with RECFM=VBS, LRECL=32767, but most records are much smaller. Perhaps this has been fixed, but you cannot specify LRECL=32767 in JCL, though, of course, the DCB macro accepts it.
Going back to LRECL; one of my programs specifies RECFM=VB, LRECL=4100. When I devised the program 19 years ago, I had a use in mind for the long record. It never materialized; in practice the longest records are 120 or 130 bytes, but the LRECL never changed; it didn't have to change. |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
| Robert Sample wrote: |
| Quote: |
| If i change the recording mode to "V" and change VBS to VB in JCL, will it work? |
It should, but be aware that the size of the data set could increase significantly. A VBS data set will have blocks that have no more than 4 bytes unused in the block, whereas a VB data set will have blocks that may have almost the LRECL of unused bytes. The specifics will vary depending upon the data, but expect the space required to go up. |
VBS space usage is not quite what Mr. Sample says. VBS has two goals.- Write constant size physical records (except for the last physical record).
- To enable the goal in the first bullet, if a record cannot fit into the current physical record, it will be broken and "spanned" into the next physical record. Every record segment has a 4 byte descriptor. The descriptor for logical records that fit into one physical is just a regular VB RDW. The descriptor for each segment of a record that spans more than one physical record is similar to an RDW; it has flags to indicate it is the first segment, a segment that is a middle segment that continues to the next physical record, or a segment that is the last segment.
|
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
I created this data set.
| Code: |
listd writevbs.output
XXXXXX.WRITEVBS.OUTPUT
--RECFM-LRECL-BLKSIZE-DSORG
VBS 32767 4096 PS
--VOLUMES--
XXXX25 |
I wrote one 32767 byte record to the data set. It has this logical view -
| Code: |
*** RECORD 1
0000 0 7FFF0000 11111111 11111111 11111111 *"...............*
0010 16 11111111 11111111 11111111 11111111 *................*
ONE OR MORE LINES SAME AS PREVIOUS LINE
7FF0 32752 11111111 11111111 11111111 111111 *............... * |
The 4 bytes at the start is an RDW (Record Descriptor Word); 7FFF is the record length, 32767. The physical records are -
| Code: |
*** RECORD 1
0000 0 10000000 0FFC0100 11111111 11111111 *................*
0010 16 11111111 11111111 11111111 11111111 *................*
ONE OR MORE LINES SAME AS PREVIOUS LINE
0FF0 4080 11111111 11111111 11111111 11111111 *................*
*** RECORD 2
0000 0 10000000 0FFC0300 11111111 11111111 *................*
0010 16 11111111 11111111 11111111 11111111 *................*
ONE OR MORE LINES SAME AS PREVIOUS LINE
0FF0 4080 11111111 11111111 11111111 11111111 *................*
...
*** RECORD 9
0000 0 00430000 003F0200 11111111 11111111 *................*
0010 16 11111111 11111111 11111111 11111111 *................*
ONE OR MORE LINES SAME AS PREVIOUS LINE
0040 64 111111 *... * |
The 10000000 is a BDW (Block Descriptor Word) 1000 is, of course 4096, the number of bytes in the record.
The 0FFC0100 in record 1 is properly called a Segment Descriptor Word (SDW) The 01 is a code that says it is the first segment of a longer logical record.
The 0FFC0300 in record 2 is an SDW that says the segment is a middle segment of a spanned record.
The 003F0200 in record 9 is an SDW that says the segment contains 63 bytes and is the last segment.
The BDW and SDW data are overhead, but to say they are wasted or useless isn't true. |
|
| Back to top |
|
|
srajendran2
New User
Joined: 13 May 2008
Posts: 56
Location: Chennai
|
|
|
|
Thanks to all for your reply.
Instead of changing in VBS to VB in JCL and COBOL, can I just use a SORT after VBS is created and copy it to VB? will it give the same result? |
|
| Back to top |
|
|
srajendran2
New User
Joined: 13 May 2008
Posts: 56
Location: Chennai
|
|
|
|
| I think we cannot do VBS to VB cannot be done directly as records are spanned. |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
| srajendran2 wrote: |
| I think we cannot do VBS to VB cannot be done directly as records are spanned. |
No. As long as the output LRECL is >= than the input LRECL an IEBGENER or similar utility should not have a problem. In fact, as long as the longest input record is <= the output LRECL you should be OK. |
|
| Back to top |
|
|
Marso
REXX Moderator
Joined: 13 Mar 2006
Posts: 1353
Location: Israel
|
|
|
|
| srajendran2 wrote: |
| Instead of changing in VBS to VB in JCL and COBOL, can I just use a SORT after VBS is created and copy it to VB? will it give the same result? |
That would not be wise, to say the least: you will spend valuable CPU time for nothing and (more than) double the disk space needed for that file.
Just update your program and your JCL. |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
| Marso wrote: |
| srajendran2 wrote: |
| Instead of changing in VBS to VB in JCL and COBOL, can I just use a SORT after VBS is created and copy it to VB? will it give the same result? |
That would not be wise, to say the least: you will spend valuable CPU time for nothing and (more than) double the disk space needed for that file.
Just update your program and your JCL. |
It's more difficult than Marso thinks to estimate the size increase for the data set. As previously mentioned, the BLKSIZE is not appropriate for a 3390. A more appropriate BLKSIZE, say 27998, would reduce the data set size by perhaps 40%. The problem with changing over to VB is the actual distribution of logical record lengths. We do not know that. I doubt srajendran2 knows it. All we know is the defined LRECL which specifies the maximum possible record length. In real world VB or VBS data sets, the actual maximum record length is often much lower than the maximum. srajendran2 should, as soon as possible, determine the actual maximum record length in the data set. Actually, today would be best! |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| In real world VB or VBS data sets, the actual maximum record length is often much lower than the maximum |
For VB, this is true. HOWEVER, I have worked with VBS data sets (not SMF, by the way), and I can state with certainty (having seen the block length bar chart) that a VBS data set on disk will have every block length within 4 bytes of the BLKSIZE value. When z/OS is filling a block for a VBS data set a starting segment will be created as long as there are 5 or more bytes left in the block (4 bytes for the SDW and at least 1 byte for the data record). This particular project was some time back, but I cannot imagine that VBS behavior would have changed that much. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Update: I have confirmed on my z/OS 2.1 system that an SMF data set with RECFM=VBS,LRECL=32760,BLKSIZE=27998 has all blocks between 27994 and 27998 bytes long, except for the last. So VBS behavior has not changed since my first observation way back when. |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
The intent of the VBS design is to have essentially constant length physical records. Mr. Sample is just saying IBM has succeeded.
VBS came about at the same time IBM was pushing RPS (the 2305 and 3330) disks to improve the relatively disappointing performance of the original System/360 disks. Fixed length records were initially regarded as being important so RPS calculations would come out correctly, so VBS was regarded as important (See the footnote).
Normal VB is going to have variable length physical records. The difference depends on the characteristics of the logical records in the data set. There is nothing wrong with this.
I spent some time yesterday writing up a program to report this. Running a variety of data sets through the program reported very little difference from physical record to physical record. Then I realized I didn't include the last physical record! The resulted in indications of considerable size differences. But, then, one would expect the last physical record will be smaller than the others, so including it in the sample is probably not a good idea.
--------
It turned out this RPS calculation was a lot of foolishness. Sequential data sets determined the RPS number for the next record when it read a record; it didn't have to calculate anything.
Emulated 3390 seems to ignore the set sector command, and appears to return garbage with the read sector command. |
|
| Back to top |
|
|
|
|
