Can SYSIN errors be rectified without submitting the JOB?

techie09 · New User Joined: 31 Oct 2013 Posts: 5 Location: India

Hi All,

Scenario:
We have modified a JCL and we need to deploy it without executing. Can we capture SYSIN errors (or any JCL error) without executing Job? Is there any way to do it?

1. When we execute Easytrieve program with TYPRUN=SCAN, it cannot catch errors in SYSIN parameters. e.g.
suppose SYSIN has condition

IF I = 'A'
...
...
and we accidentally type
IF I = 'A (single quote is missing)
...
...
this is not captured through TYPRUN=SCAN but when we submit the JCL this would give us a JCL error.

We have some site utilities to compare - BEFORE and AFTER source codes, but this doesn't yield the required answer.

Can somebdoy give some suggestion to avoid such issues other than through self review?
Just wanted to know, if there is some way to capture the SYSIN errors without actually executing the Job?

Thanks!

magesh23586 · Posted: Thu Oct 31, 2013 12:23 pm

Check whether your shop has JJ or JEM or JJSCAN etc... Such utility might do a little, but not all the parameters..

expat · Posted: Thu Oct 31, 2013 12:24 pm

So what are you saying, that you do not have a test environment where you test any changes before deployment.

If so, that is extremely bad practice. Every little change needs to be thoroughly tested before being deployed into production.

techie09 · New User Joined: 31 Oct 2013 Posts: 5 Location: India

Hi magesh23586,

Thanks for the reply.

We have something similar "JCL", but even this doesn't help. Moreover we use CA Roscoe with no TSO access.

magesh23586 · Posted: Thu Oct 31, 2013 12:49 pm

I couldnt find any other option for you, testing will be the only solution...

PeterHolland · Posted: Thu Oct 31, 2013 1:11 pm

The contents of SYSIN will never generate a JCL error, the program reading the SYSIN contents does the validating and handle any errors(abend, rc > 0,etc).

Bill Woodger · Posted: Thu Oct 31, 2013 1:44 pm

You can do a syntax-only check of an Easytrieve Plus program. In your case, if you are running it inline, you can even compile it. The TYPRUN=SCAN has done your JCL. The syntax-check/compile does the program.

JCL Checkers could check a program (call the language-processor) but I don't think any of them do.

techie09 · New User Joined: 31 Oct 2013 Posts: 5 Location: India

Many Thanks to all for your replies. Even I had similar understanding that it is difficult to capture such errors, but just wanted to check with experts before concluding it.

Thanks!

Bill Woodger · Posted: Thu Oct 31, 2013 3:10 pm

What is difficult about it? You put the Easytrieve Plus program in a PDS(E). You run a step to syntax-check that member.

If concerned about the JCL, run with TYPRUN=HOLD.

You can still get errors afterwards (dataset missing, duplicate dataset for instance).

techie09 · New User Joined: 31 Oct 2013 Posts: 5 Location: India

Hi Bill,

Thanks for your reply. Let me try this and get back to you on this.

Thanks!

techie09 · New User Joined: 31 Oct 2013 Posts: 5 Location: India

Hi All,

Apologies for late reply, but after multiple discussions and brainstorming it has been decided to modify the process undertaken for review and deployment. Also, we had a discussion on suggestion regarding using PDS for Easytrieve but client has ruled out this preference because of some internal processes they adhere to.

Bill Woodger · Posted: Thu Nov 07, 2013 1:16 pm

Thanks for the update. Ironic to see client procedures getting in the way of what they wan't to do...

anatol · Posted: Mon Nov 11, 2013 9:18 pm

you may try to put in your JCL as last step
// EXEC PGM=JSTTEST
it works better than TYPRUN=SCAN and is not actually execute your JCL

anatol · Posted: Mon Nov 11, 2013 9:21 pm

just submit the JCL with additional step PGM=JSTTEST

enrico-sorichetti · Posted: Mon Nov 11, 2013 9:50 pm

please do not post site dependent suggestions
while JSTTEST is available at Your site , it might not be the same for the TS.

anatol · Posted: Mon Nov 11, 2013 10:16 pm

ok, but JSTTEST facility is not home grown tool - it is part of JES3
If you specify the PGM=JSTTEST parameter on an EXEC statement, JES3 uses the job's Job Summary Table (JST) to produce a summary of the devices that should be allocated to your job. JES3 then stops processing the job when it completes converter/interpreter processing; the job is not scheduled for execution. The JCL and JSTTEST output are then printed.

An example of output from the JSTTEST facility is included in the following. The JCL to run the facility is illustrated below:

Bill Woodger · Posted: Mon Nov 11, 2013 10:57 pm

The problem which cannot be dealt with is the checking of the data cards. The data cards in question are an Easytrieve Plus program. Without being allowed to put the Easytrieve Plus program in a dataset, the Easytrieve Plus program cannot be syntax-checked prior to the run.

Other than by processing the source JCL to strip out the program and syntax check it. Which is nuts if it is much simpler to syntax-check it from a DSN

As to a JES3 solution - not everyone (by a very long way) uses JES3.

PeterHolland · Posted: Tue Nov 12, 2013 12:56 pm