Re: CALL using OMITTED

Frank Swarbrick wrote:
On 9/26/2008 at 8:43 PM, in message <p5hDk.137$J63.102@xxxxxxxxxxxx>,

James
J. Gavan<jgavandeletethis@xxxxxxx> wrote:

I'm fascinated that you always seem to go looking for problems that you can create in COBOL. What's wrong with KISS ?


I am not looking for problems. (Well, not in this case, at least!) I am
looking for solutions.

I'm always looking for ways to make things more flexible and dynamic, and I
look for ways that Cobol can help with this. I thought that this might be
one such case.

Simple is good. Simple and powerful is better.


So in both examples you have A, B, C and D as pic x(04). What's so complicated about :-

move spaces to C and D, when appropriate, before you do the CALL

(or any other combination of the four parameters) ???


Nothing is complicated about that. What I was looking for was a way to
leave alone a program that has:

move 'mysubr' to subroutine
call subroutine using p1 p2 p3

when program 'mysubr' has been change to support a fourth parameter, ie:

procedure division using parm1 parm2 parm3 parm4

Say there are 20 programs that call 'mysubr'. Only two of them care about
this new, fourth, parameter. The only reason that the other 18 programs
need to be touched is because they need to pass to the new version of mysubr
a data area to hold data which they don't even care about.

I hope you don't think I made this problem up just for fun. I had an
actually case a few years ago when this would have been useful. Of course
we lived without it.

Frank

No, not for fun and as explained can see your problem. My initial reaction was to say, "Well, if you were using OO....." :-), but I see that Pete has expanded on that. Now I don't know the first thing about COM that he is writing about - can't get into N/E at the moment but I do have separate access to the N/E Class book for methods; didn't spot anything there, but no doubt could find something compatible to what Pete is doing if I tried.

Now here's another possibility - but M/F OO is VASTLY different from F/J in this respect - Collections.

Forget about the TR (Technical Report) in the Standard - it's optional now along with Dynamic W/S Tables and Finalizer. Who is going to implement it ? Not F/J nor M/F and the latter via Bill K. has already said so. Which leaves Hitachi (academic because it is in Japanese and they have never expressed any interest in selling it in the 'West'. Leaves Karl at Fujitsu-Siemens - but hope he doesn't fall into the trap.

Not going to try and spell it out in detail, but briefly highlight it. Assume your 20 programs and perhaps also a permutation of 20 parameters. Without having N/E up and running I can't reference it but Pete's syntax for :-

invoke thisObject using p1, p2, p3

There is a Vocabulary Class in N/E which allows six optional parameters (I think - might be slightly more) - that might be a possibility. Now back to collections :-

Assume a table of parameters in the CALLing Program/Class :-

01 ParameterTable.
05 SomethingOne pic x(128),
05 AnotherItem pic 9(04)v9(02) comp-3.
05 ..............

Each one of course needs a meaningful name, otherwise you get screwed.

invoke MyCollection "new" returning CollectionObject

(Actual syntax for the above needs some parameters, but you get the idea).

Run through the parameters using Class CharacterArray to turn pic x(?) and pic 9(?) into objects. You can use one initial collection adding each of the 20 parameters as elements to the Collection.

If you know anything about OO so far there are only three ways of moving/copying objects :-

(a) move CustomerName of RecordClass to ......(a field in the Class you
are in)
(a) either passing them through linkage, or
(b) The SET statement :- set B to A

PECD : Have I missed any ? (a) above is a bit debatable, but it is a way of moving data within an object.

Here's the difference, (F/J v M/F) - the classes for Collections ALLOW you to copy all or parts of collections into a second collection. I've never done it so I don't know the full implications - hopefully it creates a unique reference (i.e. a separate 'pointer' with a Hex Value in the second collection so that the element can be destroyed (finalized) in the first Collection without impacting the second. There are 11 methods listed to to do this, things like "empty", "whole" or partial.

One would have to know in detail what you are doing with the parameters - if they were an initialization of values for the whole of the ParameterTable, then it's reasonably straight-froward. If as a result of some action in the CALLING program the values of parameters change per call, then the parallel element can be changed - not something the Standard TR concept of Collections allows you to do !

I'm thinking out loud - but you could generate a Collection for each of your 20 programs with different permutations :-

p1, p2, p3 or,
p1, p3, p5, p7 etc.

