Page History
9.27 CONNECT_SERVER
| Note | ||
|---|---|---|
| title | Note: | Built-In Function Rules Usage Options |
...
A request to connect to a server that is already connected will be ignored. No error will result.
Arguments
No | Type | Req/ Opt | Description | Min Len | Max Len | Min Dec | Max Dec |
|---|---|---|---|---|---|---|---|
1 | A | Req | SSN of a defined server. | 1 | 10 | ||
2 | A | Opt | Password to be used to connect to the server. This value is not stored and only exists for the duration of this function call. If this value is not specified, Application server connections use the value from the x_run parameter PSPW= for the default password. If this value is not specified, Database server connections use the password defined in the connection parameter overrides in DEFINE_DB_SERVER. You can let ODBC prompt for the password, as described in the 9.37 DEFINE_DB_SERVER example. | 1 | 256 | ||
3 | A | Opt | If this value is 'Y', then the password value is ignored, and the authority under which the Windows application is running is used for authentication with the server via the Kerberos protocol. If this value is 'N', then the password argument is used for authentication. If this value is not specified, then the default value is the current setting of the PSTC parameter. Refer to The PSXX Parameters . | 1 | 1 | ||
4 | A | Opt | User name to be used to connect to the server. This value is not stored and only exists for the duration of this function call. If this value is not specified, Application server connections use the value from the X_RUN parameter USER= for the default user name. This value is ignored in Database server connections. | 1 | 256 | ||
5 | A | Opt | Handle Server Error If this value is set to 'Y', then the client X_Run session will not abort on errors returned from a Server. Instead the return code will be set to FE and server's error messages will be stored in the message queue. If set to 'N', the client X_Run session will abort on errors returned from a Server. Default Value is 'N'. | 1 | 1 |
Return Values
No | Type | Req/ Opt | Description | Min Len | Max Len | Min Dec | Max Dec |
|---|---|---|---|---|---|---|---|
1 | A | Req | Return Code. | 2 | 2 | ||
2 | A | Opt | Server Type. If a SuperServer, one of: If a Database Server, one of: Note: If the type cannot be determined, the server type will be returned as UNKNOWN. | 3 | 15 | ||
3 | N | Opt | Connection Error Code. Zero if Return Code is OK or LANSA is unable to determine an error code. If a SuperServer, this will be the Comms Error Code. The most common Error Codes are: If a Database Server, this may be the native database error, an ODBC/CLI API return code, or -9999 indicating an internal LANSA error. | 10 | 10 | 0 | 0 |
...
Technical Notes (IBM i Specific)
| Info |
|---|
| Kerberos works without further configuration directly to a server with no access outside that server, say to SQL Server or a file share. If access outside of that one server is required – so-called 'multi-hop' – then this is what is supported: 1. Trust whole computer to *any* services. We have tested and proved this is working 2. Trust a specific domain user to *any* services. We have tested and proved that this is working. (This requires setting up the listener properly to run as a specific user. This should be verified first using lcoecho.) If your environment does not allow one of these configurations then multi-hop cannot be used. |
Technical Notes (IBM i Specific)
...
It is very strongly recommended that you avoid building complex error handling schemes into your applications. Use a very simple trap like this at all levels of your application.
if (#retcode *ne OK)
...
abort msgtxt('Failed to .............................')
endif
Let the standard error handling Built-In Function to every generated application take care of the problem. Situations have arisen where user defined error handling logic has become so complex as to consume 40 - 50% of all RDML code (with no obvious benefit to the application). Do not fall into this trap.