IBM Mainframe Forum

I believe that it is possible to tell OPC that a non-zero return code is OK. The alternative is that you can tell OPC that if you get a 166 then submit another, or the same, FTP and if that gets a 166 then go into error mode.

Tim, I'm here putting together what people have said.

If you run ftp under the control of a program, you can trap your 166 code (and any others you fancy), pause a little bit, and try again. You can make, like your JCL, a number of attempts. If still failing, you can set a suitable return code from that program. If successful you can set to zero. You could even produce a little summary of what the program did for infomation purposes.

This program could be written in REXX or CLIST running under TSO. You can develop and test it in TSO. For production you could run it in batch if you prefer. The amount of control you have depends on what you program. REXX is enormously flexible (my preference, but what the heck).

Or:

Attempt to continue down your JCL route. The amount of control you have depends on JCL and what you have for job scheduling/monitoring.

If you want this route, it would be better to split your job/proc up. All the stuff before the FTP in one place. All the stuff after the FTP in another. The FTP stuff seperate. Although you might not be able to "touch" the ftpproc, you can copy it (at least in theory) and make it your own if that helps. Tell the owners of that, so they know if anything in theirs change that there is another one out there. Breaking the job up will simplify a "JCL" solution.


You yourself asked if there was another solution to the problem. The other solution is the first one I've set out above. When the "owners" of the ftp proc find out what you have done (if you go the first route) they will (should) want to do it that way as well.

Now, we could go on flogging the JCL solution for some more time, but really I think most would go with the first solution. It will do everything you want for your JCL solution, while at the same time being possible.

I promise this is the last time I'll ask. Can you consider this solution, put forward originally by Mr Spock in the very first response (I believe, I can't check for fear of losing all this, yes, enrico, I am keeping a copy). If it is just not suitable, for whatever reason, can you just tell us the reasons so we can stop suggesting it?

So, solution 1, everything-you-want-from-the-jcl-but-in-a-program, or solution 2, something-short-of-what-you-want-but-in-jcl.

Thanks in advance.

Acknowledgements to all who have contributed to the above outline, apologies for errors and omissions.

[I think my first post disappeared; sorry if this turns out to be a duplicate]

Thank you for laying out the options so clearly. As I mentioned before, the host job ftps files to and from various other (*nix and Wintel) systems. I work with those other systems. If you need anything from C#/.Net to ESB/SOA, I'm the guy to call. But before last week, I didn't know JCL from jingle bells (and obviously still don't).

