IBM Mainframe Forum

steve-myers wrote:If you're not sure of something, try it! Here's my take, though it has not been tested.

Thanks for the help. It's actually much harder than you might think for me to try something, since I need to get four other people involved, as well as management approval. My "program" is really just IEFBR14 (which is listed on wikipedia) with a single instruction changed. My question is really just the simple one a few messages back: does it load 4000 into a register?

But since you were kind enough to suggest some code, I have a question. Based on my very limited research, I thought LA meant Load Address. Can that instruction be used to load an immediate operand (or whatever IBM calls this scenario)?

Tim wrote:I'm trying to write a short program that will set a completion code of 4000 (0xFA0). Will this do it? (Plagiarized from http://en.wikipedia.org/wiki/IEFBR14). Thanks!

Select all

JRC4000 START
        USING JRC4000,15
        B     GO
        DC    AL1(L'ID)
ID      DC    C'JRC4000'
        DS    0H
GO      L     R15,=x'FA0'
        BR    14
        END   JRC4000

Actually, it won't. =X'FA0' generates a two byte data area. I will assume the two bytes after X'FA0' are binary 0s, so what you are doing is the equivalent of L 15,=X'FA00000', so you're not getting the return code you expect.

Tim wrote:But since you were kind enough to suggest some code, I have a question. Based on my very limited research, I thought LA meant Load Address. Can that instruction be used to load an immediate operand (or whatever IBM calls this scenario)?

Oh, yes, it's used for that purpose all the time, just the size of the immediate operand is less than 4096.

Apologies for not mentioning any Assembler code in this posting...

Tim wrote:I never did understand what was going on with IDCAMS. I looked it up and found it is used to generate and modify datasets, but figured maybe this was some trivial use of the program.

Correct and correct. Or a trivial amount of "code" in the IDCAMS. The JCL around it would ensure that you got a particular step which would finish with a particular return code (zero) when any of your three FTP steps had completed with a zero return code.

"obviously this can't be done as instream, but hopefully you get the gist"

This was before we knew you were new to JCL. In a PROC you can't have "instream data" (DD *), ie you can't have "data cards" in you "run deck" like you can outside of a "Stored PROCedure". It is easy to "get around" this (there is nothing to actually get around, it is the way it works) - the usual way is to store the "card data" in a member on a PDS. Then instead of "DD *" you have ""DD DSN=my.pds.name(mymem),disp=shr". You'll see examples if you look at someone's SORTs in a PROC.

Tim wrote:the end result was to return a completion code of 0, which as I now understand things, wouldn't have helped since the job completion code was still going to be the highest value from any step in the job.

The (more) important thing was the JCL. Specifically the "IF". This would give you a step which would complete with an RC of zero if one of any of the three FTP steps was successful. So any software/human that was monitoring the situation could check in one place and see a zero code to know successful.

Now, when you have organised all your extra guys, you are going to need some JCL to run JRC4000. 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. Maybe you have nothing afterwards. So OK. 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.

So, if JOB1 and JOB3 (if it were to exist) have zero, JOB2 has 4000, then all is well and the Blackberry doesn't even tremble. If it still does, whisper "piecrust" or "custard" in a menacing sort of way.

It makes no nevermind to me what language you use for your new extra step. IDCAMS might require fewer additional people. Assembler is fine, or indeed any language which runs in that operating envioronment is fine. You'll still need JCL for it, and the important part (OK, probably not the only way, but a neat way) is the IF in posting 5 from the first thread.

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:

NBAT*.*.*.4000

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.

Good luck and well done. I guess you're not even on a bonus? Still think with your gem in one place, rather than three, with the JCL IF... but both will work, which is what you want.