RE: [open-cobol-list] libdb Licensing - READ

[Bill Klein]

FYI,
  "LOCK" and *all* of file-sharing/record-locking is in the '02 Standard,
but is in the "processor dependent" list - which (effectively) means they
are "optional"

P.S. As far as tests go, it seems to me that X/Open *used* to have some
"add-on" tests to the NIST tests - which did include "file sharing/record
locking" (which was in that Standard - but NOT exactly as it ended up in the
'02 Standard). 

> -----Original Message-----
> From: address@hidden 
> [mailto:address@hidden On 
> Behalf Of David Essex
> Sent: Friday, May 06, 2005 7:05 AM
> To: open-cobol-list
> Cc: Roger While
> Subject: Re: [open-cobol-list] libdb Licensing - READ
> 
> Roger While wrote:
> 
>  > Re: VBISAM -
>  > Try this :
>  > ... vbisamcvs.tar.gz
>  > Usual configure/make/make install
> 
> With your version, both tests seam to work.
> 
> However, much (much, much, much ...) more testing will be required.
> 
> BTW, the documentation is in MacroS**t Word8. Would it be possible to
> convert it to HTML or even RTF ?
> 
> 
>  > Well, TC, OC and VBISAM were never designed to run natively
>  > under Win. However, OC and VBISAM do run under Cygwin and
>  > supposedly under Ming. (Maybe TC too ?
> 
> Actually TC is derived from a DOS COBOL compiler, which was 
> ported to Linux.
> 
> The only file IO issues which arose with TC was indexed file 
> support on
> Win32. This required a port of BDB (1.86), first to Cygwin 
> then to MinGW.
> 
> Did some one do a port of VBISAM to MinGW ?
> 
> I could not get VBISAM to compile using MinGW. If memory serves me,
> there are some functions and/or structures which were not available on
> MinGW.
> 
> BTW, OC can be considered to be platform-independent. According to the
> SF forums, VBISAM is not. I guess if it supports UN*X and Win32
> file-systems, it should cover the majority of users.
> 
> 
>  > Both VBISAM and C-ISAM do have transaction facilities.
> 
> According to the manual, 'transaction facilities' are available on
> VBISAM to deal with different processes accessing the same record.
> 
> Unfortunately there no tests to verify this claim.
> 
> Generally, some sort of managing facility (external process) would be
> required to manage the concurrency issues.
> 
> 
>  > Interesting point - How does one specify in Cobol if one wants
>  > transactions ?
> 
> The LOCK clauses could be used, which now are part of the 2002 COBOL
> standard.
> 
> But generally, as in the past, concurrency is dealt with externally by
> some other process (facility).
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 
> great events, 4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
> _______________________________________________
> open-cobol-list mailing list
> address@hidden
> https://lists.sourceforge.net/lists/listinfo/open-cobol-list
>