View previous topic :: View next topic
|
Author |
Message |
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. |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
Quote: |
Note:- I dont want to change my calling program |
Pech! |
|
Back to top |
|
|
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. |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
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 |
|
|
GuyC
Senior Member
Joined: 11 Aug 2009 Posts: 1281 Location: Belgium
|
|
|
|
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 |
|
|
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 |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
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 |
|
|
manjul
New User
Joined: 24 Apr 2007 Posts: 13 Location: Noida
|
|
|
|
This i can try and will update you on this. Thanks. |
|
Back to top |
|
|
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. |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
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 |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
|
|
|
|
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 |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
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? |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
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 |
|
|
Binop B
Active User
Joined: 18 Jun 2009 Posts: 407 Location: Nashville, TN
|
|
|
|
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...
Also practically... I feel this would not be the case... ... |
|
Back to top |
|
|
Binop B
Active User
Joined: 18 Jun 2009 Posts: 407 Location: Nashville, TN
|
|
|
|
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... |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
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 |
|
|
Binop B
Active User
Joined: 18 Jun 2009 Posts: 407 Location: Nashville, TN
|
|
|
|
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 |
|
|
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. |
|
Back to top |
|
|
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. |
|
Back to top |
|
|
|