persisting Object Refences in COBOL
in [Cobol]
|
Prev: Line ASequential - FIXED LENGTH
Next: Cobol is Dead
From: Pete Dashwood on 12 Aug 2010 07:11 I recently wrote a COBOL .DLL that is designed to remain resident and be shared. It is written in compliance with the rules for Dynamic Program Linkage in a Fujistu environment. Basically, this means you provide an Entry file which equates entry points with .dlls and the COBOL RTS then uses this file to determine where a COBOL CALL can be loaded from. (Very similar to a standard Windows IMPORT file, but specifically for COBOL.) The nice thing about this is that even if the COBOL CALL is coded statically, it will still load the called module dynamically if it isn't already resident. (This can be useful when you have Legacy code with static calls in it which you want to be dynamic, without having to recode all the COBOL source.) Anyway, one of the called modules instantiates some objects and holds Object References to them in its working-storage. (This is not just the odd object reference; there could be around 50 of them...) Everything works fine and then we found some odd behaviour occuring and it turned out that the library had been reloaded (so all the references were lost). This was caused by it being called from web pages which have different thread signatures (they change with each round trip because the web is stateless). On the desktop or running as a single asynchronous thread, whether called from COBOL or VB, everything behaved just as it should. I figured it would be pretty easy to simply save the array of object references so it could be reloaded if a new copy of the module was loaded. Imagine my horror when I found the following: 1. You are not allowed to reference a group of Object references at a group level. 2. You are not allowed to redefine anything containing Object References. 3. You cannot define Object References in the FILE Section (ONLY WS or LINKAGE...) this makes it pretty hard to write them anywhere, given that you can't reference the goup so it could be moved to a record buffer... Now, there are a few options I can think of (make it a service so it HAS to stay resident; make the offending module a COM component with a factory that always returns the same object reference - once it is loaded, anything trying to instantiate it will get a reference to the loaded component; or maybe just make the whole .dll a COM component and each of the called modules a method (but that would mean huge changes to a lot of source code...) None of these are really very attractive. I was wondering if anybody has encountered this before and how they solved it? In both C# and VB.Net moving and saving object references is pretty straightforward. Any clues, ideas, pointers (oops, sorry for pun :-)) gratefully received. Pete. -- "I used to write COBOL...now I can do anything."
From: Bill Klein on 12 Aug 2010 14:47 Pete, Maybe I missed it in your note (you know my vision problems) - but which COBOL aer you using (on which platform). "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message news:8ci365Fl2tU1(a)mid.individual.net... >I recently wrote a COBOL .DLL that is designed to remain resident and be >shared. It is written in compliance with the rules for Dynamic Program >Linkage in a Fujistu environment. Basically, this means you provide an >Entry file which equates entry points with .dlls and the COBOL RTS then >uses this file to determine where a COBOL CALL can be loaded from. (Very >similar to a standard Windows IMPORT file, but specifically for COBOL.) > > The nice thing about this is that even if the COBOL CALL is coded > statically, it will still load the called module dynamically if it isn't > already resident. (This can be useful when you have Legacy code with > static calls in it which you want to be dynamic, without having to recode > all the COBOL source.) > > Anyway, one of the called modules instantiates some objects and holds > Object References to them in its working-storage. (This is not just the > odd object reference; there could be around 50 of them...) > > Everything works fine and then we found some odd behaviour occuring and it > turned out that the library had been reloaded (so all the references were > lost). This was caused by it being called from web pages which have > different thread signatures (they change with each round trip because the > web is stateless). On the desktop or running as a single asynchronous > thread, whether called from COBOL or VB, everything behaved just as it > should. > > I figured it would be pretty easy to simply save the array of object > references so it could be reloaded if a new copy of the module was loaded. > > Imagine my horror when I found the following: > > 1. You are not allowed to reference a group of Object references at a > group level. > 2. You are not allowed to redefine anything containing Object References. > 3. You cannot define Object References in the FILE Section (ONLY WS or > LINKAGE...) this makes it pretty hard to write them anywhere, given that > you can't reference the goup so it could be moved to a record buffer... > > Now, there are a few options I can think of (make it a service so it HAS > to stay resident; make the offending module a COM component with a factory > that always returns the same object reference - once it is loaded, > anything trying to instantiate it will get a reference to the loaded > component; or maybe just make the whole .dll a COM component and each of > the called modules a method (but that would mean huge changes to a lot of > source code...) > > None of these are really very attractive. > > I was wondering if anybody has encountered this before and how they solved > it? In both C# and VB.Net moving and saving object references is pretty > straightforward. > > Any clues, ideas, pointers (oops, sorry for pun :-)) gratefully received. > > Pete. > -- > "I used to write COBOL...now I can do anything." >
From: Richard on 12 Aug 2010 18:27 On Aug 12, 11:11 pm, "Pete Dashwood" <dashw...(a)removethis.enternet.co.nz> wrote: > I recently wrote a COBOL .DLL that is designed to remain resident and be > shared. It is written in compliance with the rules for Dynamic Program > Linkage in a Fujistu environment. Basically, this means you provide an Entry > file which equates entry points with .dlls and the COBOL RTS then uses this > file to determine where a COBOL CALL can be loaded from. (Very similar to a > standard Windows IMPORT file, but specifically for COBOL.) > > The nice thing about this is that even if the COBOL CALL is coded > statically, it will still load the called module dynamically if it isn't > already resident. (This can be useful when you have Legacy code with static > calls in it which you want to be dynamic, without having to recode all the > COBOL source.) > > Anyway, one of the called modules instantiates some objects and holds Object > References to them in its working-storage. (This is not just the odd object > reference; there could be around 50 of them...) > Everything works fine and then we found some odd behaviour occuring and it > turned out that the library had been reloaded (so all the references were > lost). This was caused by it being called from web pages which have > different thread signatures (they change with each round trip because the > web is stateless). On the desktop or running as a single asynchronous > thread, whether called from COBOL or VB, everything behaved just as it > should. > > I figured it would be pretty easy to simply save the array of object > references so it could be reloaded if a new copy of the module was loaded.. But it is not just the references that are lost, it will be the objects. Each iteration of the web is a new process, a new run-unit, this process is discarded and all allocations, including objects and called module working-storage are freed. You need to have a permanently resident run-unit, not just a callable module. The web process would need to communicate with the run-unit using a pipe or socket. This is what the COBCI-routines are for. > Imagine my horror when I found the following: > > 1. You are not allowed to reference a group of Object references at a group > level. > 2. You are not allowed to redefine anything containing Object References. > 3. You cannot define Object References in the FILE Section (ONLY WS or > LINKAGE...) this makes it pretty hard to write them anywhere, given that you > can't reference the goup so it could be moved to a record buffer... > > Now, there are a few options I can think of (make it a service so it HAS to > stay resident; make the offending module a COM component with a factory that > always returns the same object reference - once it is loaded, anything > trying to instantiate it will get a reference to the loaded component; or > maybe just make the whole .dll a COM component and each of the called > modules a method (but that would mean huge changes to a lot of source > code...) > > None of these are really very attractive. > > I was wondering if anybody has encountered this before and how they solved > it? In both C# and VB.Net moving and saving object references is pretty > straightforward. > > Any clues, ideas, pointers (oops, sorry for pun :-)) gratefully received. > > Pete. > -- > "I used to write COBOL...now I can do anything."
From: Pete Dashwood on 12 Aug 2010 21:36 Bill Klein wrote: > Pete, > Maybe I missed it in your note (you know my vision problems) - but > which COBOL aer you using (on which platform). It' Fujitsu, Bill. (see below) > > "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message > news:8ci365Fl2tU1(a)mid.individual.net... >> I recently wrote a COBOL .DLL that is designed to remain resident >> and be shared. It is written in compliance with the rules for Here it is... Appreciate your interest, thanks. >> Dynamic Program Linkage in a Fujistu environment. Basically, this >> means you provide an Entry file which equates entry points with >> .dlls and the COBOL RTS then uses this file to determine where a >> COBOL CALL can be loaded from. (Very similar to a standard Windows >> IMPORT file, but specifically for COBOL.) The nice thing about this is >> that even if the COBOL CALL is coded >> statically, it will still load the called module dynamically if it >> isn't already resident. (This can be useful when you have Legacy >> code with static calls in it which you want to be dynamic, without >> having to recode all the COBOL source.) >> >> Anyway, one of the called modules instantiates some objects and holds >> Object References to them in its working-storage. (This is not just >> the odd object reference; there could be around 50 of them...) >> >> Everything works fine and then we found some odd behaviour occuring >> and it turned out that the library had been reloaded (so all the >> references were lost). This was caused by it being called from web >> pages which have different thread signatures (they change with each >> round trip because the web is stateless). On the desktop or running >> as a single asynchronous thread, whether called from COBOL or VB, >> everything behaved just as it should. >> >> I figured it would be pretty easy to simply save the array of object >> references so it could be reloaded if a new copy of the module was >> loaded. Imagine my horror when I found the following: >> >> 1. You are not allowed to reference a group of Object references at a >> group level. >> 2. You are not allowed to redefine anything containing Object >> References. 3. You cannot define Object References in the FILE Section >> (ONLY WS >> or LINKAGE...) this makes it pretty hard to write them anywhere, >> given that you can't reference the goup so it could be moved to a >> record buffer... Now, there are a few options I can think of (make it a >> service so it >> HAS to stay resident; make the offending module a COM component with >> a factory that always returns the same object reference - once it is >> loaded, anything trying to instantiate it will get a reference to >> the loaded component; or maybe just make the whole .dll a COM >> component and each of the called modules a method (but that would >> mean huge changes to a lot of source code...) >> >> None of these are really very attractive. >> >> I was wondering if anybody has encountered this before and how they >> solved it? In both C# and VB.Net moving and saving object >> references is pretty straightforward. >> >> Any clues, ideas, pointers (oops, sorry for pun :-)) gratefully >> received. Pete. >> -- >> "I used to write COBOL...now I can do anything." Cheers, Pete. -- "I used to write COBOL...now I can do anything."
From: Pete Dashwood on 12 Aug 2010 23:39
Richard wrote: > On Aug 12, 11:11 pm, "Pete Dashwood" > <dashw...(a)removethis.enternet.co.nz> wrote: >> I recently wrote a COBOL .DLL that is designed to remain resident >> and be shared. It is written in compliance with the rules for >> Dynamic Program Linkage in a Fujistu environment. Basically, this >> means you provide an Entry file which equates entry points with >> .dlls and the COBOL RTS then uses this file to determine where a >> COBOL CALL can be loaded from. (Very similar to a standard Windows >> IMPORT file, but specifically for COBOL.) >> >> The nice thing about this is that even if the COBOL CALL is coded >> statically, it will still load the called module dynamically if it >> isn't already resident. (This can be useful when you have Legacy >> code with static calls in it which you want to be dynamic, without >> having to recode all the COBOL source.) >> >> Anyway, one of the called modules instantiates some objects and >> holds Object References to them in its working-storage. (This is not >> just the odd object reference; there could be around 50 of them...) > >> Everything works fine and then we found some odd behaviour occuring >> and it turned out that the library had been reloaded (so all the >> references were lost). This was caused by it being called from web >> pages which have different thread signatures (they change with each >> round trip because the web is stateless). On the desktop or running >> as a single asynchronous thread, whether called from COBOL or VB, >> everything behaved just as it should. >> >> I figured it would be pretty easy to simply save the array of object >> references so it could be reloaded if a new copy of the module was >> loaded. > > But it is not just the references that are lost, it will be the > objects. Each iteration of the web is a new process, a new run-unit, > this process is discarded and all allocations, including objects and > called module working-storage are freed. Ouch! That certainly seems to be the case, but I was kind of hoping it wasn't. :-) > > You need to have a permanently resident run-unit, not just a callable > module. The web process would need to communicate with the run-unit > using a pipe or socket. I hadn't thought of that. I did think of wrapping it as a Windows service so it would be loaded at system startup and forced to stay resident, but then you get the problem of how to call the modules in the .dll... (The service will recognise interrupts like "start service" "pause" "resume" etc. but at this point I have no idea how to get CALL parameters into it :-)) There is existing code with many thousands of : CALL 'module' using <whatever> ... where <whatever> is different signatures. I'm not sure how I would interface a socket to that but I'll certainly investigate it further. > This is what the COBCI-routines are for. Not come across that. Is this part of Fujitsu COBOL? I'll search the docs. Thanks for your comments, Richard. This is driving me nuts at the moment because it is one of those things that 'almost works'. Like a parachute that almost opens :-) I'll do more homework and report back. Meanwhile, if anyone else has any thoughts or suggestions on this please post. Anything that can trigger an idea is very acceptable.. > > >> Imagine my horror when I found the following: >> >> 1. You are not allowed to reference a group of Object references at >> a group level. >> 2. You are not allowed to redefine anything containing Object >> References. >> 3. You cannot define Object References in the FILE Section (ONLY WS >> or LINKAGE...) this makes it pretty hard to write them anywhere, >> given that you can't reference the goup so it could be moved to a >> record buffer... >> >> Now, there are a few options I can think of (make it a service so it >> HAS to stay resident; make the offending module a COM component with >> a factory that always returns the same object reference - once it is >> loaded, anything trying to instantiate it will get a reference to >> the loaded component; or maybe just make the whole .dll a COM >> component and each of the called modules a method (but that would >> mean huge changes to a lot of source code...) >> >> None of these are really very attractive. >> >> I was wondering if anybody has encountered this before and how they >> solved it? In both C# and VB.Net moving and saving object references >> is pretty straightforward. >> >> Any clues, ideas, pointers (oops, sorry for pun :-)) gratefully >> received. >> >> Pete. >> -- >> "I used to write COBOL...now I can do anything." Pete. -- "I used to write COBOL...now I can do anything." |