persisting Object Refences in COBOL
in [Cobol]
|
Prev: Line ASequential - FIXED LENGTH
Next: Cobol is Dead
From: Richard on 13 Aug 2010 01:46 On Aug 13, 3:39 pm, "Pete Dashwood" <dashw...(a)removethis.enternet.co.nz> wrote: > 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. > I can only assume that the problem only occurs in web programs and these don't cause issues in other programs running on the desktop. That is to say if you have a desktop program running doing calls to the module this continues without any issues if a web program does a call to the module. The problem appears to be that the web program (CGI) gets an interaction from a form (or similar) and calls the module to create some objects and replies to the browser. Later another interaction occurs, the module is called and there are no objects. It is called being stateless. You need to create a stateful process that remains resident. Apache/IIS CGI -> WebProgram -> COBCI-WRITE/READ <-> resident program with CALL -> module WebProgram disappears but resident program remains resident. You may even need a separate resident program per web user. Or use 'FastCGI' which does some of that for you. > > 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."
From: Pete Dashwood on 13 Aug 2010 02:41
Richard wrote: > On Aug 13, 3:39 pm, "Pete Dashwood" > <dashw...(a)removethis.enternet.co.nz> wrote: >> 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. >> > > I can only assume that the problem only occurs in web programs and > these don't cause issues in other programs running on the desktop. > Yes, that is exactly the case. It is only when called from web pages. > That is to say if you have a desktop program running doing calls to > the module this continues without any issues if a web program does a > call to the module. Not sure. There is a copy of the .DLL loaded on the web server and I'm pretty sure that is the one that isn't working. Sorry to be vague about this but it isn't actually running in my environment. I developed it, tested it, and so did the customer. It all worked fine. Then they started calling it from the web and it doesn't. (It DOES work OK from a web page if it is run as an asynchronous task...) > The problem appears to be that the web program (CGI) gets an > interaction from a form (or similar) and calls the module to create > some objects and replies to the browser. > > Later another interaction occurs, the module is called and there are > no objects. > > It is called being stateless. > > You need to create a stateful process that remains resident. Yes, I think so... :-) I was thinking a service, but I liked your socket/pipe idea too. The process will certainly maintain state as long as it doesn't get reloaded (or the main controlling module of it which has the Object References doesn't get reloaded.) It does this on the desktop without problem. I'm wondering now if I should write a separate web interface for it, based in CGI. > > Apache/IIS CGI -> WebProgram -> COBCI-WRITE/READ <-> resident program > with CALL -> module I understand all of that except the "COBCI-WRITE/READ". I have used the Fujitsu CGI routines with CGI and ISAPI and found them pretty good, but it was a while ago. I'll review this stuff. > > WebProgram disappears but resident program remains resident. > > You may even need a separate resident program per web user. If its in CGI I think it should be OK. Pretty sure it supports "common" routines. > > Or use 'FastCGI' which does some of that for you. Not come across that one, either. Really appreciate your time, Richard. I'm trying to help here for free because the project has run out of money (I think most of us can relate to that...) and I don't want to leave them in the lurch, but I can't really undertake a lot of time on this. I already spent the whole of last weekend looking at it and that was when I discovered that Object References can't be saved. I think the CGI interface may be the way to go, with a shared resident routine holding the ORs. Will definitely advise on how we get on. <snip> Cheers, Pete. -- "I used to write COBOL...now I can do anything." |