Itanium Port Question - VMS

This is a discussion on Itanium Port Question - VMS ; I've been called in to help with a port to Itanium on some software that I was the prime developer for many many years. I haven't touched a VMS system in 4 years, plus I only worked part time on ...

+ Reply to Thread
Page 1 of 4 1 2 3 ... LastLast
Results 1 to 20 of 62

Thread: Itanium Port Question

  1. Itanium Port Question

    I've been called in to help with a port to Itanium on some software that I was
    the prime developer for many many years. I haven't touched a VMS system in
    4 years, plus I only worked part time on VMS for the previous 6 years. So here
    goes.

    The application is a commerical tool sold into the VMS marketplace. It supports
    many databases (Rdb, Oracle, etc.) plus RMS. All at the same time. But not all
    customers have all databases, let alone even one database. In order to make
    one set of images work for all customers we would go through the following
    generalized build procedure:

    1. Compile all source code
    2. Link executable images with all databases up and running.
    3. Shut down database A.
    4. Link again, and note all unresolved symbols.
    5. Create shareable image(s) with stub routines containing entry points from step 4.
    6. Redefine logicals relevant to database A to point to shareable image from stop 5
    7. Run and test software with database A missing
    8. Repeat steps 3 through 7 for every database system.

    Notes:
    1. All databases used shareable images.
    2. During startup time, DCL procedures would look to see which databases were
    present and define logicals to point to stub images for missing databases.

    This general build process would work for almost all databases on Vax and Alpha.
    There were some strange things regarding CDD that I don't recall right now.

    The developers involved in the port are telling me that this general process no longer
    works on Itanium. They're getting some kind of "ELF" error message. (I'm trying to
    get the exact error message from them.)

    Any idea if this general approach should still work, or do we need to look at a
    different method?

    --
    Posted via a free Usenet account from http://www.teranews.com


  2. RE: Itanium Port Question

    > -----Original Message-----
    > From: Randy Park [mailto:rvfulltime@isp_removeme_.com]
    > Sent: August 24, 2007 1:28 PM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Itanium Port Question
    >
    > I've been called in to help with a port to Itanium on some software
    > that I was
    > the prime developer for many many years. I haven't touched a VMS
    > system in
    > 4 years, plus I only worked part time on VMS for the previous 6 years.
    > So here
    > goes.
    >
    > The application is a commerical tool sold into the VMS marketplace. It
    > supports
    > many databases (Rdb, Oracle, etc.) plus RMS. All at the same time.
    > But not all
    > customers have all databases, let alone even one database. In order to
    > make
    > one set of images work for all customers we would go through the
    > following
    > generalized build procedure:
    >
    > 1. Compile all source code
    > 2. Link executable images with all databases up and running.
    > 3. Shut down database A.
    > 4. Link again, and note all unresolved symbols.
    > 5. Create shareable image(s) with stub routines containing entry
    > points from step 4.
    > 6. Redefine logicals relevant to database A to point to shareable
    > image from stop 5
    > 7. Run and test software with database A missing
    > 8. Repeat steps 3 through 7 for every database system.
    >
    > Notes:
    > 1. All databases used shareable images.
    > 2. During startup time, DCL procedures would look to see which
    > databases were
    > present and define logicals to point to stub images for missing
    > databases.
    >
    > This general build process would work for almost all databases on Vax
    > and Alpha.
    > There were some strange things regarding CDD that I don't recall right
    > now.
    >
    > The developers involved in the port are telling me that this general
    > process no longer
    > works on Itanium. They're getting some kind of "ELF" error message.
    > (I'm trying to
    > get the exact error message from them.)
    >
    > Any idea if this general approach should still work, or do we need to
    > look at a
    > different method?
    >
    > --
    > Posted via a free Usenet account from http://www.teranews.com


    Randy,

    Not sure if this is the problem or not, but it does discuss some of the I64
    Library and ELF differences:

    http://h71000.www7.hp.com/doc/82fina...73pro_005.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.




  3. Re: Itanium Port Question

    Depends on you programming language, Only macro needs to be rewritten.
    And your third party software, when you have that, needs to be compiled
    on the Itanium.
    When you want to speed-up you need to get rid of allignment failures
    when they show up.

    Evert.

    Randy Park schreef:
    > I've been called in to help with a port to Itanium on some software that I was
    > the prime developer for many many years. I haven't touched a VMS system in
    > 4 years, plus I only worked part time on VMS for the previous 6 years. So here
    > goes.
    >
    > The application is a commerical tool sold into the VMS marketplace. It supports
    > many databases (Rdb, Oracle, etc.) plus RMS. All at the same time. But not all
    > customers have all databases, let alone even one database. In order to make
    > one set of images work for all customers we would go through the following
    > generalized build procedure:
    >
    > 1. Compile all source code
    > 2. Link executable images with all databases up and running.
    > 3. Shut down database A.
    > 4. Link again, and note all unresolved symbols.
    > 5. Create shareable image(s) with stub routines containing entry points from step 4.
    > 6. Redefine logicals relevant to database A to point to shareable image from stop 5
    > 7. Run and test software with database A missing
    > 8. Repeat steps 3 through 7 for every database system.
    >
    > Notes:
    > 1. All databases used shareable images.
    > 2. During startup time, DCL procedures would look to see which databases were
    > present and define logicals to point to stub images for missing databases.
    >
    > This general build process would work for almost all databases on Vax and Alpha.
    > There were some strange things regarding CDD that I don't recall right now.
    >
    > The developers involved in the port are telling me that this general process no longer
    > works on Itanium. They're getting some kind of "ELF" error message. (I'm trying to
    > get the exact error message from them.)
    >
    > Any idea if this general approach should still work, or do we need to look at a
    > different method?
    >


  4. Re: Itanium Port Question

    On Aug 24, 1:27 pm, Randy Park wrote:
    > I've been called in to help with a port to Itanium on some software that I was
    > the prime developer for many many years. I haven't touched a VMS system in
    > 4 years, plus I only worked part time on VMS for the previous 6 years. So here
    > goes.
    >
    > The application is a commerical tool sold into the VMS marketplace. It supports
    > many databases (Rdb, Oracle, etc.) plus RMS. All at the same time. But not all
    > customers have all databases, let alone even one database. In order to make
    > one set of images work for all customers we would go through the following
    > generalized build procedure:
    >
    > 1. Compile all source code
    > 2. Link executable images with all databases up and running.
    > 3. Shut down database A.
    > 4. Link again, and note all unresolved symbols.
    > 5. Create shareable image(s) with stub routines containing entry points from step 4.
    > 6. Redefine logicals relevant to database A to point to shareable image from stop 5
    > 7. Run and test software with database A missing
    > 8. Repeat steps 3 through 7 for every database system.
    >
    > Notes:
    > 1. All databases used shareable images.
    > 2. During startup time, DCL procedures would look to see which databases were
    > present and define logicals to point to stub images for missing databases.
    >
    > This general build process would work for almost all databases on Vax and Alpha.
    > There were some strange things regarding CDD that I don't recall right now.
    >
    > The developers involved in the port are telling me that this general process no longer
    > works on Itanium. They're getting some kind of "ELF" error message. (I'm trying to
    > get the exact error message from them.)
    >
    > Any idea if this general approach should still work, or do we need to look at a
    > different method?
    >
    > --
    > Posted via a free Usenet account fromhttp://www.teranews.com


    Randy,

    I have used precisely this type of procedure many times, most publicly
    in my recent OpenVMS Technical Journal article "Strategies for
    Migrating from Alpha and VAX systems to HP Integrity Servers on
    OpenVMS" (link at http://www.rlgsc.com/publications/vm...trategies.html
    ). I have seen no direct problems.

    My first impression from this post is that one of the build procedures
    is doing something incorrectly. In my examples, I was able to use
    essentially the same build procedures and options files on Alpha and
    Itanium.

    I admit that I would have to look at precisely what you are doing to
    determine where the problem is. However, I CAN say that the general
    approach should work flawlessly.

    - Bob Gezelter, http://www.rlgsc.com


  5. Re: Itanium Port Question

    To all my colleagues,

    For ease of following the dialogue, I suggest that all future postings
    go in the other thread of this topic at
    http://groups.google.com/group/comp....2533b0318224cc

    - Bob Gezelter, http://www.rlgsc.com


  6. Re: Itanium Port Question

    In article , Evert van Dijken writes:

    > Depends on you programming language, Only macro needs to be rewritten.


    And Ada.

    And PLI.

  7. Re: Itanium Port Question

    In article , Evert van Dijken writes:
    >
    >
    >Depends on you programming language, Only macro needs to be rewritten.


    Huh? You need to steer clear of those Amsterdam coffee houses!

    Macro does NOT need to be rewritten to run on Itanium. It didn't need to
    be rewritten to run on Alpha either. I recall this "mythconception" when
    Alpha was first released. A large portion of OpenVMS (VAX/Alpha/Itanium)
    is written in Macro and it has NOT rewritten. There may need to be some
    modifications to the source but there is no need to rewrite the code just
    to port it to Alpha or Itanium.

    --
    VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    "Well my son, life is like a beanstalk, isn't it?"

    http://tmesis.com/drat.jpg

  8. Re: Itanium Port Question

    On 08/26/07 15:20, VAXman- @SendSpamHere.ORG wrote:
    > In article , Evert van Dijken writes:
    >>
    >> Depends on you programming language, Only macro needs to be rewritten.

    >
    > Huh? You need to steer clear of those Amsterdam coffee houses!
    >
    > Macro does NOT need to be rewritten to run on Itanium. It didn't need to
    > be rewritten to run on Alpha either. I recall this "mythconception" when
    > Alpha was first released. A large portion of OpenVMS (VAX/Alpha/Itanium)
    > is written in Macro and it has NOT rewritten. There may need to be some
    > modifications to the source but there is no need to rewrite the code just
    > to port it to Alpha or Itanium.


    Wouldn't alignment faults be more of a problem in Macro than in,
    say, COBOL?

    --
    Ron Johnson, Jr.
    Jefferson LA USA

    Give a man a fish, and he eats for a day.
    Hit him with a fish, and he goes away for good!

  9. Re: Itanium Port Question

    In article , Ron Johnson writes:
    >
    >
    >On 08/26/07 15:20, VAXman- @SendSpamHere.ORG wrote:
    >> In article , Evert van Dijken writes:
    >>>
    >>> Depends on you programming language, Only macro needs to be rewritten.

    >>
    >> Huh? You need to steer clear of those Amsterdam coffee houses!
    >>
    >> Macro does NOT need to be rewritten to run on Itanium. It didn't need to
    >> be rewritten to run on Alpha either. I recall this "mythconception" when
    >> Alpha was first released. A large portion of OpenVMS (VAX/Alpha/Itanium)
    >> is written in Macro and it has NOT rewritten. There may need to be some
    >> modifications to the source but there is no need to rewrite the code just
    >> to port it to Alpha or Itanium.

    >
    >Wouldn't alignment faults be more of a problem in Macro than in,
    >say, COBOL?


    An alignment fault is an alignment fault regardless of the language used
    to source the program. I could write code in any language to experience
    an alignment fault; I could write code in any language to not experience
    an alignment fault. Rewriting a program sourced in language 'P' to one
    source in language 'Q' is not necessarily going to remove issues of any
    alignment fault.

    --
    VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    "Well my son, life is like a beanstalk, isn't it?"

    http://tmesis.com/drat.jpg

  10. Re: Itanium Port Question

    On Aug 26, 5:32 pm, Ron Johnson wrote:
    > Wouldn't alignment faults be more of a problem in Macro than in,
    > say, COBOL?


    This is a COBOL alignment fault ...

    01 TOP-LEVEL.
    03 DATA-ITEM-1 PIC X(1).
    03 DATA-ITEM-2 PIC S9(9) COMP.

    Data-Item-2 is not on a natural boundary. This likely happens in lots
    and lots of places in many COBOL programs. I'm sure there's a ton of
    similar problems in programs I and many others have written over the
    years.


  11. Re: Itanium Port Question

    Hi Frank,

    "FrankS" wrote in message
    news:1188172138.417708.74290@50g2000hsm.googlegrou ps.com...
    > On Aug 26, 5:32 pm, Ron Johnson wrote:
    > > Wouldn't alignment faults be more of a problem in Macro than in,
    > > say, COBOL?

    >
    > This is a COBOL alignment fault ...
    >
    > 01 TOP-LEVEL.
    > 03 DATA-ITEM-1 PIC X(1).
    > 03 DATA-ITEM-2 PIC S9(9) COMP.
    >
    > Data-Item-2 is not on a natural boundary. This likely happens in lots
    > and lots of places in many COBOL programs. I'm sure there's a ton of
    > similar problems in programs I and many others have written over the
    > years.
    >


    It's only an alignment fault if the compiler doesn't spot it and/or doesn't
    generate the instructions to move DATA_ITEM_2 to aligned memory before doing
    any integer operations on it. The fact that it might now take a few more
    instructions is neither here nor there as long as the alignment fault is
    avoided.

    I believe a problem with early versions of DEC COBOL on Itanium is that it
    was pretty useless at spotting unaligned references. I also believe that
    John Reagan's team has corrected most of the problems and a new version is
    available. (I personally think it's a bit rich to refer to it as a "New
    Feature" release but there you go.)

    Cheers Richard Maher



  12. Re: Itanium Port Question

    Forgot to mention that COBOL, like all other compilers, has the /alignment
    qualifiers if you're happy for it to pad 3 bytes between data_item_1 and
    data_item_3.

    Cheers Richard Maher

    "Richard Maher" wrote in message
    news:fat4bh$96q$1@news-01.bur.connect.com.au...
    > Hi Frank,
    >
    > "FrankS" wrote in message
    > news:1188172138.417708.74290@50g2000hsm.googlegrou ps.com...
    > > On Aug 26, 5:32 pm, Ron Johnson wrote:
    > > > Wouldn't alignment faults be more of a problem in Macro than in,
    > > > say, COBOL?

    > >
    > > This is a COBOL alignment fault ...
    > >
    > > 01 TOP-LEVEL.
    > > 03 DATA-ITEM-1 PIC X(1).
    > > 03 DATA-ITEM-2 PIC S9(9) COMP.
    > >
    > > Data-Item-2 is not on a natural boundary. This likely happens in lots
    > > and lots of places in many COBOL programs. I'm sure there's a ton of
    > > similar problems in programs I and many others have written over the
    > > years.
    > >

    >
    > It's only an alignment fault if the compiler doesn't spot it and/or

    doesn't
    > generate the instructions to move DATA_ITEM_2 to aligned memory before

    doing
    > any integer operations on it. The fact that it might now take a few more
    > instructions is neither here nor there as long as the alignment fault is
    > avoided.
    >
    > I believe a problem with early versions of DEC COBOL on Itanium is that it
    > was pretty useless at spotting unaligned references. I also believe that
    > John Reagan's team has corrected most of the problems and a new version is
    > available. (I personally think it's a bit rich to refer to it as a "New
    > Feature" release but there you go.)
    >
    > Cheers Richard Maher
    >
    >




  13. Re: Itanium Port Question

    On Aug 26, 8:04 pm, "Richard Maher"
    wrote:
    > Forgot to mention that COBOL, like all other compilers, has the /alignment
    > qualifiers if you're happy for it to pad 3 bytes between data_item_1 and
    > data_item_3.


    >From a porting perspective, though, I would expect the default

    qualifiers (no alignment) would be used, particularly if data
    structures are being used to read/write from files that already
    exist. That is, if files already exist with records that were not
    padded then the /ALIGNMENT qualifier wouldn't come into play. (Yes,
    yes, I know you can use compiler directives to selectively align
    structures. That's getting way off stream from the question of
    whether or not alignment faults are more likely to occur in Macro .vs.
    COBOL.)

    I'm aware that the compiler will generate instructions to manipulate
    bytes within an aligned quadword, but I didn't think it would generate
    instructions to manipulate all data items so that alignment faults are
    always avoided. There comes a point where the compiler writers need
    to stop being the data police for users that don't do their own
    performance analysis.


  14. RE: Itanium Port Question



    > -----Original Message-----
    > From: FrankS [mailto:sapienza@noesys.com]
    > Sent: Sunday, August 26, 2007 6:49 PM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Re: Itanium Port Question
    >
    > On Aug 26, 5:32 pm, Ron Johnson wrote:
    > > Wouldn't alignment faults be more of a problem in Macro than in,
    > > say, COBOL?

    >
    > This is a COBOL alignment fault ...
    >
    > 01 TOP-LEVEL.
    > 03 DATA-ITEM-1 PIC X(1).
    > 03 DATA-ITEM-2 PIC S9(9) COMP.
    >
    > Data-Item-2 is not on a natural boundary. This likely happens in lots
    > and lots of places in many COBOL programs. I'm sure there's a ton of
    > similar problems in programs I and many others have written over the
    > years.


    Are you saying the compile does not pad that out correctly? That should not
    be a problem in COBOL so far as I know.

    -Paul



  15. Re: Itanium Port Question

    VAXman- wrote:
    > In article , Ron Johnson writes:
    >
    >>
    >>On 08/26/07 15:20, VAXman- @SendSpamHere.ORG wrote:
    >>
    >>>In article , Evert van Dijken writes:
    >>>
    >>>>Depends on you programming language, Only macro needs to be rewritten.
    >>>
    >>>Huh? You need to steer clear of those Amsterdam coffee houses!
    >>>
    >>>Macro does NOT need to be rewritten to run on Itanium. It didn't need to
    >>>be rewritten to run on Alpha either. I recall this "mythconception" when
    >>>Alpha was first released. A large portion of OpenVMS (VAX/Alpha/Itanium)
    >>>is written in Macro and it has NOT rewritten. There may need to be some
    >>>modifications to the source but there is no need to rewrite the code just
    >>>to port it to Alpha or Itanium.

    >>
    >>Wouldn't alignment faults be more of a problem in Macro than in,
    >>say, COBOL?

    >
    >
    > An alignment fault is an alignment fault regardless of the language used
    > to source the program. I could write code in any language to experience
    > an alignment fault; I could write code in any language to not experience
    > an alignment fault. Rewriting a program sourced in language 'P' to one
    > source in language 'Q' is not necessarily going to remove issues of any
    > alignment fault.
    >


    Alignment faults are basically caused by how you arrange and declare
    your structures. This was a problem long before there was a VAX or VMS.
    We worried about it in IBM/360 Fortran IV. If you failed to put your
    REAL*8 variables first in your COMMON blocks, you could get alignment
    faults. Fixing them up slowed execution and the machines of yesteryear
    were slow to begin with. Doing anything to make them slower was anathema!!

    Those who were REALLY with it, used COMMON very sparingly! Making
    variables available to code that doesn't need them is seldom good practice!

    You usually have to work at it to get an alignment fault. Compilers
    know how to align things and usually do it very well UNTIL some dumb
    programmer makes it impossible by doing something to defeat the
    compilers alignment. If you create a struct with float, char, double
    there is no way the compiler can align it properly and still do what you
    asked for!

    Even Macro will align things properly until you create a structure
    that's impossible to align properly.


  16. Re: Itanium Port Question

    On Sun, 26 Aug 2007 17:50:13 -0700, Richard B. Gilbert
    wrote:

    > Alignment faults are basically caused by how you arrange and declare
    > your structures. This was a problem long before there was a VAX or
    > VMS. We worried about it in IBM/360 Fortran IV. If you failed to put
    > your REAL*8 variables first in your COMMON blocks, you could get
    > alignment faults. Fixing them up slowed execution and the machines of
    > yesteryear were slow to begin with. Doing anything to make them slower
    > was anathema!!
    >

    IIRC, PL/I on 360 didn't have that problem, afterall it was a byte
    addressable
    machine, as is the VAX.


    --
    PL/I for OpenVMS
    www.kednos.com

  17. Re: Itanium Port Question

    On Sun, 26 Aug 2007 16:48:58 -0700, FrankS wrote:

    > On Aug 26, 5:32 pm, Ron Johnson wrote:
    >> Wouldn't alignment faults be more of a problem in Macro than in,
    >> say, COBOL?

    >
    > This is a COBOL alignment fault ...
    >
    > 01 TOP-LEVEL.
    > 03 DATA-ITEM-1 PIC X(1).
    > 03 DATA-ITEM-2 PIC S9(9) COMP.
    >
    > Data-Item-2 is not on a natural boundary. This likely happens in lots
    > and lots of places in many COBOL programs. I'm sure there's a ton of
    > similar problems in programs I and many others have written over the
    > years.
    >

    Alignment was neglected in Alpha and Itanium, that was a mistake, and is
    the consequence of bad management, i.e. failing to understand the market.
    You will note that Power PC does not have this problem.



    --
    PL/I for OpenVMS
    www.kednos.com

  18. Re: Itanium Port Question

    On 08/26/07 19:26, FrankS wrote:
    > On Aug 26, 8:04 pm, "Richard Maher"
    > wrote:
    >> Forgot to mention that COBOL, like all other compilers, has the /alignment
    >> qualifiers if you're happy for it to pad 3 bytes between data_item_1 and
    >> data_item_3.

    >
    >>From a porting perspective, though, I would expect the default
    >> qualifiers (no alignment) would be used, particularly if data
    >> structures are being used to read/write from files that already
    >> exist. That is, if files already exist with records that were not
    >> padded then the /ALIGNMENT qualifier wouldn't come into play. (Yes,
    >> yes, I know you can use compiler directives to selectively align
    >> structures. That's getting way off stream from the question of
    >> whether or not alignment faults are more likely to occur in Macro .vs.
    >> COBOL.)

    >
    > I'm aware that the compiler will generate instructions to manipulate
    > bytes within an aligned quadword, but I didn't think it would generate
    > instructions to manipulate all data items so that alignment faults are
    > always avoided. There comes a point where the compiler writers need
    > to stop being the data police for users that don't do their own
    > performance analysis.


    Totally disagree. COBOL is not Pascal or C.

    In 1997, any COBOL compiler worth it's salt will place field values
    on appropriate alignment boundaries, and know how to intelligently
    MOVE field values.

    --
    Ron Johnson, Jr.
    Jefferson LA USA

    Give a man a fish, and he eats for a day.
    Hit him with a fish, and he goes away for good!

  19. Re: Itanium Port Question

    In article , "Tom Linden" writes:
    > On Sun, 26 Aug 2007 17:50:13 -0700, Richard B. Gilbert
    > wrote:
    >
    >> Alignment faults are basically caused by how you arrange and declare
    >> your structures. This was a problem long before there was a VAX or
    >> VMS. We worried about it in IBM/360 Fortran IV. If you failed to put
    >> your REAL*8 variables first in your COMMON blocks, you could get
    >> alignment faults. Fixing them up slowed execution and the machines of
    >> yesteryear were slow to begin with. Doing anything to make them slower
    >> was anathema!!
    >>

    > IIRC, PL/I on 360 didn't have that problem, afterall it was a byte
    > addressable
    > machine, as is the VAX.


    Even on VAX, good alignment produces better performance.

  20. Re: Itanium Port Question

    On Sun, 26 Aug 2007 19:32:35 -0700, Larry Kilgallen
    wrote:

    > In article , "Tom Linden"
    > writes:
    >> On Sun, 26 Aug 2007 17:50:13 -0700, Richard B. Gilbert
    >> wrote:
    >>
    >>> Alignment faults are basically caused by how you arrange and declare
    >>> your structures. This was a problem long before there was a VAX or
    >>> VMS. We worried about it in IBM/360 Fortran IV. If you failed to put
    >>> your REAL*8 variables first in your COMMON blocks, you could get
    >>> alignment faults. Fixing them up slowed execution and the machines of
    >>> yesteryear were slow to begin with. Doing anything to make them slower
    >>> was anathema!!
    >>>

    >> IIRC, PL/I on 360 didn't have that problem, afterall it was a byte
    >> addressable
    >> machine, as is the VAX.

    >
    > Even on VAX, good alignment produces better performance.

    True, but the degradation was nowhere near as bad as on current HW, it was,
    as it should be an extra tick.


    --
    PL/I for OpenVMS
    www.kednos.com

+ Reply to Thread
Page 1 of 4 1 2 3 ... LastLast