VMS Alpha to Itanium port
Chris Townley
from Alpha to Integrity given to me.
Currently running VMS 6.2 on Alpha - application consists of some 3500
modules Basic, with a smattering of C and macro code. This is an
application I know well, and have been maintaining/developing for some
years. However the oprogrammingh tyeam that took it in-house some 12
years ago is now just me.
I wont even look at the macro - if it doesnt run out of the box, I
rewrite as required, and there is nothing fancy in the C
However the main area will be the basic. Has anyone any ideas what
issues are likely?
TIA
--
Chris
Christoph Gartmann
It really depends on your code. If it contains nothing fancy it is not a big
deal.
Regards,
Christoph Gartmann
--
Max-Planck-Institut fuer Phone : +49-761-5108-464 Fax: -452
Immunbiologie
Postfach 1169 Internet: gartmann@immunbio dot mpg dot de
D-79011 Freiburg, Germany
http://www.immunbio.mpg.de/home/menue.html
Main, Kerry
> -----Original Message-----
> From: Chris Townley [mailto:ccto...@googlemail.com]
> Sent: April 12, 2007 2:56 PM
> To: Info...@Mvb.Saic.Com
> Subject: VMS Alpha to Itanium port
>
> Just suddenly had the concept of porting a legacy in house application
> from Alpha to Integrity given to me.
>
> Currently running VMS 6.2 on Alpha - application consists of some 3500
> modules Basic, with a smattering of C and macro code. This is an
> application I know well, and have been maintaining/developing for some
> years. However the oprogrammingh tyeam that took it in-house some 12
> years ago is now just me.
>
> I wont even look at the macro - if it doesnt run out of the box, I
> rewrite as required, and there is nothing fancy in the C
>
> However the main area will be the basic. Has anyone any ideas what
> issues are likely?
>
> --
> Chris
Chris,
Fyi ..
http://h71000.www7.hp.com/doc/porting.html
http://h71000.www7.hp.com/openvms/integrity/transition/app_tools.html
http://h21007.www2.hp.com/dspp/files/unprotected/openvms/ovms_port_guide
_v81.PDF
Some BASIC porting info (albeit VAX to Alpha) can be found at:
http://www3.sympatico.ca/n.rieck/docs/alpha_diary.html
Other resource links:
http://h71000.www7.hp.com/openvms/integrity/resources.html
http://h71000.www7.hp.com/openvms/integrity/transition/modules.html
Regards
Kerry Main
Senior Consultant
HP Services Canada
Voice: 613-592-4660
Fax: 613-591-4477
kerryDOTmainAThpDOTcom
(remove the DOT's and AT)
OpenVMS - the secure, multi-site OS that just works.
Martin Vorlaender
> Chris Townley wrote:
>> However the main area will be the basic. Has anyone any ideas what
>> issues are likely?
>
[Other good links snipped]
And not to forget Guy's very good presentations on the topic, e.g.
http://www.hp-interex.be/wiki/images/4/48/Porting_real_applications.ppt
cu,
Martin
--
One OS to rule them all | Martin Vorlaender | OpenVMS rules!
One OS to find them | work: m...@pdv-systeme.de
One OS to bring them all | http://www.pdv-systeme.de/users/martinv/
And in the Darkness bind them.| home: mar...@radiogaga.harz.de
VAXman-
>
>
>Main, Kerry <Kerry...@hp.com> wrote:
>> Chris Townley wrote:
>>> However the main area will be the basic. Has anyone any ideas what
>>> issues are likely?
>>
>> http://h71000.www7.hp.com/doc/porting.html
>
>[Other good links snipped]
>
>And not to forget Guy's very good presentations on the topic, e.g.
>http://www.hp-interex.be/wiki/images/4/48/Porting_real_applications.ppt
It might be good but not usefull... ppt!
Any PDF?
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM
"Well my son, life is like a beanstalk, isn't it?"
VAXman-
>
>
>In article <op.tqouj...@notemv-tap.mv.privat>, "Martin Vorlaender" <m...@pdv-systeme.de> writes:
>>
>>
>>Main, Kerry <Kerry...@hp.com> wrote:
>>> Chris Townley wrote:
>>>> However the main area will be the basic. Has anyone any ideas what
>>>> issues are likely?
>>>
>>> http://h71000.www7.hp.com/doc/porting.html
>>
>>[Other good links snipped]
>>
>>And not to forget Guy's very good presentations on the topic, e.g.
>>http://www.hp-interex.be/wiki/images/4/48/Porting_real_applications.ppt
>
>It might be good but not usefull... ppt!
Before I get spanked for spelling... I hit 2 Ls ... only 1 in useful.
Paul Sture
VAXman- @SendSpamHere.ORG wrote:
> In article <op.tqouj...@notemv-tap.mv.privat>, "Martin Vorlaender"
> <m...@pdv-systeme.de> writes:
> >
> >
> >Main, Kerry <Kerry...@hp.com> wrote:
> >> Chris Townley wrote:
> >>> However the main area will be the basic. Has anyone any ideas what
> >>> issues are likely?
> >>
> >> http://h71000.www7.hp.com/doc/porting.html
> >
> >[Other good links snipped]
> >
> >And not to forget Guy's very good presentations on the topic, e.g.
> >http://www.hp-interex.be/wiki/images/4/48/Porting_real_applications.ppt
>
> It might be good but not usefull... ppt!
>
> Any PDF?
Are you in possession of a mailbox or other suitable receptacle?
:-)
--
Paul Sture
Michael Unger
> It might be good but not usefull... ppt!
>
> Any PDF?
Check your mailbox ...
Michael
--
Real names enhance the probability of getting real answers.
My e-mail account at DECUS Munich is no longer valid.
Colin Butcher
http://h71000.www7.hp.com/new/hpugmig.html
--
Cheers, Colin.
Legacy = Stuff that works properly!
dav...@montagar.com
> Just suddenly had the concept of porting a legacy in house application
> from Alpha to Integrity given to me.
I would guess that you will have few problems. I've ported C from
Windows/Linux that I wrote to OpenVMS IA64 with little problem (of
course, I wrote it explicitly with portability in mind), and some old
VAX FORTRAN to IA64 with little problem once the magic qualifiers were
identified.
I would expect BASIC from Alpha to IA64 should be clean, too,
especially if you are using standard language features. The C will
probably be okay. The only wild-card that I'd be concerned about is
MACRO, but Alpha to IA64 will likely be much less trouble than a VAX
to IA64 would be.
bclaremont
> MACRO, but Alpha to IA64 will likely be much less trouble than a VAX
> to IA64 would be.
Moving Macro-32 to Integrity is much smoother than Macro-64. Macro-64
is not portable to the Integrity.
Our Migration RPG product is primarily written in Macro-32. It moved
to Integrity with little drama. See the porting article at:
http://www.migrationspecialties.com/pdf/Porting%20Migration%20RPG%20to%20Itanium_TJ.pdf
Chris Townley
through, but so far am much less worried...
If it goes ahead, I will post an update on how it goes
--
Chris
David J Dachtera
Note that the I64 machines does not support VAX Floating point natively. I don't
recall if there's emulation routines in the I64 BASIC RTL or not.
Programs that depend on undeclared numerics being any special size of VAX
Floating point might not behave as expected.
You must, of course, rebuild from source for these reasons. VMS BASIC images on
VAX can ve VESTed to Alpha, but VMS BASIC images on ALpha cannot be AESTed to
I64.
--
David J Dachtera
dba DJE Systems
http://www.djesys.com/
Unofficial OpenVMS Marketing Home Page
http://www.djesys.com/vms/market/
Unofficial Affordable OpenVMS Home Page:
http://www.djesys.com/vms/soho/
Unofficial OpenVMS-IA32 Home Page:
http://www.djesys.com/vms/ia32/
Unofficial OpenVMS Hobbyist Support Page:
http://www.djesys.com/vms/support/
Dave Froble
I participated in the most recent (Mar 2007) porting event.
My Macro32 based product was up and running in about 2 hours. No mods
required. Mostly the re-compile, link, and environment set-up.
An associate took a bit longer to build an application that is mainly
Basic. Compiled and linked with no problems. Did run into one problem,
which is currently being looked at by HP. Best I can say is that I
think that occasionally the frame set-up for calling a routine is
getting screwed up. A reproducer is in HP's hands, and they have seen
the problem. Therefore I'd expect it being fixed in a timely manner.
Some issues, the version of Basic running on itanic is V1.6. You may
need to be successfully using V1.5 on Alpha, or, you could run into
problems that are not itanic specific, but language specific.
D-Float on itanic is implemented in software, and I believe, does the
actual calculations in IEEE. This can cause problems.
I know there are people who will say, "why don't you just use IEEE", but
what about the data files with 20 years worth of data? It's not just a
programming issue.
In general, things went smoothly, and I feel that the port is quite easy.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Dave Weatherall
wrote:
> D-Float on itanic is implemented in software, and I believe, does the
> actual calculations in IEEE. This can cause problems.
>
> I know there are people who will say, "why don't you just use IEEE", but
> what about the data files with 20 years worth of data? It's not just a
> programming issue.
Or because you're talking to/controlling a system running on VAX with
D-Float only. Not sure what the story is on precision. My memory is
that the Dec floating points are more precise with less range than
their IEEE equivalents. Or is that only the singles? OTOH I guess
(hope?) that s/w emulation of G_floats would be _relatively_ swift on
an Itanium and thus be capable of executing VMS code originally
written for VAX at a more- than-acceptable pace. Still to find the
time to try it...
--
Cheers - Dave W.
David B Sneddon
> In article <op.tqoujzvydc3...@notemv-tap.mv.privat>, "Martin Vorlaender" <m...@pdv-systeme.de> writes:
>
> >Main, Kerry <Kerry.M...@hp.com> wrote:
> >> Chris Townley wrote:
> >>> However the main area will be the basic. Has anyone any ideas what
> >>> issues are likely?
>
> >>http://h71000.www7.hp.com/doc/porting.html
>
> >[Other good links snipped]
>
> >And not to forget Guy's very good presentations on the topic, e.g.
> >http://www.hp-interex.be/wiki/images/4/48/Porting_real_applications.ppt
>
> It might be good but not usefull... ppt!
>
> Any PDF?
>
> --
> VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM
>
> "Well my son, life is like a beanstalk, isn't it?"
Get yourself NeoOffice (if you don't already have it)
then read the ppt and export as pdf -- simple.
Dave
Dave Froble
My understanding is that the D-float uses 3 bits more of precision,
which are lost when the data is converted to IEEE for computation and
then converted back to D-float.
Some people have long ago adopted the convention of rounding all D-float
data after each computation, and to check for equality by testing for
differences being smaller than a selected small value.
John Reagan
>
> I wont even look at the macro - if it doesnt run out of the box, I
> rewrite as required, and there is nothing fancy in the C
As others have mentioned, moving Macro-32 is normally easy, but you
might have to add a few new directives for some non-standard calling
sequences. The Macro compiler and linker can help you track them down.
If you need help, send me email. The vast majority of OpenVMS' own
Macro-32 code went from Alpha to I64 with no modifications required.
>
> However the main area will be the basic. Has anyone any ideas what
> issues are likely?
In general, BASIC should recompile and go. It is the same compiler as
on Alpha. However, there are some nagging performance issues with the
BASIC RTL. The RTL likes to walk up and down the stack looking for
other BASIC routines to propagate things like scaling factor, etc.
While that is quick enough on Alpha, the stack walk is much slower on
I64. That constant stack walking can slow down the BASIC application.
We have fixed many of these issues for V8.3 but there are still others
on our plate. Again, if you need help, send me email.
>
> TIA
> --
> Chris
>
--
John Reagan
OpenVMS Pascal/Macro-32/COBOL Project Leader
Bob Gezelter
Chris,
Many good things have been said, and I will not belabor the points by
repeating them. However, I should note that if your sources are old
enough, in both C and BASIC, you will encounter changes in syntax and
semantics that can be laborious to correct. Not difficult, merely a
bit of editing required. As an example, VAX C permitted some non-
standard syntax conventions for constants. These conventions were not
adopted by ANSI C. ALPHA C permitted the use of the VAX conventions.
The Intel C compiler does not.
I suggest caution, until you get a feel of what, if any, patterns in
your code base are sources of problems.
While it is rare, the changes in floating point formats can cause a
problem, or at best be disconcerting, when comparing data produced on
IA-64 with data produced on Alpha. I have suggested that it is a good
idea to switch floating point formats on the Alpha first, and then
compare the IEEE standard results against one another.
- Bob Gezelter, http://www.rlgsc.com
Dave Weatherall
wrote:
> Dave Weatherall wrote:
> > On Sun, 15 Apr 2007 22:06:53 UTC, Dave Froble <da...@tsoft-inc.com>
> > wrote:
> >
> >> D-Float on itanic is implemented in software, and I believe, does the
> >> actual calculations in IEEE. This can cause problems.
> >>
> >> I know there are people who will say, "why don't you just use IEEE", but
> >> what about the data files with 20 years worth of data? It's not just a
> >> programming issue.
> >
> > Or because you're talking to/controlling a system running on VAX with
> > D-Float only. Not sure what the story is on precision. My memory is
> > that the Dec floating points are more precise with less range than
> > their IEEE equivalents. Or is that only the singles? OTOH I guess
> > (hope?) that s/w emulation of G_floats would be _relatively_ swift on
> > an Itanium and thus be capable of executing VMS code originally
> > written for VAX at a more- than-acceptable pace. Still to find the
> > time to try it...
> >
>
> My understanding is that the D-float uses 3 bits more of precision,
> which are lost when the data is converted to IEEE for computation and
> then converted back to D-float.
>
> Some people have long ago adopted the convention of rounding all D-float
> data after each computation, and to check for equality by testing for
> differences being smaller than a selected small value.
Yep - I learned that one the hard way :)
Syltrem
"Chris Townley" <ccto...@googlemail.com> wrote in message
news:1176404160.8...@o5g2000hsb.googlegroups.com...
Hi
I ported mostly subroutines (many linked to one big shareable image) , and
some executables.
I did not have problems.
Only thing is, I have a Basic USEROPEN routine that coule return the file
creation date and protection info, but this one no longer compiles.
This is true on Alpha and IA64.
You may be missing some of the stuff in BASIC$STARLET.TLB if you use that.
For instance $IMPDEF was missing.
For my USEROPEN, that's where the problem lies... they changed the
definitions to XABDET, XABDATDEF, etc somewhere between now and 10 years ago
when I last compiled the program (when migrating from VAX to Alpha).
If you have a useropen routine that works, I would gladly have it :-)
I still have to get the one I have to work (a bit complicated and not enough
time...).
Good luck with your porting.
Syltrem
No zulu in my email
Hein RMS van den Heuvel
> "Chris Townley" <cctown...@googlemail.com> wrote in message
> I ported mostly subroutines (many linked to one big shareable image) , and
> some executables. I did not have problems.
Excellent. We expected no less from OpenVMS no?
> Only thing is, I have a Basic USEROPEN routine that coule return the file
> creation date and protection info, but this one no longer compiles.
> This is true on Alpha and IA64.
Right, I don't care for the generic XAB + dedicated XABKEY part one
now needs, requiring a union/map per xab. I'd be tempted to pick up
the old definitions from your old (vax) basic adn see if they still
work.
Here is a link to an ITRC reply with pointer to code samples and my
own little sample code I wrote recently which may help some:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1100553
> For instance $IMPDEF was missing.
I'll be curious to learn what that was used for!
Walking RMS Internal-FAB structures?
Cheers,
Hein.
John Vottero
news:1177354201....@y5g2000hsa.googlegroups.com...
There are (or were) two different versions of IMPDEF. One applied to the
sys$persona routines and has been replaced on Alpha and Itanium. That's the
one that appears to be missing. I think it's been replaced by ISSDEF.
David B Sneddon
[...snip...]
>
> If you have a useropen routine that works, I would gladly have it :-)
> I still have to get the one I have to work (a bit complicated and not enough
> time...).
>
> Good luck with your porting.
>
> Syltrem
> No zulu in my email
Not exactly a USEROPEN but it does work...
grab the DBS-SYSRTL package from
http://www.users.bigpond.com/dbsneddon/software.htm
and check the FILE_ATTRIBUTES routine (written
in Macro)
Dave
Jeffrey H. Coffield
returns the actual file name (with the version #). If you send your
useropen to me I could take a look for you.
Jeff Coffield
Hein RMS van den Heuvel
> "Hein RMS van den Heuvel" <heinvandenheu...@gmail.com> wrote in
> >> For instance $IMPDEF was missing.
>
> > I'll be curious to learn what that was used for!
> > Walking RMS Internal-FAB structures?
>
> There are (or were) two different versions of IMPDEF. One applied to the
> sys$persona routines and has been replaced on Alpha and Itanium.
Ah! yes, of course. Guess I have a one-track mind.
I was thinking IMPDEF from LIB.MLB.. the only one I ever use ;-)
The new BASIC XAB definitions always annoyed me some and I never
bothered to figure out how to do them properly. I think that now I
did.
Here is the core of of a suggested solution
RECORD xabdat
VARIANT
CASE
XABDEF xxab ! Shared part for COD, BLN, SPARE AND
NXT
CASE
XABDATDEF xxabdat ! specific part
END VARIANT
END RECORD xabdat
DECLARE xabdat XAB_DAT
Full example below.
Best regards,
Hein van den heuvel ( at gmail dot com )
$ type test.bas
map (date_buf) string date_as_string = 23
open "sys$login:login.com" for input as file #1, useropen
"cdt_useropen"
print date_as_string
end
$ type useropen.bas
FUNCTION LONG cdt_useropen (FABDEF FAB, RABDEF RAB, LONG CHANNEL)
OPTION TYPE = EXPLICIT
! Gets creation date of opened file into shared psect
map (date_buf) string date_as_string = 23
%INCLUDE "$FABDEF" %FROM %LIBRARY "SYS$LIBRARY:BASIC
$STARLET.TLB"
%INCLUDE "$RABDEF" %FROM %LIBRARY "SYS$LIBRARY:BASIC
$STARLET.TLB"
%INCLUDE "$XABDEF" %FROM %LIBRARY "SYS$LIBRARY:BASIC
$STARLET.TLB"
%INCLUDE "$XABDATDEF" %FROM %LIBRARY "SYS$LIBRARY:BASIC
$STARLET.TLB"
RECORD xabdat
VARIANT
CASE
XABDEF xxab ! Shared part for COD, BLN, SPARE AND
NXT
CASE
XABDATDEF xxabdat ! specific part
END VARIANT
END RECORD xabdat
DECLARE xabdat XAB_DAT
EXTERNAL LONG FUNCTION SYS$OPEN, SYS$CONNECT
DECLARE LONG STAT, basic_rtl_provided_xabfhc
basic_rtl_provided_xabfhc = FAB::FAB$L_XAB
FAB::FAB$L_XAB = LOC(XAB_DAT) ! Me first, me first
XAB_DAT::XAB$B_COD = XAB$C_DAT ! Make it real
XAB_DAT::XAB$B_BLN = XAB$C_DATLEN
XAB_DAT::XAB$L_NXT = basic_rtl_provided_xabfhc
STAT = SYS$OPEN(FAB)
STAT = SYS$CONNECT (RAB) IF (STAT AND 1%) = 1%
FAB::FAB$L_XAB = basic_rtl_provided_xabfhc
CALL SYS$ASCTIM (0% BY VALUE, date_as_string, XAB_DAT::XAB
$Q_CDT, 0%)
cdt_useropen = STAT
END FUNCTION
Syltrem
>> Hi
>>
>> I ported mostly subroutines (many linked to one big shareable image) ,
>> and some executables.
>>
>> I did not have problems.
>>
>> Only thing is, I have a Basic USEROPEN routine that coule return the file
>> creation date and protection info, but this one no longer compiles.
>> This is true on Alpha and IA64.
>>
>> You may be missing some of the stuff in BASIC$STARLET.TLB if you use
>> that.
>> For instance $IMPDEF was missing.
>>
>> For my USEROPEN, that's where the problem lies... they changed the
>> definitions to XABDET, XABDATDEF, etc somewhere between now and 10 years
>> ago when I last compiled the program (when migrating from VAX to Alpha).
>>
>> If you have a useropen routine that works, I would gladly have it :-)
>> I still have to get the one I have to work (a bit complicated and not
>> enough time...).
>>
>> Good luck with your porting.
>>
>> Syltrem
>> No zulu in my email
>>
>>
> I have managed to decode the new XAB break up and have a useropen that
> returns the actual file name (with the version #). If you send your
> useropen to me I could take a look for you.
>
> Jeff Coffield
Hein was kind enough to fix the useropen for me
Here it is for others to use
FUNCTION LONG IVAP0049STD (FABDEF FAB, RABDEF RAB, LONG CHANNEL)
! Gets size and creation date of an opened file
OPTION TYPE = EXPLICIT
%INCLUDE "$FABDEF" %FROM %LIBRARY "SYS$LIBRARY:BASIC$STARLET.TLB"
%INCLUDE "$RABDEF" %FROM %LIBRARY "SYS$LIBRARY:BASIC$STARLET.TLB"
%INCLUDE "$XABDEF" %FROM %LIBRARY "SYS$LIBRARY:BASIC$STARLET.TLB"
%INCLUDE "$XABDATDEF" %FROM %LIBRARY "SYS$LIBRARY:BASIC$STARLET.TLB"
%INCLUDE "$XABPRODEF" %FROM %LIBRARY "SYS$LIBRARY:BASIC$STARLET.TLB"
! Ces nouvelles définitions sont une gracieuseté de Hein van den Heuvel
24-APR-2007
! Beaucoup de choses ont changé en 12 ans...
RECORD xabdat
VARIANT
CASE
XABDEF xxab ! Shared part for COD, BLN, SPARE AND NXT
CASE
XABDATDEF xxabdat ! specific part
END VARIANT
END RECORD xabdat
RECORD xabprot
VARIANT
CASE
XABDEF xxab ! Shared part for COD, BLN, SPARE AND NXT
CASE
XABPRODEF1 xxabprot ! specific part
END VARIANT
END RECORD xabprot
DECLARE xabdat XAB_DAT
DECLARE xabprot XAB_PRO
EXTERNAL LONG FUNCTION SYS$OPEN, SYS$CONNECT
DECLARE LONG STAT, basic_rtl_provided_xabfhc
MAP (MAP_IVAP0049STD) &
BASIC$QUADWORD Cre_Date, &
LONG File_Size, &
WORD Rec_Length, &
LONG File_Owner_UIC
MAP (MAP_IVAP0049STD) &
Long Cre_Date_L1, &
Cre_Date_L2, &
String Fill = 6%, &
Word File_Owner_UIC_Mbr, &
File_Owner_UIC_Grp
Init:
Rec_Length = 0
File_Size = 0
Cre_Date_L1 = 0
Cre_Date_L2 = 0
File_Owner_UIC = 0
Begin:
basic_rtl_provided_xabfhc = FAB::FAB$L_XAB
FAB::FAB$L_XAB = LOC(XAB_DAT)
XAB_DAT::XAB$B_COD = XAB$C_DAT ! 1er XAB = infos sur les dates
XAB_DAT::XAB$B_BLN = XAB$C_DATLEN
XAB_DAT::XAB$L_NXT = loc(XAB_PRO::XAB$B_COD) ! Pointeur au 2e XAB
XAB_PRO::XAB$B_COD = XAB$C_PRO ! 2e XAB = infos sur les protections
XAB_PRO::XAB$B_BLN = XAB$C_PROLEN
XAB_PRO::XAB$L_NXT = basic_rtl_provided_xabfhc ! Rajoute a Fin de
la liste
STAT = SYS$OPEN(FAB)
STAT = SYS$CONNECT (RAB) IF (STAT AND 1%) = 1%
Rec_Length = FAB::FAB$W_MRS
File_Size = FAB::FAB$L_ALQ
Cre_Date = XAB_DAT::XAB$Q_CDT
File_Owner_UIC = XAB_PRO::XAB$L_UIC
FAB::FAB$L_XAB = basic_rtl_provided_xabfhc ! Efface linkage de nos
XABs
IVAP0049STD = STAT
END FUNCTION
twn...@kittles.com
> Just suddenly had the concept of porting a legacy in house application
> from Alpha to Integrity given to me.
>
> Currently running VMS 6.2 on Alpha - application consists of some 3500
> modules Basic, with a smattering of C and macro code. This is an
> application I know well, and have been maintaining/developing for some
> years. However the oprogrammingh tyeam that took it in-house some 12
> years ago is now just me.
>
> I wont even look at the macro - if it doesnt run out of the box, I
> rewrite as required, and there is nothing fancy in the C
>
> However the main area will be the basic. Has anyone any ideas what
> issues are likely?
>
> TIA
> --
> Chris
>
Integrity. Dozens of different programmers have worked on this code
over the years, so it had may styles and flavors. The porting effort
took around 80 man hours. Not too bad. The code has currently only
been ported at the compile, link, and run level. We have not done
extensive system testing yet as this was an exploratory port. The 80
hours does not include the time we spent setting up our operating
environment (RDB, startup files, logicals, ...). I am sure that after
testing we will find a few things to fix, but almost all of our code
compiled and linked without change.
Thomas Wirt
Director of IS
Kittle's Home Furnishings
Indianapolis, IN