|
The help on the utilities I posted use stuff that sounds like what you
are describing - a command called TRCINT - Trace internals - is one of
the things used. Not something the everyday user could care about, and
for things like this you need the *SERVICE special authority.
There is also something called PEX - not the plastic piping, please!! -
Performance Explorer. This can get you just about everything you'd ever
want to know about processes. Because this kind of performance
information is already available there, I suspect that the IBM i system
developers saw no need for these utilities.
it had basically the same OS as our enhanced OS for i. And it monitors
EVERYthing - one of the reasons that mainframes are desirable for
headsdown number crunching is, they don't have as much integrated
logging of various metrics, while IBM i collects a ton of it.
Actually, that is a layer on top, sort of, that gathers in the metrics
and can be put into tables, which you can use to analyze to your heart's
content.
The latest web-based Navigator has tooling to help analyze this stuff, too.
Hope that gives you something worth looking at, man!
Vern
On 2/24/2016 3:13 PM, Justin Dearing wrote:
Vernon,level
I recently asked on this very list if such a thing existed:
http://archive.midrange.com/midrange-l/201602/msg00546.html
Actually strace/procmon/trussare not TCP/IP things. They monitor low
process calls INCLUDING opening up network sockets (which tend to betraceroute,netstat,
TCP/IP). I don't know of a standard BSD utility (ping,
etc) that would monitor what process is bound to what port, exceptnetstat,
which Rob already mentioned using.on
That being said, I Hope Rob does find a solution neater than his SQL loop
and reports it back here. If Rob's question sparks someone to find an
answer to my question, I'm glad we can all learn something useful.
Justin
On Wed, Feb 24, 2016 at 4:06 PM Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx
wrote:
Justin
Are you sure these things are not there, perhaps under a different name
or function? At one time, IBM had their regular 3-letter-component names
in commands for the well-known TCPIP things - PING is there and is also
known as VFYTCPCNN - Verify TCP/IP Connection.
There are also a couple commands that might be useful - TRCTCPAPP
apparently can give one a lot of information, and TRCCNN might help Rob
- it has an optional parameter to specify from and to ports.
HTH
Vern
On 2/24/2016 2:17 PM, Justin Dearing wrote:
Rob,there
Not going to be of help, just going to commiserate here for a bit. If
was a strace/dtrace/truss/procmon kind of thing for IBM i, this is
*exactly* the use case for it. You know something is making a TCP
connection. you even know the port, you don't know what. Well actually
GDISYS2linux your going to need to write some C code to be notified when aprocess
starts because you can only strace one process at a time.api
My only other shot in the dark idea, is it possible to do the following
(without making your whole system useless):
1. Attach every new job to a debugger
2. Have the debugger break on whatever the lowest level TCP connection
call is that any LDAP connect API call would call?the
If I was on linux or windows and you took away strace and procmon, and
APIs that they used, my MacGyver strategy would be to use windbg or gdbin
the manner described above.
On Wed, Feb 24, 2016 at 3:01 PM Rob Berendt <rob@xxxxxxxxx> wrote:
I have two lpars in this thread: GDISYS1, GDISYS2
On GDISYS1 I do WRKJOB QUSRDIR and look at the joblog and I see:
Message ID . . . . . . : GLD0120
Message . . . . : Bind error with directory server.
Cause . . . . . : Distinguished name (dn) 'CN=ADMINISTRATOR' at IP
address
10.10.6.129 failed to bind with the directory server.
The IP address for GDISYS1 is 10.17.6.129 and the IP address for
fromaddressis 10.10.6.129.
I can run a comm trace on both lpars and I can see that port 389 on
GDISYS1 address 10.17.6.129 is being accessed from port 42408 from
10.10.6.129 from GDISYS2.
I'm trying to determine what job is trying to perform an ldap bind
listlistGDISYS2 onto GDISYS1 using the name CN=ADMINISTRATOR.
Comm trace does not display jobs on either the source or target side.
NETSTAT *CNN requires that I am constantly refreshing it and I've been
unable to catch it. It doesn't have an output option to put it into a
program loop. Like the following:
create table rob.netstatstuff as (
select current timestamp as TS, n.*
from qsys2.netstat_job_info n
where n.local_port=42408
) with data
// start loop
insert into rob.netstatstuff (
select current timestamp as TS, n.*
from qsys2.netstat_job_info n
where n.local_port=42408
)
// end loop
Again, you're timing has to be perfect otherwise you get:
SQL0100 - Row not found for INSERT.
Is there a better way to determine who is trying to bind via ldap?
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
--To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.