subject:"LE C calling HLASM"


On 4/10/2012 3:11 PM, Phil Smith wrote:

Steve Comstock wrote:

Slipperier and slipperier. OK, let's try a different approach:



You tell me exactly what you want to see from the PL/I routine calling
your API and I'll see if I can cause PL/I to construct that.



In other words, your routine will see



(R1) ->  


rc = THEFUNCTION(magic,inputbuffer,inputlength)

(R1) ==>  A(magic),A(inputbuffer),A(inputlength)<== high bit set on the third 
fullword

OR (the fully specified case):

rc = THEFUNCTION(magic,inputbuffer,inputlength,outputbuffer,outputlength)

(R1) ==>  
A(magic),A(inputbuffer),A(inputlength),A(outputbuffer),A(outputlength)<== high bit 
set on the fifth fullword

Pretty standard, yes?



Yes. And here's some code:

 psubsrk: proc options(main);

 /*  declare invoked subroutines  */

   dcl thefunction entry external('CATCHER') options(asm retcode);
   dcl pliretv builtin;

 /*  declare data items   */

   dcl magic  fixed bin(31);
   dcl bufone char(1200);
   dcl lenone fixed bin(31) value (1200);
   dcl buftwo char(1600);
   dcl lentwo fixed bin(31) value (1600);

   dcl rslt fixed bin(31);
   dcl msg  char(16) value('Return value is ');

 /*  actual code begins here   */

  call thefunction(magic, bufone, lenone);
  call thefunction(magic, bufone, lenone, buftwo,lentwo);

  rslt = pliretv();
  put list (msg, rslt);

 end psubsrk;


_Notes_

1. CATCHER was an old routine I had around that does the following:
* display an entry message (..In CATCHER)
* display the first seven words pointed at by R1, in hex
* returns a value of '7' for its return code (hard coded)
* display an exit message (..Leaving CATCHER)

2. The output from the run is:

..In CATCHER
..c(R1) = 19C1A4D0
..Seven words at address pointed at by R1 =
: 19C1A500 19C1A504 99C1B074 000B 0001 00B0 
..Leaving CATCHER
..In CATCHER
..c(R1) = 19C1A4D0
..Seven words at address pointed at by R1 =
: 19C1A500 19C1A504 19C1B074 19C1A9B4 99C1B070 00B0 
..Leaving CATCHER
Return value is  7


3. Notice the first time in the third word is x'99C1B074' - the
   end of list bit is on

   the second call of thefunction the third word is x'1C1B074'
   - the end of list bit is not on there, but the fifth word
   is x'99C1B070' - the end of list bit is on

4. The strange values after the parm pointers
   (e.g.: 000B 0001 00B0  in the first call)
   are just random garbage; the compiler does not clear out
   the storage used for the parmlist: it just changes the words
   that actually have parameter entries

So, I think that's pretty straighforward; it's a CALL
instead of a function reference, but it will work. Now,
if you need a function reference I can look into it some
time.


--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PL/I with variable PLISTs (was: LE C calling HLASM)

On 4/10/2012 4:33 PM, Frank Swarbrick wrote:

- Original Message -

From: Phil Smith
To: IBM-MAIN@bama.ua.edu
Cc:
Sent: Tuesday, April 10, 2012 3:31 PM
Subject: Re: PL/I with variable PLISTs (was: LE C calling HLASM)

Bernd Oppolzer wrote:

I don't know if it helps you, but using C I would code the two calls

this way:

rc = THEFUNCTION (&magic, inputbuffer,&inputlength, NULL, NULL);

Exactly backwards-the idea here is to NOT be obscure, but to have a nice,
flexible, intuitive API. Having to specify null parameters or to use a macro for
things is what we *don't* want to do.

Haha, I can agree with that!

Funny thing with Enterprise COBOL... It "properly" sets the high-order bit
on

the last parm, but supplies no way to interrogate it! So if "THEFUNCTION" was

written in COBOL then you have to invoke it thusly:

CALL 'THEFUNCTION' USING MAGIC, INPUT-BUFFER, INPUT-LENGTH, OMITTED, OMITTED
RETURNING RC.

(The OMITTED keyword simply passes an address of NULL.)

Oy!

Well, there is a little trick you use, involving defining the
trailing parameters as pointers coming in by value, on the
procedure division header name the pointers not the items,
defining items you expect in linkage, redefining a binary
item on top of the pointers, to access one of the data items
use 'set addres of data_item to pointer', when you're done
with an item check if the redefined (binary version) is
negative - that indicates the end of list bit is on.

No problem.

:-)

Frank

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PL/I with variable PLISTs (was: LE C calling HLASM)

We don't have PL/I in our shop (I downloaded an old "trial" version of 
VisualAge PL/I for Windows to play with at home), but it seems to me that one 
MIGHT be able to do the following for PL/I to call DL/I:

declare CEETDLI entry linkage(SYSTEM);
or perhaps
declare CEETDLI entry(char(4), *, *, *, *, *, *, *, *, *, *) linkage(SYSTEM);

Then call without passing the number of parms:

call CEETDLI(ghnp, pcb-mask, i-o-area, ssa-1 ssa-2);

I am assuming that LINKAGE(SYSTEM) does indeed set the high-order bit in the 
last parm.
I used CEETDLI rather than PLITDLI because I know it can be called from "any" 
language (COBOL, PL/I, Assembler, maybe C and Fortran), so it can obviously(!) 
handle the high-order bit indicator.


I would be vary curious to have someone with both PL/I and IMS test this out.

Frank



