Solved! WAS: Re: Unique identifiers
in [Cobol]
|
Prev: Solved! WAS: Re: Unique identifiers
Next: Blue skies shining above me. nothing but .NET do I see :-(
From: Rene_Surop on 23 Feb 2010 00:35 On Feb 23, 1:27 pm, "Pete Dashwood" <dashw...(a)removethis.enternet.co.nz> wrote: > Pete Dashwood wrote: > > I am building some software that will be multiprocessed and > > multithreaded. > > I am beng constrained to write it in COBOL for reasons of history and > > am using Fujitsu NetCOBOL (unmanaged code). > > > It involves accessing various table sets on a RDB from various > > machines on a network, using objects generated for the purpose. (Data > > Access Layer (DAL) objects generated from the PRIMA Toolset.) Various > > users, machines, and application programs could be simultaneously > > accessing the same table set, each using their own instance of the > > DAL object that manages that table set. As these DAL instances will > > be in the memory space of each of the applications running them, this > > is not problematic. > > However, although the DAL objects handle their own multithreading > > (for GET and PUT operations), they do need to maintain state > > (especially when cursors are opened and being run from COBOL) and > > this requires around 16K of information to be attached to each > > instance of a DAL object. It is, in effect, a stateful context of > > that thread from that instance of the DAL object. > > > It is a bit inelegant to keep all this stuff in memory so it gets > > stepped to disk. It is currently keyed under the the ID of the DAL > > object, but once things get externalised (to disk) there is a risk of > > collision and different threads retrieving the wrong context. (As > > noted, multiple platforms could be running the same DAL object, just > > using different instances of it...) > > (I thought about using the DAL factory to stamp a serial number on > > each instance, but different processors would have their own factory > > and use the same serial numbers, so collisions would be inevitable, > > given they are sharing the same DB.) > > > I figured I could serialize the object reference and use that as part > > of the key to the context on disk. > > > I can't. > > > There is no way I can find to manipulate an object reference in > > Fujitsu COBOL. You can't REDEFINE it or ref. mod. it or do anything > > underhand to get a definition of it as 8 bytes. They really protect > > these references extremely well. > > > I considered generating a random number but there is always a risk of > > collision with these. Somehow, I have to make sure that each context > > on disk is uniquely keyed so it can be accessed from any processor on > > any machine without collisions, and the "home base" which originated > > it has to remember that key in its memory space, so it can't be TOO > > big... > > Obviously, we use unique GUIDs (Generated Unique Identifiers) all > > the time in the Windows environment. CLSIDs are just one form of this > > and these GUIDs are 16 bytes (128 bit) so they aren't too big. (After > > serializing them into the Hex form of what they contain we get a 32 > > byte string which is guaranteed to be unique (or the probability of > > collision is longer than the age of the Universe in hours...) > > > I figured I should be able to make a quick COBOL call to the Windows > > API, pick up a GUID and go merrily on my way. > > > However, the Windows API contains no such signature that I can find. > > > I could do this in one statement from C#; but calling a .NET assembly > > from this particular COBOL is a last resort. > > > I know SQLServer has a stored procedure that returns one, but I can't > > be sure they will always be using SQL Server and the code really > > should be DB independent, just as the DAL objects are. > > > Has anyone obtained GUIDs using COBOL? > > I found out that the COM support .DLL (Ole32.dll) has exactly such a > function. > > It was just a matter of obtaining a copy of Ole32.lib so I could link the > routine into COBOL. > > Wouldn't you think that Fujitsu would provide such a lib? They provide one > for the Kernel and User32... > > I COULD have downloaded a tool that generates a lib from a dll but it was > part of a C++ download package that I neither need nor want. > > I ran a search on my main development notebook (BIGBLACK... 1.3 million > files...) and went and made coffee... :-) > > Sure enough it found a number of copies of the required .lib. Seems those > nice people at Microsoft provide .lib versions of all the system .dlls as > part of their platform Software Development Kit. It is so you can reuse all > the functions they have already written into the Operating system (that is, > the ones that AREN'T COM components...[the COM components are already easily > accessible without need for the export/import information carried in > .libs.] ) I had a copy of it within the SDK I installed some years back, and > another copy within the Visual C support installed with Visual Studio 2008. > > I selected what looked like the most recent, copied it to the Fujitsu COBOL > area (running on a virtual machine called LITTLEBLACK, hosted by BIGBLACK > :-)), and then added it to my NetCOBOL project as a library. > > Coded it: > > call "CoCreateGuid" > WITH STDCALL > USING > BY REFERENCE GUID *> this is a 16 byte string > RETURNING returnCode > end-call > > Compiled and linked without problem. > > Stepped through in debugger and received 16 bytes of complete garbage in > GUID and zero in returnCode :-) > > Moved the debug line back to re-execute the call and received another > (different...) 16 bytes of garbage and zero return. > > Changed the debug view and suddenly the 16 bytes of garbage becomes 32 bytes > of HEX symbols that look very much like the registration keys we find on > boxed software (but without the hyphens...) > > The final step will be to pass the 16 bytes to a component I have which > returns the hex values, then add the 32 bytes to the context key for a given > DAL object, before writing it to disk. > > Now I can sleep without worrying about context collisions across the system, > and secure in the knowledge that they can run as many concurrent copies of > their apps as they like and it won't screw the DAL. > > Good result :-) > > Pete. > > -- > "I used to write COBOL...now I can do anything." MF IDE create (automatically) GUIDs everytime you will add a new class to a COM application. It is fixed. Such as; move z"{085CF6BE-F8C3-4C28-92D6-873E632F4237}" to theClassId move z"{0018E7E7-52D9-45C7-9068-375516F410D4}" to theInterfceId Though I never tried working on it using Ole32.DLL, it sure did do the work for me. Let the IDE create one for me.... and adopt it on my 'manually' created object.
From: Pete Dashwood on 23 Feb 2010 05:13
Rene_Surop wrote: > On Feb 23, 1:27 pm, "Pete Dashwood" > <dashw...(a)removethis.enternet.co.nz> wrote: >> Pete Dashwood wrote: >>> I am building some software that will be multiprocessed and >>> multithreaded. >>> I am beng constrained to write it in COBOL for reasons of history >>> and am using Fujitsu NetCOBOL (unmanaged code). >> >>> It involves accessing various table sets on a RDB from various >>> machines on a network, using objects generated for the purpose. >>> (Data Access Layer (DAL) objects generated from the PRIMA Toolset.) >>> Various users, machines, and application programs could be >>> simultaneously accessing the same table set, each using their own >>> instance of the DAL object that manages that table set. As these >>> DAL instances will be in the memory space of each of the >>> applications running them, this is not problematic. >>> However, although the DAL objects handle their own multithreading >>> (for GET and PUT operations), they do need to maintain state >>> (especially when cursors are opened and being run from COBOL) and >>> this requires around 16K of information to be attached to each >>> instance of a DAL object. It is, in effect, a stateful context of >>> that thread from that instance of the DAL object. >> >>> It is a bit inelegant to keep all this stuff in memory so it gets >>> stepped to disk. It is currently keyed under the the ID of the DAL >>> object, but once things get externalised (to disk) there is a risk >>> of collision and different threads retrieving the wrong context. (As >>> noted, multiple platforms could be running the same DAL object, just >>> using different instances of it...) >>> (I thought about using the DAL factory to stamp a serial number on >>> each instance, but different processors would have their own factory >>> and use the same serial numbers, so collisions would be inevitable, >>> given they are sharing the same DB.) >> >>> I figured I could serialize the object reference and use that as >>> part of the key to the context on disk. >> >>> I can't. >> >>> There is no way I can find to manipulate an object reference in >>> Fujitsu COBOL. You can't REDEFINE it or ref. mod. it or do anything >>> underhand to get a definition of it as 8 bytes. They really protect >>> these references extremely well. >> >>> I considered generating a random number but there is always a risk >>> of collision with these. Somehow, I have to make sure that each >>> context on disk is uniquely keyed so it can be accessed from any >>> processor on any machine without collisions, and the "home base" >>> which originated it has to remember that key in its memory space, >>> so it can't be TOO big... >>> Obviously, we use unique GUIDs (Generated Unique Identifiers) all >>> the time in the Windows environment. CLSIDs are just one form of >>> this and these GUIDs are 16 bytes (128 bit) so they aren't too big. >>> (After serializing them into the Hex form of what they contain we >>> get a 32 byte string which is guaranteed to be unique (or the >>> probability of collision is longer than the age of the Universe in >>> hours...) >> >>> I figured I should be able to make a quick COBOL call to the Windows >>> API, pick up a GUID and go merrily on my way. >> >>> However, the Windows API contains no such signature that I can find. >> >>> I could do this in one statement from C#; but calling a .NET >>> assembly from this particular COBOL is a last resort. >> >>> I know SQLServer has a stored procedure that returns one, but I >>> can't be sure they will always be using SQL Server and the code >>> really should be DB independent, just as the DAL objects are. >> >>> Has anyone obtained GUIDs using COBOL? >> >> I found out that the COM support .DLL (Ole32.dll) has exactly such a >> function. >> >> It was just a matter of obtaining a copy of Ole32.lib so I could >> link the routine into COBOL. >> >> Wouldn't you think that Fujitsu would provide such a lib? They >> provide one for the Kernel and User32... >> >> I COULD have downloaded a tool that generates a lib from a dll but >> it was part of a C++ download package that I neither need nor want. >> >> I ran a search on my main development notebook (BIGBLACK... 1.3 >> million files...) and went and made coffee... :-) >> >> Sure enough it found a number of copies of the required .lib. Seems >> those nice people at Microsoft provide .lib versions of all the >> system .dlls as part of their platform Software Development Kit. It >> is so you can reuse all the functions they have already written into >> the Operating system (that is, the ones that AREN'T COM >> components...[the COM components are already easily accessible >> without need for the export/import information carried in .libs.] ) >> I had a copy of it within the SDK I installed some years back, and >> another copy within the Visual C support installed with Visual >> Studio 2008. >> >> I selected what looked like the most recent, copied it to the >> Fujitsu COBOL area (running on a virtual machine called LITTLEBLACK, >> hosted by BIGBLACK :-)), and then added it to my NetCOBOL project as >> a library. >> >> Coded it: >> >> call "CoCreateGuid" >> WITH STDCALL >> USING >> BY REFERENCE GUID *> this is a 16 byte string >> RETURNING returnCode >> end-call >> >> Compiled and linked without problem. >> >> Stepped through in debugger and received 16 bytes of complete >> garbage in GUID and zero in returnCode :-) >> >> Moved the debug line back to re-execute the call and received another >> (different...) 16 bytes of garbage and zero return. >> >> Changed the debug view and suddenly the 16 bytes of garbage becomes >> 32 bytes of HEX symbols that look very much like the registration >> keys we find on boxed software (but without the hyphens...) >> >> The final step will be to pass the 16 bytes to a component I have >> which returns the hex values, then add the 32 bytes to the context >> key for a given DAL object, before writing it to disk. >> >> Now I can sleep without worrying about context collisions across the >> system, and secure in the knowledge that they can run as many >> concurrent copies of their apps as they like and it won't screw the >> DAL. >> >> Good result :-) >> >> Pete. >> >> -- >> "I used to write COBOL...now I can do anything." > > MF IDE create (automatically) GUIDs everytime you will add a new class > to a COM application. It is fixed. Such as; > > move z"{085CF6BE-F8C3-4C28-92D6-873E632F4237}" to theClassId > move z"{0018E7E7-52D9-45C7-9068-375516F410D4}" to > theInterfceId > > Though I never tried working on it using Ole32.DLL, it sure did do the > work for me. Let the IDE create one for me.... and adopt it on my > 'manually' created object. No, that's not the same thing at all, Rene. (although it looks the same... :-)) That is a CLSID and the fujitsu COM build also applies one to each COM component it builds, as a signature for the registry to uniquely identify the Class. This allows COM components to run as remote procedures across networks using COM+ and DCOM. Each DAL object has a CLSID exactly like this. (Because each object is a COM object and a Class.) However, what I need is to have the CONTEXT of information which is ATTACHED to the object (and MAY be present, depending on the environment it is running in - for example, if it is running on a web page it doesn't need to maintain state, or it can do so using session variabes, but if itis running on a desktop no session variables are available so it needs another "state maintenance" facility...). There are times when it is useful to have a unique identifier on something and KNOW that it is unique :-) Pete. -- "I used to write COBOL...now I can do anything." |