MVSFORUMS.com

mfnerd · Beginner Joined: 06 Jan 2003 Posts: 8 Topics: 6

I've some jobs using os/vs cobol programs and the return codes from those jobs are weird.Example one step has a return code of 56 but to my surprise the job doesn't abend.Any thoughts ?

Thanks.
_________________
Thanks,
Mfnerd.

taltyman · Posted: Thu Sep 04, 2003 3:02 pm Post subject:

The program can set whatever RC it wants to. For example we have a program that simply sets the RC to the numeric day of the week.

Mike · Posted: Thu Sep 04, 2003 5:36 pm Post subject:

I'd put it this way, there is no such thing as a wierd condition code, just conditions codes that you haven't encountered before. A condition code can be any number between 0 and 4095. No condition code means anything in general (perhaps 0 could be considred the exception, however a program could be written to issue a 0 in the case of an abnormal situation, if that were desired), although frequently people conisder 4 or less to be acceptable and 8 or greater to be severe.

In addition to Taltyman's reply a program can also issue abends, generally USER abends, something which is quite distinct from a return code (or in my opinion should be considered as such). I believe that the distinction should be that a return code should signify an event that has been handled which may then require different paths to be taken. Abends should indicate that something severe has happened and that processing should stop.

However more and more it seems that the grey area between the two widens and has virtually, or even has, encompassed both. Or is it that I'm just getting too old Smile

_________________
Regards,
Mike.

RonB · Posted: Fri Sep 05, 2003 2:03 pm Post subject:

The "usual" reason for "weird" return codes is the failure of a program to EXPLICITLY move a value to General Register 15 prior to ending. For COBOL programs Register 15 is set by moving a numeric value to the RETURN-CODE special register just before the GOBACK statement. For an assembler program, this is done by moving a numeric value to General Register 15 before returning to its invoking program. If R15 ( RETURN-CODE ) is NOT explicitly set, whatever value it contains when the program terminates, is considered that program's return code. The contents of R15 could be an address, or any other value stored there during processing. When a COBOL program calls another module, that module's return code ( R15 ) is automatically move to RETURN-CODE when it returns, so that it may be tested by the COBOL program. Perhaps that is what your problem is - residual value in RETURN-CODE due to a CALL.

Ron
_________________
A computer once beat me at chess, but it was no match for me at kick boxing.

Dibakar · Posted: Mon Sep 08, 2003 3:27 am Post subject:

If it is R15 then why is RC between 0 and 4095?

Brian · Beginner Joined: 12 Aug 2003 Posts: 95 Topics: 6

Dibakar,

RETURN-CODE is a S9(4) COMP variable. All negative return codes are represented by its equivalent 2's complement value.

MOVE -40 TO RETURN-CODE would return 4056 (4095 - 40) + 1.

Hope this answers your question.

Dibakar · Posted: Tue Sep 09, 2003 12:12 am Post subject:

Brian,

This answers partly.

But my question is if I move X'FFFFFFFF' to RETURN-CODE then what will be the RC? Isn't it much larger than 4095?

Brian · Beginner Joined: 12 Aug 2003 Posts: 95 Topics: 6

Dibakar

When in doubt try Mr. Green

Assume you move a value larger than 4095 the RC would be wrapped around.
MOVE 5095 TO RETURN-CODE should return 999 (5095 - 4095) - 1.

Hope this answers your question.

Dibakar · Posted: Tue Sep 09, 2003 2:19 am Post subject:

Brian,

Sometimes asking is too easy.

Thanks again.
Diba.

slade · Posted: Sat Sep 13, 2003 9:42 am Post subject:

Hi Diba,

My guess is that RC is set with a LH (load halfword) BAL instruction. But, Brian is right "When in doubt try".

Anybody out there have an S9000 in their rec room? Smile

Regards, Jack.

Mike · Posted: Sun Sep 14, 2003 4:51 pm Post subject:

I think, to be safe, you'd use L (load fullword). Just loading half word could leave data in R15, that's assuming that you were loading the register from a memory location. Another alternative is to use LA, this allows you to set a cc using a constant/specific value(e.g. you could do LA 15,8 to set rc=8). To set 0 you could also use SR 15,15 (subtract register).
_________________
Regards,
Mike.

slade · Posted: Sun Sep 14, 2003 9:50 pm Post subject:

Hi Mike,

It's been a long time since I used BAL, but I think the high order bit of the storage data that's loaded is propagated to the remaining bits in the register when an LH is executed. I think that's the way it USED TO WORK, anyway.

Anyway2, your main point my be right, that a Load (L) or Load Address (LA) is used. But it doesn't explain why the RC is limited to 4095 in spite of the fact that an RC > 4095 apparently CAN be created.

Perhaps subsequent processing by the system uses a STH or LH. A lot of these limitations were generated back when saving a halfword here and there was a big deal. Smile

Regards, Jack.

Mike · Posted: Sun Sep 14, 2003 10:30 pm Post subject:

Hi Jack,
you're right regarding the propogation of the high order/sign bit (I didn't word what I was saying that well, I didn't mean to imply that more data than the half word would be moved (I can see how it could be read that way). I meant to say that LH and L are used if the RC was stored in memory, as opposed to LA where the RC is hard coded.

I think, but I'm not sure, that the limitation of 4095 is more to do with JES/JCL storing the code intetnally as a halfword. If I had the time I'd write a quick program to see if passing a return code greater than 4095 is possible between modules (my guess is that it would be). Just a little busy at present. I'd put it in the same class as why job names are limited to 8 chars etc etc etc Smile

_________________
Regards,
Mike.

Bill Dennis · Posted: Mon Sep 15, 2003 4:29 pm Post subject:

Anything higher than 4095 spills over into the SYSTEM abend bits. If you load too large a value, you can see BOTH a system and user abend code at the same time.

Regards,
Bill

Dibakar · Posted: Tue Sep 16, 2003 5:07 am Post subject:

Thanks Bill. That clears my doubt.

Regards,
Diba.