- Original Message -
> From: Bernd Oppolzer 
> To: IBM-MAIN@bama.ua.edu
> Cc: 
> Sent: Tuesday, April 10, 2012 5:31 PM
> Subject: Re: PL/I with variable PLISTs (was: LE C calling HLASM)
> 
> Ok, this is one thing; needs probably some claryfying from IBM.
> 
> But, as Frank mentioned in the other post:
> 
> I think the high order bit is really needed in the PLITDLI case,
> because the number of parameters is not fixed and cannot be
> derived from the other parameters in every case (I guess, the number
> of SSAs is really variable on the GET request, and the high order bit on
> the last SSA marks the end of the list - only speculating; I know almost
> nothing about IMS).
> 
> So we here have a design where the API relies heavily on the OS/360
> high order bit mechanism. Languages that do not set the high order bit
> on the last parm address must prefix the address list with the parmcount,
> so that the DLI interface knows the number of the parameters.
> 
> My opinion is: there are languages that even don't support variable length
> parameter lists. But you always find a way to overcome this restriction;
> for example: you could pass an array of SSAs as a single parameter
> in the case of the IMS GET request (together with a number of entries).
> This is what I would normally do in C - starting address of the array and
> number of elements, two parameters. You don't really need variable
> length parameter lists - they are comfortable sometimes, like with
> printf etc, but you can live without them.
> 
> Kind regards
> 
> Bernd
> 
> 
> 
> Am 11.04.2012 01:07, schrieb Paul Gilmartin:
>>  On Wed, 11 Apr 2012 00:48:33 +0200, Bernd Oppolzer wrote:
>> 
>>>  I would not blame PL/1 for this.
>>>  It is not OK IMHO to request the caller to set the
>>>  high order bit on the last parameter, when the number of the parameters 
> is fixed
>>>  (see also my GDDM example on the other post). This is not required by
>>>  any OS convention,
>>>  at least that's my understanding.
>>> 
>>  It's inconsistently deprecated.  In:
>> 
>>       
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2a7b0/5.1.8
>> 
>>       5.0 ATTACH and ATTACHX -- Create a new task
>>       Subtopics:
>>       * 5.1 Description
>> 
>>       Specify VL=1 only if the called program can be passed a variable 
> number
>>       of parameters. VL=1 causes the high-order bit of the last address to 
> be
>>       set to 1; the bit can be checked to find the end of the list.
>> 
>>  Note the word "only".  But this admonition appears for ATTACH, 
> but not
>>  for CALL.  Is there any rationale for this difference, or is an RCF in 
> order?
>>  (I haven't checked LINK nor XCTL; they're in a different volume.)
>> 
>>  -- gil
>> 
>>  --
>>  For IBM-MAIN subscribe / signoff / archive access instructions,
>>  send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PL/I with variable PLISTs (was: LE C calling HLASM)


Ok, this is one thing; needs probably some claryfying from IBM.

But, as Frank mentioned in the other post:

I think the high order bit is really needed in the PLITDLI case,
because the number of parameters is not fixed and cannot be
derived from the other parameters in every case (I guess, the number
of SSAs is really variable on the GET request, and the high order bit on
the last SSA marks the end of the list - only speculating; I know almost
nothing about IMS).

So we here have a design where the API relies heavily on the OS/360
high order bit mechanism. Languages that do not set the high order bit
on the last parm address must prefix the address list with the parmcount,
so that the DLI interface knows the number of the parameters.

My opinion is: there are languages that even don't support variable length
parameter lists. But you always find a way to overcome this restriction;
for example: you could pass an array of SSAs as a single parameter
in the case of the IMS GET request (together with a number of entries).
This is what I would normally do in C - starting address of the array and
number of elements, two parameters. You don't really need variable
length parameter lists - they are comfortable sometimes, like with
printf etc, but you can live without them.

Kind regards

Bernd



Am 11.04.2012 01:07, schrieb Paul Gilmartin:

On Wed, 11 Apr 2012 00:48:33 +0200, Bernd Oppolzer wrote:


I would not blame PL/1 for this.
It is not OK IMHO to request the caller to set the
high order bit on the last parameter, when the number of the parameters is fixed
(see also my GDDM example on the other post). This is not required by
any OS convention,
at least that's my understanding.


It's inconsistently deprecated.  In:

 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2a7b0/5.1.8

 5.0 ATTACH and ATTACHX -- Create a new task
 Subtopics:
 * 5.1 Description

 Specify VL=1 only if the called program can be passed a variable number
 of parameters. VL=1 causes the high-order bit of the last address to be
 set to 1; the bit can be checked to find the end of the list.

Note the word "only".  But this admonition appears for ATTACH, but not
for CALL.  Is there any rationale for this difference, or is an RCF in order?
(I haven't checked LINK nor XCTL; they're in a different volume.)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PL/I with variable PLISTs (was: LE C calling HLASM)

2012-04-10 Thread Paul Gilmartin

On Wed, 11 Apr 2012 00:48:33 +0200, Bernd Oppolzer wrote:

>I would not blame PL/1 for this.
>It is not OK IMHO to request the caller to set the
>high order bit on the last parameter, when the number of the parameters is 
>fixed
>(see also my GDDM example on the other post). This is not required by
>any OS convention,
>at least that's my understanding.
>
It's inconsistently deprecated.  In:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2a7b0/5.1.8

5.0 ATTACH and ATTACHX -- Create a new task
Subtopics:
* 5.1 Description 

Specify VL=1 only if the called program can be passed a variable number
of parameters. VL=1 causes the high-order bit of the last address to be
set to 1; the bit can be checked to find the end of the list.

Note the word "only".  But this admonition appears for ATTACH, but not
for CALL.  Is there any rationale for this difference, or is an RCF in order?
(I haven't checked LINK nor XCTL; they're in a different volume.)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PL/I with variable PLISTs (was: LE C calling HLASM)

Well, in the DLI interfaces the number of items passed is NOT fixed.  You can 
pass one or more SSAs on a "get" call (and some others), and some calls do not 
require an SSA at all.  Some don't even require an I-O area.

Frank



- Original Message -
> From: Bernd Oppolzer 
> To: IBM-MAIN@bama.ua.edu
> Cc: 
> Sent: Tuesday, April 10, 2012 4:48 PM
> Subject: Re: PL/I with variable PLISTs (was: LE C calling HLASM)
> 
> I would not blame PL/1 for this.
> It is not OK IMHO to request the caller to set the
> high order bit on the last parameter, when the number of the parameters 
> is fixed
> (see also my GDDM example on the other post). This is not required by 
> any OS convention,
> at least that's my understanding.
> 
> Kind regards
> 
> Bernd
> 
> 
> 
> Am 11.04.2012 00:19, schrieb Frank Swarbrick:
>>  I don't know if this is relevant, but I was looking at the PL/I DL/I 
> (IMS) interface (PLITDLI) and noticed that they actually have to pass, as the 
> first parameter, a fullword containing the remaining number of items!  Crazy!
>> 
>>  For example, in COBOL you say:
>> 
>>  call 'CBLTDLI' using ghnp, pcb-mask, i-o-area, ssa-1 ssa-2.
>> 
>>  In PL/I it looks like you'd do something like this:
>>  call PLITDLI (five, ghnp, pcb-mask, i-o-area, ssa-1 ssa-2);
>> 
>>  See here for more details:
>> 
> http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=%2Fcom.ibm.ims11.doc.apg%2Fims_imsdbpliapp.htm
>> 
>>  I was pretty happy about what I learned about PL/I until I saw this.  Yuck!
>> 
>>  Frank
>> 
>> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PL/I with variable PLISTs (was: LE C calling HLASM)


