Portal | Manuals | References | Downloads | Info | Programs | JCLs | Mainframe wiki | Quick Ref
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Profile Log in to check your private messages Log in
 
VBS to VB in COBOL and JCL

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
srajendran2

New User


Joined: 13 May 2008
Posts: 56
Location: Chennai

PostPosted: Fri Jun 01, 2018 3:04 am    Post subject: VBS to VB in COBOL and JCL
Reply with quote

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

Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8376
Location: Dubuque, Iowa, USA

PostPosted: Fri Jun 01, 2018 3:23 am    Post subject: Reply to: VBS to VB in COBOL and JCL
Reply with quote

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
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 657
Location: The Universe

PostPosted: Fri Jun 01, 2018 7:40 am    Post subject:
Reply with quote

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
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 657
Location: The Universe

PostPosted: Fri Jun 01, 2018 7:57 am    Post subject: Re: Reply to: VBS to VB in COBOL and JCL
Reply with quote

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
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 657
Location: The Universe

PostPosted: Fri Jun 01, 2018 12:03 pm    Post subject:
Reply with quote

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
View user's profile Send private message
srajendran2

New User


Joined: 13 May 2008
Posts: 56
Location: Chennai

PostPosted: Fri Jun 01, 2018 7:59 pm    Post subject:
Reply with quote

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
View user's profile Send private message
srajendran2

New User


Joined: 13 May 2008
Posts: 56
Location: Chennai

PostPosted: Fri Jun 01, 2018 8:52 pm    Post subject:
Reply with quote

I think we cannot do VBS to VB cannot be done directly as records are spanned.
Back to top
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 657
Location: The Universe

PostPosted: Fri Jun 01, 2018 10:20 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Marso

REXX Moderator


Joined: 13 Mar 2006
Posts: 1292
Location: Israel

PostPosted: Sun Jun 03, 2018 2:19 pm    Post subject:
Reply with quote

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
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 657
Location: The Universe

PostPosted: Sun Jun 03, 2018 7:39 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8376
Location: Dubuque, Iowa, USA

PostPosted: Sun Jun 03, 2018 10:02 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8376
Location: Dubuque, Iowa, USA

PostPosted: Tue Jun 05, 2018 12:02 am    Post subject:
Reply with quote

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
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 657
Location: The Universe

PostPosted: Tue Jun 05, 2018 12:29 am    Post subject:
Reply with quote

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

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts SQL IN predicate using COBOL table jerryte DB2 16 Fri Jun 29, 2018 10:30 pm
No new posts Converting SAS code to Cobol or Easyt... Ashish.Raghav All Other Mainframe Topics 6 Fri Jun 29, 2018 6:01 pm
No new posts Can we use a file both as input and o... Chiku kumar COBOL Programming 6 Thu Jun 28, 2018 3:30 pm
No new posts Varying List Select SQL Query In DB2 ... NikhilGuptaGaya DB2 5 Wed Jun 27, 2018 11:01 pm
This topic is locked: you cannot edit posts or make replies. Need help - DB2 Dynamic SQL Program e... NikhilGuptaGaya DB2 6 Sat Jun 23, 2018 1:58 pm

Facebook
Back to Top
 
Job Vacancies | Forum Rules | Bookmarks | Subscriptions | FAQ | Polls | Contact Us