× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On Wed, Feb 24, 2016 at 4:54 PM Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
wrote:

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.


That seems to be the strace/procmon/truss thing for i5/OS Vern! Sometimes
you go to ask the question the right way to get the right answer. BTW it
makes total sense in retrospect that an AIX command (truss) would not work
on PASE.


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.


Ok another thing to google and possibly find useful.

As a comment on all this system admin stuff - the original system/38 -
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.


I'd find it interesting if that was still the case, but I'm entirely
ignorant of Mainframes other than having read the mythical man month and
running a minframe emulator with a 1970s version of the OS assumed to be
public domain on my laptop one afternoon.

IIRC, this is now called Collection Services - something like that.
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!


Yes, much to look at! Thanks




Vern

On 2/24/2016 3:13 PM, Justin Dearing wrote:
Vernon,

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
level
process calls INCLUDING opening up network sockets (which tend to be
TCP/IP). I don't know of a standard BSD utility (ping,
traceroute,netstat,
etc) that would monitor what process is bound to what port, except
netstat,
which Rob already mentioned using.

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,

Not going to be of help, just going to commiserate here for a bit. If
there
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
on
linux your going to need to write some C code to be notified when a
process
starts because you can only strace one process at a time.

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
api
call is that any LDAP connect API call would call?

If I was on linux or windows and you took away strace and procmon, and
the
APIs that they used, my MacGyver strategy would be to use windbg or gdb
in
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
GDISYS2
is 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
address
10.10.6.129 from GDISYS2.

I'm trying to determine what job is trying to perform an ldap bind
from
GDISYS2 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
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.

--
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.


--
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 thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.