INFO-VAX Fri, 15 Feb 2008 Volume 2008 : Issue 91 Contents: Re: DIBOL to Re: DIBOL to Re: DIBOL to Re: DIBOL to Re: DIBOL to Does dism/unload spin down a disk? Re: Does dism/unload spin down a disk? Re: Does dism/unload spin down a disk? Re: Does dism/unload spin down a disk? Re: Does dism/unload spin down a disk? Re: Does dism/unload spin down a disk? Re: Does dism/unload spin down a disk? Re: HP OpenVMS Tele-Marketing?!? Re: ODS5, /NAMES = AS_IS, LIBRARY, MMS v. me OT Richard Dawkins on slavery Re: OT Richard Dawkins on slavery Re: OT Richard Dawkins on slavery Re: SPAM detection for freeware MX 4.2 Re: Thank you Re: The "World's First" MicroVAX II Museum is now Open You don't know when you're well-off! ---------------------------------------------------------------------- Date: Thu, 14 Feb 2008 11:33:39 -0800 (PST) From: Chip Camden Subject: Re: DIBOL to Message-ID: <749a9b6a-13e0-4985-9183-3fdd896e51cd@a75g2000hsb.googlegroups.com> On Feb 10, 6:06 pm, "Richard B. Gilbert" wrote: > Tad Winters wrote: > > Let me start by saying, this is _not_ meant to start a war over > > programming languages. I'm after honest, technical answers. > > > I've done some work for a small company who happens to use some custom > > software, written largely in DIBOL, with the rest in MACRO. The custom > > forms editor generates additional MACRO code and DIBOL "include" files. > > > They've been using a single VAX system with an HSD30 for storage. The > > system runs rather slowly at times and this both frustrates the users > > and probably causes some customers to consider other suppliers. The > > system has been tuned many times, without any appreciable improvement. > > Tuning was not intended for miracles. Unless a system is horribly > mistuned to start with, the best you can hope for is to squeeze out the > last ten percent in performance! > > > I would like to propose they move to an AlphaServer, however since > > DIBOL is not available for Alpha, the standard answer would be Synergy > > DBL. Since Synergy charges for a runtime license, this is a show > > stopper. They would be looking at more than $20,000 for Synergy DBL > > alone. > > > I did mention that CHARON-VAX might be a possibility, but I'm not a > > huge fan of subjecting a stable operating system to running atop > > something much less stable. (Too bad CHARON-VAX is not an emulator > > running on bare metal.) > > > Now to the meat of my question. If a person was interested in moving > > code from DIBOL to another language (on OpenVMS), what language would > > be the best choice? Keep these details in mind: > > A runtime license cost isn't going to fly. > > Just about ANY language except Gnu C is going to require a license that > costs money! AFAIK there is no such thing as Gnu COBOL! > > > > > The language will need to support RMS file types (since indexed, > > relative and sequential files are used.) > > Calls to subroutines written in MACRO will need to work like they would > > with DIBOL. > > The language would need to support "include" files. > > > Somebody will probably ask how many lines of code there are to convert. > > I'm going to guess between 300,000 and 350,000, but don't hold me to > > it. > > > The routines directly written in MACRO have previously been ported to > > the Alpha processor, so as to MACRO, I'd only need to be sure I > > continued to generate correct code. > > > A certain number of the DIBOL programs comprise the forms editor and > > support applications, which I would port first. I'd like to start down > > the correct road first. The languages which I first thought would meet > > the requirements are FORTRAN, BASIC, Pascal, and COBOL. This doesn't > > strictly rule out others, and it would seem prudent to choose a > > language which is also supported on Itanium. > > > I await your wisdom. > > You didn't say what model VAX they were using. Some were painfully > slow, others were much faster. Knowing the Model of the VAX, we might > be able to suggest a substantially faster machine. A faster machine > might very well require more "License Units"! OTOH, rewriting 350,000 > lines of code in a new language, supported on the Alpha and/or Itanic, > is probably going to cost seven to ten man years of effort. > > The other approach, the one that you asked about; is another language. > You can code just about anything, in just about any language! Languages > have both strengths and weaknesses. The language that was great for > doing Fourier Transforms would have to be bent out of shape to write > accounts receivable and vice versa of course. > > The only widely available languages that might be close to DIBOL (a > language I know almost nothing about) are COBOL and PL/1. I believe > that PL/1 is available for Alpha; I don't know if it's available for Itanic. > > I think that, if you cost this out carefully, you may find that a > $20,000 license is small change compared to the rest of it! I'd have to agree with Richard. You could easily blow $20K in wages to convert a fraction of the code to another language. VAX DIBOL code can usually be carried over to Synergy/DE with very few changes. I'd talk to Synergex. Disclaimer: Synergex is a client of mine. ------------------------------ Date: Thu, 14 Feb 2008 11:52:22 -0800 (PST) From: Chip Camden Subject: Re: DIBOL to Message-ID: <0091266a-be13-472b-a35e-1ed1e2343cc8@d68g2000hsg.googlegroups.com> On Feb 13, 3:26 pm, Doug Phillips wrote: > On Feb 13, 3:32 pm, Tad Winters > > wrote: > > Doug Phillips wrote innews:95285ad2-9ac4-4042-9049-b1ad7fb654f4@d70g2000hsb.googlegroups.com: > > > > On Feb 12, 6:33 pm, Tad Winters > > > wrote: > > >> It seems like DIBOL was quite a good language. Why did Digital > > >> drop it with the move to Alpha? > > > > To echo Hank Vander Waal, DBL is DIBOL for the post-VAX era. At the > > > time of the Alpha port, Synergex (or was it still DISC then?) had > > > It was still DISC. > > That's what I thought, but I didn't look it up. > > > > > > extended DBL to a higher level, while still keeping DIBOL > > > compatibility, and they were going to port DBL to Alpha anyway. DEC > > > likely decided that their own resources would be better utilized in > > > other areas. > > > So they decided that it was better to give someone else the business > > rather than compete. That's an interesting way to do business. > > Yea, bean-counters tend to look at cost-benefit kinds of things. DIBOL > wasn't really making enough money to justify the cost of porting it to > compete with DBL, which was a "better" DIBOL. > > So, once DISC bought out Softbol and DEC handed them the Alpha, DISC > had a monopoly on the language. I think that fact more than any other > ticked some people off and caused them to bail. > > > > > > Someone only familiar with DEC DIBOL should not harshly judge > > > Synery/ DE (the modern name) by that standard any more than someone > > > who hasn't used VMS since early VAX should prejudge todays VMS by > > > that experience. > > > "harshly judge"? Who's doing that? > > My mistake. > > > > > > > > Beyond setting up the user environment as needed with any platform > > > change, moving from DIBOL to the Synergy product on VMS usually > > > involves little more than compile, rebuild your libraries and link > > > your apps. Then, you can play with all of the fancy new stuff > > > (Synergex offers training, too.) > > > With the move of some other code from DIBOL to DBL, there were a number > > of things that didn't just compile. I remember one item was the > > DISPLAY statements which didn't work with field attributes. Also, the > > SLICE subroutine that was included in DIBOL was absent in DBL. > > Strangely, some other programmer put in some conditional compilation > > statements to avoid calling it under DBL. When I found it later, I > > just wrote a SLICE subroutine to accomplish the task. (It was only a > > few lines of code.) > > The screen attributes were something I'd forgotten about. All of our > screen I/O was done (or was *supposed* to be done:-) in subroutines, > though, and those were simple to convert. The compiler uncovered the > few "stragglers" and that forced us to clean things up. Not even a > days worth of work if I recall. > > I don't recall ever using SLICE so that was not a problem. ISTR, now > that you've mentioned those, there were a few other minor differences > that were easy to fix or just needed a DBLOPT setting. We'd probably > done most of the work when we took the code to TSX, which was before > we ever saw a VAX. > > > > > > We still have some apps running today that started life on > > > CTS-300/500, then met DBL on TSX+, and moved to VAX and Alpha with > > > little more effort than that. And, don't overlook the DIBOL features > > > you take for granted, like the built-in understanding and support of > > > RMS records/files and the convenience of the Message Manager, that > > > you'll need to "bolt-on" to most other languages. > > > We had a customer who used TSX+ and DBL. We also had one on RSTS (I > > think) in which we had to carefully craft the linking of the code > > because of 32K code segments. > > Overlays. Yuck. Bad memories. The need for linking overlays was one of > the reasons our code was so modular, though, and that made many things > easier to port. Our code was no where near as "modular" (if that's the > word) as the MCBA stuff, though. Their code was hard to deal with, and > we inherited a few of their abandoned sites to support. Most we > converted to our stuff for near-cost just to get away from maintaining > that ####. Some we lost to merger or acquisition, but some of those > sites are still around today running on VMS (not exactly using the > same old code, though:-) > > > We definite use the Message Manager. I hadn't really considered that. > > To address that use, I guess I'd have to write a replacement. Yikes, > > that sounds like a whole lot more work. > > SO many things we've come to take for granted;-) > > > > > > Like HVW said, too, DBL can move to non-VMS platforms easier than > > > most languages. If your stuff is overly hard-coded with VMS > > > specifics then that would be a handicap for other languages, too. > > > But, even if it is, DBL might have a built-in subroutine or function > > > that you could use instead without having to reinvent your own or > > > find a third-party substitute. > > > If the goal was to change platforms, I would prefer to not carry the > > old code along. I'd rather just look at the old functionality and > > write from scratch. > > More fun. Much more time. Much more $$$. > > > > > > > > On non-RMS platforms, DBL has a built-in file/record system that to > > > the programmer looks pretty much like RMS (even has RFA's.) We > > > ported an entire accounting system to Windows in only a few weeks. > > > All of the data files were stripped to sequential, copied over, and > > > we used their utilities to reload them. The first time we did this > > > we were amazed at how easy it was. It isn't 100% simple, but it's > > > 99.99% easier than converting that much code to any other language I > > > know of. > > > > Porting everything to a new language sounds like a programmers idea > > > of fun, but what's it really going to cost the business? > > > I'm not sure I'd call it fun, but it is an excuse to create what I > > would consider better code, exchanging cryptic variable name for one > > with clear meaning, moving away from the idea that a particular > > variable has to be used for completely different purposes, just to save > > memory, allowing the applications to make use of the full size of > > screen when terminals (emulators) have move than 24 rows and/or 80 > > columns, etc. > > Cleaning up variable names and spaghetti code and such might be good, > and porting to a different language will mean finding new ways to do > some things anyway. The temptation to "fix" or "improve" too many > things, though, means going "off-script." Debugging gets more > difficult because the new stuff no longer follows the old flow and if > something doesn't work you have to determine if the bug was in the > original logic and has now decided to surface, or was caused by an > "improvement." Been there. I've had better results porting the logic > "feature for feature," noting where I'd make any significant changes, > making allowances in the code and implementing them after the new code > has been tested and proven sound. Each to his own, though:-) > > I've become so accustomed to the power of DBL that using any other > language for business apps seems painful, so I guess I am a bit biased. > 8^O I've seen a number of companies attempt to rewrite a large application in another language. Very few of them have succeeded, because it's nearly impossible to define all of the requirements for such an application. Most of what the application has to do right has been forgotten, and many of its requirements were never really understood to begin with. The project looks simple at first, but two years into it without anything you can actually use gives one pause. ------------------------------ Date: Thu, 14 Feb 2008 15:55:20 -0500 From: "Richard B. Gilbert" Subject: Re: DIBOL to Message-ID: <47B4AAB8.8000508@comcast.net> Chip Camden wrote: > On Feb 13, 3:26 pm, Doug Phillips wrote: > >>On Feb 13, 3:32 pm, Tad Winters >> >> wrote: >> >>>Doug Phillips wrote innews:95285ad2-9ac4-4042-9049-b1ad7fb654f4@d70g2000hsb.googlegroups.com: >> >>>>On Feb 12, 6:33 pm, Tad Winters >>>> wrote: >>>> >>>>>It seems like DIBOL was quite a good language. Why did Digital >>>>>drop it with the move to Alpha? >>>> >>>>To echo Hank Vander Waal, DBL is DIBOL for the post-VAX era. At the >>>>time of the Alpha port, Synergex (or was it still DISC then?) had >>> >>>It was still DISC. >> >>That's what I thought, but I didn't look it up. >> >> >> >> >>>>extended DBL to a higher level, while still keeping DIBOL >>>>compatibility, and they were going to port DBL to Alpha anyway. DEC >>>>likely decided that their own resources would be better utilized in >>>>other areas. >>> >>>So they decided that it was better to give someone else the business >>>rather than compete. That's an interesting way to do business. >> >>Yea, bean-counters tend to look at cost-benefit kinds of things. DIBOL >>wasn't really making enough money to justify the cost of porting it to >>compete with DBL, which was a "better" DIBOL. >> >>So, once DISC bought out Softbol and DEC handed them the Alpha, DISC >>had a monopoly on the language. I think that fact more than any other >>ticked some people off and caused them to bail. >> >> >> >> >>>>Someone only familiar with DEC DIBOL should not harshly judge >>>>Synery/ DE (the modern name) by that standard any more than someone >>>>who hasn't used VMS since early VAX should prejudge todays VMS by >>>>that experience. >>> >>>"harshly judge"? Who's doing that? >> >>My mistake. >> >> >> >> >> >> >>>>Beyond setting up the user environment as needed with any platform >>>>change, moving from DIBOL to the Synergy product on VMS usually >>>>involves little more than compile, rebuild your libraries and link >>>>your apps. Then, you can play with all of the fancy new stuff >>>>(Synergex offers training, too.) >>> >>>With the move of some other code from DIBOL to DBL, there were a number >>>of things that didn't just compile. I remember one item was the >>>DISPLAY statements which didn't work with field attributes. Also, the >>>SLICE subroutine that was included in DIBOL was absent in DBL. >>>Strangely, some other programmer put in some conditional compilation >>>statements to avoid calling it under DBL. When I found it later, I >>>just wrote a SLICE subroutine to accomplish the task. (It was only a >>>few lines of code.) >> >>The screen attributes were something I'd forgotten about. All of our >>screen I/O was done (or was *supposed* to be done:-) in subroutines, >>though, and those were simple to convert. The compiler uncovered the >>few "stragglers" and that forced us to clean things up. Not even a >>days worth of work if I recall. >> >>I don't recall ever using SLICE so that was not a problem. ISTR, now >>that you've mentioned those, there were a few other minor differences >>that were easy to fix or just needed a DBLOPT setting. We'd probably >>done most of the work when we took the code to TSX, which was before >>we ever saw a VAX. >> >> >> >> >>>>We still have some apps running today that started life on >>>>CTS-300/500, then met DBL on TSX+, and moved to VAX and Alpha with >>>>little more effort than that. And, don't overlook the DIBOL features >>>>you take for granted, like the built-in understanding and support of >>>>RMS records/files and the convenience of the Message Manager, that >>>>you'll need to "bolt-on" to most other languages. >>> >>>We had a customer who used TSX+ and DBL. We also had one on RSTS (I >>>think) in which we had to carefully craft the linking of the code >>>because of 32K code segments. >> >>Overlays. Yuck. Bad memories. The need for linking overlays was one of >>the reasons our code was so modular, though, and that made many things >>easier to port. Our code was no where near as "modular" (if that's the >>word) as the MCBA stuff, though. Their code was hard to deal with, and >>we inherited a few of their abandoned sites to support. Most we >>converted to our stuff for near-cost just to get away from maintaining >>that ####. Some we lost to merger or acquisition, but some of those >>sites are still around today running on VMS (not exactly using the >>same old code, though:-) >> >> >>>We definite use the Message Manager. I hadn't really considered that. >>>To address that use, I guess I'd have to write a replacement. Yikes, >>>that sounds like a whole lot more work. >> >>SO many things we've come to take for granted;-) >> >> >> >> >>>>Like HVW said, too, DBL can move to non-VMS platforms easier than >>>>most languages. If your stuff is overly hard-coded with VMS >>>>specifics then that would be a handicap for other languages, too. >>>>But, even if it is, DBL might have a built-in subroutine or function >>>>that you could use instead without having to reinvent your own or >>>>find a third-party substitute. >>> >>>If the goal was to change platforms, I would prefer to not carry the >>>old code along. I'd rather just look at the old functionality and >>>write from scratch. >> >>More fun. Much more time. Much more $$$. >> >> >> >> >> >> >>>>On non-RMS platforms, DBL has a built-in file/record system that to >>>>the programmer looks pretty much like RMS (even has RFA's.) We >>>>ported an entire accounting system to Windows in only a few weeks. >>>>All of the data files were stripped to sequential, copied over, and >>>>we used their utilities to reload them. The first time we did this >>>>we were amazed at how easy it was. It isn't 100% simple, but it's >>>>99.99% easier than converting that much code to any other language I >>>>know of. >>> >>>>Porting everything to a new language sounds like a programmers idea >>>>of fun, but what's it really going to cost the business? >>> >>>I'm not sure I'd call it fun, but it is an excuse to create what I >>>would consider better code, exchanging cryptic variable name for one >>>with clear meaning, moving away from the idea that a particular >>>variable has to be used for completely different purposes, just to save >>>memory, allowing the applications to make use of the full size of >>>screen when terminals (emulators) have move than 24 rows and/or 80 >>>columns, etc. >> >>Cleaning up variable names and spaghetti code and such might be good, >>and porting to a different language will mean finding new ways to do >>some things anyway. The temptation to "fix" or "improve" too many >>things, though, means going "off-script." Debugging gets more >>difficult because the new stuff no longer follows the old flow and if >>something doesn't work you have to determine if the bug was in the >>original logic and has now decided to surface, or was caused by an >>"improvement." Been there. I've had better results porting the logic >>"feature for feature," noting where I'd make any significant changes, >>making allowances in the code and implementing them after the new code >>has been tested and proven sound. Each to his own, though:-) >> >>I've become so accustomed to the power of DBL that using any other >>language for business apps seems painful, so I guess I am a bit biased. >>8^O > > > I've seen a number of companies attempt to rewrite a large application > in another language. Very few of them have succeeded, because it's > nearly impossible to define all of the requirements for such an > application. Most of what the application has to do right has been > forgotten, and many of its requirements were never really understood > to begin with. The project looks simple at first, but two years into > it without anything you can actually use gives one pause. This sounds, to me, like a failure to generate and/or retain and maintain the necessary documentation for the application. Throughout its lifetime an application will require both corrective and adaptive maintenance. The corrective part fixes what was wrong to begin with. The adaptive part copes with changes in the external world; e.g. the rules for sales tax changed or the company decides to accept payment via credit card. This can be extremely difficult if no one knows exactly what the application is supposed to do and/or not do. Without documentation this maintenance can be extremely expensive. A programmer who knows the application from A to Z does not constitute documentation! He can forget, he can accept other employment and then what do you do? If well done, this documentation should allow a team of competent people to rewrite the application in the same or any other suitable language. My reading over the last forty years or so suggests that the lack of such documentation is a perennial problemm. It ain't going to get done unless someone is assigned the task of writing it and is held responsible for it. Ditto for maintenance of the documentation. It's one of those things that costs you X dollars now or X^3 dollars when you need it and don't have it. (X^3 may be a drastic underestimate!) ------------------------------ Date: Thu, 14 Feb 2008 13:53:59 -0800 (PST) From: Doug Phillips Subject: Re: DIBOL to Message-ID: <20a9cb6b-ebce-42e3-a6b1-fda581d15fbf@s13g2000prd.googlegroups.com> On Feb 14, 1:52 pm, Chip Camden wrote: > On Feb 13, 3:26 pm, Doug Phillips wrote: > > On Feb 13, 3:32 pm, Tad Winters > > wrote: > > > Doug Phillips wrote innews:95285ad2-9ac4-4042-9049-b1ad7fb654f4@d70g2000hsb.googlegroups.com: > > > > If the goal was to change platforms, I would prefer to not carry the > > > old code along. I'd rather just look at the old functionality and > > > write from scratch. > > > More fun. Much more time. Much more $$$. > > > > > On non-RMS platforms, DBL has a built-in file/record system that to > > > > the programmer looks pretty much like RMS (even has RFA's.) We > > > > ported an entire accounting system to Windows in only a few weeks. > > > > All of the data files were stripped to sequential, copied over, and > > > > we used their utilities to reload them. The first time we did this > > > > we were amazed at how easy it was. It isn't 100% simple, but it's > > > > 99.99% easier than converting that much code to any other language I > > > > know of. > > > > > Porting everything to a new language sounds like a programmers idea > > > > of fun, but what's it really going to cost the business? > > > > I'm not sure I'd call it fun, but it is an excuse to create what I > > > would consider better code, exchanging cryptic variable name for one > > > with clear meaning, moving away from the idea that a particular > > > variable has to be used for completely different purposes, just to save > > > memory, allowing the applications to make use of the full size of > > > screen when terminals (emulators) have move than 24 rows and/or 80 > > > columns, etc. > > > Cleaning up variable names and spaghetti code and such might be good, > > and porting to a different language will mean finding new ways to do > > some things anyway. The temptation to "fix" or "improve" too many > > things, though, means going "off-script." Debugging gets more > > difficult because the new stuff no longer follows the old flow and if > > something doesn't work you have to determine if the bug was in the > > original logic and has now decided to surface, or was caused by an > > "improvement." Been there. I've had better results porting the logic > > "feature for feature," noting where I'd make any significant changes, > > making allowances in the code and implementing them after the new code > > has been tested and proven sound. Each to his own, though:-) > > > I've become so accustomed to the power of DBL that using any other > > language for business apps seems painful, so I guess I am a bit biased. > > 8^O > > I've seen a number of companies attempt to rewrite a large application > in another language. Very few of them have succeeded, because it's > nearly impossible to define all of the requirements for such an > application. Most of what the application has to do right has been > forgotten, and many of its requirements were never really understood > to begin with. The project looks simple at first, but two years into > it without anything you can actually use gives one pause. Boy, you leave the door open and you never know who'll show up;-) Nice to see your name pop-up here, Chip. Having been on all sides of the "port vs. rewrite" problem myself, I agree with you 100%. Taking the OP's 300k+ lines of DIBOL code to any other language could be a monumental task. The project analysis and tool development phases alone could eat up months (at what cost/per?) if it's done properly. When faced with the problem of replacing an old platform many companies choose option 3: Buy packaged software and live with the differences. If there are a *few* vital functions missing, which sometimes don't get noticed until it's too late, then those might be ported/rewritten and bolted-on or interfaced in some manner; usually for a premium price. And, a company that's been used to getting their programs tweaked here and there on a monthly basis or whenever they need might be very surprised by the answer they get the first time they ask for "a little change." Staying with perfectly good software that's doing everything you need is almost always the most cost-effective choice, regardless of the initial licensing costs. At least that cost is *known* and quantifiable. And, moving to Synergy/DE gives the company a whole new world of possibilities for their future -- assuming they care about their future. Porting an entire suite of business app's to a new language almost always proves to be a more expensive choice, and buying it canned is usually there fighting for the top. ------------------------------ Date: Thu, 14 Feb 2008 15:51:49 -0800 (PST) From: ultradwc@gmail.com Subject: Re: DIBOL to Message-ID: <2813dffd-597d-4092-920b-3030ccbcdb04@e25g2000prg.googlegroups.com> On Feb 14, 1:49=A0am, Tad Winters wrote: > ultra...@gmail.com wrote innews:918112b7-97c1-452a-9585-1e11e2a9589d@s13g2= 000prd.googlegroups.com: > > > > > > > On Feb 13, 7:49=A0pm, Tad Winters > > wrote: > >> Doug Phillips wrote > >> innews:eebcffae-f4a5-4df2-b84e-7a213c405caf@s12g2000prg.googlegroups > >> .com: > > >> =A0[..snip..] > > >> > I've become so accustomed to the power of DBL that using any > >> > other language for business apps seems painful, so I guess I am a > >> > bit biased. 8^O > > >> So you're still coding in DBL? =A0If I could find some more companies > >> in my area in need of someone to maintain their DBL code, I'd be > >> pretty happy. =A0 The 2 companies I do occasional work for right now > >> just ask for minor changes or minor new features. =A0The last "large" > >> projects were implementing faxing of invoices (a failure since they > >> counted on using a VOIP line), emailing invoices (CSV file created > >> and transferred to a *nix box at an ISP to be converted to PDF), > >> and parsing a tab delimited file, received via ftp from an ISP > >> hosted web server, into an order. > > > goldfax and dibol work together quite well ... T1s fail as well as > > other > > IP based solutions, but good old copper lines are solid for fax > > uptime ... > > I suggested looking at other faxing software before the project > started, but the lead said he wanted to stick with what he'd used > before. > > > why not run their own web server? =A0purveyor/wasd and dibol/dcl as > > script languages work terrific ... > > The system is already overloaded. > > > txt2pdf runs under perl on vms ... they could create their own pdfs > > on vms and send them out as attachments with pmdf ... and vms > > makes the perfect mail server with precisemail antispam and sophos > > antivirus along with Mark Daniels soymail webmail freeware ... > > I looked into txt2pdf and wanted to use it, but I couldn't get them to > make the necessary changes with their ISP, i.e. MX record for their IP > address, DNS IP addresses for the VMS system to do lookups for sending > email and preferably letting the VMS system do zone transfers (to be a > secondary.) > PMDF would be more software on an already overloaded system, more > money, and would require them to open port 25 on their firewall. =A0Since > they're managing the firewall themselves, I don't think I could get > them to do it. =A0Also, anti-spam would be more load and more money. > > > sounds like they need to hire a dibol/vms person full time to > > put everything under their own roof ... letting your business > > be run by other companies is a bad situation ... > > Once again, more money. =A0Someone else mentioned they must not be > spending enough, based on what their revenues must be for having 150 > concurrent users. =A0I don't know what their revenues are, though I could > look, since I have access to their system, but it's not my business. =A0 > If I really need to know, I'll ask. =A0If it's only to tell them they're > not spending enough, then it's just as easy to tell them what is called > for in the industry. > > > > > vms does not get viruses or trojans or hacked either ... > > they are on the perfect os to do everything in house > > inexpensively ... why are they not taking advantage > > of it ...- Hide quoted text - > > - Show quoted text -- Hide quoted text - > > - Show quoted text - hey, I just got an email today from synergy ... they are having a 2008 promotional license cost reduction ... now is the time to talk with them ... ------------------------------ Date: Thu, 14 Feb 2008 12:50:08 -0800 (PST) From: tadamsmar Subject: Does dism/unload spin down a disk? Message-ID: <2248d527-676b-4f72-96aa-dd797a45a596@h11g2000prf.googlegroups.com> I have a noisy disk in a shadows set and I a trying to figure out which one. Is there a vms command that will spin down a disk? I know I can physically pull each one out, but I was looking for an easier way. ------------------------------ Date: 14 Feb 2008 16:06:34 -0600 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: Does dism/unload spin down a disk? Message-ID: In article <2248d527-676b-4f72-96aa-dd797a45a596@h11g2000prf.googlegroups.com>, tadamsmar writes: > I have a noisy disk in a shadows set and I a trying to figure out > which one. > > Is there a vms command that will spin down a disk? Yes for RA disks, but not for newer disks like SCSI. ------------------------------ Date: Thu, 14 Feb 2008 22:56:23 GMT From: John Santos Subject: Re: Does dism/unload spin down a disk? Message-ID: In article , Kilgallen@SpamCop.net says... > In article <2248d527-676b-4f72-96aa-dd797a45a596@h11g2000prf.googlegroups.com>, tadamsmar writes: > > I have a noisy disk in a shadows set and I a trying to figure out > > which one. > > > > Is there a vms command that will spin down a disk? > > Yes for RA disks, but not for newer disks like SCSI. > I've always thought a stethoscope would be a useful diagnostic tool for computers, but have never actually tried it. Know any doctors? I think they get them for free as perks from drug and medical equipment companies. -- John ------------------------------ Date: Thu, 14 Feb 2008 21:01:17 -0500 From: "Richard B. Gilbert" Subject: Re: Does dism/unload spin down a disk? Message-ID: <47B4F26D.1090500@comcast.net> John Santos wrote: > In article , > Kilgallen@SpamCop.net says... > >>In article <2248d527-676b-4f72-96aa-dd797a45a596@h11g2000prf.googlegroups.com>, tadamsmar writes: >> >>>I have a noisy disk in a shadows set and I a trying to figure out >>>which one. >>> >>>Is there a vms command that will spin down a disk? >> >>Yes for RA disks, but not for newer disks like SCSI. >> > > > I've always thought a stethoscope would be a useful diagnostic > tool for computers, but have never actually tried it. > > Know any doctors? I think they get them for free as > perks from drug and medical equipment companies. > > You can buy a stethoscope if you really want one. I have one and a blood pressure cuff to go with it. If your local drug store can't fix you up, check for a medical supply company. I think you can get a stethoscope and a BP cuff for $20-$30. I don't know what a stethoscope would tell you about a computer that your unaided senses could not. You can see if the fans are moving and feel the air flow. The disk drive is the only other thing that would make noise and most of them are fairly quiet. The only really likely failure modes in a disk drive are head crash, motor failure, and bearing failure. If the disk drive is not working, it's generally obvious even if the exact cause is not. Modern hardware will generally last long after you are no longer willing to admit that you still own and use it! ------------------------------ Date: Fri, 15 Feb 2008 02:45:23 GMT From: John Santos Subject: Re: Does dism/unload spin down a disk? Message-ID: <717tj.635$Cs.496@trnddc04> Richard B. Gilbert wrote: > John Santos wrote: > >> In article , >> Kilgallen@SpamCop.net says... >> >>> In article >>> <2248d527-676b-4f72-96aa-dd797a45a596@h11g2000prf.googlegroups.com>, >>> tadamsmar writes: >>> >>>> I have a noisy disk in a shadows set and I a trying to figure out >>>> which one. >>>> >>>> Is there a vms command that will spin down a disk? >>> >>> >>> Yes for RA disks, but not for newer disks like SCSI. >>> >> >> >> I've always thought a stethoscope would be a useful diagnostic >> tool for computers, but have never actually tried it. >> >> Know any doctors? I think they get them for free as >> perks from drug and medical equipment companies. >> >> > > You can buy a stethoscope if you really want one. I have one and a > blood pressure cuff to go with it. If your local drug store can't fix > you up, check for a medical supply company. I think you can get a > stethoscope and a BP cuff for $20-$30. > > I don't know what a stethoscope would tell you about a computer that > your unaided senses could not. You can see if the fans are moving and > feel the air flow. The disk drive is the only other thing that would > make noise and most of them are fairly quiet. The only really likely > failure modes in a disk drive are head crash, motor failure, and bearing > failure. If the disk drive is not working, it's generally obvious even > if the exact cause is not. Modern hardware will generally last long > after you are no longer willing to admit that you still own and use it! > Noisy bearings, fans, disks that are still working but about to die. Lots of equipment can't be opened up without powering it down first. The OP has one noisy and possibly dying disk in a rack, can't tell which one. A stethoscope doesn't really amplify anything, it isolates the source. Oh, and actually, old hardware tends to last longer than modern hardware. (At least, old DEC hardware. Most of it was massively over-engineered.) New hardware seems mostly better about exposing common failures and easier to repair, though. Things like external hot-swappable fans and power supplies. The "locate" function on HSx's and MSA's, etc. However, ever tried to repair a modern disk drive? :-) -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: Thu, 14 Feb 2008 22:09:04 -0500 From: "Richard B. Gilbert" Subject: Re: Does dism/unload spin down a disk? Message-ID: <47B50250.10208@comcast.net> John Santos wrote: > Richard B. Gilbert wrote: > >> John Santos wrote: >> >>> In article , >>> Kilgallen@SpamCop.net says... >>> >>>> In article >>>> <2248d527-676b-4f72-96aa-dd797a45a596@h11g2000prf.googlegroups.com>, >>>> tadamsmar writes: >>>> >>>>> I have a noisy disk in a shadows set and I a trying to figure out >>>>> which one. >>>>> >>>>> Is there a vms command that will spin down a disk? >>>> >>>> >>>> >>>> Yes for RA disks, but not for newer disks like SCSI. >>>> >>> >>> >>> I've always thought a stethoscope would be a useful diagnostic >>> tool for computers, but have never actually tried it. >>> >>> Know any doctors? I think they get them for free as >>> perks from drug and medical equipment companies. >>> >>> >> >> You can buy a stethoscope if you really want one. I have one and a >> blood pressure cuff to go with it. If your local drug store can't fix >> you up, check for a medical supply company. I think you can get a >> stethoscope and a BP cuff for $20-$30. >> >> I don't know what a stethoscope would tell you about a computer that >> your unaided senses could not. You can see if the fans are moving and >> feel the air flow. The disk drive is the only other thing that would >> make noise and most of them are fairly quiet. The only really likely >> failure modes in a disk drive are head crash, motor failure, and >> bearing failure. If the disk drive is not working, it's generally >> obvious even if the exact cause is not. Modern hardware will >> generally last long after you are no longer willing to admit that you >> still own and use it! >> > > Noisy bearings, fans, disks that are still working but about to die. > > Lots of equipment can't be opened up without powering it down first. > > The OP has one noisy and possibly dying disk in a rack, can't tell > which one. A stethoscope doesn't really amplify anything, it isolates > the source. > > Oh, and actually, old hardware tends to last longer than modern > hardware. (At least, old DEC hardware. Most of it was massively > over-engineered.) New hardware seems mostly better about exposing > common failures and easier to repair, though. Things like external > hot-swappable fans and power supplies. The "locate" function on > HSx's and MSA's, etc. However, ever tried to repair a modern disk > drive? :-) > Nope! The last time I "repaired" a disk drive I "fixed" a non-working RA81 by installing a circuit board from another non-working RA81. A miracle occurred! As I recall, I had a little help from Stu Fuller who was kind enough to suggest which board needed replacement. This was ca. 1993! Modern drives, if they're out of warranty, you just drop them in the garbage and buy another one. With 80 GB EIDE drives selling for $70 US, there's no point in trying to repair one! If they're SCSI drives you put them on service contract for $2/month but usually the drives last longer than you want to use them with or without service contract. If a modern SCSI drive survives its first 90 days, it's probably good for five years or more. ------------------------------ Date: Thu, 14 Feb 2008 23:25:42 -0600 From: Chris Scheers Subject: Re: Does dism/unload spin down a disk? Message-ID: <61km2jF1vmmqeU1@mid.individual.net> John Santos wrote: > In article , > Kilgallen@SpamCop.net says... >> In article <2248d527-676b-4f72-96aa-dd797a45a596@h11g2000prf.googlegroups.com>, tadamsmar writes: >>> I have a noisy disk in a shadows set and I a trying to figure out >>> which one. >>> >>> Is there a vms command that will spin down a disk? >> Yes for RA disks, but not for newer disks like SCSI. >> > > I've always thought a stethoscope would be a useful diagnostic > tool for computers, but have never actually tried it. > > Know any doctors? I think they get them for free as > perks from drug and medical equipment companies. Go to an auto parts store and get a mechanics stethoscope. It has a long thin rod on the end. You touch the tip of the rod to various bits of equipment to listen for bad bearings. -- ----------------------------------------------------------------------- Chris Scheers, Applied Synergy, Inc. Voice: 817-237-3360 Internet: chris@applied-synergy.com Fax: 817-237-3074 ------------------------------ Date: Thu, 14 Feb 2008 16:09:45 -0800 (PST) From: Sue Subject: Re: HP OpenVMS Tele-Marketing?!? Message-ID: <9eae9caa-412b-418a-b80d-741fc5a82d59@i29g2000prf.googlegroups.com> On Feb 14, 12:01=A0pm, "johnhreinha...@yahoo.com" wrote: > I just got an interesting call. =A0It was a young man wanting to talk to > me about my server situation since I had requested a copy of the > OpenVMS 30th Anniversary CD. =A0I was so shocked I didn't talk to him > long enough to find out if he was trying to sell me more OpenVMS gear > or migrate me away. =A0I was sorry to have to tell him that I'm merely a > hobbyist and all my servers came from Ebay rather than HP. > > Maybe one of you will get a call too and have more presence of mind to > find out what's up. > > =A0 John H. Reinhardt Dear folks, Please don't be surprised, we really do care about you and in my opinion more and more folks can see how important you are. sue ------------------------------ Date: Thu, 14 Feb 2008 17:27:41 -0600 (CST) From: sms@antinode.org (Steven M. Schweda) Subject: Re: ODS5, /NAMES = AS_IS, LIBRARY, MMS v. me Message-ID: <08021417274108_206420A4@antinode.org> From: "Craig A. Berry" > > ALP $ mmk > > LIBRARY/REPLACE LIBRARY.OLB LOWER.OBJ > > %MMK-I-ACTNOUPD, action did not update target LIBRARY.OLB(LOWER=3DLOWER.OB= > J) > > Done. > > > > File names are one thing, library module names are another. > > True, but I thought the problem was that the librarian derives the > module name from the source file name as seen by the compiler. If MMK > upcases all its tokens (which I think it does), then it just might > present upper case source file names to the compiler which just might > create library modules with upper case names. No, I haven't tried any > of this. The librarian doesn't derive anything. It takes the module name from (inside) the object file. The compiler puts it there, and, as already shown, it uses the file name, not anything on its command line. From: sms@antinode.org (Steven M. Schweda) > [...] (Adding a "#pragma module" directive to every source file is not > practical. [...]) From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) > OK, this is a little less off the top, but needs to be converted > from a .com file to MMS directives. > [...] Well, ok. I suppose that that counts as clever. Thanks, I guess. I don't like it much, but, with one notable exception, it can be made to work. My current edition looks something like this: C.OBJ : temp_name = "[.$(DEST)]module_name_"+ f$getjpi( "", "PID")+ ".tmp" module = f$parse( "$(MMS$TARGET_NAME)", , , "NAME", "SYNTAX_ONLY") module = f$edit( module, "UPCASE") ! Currently superfluous. open /write temp_file 'temp_name' write temp_file "#pragma module ''module'" close temp_file $(CC) $(CFLAGS) 'temp_name'+ $(MMS$SOURCE) delete 'temp_name';* Note that $(MMS$TARGET_NAME) seems to be up-cased, which may or may not make sense. Interestingly, while the compiler is allowed to set a module name to "VMS", I, apparently, am not: CC /decc /prefix = (all) /names = as_is /include = ([], [.VMS]) /object = [. ALPHAL]VMS.OBJ /define = (VMS , _LARGEFILE ) 'temp_name'+ [.VMS]VMS.C #pragma module VMS ..............^ %CC-W-BADMODULEID, Invalid identifier found immediately following "#pragma modul e" or "#module" directive. at line number 1 in file ALP$DKA100:[UTILITY.SOURCE.mtools.mtools-3_9_11a.ALPHAL ]module_name_f20656EC7.tmp;1 %MMS-F-ABORT, For target [.ALPHAL]VMS.OBJ, CLI returned abort status: %X10B91260 . On an ODS2 disk, without the fancy #pragma directive, no one ever complained about an implicit module name of "VMS": ALP $ pipe anal /obje VMS.OBJ | sear sys$input "module name" module name: "VMS" Smells like a (stink-)bug to me. Who'll defend it? ALP $ cc /vers HP C V7.3-009 on OpenVMS Alpha V7.3-2 IT $ cc /vers HP C V7.3-018 on OpenVMS IA64 V8.3-1H1 (Presumably true for a long time.) ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Thu, 14 Feb 2008 19:17:41 GMT From: Rob Brown Subject: OT Richard Dawkins on slavery Message-ID: On Fri, 15 Feb 2008, Mark Daniel wrote: > ... > we don't approve of slavery or discrimination on the grounds of race > or sex, ... > [Richard Dawkins; quoted in Natalie Angier, "Confessions of a Lonely > Atheist," New York Times Magazine] It seems to me that this says that Richard Dawkins says he (or we, but surely he is a subset of we) approves of slavery on grounds other than race or sex. -- Rob Brown b r o w n a t g m c l d o t c o m G. Michaels Consulting Ltd. (780)438-9343 (voice) Edmonton (780)437-3367 (FAX) http://gmcl.com/ ------------------------------ Date: Thu, 14 Feb 2008 16:03:24 -0500 From: norm.raphael@metso.com Subject: Re: OT Richard Dawkins on slavery Message-ID: This is a multipart message in MIME format. --=_alternative 0073A756852573EF_= Content-Type: text/plain; charset="US-ASCII" Rob Brown wrote on 02/14/2008 02:17:41 PM: > On Fri, 15 Feb 2008, Mark Daniel wrote: > > > ... *> > we don't (approve of slavery) or ([approve of] discrimination on the grounds of race *> > or sex,) ... > > [Richard Dawkins; quoted in Natalie Angier, "Confessions of a Lonely > > Atheist," New York Times Magazine] > > It seems to me that this says that Richard Dawkins says he (or we, but > surely he is a subset of we) approves of slavery on grounds other than > race or sex. > > The problem is expression in English, not expression of the sentiment. > -- > > Rob Brown b r o w n a t g m c l d o t c o m > G. Michaels Consulting Ltd. (780)438-9343 (voice) > Edmonton (780)437-3367 (FAX) > http://gmcl.com/ > --=_alternative 0073A756852573EF_= Content-Type: text/html; charset="US-ASCII"



