Prev: read disk using mf cobol by \\.\physicaldrivex
Next: Solved! WAS: Re: Unique identifiers
From: Pete Dashwood on 23 Feb 2010 00:27
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."


From: James J. Gavan on 23 Feb 2010 02:02
Pete Dashwood wrote:
> 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.
>
Dammit and heres me having just finished writing a long message that
perhaps you could cherry-pick from. I only stopped to see a repeat of
the Canadian couple win the ice skating Gold. Pleased but not ecstatic.
Not a patch on the Sarajevo, Torval and Dean. As a really wonderful
surprise birthday present, way back Eileen bought tickets to see them in
Calgary. Very entertaining. The final act a blacked out rink. Spotlights
came on and Torval and Dean wrapped in black cloaks. Their cloaks fell
to the ice; we all went nuts in acclamation. They were dressed in their
purple uniforms and to the beautiful mournful music of Ravel's 'Bolero'
they became magic on ice.

Anyway I'll post it now. Are you absolutely sure you have covered for
all potential collisions - my reference to locking techniques in what
I've written. Not checked for typos or spelling, I'll send it after this.

Jimmy
 | 
Pages: 1
Prev: read disk using mf cobol by \\.\physicaldrivex
Next: Solved! WAS: Re: Unique identifiers