I would not blame PL/1 for this.
It is not OK IMHO to request the caller to set the
high order bit on the last parameter, when the number of the parameters 
is fixed
(see also my GDDM example on the other post). This is not required by 
any OS convention,

at least that's my understanding.

Kind regards

Bernd



Am 11.04.2012 00:19, schrieb Frank Swarbrick:

I don't know if this is relevant, but I was looking at the PL/I DL/I (IMS) 
interface (PLITDLI) and noticed that they actually have to pass, as the first 
parameter, a fullword containing the remaining number of items!  Crazy!

For example, in COBOL you say:

call 'CBLTDLI' using ghnp, pcb-mask, i-o-area, ssa-1 ssa-2.

In PL/I it looks like you'd do something like this:
call PLITDLI (five, ghnp, pcb-mask, i-o-area, ssa-1 ssa-2);

See here for more details:
http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=%2Fcom.ibm.ims11.doc.apg%2Fims_imsdbpliapp.htm

I was pretty happy about what I learned about PL/I until I saw this.  Yuck!

Frank




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PL/I with variable PLISTs (was: LE C calling HLASM)

- Original Message -
> From: Phil Smith 
> To: IBM-MAIN@bama.ua.edu
> Cc: 
> Sent: Tuesday, April 10, 2012 3:31 PM
> Subject: Re: PL/I with variable PLISTs (was: LE C calling HLASM)
> 
> Bernd Oppolzer wrote:
>> I don't know if it helps you, but using C I would code the two calls 
> this way:
> 
>> rc = THEFUNCTION (&magic, inputbuffer,&inputlength, NULL, NULL);
> 
> Exactly backwards-the idea here is to NOT be obscure, but to have a nice, 
> flexible, intuitive API. Having to specify null parameters or to use a macro 
> for 
> things is what we *don't* want to do.

Haha, I can agree with that!

Funny thing with Enterprise COBOL...  It "properly" sets the high-order bit on 
the last parm, but supplies no way to interrogate it!  So if "THEFUNCTION" was 
written in COBOL then you have to invoke it thusly:

CALL 'THEFUNCTION' USING MAGIC, INPUT-BUFFER, INPUT-LENGTH, OMITTED, OMITTED
RETURNING RC.

(The OMITTED keyword simply passes an address of NULL.)

Oy!

Frank

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PL/I with variable PLISTs (was: LE C calling HLASM)

Pure speculation on my part:

There are some systems or software components that require that on all calls
(even when the number of parameters is fixed) the last parameter address has
the high order bit set. I recall GDDM, where this was the case.

When I wanted to call GDDM routines from PASCAL/VS (in the 80s), this
was a nightmare.
The GDDM routines complained, because PASCAL/VS did not set the high
order bit

on the last parameter address.

I had to generate ASSEMBLER interfaces in between to insert the high
order bit
at the appropriate position - that is: for every GDDM call there had to
be a short
ASSEMBLER stub that knew the number of parameters and inserted the high
order

bit at the proper position.

Maybe the first word in PLITDLI has exactly the same purpose.

Kind regards

Bernd

Am 11.04.2012 00:19, schrieb Frank Swarbrick:

I don't know if this is relevant, but I was looking at the PL/I DL/I (IMS)
interface (PLITDLI) and noticed that they actually have to pass, as the first
parameter, a fullword containing the remaining number of items! Crazy!

For example, in COBOL you say:

call 'CBLTDLI' using ghnp, pcb-mask, i-o-area, ssa-1 ssa-2.

In PL/I it looks like you'd do something like this:
call PLITDLI (five, ghnp, pcb-mask, i-o-area, ssa-1 ssa-2);

See here for more details:
http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=%2Fcom.ibm.ims11.doc.apg%2Fims_imsdbpliapp.htm

I was pretty happy about what I learned about PL/I until I saw this. Yuck!

Frank

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PL/I with variable PLISTs (was: LE C calling HLASM)

I don't know if this is relevant, but I was looking at the PL/I DL/I (IMS) 
interface (PLITDLI) and noticed that they actually have to pass, as the first 
parameter, a fullword containing the remaining number of items!  Crazy!

For example, in COBOL you say:

call 'CBLTDLI' using ghnp, pcb-mask, i-o-area, ssa-1 ssa-2.

In PL/I it looks like you'd do something like this:
call PLITDLI (five, ghnp, pcb-mask, i-o-area, ssa-1 ssa-2);

See here for more details:
http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=%2Fcom.ibm.ims11.doc.apg%2Fims_imsdbpliapp.htm

I was pretty happy about what I learned about PL/I until I saw this.  Yuck!

Frank
  


- Original Message -
> From: Phil Smith 
> To: IBM-MAIN@bama.ua.edu
> Cc: 
> Sent: Tuesday, April 10, 2012 1:54 PM
> Subject: Re: PL/I with variable PLISTs (was: LE C calling HLASM)
> 
> Steve Comstock wrote:
>>  Yes. But that's Assembler. I thought the called routine
>> was C, and you were testing the parms passed in the C
>> routine. Is that not true? Are there more layers here?
> 
> Yes, there are lots of layers, it's a mixture of assembler and C, sorry. The 
> point is, we're confident that the description of the behavior we've 
> seen is as described (we have XDC, too, so can see some of it). it's very 
> strange-as if nobody at IBM ever really tried to use variable plists with 
> PL/I!
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PL/I with variable PLISTs (was: LE C calling HLASM)


IMHO the problem is:

there are different solutions for variable length parameter lists that are
not compatible.

I don't know about the PL/1 solution. Maybe Steve Comstock can help
us with this.

There are two other solutions, but they don't fit well together:

- the OS/360 solution: the last parameter address has the first bit set.
Note that this solution works only with addresses, that is, call by 
reference,

and that it requires 31 bit addressing. Parameters passed by value have
a problem, because they can be negative integers, which seems like the
end of the parameter list

- the C solution with stdarg.h. This solution needs a leading fixed number
of arguments; from those fixed arguments, the total number and the types
of the following variable argument list has to be derived (like in 
printf etc.).

The called function cannot examine the parameter list and recognize
the end of the parameter list, as in the OS solution.

That's IMO the whole dilemma. I don't see any clever solution to this 
problem,

