INFO-VAX Thu, 14 Feb 2008 Volume 2008 : Issue 89 Contents: Re: DIBOL to Re: DIBOL to Re: DIBOL to Re: DIBOL to Re: DIBOL to Re: DIBOL to Re: DIBOL to Re: DIBOL to Re: DIBOL to Re: DIBOL to Re: DIBOL to Re: Dilbert Does Virtualization Re: Dilbert Does Virtualization FORTRAN MicroVAX connection machine question FW: VMS license fees? Re: FW: VMS license fees? Re: ODS5, /NAMES = AS_IS, LIBRARY, MMS v. me Re: ODS5, /NAMES = AS_IS, LIBRARY, MMS v. me Re: ODS5, /NAMES = AS_IS, LIBRARY, MMS v. me Re: The "World's First" MicroVAX II Museum is now Open Re: Unusual mailbox status value Re: Unusual mailbox status value Re: VEST Re: VEST (was: DIBOL to Re: VEST (was: DIBOL to Re: VMS license fees? Re: VMS license fees? Re: VMS license fees? Re: VMS license fees? Re: VMS license fees? Re: VMS license fees? Re: VMS license fees? Re: VMS license fees? Re: VMS license fees? Re: VMS license fees? Re: VMS license fees? Re: VMS license fees? Re: VMS license fees? Re: VMS license fees? ---------------------------------------------------------------------- Date: Wed, 13 Feb 2008 12:01:27 -0800 (PST) From: ultradwc@gmail.com Subject: Re: DIBOL to Message-ID: <5fedc33a-4f05-44db-9c60-56186c2793ac@1g2000hsl.googlegroups.com> On Feb 12, 7:33=A0pm, Tad Winters wrote: > John Reagan wrote innews:fotat3$tf1$1@usenet01.boi.hp= .com: > > > Bob Gezelter wrote: > > >> For porting, it depends on the style of code. If you want > >> integrated (non-custom) support for access to indexed and other > >> files, you are probably limited to BASIC, FORTRAN, and COBOL. It is > >> not inherantly difficult to access keyed files from C/C++, but it > >> will be in the nature of a non-integrated add-in (or in the case of > >> C++, probably a class). > > > Not to divert the topic, but Pascal has just as good support for > > indexed and relative files as the langauges listed above. =A0Well, you > > can't CREATE a file with segmented keys from Pascal without > > resorting to a USERACTION routine, but you can open an existing file > > and even use FINDK to lookup a record. > > It seems like DIBOL was quite a good language. =A0Why did Digital drop it > with the move to Alpha? because of $$$$$$$$$$$$$$$$$$$$$$$$$$$$$ and they was stupid to do so ... the port would have been easy and they lost a lot of business because of it, i.e. MCBA ... DIBOL was a one time license multiple user solution unlike synergy ... now synergy has many more features that takes DIBOL to a whole other level, but those features are not free ... MCBA was responsible for the huge DIBOL market with all their accounting packages and there where many others small companies because of that which began using it to develop other packages such as legal software I used to modify before ... DEC pulled the rug from under them and synergy was unwilling to give them a license break and MCBA ported to cobol and cost DEC a lot of customers ... another stupid move on DECs part ... and DIBOL is superior to cobol, basic, pascal or any other 3GL ... going to those is a step backwards ... ------------------------------ Date: Wed, 13 Feb 2008 12:08:58 -0800 (PST) From: ultradwc@gmail.com Subject: Re: DIBOL to Message-ID: <81ccea98-a31b-49be-b1fa-d3ad6d10e375@i29g2000prf.googlegroups.com> On Feb 13, 1:45=A0pm, Doug Phillips wrote: > On Feb 12, 6:33 pm, Tad Winters > > > > > > wrote: > > John Reagan wrote innews:fotat3$tf1$1@usenet01.boi.= hp.com: > > > > Bob Gezelter wrote: > > > >> For porting, it depends on the style of code. If you want > > >> integrated (non-custom) support for access to indexed and other > > >> files, you are probably limited to BASIC, FORTRAN, and COBOL. It is > > >> not inherantly difficult to access keyed files from C/C++, but it > > >> will be in the nature of a non-integrated add-in (or in the case of > > >> C++, probably a class). > > > > Not to divert the topic, but Pascal has just as good support for > > > indexed and relative files as the langauges listed above. =A0Well, you= > > > can't CREATE a file with segmented keys from Pascal without > > > resorting to a USERACTION routine, but you can open an existing file > > > and even use FINDK to lookup a record. > > > It seems like DIBOL was quite a good language. =A0Why did Digital drop i= t > > 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 > 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. > > 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. > > 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.) > > 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. > > 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. > > 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?- Hide quoted text - > > - Show quoted text - functionality is not the issue ... COST is ... there are many small businesses with vax DIBOL packages from many companies who cannot afford to spend $10,000+ dollars to go to synergy ... and unless synergy gives a price break, they will loose these small customers which is exactly the stupid move DEC made ... call synergy first to try to get a price break, if not look at at vaxstation 4000-96 or vest from vax to alpha ... DO NOT PORT to something else which would cost a lot more money ... solutions exist ... ------------------------------ Date: Wed, 13 Feb 2008 13:22:19 -0800 (PST) From: Doug Phillips Subject: Re: DIBOL to Message-ID: <4f88d281-62bf-4db1-925c-09a80161cc7a@m34g2000hsf.googlegroups.com> On Feb 13, 2:08 pm, ultra...@gmail.com wrote: > On Feb 13, 1:45 pm, Doug Phillips wrote > in response to: > > On Feb 12, 6:33 pm, Tad Winters > > >-snipped- > > > > Porting everything to a new language sounds like a programmers idea of > > fun, but what's it really going to cost the business? > > functionality is not the issue ... COST is ... > How much will it cost to duplicate the functionality? I can't separate the two in my mind. Maybe you can. Like someone who hangs around here is fond of saying: The choices are good, fast and cheap; pick two. > there are many small businesses with vax DIBOL packages > from many companies who cannot afford to spend $10,000+ > dollars to go to synergy An operation with 150 interactive users likely has annual revenue of at least $10M - $20M/year. A company running an old VAX for all of their mission-critical has likely not spent their industry average percentage of income on IT for years, and has become "spoiled." Sometimes reality sucks. > ... and unless synergy gives a price > break, they will loose these small customers which is exactly > the stupid move DEC made ... > > call synergy first to try to get a price break, Or at least get an actual number that could be used for cost analysis. > if not look at > at vaxstation 4000-96 or vest from vax to alpha ... > Both short-sighted choices, IMO, if the future is of any concern. The old saw "penny wise and pound foolish" comes to mind. > DO NOT PORT to something else which would cost a lot > more money ... If cost is the only factor, or the company doesn't expect to be around for long, then they shouldn't do much of anything. If things are working fine except for a few high-load times, then some job rescheduling might be enough. > solutions exist ... and it's usually better to pick a good one. ------------------------------ Date: Wed, 13 Feb 2008 21:32:38 GMT From: Tad Winters Subject: Re: DIBOL to Message-ID: Doug Phillips wrote in news: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. > 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. > > 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? > > 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.) > > 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. 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. > > 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. > > 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. ------------------------------ Date: Wed, 13 Feb 2008 13:45:46 -0800 (PST) From: Doug Phillips Subject: Re: DIBOL to Message-ID: On Feb 13, 2:01 pm, ultra...@gmail.com wrote: > On Feb 12, 7:33 pm, Tad Winters > wrote: > > John Reagan wrote innews:fotat3$tf1$1@usenet01.boi.hp.com: > > > > Bob Gezelter wrote: > > > >> For porting, it depends on the style of code. If you want > > >> integrated (non-custom) support for access to indexed and other > > >> files, you are probably limited to BASIC, FORTRAN, and COBOL. It is > > >> not inherantly difficult to access keyed files from C/C++, but it > > >> will be in the nature of a non-integrated add-in (or in the case of > > >> C++, probably a class). > > > > Not to divert the topic, but Pascal has just as good support for > > > indexed and relative files as the langauges listed above. Well, you > > > can't CREATE a file with segmented keys from Pascal without > > > resorting to a USERACTION routine, but you can open an existing file > > > and even use FINDK to lookup a record. > > > It seems like DIBOL was quite a good language. Why did Digital drop it > > with the move to Alpha? > > because of $$$$$$$$$$$$$$$$$$$$$$$$$$$$$ > > and they was stupid to do so ... the port would have been easy > and they lost a lot of business because of it, i.e. MCBA ... > > DIBOL was a one time license multiple user solution unlike > synergy ... now synergy has many more features that takes > DIBOL to a whole other level, but those features are not free ... > > MCBA was responsible for the huge DIBOL market with all > their accounting packages and there where many others > small companies because of that which began using it to > develop other packages such as legal software I used to > modify before ... > > DEC pulled the rug from under them and synergy was unwilling > to give them a license break and MCBA ported to cobol and > cost DEC a lot of customers ... another stupid move on DECs > part ... > If you remember, MCBA was bought out and it was the new owners who tried to force the customer-base to either buy their package or find another solution. That software carried a very high price and many companies bailed rather than cough up the often $100K or so for the "upgrade" to stay with the new owners -- who were known to be, um, less concerned about customer support than one might desire. Near the end, MCBA had a large presence in the DISC/DBL world, maybe even larger than in DEC DIBOL. > and DIBOL is superior to cobol, basic, pascal or any other > 3GL ... going to those is a step backwards ... Well, DBL (Synergy/DE) is, IMO anyway. Actual DIBOL was nice and quite easy to learn and code, but other languages were gaining capabilities that DIBOL didn't have. Synergy/DE, on the other hand, has some really great features that are not "built-in" to most other languages. ------------------------------ Date: Wed, 13 Feb 2008 15:26:36 -0800 (PST) From: Doug Phillips Subject: Re: DIBOL to Message-ID: 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 ------------------------------ Date: Thu, 14 Feb 2008 00:49:42 GMT From: Tad Winters Subject: Re: DIBOL to Message-ID: Doug Phillips wrote in news:eebcffae-f4a5-4df2-b84e-7a213c405caf@s12g2000prg.googlegroups.com: [..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? If I could find some more companies in my area in need of someone to maintain their DBL code, I'd be pretty happy. The 2 companies I do occasional work for right now just ask for minor changes or minor new features. The 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. ------------------------------ Date: Wed, 13 Feb 2008 18:59:27 -0800 From: "Tom Linden" Subject: Re: DIBOL to Message-ID: On Wed, 13 Feb 2008 13:45:46 -0800, Doug Phillips wrote: > Well, DBL (Synergy/DE) is, IMO anyway. Actual DIBOL was nice and quite > easy to learn and code, but other languages were gaining capabilities > that DIBOL didn't have. Synergy/DE, on the other hand, has some really > great features that are not "built-in" to most other languages. Like what? -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Wed, 13 Feb 2008 19:17:02 -0800 (PST) From: ultradwc@gmail.com Subject: Re: DIBOL to Message-ID: <0aa89083-cd90-4177-b05d-8289c6ee6000@i7g2000prf.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 m= y > 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 ------------------------------ Date: Wed, 13 Feb 2008 19:36:40 -0800 (PST) From: ultradwc@gmail.com Subject: Re: DIBOL to Message-ID: <918112b7-97c1-452a-9585-1e11e2a9589d@s13g2000prd.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 m= y > 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 ... why not run their own web server? purveyor/wasd and dibol/dcl as script languages work terrific ... 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 ... 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 ... 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 ... ------------------------------ Date: Wed, 13 Feb 2008 20:09:47 -0800 (PST) From: Doug Phillips Subject: Re: DIBOL to Message-ID: On Feb 13, 8:59 pm, "Tom Linden" wrote: > On Wed, 13 Feb 2008 13:45:46 -0800, Doug Phillips > wrote: > > > Well, DBL (Synergy/DE) is, IMO anyway. Actual DIBOL was nice and quite > > easy to learn and code, but other languages were gaining capabilities > > that DIBOL didn't have. Synergy/DE, on the other hand, has some really > > great features that are not "built-in" to most other languages. > > Like what? Not easy to answer here, so you'll have to look for yourself: We are no longer a reseller, and receive no rewards for promoting it, but we do have a lot of DBL code running in enough places to provide a major percentage of our income. So anyone interested in Synergy/DE should contact Synergex directly. They're good people and while I haven't always agreed with the direction they've taken, I appreciate the fact that they do have a good product and do care about their customers. I guess I could likewise ask: What does PL/I offer that Synergy/DE doesn't? - except you asked first:-) ------------------------------ Date: Wed, 13 Feb 2008 13:49:26 -0500 From: JF Mezei Subject: Re: Dilbert Does Virtualization Message-ID: <47b33bcf$0$13999$c3e8da3@news.astraweb.com> Wilm Boerhout wrote: > on 12-2-2008 14:48 Larry Kilgallen wrote... >> http://www.dilbert.com/comics/dilbert/archive/images/dilbert20183362080212.gif > > I have already included it in one of my presentations! Anyone surprised that Kerry Main hasn't yet jumped into this conversation ? Since virtualisation is a pet subject of his, I expected him to provide some comments in this accurate documentary of virtualisation projects. ------------------------------ Date: 13 Feb 2008 18:57:59 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: Dilbert Does Virtualization Message-ID: <47b33db7$0$25060$607ed4bc@cv.net> In article <47b33bcf$0$13999$c3e8da3@news.astraweb.com>, JF Mezei writes: >Wilm Boerhout wrote: >> on 12-2-2008 14:48 Larry Kilgallen wrote... >>> http://www.dilbert.com/comics/dilbert/archive/images/dilbert20183362080212.gif >> >> I have already included it in one of my presentations! > > >Anyone surprised that Kerry Main hasn't yet jumped into this >conversation ? Since virtualisation is a pet subject of his, I expected >him to provide some comments in this accurate documentary of >virtualisation projects. He's busy unplugging something. :) -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" http://tmesis.com/drat.html ------------------------------ Date: Wed, 13 Feb 2008 20:11:38 -0800 (PST) From: yyyc186 Subject: FORTRAN MicroVAX connection machine question Message-ID: <86212ae7-e09a-41dc-b7ff-e2e48106df12@s8g2000prg.googlegroups.com> Hello, Odd we have all of this MicroVAX chatting going on after I just got rid of mine, but a question came up at work today. I searched a few search engines and cannot find a link to the article I'm looking for. Does anyone here have a link to the article about the person from Fermi (could have been Argonne) who took a bunch of left over MicroVAX computers and some FORTRAN code to make a connection machine out of them. I swear I remember this story from back in the days of DEC Professional, but simply cannot find it. OK, it was a weird discussion, because we were also debating about DIP switches on modems used with TCAM being used to set a modem number which had to match an entry in the TCAM database (actually authorization file) before it could communicate with TCAM on the IBM mainframe. Apparently that knowledge is also pretty arcane because there are only references to the IBM manuals which would have had such information, but the manuals aren't on-line...at least in any capacity ASK or GOOGLE could find them. Perhaps I'm just not getting lucky with my query parameters. When unlucky with a search engine, post here, and search the grey cells ------------------------------ Date: Wed, 13 Feb 2008 19:23:14 -0500 From: "Dan Allen" Subject: FW: VMS license fees? Message-ID: <003b01c86e9f$c9ec2150$1f3a0681@sdct.nist.gov> > -----Original Message----- > From: VAXman-@SendSpamHere.ORG [mailto:VAXman-@SendSpamHere.ORG] > Sent: Wednesday, February 13, 2008 5:49 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: VMS license fees? > > In article <47B363C7.6010706@comcast.net>, "Richard B. > Gilbert" writes: > >Dan Allen wrote: > >> > >> > >> > >>>-----Original Message----- > >>>From: Stanley F. Quayle [mailto:infovax@stanq.com] > >>>Sent: Wednesday, February 13, 2008 12:36 PM > >>>To: Info-VAX@Mvb.Saic.Com > >>>Subject: Re: VMS license fees? > >>> > >>>On 13 Feb 2008 at 17:02, Bill Gunshannon wrote: > >>> > >>>>Not the way I read it: "Paying for licenses? > >>>> I encounter customers all the time > >>> > >>>that don't know > >>> > >>>> that HP owns VMS. They're > >>> > >>>certainly not paying anyone > >>> > >>>> license fees for their VAX." > >>>> > >>>>Hard to interpret that as anything short of running VAX without a > >>>>valid license. > >>> > >>>What I meant was that the licenses that came with their VAX, good > >>>forever, stay good for, well, forever. > >>> > >>>--Stan Quayle > >>>Quayle Consulting Inc. > >>> > >> > >> > >> Indeed. I have a file cabinet drawer full of license PAKS > originally > >> purchased for an 11/780 in the early eighties (including a host of > >> unlimited VMS and layerd product licenses) that were > transferred as > >> part of an Alpha upgrade and are still good. Too bad > there's no interest in the Alpha aside from me.... > > > >I think your dates are a little off Dan. In 1984 there were > licenses > >but no License PAKs. You did need a software "patch" to > enable DECnet > >but that was not the same thing as a PAK. > > > >Paper license PAKs came along a couple of years later! > > 1987/88 time frame when VMS V5.0 and the LMF were introduced. > > -- > VAXman- A Bored Certified VMS Kernel Mode Hacker > VAXman(at)TMESIS(dot)COM > > "Well my son, life is like a beanstalk, isn't it?" > > http://tmesis.com/drat.html > Well I transfered into "The Bureau" in 1986 so it wouldn't be any earlier than that. I guess "early Eighties" is a stretch. Still beaucoup $$$$ worth of PAKS in that drawer - Fortran, C, Pascal, Cobol, Basic, RDB - all unlimited usage and all perfectly legit as long as you don't mind the versions. And I was indeed the lucky guy who got to install the initial LMF deployment. It's been a while and I'm afraid I've killed quite a few gray cells in the interim so my memory is a bit shakey..... Dan ------------------------------ Date: Wed, 13 Feb 2008 19:03:03 -0800 From: "Tom Linden" Subject: Re: FW: VMS license fees? Message-ID: On Wed, 13 Feb 2008 16:23:14 -0800, Dan Allen wrote: > >> -----Original Message----- >> From: VAXman-@SendSpamHere.ORG [mailto:VAXman-@SendSpamHere.ORG] >> Sent: Wednesday, February 13, 2008 5:49 PM >> To: Info-VAX@Mvb.Saic.Com >> Subject: Re: VMS license fees? >> >> In article <47B363C7.6010706@comcast.net>, "Richard B. >> Gilbert" writes: >> >Dan Allen wrote: >> >> >> >> >> >> >> >>>-----Original Message----- >> >>>From: Stanley F. Quayle [mailto:infovax@stanq.com] >> >>>Sent: Wednesday, February 13, 2008 12:36 PM >> >>>To: Info-VAX@Mvb.Saic.Com >> >>>Subject: Re: VMS license fees? >> >>> >> >>>On 13 Feb 2008 at 17:02, Bill Gunshannon wrote: >> >>> >> >>>>Not the way I read it: "Paying for licenses? >> >>>> I encounter customers all the time >> >>> >> >>>that don't know >> >>> >> >>>> that HP owns VMS. They're >> >>> >> >>>certainly not paying anyone >> >>> >> >>>> license fees for their VAX." >> >>>> >> >>>>Hard to interpret that as anything short of running VAX without a >> >>>>valid license. >> >>> >> >>>What I meant was that the licenses that came with their VAX, good >> >>>forever, stay good for, well, forever. >> >>> >> >>>--Stan Quayle >> >>>Quayle Consulting Inc. >> >>> >> >> >> >> >> >> Indeed. I have a file cabinet drawer full of license PAKS >> originally >> >> purchased for an 11/780 in the early eighties (including a host of >> >> unlimited VMS and layerd product licenses) that were >> transferred as >> >> part of an Alpha upgrade and are still good. Too bad >> there's no interest in the Alpha aside from me.... >> > >> >I think your dates are a little off Dan. In 1984 there were >> licenses >> >but no License PAKs. You did need a software "patch" to >> enable DECnet >> >but that was not the same thing as a PAK. >> > >> >Paper license PAKs came along a couple of years later! >> >> 1987/88 time frame when VMS V5.0 and the LMF were introduced. >> >> -- >> VAXman- A Bored Certified VMS Kernel Mode Hacker >> VAXman(at)TMESIS(dot)COM >> >> "Well my son, life is like a beanstalk, isn't it?" >> >> http://tmesis.com/drat.html >> > > Well I transfered into "The Bureau" in 1986 so it wouldn't be any > earlier than > that. I guess "early Eighties" is a stretch. Still beaucoup $$$$ worth > of PAKS > in that drawer - Fortran, C, Pascal, Cobol, Basic, RDB - all unlimited > usage and You forgot PL/I. > all perfectly legit as long as you don't mind the versions. And I was > indeed the > lucky guy who got to install the initial LMF deployment. It's been a > while and > I'm afraid I've killed quite a few gray cells in the interim so my > memory is a > bit shakey..... > > Dan > > -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Wed, 13 Feb 2008 14:16:03 -0600 (CST) From: sms@antinode.org (Steven M. Schweda) Subject: Re: ODS5, /NAMES = AS_IS, LIBRARY, MMS v. me Message-ID: <08021314160378_2062A39A@antinode.org> From: "John E. Malmberg" > MMK works with ODS-5 volumes and lowercase extensions now. I hadn't tried any of this stuff with MMK, but the one I have seems to be MMS-compatible: ALP $ mmk /iden %MMK-I-IDENT, this is the MadGoat Make Utility V3.9-10 -MMK-I-COPYRIGHT, Copyright © 1992-2005, MadGoat Software. All Rights Reserved. ALP $ mmk LIBRARY/REPLACE LIBRARY.OLB LOWER.OBJ %MMK-I-ACTNOUPD, action did not update target LIBRARY.OLB(LOWER=LOWER.OBJ) LIBRARY/REPLACE LIBRARY.OLB UPPER.OBJ Done. ALP $ mmk LIBRARY/REPLACE LIBRARY.OLB LOWER.OBJ %MMK-I-ACTNOUPD, action did not update target LIBRARY.OLB(LOWER=LOWER.OBJ) Done. File names are one thing, library module names are another. > I have been told that an update to MMS/DECSET to support ODS-5 will be > coming out. I do not know the status. ftp://ftp.itrc.hp.com/openvms_patches/layered_products/alpha/ ftp://ftp.itrc.hp.com/openvms_patches/layered_products/i64/ > For the shared images [...] That's a different problem. From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) > Off the top of my head (probably needs more work specific to your > case): > > .C.OBJ: > $(CC) $(CFLAGS) a.c+$(MMS$SOURCE)+z.c/object=$(MMS$TARGET) > > Where a.c and z.c contain the needed #pragma entry and exit. Off the top of _my_ head, what good would a.c do which can't be done with command-line options? And what good would z.c do if it follows all the real code? Still waiting for a (clearly) clever suggestion... ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: 13 Feb 2008 17:16:21 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: ODS5, /NAMES = AS_IS, LIBRARY, MMS v. me Message-ID: In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > > Off the top of my head (probably needs more work specific to your > case): OK, this is a little less off the top, but needs to be converted from a .com file to MMS directives. $module = f$parse(p1,,,"name") $module = f$edit(module,"upcase") $open/write outp sys$scratch:module.h $write outp "#pragma module " + module $close outp $cc /first_include=sys$scratch:module.h 'p1 $delete sys$scratch:module.h; ------------------------------ Date: Thu, 14 Feb 2008 04:09:51 GMT From: "John E. Malmberg" Subject: Re: ODS5, /NAMES = AS_IS, LIBRARY, MMS v. me Message-ID: Steven M. Schweda wrote: > From: "John E. Malmberg" > >> MMK works with ODS-5 volumes and lowercase extensions now. > > I hadn't tried any of this stuff with MMK, but the one I have seems > to be MMS-compatible: > > ALP $ mmk /iden > %MMK-I-IDENT, this is the MadGoat Make Utility V3.9-10 > -MMK-I-COPYRIGHT, Copyright © 1992-2005, MadGoat Software. All Rights Reserved. You have a later version than I have. I have V3.9-9. I have been using MMK for a few years now to build Perl on ODS-5 disks where the source filenames are in the exact case as pulled down from repository. MMS was not able to do the build because it required the extensions to be in upper case. -John wb8tyw@qsl.network Personal Opinion Only ------------------------------ Date: Wed, 13 Feb 2008 22:46:51 GMT From: "Robert Jarratt" Subject: Re: The "World's First" MicroVAX II Museum is now Open Message-ID: "alegend" wrote in message news:6139fe6c-c530-4956-b64a-4c9eeb86c238@s12g2000prg.googlegroups.com... > Hello All, > > 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. > > A partial, lots-to-be-done web presence is at: http://www.microvax2.org > (check out the virtual tour). > > It is located in Israel, and entry is free and by appointment only. > > I have no idea what a visitor might do there after wandering around > the room for a few minutes, but if you are in the neighborhood and in > desparate need for a VMS 5.4 prompt, you can find it there. > > Seriously, this place is all about preserving the MicroVAX II, and as > much software, literature and related hardware as possible. It is > built like a computer room from the late 80's, and a glass wall is the > next thing on the construction plan. > > The history of the 12 sq. meter room in my front yard goes back many > years. But in the last year I have cleared tons of rubbish from it, > lay down a new ceramic tile floor, got it painted, had special-ordered > all the furniture, connected the room to mains power, littered the > ceiling with spot lights, and had the essential air conditioner > installed. > > I would like to take the opportunity to thank all those who helped me, > in this newsgroup and beyond (you know who you are). > > My apologies for the double posting. > > -Al. Some interesting stuff there, brings back memories. One comment intrigued me though, on cleaning a TK50. I had worked most of it out for myself, but then at the very last you mention the head tachometer. Where is that? Any recommendations on how to clean it? I have a tape that I know to have been readable recently but will not load in my TK50. Thanks Rob ------------------------------ Date: Wed, 13 Feb 2008 11:37:17 -0800 (PST) From: Hein RMS van den Heuvel Subject: Re: Unusual mailbox status value Message-ID: <21b977ad-9fe3-473f-be48-e51c6c7e74bb@b2g2000hsg.googlegroups.com> On Feb 13, 1:40=A0am, David B Sneddon wrote: > On Feb 13, 4:48 am, FrankS wrote: > > On Feb 12, 9:31 pm, John Santos wrote: > > > > Are you sure there isn't a "passed by value"/"passed by reference" con= fusion > > > somewhere? > > > The %INCLUDE "STARLET" %FROM %LIBRARY takes care of declaring the > > parameter data types and passing mechanisms. =A0The compiler is > > responsible for making sure the rest is handled correctly. Right. > > It is my understanding that the definitions are there to allow > the compiler to generate warnings about your code, not change the > code. Wrong. Basic changes the default passing mechanisme based on the prototype. This is not too strange (for basic) as it already pick the method by desriptor o by reference based on passing a string or an integers and such. > =A0It is possible to pass something by reference and have the > same result as passing something else by value and vice versa > e.g. passing the address of a variable by value is the same as passing > the variable by reference. I've seen that happen. Customers are convinced the code is correct 'because it works'. But in fact it was just bad luck it worked, the code was broken. > Your code is wrong. =A0Fix it. While I prefer the explicit passing pechanism, I beg to differ. The code i correct. It works doesn't it ? :-) :-). Seriously, this code is correct, but it was long ago enough for me to verify. So I did write a little standalone test. 1 option type =3D explicit,size =3D integer long, constant type =3D integer %include "$IOSBDEF" %from %library %include "STARLET" %from %library external word constant IO$_READVBLK declare long constant c$_max_message =3D 12, EFN$C_ENF =3D 128 declare long l$_return_status declare word w$_mailbox_channel record msg_structure string s$_buffer =3D c$_max_message end record msg_structure map (MSG) msg_structure MSG map (NCR$IOSB) iosb io_status map (NCR$IOSB) basic$quadword io_quadword l$_return_status =3D sys$assign ( 'TT:', w$_mailbox_channel,, ) if (l$_return_status and 1%) =3D 0% then call lib$stop (l $_return_status by value) \ end if while 1 + 1 =3D 2 l$_return_status =3D SYS$QIOW( EFN$C_ENF, w $_mailbox_channel, & IO$_READVBLK, io_quadword, , ,& msg::s$_buffer, c$_max_message, , , , ) print l$_return_status, io_status::IOSB$W_STATUS, io_status::IOSB$W_BCNT print "-->"; msg::s$_buffer; "<--" next Yeah... my definitions might 'fix' a problem that was not shown. Frank, how about the link map and the IOSB and MSG (or whatever name was used) psects? Could a module have snuck in which re-defines /overlays something? an / OPT link option? There is no shareable, writeable instaleld, image involved is there? Doe the corruption start at a certain psect boundary? > Can you expand on why using EFN$C_ENF would affect the behavior? No. That's admittedly some vague handwaving / gutfeel which our friend John seems to share. The original synchorization has two external things to work with: EFN + IOSB. Now there is just 1. So it feels like it would be easier to get that wrong. Does the mailbox not have a read/write attention AST? Cheers, Hein. ------------------------------ Date: Wed, 13 Feb 2008 16:39:21 -0800 (PST) From: FrankS Subject: Re: Unusual mailbox status value Message-ID: <3a836d65-a71a-4bff-9b1b-4ec2a4e0ef38@e10g2000prf.googlegroups.com> On Feb 13, 2:37=A0pm, Hein RMS van den Heuvel wrote: > Yeah... my definitions might 'fix' a problem that was not shown. You pretty much got it the same. Some differences between your test case and the actual production code I have are: a) Instead of declarations for the EFN$C_ENF and IO$_READVBLK I use %INCLUDE "$IODEF" and "$EFNDEF" b) The MSG_STRUCTURE is actually more complicated, as it contains VARIANT sections to redefine the contents of the message buffer. For example, the first two bytes of the message are the message length. This is used to validate that the record length returned from the mailbox is the expected message length. c) The MSG record is declared as a local variable, not on a MAP block. Only the IOSB is on a MAP block. > There is no shareable, writeable instaleld, image involved is there? Nope. > Doe the corruption start at a certain psect boundary? Still working on understanding the nature of the corrupted data area(s). The error occurs periodically enough that I was able to get a process dump today for more research. > Does the mailbox not have a read/write attention AST? Nope. ------------------------------ Date: Wed, 13 Feb 2008 11:15:45 -0800 From: "Tom Linden" Subject: Re: VEST Message-ID: On Wed, 13 Feb 2008 10:41:40 -0800, JF Mezei wrote: > FrankS wrote: > >> If you VEST the DIBOL compiler and are able to mate it to the Alpha >> GEM routines then one could expect it to produce Alpha code. It >> wouldn't surprise me if some of Digital's earliest efforts at porting >> to Alpha involved new GEM code with VESTed compilers. > > Did any VAX compilers use GEM ? no -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Wed, 13 Feb 2008 13:47:42 -0500 From: JF Mezei Subject: Re: VEST (was: DIBOL to Message-ID: <47b33b69$0$13999$c3e8da3@news.astraweb.com> Stanley F. Quayle wrote: > Sounds like a lot of work compared to running CHARON-VAX [Shameless Plug Alert (tm) I am > a CHARON reseller]. In a couple of days, he'd be done. Not all customers are up to > reverse-engineering something like a compiler. From a hardware point of view, you are correct. Since Alpha is no longer developped, it is just as dead as VAX so there is no real point to migrate VAX to Alpha. The one big difference however is that VMS is now sigificantly more advanced on Alpha than on VAX, so moving to Alpha does give you many software advantages. If not for that one application, it gives you for oither applications. If VMS were still developped on VAX, then the Charron solution would be the best. Now, if VMS development has been scaled down to a point where progress is minimal from the point of view of the user/programmer, then the gap between VAX-VMS and Alpha-VMS will stop growing. (aka: if new version of VMS are made onlyto support new HP hardware, this doesn't change the value of vMS to the user/programmer). ------------------------------ Date: 13 Feb 2008 22:16:30 -0600 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: VEST (was: DIBOL to Message-ID: In article , FrankS writes: > I don't think it was too much of a stretch to guess that the GEM > functions common to all compilers would be located in a shareable > image. It might not be much of a stretch, but it is not true. > It > wouldn't surprise me if some of Digital's earliest efforts at porting > to Alpha involved new GEM code with VESTed compilers. The actual approach was building cross compilers on VAX. ------------------------------ Date: 13 Feb 2008 18:48:19 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: VMS license fees? Message-ID: <61gsbjF1v2iveU1@mid.individual.net> In article <47b339bf$0$10268$c3e8da3@news.astraweb.com>, JF Mezei writes: > Bill Gunshannon wrote: >> >> Not surprised, but some people actually don't believe in stealing >> software. I woould be willing to bet that there are a lot of >> commercial VMS systems running with Hobbyist PAKs. > > I don't think so. Your presumption would assume that there would have > been new customers who started to use VMS since the hobbyisty programme > was started and who would have decided to use those licences "illegally". No, no such presumption. It would include someone who needs another machine to test something and they are only going to need it for a month or two, so........ > > I would think that almost all customers are long tike VMS customers who > have had their licences for a very long time even if they no longer pay > for the support fees. Seems like you are making suppositions, too. > > Where hobbyist may be "abused" are those legitimate shops needing a new > licence to compile some freeware utility etc and being unable to reach > Digital to buy such licence, they go the way of hobbyist. And how is this any differnt than what I said up above? Not being able to contact HP to buy a license does not change the legal or moral responsibility to have a legitimate license in place before using a machine for business purposes. Believe it or not, the dificulty or inability to contact Mentec was the most common reason given for running PDP-11's without valid licenses. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Wed, 13 Feb 2008 11:09:39 -0800 From: "Tom Linden" Subject: Re: VMS license fees? Message-ID: On Wed, 13 Feb 2008 10:37:48 -0800, Wilm Boerhout = wrote: > on 13-2-2008 17:38 Richard B. Gilbert wrote... > >> And some of us bought systems with licenses included! > > If you bought them new, that's OK. If you bought'm second hand, (VAX o= r = > Alpha), it's only OK for the base OS license + "hardware attached" = > software (Category 1 software). All other licenses are not transferabl= e = > outside of the first owner legal entity (relicensing), although they a= re = > transferable within the original legal entity (redesignation). = > Relicensing is not free where it is permitted. Written permission from= = > HP required in all cases. > > Software License Policy > http://licensing.hp.com/swl/view.slm?page=3Dxfer > > I'm not sure whether HP staff does enforce this policy, well, then = > again, I'm sure they don't. When I was a Digital employee in the 80's,= = > everyone selling second hand knew this. It was enforced then. > As a matter of law if you are aware of a violation and don't act to enfo= rce your rights you may abdicate them -- = PL/I for OpenVMS www.kednos.com ------------------------------ Date: Wed, 13 Feb 2008 14:52:05 -0500 From: "Stanley F. Quayle" Subject: Re: VMS license fees? Message-ID: <47B30415.23445.195F0298@infovax.stanq.com> On 13 Feb 2008 at 18:48, Bill Gunshannon wrote: > No, no such presumption. It would include someone who needs another > machine to test something and they are only going to need it for a > month or two, so........ DSPP members get VMS licenses for free, including VAX ones... --Stan Quayle Quayle Consulting Inc. ---------- Stanley F. Quayle, P.E. N8SQ Toll free: 1-888-I-LUV-VAX 8572 North Spring Ct., Pickerington, OH 43147 USA stan-at-stanq-dot-com http://www.stanq.com/charon-vax.html "OpenVMS, when downtime is not an option" ------------------------------ Date: 13 Feb 2008 19:58:56 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: VMS license fees? Message-ID: <61h0fvF1vk14fU1@mid.individual.net> In article <47B30415.23445.195F0298@infovax.stanq.com>, "Stanley F. Quayle" writes: > On 13 Feb 2008 at 18:48, Bill Gunshannon wrote: >> No, no such presumption. It would include someone who needs another >> machine to test something and they are only going to need it for a >> month or two, so........ > > DSPP members get VMS licenses for free, including VAX ones... > What does DSPP membership cost? bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 13 Feb 2008 20:10:26 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: VMS license fees? Message-ID: <61h15iF1vk14fU2@mid.individual.net> In article <61h0fvF1vk14fU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes: > In article <47B30415.23445.195F0298@infovax.stanq.com>, > "Stanley F. Quayle" writes: >> On 13 Feb 2008 at 18:48, Bill Gunshannon wrote: >>> No, no such presumption. It would include someone who needs another >>> machine to test something and they are only going to need it for a >>> month or two, so........ >> >> DSPP members get VMS licenses for free, including VAX ones... >> > > What does DSPP membership cost? Nevermind. I eventually found it (but it wan't easy or obvious.) Of course, there are other requirements that would make my example above not qualify anyway. So we're back to: someone who needs another machine to test something and they are only going to need it for a month or two, so........ :-) bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Wed, 13 Feb 2008 21:26:00 +0100 From: Wilm Boerhout Subject: Re: VMS license fees? Message-ID: <47b35269$0$25482$ba620dc5@text.nova.planet.nl> on 13-2-2008 19:40 JF Mezei wrote... [snip] > Where hobbyist may be "abused" are those legitimate shops needing a new > licence to compile some freeware utility etc and being unable to reach > Digital to buy such licence, they go the way of hobbyist. No excuses in my country. It is still possible (and not very difficult either) for me and my customers to buy VMS licenses (the old Q*-*****-** scheme). VAX as well as Alpha. Whether you like the price for your VAX/DEC/HP C compiler is another thing... -- Wilm Boerhout Zwolle, NL remove OLD PAINT from return address to reply ------------------------------ Date: Wed, 13 Feb 2008 21:37:37 +0100 From: Wilm Boerhout Subject: Re: VMS license fees? Message-ID: <47b35523$0$25476$ba620dc5@text.nova.planet.nl> on 13-2-2008 20:52 Stanley F. Quayle wrote... > DSPP members get VMS licenses for free, including VAX ones... Yes, but not to run their *own* business applications on. If you want to sell email services using your Alpha as a server, DSPP licensing is not enough. Demo purposes, OK. -- Wilm Boerhout Zwolle, NL remove OLD PAINT from return address to reply ------------------------------ Date: Wed, 13 Feb 2008 16:40:23 -0500 From: "Richard B. Gilbert" Subject: Re: VMS license fees? Message-ID: <47B363C7.6010706@comcast.net> Dan Allen wrote: > > > >>-----Original Message----- >>From: Stanley F. Quayle [mailto:infovax@stanq.com] >>Sent: Wednesday, February 13, 2008 12:36 PM >>To: Info-VAX@Mvb.Saic.Com >>Subject: Re: VMS license fees? >> >>On 13 Feb 2008 at 17:02, Bill Gunshannon wrote: >> >>>Not the way I read it: "Paying for licenses? >>> I encounter customers all the time >> >>that don't know >> >>> that HP owns VMS. They're >> >>certainly not paying anyone >> >>> license fees for their VAX." >>> >>>Hard to interpret that as anything short of running VAX without a >>>valid license. >> >>What I meant was that the licenses that came with their VAX, >>good forever, stay good for, well, forever. >> >>--Stan Quayle >>Quayle Consulting Inc. >> > > > Indeed. I have a file cabinet drawer full of license PAKS originally purchased > for an 11/780 in the early eighties (including a host of unlimited VMS and > layerd product licenses) that were transferred as part of an Alpha upgrade and > are still good. Too bad there's no interest in the Alpha aside from me.... I think your dates are a little off Dan. In 1984 there were licenses but no License PAKs. You did need a software "patch" to enable DECnet but that was not the same thing as a PAK. Paper license PAKs came along a couple of years later! ------------------------------ Date: Wed, 13 Feb 2008 16:46:12 -0500 From: "Richard B. Gilbert" Subject: Re: VMS license fees? Message-ID: <47B36524.3000409@comcast.net> Wilm Boerhout wrote: > on 13-2-2008 17:38 Richard B. Gilbert wrote... > >> And some of us bought systems with licenses included! > > > If you bought them new, that's OK. If you bought'm second hand, (VAX or > Alpha), it's only OK for the base OS license + "hardware attached" > software (Category 1 software). All other licenses are not transferable > outside of the first owner legal entity (relicensing), although they are > transferable within the original legal entity (redesignation). > Relicensing is not free where it is permitted. Written permission from > HP required in all cases. I bought from a dealer and the machine was new. This was back in the late 1990's when the AlphaStation 200 went EOL. ------------------------------ Date: 13 Feb 2008 22:43:51 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: VMS license fees? Message-ID: <47b372a7$0$25029$607ed4bc@cv.net> In article <61h0fvF1vk14fU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes: >In article <47B30415.23445.195F0298@infovax.stanq.com>, > "Stanley F. Quayle" writes: >> On 13 Feb 2008 at 18:48, Bill Gunshannon wrote: >>> No, no such presumption. It would include someone who needs another >>> machine to test something and they are only going to need it for a >>> month or two, so........ >> >> DSPP members get VMS licenses for free, including VAX ones... >> > >What does DSPP membership cost? If you have to ask Bill, you can't afford it. ;) -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" http://tmesis.com/drat.html ------------------------------ Date: 13 Feb 2008 22:48:49 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: VMS license fees? Message-ID: <47b373d1$0$25029$607ed4bc@cv.net> In article <47B363C7.6010706@comcast.net>, "Richard B. Gilbert" writes: >Dan Allen wrote: >> >> >> >>>-----Original Message----- >>>From: Stanley F. Quayle [mailto:infovax@stanq.com] >>>Sent: Wednesday, February 13, 2008 12:36 PM >>>To: Info-VAX@Mvb.Saic.Com >>>Subject: Re: VMS license fees? >>> >>>On 13 Feb 2008 at 17:02, Bill Gunshannon wrote: >>> >>>>Not the way I read it: "Paying for licenses? >>>> I encounter customers all the time >>> >>>that don't know >>> >>>> that HP owns VMS. They're >>> >>>certainly not paying anyone >>> >>>> license fees for their VAX." >>>> >>>>Hard to interpret that as anything short of running VAX without a >>>>valid license. >>> >>>What I meant was that the licenses that came with their VAX, >>>good forever, stay good for, well, forever. >>> >>>--Stan Quayle >>>Quayle Consulting Inc. >>> >> >> >> Indeed. I have a file cabinet drawer full of license PAKS originally purchased >> for an 11/780 in the early eighties (including a host of unlimited VMS and >> layerd product licenses) that were transferred as part of an Alpha upgrade and >> are still good. Too bad there's no interest in the Alpha aside from me.... > >I think your dates are a little off Dan. In 1984 there were licenses >but no License PAKs. You did need a software "patch" to enable DECnet >but that was not the same thing as a PAK. > >Paper license PAKs came along a couple of years later! 1987/88 time frame when VMS V5.0 and the LMF were introduced. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" http://tmesis.com/drat.html ------------------------------ Date: Wed, 13 Feb 2008 16:17:32 -0800 (PST) From: FrankS Subject: Re: VMS license fees? Message-ID: <91999cc8-1d02-4d9c-81c7-6cbb4f645d54@1g2000hsl.googlegroups.com> On Feb 13, 12:35=A0pm, "Stanley F. Quayle" wrote: > What I meant was that the licenses that came with their VAX, good forever,= stay good for, > well, forever. I don't remember what the license policies were back when Digital was issuing them. Current HP policy is that the license you buy is good for the version you buy, and nothing else. In order to install new versions you must be on a software support contract which gives you the "right to new versions" (RTNV). So, if you buy an OpenVMS Base license today at the current version (v8.3-1H1) and don't get a software support contract then you are not allowed to upgrade, say, to v8.4 when it is issued. You can continue to run v8.3-1H1 forever, though. ------------------------------ Date: Wed, 13 Feb 2008 16:20:39 -0800 (PST) From: FrankS Subject: Re: VMS license fees? Message-ID: <9e386bd7-d901-489e-8e65-0ae4dddeeaf1@m34g2000hsb.googlegroups.com> On Feb 13, 1:48=A0pm, billg...@cs.uofs.edu (Bill Gunshannon) wrote: > No, no such presumption. =A0It would include someone who needs another > machine to test something and they are only going to need it for a > month or two, so........ HP can and does issue temporary licenses. I would think they're a bit tight-fisted about them and probably don't do it unless you're on a support contract. ------------------------------ Date: Wed, 13 Feb 2008 20:18:55 -0500 From: "Richard B. Gilbert" Subject: Re: VMS license fees? Message-ID: <47B396FF.50703@comcast.net> FrankS wrote: > On Feb 13, 12:35 pm, "Stanley F. Quayle" wrote: > >>What I meant was that the licenses that came with their VAX, good forever, stay good for, >>well, forever. > > > I don't remember what the license policies were back when Digital was > issuing them. Current HP policy is that the license you buy is good > for the version you buy, and nothing else. In order to install new > versions you must be on a software support contract which gives you > the "right to new versions" (RTNV). > > So, if you buy an OpenVMS Base license today at the current version > (v8.3-1H1) and don't get a software support contract then you are not > allowed to upgrade, say, to v8.4 when it is issued. You can continue > to run v8.3-1H1 forever, though. DEC's policy was the same! ------------------------------ End of INFO-VAX 2008.089 ************************