On Sat, 29 Oct 2016 19:37:05 -0500, Paul Gilmartin <[email protected]> wrote:
>In: > z/OS 2.2.0 > z/OS MVS > z/OS MVS Program Management: User's Guide and Reference > Starting the binder > Invoking the binder with JCL > DD statements > Binder DD statements > SYSPRINT and SYSLOUT DD statements > >I read: > SYSPRINT or SYSLOUT can also be assigned to a z/OS UNIX file. In this case, > FILEDATA=TEXT must also be specified. > >(Similar statement about SYSTERM in a different section.) Some readers >will not be surprised that when I read such a rule, I put on my Black Team >cape and investigate what happens when I break it. So: > >If SYSPRINT FILEDATA is BINARY or RECORD, Binder writes the file content >as if TEXT had been specified, then leaves the file tagged as the value >specified in the JCL, pretty unusable, and exits with RC=0. > >What should I say in my SR? I'm disinclined to accept "You broke the rules; >RTFM; WAD," as an answer. How would Pubs feel about documenting the >behavior, including the RC=0? I would be inclined to say that you just demonstrated why you _must_ specify FILEDATA=TEXT, and I would say that the book was right. True, it didn't say what would fail, or how it would fail, without that specification. But you didn't specify it, and you got something unusable, proving that the specification is necessary. There are probably a lot of failure scenarios where IBM (and other vendors) do not document exactly how things will break if you don't follow the rules. Of course, I wouldn't object if they improved that doc by saying "... must also be specified or you won't like the results." :) -- Walt ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
