gnucobol-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [open-cobol-list] Sort utility within OC


From: Alain Lucari
Subject: Re: [open-cobol-list] Sort utility within OC
Date: Sat, 26 May 2007 13:10:22 +0200

Hello David,

Very happy to have some news from you.

Le Fri, 25 May 2007 22:10:57 -0400
David Essex <address@hidden> a écrit:

> Robert Moenck wrote:
> 
>  > I read with interest your post on a Sort Utility for OpenCobol.
>  > This is a project I have considered as well.
>  > Maybe we can cooperate on something.
> 
> The modular concept I had in mind would be as follows.
> 
> 1) Command line interface (C code)
> - Used to set files names (input, output, syntax)
> 2) The SORT syntax (YACC/C code)
> - Used to define sort, sum, input, output fields, etc.
> 3) Control (C code)
> - It uses the SORT syntax and command line options to
>      define a 'SORT structure' and choose an algorithm.
> 4) Back end sort utility library (C code)
> - Where the actual SORT and field manipulation is done,
>      using the 'SORT structure'
> 
> I have part 2 working, and about 80% completed.
> 
> Part 1 should not take very long to write.
> 
> The real work would be in parts 3-4. But existing code could be
> taken from OC and/or TC and existing sort programs.
> 
> 
>  > I have used these Mainframe utilities (very slightly)
>  > and to my mind anyone porting a system from the Mainframe
>  > would be looking for this kind of capability.
> 
> True, but most COBOL commercial compilers include a SORT, JCL
> conversion/emulators and other utilities.
> 
> 
>  > Maybe a first cut at the problem would be a Perl wrapper
>  > script around an existing sort program.
> 
> I think that approach would be problematic, in the long run.
> 
> First neither Perl or existing SORT programs have any facility to
> handle mainframe (COBOL) data types.
> 
> I think it would be easier to start with a very basic SORT program,
> and there many examples available on the NET, and build from there.
> 
> And finally Perl can be a problem an many platforms.
> I had to (un)install about 5 different Win32 versions (builds),
> before I found one which worked properly. And even so, the same
> script will run faster on UN*X than Win32.
> 
>  > You mention that you already have some code and I notice you
>  > are a member of Source Forge.
>  > Would setting up a project on Source Forge be a way to get
>  > the ball rolling?
>  > There is an existing project on Cobol Utilities, but it seems
>  > to be mainly a conduit for spam.
> 
> The Cobol Utilities project was setup for COBOL related projects.
> So it would be the ideal place to host a SORT utility program.
> 
> I do not have administrator privileges for that SF project.
> But I don't think it would be very difficult to get CVS commit
> (write) access.
> 
> Unfortunately I do not have very much free time at the moment, so my
> contribution to this project would be limited.
> 
> 
> Cheers
> 
All before is very too much complicated for me. What I can said is :
- In a first time, I have tried to use TC for about 1 000 programs,
 some with Cobol sort, and I have some problems, not only with sort.

- in a second time, I have worked (à little) with Keisuke.
As you well wknow David, first of this time I have used OC for found
what  errors (not found by MF, nor Acu, done that a program running
with  this two do not  compile with TC WITHOUT ANY ERROR MESSAGE.
 The most of the time the problem was a same name used in a copy and 
 in the working-storage of the program.
 OC detect very well that, but what does MF and ACU in this case ?

About SORT, the usage of DB is easy  but not the better way IMHO.
IMHO also the best way is to use Unix sort, with perhaps an easy way
for to lazzies guies for type <info sort> the only complete about.
The guy writing  about said "we works on different unices" and I have
nothing to do with Win users.

But, the better, in the same time I have tried TC and, after OC, I
have searched how to replace C-ISAM, and with the help of Rildo and
some others, used Postgres.
In the most of the cases I have replaced two programs (1 for select 
and sort and 1 for use the result of the sort) by one asking postgres
for sorted result and doing the work.
Sure, I have worked about 3 years (when I have some time) about that
- use my own screen driver with GCC (I am not fanatic of C),
- test TC and OC (great thanks to Rildo and Keisuke)
- How to use Postgres for replace C-ISAM (thanks Rildo). 

The guy write "we would change for the price of compilers" ...
Ok, you can change for free BUT, you can work a little, no ?
Unless, the Indians or the Chineses catch your work in a little time
what you think about ?
If HE know better Cobol than C, like me, He may work a little about ? 

Now I have 4 customers using Posgres and OC on about 50 PCs on Linux
with, for the most, very olds cobol program, writed from 1989, using
Eclair (my own replacing screen secrton)
Postgres (7.4.2)
O-C (old, but tested).

Where is the goal : replace all the bugguies compiler for all OS, with
sure a too big work,
or give a free compiler wich works wells and said "if your preeceding
comiler was bugged or if you want more/too much press your mind and
make it.
For me, the second way is the better : for the price, no reason for
make anything.
  
Regards,
-- 
Alain Lucari (Eurlix)
Ce que l'on conçoit bien s'énonce clairement
et les mots pour le dire arrivent aisément. N. Boileau.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]