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 Visual LANSA, LANSA for i or on the web. To avoid confusion, always list the LANSA product you are reporting the issue for (or requesting the enhancement for).

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. 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 potential fix from LANSA will be based on the latest EPC level so you will be required to get to that EPC level in order to get the fix.

Refer to the LANSA Supported Platforms documents for supported Operating systems and 3rd party products. If an issue can only be reproduced on a non-supported versions of Windows or IBM i, the resolution might be to get to a supported O/S.

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, if possible using shipped demo material and fields and files. Using the Quickexport facility from the IDE is a quick way of packaging up all the material required to reproduce an issue. LANSA Support can just import, compile and execute to quickly see the issue. It is not always possible to package up and issue, especially when a problem is generated at runtime on large and/or complex applications. However, if a problem can be recreated using shipped demonstratation material or packaged into a quickexport, LANSA Support can progress a fix quicker, if a fix is required.

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.

Turn on tracing and review the generated output. Tracing is generally a developer tool and there is no expectation that customers can understand or interpret trace files or logs. However, you might observe a message that clearly indicates what the problem is, for example, if you see a message that a license is expired, etc. Trace files contain valuable information about the job.

Click here for more information about troubleshooting and reporting communications problems

Just as any IBM i jobs generate a joblog, web jobs will also generate joblogs.

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. Using the Quickexport facility from the IDE is a quick way of packaging up all the material required to reproduce an issue. Use the 'Cross References' and 'Cascade selection' options to ensure you package all relevant objects.