CALL using OMITTED
Frank Swarbrick
been trying out some features in Enterprise COBOL for z/OS that are missing
in COBOL for VSE/ESA. One feature I've always thought might be useful is
CALL with the OMITTED argument. So I wrote the following:
ID DIVISION.
PROGRAM-ID. COB1.
PROCEDURE DIVISION.
DISPLAY 'NEW TEST' UPON CONSOLE
DISPLAY 'TEST!' UPON CONSOLE
DISPLAY 'TEST2'
DISPLAY 'WHEEEE!!!' UPON CONSOLE
DISPLAY 'YET ANOTHER TEST' UPON CONSOLE
CALL 'COBX' USING BY CONTENT 'AAAA'
OMITTED
'CCCC'
OMITTED
STOP RUN.
ID DIVISION.
PROGRAM-ID. COBX.
DATA DIVISION.
LINKAGE SECTION.
77 A PIC X(4).
77 B PIC X(4).
77 C PIC X(4).
77 D PIC X(4).
PROCEDURE DIVISION USING A B C D.
IF ADDRESS OF A = NULL
DISPLAY 'A IS OMITTED'
ELSE
DISPLAY A
END-IF
IF ADDRESS OF B = NULL
DISPLAY 'B IS OMITTED'
ELSE
DISPLAY B
END-IF
IF ADDRESS OF C = NULL
DISPLAY 'C IS OMITTED'
ELSE
DISPLAY C
END-IF
IF ADDRESS OF D = NULL
DISPLAY 'D IS OMITTED'
ELSE
DISPLAY D
END-IF
EXIT PROGRAM.
END PROGRAM COBX.
END PROGRAM COB1.
This works. However, I also tried:
CALL 'COBX' USING BY CONTENT 'AAAA'
OMITTED
'CCCC'
Where I, umm, omitted the OMITTED keyword as the fourth parameter.
According to the Cobol 2002 standard, I believe this would work:
From 14.8.4.3 General rules:
"11) If an OMITTED phrase is specified or a trailing argument is omitted,
the omitted-argument condition for that
parameter evaluates to true in the called program. (8.8.4.1.7,
Omitted-argument condition.)"
This does not appear to work in Enterprise Cobol. I would have expected to
see 'D IS OMITTED'. But I did not. It printed the value of D, which was
spaces (I guess; or something not readable).
I can't find anything in the IBM docs that say what should be expected in
this situation. All I could find was this:
----------------
4.2.1.3 Testing for OMITTED arguments
You can specify that one or more BY REFERENCE arguments are not to be passed
to a called program by coding the OMITTED keyword in place of those
arguments in the CALL statement.
For example, to omit the second argument when calling program sub1, code
this statement:
Call 'sub1' Using PARM1, OMITTED, PARM3
The arguments in the USING phrase of the CALL statement must match the
parameters of the called program in number and position.
In a called program, you can test whether an argument was passed as OMITTED
by comparing the address of the corresponding parameter to NULL. For
example:
Program-ID. sub1.
. . .
Procedure Division Using RPARM1, RPARM2, RPARM3.
If Address Of RPARM2 = Null Then
Display 'No 2nd argument was passed this time'
Else
Perform Process-Parm-2
End-If
----------------
Well, I guess maybe this statement says it in some ways:
"The arguments in the USING phrase of the CALL statement must match the
parameters of the called program in number and position."
Since the number of arguments does not match I guess the result is
undefined. Annoying! I wonder if they would consider following the
standard... Seems to me this would be a very simple change. The IBM
calling convention sets the high-order byte in the address of the last
parameter. So its easy to know which parameter was last, and then assume
parameters after that are omitted.
The main reason I would like this is that sometimes a subroutine needs to be
extended to allow for more parameters. When a new parameter is added then
all programs calling it need to be changed to pass the additional parameter,
even if they don't actually have a use for it. My hope was that with
omitted trailing arguments the subroutine could just check for them being
omitted, and not use them. The way that it stands I find very little use
for it.
So close and yet so far! Argh!
They should also allow the test to be "IF data-name IS OMITTED", which is
also in the standard (rather than checking for an address of NULL).
Oh well...
Frank
William M. Klein
I have sent a query off to my "usually reliable sources" within IBM, but I
would point out that the '02 Standard limits OMITTED to CALLs with
"call-prototypes" and also has the "omitted argument" relational test. IBM
doesn't have either of these, so their OMITTED support is certainly NOT up to
the '02 Standard level (nor do they claim it is).
--
Bill Klein
wmklein <at> ix.netcom.com
"Frank Swarbrick" <Frank.S...@efirstbank.com> wrote in message
news:48DD0EC9.6...@efirstbank.com...
Frank Swarbrick
<8ceDk.360083$Qi2.1...@fe06.news.easynews.com>, William M.
Klein<wmk...@nospam.netcom.com> wrote:
> Frank,
> I have sent a query off to my "usually reliable sources" within IBM,
> but I
> would point out that the '02 Standard limits OMITTED to CALLs with
> "call-prototypes" and also has the "omitted argument" relational test.
> IBM
> doesn't have either of these, so their OMITTED support is certainly NOT
> up to
> the '02 Standard level (nor do they claim it is).
I must have missed the call-prototype restriction.
Anyway, thanks for checking for me.
Frank
James J. Gavan
I'm fascinated that you always seem to go looking for problems that you
can create in COBOL. What's wrong with KISS ?
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) ???
Jimmy
docd...@panix.com
James J. Gavan <jgavande...@shaw.ca> wrote:
[snip]
>I'm fascinated that you always seem to go looking for problems that you
>can create in COBOL. What's wrong with KISS ?
Come now, Mr Gavan... if 'a person's got to know their limits' then a
person must, at some point, test those limits to breaking. Likewise with
new tools and learning; on the way to becoming the Olde One who can say
'You can try that, sure, but when I did we brought down Prod for six
hours... then again, we were using IFOX and IKFCBL00 so maybe it's time to
see what's changed!'
>
>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) ???
Complexity is in the mind of the beholder, Mr Gavan... consider the
following:
01 CALLING-DATA.
05 WS-CALLING-POSSIBILITY-NUM001 PIC S9(3) COMP-3 VALUE 1.
05 WS-CALLING-POSSIBILITY-DATA.
10 WS-CALLPOSS-FROMDT PIC 9(8) VALUE ZEROES.
10 WS-CALLPOS-TODT PIC 9(8) VALUE ZEROES.
10 FILLER PIC X(74) VALUE SPACES.
05 WS-CALLING-POSSIBILITY-NUM002 PIC S9(3) COMP-3 VALUE 2.
10 WS-CALLPOS-STOCK-OPEN PIC S9(5)V9(4) COMP-3 VALUE +0
10 WS-CALLPOS-STOCK-MID PIC S9(5)V9(4) COMP-3 VALUE +0
10 WS-CALLPOS-STOCK-CLOSE PIC S9(5)V9(4) COMP-3 VALUE +0
10 FILLER PIC X(85) VALUE SPACES.
05 WS-CALLING-POSSIBILITY-NUM003 PIC S9(3) COMP-3 VALUE 3.
10 WS-CALLPOSS-TEMP-FAHRENHEIT PIC S9(9)V9(4) COMP-3 VALUE +0.
10 WS-CALLPOSS-TEMP-CELSIUS PIC S9(9)V9(4) COMP-3 VALUE +0.
10 WS-CALLPOSS-TEMP-KELVIN PIC S9(9)V9(4) COMP-3 VALUE +0.
10 FILLER PIC X(75) VALUE SPACES.
...
01 REDEF REDEFINES CALLING-AREA.
05 CALLING-ITEM OCCURS 999.
10 CALLING-POSSIBILITIY-NUM PIC S9(3) COMP-3.
10 CALLING-ITEM-DATA PIC X(100).
... and then the LINKAGE becomes a mere
01 WS-LINKAGE-DATA.
05 WS-LPARM-LEN PIC S9(4).
05 WS-LPARM-ITEM.
10 WS-LPARM-NUM PIC S9(3) COMP-3.
10 WS-LPARM-DATA PIC X(100).
... and then a simple
MOVE CALLING-ITEM (SUB1) TO WS-LPARM-ITEM
CALL SUBRTN USING WS-LPARM-ITEM
... and, of course, a subroutine that begins as All Good Subroutines
should:
PROCEDURE DIVISION USING LPARM-ITEM.
IF LPARM-NUM NOT NUMERIC
(set error flags/msgs)
GO TO 9998-BAD-DATA-RETURN.
IF LPARM-NUM = 0
(set error flags)
GO TO 9998-BAD-DATA-RETURN.
IF LPARM-NUM > (max errors handled)
(set error flags, message to increase table size)
GO TO 99980BAD-DATA-RETURN.
*
GO TO PROCESS-DATA-001,
PROCESS-DATA-002,
PROCESS-DATA-003
... PROCESS-DATA-999
DEPENDING ON LPARM-NUM.
What's easier than that? Never mind that it is is cumbersome and relies
on the assumption that human time is less expensive than machine time...
it sure is simple *and* blindingly fast, too!
DD
William M. Klein
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.
--
Bill Klein
wmklein <at> ix.netcom.com
"William M. Klein" <wmk...@nospam.netcom.com> wrote in message
news:8ceDk.360083$Qi2.1...@fe06.news.easynews.com...
Frank Swarbrick
<748Ek.804832$3p2.3...@fe10.news.easynews.com>, William M.
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
Frank Swarbrick
> 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
Pete Dashwood
"Frank Swarbrick" <Frank.S...@efirstbank.com> wrote in message
news:48E118C2.6...@efirstbank.com...
You've highlighted something very important here, Frank.
A large amount of the maintenance that goes on in COBOL shops is down to
interface changes, exactly as you describe.
In an OOP environment the same kind of problem can happen, but the
environment is more "forgiving"...
I'll try and explain.
Suppose I have a Class and it has a method called "SomeMethod" that takes
parameters p1, p2 and p3.
I get an object instance of this class stored in "objMyClass" (OBJECT
REFERENCE)...
In OO COBOL I would write:
invoke objMyClass "SomeMethod"
using p1, p2, p3
end-invoke
Now we hit a snag. My Class can be late or early bound. If it is late bound
things are resolved at run time and I can "get away with" not passing all
parameters to it; if it is early bound, the compiler will check the
parameters for compliance to the method prototype and shoot me down in
flames if they are not "all present and accounted for".
I use latebound classes exclusively because they require less maintenance
and are more flexible, but I have the luxury of deciding policy in my shop.
(Latebound does incur an overhead, but I find this acceptable... it is
simlar to, though not exactly the same as... dynamic versus static linkage.)
Some time back I got to thinking about all the regression testing every time
you change an interface and decided there had to be a better way.
There is. (at least if you are using OO COBOL).
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?
I know of no way to do this in standard COBOL, but there is a pretty easy
way to do it with OO, especially if the Class you are dealing with is a COM
object...
Say I only need p2 for a specific invoke... I can do this:
invoke objMyClass "SET-p2"
using ws-p2
end-invoke
(This uses the COM support base class in Fujitsu... here's the same thing in
a non-COM object)
invoke objMyClass "setp2"
using ws-p2
end-invoke
(The difference is that I don't have to write the "setter" method for the
COM object (they are inherited automatically from the Fujitsu Base Class), I
do have to if it is my own object.)
So now I have set the parameter(s) to whatever value(s) I want BEFORE
invoking the Class Method. I don't need to pass them and the interface
disappears...
invoke objMyClass "SomeMethod"
end-invoke
No interface, no regression testing.
If I add another parameter to the Class (and usually I don't, but that's
another story...) ONLY the calls that need THAT parameter need to be tested.
Object methods are encapsulated within the Class so there is no danger of a
new parameter affecting existing Methods. (I can make sure by simply
extending the Class or overriding it for instances where the new parameter
is used; existing instances use the same method with the same parameters
they have always used.)
It's fairly hard to explain the ramifications and benefits of this. I have
tried (and failed dismally... :-)) to do so here on a few occasions. This is
what I'm talking about when I say that OO requires less maintenance than
procedural code.
The "parameters" are set in the Class as PUBLIC PROPERTIES so they are
visible to external programs, through the GET and SET methods.
Calling (invoking, in an OO context) programs pre-set the "parameters"
before they activate the method. It's a bit like setting the points on a
railway line, then allowing the train to go.
Immediate benefits are encapsulation of specific methods and parameters, and
NOT needing to amend a suite of programs because an interface changed. If
there is no interface, it CAN'T change.
Pete.
--
"I used to write COBOL...now I can do anything."
James J. Gavan
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
Pete Dashwood
"James J. Gavan" <jgavande...@shaw.ca> wrote in message
news:ihhEk.97$cs4...@newsfe01.iad...
> Frank Swarbrick wrote:
>>>>>On 9/26/2008 at 8:43 PM, in message <p5hDk.137$J63...@newsfe08.iad>,
>>
>> James
>> J. Gavan<jgavande...@shaw.ca> wrote:
>>
<snip>
I thought your idea of using collections for parameters was imaginative, but
there are a couple of problems with it, as far as I'm concerned.
1. Encapsulation. An object instance of a Class should be encapsulated.
PROPERTIES achieve that, sharing parameters in a Collection, doesn't. It
becomes unwieldy when you start having a separate Collection for each
program, although you certainly COULD do that. The problem is that the
Collection has to be shared so that whatever is calling can set it up. That
violates encapsulation. Using the PROPERTY approach, only the object which
owns the property can ever access it. "Outsiders" have to do so through a
method of the object.
2. There are a variety of ways to access the collection (indexes, keys,
hashes, etc.) and this gets confusing. The access method needs to be
overridden if you want to access with a key to a parameter instead of an
index. If you manage it with collection indexes they have to be maintained
when a parameter is deleted, and so on. It is DOable, but unwieldy in my
opinion. (You may not be aware, but Fujitsu (at Enterprise level) offer a
rich series of Collection Classes for COBOL. They include:
COLLECTION CLASS
CLEAR-COLLECTION Makes the current collection empty.
CLONE-COLLECTION Creates a replica of the current collection.
CONTAINS-ELEMENT Checks whether the current collection contains a specified
element.
CONTAINS-ALL-ELEMENT Checks whether the current collection contains all
elements in
a specified collection.
CREATE-ITERATOR Creates an iterator object for the current object.
GET-SIZE Returns the number of elements in the current collection.
IS-EMPTY Checks whether the current collection is empty
LIST CLASS
CREATE-LIST-ITERATOR Creates a list iterator object for the current list.
EQUALS-LIST-COLLECTION Checks whether the current list matches a specified
one.
LINKED LIST CLASS
ADD-FIRST-ELEMENT Adds an element to the head of the current list.
ADD-LAST-ELEMENT Adds an element to the end of the current list.
GET-FIRST-ELEMENT Returns an element at the head of the current list.
GET-LAST-ELEMENT Returns an element at the end of the current list.
REMOVE-FIRST-ELEMENT Deletes an element at the head of the current list.
REMOVE-LAST-ELEMENT Deletes an element at the end of the current list.
SET CLASS
ADD-ELEMENT Adds an element to the current set.
ADD-ALL-ELEMENT Adds all the elements included in a specified
collection to the current set.
EQUALS-SET-COLLECTION Checks whether the current set and a specified set
are equivalent.
REMOVE-ELEMENT Removes an element from the current set.
REMOVE-ALL-ELEMENT Removes all the elements included in a specified
collection from the current set.
MAP CLASS
CLEAR-COLLECTION Makes the current map empty.
CLONE-COLLECTION Creates a replica of the current map.
CREATE-ITERATOR Creates an iterator object for the current map.
GET-SIZE Returns the number of entries for the current map.
IS-EMPTY Checks whether the current map is empty.
MAP ENTRY CLASS
CONTAINS-KEY Checks whether a specified key is contained in the
current map.
CONTAINS-VALUE Checks whether a specified value (object) is
contained in the current map.
EQUALS-MAP-COLLECTION Checks whether the current map matches a
specified map.
GET-VALUE Returns a value (object) of a specified key from
the current map.
PUT-ENTRY Adds an entry (key and value) to the current map.
PUT-ALL-ENTRY Adds all entries (keys and values) contained in a
specified map to the current map.
REMOVE-ENTRY Deletes an entry (key and value) of a specified key
from the current map.
COLLECTION EXCEPTION CLASS
GET-CLASS-NAME Returns the class name of a class library in which an
exception object occurs.
GET-METHOD-NAME Returns the method name of a class library in which an
exception object occurs.
GET-CODE Returns an exception type.
GET-MESSAGE Returns an exception message
I have never had occasion to use them in COBOL, but I use collections in C#
and VB all the time. I think it is fair to consider a set of parameters to a
program as a collection. It is the mechanics of it, not the concept which I
don't personally like.
I see what you are saying, but I wouldn't do it. (Too complex...)
>
> 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.
>
The problem is that parameters need to be associated with a Class, and
different methods of the Class may require different parameters. I use
Object PROPERTIES because they are owned and accessed by the Class, and
access to them is simple and unambiguous.
Connecting a group of parameters on a file or database (or in a
Collection...) and then using different entry points to access them is
technically feasible, but I have never worked on a site where they would
allow this.
I think it is an imaginative approach but it is just too complex and
unwieldy, compared to using properties.
Just one man's opinion...:-)
James J. Gavan
No doubt you found the suggestions from Pete and myself interesting, but
not particularly germane to your current problem for mainframe
Procedural. I'll get back to Pete's comments later, but first......
Wont guarantee it, but working 'backwards, from my thoughts on
Collections, I might just hit on a suggested Procedural solution - but
no promises.
I need to know a few things. I know confidentiality is involved, but can
you perhaps illustrate the sort of parameter requirements and why,
without being specific,
"This program is being used to check dodgy customers and close their
accounts, fr' instance Freddie and Fannie, AIG etceterah"
- so get 'clever' hide the real intent; some dummy parameter names
without giving the game away.
So now some questions :-
- How many sub-programs being called and any need for expansion.
- Is there a maximum number of parameters covering all programs above
- Actual parameters can be permutated per sub-program - correct ?
- Parameter fields can be a mix of pic x(?) and pic 9(?) - can you
specify a maximum size for BOTH; should you say hit on a max pic x(512),
can you also come up with a desirable smaller average value; i.e. we
have two options covering pic x(?) parameter sizes. (My own thoughts -
can't see that you would be passing pix c x(512) - but unless I ask, we
aren't going to know).
- A point I made in my original e-mail, is each set of parameters only
applicable to a particular sub-program or can Permutation-A apply to
sub-programs 2, 5, 7; is there a Permutation-B that would apply to
sub-programs 1,3, 4, 6
Puhleeese - if possible illustrate your parameters at the moment and the
sort of pic x(x) or pic 9(x) values they hold.
From above I'll try and figure what I can do. If you can think of
anything else pertinent to the problem that I haven't indicated, please
let me/us know.
Jimmy