Share:|

-by Joe Goldberg, Control-M Solutions Marketing, BMC Software Inc.

 

Imagine you’re an IT Operations dude or dudette. You’ve been working twelve hour shifts for three nights straight and tomorrow is Friday. You have a great long weekend planned.

 

Suddenly, you get a notification that job PYPWCR12 aborted. You snap into action and call the duty programmer, anxiously waiting until the problem is fixed and you can breathe a deep sigh of relief.

 

You are a dedicated employee and your company’s production is important to you but you also happen to know that PYPWCR12 is the job that makes the bank deposit that will ensure you can cash your payroll check and truly enjoy that weekend you have planned. Not only do YOU know it but that duty programmer also knew it and probably responded just a little faster than normal; perhaps for similar reasons to yours.

 

How did you know? Well, because you have standards in your installation. The first two characters of a job name must be a valid application (PY is payroll) and “P” means it’s a production job (this is for real and not just some programmer running tests), it’s the Weekly job that does Check Reconciliation.

 

Of course you know standards are important for more than just letting IT Ops folks plan for a great weekend.

 

Standards are critical for all kinds of reasons such as ensuring consistency, simplifying administration and security and making important information known to all interested parties. But how exactly are standards enforced? For batch job and workload definitions, usually the answer is manually and that is not a great answer. Let’s look at a simple example in that scenario above. QualityControl.jpg

 

What if your organization enforces security for job access? That on-call programmer can only look at jobs that are part of the production payroll application. Recently, a change was made to one of the jobs and instead of starting the job name with PYP…, a typographical error was made and the job name was PYBWCR12. When that job failed, perhaps it was not identified correctly as being part of production payroll? If it was properly identified, perhaps the on-call programmer could not access the output. Perhaps the failure itself was due to some check for the job name (very common in z/OS environments).

 

I mention z/OS because job name validation in this platform is a common practice that has evolved over decades but is almost completely absent in other environments. Standards enforcement is largely a manual process subject to all the challenges that manual processes present.

 

I’ve focused on job names but of course standards are critical for almost every character or attribute of a job.

  • If the “Run As” user is invalid, the job will likely fail security validation
  • If the filepath is invalid, the required script will not be found or even worse, the wrong script may be executed
  • If the wrong email address used for failure notification, no one will respond to correct a critical problem
  • If the application or sub-application name is incorrect, the job may not be seen by its owners or the folks repsonsible for fixing problems.
  • If documentation is omitted, Operations may not have proper instructions for handling the job

 

The list really does go on and on.

 

What makes this situation even more challenging is that many organizations have multiple standards. z/OS job names are eight characters and may be very similar to PYPWCR12 but in the very same flow, there may be Unix jobs that have names like “Payroll_Check_Reconcilliation_Bank_Deposit”. It’s common to have different standards for Windows versus Unix/Linux versus ERP versus File Transfers and so on. This makes it exceedingly difficult to remember all this and to get it right for application developers who submit requests or for centralized operations teams who build or modify job definitions.

 

A great way to deal with this problem is to make the workload automation solution smart enough to know your standards and to enforce them when job requests are submitted and when jobs are modified or built. That’s the idea behind the Site Standards facility of BMC Control-M Workload Change Manager. You can define any number of Site Standards you require. You can allow users to select standards or you can set a specific standard for a folder. If request submitters, usually application developers or business analysts, are very familiar with the site standards, you can insist the requests comply with the standards, or, if your users are not that knowledgeable, you can accept requests with errors.

 

Here’s the thing; standards are also enforced for schedulers working with the Workload Automation client so that validation must be performed and passed before changes are committed. No more guessing, hoping and relying on only human eyeballs to stand between managing job definitions and job failure.

 

If you have a solution that you have implemented or if you are suffering with a process that is less than perfect, tell us all about it and share with the community.

 

 

The postings in this blog are my own and do not necessarily represent the opinions or positions of BMC Software