Write to BR14 allocated PSDS - Unitech ACR 3.3

[David Speake]

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
told them that "Since the product is LE compliant, it cannot write into a
dataset that has been generated by the IEFBR14 utility". There WILL be
testing (SMS and non-SMS) before this task is undertaken. I read the thread
on "EOF MARKS" Tue, 30 Mar 2004 12:51:40 -0600, and loved the SMSBR14 idea
for that situation. But my question is: Cannot write? 

I know that READING a BR14 allocated data set has ALWAYS (prior to SMS) been
a fine recipe for disaster, but writing? And if this IS true, what does LE
have to do with it.

P. S.INFOGIX is an IBM BP 
  
  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Tom Marchant]

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 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
>told them that "Since the product is LE compliant, it cannot write into a
>dataset that has been generated by the IEFBR14 utility". There WILL be
>testing (SMS and non-SMS) before this task is undertaken. I read the thread
>on "EOF MARKS" Tue, 30 Mar 2004 12:51:40 -0600, and loved the SMSBR14 idea
>for that situation. But my question is: Cannot write?
>
>I know that READING a BR14 allocated data set has ALWAYS (prior to SMS) 
been
>a fine recipe for disaster, but writing? And if this IS true, what does LE
>have to do with it.
>
>P. S.INFOGIX is an IBM BP
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Gibney, Dave]

   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.


Dave Gibney  [EMAIL PROTECTED]
System Programmer(509) 335-7359
Information Technology
Washington State University
Pullman, WA 99164-1222

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Tom Marchant
> Sent: Tuesday, May 23, 2006 10:45 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Write to BR14 allocated 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 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
> >told them that "Since the product is LE compliant, it cannot write
into a
> >dataset that has been generated by the IEFBR14 utility". There WILL
be
> >testing (SMS and non-SMS) before this task is undertaken. I read the
> thread
> >on "EOF MARKS" Tue, 30 Mar 2004 12:51:40 -0600, and loved the SMSBR14
> idea
> >for that situation. But my question is: Cannot write?
> >
> >I know that READING a BR14 allocated data set has ALWAYS (prior to
SMS)
> been
> >a fine recipe for disaster, but writing? And if this IS true, what
does
> LE
> >have to do with it.
> >
> >P. S.INFOGIX is an IBM BP
> >
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Imbriale, Donald (Exchange)]

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
they cannot, so I make 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 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
>told them that "Since the product is LE compliant, it cannot write into
a
>dataset that has been generated by the IEFBR14 utility". There WILL be
>testing (SMS and non-SMS) before this task is undertaken. I read the
thread
>on "EOF MARKS" Tue, 30 Mar 2004 12:51:40 -0600, and loved the SMSBR14
idea
>for that situation. But my question is: Cannot write?
>
>I know that READING a BR14 allocated data set has ALWAYS (prior to SMS)
been
>a fine recipe for disaster, but writing? And if this IS true, what does
LE
>have to do with it.
>


***
Bear Stearns is not responsible for any recommendation, solicitation, 
offer or agreement or any information about any transaction, customer 
account or account activity contained in this communication.
***

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Chris Mason]

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: 
Sent: Tuesday, 23 May, 2006 7:45 PM
Subject: Re: Write to BR14 allocated 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 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
> >told them that "Since the product is LE compliant, it cannot write into a
> >dataset that has been generated by the IEFBR14 utility". There WILL be
> >testing (SMS and non-SMS) before this task is undertaken. I read the
thread
> >on "EOF MARKS" Tue, 30 Mar 2004 12:51:40 -0600, and loved the SMSBR14
idea
> >for that situation. But my question is: Cannot write?
> >
> >I know that READING a BR14 allocated data set has ALWAYS (prior to SMS)
> been
> >a fine recipe for disaster, but writing? And if this IS true, what does
LE
> >have to do with it.
> >
> >P. S.INFOGIX is an IBM BP
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Craddock, Chris]

 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
> they cannot, so I make them aware of the error of their ways.

And do ya say "Liar liar, pants on fire"? You should.

IEFBR14 is a two instruction program. It does not do ANYTHING but return
with a zero condition code. z/OS allocation creates the datasets
referenced in the JCL. IEFBR14 is just used as a dummy program to get
allocation to do its thing. LE has nothing whatsoever to do with it. A
dataset is a dataset is a dataset.

