IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

How can i handle Variable Parameters List


IBM Mainframe Forums -> COBOL Programming
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
manjul

New User


Joined: 24 Apr 2007
Posts: 13
Location: Noida

PostPosted: Thu Nov 05, 2009 3:20 pm
Reply with quote

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.
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Thu Nov 05, 2009 3:54 pm
Reply with quote

Quote:
Note:- I dont want to change my calling program


Pech!
Back to top
View user's profile Send private message
manjul

New User


Joined: 24 Apr 2007
Posts: 13
Location: Noida

PostPosted: Thu Nov 05, 2009 3:59 pm
Reply with quote

Actually I can't change my calling modules. List of calling modules is very large.
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Thu Nov 05, 2009 4:55 pm
Reply with quote

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

Code:

IF  ADDRESS OF PARM-B = NULL

As far as testing for the high-order bit to be 'ON' in the last address in the parmlist, as you've said, this is true in Assembler, but I wouldn't count on COBOL to abide by this as there are things done "under the covers" by the compiler.

In other words, there are no guarantees.

Bill
Back to top
View user's profile Send private message
GuyC

Senior Member


Joined: 11 Aug 2009
Posts: 1281
Location: Belgium

PostPosted: Thu Nov 05, 2009 5:01 pm
Reply with quote

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)
Back to top
View user's profile Send private message
manjul

New User


Joined: 24 Apr 2007
Posts: 13
Location: Noida

PostPosted: Thu Nov 05, 2009 5:21 pm
Reply with quote

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
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Thu Nov 05, 2009 5:27 pm
Reply with quote

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
Back to top
View user's profile Send private message
manjul

New User


Joined: 24 Apr 2007
Posts: 13
Location: Noida

PostPosted: Thu Nov 05, 2009 5:29 pm
Reply with quote

This i can try and will update you on this. Thanks.
Back to top
View user's profile Send private message
manjul

New User


Joined: 24 Apr 2007
Posts: 13
Location: Noida

PostPosted: Thu Nov 05, 2009 5:37 pm
Reply with quote

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.
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Thu Nov 05, 2009 5:52 pm
Reply with quote

instead of
Code:

SET VAR-PTR TO ADDERSS(sic) OF PARM-A
IF VAR-PTR EQUAL TO NULL

try using
Code:

IF ADDRESS OF PARM-A = NULL


and since PARM-A is part of LINKAGE,
if the ADDRESS OF PARM-A NOT = NULL
then you already have access to the area.

Why are you using a pointer????????????
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA

PostPosted: Thu Nov 05, 2009 6:09 pm
Reply with quote

Deja vu all over again. This issue came up in October 2008. From back then, the subroutine:
Code:
      LINKAGE SECTION.
      01  LS-PARM-01                  PIC X(08).
      01  LS-PARM-02                  PIC X(08).
      01  LS-PARM-03                  PIC X(16).
      01  LS-PARM-04                  PIC X(16).
     /
      PROCEDURE DIVISION              USING LS-PARM-01
                                            LS-PARM-02
                                            LS-PARM-03
                                            LS-PARM-04.
      S1000-MAIN       SECTION.
          IF  ADDRESS OF LS-PARM-04 = NULL
              DISPLAY '3 PARAMETERS PASSED'
              DISPLAY 'LS-PARM-01 = ' LS-PARM-01
              DISPLAY 'LS-PARM-02 = ' LS-PARM-02
              DISPLAY 'LS-PARM-03 = ' LS-PARM-03
          ELSE
              DISPLAY '4 PARAMETERS PASSED'
              DISPLAY 'LS-PARM-01 = ' LS-PARM-01
              DISPLAY 'LS-PARM-02 = ' LS-PARM-02
              DISPLAY 'LS-PARM-03 = ' LS-PARM-03
              DISPLAY 'LS-PARM-04 = ' LS-PARM-04
          END-IF.
          GOBACK.
and the calling program:
Code:
      WORKING-STORAGE SECTION.
      01  WS-VARIABLES.
          05  WS-PARM-01              PIC X(08) VALUE 'PARM1111'.
          05  WS-PARM-02              PIC X(08) VALUE 'PARM2222'.
          05  WS-PARM-03              PIC X(16) VALUE 'PARM3333'.
          05  WS-PARM-04              PIC X(16) VALUE 'PARM4444'.
     /
      PROCEDURE DIVISION.
      S1000-MAIN       SECTION.
          DISPLAY 'MF0028 STARTING WITH 3-PARM CALL'.
          CALL 'MF0028S' USING WS-PARM-01
                               WS-PARM-02
                               WS-PARM-03
                               .
          DISPLAY 'MF0028 CONTINUING WITH 4-PARM CALL'.
          CALL 'MF0028S' USING WS-PARM-01
                               WS-PARM-02
                               WS-PARM-03
                               WS-PARM-04
                               .
          DISPLAY 'MF0028 ENDING'.
          GOBACK.
