On Tue, 4 Feb 2014 09:52:24 -0500, Shmuel Metz (Seymour J.) wrote:
> on 02/04/2014 at 07:37 AM, Paul Gilmartin said:
>
>>Is the UCB address nonzero for zFS files?
>
>The UCB address in the TIOT entry is zero for anything not allocated
>to a device; that includes not only Unix files but also subsytem files
>and TSO terminals. Back in the day it also included TCAM. There are
>flag bits in, e.g., TIOELINK, to determine who did what to whom.
>
With my novice knowledge, I would have expected that, but David
said:
On 2014-02-04, at 06:44, Jousma, David wrote:
>No, we have users sorting data with path names as input. Just ran a test. ...
//DFSORT EXEC PGM=SORT
//SORTIN DD PATHDISP=KEEP,
// PATHOPTS=ORDONLY,
// FILEDATA=TEXT,
// RECFM=VB,LRECL=255,BLKSIZE=25496,
// PATH='/etc/httpd1443.conf'
> ...
And earlier:
On 2014-01-30, at 13:18, Jousma, David wrote:
>We have an exit for DFSORT that scans TIOT to see if someone concatenated a
>DUMMY
>dataset as input. Here is what I believe to be the relevant snippet of code:
> ...
>* NOTE: COULD ALSO BE DD *
>DDCHK CLC TIOEFSRT,=AL3(0) Q. REAL UCB ADDRESS ?
> BE DDBAD A. NO, BAD DD
> ...
OK, I'm naive about data areas. Elsewhere, I find:
http://pic.dhe.ibm.com/infocenter/zos/v1r13/index.jsp?topic=%2Fcom.ibm.zos.r13.idac700%2Fc7247.htm
The file validation exit will receive a UCB address from TEPMUCB in IFGTEP,
from DEBUCBA
and from TIOEFSRT. All three sources will allow a 31–bit UCB address but
TIOEFSRT will
contain zero if the actual UCB is above the line and allocation did not
capture the UCB address. ...
Why might David's test exclude SYSIN as an apparent DUMMY, but accept
PATH=? How much is he at risk of someone's using a UCB above the line
in SORTIN "and allocation'[s] not captur[ing] the UCB address"?
And why not rely on DSN=NULLFILE?
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
