On 23 May 2009 12:32:09 -0700, paulgboul...@aim.com (Paul Gilmartin)
wrote:
You seem to be agreeing with Steve Thompson that In the MVS world, we
are not device dependant, only insofar as there is only one type of
device. A weak assertion indeed. Would you be willing to go so far
as to side
On 25 May 2009 18:23:38 -0700, joa...@swbell.net (John McKown) wrote:
I agree, except for truly direct access data sets. What I have fought
with here is the mindset of I must allocate in CYLINDERS in order to be
efficient. I want them to allocate in RECORDS (or millions of records).
But, oh,
And of course, people cut and paste their SORTWK* files often without thinking.
We made it even more turnkey than that.
We cleaned up all the Production JCL, and made them dynamic.
After all, they are temporary anyway, make them all very, very large and we
won't be called in.
With SYNCSORT,
On 25 May 2009 19:16:25 -0700, in bit.listserv.ibm-main you wrote:
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of John McKown
Sent: Monday, May 25, 2009 6:21 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: BLOCK CONTAINS
On Sat, 23 May
On Mon, 25 May 2009 19:13:43 -0700, Gibney, Dave wrote:
OK, but how is this desire not satisfied via AVGREC allocations? Oh, it
is and you'll claim your applications folks can't handle the concept.
AVGREC is:
o Woefully misleading; it seems to abbreviate AVeraGe RECord size,
with which it
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Paul Gilmartin
Sent: Wednesday, May 27, 2009 3:23 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: BLOCK CONTAINS
On Mon, 25 May 2009 19:13:43 -0700, Gibney, Dave wrote:
OK, but how
On Sat, 23 May 2009, Ted MacNEIL wrote:
You seem to be agreeing with Steve Thompson that In the MVS world, we are
not device dependant, only insofar as there is only one type of device. A
weak assertion indeed.
Not at all.
There are at least two device types -- tape and disk.
And, I
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of John McKown
Sent: Monday, May 25, 2009 6:21 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: BLOCK CONTAINS
On Sat, 23 May 2009, Ted MacNEIL wrote:
You seem to be agreeing with Steve
--- On Sat, 5/23/09, Eric Bielefeld eric-ibmm...@wi.rr.com wrote:
From: Eric Bielefeld eric-ibmm...@wi.rr.com
Subject: Re: Submitting a Marketing REQUEST (was: BLOCK CONTAINS
To: IBM-MAIN@bama.ua.edu
Date: Saturday, May 23, 2009, 9:26 AM
Ed,
And yet, IBM is hiring 1,300 people in Dubuque
Ed,
And yet, IBM is hiring 1,300 people in Dubuque Iowa. I'm sure they will
hire some who got laid off in other areas of the country, but it is a good
sign.
Eric Bielefeld
Sr. Systems Programmer
Milwaukee, Wisconsin
414-475-7434
- Original Message -
From: Ed Gould
Paul Gilmartin wrote:
On Fri, 15 May 2009 09:27:42 -0400, Thompson, Steve wrote:
Welcome to the MVS world. In the MVS world, we are not device dependant,
nor are we data definition locked/blocked. We generally don't have to
recompile our programs, change the DTF contents (DCB in MVS), etc. just
All things being equal, I would much rather not use my scarce time dealing
with DASD architecture migration.
Having gone from 3330 -- 3350 -- 3380 -- 3390 (emulation mode) -- 3390
(native), I agree 100%!
IBM promised, years ago, to not change the geometry again.
Better the devil you know; I
On Sat, 23 May 2009 19:12:19 +, Ted MacNEIL wrote:
All things being equal, I would much rather not use my scarce time dealing
with DASD architecture migration.
Having gone from 3330 -- 3350 -- 3380 -- 3390 (emulation mode) -- 3390
(native), I agree 100%!
IBM promised, years ago, to not
You seem to be agreeing with Steve Thompson that In the MVS world, we are not
device dependant, only insofar as there is only one type of device. A weak
assertion indeed.
Not at all.
There are at least two device types -- tape and disk.
And, I can convert to either without re-compiling.
That
Ted MacNEIL pisze:
You seem to be agreeing with Steve Thompson that In the MVS world, we are not
device dependant, only insofar as there is only one type of device. A weak
assertion indeed.
Not at all.
There are at least two device types -- tape and disk.
And, I can convert to either
At 20:24 -0300 on 05/18/2009, Clark Morris wrote about Re: BLOCK CONTAINS:
On 18 May 2009 13:35:40 -0700, in bit.listserv.ibm-main you wrote:
Ah! NOBLOCK had F/80/80 whereas BLOCK1 had FB/80/80. BLOCK0 still
had FB/80/27920. But it is still interesting, to me, that BLOCK
CONTAINS 1
At 16:07 -0500 on 05/18/2009, Paul Gilmartin wrote about Re: BLOCK CONTAINS:
On Mon, 18 May 2009 18:18:20 +0200, Gilbert Saint-Flour wrote:
On Monday 18 May 2009 18:04, Paul Gilmartin wrote:
What a stupid necessity that programmers have to code BLOCK CONTAINS 0 !
What happens
--- On Wed, 5/20/09, Martin Packer martin_pac...@uk.ibm.com wrote:
--SNIP---
Do you suppose it has to be YOUR
Marketing Rep? Or just a friendly IBMer
in the field?
Cheers, Martin (still striving to be a friendly IBMer after
all these
years) :-)
Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
Bill Klein
Sent: Tuesday, May 19, 2009 10:35 PM
To: IBM-MAIN@bama.ua.edu
Subject: Submitting a Marketing REQUEST (was: BLOCK CONTAINS
Frank Swarbrick fswarbr...@gmail.com wrote in message
news:listserv%200905191643164240.0
(was: BLOCK CONTAINS
Sent by:
IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu
Frank Swarbrick fswarbr...@gmail.com wrote in message
news:listserv%200905191643164240.0...@bama.ua.edu...
snip
By the way, any pointers on how to submit a marketing requirement? VSE
actually has
On 18 May 2009 12:41:15 -0700, eamacn...@yahoo.ca (Ted MacNEIL) wrote:
I don't think it's a lie.
Historically, ZERO has always had a special meaning.
In COBOL's case, it just means that the programme is not going to determine
the blocksize, but leaves a place-holder for it when it's decided
@bama.ua.edu
Sent: Tuesday, May 19, 2009 7:35:16 PM GMT -08:00 US/Canada Pacific
Subject: Submitting a Marketing REQUEST (was: BLOCK CONTAINS
Frank Swarbrick fswarbr...@gmail.com wrote in message
news:listserv%200905191643164240.0...@bama.ua.edu...
snip
By the way, any pointers on how
Actually, I don't think the Standard has much opinion on the entire BLOCK
CONTAINS clause. The fact is that MOST existing conforming COBOL
compilers run in environments where blocking doesn't exist any more. For
most conforming compilers, this phrase is documented as syntax checked but
has
be BLOCK 0.
Great idea, and I wish IBM added that option to the compiler.
What a stupid necessity that programmers have to code BLOCK CONTAINS
0 !
What happens if the programmer pre-allocates the data set? It's
still a stupid necessity, but it might help in dealing with
situations where
On Mon, 18 May 2009 13:08:28 -0500, John McKown joa...@swbell.net
wrote:
I just ran a quick test using Enterprise COBOL 3.4.1. I had one input FD and
three output FDs. The output FDs were: (1) No BLOCK CONTAINS at all; (2)
BLOCK CONTAINS 0 RECORDS; and (3) BLOCK CONTAINS 1 RECORDS. I
directed
):
-
13.16.10 BLOCK CONTAINS clause
The BLOCK CONTAINS clause specifies the size of a physical record.
13.16.10.1 General format
13.16.10.2 Syntax rules
1) If integer-1 is specified, integer-2 shall be greater than integer-1.
13.16.10.3 General rules
1) This clause is required
, but it is important
to understand exactly does happen/when/how under z/OS - so the
requirements
for the conversion are resourced and met.
As I have said previously, I do think that having Block Contains 0 is the
best solution - as it gives desirable results when the phrase is used and
doesn't hurt when
Frank Swarbrick fswarbr...@gmail.com wrote in message
news:listserv%200905191643164240.0...@bama.ua.edu...
snip
By the way, any pointers on how to submit a marketing requirement? VSE
actually has a submit a requirement web page (https://www-
On 15 May 2009 18:08:22 -0700, cfmpub...@ns.sympatico.ca (Clark
Morris) wrote:
I checked the reference you gave and for QSAM files, if the BLOCK
CONTAINS clause is omitted, BLOCK 1 RECORD is assumed. This stupidity
has aggravated me for years.
The whole idea of (IBM mainframe) CoBOL still
I may (a while ago - in the past) have mislead Clark.
There is DEFINITELY a difference between coding
Block Contains 1
versus
omitting the Block CONTAINS clause
(for output files)
The former creates a RECFM=FB/BM file (with one record per block)
while
the latter produces a RECFM=F/V
On Friday 15 May 2009 04:47, Clark Morris wrote:
I submitted a SHARE requirement back in the 1990's to have
a compile option that the default be BLOCK 0.
Great idea, and I wish IBM added that option to the compiler.
What a stupid necessity that programmers have to code BLOCK
I don't know about Clark submitting a requirement in the 90's, but there is
an existing SHARE requirement:
SSLNGC03003 Compiler option to make BLOCK CONTAINS clause SMS sensitive
(Part of the Description)
The current default for when the BLOCK CONTAINS x RECORDS clause is
omitted
a stupid necessity that programmers have to code BLOCK CONTAINS 0 !
What happens if the programmer pre-allocates the data set? It's
still a stupid necessity, but it might help in dealing with
situations where recompilation is impractical.
-- gil
On Monday 18 May 2009 18:04, Paul Gilmartin wrote:
What a stupid necessity that programmers have to code BLOCK CONTAINS 0 !
What happens if the programmer pre-allocates the data set?
It's still a stupid necessity, but it might help in dealing with
situations where recompilation
Curiousity question: would using the IFG0EX0B exit be a Good Idea(tm)? From
my initial reading, it can change the BLKSIZE. And likely the RECFM as well (to
change F/V to FB/VB).
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N.
I just ran a quick test using Enterprise COBOL 3.4.1. I had one input FD and
three output FDs. The output FDs were: (1) No BLOCK CONTAINS at all; (2)
BLOCK CONTAINS 0 RECORDS; and (3) BLOCK CONTAINS 1 RECORDS. I directed each
to a separate SMS managed disk dataset. On the JCL for each output file
The whole idea of (IBM mainframe) CoBOL still caring about blocksize is
irritating.
The fix of making BLOCK CONTAINS 0 is IMHO, not the way fixes should be.
I really don't think this qualifies as a 'fix'.
I learned COBOL in 1976, and was taught, back then, to always use BLOCK
CONTAINS 0 RECORDS
What a stupid necessity that programmers have to code BLOCK CONTAINS 0 !
What a stupid necessity that REXX programmers have to code:
PARSE (UPPER) ARG var1 var2 ...
What a stupid necessity to have to code extra volumes in JCL/IDCAMS (or in your
ACS) routines.
What a stupid necessity
/where the different BLOCK CONTAINS clauses make a
difference.
John McKown joa...@swbell.net wrote in message
news:listserv%200905181308288278.0...@bama.ua.edu...
I just ran a quick test using Enterprise COBOL 3.4.1. I had one input FD
and
three output FDs. The output FDs were: (1) No BLOCK
On 18 May 2009 11:30:02 -0700, eamacn...@yahoo.ca (Ted MacNEIL) wrote:
The whole idea of (IBM mainframe) CoBOL still caring about blocksize is
irritating.
The fix of making BLOCK CONTAINS 0 is IMHO, not the way fixes should be.
I really don't think this qualifies as a 'fix'.
I learned COBOL
It is a lie to say BLOCK CONTAINS 0 RECORDS, it would have been better to have
done that by leaving out the line altogether.
I don't think it's a lie.
Historically, ZERO has always had a special meaning.
In COBOL's case, it just means that the programme is not going to determine the
blocksize
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of Bill Klein
Sent: Monday, May 18, 2009 1:45 PM
To: IBM-MAIN@bama.ua.edu
Subject: Fw: BLOCK CONTAINS
John,
What happens if you run the exact same test, but instead of
having
On Mon, 18 May 2009 18:18:20 +0200, Gilbert Saint-Flour wrote:
On Monday 18 May 2009 18:04, Paul Gilmartin wrote:
What a stupid necessity that programmers have to code BLOCK CONTAINS 0 !
What happens if the programmer pre-allocates the data set?
It's still a stupid necessity, but it might
Yah.
It should be done by the access method; the application should be oblivious to
the entire blocking process.
We have 45 years of baggage.
Woulda, coulda, shoulda.
Most people/shops have templates with these things already specified.
Copy, and move on.
If BLOCK CONTAINS is an issue, you
On 18 May 2009 13:35:40 -0700, in bit.listserv.ibm-main you wrote:
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of Bill Klein
Sent: Monday, May 18, 2009 1:45 PM
To: IBM-MAIN@bama.ua.edu
Subject: Fw: BLOCK CONTAINS
John,
What
On 18 May 2009 14:10:36 -0700, in bit.listserv.ibm-main you wrote:
On Mon, 18 May 2009 18:18:20 +0200, Gilbert Saint-Flour wrote:
On Monday 18 May 2009 18:04, Paul Gilmartin wrote:
What a stupid necessity that programmers have to code BLOCK CONTAINS 0 !
What happens if the programmer pre
On Mon, 18 May 2009 21:28:02 +, Ted MacNEIL wrote:
We have 45 years of baggage.
Woulda, coulda, shoulda.
Most people/shops have templates with these things already specified.
Copy, and move on.
Whenever I hear this diachronic rationale for some
deficiency of z/OS, I think of the political
:
America: Love it or leave it!
were countered with:
America: Change it or lose it!
C 'America' 'z/OS' ALL
You missed my point(s):
1. The existance of templates can/does handle the requirement for BLOCK
CONTAINS.
2. Some things are way to trivial to lose sleep over.
3. There are more
Paul Gilmartin paulgboul...@aim.com wrote in message
news:listserv%200905181607125082.0...@bama.ua.edu...
On Mon, 18 May 2009 18:18:20 +0200, Gilbert Saint-Flour wrote:
snip
Is default unblocked an ANSI Standard requirement? (Of course
this doesn't preclude an extension implemented via
the requirements
for the conversion are resourced and met.
As I have said previously, I do think that having Block Contains 0 is the
best solution - as it gives desirable results when the phrase is used and
doesn't hurt when it isn't used.
Ted MacNEIL eamacn...@yahoo.ca wrote in message
news:1311180719
the BLOCK CONTAINS clause is omitted, that externally
specified (by DD or SDB) value should prevail. And thus that z/OS
COBOL deviates from the Standard on this matter.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access
a file as RECFM=VB, BLKSIZE=1, LRECL=4004 then
1) If Cobol says BLOCK CONTAINS 1 it works (of course).
2) If Cobol says BLOCK CONTAINS 0 it works.
3) If Cobol says BLOCK CONTAINS 12345 it works (!!!)
4) If Cobol does not have a BLOCK CONTAINS clause it works (!!!)
This is the case
...@gmail.com]
Sent: Friday, May 15, 2009 6:20 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: VSE I/O Performance VS MVS [was BLOCK CONTAINS]
On Fri, 15 May 2009 14:09:33 -0400, Thompson, Steve
steve_thomp...@stercomm.com wrote:
Because of past conversions, I think this needs to be said:
1) VSE/ESA got
, Inc.
201-930-8260
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Clark Morris
Sent: Thursday, May 14, 2009 10:45 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: BLOCK CONTAINS
snip
While blocked input files may be read successfully if neither
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Frank Swarbrick
Sent: Thursday, May 14, 2009 7:03 PM
To: IBM-MAIN@bama.ua.edu
Subject: BLOCK CONTAINS
I have been a bit of experimenting with z/OS QSAM files from a Cobol
program
and I find
On Friday 15 May 2009 02:05, Frank Swarbrick wrote:
We are migrating from VSE to z/OS, and at the same time we are going
to convert most of our existing ESDS files to regular sequential files.
I see no reason to add BLOCK CONTAINS 0 to all of our FD's if it has
no affect (our VSAM FD's do
] On Behalf Of
Gilbert Saint-Flour
Sent: Friday, May 15, 2009 8:29 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: BLOCK CONTAINS
On Friday 15 May 2009 02:05, Frank Swarbrick wrote:
We are migrating from VSE to z/OS, and at the same time we are going
to convert most of our existing ESDS files to regular
...@ssfcu.org]
Sent: Friday, May 15, 2009 9:37 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: BLOCK CONTAINS
What if a new device came out and there was a better optimum blocksize for it?
Wouldn't you have to recompile everthing that used that file to get the optimum
blocksize? I don't know I'm just asking
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Ward, Mike S
Sent: Friday, May 15, 2009 8:38 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: BLOCK CONTAINS
What if a new device came out and there was a better optimum blocksize
for it? Wouldn't
On Fri, 15 May 2009 09:27:42 -0400, Thompson, Steve wrote:
Welcome to the MVS world. In the MVS world, we are not device dependant,
nor are we data definition locked/blocked. We generally don't have to
recompile our programs, change the DTF contents (DCB in MVS), etc. just
because the file
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Paul Gilmartin
Sent: Friday, May 15, 2009 9:07 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: BLOCK CONTAINS
On Fri, 15 May 2009 09:27:42 -0400, Thompson, Steve wrote:
Welcome to the MVS world
If we are not device dependant, why is there such intense trepidation and
resistance to the mere suggestion of a device with a novel geometry such as
more bytes per track or more tracks per cylinder?
That is a different issue.
If you code BLOCK CONTAINS 0, your application does not need
. The
manuals
seem to imply that if you use the BLOCK CONTAINS clause (whether 0 or
something else) then the file has a RECFM of either VB or FB. And if you
don't
include it then it's either V or B.
While blocked input files may be read successfully if neither the
block size nor BLOCK 0 is specified
On Fri, 15 May 2009 09:27:42 -0400, Thompson, Steve
steve_thomp...@stercomm.com wrote:
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Frank Swarbrick
Sent: Thursday, May 14, 2009 7:03 PM
To: IBM-MAIN@bama.ua.edu
Subject: BLOCK CONTAINS
Perhaps this explains the observed action?
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3LR31/5.2.4
quote
BLOCK CONTAINS
0 can be specified for QSAM files. If BLOCK CONTAINS 0 is specified for a
QSAM file, then:
* The block size is determined at run time from
no reason to add BLOCK CONTAINS 0 to all of our FD's if it has
no affect (our VSAM FD's do not (generally!) specify the BLOCK CONTAINS
clause, because it has no meaning to VSAM).
IIRC, BLOCK CONTAINS 0 is only needed for OUTPUT files in COBOL, but I
think
it's better to put it everywhere, so
On Fri, 15 May 2009 10:34:31 -0400, Thompson, Steve
steve_thomp...@stercomm.com wrote:
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Paul Gilmartin
Sent: Friday, May 15, 2009 9:07 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: BLOCK CONTAINS
that if you use the BLOCK CONTAINS clause (whether
0 or something else) then the file has a RECFM of either VB or FB. And
if you don't include it then it's either V or B.
We are not using a vendor. We have systems and applications programmers
that come from the MVS world, so we're going
--snip
What if a new device came out and there was a better optimum blocksize
for it? Wouldn't you have to recompile everthing that used that file to
get the optimum blocksize? I don't know I'm just asking.
On Fri, 15 May 2009 11:31:19 -0500, McKown, John
jmck...@healthmarkets.com wrote:
Perhaps this explains the observed action?
http://publibz.boulder.ibm.com/cgi-
bin/bookmgr_OS390/BOOKS/IGY3LR31/5.2.4
quote
BLOCK CONTAINS
0 can be specified for QSAM files. If BLOCK CONTAINS 0 is specified
3) If Cobol says BLOCK CONTAINS 12345 it works (!!!)
I'll bet you 3) If Cobol says BLOCK CONTAINS doesn't :)
Dave Gibney
Information Technology Services
Washington State University
--
For IBM-MAIN subscribe / signoff
job of pointing this out.
Here is an extract from one page in our course Enterprise COBOL
Update I: Essentials:
While not strictly a change to the language, there has
been a change to the way OPEN works that is worthwhile
knowing about
* Historically, coding BLOCK CONTAINS ensured the value
Because of past conversions, I think this needs to be said:
1) VSE/ESA got to use XA I/O just like MVS. This means, to the VSE shop,
that some slick stuff that got offloaded to the I/O Subsystem (shall we
say parts of VM's and MVS' I/O Supervisor code) became available w/o any
JCL or application
On Fri, 15 May 2009 10:05:48 -0700, Gibney, Dave gib...@wsu.edu wrote:
3) If Cobol says BLOCK CONTAINS 12345 it works (!!!)
I'll bet you 3) If Cobol says BLOCK CONTAINS doesn't :)
Sorry, you lose that bet. That does work.
The only things that I've been able to determine simple do
By fail, I would have expected you to get an I/O error reading an
existing file where the COBOL BLOCK CONTAINS is less. But, now I think
about it, recent DFP, like somewhere in the last coupe decades (Probably
around os390 1.4 or 2.5 for us) OPEN got smarter and handles unlike
block sizes much
On Fri, 15 May 2009 14:09:33 -0400, Thompson, Steve
steve_thomp...@stercomm.com wrote:
Because of past conversions, I think this needs to be said:
1) VSE/ESA got to use XA I/O just like MVS. This means, to the VSE shop,
that some slick stuff that got offloaded to the I/O Subsystem (shall we
say
...@gmail.com]
Sent: Friday, May 15, 2009 6:20 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: VSE I/O Performance VS MVS [was BLOCK CONTAINS]
On Fri, 15 May 2009 14:09:33 -0400, Thompson, Steve
steve_thomp...@stercomm.com wrote:
Because of past conversions, I think this needs to be said:
1) VSE/ESA got to use XA
On 15 May 2009 09:32:23 -0700, in bit.listserv.ibm-main you wrote:
Perhaps this explains the observed action?
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3LR31/5.2.4
quote
BLOCK CONTAINS
0 can be specified for QSAM files. If BLOCK CONTAINS 0 is specified for a
QSAM file
--- On Fri, 5/15/09, Frank Swarbrick fswarbr...@gmail.com wrote:
SNIP--
What does this have to do with anything? Well, the
typical throughput
performance gains seen in the past when going from VSE
to MVS don't
happen because what was
I have been a bit of experimenting with z/OS QSAM files from a Cobol program
and I find that the manuals don't exactly agree with my results. The manuals
seem to imply that if you use the BLOCK CONTAINS clause (whether 0 or
something else) then the file has a RECFM of either VB or FB
On 14 May 2009 17:05:53 -0700, in bit.listserv.ibm-main you wrote:
I have been a bit of experimenting with z/OS QSAM files from a Cobol program
and I find that the manuals don't exactly agree with my results. The manuals
seem to imply that if you use the BLOCK CONTAINS clause (whether 0
81 matches
Mail list logo