and the output:
Code:
 MF0028 STARTING WITH 3-PARM CALL
 3 PARAMETERS PASSED
 LS-PARM-01 = PARM1111
 LS-PARM-02 = PARM2222
 LS-PARM-03 = PARM3333
 MF0028 CONTINUING WITH 4-PARM CALL
 4 PARAMETERS PASSED
 LS-PARM-01 = PARM1111
 LS-PARM-02 = PARM2222
 LS-PARM-03 = PARM3333
 LS-PARM-04 = PARM4444
 MF0028 ENDING
IIRC, you have to actually test the LINKAGE SECTION address to be NULL -- if you SET the address and then test the variable, you get garbage. I haven't tested that, though, so that is based upon my (possibly faulty) memory.
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Thu Nov 05, 2009 6:21 pm
Reply with quote

This new COBOL module that you are writing consists of
  1. determining which linkage items have been passed
  2. determining which routine to use to process the CALL
  3. 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?
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Thu Nov 05, 2009 6:41 pm
Reply with quote

Quote:
2 will require some effort; what do you have in mind?


reason I ask:

with 175 possible 'passed' parms, that means every CALLing module will require change,


The USING phrase in the PROCEDURE DIVISION of the new CALLed module will have 175 parms.
i.e. USING PARM-1, PARM-2, ... PARM-175

The CALLing module will have CALL new-cobol-program USING PARM-5, PARM-9, PARM-114.

The new CALLed cobol module will assign the address of the first parm of the CALLing list to the first parm of the USING list.

how are you going to tell them apart?

This will not be an easy task.
I suggest rethinking your approach to the assembler to cobol conversion.
most of the time the assembler modules are left and any new functionality is added by creating a new CALL to a new module.

with 175 possible parms, I imagine this assembler module is a monster,
and that is why you are tasked with converting to COBOL.

the assembler module was probably written back in the days when
modularity was a term only applied to work spaces.
Back to top
View user's profile Send private message
Binop B

Active User


Joined: 18 Jun 2009
Posts: 407
Location: Nashville, TN

PostPosted: Thu Nov 05, 2009 6:58 pm
Reply with quote

Quote:
The CALLing module will have CALL new-cobol-program USING PARM-5, PARM-9, PARM-114.

As per Manjul's post... my assumption is this situation will never happen... My understanding was whatever is passed first is the first parameter... whatever is passed second is the second parameter... so on... icon_smile.gif

Also practically... I feel this would not be the case... icon_razz.gif ...
Back to top
View user's profile Send private message
Binop B

Active User


Joined: 18 Jun 2009
Posts: 407
Location: Nashville, TN

PostPosted: Thu Nov 05, 2009 7:13 pm
Reply with quote

Hi,

I was just thinking about another strategy ?? icon_razz.gif

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...
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Fri Nov 06, 2009 4:27 am
Reply with quote

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
Back to top
View user's profile Send private message
Binop B

Active User


Joined: 18 Jun 2009
Posts: 407
Location: Nashville, TN

PostPosted: Fri Nov 06, 2009 7:28 am
Reply with quote

Quote:
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?

Wouldn't the current Assembler routine already have this logic ?
Back to top
View user's profile Send private message
manjul

New User


Joined: 24 Apr 2007
Posts: 13
Location: Noida

PostPosted: Fri Nov 06, 2009 9:33 am
Reply with quote

Solution from Robert works fine. Thank you to all of you to participate in the discussion.
Back to top
View user's profile Send private message
manjul

New User


Joined: 24 Apr 2007
Posts: 13
Location: Noida

PostPosted: Fri Nov 06, 2009 11:54 am
Reply with quote

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.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> COBOL Programming

 


Similar Topics
Topic Forum Replies
No new posts REXX/CMS How to place command console... CLIST & REXX 4
No new posts Starting a PROC with parameters from ... CLIST & REXX 6
No new posts CA7 count with DATE variable CA Products 0
No new posts Extracting Variable decimal numbers f... DFSORT/ICETOOL 17
No new posts How to create a list of SAR jobs with... CA Products 3
Search our Forums:

Back to Top