|
View previous topic :: View next topic
|
| Author |
Message |
darioits
New User
Joined: 10 Sep 2019
Posts: 5
Location: Italy
|
|
|
|
I work from 30 year on mainframe as OPC/JCL/REXX/CLIST scheduling and my problem is recently a lot of file aren't with correctly allocated with proper blksize (blksize are equal to lrecl), but jcl are correctly with blksize=0 and aren't changed (file are FB sequential)
In IBM manual I find this sentence
“Block size (BLKSIZE) specifies the maximum length, in bytes, of a physical block of storage in MVS. If BLKSIZE(0) is specified, the system will determine the optimal block size based on the maximum record length (LRECL) and the physical characteristics of the disk, or approximately half of a physical track. Half track blocking is optimal in that it reduces the amount of wasted storage on the disk” also If BLKSIZE(0) is specified for Direct Access (DA) data sets, the system does not determine the block size
My question is, how can I check if something is changed on mainfame, it's seems central support does not know the topic very well?
Thank you in advance |
|
| Back to top |
|
 |
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010
Posts: 3051
Location: NYC,USA
|
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
BLKSIZE=0 basically allows the system to select what it regards as an "optimal" BLKSIZE. "Optimal" is debatable. "Optimal" appears to be biased in terms of capacity; on 3380 and 3390 (or emulated 3380 or 3390) devices it amounts to two records per track. On 3350 and earlier disk devices it amounts to one record per track. This is governed by the maximum allowable BLKSIZE is 32760.
On 3390 the maximum possible BLKSIZE for two records per track is 27998 bytes (or 55996 bytes per track). Anything larger gets one record per track, so 27999 would get one record per track, so 27997 bytes of possible capacity would not be used. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| my problem is recently a lot of file aren't with correctly allocated with proper blksize (blksize are equal to lrecl), but jcl are correctly with blksize=0 and aren't changed (file are FB sequential) |
This is quite possible -- the PRIMARY source for DCB information (including the block size) is the program. If the program is coded with LRECL and BLKSIZE being the same, then the JCL BLKSIZE=0 value will be ignored. And the system won't arbitrarily change block size on an existing data set. |
|
| Back to top |
|
|
darioits
New User
Joined: 10 Sep 2019
Posts: 5
Location: Italy
|
|
|
|
| indeed many of these programs are new (migrating from sas to cobol), in which cobol section could programmer check if this clause exists |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
| Quote: |
| my problem is recently a lot of file aren't with correctly allocated with proper blksize (blksize are equal to lrecl), ... |
With RECFM = FB, LRECL = BLKSIZE is not necessarily either "correct" or "optimal." Consider the very common LRECL=80. It's plain stupid for BLKSIZE=80! You will get roughly 50 records per track, about 4000 used bytes of a net capacity of more than 50,000 bytes. With RECFM=FB, BLKSIZE must be a multiple of LRECL. For RECFM=FB, LRECL=80, System Determined BLKSIZE will be 27920. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| in which cobol section could programmer check if this clause exists |
Look in the FILE SECTION at the definition for the file. BLOCK CONTAINS is the specific clause to check in the FILE SECTION. |
|
| Back to top |
|
|
darioits
New User
Joined: 10 Sep 2019
Posts: 5
Location: Italy
|
|
|
|
after a lot of test we discover the problem that all this 3 statement in FD must be declared, unless otherwise specified the Blksize is wrong
BLOCK 0 RECORDS
RECORDING MODE IS F
LABEL RECORDS STANDARD.
Maybe there's some default in compiler?
Thank you in advance |
|
| Back to top |
|
|
Nic Clouston
Global Moderator
Joined: 10 May 2007
Posts: 2455
Location: Hampshire, UK
|
|
|
|
| Quote: |
| Maybe there's some default in compiler? |
Look in the compiler listing - defaults used are listed there. |
|
| Back to top |
|
|
darioits
New User
Joined: 10 Sep 2019
Posts: 5
Location: Italy
|
|
|
|
| the only difference in compiling is the wrong blksiza has QSAM=F, the right QSAM=FB |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| As of version 5.1 of Enterprise COBOL, the LABEL RECORDS clause is checked for syntax but otherwise has no impact on the program. If you are running version 5.1 or later of Enterprise COBOL, you don't have to put the LABEL RECORDS clause on an FD. |
|
| Back to top |
|
|
darioits
New User
Joined: 10 Sep 2019
Posts: 5
Location: Italy
|
|
|
|
this is a version:
IBM Enterprise COBOL for z/OS 6.1.0 |
|
| Back to top |
|
|
hankoerlemans
New User
Joined: 25 Jan 2018
Posts: 57
Location: Australia
|
|
|
|
| BLOCK0 compiler option is probably what you need to explore. |
|
| Back to top |
|
|
|
|
