Basic troubleshooting for LANSA Composer Request Server
|Date:||18th August 2010|
|Product/Release:||LANSA Composer V3.0|
|Abstract:||Basic troubleshooting for LANSA Composer Request Server|
|Submitted By:||LANSA Technical Support|
The request server functionality provided by LANSA Composer allows for the calling of LANSA functions on different partition and/or systems through the CALL_FUNCTION activity or a LANSA Composer processing sequence through COMPOSER_RUN activity. This article looks at some steps that can be taken to diagnose errors that may arise when attempting to use this functionality. Before attempting any kind of request server call, please consult Appendix F of the LANSA Composer User Guide for more information.
Simple things that can be done to ensure Request Server functionality:
- Create an empty function and make sure it runs from LANSA IDE.
- Try to call the empty function using LANSA Composer Request Server.
- Should this succeed, try adding one functionality at a time and repeat the test until the desired functionality has been achieved.
- Otherwise, try some simple troubleshooting / tracing step as detailed below
- Certain functionalities such as exchanging variable data on IBM i or database connection on Windows may need additional setup. If the application breaks after adding specific functionalities, please read the relevant sections of the LANSA Composer guide for additional information on LANSA Composer Request Server.
Troubleshooting on IBM i Server
Failures on an IBM i server can usually be resolved by looking at the job logs. A typical LANSA Composer request server call will usually generate two different job logs.
One job log will be produced for the job initiating the CALL_FUNCTION or COMPOSER_RUN request (the client) - in other words, the job that executes the processing sequence. If running a processing sequence through the LANSA Composer client, this will typically be a TP (e.g. TP00000009) job running under the specific LANSA Composer subsystem. If you start your processing sequence by other means, for example from another LANSA application or in a submitted job, then you need to look for the joblog for that job.
One or more job logs will also be produced to handle the request server call, usually created with the name LCRQSERV. More than one job logs may be produced for multiple request server calls. By default, these will be produced in the QUSRWRK subsystem. However, the request server jobs could be configured to run under a different subsystem. For more details, please see the ‘LANSA Composer Request Server for IBM i Configuration Settings’ in Appendix F.
If exchanged values are not passed or received correctly, please check position 487 of LANSA data area DC@A01 in the LANSA system containing the function to be called and make sure that it is set to Y. If it is not set to Y, the LANSA function will need to be re-compiled after changing the data area. Please also make sure that the LANSA function and/or LANSA Composer processing sequence follows other guidelines outlined in Appendix F of the LANSA Composer documentation.
Another common error will arise from unsuitable configuration as specified in data area DXRQSSERV. In most cases, the default value for these should suffice. However, there are cases where changes are necessary. One such case is when the default user of &PGMLIB specified on the skeleton SBMJOB command in that data area is not available or has insufficient privileges. In this case, you should change the skeletal SBMJOB command in the data area to use a different value for the USER parameter. Please read ‘LANSA Composer Request Server for IBM i Configuration Settings’ in Appendix F to for more details.
Troubleshooting on Windows Server
As there are no equivalent troubleshooting tools on Windows, LANSA and LANSA Composer provides several additional tools that can be used to resolve errors.
When encountering errors on a LANSA Composer processing sequence, first check the relevant LANSA System Configuration and ensure that all values are correct. Also check that the correct LANSA System Configuration ID has been passed to the CALL_FUNCTION activity.
To confirm that the correct parameters have been used, check the processing sequence log immediately before the reported failure to see a number of X_RUN parameters (maximum logging may need to be enabled for this) and see if they are correct. One way of doing this is to use the parameters on the target LANSA System with X_RUN.exe from the command line or using the call function utility provided by LANSA. To understand what each parameter might mean, please refer to the appropriate section of the LANSA Composer guide.
In addition, Windows server installation of LANSA Composer provides tracing functionality. To turn on tracing, Assign &LOGRQSSERVER = 'Y' (Use ASSIGN Processing Sequence directive) before the CALL_FUNCTION activity. If successful, a dxrqsservnnn.log file will be created in the location specified by the processing sequence log (example below).
Another option is to turn on LANSA tracing in the target LANSA system. To do so, specify ITRO=Y ITRC=ALL in the LANSA System overrides section of the LANSA System configuration in addition to other parameters that have already been specified. For details about what these parameters do and other parameters that could be specified please refer to the appropriate LANSA documentation.
Also note that as multiple databases are supported on Windows platforms, the database details will differ slightly between different systems. However, in all cases the specified users must have the proper authorities to access the database.