FTPD1

[Finch, Steve]

In your OE log (HFS file)

Browse /etc/syslog.conf to find the location of your log file

It's pretty trivial, unless you are using FTPLOGGING

Steve
EDS
-----Original Message-----
From: IBM TCP/IP List [mailto:IBMTCP-***@VM.MARIST.EDU] On Behalf Of
Ronald Wells
Sent: Thursday, September 15, 2005 2:40 PM
To: IBMTCP-***@VM.MARIST.EDU
Subject: Re: FTPD1

Where should syslog output be located when someone does an FTP ?? gather
it
is in HFS file somewhere..but where?

----------------------------------------------------------------------
Email Disclaimer
This E-mail contains confidential information belonging to the
sender, which may be legally privileged information. This information
is intended only for the use of the individual or entity addressed
above. If you are not the intended recipient, or an employee or
agent responsible for delivering it to the intended recipient, you are
hereby notified that any disclosure, copying, distribution, or the
taking of any action in reliance on the contents of the E-mail or
attached files is strictly prohibited.

----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO IBMTCP-L

----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO IBMTCP-L

[McKown, John]

Post by Finch, Steve
-----Original Message-----
Behalf Of Ronald Wells
Sent: Thursday, September 15, 2005 1:40 PM
Subject: Re: FTPD1
Where should syslog output be located when someone does an
FTP ?? gather it
is in HFS file somewhere..but where?

Wherever you tell it to put it. FTP does not actually write directly to
a file. It sends "syslog" messages to the syslog daemon. Note that this
is not the same thing as the z/OS SYSLOG that we are all familar with.
So, first, you must have the syslog daemon running. I do this with a
line in /etc/rc like:

_BPX_JOBNAME='SYSLOGD' /usr/sbin/syslogd -c -u &

This starts up the daemon when OMVS is started at IPL time. This daemon
generally gets its control cards from /etc/syslog.conf. Mine looks like:

kern.* /var/log/kern.%Y-%m-%d
user.* /var/log/user.%Y-%m-%d
mail.* /var/log/mail.%Y-%m-%d
news.* /var/log/news.%Y-%m-%d
uucp.* /var/log/uucp.%Y-%m-%d
daemon.* /var/log/daemon.%Y-%m-%d
auth.* /var/log/auth.%Y-%m-%d
cron.* /var/log/cron.%Y-%m-%d
local0.* /var/log/local0.%Y-%m-%d
local1.* /var/log/local1.%Y-%m-%d
local2.* /var/log/local2.%Y-%m-%d
local3.* /var/log/local3.%Y-%m-%d
local4.* /var/log/local4.%Y-%m-%d
local5.* /var/log/local5.%Y-%m-%d
local6.* /var/log/local6.%Y-%m-%d
local7.* /var/log/local7.%Y-%m-%d

FTP puts its information out to the daemon entry. And with the above
lines, my files look like:

/var/log/daemon.2005-09-15

In which there are lines like:

