Re: CALL using OMITTED

On 9/29/2008 at 11:16 AM, in message
<748Ek.804832$3p2.397919@xxxxxxxxxxxxxxxxxxxxxx>, William M.
Klein<wmklein@xxxxxxxxxxxxxxxxx> wrote:
Frank,
Thinking a little more about this, I do NOT think IBM will/should
"easily"
treat an omitted final parameter like an explicit OMITTED phrase (at
least
without call prototypes).

IBM has an (undocumented?) feature that Micro Focus emulates with its
"sticky-linkage" compiler directive. The USEFUL part of this feature is
that if
you call the same program using multiple (IBM extension) ENTRY
statements and
one has 4 parameters and the 2nd call uses only 3 parameters, then
"addressability" is MAINTAINED for the omitted parameter.

The (less useful?) variation of this is if you call a program with NO
ENTRY
statement and call it first with 4 parameters and then with 3
parameters, then
the 4 item retains "sticky-linkage" (i.e. addressability) from the
previous
call.

THEREFORE< I don't think that they (IBM) could (uparwadly compatibly)
treat an
omitted trailing parameter as the same as an explicit OMITTED parameter.

***

I still haven't heard make from my usually reliable sources, but this is
my
opinion on the subject.

Wow! I never in my wildest dreams would have imagined linkage to work this
way. I have seen occasional reference to Micro Focus' "sticky linkage", but
I did not realize it was inherited from IBM mainframe Cobol. I just tried
it on z/OS and it works just as you say. (Didn't try VSE, but I imagine it
is the same.)

Even if one wanted to do this kind of trick, it seems to me it would make
more sense for a program to move the data to working storage if there was a
need to retain addressability to it between calls. Well, I guess this would
only work if the calling program didn't want to change the value in the
calling program. Of course you could save the address itself in
working-storage and do it that way. I can see no good (only evil) coming
out of taking advantage of this feature.

Oh well. I imagine I'm 30 or 40 years to late to get that fixed! Though if
it is undocumented, I guess they could go ahead and change it without
worrying about compatibility. :-)

Frank

.

Relevant Pages

  • Re: IBM shoots itself in the foot -
    ... Imagine that if IBM software managers were setting their long term ... I imagine CGIDEV2 may never have seen the light of day. ... > locks in the hardware layer if they helped out the CGIDEV community. ... > Open Source code from the Linux community and contributes Open Source code ...
    (comp.sys.ibm.as400.misc)
  • Re: Programmer knowledge
    ... On Fri, 9 Apr 2004 13:36:16 UTC, blmblm@myrealbox.com wrote: ... >>I suppose it's possible to imagine that IBM developed ... >>indeed have seemed threatening to IBM executives. ... for solutions and OS/2 on the mighty Model 50/60/70/80/90 PCs. ...
    (comp.programming)
  • Re: HVD adapters
    ... Yes, I can imagine, as I've heard good things about them. ... Shame the same ... can't be said for IBM S/390 18.2GB SSA Disks in FC 2109 enclosures, ...
    (comp.sys.ibm.ps2.hardware)
  • Re: Brace for impact!
    ... >> I seem to recall seeing several ads on tv hyping this feature for PC ... "IBM Hard Drive Active Protection System ... The software component basically receives, ... and reacts to signals from the motion detector. ...
    (comp.sys.mac.advocacy)
  • Re: QASJSNDHST CPA5305
    ... Here is an email IBM sent us to deal with it. ... set to *YES when the QASJSNDHST file is created... ... I infer from its name that the database file object is a Service Agent ... error message is a side effect of a _poor design_ of that feature. ...
    (comp.sys.ibm.as400.misc)