CC

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Mike Bell]

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 / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Chase, John]

> -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 IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Gibney, Dave]

   With SMS, RLSE, (Yes, Immediate) at least I think I've seen it,
happens at step end. You're correct for non-SMS datasets.


Dave Gibney  [EMAIL PROTECTED]
System Programmer(509) 335-7359
Information Technology
Washington State University
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 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 / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Bruce Black]

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 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 that 
a dataset that was allocated with no EOF may always cause errors.


Of course, this has nothing to do with IEFBR14 per se, but with a 
dataset which is allocated in JCL but is never OPENED for output.  The 
PGM= could be anything. 


--
Bruce A. Black
Senior Software Developer for FDR
Innovation Data Processing 973-890-7300
personal: [EMAIL PROTECTED]
sales info: [EMAIL PROTECTED]
tech support: [EMAIL PROTECTED]
web: www.innovationdp.fdr.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[David Speake]

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. As far as I know LE does NOT open everthing INOUT but the
product in question just might. Cannot imagine WHY, but you just let in a
tiny particle of doubt. Whine.   

You guys should charge, may teach me to THINK yet. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Paul Gilmartin]

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 that
> a dataset that was allocated with no EOF may always cause errors.
> 
> Of course, this has nothing to do with IEFBR14 per se, but with a
> dataset which is allocated in JCL but is never OPENED for output.  The
> PGM= could be anything.
> 
But, in the broader view, Why can't IBM's premier OS,
whose predecessors helped send men to the moon and back, do a
better job of keeping track of where files end?

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Kirk Talman]

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 believe they can even be 
implemented in Cobol using the OPTIONAL file concept.

IBM Mainframe Discussion List  wrote on 5/23/2006 
7:04:29 PM:

> But, in the broader view, Why can't IBM's premier OS,
> whose predecessors helped send men to the moon and back, do a
> better job of keeping track of where files end?
> -- gil


-
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed.  The information may also constitute a legally
privileged confidential communication.  If the reader of this
message is not the intended recipient or an agent responsible for
delivering it to the intended recipient, you are hereby notified
that you have received this communication in error and that any
review, dissemination, copying, or unauthorized use of this
information, or the taking of any action in reliance on the
contents of this information is strictly prohibited.  If you have
received this communication in error, please notify us immediately
by e-mail, and delete the original message.  Thank you

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Art Celestini]

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" that SMS provided
when it first came out.




==
Art Celestini   Celestini Development Services
Phone: 201-670-1674Wyckoff, NJ
=  http://celestini.com  =
Mail sent to the "From" address  used in this post
will be rejected by our server.   Please send off-
list email to:  ibmmaincelestinicom.
==

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Ed Gould]

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 before it starts outputting to it, then it is possible  
that

a dataset that was allocated with no EOF may always cause errors.

Of course, this has nothing to do with IEFBR14 per se, but with a
dataset which is allocated in JCL but is never OPENED for output.   
The

PGM= could be anything.


But, in the broader view, Why can't IBM's premier OS,
whose predecessors helped send men to the moon and back, do a
better job of keeping track of where files end?



Gil,

They give you an option to do so if you fail to use the option so  
then is option user error?


Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Thomas Berg]

==  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
__

 They that can give up essential liberty to obtain a little temporary safety 
deserve neither liberty nor safety.
 - Benjamin Franklin

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Hunkeler Peter (KIUB 34)]

>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 
management, but it will not during allocation, even if 
SMS writes an EOF into it.

Peter Hunkeler
CREDIT SUISSE

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Hunkeler Peter (KIUB 34)]

>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 Hunkeler
CREDIT SUISSE

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Shmuel Metz (Seymour J.)]

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 
>the IEFBR14 utility". 

What are they smoking?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Shmuel Metz (Seymour J.)]

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 do with either IEFBR14 or LE.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[(IBM Mainframe Discussion List)]

 
 
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 
>the IEFBR14  utility".

>In a message dated 5/24/2006 7:02:48 A.M. Central Daylight  Time, 
shmuel+ibm->[EMAIL PROTECTED] writes:
What are they smoking?
 
It could be that the group in his shop OR the vendor is the one that's been  
smoking the cluelessness-inducing substance.  Or maybe both clusters.   I have 
encountered some clueless vendors.