Sep 15 05:57:15 LIH1/BPXROOT ,FTPD2, ftpd[50331853]: EZYFS50I
ID=FTPD100054 CONN starts Client IPaddr=10.170.9.64 hostname=UNKNOWN
Sep 15 05:57:15 LIH1/BPXROOT FTPD2 ftps[50331853]: RA0715 pass: use
__passwd() to verify the user
Sep 15 05:57:15 LIH1/FTH001 FTPD2 ftps[50331853]: EZYFS56I
ID=FTPD100054 ACCESS OK USERID=FTH001
Sep 15 05:57:15 LIH1/FTH001 FTH001 ftps[50331853]: EZYFS60I
ID=FTPD100054 ALLOC OK Use MVS DSN=FTHMN.MAGI200D.FILE
Sep 15 05:57:15 LIH1/FTH001 FTH001 ftps[50331853]: EZYFS61I
ID=FTPD100054 ALLOC DDNAME=SYS00001 VOLSER=FT0006 DSORG=PS
DISP=(OLD,KEEP)
Sep 15 05:57:15 LIH1/FTH001 FTH001 ftps[50331853]: EZYFS70I
ID=FTPD100054 DEALL OK Release MVS DSN=FTHMN.MAGI200D.FILE
Sep 15 05:57:15 LIH1/FTH001 FTH001 ftps[50331853]: EZYFS81I
ID=FTPD100054 TRANS MVS DSN=FTHMN.MAGI200D.FILE
Sep 15 05:57:15 LIH1/FTH001 FTH001 ftps[50331853]: EZYFS83I
ID=FTPD100054 TRANS Stru=F Mode=S Type=A Input=623 bytes
Sep 15 05:57:15 LIH1/FTH001 FTH001 ftps[50331853]: EZYFS80I
ID=FTPD100054 TRANS Reply=250 Transfer completed successfully.
Sep 15 05:57:15 LIH1/FTH001 FTH001 ftps[50331853]: EZYFS60I
ID=FTPD100054 ALLOC OK Use MVS DSN=FTHPN.PAGI200D.FILE
Sep 15 05:57:15 LIH1/FTH001 FTH001 ftps[50331853]: EZYFS61I
ID=FTPD100054 ALLOC DDNAME=SYS00002 VOLSER=FT0009 DSORG=PS
DISP=(OLD,KEEP)
Sep 15 05:57:15 LIH1/FTH001 FTH001 ftps[50331853]: EZYFS70I
ID=FTPD100054 DEALL OK Release MVS DSN=FTHPN.PAGI200D.FILE
Sep 15 05:57:15 LIH1/FTH001 FTH001 ftps[50331853]: EZYFS81I
ID=FTPD100054 TRANS MVS DSN=FTHPN.PAGI200D.FILE
Sep 15 05:57:15 LIH1/FTH001 FTH001 ftps[50331853]: EZYFS83I
ID=FTPD100054 TRANS Stru=F Mode=S Type=A Input=623 bytes
Sep 15 05:57:15 LIH1/FTH001 FTH001 ftps[50331853]: EZYFS80I
ID=FTPD100054 TRANS Reply=250 Transfer completed successfully.
Sep 15 05:57:15 LIH1/FTH001 FTH001 ftps[50331853]: EZYFS52I
ID=FTPD100054 CONN ends Input=1246 bytes Output=0 bytes

Also, if you tell the server to, it will generate SMF records. Either
type 118 or 119 or both.


--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its'
content is protected by law. If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.

----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO IBMTCP-L

[andrew mcintyre]

Post by McKown, John
Wherever you tell it to put it. FTP does not actually write directly to
a file. It sends "syslog" messages to the syslog daemon. Note that this
is not the same thing as the z/OS SYSLOG that we are all familar with.
So, first, you must have the syslog daemon running.

And instead of just having the plain vanilla OMVS syslog daemon running and
not having much functionality with it, wouldn't it be nice if you could
automate any message flowing to syslogd? Do something like page somebody? Run
a REXX? Shutdown a server? Startup a server? Send a message to a central LPAR?
REXEC to a UNIX box and run a command? SSH to a UNIX box and run a command?

Drum roll.... You can!! Instead of starting OMVS syslogd, start the one in
NetView for z/OS. Then you can have an automated response to any message that
flows to the NetView syslogd. Just use the NetView Automation Table to trap
any message or event that flows and take whatever action you want to take.

You could actually automate an entire room of UNIX severs sending their
messages to a single NetView for z/OS.

Feel free to contact me if anyone wants any further info on this.

========================================================
Andrew McIntyre - Senior I/T Specialist - certified
zSeries Software Technical Sales
SMPO (Software Migration Project Office)
TMT (Tivoli Migration Team)
404-487-2477 or tie 546-2477
***@us.ibm.com
========================================================
SMPO
http://www.ibm.com/software/solutions/softwaremigration
NetView for z/OS
http://www.ibm.com/tivoli/products/netview-zos/resources/nv390-update.html
System Automation for z/OS
http://www.s390.ibm.com/sa
========================================================

