On Sat, 24 Feb 1996, Barry Steinhardt wrote:
> Please forgive a non-technical person who has only recently become aware
> of this list.
>
> My organization is considering upgrading from an HP 3000 Series 52 to
> Series 918 and the latest release of MPE-IX. . All of our data base
> related programs are written in Cobol II/V. We have been told that we can
> run them on the new machine in compatability mode with only minor changes
> principally related to the connection to printers and other peripherals.
>
> We are assured by HP and the VAR that this is a common upgrade, so I
> assume others of you have some experience with it.
>
> I would be interested in hearing about those experiences and particularly
> any problems you may have encountered running in compatibility mode.
>
> Thank you.
>
>
> Barry Steinhardt
> Barry Steinhardt
> ACLU
> Associate Director
> 132 West 43 Street
> New York, N.Y 10036
> 212-944-9800 (voice)
> 212-354-5290 (fax)
>
Barry:
We migrated from a 3000/Series III to a 3000/950 way back in 1988 and are
currently on Version 4.0 of MPE/iX. At the time of our migration, nearly
all of our code was done in COBOL/II. To this day, we still use a lot of
the existing COBOL/II code we had back in '88 untouched (no modifications
and no recompiles) and it runs just fine in compatibility mode.
I'd recommend that, if possible, you re-compile your source using the
Native Mode compilers simply to realize the significant performance gain
both in compilation and in execution speed. Just to give you an example
of compilation speed, we recompiled a 10K line COBOL program using the
COB85XL (native mode) compiler vs. the COBOLII (compatibility mode)
compiler. The compilation time for the CM compiler was 20 minutes (wall
time); the same compile for the NM compiler was completed in under 2
minutes (wall time under a typical system load).
There are a few quirks with the COB85XL compiler, particularly in the way
that NM handles files. For instance, if you tried to read a 100-byte
record into a FD of 80 bytes, the COBOLII compiler will happily chop off
the last 20 bytes of the record and give you only the first 80; the
COB85XL compiler will blow up in your face! So you'll need to reconcile
the record size the program expects with the record size actually on disk
in order to avoid that kind of error.
If you find that you absolutely need the CM version of the code, you can
still realize *some* performance gain by using the :OCTCOMP Object Code
Translator against the CM object code file. You'll get at least a few
Native Mode features in a CM object file. Note that the OCTCOMP does not
work in 100% of all cases. There are a very few reasons (I can't recall
the one or two we've experienced) why an OCTCOMPTed object file won't run
correctly and you'll just have to live with the CM version.
The configuration of printers, disks and other peripherals is done using
the :SYSGEN utility rather than the :SYSDUMP utility. SYSGEN is far
superior to SYSDUMP in that it is menu-driven and provides for more
configuration error checking that does SYSDUMP. Also, you can save more
than one configuration and reboot from a different configuration file, if
needed. In addition, terminals, serial printers, etc. are configured
on-line using a VPLUS utility called :NMMGR. In fact, if you purchase HP
OpenView DTC Manager, you can change many of a printer's or terminal's
characteristics "on the fly" -- no more REBOOTING to change a printer's
baud rate!!
Hope this little blurb helps -- Happy Migration !!!
=======================================================================
Tom Madigan | Phone......804.594.7180
Administrative System Manager |
Christopher Newport University | Urgent.....804.594.7220
Computer Center |
50 Shoe Lane | Fax........804.594.7500
Newport News, VA 23606-2988 |
USA | [log in to unmask]
=======================================================================
|
