Calling structure suggestions 1

[razalas]

Ok, not sure if this is the right forum for this question, but to my mind it should be.

I am looking for suggestions or descriptions of best practices for setting up (or more accurately, changing) the calling structure for an application.

Here's the scenario:

We have a fairly large code base of applications (hundreds of programs and well over 10M SLOC) in Cobol running under Linux. All the programs are interlinked by hard-coded program calls. 99% of the program calls use absolute path names to identify their targets.

The problem this creates is that it makes it difficult to set up multiple independent development/test environments. Doing so requires maintaining separate copies of the source code with all the hard-coded links overridden to point to the current development environment.

When I was in the mainframe world, we used to manage this issue by concatenating multiple program libraries in the JOBLIB or STEPLIB. The equivalent in a *nix setup is to catenate multiple search directories pointed to by the PATH environment variable. And there's the rub, since all our called programs are identified by absolute fully qualified path names there's is no searching the PATH. So...

What are we to do?

As I see it, these are our options:

0) Status Quo

CALL "/usr/apps/next-program.cob"
     USING PASS-DATA...

[ul]
[li]Pros: No immediate impact to production environments[/li]
[li]Cons: continuing bottleneck for multiple development efforts[/li]
[li]Risks: continuing degradation of ability for development to meet changing needs of business[/li][/ul]
1) Rewrite all application programs to use a centralized called program manager

MOVE "next-program.cob"
     TO NAME-OF-NEXT-PROGRAM
*** PROGRAM-MANAGER looks up location of
*** next program from some data store
*** and effects the transfer of control
CALL PROGRAM-MANAGER
     USING NAME-OF-NEXT-PROGRAM
           PASS-DATA...

[ul]
[li]Pros: maximum flexibility[/li]
[li]Cons: significant effort required with little immediate visible gain to justify the work[/li]
[li]Risks: high probability for errors based on integration of new code into existing code base[/li][/ul]
2) Remove all hard-coded links and fall back to using the PATH mechanism for controlling program versions that are executed

CALL "next-program.cob"
     USING PASS-DATA...

[ul]
[li]Pros: minimal code change, gain required flexibility, code changes can be largely automated[/li]
[li]Cons: requires validation of PATH setup for all existing users[/li]
[li]Risks: minimal risk for code translation errors, slight risk for user setup errors[/li][/ul]
3) Replace all absolute path names for called programs with relative path names

CALL "Programs/next-program.cob"
     USING PASS-DATA...

[ul]
[li]Pros: same as for #2, does not rely on PATH setup of users[/li]
[li]Cons: requires specialized links to be set up for each execution environment[/li]
[li]Risks: easy to crash production environment by destroying local links[/li][/ul]

I have proposed both options 2 and 3 before to my management, but they have always been reluctant to consider implementing either change. I think, somewhere in the past, they were bitten by an issue caused by executing the wrong version of a program and therefore are afraid to leave the security of their hard-coded absolute program identifiers. But we have got to do something...

Does anybody have any other suggestions for dealing with this type of situation?

Code what you mean,
and mean what you code!
But by all means post your code!

Razalas

 

[fredericofonseca]

I would suggest another option.

Create a database of the correct path to call the programs.
then change the programs so they call a central program to retrieve the correct location (and even name) of the program to call.

MOVE "next-program.cob"
     TO NAME-OF-NEXT-PROGRAM
*** PROGRAM-MANAGER looks up location of
*** next program from some data store
*** and effects the transfer of control
CALL PROGRAM-MANAGER
     USING NAME-OF-NEXT-PROGRAM
           CALL-MODULE-NAME
**** Upon returning
CALL CALL-MODULE-NAME USING.....

Note that such conversion of programs can be made easily with awk or with a COBOL program that reads the original code, replaces all call's with the above code, retaining the original "using" list, and adds a copybook to the programs containing the variables required to call the program-manager.

Work involved is not as big as you may think. I have done it before in COBOL and it is straightforward to do.



Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

FAQ219-2884
FAQ181-2886

 

[razalas]

Frederico,

thanks for the suggestion!

Yes, if we go that way, that would be a big improvement over the current form for option #1 since it eliminates the need for the program-manager to handle passing variable arguments to the called programs.

Code what you mean,
and mean what you code!
But by all means post your code!

Razalas

 

[fredericofonseca]

Razalas,

When you decide on this one, please come back to us with the final solution.

Also, regarding the automation of the conversion, if you wish I can send you a program I did to convert calls to a routine. Should be easy to adapt to your programs.

email frederico_fonseca at the domain below if you wish to contact me.

Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

FAQ219-2884
FAQ181-2886

 

[razalas]

Frederico,

we are just starting a large project and I had posted this question hoping to get some additional ideas to help me convince my management to allow us to make these changes to help us out internally going forward.

I've gotten the ok to proceed with option 3 just for the development phase of this project since we have to do something similar just to be able to test anyway. We are supposed to put it all back to full, hard-coded pathnames when we install it into production.

I am hoping that after testing with the suggested changes, "we" will gain enough confidence to leave it in place. I'll be sure and post back when it's all done.

BTW, there was a fourth option which I failed to mention. That is to put the names/locations for all called programs into a single copybook and include it in each program which needs to call another program. This approach can become unwieldy so I would rather not take that approach.

I will probably e-mail you in the next couple of days to take a look at the conversion you offered, but right now I have to go prep for a web show.

Code what you mean,
and mean what you code!
But by all means post your code!

Razalas

 

[Crox]

Hi Razalas,

the idea of Fredericofonseca is ok, but it can be done better. Define call's as a service. Use an interface that can handle the call as a service-name. The PROGRAM-MANAGER can be a service handler. Use an interface-type with a version so that you will be free to change the interface any time.

