[Info-vax] PostgreSQL (Re: open source OpenVMS (Re: Oracle-RDB seminar notes))

[Bill Gunshannon]

In article <9f64161b-2e02-43aa-8967-3e6fa2f26139 at googlegroups.com>,
	BillPedersen <pedersen at ccsscorp.com> writes:
> On Thursday, April 4, 2013 10:00:07 PM UTC-4, Bill Gunshannon wrote:
>> In article <kjl6uv$b72$1 at dont-email.me>,
>> 
>> 	Stephen Hoffman <seaohveh at hoffmanlabs.invalid> writes:
>> 
>> > On 2013-04-05 00:24:27 +0000, Bill Gunshannon said:
>> 
>> > 
>> 
>> >> In article <5cce1080-517e-40bc-bf57-7daad6f91956 at googlegroups.com>,
>> 
>> >> 	BillPedersen <pedersen at ccsscorp.com> writes:
>> 
>> >>> Actually, we do not care what language you use or even if you use a 
>> 
>> >>> language.  If you have a favorite open source application written in 
>> 
>> >>> any language we would be happy to help you and have your involvement.
>> 
>> >>> We can also use people interested in helping spread the word, run 
>> 
>> >>> tests, manage the VMS-Ports site.  Write wiki articles.  Many, many 
>> 
>> >>> tasks besides programming and porting.
>> 
>> >>> Yes, some of the major support efforts are in C and the CRTL is a major 
>> 
>> >>> focus of issues.  Much of the open source software is written in C.  
>> 
>> >>> But there are also open source applications written in Fortran, COBOL, 
>> 
>> >>> Pascal and other languages. But knowledge of C is not required.
>> 
>> >>> As far as transfer vectors they are alive and well and important to 
>> 
>> >>> allow upgrades of sharable libraries to be done without impacting the 
>> 
>> >>> executables calling them.  Recent work done as a part of some porting 
>> 
>> >>> work has made the transfer vector mechanism nearly identical across all 
>> 
>> >>> three architectures of OpenVMS.
>> 
>> >>> Bill.
>> 
>> >> 
>> 
>> >> I would like to see the ones written in COBOL.  Got any pointers?  :-)
>> 
>> > 
>> 
>> > The transfer vectors (VAX) or symbol vectors (Alpha, Itanium) do not 
>> 
>> > vary by language.   VAX uses a block of assembler, while Alpha and 
>> 
>> > Itanium use linker directives.  (Sure, it would have been nice to add 
>> 
>> > compatible linker directive to VAX, but the goal back then was to get 
>> 
>> > to Alpha and to enhance and update Alpha. What VAX had with its 
>> 
>> > transfer vectors worked, and was already in wide use.)
>> 
>> > 
>> 
>> > Various tools to build the vectors from common sources are available.  
>> 
>> > I've linked to one earlier in this thread, and I suspect gnv has its 
>> 
>> > own implementation.
>> 
>> > 
>> 
>> > As for a COBOL shareable image example, there's one available in the 
>> 
>> > fine manual:
>> 
>> > 
>> 
>> > http://h30266.www3.hp.com/odl/vax/progtool/cobol57a/6297/6297_profile_005.html
>> 
>> 
>> 
>> I wasn't talking about any vectors.  Bill said "But there are also open
>> 
>> source applications written in Fortran, COBOL".  I would like to see
>> 
>> some of these "open source applications" that are written in COBOL.
>> 
>> 
>> 
>> bill
>> 
>> 
>> 
>> -- 
>> 
>> Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
>> 
>> billg999 at cs.scranton.edu |  and a sheep voting on what's for dinner.
>> 
>> University of Scranton   |
>> 
>> Scranton, Pennsylvania   |         #include <std.disclaimer.h>
> 
> I never said there were a lot of open source COBOL programs but here are a couple...
> 
> http://sourceforge.net/projects/apac-accounting/?source=directory
> 
> http://sourceforge.net/projects/acas/?source=directory

Thank you.  I will have to look at the source when I have a few free minutes.
I notice both are precisely the kind of work COBOL was designed for. A very
good choice of languages.

I still have a desire to wrtite an Open Source COBOL project myself.  A
Library Card Catalog.  But it is yet another of those things for which
the time never seems to materialize.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999 at cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>