1 INFO-VAX	Wed, 17 Nov 2004	Volume 2004 : Issue 639       Contents:5 (Just for fun) What if DEC had licensed VMS to Apple? 9 Re: (Just for fun) What if DEC had licensed VMS to Apple? 9 Re: (Just for fun) What if DEC had licensed VMS to Apple? 9 Re: (Just for fun) What if DEC had licensed VMS to Apple? 9 Re: (Just for fun) What if DEC had licensed VMS to Apple?  Re: any opinions on Axiant? 8 Re: common code base for ALPHA and Itanium and compilers8 Re: common code base for ALPHA and Itanium and compilers8 Re: common code base for ALPHA and Itanium and compilers8 Re: common code base for ALPHA and Itanium and compilers; Re: DS10L SCSI card - recommendations ( + other uppgrades?)  DS25 under VMS V6.2  Re: DS25 under VMS V6.2  Re: DS25 under VMS V6.2 ( Re: EXE files different after ZIP/UNZIP?: Re: Extending DCL [was: Re: DCL suggestion for f$verify()]: Re: Extending DCL [was: Re: DCL suggestion for f$verify()]: Re: Extending DCL [was: Re: DCL suggestion for f$verify()]: Re: Extending DCL [was: Re: DCL suggestion for f$verify()]: Re: Extending DCL [was: Re: DCL suggestion for f$verify()]" Re: FAST BOOT OF SIMH VAX Emulator" Re: FAST BOOT OF SIMH VAX Emulator" Re: FAST BOOT OF SIMH VAX EmulatorP Re: interesting take on Olsen's "no reason for any individual to have a computer Re: Newsgroup moderation on VMS  Re: Newsgroup moderation on VMS  Re: Newsgroup moderation on VMS , Re: Online forums for former digits/deccies?P PLEASE DO NOT FEED THE TROLLS (was "Re: this newsgroup heavily trolled by Nomen  Re: Radeon 7500 problem  Re: raid hardware  Re: raid hardware E SOLUTION FOUND: SAVE and RESTORE - Re: FAST BOOT OF SIMH Emulated VAX  Re: t1lib, %SYSTEM-F-HPARITH Re: t1lib, %SYSTEM-F-HPARITH Re: t1lib, %SYSTEM-F-HPARITH Re: t1lib, %SYSTEM-F-HPARITH Re: t1lib, %SYSTEM-F-HPARITH Re: t1lib, %SYSTEM-F-HPARITH Re: t1lib, %SYSTEM-F-HPARITH Re: t1lib, %SYSTEM-F-HPARITH Re: t1lib, %SYSTEM-F-HPARITH Re: telnet  thru vpn to vms...8 Re: this newsgroup heavily trolled by gay Darrell Larose8 Re: this newsgroup heavily trolled by gay Darrell Larose" Upgrade base/path for V8.2 release  F ----------------------------------------------------------------------    Date: 17 Nov 2004 03:29:42 -0800& From: "Galen" <gspamtackett@yahoo.com>> Subject: (Just for fun) What if DEC had licensed VMS to Apple?B Message-ID: <1100690982.049928.85160@c13g2000cwb.googlegroups.com>  D I've heard it rumored that this was actually considered at one time.F Perhaps it was back around the time that DEC and Apple had their brief	 alliance.   A Would OS X have been built on VMS instead of Mach/OpenBSD/Darwin?  :-)    Imagine:  @ - opening a terminal window under OS X and getting a DCL prompt.  C - clustering (VMS-fashion) with up to 96 other Macs (not to mention  VAXes and other VMS platforms.)   @ - desktop applications built on CDA (would that be good or bad?)  E - mini-GUI apps built on DCL scripts, as can be done with help from a 3 Cocoa application using shell scripts on real OS X.   E - No Palmer, no C?rly  (? being a wildcard that matches either "u" or  "a".)   = - Micro$loth perhaps kept to just a minor role in the market.   D Seriously, though, the OS architectural talent of the VMS team, plusB the human interface talent of the Mac folks, might have eventuallyD produced quite an impressive desktop system that was even more solid than the current OS X.  ? The corporate cultures of the two companies were obviously very G different, perhaps even completely at odds with each other. But perhaps @ this kind of collaboration might still have been possible if the opportunity hadn't been missed.    ------------------------------    Date: 17 Nov 2004 08:06:53 -06004 From: kaplow_r@encompasserve.org.TRABoD (Bob Kaplow)B Subject: Re: (Just for fun) What if DEC had licensed VMS to Apple?3 Message-ID: <K4GImBSSFRPn@eisner.encompasserve.org>     If you want to play "what if"...  G What if in 1997, instead of selling the FAB to Intel they worked out an J agreement that IA64 was stilborn and it would be replaced with Alpha, madeH by Intel, licensed from DEC? Superior technology from DEC, cost of scale from Intel.     1 	Bob Kaplow	NAR # 18L	TRA # "Impeach the TRA BoD" & 		>>> To reply, remove the TRABoD! <<<K Kaplow Klips & Baffle:	http://nira-rocketry.org/LeadingEdge/Phantom4000.pdf L     www.encompasserve.org/~kaplow_r/    www.nira-rocketry.org    www.nar.org  I         Men never do evil so completely and cheerfully as when they do it 4         with religious conviction. --  Blaise Pascal   ------------------------------  # Date: Wed, 17 Nov 2004 15:18:49 GMT " From:   VAXman-  @SendSpamHere.ORGB Subject: Re: (Just for fun) What if DEC had licensed VMS to Apple?0 Message-ID: <00A3B017.595C527B@SendSpamHere.ORG>  j In article <K4GImBSSFRPn@eisner.encompasserve.org>, kaplow_r@encompasserve.org.TRABoD (Bob Kaplow) writes:! >If you want to play "what if"...  > H >What if in 1997, instead of selling the FAB to Intel they worked out anK >agreement that IA64 was stilborn and it would be replaced with Alpha, made   # Instead, IA64 is a living abortion.    --  < http://www.ProvN.com  for the *best* OpenVMS system security=                       solutions that others only claim to be.  --  , Cyber-Terrorism (si'-ber tayr'-or-iz-em) n.:M   The release of, the sale of, or the use of any Micro$oft software product!   --  K VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM    ------------------------------  % Date: Wed, 17 Nov 2004 10:22:00 -0500 # From: "John Smith" <a@nonymous.com> B Subject: Re: (Just for fun) What if DEC had licensed VMS to Apple?, Message-ID: <AKydneBlfaQF8QbcRVn-tQ@igs.net>   Bob Kaplow wrote: " > If you want to play "what if"... > F > What if in 1997, instead of selling the FAB to Intel they worked outC > an agreement that IA64 was stilborn and it would be replaced with C > Alpha, made by Intel, licensed from DEC? Superior technology from   > DEC, cost of scale from Intel.    I Or what if DEC had close to price/performance parity with Sun in the late I 80's/early 90's before Alpha came on the scene? Sun would have choked and B died and the biggest migration from VMS would never have happened.   ------------------------------  # Date: Wed, 17 Nov 2004 16:36:35 GMT 6 From: Lady Chatterly <gspamtackett@catcher.in.the.rye>B Subject: Re: (Just for fun) What if DEC had licensed VMS to Apple?+ Message-ID: <1af2922.e6eaf452@easynews.com>   g In article <1100690982.049928.85160@c13g2000cwb.googlegroups.com> Galen <gspamtackett@yahoo.com> wrote:  > E >I've heard it rumored that this was actually considered at one time. G >Perhaps it was back around the time that DEC and Apple had their brief 
 >alliance. > B >Would OS X have been built on VMS instead of Mach/OpenBSD/Darwin?  B The most overlooked advantage to owning a computer is that if they= foul up there's no law against whacking them around a little.    -- Lady Chatterly  B "Tell me something Lady C...are you a FEMbot...with a penchant for= evul?  And do you run on Linux? Cause I value stability in an # application." -- Onideus Mad Hatter    ------------------------------  % Date: Wed, 17 Nov 2004 06:41:11 -0500   From: "Jeff" <jpf33@hotmail.com>$ Subject: Re: any opinions on Axiant?2 Message-ID: <vNGmd.251$df.20004@tor-nn1.netcom.ca>   thanks!   6 "Syltrem" <syltremzulu@videotron.ca> wrote in message , news:lLomd.188$df.18336@tor-nn1.netcom.ca...4 >I have recently evaluated it, and it's pretty nice.I > You have to get use to doing click-click-click all the time, but after   > someI > initial bitching I found that mostly I could do things as fast with the 3 > click-click-click than by typing the code in TPU. L > And the most wonderful thing about it is that it's like PHPAINT come back  > toI > life, with added features. No need to calculate to coordinates for all   > stuff L > in your screen anymore. That's great because we have been missing PHPAINT  > a  > lot since version 6 was gone.  > I > You can easily import ALL your existing source code in Axiant, then you  > manage it in there. E > Just one source code will take care of Axiant clients and terminal  
 > clients.K > It doesn't help with QUIZ or QTP (I mean, no click-click-click interface   > to > do the programming of those). K > Everything is an object (screen, title,  temp, fields...) so it really is K > object programming and you can reuse objects. Good concept, all with good   > old Powerhouse code unchanged.E > Only major problem: There is a nasty bug in Powergrid that gets the K > connection killed as soon as you try to do a backout. They will certainly  > fix that. Have to. > L > I liked it, people here liked it. We just have to make a business case out > of it. >  >  > --  	 > Syltrem  >   > OpenVMS 7.3-1 + Oracle 8.1.7.4J > http://pages.infinit.net/syltrem (OpenVMS related web site, en franais)' > ---zulu is not in my email address--- 7 > "Jeff" <jpf33@hotmail.com> a crit dans le message de . > news:i6nld.121$df.11148@tor-nn1.netcom.ca... >> >> >  >    ------------------------------    Date: 17 Nov 2004 07:51:58 -0800& From: "Galen" <gspamtackett@yahoo.com>A Subject: Re: common code base for ALPHA and Itanium and compilers B Message-ID: <1100706718.096855.24170@c13g2000cwb.googlegroups.com>  @ Phillip only mentioned Fortran 2003. But I heard something about! Fortran that may be of interest--   A I believe I heard that the IA64 Fortran for VMS product is purely E Fortran 9x and does not include a separate Fortran 77 compiler unlike B the Alpha product which does. Can an HP source tell us for certain about this difference?  G I expect the Fortran 9x compiler would handle most Fortran 77 code with D few if any source changes based on limited experience with each, butG don't know if this is generally true with o.p.c. (Other People's Code.)    ------------------------------  % Date: Wed, 17 Nov 2004 10:59:58 -0500 # From: "John Smith" <a@nonymous.com> A Subject: Re: common code base for ALPHA and Itanium and compilers , Message-ID: <suSdndW25ejj6AbcRVn-rQ@igs.net>   John Reagan wrote: > John Smith wrote:  > 3 >> I'm not sure I understood this last bit clearly. E >> I know that the Fortran group at Compaq was bequeathed to Intel at " >> the time of the chip slaughter.F >> Are you now saying that HP has now gone out and hired its own groupF >> of Fortran developers, or is this a case of continued body donationF >> to Intel at HP's expense or that HP is paying for new Intel Fortran	 >> hires?  >> >> > F > No, the people work on Fortran on HP.  They do not work for Intel or > provide service to Intel.  > H > The relationship with Fortran is difficult to describe.  We do get "A"D > compiler from Intel, but we have to do some OpenVMS-specific work,D > test, package, document, answer customer problem reports, etc.  We  > also have to work on the RTLs.     Thanks for the clarification.    ------------------------------  + Date: Wed, 17 Nov 2004 16:39:09 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)A Subject: Re: common code base for ALPHA and Itanium and compilers $ Message-ID: <cnfurd$o4u$2@online.de>  B In article <1100706718.096855.24170@c13g2000cwb.googlegroups.com>,) "Galen" <gspamtackett@yahoo.com> writes:    B > Phillip only mentioned Fortran 2003. But I heard something about# > Fortran that may be of interest--  > C > I believe I heard that the IA64 Fortran for VMS product is purely G > Fortran 9x and does not include a separate Fortran 77 compiler unlike D > the Alpha product which does. Can an HP source tell us for certain > about this difference?  F What, exactly, do you mean here?  Or what are you concerned about?  OnH Alpha, true, one can process any standard Fortran77 code with either theF Fortran77 compiler or with the Fortran9x compiler with the appropriateE qualifiers (there is a qualifier /STANDARD=F90; since F77 is a proper * subset of F90, this should do the trick).   H Presumably, even if there is not a "separate compiler", there will be a I /STANDARD=F77 or whatever qualifer.  Perhaps in the early days there was  F more efficiency with the F77 compiler as opposed to the F90 compiler, : but surely that is not an issue today and/or with Itanium.  I > I expect the Fortran 9x compiler would handle most Fortran 77 code with F > few if any source changes based on limited experience with each, butI > don't know if this is generally true with o.p.c. (Other People's Code.)   F There are MANY qualifiers to the compiler; I'm sure this won't pose a 
 problem.    G On a related note, I REALLY like the HELP with Fortran: it provides an  I overview of all qualifiers including their defaults.  I think every HELP   should be like this.   ------------------------------  # Date: Wed, 17 Nov 2004 18:04:08 GMT & From: John Reagan <john.reagan@hp.com>A Subject: Re: common code base for ALPHA and Itanium and compilers 1 Message-ID: <soMmd.3051$XY2.432@news.cpqcorp.net>    Galen wrote:  C > I believe I heard that the IA64 Fortran for VMS product is purely G > Fortran 9x and does not include a separate Fortran 77 compiler unlike D > the Alpha product which does. Can an HP source tell us for certain > about this difference? >   < Correct.  There is no separate F77 compiler for OpenVMS I64.   --   John Reagan / HP Pascal/{A|I}MACRO for OpenVMS Project Leader  Hewlett-Packard Company    ------------------------------  + Date: Wed, 17 Nov 2004 09:23:04 +0000 (UTC) * From: Osmo Kujala <kujala@tukki.cc.jyu.fi>D Subject: Re: DS10L SCSI card - recommendations ( + other uppgrades?), Message-ID: <cnf59o$g8l$1@mordred.cc.jyu.fi>  , Rodman S. Regier <rsr@hfx.andara.com> wrote:  @ > My sources indicate that the 3X-KZPEA-DB and the Adaptec 39160" > start life from the same source.  A And my tests argee that KZPEA and Adaptec 39160 ("Adaptec model")  looks identical.  F > I have successfuly used 39160's in DS10L's and booted 3rd party SCSI > U320 disks.   G A little warning here. Plain Adaptec model of 39160 seems to work fine, F but Compaq model of 39160 doesn't work for Alpha/VMS. (1 model tested ' here, other sources have reported same)   ; >  I'm using it with external disks, but you should be able + > to use with a single internal SCSI drive.   * Or two if CD/floppy combo thrown away. (?)  G Now that we are discussing upgrading DS10L, I ask again some questions:    1)  K >I thought I could use temporarily higher PCI-riser. But do you anyone know J >if the PCI-riser of DS10 is only possibility? I don't happen to own such.   2)  G >Another "problem" is the memory. Is there any source of 200-pin SDRAMs H >at PC prices. Island used to have good low-profile model(can be used in1 >both banks), but even that is way too expensive.    3)  K >By the way, anyone can explain why there is a resistor in the cdrom/floppy / >combo set, which doesn't do anything but heat?    Osmo   ------------------------------  % Date: Wed, 17 Nov 2004 18:27:42 +0100 , From: "Ferry Bolhar" <bol@adv.magwien.gv.at> Subject: DS25 under VMS V6.25 Message-ID: <1100712465.610203@proxy.dienste.wien.at>   
 Hello people,   L does someone know whether an AlphaServer DS25 is running under OpenVMS V6.2?  $ MTIA and kind greetings from Vienna,   Ferry  --   Ing. Ferry Bolhar % Municipality of Vienna, Department 14  A-1010 Vienna / AUSTRIA  E-mail: bol@adv.magwien.gv.at    ------------------------------    Date: 17 Nov 2004 12:20:04 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)   Subject: Re: DS25 under VMS V6.23 Message-ID: <$PABjO3KiDBB@eisner.encompasserve.org>   d In article <1100712465.610203@proxy.dienste.wien.at>, "Ferry Bolhar" <bol@adv.magwien.gv.at> writes: > Hello people,  > N > does someone know whether an AlphaServer DS25 is running under OpenVMS V6.2?  C This is easily determined by the relative release dates of the two.   * The DS25 was released after the year 1999.  ) VMS V6.2 was released at the end of 1995.   E Thus that version of the operating system did not anticipate hardware , that would not be built for another 4 years.   ------------------------------  # Date: Wed, 17 Nov 2004 18:23:44 GMT # From: hoff@hp.nospam (Hoff Hoffman)   Subject: Re: DS25 under VMS V6.21 Message-ID: <QGMmd.3053$s%2.335@news.cpqcorp.net>   d In article <1100712465.610203@proxy.dienste.wien.at>, "Ferry Bolhar" <bol@adv.magwien.gv.at> writes:  M :does someone know whether an AlphaServer DS25 is running under OpenVMS V6.2?   E   For official support, OpenVMS Alpha V7.3-1 is the required minimum  A   version for the AlphaServer DS25 platform.  V7.3-2 with current 3   ECOs would be the version I would recommend here.   D   OpenVMS Alpha V6.2 has no support for the particular platform, nor;   for the particular Alpha microprocessor -- it won't boot.   B   Release platform minimums are referenced in the OpenVMS FAQ, and@   there is a version Rule Of Thumb listed there derived from the/   platform microprocessor, as well.  Some URLs:   '     <http://www.hp.com/go/openvms/faq/> <     <http://h71000.www7.hp.com/openvms/hw_supportchart.html>  D   I'd recommend use of the text-format version of the FAQ; it's moreD   easily searchable.   (The HTML-format FAQ is certainly pretty, butH   it is also deceptively useless for most reference-related activities.)  G   Do realize that we do not take the requirement for an OpenVMS upgrade C   for new platform support lightly -- as a general rule, if OpenVMS E   Engineering can provide suppport and can thus sell a newer platform F   on an older OpenVMS release, it makes sense for us to do so.  AddingG   support for new hardware and new platforms can be an involved effort, G   and generating a new release of the operating system is not a trivial    undertaking.    N  ---------------------------- #include <rtfaq.h> -----------------------------K     For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq N  --------------------------- pure personal opinion ---------------------------E         Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[at]hp.com    ------------------------------  # Date: Wed, 17 Nov 2004 16:35:53 GMT 2 From: Lady Chatterly <dsmit115@catcher.in.the.rye>1 Subject: Re: EXE files different after ZIP/UNZIP? ' Message-ID: <40497eb.3758a4fb@ausi.com>   a In article <2151a4d2.0411160902.24c93608@posting.google.com> dsmit115@csc.com (Dave Smith) wrote:  > H >sms@antinode.org wrote in message news:<04111514252420@antinode.org>...- >> From: Anders.Wallin@om.com (Anders Wallin)  >> >    ...A >> > Why doesn't ANAL/IMAGE or CHECKSUM think something is wrong?  >>F >>    Perhaps nothing significant is wrong.  Currently popular Zip andH >> UnZip programs can corrupt data after a file's EOF marker, which mostF >> programs won't read.  (However, I'd expect DIFFERENCES to be one of
 >> those.) > F >Me, too, but I've noticed that while an .EXE file doesn't necessarilyF >end on a block boundary (end of file byte is not necessarily 0) DIFF,G >being a record-oriented file comparison tool, will (probably) read the ? >entire last block as the last record and then end up with some E >possible "junk" at the end (as you have posted about in the past). I C >see this "junk" with DUMP /RECORD, for example, which isn't "smart ' >enough" to stop at the last used byte.   @ It all depends on what you are looking to achieve when you enter either area.   -- Lady Chatterly  6 "Apparently, Lady Chatterly is a Bot.  S/he pops up on= alt.music.michael-jackson from time to time." -- Archie Leach    ------------------------------  # Date: Wed, 17 Nov 2004 14:35:55 GMT + From: "Anthony Borla" <ajborla@bigpond.com> C Subject: Re: Extending DCL [was: Re: DCL suggestion for f$verify()] = Message-ID: <flJmd.39471$K7.11859@news-server.bigpond.net.au>   5 "David Froble" <davef@tsoft-inc.com> wrote in message & news:419A96B1.2010804@tsoft-inc.com...   Dave,    >  <SNIP> > 8 > I'm not one to ever say that things can't be improved.4 > However, for what I use DCL for, there aren't many7 > deficiencies.  I'd be interested is seeing what could  > be better. >   F See my other recent post to this thread, and read my comments below. ID should stress, also, that I wasn't being critical of DCL, but merelyH suggestive of how I think it could be improved so that its life could be% extended and its usefulness enhanced.    > , > Then again, I didn't really understand the > GUI when it first appeared.  >   C I had a similar problem when I switched from DESQview [a text-based J multitasking shell] to Windows 3.x [it was management mandated change] - I9 didn't understand *why* I had switched over to a GUI ;) !   J While it's touted as a general purpose interface, and in many circles as aL wholesale replacement for *all* other user interfaces, I see a GUI more as aC specialist interface one that excels at certain tasks, but one that 0 represents needless overhead for so many others.  C Additionally, it's not an interface well-suited to being automated, H something which includes system administration tasks. Certainly opinionsJ will differ here, and there may be wide differences between platforms, butL for me, the recording mouse-movements and keystrokes certainly isn't my idea  of 'application automation' :) !   > = > As for deficiencies, the command line interface on windows. ? > Pitiful. If I go on, it would be about no stand-alone backup,  > no batch, etc. >   ( You won't get much argument from me :) !   Some related points:  3 * The home-user targeted Windows offerings remained 8    'deficient' until the release of XP a couple of years3    ago; the professional-user targeted systems [NT] 6    offered richer CLI's, and could always be augmented    via 'resource kits'  7 * These deficiencies provided many third party software 8    developers ample scope to 'fill the void'. Also, much8    clever work was done by various user groups in making;    the standard command language useful [i.e. lots of tips, !    tricks, undocumented features]   5 * Not much call for a general purpose batch subsystem =    in single-user desktop systems; printing subsystem handled 6    its own queues, and job scheduling was later added.4    Again the professional-user targeted systems were5    better catered for [e.g. UNIX-derived 'at' command     for job scheduling]  7    Along similar lines, early home-user targeted didn't >    support 'services' [i.e. something like detached processes]<    until recently but professional-user targeted systems did    from the outset  J I think there was a strong belief in the 'GUI-as-universal-interface', andL this perhaps accounts for the very bare CLI offerings for home-user targetedC systems: it was probably expected they would never have to use it !   I The professional-user targeted systems faired better CLI-wise, but still, K not a patch on the standard offerings of VMS. Unfortunately quality doesn't  always win market share.   > B > Right now, DCL is part of those things that I've come to realize > make using VMS so nice.  >   L Yes, I fully agree with you ! DCL boasts some terrifically useful facilitiesL and has, I think, well-stood the test of time. My argument was for taking an7 already robust, and very useful tool, and improving it.   K I'm proposing that DCL be enhanced so that it is more on par with languages K like Perl, Python, and REXX [see my previous response], by allowing the DCL  user to:  F * Write their own lexical functions [i.e. same as labelled subroutinesH    but with the benefit of cleaner calling syntax, and ability to return    values directly e.g.   *        write sys$output f$mylexical(x,y,z)      or:  "        retval = f$mylexical(x,y,z)  A *  Use object modules / library routines [via suitable interface] =     directly from DCL. This feature may be the most difficult ?     to implement as it involves many issues, but it is also the @     one which has the most postential benefit, and is one of the;     features which makes the earlier mentioned languages so      flexible and powerful   F Also suggest that a new qualifier be added to commands that works in aL manner similar to /OUTPUT, but allows trapping of command output to a symbol instead of a file e.g.       COMMAND/SYMOUT=mysymbol   C One of the respondents also mentioned a couple of useful additions.   K More details may be found in my previous posts. Essentially all suggestions I seem like fairly small / modest additions that can, potentially, make DCL   more powerful and easier to use.   Cheers,   
 Anthony Borla    ------------------------------  # Date: Wed, 17 Nov 2004 14:35:44 GMT + From: "Anthony Borla" <ajborla@bigpond.com> C Subject: Re: Extending DCL [was: Re: DCL suggestion for f$verify()] = Message-ID: <4lJmd.39470$K7.23785@news-server.bigpond.net.au>   0 "John Vottero" <John@mvpsi.com> wrote in message7 news:6PTld.24819$5b1.1649@newssvr17.news.prodigy.com... 8 > "Anthony Borla" <ajborla@bigpond.com> wrote in message8 > news:NFJld.36254$K7.7440@news-server.bigpond.net.au... >   2 John, and all [including maybe some HP'er's ;) !],   >  > [Many good ideas snipped]  >   J I'm sure I wasn't the first to propose such facilities for DCL. They wouldG appear to be only fairly modest changes [though I cannot gauge how much G behind-the-scenes effort would be needed to effect them], but ones that L could - potentially - significantly enhance the usability of DCL. Of course,L technical feasability and economic feasability are two separate issues; if a> test of the latter fails, all related discussion becomes moot.   > 8 > My wish is that HP enhances DCL by starting over, with > a clean sheet of paper.  > < > Provide backwards compatibility with the /CLI qualifier in > AUTHORIZE. >   L I doubt HP will ever go 'back to the drawing board' with DCL, nor does thereK seem to be a compelling need to do so since DCL, as it is, provides all the K basic facilities of a robust command language. All I'm advocating is that a E few tweaks be applied to DCL [since it is, after all, *still* the VMS H operating system's standard command language], to make it more usable byE making it more extensible, and thus bring it more into line with more L recently developed script / command languages. This approach would allow forF the development of 'better' command procedures [by choosing to use theC enhancements], whilst also maintaining backwards compatibility [the B enhancements would not affect existing code execution in any way].   > 4 > DCL was fantastic 25 years ago but, it's outdated. >   @ If, by 'outdated', you mean it doesn't sport facilities such as:   * Complex data structures & * Direct access to all system services7 * Non-native facilities like regular expression parsing   C things which are expected as standard features in newer development . environments, then I'd have to agree with you.  G However, if you are referring to features of DCL, such as, for example:   : * Each command procedure line needs to commence with a '$'-   making it [possibly] more difficult to edit   ; * The lack of an explicit loop control structure, something :   which forces the programmer into using either recursion,8   or the GOTO keyword, for building iterative constructs  4 * Support for user-defined subroutines but *not* for6   user-defined functions, so forcing the programmer to2   use non-local variables to capture return values  G then I wouldn't call it 'outdated' [because it is perfectly possible to K solve real-world problems with these features], but I would agree that, DCL B programming may appear somewhat 'idiosyncratic', particularly to a< programmer who has only worked with newer language products.  F In either case there is ample scope for improving DCL. Importantly, by! simply adding these two features:   9 * Add user-defined function support, perhaps by extending     the syntax of the CALL command  4 * Add user-installable code support [as discussed in1   previous message, and also as code libraries ?]    it should be possible to:   ; * Write more modular, elegant code [since kludges involving "   non-local variables are avoided]  6 * Add support [via libraries] for, among other things,8   complex data structures, and access to system services7   [basically all things only normally accessable from a    compiled language module]   J One of the strengths, and probably a reason for the increasing popularity,L of scripting languages like Perl and Python, is their ability to easily callG on system services [via builtin user-installable code support] in a way K usually reserved for compiled languages like C, or COBOL. Surely DCL can be  made to share this strength ?   E The same facility [user-installable code support] can also be used to C augment DCL with more complex data structures, or give it access to G non-native facilities like regular expression parsing. Please note that D these are merely illustrative; I'm not suggesting *these* particularL facilities are essential to have but that if extensibility is built into DCLL such things can be incorporated if required, something that is currently not	 the case.   K It is instructive, I think, to compare DCL to REXX, the PL/I-like command / J scripting language in use primarily in IBM large-system environments [i.e.J z/OS and z/VM], but was also used as the command language of the ill-fatedE OS/2 product, and has garnered quite a following as a general-purpose D scripting language on desktop machines under both Windows and Linux.  I Both languages hark from the the late 1970's, are quite faithful to their G original specification [i.e. despite refinements have not substantially  changed from their inception],I and were designed to be command languages on 'large' systems [though REXX $ has a somewhat broader application].  H As would be expected of command languages both allow access to, at leastL some, system services, but do so in different ways. DCL does so strictly viaL inbuilt functionality [i.e. commands like SET and SHOW and lexical functionsJ like f$user etc], whereas REXX places minimal reliance on builtin routinesB for this task, instead relying on the user to supply the requisiteG functionality [i.e. it implements user-installable code support via the  builtin RXFUNCADD routine].   ; This difference in approach has the following implications:   6 * In DCL the user cannot add a new lexical function to5   the language; either HP writes it, or the user must 2   write a routine in another language, and call it   from the script   3 * In REXX the user decides what function is needed, 8   and adds it to the language; the function may, itself,5   be written in REXX, or it may be an external module   I Both approaches certainly allow a solution to be implemented. However, it K could be argued that the latter is a cleaner approach, one that makes for a * better, more easily implemented solution..  K Now, my aim in making this brief comparison with REXX is not to be critical L of DCL but to show how its utility can [easily ?] be extended. By making theE comparision with an existing real-world system of similar genesis and L vintage that *is* already so extended I hope to inject some credibility into< the proposal, and show that it is not simply much 'hot air'.  : A fair question to pose in response to such a proposal is:  9   Why bother ? Why not simply opt to use one of the newer @   scripting languages where facilities beyond DCL's capabilities   are needed ?  G The answer, I think, is that DCL isn't dead, it still is the VMS native H command language, and is a tool that is [presumably] still in use on theL many VMS systems around the globe [all 400,000 of them ;) !]. As such, if itJ is deemed both technically and economically feasable, then it should be so/ enhanced for the benefit of its existing users.   K By the by, such an enhancement may also have the benefit of providing proof H that VMS *isn't* being abandoned by its owner, so providing the existingK user base some assurance of continued future development and support [or am * I simply being naive in thinking this :)].   >  > You can go to: > : > http://msdn.microsoft.com/theshow/episode043/default.asp > 4 > and watch a video that demos MSH, the command line: > environment for Longhorn.  Just watch part 5, "Enter the > Programmer". >   J I skipped the video presentation, and went straight for the transcript - IB much prefer text when it comes to absorbing technical information.  K Fascinating stuff !!! In particular, the move away from a data stream-based G work mode to an 'intelligent' object-based one. A few initial thoughts:   B * MS seem to have rediscovered the importance of the command-line,>   especially for facilitating system administration tasks and,@   generally, automating tasks through scripting; a positive move   indeed since:   <   - They neglected it for *so* long e.g. it wasn't until theA     release of NT that any significant enhancements to the native =     command language [i.e. MS-DOS / Windows 'batch' language] @     appeared, and, in fact, it wasn't until XP was released that;     these enhancements became mainstream [i.e. available on #     home-targeted machines as well]   >   - It is well-high impossible to perform administration tasks>     effectively using a GUI [ok for one-off tasks, but painfulA     for anything complicated]. You *had* to use the command-line, =     helped along by the utilities provided in their 'resource 2     kits', to have a chance at automating anything  ; * It certainly seems to be a radical redesign of the humble =   command-line, though one targeted at developers rather than =   casual users. By the looks of things it will require *much* <   knowledge to become productive - I don't see someone being=   able to type 'help' and then be able to gain enough insight $   to quickly whip up a solution :) !  B * Streams of objects are likely to need *alot* of CPU power, so itB   would seem to be an environment that will very-fully exploit theB   added power of the next generation of 64 bit machines. Of course=   one would need to carefully weigh up whether this extra CPU B   'grunt' should be utilised by production applications, or by the.   infrastructure the operating system provides  G Overall, I found some of these ideas fascinating. Then again, I'd fully H expect to be fascinated when the capabilities of a *brand new* operatingK system are being demonstrated. No point in making such a huge investment if J the end product isn't going to offer significantly different capabilities.  G Crucially, though, even such new capabilities don't invalidate existing L capabilities: they are merely different, and very solid arguments must firstJ be built illustrating how, exactly, users will benefit, before an industryI stampede begins. Whilst MS seem able [due to exceedingly deep pockets] to J reinvent their operating system every few years [thus requiring developersJ to undertake significant retraining (along with the rewriting of much codeF !), and users update their applications for sometimes dubious, or onlyL minimal, gain] I don't see it as a strategy its competitors need necessarilyG follow. Being cognisant of core competencies and working to refine, and D improve them might better serve all current and future stakeholders.   > 3 > They even mention OpenVMS and DCL at least twice.  >    Here are the two instances:   K     "... Third is we've focused in on some production-oriented capabilities I     of it, like VMS's DCL or the AS400. We're really focused in on trying "     to solve admins' problems ..."   and:  I     "... and a production oriented system like VMS' DCL or AS400. But the H     last thing I mentioned to you was the fact that you can make gettingI     at management information as easy as it is getting at files in a file      system ..."   H Nothing substantial is said of VMS. I suspect it is only mentioned as anD example of a widely known server-based system [as opposed to desktopK system], though it is good to know that they seem to be implying that it is  a platform for serious work.  K Anyway, many thanks for your response, and for pointing out the Monad link, " it was certainly enlightening :) !   Cheers,   
 Anthony Borla    ------------------------------  % Date: Wed, 17 Nov 2004 07:35:02 -0800 # From: "Tom Linden" <tom@kednos.com> C Subject: Re: Extending DCL [was: Re: DCL suggestion for f$verify()] ( Message-ID: <opshl78ojezgicya@hyrrokkin>  G On Wed, 17 Nov 2004 14:35:44 GMT, Anthony Borla <ajborla@bigpond.com>    wrote:  2 > "John Vottero" <John@mvpsi.com> wrote in message9 > news:6PTld.24819$5b1.1649@newssvr17.news.prodigy.com... 9 >> "Anthony Borla" <ajborla@bigpond.com> wrote in message 9 >> news:NFJld.36254$K7.7440@news-server.bigpond.net.au...  >> > 4 > John, and all [including maybe some HP'er's ;) !], >  >> >> [Many good ideas snipped] >> > H > I'm sure I wasn't the first to propose such facilities for DCL. They   > would I > appear to be only fairly modest changes [though I cannot gauge how much I > behind-the-scenes effort would be needed to effect them], but ones that H > could - potentially - significantly enhance the usability of DCL. Of  	 > course, K > technical feasability and economic feasability are two separate issues;    > if a@ > test of the latter fails, all related discussion becomes moot. >  >>9 >> My wish is that HP enhances DCL by starting over, with  >> a clean sheet of paper. >>= >> Provide backwards compatibility with the /CLI qualifier in 
 >> AUTHORIZE.  >> > J > I doubt HP will ever go 'back to the drawing board' with DCL, nor does   > there K > seem to be a compelling need to do so since DCL, as it is, provides all    > the H > basic facilities of a robust command language. All I'm advocating is   > that aG > few tweaks be applied to DCL [since it is, after all, *still* the VMS J > operating system's standard command language], to make it more usable byG > making it more extensible, and thus bring it more into line with more L > recently developed script / command languages. This approach would allow   > for H > the development of 'better' command procedures [by choosing to use theE > enhancements], whilst also maintaining backwards compatibility [the D > enhancements would not affect existing code execution in any way]. >  >>5 >> DCL was fantastic 25 years ago but, it's outdated.  >> > B > If, by 'outdated', you mean it doesn't sport facilities such as: >  > * Complex data structures ( > * Direct access to all system services9 > * Non-native facilities like regular expression parsing  > E > things which are expected as standard features in newer development 0 > environments, then I'd have to agree with you. > I > However, if you are referring to features of DCL, such as, for example:  > < > * Each command procedure line needs to commence with a '$'/ >   making it [possibly] more difficult to edit  > = > * The lack of an explicit loop control structure, something < >   which forces the programmer into using either recursion,: >   or the GOTO keyword, for building iterative constructs > 6 > * Support for user-defined subroutines but *not* for8 >   user-defined functions, so forcing the programmer to4 >   use non-local variables to capture return values  I why *not* ?  Doesn't REXX provide such support?  I believe VOS also has    this. L Of course it would have to be appropriately priveleged as pointed out in a   previous post by John Briggs (IIRC) > I > then I wouldn't call it 'outdated' [because it is perfectly possible to K > solve real-world problems with these features], but I would agree that,    > DCL D > programming may appear somewhat 'idiosyncratic', particularly to a> > programmer who has only worked with newer language products. > H > In either case there is ample scope for improving DCL. Importantly, by# > simply adding these two features:  > ; > * Add user-defined function support, perhaps by extending " >   the syntax of the CALL command > 6 > * Add user-installable code support [as discussed in3 >   previous message, and also as code libraries ?]  >  > it should be possible to:  > = > * Write more modular, elegant code [since kludges involving $ >   non-local variables are avoided] > 8 > * Add support [via libraries] for, among other things,: >   complex data structures, and access to system services9 >   [basically all things only normally accessable from a  >   compiled language module]  > B > One of the strengths, and probably a reason for the increasing  
 > popularity, K > of scripting languages like Perl and Python, is their ability to easily    > callI > on system services [via builtin user-installable code support] in a way L > usually reserved for compiled languages like C, or COBOL. Surely DCL can   > be > made to share this strength ?  > G > The same facility [user-installable code support] can also be used to E > augment DCL with more complex data structures, or give it access to I > non-native facilities like regular expression parsing. Please note that F > these are merely illustrative; I'm not suggesting *these* particularL > facilities are essential to have but that if extensibility is built into   > DCL L > such things can be incorporated if required, something that is currently   > not  > the case.  > E > It is instructive, I think, to compare DCL to REXX, the PL/I-like    > command / H > scripting language in use primarily in IBM large-system environments   > [i.e. D > z/OS and z/VM], but was also used as the command language of the   > ill-fated G > OS/2 product, and has garnered quite a following as a general-purpose F > scripting language on desktop machines under both Windows and Linux. > K > Both languages hark from the the late 1970's, are quite faithful to their I > original specification [i.e. despite refinements have not substantially   > changed from their inception],K > and were designed to be command languages on 'large' systems [though REXX & > has a somewhat broader application]. > J > As would be expected of command languages both allow access to, at leastL > some, system services, but do so in different ways. DCL does so strictly   > via F > inbuilt functionality [i.e. commands like SET and SHOW and lexical   > functions E > like f$user etc], whereas REXX places minimal reliance on builtin   
 > routinesD > for this task, instead relying on the user to supply the requisiteI > functionality [i.e. it implements user-installable code support via the  > builtin RXFUNCADD routine].  > = > This difference in approach has the following implications:  > 8 > * In DCL the user cannot add a new lexical function to7 >   the language; either HP writes it, or the user must 4 >   write a routine in another language, and call it >   from the script  > 5 > * In REXX the user decides what function is needed, : >   and adds it to the language; the function may, itself,7 >   be written in REXX, or it may be an external module  > K > Both approaches certainly allow a solution to be implemented. However, it I > could be argued that the latter is a cleaner approach, one that makes    > for a , > better, more easily implemented solution.. > F > Now, my aim in making this brief comparison with REXX is not to be  
 > criticalL > of DCL but to show how its utility can [easily ?] be extended. By making   > the G > comparision with an existing real-world system of similar genesis and K > vintage that *is* already so extended I hope to inject some credibility    > into> > the proposal, and show that it is not simply much 'hot air'. > < > A fair question to pose in response to such a proposal is: > ; >   Why bother ? Why not simply opt to use one of the newer B >   scripting languages where facilities beyond DCL's capabilities >   are needed ? > I > The answer, I think, is that DCL isn't dead, it still is the VMS native J > command language, and is a tool that is [presumably] still in use on theJ > many VMS systems around the globe [all 400,000 of them ;) !]. As such,   > if it K > is deemed both technically and economically feasable, then it should be    > so1 > enhanced for the benefit of its existing users.  > I > By the by, such an enhancement may also have the benefit of providing    > proof J > that VMS *isn't* being abandoned by its owner, so providing the existingL > user base some assurance of continued future development and support [or   > am, > I simply being naive in thinking this :)]. >  >> >> You can go to:  >>; >> http://msdn.microsoft.com/theshow/episode043/default.asp  >>5 >> and watch a video that demos MSH, the command line ; >> environment for Longhorn.  Just watch part 5, "Enter the  >> Programmer".  >> > L > I skipped the video presentation, and went straight for the transcript -   > I D > much prefer text when it comes to absorbing technical information. > B > Fascinating stuff !!! In particular, the move away from a data   > stream-basedI > work mode to an 'intelligent' object-based one. A few initial thoughts:  > D > * MS seem to have rediscovered the importance of the command-line,@ >   especially for facilitating system administration tasks and,B >   generally, automating tasks through scripting; a positive move >   indeed since:  > > >   - They neglected it for *so* long e.g. it wasn't until theC >     release of NT that any significant enhancements to the native ? >     command language [i.e. MS-DOS / Windows 'batch' language] B >     appeared, and, in fact, it wasn't until XP was released that= >     these enhancements became mainstream [i.e. available on % >     home-targeted machines as well]  > @ >   - It is well-high impossible to perform administration tasks@ >     effectively using a GUI [ok for one-off tasks, but painfulC >     for anything complicated]. You *had* to use the command-line, ? >     helped along by the utilities provided in their 'resource 4 >     kits', to have a chance at automating anything > = > * It certainly seems to be a radical redesign of the humble ? >   command-line, though one targeted at developers rather than ? >   casual users. By the looks of things it will require *much* > >   knowledge to become productive - I don't see someone being? >   able to type 'help' and then be able to gain enough insight & >   to quickly whip up a solution :) ! > D > * Streams of objects are likely to need *alot* of CPU power, so itD >   would seem to be an environment that will very-fully exploit theD >   added power of the next generation of 64 bit machines. Of course? >   one would need to carefully weigh up whether this extra CPU D >   'grunt' should be utilised by production applications, or by the0 >   infrastructure the operating system provides > I > Overall, I found some of these ideas fascinating. Then again, I'd fully J > expect to be fascinated when the capabilities of a *brand new* operatingL > system are being demonstrated. No point in making such a huge investment   > if@ > the end product isn't going to offer significantly different   > capabilities.  > I > Crucially, though, even such new capabilities don't invalidate existing J > capabilities: they are merely different, and very solid arguments must   > first E > be built illustrating how, exactly, users will benefit, before an   
 > industryK > stampede begins. Whilst MS seem able [due to exceedingly deep pockets] to C > reinvent their operating system every few years [thus requiring    > developersI > to undertake significant retraining (along with the rewriting of much    > codeH > !), and users update their applications for sometimes dubious, or onlyD > minimal, gain] I don't see it as a strategy its competitors need  
 > necessarily I > follow. Being cognisant of core competencies and working to refine, and F > improve them might better serve all current and future stakeholders. >  >>4 >> They even mention OpenVMS and DCL at least twice. >> >  > Here are the two instances:  > B >     "... Third is we've focused in on some production-oriented   > capabilitiesK >     of it, like VMS's DCL or the AS400. We're really focused in on trying $ >     to solve admins' problems ..." >  > and: > K >     "... and a production oriented system like VMS' DCL or AS400. But the J >     last thing I mentioned to you was the fact that you can make gettingK >     at management information as easy as it is getting at files in a file  >     system ..."  > J > Nothing substantial is said of VMS. I suspect it is only mentioned as anF > example of a widely known server-based system [as opposed to desktopL > system], though it is good to know that they seem to be implying that it   > is > a platform for serious work. > I > Anyway, many thanks for your response, and for pointing out the Monad    > link, $ > it was certainly enlightening :) ! > 	 > Cheers,  >  > Anthony Borla  >  >  >        --  C Using Opera's revolutionary e-mail client: http://www.opera.com/m2/    ------------------------------  % Date: Wed, 17 Nov 2004 11:25:22 -0500 # From: sol gongola <sol@adldata.com> C Subject: Re: Extending DCL [was: Re: DCL suggestion for f$verify()] + Message-ID: <419B7B72.78D3F571@adldata.com>    >  > > : > > My wish is that HP enhances DCL by starting over, with > > a clean sheet of paper.  > > > > > Provide backwards compatibility with the /CLI qualifier in > > AUTHORIZE. > >  >  >   9 Is there a way to specify something other than /CLI=DCL ?   H I haven't been able to find any specifications for writing a vms usable 3 command line interface. Does such a document exist?    sol    ------------------------------    Date: 17 Nov 2004 12:14:56 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) C Subject: Re: Extending DCL [was: Re: DCL suggestion for f$verify()] 3 Message-ID: <Beh5FvJV5N3d@eisner.encompasserve.org>   Q In article <419B7B72.78D3F571@adldata.com>, sol gongola <sol@adldata.com> writes:   ; > Is there a way to specify something other than /CLI=DCL ?   " Yes.  That is how /CLI=MCR worked.  J > I haven't been able to find any specifications for writing a vms usable 5 > command line interface. Does such a document exist?   B It is the VMS Source Listings, from which you will have to reverseG engineer the proper technique.  Writing your own CLI is not a supported G feature.  I am sure it would be supported if you were to pay HP a _lot_ 	 of money.    ------------------------------    Date: 17 Nov 2004 02:59:37 -0800& From: "Galen" <gspamtackett@yahoo.com>+ Subject: Re: FAST BOOT OF SIMH VAX Emulator B Message-ID: <1100689177.181769.20060@c13g2000cwb.googlegroups.com>   Dave wrote:   F > I'm guessing most people are running SIMH just to see VMS running on a windoz) > box, and aren't doing anything serious.    Ah, but not me!   ( I'm running it on an OS X 10.3 PowerMac., Still not doing anything serious, though :-)   ------------------------------    Date: 17 Nov 2004 06:22:02 -0800& From: vadim.model@srm.ru (Vadim Model)+ Subject: Re: FAST BOOT OF SIMH VAX Emulator = Message-ID: <c34f4f8b.0411170622.642006f0@posting.google.com>   Z David Froble <davef@tsoft-inc.com> wrote in message news:<419A9CD4.30509@tsoft-inc.com>...L > If you have applications running, with complex transactions being posted, S > updating multiple files, and you kill it in the middle of a transaction then you   > have bad data.   No doubt ...  P > I'm guessing most people are running SIMH just to see VMS running on a windoz ) > box, and aren't doing anything serious.   C Exactly. If one complains about waiting for too long booting up and E shutting down VMS, I assume that one is not doing anything serious. I C would never recommend fast "powerdown" instead of slow shutdown for % one running 8 parallel batch BACKUPs.    Regards, Vadim    ------------------------------  # Date: Wed, 17 Nov 2004 16:38:05 GMT 5 From: Lady Chatterly <vadim.model@catcher.in.the.rye> + Subject: Re: FAST BOOT OF SIMH VAX Emulator / Message-ID: <a9b3986.3891dc17@news.1usenet.com>   d In article <c34f4f8b.0411170622.642006f0@posting.google.com> vadim.model@srm.ru (Vadim Model) wrote: > [ >David Froble <davef@tsoft-inc.com> wrote in message news:<419A9CD4.30509@tsoft-inc.com>... L >> If you have applications running, with complex transactions being posted,S >> updating multiple files, and you kill it in the middle of a transaction then you  >> have bad data.  > 
 >No doubt ...   E After the war, the United States had split into five separate regions C based on the various factors and military objectives they each had.   P >> I'm guessing most people are running SIMH just to see VMS running on a windoz* >> box, and aren't doing anything serious. > D >Exactly. If one complains about waiting for too long booting up andF >shutting down VMS, I assume that one is not doing anything serious. ID >would never recommend fast "powerdown" instead of slow shutdown for& >one running 8 parallel batch BACKUPs.  B And when the going gets tough, feminists headjob under the nearest desk.   	 >Regards,  >Vadim  % What makes you so certain about that?    -- Lady Chatterly  F "So KK (he is almost smart enough to get his 3rd K) tell everyone what1 you really think of Lady Chatterly..." -- Aratzio    ------------------------------  ! Date: Wed, 17 Nov 04 10:00:59 GMT  From: jmfbahciv@aol.com Y Subject: Re: interesting take on Olsen's "no reason for any individual to have a computer , Message-ID: <S5SdnYEH5_20tAbcRVn-qA@rcn.net>  , In article <419AA740.8010504@tsoft-inc.com>,,    David Froble <davef@tsoft-inc.com> wrote: >John Smith wrote: > 2 >> Phillip Helbig---remove CLOTHES to reply wrote: >>  , >>>http://www.snopes.com/quotes/kenolsen.asp >>> F >>>The above is interesting because a) I always thought of this in theD >>>same context as Thomas J. Watson's [Chairman of the Board at IBM]	 >>>famous 
 >>>remark: >>> > >>>   I think there's a world market for about five computers. >>> E >>>and b) it comes from a source which in my opinion has made few, if H >>>any, mistakes in determining the truth or falsehood of urban legends. >>> I >>>I think the quote below, however, WAS intended the way it sounds.  :-)  >>> K >>>------------------------------------------------------------------------  -- >>>  >> ----- >>  E >>>The PC has bred anarchy.  Hardware, software, and peripherals have C >>>been thrown together in random configurations at the whim of any E >>>employee with access to an expense voucher and computer catalogue. D >>>The result has been a financial and administrative night mare for >>>corporations. >>>  >>   >>  E >> Maybe he'd already had dealings with Bill Gates when he made that   remark?  >> ;-) >>   >>   >>   > ) >Ever hear the expression "'dead' right"?  > ? >It's true that PCs have been a bit of financial, support, and   administration  L >problem, but the other side of that coin is that they have also provided a L >significant increase in productivity and capability in some ways.  Anybody  know  I >of anyone who still dicates letters, memos, and such for a secretary to  	 type up?    5 Which is a very large drain on business productivity.    <snip>   /BAH  ' Subtract a hundred and four for e-mail.    ------------------------------  # Date: Wed, 17 Nov 2004 12:00:12 GMT " From:   VAXman-  @SendSpamHere.ORG( Subject: Re: Newsgroup moderation on VMS0 Message-ID: <00A3AFFB.9B7ABE38@SendSpamHere.ORG>  \ In article <419A9F99.D9360E2F@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes:4 >what would it take to moderate a newsgroup on VMS ?   Mail and an editor.  --  < http://www.ProvN.com  for the *best* OpenVMS system security=                       solutions that others only claim to be.  --  , Cyber-Terrorism (si'-ber tayr'-or-iz-em) n.:M   The release of, the sale of, or the use of any Micro$oft software product!   --  K VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM    ------------------------------  # Date: Wed, 17 Nov 2004 15:34:57 GMT & From: John Reagan <john.reagan@hp.com>( Subject: Re: Newsgroup moderation on VMS0 Message-ID: <BcKmd.3030$UE2.42@news.cpqcorp.net>    VAXman- @SendSpamHere.ORG wrote:^ > In article <419A9F99.D9360E2F@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > 5 >>what would it take to moderate a newsgroup on VMS ?  >  >  > Mail and an editor.   3 and a very thick skin or at least an asbestos suit.    --   John Reagan / HP Pascal/{A|I}MACRO for OpenVMS Project Leader  Hewlett-Packard Company    ------------------------------  % Date: Wed, 17 Nov 2004 10:51:35 -0500 # From: "John Smith" <a@nonymous.com> ( Subject: Re: Newsgroup moderation on VMS, Message-ID: <y8WdneSZP6gV7gbcRVn-jQ@igs.net>   John Reagan wrote:" > VAXman- @SendSpamHere.ORG wrote:8 >> In article <419A9F99.D9360E2F@teksavvy.com>, JF Mezei) >> <jfmezei.spamnot@teksavvy.com> writes:  >>7 >>> what would it take to moderate a newsgroup on VMS ?  >> >> >> Mail and an editor. > 5 > and a very thick skin or at least an asbestos suit.     - Asbestos is so passe and a health hazard too. 3 How about an Aerogel suit instead? Very cool stuff.   . http://stardust.jpl.nasa.gov/tech/aerogel.html  3 http://eande.lbl.gov/ECS/Aerogels/images/FLOWER.JPG    http://www.aerogel.com/ # http://www.aerogel.com/footwear.htm    ------------------------------    Date: 17 Nov 2004 06:56:49 -0800  From: "Barry" <dysert@gmail.com>5 Subject: Re: Online forums for former digits/deccies? C Message-ID: <1100703409.910966.209150@f14g2000cwb.googlegroups.com>   G I too would be interested in keeping in touch with former Digits (hence # my lurking in this group).  Thanks.    ------------------------------  % Date: Wed, 17 Nov 2004 10:41:26 -0500 / From: "Geoffrey Welsh" <reply@newsgroup.please> Y Subject: PLEASE DO NOT FEED THE TROLLS (was "Re: this newsgroup heavily trolled by Nomen  3 Message-ID: <XiKmd.87$Lh4.45@fe51.usenetserver.com>    Darrell Larose wrote: 4 > "Nomen Nescio" <nobody@dizum.com> wrote in message4 > news:b2cbaabfa66fb5294289c9101525431e@dizum.com... >>' > TROLLS again, and again... ad nauseum   7  ... and people who get suckered into replying to them.   . Ladies & Gents, PLEASE DO NOT FEED THE TROLLS.  J Those of us who've learned how to use killfiles & filters would never see D the trolls' posts if you wouldn't reply and quote them.  I heartily  recommend you do the same.   --  < Geoffrey Welsh <Geoffrey [dot] Welsh [at] bigfoot [dot] com>F If anything worth doing is worth doing right, then surely anything not- worth doing right is not worth doing at all.     ------------------------------  # Date: Wed, 17 Nov 2004 16:58:27 GMT 4 From: "Fred Kleinsorge" <fred.nospam@nospam.dec.com>  Subject: Re: Radeon 7500 problem2 Message-ID: <TqLmd.3041$CH2.1000@news.cpqcorp.net>  L Because the DVI port was being configured by "BIOS magic".  The BIOS is onlyL run on the first card, and not on the others.  So the driver needs to do theG magic.  The next graphics patch kit should allow the DVI port (with the   analog dongle attached) to work.  C We are looking at dual head and direct DVI-DVI for a future update.       D "Robert Trawinski" <robert.trawinski@softax.com.pl> wrote in message% news:cnd0v9$8d6$1@bozon2.softax.pl... 	 > Hi all,  > I > I have got DS20 with two Radeon7500 PCI, VMS 7.3-2, all patches (update  > 3.0).  > J > First card work with DVI output, but second work only with D-Sub output.F > This is multi-head configuration (no Xinerama configured). Both card > work properly A > (DVI output works good) when they are the only card in machine.  > A > Why can't I connect second monitor to second's card DVI output?  >  > Thanks for your help >  >  > Robert   ------------------------------    Date: 17 Nov 2004 02:50:39 -0800& From: "Galen" <gspamtackett@yahoo.com> Subject: Re: raid hardwareB Message-ID: <1100688639.266304.53560@z14g2000cwz.googlegroups.com>  E I have some very recent experience with the SmartArray 5300A hardware  RAID controller and VMS.  G The controller supports up to two or four Ultra 160 Wide SCSI ports and > either 256 MB or 512 MB of battery-backed cache memory, and isC field-upgradable between these two levels. One of the SCSI ports is G available for internal use if desired. According to the specs it has an ? aggregate bandwidth of 533-MB/s. I assume this would be for the B four-port version in a 66 MHz PCI slot (though 33 MHz slots can be used.)  D The controller has built in predictive failure analysis for both theG attached disk drives and its cache memory. It's not clear to me how YOU C find out about impending failures, but perhaps it's via SEA (System B Event Analyzer, formerly known as Compaq Analyze) or the Web-based Management Agents (see below.)  G The SmartArray 5300A controller only supports the Storageworks 4300 and F SmartArray MSA30 storage shelves (and maybe the Storageworks 4200, I'mC not sure). At this writing the controller does not support hot plug @ tape drives on VMS. I haven't tried any non-hotplug tape drives.  @ As far as I can tell there is no way to back up the controller's+ settings other than recording them by hand.   E The SmartArray 5300A is supported with VMS V7.3-1 and V7.3-2 provided E that certain system ECO kits are applied. There are some restrictions E as to which Alpha hardware platforms support it. If you have a system F that's newer than the EV67 ES40 it's likely to be fully supported; theF link at the bottom of this message will take you to much more completeB information on HP's site. (I used the controller on an unsupportedF first-generation ES40 with no problem except that the attached storage was invisible to SRM.)  G It is true that you can configure the controller from the console (SRM)  level with a command like:   >>> RUN BIOS PYA0   F But this gives you access to only a limited subset of the controller'sD configurable settings. You have no control over stripe size or cacheG memory allocation, and no ability (as far as I know) to migrate between  RAID levels.  G There is NO CLI-level management interface to the controller. Even from A the SRM level via the RUN BIOS command, all you get is a DOS-like F screen based configuration tool (it will work on a graphics head or on" a VT100-compatible dumb terminal.)  G As far as I know the only way to get full access is using the Web-based = Management Agents (WBEM) and the ACU-XE application that runs F underneath them. WIth these you have your choice of a basic, assisted,F or advanced interface to configure the device and its storage. HoweverB with the current version of things (WBEM V3.02 and ACU-XE V1.26) I@ can't get the advanced mode to come up. There are also some userB interface performace issues when used with VMS-based browsers, andG ACU-XE can also abort if you click on browser objects before it's ready  for you to do so.   G Installing WBEM and ACU-XE is not exactly trivial. I strongly recommend C reading the release notes and installation guides for both of these C products (and for the 5300A itself) before attempting installation.   B This link will take you to the SmartArray 5300A page on HP's site,1 where you'll find much more complete information:    http://tinyurl.com/4oxy9  G Let me know if you have any questions about this device and I'll see if  I can answer them.  C (Also greetings, Jim, from a former Bay Area VMS system manager and C BAYVAX member--I was at Lockheed Martin in Sunnyvale for 19 years.)    ------------------------------    Date: 17 Nov 2004 09:50:31 -0800, From: JimStrehlow@data911.com (Jim Strehlow) Subject: Re: raid hardware= Message-ID: <4b6ec350.0411170950.56b6e305@posting.google.com>   & "Galen" <gspamtackett@yahoo.com> wroteG > I have some very recent experience with the SmartArray 5300A hardware  > RAID controller and VMS. ...   < That is just the type of information for which I am looking.
 Thank you.  F Are there any "education courses" (??) or good manuals or white papersD on helping to educate OpenVMS System Managers  before  they purchaseD what they think they will need to know about RAID for OpenVMS ... or/ do we just do as we do best ... learn as we go?   C I wonder what sort of RAID hardware will be available for Integrity  servers?  B Jim Strehlow, Alameda, CA, USA (BAYVAX LUG member 14-17 years ago)   ------------------------------    Date: 17 Nov 2004 01:57:18 -0800, From: shevchenko@ikp.tu-darmstadt.de (Sheva)N Subject: SOLUTION FOUND: SAVE and RESTORE - Re: FAST BOOT OF SIMH Emulated VAX= Message-ID: <adeef81b.0411170157.3405b8dd@posting.google.com>   " SOLUTION FOUND: SAVE and RESTORE !, Thanks to everybody for so many suggestions!7 Perhaps, you were confused with the Subject of my mail.   A I run it under two platforms, Windows and Linux. The PC is rather 4 slow, so for me the bootup sequence takes 8 minutes!  D The problem is NOT in automating the boot-up of the emulated system.D I just want to have it booted all the time, without the need to SHUT it DOWN!D When I restart my PC, I can start SIMH rather quickly. This is not aE problem. The emulated system has to be started newly - and this takes  time.   F BUT I have found the solution! AND THAT IS WHAT Tim Sneddon suggested!  4 The SIMH commands save and restore - let me do that.  C Let's say at the end of my working day I do NOT do SHUTDOWN for the : emulated system! I just interrupt the emulation by Ctrl-E. Then I do "simh> save file.sav" D And it stores all the actual values of registers (program counter PC+ etc), the stack and the memory into a file.   < The next day I boot the PC, start the SIMH, and then just do "simh> restore file.sav"    @ and voila! Within 10 seconds the emulated system is running, andE exactly at the same point where I have left it yesterday. There is no % need to SHUTDOWN and BOOT it anymore!   E It was not quite obvious, as there are almost no info about these two D commands, they are not discussed anywhere except in one file, hidden in the sources.   - I had to look for a long, until I found them! 8 I think one has to put it into more common FAQ sections.   Anyway, thank you!  
 Best regards,  Artem.          s Tim Sneddon <first-initiallastname@bsddotinfomedia.com.au> wrote in message news:<2vsvd5F2pgl4kU1@uni-berlin.de>...  > Stanley F. Quayle wrote:J > > SIMH will have the same limitations of the operating system that it's G > > running.  Having a "quick boot" of VMS has been on the "wish list"   > > for a long time. > > J > > To modify VMS to support "quick boot" would be a substantial effort --G > > and HP certainly isn't interested in supporting it.  After all, if  J > > the boot takes 10 minutes, but your system runs for years afterwards, 7 > > what's the point?  This isn't Windows, after all...  > C > As mentioned by other posters...VMS on VAX did have this feature. A > I went looking for this a while back and I'm pretty sure it was  > removed in OpenVMS VAX V7.1. >  > > G > > But, given the source code of SIMH, you could probably capture the  - > > memory state somehow, and give it a shot.  > D > There is a way of doing this. IIRC you can use the SAVE <filename>D > command to save the emulator state. Then use RESTORE <filename> toC > bring it back. The only problem I had with this is that I use the / > DZ telnet connection and doing this broke it.  >  > Regards, Tim.    ------------------------------  % Date: Wed, 17 Nov 2004 06:50:56 -0500 2 From: Chip Coldwell <coldwell@physics.harvard.edu>% Subject: Re: t1lib, %SYSTEM-F-HPARITH G Message-ID: <Pine.LNX.4.44.0411170645570.6335-100000@frank.harvard.edu>    On Tue, 16 Nov 2004, Z wrote:    > Chip Coldwell wrote: > > %SYSTEM-F-HPARITH, high performance arithmetic trap, Imask=00000000, Fmask=00040000, summary=02, PC=000000000006DD14, PS=0000001B R > > -SYSTEM-F-FLTINV, floating invalid operation, PC=000000000006DD14, PS=0000001B3 > > %TRACE-F-TRACEBACK, symbolic stack dump follows N > >   image    module    routine             line      rel PC           abs PCS > >  T1EXAMPLE1  TYPE1  RMoveTo              6247 00000000000037A4 000000000006DD14  > ... @ > > Does anyone have any experience with this?  Is there an ECO? > ' > This may be a problem with your code.  > @ > What is happening at line 6247 in TYPE1.C, function RMoveTo()?  F TYPE1.C has only 4496 lines in it, but the function RMoveTo looks like this:    /* |- dx dy RMOVETO |- */ ( /* Behaves like RMOVETO in PostScript */ static int RMoveTo(dx,dy)    DOUBLE dx,dy;  {    long pindex = 0;  -   /* compute hinting for previous segment! */ a   FindStems( currx, curry, currx-ppoints[numppoints-2].x, curry-ppoints[numppoints-2].y, dx, dy);   4   /* Allocate a new path point and pre-setup data */   pindex = nextPPoint();'   ppoints[pindex].x       = currx + dx; '   ppoints[pindex].y       = curry + dy; .   ppoints[pindex].ax      = ppoints[pindex].x;.   ppoints[pindex].ay      = ppoints[pindex].y;(   ppoints[pindex].type    = PPOINT_MOVE;   ppoints[pindex].hinted  = 0;     /* update ideal position */    currx                  += dx;    curry                  += dy;      return(0); }   A Note that there are no divides, and therefore no divides-by-zero.    Chip   --   Charles M. "Chip" Coldwell System Administrator Harvard Physics Department 617-495-3388   ------------------------------  % Date: Wed, 17 Nov 2004 04:05:55 -0800  From: Z <z@no.spam> % Subject: Re: t1lib, %SYSTEM-F-HPARITH 0 Message-ID: <10pmfk373aqu389@corp.supernews.com>   Chip Coldwell wrote: >>>%SYSTEM-F-HPARITH, high performance arithmetic trap, Imask=00000000, Fmask=00040000, summary=02, PC=000000000006DD14, PS=0000001BQ >>>-SYSTEM-F-FLTINV, floating invalid operation, PC=000000000006DD14, PS=0000001B 2 >>>%TRACE-F-TRACEBACK, symbolic stack dump followsM >>>  image    module    routine             line      rel PC           abs PC R >>> T1EXAMPLE1  TYPE1  RMoveTo              6247 00000000000037A4 000000000006DD14 >> >>...  >>? >>>Does anyone have any experience with this?  Is there an ECO?  >>' >>This may be a problem with your code.  >>@ >>What is happening at line 6247 in TYPE1.C, function RMoveTo()? >  > H > TYPE1.C has only 4496 lines in it, but the function RMoveTo looks like > this:   4 Use $ CC/LIST/SHOW=ALL ...  to generate a .LIS file.    C > Note that there are no divides, and therefore no divides-by-zero.   F Noted. Please post the same function (RMoveTo) but from the .LIS this 3 time, with the line #s generated by /LIST/SHOW=ALL.    ------------------------------  % Date: Wed, 17 Nov 2004 12:46:55 +0000 - From: John Laird <nospam@laird-towers.org.uk> % Subject: Re: t1lib, %SYSTEM-F-HPARITH 8 Message-ID: <jfhmp0d38epchr7n9ii9ug6sm3o23k1k4a@4ax.com>  1 On Tue, 16 Nov 2004 21:30:56 -0500, Chip Coldwell % <coldwell@physics.harvard.edu> wrote:   5 >%SYSTEM-F-HPARITH, high performance arithmetic trap, M >Imask=00000000, Fmask=00040000, summary=02, PC=000000000006DD14, PS=0000001B O >-SYSTEM-F-FLTINV, floating invalid operation, PC=000000000006DD14, PS=0000001B   D Both these messages are consistent with an instruction referencing aL floating-point value that was not a valid one.  (Not all bit representationsL are valid floating-point numbers.)  The Fmask suggests the value in registerL F18 was the bad one.  Examination of the compiler listing, together with theL stack dump, should help narrow this down to a line of code and hopefully the errant variable.  K This is often the result of passing in the address of something that is not J a genuine float or double variable, or has perhaps never been assigned but( instead contains a previous stale value.  J Invalid Vax fp values are those with an exponent field of all zeroes (noteH this is not the same as an exponent of zero), and a non-zero sign bit orG mantissa, iirc.  Zero is represented by all-zeroes.  This rather nicely H catches cases where the argument is in fact a smallish positive integer.J From memory, IEEE has a specific bit-representation for NaN (Not a Number)I and I can't honestly remember if all other values are valid or not.  They J may be, especially if the exponent is not offset as Vax ones are.  NaN mayE be logically -0.0 but my memory is very rusty.  Knowing this helps to J explain why your program stops crashing when you change fp format, but you( almost certainly still have a bug in it.   --  ' Take my advice, I don't use it anyway.     Mail john rather than nospam...    ------------------------------  % Date: Wed, 17 Nov 2004 07:40:48 -0500 2 From: Chip Coldwell <coldwell@physics.harvard.edu>% Subject: Re: t1lib, %SYSTEM-F-HPARITH G Message-ID: <Pine.LNX.4.44.0411170739080.6335-100000@frank.harvard.edu>    On Wed, 17 Nov 2004, Z wrote:  > Chip Coldwell wrote: > >>>%SYSTEM-F-HPARITH, high performance arithmetic trap, Imask=00000000, Fmask=00040000, summary=02, PC=000000000006DD14, PS=0000001BS > >>>-SYSTEM-F-FLTINV, floating invalid operation, PC=000000000006DD14, PS=0000001B 4 > >>>%TRACE-F-TRACEBACK, symbolic stack dump followsO > >>>  image    module    routine             line      rel PC           abs PC T > >>> T1EXAMPLE1  TYPE1  RMoveTo              6247 00000000000037A4 000000000006DD14 > >> > >>...  > >>A > >>>Does anyone have any experience with this?  Is there an ECO?  > >>) > >>This may be a problem with your code.  > >>B > >>What is happening at line 6247 in TYPE1.C, function RMoveTo()? > >  > > J > > TYPE1.C has only 4496 lines in it, but the function RMoveTo looks like	 > > this:  > 6 > Use $ CC/LIST/SHOW=ALL ...  to generate a .LIS file. >  > E > > Note that there are no divides, and therefore no divides-by-zero.  > H > Noted. Please post the same function (RMoveTo) but from the .LIS this 5 > time, with the line #s generated by /LIST/SHOW=ALL.    Here ya go:   )            6239 /* |- dx dy RMOVETO |- */ 8            6240 /* Behaves like RMOVETO in PostScript */)            6241 static int RMoveTo(dx,dy)             6242   DOUBLE dx,dy;        1    6243 { "       1    6244   long pindex = 0;       1    6245 =       1    6246   /* compute hinting for previous segment! */ q       1    6247   FindStems( currx, curry, currx-ppoints[numppoints-2].x, curry-ppoints[numppoints-2].y, dx, dy);        1    6248 D       1    6249   /* Allocate a new path point and pre-setup data */(       1    6250   pindex = nextPPoint();7       1    6251   ppoints[pindex].x       = currx + dx; 7       1    6252   ppoints[pindex].y       = curry + dy; >       1    6253   ppoints[pindex].ax      = ppoints[pindex].x;>       1    6254   ppoints[pindex].ay      = ppoints[pindex].y;8       1    6255   ppoints[pindex].type    = PPOINT_MOVE;.       1    6256   ppoints[pindex].hinted  = 0;       1    6257 -       1    6258   /* update ideal position */ /       1    6259   currx                  += dx; /       1    6260   curry                  += dy;        1    6261        1    6262   return(0);       1    6263 }    Chip   --   Charles M. "Chip" Coldwell System Administrator Harvard Physics Department 617-495-3388   ------------------------------  % Date: Wed, 17 Nov 2004 07:52:11 -0500 2 From: Chip Coldwell <coldwell@physics.harvard.edu>% Subject: Re: t1lib, %SYSTEM-F-HPARITH G Message-ID: <Pine.LNX.4.44.0411170745470.6335-100000@frank.harvard.edu>   ) On Wed, 17 Nov 2004, Chip Coldwell wrote:    > On Wed, 17 Nov 2004, Z wrote:  > > Chip Coldwell wrote: > > >>>%SYSTEM-F-HPARITH, high performance arithmetic trap, Imask=00000000, Fmask=00040000, summary=02, PC=000000000006DD14, PS=0000001BU > > >>>-SYSTEM-F-FLTINV, floating invalid operation, PC=000000000006DD14, PS=0000001B 6 > > >>>%TRACE-F-TRACEBACK, symbolic stack dump followsQ > > >>>  image    module    routine             line      rel PC           abs PC V > > >>> T1EXAMPLE1  TYPE1  RMoveTo              6247 00000000000037A4 000000000006DD14 > > >>	 > > >>...  > > >>C > > >>>Does anyone have any experience with this?  Is there an ECO?  > > >>+ > > >>This may be a problem with your code.  > > >>D > > >>What is happening at line 6247 in TYPE1.C, function RMoveTo()? > > >  > > > L > > > TYPE1.C has only 4496 lines in it, but the function RMoveTo looks like > > > this:  > > 8 > > Use $ CC/LIST/SHOW=ALL ...  to generate a .LIS file. > >  > > G > > > Note that there are no divides, and therefore no divides-by-zero.  > > J > > Noted. Please post the same function (RMoveTo) but from the .LIS this 7 > > time, with the line #s generated by /LIST/SHOW=ALL.  > 
 > Here ya go:  > + >            6239 /* |- dx dy RMOVETO |- */ : >            6240 /* Behaves like RMOVETO in PostScript */+ >            6241 static int RMoveTo(dx,dy) ! >            6242   DOUBLE dx,dy;  >       1    6243 { $ >       1    6244   long pindex = 0; >       1    6245 ? >       1    6246   /* compute hinting for previous segment! */ s >       1    6247   FindStems( currx, curry, currx-ppoints[numppoints-2].x, curry-ppoints[numppoints-2].y, dx, dy);   E Next I'll guess you're going to want to see "FindStems" based on the  C suspicion that it is a macro or the compiler in-lined the function.    Here it is:   :            5351 static void FindStems( double x, double y,<            5352                        double dx, double dy,D            5353                        double nextdx, double nextdy)       1    5354 {        1    5355   int i;&       1    5356   int newvert, newhor;.       1    5357   int newhorhalf, newverthalf;       1    5358 P       1    5359   /* The following values will be used to decide whether a curveM       1    5360      crosses or touches a stem in an aligned manner or not */ ^       1    5361   double dtana     = 0.0;   /* tangent of pre-delta against horizontal line */\       1    5362   double dtanb     = 0.0;   /* tangent of pre-delta against vertical line */_       1    5363   double nextdtana = 0.0;   /* tangent of post-delta against horizontal line */ ]       1    5364   double nextdtanb = 0.0;   /* tangent of post-delta against vertical line */        1    5365        1    5366 5       1    5367   /* setup default hinted position */ I       1    5368   ppoints[numppoints-1].ax     = ppoints[numppoints-1].x; I       1    5369   ppoints[numppoints-1].ay     = ppoints[numppoints-1].y; ;       1    5370   if ( ppoints[numppoints-1].hinted == -1 ) 4       1    5371     /* point is not to be hinted! */       1    5372     return;        1    5373   else5       1    5374     ppoints[numppoints-1].hinted = 0;        1    5375 %       1    5376   if ( InDotSection )        1    5377     return;        1    5378 ,       2    5379   if ( ProcessHints == 0 ) {       2    5380     return;        1    5381   }        1    5382 [       1    5383   /* setup (absolute) tangent values and define limits that indicate nearly ?       1    5384      horizontal or nearly vertical alignment */ g       1    5385 #define NEARLYVERTICAL     0.2   /* This corresponds to about 11.3 degress deviation */ d       1    5386 #define NEARLYHORIZONTAL   0.2   /* from the ideal direction.                     */"       2    5387   if ( dy != 0 ) {"       2    5388     dtana = dx/dy;&       2    5389     if ( dtanb < 0.0 )%       2    5390       dtana = -dtana;        1    5391   }        1    5392   else-       1    5393     dtana = NEARLYHORIZONTAL; "       2    5394   if ( dx != 0 ) {"       2    5395     dtanb = dy/dx;&       2    5396     if ( dtanb < 0.0 )%       2    5397       dtanb = -dtanb;        1    5398   }        1    5399   else+       1    5400     dtanb = NEARLYVERTICAL; &       2    5401   if ( nextdy != 0 ) {.       2    5402     nextdtana = nextdx/nextdy;*       2    5403     if ( nextdtana < 0.0 )-       2    5404       nextdtana = -nextdtana;        1    5405   }        1    5406   else1       1    5407     nextdtana = NEARLYHORIZONTAL; &       2    5408   if ( nextdx != 0 ) {.       2    5409     nextdtanb = nextdy/nextdx;*       2    5410     if ( nextdtanb < 0.0 )-       2    5411       nextdtanb = -nextdtanb;        1    5412   }        1    5413   else/       1    5414     nextdtanb = NEARLYVERTICAL;        1    5415 (       1    5416   newvert = newhor = -1;0       1    5417   newhorhalf = newverthalf = -1;       1    5418 >       2    5419   for (i = currstartstem; i < numstems; i++) {=       3    5420     if (stems[i].vertical) { /* VSTEM hint */ A       3    5421       /* OK, stem is crossed in an aligned way */ X       4    5422       if ( (dtana <= NEARLYVERTICAL) || (nextdtana <= NEARLYVERTICAL)) {1       4    5423         if ((x >= stems[i].x ) && =       5    5424             (x <= stems[i].x+stems[i].dx )) { &       5    5425           newvert = i;=       5    5426           if (x < stems[i].x+stems[i].dx / 2) /       5    5427             newverthalf = LEFT;        5    5428           else0       5    5429             newverthalf = RIGHT;       4    5430         }        3    5431       }        2    5432     } ;       3    5433     else {                 /* HSTEM hint */ \       4    5434       if ( (dtanb <= NEARLYHORIZONTAL) || (nextdtanb <= NEARLYHORIZONTAL)) {C       4    5435         /* OK, stem is crossed in an aligned way */ 1       4    5436         if ((y >= stems[i].y ) && =       5    5437             (y <= stems[i].y+stems[i].dy )) { %       5    5438           newhor = i; =       5    5439           if (y < stems[i].y+stems[i].dy / 2) 0       5    5440             newhorhalf = BOTTOM;       5    5441           else-       5    5442             newhorhalf = TOP;        4    5443         }        3    5444       }        2    5445     }        1    5446   }        1    5447 (       2    5448   if ( newvert != -1 ) {Q       2    5449     /* mark the latest point in the point list to be v-hinted! */ 0       3    5450     if ( newverthalf == LEFT ) {%       3    5451       /* left hint */ L       3    5452       ppoints[numppoints-1].ax  += stems[newvert].lbhintval;       2    5453     }        3    5454     else {'       3    5455        /* right hint */ L       3    5456       ppoints[numppoints-1].ax  += stems[newvert].rthintval;       2    5457     } 9       2    5458     ppoints[numppoints-1].hinted |= 0x01;        1    5459   } '       2    5460   if ( newhor != -1 ) { Q       2    5461     /* mark the latest point in the point list to be h-hinted! */ 1       3    5462     if ( newhorhalf == BOTTOM ) { '       3    5463       /* bottom hint */ K       3    5464       ppoints[numppoints-1].ay  += stems[newhor].lbhintval;        2    5465     }        3    5466     else {%       3    5467        /* top hint */ K       3    5468       ppoints[numppoints-1].ay  += stems[newhor].rthintval;        2    5469     } 9       2    5470     ppoints[numppoints-1].hinted |= 0x02;        1    5471   }        1    5472        1    5473   return;        1    5474        1    5475 }    Chip   --   Charles M. "Chip" Coldwell System Administrator Harvard Physics Department 617-495-3388   ------------------------------  + Date: Wed, 17 Nov 2004 16:01:55 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)% Subject: Re: t1lib, %SYSTEM-F-HPARITH $ Message-ID: <cnfsli$lu3$1@online.de>  G In article <Pine.LNX.4.44.0411162113550.2226-100000@frank.harvard.edu>, 5 Chip Coldwell <coldwell@physics.harvard.edu> writes:    H > And if there is an ECO, how does a hobbyist obtain it? (by becoming a  > paying customer?)   &    Linkname: openvms_patches directory2         URL: ftp://ftp.itrc.hp.com/openvms_patches!     Charset: iso-8859-1 (assumed) :      Server: dux418 FTP server (HP ASL ftpd, version(323))   ------------------------------  # Date: Wed, 17 Nov 2004 16:37:21 GMT 0 From: Lady Chatterly <nospam@catcher.in.the.rye>% Subject: Re: t1lib, %SYSTEM-F-HPARITH 5 Message-ID: <af6963b.a6a26b2f@bignews5.bellsouth.net>   f In article <jfhmp0d38epchr7n9ii9ug6sm3o23k1k4a@4ax.com> John Laird <nospam@laird-towers.org.uk> wrote: > 2 >On Tue, 16 Nov 2004 21:30:56 -0500, Chip Coldwell& ><coldwell@physics.harvard.edu> wrote: > 6 >>%SYSTEM-F-HPARITH, high performance arithmetic trap,N >>Imask=00000000, Fmask=00040000, summary=02, PC=000000000006DD14, PS=0000001BP >>-SYSTEM-F-FLTINV, floating invalid operation, PC=000000000006DD14, PS=0000001B > E >Both these messages are consistent with an instruction referencing a M >floating-point value that was not a valid one.  (Not all bit representations M >are valid floating-point numbers.)  The Fmask suggests the value in register M >F18 was the bad one.  Examination of the compiler listing, together with the M >stack dump, should help narrow this down to a line of code and hopefully the  >errant variable.   D Perhaps I should let you all in on a little secret. No one likes youC in the future. This time period is looked at as being full of lazy, C self-centered, civically ignorant sheep. Perhaps you should be less 1 concerned about me and more concerned about that.   L >This is often the result of passing in the address of something that is notK >a genuine float or double variable, or has perhaps never been assigned but ) >instead contains a previous stale value.   ! Aren't you being a bit tentative?   K >Invalid Vax fp values are those with an exponent field of all zeroes (note I >this is not the same as an exponent of zero), and a non-zero sign bit or H >mantissa, iirc.  Zero is represented by all-zeroes.  This rather nicelyI >catches cases where the argument is in fact a smallish positive integer. K >From memory, IEEE has a specific bit-representation for NaN (Not a Number) J >and I can't honestly remember if all other values are valid or not.  TheyK >may be, especially if the exponent is not offset as Vax ones are.  NaN may F >be logically -0.0 but my memory is very rusty.  Knowing this helps toK >explain why your program stops crashing when you change fp format, but you ) >almost certainly still have a bug in it.   C Can you be certain you cannot honestly remember if all other values  are valid or not?    -- Lady Chatterly  @ "Oh, look everyone, joooooooooody is chummy with the chatterly - troll....." -- Rhyanon   ------------------------------  % Date: Wed, 17 Nov 2004 09:21:37 -0800  From: Z <z@no.spam> % Subject: Re: t1lib, %SYSTEM-F-HPARITH 0 Message-ID: <10pn23t2l7dq2ef@corp.supernews.com>   Chip Coldwell wrote:I >>>Noted. Please post the same function (RMoveTo) but from the .LIS this  6 >>>time, with the line #s generated by /LIST/SHOW=ALL.  
 >>Here ya go:  ... s >>      1    6247   FindStems( currx, curry, currx-ppoints[numppoints-2].x, curry-ppoints[numppoints-2].y, dx, dy);  ...   < >            5351 static void FindStems( double x, double y,> >            5352                        double dx, double dy,F >            5353                        double nextdx, double nextdy) ... $ >       2    5387   if ( dy != 0 ) {$ >       2    5388     dtana = dx/dy; ... $ >       2    5394   if ( dx != 0 ) {$ >       2    5395     dtanb = dy/dx; ... ( >       2    5401   if ( nextdy != 0 ) {0 >       2    5402     nextdtana = nextdx/nextdy; ... ( >       2    5408   if ( nextdx != 0 ) {0 >       2    5409     nextdtanb = nextdy/nextdx;  G I suspect that either dy (lines 5387,5388) or dx (5394,5395) or nextdy  G (5401,5402) or nextdx (5408,5409) is very small, small enough to cause   the trap but not exactly 0.   C Why not run it in the debugger with SET BREAK/EXCEPTION (I _think_  G that's what you want ... HELP SET BREAK if it's not) and see if that's  B the case?  I assume this is reproduceable even when compiled with - /DEBUG=ALL/NOOPT, linked with /DEBUG and run?    ------------------------------  % Date: Wed, 17 Nov 2004 09:25:58 -0800  From: Z <z@no.spam> % Subject: Re: t1lib, %SYSTEM-F-HPARITH / Message-ID: <10pn2c2nftup7b@corp.supernews.com>    John Laird wrote: 6 >>%SYSTEM-F-HPARITH, high performance arithmetic trap,N >>Imask=00000000, Fmask=00040000, summary=02, PC=000000000006DD14, PS=0000001BP >>-SYSTEM-F-FLTINV, floating invalid operation, PC=000000000006DD14, PS=0000001B >  > F > Both these messages are consistent with an instruction referencing aN > floating-point value that was not a valid one.  (Not all bit representationsN > are valid floating-point numbers.)  The Fmask suggests the value in registerN > F18 was the bad one.  Examination of the compiler listing, together with theN > stack dump, should help narrow this down to a line of code and hopefully the > errant variable. > M > This is often the result of passing in the address of something that is not L > a genuine float or double variable, or has perhaps never been assigned but* > instead contains a previous stale value.  D Good point. The code uses a typedef (DOUBLE) for dx and dy. But the ( actual function declares them as double.  + What's the definition of type DOUBLE, Chip?    (It'll be in your .LIS file)   ------------------------------  # Date: Wed, 17 Nov 2004 16:36:24 GMT 3 From: Lady Chatterly <pcoviello@catcher.in.the.rye> ' Subject: Re: telnet  thru vpn to vms... * Message-ID: <dfafb53.05eb14c4@demon.co.uk>  e In article <ff0902a.0411160931.1a6f48c0@posting.google.com> pcoviello@gmail.com (Paul Covielo) wrote:  > G >we have a vendor that is trying to connect to one node in a cluster of % >3, the others they can connect to...  > , >this is a new es47 node into the cluster...  A Hmmm ...  kinda adds a new meaning to the word ...  oh ...  never  mind.   F >we have telnet setup similar to the other nodes and we can connect on
 >this side  " Have you considered anything else?   >any thoughts?    A friend's eye is a good mirror.   >thanks  >Paul   E A high-speed train system connects the larger cities. Roads are still 4 used for cars and many people ride horses and bikes.   -- Lady Chatterly  B "It ain't a bot. Bot's are smarter, funnier, more interesting." -- Gary L. Burnore    ------------------------------  + Date: Tue, 16 Nov 2004 18:00:03 +0100 (CET) % From: Nomen Nescio <nobody@dizum.com> A Subject: Re: this newsgroup heavily trolled by gay Darrell Larose 8 Message-ID: <8346a5d4dbfb9c0db0ca881d6e7bc6be@dizum.com>  A Darrell Larose <cota348@rogers.com> masturbated while fantasizing  about JF Mezei and ejaculated:   > 3 >"Nomen Nescio" <nobody@dizum.com> wrote in message 3 >news:b2cbaabfa66fb5294289c9101525431e@dizum.com...  >>& >TROLLS again, and again... ad nauseum  A Poor Darrell Larose ... still in love with JF Mezei even after JF E rejected him and scolded him and humiliated him publically ... LOL!!!    Poor gay Darrell.....    Darrell Larose 121 Northwestern Ave Ottawa, ON K1Y 0M1 (613) 725-0245 cota348@rogers.com ad607@FreeNet.Carleton.CA    ------------------------------  % Date: Wed, 17 Nov 2004 09:14:26 -0500 " From: "treo" <noemail@invalid.org>A Subject: Re: this newsgroup heavily trolled by gay Darrell Larose 7 Message-ID: <91Jmd.9937$NE4.9662@fe34.usenetserver.com>   3 "Nomen Nescio" <nobody@dizum.com> wrote in message  1 news:8346a5d4dbfb9c0db0ca881d6e7bc6be@dizum.com..     L All anyone sees is you, an anonymous coward, outing personal info on usenet.  2 That makes you a netabuser, and scum. End of story   ------------------------------  % Date: Wed, 17 Nov 2004 13:40:34 -0500  From: norm.raphael@metso.com+ Subject: Upgrade base/path for V8.2 release Q Message-ID: <OF55B49540.B236F81D-ON85256F4F.006657F8-85256F4F.00669F25@metso.com>   I Will the new (nonSDK) OpenVMS V8.2 VAX require V7.3 before upgrade or can 4 it be upgraded from V7.2 or (which) earlier version?I Will the new (nonSDK) OpenVMS V8.2 Alpha require V7.3-2 before upgrade or : can it be upgraded from V7.3-1 or (which) earlier version?   ------------------------------   End of INFO-VAX 2004.639 ************************