Also consider syslogd, especially for logging of "system" functions. This allows you to categorize, filter, and direct logs to unix files that are automatically archived to z/OS datasets. More info can be found in the Comm Server doc.
Kirk Wolf Dovetailed Technologies http://dovetail.com On Wed, Feb 6, 2013 at 1:56 PM, John McKown <[email protected]>wrote: > This is just my opinion. Others may, and likely will, disagree. But just > today, I came up with a reason to "log" to a UNIX file instead of a SYSOUT > or z/OS sequential data set, and especially the latter. > > There are many pluses of SYSOUT or UNIX over a sequential data set. First, > you don't need to specify a SPACE= parameter. Second, unless you use an > existing sequential data set and use DISP=SHR, you can't see the output as > it is being generated. With SYSOUT, you can view it via SDSF. With a UNIX > file, you can use ISPF browse or perhaps even the "tail" command on a UNIX > shell session. The "tail" is nice because you can get to the bottom rather > quickly. > > One major plus of a UNIX file over SYSOUT is if you have multiple "log" DDs > in the same step and you'd like the output to be interspersed. This > occurred to me because CA-Endevor enables multiple different traces by > using multiple different DD names. Suppose you'd like a consolidated log in > which each line was in close proximity to the other trace lines generated > around the same time. I cannot think of a way to do this with either SYSOUT > or a sequential data set. Perhaps I'm missing something. > > But for the above, in UNIX, you can easily do: > > // SET LOGFILE='/tmp/&SYSUID..this.trace' > //* OTHER JCL > //* TRACE DDS > //EN$TRALC DD PATH='&LOGFILE', > // PATHOPTS=(OWRONLY,OAPPEND,OCREAT), > // PATHDISP=(KEEP,KEEP) > // RECFM=FA,LRECL=133,BLKSIZE=133 > //* > //EN$TRITE DD PATH='&LOGFILE', > // PATHOPTS=(OWRONLY,OAPPEND,OCREAT), > // PATHDISP=(KEEP,KEEP) > // RECFM=FA,LRECL=133,BLKSIZE=133 > //* > //* AND SO ON. > //* > > Because I specified "unblocked" output, each line is written to the file > immediately (OK, put in > the UNIX kernel's buffer for the file). The OAPPEND on each means that > every write operation is > prefixed with a "go to the end of the file" type operation. Since the > buffering for a given specific UNIX file is kept in a single file buffer in > the kernel, this means that the lines should be written to the in pretty > much time sequenced order. > > Hope this is at least of some interest. > > -- > This is a test of the Emergency Broadcast System. If this had been an > actual emergency, do you really think we'd stick around to tell you? > > Maranatha! <>< > John McKown > > ---------------------------------------------------------------------- > 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
