Conference vaxaxp::alphanotes

A Unix-to-Unix or VMS-to-VMS port is faster than (say) a VMS-to-Unix
port. Simple compiler language ports faster than macro code. System
calls are much harder to port than standard language I/O. Programs
that have been ported previously are easier to port than programs
that have never been ported. A good test system is very important.
VEST (if appropriate) would be quicker than recompiling.

The port could go as fast as the compilers and the test system
permit, or it could go as slow as writing all new code from scratch.

Dave

>    what are the important questions of which a migration planner should
>    consider in determining the sizing ?

Some important questions:
  - What OS version are you starting from (presuming VMS->VMS)?
  - What language(s) does the software use?  What versions?
  - What third-party software (libraries, databases, etc) is involved?
  - What other Digital software is involved?
  - Any assembly language, or other machine-specific tricks?
  - Do you share memory between processes?  Use AST's?
  - Need any special hardware?
  - Do you depend on low-level details, such as pagesize, or layout of
    floating-point?

Surely the "Planning for migration" book covers this?

    re .0
    
    plus...
    
    What level of testing is required (i.e. based on mission critical-ness
    of application)?
    
    Does the existing system lend itself to and have facilities for
    regression testing?

    
  >>  The port could go as fast as the compilers and the test system
                                       ^^^^^^^^^         ^^^^^^^^^^^ 
  >>  permit, or it could go as slow as writing all new code from scratch.
    
  This imply the time gap is very hard to estimate indeed.
    
    1) Compilers
    
    if we examine the DEC version of compilers, how would you rate them
    in term of ease of porting, I will imagine C will be on the top
    of the list, how about others ? Please be extensive in your list
    of compilers.
    
    2) Test Systems
    
    I will imagine most customer will not have a sophisicated test
    system so what can we do in this case as we in most cases do
    not know the details of the customer's operations and their
    industrial knowledge (most migrators are from computer science
    or software engineering background) and often migration have
    to be done in a limited time span making studying the customers'
    systems in details for the preparation of testing impossible.
    
    what's your opinion ?
    
    sl.                               

    Actually, if you are moving from VAX C on OpenVMS VAX to DEC C on
    OpenVMS Alpha, then C might be the worst language to port.  Also,
    given the ease of which you can unknowingly add machine-specific
    code in C...  
    
    I would think that Fortran is probably the easiest to port from VAX 
    to Alpha with Pascal, COBOL, Ada, C++, and DEC C to DEC C, all tied
    for 2nd place.  
    
    What languages are you interested in?
    
    				-John

   Every single port is different.  Without at least looking at the
   source code, it's impossible to safely estimate...

    
:  >>  The port could go as fast as the compilers and the test system
:                                       ^^^^^^^^^         ^^^^^^^^^^^ 
:  >>  permit, or it could go as slow as writing all new code from scratch.

:  This imply the time gap is very hard to estimate indeed.

   Uh, I'd say "impossible".  This migration could take anything from
   a week to a year. 

   It's highly dependent on how tightly the programmers tied the code
   to the platform...  For instance, if you've got lots of little twisty
   macro32 programs and the application needs CMKRNL privilege, you're
   likely in trouble...
   
:    if we examine the DEC version of compilers, how would you rate them
:    in term of ease of porting, I will imagine C will be on the top
:    of the list, how about others ? Please be extensive in your list
:    of compilers.

   C code can be difficult to port, or quite easy.  Which end of the
   spectrum depends on the programmer(s).

   I would -- as was previously mentioned -- migrate VAX C to DEC C on
   OpenVMS VAX, before moving from OpenVMS VAX to OpenVMS Alpha.  And
   the same holds true for other products -- get to compatible/current
   versions of OpenVMS, compilers, and any other tools first on the VAX
   platform, then perform the port to Alpha.
    
:    2) Test Systems
:    
:    I will imagine most customer will not have a sophisicated test
:    system so what can we do in this case as we in most cases do
:    not know the details of the customer's operations and their
:    industrial knowledge (most migrators are from computer science
:    or software engineering background) and often migration have
:    to be done in a limited time span making studying the customers'
:    systems in details for the preparation of testing impossible.

   You can imagine what you want, and I'll imagine what I want. :-)
   I'll imagine one or more dedicated porting system(s), as it is far
   easier and far safer to port code somewhere other than on a "live"
   production system.  If your customer is willing to "rush" the
   migration (with information on what that might mean), then the
   customer can pay more for a reduced level of risk and an increased
   level of care, or can pay less and risk more problems.  In either
   case, the customer has made a cost-benefit choice, and hopefully
   it will work out....

Digital does offer DTM which runs on VAX and Alpha VMS platforms
to support sophisticated test systems.

