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



Is anyone familiar with the Remote address in the journal entries?

I had assumed that this would be the IP address of the location (e.g.
workstation) that did the update. However, I am seeing cases where this
value is populated for some entries and then not for the rest. Same job,
same programs (although a different call), same files.

I'm also seeing that in batch jobs that FTP to a remote system the updates
to local files show the IP address that the job was FTPing to.

I opened a PMR with IBM and they responded with

"The sockets developer said that his layer sets the local and remote IP
address in the thread control block each time a Sockets API is called in
that thread replacing the previous values.

When the sockets API close() call happens and the thread control block
addresses match those of the closed socket, the IP address values are
zeroed out in the control block.
The thread could have access to hundreds of open sockets, until one of them
is used again on a socket API call, no IP address value can be stored in
the thread control block. While in this state audit records that use the
thread control block remote IP address value will show this field as
blank/zeroed/omitted.


So it is expected that after one thread has closed its socket, you will not
see an IP address logged until another open is done, even if other threads
still have their socket open."


I know next to nothing about sockets programming but I don't see how this
relates to simply writing a record to a database file in a simple RPG
program. Is this being done under the cover in an interactive job? What
about in batch jobs?


Any enlightenment would be appreciated.



Thanks,



Gord


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.