Would be neat, but I can't figure out how to have an application write to the UNIX syslogd daemon simply by using a DD and the UNIX file via QSAM interface. Hum, I guess it might be possible to use the GPSAM routines on the CBTTape to do this.
On Fri, Feb 8, 2013 at 7:53 AM, Kirk Wolf <[email protected]> wrote: > 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 > -- 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
