I have to admit, though, that the ones I have read were not page
turners.
sure they were, you had to keep turning the pages to get past the
incomprensible CEspeak to find the few nuggets of useful info
--
Bruce A. Black
Senior Software Developer for FDR
Innovation Data Processing
In a message dated 8/8/2005 6:08:28 P.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
No; the 3390 is an FBA disk simulating CKD.
That's what I get for trusting, but not verifying, IBM's technical
publications. GC26-4573-03, IBM 3390 Direct Access Storage Introduction, says
All
In [EMAIL PROTECTED], on 08/09/2005
at 09:29 AM, Bill Fairchild [EMAIL PROTECTED] said:
I don't usually look under the covers.
I vaguely recall that near the time of the announcement. IBM mentioned
that the 3370 and 3375 were the same disk drive except for the
FBA-CKD conversion.
I just read
In a message dated 8/6/2005 9:35:55 P.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
real CKD DASD haven't been available for decades...
IBM stopped manufacturing 3390 disks about five years ago, I believe, which
was much more recent than decades. The 3390 disk is a CKD DASD.
IBM stopped manufacturing 3390 disks about five years ago, I believe, which
was much more recent than decades.
according to the IBM sales manual, the 3390 disks were withdrawn from
marketing in 1996 (April or December, depending on model) so almost a
decade. Service is still avaialble
In [EMAIL PROTECTED], on 08/08/2005
at 10:43 AM, Bill Fairchild [EMAIL PROTECTED] said:
IBM stopped manufacturing 3390 disks about five years ago, I believe,
which was much more recent than decades. The 3390 disk is a CKD
DASD.
No; the 3390 is an FBA disk simulating CKD. I'm not aware of any
In [EMAIL PROTECTED], on 08/05/2005
at 08:13 AM, Ron and Jenny Hawkins [EMAIL PROTECTED] said:
Seeing as most of these methods work on principles of 3390 physical
disk layout, then this argument would also recommend against cached
DASD and arrays that emulate 3390.
No, because cached DASD
In
[EMAIL PROTECTED],
on 08/04/2005
at 11:44 AM, Jeffrey Deaver [EMAIL PROTECTED] said:
I was not looking to spend a good deal of time on the phone with them
and hardly have to the knowledge to argue the points well, no simply
nodded my head (sort to speak). But now that I'm thinking about
Jim,
I wholeheartedly agree with you, Both the DFSORT and the SYNCSORT guys have
done a great job of exploiting DIM techniques to make the most of what is
generally an IO bound process. With both sort products I think it is fair to
say that they will only use the SORTWK when Hiperspace and
: DFSORT MOD27 support
The SMS Implementation course (DVD version, anyway) that I obtained late
last year still mentions that Sort work datasets should be excluded from
VIO.
We run Syncsort here, and I was curious, so called them up to discuss this
conversation. The fellow I spoke
First was that the efficient access methods built into the product were not
as effective when using VIO.
Second was that the decision to place the temporary dsn in VIO was based
only on the primary allocation and that if the sortwork used a number of
secondary allocations, it could cause a
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 08/04/2005
08:13:03 PM:
First was that the efficient access methods built into the product
were
not
as effective when using VIO.
Seeing as most of these methods work on principles of 3390 physical disk
layout, then this
Radoslaw Skorupka wrote:
AFAIK new DFSORT for z/OS 1.5 uses 64-bit memory objects instead of
hiperspaces. Previous version (rel. 14) liked Expanded memory very much
and missed it in z/Architecture.
z/OS DFSORT V1R5 can use memory object sorting, data space sorting or
hipersorting, and will
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of McKown, John
Sent: Wednesday, 3 August 2005 12:08 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: DFSORT MOD27 support
-Original Message-
From: IBM Mainframe Discussion List
: Wednesday, 3 August 2005 12:08 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: DFSORT MOD27 support
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Ron and Jenny Hawkins
Sent: Tuesday, August 02, 2005 10:50 AM
To: IBM-MAIN@BAMA.UA.EDU
All(hopefully Frank),
I'm not a DFSORT expert, but have some questions(an ETR has
Already been opened with IBM on this). We recently
Started adding MOD27's to our SMS management pool that is used
For SORTWKxx allocations. Jobs that worked in the past now fail
Because DFSORT cannot switch to
On Mon, 2005-08-01 at 10:49 -0400, Jousma, David wrote:
Did you leave SORTWKxx allocations on mod-9's?
I left SORTWKxx allocations on unmanaged public -9s. Didn't see any
good reason for managing them.
--
David Andrews
A. Duda and Sons, Inc.
[EMAIL PROTECTED]
All(hopefully Frank),
I'm not a DFSORT expert, but have some questions(an ETR has
Already been opened with IBM on this). We recently
Started adding MOD27's to our SMS management pool that is used
For SORTWKxx allocations. Jobs that worked in the past now fail
Because DFSORT cannot
David Andrews wrote:
On Mon, 2005-08-01 at 10:49 -0400, Jousma, David wrote:
Did you leave SORTWKxx allocations on mod-9's?
I left SORTWKxx allocations on unmanaged public -9s. Didn't see any
good reason for managing them.
Maybe except:
- possibility to keep work datasets on dedicated
OMG, another MVS recommendation that won't lay down and die!!! (I'm not
dissing you Kees) This one is well past its use by date.
It was (and still is) a very good thing to exclude SORTWK datasets from VIO
when VIO is going out to your locals. Blockset to the SORTWORK datasets will
produce a much
David Jousma wrote:
I'm not a DFSORT expert, but have some questions(an ETR has Already been
opened with IBM on this). We recently Started adding MOD27's to our SMS
management pool that is used For SORTWKxx allocations. Jobs that worked in
the past now fail Because DFSORT cannot switch to
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Ron and Jenny Hawkins
Sent: Tuesday, August 02, 2005 10:50 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: DFSORT MOD27 support
snip
However, when Expanded Storage arrived, VIO started
22 matches
Mail list logo
