Re: Information on migration of DMS2200 to relational databases

Harry,
as you are in charge of preparing a research document, this would mean
to gather as much information as possible. Please accept, that
companies like Inglenet or ours are trying to locate business
opportunities. In case there is no opportunity at this moment, we
would be happy to give you as much information as we can in order to
help.
The first step would be to collect all the information about the
current system in order to have clear information about the scope of
the (possible) project.
Once there is a complete inventory, it needs to be figured out what
application infrastructure is available on the possible target
platforms.
Operating System, database, compiler, tools etc.

This are the areas to look at:
Data migration, while this seems to be a simple and straight forward
process, there are some issues to take care about, 9 bit characters,
fieldata, PIC 1 binary fields, 36 bit words and the data alignments
associated.

Source code migration to the target COBOL Compiler for batch and
online programs, taking into account that data might be located at a
different displacement as it used to be - alignment! - and keeping the
logic intact.
API's being used within the application should be left intact as much
as possible, so developers will not be puzzled with different code
injections. Parameters and status information needs to be the same.
Keep in mind that the application is using lots of copy structures
supplied by the OS environment, DMCA from DMS, DPS and TIP related
copy structures, bit switches in batch and ECL etc.

DML for DMS 2200 access and currency are very important as the
application may rely on the DMS navigation concept. Some applications
might even use direct calls to the DMS handler.

For RDMS to Oracle it seems to be a straight forward process changing
to a different SQL dialect, but what about issues like cursor
stability which is definitely different in Oracle and in RDMS. This is
something that might only show up with testing, as it may be relevant
or not, depending on the logical flow of the program.

User interface issues are usually straight forward, if the screen
management system, here most likely DPS is supported on the target
platform. Make sure every function including paging support, line I/O,
dice and fcc's are supported. DPS is also tightly integrated into the
TIP transaction flow
Online printing and file transfer might be an issue to be considered.
There are very often processes that rely on that at the user side and
the IT might not be aware of all of the details.

User training may be largely reduced, if there is the same
functionality as with the common UTS emulators. Simple things like
msg. Wait, xmit, function keys UTS control page settings may require
additional attention. Emulation might be based on 7 bit characters, so
what is the impact when there is an ISO character set on the target
system.

Are there any interfaces to other systems, inbound or outbound, is
there any distributed transaction processing used.

ECL supporting cycled files might be an issue as well as the commonly
used switches.
We think, that we have proven methods and tools for all of the issues
above, so why ignore it?

Staying on the existing platform is always an option, either one is
locked in due to whatever reason (most of the code in MASM is
definitely a reason), or everything is as good as it can be.

If there are no constraints, so why consider to move away, we know a
lot of sites that have already done the move, or are currently
planning it.
Cost, lack of skilled staff, poor performance, difficult data usage,
lack of tools, not a strategic platform within the enterprise are just
a few reasons that spark off a migration discussion. Forget the
performance issue, we have never ever seen that to be an issue. If
someone is still afraid about performance, there is Linux on zSeries
systems.
Regards HansJ

.

Relevant Pages

  • Re: Debug mode
    ... I know the eVC 3 IDE is very fussy about platform mismatches; ... maybe VS 2003 won't support the mismatch when the actual target is WM ...
    (microsoft.public.pocketpc.developer)
  • Re: Porting Cfront to Linux
    ... >> to support a new platform fairly easily, so long as the target ... Comeau C/C++ with Dinkumware's Libraries... ...
    (comp.os.linux.misc)
  • Re: How to delete a feature type in PB4.2
    ... > My platform(Sitsang: a reference board of PXA250) are difficult to start. ... > Setting the "Exclude from build" flag on the PCMCIA driver for ... > the necessary support is not present in your platform. ... > Setting the "Exclude from build" flag on the Local Area Networking ...
    (microsoft.public.windowsce.platbuilder)
  • Re: What so special about PostgreSQL and other RDBMS?
    ... > provider is unavailable or limited to simple telephone support. ... about license management and control of procurement. ... dependencies, at the very least you are dependent on skill and expertise - ... >> even if this means being dependent upon that platform. ...
    (comp.lang.php)
  • Re: MSBuild file for .Net 1.0, 1.1, 2.0, Compact Framework 1.0 & 2.0 and Mono
    ... I'm currently working in a library that has to target both .Net 2.0 and .Net ... But nothing to target Compact Framework ... The existing Any CPU platform remains, and if you build with that platform ... you can override the platform names before including ...
    (microsoft.public.vstudio.development)