and pass these to one of the selected callee programs. Now once an object is created it *knows* its properties and valid methods.

Invoke Program2 using Collection-2 (Collection 2 has 4 elements - p1, p3, p5, p7 above, say).

Your receiving program :-

Linkage section.
01 Input-Collection object reference.

Procedure Div.

invoke Input-Collection "size" returning ws-size *> # of elements

XP = Extreme Programming - check that the size = the number of elements the receiving program anticipates.

Do an iteration/calback or PERFORM against the elements, using class CharacterArray to turn the objects back into pic x(?) or pic 9(?) giving your program the parameters it expects.

Pete's sentence :-

"Suppose there WAS NO INTERFACE? What if I could somehow set the parameters I needed to use in the called method BEFORE I invoked it?"

May not be the answer to his question, but if he was to :-

invoke Program2 "new" using Collection2 returning Obj-Program2

I normally don't have a "new" method in FACTORY letting the caller program do its thing by referencing Class Base at the top of the hierarchy.

*>-------------
FACTORY
method "new".
Linkage.
01 lnk-Collection object reference.
01 Lnk-self object reference *> = Instance of Program2

Procedure Division using Collection returning lnk-self
..
Invoke self 'new' returning lnk-self
invoke lnk-self "initialize" using lnk-Collection
*>------------------------
OBJECT.
WORKING-STORAGE SECTION.
78 ExpectedSize value 4.
01 ParameterTable.
05 Param1 pic 9(03). *> makes sense to call each parameter
05 Param2 pic x(128). *> by its original number in the
05 Param3 pic 9(05). *> CALLing program to avoid confusion
05 Param4 pic x(22).

01 ws-size pic x(04) comp-5.

method "initialize"
Linkage.
01 lnk-Collection

Procedure Div using....

invoke lnk-Collection "size" returning ws-size

if ws-size <> ExpectedSize ... we have a problem.....

perform varying n from 1 by 1 until n > ws-size

move function-length (n) to Param1 etc.....

end-perform

*** I'm really free-wheeling above without the compiler - but hopefully it conveys the idea.

I think you can see the germ of an idea. OO is infinitely flexible and you have received two different approaches. I don't think you can get your lot into dotNet, (could be very wrong on that because I haven't studied the topic), but push your guys for Java as an alternative.

Off the wall idea for Procedural COBOL - could you have a separate program to establish the parameters per called program and perhaps use the entry-point technique ???? No clear ideas, but just a thought.

Jimmy
.

Relevant Pages

  • Re: ouvrir un document word =?ISO-8859-1?Q?=E0_partir_d=27un?= =?ISO-8859-1?Q?_progr
    ... The trouble is, there are so many permutations and in the case of mail-merge, MS let's you even do "IF tests ..." ... You database is it a COBOL ISAM or a DB Table you were getting your address info from. ... It appears if you have an ODBC Driver then for mail-merge, MS Word can reference your DB. ... the meeting will be held at << a merged field>> and the date and time of the meeting is << a merged field ...
    (comp.lang.cobol)
  • Re: invoking a method
    ... The use of SET as shown here, will not work outside the Fujitsu Object COBOL ... invoke DBObject ... I will admit I have not worked on anyone else's Cobol compiler so I ... typical reference manual for a Cobol Compiler will have line and box based ...
    (comp.lang.cobol)
  • Re: Thoughts on passing values to PowerCOBOL DLL
    ... COBOL thrust upon them. ... At my age I sometimes have trouble finding my ... then this would be a matter of "uniqueness of reference", ... I think as you become more familiar with it (even through use of PowerCOBOL) ...
    (comp.lang.cobol)
  • Re: new block notation (was: Re: ruby-dev summary 26468-26661)
    ... It is possible to invoke all three in an arbitrary scope (where 'self' and instance variables refer to a specific, runtime-chosen instance of any class) by passing them as a block to a special ... It is possible to get a reference to a method and assign it to a variable. ... It is possible to invoke a method reference in the scope of the instance to which it is tied without supplying the instance as a receiver. ... Lambdas are not associated with any specific instance. ...
    (comp.lang.ruby)
  • Re: Help Constructing Fictional Cross-Religious Movement
    ... >>Wilson Heydt wrote: ... Except that in COBOL ... reference to it) in some variable/array/objectMember. ... in languages which are designed to support OO. ...
    (rec.arts.sf.composition)