Tags

, , , , , , , , , , , , , ,

Most of the mainframe projects have production support and you know how important it is to keep track of errors/issues that have occurred in the past. There will be some issues which can be resolved instantly but there are some issues which you (or other team member) has spent a lot of time to resolve it. Capturing all the steps that you used to resolve the issue will immensely help next time when the same issue occurs.

In Mainframes, probably we look at a job level for the batch issues. So, having a database with the details of the issue occurred and solutions that were taken for all the encountered issues at a job level will help the current team and any future team members that are going to support the application.

The job failures are classified as below Data, Network, Delay, Deadlock

  • Data: The failure is classified as data issue if there is any discrepancy in the file received. Examples of data issues could be due to the following reasons:
  1. Incorrect file received from the upstream or the vendor.
  2. Junk values in the file which has caused the data inconsistency.
  3. The format of the file is not as expected for example; the data or the values in the files are not in the correct format as expected.
  4. Missing values in the file or the file is empty.
  • Network: The interaction with batch processing is mainly through a network of transmitting or receiving the files from either one server to another or through DB2 tables. The failure is classified as network issue when there is any issue in interacting with the batch processing. Examples of the network issue could be due to the following reasons:
  1. Server unavailability to while extraction the file or uploading the file during the job execution.
  2. Resource unavailability, this could be due to the file or the table is been used by other jobs.
  3. System or the application down while the user is trying to access the data.
  • Delay: When there is any feed delay from the upstream or the vendor the batch jobs go into the failed status. The delay would happen due to the following reasons mentioned below:
  1. The file is very huge (that is, contains a greater number of records than the expected.
  2. The scheduled release activity either in our application or in the upstream.
  3. The jobs going into contention waiting for the files which are used by the other jobs.
  • Deadlock: When the batch is executing concurrently, a deadlock can happen when one job is trying to access the file or database and is waiting on the other job for release the lock on that file or the database.

A known error database, then, tracks all the known errors within the IT’s jurisdiction, which is typically an entire system or even organization. Ideally, the KEDB includes:

  • Descriptions of how/when the issue will appear, including a description of the incident from the user’s point of view
  • Screenshots of the incident(s) and problem
  • Text of error messages
  • Workarounds (temporary solutions) that help the user handle the problem and return to productive work with minor to no delay
  • Resolutions, if the incident and problem have occurred and previously been solved

Benefits of a Known Error Database

IT teams within enterprises develop a KEBD because it offers many benefits, both to users and directly to the IT team.

Benefits of a KEDB to Users

A KEDB helps users continue in their productive work, as they typically aren’t concerned about the wider effects of the incident. Here are some user benefits of a KEDB:

  • Reduces downtime. If an incident is already reported, which is likely, a user won’t have to wait long for a response from the help desk because a workaround likely already exists. This minimizes downtown while a user is working.
  • Ensures continuous work. If the incident happens again, the user already knows the workaround, therefore contacting the help desk again isn’t necessary.
  • Avoids individual troubleshooting. When a workaround already exists, the user does not have to troubleshoot on their own. When user is troubleshooting without the help of IT, the user’s productive worktime decreases significantly. This also helps the user use their own skills for their own work.

Benefits of a KEDB to IT

Known error databases are especially useful to the IT department and the help desk for several reasons:

  • Responds quickly to users. The help desk doesn’t have to find a workaround every time a user reports an incident. Chances are good that there is already an existing workaround, and by pointing the user to the database, the help desk has saved time on that incident.
  • Tracks occurrence and severity. The KEDB allows the help desk to track how often and how widespread the incident occurs. The more users who report it, the more common it may be. This is another way of prioritizing how quickly a long-term solution must be found.
  • Offers consistent and repeatable workarounds. With a safe and tested workaround, the help desk now has a consistent resolution for all users who report the incident. This improves the user satisfaction, which contributes to the IT department’s efficiency.
  • Maintains safety. When the help desk can offer a safe and proven workaround, users aren’t inclined to troubleshoot on their own. Users attempting to find solutions to their own incidents can lead to serious problems like disabling antivirus software or triggering other incidents.
  • Prevents repeat work. If the new incident has been solved before, IT can reference prior solutions as a starting point for researching and solving the current problem. This often leads to IT finding a resolution in a fraction of the time it previous took.
  • Avoids skill gaps. Most help desks are staffed with a combination of entry-level and advanced-skills employees. A KEDB allows entry- and lower-level employees to have experience assisting users as they can reference the information in the database. This frees up the more advanced employees so they can continue resolving problems.
  • Prioritizes all IT issues. The KEDB can become part the overall IT Problem Management Database. This database helps IT identify problems and prioritize where to spend their resources finding permanent solutions.

References

Click to access E05033136.pdf

https://www.bmc.com/blogs/known-error-database-an-introduction-to-kedbs/

——————————————————————————————————–

In United States, If you would like to Earn Free Stocks, Credit card Points and Bank account Bonuses, Please visit My Finance Blog

——————————————————————————————————–

You may also like to look at:

Working on Mainframes – Is Change to a different technology necessary
Important SQL CODES and ABEND CODES
SORT JOIN – TO JOIN TWO FILES BASED ON A KEY
KNOW YOUR MAINFRAME
REXX – INITIAL SETUP
HOW TO SUBMIT A BATCH JOB FROM THE CICS PROGRAM
CICS – EXEC interface block – EIBRESP Values
CICS – EXEC interface block Fields
Flow of control between COBOL programs, run units, and CICS
CICS INTERVIEW QUESTIONS
CICS TIPS
COBOL – COPY and INCLUDE statements
COBOL – PERFORMANCE IMPROVEMENT
COBOL – SIGN STORED IN COMP, COMP-3 AND DISPLAY FORMATS
SHORTEST COBOL PROGRAM
RESTART LOGIC IN COBOL DB2 Program
GOBACK – EXIT PROGRAM – STOP RUN
Continuation lines in COBOL
Computational items – COMP, COMP 1 , COMP 2, COMP 3
COBOL program format
cobol indicator area column-7 and area a and area b
COBOL INTERVIEW QUESTIONS
COBOL TIPS
COBOL COMPILER OPTIONS
The IDENTIFICATION DIVISION