It's impossible to overstate the inertia in an organization where a) everything is running more or less correctly (operators rerun any jobs that fail), and b) any thing that doesn't run smoothly generates revenue for the vendor. What I'm saying is that suggestions to have this or that group do something probably make sense in most organizations, but I don't think it's going to work here. I wish I could just turn this over to the mainframe team but I'm afraid we're on our own in my group. Basically I'm limited to working with the job and procs under my control, ans submitting them to run under whatever it is that runs them (OPCA, I'm told).

They say if you want something done.... So I got a copy of the job and proc, which for some reason my group owns. They were probably written by the vendor and turned over to us, since no one here has the skills to have written them. I got a JCL manual, absorbed the basics, looked up if/then/else, and figured out how to get BXPBATCH to run sleep in a Unix shell. I put in the ftp retry logic. Everything worked exactly as expected, except the job completion code never changed, and the Blackberry still kept beeping in the middle of the night. All I wanted to do was set my job completion code to 0. I never imagined it would be difficult, let alone impossible.

As a programmer, I expect to be able to control more or less what my programs and scripts do, but JCL is an alien world. I'm still trying to wrap my head around the fact that the job completion code is set to the highest code returned by any step, and there's nothing you can do to change it. Some of the suggestions have been along the lines of "you should rewrite the whole thing in glorbrik and run it under twizzleblat." While I appreciate someone taking the time to respond, I have zero mainframe background, so it means nothing to me (and apparently there are some who take offense at that).

So, to answer your question, (re)writing something in REXX or anything else is beyond my current skill set, and even if there were someone here who knew how to do it, they have there own problems to deal with. And it hasn't gone unnoticed by my manager that this isn't what I'm getting paid to do.

I wish there were another solution, but it looks like I'm stuck. If I do come up with something, I'll post it here.

To those who offered advice, thank you. You've been very patient with me and very generous with your time.

OK. But don't run. Maybe we try to get to the best with the JCL option?

I'd suggest, like enrico, to split your job into three seperate jobs. You have stuff in the first part of the job, which has to complete, else it is a problem. You have stuff at the end of the job, which has to complete, else it is a problem.

Then there is the stuff in the middle, which can fail from time-to-time. Doing this makes any restarts simpler, makes it easy to know what to worry about and what just to toss on again.

Then you are down to the tricky part. You want to know, or OPS to know, that at least one of the FTPs was succesful. You will still have a problem getting only non-zero return codes/reason codes/condition codes. So, how about making that a virtue, if you can't get around it. You have the IDCAMS code/JCL from Mr Spock (setting MAXCC). IDCAMS is a utility for doing things to VSAM files. The things that you do set the "code", which is then returned to the JCL. The "standard" for these codes is 0, 4, 8, 12, 16 in "severity" sequence. The space in between is so that you can add other codes. Curiously, I've never seen it done. How about choosing something between 1 and 3 (inclusive) for your "successful" status. Not perfect, but maybe workable.

Have a good weekend. Toodle pip, if you're in the UK.

PS. Tell your manager that what you are doing is pretty advanced for a JCL beginner.

Will anything done with IDCAMS/MAXCC change the job completion code from 166 to something lower? The problem is not with the operators, but the automated step (of which I have no knowledge at all) that sees a non-zero code and injects a ticket into the system.

No - IDCAMS will NOT change the highest return code. Once a step has finished the return code is set in stone. However - OPC (OPCA/TWS/Tivoli Work Station all the same thing) can be told to ignore certain return codes so probably best to chat with your OPC guys and tell them what you want.

Rexx could be a useful thing to learn - it is available on so many platforms from PDAs to mainframe.

NicC got there first. At least I now know how I lose postings. Didn't lose it this time, just not needed.

What NicC said, though I don't know anything about Tivoli myself. If that is where you are getting paged from, you should be able to turn it off for a specific return codes. Non-zero codes are not uncommon.

Maybe REXX runs on your Blackberry, I don't know It is really a nice language. Powerful. Look around on the internet, there is software, manuals and lots of examples etc. You'll pick it up in no time.

Tim, for what it's worth, I feel your frustration. I know that I'm always in the minority about this, but I think that what you're going through is exactly what's wrong with the current state of affairs in IT. You are, by your own admission, a programmer. As a programmer, you should be writing code, spec'ing your applications, working with the end users, etc. That's what you're paid to do. You shouldn't have to be writing JCL or defining batch schedules, and you certainly shouldn't be managing data transfers. Production Supports specialists ought to handle the first part (and taking those after-hours problem calls) and Data Transfer/Integration specialists ought to be handling the data exchange processes between systems. Companies keep downsizing and removing those necessary specialty roles, unrealistically expecting everyone who's left to have expertise in everything, to be a "Jack of all trades, master of none". I don't know how IT can survive in this mode. I see here every day people who are working outside of their area of expertise and don't have the knowledge or background experience to know what they're supposed to do. And, in my opinion, they shouldn't have to.

Silly me, your 166 is already identifiable enough. Plus, when I suggested setting between 1 and 3, it wouldn't work as any of those options are slightly less than 166. Wouldn't even give you anything trying to mask a RC 4. Brainless.

If you want to conceptualise the problem, say that you run a binary from your unix prompt. It processes a number of parameters and returns a result to you. You then say, but it would be best if the result was zero. Your only option would be to change the parameters. Getting back to the JCL, the only way to get a zero from the FTP is to do it under program control. You don't have time/knowledge to do that, so talk to the man who can stop a 166 in your proc from setting off the Blackberry IF one of your retries has been successful.

I'd still recommend the split enrico suggested. It is more reassuring to isolate the part that is behaving badly and makes restarts easier. If you don't have time to do it now, "raise a fault" (or whatever term your site uses) for it, maybe also for putting it under program (rexx) control. It doesn't have to be much of a program, but it is the only way you can (nearly) guarantee a zero from your FTP step in the future.