I’m using structured design to design my aplications which will be constructed with Natural 4.1 for Z/OS.
To achieve a highly cohesive and loosely coupled module, in the context of structured design, the best option is to use a informational cluster. This kind of module is similar to a class, it has it’s own data and subroutines(methods). Each subroutine sees it’s own data(local) and the module’s data (global), but doesn’t see the other subroutine’s data. In Cobol we can achieve it using different entry points in the same program.
I have not found a way to implement this kind of module in Natural 4.1, except using NaturalX. Am I wrong?
An alternative to the use of GDAs is to establish AIVs (application independent variables) that are valid while logged into a specific Natural library. You can initialize these with the library’s startup module defined in Natural security or using LOGONEX1, and they can be accessed by any object while logged into that library.
Like the GDA, as Ralph mentioned, each module would have its own local data constructs as well as access to the application-wide variables.
A few problems arise with the use of a Global Data Area referenced by separeted modules (external subroutines).
Whenever a change is required in the GDA, all modules need at least to be re-compiled.
Everyone can reference this global in as many programs as possible, therefore increasing the coupling between all modules/objects that reference the GDA.
Moreover, this GDA tends to be referenced by modules that are not tightly functionally related, many times demanding new fields to be added to the GDA which are also not related to the already existing fields. This phenomena increases the obscurity of the GDA and the module as a whole and increases the level of detail that one needs to handle with in order to understand the program.
The AIV is a bit better, because you need to declare a homogeneous global data item, that is, a level 01 variable. Hence, its readability is increased. But still has the same problems described above.
The ideal solution would be a single module that contains lexically all the subroutines that process its data (global/shared only for its subroutines, not for the outside). Other procedural languages, like Cobol or PL/I allow this kind of construction.
This approach guarantees the achievement of the information hiding concept, that is, highly related functions and data, all located and hidden inside one single black box. All the other modules in the system can make use of it without knowing its internal functioning or data structures.
The following code is not allowed but would be the ideal:
DEFINE DATA
LOCAL /* THIS DATA IS GLOBAL ONLY FOR THE CONTAINED
.... /* SUBROUTINES WHITIN THE MODULE
END-DEFINE
DEFINE SUBROUTINE SUB-A /* THIS IS AN ENTRY POINT
DEFINE DATA PARAMETER
....
END-DEFINE
...LOGIC...
END-SUBROUTINE
DEFINE SUBROUTINE SUB-B
DEFINE DATA PARAMETER
....
END-DEFINE
...LOGIC...
END-SUBROUTINE
END
Of course it can’t be implemented, but is there a similar way?
Your construct works if your subroutines are in-line subroutines, and you can remove the parameter data. In-line subroutines have access to the local data defined in the program.
I am not sure why you wish to shy away from the GDA concept Ralph suggested. You could have a GDA defined just for that program and it’s dependent subroutines and subprograms (inline or external), which would fit your described need, though it’s still not ideal if you seek to optimize efficiency through used of modular code.
The way you have responded here sounds like you want to apply some kind of Java style of programming to Natural. While academic approaches sound good on a blackboard, it is best to use every tool/programming language in the style of that language. People tried for years to write Natural in COBOL style, and they typically end up with bad Natural. I don’t imagine it will work any better imposing Java-oriented inheritance properties when the existing data concepts in Natural are quite functional and usable for whatever purpose you need.
I’m not saying that GDA, or external subroutines are good or bad, but everything has a trade-off. That’s why I asked you if a different approach exists. Sorry if I was misunderstood.
The concepts discussed are not from Java or other kind of language. It belongs to the design decision phase. Also, it’s not a OO concept, although OO languanges easily implement this approach. Information hidding is an old (about 1970-80) quality concept related to design, not to code. Although it interfers(positively) in the codification.
I agree with you. I can use the GDA only in the programs/subroutines that demands it. In the development phase it sounds good. The real problem appears in the maintenance phase. The GDA is visible to everybody (programers), then, one can use it freely and increments it in a uncontrolled way.
Regarding the in-line vs external subroutines, if I put in-line subroutines acessing the local data, all the variables in the program become shared among all subroutines. When a change needs to be done in the subroutine A, in order to fix a bug, another bug may be introduced in subroutine B, and so on, causing a chain of error propagation. This is a error-prone approach, and unfortunately is over-used in most companies.
I’m trying to construct a defensive design, increasing this way, the life-time of the system to be built.
The only wall between practice and theory is the human factor.
If you want to do peudo OO in Natural the best method is to use a PDA to represent your object(s) and the methods that operate on the “class” are a set of subprograms (eg getters, setters, etc) that use the PDA.
Passing the “psudo” object is just passing the pda data around.
If you want to “extend” the psudo class then you make and additional PDA that has the extra class data so the set of callnats use both PDA’s, which represent the extended class. This means any “extended” classes (PDA#2) can still call the base class (PDA#1) callnats.
If you what the equivalant to Java statics, use and AIV variables prefixed with the PDA name to “remember” data between subprogram calls.
What ever you do dont use external subroutines or GDA they are a mess
This method is the closest way of doing psudo OO in Natural
You could use classes. They have been invented to support Windows DCOM many years ago, but classes are also available on mainframes (at least in 4.2.6 - we actually use). You can define an “object data area” instead of an “parameter data area”. This object data can only be accessed via methods defined for the classes ( = information hiding).
Second best approach is using PDA’s and writing dedicated subprogram(s), which deals with the data - and no other program may manipulate this pda-data. This is a widealy used approach in Natural.