I do believe that I should be able to point DFSORT at any file (Unix or not) where performing the functions of DFSORT make sense, and not be required to specify in JCL the physical attributes of LRECL, RECFM and most especially BLKSIZE. These should all be derivable from the physical dataset at open time. This should not be extended to think I am saying that these JCL statements should be disallowed as overrides for some reason or other.
And, DDFSORT (or other utilities) should be able to detect (and coherently report) when they are asked to perform functions against data that is not in a useable or logical format for the function requested. > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Paul Gilmartin > Sent: Tuesday, January 16, 2018 3:23 PM > To: [email protected] > Subject: Re: DFSORT for HTTP logs - RECFM and BLKSiZE? > > On Tue, 16 Jan 2018 21:48:14 +0000, Gibney, Dave wrote: > > >It may not be the case that it just works, but it should. > > > >No matter where the dataset was created, it must exist in a way that is > accessible on z/OS, or they wouldn't be trying to process it via DFSORT. > > > >And, by existing, all required attributes to successfully process it should > >be > derivable by the access method at open. JCL should only need to specify > DSN, Locations (if not cataloged) and DISP. > > > Do you believe that's true for a UNIX file? I don't. The OP said, "my HTTP > logs > (httpd-log.MMMddYYYY)." That sounds like a UNIX pathname. > > >I'm sounding like Gil :) > > > Except that we disagree on this matter of attributes. > > -- gil > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
