How can i handle Variable Parameters List

manjul · New User Joined: 24 Apr 2007 Posts: 13 Location: Noida

I have a sub program that is written in Assembly, We can call this module in our COBOL program with multiple variables,
e.g.
CALL 'PGMABC' USING PARM-A

CALL 'PGMABC' USING PARM-A
PARM-B

CALL 'PGMABC' USING PARM-A
PARM-B
PARM-C

Since Assembly code has a mechanism to go and check high order bit of variable address, if it is 1 then it is assumed to be the last parameter.

My Problem is, I have to convert this code in COBOL. now can some one tell me how i can handle this variable parameter list problem. In my case no of variable parameter in any call is up to 175.
Note:- I dont want to change my calling program.
Please help.

dbzTHEdinosauer · Posted: Thu Nov 05, 2009 3:54 pm

manjul · New User Joined: 24 Apr 2007 Posts: 13 Location: Noida

Actually I can't change my calling modules. List of calling modules is very large.

Bill O'Boyle · Posted: Thu Nov 05, 2009 4:55 pm

In the called COBOL version of the sub-program, try checking for parameter addressability/non-addressability via -

GuyC · Posted: Thu Nov 05, 2009 5:01 pm

I'm not sure , but I think you can test

if address of ls-parmB = null
then make sure you don't use any field from parmB
end-if

It's been a while since I messed with pointers in cobol, so you'll have to test it yourself

(oops double posted the same answer)

manjul · New User Joined: 24 Apr 2007 Posts: 13 Location: Noida

We have tried
01 VAR-PTR POINTER.

SET VAR-PTR TO ADDERSS OF PARM-A

IF VAR-PTR EQUAL TO NULL
|
|

BUT WE ARE GETTING GARBAGE VALUES IN IT.

This is not helping. Any other suggestions

Bill O'Boyle · Posted: Thu Nov 05, 2009 5:27 pm

The OPTIMIZE compiler option may ensure a NULL ADDRESS for a PARM not passed.

Do you compile your programs using NOOPT or OPT compiler option?

NOOPT may not clear these addresses, whereas, OPT just might, as this would be in line with the Optimizing feature of the compiler.

However, you'll have to give it a try as this is just a guess....

Bill

manjul · New User Joined: 24 Apr 2007 Posts: 13 Location: Noida

This i can try and will update you on this. Thanks.

manjul · New User Joined: 24 Apr 2007 Posts: 13 Location: Noida

Below are my COMPILER Options,
28 XXCOB EXEC PGM=IGYCRCTL, * ** COBOL FOR MVS & VM COMPILER **
XX PARM=('APOST,MAP,NAME,NUMPROC(MIG),&LIST,OPT',
XX 'TERM,RENT,NOSEQ,TRUNC(BIN),XREF(SHORT)'),
XX REGION=4096K

I guess we are already using OPT option. This is not helping.

dbzTHEdinosauer · Posted: Thu Nov 05, 2009 5:52 pm

instead of

Robert Sample · Posted: Thu Nov 05, 2009 6:09 pm

Deja vu all over again. This issue came up in October 2008. From back then, the subroutine:

dbzTHEdinosauer · Posted: Thu Nov 05, 2009 6:21 pm

This new COBOL module that you are writing consists of

determining which linkage items have been passed
determining which routine to use to process the CALL
the routines to process the data

1 and 3 are easy, though you are making 1 impossible.
2 will require some effort; what do you have in mind?

dbzTHEdinosauer · Posted: Thu Nov 05, 2009 6:41 pm

Binop B · Posted: Thu Nov 05, 2009 6:58 pm

Binop B · Posted: Thu Nov 05, 2009 7:13 pm

Hi,

I was just thinking about another strategy ??

How about having an Assembler program in between the CALLing and the CALLed COBOL program. If Assembler can handle the particular scenario, why not use the Assembler program to validate the parameters from the CALLing program and ensure that 175 parameters is passed to the COBOL CALLed program where the functional processing will be done...

Bill O'Boyle · Posted: Fri Nov 06, 2009 4:27 am

You could do that and perhaps a TM X'80' can be issued to test the end of the parmlist. But there's a bigger problem, which Dick spoke of above.

How would the Assembler sub-program know whether the caller passed PARM-004, PARM-013, PARM-033 and PARM-100 or a completely different combination?

There's no way to tell them apart, except to include code in the sub-program, which would establish addressability and then check somewhere in the data, for some sort of eyecatcher. This will then add intelligence to the sub-program and it could then build the parmlist for the COBOL sub-program, consisting of 175 addresses, with some being valid addresses (like for the PARM example above) and the remaining set to X'00's.

When the COBOL sub-program gains control from this intermediate Assembler sub-program, then all 175 parm-addressees must be checked for NOT NULL (the given parm was passed) or NULL (the given parm was not passed).

It is worth noting that you need to leave R12 alone in the Assembler sub-program, because it contains the address of the LE 'COMMON ANCHOR AREA', which will be needed by COBOL. Otherwise, if R12 is corrupted and/or compromised, you'll crash and burn.

If at all possible, perhaps try to make the Assembler sub-program LE compliant and then you won't have to worry.

Good Luck....

Bill

Binop B · Posted: Fri Nov 06, 2009 7:28 am

manjul · New User Joined: 24 Apr 2007 Posts: 13 Location: Noida

Solution from Robert works fine. Thank you to all of you to participate in the discussion.

manjul · New User Joined: 24 Apr 2007 Posts: 13 Location: Noida

Soory to say guys...... Even Solution from Robert Did't work out well.... I tried one small test case that was working initally but as soon as i tried it to test with more variables it failed.........

We have changed our approch to this problem now we are changing our calling program with fix no of parameters.

Thanks for all your efforts and time you have spend.