Without a good test system all sorts of subtle bugs will slip through
a major porting effort such as this. When you compile on Alpha you
get the latest and greatest versions of all the compilers. The new
compilers have wonderful optimizers, but (especially for C) if you
break the language rules you won't get the same results that you
used to get. Little technical errors that used to make no difference
become important. If the customer doesn't have a good test system,
now is the time to make one. It would be well worth the effort.

Dave

    
    Re: .5
    
    >> What languages are you interested in?
    
    what do you think of porting VAX BASIC sources to Alpha by recompilation
    with DEC BASIC ?
    
    I find many differences between VAX and DEC BASIC as listed in :

    CLT::CLT$LIBRARY:[DECBASIC.KITS]BASIC012_RELEASE_NOTES.TXT;1
    
        under section 4:
    
                     4 Differences Between DEC BASIC and VAX BASIC..........
    
                      4.1 VAX BASIC Features Not Planned For DEC BASIC......
    
                      4.2 Incompatible Features Between DEC BASIC and
                          VAX BASIC.........................................
    
    
    What do you think of the difficulty in porting BASIC then ?
    What are the main obstacles in porting ?
    
    steve

    Ask in the BASIC conference.  They'll be more than happy to tell you
    want you want to know.
    
    				-John

    
    RE .8
    
    Yes...as John suggests, ask in the DEC BASIC conference (TURRIS::DECBASIC).
    
    While there are a number of VAX BASIC features not implemented
    in DEC BASIC, we have found few (if any) customers who rely on
    these features.  If your customer uses these features, there may
    be a problem, however I expect they do not.
    
    Most of the features which are different between the two languages
    are differences which are not unique to BASIC (for example differenced
    in D-floating).
    
    In general, we believe that porting from VAX BASIC to DEC BASIC is
    quite easy.
    
    						Ed
    
    					(former member - DEC BASIC Engineering)

:    What do you think of the difficulty in porting BASIC then ?
:    What are the main obstacles in porting ?

   The crystal ball says this port will take you exactly 3.1415926535
   years, but only if the year starts on a full moon.  :-)

   Again, please read the available documentation, and please review
   the code.  These documents and this code review will contain the
   answers to your questions -- without both, answers you will get
   here are just as accurate as those of the crystal ball.  :-)

    re .*
    
    Well at least BASIC is not a language that encourages architecture
    specific hacks (e.g. as C does).
    
    I've sacrificed a few virgins and goats and the answer is 
    2.7182818284590452354 years provided that you start within the next 5 hours.

    
    Re .12
    
>    Well at least BASIC is not a language that encourages architecture
>    specific hacks (e.g. as C does).
    
    Guess you didn't program much on RSTS/E eh? :-)  :-)
    
    					Ed
    
    

    
    of course, code-review is the logical way to determine portability,
    but it is not practical when you have more than 1,200,000 line of
    codes and you have to estimate the migrate project sizing within
    week.
    
    what would you do then ?
    
    steve

.14> [...]		migrate project sizing within
.14>     week.
    
    I would explain exactly this to your Customer and ask them to permit
    you the required time to perform a formal Migration Assessment.. any
    thing less is really guesswork and leaves both parties exposed..
    
    John.

    re .14
    
    Note also that some aspects of code review can be automated. E.g. once
    you identify some arch specific things, you can automate the search for
    all occurrences of it. It isn't exact but it helps.

Right now you have almost no information about what the code to be ported
looks like.  If you really need a better answer within a week, try sampling
the code -- as randomly as you can -- to look for problems.  You can
then give a slightly better estimate as to whether most of the code will be
easy, most of it will have trouble, or something in between.

  Um.  Copy to an Alpha, compile and link, read errors ?

  I did this with a huge, old program.  Got it to run in a few days.

  Testing it out took most of the time.

  If you aren't that familiar with the language, find somebody who is.

  bb

    
    yes, migration involves both the porting and the testing effort,
    so what is the % of each in a typical situation if
    
    migration (100%) = porting (? %) + testing (? %)
    
    steve

   Without information on the code and the test suite, there's no way
   to answer this...

:    migration (100%) = porting (? %) + testing (? %)

   I've seen anything from porting circa 0% (easily portable code) and
   testing effort circa 100% (no test suite; extensive by-hand testing
   required) to porting circa 100% (highly-architecture specific and
   non-portable code) and testing effort circa 0% (excellent test suite).

>    of course, code-review is the logical way to determine portability,
>    but it is not practical when you have more than 1,200,000 line of
>    codes and you have to estimate the migrate project sizing within
>    week.
>    
>    what would you do then ?
    
    Sell the project in two stages.  First stage is code review.  After
    completing the code review, you quote the second stage.  That way, both
    you and the customer knows what they are getting in to.