I think you are explaining what, in COBOL terms, is CALL BY CONTENT, not CALL BY VALUE. CALL BY CONTENT seems to be similar (same?) as what Bernd is describing in PL/I with the placement of parentheses around the argument. CALL BY CONTENT (in COBOL) creates a "dummy" variable, copies the "content" of the original variable to the dummy variable, and passes the address of the dummy variable.
CALL BY VALUE (in COBOL) does not do this. CBV places the actual value (generally, if maybe not always) in the parameter list (where CALL BY REFERENCE and CALL BY CONTENT would place an address). On the CALLEE side you also must (*) specify BY VALUE when the caller argument is passed BY VALUE, so that the CALLEE knows there is a value rather than an address in that parameter. (*) The "exception" being that you COULD have the caller do CALL XXX BY VALUE ADDRESS OF MY-FIELD and have the CALLER "receive" the parameter by reference (the default) to be able to address the callers MY-FIELD variable. Not generally recommended, but can work. In C you always "call by value", but sometimes the value is an address (reference)., e.g. (as has been shown by others), xxx(a, &b) This passes the value of a and THE VALUE OF THE ADDRESS of b. So rather, in COBOL this would be call 'xxx' using by value a, by value address of b. When invoking program 'xxx', regardless of if it is written in C, COBOL, PL/I or assembler, there is no other way for a COBOL program to call it passing the VALUE of a other than using the BY VALUE clause as shown previously. If you attempted to pass BY REFERENCE (default) or BY CONTENT then the corresponding parameter in xxx would be the address of a, not the value of a, and would not work as desired. I think Bernd has shown in PL/I how to use BYVALUE or something like that. Prior to BY VALUE being added to COBOL (pre-1985, I believe) you could not properly call a C routine that expected a value parameter. Only C routines that had pointer arguments was possible. Clear as mud? ________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Joel C. Ewing <[email protected]> Sent: Monday, March 27, 2023 9:19 AM To: [email protected] <[email protected]> Subject: Re: ASM call by value All you really need to do a "call by value" in ASM is a special Call macro (say maybe VCALL) that allocates "hidden" space for a copy of the variable value, copies the original variable, and somehow passes that to the called program, and a programming rule that says you only invoke that particular subroutine using the intended interface. You can even add a special Subroutine entry macro and employ some "tricks" so that attempts to reference the subroutine name by an ordinary Call macro or direct reference will fail. If your only allowed interfaces to the subroutine allows it so see the value of a variable passed by the caller but not change the corresponding variable known to the caller, then that IS call by value, no matter what the underlying implementation in low-level code. Native machine instructions and standard subroutine linkages may only support call by reference, but the advantage of a macro assembler is that you can extend the language through macros and create an enhanced language that can do so much more. Some notable examples of this are various implementations using macros that allow use of structured-programming control constructs and recursive procedures with dynamic variable storage in Assembly programs. Joel C Ewing On 3/27/23 09:13, Bernd Oppolzer wrote: > DCL X BIN FIXED (31); > CALL SUB ((X)); > > SUB: PROC (P); > DCL P BIN FIXED (31); > > END SUB; > > The statement CALL SUB ((X)); > creates a dummy argument for X (that is, a copy of variable X). > The CALL statement passes THE ADDRESS of that copy to the SUB subroutine. > This is NOT call by value. > > The subroutine cannot change X, because it gets the address of the > copy of X > and not the address of X. That is: > > call by reference of a dummy argument > and not > call by value > > The types of X and P may be different; if so, the dummy argument gets > the type of P. > In this case, no parantheses are required (but a warning message is > issued, if there are > no parentheses). But the mechanism is the same, regardless if the > types match (with parantheses) > or if the types don't match (without parantheses). Only in the case > when the types match and > there are no parantheses, you have a real call by reference where the > subroutine can change > the value of the caller. > > This is PL/1 ... other languages don't behave this way. With other > languages, you will get a > problem at runtime, if the types don't match. > > Kind regards > > Bernd > > > > Am 27.03.2023 um 16:03 schrieb Seymour J Metz: >> Why is it important to you that an address not be passed and why do >> you believe that a PL/I dummy variable means that the argument was >> not passed by value? Languages specify black box behavior, not how >> you enforce that behavior. >> >> ________________________________________ >> From: IBM Mainframe Discussion List <[email protected]> on >> behalf of Bernd Oppolzer <[email protected]> >> Sent: Monday, March 27, 2023 9:55 AM >> To: [email protected] >> Subject: Re: ASM call by value >> >> What is important to me at least: a parameter passing mechanism where >> addresses are passed >> and the value on the caller's side cannot be altered (because it has >> been copied before, like in the >> DUMMY argument mechanism of PL/1, for example) it NOT call by value. >> >> You cannot call a true BYVALUE module or function by using such a >> parameter passing mechanism. >> That is: it is not only important that the caller's variable is not >> altered; >> it is also important that VALUEs are passed, not addressed. Otherwise >> you have some sort of >> "restricted" call by reference, which is not the same as call by value. >> >> You are right, of course, that Reg 1 and DSA etc. are details of the >> implementation, >> only mentioned here to clarify the idea. >> >> Kind regards >> >> Bernd >> >> >> Am 27.03.2023 um 14:25 schrieb Seymour J Metz: >>> There's more than one implementation; they all <crosses fingers> >>> enforce the semantics. Again, what call by value is all about is >>> that the caller's variable in not altered, regardless of how the >>> compiler enforces that. The whole shtick with R1 and DSA is not part >>> of the semantics. >>> >>> ________________________________________ >>> From: IBM Mainframe Discussion List <[email protected]> on >>> behalf of Bernd Oppolzer <[email protected]> >>> Sent: Monday, March 27, 2023 7:10 AM >>> To: [email protected] >>> Subject: Re: ASM call by value >>> >>> Implementation enforces semantics in this case ... >>> >>> The C implementation (on z/OS at least, but IMO on other platforms as >>> well) builts a reg1 parameter list >>> and puts the "value parms" there. With C on z/OS, the reg1 parameter >>> list resides on the "stack", which >>> is addressed by reg 13 in the caller's DSA, so that the whole process >>> remains reentrant. >>> >>> Then the called prog can, if it wants, change the passed values, which >>> are in fact local variables, >>> as seen be the called prog. But nothing is changed from the perspective >>> of the caller. >>> >>> This is what call by value is about. >>> >>> The ASSEMBLER call macro supports this, but only for integer parms, and >>> not for parameter lists which >>> dont reside in the caller's CSECT. So we have two issues here: >>> >>> - no "larger" data types supported >>> - no support for the reentrant case >>> >>> HTH, >>> kind regards >>> >>> Bernd >>> >>> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO IBM-MAIN >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN -- Joel C. Ewing ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
