In message <[log in to unmask]>, Michael Anderson 
<[log in to unmask]> writing at 09:58:25 in his/her local time 
opines:-
>OpenCOBOL is amazingly complete ANSI85 + plus much of 2002. Some 
>OpenCOBOL only functions may help you with string processing.
>
>Function TRIM()
>Function SUBSTITUTE()
>Function CONCATENATE()
>
>Trim especially helps with calling NON-COBOL functions, for example:
>STRING Trim(my-str-var) x"00" delimited by size into my-C-parm.
>Call "my-C-Func" using my-C-parm.
>
>or
>
>Compute Actual-length-entered = Length(trim(mystring)).
>
>
>Substitute works like INSPECT only better, because substitute strings 
>can vary in length.
>
>Concatenate is like STRING, less verbiage.
>
>Use the Compiler option -ffunctions-all so you won't need to include 
>the key word "FUNCTION" in your source code.
>
>http://opencobol.add1tocobol.com/OpenCOBOL%20Programmers%20Guide.pdf
>
>--
>Mike

Mike, I think you might be quoting a PM...

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 :-(

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?

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!

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

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?

Just like it doesn't support COPYLIBs, mumble, mumble.

Though in my implementation, COPY isn''t supported by Pro*COBOL, even 
for separated COPYLIB members, and I have to use INCLUDE for them (and 
lose the rewriting that COPY can do, in principle, though I don't 
actually need it).

But I haven't tried nested INCLUDES in Pro*COBOL. The manual is silent 
on the matter. I'll give it a go tomorrow and see if it works.

Roy


>On 09/19/2012 09:38 AM, Robert W. Mills wrote:
>> It is currently in pure OpenCOBOL 1.1.
>>
>> My routines that handle $include files and copy modules already use 
>>recursion. Will have a look at a recursive solution for handling the 
>>nested macros as well. Thanks for the suggestion.
>>
>> regards,
>> Robert W.Mills
>>
>>
>> On 19 Sep 2012, at 02:39 PM, Michael Anderson 
>><[log in to unmask]> wrote:
>>
>>> On 09/18/2012 08:54 AM, Robert W. Mills wrote:
>>>> After 4 years without them on OpenCOBOL & MicroFocus I decided to 
>>>>write my own preprocessor.
>>>>
>>>> The current version runs a bit slow (has to make 2 passes of the 
>>>>source file and uses an indexed work file) and can not handle nested 
>>>>
>>> Depending on what language used for your preprocessor, it seem to me 
>>>that "if" the macro handler is a separate function call, then you 
>>>could add some recursive logic to it?
>>>
>>> * To join/leave the list, search archives, change list settings, *
>>> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>
>* To join/leave the list, search archives, change list settings, *
>* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

-- 
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 *