On Sat, 12 May 2007 00:22:19 -0400, Pinnacle wrote:
Dynamic ISPF covers that. Also, z/OS V1R8 has an option to make STACK the
default for all LIBDEFs (my enhancement request, since no one could ever
tell me what a non-STACKed LIBDEF was ever good for except screwing up your
ISPF session). You
On Fri, 11 May 2007 11:21:13 -0500, Thomas Conley wrote:
#7 - Get rid of your stupid SMP/E procs and give me DDDEFS!! (this means you
CA-1 and Panvalet)
#2 - Stop giving me 3K and 6K blocksizes, loadlibs should be blocked at 32760
and everything else should get 0 for SDB (unless you have a wacky
But, can an ISV depend all customers' having Dynamic ISPF
Yes, this is SOP. All a vendor needs to do is code a clist
or exec that does the LIBDEFs and have the customer activate
it from a panel.
Bob Shannon
Rocket Software
#2 - Stop giving me 3K and 6K blocksizes, loadlibs should be blocked at
32760
and everything else should get 0 for SDB (unless you have a wacky format
like
CA-Viewpoint).
Does SDB make an adverse selection for loadlibs? Has a suggestion
been made to IBM to ameliorate this? How much worse, by
Paul Gilmartin wrote:
On Fri, 11 May 2007 11:21:13 -0500, Thomas Conley wrote:
#7 - Get rid of your stupid SMP/E procs and give me DDDEFS!! (this means you
CA-1 and Panvalet)
#2 - Stop giving me 3K and 6K blocksizes, loadlibs should be blocked at 32760
and everything else should get 0 for SDB
I downloaded the zip file from from
http://www.vm.ibm.com/download/packages/alltime.html and unzipped it just
fine. I even browsed every file. This is a May 2002 version. If your copy was
damaged, was it the vmarc or zip version? Did you report it to IBM? What
indication led you to believe it
Similar to what I do for labs at the SHARE Conference. I have simpler needs so
I provide one edit macro for them to run while they are editing the IEBUPDTE
input they will use to populate their PDS. IBM uses CPPUPDTE and the
SERVERPAC dialog to alter and tailor JCL for installations. ISPF file
It had some small effect, back when RPS delay was a signivicant factor.
I still allocate directories in full track amounts, but mostly from
force of habit. I can't see that it does any harm, and the allocations
that come from IBM and OEM software providers aren't always large enough
to apply
The PDS directory records are a fixed size, LRECL=255, I believe. My reason to
allocate a PDS filling a track, or multiples, with the directory comes from
thinking half-track blocking is efficient for reads and if I use one half, or
full
track directory then I am doing the least amount of I/O
I haven't looked lately; does it contain the noun RAX ?? or the 2848
controller and the 2260 display terminal?
Michael Stack wrote:
I dunno. My personal completeness measure would be the presence of
the term GOVRFLB. No particular reason - I just like to pronounce it.
Mike
At 01:26 PM
-snip-
The PDS directory records are a fixed size, LRECL=255, I believe. My
reason to allocate a PDS filling a track, or multiples, with the
directory comes from thinking half-track blocking is efficient for reads
and if I use one half, or full
Pinnacle wrote:
Tom,
I tested this in the old days of SLED DASD, and the directory was a
keyed track and you COULD NOT store a member in the directory track. It
always took 2 tracks minimum for a PDS (of course, this has not been
true for about 15 years).
Regards,
Tom Conley
255? Really?
Bob
-snip-
The PDS directory records are a fixed size, LRECL=255, I believe. My
reason to allocate a PDS filling a track, or multiples, with the
directory comes from thinking half-track blocking is efficient for reads
and if I
Paul Gilmartin wrote:
Does SDB make an adverse selection for loadlibs?
The issue is not block size selection but rather deterministic
recognition of the library as being a loadlib. Though common, DSORG=PO
and RECFM=U do not necessarily indicate a loadlib/polib. Therefore, the
system can't
IIRC, the DIRF bit was implemented because of a problem in DADSM causing
overlapping tracks on 2314 volumes in a shared DASD environment with 2
controllers (2314 2844). I was playing systems programmer at NIH in the
late '60s thru the early '80s and we ran into the problem with horrific
results.
Rick Fochtman said:
Ken, the physical BLKSIZE of the directory is 255, plus a 8-byte physical
key.
I think you'll find that's 256.
From: Rick Fochtman [EMAIL PROTECTED]
Reply-To: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Top 10 software install
Pinnacle wrote:
[...]
Regardless of how many you specified, the first member starts on/in the
next track after the directory.
That's not correct. Never was. You can prove it easily enough.
Create a
PDS with one track, no secondary. If what you say was true, you'd
never be
able to create
- Original Message -
From: Greg Price [EMAIL PROTECTED]
Newsgroups: bit.listserv.ibm-main
Sent: Saturday, May 12, 2007 11:19 AM
Subject: Re: Top 10 software install gripes
Pinnacle wrote:
Tom,
I tested this in the old days of SLED DASD, and the directory was a
keyed track and you
thus reducing CPU overhead and the chance of RPS miss.
That is so five minutes ago.
1. ECKD got rid of most overhead
2. RAID took care of the rest.
3. Talk about cache.
Allocate with whatever units you wish.
Performance issues regarding cylinder, block, track allocation are long gone.
Can you
On Sat, 12 May 2007 08:36:03 -0700, Edward Jaffe wrote:
Paul Gilmartin wrote:
Does SDB make an adverse selection for loadlibs?
The issue is not block size selection but rather deterministic
recognition of the library as being a loadlib. Though common, DSORG=PO
and RECFM=U do not necessarily
On Fri, 11 May 2007 11:21:13 -0500, Thomas Conley wrote:
#8 - Stop telling me to jam all my SMP/E zones into one GLOBAL, at least give
me the JCL to create multiple VSAM clusters for the TARGET and DLIB zones.
OK. Educate me:
Why does this matter; what's the motivation?
Is there perhaps
On Sat, 12 May 2007 08:36:03 -0700, Edward Jaffe wrote:
Non-sequitur. SDB does not choose 1/2 track blocking when RECFM=U.
OK. I RTFM. Using Data Sets confirms that SDB does not operate on
RECFM=U. But why not?
However:
Title: z/OS V1R7.0 MVS Program Management: User's Guide and
Paul Gilmartin wrote:
On Fri, 11 May 2007 11:21:13 -0500, Thomas Conley wrote:
#8 - Stop telling me to jam all my SMP/E zones into one GLOBAL, at least give
me the JCL to create multiple VSAM clusters for the TARGET and DLIB zones.
OK. Educate me:
Why does this matter; what's the
Mark Zelden wrote:
[...]
As far as more options... I know you use Sun/STK like we do... I think
I heard VTCS 6.2 will have some help there.
VTCS 6.2 supports 4GB VTVs. Before compression.
AFAIK, new IBM VTS supports even 12GB VTVs.
--
Radoslaw Skorupka
Lodz, Poland
--
BRE Bank SA
ul.
Hi Howard,
On Fri, 4 May 2007 12:05:45 -0600, Howard Brazee [EMAIL PROTECTED]
wrote:
I would think that most reasons for blocking at particular rates would
be less important now with such cheap memory. I'm curious whether
the tape drives nowadays have sufficient buffering, not to mention how
Hi, for some reason nobody turn on this flag in our EMC box (DMX3000 and
DMX2000).
After a long discussion EMC support turn on this flag and now the decive shows
MIDAW enabled.
We running z/OS R7. Any experience in this area? Performance for DB2 or others?
Roland Schiradin
ALTE LEIPZIGER
On 12 May 2007 13:44:55 -0700, in bit.listserv.ibm-main you wrote:
Mark Zelden wrote:
[...]
As far as more options... I know you use Sun/STK like we do... I think
I heard VTCS 6.2 will have some help there.
VTCS 6.2 supports 4GB VTVs. Before compression.
AFAIK, new IBM VTS supports even 12GB
27 matches
Mail list logo
