QA engineer new to mainframe... resources to learn?

[romille]

Hello, this is my first post...

I am new to mainframe. I have a JCL library made by someone else that I use to run batch programs to test certain functions. The trouble is that when these programs throw an error or need to be updated, I have no idea what I am doing. I know nothing about COBOL, and barely know my way around the UI.

Any help would be appreciated! I am really looking for an "idiot's introduction" sort of starting point.

Thank you!

[BillyBoyo]

Does your jobspec as a QA person require you to change Cobol code? If you are supposed to QA Cobol code, rather than program function (output, resources etc) then you need to get your company to arrange Cobol training for you, and you will need to gain some experience in also using the code - you would need time to write some (no essential or training) programs.

With the JCL, again, mostly it should not be your job, other than things like "dumb mistakes" typos and such-like that take no thinking or no particular skill to fix. You QA job is about what others have done, not about what you do, I'd have thought.

For more general stuff, you'll find a lot of information in the online help/tutorials (pressing PF1 when something you don't understand happens is always a good start). Also identify what knowledge would be the most help to you, and prioritise what you need to know. All the IBM manuals are available, but there is no point in consuming a manual which will be for something you never need to use. Much better to get a good grasp of the basics of JCL, say, and be aware of what other JCL is available and how to find out about something when you need it.

The plethora of messages you'll come across are one area to concentrate on, but if you google for LookAt from IBM, you'll find a great deal of help with those.

There is something of a technique to reading manuals, and it is worth time investing in that.

[steve-myers]

There are two jobs for QA

• Making sure the thing (that is to say, the product you are quality testing) works to spec.
• Trying to break the thing.
• Something related to the first bullet, and it's not always a direct requirement: verifying the thing performs acceptably in a real world environment.

Now, to do this a QA engineer needs these skills:

• A rudimentary knowledge of how the thing works. Not the detailed knowledge a development engineer needs, but you will need this to figure out if the thing is working correctly.
• A rudimentary understanding of how the the operating system works and how the thing interacts with the operating system.
• A rudimentary knowledge of the tools used to install the thing. In the MVS and z/OS world that means
  • SMP (System Modification Program). SMP is used for many, though not all, products.
  • Almost certainly, JCL
  In the VSE and z/VSE world this means
  • MSHP (I think), often called Mishap!
  • VSE JCL
  A QA engineer may have to install the thing, to verify the documented installation instructions are more or less correct.

[Akatsukami]

Messrs. Boyo and Myers have spoken well and knowledgeably. However, it occurs to me that there is another interpretation of your words, romille: that you have a standard suite of test programs to be run when, e.g., a new version of DB2 is installed on an LPAR, to benchmark performance, and that you are looking for what to do when things go pear-shaped for reasons of genuine incompatibility between your test suite and the upgraded software.

Aside from the standard "COBOL For Dummies"-type books that are easily found through Amazon, I would recommend:

• The University of Limerick's COBOL tutorial site
• The American Programmer's Just Enough to Be Dangerous JCL Tutorial (which you can use even if you're a furriner )

[steve-myers]

... you have a standard suite of test programs...

Akatsukami is very correct, though a more generic statement might be in order: you should document a procedure to validate operation of the thing for a new release when some other QA engineer will be checking it. It is especially important to document scenarios where you (or perhaps others) have broken the thing so you can verify a fix actually fixes the problem and does not break something else. Akatsukami and I probably have slightly different points of view about this issue; my background is a support engineer for a thing (what it was is immaterial), whereas I suspect Akatsukami is a user of many different things.