| Hello,
Many thanks to all of you.
The Circular problem is fixed and the customer is very happy.
re .5 :
--------
>> Maybe I'll suggest the customer to use one shareable for all the shared modules
>> to avoid the circularity : every module which is not specific to one application
>> will be in this specific shareable image (PROJECT_SHAREABLE).
The customer didn't like it.
re .7 :
--------
>> You can try to link all
>> those modules (here by example COB_NAME_START) in one shareable image
>> and then use this image when you link your both circulary linked
>> images. Hopefully it will be the only image that has LIB$INITIALIZE and
>> will be not circulary linked:
>>
>> +-------+ +-------+
>> | | <---- | |
>> |Image A| ----> |Image B|
>> | | <---- | |
>> +-------+ +-------+
>> | |
>> v v
>> +---------+
>> |New Image|
>> +---------+
I've tried it and it solved the problem !
>> And not forget, perhaps the way, you mentioned in (now deleted) .4 -
>> to place all common routines in one shareable module and avoid
>> circularity - could be the best solution to your problem ...
This solution is not accepted by the customer...
re .8 :
-------
>>I think if you move it
>>into a separate image, you might find some COBOL features stop working
>>-- from the module name, I would expect "CALL dataname" to stop working.
I've made some tests and everything works fine.
>>In your environment, where several independent groups develop pieces,
>>to be put together to form an application, I'm having trouble understanding
>>why it's helpful to deliver the pieces as shareable images, rather than,
>>say, as object libraries. The object libraries would all be linked into
>>a single shared image, to eliminate the circularity problem. Each group
>>could maintain its own copy of the shared image, containing up-to-the-minute
>>copies of that group's code, together with the most recent "stable" version
>>of the code from all the other groups.
The customer doesn't like to have one large shareable image for all the
project : when you fix one module you have to rebuild and distribute all
the project...
re .9 :
-------
>> What the customer is trying to do may be reasonable although I think
>> you need to look carefully at whether the groups are delivering
>> logically independent subsystems with defined interfaces or the
>> shareable images just reflect the organisational structure. If the
>> former (sounds like a vaguely object oriented approach) then probably
>> COBOL is the wrong choice of language.
This is a Bank Application and COBOL is well known language.
>> If the latter then providing an
>> object library instead of a shareable image is functionally equivalent.
If a module is used by many applications , by using shareable image you
just have to change one place when changing the module.
(It's shareable image).
When using Object libraries, many applications must rebuild when changing
a module which is called by many.
>> The bottom line is that initialising shareable images with circular
>> references is considered too hard by VMS (it need not be impossible)
>> and COBOL uses the initialise mechanism.
>> If this is a major problem for your customer, you should escalate
>> formally against VMS and COBOL.
As I mentioned above, the problem is solved.
best regards
Arie.
|