IBM Mainframe Forum

Hi ,

I am relatively new to mainframe and recently joined as a mainframe support engineer and one thing that was bugging me since first day is that why we need to manually restart the errors like FTP and contention as they have to be just restarted from error step. Can't we just automate that.

1) For FTP can we not just give an command to retry to connect to the server until its up instead of throwing error like browsers do and.
2) For contention can't we just check for the dataset before the step and only if it available the step will execute.

I have done some research and got the result that we cant wait the batch jobs. Why? Isn't the job waiting when its in error state.

Thank you in advance for your replies.

I think your terminology is lacking. This

Isn't the job waiting when its in error state.

makes no sense -- if a job gets an error, it stops running and that is why a restart is required.

When there is contention for a data set, the job waits for the data set (until the system time out for waits is reached). The job is not executing during the wait (and if your site is using JES3, the job will not start until the data set is available).

FTP errors frequently are caused by something on the other end (missing file, incorrect permissions, etc) and hence automatically restarting an FTP step makes no sense. The point of a manual restart is for the person to check the system the FTP session connects to, identify the issue on that system, and resolve it before the restart.

These users thanked the author Robert Sample for the post:

Sameerb (Wed Jan 10, 2018 6:48 pm)

As I mentioned I am new to the this mainframe and JCL field and this is just a random idea from the top of my head.

I was asking that instead of throwing error for every contention and ftp error is there a way to automate it.

Generally what happen in our organization that the job abends if the dataset it needed is being used by other job and and it throws a error and there is only difference of 2-5 minutes of that dataset being available then we have to manually convey the message to the other team to restart the job from the failed step. Instead of this can't we just check first if the dataset is available and if not just pause the job for few minutes and then when the dataset gets available it will get automatically restart i.e is there any command in JCL for this ? Is this feasible ?

And for the FTP we generally get this abends when serves are down so if we just keep retrying the connection after some given time without throwing any error. For example: just like the web browsers when internet is down they just keep retrying connection until the net is up and then just refresh the webpage.

Can you just help me to understand if this is feasible and if it is How? and if not Why ?

First - nothing is ever "thrown" on a mainframe. There are plenty of other ways of describing this. For example, your statement "without throwing any error" can be replaced by "without abending".
Second - as said by Robert, data set contention is unlikely to cause an abend, the job that gets it first will doits processing and when finished the next job will get access. If you are having problems then your scheduling system should be updated to reflect the dependency.
Third - a scheduling system CAN resubmit a job after an error automatically as long as the error has been defined to the scheduler and a limit set on the number of re-tries.
Fourth - JCL does not do much as its purpose is to tell the operating system that you want to run one or more programs and the resources required by those programs. Once the JCL has been read it is translated into information that the initiator understands and, effectively, thrown away - all within microseconds of being submitted.

If the job is automatically restarted then how would any error resolution take place.

Oh look, my job has ABENDed, I won't bother looking why, I'll just restart it and hope it works again.
Completely the wrong approach to mainframe, or any other, work.

If something goes wrong then the idea is to analyse WHAT went wrong, why did it happen, what can I do to prevent this error again is more the ticket

As pointed out elsewhere, what you want to do is called a "job scheduler" on the mainframe. Job schedulers can look at the resources a job requires and ensure the job does not start until all resources are available. Job schedulers can also check FTP return codes and flag the FTP for manual review. Under no circumstances would you EVER want to automatically restart an FTP job -- what if the problem is that the server administrator changed the password the FTP job uses to sign onto the server -- the FTP job will never execute until the password is updated and that requires MANUAL change. There are many possible reasons for an FTP to fail and the job needs to be reviewed by a person, period. If your site has a job scheduler, and if that job scheduler allows for automatic restart, I'd say if one restart does not allow the FTP to complete then the job scheduler should require manual intervention (one restart allows for a server to be down briefly and come back up, but if the restart fails then the job needs attention).

It is possible to eliminate contention for a particular job -- just add a step to the front of the job that executes IEFBR14 and specifies DISP=OLD for every data set (up to the system limit for data sets in a single step). The job will not start executing until every data set is available for allocation. Of course, if one (or more) of the data sets is used a lot, it may require a few days (or weeks) before the job starts executing.

And learn not to use inappropriate terminology -- IBM mainframes have been around for more than 50 years at this point and they have never in those 50+ years "thrown" any errors. Jobs may ABEND, or get non-zero step condition codes, but they don't "throw" things. With Java running on mainframes now, a Java program may throw an error -- but that is not the mainframe throwing the error, it is Java. And FTP is not Java, so FTP does not throw errors.