BillyBoyo wrote:What JCL are you going to use and what is going to happen (elsewhere) after RC goes to 4000 (that couldn't be done with 166)? Now, if you do have anything in your PROC/JOB after the FTP/JRC then any non-zero return codes (whatever we call them) are going to be "hidden" by the 166/4000.
It's never been my intention to eliminate the 166 job completion code, or to find some way to ignore it. Let me describe the scenario assuming all my mods are in place and working. If the ftp is attempted and succeeds, the job completion code is 0 and we're done. If the ftp is attempted, and fails, and is retried, and fails again, then the job should (and will) return 166, because something really is wrong, and the alert really should be generated.
Now for the interesting case. If the ftp is attempted, and fails, and is retried, and succeeds, what happens? The RC for the first ftp is 166, but the RC for the retry is 0. I had hoped to return 0 as the job completion code at that point, but it doesn't work that way--the completion code is going to be the highest RC encountered in any step, in this case 166. It took awhile for me grasp that I couldn't simply set the job completion code to whatever I wanted (in fact, I still have some trouble with that). So my job returns 0 on immediate success, 166 on failure, and 166 on success after a retry. There's no way to distinguish those last two cases. I wanted a 0 on success with a retry, but JCL doesn't work that way. It looked like I was stuck.
Or so I thought. While I can't force the completion code to 0, it turns out I CAN force it to any value HIGHER than 166, such as 4000. Either my little assembly gem (if I can get the single instruction I wrote myself right), or apparently IDCAMS, can be used for this purpose. After a successful ftp retry, I could run the gem or IDCAMS and force the completion code to 4000. Well, that's something. Can I use it?
I can! With some more research, I learned it's possible to (forgive me if I have the details or terminology wrong here) tell OPCA to ignore (or treat as successful) jobs ending with certain specific completion codes. Somewhere, someone can add a line to a file that looks something like this:
All my jobs begin with NBAT, so that first * must be a wildcard, and the 4000 is the code I want ignored. I don't know what the middle two stars are for. Then end result is that my job returns 0 on immediate success, 166 on failure, and 4000 on success after a retry. OPCA will only generate the alert on the true failure indicated by the 166.
Now all I have to do is figure out how to get the NBAT line added to whatever it needs to be added to.
BillyBoyo wrote:But if you do, that is why we suggested splitting it out of the job. And any stuff before the FTPs. So you end up with a short PROC in a short JOB which is a potential (insert suitable expression here, it seems I am unable to communicate about that) and one (or two, depending on whether you have "stuff" (I know JCL isn't called "stuff") after the FTPs) JOB(s) which should only get zero RCs.
The job has two steps: run the ftp proc, then set a flag upon completion. The ftp proc has two steps: do whatever JCL incantation is needed to create some file space, then run the actual ftp. I don't see how that can be split up. If you add in the retries, maybe they could be split off, but I don't see the advantage, and it doesn't solve the basic problem that we need to distinguish a complete failure from a successful retry. And even if there were an advantage, the complexity factor has already exceeded my meager skill set.
Thanks for taking the time to help me through this! If it works, it will save the company about $7K per year in ticket charges. ("Wow, wouldn't management want to support that effort!?") Yeah, you'd think that, wouldn't you? The best case scenario is I don't get chewed out for not working on my own stuff this past week.