that is: there will be no solution that works perfectly for all languages.

There are more problems with parameter passing. If you are restricted to
parameter passing mechanisms that work in more than one language
(in our case for example: PL/1, ASSEMBLER, C), you have to be very
restrictive. In our case, for example, we found the following solutions:

- no PL/1 descriptors

- only pointers to structures

- only integer results (returncodes)

- structure definitions generated by central repository, so that there are
no different alignment considerations from the three languages (and all
structure components match)

Kind regards

Bernd



Am 10.04.2012 23:31, schrieb Phil Smith:

Bernd Oppolzer wrote:

I don't know if it helps you, but using C I would code the two calls this way:
rc = THEFUNCTION (&magic, inputbuffer,&inputlength, NULL, NULL);

Exactly backwards-the idea here is to NOT be obscure, but to have a nice, 
flexible, intuitive API. Having to specify null parameters or to use a macro 
for things is what we *don't* want to do.

Thanks though!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Fwd: Fwd: Re: PL/I with variable PLISTs (was: LE C calling HLASM)


It just came to my mind that you can do the same thing in PL/1,
if you pass Pointers BYVALUE and treat the pointers in the same way
as I did it in my C example.

I often did this (passing Pointers BYVALUE from PL/1 modules),
when there was the need to call C modules from PL/1 programs
and no other definition of the C ENTRY was appropriate.

for example:

DCL YCSPXML ENTRY (PTR BYVALUE,
   PTR BYVALUE,
   PTR BYVALUE,
   PTR BYVALUE,
   PTR BYVALUE,
   PTR BYVALUE)
OPTIONS (ASM RETCODE);

in fact, it is a C program, returning an int (the retcode).

Kind regards

Bernd




 Original-Nachricht 
Betreff:Fwd: Re: PL/I with variable PLISTs (was: LE C calling HLASM)
Datum:  Tue, 10 Apr 2012 23:26:51 +0200
Von:Bernd Oppolzer 
Antwort an: IBM Mainframe Discussion List 
An: IBM-MAIN@bama.ua.edu
Newsgruppen:bit.listserv.ibm-main
Referenzen: <4f84a4db.8080...@t-online.de>



Sorry, the ! should be a |

bitwise or operator in C

I mixed up bitwise or in C with logical or in PL/1

Kind regards

Bernd




 Original-Nachricht 
Betreff:Re: PL/I with variable PLISTs (was: LE C calling HLASM)
Datum:  Tue, 10 Apr 2012 23:23:39 +0200
Von:Bernd Oppolzer
An: IBM Mainframe Discussion List



I don't know if it helps you, but using C I would code the two calls
this way:

rc = THEFUNCTION (&magic, inputbuffer,&inputlength, NULL, NULL);


rc = THEFUNCTION (&magic, inputbuffer,&inputlength, outputbuffer,&outputlength);


Note that the parameters that are probably integers are prefixed with an
ampersand
to pass the addresses.

If it is needed that the 3rd and the 5th address has the high order bit
set,
you can to this in C, too. I would use a macro called HIGHBITON (x), for
example,
which is coded as follows:

#define HIGHBITON(x)  (void *)((unsigned int)(x) ! 0x8000)

So we have


rc = THEFUNCTION (&magic, inputbuffer, HIGHBITON(&inputlength), NULL, NULL);


rc = THEFUNCTION (&magic, inputbuffer,&inputlength, outputbuffer, 
HIGHBITON(&outputlength));


The two additional NULL parameters after the 3rd address in the first
case do no harm.

Kind regards

Bernd



Am 10.04.2012 23:11, schrieb Phil Smith:

  Steve Comstock wrote:

  Slipperier and slipperier. OK, let's try a different approach:
  You tell me exactly what you want to see from the PL/I routine calling
  your API and I'll see if I can cause PL/I to construct that.
  In other words, your routine will see
  (R1) ->

  rc = THEFUNCTION(magic,inputbuffer,inputlength)

  (R1) ==>A(magic),A(inputbuffer),A(inputlength)<== high bit set on the 
third fullword

  OR (the fully specified case):

  rc = THEFUNCTION(magic,inputbuffer,inputlength,outputbuffer,outputlength)

  (R1) ==>
A(magic),A(inputbuffer),A(inputlength),A(outputbuffer),A(outputlength)<== high bit 
set on the fifth fullword

  Pretty standard, yes?

  --
  For IBM-MAIN subscribe / signoff / archive access instructions,
  send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PL/I with variable PLISTs (was: LE C calling HLASM)

Bernd Oppolzer wrote:
>I don't know if it helps you, but using C I would code the two calls this way:

>rc = THEFUNCTION (&magic, inputbuffer,&inputlength, NULL, NULL);

Exactly backwards-the idea here is to NOT be obscure, but to have a nice, 
flexible, intuitive API. Having to specify null parameters or to use a macro 
for things is what we *don't* want to do.

Thanks though!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Fwd: Re: PL/I with variable PLISTs (was: LE C calling HLASM)


Sorry, the ! should be a |

bitwise or operator in C

I mixed up bitwise or in C with logical or in PL/1

Kind regards

Bernd




 Original-Nachricht 
Betreff:Re: PL/I with variable PLISTs (was: LE C calling HLASM)
Datum:  Tue, 10 Apr 2012 23:23:39 +0200
Von:Bernd Oppolzer 
An: IBM Mainframe Discussion List 



I don't know if it helps you, but using C I would code the two calls
this way:

rc = THEFUNCTION (&magic, inputbuffer,&inputlength, NULL, NULL);


rc = THEFUNCTION (&magic, inputbuffer,&inputlength, outputbuffer,&outputlength);


Note that the parameters that are probably integers are prefixed with an
ampersand
to pass the addresses.

If it is needed that the 3rd and the 5th address has the high order bit
set,
you can to this in C, too. I would use a macro called HIGHBITON (x), for
example,
which is coded as follows:

#define HIGHBITON(x)  (void *)((unsigned int)(x) ! 0x8000)

So we have


rc = THEFUNCTION (&magic, inputbuffer, HIGHBITON(&inputlength), NULL, NULL);


rc = THEFUNCTION (&magic, inputbuffer,&inputlength, outputbuffer, 
HIGHBITON(&outputlength));


The two additional NULL parameters after the 3rd address in the first
case do no harm.

Kind regards

Bernd



