[comp.os.vms] passing strings from COBOL to Pascal

sommar@enea.se (Erland Sommarskog) (07/17/88)

The scene: I have several Cobol modules that call this same Pascal
module. Thus, all tricks should be on the Pascal side.    
  All Cobol modules have the same appearance, only the contents of 
the strings vary beside a message code. Basically I want to write:
     CALL "Pascal_routine" USING                Specific_msg_code, 
                                 BY <mechanism> "specific text" 
                           GIVING Ret_status
I don't want to explicitly mention the length of the string parameter,
since it could be a source of error. (One changes the string, but for-
gets to the change the length.)
  On the Pascal side I don't want to make any assumptions about the
maximum length of the string, so accordingly I use a conformant schema.
I tried various combinations of passing mechanism, PACKED/VARYING and
VAR/non-VAR, but none of them worked as desired. Best was by descriptor
and a Pascal declaration like: 
     (. Global .) 
     FUNCTION Pascal_routine(    Code : integer;
                             VAR Str  : VARYING(.$len.) OF char) : integer;
  What Cobol put in the parameter area for the string was an address.
On that address one could find the length of the string. *Behind* this
word, was the string itself. On the Pascal side this became, assuming 
the string "ABCDEF":
     $len :      6
     Str.length: 256*66 + 65
     Str.body:   "DCEF''(0)''(6)" 
The debugger presented the string to me as "ABCDEF", though. (If I used 
a PACKED ARRAY instead, both Pascal and debugger considered the Cobol 
descriptor as totally invalid.)

My solution was to add a routine within Pascal-routine that took
care of the string. Unfortunately, this meant I had to decide a 
maximum length, which in this case was acceptable, but next time it 
may not. And, no, it is not possible to shuffle around in Str. Cobol
places the string in low read-only memory.

Now, what should I've done? Is it just that it is impossible? 
-- 
Erland Sommarskog           
ENEA Data, Stockholm        
sommar@enea.UUCP            
"It all looks quite impressive really, but is it really necessary?" Radio Stars

kend@umbc3.UMD.EDU (Ken Dahl) (07/19/88)

In article <3744@enea.se> sommar@enea.se (Erland Sommarskog) writes:
>The scene: I have several Cobol modules that call this same Pascal
>module. Thus, all tricks should be on the Pascal side.    
>  All Cobol modules have the same appearance, only the contents of 
>the strings vary beside a message code. Basically I want to write:
>     CALL "Pascal_routine" USING                Specific_msg_code, 
>                                 BY <mechanism> "specific text" 
>                           GIVING Ret_status
>and a Pascal declaration like: 
>     (. Global .) 
>     FUNCTION Pascal_routine(    Code : integer;
>                             VAR Str  : VARYING(.$len.) OF char) : integer;

The mechanism you want to use in the COBOL Call statement is DESCRIPTOR.
In the Pascal function declaration, you should add %REF before CODE since
COBOL passes arguments by REFERENCE by default, and add %STRDESCR before
STR since the string will be passed by descriptor.


For more help, you can check the COBOL (section 6) and Pascal (section 7)
reference manuals.

kend@umbc3.UMD.EDU (Ken Dahl) (07/22/88)

As Erland Sommarskog pointed out, the %descr that I suggested won't work
when declaring a Pascal function that is not external.  I tried some testing
with different attributes in Pascal and successfully passed a string to
Pascal from COBOL using:

Procedure PrtString(VAR code : integer;  (* Cobol passes by ref *)
                    VAR str  : [class_s] packed array [l..u:integer] of char);


this could easily be written as a function to do what Mr. Sommarskog needs.  In
addition to passing the string correctly, the lower and upper bounds of the
string are passed as well (as l and u respectively in this example).


-- 
------------------------------------------------------------------------------
Kenneth Dahl
ARPANET: kend@umbc3.umd.edu                                  BITNET: KEND@UMBC
My opinions are not necessarily those of the University of Maryland...