For over 20 years we've been supporting thousands of our customers around the world.  One thing that is very inconsistent is the information received when a customer asks for support.

I would like to outline what you can do to make sure we, or any vendor, can provide top notch support as quickly as possible.

What Not to Send

First and foremost, do NOT send screen captures or images unless we request them.  Especially if they are job logs, commands that were run, or other displays. 

It's just as easy these days to copy and paste text from your 5250 emulation software than it is to send an image.  This allows us to copy and paste information from the data (which is impossible using screen capture images).  It also makes the emails smaller, take less bandwidth.  Also, when sending large images they can really mess up the view of the email as it can stretch the end of the lines of text past the end of the screen.

When sending job logs, send them in text or PDF format (more on that later).

Software Name and Version

Some customers may only use one piece of software and not thing about sending this information.  But the name of the software and version of that software is a great start.  The name of the software is normally pretty straightforward, but the version can be tricky to find in some cases.

See this new article for instructions on how to find the version for software from BVSTools.

Company Name and Contact Information

This may seem trivial, but sometimes we can't get all this information just from the your email address.

Your Machine's Serial Number and Model Number

Providing your machine's serial number and model number also helps us pinpoint who we are dealing with.  We can link the serial number back to a customer and find any notes we may have on you, as well as what software you've purchased.  

If you are using BVSTools software you should have a command named DSPMCHINF (Display Machine Information) in your software's library.  If you use this to send the information that is even better.  But as mentioned before, do NOT send a screen capture image.  Copy and paste the text from the screen instead.

A Complete JOB LOG

This one is almost the most important, which is why we saved it for last to discuss.

We get a lot of support calls and emails saying "Software XXXXXX doesn't work.  Why?"  What's difficult about this is "doesn't work" can mean one of many things.  So, providing a detailed description of the problem as well as a complete job log is invaluable to us when we are trying to provide you with top notch support.

What do we mean by "a Complete Job Log"?  

This means we want to see the command that was run with all the parameters you used filled in.  The CL source or RPG source just doesn't provide us with enough information most of the time.  But, if we can see the command that was run as well as the messages in the job log after it, that helps.

What we recommend is this:

1. Change the Job Logging Level to Zero and Turn on CL logging (if it's not already on).  
   If you're running the command from your interactive job, this is as easy as running the command:
   
   CHGJOB LOG(4 00 *SAME) LOGCLPGM(*YES) 
   
   If the job is submitted to batch, there are ways to do this as well.  We would suggest putting the job queue on hold that the job will enter.  When the job enters the job queue, you can view the job information and use the CHGJOB command to turn on CL logging as we did in the previous example.  Better yet, instead of submitting the job, sometimes for testing it's better to run it interactively.
    
2. Send us the Job Log
   Sending us the job log means you'll first need to create a spooled file from the job log.  This is accomplished using the following command:
   
   DSPJOBLOG OUTPUT(*PRINT)
   
   This will take your entire job log and create a spooled file from it.  Then, use a tool such as SPLTOOL to convert the spooled file to a PDF or TXT file and send it to us.  Even if you don't have a license for SPLTOOL, download and install it and use a temporary key.  That's no problem with us if you need to do that and don't plan on purchasing the software.  We would just prefer to get as much information as we can to provide support.
    
3. Details, Details, Details!
   Provide as much information as you can about any changes, PTFs, etc that have been done.  For example, if MAILTOOL is working fine one day, then just stops, think and ask yourself "what changed?"  Most of the time it's not our software that changed.  In fact, it's normally because of a network change that most of our software stops working, not our software itself.  But, any information you can provide will help tremendously, even if it seems minute.

If you are asking for support for MAILTOOL (or the SPL2EMAIL command), here is another article with more specific debug information that you can provide:

Providing Debug Information When Using MAILTOOL

Keeping these thoughts in mind you should be able to provide complete information to us at BVSTools or any vendor.  The more information the better!

Brad