In message <[log in to unmask]>, Michael Anderson 
<[log in to unmask]> writing at 23:34:15 in his/her local time 
opines:-
>On 09/19/2012 02:42 PM, Roy Brown wrote:

>> Mike, I think you might be quoting a PM...
>Uh?

I don't have or see the message from Robert Mills; there's a dot in the 
thread where this message would be. I think he wrote you privately.

>> I've just gotten the free OpenCOBOL product installed and running 
>>after something of a nightmare learning curve.
>> It might have been cheaper for my client simply to have bought 
>>MicroFocus COBOL (or to have hired someone who knew what the hell they 
>>were doing).
>> It was no use me trying to use the OpenCOBOL Forum - they closed that 
>>to new users after a series of spambot attacks, last January, and 
>>still haven't opened it again.
>> They claim to have an alternative place you *can* subscribe to, and 
>>post to, and they'll pick up the messages and put them on the 
>>OpenCOBOL forum.
>> But after two weeks, I'm still waiting for my first such posting to 
>>be moderated and even appear on *that* forum, let alone the OpenCOBOL 
>>forum itself.
>> That's no way to go on :-(

>Keep in mind, this is all on a volunteer basis. I know they are 
>actively working on it, and 2.0 should out soon.

Yes I understand that, and there's no reason they should run a forum at 
all.

But it's a bit shambolic :-(

Update: it turns out I posted to the now discontinued peoplecards.ca :-(

You'd think they'd have shut that down with a final message saying 
'We've moved' wouldn't you? But no....

Fortunately, I've had enough bad experience with dialog boxes on the web 
never to post anything that I haven't written somewhere safe on my 
machine first, so I still have the text I posted.

Now I've gone for the SourceForge account they now recommend. But that 
setup is fubared-on-entry, so I now have to wait for them to notice me 
there, and give me permission to post there, so they can (eventually?) 
pick up my posting and put it in the main forum.

Ho-hum. But of course, I am now well beyond where I was then, so I don't 
know what I'm going to say, any more.

>You may also choose to get the source code to OpenCOBOL and help with 
>the project.

Is it in C? I bet it's in C. I haven't had to learn C yet.

>Or pay someone to help you with it.

*I'm* the person being paid to help my client with this. I'm here to do 
COBOL, and didn't expect to have to learn Red Hat administration in 
order to install the software I was going to use :-)

I did ask for some Linux support on this, from within the organisation, 
but the only person who knows anything about it is horrendously busy :-(

> As I said before; free doesn't mean no price, it means you are free to 
>do what you want with it.
>You may spend as much as you would buying a commercial compiler, but 
>you would not have any additional fees or constraints.
>It would be your own version of the OpenCOBOL compiler, add support for 
>INTRINSIC calls, and HP COBOLII extensions, like $CONTROL and $PAGE, 
>and %MACROS.
>With a good understanding of DWARF & ELF you could even build a 
>interactive debugger, using gdb to step thru your OpenCOBOL code.
>Modify the DISPLAY verb to be WEB ready..... so on..... Then remember 
>"copyleft", post your modifications back to the main project, for 
>possible assimilation.

I'm sure I could; but when I want to just drill a hole in a wall, I buy 
an electric drill, not try to build one :-)

>> If either of you is lucky enough to be subscribed to that Forum, 
>>could you please remind them of what they said, and will they please 
>>go look for my posting - and maybe subscribe me to the actual 
>>OpenCOBOL forum,  so I can use it directly, without all this nonsense?

>I've been subscribed since 2007, I find out whats-up for you.

Thanks - but as above, it seems to be my fault, sort of.

>> But anyway, I solved the problem I had (no thanks to them) after 
>>reading a Red Hat Administrator's guide from cover to cover, with 
>>special attention to rpms and yum, and found out that I needed the 
>>devel rpm for gmp as well as just the ordinary, runtime, rpm.

>> I now have 64-bit OpenCOBOL successfully compiling HP3000 COBOL 
>>programs that have been migrated to UNIX/Oracle, and preprocessed 
>>through Oracle's Pro*COBOL. Which is quite a journey....

>> But we never got 32-bit OpenCOBOL running (though I might know enough 
>>now to do that). Which we needed to run COBOL subprograms with 
>>Powerhouse on UNIX.

>> I've solved it (up to a point) by using an executable COBOL wrapper 
>>for the subprograms, and files for the passed parameters, though 
>>Powerhouse gets upset if I try to reuse one of the files in the same 
>>instantiation... that's tomorrow's problem to bottom...

>> UNIX is a nightmare!

>Its really not that bad, understanding how libraries are linked on Unix 
>will make easier.

>./configure
>make
>make install

That's a superuser command, isn't it? The combination of me and Linux is 
still too dangerous for me to be let loose at root level...

>And the all important
>ldconfig

>Thats really simple.
>Package managers like yum and apt-get will maintain dependency chains, 
>but installs using tarballs with configure & make will not.
>But if you know the dependencies then the package managers can help you 
>get them installed properly.
>Example:
>yum whatprovides ncurses

>will give you the packagename.architecture

>then you
>yum install packagename.architecture

>read up on ldconfig, LP_LIBRARY_PATH and LD_DEBUG variables.

>Its really not much different than MPE's USL,RL, SL, XL, NMRL, and OBJ's
>Yes it is hierarchical and therefore more complex, more configurable, 
>but the same concept as the MPE LINK/PREP commands.

>There are rules, The list of directories to be searched is stored in 
>the file /etc/ld.so.conf.

>http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

Thank you. There's probably only a couple of pages of stuff I need to 
know. Trouble is, up until now, they have been spread out through a 
600-page manual.

>> But why preprocess includes? OpenCOBOL supports COPY, up to a point.

>Yes, but it does not support macro's

Indeed so.

>But your copy module could also contain a macro, right?

Could, I guess. So that's why Copybooks and includes have to be 
preprocessed...

>> Or is it that, unlike HP3000 COBOL II, where the manual says it does 
>>not support nested COPY statements though the compiler actually does, 
>>Open COBOL really doesn't support nested COPY?

>Yes nested copy's do work, however the REPLACING clause does not work. 
>Worse (I think) COPY with REPLACING does not generate a compile error, 
>but the replacement does not occur.

Tut. Hopefully it's logged as a bug on OC?

Cheers

Roy
-- 
Roy Brown        'Have nothing in your houses that you do not know to be
Kelmscott Ltd     useful, or believe to be beautiful'  William Morris

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *