Longtime VMS system manager/programmer available - VMS

This is a discussion on Longtime VMS system manager/programmer available - VMS ; In article , JF Mezei writes: > Arne Vajh°j wrote: >> >> The question is whether it would make sense to port VMS to x86-64 >> in N years if Itanium is dropped. > > Because the installed base of ...

+ Reply to Thread
Page 3 of 8 FirstFirst 1 2 3 4 5 ... LastLast
Results 41 to 60 of 147

Thread: Longtime VMS system manager/programmer available

  1. Re: Longtime VMS system manager/programmer available

    In article <7aefd$47fed525$cef8887a$16914@teksavvy.com>,
    JF Mezei writes:
    > Arne Vajh°j wrote:
    >>
    >> The question is whether it would make sense to port VMS to x86-64
    >> in N years if Itanium is dropped.

    >
    > Because the installed base of VMS is shrinking, and no marketing is done
    > to try to grow it, the longer it takes for them to put IA64 out of its
    > misery, the smaller the remaining installed base will be for VMS. The
    > smaller it is, the easier it will be to decide to not port VMS beyond IA64.


    If (and that's a real big if) they decided to port VMS to x86-64, who is
    left to actually do it? Because of the lack of expertise in things like
    BLISS and MACRO how much would have to be re-written nthat dreaded "C"?
    If large portions were written in C by the current crop of programmers,
    how much of VMS's stability and integrity would be damaged or destroyed?

    >
    > It's that simple. HP is trying to give the appearance of taking good
    > care of VMS when in fact, it is treating it like an elderly person,
    > allowing it to stay stagnant in its old comfy chesterfield that is
    > getting narrower and narrower every year. By the time they pull the
    > plug, there will be very few left to mourn its passing and HP will have
    > succesfully gotten rid of a pesky product without killing itself in the
    > process (like DEC and Compaq).


    I do not think there would be a shortage of people mourning the demise of
    VMS. I am not what you would call one of the more rabid VMS fanatics, but
    I would certainly mourn it's passing just as I mourn it's disappearance
    from academia.

    bill


    --
    Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
    billg999@cs.scranton.edu | and a sheep voting on what's for dinner.
    University of Scranton |
    Scranton, Pennsylvania | #include

  2. Re: Longtime VMS system manager/programmer available

    billg999@cs.uofs.edu (Bill Gunshannon) writes:

    > If (and that's a real big if) they decided to port VMS to x86-64, who is
    > left to actually do it? Because of the lack of expertise in things like
    > BLISS and MACRO how much would have to be re-written nthat dreaded "C"?
    > If large portions were written in C by the current crop of programmers,
    > how much of VMS's stability and integrity would be damaged or destroyed?


    IF a port to a different architecture was done, it's almost a given that
    we would need to call in some hired guns to do things like port the BLISS
    compiler.

    It's not clear why this bizarre notion that only new, inexperienced
    VMS engineers program in C. Some of the more experienced members of
    VMS engineering are strong advocates of C. Anyone remember "Writing
    OpenVMS Alpha Device Drivers in C"? And that's a 12-year old book!

    Nonetheless, a complete rewrite of BLISS and MACRO into C would not
    likely be the best solution should the likely-never-to-happen port
    to a different architecture be undertaken.

    --

    Rob Brooks MSL -- Nashua brooks!cuebid.zko.hp.com

  3. Re: Longtime VMS system manager/programmer available

    Jan-Erik S÷derholm wrote:
    > JF Mezei wrote:
    >> But HP employees have made it quite clear that interactive use
    >> is no longer a priorioty for development.

    >
    > Just as for any other server-OS on the planet, even 3270
    > on MVS is replaced by other client tools, web based or
    > whatever. VMS is no different than any other server-OS
    > in this regard.


    True.

    VMS on the desktop is a monty python idea.

    But the fact that other OS'es not coming from the desktop
    world also has dropped the desktop presence does not mean
    that they are all equal regarding future.

    Arne



  4. Re: Longtime VMS system manager/programmer available

    On Fri, 11 Apr 2008 10:26:54 -0700, Rob Brooks
    wrote:

    > billg999@cs.uofs.edu (Bill Gunshannon) writes:
    >
    >> If (and that's a real big if) they decided to port VMS to x86-64, who is
    >> left to actually do it? Because of the lack of expertise in things like
    >> BLISS and MACRO how much would have to be re-written nthat dreaded "C"?
    >> If large portions were written in C by the current crop of programmers,
    >> how much of VMS's stability and integrity would be damaged or destroyed?

    >
    > IF a port to a different architecture was done, it's almost a given that
    > we would need to call in some hired guns to do things like port the BLISS
    > compiler.
    >
    > It's not clear why this bizarre notion that only new, inexperienced
    > VMS engineers program in C. Some of the more experienced members of
    > VMS engineering are strong advocates of C. Anyone remember "Writing
    > OpenVMS Alpha Device Drivers in C"? And that's a 12-year old book!
    >
    > Nonetheless, a complete rewrite of BLISS and MACRO into C would not
    > likely be the best solution should the likely-never-to-happen port
    > to a different architecture be undertaken.
    >

    VMS engineering has had brain-dead managment since the early 80's allowing
    the engineers to experiment with all sorts of crap, including C.


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

  5. Re: Longtime VMS system manager/programmer available

    Tom Linden wrote:
    > On Fri, 11 Apr 2008 10:26:54 -0700, Rob Brooks
    > wrote:
    >
    >> billg999@cs.uofs.edu (Bill Gunshannon) writes:
    >>
    >>> If (and that's a real big if) they decided to port VMS to x86-64, who is
    >>> left to actually do it? Because of the lack of expertise in things like
    >>> BLISS and MACRO how much would have to be re-written nthat dreaded "C"?
    >>> If large portions were written in C by the current crop of programmers,
    >>> how much of VMS's stability and integrity would be damaged or destroyed?

    >>
    >> IF a port to a different architecture was done, it's almost a given that
    >> we would need to call in some hired guns to do things like port the BLISS
    >> compiler.
    >>
    >> It's not clear why this bizarre notion that only new, inexperienced
    >> VMS engineers program in C. Some of the more experienced members of
    >> VMS engineering are strong advocates of C. Anyone remember "Writing
    >> OpenVMS Alpha Device Drivers in C"? And that's a 12-year old book!
    >>
    >> Nonetheless, a complete rewrite of BLISS and MACRO into C would not
    >> likely be the best solution should the likely-never-to-happen port
    >> to a different architecture be undertaken.
    >>

    > VMS engineering has had brain-dead managment since the early 80's allowing
    > the engineers to experiment with all sorts of crap, including C.
    >
    >


    It's been said before but. . . THE LANGUAGE DOES NOT MAKE THE PROGRAM.
    You don't have to write bad code in C, it's just easier to do so than
    it really should be. You could write poor code in BLISS, you'd just
    have to work a little harder to make it bad. You can write a buggy
    program in ADA; you just have to work harder. . . .

    If nobody ever tried anything new, we'd still be chipping flint and
    bashing JF with stone axes instead of words.

  6. Re: Longtime VMS system manager/programmer available

    Richard B. Gilbert wrote:

    > If nobody ever tried anything new, we'd still be chipping flint and
    > bashing JF with stone axes instead of words.


    The newer stuff doesn't necessarily work better. The fact that I am
    still here tends to show that words may be less effective than stone
    axes :-)

    I just installed some "BitTorrent" software, apparently written with a
    mixture of GCC and python. The thing consumes 100% of the cpu time given
    to it. All it does is transfer data. A properly witten program in C on
    an allmighty Microvax II would leave some spare CPU cycles.


    Kiddies are now so far detached from the machine through layers of
    software and middleware that they no longer have control over how their
    software actually runs. So all these newfangled tools end up creating
    software that is overlybloated, slower and not really using the CPU and
    OS intelligently.

  7. Re: Longtime VMS system manager/programmer available

    Tom Linden wrote:

    > On Fri, 11 Apr 2008 10:26:54 -0700, Rob Brooks
    > wrote:
    >
    >> billg999@cs.uofs.edu (Bill Gunshannon) writes:
    >>
    >>> If (and that's a real big if) they decided to port VMS to x86-64, who is
    >>> left to actually do it? Because of the lack of expertise in things like
    >>> BLISS and MACRO how much would have to be re-written nthat dreaded "C"?
    >>> If large portions were written in C by the current crop of programmers,
    >>> how much of VMS's stability and integrity would be damaged or destroyed?

    >>
    >>
    >> IF a port to a different architecture was done, it's almost a given that
    >> we would need to call in some hired guns to do things like port the BLISS
    >> compiler.
    >>
    >> It's not clear why this bizarre notion that only new, inexperienced
    >> VMS engineers program in C. Some of the more experienced members of
    >> VMS engineering are strong advocates of C. Anyone remember "Writing
    >> OpenVMS Alpha Device Drivers in C"? And that's a 12-year old book!
    >>
    >> Nonetheless, a complete rewrite of BLISS and MACRO into C would not
    >> likely be the best solution should the likely-never-to-happen port
    >> to a different architecture be undertaken.
    >>

    > VMS engineering has had brain-dead managment since the early 80's allowing
    > the engineers to experiment with all sorts of crap, including C.
    >
    >


    Oh, come on now; twice.

    1.I won't argue about the quality of the senior managers who were responsible
    for VMS (i.e., Curly & Carly), but the lower ranks of VMS management
    included some rather sharp folks.

    2.C, in its place, is pretty good. In particular, when C is used for stuff
    that would otherwise have been written in assembly language, C is IMHO
    just dandy. Have you had good luck writing device drivers in PL/I?
    --
    Cheers, Bob

  8. Re: Longtime VMS system manager/programmer available

    On Fri, 11 Apr 2008 19:05:37 -0700, Richard B. Gilbert
    wrote:

    > It's been said before but. . . THE LANGUAGE DOES NOT MAKE THE PROGRAM.
    > You don't have to write bad code in C, it's just easier to do so than it
    > really should be. You could write poor code in BLISS, you'd just have
    > to work a little harder to make it bad. You can write a buggy program
    > in ADA; you just have to work harder. . . .


    You don't get it, why write code using an inferior tool, you have to expend
    more effort and the code will be more difficult to maintain? It is about
    programming standards.

    > If nobody ever tried anything new, we'd still be chipping flint and
    > bashing JF with stone axes instead of words.


    I would hardly characterize C or Bliss as something 'new' They were
    retrograde when devised.


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

  9. Re: Longtime VMS system manager/programmer available

    On Sat, 12 Apr 2008 05:46:30 -0700, Bob Willard
    wrote:

    > Tom Linden wrote:
    >
    >> On Fri, 11 Apr 2008 10:26:54 -0700, Rob Brooks
    >> wrote:
    >>
    >>> billg999@cs.uofs.edu (Bill Gunshannon) writes:
    >>>
    >>>> If (and that's a real big if) they decided to port VMS to x86-64, who
    >>>> is
    >>>> left to actually do it? Because of the lack of expertise in things
    >>>> like
    >>>> BLISS and MACRO how much would have to be re-written nthat dreaded
    >>>> "C"?
    >>>> If large portions were written in C by the current crop of
    >>>> programmers,
    >>>> how much of VMS's stability and integrity would be damaged or
    >>>> destroyed?
    >>>
    >>>
    >>> IF a port to a different architecture was done, it's almost a given
    >>> that
    >>> we would need to call in some hired guns to do things like port the
    >>> BLISS
    >>> compiler.
    >>>
    >>> It's not clear why this bizarre notion that only new, inexperienced
    >>> VMS engineers program in C. Some of the more experienced members of
    >>> VMS engineering are strong advocates of C. Anyone remember "Writing
    >>> OpenVMS Alpha Device Drivers in C"? And that's a 12-year old book!
    >>>
    >>> Nonetheless, a complete rewrite of BLISS and MACRO into C would not
    >>> likely be the best solution should the likely-never-to-happen port
    >>> to a different architecture be undertaken.
    >>>

    >> VMS engineering has had brain-dead managment since the early 80's
    >> allowing
    >> the engineers to experiment with all sorts of crap, including C.
    >>

    >
    > Oh, come on now; twice.
    >
    > 1.I won't argue about the quality of the senior managers who were
    > responsible
    > for VMS (i.e., Curly & Carly), but the lower ranks of VMS management
    > included some rather sharp folks.


    Sharp folks can build the wrong thing without seasoned direction, moreover
    part of software management is setting and maintaining standards, like SDL.

    >
    > 2.C, in its place, is pretty good. In particular, when C is used for
    > stuff
    > that would otherwise have been written in assembly language, C is IMHO
    > just dandy. Have you had good luck writing device drivers in PL/I?


    Maybe I am more familiar with C than you are with PL/I?
    I haven't had a need to do so, but I easily could, and have done so years
    ago
    for unix, including replacing some portions of the kernel. The tape driver
    on Primos was written in Fortran, BTW.



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

  10. Re: Longtime VMS system manager/programmer available

    Tom Linden wrote:
    > On Fri, 11 Apr 2008 19:05:37 -0700, Richard B. Gilbert
    > wrote:
    >
    >> It's been said before but. . . THE LANGUAGE DOES NOT MAKE THE
    >> PROGRAM. You don't have to write bad code in C, it's just easier to
    >> do so than it really should be. You could write poor code in BLISS,
    >> you'd just have to work a little harder to make it bad. You can write
    >> a buggy program in ADA; you just have to work harder. . . .

    >
    > You don't get it, why write code using an inferior tool, you have to expend
    > more effort and the code will be more difficult to maintain? It is about
    > programming standards.
    >


    Has everyone finally managed to agree on just what the "programming
    standards" should be? I've always tried to write code that could be
    understood and maintained by those who came after me. I don't know that
    I've succeeded but I've tried. . . . In the process, I've used at least
    seven different assembler languages, Fortran II, Fortran IV, Fortran 77,
    PL/1, C, DCL, sh, ksh, awk, and, perhaps, a few that I've forgotten.

    Generally, you have to use the tools that are available, whatever they
    might be. It has been a while since I looked at pricing but a Fortran
    compiler license for the VAX 11/750 used to cost $5,000 US. The price
    was approximately the same for ANY of the available compilers. This
    meant that you didn't always have the appropriate tool for the job; you
    had to "make do" with whatever was available.

  11. Re: Longtime VMS system manager/programmer available

    On Apr 11, 10:05 pm, "Richard B. Gilbert"
    wrote:
    > Tom Linden wrote:
    > > On Fri, 11 Apr 2008 10:26:54 -0700, Rob Brooks
    > > wrote:

    >
    > >> billg...@cs.uofs.edu (Bill Gunshannon) writes:

    >
    > >>> If (and that's a real big if) they decided to port VMS to x86-64, who is
    > >>> left to actually do it? Because of the lack of expertise in things like
    > >>> BLISS and MACRO how much would have to be re-written nthat dreaded "C"?
    > >>> If large portions were written in C by the current crop of programmers,
    > >>> how much of VMS's stability and integrity would be damaged or destroyed?

    >
    > >> IF a port to a different architecture was done, it's almost a given that
    > >> we would need to call in some hired guns to do things like port the BLISS
    > >> compiler.

    >
    > >> It's not clear why this bizarre notion that only new, inexperienced
    > >> VMS engineers program in C. Some of the more experienced members of
    > >> VMS engineering are strong advocates of C. Anyone remember "Writing
    > >> OpenVMS Alpha Device Drivers in C"? And that's a 12-year old book!

    >
    > >> Nonetheless, a complete rewrite of BLISS and MACRO into C would not
    > >> likely be the best solution should the likely-never-to-happen port
    > >> to a different architecture be undertaken.

    >
    > > VMS engineering has had brain-dead managment since the early 80's allowing
    > > the engineers to experiment with all sorts of crap, including C.

    >
    > It's been said before but. . . THE LANGUAGE DOES NOT MAKE THE PROGRAM.
    > You don't have to write bad code in C, it's just easier to do so than
    > it really should be. You could write poor code in BLISS, you'd just
    > have to work a little harder to make it bad. You can write a buggy
    > program in ADA; you just have to work harder. . . .
    >
    > If nobody ever tried anything new, we'd still be chipping flint and
    > bashing JF with stone axes instead of words.



    By the same token (whatever that means!), if you don't throw out those
    new things you tried that failed, you end up with bad stuff. (In
    physics we threw out phlogiston, n-rays, and the fifth force, e.g.,
    because they turned out to be bogus. [I was right about the fifth
    force!] Scientists threw out cold fusion because it was bogus. And now
    there's software named after it! Way to go!) Maybe that's why we have
    the fastest hardware that's ever been made, supposedly doubling in
    speed every 18 months, yet still everything is slow. We have all these
    fancy programming tools like color-coded code editors (or whatever the
    hell they're called), visual this and visual that, and still end up
    with so much bad software. Yeah, marketing pressures are in part to
    blame, but so is ignorance. Web-page design is often awful. Why do
    they put important links in microscopic font ABOVE the title of the
    page? Who looks above the title anywhere else? Typography is not done
    well. Long lines are harder to read as the LaTeX manual tells us about
    one of the most elementary mistakes people make when doing their own
    typography. In general, lines should be no longer than 75 characters
    each.

    And then there's Microsoft software. Does anyone think PL/I could save
    them? Well, it might help a little, I'm not really sure.

    Of course you can screw things up even with the best tools.

    I've noticed at least some developers seem to think that the speed of
    hardware will somehow make up for poor algorithms and such. Some stuff
    I've seen generates thousands of error messages and these are sent to
    pages just because of a single thing that had gone wrong. I once
    received 600 page alerts because a single disk experienced 600 errors!
    And there was no way I could do a mass delete!
    AUUUUUGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!

    Of course it's still better to use better tools, whatever
    is best suited to the job, etc.

    All right -- enough ranting.

    AEF

  12. Re: Longtime VMS system manager/programmer available

    AEF wrote:
    > On Apr 11, 10:05 pm, "Richard B. Gilbert"
    > wrote:
    >> Tom Linden wrote:
    >>> On Fri, 11 Apr 2008 10:26:54 -0700, Rob Brooks
    >>> wrote:
    >>>> billg...@cs.uofs.edu (Bill Gunshannon) writes:
    >>>>> If (and that's a real big if) they decided to port VMS to x86-64, who is
    >>>>> left to actually do it? Because of the lack of expertise in things like
    >>>>> BLISS and MACRO how much would have to be re-written nthat dreaded "C"?
    >>>>> If large portions were written in C by the current crop of programmers,
    >>>>> how much of VMS's stability and integrity would be damaged or destroyed?
    >>>> IF a port to a different architecture was done, it's almost a given that
    >>>> we would need to call in some hired guns to do things like port the BLISS
    >>>> compiler.
    >>>> It's not clear why this bizarre notion that only new, inexperienced
    >>>> VMS engineers program in C. Some of the more experienced members of
    >>>> VMS engineering are strong advocates of C. Anyone remember "Writing
    >>>> OpenVMS Alpha Device Drivers in C"? And that's a 12-year old book!
    >>>> Nonetheless, a complete rewrite of BLISS and MACRO into C would not
    >>>> likely be the best solution should the likely-never-to-happen port
    >>>> to a different architecture be undertaken.
    >>> VMS engineering has had brain-dead managment since the early 80's allowing
    >>> the engineers to experiment with all sorts of crap, including C.

    >> It's been said before but. . . THE LANGUAGE DOES NOT MAKE THE PROGRAM.
    >> You don't have to write bad code in C, it's just easier to do so than
    >> it really should be. You could write poor code in BLISS, you'd just
    >> have to work a little harder to make it bad. You can write a buggy
    >> program in ADA; you just have to work harder. . . .
    >>
    >> If nobody ever tried anything new, we'd still be chipping flint and
    >> bashing JF with stone axes instead of words.

    >
    >
    > By the same token (whatever that means!), if you don't throw out those
    > new things you tried that failed, you end up with bad stuff. (In
    > physics we threw out phlogiston, n-rays, and the fifth force, e.g.,
    > because they turned out to be bogus. [I was right about the fifth
    > force!] Scientists threw out cold fusion because it was bogus. And now
    > there's software named after it! Way to go!) Maybe that's why we have
    > the fastest hardware that's ever been made, supposedly doubling in
    > speed every 18 months, yet still everything is slow.


    If you build a faster computer, someone will build slower software to
    run on it. I've spent a substantial portion of my life waiting to get
    my prompt back!!

  13. Re: Longtime VMS system manager/programmer available

    On Sat, 12 Apr 2008 07:27:05 -0700, AEF wrote:

    > And then there's Microsoft software. Does anyone think PL/I could save
    > them? Well, it might help a little, I'm not really sure.


    Funny, you should bring that up, because I asked Cutler about 10 years ago
    if they had any interest in PL/I on NT, No.

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

  14. Re: Longtime VMS system manager/programmer available

    On Sat, 12 Apr 2008 07:20:54 -0700, Richard B. Gilbert
    wrote:

    > Tom Linden wrote:
    >> On Fri, 11 Apr 2008 19:05:37 -0700, Richard B. Gilbert
    >> wrote:
    >>
    >>> It's been said before but. . . THE LANGUAGE DOES NOT MAKE THE
    >>> PROGRAM. You don't have to write bad code in C, it's just easier to
    >>> do so than it really should be. You could write poor code in BLISS,
    >>> you'd just have to work a little harder to make it bad. You can write
    >>> a buggy program in ADA; you just have to work harder. . . .

    >> You don't get it, why write code using an inferior tool, you have to
    >> expend
    >> more effort and the code will be more difficult to maintain? It is
    >> about
    >> programming standards.
    >>

    >
    > Has everyone finally managed to agree on just what the "programming
    > standards" should be? I've always tried to write code that could be
    > understood and maintained by those who came after me. I don't know that
    > I've succeeded but I've tried. . . . In the process, I've used at least
    > seven different assembler languages, Fortran II, Fortran IV, Fortran 77,
    > PL/1, C, DCL, sh, ksh, awk, and, perhaps, a few that I've forgotten.


    I've got you beat, or maybe I remember the (names of) ones you have
    forgotten:-)

    >
    > Generally, you have to use the tools that are available, whatever they
    > might be. It has been a while since I looked at pricing but a Fortran
    > compiler license for the VAX 11/750 used to cost $5,000 US. The price
    > was approximately the same for ANY of the available compilers. This
    > meant that you didn't always have the appropriate tool for the job; you
    > had to "make do" with whatever was available.


    Sorry to belabor the point, but just because a compiler is expensive
    doesn't
    imply that using an inferior tool is the best choice, in fact, I would
    argue
    to the contrary.

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

  15. RE: Longtime VMS system manager/programmer available


    > -----Original Message-----
    > From: JF Mezei [mailto:jfmezei.spamnot@vaxination.ca]
    > Sent: April 10, 2008 6:44 PM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Re: Longtime VMS system manager/programmer available
    >
    > Jan-Erik S÷derholm wrote:
    >
    > > Just as for any other server-OS on the planet, even 3270
    > > on MVS is replaced by other client tools, web based or
    > > whatever. VMS is no different than any other server-OS
    > > in this regard.

    >
    >
    > OS that are relegated to server only stuff don't have much of a future.
    > Even Linux knows that to gain market traction, it needs to have a
    > modern
    > user interface.
    >


    JF -

    If you are talking about managing servers with GUI's, when was the last
    time you looked at any of the modern GUI tools to manage OpenVMS?

    - HP OpenVMS Systems Homepage (HP SMH)
    http://www.openvms.compaq.com/openvm...smh/index.html

    - OpenVMS System Management summary page:
    http://www.openvms.compaq.com/openvm...anagement.html

    - Availability Manager (OpenVMS or Windows host)
    http://www.openvms.compaq.com/openvm...lman/what.html

    - OpenVMS Management Station (Windows based UAF, disk, printers)
    http://www.openvms.compaq.com/openvm...gus/index.html
    (scroll down for sample screen shots)

    - WBEM based enhancements
    http://www.openvms.compaq.com/openvm...bem_index.html

    - Distributed NetBeans (development tools & management)
    http://h71000.www7.hp.com/openvms/pr...ns/distnb.html

    And btw, Microsoft is under a lot of pressure to come up with a better
    command line infrastructure right now as the feedback they received is
    that GUI's do not cut it for production environments e.g. large batch
    and reporting type environments.


    Regards

    Kerry Main
    Senior Consultant
    HP Services Canada
    Voice: 613-254-8911
    Fax: 613-591-4477
    kerryDOTmainAThpDOTcom
    (remove the DOT's and AT)

    OpenVMS - the secure, multi-site OS that just works.





  16. Re: Longtime VMS system manager/programmer available

    Tom Linden wrote:
    > On Sat, 12 Apr 2008 07:20:54 -0700, Richard B. Gilbert
    > wrote:
    >
    >> Tom Linden wrote:
    >>> On Fri, 11 Apr 2008 19:05:37 -0700, Richard B. Gilbert
    >>> wrote:
    >>>
    >>>> It's been said before but. . . THE LANGUAGE DOES NOT MAKE THE
    >>>> PROGRAM. You don't have to write bad code in C, it's just easier to
    >>>> do so than it really should be. You could write poor code in BLISS,
    >>>> you'd just have to work a little harder to make it bad. You can
    >>>> write a buggy program in ADA; you just have to work harder. . . .
    >>> You don't get it, why write code using an inferior tool, you have to
    >>> expend
    >>> more effort and the code will be more difficult to maintain? It is
    >>> about
    >>> programming standards.
    >>>

    >>
    >> Has everyone finally managed to agree on just what the "programming
    >> standards" should be? I've always tried to write code that could be
    >> understood and maintained by those who came after me. I don't know
    >> that I've succeeded but I've tried. . . . In the process, I've used
    >> at least seven different assembler languages, Fortran II, Fortran IV,
    >> Fortran 77, PL/1, C, DCL, sh, ksh, awk, and, perhaps, a few that I've
    >> forgotten.

    >
    > I've got you beat, or maybe I remember the (names of) ones you have
    > forgotten:-)
    >
    >>
    >> Generally, you have to use the tools that are available, whatever they
    >> might be. It has been a while since I looked at pricing but a Fortran
    >> compiler license for the VAX 11/750 used to cost $5,000 US. The price
    >> was approximately the same for ANY of the available compilers. This
    >> meant that you didn't always have the appropriate tool for the job;
    >> you had to "make do" with whatever was available.

    >
    > Sorry to belabor the point, but just because a compiler is expensive
    > doesn't
    > imply that using an inferior tool is the best choice, in fact, I would
    > argue
    > to the contrary.
    >


    If you don't have the $5000 for the tool of your choice, you must use
    whatever is available! Or, perhaps, look for another job.

  17. Re: Longtime VMS system manager/programmer available

    "Tom Linden" wrote in
    newsp.t9h9wofxhv4qyg@murphus.hsd1.ca.comcast.net:

    > Sorry to belabor the point, but just because a compiler is expensive
    > doesn't imply that using an inferior tool is the best choice, in fact,
    > I would argue to the contrary.


    I'm not sure you've seen his point going by at all. If you have a compiler
    for X on site already and the best tool for today's job is Y but costs $Z
    then the odds are really good that X will be used.

    These days the question is more likely to boil down to "is Y available for
    free and does it produce reasonable machine code", but the principle is the
    same.

    This is even assuming that anyone else agrees with you that Y is better
    than X for the job in hand, of course.

    Antonio



  18. Re: Longtime VMS system manager/programmer available

    JF Mezei wrote:
    > Richard B. Gilbert wrote:
    >> If nobody ever tried anything new, we'd still be chipping flint and
    >> bashing JF with stone axes instead of words.

    >
    > The newer stuff doesn't necessarily work better. The fact that I am
    > still here tends to show that words may be less effective than stone
    > axes :-)
    >
    > I just installed some "BitTorrent" software, apparently written with a
    > mixture of GCC and python. The thing consumes 100% of the cpu time given
    > to it. All it does is transfer data. A properly witten program in C on
    > an allmighty Microvax II would leave some spare CPU cycles.


    A proper written Python script should also be able to do that
    (unless you have an absurd fast internet connection).

    > Kiddies are now so far detached from the machine through layers of
    > software and middleware that they no longer have control over how their
    > software actually runs. So all these newfangled tools end up creating
    > software that is overlybloated, slower and not really using the CPU and
    > OS intelligently.


    I don't think I would blame the software and the middleware, but you
    are correct about so many not understanding what is going on
    inside the software.

    The result can be developers that spend most of the time optimizing
    a micro seconds of a loop in their code, but for each iteration get
    a CLOB from the database and parse it into an XML document.

    Arne

  19. Re: Longtime VMS system manager/programmer available

    Richard B. Gilbert wrote:
    > Generally, you have to use the tools that are available, whatever they
    > might be. It has been a while since I looked at pricing but a Fortran
    > compiler license for the VAX 11/750 used to cost $5,000 US. The price
    > was approximately the same for ANY of the available compilers. This
    > meant that you didn't always have the appropriate tool for the job; you
    > had to "make do" with whatever was available.


    Price of tools are often an important factor in the decision
    about tools.

    The good thing (for developers in general not for those making
    tools) is that the new standard price for development tools
    are zero.

    Arne

  20. Re: Longtime VMS system manager/programmer available

    Main, Kerry wrote:
    > From: JF Mezei [mailto:jfmezei.spamnot@vaxination.ca]
    >> Jan-Erik S÷derholm wrote:
    >>> Just as for any other server-OS on the planet, even 3270
    >>> on MVS is replaced by other client tools, web based or
    >>> whatever. VMS is no different than any other server-OS
    >>> in this regard.

    >>
    >> OS that are relegated to server only stuff don't have much of a future.
    >> Even Linux knows that to gain market traction, it needs to have a
    >> modern
    >> user interface.


    > If you are talking about managing servers with GUI's, when was the last
    > time you looked at any of the modern GUI tools to manage OpenVMS?


    No. I think he is dreaming about OpenVMS on the desktop
    for word processing etc..

    The development for server OS's seems to be going in the opposite
    direction - less GUI.

    As an example Windows 2008 Server Core Installation.

    Arne

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