Bill  Fairchild

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Paul Gilmartin]

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 told them that "Since the product is LE
> >compliant, it cannot write  into a dataset that has been generated by
> >the IEFBR14  utility".
> 
> >In a message dated 5/24/2006 7:02:48 A.M. Central Daylight  Time,
> shmuel+ibm->[EMAIL PROTECTED] writes:
> What are they smoking?
> 
> It could be that the group in his shop OR the vendor is the one that's been
> smoking the cluelessness-inducing substance.  Or maybe both clusters.   I have
> encountered some clueless vendors.
> 
o Find out whether it's "the group in his shop" or the vendor.

o If the vendor and the restriction explicitly cites IEFBR14,
  torment their tech support, repeatedly if necessary, with
  questions such as:

  If not IEFBR14, may I use a trivial invocation of some
  other program, such as IKJEFT01 with only "LOGOFF"
  in SYSTSIN, and "DD DISP=NEW" to create the data set?

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Paul Gilmartin]

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 file ?
> 
There's DS1LSTAR.  But there was a design blunder.  It _should_
have been the behavior ever since release 1 of OS/360 that any
attempt to READ beyond DS1LSTAR should cause EODAD to be invoked.
This test should have been incorporated in the access method,
not left as the responsibility of the application programmer.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Paul Gilmartin]

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 first track and correspondingly set DS1LSTAR.
> I seem to recall this as one of the "features" that SMS provided
> when it first came out.
> 
Underreaching.  Why the restriction to SAM?  Allocation ought to
write EOF whenever a NEW primary extent is allocated, regardless
of known or unknown DSORG.

The one possible exception is when the programmer requests an
absolute track address (is this even supported nowadays?),
since that might be an attempt to recover data after a DSCB
was lost, and writing the EOF might obliterate the data.

I'm more tolerant of the restriction to SMS; not all new
enhancements should be retrofitted to obsolete functions.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

SV: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Thomas Berg]

> -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: 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 file ?
> > 
> There's DS1LSTAR.  But there was a design blunder.  It 
> _should_ have been the behavior ever since release 1 of 
> OS/360 that any attempt to READ beyond DS1LSTAR should cause 
> EODAD to be invoked. This test should have been incorporated 
> in the access method, not left as the responsibility of the 
> application programmer.
> 

Yes.  There is many inconsistenses/logical fallacys in MVS aka z/OS that 
generates endless problems.
One example is this thread.  Either does a dataset exist.  Or not.
If it exist it should be readable regardless if it is empty or not.

___
Thomas Berg   IT Utveckling   FöreningsSparbanken AB (Publ) / SWEDBANK  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Bruce Black]

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" that SMS provided
when it first came out.
Art, I believe you are right, but I can never remember the exact rules 
to get the EOF written.  I searched the FMs once, but I don't think it 
is documented.


but actually DS1LSTAR is still zero in that case.  the EOF is record 1, 
so the last "data block" is "record 0".  You can't tell the difference 
from LSTAR. 

As for Gil's suggestion that the access method should not allow you to 
read past LSTAR, in the past it was not uncommon for LSTAR to be 
inaccurate.  It is updated at CLOSE but if CLOSE fails or system crashes 
or whatever, the DSCB may not get updated.  There may be lots of valid 
data past the LSTAR.  Not so common today but can happen.


--
Bruce Black
Senior Software Developer
Innovation Data Processing

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Doug Henry]

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 before data has been written 
in it. This means the first GET or first CHECK for a READ causes the EODAD 
routine to be called.

z/OS V1R7.0 DFSMS: Implementing System-Managed Storage

 For sequential data sets, SMS writes a hardware EOF at the beginning of 
the data set at initial allocation. This prevents data integrity problems 
when applications try to read the data before data is written in the data 
set. 

Doug 


On Wed, 24 May 2006 11:00:21 -0400, Bruce Black <[EMAIL PROTECTED]> 
wrote:

>Art, I believe you are right, but I can never remember the exact rules
>to get the EOF written.  I searched the FMs once, but I don't think it
>is documented.
>
>but actually DS1LSTAR is still zero in that case.  the EOF is record 1,
>so the last "data block" is "record 0".  You can't tell the difference
>from LSTAR.
>
>As for Gil's suggestion that the access method should not allow you to
>read past LSTAR, in the past it was not uncommon for LSTAR to be
>inaccurate.  It is updated at CLOSE but if CLOSE fails or system crashes
>or whatever, the DSCB may not get updated.  There may be lots of valid
>data past the LSTAR.  Not so common today but can happen.
>
>--
>Bruce Black
>Senior Software Developer
>Innovation Data Processing

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Shmuel Metz (Seymour J.)]

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, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Patrick O'Keefe]

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 non-sequential dataset?
There is no logical place to put it; "the end" depends on the logic of 
the program reading the dataset.  There is no place to put EOF for an 
empty dataset except at the beginning, of course, but putting it there
is no more logical that leaving it out altogether.

Pat O'Keefe

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[J R]

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 have here is a failure to communicate!"

Vivian said:

ACR/Summary and ACR/Detail version 3.3 has had reports of problems READING 
files initialized by IEFBR14, which is due to the fact that there is no EOF 
marker in the file.



We have always had top-notch customer support ...



David  Speake said:

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 ...


_
Is your PC infected? Get a FREE online computer virus scan from McAfee® 
Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Ted MacNEIL]

>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!!!  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Chase, John]

> -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.
> 
> VSAM?

Yeah -- HARBA and HURBA (High Allocated Relative Byte Address and High
Used RBA) live in the catalog entry.

-jc-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Paul Gilmartin]

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
> > >EOF whenever a NEW primary extent is allocated, regardless of known or
> > >unknown DSORG.
> >
> > VSAM?
> 
> Yeah -- 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?

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Bruce Black]

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 
purpose since VSAM does not use EOFs.  The RBA values tell it where the 
end of data is so VSAM never reads beyond them.


Unlike non-VSAM, VSAM has a "file open" flag so if the file is not 
closed properly, the next OPEN does an implicit VERIFY function, which 
reads the data and determines where the real HURBA is. 

An EOF In VSAM beyond the HURBA would probably be ignored, even on a 
VERIFY, but it serves no purpose.



Why the restriction to SAM?  Allocation ought to
write EOF whenever a NEW primary extent is allocated, regardless
of known or unknown DSORG.
As Doug Henry pointed out in his quotes from the manuals (thanks, Doug, 
I knew it had to be somewhere), SMS datasets write the EOF for DSORG=PS 
AND unspecified DSORG, so it covers all dataset types where the EOF may 
be important. 


--
Bruce A. Black
Senior Software Developer for FDR
Innovation Data Processing 973-890-7300
personal: [EMAIL PROTECTED]
sales info: [EMAIL PROTECTED]
tech support: [EMAIL PROTECTED]
web: www.innovationdp.fdr.com 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Shmuel Metz (Seymour J.)]

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 CI formatted. Similar considerations
apply to other access methods. The EOF is really only relevant to
(B|P|Q)SAM.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Shmuel Metz (Seymour J.)]

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 (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Shmuel Metz (Seymour J.)]

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 formatted.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Bruce Black]

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, 
disregarding any previous contents, including the EOF.   So the EOF 
would just be unnecessary work for a VSAM allocation.


--
Bruce A. Black
Senior Software Developer for FDR
Innovation Data Processing 973-890-7300
personal: [EMAIL PROTECTED]
sales info: [EMAIL PROTECTED]
tech support: [EMAIL PROTECTED]
web: www.innovationdp.fdr.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Paul Gilmartin]

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 regularly?

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Paul Gilmartin]

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, then VSAM OPEN or EOV
> would immediately format the CA with CIs as soon as it is needed,
> disregarding any previous contents, including the EOF.   So the EOF
> would just be unnecessary work for a VSAM allocation.
> 
Finally, some good sense in this thread.  I was dismayed by the
presumption of some readers that the design would put the operations
in the wrong order -- first CI format, then write the EOF; naturally
it works better the other way around.

My guiding rationale here is that when a new extent is allocated,
the component (DADSM?) pays little attention to the former use
or content of the space allocated.  If, by happenstance, the
first track in the extent contains an EOF, I'd expect other
components to be prepared to deal with it.  Empirically, this
appears so -- I've never heard of a software failure because
an unitialized extent contained an unexpected EOF.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Write to BR14 allocated PSDS - Unitech ACR 3.3

[Shmuel Metz (Seymour J.)]

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 VSAM.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html