Am 10.04.2012 23:11, schrieb Phil Smith:

 Steve Comstock wrote:

 Slipperier and slipperier. OK, let's try a different approach:
 You tell me exactly what you want to see from the PL/I routine calling
 your API and I'll see if I can cause PL/I to construct that.
 In other words, your routine will see
 (R1) ->   

 rc = THEFUNCTION(magic,inputbuffer,inputlength)

 (R1) ==>   A(magic),A(inputbuffer),A(inputlength)<== high bit set on the third 
fullword

 OR (the fully specified case):

 rc = THEFUNCTION(magic,inputbuffer,inputlength,outputbuffer,outputlength)

 (R1) ==>   
A(magic),A(inputbuffer),A(inputlength),A(outputbuffer),A(outputlength)<== high bit 
set on the fifth fullword

 Pretty standard, yes?

 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PL/I with variable PLISTs (was: LE C calling HLASM)

I don't know if it helps you, but using C I would code the two calls 
this way:


rc = THEFUNCTION (&magic, inputbuffer,&inputlength, NULL, NULL);


rc = THEFUNCTION (&magic, inputbuffer,&inputlength, outputbuffer,&outputlength);


Note that the parameters that are probably integers are prefixed with an 
ampersand

to pass the addresses.

If it is needed that the 3rd and the 5th address has the high order bit 
set,
you can to this in C, too. I would use a macro called HIGHBITON (x), for 
example,

which is coded as follows:

#define HIGHBITON(x)  (void *)((unsigned int)(x) ! 0x8000)

So we have


rc = THEFUNCTION (&magic, inputbuffer, HIGHBITON(&inputlength), NULL, NULL);


rc = THEFUNCTION (&magic, inputbuffer,&inputlength, outputbuffer, 
HIGHBITON(&outputlength));


The two additional NULL parameters after the 3rd address in the first 
case do no harm.


Kind regards

Bernd



Am 10.04.2012 23:11, schrieb Phil Smith:

Steve Comstock wrote:

Slipperier and slipperier. OK, let's try a different approach:
You tell me exactly what you want to see from the PL/I routine calling
your API and I'll see if I can cause PL/I to construct that.
In other words, your routine will see
(R1) ->  

rc = THEFUNCTION(magic,inputbuffer,inputlength)

(R1) ==>  A(magic),A(inputbuffer),A(inputlength)<== high bit set on the third 
fullword

OR (the fully specified case):

rc = THEFUNCTION(magic,inputbuffer,inputlength,outputbuffer,outputlength)

(R1) ==>  
A(magic),A(inputbuffer),A(inputlength),A(outputbuffer),A(outputlength)<== high bit 
set on the fifth fullword

Pretty standard, yes?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PL/I with variable PLISTs (was: LE C calling HLASM)

Steve Comstock wrote:
>Slipperier and slipperier. OK, let's try a different approach:

>You tell me exactly what you want to see from the PL/I routine calling
>your API and I'll see if I can cause PL/I to construct that.

>In other words, your routine will see

>(R1) -> 

rc = THEFUNCTION(magic,inputbuffer,inputlength)

(R1) ==> A(magic),A(inputbuffer),A(inputlength) <== high bit set on the third 
fullword

OR (the fully specified case):

rc = THEFUNCTION(magic,inputbuffer,inputlength,outputbuffer,outputlength)

(R1) ==> A(magic),A(inputbuffer),A(inputlength),A(outputbuffer),A(outputlength) 
<== high bit set on the fifth fullword

Pretty standard, yes?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PL/I with variable PLISTs (was: LE C calling HLASM)


On 4/10/2012 1:54 PM, Phil Smith wrote:

Steve Comstock wrote:

Yes. But that's Assembler. I thought the called routine
was C, and you were testing the parms passed in the C
routine. Is that not true? Are there more layers here?


Yes, there are lots of layers, it's a mixture of assembler and C, sorry. The 
point is, we're confident that the description of the behavior we've seen is as 
described (we have XDC, too, so can see some of it). it's very strange-as if 
nobody at IBM ever really tried to use variable plists with PL/I!



Slipperier and slipperier. OK, let's try a different approach:

You tell me exactly what you want to see from the PL/I routine calling
your API and I'll see if I can cause PL/I to construct that.

In other words, your routine will see

(R1) -> 



--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PL/I with variable PLISTs (was: LE C calling HLASM)

Steve Comstock wrote:
> Yes. But that's Assembler. I thought the called routine
>was C, and you were testing the parms passed in the C
>routine. Is that not true? Are there more layers here?

Yes, there are lots of layers, it's a mixture of assembler and C, sorry. The 
point is, we're confident that the description of the behavior we've seen is as 
described (we have XDC, too, so can see some of it). it's very strange-as if 
nobody at IBM ever really tried to use variable plists with PL/I!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PL/I with variable PLISTs (was: LE C calling HLASM)


On 4/10/2012 1:27 PM, Phil Smith wrote:

Steve Comstock wrote:

But I would like to see the code you use to test the high bit, please.
Nothing proprietary, just informative


OK, something like this:
  L R2,0(,R8)
  TM0(R8),X'80'
  BOLASTPARM

? Pretty basic...



Yes. But that's Assembler. I thought the called routine
was C, and you were testing the parms passed in the C
routine. Is that not true? Are there more layers here?


--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PL/I with variable PLISTs (was: LE C calling HLASM)

Steve Comstock wrote:
>But I would like to see the code you use to test the high bit, please.
>Nothing proprietary, just informative

OK, something like this:
 L R2,0(,R8)
 TM0(R8),X'80'
 BOLASTPARM

? Pretty basic...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PL/I with variable PLISTs (was: LE C calling HLASM)


On 4/10/2012 12:44 PM, Phil Smith wrote:

Steve Comstock wrote:

re whether we'll expect customers to be running Enterprise PL/I:
And the answer is?


Oops...meant to answer this. Um...I guess "whatever's current" was my
assumption. Are the older compilers supported?


Some are. But there are, apparently, many customers running with
unsupported compilers. Some of the posts here have been pretty
incredibly about how old the software is.

But, we'll assume current Enterprise PL/I, then. Thanks.




Re our C prototype:


Do you really have the ellipsis? If so, my reading
of the docs is that all arguments after int  *inputLength,
will have to be of that type (that is, all pointers to
integer values) and not pointer to char followed by pointer
to int; of course, you can play games. But I think that
would be a problem.



Generally, the above C function will expect, when it is
called, to have R1 set up this way:



(R1) ->  a(magic)
   a(inputBuffer)
   a(inputLength)
   a(outputBuffer)
   a(outputLength)


That isn't the behavior we've observed.


