>>> On 9/7/2012 at 06:56 PM, Mike Schwab wrote:
> 10 or 20 Linux servers consolidated onto 1 x86-64 blade server.
> 300 Linux servers consolidated onto 1 zIFL.
>
> Now that looks reasonable. A full speed z processor is still 15 to 30
> times faster than Virtual x86-64.
Um, no, that's not what
At 15:30 -0400 on 09/07/2012, Shmuel Metz (Seymour J.) wrote about
Re: Anyone know how to copy a PDS directory as a flat file?:
>Got paraphrase of "WAD".
Broken as designed?
That is BAD - ie: The design is wrong but the code works as the
design says it should.
WAD is Working As Designed
At 10:05 -0500 on 09/06/2012, Kirk Wolf wrote about Re: Anyone know
how to copy a PDS directory as a flat file?:
But don't PDS directory blocks have keys on disk? IEBGENER won't copy
those - your target dataset will be regular DSORG=PS.
You can ignore the existence of the keys. Their sole p
Clark Morris writes:
> I see what you have posted and what Lynn Wheeler has posted and am
> confused. Assuming that VMware on Intel and similar solutions for the
> p series have gotten much better since 2007 (not unrealistic), I'm
> looking at the relative CPU power and asking is the server utili
SORTWK does not use secondary extents.
Gradully change the SMS SPACE default toward 1/16th of a volume (up to
64K Cylinders) for primary and secondary. That would allow it to fill
up an empty volume before going to the next volume.
Actually, if they could look at the size of their dataset after
See 'z/OS V1R12 DFSMS Using Data Sets', Chapter 26. It has a section titled
'Reading a PDS Directory Sequentially'. Chapter 27 has a similar section for
reading a PDSE directory.
Chris Blaicher
Senior Software Engineer, Software Services
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake,
I decided to ask this forum about a "problem" we have were I work. In
summary, the programmers don't want to be forced to specify SPACE
parameters in the JCL (or IDCAMS DEFINEs). They also don't want to be
forced to use SORTWKnn allocations or do specify any SIZE type
parameters in the controls. Th
Thanks Walt, that what I thought also..
Scott ford
www.identityforge.com
On Sep 9, 2012, at 7:28 PM, Walt Farrell wrote:
> On Sun, 9 Sep 2012 12:05:02 -0400, Scott Ford wrote:
>
>> I don't dispute fact that replacement for an IDCAMS LISTCAT for determining
>> statuses of cataloged VSAM datas
In
,
on 09/09/2012
at 12:50 PM, said:
>find: FSUM6004 write error on standard output: EDC5133I NO SPACE LEFT
>ON DEVICE.
Look at the script to see where it is redirecting the output of find,
e.g.,
find foo >bar
to redirect find foo to bar. That might be in an HFS, TFS or ZFS.
Whatever, you
On Sun, 9 Sep 2012 12:05:02 -0400, Scott Ford wrote:
>I don't dispute fact that replacement for an IDCAMS LISTCAT for determining
>statuses of cataloged VSAM datasets , etc could be in the future.
>The csi interface I use.
I doubt that IBM will provide yet another interface. CSI is what people
On 9 Sep 2012 07:06:50 -0700, in bit.listserv.ibm-main you wrote:
>Another option is
>
>
>OA06673: EDC5133I NO SPACE LEFT ON DEVICE RECEIVED WHEN ATTEMPTING TO
>CRECREATE A FILE ON A ZFS AGGREGATE THAT IS NOT FULL.
>
>Application that quickly creates many small files and then
>deletes them in a sm
I don't dispute fact that replacement for an IDCAMS LISTCAT for determining
statuses of cataloged VSAM datasets , etc could be in the future. The csi
interface I use.
Scott ford
www.identityforge.com
On Sep 9, 2012, at 1:32 AM, Ed Gould wrote:
> Scott:
> I would suggest rather than to suggest
On Sep 6, 2012, at 10:31 PM, Skip Robinson wrote:
SNIP--
If you are deeply disturbed by RC 8, either take a (physician
prescribed)
pill, or spend some of your vast spare time researching each erro
Folks -
I would like to know if anyone can provide an example (BAL) of using IARVSERV
on the target end of the page-sharing process, particularly between code
running in two or more different address spaces ? The method of creating the
source data side of this process appears fairly straightfo
Paul,
You may need to go to the vendor for this issue. Who supports Astute - what
vendor?
Lizette
>
> We upgraded the operating system to z/OS 1.13 from z/OS 1.11 and are
getting an
> S0C4 at X'458' in Astute module AST$MEXT, CSECT AST$MEXT. Has anyone come
> across this and if you have a fix
Another option is
OA06673: EDC5133I NO SPACE LEFT ON DEVICE RECEIVED WHEN ATTEMPTING TO
CRECREATE A FILE ON A ZFS AGGREGATE THAT IS NOT FULL.
Application that quickly creates many small files and then
deletes them in a small zfs aggregate, eventually begins
receiving EDC5133I No space left on de
It is possible that it is a temp volume and not the volume where the zFS file
resides. I always thought that IBM should specify what volume/file name in the
EDC5133I messages
Lizette
>
> It is the disk volume where your ZFS resides.
>
> ITschak
>
> On Sun, Sep 9, 2012 at 12:50 PM, גדי בן
We upgraded the operating system to z/OS 1.13 from z/OS 1.11 and are
getting an S0C4 at X'458' in Astute module AST$MEXT, CSECT AST$MEXT. Has
anyone come across this and if you have a fix can you sent to this sending
email.
Thank You,
Paul Strauss
Integrated Technology Delivery, Global Services
http://www-01.ibm.com/support/docview.wss?uid=isg1OA36700
GIve these instructions a shot.
On Sun, Sep 9, 2012 at 5:14 AM, גדי בן אבי wrote:
> The volume where the WAS ZFS resides definitely has room. I confirmed this by
> using the zfsadm grow command.
> Could the output be going to a different
The volume where the WAS ZFS resides definitely has room. I confirmed this by
using the zfsadm grow command.
Could the output be going to a different directory?
Gadi
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Itschak Mugzach
Sen
It is the disk volume where your ZFS resides.
ITschak
On Sun, Sep 9, 2012 at 12:50 PM, גדי בן אבי wrote:
> Hi,
>
> As part of a large package of PTFS, I am applying service to WAS OEM.
> The PTF’s are UK76762, UK76768 and UK76773.
> The APPLY fails with these messages:
> BPXF151I BPXCOPY WAS IN
Hi,
As part of a large package of PTFS, I am applying service to WAS OEM.
The PTF’s are UK76762, UK76768 and UK76773.
The APPLY fails with these messages:
BPXF151I BPXCOPY WAS INVOKED FOR HEAD ID 01.
BPXF150I MVS DATA SET WITH DDNAME SYSUT1 SUCCESSFULLY COPIED INTO TEXT HFS FILE
/usr/lpp/zWeb
22 matches
Mail list logo
