In [EMAIL PROTECTED], on 05/25/2006
at 01:00 PM, Paul Gilmartin [EMAIL PROTECTED] said:
Why? I thought it was possible to write over an EOF.
If you're going to reformat the extent as part of EOV then what's the
point of writing an EOF in it?
Doesn't DISP=MOD do that regularly?
Not for
In
[EMAIL PROTECTED],
on 05/24/2006
at 04:51 PM, Chase, John [EMAIL PROTECTED] said:
Yeah -- HARBA and HURBA (High Allocated Relative Byte Address and
High Used RBA) live in the catalog entry.
More to the point, you really don't want an EOF at the beginning of an
extent that is supposed to be
In [EMAIL PROTECTED], on 05/24/2006
at 06:26 PM, Paul Gilmartin [EMAIL PROTECTED] said:
Would this have any adverse interaction with writing a physical EOF
at the beginning of a newly allocated extent?
No; the real kicker is the adverse interaction with the CI formatting.
--
Shmuel
In [EMAIL PROTECTED], on 05/24/2006
at 09:26 PM, Bruce Black [EMAIL PROTECTED] said:
An EOF In VSAM beyond the HURBA would probably be ignored,
Wouldn't it blow you out of the water when you tried writing new
records in that space? AFAIK the VSAM PUT logic expects the space to
be CI
Wouldn't it blow you out of the water when you tried writing new
records in that space? AFAIK the VSAM PUT logic expects the space to
be CI formatted.
If allocation wrote the EOF into the VSAM cluster, then VSAM OPEN or EOV
would immediately format the CA with CIs as soon as it is needed,
In a recent note, Shmuel Metz (Seymour J.) said:
Date: Thu, 25 May 2006 08:30:54 -0300
More to the point, you really don't want an EOF at the beginning of an
extent that is supposed to be CI formatted.
Why? I thought it was possible to write over an EOF. Doesn't
DISP=MOD do that
In a recent note, Bruce Black said:
Date: Thu, 25 May 2006 10:10:26 -0400
Wouldn't it blow you out of the water when you tried writing new
records in that space? AFAIK the VSAM PUT logic expects the space to
be CI formatted.
If allocation wrote the EOF into the VSAM cluster,
With SMS, RLSE, (Yes, Immediate) at least I think I've seen it,
happens at step end. You're correct for non-SMS datasets.
You don't think about partial release of the space management
function activated via management class, do you?
A data set might loose its allocated space during space
LE has nothing whatsoever to do with it.
A dataset is a dataset is a dataset.
Well, there are those who get an EOF written at allocation
time and those that don't. Can't remember if having SMS
active is sufficient of if the data set needs to be
managed to get the EOF written.
Peter
In [EMAIL PROTECTED], on 05/23/2006
at 12:05 PM, David Speake [EMAIL PROTECTED] said:
The group in my shop responsible for care and feeding of this product
contend that the vendor has told them that Since the product is LE
compliant, it cannot write into a dataset that has been generated by
In [EMAIL PROTECTED],
on 05/23/2006
at 10:52 AM, Gibney, Dave [EMAIL PROTECTED] said:
RLSE happens at the end of the BR14 step. If your DATACLAS or
space allocations don't have sufficient secondary and you specify
RLSE via JCL or SMS, you can be burnt with x37 abends.
Which has nothing to
In [EMAIL PROTECTED], on 05/23/2006
at 12:05 PM, David Speake [EMAIL PROTECTED] said:
The group in my shop responsible for care and feeding of this product
contend that the vendor has told them that Since the product is LE
compliant, it cannot write into a dataset that has been
In a recent note, (IBM Mainframe Discussion List) said:
Date: Wed, 24 May 2006 08:08:43 EDT
In [EMAIL PROTECTED], on 05/23/2006
at 12:05 PM, David Speake [EMAIL PROTECTED] said:
The group in my shop responsible for care and feeding of this product
contend that the vendor has
In a recent note, Thomas Berg said:
Date: Wed, 24 May 2006 05:51:41 +0200
== Kirk Talman == wrote2006-05-24 01:40:
Call it a design issue. There is no flag in the VTOC that says if the
file has data in it.
Well, even an empty can has a bottom, so why can't a
In a recent note, Art Celestini said:
Date: Tue, 23 May 2006 20:18:02 -0400
If I am not mistaken, if you allocate on an SMS-managed volume
and specify enough DCB attributes so that SMS knows that it is
intended to be a SAM data set, SMS will write an EOF at the
beginning of the
-Ursprungligt meddelande-
Från: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] För Paul Gilmartin
Skickat: den 24 maj 2006 15:43
Till: IBM-MAIN@BAMA.UA.EDU
Ämne: Re: Write to BR14 allocated PSDS - Unitech ACR 3.3
In a recent note, Thomas Berg said:
Date
If I am not mistaken, if you allocate on an SMS-managed volume
and specify enough DCB attributes so that SMS knows that it is
intended to be a SAM data set, SMS will write an EOF at the
beginning of the first track and correspondingly set DS1LSTAR.
I seem to recall this as one of the features
Bruce,
Here are the places where SMS writing an EOF is documented.
z/OS V1R7.0 DFSMS Using Data Sets
When the system allocates a new SMS data set with DSORG=PS or no DSORG,
the access methods treat the data set as being null, that is, having no
data. A program can safely read the data set
In [EMAIL PROTECTED], on 05/24/2006
at 07:50 AM, Paul Gilmartin [EMAIL PROTECTED] said:
Underreaching. Why the restriction to SAM? Allocation ought to
write EOF whenever a NEW primary extent is allocated, regardless of
known or unknown DSORG.
VSAM?
--
Shmuel (Seymour J.) Metz,
On Wed, 24 May 2006 07:50:12 -0600, Paul Gilmartin
[EMAIL PROTECTED] wrote:
...
Underreaching. Why the restriction to SAM? Allocation ought to
write EOF whenever a NEW primary extent is allocated, regardless
of known or unknown DSORG.
...
??? Where (or perhaps, what) is EOF for a
The problem here is one of imprecise communication.
IEFBR14 does not create datasets.
IEFBR14 does not allocate datasets.
IEFBR14 does not initialize datasets.
I suspect we all knew what the gist of the vendor's
recommendation was but, as written in the OP's post,
one had to wonder.
What we
Can't remember if having SMS active is sufficient of if the data set needs to
be managed to get the EOF written.
It's been a while.
But, I believe it has to be managed.
-
-teD
300,000 Kilometres per Second
Not only is it a good idea!
It's the LAW!!!
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Shmuel Metz (Seymour
J.)
Paul Gilmartin said:
Underreaching. Why the restriction to SAM? Allocation ought to
write
EOF whenever a NEW primary extent is allocated, regardless of known
or
unknown DSORG.
In a recent note, Chase, John said:
Date: Wed, 24 May 2006 16:51:46 -0500
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Shmuel Metz (Seymour
J.)
Paul Gilmartin said:
Underreaching. Why the restriction to SAM? Allocation ought to write
eah -- HARBA and HURBA (High Allocated Relative Byte Address and High
Used RBA) live in the catalog entry.
Would this have any adverse interaction with writing a physical
EOF at the beginning of a newly allocated extent?
Actually it is in the VVR in the VVDS. Writing an EOF would have no
I have a request for assistance in finding all JCL steps that use IEFBR14 to
create (allocate might be a better word choice) data sets that are to be
!written! to by INFOGIX/Unitech ACR version 3.3. The group in my shop
responsible for care and feeding of this product contend that the vendor has
Sounds like FUD. BR14 is just a trivial program. The allocation is
not done by BR14, but by the same allocation at step initiation that
is used when you execute any other program.
On Tue, 23 May 2006 12:05:19 -0500, David Speake [EMAIL PROTECTED]
wrote:
I have a request for assistance in
PSDS - Unitech ACR 3.3
Sounds like FUD. BR14 is just a trivial program. The allocation is
not done by BR14, but by the same allocation at step initiation that
is used when you execute any other program.
On Tue, 23 May 2006 12:05:19 -0500, David Speake
[EMAIL PROTECTED]
wrote:
I have
them aware of the error of their ways.
Don Imbriale
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf
Of David Speake
Sent: Tuesday, May 23, 2006 1:05 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Write to BR14 allocated PSDS - Unitech ACR 3.3
I have a request
Tom,
Shall we add I for FUD making FUDI, I for Ignorance, that is?
Chris Mason
- Original Message -
From: Tom Marchant [EMAIL PROTECTED]
Newsgroups: bit.listserv.ibm-main
To: IBM-MAIN@BAMA.UA.EDU
Sent: Tuesday, 23 May, 2006 7:45 PM
Subject: Re: Write to BR14 allocated PSDS - Unitech
Don Imbriale said:
Whenever I hear vendor claims like Since the product is LE compliant,
it cannot write into a dataset that has been generated by the IEFBR14
utility, I insist that they provide specific references to
documentation from IBM that describes that particular behavior.
Usually
RLSE doesn't happen unless the dataset has been opened for output. Which
BR14 doesn't do.
dataset allocated with IEFBR14 is exactly like specified in JCL - complete
with no EOF or anything.
Mike
--
For IBM-MAIN subscribe /
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Chris Mason
Tom,
Shall we add I for FUD making FUDI, I for
Ignorance, that is?
You left out Superstition: FUDSI. :-)
-jc-
--
For
Pullman, WA 99164-1222
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Mike Bell
Sent: Tuesday, May 23, 2006 11:28 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Write to BR14 allocated PSDS - Unitech ACR 3.3
RLSE doesn't happen unless
The group in my shop
responsible for care and feeding of this product contend that the vendor has
told them that Since the product is LE compliant, it cannot write into a
dataset that has been generated by the IEFBR14 utility.
I know absolutely nothing about LE, so this is pure conjecture. If
Ahh Bruce. Spoilsport. The other guys had just about convinced me I was
right, as much by their attitude as by hard information (dangerous
orientation). I guess I should have phrased it a bit better. I Browsed
IEFBR14 20+ years ago (or maybe it was ROSCOE's ZAP monitor) so I knew it
did nothing.
In a recent note, Bruce Black said:
Date: Tue, 23 May 2006 14:40:37 -0400
I know absolutely nothing about LE, so this is pure conjecture. If LE
always opens pre-existing datasets as INOUT, meaning that it reads from
the dataset before it starts outputting to it, then it is possible
Call it a design issue. There is no flag in the VTOC that says if the
file has data in it.
We have a series of in-house utilities to deal with this.
EOF opens and closes a series of QSAM files whose DDNAMEs are EOFnn where
nn is 01, 02, 03, ...
Creating it is a good programming exercise. I
If I am not mistaken, if you allocate on an SMS-managed volume
and specify enough DCB attributes so that SMS knows that it is
intended to be a SAM data set, SMS will write an EOF at the
beginning of the first track and correspondingly set DS1LSTAR.
I seem to recall this as one of the features
On May 23, 2006, at 6:04 PM, Paul Gilmartin wrote:
In a recent note, Bruce Black said:
Date: Tue, 23 May 2006 14:40:37 -0400
I know absolutely nothing about LE, so this is pure conjecture.
If LE
always opens pre-existing datasets as INOUT, meaning that it reads
from
the dataset
== Kirk Talman == wrote2006-05-24 01:40:
Call it a design issue. There is no flag in the VTOC that says if the
file has data in it.
Well, even an empty can has a bottom, so why can't a file ?
Thomas Berg
--
__
Mundus Vult Decipi
41 matches
Mail list logo