----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO IBMTCP-L

[McKown, John]

Post by Finch, Steve
-----Original Message-----
Behalf Of andrew mcintyre
Sent: Thursday, September 15, 2005 2:12 PM
Subject: Re: FTPD1

<snip>

Post by Finch, Steve
And instead of just having the plain vanilla OMVS syslog
daemon running and
not having much functionality with it, wouldn't it be nice if
you could
automate any message flowing to syslogd? Do something like
page somebody? Run
a REXX? Shutdown a server? Startup a server? Send a message
to a central LPAR?
REXEC to a UNIX box and run a command? SSH to a UNIX box and
run a command?
Drum roll.... You can!! Instead of starting OMVS syslogd,
start the one in
NetView for z/OS. Then you can have an automated response to
any message that
flows to the NetView syslogd. Just use the NetView Automation
Table to trap
any message or event that flows and take whatever action you
want to take.
You could actually automate an entire room of UNIX severs
sending their
messages to a single NetView for z/OS.
Feel free to contact me if anyone wants any further info on this.

Nice functionality. Assuming you have/are licensed for NetView. We
don't/aren't.

--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its'
content is protected by law. If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.

----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO IBMTCP-L

[McKown, John]

Post by Finch, Steve
-----Original Message-----
Behalf Of Ronald Wells
Sent: Thursday, September 15, 2005 2:39 PM
Subject: Re: FTPD1
so John
you running SYSLOGD---satrted task setup??

Yes, I am running SYSLOGD. It is a "started task", but, as I said, I
start it via the /etc/rc file and not with a START SYSLOGD type command.
If you want to do it that way, the manual give the following JCL:

//SYSLOGD PROC
//SYSLOGD EXEC PGM=SYSLOGD,REGION=30M,TIME=NOLIMIT,
// PARM='POSIX(ON),ALL31(ON)/ -f /etc/syslogd.conf'
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSOUT DD SYSOUT=*
//SYSERR DD SYSOUT=*
//CEEDUMP DD SYSOUT=*

You need to make sure that this runs as your SUPERUSER as defined in the
BPXPRMnn member of PARMLIB. You can do this using RACF:

RDEF STARTED SYSLOGD.* UACC(NONE) +
STDATA(USER(........) GROUP(........) TRUSTED(YES) TRACE(YES))
SETROPTS RACLIST(STARTED) REFRESH

Replace the dots with the appropriate RACF user and group in the STDATA
segment.

Reference:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/BPXZB251/17.7

--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its'
content is protected by law. If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.

----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO IBMTCP-L

[McKown, John]

Post by Finch, Steve
-----Original Message-----
Behalf Of Ronald Wells
Sent: Thursday, September 15, 2005 3:41 PM
Subject: Re: FTPD1
John---see that and think that part is ok so far...
the syslog parm list...getting confused ... many many
options..lol...to
record....
guess I'm just use to mvs syslog....getting everything ....
gather next question is option..best fit...
plus I gather I need something to switch these log(s) like I
do my SMF when
full or on a daily basis..?

Ah, yes. I forgot about that. With the example /etc/syslog.conf that I
posted, you should "rotate" the logs just a wee tad after midnight. I
use the cron daemon for that. However, you can use anything which can do
a UNIX "kill" command. If you prefer to use a z/OS started task, just
run, say as LOGROTAT (or in a batch job):

//STEP1 EXEC PGM=BPXBATCH,
// PARM='SH kill -HUP $(cat /etc/syslog.pid)'
//STDOUT DD PATH='/dev/console',
// FILEDATA=TEXT,
// PATHOPTS=(OCREAT,OAPPEND,OWRONLY)
//STDERR DD PATH='/dev/console',
// FILEDATA=TEXT,
// PATHOPTS=(OCREAT,OAPPEND,OWRONLY)
//STDIN DD PATH='/dev/null',
// FILEDATA=TEXT,
// PATHOPTS=(ORDONLY)

