Improving Issue Resolution Times

Detailed Description:

Below are some 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 when you submit a query to LANSA Support. To improve the response time, it is preferable to have this information available.

Questions generally asked when submitting a support call.

What is the urgency of this issue?

All issues are important to resolve.  However, some may have an impact on a live system, and could be considered as a critical whereas, other issues may be simple enquiries.  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.

Have you been able to regularly recreate the issue?

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.

When does the issue occur?

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?

Does the issue appear on every PC?

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.

Which product is being used?

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 the LANSA product.

Which version/program change of the software is being used?  What EPC level?

The are many combinations of product level and EPC available and it is important when submitting an issue to specify the EPCs currently installed.  EPCs provide both fixes and new features for products. It is equally important to ensure you are on the latest EPC level. This has 2 benefits. It helps to determine whether the problem has been fixed by a later EPC or not and any future fix via EPC will be based on the latest EPC level so you will be required to get to that EPC level anyway. 

Which is the platform/operating system release?

Windows 9x, NT, 2000, server, workstation, OS/400 V5R1, V5R2, etc. PTF level on iSeries and service pack on Windows is also important. All of these versions are subtly different, and may be the cause of specific issues.

It used to work and now it doesn't!

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 changes in the path statement in AUTOEXEC.BAT that have prevent software running correctly afterwards.

If you think your issue is a defect in LANSA

The first thing to do is try to recreate the issue in a controlled environment, usually the DEM partition, using the Personnel 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. 

If a client server job to the iSeries is failing for any reason.

Review the joblog generated on the iSeries.  The joblog always contains information that will 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).  We will invariably ask for a joblog when the issue is iSeries or iSeries 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.

If a client server job to an Windows/UNIX server is failing for any reason.

Turn on tracing and review the generated output.   Trace files contain valuable information about the job.

Click here for more information about troubleshooting and reporting communications problems

If your Web jobs are failing to connect

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

Click here for more information about finding LANSA for the WEB joblogs

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

If your issue is Deployment tool Related

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

Sending a test case to LANSA Support

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.