In 20140719043544.8bf1e6d3c...@terpsichore.ugcs.caltech.edu, on
07/18/2014
at 09:35 PM, glen herrmannsfeldt g...@ugcs.caltech.edu said:
OK, but the code for doing OPEN and CLOSE can easily be in an
overlay,
The SVC transient areas were only 1 KiB; at that size, I'm not sure
that anything was
On Fri, 18 Jul 2014 07:40:46 +0200, Peter Hunkeler wrote:
RECFM=U stands for undefined. As someone else already pointed out, every block
can be of different length, no matter what block size is set. The block size
field in the DCB is used to communicate the current block's length between the
Hi
I am afraid that reading the JFCB to determine the BLKSIZE is unlikely to
work if the DD Statement doesn't have a BLKSIZE parameter coded.
Remember the merge order for OPEN is program, DD Statement, and DSCB.
Kind Regards - Terry
Director
KMS-IT Limited
228 Abbeydale Road South
Dore
Hi
It would appear that open does complete the DCBBLKSI field, or it does on
z/OS 1.13 when the following code is executed.
LAR10,TESTFILEMAKE DCB
USING IHADCB,R10 ADDRESSABLE
OPEN
Grasping at straws . . . Did this test behave any differently between
DSORG=PO and DSORG=PS?
===
Date: Fri, 18 Jul 2014 09:37:19 +0100
From: terry_sambro...@btconnect.com
Subject: Re: OPEN not filling in DCBBLKSI for RECFM=U data set
To: IBM-MAIN@LISTSERV.UA.EDU
Hi
It would
Remember the merge order for OPEN is program, DD Statement, and DSCB.
If memory serves me right, the JFCB is built by allocation long before OPEN. It
contains a) the dcb parms from the DD (or SVC 99), and b) data from the DSCB
for all fields not specified on the DD. b) happens only for
This sets blocksize in the DCB on 1.13 whether pointing to a member or the
library or whether MACRF=(GL) or MACRF=(R).
TEST CSECT ,
PRINT NOGEN
SAVE (14,12)
LR12,15
USING TEST,12
LA14,SAVE
ST13,4(,14)
ST
On Fri, 18 Jul 2014 07:40:46 +0200, Peter Hunkeler wrote:
RECFM=U stands for undefined. As someone else already pointed out, every block
can be of different length, no matter what block size is set. The block size
field in the DCB is used to communicate the current block's length between the
On Fri, 2014-07-18 at 07:38 -0500, Bill Godfrey wrote:
The block size field is not set to the current block's length for BSAM
READ either. For BSAM READ, the length is determined after a CHECK or
WAIT by subtracting the residual count from the length used by READ,
as described in Using Data
On Fri, 18 Jul 2014 13:27:59 +0200, Peter Hunkeler wrote:
Remember the merge order for OPEN is program, DD Statement, and DSCB.
If memory serves me right, the JFCB is built by allocation long before OPEN.
It contains a) the dcb parms from the DD (or SVC 99), and b) data from the
DSCB for all
For an undefined record format file;
The blocksize from the dscb is the maximum blocksize for that dataset.
You would getmain a buffer of that size for use by a GET move mode macro.
The actual size of the block retrived is returned in the DCB lrecl field.
It can theoretically be equal to or
You are thinking of the DCBLRECL field, not the block size field, and only
for QSAM GET.
I stand corrected. You're absolutely right.
--
Peter Hunkeler
--
For IBM-MAIN subscribe / signoff / archive access instructions,
From DFSMS Using Data Sets
System-determined block size: The system can derive the best block size for
DASD, tape, and spooled data sets. The system does not derive a block size for
BDAM, old, or unmovable data sets, or when the RECFM is U.
On Fri, 18 Jul 2014 09:21:15 -0400, David Andrews wrote:
On Fri, 2014-07-18 at 07:38 -0500, Bill Godfrey wrote:
The block size field is not set to the current block's length for BSAM
READ either. For BSAM READ, the length is determined after a CHECK or
WAIT by subtracting the residual count
In 53c82c44.10...@dignus.com, on 07/17/2014
at 04:04 PM, Thomas David Rivers riv...@dignus.com said:
I've been wading thru the documentation (DFSMS Using Data Sets),
etc... trying to figure out why the DCBBLKSI field of my DCB is not
being filled in for a RECFM=U data set for INPUT.
Are there
In 8181732357726051.wa.paulgboulderaim@listserv.ua.edu, on
07/17/2014
at 03:08 PM, Paul Gilmartin
000433f07816-dmarc-requ...@listserv.ua.edu said:
Would that be in the catalog or in the VTOC?
DSCB1 for non-VSAM.
That sounds strange. If you omitted or specified BLKSIZE=0, I
believe
In 0741344928727709.wa.paulgboulderaim@listserv.ua.edu, on
07/18/2014
at 01:09 AM, Paul Gilmartin
000433f07816-dmarc-requ...@listserv.ua.edu said:
Subsequently, the size of each block as read could be returned in
DCBBLKSI
No. DCBLRECL.
--
Shmuel (Seymour J.) Metz, SysProg and
In ez-13225146.1877254...@gmx.ch, on 07/18/2014
at 07:40 AM, Peter Hunkeler p...@gmx.ch said:
RECFM=U stands for undefined. As someone else already pointed out,
every block can be of different length, no matter what block size
is set. The block size field in the DCB is used to communicate the
In ez-1921262965.1751167...@gmx.ch, on 07/18/2014
at 01:27 PM, Peter Hunkeler p...@gmx.ch said:
If memory serves me right, the JFCB is built by allocation long
before OPEN. It contains a) the dcb parms from the DD (or SVC 99),
and b) data from the DSCB for all fields not specified on the DD.
On 07/18/2014 09:53 AM, Tim Deller wrote:
From DFSMS Using Data Sets
System-determined block size: The system can derive the best block size for
DASD, tape, and spooled data sets. The system does not derive a block size
for BDAM, old, or unmovable data sets, or when the RECFM is U.
Which
On Fri, 18 Jul 2014 10:53:55 -0500, Joel C. Ewing wrote:
On 07/18/2014 09:53 AM, Tim Deller wrote:
From DFSMS Using Data Sets
System-determined block size: The system can derive the best block size for
DASD, tape, and spooled data sets. The system does not derive a block size
for BDAM,
Thomas David Rivers wrote:
I've been wading thru the documentation (DFSMS Using Data Sets), etc...
trying to figure out why the DCBBLKSI field of my DCB is not
being filled in for a RECFM=U data set for INPUT. (Non-LBI)
Many thanks to everyone who took a moment to help look into this.
After
Paul Gilmartin wrote:
ISTR hearing that for RECFM=U, SDB selects 32760.
You might have heard that, but it does not match my recollection; and,
on our internal z/OS V2.1 system, tests with both ISPF OPT3.2 and JCL
show a resulting block size of zero if one is not specified for RECFM=U.
--
On Fri, 18 Jul 2014 13:23:29 -0400, John Eells wrote:
Paul Gilmartin wrote:
ISTR hearing that for RECFM=U, SDB selects 32760.
You might have heard that, but it does not match my recollection; and,
on our internal z/OS V2.1 system, tests with both ISPF OPT3.2 and JCL
show a resulting block size
On Fri, 18 Jul 2014 13:23:29 -0400, John Eells wrote:
Paul Gilmartin wrote:
ISTR hearing that for RECFM=U, SDB selects 32760.
You might have heard that, but it does not match my recollection; and,
on our internal z/OS V2.1 system, tests with both ISPF OPT3.2 and JCL
show a resulting block size
On Fri, 18 Jul 2014 12:54:51 -0400, Thomas David Rivers wrote:
After Terry posted some sample code that indicated the DCBBLKSI
*was* set after an OPEN (and a collected phew from me) - I started
digging into it more.
Sigh of relief.
It looks like this was, in fact, a bug in the OPEN EXIT - it
Paul wrote:
IBM designers a half century ago are not to be forgiven for the
continuing anguish they inflicted on programmers in order to save
two bytes in the DCB. There should have been two separate fields,
one for the label block size; the other for the size of the
block currently
I've been wading thru the documentation (DFSMS Using Data Sets), etc...
trying to figure out why the DCBBLKSI field of my DCB is not
being filled in for a RECFM=U data set for INPUT. (Non-LBI)
In particular, I want to allocate a buffer of sufficient size to hold
any block
we might read for a
On Thu, 17 Jul 2014 16:04:20 -0400, Thomas David Rivers wrote:
I put zeros into the DCB before the OPEN; then I do the OPEN... expecting
the DCB to have the DCBBLKSI field set to the block size...
But - it remains zero.
The JCL (well, an SVC 99 actually) doesn't specify a BLKSIZE for the file.
On Thu, 17 Jul 2014 16:04:20 -0400, Thomas David Rivers wrote:
I've been wading thru the documentation (DFSMS Using Data Sets), etc...
trying to figure out why the DCBBLKSI field of my DCB is not
being filled in for a RECFM=U data set for INPUT. (Non-LBI)
The JCL reference has this:
quote
On Thu, 17 Jul 2014 16:04:20 -0400, Thomas David Rivers wrote:
Does anyone know why the DCBBLKSI field would not be filled in ?
Was the OPEN successful?
--
Tom Marchant
--
For IBM-MAIN subscribe / signoff / archive access
On Thu, 17 Jul 2014 15:39:43 -0500, Tom Marchant wrote:
In particular, I want to allocate a buffer of sufficient size to hold
any block
we might read for a pre-existing RECFM=U data set.
Why not use 32760?
Don't some devices support larger blocks nowadays?
(But is that returned in DCBBLKSI?)
Thomas David Rivers wrote:
I've been wading thru the documentation (DFSMS Using Data Sets), etc...
trying to figure out why the DCBBLKSI field of my DCB is not
being filled in for a RECFM=U data set for INPUT. (Non-LBI)
In particular, I want to allocate a buffer of sufficient size to hold
On Thu, 17 Jul 2014 17:24:30 -0400, Thomas David Rivers wrote:
- After the OPEN has finished, the DCBBLKSI field remains 0.
Do you have a DCBE?
- In this case, we _could_ use 32760 for the size of the read buffer
to allocate.. that seems rather large... and, does LBI mean that
Tom Marchant wrote:
On Thu, 17 Jul 2014 17:24:30 -0400, Thomas David Rivers wrote:
- After the OPEN has finished, the DCBBLKSI field remains 0.
Do you have a DCBE?
No DCBE - just an ol' below-the-line DCB.
- In this case, we _could_ use 32760 for the size of the read
On Thu, 17 Jul 2014 21:11:52 -0400, Thomas David Rivers wrote:
But - what's the tracklen of a BSAM UNIX file?
Given that you posted a DSLIST INFO showing UNIT=3390, I'm
calling that question hypothetical. But OPEN's not filling in DCBBLKSI
remains a mystery.
So, does this mean you can use
On Thu, 17 Jul 2014 21:11:52 -0400, Thomas David Rivers wrote:
pouring thru the documentation, I could only find sentences that indicate the
DCBBLKSI
is only filled in by OPEN for F/FB/V/VB files. This leads me to wonder,
perhaps it
simply isn't filled in for RECFM=U? (Which is what appears
RECFM=U stands for undefined. As someone else already pointed out, every block
can be of different length, no matter what block size is set. The block size
field in the DCB is used to communicate the current block's length between the
program and the access method. I can imagine this to be the
38 matches
Mail list logo