Watch out for that lower case! It is very important. You must run the
above with a userid with a UID of zero, just like you did with the
SYSLOGD started task.

If I were to use the above method, I would use a started task that is
triggered by a CA-OPS/MVS TOD rule at 1 second after midnight.

Other considerations:

1) make sure that the filesystem (HFS file) that contains /var/log has
enough space. You don't really want to run out. If you do run out, you
will definately loose information. It is even theoritically possible, if
you fill up the "root" filesystem, that other UNIX work will suffer
degradation or even fail. I strongly recommend that /var/log be in its
own HFS file which is mounted at IPL time via the BPXPRMxx member of
PARMLIB.

2) You'll want to delete these logs after some period of time. You can
either just delete them, as I do, or copy them, then delete them. I have
another cron job with cleans up /var/log. I have it set up to run at 1
a.m. it does the command:

rm $(find /var/log -mtime +3)

This finds all the files in the /var/log subdirectory which were last
modified 3 days ago or longer and removes them. Again, you can use a
z/OS started task (again with the appropriate RACF userid) like:

//STEP1 EXEC PGM=BPXBATCH,
// PARM='SH rm $(find /var/log -mtime +3)'
//STDOUT DD PATH='/dev/console',
// FILEDATA=TEXT,
// PATHOPTS=(OCREAT,OAPPEND,OWRONLY)
//STDERR DD PATH='/dev/console',
// FILEDATA=TEXT,
// PATHOPTS=(OCREAT,OAPPEND,OWRONLY)
//STDIN DD PATH='/dev/null',
// FILEDATA=TEXT,
// PATHOPTS=(ORDONLY)

--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its'
content is protected by law. If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.

----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO IBMTCP-L

[McKown, John]

Post by Finch, Steve
-----Original Message-----
Behalf Of Ronald Wells
Sent: Thursday, September 15, 2005 4:12 PM
Subject: Re: FTPD1
got it recording...neat....
_ File 600 2005-09-15 17:03 STC1 1447 ivp.syslog.log
did a FTP and it logged what I wanted---hopefully....
below is SYSLOG member for the SYSLOGD proc...
any suggestion??
plus>> what is LOGROTAT ... did not see that mentioned any where...??
#
*.* /tmp/ivp.syslog.log
#
Just used default example........

LOGROTAT is my made up name for the STC. On Linux, there is a supplied
function called "logrotate" which does what I was talking about (and
much more). But LOGROTATE is too long a name, so I shortened it. It is
just the concept of whatever it is which does the "kill -HUP" command to
cause SYSLOGD to restart its logging, which, with the previously posted
example syslog.conf, will cause SYSLOGD to change the name of the file
to which it is writing.

Now, with the above example, there is absolutely NO reason to "rotate"
the logs because SYSLOGD will just start writing to the exact same file.
But, with that example, the file will grow without limit until it fills
up the filesystem which contains /tmp/. This is not a good idea! I did
that once by mistake. Things got dicey with UNIX work until I fixed it.
Having said that, there are ways to make that work "correctly", but I
consider them to be a bit more difficult than my way (having SYSLOGD put
the date in the log file and refreshing SYSLOGD each morning around
midnight).

--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its'
content is protected by law. If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.

----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO IBMTCP-L

[Schlehuber, Patrick]

Has anyone had any luck porting logrotate over to USS? This is a darn slick utility shipped with most Linux distros.




-----Original Message-----
From: IBM TCP/IP List [mailto:IBMTCP-***@VM.MARIST.EDU]On Behalf Of
McKown, John
Sent: Thursday, September 15, 2005 4:19 PM
To: IBMTCP-***@VM.MARIST.EDU
Subject: Re: FTPD1