The service-handler can have it's own parameters, like people use in architectural environments. In those environments, the service-handler knows what program lays behind the service call also at what date. So if you want to migrate some subsystems, you define other programs in the service-handler tables that will take over for example in january.

It is not so difficult to use this approach, it seems almost the same, as Fredericofonseca's, but it is more flexible. For example if you want to test, you can define other modules with a complete other name to run your application. If your service-handler can act on users, it can know that for a certain user, it has to use other tables to connect a service to a program. Even running in production-environment, it can handle test-transactions without any problem, making special logs.....

This way of service-handling is used a lot in some environments. It is very comfortable.

Regards,

Crox

 

[razalas]

Crox,

that sounds great, but how do I implement that in a Cobol environment?

Can you point me to an example somewhere?


Code what you mean,
and mean what you code!
But by all means post your code!

Razalas

 

[k5tm]

Use an interface-type with a version so that you will be free to change the interface any time.

that sounds great, but how do I implement that in a Cobol environment?

I am juxtaposing these two statements. Is the concept of an interface type what you find interesting?

It really is not that difficult, if you plan for it. You can plant a version in the input parameters of a subprogram, or you can use EXTERNAL to set up a version for the entire run unit, etc. If a new interface version means that parameters have changed, you can define any number of 01-level parameter descriptions in linkage section. Then, at the beginning of the called program, determine the interface version and base the formal parameters that are correct for that version to the actual parameters.

This can make for some rather arcane-looking COBOL code.



Tom Morrison

http://www.liant.com

 

[Crox]

Hi,

I have some examples in a personal library, never found something on the web. I think there is not a lot of information about this for free outside.....

To give you an idea here is an example of an interface:

       01  GENERAL-CALLHANDLER-INTERFACE.
           03  GENERAL-CALLHANDLER-INPUT.
               05  GENERAL-CALL-HANDLER-VERSION      PIC  X(003).
               05  GENERAL-CALLING-MODULE            PIC  X(008).
               05  GENERAL-ASK4-SERVICE-NAME         PIC  X(008).
               05  GENERAL-ASK4-SERVICE-VERSION      PIC  X(003).
           03  GENERAL-CALLHANDLER-RETURNCODE        PIC S9(004) COMP-5.
               88  GENERAL-CH-OK                     VALUE  ZERO.
               88  GENERAL-CH-FATAL                  VALUE +9999.

Your callhandler can match the service-name with version to the module that has to be called. It is even possible to use the calling module with the match. In the first release, you can use the callhandler just to call the service with the same name as the module that has to be called. You can define your callhandler as recursive. You can define a central definition to do some kind of administration or create a calling-trail. It is useful to use an external field for this.

It is even possible to use the callhandler in two ways, one as call/service handler but also as driver.....

EXTERNAL is something from IBM. I don't know if many COBOL suppliers have implemented this. On the other hand, it is also not so difficult to create a small module that handles in a non-recursive way a variable container where you can create and maintain variables just for your run-unit during the job.

If you use architectural concepts, a call handler and a variable environment routine / container are part of a technical layer for your system.

I hope these possibilities are of interest of the members of this forum. As technical architect and JSP/JSD-coach, I worked a lot with these concepts.

Regards,

Crox

 

[razalas]

Crox,

thanks for clarifying your original suggestion with this last post. What you are advocating is where I would like us to wind up, but it would be a lot change for the moment. This is another level of sophistication above what I was proposing as option #1 in my o/p. If we were rewriting rearchitecting our apps, that would definitely be the way to go.

And, yes, I am familiar with the EXTERNAL attribute. It is part of the Cobol standard, and not just an IBM thing. For instance, I use it in error handling routines, to avoid having to pass back contextual information through intermediate programs that have no knowledge or need for that information.

Regarding the calling structure, if we ever get to re-architect anything, it will be as part of a migration to a whole new development platform (i.e. different programming language, most likely Java). In the meantime, I am just trying to incrementally sneak in additional changes to move us closer to a discernible and consistent master application framework.

You know, it's a shame that most Cobol applications are written, as well, Cobol programs. In spite of its lack of some of the more sophisticated features available in newer languages, there is still quite a bit that can be done more efficiently and simply in Cobol. IMHO, the thing that hurts Cobol most, is the lack of vision and understanding of how applications should be put together as a whole, and that, is really not any fault of Cobol itself.

Code what you mean,
and mean what you code!
But by all means post your code!

Razalas

 

[fredericofonseca]

Razalas,

Mind confirming if ALL your programs use the
CALL "xxxx"
or if some of them use
CALL VARIABLE-NAME

And also if it is possible to have, within the same program, calls to the same program name, buth with different path names.
e.g.
000-section-1
call "/usr/apps/prog1.cob"

000-section-2
call "/usr/apps/account/prog1.cob"



Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

FAQ219-2884
FAQ181-2886

 

[razalas]

Frederico,

about 95% of the calls are

CALL PROGRAM-A

where PROGRAM-A is the unique program name defined in Working storage, like

01  PROGRAM-A PIC X(40) VALUE "/usr/apps/program-a.cob".

Program names are unique. If there is a program named "prog1", it will be "/usr/apps/prog1.cob" everywhere. If there were a "/usr/apps/account/prog1.cob", it would be referred to something other than "prog1", say "acct-prog1".

Code what you mean,
and mean what you code!
But by all means post your code!

Razalas

 

[fredericofonseca]

Thanks for reply.

I just remember another issue. As you didn't mention it, then probably isn't a issue at all, but how do you deal with the location of the files? or are you using SQL to store all your data?

Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

FAQ219-2884
FAQ181-2886

 

[razalas]

The data files all referenced locally in the current working directory. The users are all automatically directed to a particular working directory when they login.



Code what you mean,
and mean what you code!
But by all means post your code!

Razalas