Ah, that's why I asked about any pragma's you may have
and what compiler options you are setting in C

Generally, what I've show is true; however, in some cases
the actual first element in the list is the address of
where the function value will be returned. The docs are
a little ambiguous, so I'm trying to nail down the details.





So how, in your C code, do you currently check how
many arguments have been received?



This won't be hard, really, :-) , but we need to pay
attention to detail.


High-bit.


But I would like to see the code you use to test the high bit, please.
Nothing proprietary, just informative




What's weird to me is that PL/I and C share parts of
the same compiler logic! Ah well.


Indeed.





--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PL/I with variable PLISTs (was: LE C calling HLASM)

Steve Comstock wrote:
>Umm... that doesn't show the COBOL call, nor the Assembler call
>those are what I was wanting to see, to compare them to your
>PL/I invocations

? COBOL is basically the same, don't have assembler handy but that's even 
easier:

call THEFUNCTION using inbuffer inlength inbuffer inlength returning rc


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PL/I with variable PLISTs (was: LE C calling HLASM)

Steve Comstock wrote:
>re whether we'll expect customers to be running Enterprise PL/I:
>And the answer is?

Oops...meant to answer this. Um...I guess "whatever's current" was my 
assumption. Are the older compilers supported?

Re our C prototype:

>Do you really have the ellipsis? If so, my reading
>of the docs is that all arguments after int  *inputLength,
>will have to be of that type (that is, all pointers to
>integer values) and not pointer to char followed by pointer
>to int; of course, you can play games. But I think that
>would be a problem.

>Generally, the above C function will expect, when it is
>called, to have R1 set up this way:

>(R1) -> a(magic)
>   a(inputBuffer)
>   a(inputLength)
>   a(outputBuffer)
>   a(outputLength)

That isn't the behavior we've observed.

>So how, in your C code, do you currently check how
>many arguments have been received?

>This won't be hard, really, :-) , but we need to pay
>attention to detail.

High-bit.

>What's weird to me is that PL/I and C share parts of
>the same compiler logic! Ah well.

Indeed.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PL/I with variable PLISTs (was: LE C calling HLASM)


On 4/10/2012 12:33 PM, Phil Smith wrote:

OK, Steve, here's the previous post...thanks again!


Umm... that doesn't show the COBOL call, nor the Assembler call
those are what I was wanting to see, to compare them to your
PL/I invocations



From: Phil Smith
Sent: Tuesday, April 10, 2012 9:00 AM
To: ibm-main@bama.ua.edu
Subject: RE: Re: LE C calling HLASM

Steve Comstock wrote:

Ah, so that's what you want it for. But if the output buffer
length is zero, doesn't that tell you to use the input buffer?



And if an argument is omitted, it will appear as zero, right?
I mean, why else would you pass a buffer length of zero?


Because users make mistakes? I mean, we could do that, but it doesn't really 
solve the problem. We don't want to force them to type OMITTED - at that point 
they might as well code:
rc = THEFUNCTION(inbuffer, inlength, inbuffer, inlength);

What we want is to allow both:
rc = THEFUNCTION(inbuffer, inlength, outbuffer, outlength);
and
rc = THEFUNCTION(inbuffer, inlength); /* Works same as if inbuffer/inlength 
specified again as 3rd&  4th parameters */

as we can in COBOL. Or even in C, for that matter. I still find it hard to 
believe that PL/I can't do this!

Remember that LIST seemed like the answer, except that the high bit never got 
set on the last parameter. And then LINKAGE(SYSTEM) seemed like the answer, 
except that you can't specify that on a function call.