Post by Finch, Steve
-----Original Message-----
Behalf Of Ronald Wells
Sent: Thursday, September 15, 2005 4:12 PM
Subject: Re: FTPD1
got it recording...neat....
_ File 600 2005-09-15 17:03 STC1 1447 ivp.syslog.log
did a FTP and it logged what I wanted---hopefully....
below is SYSLOG member for the SYSLOGD proc...
any suggestion??
plus>> what is LOGROTAT ... did not see that mentioned any where...??
#
*.* /tmp/ivp.syslog.log
#
Just used default example........

LOGROTAT is my made up name for the STC. On Linux, there is a supplied
function called "logrotate" which does what I was talking about (and
much more). But LOGROTATE is too long a name, so I shortened it. It is
just the concept of whatever it is which does the "kill -HUP" command to
cause SYSLOGD to restart its logging, which, with the previously posted
example syslog.conf, will cause SYSLOGD to change the name of the file
to which it is writing.

Now, with the above example, there is absolutely NO reason to "rotate"
the logs because SYSLOGD will just start writing to the exact same file.
But, with that example, the file will grow without limit until it fills
up the filesystem which contains /tmp/. This is not a good idea! I did
that once by mistake. Things got dicey with UNIX work until I fixed it.
Having said that, there are ways to make that work "correctly", but I
consider them to be a bit more difficult than my way (having SYSLOGD put
the date in the log file and refreshing SYSLOGD each morning around
midnight).

--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its'
content is protected by law. If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.

----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO IBMTCP-L

----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO IBMTCP-L

[McKown, John]

Post by Finch, Steve
-----Original Message-----
Behalf Of Ronald Wells
Sent: Thursday, September 15, 2005 4:44 PM
Subject: Re: FTPD1
do I need to adjust the syslog member to log other
tasks...from what I see
I have to specify which to log?? guess it defaults to FTP
only?? ... just
reading comments in member and looks like if I do not specify

link SMTP

it does not log anything for it either...?

There is a good section on how to setup the z/OS supplied SYSLOGD which
starts at:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B341/1.5.
1

Basically, you tell SYSLOGD when to put log data that is sent to it from
another source, such as the ftp daemon. The "other source" sends
information to the syslog daemon either via a UNIX stream (source is
"local") or a IP UDP packet (source is "local" or "remote").

SYSLOGD only logs what another source sends to it. It is up to the
person who wrote the "source" facility to send the information that the
source facility wants logged to SYSLOGD. So, if you are hoping that
something is logged by, say, SMTP, then you need to do two things.
First, set up SMTP (or whatever) so that it sends logging requests to
SYSLOGD. How to do this, and if it is possible, should be in the
documentation for the other source facility. Second, you must set up
SYSLOGD so that it knows what to do with the data sent to it.

IOW, the "source facility" set up to send information to SYSLOGD and
SYSLOGD must be set up with a rule in syslogd.conf telling it what to do
with the information which is sent to it.

--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its'
content is protected by law. If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.

----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO IBMTCP-L

