On 05/25/2013 09:23 PM, Robert A. Rosenberg wrote:
At 09:28 -0700 on 05/25/2013, Charles Mills wrote about Re: Really? No
FTP SITE RLSE?:
For allocating sequential data sets this is the maximum amount of space
that is allocated for the primary extent. If a smaller amount of
space is
needed to hold the data being transferred, only the amount actually
needed to hold the data is allocated.
2. What you quoted is very plausible. The quote above does not sound
technically accurate. How would the FTP server "know" the "actually
needed" amount of space to allocate?
The quote can be read two ways.
Way 1 is that the amount you ask for is allocated, the transfer is
done, and then the file allocation is truncated/space is released.
This results in only the needed space remaining allocated.
Way 2 is that your requested space is overridden by the computed
needed space and only that amount is allocated. That is then used to
accept the transfer. To do this the amount of space used for the
source is used to tell how much space to allocate for the target. That
takes into account the LRECL/BLKSIZE of both files as well as the
DEVTYPEs of the devices and the size of the source file.
I think Way 1 is simpler although it can introduce fragmentation of
the target device due to the returned extents. IOW, you ask for 10 cyl
(you get cyl 1000-1009) but use only 1 cyl returning 9 cyl (Cyl
1001-1009). Unless Cyl 1010 is free, the next 10 cylinder request can
not be serviced with cyl 1001-1009 thus leading to fragmentation
(assuming the a primary request is serviced by contiguous space not a
group of extents).
...
But knowing that way (2) is technically incorrect and (1) is closer to
reality, the manual is extremely imprecise and misleading in that it
implies; by use of "maximum" that an initial allocation less the
"PRIMARY" is possible rather than this being the exact amount
"allocated" initially; instead of referring to "primary space" it
incorrectly refers to a "primary extent" (primary space may be allocated
in multiple "extents" - the first extent is just a "first extent" not a
"primary" one); shows no understanding that allocated extents and the
extents left after the data set is closed may not be identical, and
completely ignores here (and in the description of the SECONDARY
parameter) the [somewhat peculiar] manner in which PRIMARY and SECONDARY
parameters interact to determine maximum total allocated space and
number of extents.
All in all, these particular parameter descriptions in the IP Reference
have all the mark of being written by someone familiar with IP and UNIX,
but having at best marginal understanding of z/OS data set and DASD
principles. These distinctions are important in understanding, for
example, why it would be bad as a "handle anything" default to request a
PRIMARY of 3000 cylinders on a system that doesn't have 3000 free
cylinders on any available volume and expect success for storing a 1
track file. When you also start throwing in possible interactions with
explicit or implied installation ACS and DATACLAS parameters, terse
explanations are impossible. The IP manual would be better off at some
point to just say "any explanation given here is a simplification", how
the FTP allocation parameters relate to JCL allocation parameters, and
that after taking that correspondence into consideration standard z/OS
data set allocation and extension rules apply.
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