...phsiii (will it go 'round in circles...?)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN




--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PL/I with variable PLISTs (was: LE C calling HLASM)

OK, Steve, here's the previous post...thanks again!

From: Phil Smith
Sent: Tuesday, April 10, 2012 9:00 AM
To: ibm-main@bama.ua.edu
Subject: RE: Re: LE C calling HLASM

Steve Comstock wrote:
>Ah, so that's what you want it for. But if the output buffer
>length is zero, doesn't that tell you to use the input buffer?

>And if an argument is omitted, it will appear as zero, right?
>I mean, why else would you pass a buffer length of zero?

Because users make mistakes? I mean, we could do that, but it doesn't really 
solve the problem. We don't want to force them to type OMITTED - at that point 
they might as well code:
   rc = THEFUNCTION(inbuffer, inlength, inbuffer, inlength);

What we want is to allow both:
   rc = THEFUNCTION(inbuffer, inlength, outbuffer, outlength);
and
   rc = THEFUNCTION(inbuffer, inlength); /* Works same as if inbuffer/inlength 
specified again as 3rd & 4th parameters */

as we can in COBOL. Or even in C, for that matter. I still find it hard to 
believe that PL/I can't do this!

Remember that LIST seemed like the answer, except that the high bit never got 
set on the last parameter. And then LINKAGE(SYSTEM) seemed like the answer, 
except that you can't specify that on a function call.

...phsiii (will it go 'round in circles...?)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PL/I with variable PLISTs (was: LE C calling HLASM)


On 4/10/2012 11:15 AM, Frank Swarbrick wrote:

I only happened to learn PL/I this weekend,


Well I'm impressed!


so take this with a grain of salt,

but can't you activate THEFUNCTION with a call rather than as a function in
order to be able to use LINKAGE(SYSTEM)? And then use PLIRETV() in order to get
the return code?

1. Yes you can, theoretically, set this up as a procedure

2. And, yes, the call to PLIRETV should work (although in
   the literature it says for this to work the called
   program should have made a call to PLIRETC, the effect
   from the C function will probably match that)

3. But the problem he is concerned with: how to pass
   three parameters or five parameters and have the
   C function know which have been passed

   If he is counting on the end-of-list flag, then
   the C function must have something like

 #pragma linkage(thefunction,OS)

   but it's not clear if that is the case here

   That's why I wanted to see how he checks for the
   number of parms in his C code.


Also, to turn on the end-of-list flag, the call from
the PL/I program will have to have options(asm), so:

  call thefunction(magic, inbuff, inbufflen, outbuff, outbufflen) options(asm);

or

  call thefunction(magic, inbuff, inbufflen) options(asm);


Also note that if the subroutine were declared as a function,
then options(asm) is not allowed.




declare THEFUNCTION entry options(ASM RETCODE LINKAGE(SYSTEM));
(I think LINKAGE(SYSTEM) is redundant here.)


call THEFUNCTION(one, two, three);
display(pliretv());
call THEFUNCTION(one, two, three, four, five);
display(pliretv());

(Not sure if the declare entry requires the parms to be declared.)


Maybe you can even wrap the above into a PL/I function so that your PL/I 
programs can invoke it as a function.

Just a WAG.  Good luck!

Frank



- Original Message -

From: Phil Smith
To: IBM-MAIN@bama.ua.edu
Cc:
Sent: Tuesday, April 10, 2012 9:57 AM
Subject: Re: PL/I with variable PLISTs (was: LE C calling HLASM)

Steve Comstock wrote:

I'm confused here, because the title of the thread
is 'C calling HLASM' and here we are talking about
PL/I.


Yeah, true...topic drift. Renamed.


So what's really going on here that is the mystery?



My guess is: you have a C function that you want to
call from, in this instance, a PL/I program. Right?


Right.


Can you show us the definition of the C function
(not the body, just the definition of parameters
along with any pragma statements you might have,
and compiler options relevant to calls / function
references)?


See below.


Can you show us how you invoke the function from
C, COBOL, and Assembler? That is, some sample calls
or function references that work successfully, both
with two arguments and four arguments (BTW: do you
allow the output buffer to be specified without the
last length argument? How about no output buffer
but with a length? In other words, must the user
specify exactly two or exactly four arguments?)


The previous post had an example from COBOL; C is the same, only in C syntax.
Assembler too. We validate that we got three or five arguments (note there's
an initial, required argument).


Finally: there are some differences in the Enterprise
PL/I compiler regarding compile time options and
options available for declaring functions and
subroutines so I ask this: is your expectation that
your customers will be running the Enterprise PL/I
compiler or some earlier compiler?


Here's a C prototype, with the serial numbers filed off:

int THEFUNCTION( char *magic,
  char *inputBuffer,
  int  *inputLength,
  ...)





--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PL/I with variable PLISTs (was: LE C calling HLASM)


On 4/10/2012 9:57 AM, Phil Smith wrote:

Steve Comstock wrote:

I'm confused here, because the title of the thread
is 'C calling HLASM' and here we are talking about
PL/I.


Yeah, true...topic drift. Renamed.


So what's really going on here that is the mystery?



My guess is: you have a C function that you want to
call from, in this instance, a PL/I program. Right?


Right.


Can you show us the definition of the C function
(not the body, just the definition of parameters
along with any pragma statements you might have,
and compiler options relevant to calls / function
references)?


See below.


Can you show us how you invoke the function from
C, COBOL, and Assembler? That is, some sample calls
or function references that work successfully, both
with two arguments and four arguments (BTW: do you
allow the output buffer to be specified without the
last length argument? How about no output buffer
but with a length? In other words, must the user
specify exactly two or exactly four arguments?)


The previous post had an example from COBOL; C is the same, only in C
syntax.Assembler too. We validate that we got three or five arguments
(note there's an initial, required argument).



Yeah, but I don't have the previous post. I'm trying
to get better about cleaning out my inbasket, and
sometimes I get overzealous.




Finally: there are some differences in the Enterprise
PL/I compiler regarding compile time options and
options available for declaring functions and
subroutines so I ask this: is your expectation that
your customers will be running the Enterprise PL/I
compiler or some earlier compiler?


And the answer is?





Here's a C prototype, with the serial numbers filed off:

int THEFUNCTION( char *magic,
  char *inputBuffer,
  int  *inputLength,
  ...)


Do you really have the ellipsis? If so, my reading
of the docs is that all arguments after int  *inputLength,
will have to be of that type (that is, all pointers to
integer values) and not pointer to char followed by pointer
to int; of course, you can play games. But I think that
would be a problem.

Generally, the above C function will expect, when it is
called, to have R1 set up this way:

(R1) -> a(magic)
a(inputBuffer)
a(inputLength)
a(outputBuffer)
a(outputLength)


So how, in your C code, do you currently check how
many arguments have been received?

This won't be hard, really, :-) , but we need to pay
attention to detail.

What's weird to me is that PL/I and C share parts of
the same compiler logic! Ah well.


--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PL/I with variable PLISTs (was: LE C calling HLASM)

Frank Swarbrick suggested using a CALL instead of a function.

I'll try that; I'm not sure it's an acceptable change to the usage, but thanks.

I'm off after today for surgery for a herniated disc, so might be a while.

Still find it hard to believe that PL/I makes this so hard!

...phsiii

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PL/I with variable PLISTs (was: LE C calling HLASM)

I only happened to learn PL/I this weekend, so take this with a grain of salt, 
but can't you activate THEFUNCTION with a call rather than as a function in 
order to be able to use LINKAGE(SYSTEM)?  And then use PLIRETV() in order to 
get the return code?

declare THEFUNCTION entry options(ASM RETCODE LINKAGE(SYSTEM));
(I think LINKAGE(SYSTEM) is redundant here.)


call THEFUNCTION(one, two, three);
display(pliretv());
call THEFUNCTION(one, two, three, four, five);
display(pliretv());

(Not sure if the declare entry requires the parms to be declared.)


Maybe you can even wrap the above into a PL/I function so that your PL/I 
programs can invoke it as a function.

Just a WAG.  Good luck!

Frank



- Original Message -
> From: Phil Smith 
> To: IBM-MAIN@bama.ua.edu
> Cc: 
> Sent: Tuesday, April 10, 2012 9:57 AM
> Subject: Re: PL/I with variable PLISTs (was: LE C calling HLASM)
> 
> Steve Comstock wrote:
>> I'm confused here, because the title of the thread
>> is 'C calling HLASM' and here we are talking about
>> PL/I.
> 
> Yeah, true...topic drift. Renamed.
> 
>> So what's really going on here that is the mystery?
> 
>> My guess is: you have a C function that you want to
>> call from, in this instance, a PL/I program. Right?
> 
> Right.
> 
>> Can you show us the definition of the C function
>> (not the body, just the definition of parameters
>> along with any pragma statements you might have,
>> and compiler options relevant to calls / function
>> references)?
> 
> See below.
> 
>> Can you show us how you invoke the function from
>> C, COBOL, and Assembler? That is, some sample calls
>> or function references that work successfully, both
>> with two arguments and four arguments (BTW: do you
>> allow the output buffer to be specified without the
>> last length argument? How about no output buffer
>> but with a length? In other words, must the user
>> specify exactly two or exactly four arguments?)
> 
> The previous post had an example from COBOL; C is the same, only in C syntax. 
> Assembler too. We validate that we got three or five arguments (note there's 
> an initial, required argument).
> 
>> Finally: there are some differences in the Enterprise
>> PL/I compiler regarding compile time options and
>> options available for declaring functions and
>> subroutines so I ask this: is your expectation that
>> your customers will be running the Enterprise PL/I
>> compiler or some earlier compiler?
> 
> Here's a C prototype, with the serial numbers filed off:
> 
> int THEFUNCTION( char *magic,
>              char *inputBuffer,
>              int  *inputLength,
>              ...)
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: LE C calling HLASM

2012-04-10 Thread Shmuel Metz (Seymour J.)

In <0363431161795505.wa.elardus.engelbrechtsita.co...@bama.ua.edu>, on
04/10/2012
   at 05:39 AM, Elardus Engelbrecht 
said:

>http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.ikjb300%2Fpack.htm

Yes. TSO/E also picked up up PCF.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PL/I with variable PLISTs (was: LE C calling HLASM)

Steve Comstock wrote:
>I'm confused here, because the title of the thread
>is 'C calling HLASM' and here we are talking about
>PL/I.

Yeah, true...topic drift. Renamed.

>So what's really going on here that is the mystery?

>My guess is: you have a C function that you want to
>call from, in this instance, a PL/I program. Right?

Right.

>Can you show us the definition of the C function
>(not the body, just the definition of parameters
>along with any pragma statements you might have,
>and compiler options relevant to calls / function
>references)?

See below.

>Can you show us how you invoke the function from
>C, COBOL, and Assembler? That is, some sample calls
>or function references that work successfully, both
>with two arguments and four arguments (BTW: do you
>allow the output buffer to be specified without the
>last length argument? How about no output buffer
>but with a length? In other words, must the user
>specify exactly two or exactly four arguments?)

The previous post had an example from COBOL; C is the same, only in C syntax. 
Assembler too. We validate that we got three or five arguments (note there's an 
initial, required argument).

>Finally: there are some differences in the Enterprise
>PL/I compiler regarding compile time options and
>options available for declaring functions and
>subroutines so I ask this: is your expectation that
>your customers will be running the Enterprise PL/I
>compiler or some earlier compiler?

Here's a C prototype, with the serial numbers filed off:

int THEFUNCTION( char *magic,
 char *inputBuffer,
 int  *inputLength,
 ...)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: LE C calling HLASM


On 4/10/2012 7:00 AM, Phil Smith wrote:

Steve Comstock wrote:

Ah, so that's what you want it for. But if the output buffer
length is zero, doesn't that tell you to use the input buffer?



And if an argument is omitted, it will appear as zero, right?
I mean, why else would you pass a buffer length of zero?


Because users make mistakes? I mean, we could do that, but it doesn't really

solve the problem. We don't want to force them to type OMITTED - at that point
they might as well code:

rc = THEFUNCTION(inbuffer, inlength, inbuffer, inlength);

What we want is to allow both:
rc = THEFUNCTION(inbuffer, inlength, outbuffer, outlength);
and
rc = THEFUNCTION(inbuffer, inlength); /* Works same as if inbuffer/inlength 
specified again as 3rd&  4th parameters */

as we can in COBOL. Or even in C, for that matter. I still find it hard to 
believe that PL/I can't do this!

Remember that LIST seemed like the answer, except that the high bit never got 
set on the last parameter. And then LINKAGE(SYSTEM) seemed like the answer, 
except that you can't specify that on a function call.

...phsiii (will it go 'round in circles...?)


I'm confused here, because the title of the thread
is 'C calling HLASM' and here we are talking about
PL/I.

So what's really going on here that is the mystery?

My guess is: you have a C function that you want to
call from, in this instance, a PL/I program. Right?


Can you show us the definition of the C function
(not the body, just the definition of parameters
along with any pragma statements you might have,
and compiler options relevant to calls / function
references)?


Can you show us how you invoke the function from
C, COBOL, and Assembler? That is, some sample calls
or function references that work successfully, both
with two arguments and four arguments (BTW: do you
allow the output buffer to be specified without the
last length argument? How about no output buffer
but with a length? In other words, must the user
specify exactly two or exactly four arguments?)


Finally: there are some differences in the Enterprise
PL/I compiler regarding compile time options and
options available for declaring functions and
subroutines so I ask this: is your expectation that
your customers will be running the Enterprise PL/I
compiler or some earlier compiler?



--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: LE C calling HLASM

Steve Comstock wrote:
>Ah, so that's what you want it for. But if the output buffer
>length is zero, doesn't that tell you to use the input buffer?

>And if an argument is omitted, it will appear as zero, right?
>I mean, why else would you pass a buffer length of zero?

Because users make mistakes? I mean, we could do that, but it doesn't really 
solve the problem. We don't want to force them to type OMITTED - at that point 
they might as well code:
   rc = THEFUNCTION(inbuffer, inlength, inbuffer, inlength);

What we want is to allow both:
   rc = THEFUNCTION(inbuffer, inlength, outbuffer, outlength);
and
   rc = THEFUNCTION(inbuffer, inlength); /* Works same as if inbuffer/inlength 
specified again as 3rd & 4th parameters */

as we can in COBOL. Or even in C, for that matter. I still find it hard to 
believe that PL/I can't do this!

Remember that LIST seemed like the answer, except that the high bit never got 
set on the last parameter. And then LINKAGE(SYSTEM) seemed like the answer, 
except that you can't specify that on a function call.

...phsiii (will it go 'round in circles...?)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: LE C calling HLASM


On 4/10/2012 5:58 AM, Phil Smith wrote:

Jan MOEYERSONS quoted the doc, then asked:

Is this not true then?


I know this has been a protracted thread, so I'll summarize: If I use LIST, I
can't use LINKAGE(SYSTEM), so it doesn't set the high bit. If

I use OMITTED, it passes a zero for that parameter, so I can't tell whether the
parameter was omitted or really passed as zero.


Our API is flexible: if you don't specify an output buffer& length, it uses

the input buffer& length. But that doesn't want to work in PL/I.




Ah, so that's what you want it for. But if the output buffer
length is zero, doesn't that tell you to use the input buffer?

And if an argument is omitted, it will appear as zero, right?
I mean, why else would you pass a buffer length of zero?


Ideas?
--
...phsiii

Phil Smith III
p...@voltage.com
Voltage Security, Inc.
www.voltage.com
(703) 476-4511 (home office)
(703) 568-6662 (cell)




--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: LE C calling HLASM