[O'keefe, Patrick]

Here's Andrew's ofline respinse to my offline "posting".

This is one of those NetView functions that sounds a lot better on

paper

than in practice. It would make a lot of sense if the primary purpose
logging messages is to drive automation, but the primary purpose is

usually

to log messages. Those people used to looking in the HFS log archives

would

kill the person that moved sysld to NetView.

===I disagree. The primary purpose of it being available in NetView is
for automation. I also doubt very many people browse thru a single large
HFS file that has merged messages from all over every UNIX box and
process around. And if you showed them BLOG under NetView, they would
probably thank you.

Now, if the OMVS syslogd had a hook that would route messages to

NetView,

THAT would be a useful feature ... if Unix program developers had only
realised the msgids were a good idea.

===It does have that hook. See the other posts on the forum. You can
very easily route all of them to the MVS syslog which could have them
flow on into NetView, but to me that's extra overhead AND you are
cluttering up syslog. And of course, msgids or not, you can still trap
them with TEXT or other tokens.

===If you could respond to the forum instead of emailing my non-IBM
posting address, that would be better. That way I could respond on the
forum. Thanks.

----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO IBMTCP-L

[O'keefe, Patrick]

Here's a posting that accidentally went to Andrew rather than forum.
I'll post his response in a separate posting:


This is one of those NetView functions that sounds a lot better on paper
than in practice. It would make a lot of sense if the primary purpose
logging messages is to drive automation, but the primary purpose is
usually to log messages. Those people used to looking in the HFS log
archives would kill the person that moved sysld to NetView.

Now, if the OMVS syslogd had a hook that would route messages to
NetView, THAT would be a useful feature ... if Unix program developers
had only realised the msgids were a good idea.

Pat O'Keefe

-----Original Message-----
From: IBM TCP/IP List on behalf of andrew mcintyre
Sent: Thu 09/15/2005 12:12 PM
To: IBMTCP-***@VM.MARIST.EDU
Subject: Re: FTPD1

Post by McKown, John
Wherever you tell it to put it. FTP does not actually write directly
to a file. It sends "syslog" messages to the syslog daemon. Note that
this is not the same thing as the z/OS SYSLOG that we are all familar
with. So, first, you must have the syslog daemon running.

And instead of just having the plain vanilla OMVS syslog daemon running
and not having much functionality with it, wouldn't it be nice if you
could automate any message flowing to syslogd? Do something like page
somebody? Run a REXX? Shutdown a server? Startup a server? Send a
message to a central LPAR? REXEC to a UNIX box and run a command? SSH to
a UNIX box and run a command?

Drum roll.... You can!! Instead of starting OMVS syslogd, start the one
in NetView for z/OS. Then you can have an automated response to any
message that flows to the NetView syslogd. Just use the NetView
Automation Table to trap any message or event that flows and take
whatever action you want to take.

You could actually automate an entire room of UNIX severs sending their
messages to a single NetView for z/OS.

Feel free to contact me if anyone wants any further info on this.

========================================================
Andrew McIntyre - Senior I/T Specialist - certified
zSeries Software Technical Sales
SMPO (Software Migration Project Office)
TMT (Tivoli Migration Team)
404-487-2477 or tie 546-2477
***@us.ibm.com
========================================================
SMPO
http://www.ibm.com/software/solutions/softwaremigration
NetView for z/OS
http://www.ibm.com/tivoli/products/netview-zos/resources/nv390-update.ht
ml
System Automation for z/OS
http://www.s390.ibm.com/sa
========================================================

----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions, send
email to ***@VM.MARIST.EDU with the message: INFO IBMTCP-L

----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO IBMTCP-L

[O'keefe, Patrick]

Andrew,
You assume the people looking at the OMVS logs know and/or have any
reason to use NetView. That is certainly not the case in our shop. And
they are the ones that set up the current syslogd configuration. Taking
their tools away from them (even replacing it with something better) is
not the way to win friends and influence people. In spite of my own
personal feelings, not everybody sees NetView as the center of the
universe.

Yes, I know about having the syslogd set up to send all syslog messages
to SYSLOG. We have it set up that way. That's not exactly what I meant
as a "hook". And I definitely agree about the overhead and clutter.


-----Original Message-----
From: Andrew Mcintyre [mailto:***@us.ibm.com]
Sent: Monday, September 19, 2005 5:42 AM
To: O'keefe, Patrick
Subject: Re: FW: FTPD1



See below starting with ===


Andrew McIntyre - Senior I/T Specialist - certified
zSeries Software Technical Sales
SMPO (Software Migration Project Office)
TMT (Tivoli Migration Team)
404-487-2477 or tie 546-2477
***@us.ibm.com




"andrew mcintyre" <***@m-m.com>
09/18/2005 05:14 PM Please respond to
amcintyre

ToAndrew Mcintyre/Atlanta/***@IBMUS
cc
SubjectFW: FTPD1

Post by Finch, Steve
-----Original Message-----
Sent: Sunday, September 18, 2005 4:24 PM
Subject: RE: FTPD1
This is one of those NetView functions that sounds a lot better on

paper

Post by Finch, Steve
than in practice. It would make a lot of sense if the primary purpose
logging messages is to drive automation, but the primary purpose is

usually

Post by Finch, Steve
to log messages. Those people used to looking in the HFS log archives

would

Post by Finch, Steve
kill the person that moved sysld to NetView.

===I disagree. The primary purpose of it being available in NetView is
for automation. I also doubt very many people browse thru a single large
HFS file that has merged messages from all over every UNIX box and
process around. And if you showed them BLOG under NetView, they would
probably thank you.

Post by Finch, Steve
Now, if the OMVS syslogd had a hook that would route messages to

NetView,

Post by Finch, Steve
THAT would be a useful feature ... if Unix program developers had only
realised the msgids were a good idea.

===It does have that hook. See the other posts on the forum. You can
very easily route all of them to the MVS syslog which could have them
flow on into NetView, but to me that's extra overhead AND you are
cluttering up syslog. And of course, msgids or not, you can still trap
them with TEXT or other tokens.

===If you could respond to the forum instead of emailing my non-IBM
posting address, that would be better. That way I could respond on the
forum. Thanks.


----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO IBMTCP-L

[andrew mcintyre]

Post by O'keefe, Patrick
In spite of my own
personal feelings, not everybody sees NetView as the center of the
universe.

Yes but NetView should be the center of the universe. ;)

Thanks for pointing out my reply to issue. I think it's fixed now. Maybe.

========================================================
Andrew McIntyre - Senior I/T Specialist - certified
zSeries Software Technical Sales
SMPO (Software Migration Project Office)
TMT (Tivoli Migration Team)
404-487-2477 or tie 546-2477
***@us.ibm.com
========================================================
SMPO
http://www.ibm.com/software/solutions/softwaremigration
NetView for z/OS
http://www.ibm.com/tivoli/products/netview-zos/resources/nv390-update.html
System Automation for z/OS
http://www.s390.ibm.com/sa
========================================================

----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO IBMTCP-L

[David Bruton]

One more question on the syslogd
I have the >> *.* /dev/console
from what I am reading this is assuming err and above..

*.* /dev/console says all facilities and all priorities go to
/dev/console. This is almost certainly not what you want. If you want
err and above use this:

*.err /dev/console

You can also control logging by specifying a userid and/or a jobname (or
use * for wildcard). For example, to send syslog messages from job FTPD1
running as userid BPXROOT, you could do this:

BPXROOT.FTPD1.*.* /dev/console

This feature was introduced is OS/390 V2R10 if my memory is correct.


David Bruton
***@us.ibm.com

----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO IBMTCP-L

[David Bruton]

PARM of syslodd proc...
// PARM='/-c -i -f / <<< any good recommendations ??

Well, generic recommendations are hard to do because it usually depends on
your requirements. I can give you some insight, perhaps.

-c causes syslogd to create log files if they don't already exist. The
default behavior of syslogd is to try to open the specified file (if the
destination is a file) and if that fails, to disable the rule. This may or
may not be what you want especially if you create log files dynamically with
strftime format strings and want to keep logs for different days or months
in different directories. I would say this parameter is for the advanced
syslogd administrator/system programmer.

-i was added to prevent syslogd from opening UDP port 514. If you do not use
the z/os syslogd to process syslogd messages from remote syslogds then I
would recommend that you specify this option. Note that use of this option
does not prevent the z/os syslogd from SENDING to remote syslogds.

-f you only need this if you want to specify an alternate config file. The
default is /etc/syslog.conf.

You didn't mention -u, but this option provides you with more detail in the
syslogd message header written for each message. When -u is used, you will
also get the userid and jobname of the local process that caused the syslogd
message to be written (ie. caller of the syslog() function). This does not
apply to messages received from remote syslogds. Typically, you would use
this option if you have multiple instances of the same application and want
to be able to distinguish between their syslogd log messages written to a
common file.

Hope that helps.

David Bruton
***@us.ibm.com

----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO IBMTCP-L