Longtime VMS system manager/programmer available - VMS

This is a discussion on Longtime VMS system manager/programmer available - VMS ; Bob Willard schrieb: > KO had been convinced by the Jack Ss, who had been convinced by Grant S, > of the importance of using proprietary stuff instead of open stuff to > protect the revenue stream for DEC's storage ...

+ Reply to Thread
Page 6 of 8 FirstFirst ... 4 5 6 7 8 LastLast
Results 101 to 120 of 147

Thread: Longtime VMS system manager/programmer available

  1. Re: Longtime VMS system manager/programmer available

    Bob Willard schrieb:


    > KO had been convinced by the Jack Ss, who had been convinced by Grant S,
    > of the importance of using proprietary stuff instead of open stuff to
    > protect the revenue stream for DEC's storage group.


    The same Ss, who equipped some VAXstation models with male SCSI
    connectors, so one has to buy those special SCSI cables with a female
    connector on one end ?
    Moreover, since those pins easily get bent/broken, one essentially
    has to replace/repair the whole SCSI card (as opposed to just ditching
    a broken cable), creating more revenue for DECs repair division.

    > True, in the short
    > term, but counterproductive in the long term; those expensive storage
    > products became another financial reason for customers to buy non-DEC
    > systems. KO believed that customers were willing to pay (much) higher
    > prices to get systems of higher quality; as the record shows, few were.


    Well, some/many people would probably pay 20 or 30 percent more
    if they get higher quality, but not factors two or three.


  2. Re: Longtime VMS system manager/programmer available

    In article <48016061$0$90269$14726298@news.sunsite.dk>, =?ISO-8859-15?Q?Arne_Vajh=F8j?= writes:
    >
    > Is writing a device driver in another HLL than C supported on OpenVMS ?


    Yes, and no. On VAXen only Macro-32 is supported. On Alpha
    Macro-32, C, and BLISS are "supported", but C is supported much
    better than the other two and BLISS barely at all.

    I think IA-64 is in bed with Alpha on this.


  3. Re: Longtime VMS system manager/programmer available

    In article , "Tom Linden" writes:
    >
    > Firstly I would not characterize C as a HLL, secondly don't know what you
    > mean by supported. If I write a device driver that is my concern not HP's


    Supported: the vendor says "yes, that will work", it works, there
    are appropriate interface definitions provided, there are working
    examples (BLISS is a little deficient on this), and if you ask the
    vendor for help their first reaction won't be "we don't support
    that".

    There is an unsupported interface provided by some non-DEC folks for
    writing VMS device drivers in BLISS on VAX. But since those
    outsiders provided the interface definitions back in about the VMS
    5.x timeframe you may find you have to update them yourself in order
    to get it to work. On the other hand, when I had problems in a
    device driver written in Macro-32 for a VAX I was able to send a
    crash dump to customer support and they had no trouble helping me
    track down the hardware problem that was causing it (even though the
    hardware was under 3rd party maintenance).

    If you want to write a VMS device driver in PL/I, you go right ahead.
    Happy fat Al.


  4. Re: Longtime VMS system manager/programmer available

    In article , Bob Willard writes:

    > No wonder. DSSI was SCSI with a couple of very minor changes; those
    > changes were made specifically to ensure that cheap SCSI HDs could not
    > be used in place of expensive DSSI HDs.


    Minor changes? MSCP is a sufficiently complexs layer that non of the
    free UNIX-ish OS have been able to cope with it. Even DEC put
    a VAX chip into its MIPS based DECSystem 5000 series to get them to
    talk to DSSI disks.


  5. Re: Longtime VMS system manager/programmer available

    In article <1208152792_525@isp.n>, Jeff Campbell
    wrote:

    > When's the last time you SET HOST/DUP MY-RANDOM-SCSI-DRIVE on a PC? 8-)
    >
    > That alone could have been the difference. The ability to run internal
    > formatting, bad block scans, statistics, etc. was far ahead of contemporaneous
    > SCSI development. Coupled with MSCP's bad block management it could have
    > taken the industry by storm. But, no marketing strikes again.


    I came across an example in the late 1980s of a site who had bought
    their peripherals from an OEM rather than DEC. Apart from the appalling
    terminals, the disks/disk controllers didn't have the automatic bad
    block replacement inherent in DSA (Digital Storage Architecture), with
    the result that allocating a complete disk to a database (ADABAS IIRC)
    wasn't possible except in chunks to work around bad blocks.

    --
    Paul Sture

    Sue's OpenVMS bookmarks:
    http://eisner.encompasserve.org/~stu...bookmarks.html

  6. Re: Longtime VMS system manager/programmer available


    "Richard B. Gilbert" wrote in message
    news:ZOydneSVrrckRZ_VnZ2dnUVZ_qLinZ2d@comcast.com. ..
    > JF Mezei wrote:
    > > Richard B. Gilbert wrote:
    > >
    > >> Little? How about none? It looked as if every machine was designed
    > >> from scratch. If you can find a VERY OLD DEC catalog, take a look at
    > >> the RZ26 disk drive. There were twenty or thirty different variants.
    > >> The difference? The mounting hardware!!

    > >
    > > It would have taken a simple edict from Ken Olsen to get all the
    > > different kingdoms within DEC to start using standard parts instead of
    > > engineering thir own and to challenge Digital to make a vax workstation
    > > that would compete against Macs. (aka: same ballpark as PCs with with a
    > > small markup due to better quality.

    >
    > Huh?? DEC couldn't even build a PC at a competitive price. Remember
    > the Rainbow? It sold for $5000 with a SMALL hard disk, 5 or 10MB.
    > >
    > > And just imagine if DEC had sold its DSSI drives and controllers at
    > > commodity prices, it might have been the one standard that was used
    > > insted of IDE or scsi.

    >
    > I've used both SCSI and DSSI drives. DSSI did not offer anything that
    > was worth the extra cost. There was, AFAIK no second source for DSSI
    > drives. They had no hope of becoming a standard!
    >
    > DEC was sitting on a treasure of engineers and products, but its
    > business practices prevented almost all from being a commercial success.
    >
    > DEC's
    >


    Others have already pointed out some of the "value add" in DSSI vs SCSI,
    there is more to add (such as disks with a built in choice of "high
    performance low capacity" vs "lower performance higher capacity", and proper
    Write Protect and Run/Stop buttons, and probably more too). Plus proper dual
    host capability, something which SCSI-only clusters often found troublesome.

    There were PCs in DEC after the Rainbow, and I don't mean the European
    DECivetti stuff.

    Where were you when the AlphaStation 400 came out? Take out the Alpha proces
    sor card and slot in an x86 card. I don't know or care what the PC
    equivalent was called, but it existed, and there was even an offical upgrade
    path from x86 box to Alpha box. It was so PC-compatible that it had parity
    not ECC memory, and if you filled one up you'd have so many random errors
    that you'd start to notice the crashes. In a Windows environment, you'd
    blame the OS (in the absence of any meaningful error log and crash dump
    tools) and move on, but in a Tru64/VMS environment you (a) knew
    instinctively the OS wasn't the problem (b) the built in tools told you
    exactly why the system crashed.

    The Personal Workstations went even further down the common-technology
    route. An industry standard NLx form factor motherboard/daughtercard
    arrangement, with industry standard designs and components (apart from the
    ridiculous "frost white" plastics and keyboards and monitors... grrr). One
    variant of the box with the Alpha processor card was capable of running NT,
    and if you were willing to pay extra (oops) you could also get one that
    would run UNIX or VMS. At a component level, other than the Alpha and one or
    two support chips it was all PC-class stuff, almost identical with the x86
    equivalent box. Except for price, and serious-OS functionality, obviously.

    Look inside a DS10, and apart from the odd shape, what makes it electrically
    any different from a PC?

    Alpha systems could be and were *built* at relatively competitive prices.
    DEC HQ either didn't want volume or never worked out how to get volume via
    sensible pricing of hardware and software.

    "DEC business practices prevented almost all from being a commercial
    success"

    Probably. The "VMS only runs on expensive hardware" ideas were always a bit
    dodgy, from the days of the VAXserver/RTVAX and on. Later on, the "no
    Alpha/VMS/Tru64 in volume markets" was probably something to do with Palmer
    not wanting to upset either Intel or MS (or Oracle or...) at the time he was
    at the top. Before that, well, who could really have thought that Windows
    was going anywhere? Windows 3.1 came out around the same time as the 21064;
    somewhere I still have a copy of an issue of Byte magazine which has them
    both on the cover. And who would have thought the multi-platform days of
    Windows NT on Alpha and MIPS and PowerPC would be over almost before they
    started, not because the technology wasn't up to it, but because Bill said
    so.

    Meanwhile, UNIX (and friends) is still just about to take over the world,
    just like it has been since the mid 1980s. Maybe. Hindsight's a handy kind
    of thing.

    Regards
    John



  7. Re: Longtime VMS system manager/programmer available

    In article <48022dd7$0$90268$14726298@news.sunsite.dk>,
    Arne Vajh°j writes:
    > JF Mezei wrote:
    >> Michael Kraemer wrote:
    >>> VAXstations OTOH were ridiculously overprized
    >>> compared to their RISC counterparts.

    >>
    >> Replace the word "ridiculously" with "artificially".
    >>
    >> DEC suffered from the "must not allow our high margin customers from
    >> starting to buy more powerful and cheaper systems from us". They never
    >> thought about attracting more new customers to compensate for the high
    >> marghin customers buying cheaper systems from DEC.
    >>
    >> So those high margin customers ended up buying smaller, more powerful
    >> and cheaper systems from companies DEC refused to admit competed against
    >> itself. (like compaq/microsoft)
    >>
    >> DEC had had many opportunities from the early 1980s to the late 1980s to
    >> really make it big. They missed them. Miseed the boat and were left behind.

    >
    > No doubt that they had high margins.
    >
    > But my guess is that the production costs were also higher.
    >
    > VAX'es was build to last for decades and did (still do in some
    > cases).
    >
    > PC's are a use and throw away commodity. Nobody really cares
    > if the parts start to fail after 4 years of 5x8 usage.
    >


    That may be true today, but it certainly wasn't then. I just recently
    (within the last 6 months) got rid of a number of original IBM PC's
    that while too slow for any reasonable use were still perfectly usable.
    I still have PS/2's that work perfectly well, albeit a little slow.
    I, like many others, have always believed that the VAX could have been
    made and marketed competitive with PC hardware. It was a decision by
    DEC to not try to compete with the PC world then, just as it is iby HP
    now.

    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

  8. Re: Longtime VMS system manager/programmer available

    In article ,
    brooks@cuebid.zko.hp.nospam (Rob Brooks) writes:
    > 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.


    Where would you find them and why would you think that management would
    agree to pay the obviously high pricetag they could and probably would
    demand?

    >
    > 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!



    I didn't say only inexperienced programmers use C, but most people here
    repeatedly have stated that no good code can be written in C. (I don't
    agree, but I am sure that puts me in the minority here.)

    >
    > 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.


    So you agree that VMS is on it's last architecture? And what are your
    long term prognostications regarding the Itanic? :-)

    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

  9. Re: Longtime VMS system manager/programmer available

    In article ,
    "Tom Linden" writes:
    > 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.


    And in regards my last posting int his thread, I rest my case!! :-)

    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

  10. Re: Longtime VMS system manager/programmer available

    In article ,
    Michael Kraemer writes:
    > Arne Vajh°j schrieb:
    >
    >> And some are done for free by developers having a day job
    >> doing end user software.

    >
    > I can't believe that too many developers are eligible
    > for this kind of scenario.
    > Somebody developing software 8+ hours a day for a living
    > would hardly spend another 8 hours developing software for free.


    Why would you say that? I work with computers all day and then go home and
    play with computers in my spare time. Why else would I keep all those VAX,
    PDP-11, Alpha, Sparc and other architectures around my house? I would
    guess the majority of developers of serious opensource projects have IT
    jobs in the real world.

    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

  11. Re: Longtime VMS system manager/programmer available

    Bill Gunshannon wrote:
    > In article <48022dd7$0$90268$14726298@news.sunsite.dk>,
    > Arne Vajh°j writes:
    >> JF Mezei wrote:
    >>> Michael Kraemer wrote:
    >>>> VAXstations OTOH were ridiculously overprized
    >>>> compared to their RISC counterparts.
    >>> Replace the word "ridiculously" with "artificially".
    >>>
    >>> DEC suffered from the "must not allow our high margin customers from
    >>> starting to buy more powerful and cheaper systems from us". They never
    >>> thought about attracting more new customers to compensate for the high
    >>> marghin customers buying cheaper systems from DEC.
    >>>
    >>> So those high margin customers ended up buying smaller, more powerful
    >>> and cheaper systems from companies DEC refused to admit competed against
    >>> itself. (like compaq/microsoft)
    >>>
    >>> DEC had had many opportunities from the early 1980s to the late 1980s to
    >>> really make it big. They missed them. Miseed the boat and were left behind.

    >> No doubt that they had high margins.
    >>
    >> But my guess is that the production costs were also higher.
    >>
    >> VAX'es was build to last for decades and did (still do in some
    >> cases).
    >>
    >> PC's are a use and throw away commodity. Nobody really cares
    >> if the parts start to fail after 4 years of 5x8 usage.

    >
    > That may be true today, but it certainly wasn't then. I just recently
    > (within the last 6 months) got rid of a number of original IBM PC's
    > that while too slow for any reasonable use were still perfectly usable.
    > I still have PS/2's that work perfectly well, albeit a little slow.
    > I, like many others, have always believed that the VAX could have been
    > made and marketed competitive with PC hardware. It was a decision by
    > DEC to not try to compete with the PC world then, just as it is iby HP
    > now.


    IBM made good PC's too.

    But first they lowered the quality. And later they sold the business
    to the chinese.

    PC users are not willing to pay for quality.

    With the growth in hardware "capacity" and software requirements
    to hardware, then I can not even blame them - it makes sense.

    Arne


  12. Re: Longtime VMS system manager/programmer available

    Bill Gunshannon wrote:
    > In article ,
    > brooks@cuebid.zko.hp.nospam (Rob Brooks) writes:
    >> 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!

    >
    > I didn't say only inexperienced programmers use C, but most people here
    > repeatedly have stated that no good code can be written in C. (I don't
    > agree, but I am sure that puts me in the minority here.)


    Obviously good code can be written in C.

    And my guess would be that a lot of good programmers work with C.

    Programmers very rarely choose the language to use themselves.

    And I would say that C is a language where the difference between
    good and bad programmers really show !

    Arne

  13. Re: Longtime VMS system manager/programmer available

    Michael Kraemer wrote:
    > Arne Vajh°j schrieb:
    >> No doubt that they had high margins.
    >>
    >> But my guess is that the production costs were also higher.

    >
    > VAXstations were overpriced by a factor about three.
    > I don't think this can be justified by higher production costs.


    It can not justify the high price.

    But it can prove that even with standard profit margin they
    would not have been competitive with the standard PC's.

    Arne

  14. Re: Longtime VMS system manager/programmer available

    Arne Vajh°j wrote:

    > And I would say that C is a language where the difference between
    > good and bad programmers really show !



    At the time C was relatively new outside of unix, it was said that
    assembler programmers were old enough to remember the absolute need to
    write efficient code in a very small memory footprint.

    Today, C programmers are the ones who are old enough to know to make
    efficient programs without bloated structures and giganourmous memory
    and CPU requirements. It the younger generation who grew up on C++,
    perl, php, all the visual microsoft crap who now are so far detached
    from the machines that they write bloated inefficient code and they have
    no experience in needing to write efficient code since they just buy
    more memory and faster CPU when their app needs it.

  15. Re: Longtime VMS system manager/programmer available

    JF Mezei schrieb:

    > Today, C programmers are the ones who are old enough to know to make
    > efficient programs without bloated structures and giganourmous memory
    > and CPU requirements. It the younger generation who grew up on C++,
    > perl, php, all the visual microsoft crap who now are so far detached
    > from the machines that they write bloated inefficient code and they have
    > no experience in needing to write efficient code since they just buy
    > more memory and faster CPU when their app needs it.


    The regular Gnu/Linux crowd isn't much better.


  16. Re: Longtime VMS system manager/programmer available

    Bill Gunshannon schrieb:

    > Why would you say that? I work with computers all day and then go home and
    > play with computers in my spare time.


    So do I. But "playing" is not "developing".

    > Why else would I keep all those VAX,
    > PDP-11, Alpha, Sparc and other architectures around my house? I would
    > guess the majority of developers of serious opensource projects have IT
    > jobs in the real world.


    Maybe, but, from my own experience, I doubt that one can devote the same
    amount of time and effort in a leisure time project after having worked
    hard 40+ hours in a regular IT job. But to be efficient on a particular
    project, you need to spend a significant amount of time.
    Look at the gazillion of OSS projects which were abandoned because
    the author(s) had no more time. Finished university, got a girl friend,
    bought a house etc.


  17. Re: Longtime VMS system manager/programmer available

    Arne Vajh°j schrieb:

    > It can not justify the high price.
    >
    > But it can prove that even with standard profit margin they
    > would not have been competitive with the standard PC's.


    The competition at that time weren't PCs
    (which nobody took serious anyway, we're talking about pre-Windoze3.1),
    but RISC workstations. Even those from DEC themselves were way
    more competitive than VAXen.


  18. Re: Longtime VMS system manager/programmer available

    In article , "John Wallace" writes:

    > There were PCs in DEC after the Rainbow, and I don't mean the European
    > DECivetti stuff.


    I only recall DEC reselling laptops from Olivetti. But I do recall
    DEC reselling desktops from Tandy.


  19. Re: Longtime VMS system manager/programmer available

    On Apr 14, 11:14 pm, JF Mezei wrote:
    > Arne Vajh°j wrote:
    > > And I would say that C is a language where the difference between
    > > good and bad programmers really show !

    >
    > At the time C was relatively new outside of unix, it was said that
    > assembler programmers were old enough to remember the absolute need to
    > write efficient code in a very small memory footprint.
    >
    > Today, C programmers are the ones who are old enough to know to make
    > efficient programs without bloated structures and giganourmous memory
    > and CPU requirements. It the younger generation who grew up on C++,
    > perl, php, all the visual microsoft crap who now are so far detached
    > from the machines that they write bloated inefficient code and they have
    > no experience in needing to write efficient code since they just buy
    > more memory and faster CPU when their app needs it.


    Say what? Since when has this made things run acceptably fast?

    AEF

  20. RE: Longtime VMS system manager/programmer available

    > -----Original Message-----
    > From: AEF [mailto:spamsink2001@yahoo.com]
    > Sent: April 15, 2008 11:29 AM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Re: Longtime VMS system manager/programmer available
    >
    > On Apr 14, 11:14 pm, JF Mezei wrote:
    > > Arne Vajh°j wrote:
    > > > And I would say that C is a language where the difference between
    > > > good and bad programmers really show !

    > >
    > > At the time C was relatively new outside of unix, it was said that
    > > assembler programmers were old enough to remember the absolute need

    > to
    > > write efficient code in a very small memory footprint.
    > >
    > > Today, C programmers are the ones who are old enough to know to make
    > > efficient programs without bloated structures and giganourmous

    > memory
    > > and CPU requirements. It the younger generation who grew up on C++,
    > > perl, php, all the visual microsoft crap who now are so far detached
    > > from the machines that they write bloated inefficient code and they

    > have
    > > no experience in needing to write efficient code since they just buy
    > > more memory and faster CPU when their app needs it.

    >
    > Say what? Since when has this made things run acceptably fast?
    >
    > AEF


    This is especially true these days with the advancement of multi-core
    cpu's. Applications not written with the concept of threads, SMP,
    job scheduling etc will have problems with performance no matter how
    many additional CPU's you throw at the solution.


    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.





+ Reply to Thread
Page 6 of 8 FirstFirst ... 4 5 6 7 8 LastLast