convert old cobol program
rmunyan
would like to convert it to Access 97 anyone have any ideas or thoughts
on how to achieve this.
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
Michael Mattias
software packages written for Access(r) databases available "off the shelf".
With most of the guts of the system written, you should be able to add any
business "tailoring" to the system fairly easily. And, with ODBC widely
available, you may not even require the "base" package be written in Access,
only that it be written using an ODBC-compliant database.
Don't ignore these possibilities; they may save you a lot of money in the
long run.
Before scrapping and rewriting a major applications system such as
"inventory" (and whatever that entails in you business), you may want to
engage an outside consultant to take a fresh look at your situation. (BIAS
ALERT: I do this kind of consulting for a living, so may be more inclined to
suggest it than, say, a truck driver). (And in a truly remarkable
coincidence, I 'do' COBOL, and a knowledge of COBOL may be an asset in your
migration).
--
Michael Mattias
Tal Systems
Racine WI USA
michael...@gte.net
rmunyan wrote in message <03023aa5...@usw-ex0107-050.remarq.com>...
docd...@clark.net
rmunyan <rmunyan...@citationinc.com.invalid> wrote:
>My company has a very old non-supported cobol inventory program. We
>would like to convert it to Access 97 anyone have any ideas or thoughts
>on how to achieve this.
Yes... it should be rather simple.
1) Find someone who knows both COBOL and Access.
2) Pay this person a Lot of Money.
3) Let this person Do The Job.
DD
Cheesle
news:03023aa5...@usw-ex0107-050.remarq.com...
> My company has a very old non-supported cobol inventory program. We
> would like to convert it to Access 97 anyone have any ideas or thoughts
> on how to achieve this.
I don't believe it. The particular Cobol vendor might have been pulling the
trigger alright, but I would be very surprised if your cobol wouldn't be
easier ported to another Cobol vendor than for instance MS Access.
I don't know of any Cobol to MS Access conversions, and I doubt it is going
to be easy. You will probably be better of trying another Cobol vendor.
Do you know what Cobol it is?
Cheesle
AnhMy Tran
> would like to convert it to Access 97 anyone have any ideas or thoughts
> on how to achieve this.
I know both COBOL and Access.
If your system can work with Access, it is very small application.
Otherwise, it should have been with SQL server or Oracle.
Old COBOL applications may work with DB, and Access can read DB.
Old COBOL may work with Text compressed files or Index files.
In this case, you should write COBOL programs to convert compressed files
and indexed files into un-compressed files, and plain Txt files so that
Access can read them. It is the matter of Data conversion rather than
application or programming conversion. It is the entire system.
There is no way to convert COBOL programms into Access, for COBOL programm
are compiles into EXE files, and Access is MS package that includes all
functions and macros in its black box so that no programmers can convert
them and reuse them.
I can convert COBOL program into VB program or VC++ program, but I don't
think anyone can convert EXEs into SQL server or Oracle applications or
vice versa. They are totally different conceptually.
--
Posted via CNET Help.com
http://www.help.com/
X
>My company has a very old non-supported cobol inventory program. We
>would like to convert it to Access 97 anyone have any ideas or thoughts
>on how to achieve this.
conversion to other languages is often underestimated by people.
For some examples of the realities of language conversions I encourage
you to take a look at http://adam.wins.uva.nl/~x/con/con.html where I
and my russian colleague Andrey A. Terekhov provide you with many
examples on the problems one faces when converting languages. COBOL is
included in this paper.
Have fun
--XX
AI RoboForm
>
> My company has a very old non-supported cobol inventory program. We
> would like to convert it to Access 97 anyone have any ideas or thoughts
> on how to achieve this.
>
> The fastest and easiest way to search and participate in Usenet - Free!
Don't know about program, but you most definitely will need
the data from these old Cobol files. Siber Systems sells
tools that convert old Cobol data files into CVS text files
or into DBF files -- something you will need to do
to make your data readable to Access.
More details on this at http://www.siber.com/sct/datafile/
Regards,
Vadim Maslov
Jerry P
Conversion of the data from COBOL data files to Access is
doable, but non-trivial.
Once you have the data, you have to write Access programs
to replicate the business knowledge built into the original
programs and accumulated over years and years.
While GL/AP/AR programs can cross industry
lines, inventory processing is fraught with the peculiarities
of the business (nursery inventory programs have a code
for when a plant dies, odd check-digit computations for part
numbers, Electronic Data Interchange, sell by fractional
units, multiple prices depending on the customer,
FIFO, LIFO, and other accounting curiosities).
You have to be able to receive, sell, return, and adjust
merchandise, create purchase order, invoices, generate
price labels, produce picking lists, make dozens of
reports, add items to the inventory, delete discontinued
ones, track sales, acquisitions, orders, and returns by
day, week, month, year, interact with customer records,
calculate shipping, and on and on and on.
In sum, as hard as the data conversion will be, it is but
the flicker of a candle compared to the volcano of coding
the business logic.
rmunyan <rmunyan...@citationinc.com.invalid> wrote in message
news:03023aa5...@usw-ex0107-050.remarq.com...
William M. Klein
Doesn't your product require knowing what compiler produced the data files?
(and probably even the appropriate record descriptions)? According to
another part of this thread, the person with the "problem" doesn't even know
the compiler - much less the record layout.
--
Bill Klein
wmklein <at> ix dot netcom dot com
AI RoboForm <in...@roboform.com> wrote in message
news:3855879E...@roboform.com...
> rmunyan wrote:
> >
> > My company has a very old non-supported cobol inventory program. We
> > would like to convert it to Access 97 anyone have any ideas or thoughts
> > on how to achieve this.
> >
> > * Sent from RemarQ http://www.remarq.com The Internet's Discussion
Network *
> > The fastest and easiest way to search and participate in Usenet - Free!
>
Charles Hammond
Charles Hammond, BSIM Undergraduate Program
On Mon, 13 Dec 1999, rmunyan wrote:
> My company has a very old non-supported cobol inventory program. We
> would like to convert it to Access 97 anyone have any ideas or thoughts
> on how to achieve this.
> * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
> The fastest and easiest way to search and participate in Usenet - Free!
The only thing you need to know is how to access the tables in the access
database. You are only moving data from one field to another field.
All you have to do is to figure out how to populate the table with the
files previously used in COBOL which may be vsam and require access keys
and passwords. Maybe you should just hire a conversion expert. How did
you populate the database you have now?
Vadim Maslov
>
> Vadim,
> Doesn't your product require knowing what compiler produced the data files?
> (and probably even the appropriate record descriptions)? According to
> another part of this thread, the person with the "problem" doesn't even know
> the compiler - much less the record layout.
>
> --
> Bill Klein
Yes, it does. Right now we do FSC and MF files.
But we also try to extend into other Cobol data
file formats, and so far our experience was that
with some effort most PC Cobol data file formats
can be understood and read by our readers.
So we will indeed take a look into his data files if
he sends them to us and we will find the best way
to read them.
Regards,
Vadim Maslov
Michael Mattias
>conversion to other languages is often underestimated by people.
>For some examples of the realities of language conversions I encourage
>you to take a look at http://adam.wins.uva.nl/~x/con/con.html where I
>and my russian colleague Andrey A. Terekhov provide you with many
>examples on the problems one faces when converting languages.
I have never been a fan of "verb-for-verb" language conversions; not one
bit.
If the target language can do something more efficiently, a language
converter will never find it. (Well, "never" is a pretty strong word, but
damned if I've ever seen a converter do this).
Changing languages is done for a reason: this may be maintainability, or
efficiency, or even the [non-]availability of the original language on a new
piece of hardware or operating system. As long as one is changing - a
generally traumatic event anyway - why not start off "fresh" on the new
system?
While using an indexed table to accomplish "upper-casing" can be done in
C++, and could realistically only be done in (pre-'85) ANSI COBOL using
either
TRANSFORM or some indexed table, isn't the c 'toupper' a superior solution
if moving to C?
MCM
Peter.Schalber
I think there are many other questions.
OK you have to convert the data from the existing COBOL platform .
But:
1. How big is your company ?
2. How many user are working with this software package (Cobol) ?
3. What is your hardware platform ?
4. Do you want to change your hardware platform ?
5. Is it possible to use standard software ?
6. Can Access 97 solve my business logic amd performance requirements ?
Access 97 is a platform for small desktop applications (1 - 6 User)
Peter
"rmunyan" <rmunyan...@citationinc.com.invalid> wrote in message
news:03023aa5...@usw-ex0107-050.remarq.com...
Ken Foskey
>
> conversion to other languages is often underestimated by people.
> For some examples of the realities of language conversions I encourage
> you to take a look at http://adam.wins.uva.nl/~x/con/con.html where I
> and my russian colleague Andrey A. Terekhov provide you with many
> is included in this paper.
I reviewed this paper for IEEE magazine. It is very good. It
basically says that something very simple is not simple.
Verb for verb just will not work. REad the article to find out more.
Thanks
Ken Foskey
http://www.zipworld.com.au/~waratah/