In 4e40ab82.3020...@bcs.org.uk, on 08/09/2011
at 04:37 AM, CM Poncelet ponce...@bcs.org.uk said:
Gimme a break. I am not mathematically 'naïve' and my proof was in
fact correct.
ROTF,LMAO!
End of discussion.
You say I go, I go, but you don't go.
--
Shmuel (Seymour J.) Metz, SysProg
In 00fc01cc5541$5889c1c0$099d4540$@us, on 08/07/2011
at 03:34 PM, Jim Thomas j...@thethomasresidence.us said:
That said, yes, I do not remember much from my Univ. days (as I've
said before .. I don't remember what I ate for dinner last night ...
:-) ), but .. mathematically written (and since
In 4e3ee8fa.6080...@bcs.org.uk, on 08/07/2011
at 08:35 PM, CM Poncelet ponce...@bcs.org.uk said:
But you seem to be saying that, unless I can cite from your book the
chapter and verse that supports my argument, my argument is false.
No, neither I nor the others have said that. What we said
Shmuel Metz (Seymour J.) wrote:
In 4e3ee8fa.6080...@bcs.org.uk, on 08/07/2011
at 08:35 PM, CM Poncelet ponce...@bcs.org.uk said:
But you seem to be saying that, unless I can cite from your book the
chapter and verse that supports my argument, my argument is false.
No, neither I
In 4e3ca3f5.1060...@bcs.org.uk, on 08/06/2011
at 03:16 AM, CM Poncelet ponce...@bcs.org.uk said:
Is it perhaps because you forget that Fortran I was around in 1955
and the Lyons Electronic Office (LEO) was around in 1952?
No, it's because you've made enough erroneous statements that you have
Shmuel Metz (Seymour J.) wrote:
In 4e3ca3f5.1060...@bcs.org.uk, on 08/06/2011
at 03:16 AM, CM Poncelet ponce...@bcs.org.uk said:
Is it perhaps because you forget that Fortran I was around in 1955
and the Lyons Electronic Office (LEO) was around in 1952?
No, it's because you've
(mobile)
636-294-1014(res)
j...@thethomasresidence.us (Email)
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of CM Poncelet
Sent: Sunday, August 07, 2011 2:35 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: CORRUPT PDS - I
@bama.ua.edu
Date: Sun, 7 Aug 2011 20:35:22
To: IBM-MAIN@bama.ua.edu
Reply-To: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu
Subject: Re: CORRUPT PDS - I/O ERROR
Shmuel Metz (Seymour J.) wrote:
In 4e3ca3f5.1060...@bcs.org.uk, on 08/06/2011
at 03:16 AM, CM Poncelet ponce
On Thu, 4 Aug 2011 19:35:47 -0400, Shmuel Metz (Seymour J.)wrote:
I believe that he wants the DWIWHMHIUWIWTA macro.
Is that something like do what I would have meant had I understood
what I wanted to accomplish?
--
Tom Marchant
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Tom Marchant
On Thu, 4 Aug 2011 19:35:47 -0400, Shmuel Metz (Seymour J.)wrote:
I believe that he wants the DWIWHMHIUWIWTA macro.
Is that something like do what I would have meant had I understood
what I wanted
In 2058724295111982.wa.m42tomibmmainyahoo@bama.ua.edu, on
08/05/2011
at 09:07 AM, Tom Marchant m42tom-ibmm...@yahoo.com said:
Is that something like do what I would have meant had I understood
what I wanted to accomplish?
Exactly.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Shmuel Metz (Seymour J.) wrote:
In 4e3a4e7e.5090...@bcs.org.uk, on 08/04/2011
at 08:47 AM, CM Poncelet ponce...@bcs.org.uk said:
I proved that, if On input, the order of override priority is
program DCB - JCL DCB - dataset attributes, then the consequence
is an I/O error
Not only
Shmuel Metz (Seymour J.) wrote:
In 4e392bb7.7080...@bcs.org.uk, on 08/03/2011
at 12:06 PM, CM Poncelet ponce...@bcs.org.uk said:
NO NO NO again. What I did was prove by 'reductio ad absurdum' that
if the premiss/assertion On input, the order of override priority
is program DCB - JCL
Is there any chance that those of you who still have an interest in arguing
this matter could take it offline and email each other directly. That way
those of us who have long lost interest in this can stop being bombarded with
the constant attacks you all seem to be throwing around
] On Behalf Of Steve Dover
Sent: Thursday, August 04, 2011 7:21 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: CORRUPT PDS - I/O ERROR
Is there any chance that those of you who still have an
interest in arguing this matter could take it offline and
email each other directly. That way those of us who have
In
f255efe0ecf08c4a9c1db6aff423541715f32...@ch2wpmail1.na.ds.ussco.com,
on 08/03/2011
at 12:16 PM, Chase, John jch...@ussco.com said:
IOW, to perfect the DWIM macro? :-)
I believe that he wants the DWIWHMHIUWIWTA macro.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position;
In 4e394150.1070...@bcs.org.uk, on 08/03/2011
at 01:38 PM, CM Poncelet ponce...@bcs.org.uk said:
Well yes, they have to be loaded into VS to be processed. In the case
of block read/writes they precede the data records in the buffer.
But whatever was being discussed at the time I wrote that
In 4e3a4e7e.5090...@bcs.org.uk, on 08/04/2011
at 08:47 AM, CM Poncelet ponce...@bcs.org.uk said:
I proved that, if On input, the order of override priority is
program DCB - JCL DCB - dataset attributes, then the consequence
is an I/O error
Not only did you not prove that, but others gave
In 4e397247.7070...@bcs.org.uk, on 08/03/2011
at 05:07 PM, CM Poncelet ponce...@bcs.org.uk said:
The absurd consequences are that 'FB,90' records would have to be
read as 'FB,80' records and the last record in the block padded with
X'00's
That is not a consequence, absurd or otherwise.
In
In 4e395e34.1070...@bcs.org.uk, on 08/03/2011
at 03:41 PM, CM Poncelet ponce...@bcs.org.uk said:
But I should get *no* I/O error at all on read if the DCB precedence
rules for output apply also to input,
False.
In 4e396dcd.60...@bcs.org.uk, on 08/03/2011
at 04:48 PM, CM Poncelet
NO NO NO again. What I did was prove by 'reductio ad absurdum' that if
the premiss/assertion On input, the order of override priority is
program DCB - JCL DCB - dataset attributes is true then its
consequences are absurd: therefore the premiss/assertion is false.
Please note that, at the
In 4e386bfb.7030...@acm.org, on 08/02/2011
at 04:28 PM, Joel C. Ewing jcew...@acm.org said:
To almost take pride in not having the time to consult appropriate
references, and yet at the same time be adamant that you are right
and others wrong when they have,
Some of us[1] have read not only
In 4e37505a.7090...@bcs.org.uk, on 08/02/2011
at 02:18 AM, CM Poncelet ponce...@bcs.org.uk said:
What I would expect, if the program's DCB attributes 'overrode'/'took
precedence over'/etc. those of the physical dataset on DASD, is that
the attributes in the dataset's DSCB on DASD would be
In 4e38932c.2030...@bcs.org.uk, on 08/03/2011
at 01:15 AM, CM Poncelet ponce...@bcs.org.uk said:
... but open for output, followed by write, works - whereas open for
input, followed by read, doesn't (it fails with an I/O ERR): that
is a fact, not an opinion.
No, it is not a fact. It is a
Gerhard Postpischil wrote:
On 8/2/2011 3:11 PM, CM Poncelet wrote:
this. But in any case the BDW and RDW would not be loaded into
the buffer.
The BDW and RDW are always included in the buffer. They may not be
seen at the application level (e.g., on a ForTran read or write, or in
CoBOL).
On Wed, 3 Aug 2011 13:38:40 +0100, CM Poncelet wrote:
Gerhard Postpischil wrote:
The BDW and RDW are always included in the buffer. They may not be
seen at the application level (e.g., on a ForTran read or write, or in
CoBOL).
Well yes, they have to be loaded into VS to be processed. In the
On Wed, 3 Aug 2011 12:06:31 +0100, CM Poncelet wrote:
NO NO NO again. What I did was prove by 'reductio ad absurdum' that if
the premiss/assertion On input, the order of override priority is
program DCB - JCL DCB - dataset attributes is true then its
consequences are absurd: therefore the
I am proving by 'reductio ad absurdum' that if the assertion is true,
then its consequences are absurd: and hence that the assertion is false.
You are discussing the absurd consequences which would follow from the
assertion being true. The point I am illustrating is that you cannot
impose a
I have read the manuals and I reference them when *necessary*, I have
also read *some* of the code (howbeit by disassembling it), I do not
'take pride' in not having the time etc. (because I actually do *not*
have the time to consult references which have no relevancy to the work
I am
Shmuel Metz (Seymour J.) wrote:
In 4e38932c.2030...@bcs.org.uk, on 08/03/2011
at 01:15 AM, CM Poncelet ponce...@bcs.org.uk said:
... but open for output, followed by write, works - whereas open for
input, followed by read, doesn't (it fails with an I/O ERR): that
is a fact, not an
On Wed, 3 Aug 2011 15:20:22 +0100, CM Poncelet wrote:
I am proving by 'reductio ad absurdum' that if the assertion is true,
then its consequences are absurd: and hence that the assertion is false.
What consequences? In what way are they absurd?
Hint: To show that something is absurd, it is
On Wed, 3 Aug 2011 15:41:56 +0100, CM Poncelet wrote:
But I should get *no* I/O error at all on read if the DCB precedence
rules for output apply also to input, as is asserted (... not by me).
Of course you should get an I/O error on read if you specify a
blocksize that is inconsistent with the
Years ago a man named Mark Thomen (I miss him and his wisdom) probably
would have Relson-ed this thread days ago.
all snipped
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
CM, Wrong again (but should we be surprised)! The RDW is indeed part of
the logical record and is returned by the access method as part of the
logical record on input and expected as part of the record on output.
Some higher level languages (for example,COBOL) hide this from the
programmer
Tom Marchant wrote:
On Tue, 2 Aug 2011 20:11:27 +0100, CM Poncelet ponce...@bcs.org.uk wrote:
Gerhard Postpischil wrote:
His example used RECFM=FB, so there are no BDWs and no RDWs (if there
were, then the first four bytes of the second record would be the RDW,
not data).
Yes
If expressed that way, I have no choice but to accept that BANANA
overrides SYSDA - although that is not the interpretation of 'override'
I am referring to.
If expressed as BANANA prevails over SYSDA, then I disagree - because
BANANA would fail with a JCL error and would therefore not
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of
CM Poncelet
Sent: Wednesday, August 03, 2011 7:39 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: CORRUPT PDS - I/O ERROR
... I translate my thoughts into words and for this I use whatever
Tom Marchant wrote:
On Wed, 3 Aug 2011 15:20:22 +0100, CM Poncelet wrote:
I am proving by 'reductio ad absurdum' that if the assertion is true,
then its consequences are absurd: and hence that the assertion is false.
What consequences? In what way are they absurd?
The absurd
On Wed, 3 Aug 2011 17:03:21 +0100, CM Poncelet wrote:
If expressed that way, I have no choice but to accept that BANANA
overrides SYSDA - although that is not the interpretation of 'override'
I am referring to.
Feeding this troll is a waste of time. He insists upon providing his own
meanings
You cannot have two 'logic sets' - one for output and another for input.
If output hits no I/O error then input hits no I/O error. Otherwise your
single assertion, applicable both to output and input, is flawed -
because it has two possible outcomes. It is 'along the lines of'
asserting that:
'override' includes 'over' and 'ride' - and 'ride' is ambiguous.
Tom Marchant wrote:
On Wed, 3 Aug 2011 17:03:21 +0100, CM Poncelet wrote:
If expressed that way, I have no choice but to accept that BANANA
overrides SYSDA - although that is not the interpretation of 'override'
I am
Google me this.
While processing a job step that has duplicate DDNAMES coded and
at least one of the DDNAMES points to a JES data set (SYSIN,
SYSOUT, etc.) an extend failure can occur. This error occurs
when the non-JES data set is attempting to extend to a second
volume and this candidate
On 8/3/2011 8:38 AM, CM Poncelet wrote:
Well yes, they have to be loaded into VS to be processed. In the
case of block read/writes they precede the data records in the
buffer. But whatever was being discussed at the time I wrote
that had to do with record read/writes, in which case the BDW
and
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Joel C. Ewing
[ snip ] I guess the logical
corollary of CM expecting it to be reasonable to raise an IBM PMR to
eliminate errors caused by user misuse of JCL DD or program DCB
parameters would be to expect IBM to
Either that or he thinks he is executing IEHPROPHET.
On Wed, Aug 3, 2011 at 1:16 PM, Chase, John jch...@ussco.com wrote:
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Joel C. Ewing
[ snip ] I guess the logical
corollary of CM expecting it to be reasonable
... I translate my thoughts into words and for this I use whatever suitable
word - not necessarily the most appropriate one - first comes to mind.
Humpty Dumpty to Alice:
A word means exactly what I intend it to mean!
In a field that requires precision and accuracy, communication in that field
snip-
To almost take pride in not having the time to consult appropriate
references, and yet at the same time be adamant that you are right
and others wrong when they have,
Some of us[1] have read not only the manuals
In 4e392bb7.7080...@bcs.org.uk, on 08/03/2011
at 12:06 PM, CM Poncelet ponce...@bcs.org.uk said:
NO NO NO again. What I did was prove by 'reductio ad absurdum' that
if the premiss/assertion On input, the order of override priority
is program DCB - JCL DCB - dataset attributes is true then
Thanks for your comments.
It seems to me that there are two areas of dispute. (a) My recollection
of MVS control blocks etc. As I have not worked as an MVS sysprog for
nearly 12 years, my memory of them is somewhat fuzzy - just as my
knowledge of French (my original academic language), Dutch
I'll look into it when I have the time.
Dale Miller wrote:
Mr. Poncelet said We are arguing semantics. Yes, computer language
statements have syntax requirements and properly-written statements
have semantics associated with them. The language in the JCL
Reference Manual specifically
Gerhard Postpischil wrote:
On 8/1/2011 9:53 PM, CM Poncelet wrote:
Quite possibly; but it's a contrived case where the 2nd LRECL is
a fixed length multiple of the first (so there is one BDW and
one RDW, and the records follow each other consecutively in the
buffer).
His example used
I really wish you folks would get your semantics clear. The original problem
and solution proves the facts without need for further discussion.
1. Take a perfectly good, LRECL=80 PDS. Maybe to be really clear, find a PDS
with LERECL 133.
2. trash it by pointing any SYSOUT DD to a NEW
On 8/2/2011 3:11 PM, CM Poncelet wrote:
this. But in any case the BDW and RDW would not be loaded into
the buffer.
The BDW and RDW are always included in the buffer. They may not
be seen at the application level (e.g., on a ForTran read or
write, or in CoBOL).
I have no time for that. If
-snip--
What I would expect, if the program's DCB attributes 'overrode'/'took
precedence over'/etc. those of the physical dataset on DASD, is that the
attributes in the dataset's DSCB on DASD would be overriden
snip---
Quite possibly; but it's a contrived case where the 2nd LRECL is a fixed
length multiple of the first (so there is one BDW and one RDW, and the
records follow each other consecutively in the buffer).
To quote Mark Twain: It ain’t what you don’t know that gets you into
trouble. It’s what you know for sure that just ain’t so.
After dealing with computers for 40+ years, I can tell you that some of
the most important concepts are (1)to know when you don't know the right
answer, (2)know
In 4e35f6d3.9090...@bcs.org.uk, on 08/01/2011
at 01:44 AM, CM Poncelet ponce...@bcs.org.uk said:
The 'acid test' is whether the same program DCB (ignoring the MACRF=
and EODAD=) can be used *both* for OUTPUT and for INPUT (with a
change in MACFR= and adding EODAD= when opening for INPUT),
In 4e36c3fe.30...@bcs.org.uk, on 08/01/2011
at 04:19 PM, CM Poncelet ponce...@bcs.org.uk said:
Probably ... because my definition
Your definition is irrelevant. The documentation of how OPEN behaves
uses IBM's definitions.
Otherwise the 'standard' definition of DCB override is purely
In 4e356a03.4060...@bcs.org.uk, on 07/31/2011
at 03:43 PM, CM Poncelet ponce...@bcs.org.uk said:
they 'count' as program DCBs is short-speak for 'they are executable
code' (as opposed to JCL and DASD)
A DCB is not executable code; it is a data area.
I know that; but on input they do not
... but open for output, followed by write, works - whereas open for
input, followed by read, doesn't (it fails with an I/O ERR): that is a
fact, not an opinion.
So unless the I/O ERR is actually the desired outcome, it is an error.
If it needs to be fixed, then either the program's merged
Open for output merges all the attributes and then REPLACES the DSCB values
with the result of the merge.
On Tue, Aug 2, 2011 at 8:15 PM, CM Poncelet ponce...@bcs.org.uk wrote:
... but open for output, followed by write, works - whereas open for input,
followed by read, doesn't (it fails with
On Tue, 2 Aug 2011 20:11:27 +0100, CM Poncelet ponce...@bcs.org.uk wrote:
Gerhard Postpischil wrote:
His example used RECFM=FB, so there are no BDWs and no RDWs (if there
were, then the first four bytes of the second record would be the RDW,
not data).
Yes ... and I am writing from memory,
I must admit most of this thread has made its way into the bin without more
than a perfunctory glance.
Toms latest contribution does however display admirable patience in the face
of intransigence. Kudos to Tom.
Shane ...
--
For
I did not look at all the other responses so please forgive me if someone
already gave you the answer. Most the time I have seen this error the
lrecl/blocksize was reset by creating a member with a different lrecl. All you
have to do is create a member with the right lrecl/blksize and all but
Tom Marchant wrote:
On Mon, 1 Aug 2011 01:44:03 +0100, CM Poncelet wrote:
If the same DCB is opened for INPUT (MACRF=GM|L,EODAD=etc.), then the
program's DCB attributes do *not* override those on DASD
Right. No one said that they do.
and, as the
program's DCB attributes are
On Mon, 1 Aug 2011 16:19:26 +0100 CM Poncelet ponce...@bcs.org.uk wrote:
:Probably ... because my definition includes that the overriding DCB must
:then also be able to read successfully the dataset whose DCB attributes
:have been overridden - regardless of BDW, RDWs and data. Otherwise the
On Mon, 1 Aug 2011 00:45:05 -0500, Tom Marchant wrote:
On Mon, 1 Aug 2011 01:44:03 +0100, CM Poncelet wrote:
If the same DCB is opened for INPUT (MACRF=GM|L,EODAD=etc.), then the
program's DCB attributes do *not* override those on DASD
Right. No one said that they do.
I should have written,
On Mon, 1 Aug 2011 01:44:03 +0100, CM Poncelet ponce...@bcs.org.uk wrote:
If I am wrong, please prove it by submitting verifiable 'general
purpose' examples of this (excluding 'reblocking' trivia). A 'verifiable
example' is one in which all the program's DCB attributes are different
from those of
What I would expect, if the program's DCB attributes 'overrode'/'took
precedence over'/etc. those of the physical dataset on DASD, is that the
attributes in the dataset's DSCB on DASD would be overriden by the
program DCB's attributes during the *read* (without changing the DSCB on
DASD), and
Quite possibly; but it's a contrived case where the 2nd LRECL is a fixed
length multiple of the first (so there is one BDW and one RDW, and the
records follow each other consecutively in the buffer).
By 'general purpose' example I meant one where the LRECLs, RECFMs and
BLKSIZEs in the input
On 8/1/2011 9:18 PM, CM Poncelet wrote:
If the DCB had 'FB,80' and the actual data had 'FB,90' - then I
would expect the first 80 bytes to be read in, then the next
81st to 160th bytes etc. until all the data had been read in
using 'FB,80' (and with the last record in a block being
appended with
On 8/1/2011 9:53 PM, CM Poncelet wrote:
Quite possibly; but it's a contrived case where the 2nd LRECL is
a fixed length multiple of the first (so there is one BDW and
one RDW, and the records follow each other consecutively in the
buffer).
His example used RECFM=FB, so there are no BDWs and no
Mr. Poncelet said We are arguing semantics. Yes, computer language
statements have syntax requirements and properly-written statements
have semantics associated with them. The language in the JCL Reference
Manual specifically refers to the relative priority of information
provided in the
Shmuel Metz (Seymour J.) wrote:
In 4e2f48fa.8010...@bcs.org.uk, on 07/27/2011
at 12:08 AM, CM Poncelet ponce...@bcs.org.uk said:
But the exit points 'count' as program DCBs
they 'count' as program DCBs is short-speak for 'they are executable
code' (as opposed to JCL and DASD)
On Sun, 31 Jul 2011 15:43:15 +0100 CM Poncelet ponce...@bcs.org.uk wrote:
:I know that; but on input they do not override the DCB from DASD - and
:that is regardless of their order
What do you mean by that statement?
Do you mean that they do not change the physical data already recorded?
Binyamin Dissen wrote:
On Sun, 31 Jul 2011 15:43:15 +0100 CM Poncelet ponce...@bcs.org.uk wrote:
:I know that; but on input they do not override the DCB from DASD - and
:that is regardless of their order
What do you mean by that statement?
Before the DCB on DASD can be accessed, the
override both the DSCB data and the DD statement data.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of CM Poncelet
Sent: Sunday, July 31, 2011 9:35 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: CORRUPT PDS - I/O ERROR
Before the DCB on DASD can
On 7/31/2011 12:35 PM, CM Poncelet wrote:
The program's DCB attributes take priority over (i.e.
'override') the DCB attributes on DASD for OUTPUT, and the DCB
attributes on DASD take priority over (i.e. 'override') the
program's DCB for INPUT. If a program 'disagrees' with that and
tries to
On Sun, 31 Jul 2011 18:19:11 -0400 Gerhard Postpischil gerh...@valley.net
wrote:
:On 7/31/2011 12:35 PM, CM Poncelet wrote:
: The program's DCB attributes take priority over (i.e.
: 'override') the DCB attributes on DASD for OUTPUT, and the DCB
: attributes on DASD take priority over (i.e.
In 4e34784d.2020...@bcs.org.uk, on 07/30/2011
at 10:31 PM, CM Poncelet ponce...@bcs.org.uk said:
What I am saying is that, on INPUT, a dataset's physical DCB
attributes from its DSCB on DASD cannot be overriden by a JCL or
program DCB.
Yes, and what you are saying is wrong.
According to
In 4e349468.4060...@bcs.org.uk, on 07/31/2011
at 12:31 AM, CM Poncelet ponce...@bcs.org.uk said:
I'm afraid I disagree.
Because you are confusing the DSCB with the blocks written in the
dataset.
What it proves is not that the DCB on DASD was
overwritten by the one in the JCL, but that the
The 'acid test' is whether the same program DCB (ignoring the MACRF= and
EODAD=) can be used *both* for OUTPUT and for INPUT (with a change in
MACFR= and adding EODAD= when opening for INPUT), when the dataset's
physical DCB attributes on DASD are *different* from those specified in
the
Shmuel Metz (Seymour J.) wrote:
In 4e349468.4060...@bcs.org.uk, on 07/31/2011
at 12:31 AM, CM Poncelet ponce...@bcs.org.uk said:
I'm afraid I disagree.
Because you are confusing the DSCB with the blocks written in the
dataset.
We are arguing semantics ...
What it proves is
snip--
The program's DCB attributes take priority over (i.e.
'override') the DCB attributes on DASD for OUTPUT, and the DCB
attributes on DASD take priority over (i.e. 'override') the
program's DCB for INPUT. If a program
-snip
I'm afraid I disagree.
Because you are confusing the DSCB with the blocks written in the
dataset.
What it proves is not that the DCB on DASD was
overwritten by the one in the JCL, but that the DCB in the JCL
--snip--
I'm afraid I disagree.
Because you are confusing the DSCB with the blocks written in the
dataset.
We are arguing semantics ...
--unsnip
NOT
Shmuel Metz (Seymour J.) wrote:
In 4e34784d.2020...@bcs.org.uk, on 07/30/2011
at 10:31 PM, CM Poncelet ponce...@bcs.org.uk said:
What I am saying is that, on INPUT, a dataset's physical DCB
attributes from its DSCB on DASD cannot be overriden by a JCL or
program DCB.
Yes, and
Rick Fochtman wrote:
--snip--
I'm afraid I disagree.
Because you are confusing the DSCB with the blocks written in the
dataset.
We are arguing semantics ...
The DCB coded in the program over-rides everything.
If a data set has VB 133, 1330 and the program has FB 80,800 and opens
it for either input or output, the DSCB will be changed to that coded in
the program.
It's always been that way. (Except the Fujitsu equivalent MSP Operating
system put
On Mon, 1 Aug 2011 13:50:09 +1000, Clement Clarke wrote:
If a data set has VB 133, 1330 and the program has FB 80,800 and opens
it for either input or output, the DSCB will be changed to that coded in
the program.
Not quite. If the data set is opened for input, the program will attempt to
read
On Sat, 30 Jul 2011 04:27:44 -0700, Dale Miller wrote:
In my previous note I said:
one can
TEMPORARILY override the dataset attributes with a DD card if the OPEN
is for INPUT
Mr. Marchant said NO, and referred to the JCL Reference Manual
section Completing the data control block.
Please read
On Sun, 31 Jul 2011 17:35:25 +0100, CM Poncelet wrote:
Before the DCB on DASD can be accessed, the program's own 'completed'
DCB (including any missing DCB parms filled-in from a RDJFCB of the
JCL's DD and/or from an exit, if present) must be opened.
The DCB is completed during the open process
On Mon, 1 Aug 2011 01:44:03 +0100, CM Poncelet wrote:
If the same DCB is opened for INPUT (MACRF=GM|L,EODAD=etc.), then the
program's DCB attributes do *not* override those on DASD
Right. No one said that they do.
and, as the
program's DCB attributes are inconsistent with those of the dataset
In my previous note I said:
one can
TEMPORARILY override the dataset attributes with a DD card if the OPEN
is for INPUT
Mr. Marchant said NO, and referred to the JCL Reference Manual
section Completing the data control block.
Please read again what I said. I said dataset attributes, not the
What I am saying is that, on INPUT, a dataset's physical DCB attributes
from its DSCB on DASD cannot be overriden by a JCL or program DCB.
Consider the following JCL where
SYS1.RECFMVBA.LRECL137.BLK27998 has physical
DCB=(RECFM=VBA,LRECL=137,BLKSIZE=27998,DSORG=PS)
On Sat, 30 Jul 2011 22:31:57 +0100 CM Poncelet ponce...@bcs.org.uk wrote:
:What I am saying is that, on INPUT, a dataset's physical DCB attributes
:from its DSCB on DASD cannot be overriden by a JCL or program DCB.
:Consider the following JCL where
:SYS1.RECFMVBA.LRECL137.BLK27998 has physical
I'm afraid I disagree. What it proves is not that the DCB on DASD was
overwritten by the one in the JCL, but that the DCB in the JCL was
incorrect/incompatible with the one on DASD.
If I allocate SYSUT1 with DCB=(RECFM=FBA,LRECL=121,BLKSIZE=16093) and
SYSUT2 with
In 1311699756.83896.yahoomail...@web34508.mail.mud.yahoo.com, on
07/26/2011
at 10:02 AM, esmie moo esmie_...@yahoo.ca said:
When I try to browse a member of my pds I get a I/O error. I tried
browsing several members but I get the same error message. Is there
a way of fixing it?
Not without
In 4e2f48fa.8010...@bcs.org.uk, on 07/27/2011
at 12:08 AM, CM Poncelet ponce...@bcs.org.uk said:
But the exit points 'count' as program DCBs
NFW; they count as exits. The actual priority order is:
DSCB1
JFCB[1]
DCB
Changes made by DCB Exit
regardless of whether it is input or
In a6b9336cdb62bb46b9f8708e686a7ea00afc0ed...@nrhmms8p02.uicnrh.dom,
on 07/27/2011
at 07:20 AM, McKown, John john.mck...@healthmarkets.com said:
Many placed do. I don't understand why.
Stupidity above and beyond the call of duty. It's an example of
auditing by checklist, with the checklist
1 - 100 of 150 matches
Mail list logo