Rob Brown <mylastname@gmcl.com> wrote on 02/14/2008 02:17:41 PM:

> On Fri, 15 Feb 2008, Mark Daniel wrote:
>
> > ...

*> > we don't (approve of slavery) or ([approve of] discrimination on the grounds of race
*> > or sex,) ...

> > [Richard Dawkins; quoted in Natalie Angier, "Confessions of a Lonely
> > Atheist," New York Times Magazine]
>
> It seems to me that this says that Richard Dawkins says he (or we, but
> surely he is a subset of we) approves of slavery on grounds other than
> race or sex.
>
>

The problem is expression in English, not expression of the sentiment.
> --
>
> Rob Brown                        b r o w n a t g m c l d o t c o m
> G. Michaels Consulting Ltd.      (780)438-9343 (voice)
> Edmonton                         (780)437-3367 (FAX)
>                                   http://gmcl.com/
>
--=_alternative 0073A756852573EF_=-- ------------------------------ Date: Thu, 14 Feb 2008 22:54:09 GMT From: John Santos Subject: Re: OT Richard Dawkins on slavery Message-ID: In article , mylastname@gmcl.com says... > On Fri, 15 Feb 2008, Mark Daniel wrote: > > > ... > > we don't approve of slavery or discrimination on the grounds of race > > or sex, ... > > [Richard Dawkins; quoted in Natalie Angier, "Confessions of a Lonely > > Atheist," New York Times Magazine] > > It seems to me that this says that Richard Dawkins says he (or we, but > surely he is a subset of we) approves of slavery on grounds other than > race or sex. > > > No, "or" has a lower operator precedence than "on", so if you want to say that, you have to use parentheses, I.e. "... approve of (slavery or discrimination) on the grounds of ..." HTH. -- John ------------------------------ Date: Thu, 14 Feb 2008 17:35:21 -0800 From: "Tom Linden" Subject: Re: SPAM detection for freeware MX 4.2 Message-ID: On Thu, 14 Feb 2008 06:25:57 -0800, Jan-Erik Söderholm wrote: > Vance Haemmerle wrote: >> Jan-Erik Söderholm wrote: >>> Vance Haemmerle wrote: >>> >>>> I've been using MX 4.2 for almost a decade, with the >>>> latest patches and the Anti-open relay modifications. >>>> Is there anyone else out there still using MX 4.2? >>> >>> >>> Well, yes, I'm "still" using MX 4.2 since installing >>> it about 2 weeks ago... :-) >>> >>> (I have been using the 3.x version(s) about 15 yrs ago, >>> but that's another story.) >>> >>> I'd be intrerested in your changes. >> http://toyvax.glendale.ca.us/www/mx_spam.html >> -- Vance >> > > OK, fine. > I have also fetched the 6.0 kit, so we'll see which way I'll go. > Thanks anyway ! I wonder if there is any difference between 5.4 and 6.0? > > Jan-Erik. > -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Thu, 14 Feb 2008 20:55:01 -0600 From: David J Dachtera Subject: Re: Thank you Message-ID: <47B4FF05.F5C9E12E@spam.comcast.net> Sue wrote: > > Dear Newsgroup, > > I just wanted to say "Thank you". I really appreciate that you are > vocal, loyal and always willing to give me an answer to my questions > and feedback to my requests. > > I know that if you are on my email list that sometimes I send a lot of > email and you don't seem to mind. Please remember that you are > valued. > > I have my own TLA (three letter acronym) which in the UK has a > completely different meaning. But it is GBH, great big hug. > > GBH, > Sue Much thanx to you, Sue, for all you do for the community. David J Dachtera DJE Systems ------------------------------ Date: Fri, 15 Feb 2008 06:09:43 GMT From: Christine Ricketts/Andrew Stewart Subject: Re: The "World's First" MicroVAX II Museum is now Open Message-ID: <47b52ca3$1@news.mel.dft.com.au> Greetings Alon, > After more than a year, which should have taken less than three weeks, > the MicroVAX II museum (or better referred to as "shrine", due to its > size) is now open. [cut] Congratulations from the bloke who helped "force feed" your MicroVAX II obsession in Melbourne, Australia. I'm trying to clean up my factory, AKA the VAX/PDP-11 "dungeon", by trying to give away the boxes of ancient IBM PC s/w I collected many moons ago. Next target is the ancient IBM PC compatible h/w. Hopefully the Grandmas are not spoiling Ori and sibling too much. (can't pop your wife's name off the top of my memory stack!) -- Regards, Andy. 03-9808-9584 AH, 04140-76667 reasonable hours only. If this is an news group posting and you want to email me then substitute "darkstar" and "carringbush" appropriately. "With enough lubrication, we can do anything." Motto of the Mythbuster team. ------------------------------ Date: Fri, 15 Feb 2008 06:52:02 +0800 From: "Richard Maher" Subject: You don't know when you're well-off! Message-ID: Hi, > It is a pity that nobody at HP cares about PHP, that a recent version > has not been released... I've being waiting for IPsec in TCP/IP services (a pre-requisite for claiming full IPv6 support) for an eternity :-( and I guess Java6 is still somewhere over the rainbow? But the good news is RTR is ahead of schedule and PCSI is getting a complete facelift; you guys never had it so good :-( Cheers Richard Maher "palm123" wrote in message news:f34a5c51-3f0e-4afd-9672-cf274970d0b5@37g2000hsl.googlegroups.com... > >>>Why was it left to JFP to do this? Isn't looking after PHP and > MySQL on VMS > enough? > > JFP supports Python and Mysql, not PHP. > > It is a pity that nobody at HP cares about PHP, that a recent version > has not been released... > > Regards ------------------------------ End of INFO-VAX 2008.091 ************************