On Mon, 30 Apr 2012 13:20:48 -0700, Charles Mills wrote:
>
>At least too many OPEN's is better than too many DYNALLOC's *and* too many
>OPEN's.
>
Ummm. No. A few years ago, I had an APAR created because
the z/OS UNIX (USS) command e.g.:
$ cp -P'SPACE=(5000,5000)' homelog //temp.test.space3
cp: FSUM6260 write error on file "//temp.test.space3": EDC5092I An I/O
abend was trapped.
$ ls -l homelog
-rw-r--r-- 1 user group 346153 Jan 12 14:05 homelog
was failing with a Sx37, regardless of how large an extent I requested.
IBM's explanation:
o If the programmer specified SPACE, the C/LE RTL assumed a RLSE
subparameter.
(This seems precisely backward to me. If the RTL supplies a generous
default, RLSE may be appropriate. If the programmer specified SPACE
explicitly, give him what he asks for.)
o The command internally caused the data set to be opened and closed
_four_ times (!?!?!?!). After the first close, most of the space was
released. The attempt to write the actual data was bound to fail
writing to a minimal extent.
IBM's reactions were:
o Specify a secondary extent.
o FIN.
o For compatibility, we'll retain the current behavior, but provide
the programmer a NORLSE option.
The problem persists at z/OS 1.12:
D37-04,IFG0554P,user,STEP1,SYS00017,41CA,TSO026,user.TEMP.TEST.SPACE3
There seems to be no NORLSE option. If I supply a secondary
extent, I get an 8 block (1 track?) primary extent and a 4008 block
second extent.
<SIGH/> I can't respect this. Does any IBM representative dare to
comment on it?
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
