In [EMAIL PROTECTED], on 05/13/2007
at 08:05 AM, Kenneth E Tomiak [EMAIL PROTECTED] said:
Not to be confused with how many bytes per member. That varies, a
loadlib uses flags and I recall used the same number of bytes for
every loadlib member,
No, the size of a load module directory entry
Bow out at any time.
It is simply *not worth* to discuss. I simply don't care about wasted track
in my PDS.
--
Radoslaw Skorupka
Lodz, Poland
Not sure anyone stated 44, 45, 46 were magic numbers, We stated how many
fit on a track and how we were willing to try to use that in our allocations.
Rick Fochtman wrote:
-snip--
I think everyone agrees that directory should have safe margin for
updates. However the discussion was about magic numbers like 44,45, or
46. Spare directory blocks are obvious, any of the numbers above not.
Despite of
On Thu, 17 May 2007 00:23:23 +, Ted MacNEIL wrote:
For 15 years I have allocated at least one cylinder for directory space.
Never had a STOW problem.
Really? You never allocate less than 674 directory blocks?
--
Tom Marchant
On Wed, 16 May 2007 18:44:28 -0400, Pinnacle wrote:
My gripe is that there is NO REASON for a vendor to be stingy with
directory blocks. I hate it when the initial install goes OK, then the
first maintenance tape causes me 5 runs because 4 datasets run out of
directory blocks.
THANK
Tom Marchant wrote:
On Wed, 16 May 2007 18:44:28 -0400, Pinnacle wrote:
My gripe is that there is NO REASON for a vendor to be stingy with
directory blocks. I hate it when the initial install goes OK, then the
first maintenance tape causes me 5 runs because 4 datasets run out of
directory
Really? You never allocate less than 674 directory blocks?
At the price of today's disk, why not?
I have better things to occupy my time than worry about directory problems.
One cylinder it is!
-
Too busy driving to stop for gas!
-snip--
I think everyone agrees that directory should have safe margin for
updates. However the discussion was about magic numbers like 44,45, or
46. Spare directory blocks are obvious, any of the numbers above not.
Despite of discussion noone explained
: Top 10 software install gripes
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
% of PDS in that shop.
Ron
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of R.S.
Sent: Thursday, 17 May 2007 8:25 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Top 10 software install gripes
I think everyone agrees that directory should have
- Original Message -
From: Neal Eckhardt [EMAIL PROTECTED]
Newsgroups: bit.listserv.ibm-main
Sent: Wednesday, May 16, 2007 4:18 PM
Subject: Re: Top 10 software install gripes
On 11 May 2007 12:17:17 -0700, [EMAIL PROTECTED] (Tom
Marchant) wrote:
On Fri, 11 May 2007 11:21:13 -0500
Tom,
You aren't the only ones, just the vocal ones! LOL
Bob Richards
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Pinnacle
Sent: Wednesday, May 16, 2007 6:44 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Top 10 software install gripes
I am not hard set on filling the track for filling sake. I do it because it
seems
orderly. Certainly a vendor should allocate 'stingy' because they are also not
providing the disk space but they should be considerate and use reasonable
numbers. We should not be guessing how many more directory
If they already fill 43 directory blocks, then using Tom's method they should
have upped to 90, not 45. I could live with that. If they fill 2 directory
blocks
then I do not want to see 90, 45 is still okay by me.
I think we're optimising the wrong thing!
At the cost of today's disk, why are
meanness in the allocation of data sets - including directory blocks.
Chris Mason
- Original Message -
From: Kenneth E Tomiak [EMAIL PROTECTED]
Newsgroups: bit.listserv.ibm-main
To: IBM-MAIN@BAMA.UA.EDU
Sent: Thursday, May 17, 2007 1:13 AM
Subject: Re: Top 10 software install gripes
I am
- Original Message
From: Thomas Conley [EMAIL PROTECTED]
#4 - Directory blocks should ALWAYS be a multiple of 45. That way I won't
get directory out of space the next time you expand your product.
I wasn't aware of this. Why should directory blocks for PDSes be multiple of 45
?
I
Why should directory blocks for PDSes be multiple of 45 ?
Thats not entirely accurate. A 3390 track holds 46 directory records,
but allocating only 45 allows the EOF for the directory to be placed on
the same track.
But for additional directory space, use multiples of 46, formula
(not
46), so wouldn't the formula be 44+(45*n) as was mentioned in a prior reply?
Peter
-Original Message-
From: Bruce Black [mailto:[EMAIL PROTECTED]
Sent: Monday, May 14, 2007 11:58 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Top 10 software install gripes
Why should directory blocks
Edward Jaffe wrote:
John Eells wrote:
Paul Gilmartin wrote:
snip
I.e. 32760. So I can equally well use BLKSIZE=0 for load module
libraries as for
other data sets. It matters little to me whether BLKSIZE gets set by
SDB or by
the binder.
snip
It gets set by the first program to open the
Bruce, I don't want to go up against you in a DASD knowledge battle (I know
I would lose), but my copy of IBM 3390 Direct Access Storage Reference
Summary, GX26-4577-2, August 1990, Table 2 (3390 mode), page 10, says that
255 to 288 byte blocks with keys of 1-22 bytes are max 45 to the track
Except this started as what should a software vendor be coding for blksize.
The vendor can not be sure every shop has someone like you writing acs
routines. I could see a SHARE presentation here. But then MVS SCP would not
be the right place for it. I'll bet you have some really good routines
Maybe the block of code in your ACS routine to handle this would make a neat
tip in the MVS SCP Newsletter.
On Sun, 13 May 2007 08:11:59 -0500, Kenneth E Tomiak
[EMAIL PROTECTED] wrote:
Except this started as what should a software vendor be coding for blksize.
The vendor can not be sure
When I try to read a PDS directory with LRECL(=BLKSIZE)=255, I *still* receive
an S001 abend.
Bob
Kenneth E Tomiak wrote:
Not to be confused with how many bytes per member. That varies, a loadlib
uses flags and I recall used the same number of bytes for every loadlib
member, a non-loadlib
Re: Ed Jaffe's SMS routine and the MVSSCP Newsletter.
Good thought, Ken! Ed, if you're willing to share the routine, send it on
to me.
Cheers,,,Steve
Steve Conway
Lead Systems Programmer
Information Systems Services Division
Computer Network Operations
Phone: (703) 450-3156
Fax:
On Sun, 13 May 2007 10:16:16 -0400, Bob Rutledge [EMAIL PROTECTED] wrote:
When I try to read a PDS directory with LRECL(=BLKSIZE)=255, I *still* receive
an S001 abend.
Kenneth E Tomiak wrote:
than using statistics. Early clist code that read the PDS directory directly,
allocated it with
--snip---
All I can tell you is that I tested this on an old 3380 circa 1994 with
MVS 4.2(? so long ago not sure anymore). Nothing other than the
directory was stored on the first track. I then tested on a RAMAC2, but
no problem creating a 1-track
--snip-
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
---snip--
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
Kenneth E Tomiak wrote:
Except this started as what should a software vendor be coding for blksize.
The vendor can not be sure every shop has someone like you writing acs
routines.
Huh? This started in a thread whose subject line is Top 10 Software Install
Gripes. *This* post is part
Paul Gilmartin wrote:
snip
I.e. 32760. So I can equally well use BLKSIZE=0 for load module libraries as
for
other data sets. It matters little to me whether BLKSIZE gets set by SDB or by
the binder.
snip
It gets set by the first program to open the data set. If that's
always the Binder,
John Eells wrote:
Paul Gilmartin wrote:
snip
I.e. 32760. So I can equally well use BLKSIZE=0 for load module
libraries as for
other data sets. It matters little to me whether BLKSIZE gets set by
SDB or by
the binder.
snip
It gets set by the first program to open the data set. If that's
Length halfword..
snipped from my prior reply to PDS directory track(s) used
..and here's the one and only directory block:
=== BLOCK# 1
(+) 0062 --- each used dir blk starts with halfword
offset-to-freespace or length in use in this block, either
interpretation works for me.
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
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
-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
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
There, I feel better.
What are you really trying to say?
You have to stop holding back and be more direct as to what you truly mean!
-
Too busy driving to stop for gas!
--
For IBM-MAIN subscribe / signoff / archive access
]sent:
Going through all this vendor software installs is really ticking me off (like
I
needed a reason). So here's the top 10 software install gripes:
#10 - Quit telling me to jam your ISPF product datasets into the LOGON proc
(s 20th century), gimme a Rexx exec with LIBDEF support (grab
Going through all this vendor software installs is really ticking me off (like
I
needed a reason). So here's the top 10 software install gripes:
#10 - Quit telling me to jam your ISPF product datasets into the LOGON proc
(s 20th century), gimme a Rexx exec with LIBDEF support (grab my
#1 - Change your stupid SYSDA default UNIT to SYSALLDA, PUHLEEEZZEEE!!!
I haven't been in a shop where SYSDA has worked for over a DECADE! Many
sites stopped defining SYSDA in favor of the system esoteric SYSALLDA, so
get with the program!
Interesting..
In my 28+ years of Mainframe
/SNIP
It's Friday, I know... And it's Mother's Day weekend. Did everyone get
an appropriate gift for their mother?
/END SNIP
Under penalty of death I did and the golf clubs are put away until next
week.
Thanks,
Fletch (
Dilbert - I ask for so little..and boy do I get it.
Personally, I thought SYSALLDA went out with MVT, but then I was never an MVS
sysprog.
SYSALLDA has been in every shop I've ever been in.
But, I still believe in SYSDA.
Of course, in an SMS environment it doesn't matter.
I have been using UNIT=DASD for the last 15 years.
If your SMS environment
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Ted MacNEIL
Sent: Friday, May 11, 2007 10:37 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Top 10 software install gripes
There, I feel better.
What are you really trying to say?
You have
.
Peter
-Original Message-
From: Tom Savor [mailto:[EMAIL PROTECTED]
Sent: Friday, May 11, 2007 12:29 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Top 10 software install gripes
#1 - Change your stupid SYSDA default UNIT to SYSALLDA, PUHLEEEZZEEE!!!
I haven't been in a shop where SYSDA has
Well, my son and I were just emailing back and forth asking what we could get
for mom. So I guess I-am/we-are behind the curve. :( I KNOW! A new workout
outfit! g, d r, vvf
Luckily, or not, I do not have any golf clubs to put away. However, I
hope-to/want-to/intend-to peddle my new bike
I, like Tom, use SYSALLDA. When working at lots of shops consulting,
it will always work. Even on P/390s that have 3380 format DASD.
One size fits all in this case.
On Fri, 11 May 2007 16:44:35 +, Ted MacNEIL [EMAIL PROTECTED] wrote:
Personally, I thought SYSALLDA went out with MVT, but
Even though my wife calls me a mother quite often, I'm still not getting
anything. And that counts for Father's Day also. g
On Fri, 11 May 2007 12:52:33 -0400, Fletcher, Kevin
[EMAIL PROTECTED] wrote:
/SNIP
It's Friday, I know... And it's Mother's Day weekend. Did everyone get
an appropriate
Besides, I don't think SYSALLDA is appropriate.
Why pray tell?
Opinion mostly.
But, I'm just afraid when there are holes in the ACS routines.
Yes, you can put your data wherever you want, but back-up/recovery, etc. is
more important.
If you want to use it as a placeholder, that's fine if
Indeed - these are ***problems*** - not merely issues!
Chris Mason
- Original Message -
From: Jeffrey D. Smith [EMAIL PROTECTED]
Newsgroups: bit.listserv.ibm-main
To: IBM-MAIN@BAMA.UA.EDU
Sent: Friday, May 11, 2007 6:39 PM
Subject: Re: Top 10 software install gripes
-Original
it.
-Original Message-
From: Fletcher, Kevin
Sent: Friday, May 11, 2007 12:53 PM
To: 'IBM Mainframe Discussion List'
Subject: RE: Top 10 software install gripes
/SNIP
It's Friday, I know... And it's Mother's Day weekend. Did everyone get
an appropriate gift for their mother?
/END SNIP
Under
You too??? I thought I was the only mail mother 'round these parts. g
On Fri May 11 12:19 , Matthew Stitt [EMAIL PROTECTED] sent:
Even though my wife calls me a mother quite often, I'm still not getting
anything. And that counts for Father's Day also.
On Fri, 11 May 2007 12:52:33 -0400,
Yes. And on Sunday, I'll probably try to get in line with the rest of the
women to get my carnation.
G, D, R
On Fri, 11 May 2007 13:39:07 -0400, Gary Green [EMAIL PROTECTED]
wrote:
You too??? I thought I was the only mail mother 'round these parts. g
On Fri May 11 12:19 , Matthew Stitt
, May 11, 2007 12:21 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Top 10 software install gripes
Going through all this vendor software installs is really ticking me off
(like I
needed a reason). So here's the top 10 software install gripes:
#10 - Quit telling me to jam your ISPF product datasets
On Fri, 11 May 2007 17:21:10 +, Ted MacNEIL [EMAIL PROTECTED]
wrote:
Besides, I don't think SYSALLDA is appropriate.
Why pray tell?
Opinion mostly.
But, I'm just afraid when there are holes in the ACS routines.
Yes, you can put your data wherever you want, but back-up/recovery, etc.
is
On Fri, 11 May 2007 14:09:54 -0500, Tom Marchant [EMAIL PROTECTED]
wrote:
System software does not belong on SMS managed volumes.
You forgot to add IMO prior to that statement.
While I personally don't prefer it, there is nothing wrong with SMS controlling
all you can - and I have been at
System software does not belong on SMS managed volumes.
I disagree with that one!
There's more to SMS than just determining where to put data.
There's back-up, for example.
Set up your system software with GUARANTEED SPACE, and a management class that
never migrates/scratches, but does back
On Fri, 11 May 2007 11:21:13 -0500, Thomas Conley wrote:
#4 - Directory blocks should ALWAYS be a multiple of 45. That way I won't
get directory out of space the next time you expand your product.
ITYM because a 3390 track will hold 45 directory blocks. That might or moght
not mean that you
Farley, Peter x23353 wrote:
Me three. SYSDA works here all the time, and at least at one small service
bureau I am aware of, and last but not least at a very large telecom firm
with giant IBM hardware installations all over the place.
Personally, I thought SYSALLDA went out with MVT, but then
Tom Marchant wrote:
On Fri, 11 May 2007 11:21:13 -0500, Thomas Conley wrote:
#4 - Directory blocks should ALWAYS be a multiple of 45. That way I won't
get directory out of space the next time you expand your product.
ITYM because a 3390 track will hold 45 directory blocks. That might or
On Fri, 11 May 2007 14:16:26 -0500, Mark Zelden wrote:
On Fri, 11 May 2007 14:09:54 -0500, Tom Marchant m42tom-
[EMAIL PROTECTED]
wrote:
System software does not belong on SMS managed volumes.
You forgot to add IMO prior to that statement.
Yes, you're right. Thanks for the correction.
While
On Fri, 11 May 2007 21:57:08 +0200, R.S. wrote:
IMHO 46 blocks would fit in single track. However I still don't get why
it's important at all. Can you enlight me ?
I'm not sure how many PDS directory blocks will fit on a track, but I don't see
why it's important either. IIRC, the remainder of
In an SMS environment, you have to use different DSNAMEs for each target zone,
rather than go by VOLUME.
And, this is a problem, why?
-
Too busy driving to stop for gas!
--
For IBM-MAIN subscribe / signoff / archive access
At 14:17 -0500 on 05/11/2007, Tom Marchant wrote about Re: Top 10
software install gripes:
On Fri, 11 May 2007 11:21:13 -0500, Thomas Conley wrote:
#4 - Directory blocks should ALWAYS be a multiple of 45. That way I won't
get directory out of space the next time you expand your product
Make that PDS a PDSE
I was waiting for that one to come up!
Not in my lifetime, except where absolutely required.
They are still wayy too flakey!
-
Too busy driving to stop for gas!
--
For IBM-MAIN subscribe /
According to prior discussions on this list, 44 blocks is optimal for the
last track of the directory. 45 blocks will fit on a 3390 track, with the
directory EOF block still needing to be taken into account. If you use 45
blocks, then your directory will take 2 tracks due to the EOF entry. So I
sure now.
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]
Behalf Of Tom Marchant
Sent: 11 May 2007 21:20
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Top 10 software install gripes
On Fri, 11 May 2007 21:57:08 +0200, R.S. wrote:
IMHO 46 blocks would fit in single
On Fri, 11 May 2007 21:11:54 +, Ted MacNEIL wrote:
Make that PDS a PDSE
I was waiting for that one to come up!
Not in my lifetime, except where absolutely required.
They are still wayy too flakey!
Really? I use them every day. Have been for years.
--
Tom Marchant
On Fri, 11 May 2007 20:31:56 +, Ted MacNEIL [EMAIL PROTECTED] wrote:
In an SMS environment, you have to use different DSNAMEs for each target
zone, rather than go by VOLUME.
And, this is a problem, why?
I didn't say it was a problem. It's just a difference. There are
advantages and
On Sat, 12 May 2007 00:20:41 +0100, Tony wrote:
Think of where CKD devices came from. Search for a record on a disk that
had a record key equal to or greater than the one you are looking for. In
this case the key is the member name. Hardware feature, promoted heavily and
used by JES and DB2 (got
That doesn't explain why you'd want the directory to be allocated in full
tracks, though.
IIRC, I was taught that the entire track was formatted as directory blocks, but
you could only allocate/access the ones you asked for in JCL.
Regardless of how many you specified, the first member starts
On Fri, 11 May 2007 23:54:34 +, Ted MacNEIL [EMAIL PROTECTED] wrote:
That doesn't explain why you'd want the directory to be allocated in full
tracks, though.
IIRC, I was taught that the entire track was formatted as directory blocks,
but you could only allocate/access the ones you asked for
]
Behalf Of Tom Marchant
Sent: 12 May 2007 00:47
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Top 10 software install gripes
On Sat, 12 May 2007 00:20:41 +0100, Tony wrote:
Think of where CKD devices came from. Search for a record on a disk that
had a record key equal to or greater than the one you
On Sat, 12 May 2007 01:34:38 +0100, Tony [EMAIL PROTECTED] wrote:
I don't know the answer. It may be in a Redbook.
I doubt it. I've never seen any reccomendation that directories be
allocated so that they will fill up tracks.
I would think that the
starting point for any disk search is a
I thought that long ago when the old 3380 3390 dasd was current, that
allocating the PDS directory on either a track or cylinder boundary had some
advantages. At least that's what I remember.
Eric Bielefeld
On Sat, 12 May 2007 01:34:38 +0100, Tony [EMAIL PROTECTED] wrote:
I don't know
- Original Message -
From: Tom Marchant [EMAIL PROTECTED]
Newsgroups: bit.listserv.ibm-main
Sent: Friday, May 11, 2007 7:58 PM
Subject: Re: Top 10 software install gripes
On Fri, 11 May 2007 23:54:34 +, Ted MacNEIL [EMAIL PROTECTED]
wrote:
That doesn't explain why you'd want
- Original Message -
From: Imbriale, Donald [EMAIL PROTECTED]
Newsgroups: bit.listserv.ibm-main
Sent: Friday, May 11, 2007 2:21 PM
Subject: RE: Top 10 software install gripes
Regarding #10:
When using LIBDEF, be sure to include STACK.
If using ALTLIB, during cleanup, don't issue
92 matches
Mail list logo
