These guidelines that will ensure that your issues are resolved as quickly as possible.

The following are the sort of questions that you may be asked once you have submitted a query to LANSA Support. The list also contains checks that you can perform yourself. To improve the response time, it is preferable to have this information available or be ready to indicate what checks have been performed already.

Questions generally asked when submitting a support call:

Expand All

All issues are important to resolve. However, some may have an impact on a live system and would be considered as a critical issue that needs to be resolved immediately whereas, other issues may be found during development and are not so critical to resolve immediately. Please ensure that you inform LANSA Support of the urgency of the issue. Urgent issues will be given priority.

When logging calls with LANSA Support, be sure to always include the urgency of the resolution of the problem. (Of course, an explanation should be given as to why the call is considered urgent).

Remember, the urgency of a particular problem will dictate the escalation priority and the response time and ultimately whether an EPC fix will be created.

And its not just when logging defects that you need to specify an urgency. You may have need of an urgent answer to a question or want to log an urgent enhancement.

Bear in mind that if you do not indicate that a support call is urgent, LANSA Support will treat it as non-urgent and give it the corresponding escalation priority and response times.

Did it happen once, or is it a consistent error? If you cannot recreate the issue again, it is most likely that LANSA Support will face the same problem of not being able to recreate it. Try to identify a common cause or any patterns to reproduce.

For example, what line of code causes the program to fail? Have you used the LANSA debugging tool to narrow down the problem, for example?

If the issue is isolated to a single machine, then it may well be environment related. Try to identify any differences between the machines as this will provide very specific areas to investigate.

Even though the product is obvious to you, this is not always obvious to LANSA Support. For example, a drop down error can be encountered in LANSA for the AS/400, LANSA for Windows, LANSA for the Web and Visual LANSA. To avoid confusion, always list the LANSA product.

Have you determined that you are using supported LANSA software? Refer to The Statement of support for LANSA software for the current versions of LANSA that are officially supported. When submitting an issue to LANSA Support, you must also specify the EPC level that the issue has been reproduced on. EPCs provide both fixes and new features for LANSA products. Check your EPC level here. You should ensure you are on the latest EPC level. This has 2 benefits.

  1. It helps to determine whether the problem has been fixed by a later EPC or not.
  2. Any future fix will be based on the latest EPC level so you will be required to get to that EPC level.

Refer to the LANSA Supported Platforms documents for supported Operating systems and 3rd party products. Issues must be reproduced on supported versions of Windows or IBM i.

There are always situations where software used to work and now, seemingly inexplicably, it doesn't. Most of the time, the behavior can be explained. Try to think of anything that may have changed on the machine, however unrelated, that might affect the rest of the operations. Good examples are installing a virus checker, applying a PTF, using a new video card, etc. In the case of virus checkers, these have been known to cause problems in that they might incorrectly flag a file as a potential virus, thus stopping the correct functioning of LANSA.

The first thing to do is try to recreate the issue in a controlled environment, perhaps in the DEM partition, using the shipped Personnel Master system fields and files. As we also have this demonstration application available to us; this will ensure that we can also recreate the issue. This is not always possible, especially when a problem is generated at runtime on large and/or complex applications. However, if a problem can be recreated using the demo fields and files, all that LANSA Support needs is the RDML or RDMLX code.

Review the joblog generated on the IBM i server. The joblog always contains relevant information about the failure that may help resolve the issue, and you may find that the answer to the issue is relatively simple once you've read it (Tip: Read the joblog from the bottom to the top). Support will invariably ask for a joblog when the issue is logged for LANSA for i or IBM i client server related. When sending a joblog to LANSA Support, always include ALL of the log, not just an extract, regardless of how insignificant the text may appear to be.

Just as any IBM i jobs generate a joblog, a LANSA for WEB job will be no different.

Click here if connection to the Web server could not be established

The LANSA deployment tool generates two files when being used, DPCREATE.LOG and X_IPARAM.DAT. Before reporting any deployment tool issue, ensure that you have these two files.

Click here for more information about reporting deployment tool issues

The quickest way for LANSA Support to troubleshoot, escalate and resolve LANSA problems is if we can generate the problem in our dedicated debug environment. If you have a test case that can highlight the problem, without the need to have your entire application and runtime environment, then this should be packaged up and sent to LANSA Support so we can import and compile and execute this too. This is by far the fastest way to get an issue reproduced, which is the first step in getting it resolved. The Visual LANSA Deployment Tool can be used to package up a test case. Refer to Using the deployment tool to export an object and all its dependent objects for detailed steps to send a test case to LANSA Support.