AO Support Process

This page describes the procedure for logging a support request, reporting a malfunction or requesting a new functional enhancement for AO.

Please submit a “Ticket” simply by sending an e-mail via the contact form below. Include as much information as possible. Please follow our suggested guidelines (on the right or below on mobile devices) absolutely as it will expedite the resolution of your support request.

Your Title Goes Here

Your content goes here. Edit or remove this text inline or in the module Content settings. You can also style every aspect of this content in the module Design settings and even apply custom CSS to this text in the module Advanced settings.

1. Background

To ensure transparent management of the AO product, it is essential to track all support requests, malfunctions, and new functional enhancements in a proper manner. TEMBO has implemented a support management system called Request Tracker (RT), where every request generates a “ticket” with a unique tracking number. RT responds to the “Requester” with a “Ticket Received” confirmation email and notifies the queue manager of the new ticket.

 

TEMBO undertakes to provide feedback on each ticket received within 48 hours. This feedback depends on the type of request but the intent is to inform the requester of the plan of action and/or lead-time for the request. TEMBO may also request additional information needed to resolve the ticket at this time.

 

Depending on the type of requested activity, the requester may receive additional feedback on progress or other communication as necessary.

2. Submitting a “Ticket”
  • TEMBO recommends that an organization with multiple AO users designate a single person as their AO support contact or “Requester” (as RT terms the role). This avoids the possibility of reporting issues more than once (or potentially not at all) and provides a single point of contact between TEMBO and the customer.
  • The requester submits a “Ticket” simply by sending an e-mail via the contact form.
  • The email should include as much information as possible to describe the issue and provide the TEMBO developers with a clear understanding as to what has happened. More and detailed information facilitates problem determination and timelier turnaround of any possible work-around and/or solution.
  • Please use the list below as a guideline to the sort of information to provide:
  • The “Subject” of the e-mail should be an identifiable, but brief, description of the issue, as this will become the subject of the ticket.
  • The first line of the body should indicate the type of issue being reported and severity from the user’s perspective.
    • E.g. AO Fault: Severity = Low
    • E.g. Error: Show Stopper
    • E.g. Enhancement Request: Could really use it now.
  • The body of the e-mail should describe, in detail, what the user tried to do and the steps taken leading up to the issue. Please include the environment, schema and file names as defined in AO wherever possible.
  • Imbed in the email or add as attachments any pertinent screen shots to support the explanation; the RT system will attach these to the ticket it generates. Spool files of compilations, particularly from the RUNSQLSTM command often provide very helpful information.
  • The most important information provider for these types of issues is the Job Log. The IBM i job log contains a series of messages leading up to the final message (the one appearing on the screen), as well as other very helpful information for analysing problems. Please include as much of the job log (including the second-level message text, i.e. generated with the *PRINT option) preceding the final message as possible. If feasible, include only the section relevant to the issue described; however, better to include too much information rather than too little.
  • As the RT system includes ANYTHING it finds on the mail as part of the ticket, we kindly request that you please remove all information that does not pertain to the issue from the mail, such as email signature information, company logos, notices, etc. This saves space in our database and reduces clutter.
  • For Enhancement Requests, the email simply needs to detail the specification of the added function or new feature in as much detail as possible.
  • After resolving the issue and testing the solution, TEMBO changes the ticket status to “Resolved,” which automatically generates a resolved ticket to the original requester informing them of completion.
  • All “Resolved” issues, by default, are included in the next release of the AO Product.
3. Log On Support

If the customer provides TEMBO access and a logon to their IBM i where the customer installed the AO Foundation product, this allows TEMBO to provide enhanced and simplified support. We can negotiate such access at the time we sign the support agreement. Such support involves no additional costs or discounts, but serves to make the support of the AO product easier for both parties.

 

With Log On support in place, the Requester raises a ticket in the manner described above but instead of extracting and attaching compilation listings, job logs and screen prints to the email, the Requester places these supporting documents and information into the ADSERO output queue in the AO_GPL schema. TEMBO can then view and retrieve these as required.

 

In addition, the ability for our development team to repeat the user’s actions in the same environment often results in faster problem resolution and quicker identification of workarounds to temporarily overcome the problem.

4. Emergency Patches

If the nature of the error negatively affects the users to the extent that they cannot wait for the next release of AO and no workaround is available, TEMBO can “patch” (with the customer’s approval) the AO code directly in one of two ways.

 

With “Log On Support,” TEMBO can patch the AO code directly on the customer’s machine.

 

Without “Log On Support”, TEMBO supplies the customer with a zipped IBM i save file (*SAVF) containing the patches, along with instructions on how to install them.

 

Note: We advise use of this method of “patching” the AO code only in extreme circumstances, as it could theoretically cause stability problems within the code, particularly if done on a repeated basis.

 

AO Support Process Version 4.1 – Published 2 January 2018