Re: Unisys OS/2200 DMS / TIP / COBOL Migration

Robert,
Question 1:
I could first argue that almost any system is proprietary. The term
open is only valid if you use only the officially standardized part of
your system (e.g. only standard SQL) and none of any proprietary, or
also so called "value add" components of a system. Who does that?
Answer 1:
Ok, Open system would need to be better defined, but for now, Unix and
Linux should be named. Changing the OS in such an environment is
usually not such a big issue.
Question 2:
Whether it is a good idea to stick with a proprietary mainframe like
the 2200 depends on a number of factors: - What is the software
investment in that system?
Answer 2:
This is exactly the point to make, the application software investment
is very likely the reason to migrate off a proprietary mainframe and
keep the application software intact. Intact for the end-users and the
developers. It should not matter on what platform it is running.
Question 3:
How easily can that software be converted and at what total cost?
Answer 3:
The application software is not "converted", rather it is
"migrated" leaving it virtually identical to the way it was on the
mainframe. In order for this to be possible, the new environment must
support the legacy system api's that the application is using. This
is exactly what Inglenet is providing. So the migration is straight
forward leaving the COBOL code, including all the api calls basically
intact. There may be some very minor changes required due to the
differences in COBOL compiler dialects. If there's MASM code, this
typically has to be re-written in C. Often with MASM code, it was
written originally to do something that is very OS specific that
couldn't be done in COBOL. With that kind of stuff, it usually has to
be reworked anyway because of the new OS environment.
Question 4:
What is the guarantee that it will run efficiently and reliably on
another system?
Answer 4:
Ask for some reference accounts, they have all been successful. When it
comes to efficiency, batch run time is usually a good unit of measure,
what about cutting the batch run time down to 20%? Efficient enough?
Modern server technology available today provides tremendous processing
power at very affordable rates. Also main memory capacity on modern
server systems is very large. We often see servers with multiple
gigabytes of main memory which is also contribing to higher throughput.

Question 5:
Is your software "mission critical"? If yes what is the risk involved
in a conversion? Is your business at risk?
Answer 5:
There have been many Unisys migrations using Inglenet tools, all of
them "business critical" ranging from medium size to large scale
shops. None ever failed, running for many years. There are a couple of
recently migrated 2200 sites including the public sector. This is
including police, healthcare and other critical sites, so the risk is
very much limited. Inglenet (formerly Allinson-Ross Corporation) has
been in business since 1974 and currently supports scores of "mission
critical" organizations who are using Inglenet's software to run
their OLTP environment.
Question 6:
Will the "open" system and related system software offer the same
levels of reliability and guarantees of support?
Answer 6:
That depends on what you are choosing as a target system. If you are
looking for a large "name-brand" hardware supplier, there are
several to choose from including IBM, HP, Sun. Each one of these
companies provides their own "branded" version of UNIX such as AIX,
HP-UX and Solaris. With these companies the client is getting same
level of reliability and guaranteed support that one might be familiar
with in the mainframe world. Some customers are not looking for that
level of support from a single supplier. For these accounts, buying a
server from a company like Dell and then adding the OS themselves makes
more sense. In this case, many customers opt for Linux from suppliers
such as Red Hat or SUSE (Novell).
Question 7:
A further question is whether a conversion (especially of older
software) is a good idea if you want to move to an "open" system.
Answer 7:
Agreed, if the software is not worth keeping it, don't migrate. In
fact if you can find a packaged solution that will do what you need,
that likely is the best option. However, what we often discover is that
customers have custom applications because they support unique aspects
of the customers business. This "uniqueness" often gives the
customer a competitive advantage in the marketplace so replacing it
with a commercial off-the-shelf (COTS) package is not an option from a
business planning point of view.
Question 8:
I would rather suggest a rewrite using the tools most appropriate to
the "open" system chosen. This will have to be done any way sooner or
later, so the conversion is in fact just an additional cost.
Answer 8:
If it is considered to "rewrite" which is very rare these days, and
the rewrite is going to take a while, migration is a valid option.
Rewrite can then be done gradually. Migration cost is most likely less
than sticking with a 2200 for a couple of years. A very important
aspect of the Inglenet tools to understand is a component called DBI
(DataBase Interface). What DBI does is to provide legacy database (DMS)
api support for the new relational (Oracle most often) database. So
even thought the data has been unloaded from DMS and reloaded to a
relational model database, DBI makes the relational database look like
the legacy database to the COBOL applications. Furthermore, the
relational schema can be modified to better suite the needs of new
applications without having to change the existing COBOL applications.
This is done through a feature of DBI called "data-mapping" where
you can specify exactly how the relational data is "mapped" to the
DMS sets and records. What this gives you is the ability to develop new
code in new languages (Java, C++, C#, VB etc) that will use the
relational database directly while the existing COBOL applications
continue to use the same relational database through the features of
DBI. This makes re-writing the applications over a period of time much
more feasible than trying to take a shot-gun approach.
Question 9:
Note also that in quite a few cases companies have moved away from
mainframes for demographic reasons: most programs were written long
time ago by people who had retired or were about to retire making it
difficult to support the existing programs. In that case again it is
better to do a rewrite with a team that will be there for a few years
to come.
Answer 9:
We are talking about COBOL here, there is still some time to come until
the COBOL skills are drying up, but in general this may be a good
reason to rewrite, this takes time see above (answer 8).
Question 10:
Of course it also depends on what your business requirements really
are. If you wish to run standard application packages rather than your
own software it is of course an other story.
Answer 10:
Right, running standard applications will basically force you into open
systems, but running part of your own application on the same platform
within the same database system should make sense.
Question 11:
As for the statement you mention, something is missing. What the man
meant to say is that "open systems are an alternative to non-Unisys
proprietary systems".
Answer 11:
Why would you want to limit that to "non-Unisys" proprietary
systems, I did not see it that way, you can however account that to my
very basic English language skills.
Anyway thanks for your comments, they are very much appreciated.
Hans

.

Relevant Pages

  • Re: COBOL tools - and wher are you going (was: Experience with "cobol-it" cobol?
    ... migration" it is enough to get stuff running on the new platform. ... run existing applications under Windows without problem, ... You can write them in OO COBOL or you can use something else, ... Most modern languages support ...
    (comp.lang.cobol)
  • Re: OO in Batch (Was: Program ID)
    ... like a COBOL based ... with support and a really good compiler ... > source) IDE, support for generating CGI, and OO. ... > "Applications that make extensive use of unsupported IBM or Micro Focus ...
    (comp.lang.cobol)
  • RE: Error Occurs in different PC
    ... You may want to check the the reference of the database, ... Microsoft Access 11.0 Object Library ... Microsoft Visual Basic for Applications Extensibility 5.3 ... Microsoft Online Community Support ...
    (microsoft.public.access.formscoding)
  • Re: Windows Ada database support.
    ... DAK> if S.Key in 100..200 then ... *are* reasons for organizing your data this way *in the database*. ... applications with no need to reorganize the data model. ... to support a multitude of applications. ...
    (comp.lang.ada)
  • ANN: Dabo 3-tier desktop framework for data-aware apps
    ... for creating cross-platform data-aware applications. ... The product's name is Dabo, and it will let you create ... Both the database layer and the UI layer can be used ... The primary means of support is provided through the dabo-users ...
    (comp.lang.python)