×
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 1/24/2024 12:42 PM, Jose Perez wrote:
you can do
Exec sql
Values Current Server Into : Server
it retrieves the same value
RTVNETA does in CL
or you can do
SELECT LOCAL_HOST_NAME FROM QSYS2.TCPIP_INFO
LOCAL_HOST_NAME is not the same as either the system name or CURRENT_SERVER.
LOCAL_HOST_NAME comes from the TCP/IP domain info for the system that you can
see in Option 12, "Change TCP/IP domain information". The value in
LOCAL_HOST_NAME is comprised of HOSTNAME concatenated with DMNNAME from that screen.
The column HOST_NAME in the IBM views NETWORK_ATTRIBUTE_INFO, SYSTEM_STATUS_INFO
and SYSTEM_STATUS_INFO_BASIC is the same as the value in "Current system name"
in DSPNETA. The view NETWORK_ATTRIBUTE_INFO invokes a table function by the same
name, and I'll bet anything the service program for the table function,
QSYS2.QDBSSUDF2, is calling the API program QWCRNETA.
The views NETWORK_ATTRIBUTE_INFO, SYSTEM_STATUS_INFO and
SYSTEM_STATUS_INFO_BASIC all use IBM table functions that invoke the same IBM
service program, albeit with different procedures. The table function for
NETWORK_ATTRIBUTE_INFO has the same name as the view; the function for the two
system status views is SYSTEM_STATUS.
To summarize:
* current system name is HOST_NAME from one of NETWORK_ATTRIBUTE_INFO or either
of the system status views
* CURRENT SERVER is the local RDB name from WRKRDBDIRE, or the views
RDB_ENTRY_INFO or SYSCATALOGS, both in QSYS2
* LOCAL_HOST_NAME is from the TCP/IP domain information
As John Yeung noted, NETWORK_ATTRIBUTE_INFO might not be available depending on
your OS release, and SYSTEM_STATUS_INFO_BASIC is faster than SYSTEM_STATUS_INFO.
midrange.com
