INFO-VAX Thu, 23 Aug 2007 Volume 2007 : Issue 461 Contents: Re: Any filename problems going from VAX/ODS-2 to Alpha/ODS-5/case blind? blind? Re: COBOL Transactions? Re: COBOL Transactions? Re: COBOL Transactions? Re: COBOL Transactions? Re: COBOL Transactions? Re: COBOL Transactions? RE: COBOL Transactions? RE: COBOL Transactions? RE: COBOL Transactions? RE: COBOL Transactions? RE: COBOL Transactions? Re: COBOL Transactions? RE: COBOL Transactions? RE: COBOL Transactions? RE: COBOL Transactions? RE: COBOL Transactions? Re: COBOL Transactions? Re: COBOL Transactions? RE: COBOL Transactions? Re: decnet startup failing Re: DECnet-Plus for a hobbyist Re: DECnet-Plus for a hobbyist Re: DECnet-Plus for a hobbyist Re: DECnet-Plus for a hobbyist Re: DECnet-Plus for a hobbyist Re: Free to good home. Microvaxes, Vaxstations, Alphas Re: Help with tracking down intrusion record logs Re: Help with tracking down intrusion record logs Re: Help with tracking down intrusion record logs Re: Help with tracking down intrusion record logs Re: Help with tracking down intrusion record logs Re: Help with tracking down intrusion record logs Re: Help with tracking down intrusion record logs Re: Help with tracking down intrusion record logs Re: Here's one for Bob (hope it makes your head spin) Re: Here's one for Bob (hope it makes your head spin) Re: Here's one for Bob (hope it makes your head spin) Re: Here's one for Bob (hope it makes your head spin) Re: Here's one for Bob (hope it makes your head spin) Re: Here's one for Bob (hope it makes your head spin) is this a race condition? Re: is this a race condition? Re: is this a race condition? Re: is this a race condition? Re: is this a race condition? Re: Looking for SEDT source code OpenVMS Customer Lab Re: Peer review (was Re: Wisconsin professor says global warming a hoax!) Re: Peer review (was Re: Wisconsin professor says global warming a hoax!) a hoax Re: Peer review (was Re: Wisconsin professor says global warming a hoax!) a hoax Re: Peer review (was Re: Wisconsin professor says global warminga hoax!) Re: Reading non-VMS DAT tape Re: Reading non-VMS DAT tape Re: Reading non-VMS DAT tape St. Linus on GPLv2, v3 & BSD licenses Re: VMS 8.3 and TCPIP X.Y: the killer application ---------------------------------------------------------------------- Date: Wed, 22 Aug 2007 22:17:57 GMT From: John Santos Subject: Re: Any filename problems going from VAX/ODS-2 to Alpha/ODS-5/case blind? blind? Message-ID: John Santos wrote: [...] > > On the other hand, if you're commute is via private NSA jet to Arrgh!!! "... your commute..." [...] -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: Wed, 22 Aug 2007 14:18:53 -0400 From: John Reagan Subject: Re: COBOL Transactions? Message-ID: Paul Raulerson wrote: > I posted this question in another, but I figured someone here might > have a good idea they were willing to share. > > > Most COBOL implementations provide a > BEGIN TRANSACTION > COMMIT/ROLLBACK > construct. > > I have a need to update several files, all of which much be sucessful or all of which much be rolled back, which would normally be easily handled by the above COBOL construct. > > Suggestions have ranged from using RMS Journaling, to the HP transaction manager, to using a database for transaction managemen. All of these suggestions would mostly likely work, but they add cost. I have no idea of the magnitude of that cost though. I'm also trying to avoid adding a database because of the overhead (physcial and management) as well as the cost. > > Does anyone have a rough idea just how much cost the RMS or transaction manager solution adds to the end user on a small machine? Assuming I pass it on to the end-user directly "at cost." > > Or if John R. is reading this - any plans to add transaction management directly into the compiler? Or is there transaction management built into Pascal or Fortran that I can use to manage this? This cannot be an unusual situation, especially with VMS being used in financial markets. > Yep, I'm reading this (as well as the ITRC discussion). No, we don't have any COMMIT like feature in our compilers. No current plans for adding them. The underlying RMS journalling and/or DDTM services are probably the best you are going to get. If we were to add some COMMIT feature to COBOL those are the services we'd use. -- John Reagan OpenVMS Pascal/Macro-32/COBOL Project Leader Hewlett-Packard Company ------------------------------ Date: Wed, 22 Aug 2007 16:42:12 -0400 From: "Richard B. Gilbert" Subject: Re: COBOL Transactions? Message-ID: <46CC9FA4.7040403@comcast.net> Paul Raulerson wrote: > I posted this question in another, but I figured someone here might > have a good idea they were willing to share. > > > Most COBOL implementations provide a > BEGIN TRANSACTION > COMMIT/ROLLBACK > construct. > > I have a need to update several files, all of which much be sucessful or all of which much be rolled back, which would normally be easily handled by the above COBOL construct. > > Suggestions have ranged from using RMS Journaling, to the HP transaction manager, to using a database for transaction managemen. All of these suggestions would mostly likely work, but they add cost. I have no idea of the magnitude of that cost though. I'm also trying to avoid adding a database because of the overhead (physcial and management) as well as the cost. > > Does anyone have a rough idea just how much cost the RMS or transaction manager solution adds to the end user on a small machine? Assuming I pass it on to the end-user directly "at cost." > > Or if John R. is reading this - any plans to add transaction management directly into the compiler? Or is there transaction management built into Pascal or Fortran that I can use to manage this? This cannot be an unusual situation, especially with VMS being used in financial markets. > > I'm also open to "sneaky tricks" from the past on how to do this safely without the added expense. > > Thanks > -Paul > > This sounds a hell of a lot like "two phase commit" which was added to RMS about 13 years ago as I recall. IIRC it writes the transaction details to a journal first, then updates the files and finally erases the journal entry or marks it "done" or some such. For further details, RTFM. ------------------------------ Date: Wed, 22 Aug 2007 22:02:58 GMT From: =?UTF-8?B?SmFuLUVyaWsgU8O2ZGVyaG9sbQ==?= Subject: Re: COBOL Transactions? Message-ID: Paul Raulerson wrote: > I posted this question in another, but I figured someone here might > have a good idea they were willing to share. > > > Most COBOL implementations provide a > BEGIN TRANSACTION > COMMIT/ROLLBACK > construct. > > I have a need to update several files, all of which much be sucessful or all of which much be rolled back, which would normally be easily handled by the above COBOL construct. > > Suggestions have ranged from using RMS Journaling, to the HP transaction manager, to using a database for transaction managemen. All of these suggestions would mostly likely work, but they add cost. I have no idea of the magnitude of that cost though. I'm also trying to avoid adding a database because of the overhead (physcial and management) as well as the cost. > > Does anyone have a rough idea just how much cost the RMS or transaction manager solution adds to the end user on a small machine? Assuming I pass it on to the end-user directly "at cost." > > Or if John R. is reading this - any plans to add transaction management directly into the compiler? Or is there transaction management built into Pascal or Fortran that I can use to manage this? This cannot be an unusual situation, especially with VMS being used in financial markets. > > I'm also open to "sneaky tricks" from the past on how to do this safely without the added expense. > > Thanks > -Paul > > As close to everyone as you can get that is those needs, are probably running a proper database, preferable Rdb, of course :-) The nice thing about Rdb is that for moderataly small databases, it's mostly a set-n-forget process. Rdb lives happily without a lot of "baby sitting"... Jan-Erik. ------------------------------ Date: Wed, 22 Aug 2007 17:38:57 -0500 From: Ron Johnson Subject: Re: COBOL Transactions? Message-ID: <6W2zi.334136$wG2.39875@newsfe17.lga> On 08/22/07 17:02, Jan-Erik Söderholm wrote: > Paul Raulerson wrote: >> I posted this question in another, but I figured someone here might >> have a good idea they were willing to share. >> >> Most COBOL implementations provide a BEGIN TRANSACTION >> COMMIT/ROLLBACK >> construct. >> I have a need to update several files, all of which much be sucessful >> or all of which much be rolled back, which would normally be easily >> handled by the above COBOL construct. >> >> Suggestions have ranged from using RMS Journaling, to the HP >> transaction manager, to using a database for transaction managemen. >> All of these suggestions would mostly likely work, but they add cost. >> I have no idea of the magnitude of that cost though. I'm also trying >> to avoid adding a database because of the overhead (physcial and >> management) as well as the cost. >> >> Does anyone have a rough idea just how much cost the RMS or >> transaction manager solution adds to the end user on a small machine? >> Assuming I pass it on to the end-user directly "at cost." >> >> Or if John R. is reading this - any plans to add transaction >> management directly into the compiler? Or is there transaction >> management built into Pascal or Fortran that I can use to manage this? >> This cannot be an unusual situation, especially with VMS being used in >> financial markets. >> I'm also open to "sneaky tricks" from the past on how to do this >> safely without the added expense. >> Thanks -Paul >> > > As close to everyone as you can get that is those needs, are > probably running a proper database, preferable Rdb, of course :-) > > The nice thing about Rdb is that for moderataly small databases, > it's mostly a set-n-forget process. Rdb lives happily without > a lot of "baby sitting"... But costs US$20K (I think) per CPU, I think, not including discounts. The question to ask John Reagan, I think, is if COBOL file semantics can work in harmony with low-level RMS/DTM 2PC API calls. -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: 22 Aug 2007 17:41:19 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: COBOL Transactions? Message-ID: In article <46CC9FA4.7040403@comcast.net>, "Richard B. Gilbert" writes: > Paul Raulerson wrote: >> I posted this question in another, but I figured someone here might >> have a good idea they were willing to share. >> >> >> Most COBOL implementations provide a >> BEGIN TRANSACTION >> COMMIT/ROLLBACK >> construct. >> >> I have a need to update several files, all of which much be sucessful or all of which much be rolled back, which would normally be easily handled by the above COBOL construct. > This sounds a hell of a lot like "two phase commit" which was added to > RMS about 13 years ago as I recall. IIRC it writes the transaction > details to a journal first, then updates the files and finally erases > the journal entry or marks it "done" or some such. > > For further details, RTFM. I do not believe this is a case of Read The Fine Manual. As I read the discussion the issues is than other Cobol implementations embed transaction handling in the language, while VMS Cobol does not. Likely this is something that would have to be done by User Open routines (I presume VMS Cobol has those) combined with explicit calls to RMS Journaling. It would be nicer if it were just a matter of compile-and-go, but I do not know to what extent the syntax shown above is in the Cobol standard. Of course John Reagan is quite experienced with implementing things before they make it into a standard, and has experience with what happens when the standard goes in a different direction, along with the standards committee politics that can force it in a different direction as a result of some vendors having implemented it one way. ------------------------------ Date: Thu, 23 Aug 2007 07:10:55 +0800 From: "Richard Maher" Subject: Re: COBOL Transactions? Message-ID: Hi John, > Yep, I'm reading this (as well as the ITRC discussion). No, we don't > have any COMMIT like feature in our compilers. No current plans for > adding them. If Paul is hell bent on using COBOL verbs for transactions, isn't there always DBMS? Oracle still support (and probably even sell it). If on the other hand, you/ve moved on to Relational Databases then SQL does seem to be the most popular DML with the usual crappy precompilers for most languages. (Does Orrible Oracle support the SQL Module language?) http://h71000.www7.hp.com/doc/82final/6393/6393pro_contents.html Still if you insist on being really cheap and pretend that you were in UNIX ISAM-land then you could use mySQL and forget that transactions ever existed. I mean, as if anything could go wrong between updates to two different tables hey? As if that's ever gonna happen :-( Yep ACID eh; what's it all about? Certainly those in HP that are now forcing the Waste of Substantial Investment in Technology down your throats don't give a Monkey's about it. But WS-AT was never really meant to accurately model the brave new world of the Net now was it? Yep Business Activity transactions (and trying stuff the genie back in the bottle) are right up UNIX's street! But too answer your question, you could: - 1) Buy RMS jounalling (I agree it should've been bundled) 2) Buy Rdb 3) Buy Oracle Obviously 2 and 3 have their own transactions but with DECdtm you can encompass updates to all three data sources within the ACID properties of a true 2PC. And with hotTIP you can use Microsoft's MTS/DTC as the coordinator to steatch that 2PC transaction to Oracle or SQL Server on a Windows domain. Also, thanks in no small part to moi, the DECdtm Branch Management services are now documented with VMS and allow you to achive parallelism with different transactions branches in different processess and pssibly machines. (Rdb engineering (it's Mugabe-esque leadership anyway) thinks this is crap and has refused to update their Guide to Distributed Transactions) Yep, Microsoft think transactions are pretty important for some reason, and have spent a lot of money on their DECdtm-copy :-( While Digital said "Piss off Jim Johnson, Steve Lionel et al, we don't need your kind here with your silly transactions. Go to Microsoft and see what we care! We've forced a succession of failed products (Rally, DECForms, DECAdmire, ONC/RPC, DCE/RPC, COM, ACMSxp, BridgeBloodyWorks, Forte (and now it's WSIT and AXIS and Tomcat and making VMS quack like a penguin)) down the throats of our long-suffering VMS client base and yet somehow managed to keep our jobs! Yep, we're feeling pretty invulnerable at the moment, so bugger the lot of ya! Cheers Richard Maher "John Reagan" wrote in message news:fahuqe$toi$1@usenet01.boi.hp.com... > Paul Raulerson wrote: > > I posted this question in another, but I figured someone here might > > have a good idea they were willing to share. > > > > > > Most COBOL implementations provide a > > BEGIN TRANSACTION > > COMMIT/ROLLBACK > > construct. > > > > I have a need to update several files, all of which much be sucessful or all of which much be rolled back, which would normally be easily handled by the above COBOL construct. > > > > Suggestions have ranged from using RMS Journaling, to the HP transaction manager, to using a database for transaction managemen. All of these suggestions would mostly likely work, but they add cost. I have no idea of the magnitude of that cost though. I'm also trying to avoid adding a database because of the overhead (physcial and management) as well as the cost. > > > > Does anyone have a rough idea just how much cost the RMS or transaction manager solution adds to the end user on a small machine? Assuming I pass it on to the end-user directly "at cost." > > > > Or if John R. is reading this - any plans to add transaction management directly into the compiler? Or is there transaction management built into Pascal or Fortran that I can use to manage this? This cannot be an unusual situation, especially with VMS being used in financial markets. > > > > Yep, I'm reading this (as well as the ITRC discussion). No, we don't > have any COMMIT like feature in our compilers. No current plans for > adding them. > > The underlying RMS journalling and/or DDTM services are probably the > best you are going to get. If we were to add some COMMIT feature to > COBOL those are the services we'd use. > > -- > John Reagan > OpenVMS Pascal/Macro-32/COBOL Project Leader > Hewlett-Packard Company ------------------------------ Date: Wed, 22 Aug 2007 19:41:52 -0500 From: "Paul Raulerson" Subject: RE: COBOL Transactions? Message-ID: <005401c7e51e$6680b8c0$33822a40$@com> > -----Original Message----- > From: Richard B. Gilbert [mailto:rgilbert88@comcast.net] > Sent: Wednesday, August 22, 2007 3:42 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: COBOL Transactions? > > Paul Raulerson wrote: > > I posted this question in another, but I figured someone here might > > have a good idea they were willing to share. > > > > > > Most COBOL implementations provide a > > BEGIN TRANSACTION > > COMMIT/ROLLBACK > > construct. > > > > I have a need to update several files, all of which much be sucessful > or all of which much be rolled back, which would normally be easily > handled by the above COBOL construct. > > > > Suggestions have ranged from using RMS Journaling, to the HP > transaction manager, to using a database for transaction managemen. All > of these suggestions would mostly likely work, but they add cost. I > have no idea of the magnitude of that cost though. I'm also trying to > avoid adding a database because of the overhead (physcial and > management) as well as the cost. > > > > Does anyone have a rough idea just how much cost the RMS or > transaction manager solution adds to the end user on a small machine? > Assuming I pass it on to the end-user directly "at cost." > > > > Or if John R. is reading this - any plans to add transaction > management directly into the compiler? Or is there transaction > management built into Pascal or Fortran that I can use to manage this? > This cannot be an unusual situation, especially with VMS being used in > financial markets. > > > > I'm also open to "sneaky tricks" from the past on how to do this > safely without the added expense. > > > > Thanks > > -Paul > > > > > > This sounds a hell of a lot like "two phase commit" which was added to > RMS about 13 years ago as I recall. IIRC it writes the transaction > details to a journal first, then updates the files and finally erases > the journal entry or marks it "done" or some such. > > For further details, RTFM. So new? No wonder it isn't in the compilers! -Paul ------------------------------ Date: Wed, 22 Aug 2007 19:41:00 -0500 From: "Paul Raulerson" Subject: RE: COBOL Transactions? Message-ID: <005301c7e51e$472eaf90$d58c0eb0$@com> > -----Original Message----- > From: John Reagan [mailto:john.reagan@hp.com] > Sent: Wednesday, August 22, 2007 1:19 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: COBOL Transactions? > > Paul Raulerson wrote: > > I posted this question in another, but I figured someone here might > > have a good idea they were willing to share. > > > > > > Most COBOL implementations provide a > > BEGIN TRANSACTION > > COMMIT/ROLLBACK > > construct. > > > > I have a need to update several files, all of which much be sucessful > or all of which much be rolled back, which would normally be easily > handled by the above COBOL construct. > > > > Suggestions have ranged from using RMS Journaling, to the HP > transaction manager, to using a database for transaction managemen. All > of these suggestions would mostly likely work, but they add cost. I > have no idea of the magnitude of that cost though. I'm also trying to > avoid adding a database because of the overhead (physcial and > management) as well as the cost. > > > > Does anyone have a rough idea just how much cost the RMS or > transaction manager solution adds to the end user on a small machine? > Assuming I pass it on to the end-user directly "at cost." > > > > Or if John R. is reading this - any plans to add transaction > management directly into the compiler? Or is there transaction > management built into Pascal or Fortran that I can use to manage this? > This cannot be an unusual situation, especially with VMS being used in > financial markets. > > > > Yep, I'm reading this (as well as the ITRC discussion). No, we don't > have any COMMIT like feature in our compilers. No current plans for > adding them. > > The underlying RMS journalling and/or DDTM services are probably the > best you are going to get. If we were to add some COMMIT feature to > COBOL those are the services we'd use. > > -- > John Reagan > OpenVMS Pascal/Macro-32/COBOL Project Leader > Hewlett-Packard Company Well, that will have to do. I am just hoping it does not add very significant cost to the delivered product. Sometimes it seems like every dime added to the cost means 10 less sales. (*sigh*) -Paul ------------------------------ Date: Wed, 22 Aug 2007 19:50:58 -0500 From: "Paul Raulerson" Subject: RE: COBOL Transactions? Message-ID: <005901c7e51f$ab88bac0$029a3040$@com> > > The nice thing about Rdb is that for moderataly small databases, > > it's mostly a set-n-forget process. Rdb lives happily without > > a lot of "baby sitting"... > > But costs US$20K (I think) per CPU, I think, not including discounts. > > The question to ask John Reagan, I think, is if COBOL file semantics > can work in harmony with low-level RMS/DTM 2PC API calls. > > -- > Ron Johnson, Jr. > Jefferson LA USA Drat -which is of course why Hoff suggested mySQL. $20K/processor is just too much additional overhead for the majority of the market I want to target. I need to be able to deliver a low end solution in the under $10K market - and base the profit on annual support and customization costs. At the other end of the market by the way, the software is running on 50K user installations. Where they constantly scream at me to keep the processor cycles low and could I kindly keep the DASD usage as small as possible please? (*sigh*) You can't win! :) -Paul ------------------------------ Date: Wed, 22 Aug 2007 19:46:21 -0500 From: "Paul Raulerson" Subject: RE: COBOL Transactions? Message-ID: <005801c7e51f$06a4d0c0$13ee7240$@com> > -----Original Message----- > From: Jan-Erik S=C3=B6derholm [mailto:jan-erik.soderholm@telia.com] > Sent: Wednesday, August 22, 2007 5:03 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: COBOL Transactions? >=20 > Paul Raulerson wrote: > > I posted this question in another, but I figured someone here might > > have a good idea they were willing to share. > > > > > > Most COBOL implementations provide a > > BEGIN TRANSACTION > > COMMIT/ROLLBACK > > construct. > > > > I have a need to update several files, all of which much be = sucessful > or all of which much be rolled back, which would normally be easily > handled by the above COBOL construct. > > > > Suggestions have ranged from using RMS Journaling, to the HP > transaction manager, to using a database for transaction managemen. = All > of these suggestions would mostly likely work, but they add cost. I > have no idea of the magnitude of that cost though. I'm also trying to > avoid adding a database because of the overhead (physcial and > management) as well as the cost. > > > > Does anyone have a rough idea just how much cost the RMS or > transaction manager solution adds to the end user on a small machine? > Assuming I pass it on to the end-user directly "at cost." > > > > Or if John R. is reading this - any plans to add transaction > management directly into the compiler? Or is there transaction > management built into Pascal or Fortran that I can use to manage this? > This cannot be an unusual situation, especially with VMS being used in > financial markets. > > > > I'm also open to "sneaky tricks" from the past on how to do this > safely without the added expense. > > > > Thanks > > -Paul > > > > >=20 > As close to everyone as you can get that is those needs, are > probably running a proper database, preferable Rdb, of course :-) >=20 > The nice thing about Rdb is that for moderataly small databases, > it's mostly a set-n-forget process. Rdb lives happily without > a lot of "baby sitting"... >=20 > Jan-Erik. I suppose I will look at RDB; it really is just another layer of = complexity and another cost item, though I will have to compare costs = between that and RMS journaling.=20 Databases invariably seem to add overhead I just don't want to deal = with. One more piece to keep up to date, patched, licensed, maintenance, etc. It makes a huge difference in the = SMB market I want to target.=20 -Paul ------------------------------ Date: Wed, 22 Aug 2007 20:02:06 -0500 From: "Paul Raulerson" Subject: RE: COBOL Transactions? Message-ID: <005a01c7e521$39dc7860$ad956920$@com> > -----Original Message----- > From: Richard Maher [mailto:maher_rj@hotspamnotmail.com] > Sent: Wednesday, August 22, 2007 6:11 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: COBOL Transactions? > > Hi John, > > > Yep, I'm reading this (as well as the ITRC discussion). No, we don't > > have any COMMIT like feature in our compilers. No current plans for > > adding them. > > If Paul is hell bent on using COBOL verbs for transactions, isn't there > always DBMS? Oracle still support (and probably even sell it). If on > the > other hand, you/ve moved on to Relational Databases then SQL does seem > to be > the most popular DML with the usual crappy precompilers for most > languages. > (Does Orrible Oracle support the SQL Module language?) > I'm hell bent on porting 678,000+ lines of code from a mainframe and/or AS/400 environment to VMS. That SLOC count seems to keep growing as I busy myself porting away at it. The small parts in Assembler and RPG I have not even tried to address yet. They pretty obviously won't port. (*sigh*) It was startling to not find transaction support built into the language under VMS, yes. Sort of like walking into a house you want to buy and finding they forgot to include a bathroom. Very much so given the overall very high quality of the compiler in question. (And there is no doubt about it, it *is* a high quality compiler.) I admit to having IBM COBOL tunnel vision sometimes; IBM COBOL is just so darn convenient, unless of course, you need to directly twiddle bits around. Then just give up and drop into assembler to do it! Not being bundled is understandable though; I assume the RMS Dectm stuff is owned by another department than the compiler department. Just odd when viewed through COBOL tinted lenses is all. I tend to agree with a lot of your other comments, snipped for brevity in this particular reply. -Paul ------------------------------ Date: Wed, 22 Aug 2007 20:46:52 -0500 From: "Tom M" Subject: Re: COBOL Transactions? Message-ID: <46cce694$0$6472$4c368faf@roadrunner.com> "Paul Raulerson" wrote in message news:005801c7e51f$06a4d0c0$13ee7240$@com... > -----Original Message----- > From: Jan-Erik Söderholm [mailto:jan-erik.soderholm@telia.com] > Sent: Wednesday, August 22, 2007 5:03 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: COBOL Transactions? > > Paul Raulerson wrote: > > I posted this question in another, but I figured someone here might > > have a good idea they were willing to share. > > > > > > Most COBOL implementations provide a > > BEGIN TRANSACTION > > COMMIT/ROLLBACK > > construct. > > > > I have a need to update several files, all of which much be sucessful > or all of which much be rolled back, which would normally be easily > handled by the above COBOL construct. > > > > Suggestions have ranged from using RMS Journaling, to the HP > transaction manager, to using a database for transaction managemen. All > of these suggestions would mostly likely work, but they add cost. I > have no idea of the magnitude of that cost though. I'm also trying to > avoid adding a database because of the overhead (physcial and > management) as well as the cost. > > > > Does anyone have a rough idea just how much cost the RMS or > transaction manager solution adds to the end user on a small machine? > Assuming I pass it on to the end-user directly "at cost." > > > > Or if John R. is reading this - any plans to add transaction > management directly into the compiler? Or is there transaction > management built into Pascal or Fortran that I can use to manage this? > This cannot be an unusual situation, especially with VMS being used in > financial markets. > > > > I'm also open to "sneaky tricks" from the past on how to do this > safely without the added expense. > > > > Thanks > > -Paul > > > > > > As close to everyone as you can get that is those needs, are > probably running a proper database, preferable Rdb, of course :-) > > The nice thing about Rdb is that for moderataly small databases, > it's mostly a set-n-forget process. Rdb lives happily without > a lot of "baby sitting"... > > Jan-Erik. I suppose I will look at RDB; it really is just another layer of complexity and another cost item, though I will have to compare costs between that and RMS journaling. We use it with C, but there is a precompiler for COBOL. You might also want to look at Ingres (http://www.ingres.com). It should work out cheaper than Oracle or Rdb. You can download a copy from that site. Databases invariably seem to add overhead I just don't want to deal with. One more piece to keep up to date, patched, licensed, maintenance, etc. It makes a huge difference in the SMB market I want to target. -Paul ------------------------------ Date: 22 Aug 2007 22:04:51 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: RE: COBOL Transactions? Message-ID: In article <005301c7e51e$472eaf90$d58c0eb0$@com>, "Paul Raulerson" writes: >> -----Original Message----- >> From: John Reagan [mailto:john.reagan@hp.com] >> Sent: Wednesday, August 22, 2007 1:19 PM >> The underlying RMS journalling and/or DDTM services are probably the >> best you are going to get. If we were to add some COMMIT feature to >> COBOL those are the services we'd use. > Well, that will have to do. I am just hoping it does not add very > significant cost to the > delivered product. Sometimes it seems like every dime added to > the cost means > 10 less sales. (*sigh*) If I were the one making the third party business decision, I would have the code work either with or without RMS Journaling and tell the customers they can decide what level of reliability they want. ------------------------------ Date: Wed, 22 Aug 2007 22:03:14 -0500 From: "Paul Raulerson" Subject: RE: COBOL Transactions? Message-ID: <000301c7e532$25d7be90$71873bb0$@com> [SNIP SNIP SNIP] > -----Original Message----- > From: Richard Maher [mailto:maher_rj@hotspamnotmail.com] > Sent: Wednesday, August 22, 2007 6:11 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: COBOL Transactions? > [SNIP] Hey Richard, do you have a pointer to how to turn this DDTM *on*? I have found: DDTM$XA_SHUTDOWN.COM;1 DDTM$XA_STARTUP.COM;1 DDTM$XG_START_SERVER.COM;1 DECDTM$SHUTDOWN.COM;1 DECDTM$STARTUP.COM;1 and ran the DECDTM$STARTUP.com script, which seems to have succeeded. Also ran the DDTM$XG_START_SERVER.com script, and they *seem* to be running. Marked a test file with SET FILE/RU_JOURNAL and it seems to report itself correctly. Constantly get back a failure code, 933B. Ran the example script, created the files and still get the same error code. I do not know if it is a license thing or not. Show license finds the following lines, so I think it is licensed. DTM DEC 0 0 100 0.0 (none) 31-JUL-2008 RMSJNL DEC 0 0 100 0.0 (none) 31-JUL-2008 I cannot find any startup files or stuff with *RMS* in the name to run or whatever. I did scan through the manuals I could find, and the RMS Journal manual was clear that DECdtm has to be running first, but ... not really working. Advice? Pointers? Thanks -Paul ------------------------------ Date: 22 Aug 2007 22:09:31 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: RE: COBOL Transactions? Message-ID: In article <005a01c7e521$39dc7860$ad956920$@com>, "Paul Raulerson" writes: > Not being bundled is understandable though; I assume the RMS Dectm stuff is > owned by another department than the compiler department. Just odd when > viewed through COBOL tinted lenses is all. Actually, RMS journaling has always been owned by the operating system group. But it is separately licensed since it is a lot of extra work to develop it and they want to have it paid for by the customers who need that level of reliability, rather than raising the base VMS price for those who don't care. In recent memory there was an add-on product (POSIX) that was "free". When the time came to trim costs, they could not find out who was using it (if anyone) and it was dumped for future versions of VMS (although some features are now included in the C Runtime Library). ------------------------------ Date: Thu, 23 Aug 2007 03:42:23 +0000 From: "Main, Kerry" Subject: RE: COBOL Transactions? Message-ID: > -----Original Message----- > From: Paul Raulerson [mailto:paul@raulersons.com] > Sent: August 22, 2007 9:02 PM > To: Info-VAX@Mvb.Saic.Com > Subject: RE: COBOL Transactions? > > > > > -----Original Message----- > > From: Richard Maher [mailto:maher_rj@hotspamnotmail.com] > > Sent: Wednesday, August 22, 2007 6:11 PM > > To: Info-VAX@Mvb.Saic.Com > > Subject: Re: COBOL Transactions? > > > > Hi John, > > > > > Yep, I'm reading this (as well as the ITRC discussion). No, we > don't > > > have any COMMIT like feature in our compilers. No current plans > for > > > adding them. > > > > If Paul is hell bent on using COBOL verbs for transactions, isn't > there > > always DBMS? Oracle still support (and probably even sell it). If on > > the > > other hand, you/ve moved on to Relational Databases then SQL does > seem > > to be > > the most popular DML with the usual crappy precompilers for most > > languages. > > (Does Orrible Oracle support the SQL Module language?) > > > > I'm hell bent on porting 678,000+ lines of code from a mainframe and/or > AS/400 environment to VMS. That SLOC count seems to keep growing as I > busy > myself porting away at it. The small parts in Assembler and RPG I have > not > even tried to address yet. They pretty obviously won't port. (*sigh*) > Paul, You might be interested in the following .. http://www.migrationspecialties.com/Migration-RPG.html http://www.migrationspecialties.com Bruce Claremont (site owner) is a good porting resource that may be able to= assist you. Bruce has good Mainframe to OpenVMS porting experience. [snip] Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-592-4660 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT) OpenVMS - the secure, multi-site OS that just works. ------------------------------ Date: Thu, 23 Aug 2007 03:55:24 -0000 From: Hein RMS van den Heuvel Subject: Re: COBOL Transactions? Message-ID: <1187841324.903088.245580@x35g2000prf.googlegroups.com> On Aug 22, 6:41 pm, Kilgal...@SpamCop.net (Larry Kilgallen) wrote: > In article <46CC9FA4.7040...@comcast.net>, "Richard B. Gilbert" writes: : > > For further details, RTFM. > > I do not believe this is a case of Read The Fine Manual. As I read > the discussion the issues is than other Cobol implementations embed > transaction handling in the language, while VMS Cobol does not. Agreed. > Likely this is something that would have to be done by User Open > routines (I presume VMS Cobol has those) combined with explicit > calls to RMS Journaling. Disagree. RU Journalling specifically spans mutliple file. Single file is sort of easy to do. A useropen does not cut it. One needs a larger 'context' know to all files partitipating. RMS RU Journaling offers that in cooperation with the system service [$start/$end/$abort]_trans and file attributes to indicate which file participates or not. > It would be nicer if it were just a matter of compile-and-go, but > I do not know to what extent the syntax shown above is in the Cobol > standard. It almost is. But there are implementation details, notably record lock being held until transaction end. Cheers, Hein. ------------------------------ Date: Thu, 23 Aug 2007 03:49:38 -0000 From: Hein RMS van den Heuvel Subject: Re: COBOL Transactions? Message-ID: <1187840978.421774.183940@z24g2000prh.googlegroups.com> On Aug 22, 1:53 pm, "Paul Raulerson" wrote: > I posted this question in another, but I figured someone here might > have a good idea they were willing to share. > > Most COBOL implementations provide a > BEGIN TRANSACTION > COMMIT/ROLLBACK > construct. How come you appear so hung up about a few source lines? Surely a litte pre-processor can flip those lines to calls to SYS $START_TRANS in a heartbeat?! If you were NOT to use cobol native RMS FILE IO then you'd drop a lot of what cobol offers and will be adding dozens of new lines which are not in the language itself. > I have a need to update several files, all of which much be sucessful or all of which much be rolled back, which would normally be easily handled by the above COBOL construct. > And RMS RU Jurnalling will do just that. And it can be activated without changing the code one line, once you have the start/end/abort in place. > Does anyone have a rough idea just how much cost the RMS or transaction manager solution adds to the end user on a small machine? Assuming I pass it on to the end-user directly "at cost." >From what I learned you are building a product which should really exite HP OpenVMS folks offering a way to lure IBM CICS customers over. Forget about Alpha (for now). Focus on marketing for Itanium. HP ought to be very supportive on cutting a deal on the small system RMS Journaling pricing for the purpose of attrackting IBM customers and creating new OpenVMS customers. If you can offer first line operational support, then there is almost no cost to them (RMS Journalling support has been rather stable) and it offers a nice new market penetration opportunity. But this is only deemed useful to HP if you play the Itanium card. Whether you believe in Itanium or not, Wheterh Alpha might be an easier or more cost effective solution, it matter not. Itanium is probably the only thing HP would be willing to invest in. > Or if John R. is reading this - any plans to add transaction management directly into the compiler? Or is there transaction management built into Pascal or Fortran that I can use to manage this? Hmm, those remarks suggest very limited understanding of how OpenVMS works. Languages do NOT roll their own stuff. They are all just dialects to do the same thing using core functions from the kernel or run time libraries. If Pascal had 'free' transaction management, then Cobol and Fortran and Basic would also have it. Period. That's how it's done for OpenVMS. > This cannot be an unusual situation, especially with VMS being used in financial markets. Financial market applications (should) KNOW when and where to pay money for funtionality they should not attempt to create themselfs. Ttransaction processing is serious stuff, warranting serious investments. The SMB business might not be willing to make that investment. Negotiations with HP might allow you to bridge that gap. > I'm also open to "sneaky tricks" from the past on how to do this safely without the added expense. I can see the , but in my book 'sneaky' does not compute in the context of transactional consistency. > > Thanks > -Paul ------------------------------ Date: Wed, 22 Aug 2007 23:37:53 -0500 From: "Paul Raulerson" Subject: RE: COBOL Transactions? Message-ID: <000001c7e53f$5ee9a7e0$1cbcf7a0$@com> > -----Original Message----- > From: Hein RMS van den Heuvel [mailto:heinvandenheuvel@gmail.com] > Sent: Wednesday, August 22, 2007 10:50 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: COBOL Transactions? > > On Aug 22, 1:53 pm, "Paul Raulerson" wrote: > > I posted this question in another, but I figured someone here might > > have a good idea they were willing to share. > > > > Most COBOL implementations provide a > > BEGIN TRANSACTION > > COMMIT/ROLLBACK > > construct. > > How come you appear so hung up about a few source lines? > Surely a litte pre-processor can flip those lines to calls to SYS > $START_TRANS in a heartbeat?! > If you were NOT to use cobol native RMS FILE IO then you'd drop a lot > of what cobol offers and will be adding dozens of new lines which are > not in the language itself. > I'm not- the code was fairly simple to put in, just a wee bit more difficult to discern why it isn't "just working." I'm probably not being clear at the moment. I *certainly* agree about the benefits of using native COBOL over adding a database. Besides, I'm really only current on DB/2. The ingress link that was sent earlier looks really good though. Ingress was co-developed at the same time as DB/2 and it has some neat features in it still- that date back to the then. And yep - I wrote a translator that coverts IBM -> HP Cobol, for the most part. None of the screens have moved perfectly cleanly yet, but that is because it takes a lot more code to display, accept, and edit the field. That *could* be addressed with the forms packages, but they once again, add expense. > > > I have a need to update several files, all of which much be sucessful > or all of which much be rolled back, which would normally be easily > handled by the above COBOL construct. > > > > And RMS RU Jurnalling will do just that. > And it can be activated without changing the code one line, once you > have the start/end/abort in place. > I may need to chat with you or someone about that activating bit. I have not had a lot of luck finding the correct manual, especially in 8.3. Found some 7.x level manuals. > > Does anyone have a rough idea just how much cost the RMS or > transaction manager solution adds to the end user on a small machine? > Assuming I pass it on to the end-user directly "at cost." > > > >From what I learned you are building a product which should really > exite HP OpenVMS folks offering a way to lure IBM CICS customers over. > Forget about Alpha (for now). Focus on marketing for Itanium. I agree entirely. I have an Alpha right now though, and it works, and is running current level stuff. Alpha -> Itanium I can do in one of the porting sessions HP periodically gives. > HP ought to be very supportive on cutting a deal on the small system > RMS Journaling pricing for the purpose of attrackting IBM customers > and creating new OpenVMS customers. If you can offer first line > operational support, then there is almost no cost to them (RMS > Journalling support has been rather stable) and it offers a nice new > market penetration opportunity. But this is only deemed useful to HP > if you play the Itanium card. Whether you believe in Itanium or not, > Wheterh Alpha might be an easier or more cost effective solution, it > matter not. Itanium is probably the only thing HP would be willing to > invest in. I don't have any history with Alpha, so that works for me. I picked up an Alpha cheap (as in $49 off e-bay), added a Compaq HA35 drive array ($100, including shipping, again off e-bay), some memory from a broken old RS/6000 machine (free) and THEN I found out that HP was not really selling Alpha's anymore. I was not seriously convinced the port would work until I had spent a couple weeks on it. I am getting faster, though when I run into technology areas I don't know much about (ahem... RMS Journaling?! NOT in the compiler?!) I have to slow down and go study it until I am sure I understand the technology and how to use it. Newsgroup and ITRC are both invaluable resources. > > > Or if John R. is reading this - any plans to add transaction > management directly into the compiler? Or is there transaction > management built into Pascal or Fortran that I can use to manage this? > > Hmm, those remarks suggest very limited understanding of how OpenVMS > works. > Languages do NOT roll their own stuff. They are all just dialects to > do the same thing using core functions from the kernel or run time > libraries. > If Pascal had 'free' transaction management, then Cobol and Fortran > and Basic would also have it. Period. That's how it's done for > OpenVMS. > Not so. COBOL is not COBOL unless it supplies certain indexed file handling capabilities, something that is NOT true of other languages. Part of the normal COBOL thing is to supply the BEGIN TRANSACTION keywords, though it is not required in the language spec for COBOL 85. I believe it is for the new spec coming out... Of course, high end transaction systems handle this very well, usually by serializing access to file resources, and by providing true transaction. They cost though- CICS for example runs anywhere from just under a thousand dollars per month *up*. > > This cannot be an unusual situation, especially with VMS being used > in financial markets. > > Financial market applications (should) KNOW when and where to pay > money for funtionality they should not attempt to create themselfs. > Ttransaction processing is serious stuff, warranting serious > investments. > The SMB business might not be willing to make that investment. > Negotiations with HP might allow you to bridge that gap. > Yeah, well - an unhappy customer is an unhappy customer- be they SMB or Large. And SMB business's range upwards to companies with over a billion dollars in assets these days. Also, it isn't unusual for even relatively small customers to have large aggregates; for example, look at convenience stores. Individually small - in the aggregate, often pretty respectable. Moving and storage unit management is also lucrative. Admittedly, it ain't the same league as where a single sale puts one of your kids through college, but then again, those kinds of sales are few and far between, and also EXPENSIVE to close. If the transactions are not reliable, then the software just purely isn't good enough. Even for a really small business. Just because that business cannot afford a $60K hardware/software investment does not mean they should be sold inferior products. Even if it means selling on another platform. Minimum mainframe investment by the way, runs around $100K these days, even buying used gear. I need to cut that by a factor of 10 to open the lower end market. That is why I sweat even the small dollars right now. It's a tight fit. More reasonable, entry will be in the $15k region, but even at that, it's the cost of a small car, and a not insignificant investment for a small business > > I'm also open to "sneaky tricks" from the past on how to do this > safely without the added expense. > > I can see the , but in my book 'sneaky' does not compute in the > context of transactional consistency. > > I am not above "outsmarting" the common wisdom. The common wisdom *invariably* costs money! Sneaky tricks are great, so long as those tricks actually work. > > > > Thanks > > -Paul > ------------------------------ Date: 23 Aug 2007 01:51:29 +0200 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOeGER) Subject: Re: decnet startup failing Message-ID: <46cce821$1@news.langstoeger.at> In article <1187008585.718347@proxy.dienste.wien.at>, "Ferry Bolhar" writes: >"Peter 'EPLAN' LANGSTOeGER" > >> And DECnet Phase5 aka DECnet-OSI aka DECnet-Plus has also no problem >> starting after TCPIP > >Unless when running with phase-IV-compatible addresses enabled. Nope. I always used phase-IV-compatible addresses and I never had problems. -- Peter "EPLAN" LANGSTOEGER Network and OpenVMS system specialist E-mail peter@langstoeger.at A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist ------------------------------ Date: 22 Aug 2007 13:02:35 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: DECnet-Plus for a hobbyist Message-ID: In article , "Robert Jarratt" writes: > I have been trying to find something that will help me to set up just enough > DECnet to allow me to download the software to a DECserver, and connect > together a small number of VAXstations I have at home (I am already > networking with TCP/IP, but DECnet would be fun to play with too). There is > a huge amount of documentation which would take me some time to work through > and understand. The DECnet protocol is not use for DECserver downloads, so you can just skip all that. MOM/MOP is used for DECserver downloads. Older versions of MOM/MOP were managed through NCP, like DECnet Phase IV, which often leads to this confusion. Current versions of VMS provide LANCP for managing MOM/MOP, or if you use DECnet Phase IV you can still use NCP. > I tried setting it up and got as far as choosing a local namespace (seems > simple), but the next question about the location of the file stumped me > somewhat. If you're setting up a local namespace then you're using DECnet Phase V management tools which won't help you with MOM/MOP. ------------------------------ Date: Wed, 22 Aug 2007 21:18:15 +0300 From: =?ISO-8859-1?Q?Uusim=E4ki?= Subject: Re: DECnet-Plus for a hobbyist Message-ID: <46cc7de2$0$9927$9b536df3@news.fv.fi> Robert Jarratt wrote: > I have been trying to find something that will help me to set up just enough > DECnet to allow me to download the software to a DECserver, and connect > together a small number of VAXstations I have at home (I am already > networking with TCP/IP, but DECnet would be fun to play with too). There is > a huge amount of documentation which would take me some time to work through > and understand. > > Is there a resource somewhere that would allow me to get started a bit more > quickly for the sake of domestic harmony? I am thinking along the lines of > Phil Wherry's page for installing VMS. > > I tried setting it up and got as far as choosing a local namespace (seems > simple), but the next question about the location of the file stumped me > somewhat. > > Thanks > > Rob > > If you are running some older VAXstations with limited memory, I tend to suggest to run DECnet Phase IV instead of DECnet-Plus. And if your wish is to just do the basic tasks with DECnet, it will be enough. But if you want to do something advanced like running DECnet-over-IP or run a DECdns server etc, then you need to install DECnet-Plus. The net$configure procedure provides you with good default values for different parameters and you can safely use them. I think most users don't alter the parameters unless there is a really important reason. Personally I like DECnet-Plus because of its support for very detailed management of all the layers of the protocol stack. Of course it takes time to learn it, but when you know it, you have a very thorough view of what is happening in the stack and the configurability is really comprehensive. Regards, Kari ------------------------------ Date: Wed, 22 Aug 2007 21:59:29 GMT From: "Robert Jarratt" Subject: Re: DECnet-Plus for a hobbyist Message-ID: <5l2zi.43781$6z6.30018@newsfe1-gui.ntli.net> "JF Mezei" wrote in message news:39569$46cbd6ba$cef8887a$29878@TEKSAVVY.COM... > Robert Jarratt wrote: >> I have been trying to find something that will help me to set up just >> enough DECnet to allow me to download the software to a DECserver, and >> connect together a small number of VAXstations I have at home > > > Do yourself a favour and get the "real" decnet (decnet 4). It is MUCH > easier to install, configure and maintain and you won't have to fight the > osftware to find a way to elininate annoying OPCOM messages. Decnet 4 also > takes a MUCH smaller footprint on your system disk and in memory. > > It should be part of the VMS distribution CD. OK, so I switched to IV, but it looks like I don't know how to specify decnet addresses because this is how I responded to the NETCONFIG.COM: $ @netconfig.com DECnet for OpenVMS network configuration procedure This procedure will help you define the parameters needed to get DECnet running on this machine. You will be shown the changes before they are executed, in case you wish to perform them manually. What do you want your DECnet node name to be? [VLC]: VLC1 What do you want your DECnet address to be? : 1.1 Do you want to operate as a router? [NO (nonrouting)]: Do you want a default DECnet account? [NO]: Do you want a default account for the MAIL object? [YES]: Do you want a default account for the FAL object? [NO]: Do you want a default account for the PHONE object? [YES]: Do you want a default account for the NML object? [YES]: Do you want a default account for the MIRROR object? [YES]: Do you want a default account for the VPM object? [YES]: When I installed the DVNETEND license and rebooted, this is what STARTNET.COM gave me: $ @STARTNET %RUN-S-PROC_ID, identification of created process is 0000008F %NCP-W-INVPVA, Invalid parameter value , Physical address Line = SVA-0 %NCP-W-UNRCMP, Unrecognized component , Circuit Circuit = SVA-0 %NCP-I-NOINFO, No information in database %RUN-S-PROC_ID, identification of created process is 00000091 What did I do wrong? Thanks Rob ------------------------------ Date: Wed, 22 Aug 2007 17:16:11 -0500 (CDT) From: sms@antinode.org (Steven M. Schweda) Subject: Re: DECnet-Plus for a hobbyist Message-ID: <07082217161136_20200296@antinode.org> From: "Robert Jarratt" > $ @STARTNET > %RUN-S-PROC_ID, identification of created process is 0000008F > %NCP-W-INVPVA, Invalid parameter value , Physical address > Line = SVA-0 DECnet IV expects to set the physical address of the network interface according to the SCSSYSTEMID, and it can do this only if it's the first network protocol to grab the device. Thus, DECnet IV must be started before the IP stuff. The system start-up stuff tends to do it right, but if you do it manually, you need to inhibit the IP (and/or Appletalk, and/or so on) stuff until you get DECnet (IV) going. DECnet-Plus (V) doesn't care. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Wed, 22 Aug 2007 20:36:09 -0500 From: David J Dachtera Subject: Re: DECnet-Plus for a hobbyist Message-ID: <46CCE489.38A33AB4@spam.comcast.net> Robert Jarratt wrote: > > "JF Mezei" wrote in message > news:39569$46cbd6ba$cef8887a$29878@TEKSAVVY.COM... > > Robert Jarratt wrote: > >> I have been trying to find something that will help me to set up just > >> enough DECnet to allow me to download the software to a DECserver, and > >> connect together a small number of VAXstations I have at home > > > > > > Do yourself a favour and get the "real" decnet (decnet 4). It is MUCH > > easier to install, configure and maintain and you won't have to fight the > > osftware to find a way to elininate annoying OPCOM messages. Decnet 4 also > > takes a MUCH smaller footprint on your system disk and in memory. > > > > It should be part of the VMS distribution CD. > > OK, so I switched to IV, but it looks like I don't know how to specify > decnet addresses because this is how I responded to the NETCONFIG.COM: > > $ @netconfig.com > > DECnet for OpenVMS network configuration procedure > > This procedure will help you define the parameters needed to get DECnet > running on this machine. You will be shown the changes before they are > executed, in case you wish to perform them manually. > > What do you want your DECnet node name to be? [VLC]: VLC1 > What do you want your DECnet address to be? : 1.1 > Do you want to operate as a router? [NO (nonrouting)]: > Do you want a default DECnet account? [NO]: > Do you want a default account for the MAIL object? [YES]: > Do you want a default account for the FAL object? [NO]: > Do you want a default account for the PHONE object? [YES]: > Do you want a default account for the NML object? [YES]: > Do you want a default account for the MIRROR object? [YES]: > Do you want a default account for the VPM object? [YES]: > > When I installed the DVNETEND license and rebooted, this is what > STARTNET.COM gave me: > > $ @STARTNET > %RUN-S-PROC_ID, identification of created process is 0000008F > %NCP-W-INVPVA, Invalid parameter value , Physical address > Line = SVA-0 > > %NCP-W-UNRCMP, Unrecognized component , Circuit > Circuit = SVA-0 > > %NCP-I-NOINFO, No information in database > %RUN-S-PROC_ID, identification of created process is 00000091 > > What did I do wrong? Post the output of SHOW DEVICE E and maybe we can figure out where NETCONFIG made an invalid assumption. (ESA0: doesn't sound right for a VLC - I'd have expected EWA0: and EWA-0, but it's been a while). -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: Thu, 23 Aug 2007 00:52:25 +0100 From: Elliott Roper Subject: Re: Free to good home. Microvaxes, Vaxstations, Alphas Message-ID: <230820070052253169%nospam@yrl.co.uk> In article <130820070946381392%nospam@yrl.co.uk>, Elliott Roper wrote: > I have a pile of old kit waiting to go to the tip. > Phillip Helbig, as he grabbed the best stuff, convinced me I should > mention what's left in case anyone wants it. The last of it has left the building. I'm pleased to say that all the really useful bits seem to have new owners who will look after and use the dear old things. It is a bit sad to be saying goodbye to VMS (well maybe I'll crank up SIMH on a Mac if the nostalgia gets unbearable) But, hell, it *was* fun while it lasted. -- To de-mung my e-mail address:- fsnospam$elliott$$ PGP Fingerprint: 1A96 3CF7 637F 896B C810 E199 7E5C A9E4 8E59 E248 ------------------------------ Date: 22 Aug 2007 13:04:38 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Help with tracking down intrusion record logs Message-ID: In article <1187767904.199876.204390@l22g2000prc.googlegroups.com>, mcbill20@yahoo.com writes: > A few hours ago I noticed my VMS console going crazy with intrusion > messages. Someone was trying to breakin via FTP. The console messages > of course had the date/time, program (FTP), username ("administrato"), > and the remote host. When I did a "show intru" it showed some 6400 > attempts. > > I did a whois on the remote host and found it's a Dallas-based > internet hosting service using Linux servers. I sent an e-mail to the > network admin about the problem and received a request for logs so > they could take action. > > The problem is that the breakin attempts do not show up in > operator.log and now that it's several hours later I can't even do a > "show intrusion". Where are these logs kept? > > Thanks, > Bill Any operator messages from these events should be in operator.log . All security events are logged to the audit log, wherever you put that. Look at your system startup scripts to determine where you put the audit log, or the help files to find where it goes by default. ------------------------------ Date: 22 Aug 2007 13:05:48 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Help with tracking down intrusion record logs Message-ID: In article <07082207414753_20200296@antinode.org>, sms@antinode.org (Steven M. Schweda) writes: > > and SYS$MANAGER:AA.OUT has W:RE protection, so that I can easily include > it in my (non-SYSTEM) e-mail. (My own login.com also defines "AA".) Boy, am I glad you're not responsible for security on my system. I'd never make security information world readable. ------------------------------ Date: Wed, 22 Aug 2007 13:17:18 -0500 (CDT) From: sms@antinode.org (Steven M. Schweda) Subject: Re: Help with tracking down intrusion record logs Message-ID: <07082213171836_20200296@antinode.org> From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) > > and SYS$MANAGER:AA.OUT has W:RE protection, so that I can easily include > > it in my (non-SYSTEM) e-mail. (My own login.com also defines "AA".) > > Boy, am I glad you're not responsible for security on my system. I'd > never make security information world readable. I don't consider these data particularly secret, or I'd use an ACL here, too. Of course, I am the only user on this system, and I also don't consider myself to be a big security threat, but what's the worry about, stuff like, say: Security alarm (SECURITY) and security audit (SECURITY) on ALP, system id: 1119 Auditable event: Network login failure Event time: 21-AUG-2007 16:01:18.62 PID: 2021F262 Process name: TCPIP$SS_BG5702 Username: TCPIP$SSH Remote node fullname: SSH_PASSWORD:VDS145.SIVIT.ORG Remote username: SSH_50F8D093 Status: %LOGIN-F-NOTVALID, user authorization failure If it were such a big secret, I wouldn't be e-mailing it to some ISP which harbors out-of-control Windows systems. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Wed, 22 Aug 2007 21:46:07 GMT From: John Santos Subject: Re: Help with tracking down intrusion record logs Message-ID: Steven M. Schweda wrote: > From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) > > >>>and SYS$MANAGER:AA.OUT has W:RE protection, so that I can easily include >>>it in my (non-SYSTEM) e-mail. (My own login.com also defines "AA".) >> >> Boy, am I glad you're not responsible for security on my system. I'd >> never make security information world readable. > > > I don't consider these data particularly secret, or I'd use an ACL > here, too. Of course, I am the only user on this system, and I also > don't consider myself to be a big security threat, but what's the worry > about, stuff like, say: > > Security alarm (SECURITY) and security audit (SECURITY) on ALP, system id: 1119 > Auditable event: Network login failure > Event time: 21-AUG-2007 16:01:18.62 > PID: 2021F262 > Process name: TCPIP$SS_BG5702 > Username: TCPIP$SSH > Remote node fullname: SSH_PASSWORD:VDS145.SIVIT.ORG > Remote username: SSH_50F8D093 > Status: %LOGIN-F-NOTVALID, user authorization failure > > If it were such a big secret, I wouldn't be e-mailing it to some ISP > which harbors out-of-control Windows systems. > The problem, AFAIK, is that if a user gets out of sync with the prompts on a login failure, and types his password in to Username:, it will show up in the Username: field (in plain text) in this file, which, if world-readable, any enterprising nogoodnik could scrape up. I think ana/audit used to put the attempted passwords in the log, which are sometimes very interesting, but I think it no longer does this. (For example, if you see JOE_USER with 3 failed login attempts followed by a successful login, with the 3 passwords being "password", "passw0r" and "pasw0rd", it's a good guess his real password is "passw0rd". Or if you see a failed attempt by JO_USER to login with "passw0rd" followed immediately by JOE_USER logging in successfully, you can be pretty sure of the same thing. I think this is why VMS stopped displaying the failed passwords.) You can get valid usernames from successful logins. Don't know how useful this is on VMS, though, since the security is based on the password (hidden, encrypted), not the username, which is easily visible. It might help with social engineering to know a valid but obscure username. Does anyone know of any other reasons why analyze/audit's output needs to be kept secure? Or is it just on general principle? -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: Wed, 22 Aug 2007 16:59:01 -0500 (CDT) From: sms@antinode.org (Steven M. Schweda) Subject: Re: Help with tracking down intrusion record logs Message-ID: <07082216590133_20200296@antinode.org> From: John Santos > The problem, AFAIK, is that if a user gets out of sync with the prompts on a > login failure, and types his password in to Username:, it will show up in > the Username: field (in plain text) in this file, which, if world-readable, > any enterprising nogoodnik could scrape up. Could happen. Hasn't. > I think ana/audit used to put the attempted passwords in the log, which > are sometimes very interesting, but I think it no longer does this. You mean like this?: Security alarm (SECURITY) and security audit (SECURITY) on ALP, system id: 1119 Auditable event: Remote interactive login failure Event time: 22-AUG-2007 16:57:45.90 PID: 20221BB1 Process name: _RTA4: Username: SMS Terminal name: RTA4:, _RTA4:, ALP::SMS Remote node fullname: LOCAL:.ALP Remote username: SMS Status: %LOGIN-F-INVPWD, invalid password > You can get valid usernames from successful logins. [...] _Successful_ log-ins don't appear in the report. > Does anyone know of any other reasons why analyze/audit's output needs to > be kept secure? Or is it just on general principle? I haven't seen one, which is why I wasn't particularly worried about the permissive protections on this report. I normally look at the report after I extract it, and if I ever see anything worth protecting, I'll probably take some step or other to protect it. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Wed, 22 Aug 2007 22:28:59 GMT From: John Santos Subject: Re: Help with tracking down intrusion record logs Message-ID: Steven M. Schweda wrote: > From: John Santos > >>The problem, AFAIK, is that if a user gets out of sync with the prompts on a >>login failure, and types his password in to Username:, it will show up in >>the Username: field (in plain text) in this file, which, if world-readable, >>any enterprising nogoodnik could scrape up. > > > Could happen. Hasn't. > > >>I think ana/audit used to put the attempted passwords in the log, which >>are sometimes very interesting, but I think it no longer does this. > > > You mean like this?: > > Security alarm (SECURITY) and security audit (SECURITY) on ALP, system id: 1119 > Auditable event: Remote interactive login failure > Event time: 22-AUG-2007 16:57:45.90 > PID: 20221BB1 > Process name: _RTA4: > Username: SMS > Terminal name: RTA4:, _RTA4:, ALP::SMS > Remote node fullname: LOCAL:.ALP > Remote username: SMS > Status: %LOGIN-F-INVPWD, invalid password > > Well, no, not like that, because the text the user typed doesn't appear here. What I'm claiming is that in an earlier version of VMS (which could very well still be in use out there), the response to "Password:" *did* appear in the report. > >>You can get valid usernames from successful logins. [...] > > > _Successful_ log-ins don't appear in the report. > Only because you've filtered them out or have set audit/disable=logins... (The reason I'm being picky about this is because someone is sure to Google this someday, possibly in the midst of a security incident, and it would be good to have them proceed cautiously and avoid the fire-pits.) > >>Does anyone know of any other reasons why analyze/audit's output needs to >>be kept secure? Or is it just on general principle? > > > I haven't seen one, which is why I wasn't particularly worried about > the permissive protections on this report. I normally look at the > report after I extract it, and if I ever see anything worth protecting, > I'll probably take some step or other to protect it. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: Wed, 22 Aug 2007 17:12:57 -0700 From: AEF Subject: Re: Help with tracking down intrusion record logs Message-ID: <1187827977.220927.37690@e9g2000prf.googlegroups.com> On Aug 22, 2:05 pm, koeh...@eisner.nospam.encompasserve.org (Bob Koehler) wrote: > In article <07082207414753_20200...@antinode.org>, s...@antinode.org (Steven M. Schweda) writes: > > > > > and SYS$MANAGER:AA.OUT has W:RE protection, so that I can easily include > > it in my (non-SYSTEM) e-mail. (My own login.com also defines "AA".) > > Boy, am I glad you're not responsible for security on my system. I'd > never make security information world readable. You're back! I was worried after your no-content reply to Bob! :-) AEF ------------------------------ Date: Wed, 22 Aug 2007 20:42:01 -0500 From: David J Dachtera Subject: Re: Help with tracking down intrusion record logs Message-ID: <46CCE5E9.D6021DB5@spam.comcast.net> mcbill20@yahoo.com wrote: > > A few hours ago I noticed my VMS console going crazy with intrusion > messages. Someone was trying to breakin via FTP. The console messages > of course had the date/time, program (FTP), username ("administrato"), > and the remote host. When I did a "show intru" it showed some 6400 > attempts. > > I did a whois on the remote host and found it's a Dallas-based > internet hosting service using Linux servers. I sent an e-mail to the > network admin about the problem and received a request for logs so > they could take action. > > The problem is that the breakin attempts do not show up in > operator.log and now that it's several hours later I can't even do a > "show intrusion". Where are these logs kept? When you see these, SHOW INTRUSION/OUTPUT=filespec can help. -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: 22 Aug 2007 12:57:51 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Here's one for Bob (hope it makes your head spin) Message-ID: In article <1187784817.251805.122290@i13g2000prf.googlegroups.com>, ultradwc@gmail.com writes: > > I posted this awhile ago ... this should make your > head spin ... Anybody can post that stuff. Running around the modern Mt. Sinai or the suspected biblical Mt. Sinai (not the same mountain), arguing which is which, making claims about what someone sees, ... Nothing new. ------------------------------ Date: Wed, 22 Aug 2007 18:24:13 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: Here's one for Bob (hope it makes your head spin) Message-ID: In article , david20@alpha2.mdx.ac.uk writes: {...snip...} >Being prepared to suffer and die for your faith doesn't imply any validity to >that faith just that you believe in it very strongly. Death for one's faith, or in this case, truth simply won't change much. http://www.tmesis.com/slower_than_guns.html However, I'd be willing to die for the truth over some unfounded faith any day! -- 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.jpg ------------------------------ Date: Wed, 22 Aug 2007 17:21:14 -0400 From: "John Smith" Subject: Re: Here's one for Bob (hope it makes your head spin) Message-ID: Neil Rieck wrote: > Here's one for Bob. (hope it makes your head spin) > > Misquoting Jesus: The Story Behind Who Changed The Bible and Why > > When world-class biblical scholar Bart Ehrman first began to study the > texts of the Bible in their original languages he was startled to > discover the multitude of mistakes and intentional alterations that > had been made by earlier translators. In Misquoting Jesus, Ehrman > tells the story behind the mistakes and changes that ancient scribes > made to the New Testament and shows the great impact they had upon the > Bible we use today. He frames his account with personal reflections on > how his study of the Greek manuscripts made him abandon his once > ultraconservative views of the Bible. Since the advent of the printing > press and the accurate reproduction of texts, most people have assumed > that when they read the New Testament they are reading an exact copy > of Jesus's words or Saint Paul's writings. And yet, for almost fifteen > hundred years these manuscripts were hand copied by scribes who were > deeply influenced by the cultural, theological, and political disputes > of their day. Both mistakes and intentional changes abound in the > surviving manuscripts, making the original words difficult to > reconstruct. For the first time, Ehrman reveals where and why these > changes were made and how scholars go about reconstructing the > original words of the New Testament as closely as possible. Ehrman > makes the provocative case that many of our cherished biblical stories > and widely held beliefs concerning the divinity of Jesus, the Trinity, > and the divine origins of the Bible itself stem from both intentional > and accidental alterations by scribes -- alterations that dramatically > affected all subsequent versions of the Bible. > > Listen to a 53 minute interview here: > http://www.cbc.ca/tapestry/archives/2007/072207.html > > One Oxford bible scholar (John Mill) in 1707 published an in depth > 'textual analysis' of more than 100 biblical manuscripts documenting > more than 30,000 differences. > http://en.wikipedia.org/wiki/Textual_analysis > http://en.wikipedia.org/wiki/John_Mill > Since then, other bible researchers have documented more than 100,000 > differences. > > Example-1, the story of the adulterous woman brought before Jesus is > total fiction and doesn't appear in any of the earliest manuscripts. > It was added by scribes who knew exactly what they were doing. > > Example-2, every last page (codex) of the Book of Revelation was > missing when St Jerome was working on the Latin Vulgate so he just > read a bunch of Greek manuscripts (which were mostly different) and > then translated the average meaning back into latin. (so much for all > the people who labor over every word in this strange book) > > Example-3, everyone today loves the King James Version but it appears > that this book is based upon a 12th century manuscript that just might > have been the worst choice for a bible (but there were not many others > available in Western Europe at the time) > > Food for thought: If the bible is the inspired word of God then why > did he allow all these people to mess around with it? Or, from what I > can see (I just finished reading the book) he seems to have gone out > of his way to make sure we can never get a glimpse of the original > text. > > NSR Sounds like the bible was written by a committee - and we all know how good a job committee's do with anything ;-) Not that I'm for religion in any way, but I'm prepared to tolerate it in others so long as they keep it to themselves. -- OpenVMS - The never-advertised operating system with the dwindling ISV base. ------------------------------ Date: Thu, 23 Aug 2007 00:45:41 -0000 From: ultradwc@gmail.com Subject: Re: Here's one for Bob (hope it makes your head spin) Message-ID: <1187829941.906578.232570@z24g2000prh.googlegroups.com> On Aug 21, 11:38 pm, Neil Rieck wrote: > > Example-3, everyone today loves the King James Version but it appears > that this book is based upon a 12th century manuscript that just might > have been the worst choice for a bible (but there were not many others > available in Western Europe at the time) > > Food for thought: If the bible is the inspired word of God then why > did he allow all these people to mess around with it? Or, from what I > can see (I just finished reading the book) he seems to have gone out > of his way to make sure we can never get a glimpse of the original > text. well these links seem to shot holes in your misguided theory ... http://odyssey.lib.duke.edu/papyrus/texts/manuscripts.html http://theologos.net/NTpapyrus.html http://www.prophecyinthenews.com/articledetail.asp?Article_ID=72 ------------------------------ Date: Thu, 23 Aug 2007 01:06:09 -0000 From: ultradwc@gmail.com Subject: Re: Here's one for Bob (hope it makes your head spin) Message-ID: <1187831169.198101.123780@j4g2000prf.googlegroups.com> On Aug 21, 11:38 pm, Neil Rieck wrote: > > Example-3, everyone today loves the King James Version but it appears > that this book is based upon a 12th century manuscript that just might > have been the worst choice for a bible (but there were not many others > available in Western Europe at the time) > > Food for thought: If the bible is the inspired word of God then why > did he allow all these people to mess around with it? Or, from what I > can see (I just finished reading the book) he seems to have gone out > of his way to make sure we can never get a glimpse of the original > text. > > NSR and here are some more ... your false assertions are revealed as just that ... FALSE! http://www.consider.org/library/text.htm http://www.entheology.org/library/winters/NEWTEST2.TXT http://www.religion-online.org/showarticle.asp?title=91 http://www.biblicaldefense.org/Writings/new_testament_reliability.htm http://home.houston.rr.com/apologia/sec5p4.htm ------------------------------ Date: Wed, 22 Aug 2007 19:55:20 -0700 From: Neil Rieck Subject: Re: Here's one for Bob (hope it makes your head spin) Message-ID: <1187837720.640611.243850@q3g2000prf.googlegroups.com> On Aug 22, 9:06 pm, ultra...@gmail.com wrote: > On Aug 21, 11:38 pm, Neil Rieck wrote: > Any idiot can set up a website which can be used by others as proof. It is hardly what any rational person would accept as peer-reviewed literature. Why not try reading the book "Misquoting Jesus: The Story Behind Who Changed The Bible and Why" (which was peer-reviewed by the way) then get back to me. The proof laid out in this book shows that a majority of very early Biblical manuscripts are different. If you're going to believe in something you had better be aware of the warts and all. p.s. as an aside, reading the book has not changed "MY" belief in Christianity. In fact, it has cleared what I saw as a few inconsistancies. YMMV NSR ------------------------------ Date: Wed, 22 Aug 2007 18:01:10 -0700 From: "dpm_google@myths.com" Subject: is this a race condition? Message-ID: <1187830870.915352.211590@e9g2000prf.googlegroups.com> 23 years ago, fresh out of university, my first job was maintaining FORTRAN on a VAX. Last month I started a new job, and I am . . . maintaining FORTRAN on a VAX. (sigh) The operating-system part is nice, the language is not. Check this out: SUBROUTINE FOREVER IMPLICIT NONE INTEGER*4 I INTEGER*4 STATUS INTEGER*2 IOSB(4) INTEGER*2 READCHAN INTEGER*2 WRITECHAN LOGICAL*1 MORE BYTE READBUFFER(64) BYTE WRITEBUFFER(32) STATUS = SYS$CREMBX(,READCHAN,%VAL(64),%VAL(128),,,'MYMBX') IF (.NOT. STATUS) THEN LIB$SIGNAL(%VAL(STATUS), %VAL(0)) STATUS = SYS$ASSIGN('YOURMBX',WRITECHAN) IF (.NOT. STATUS) THEN LIB$SIGNAL(%VAL(STATUS), %VAL(0)) WHILE (.TRUE.) STATUS = SYS$QIOW(,%VAL(READCHAN),%VAL(IO$_READVBLK),IOSB,,, %REF(READBUFFER),%VAL(64),,,,) IF (STATUS) THEN IF (IOSB(1)) THEN MORE = .TRUE. WHILE (MORE) FOR I=1,READBUFFER(4) IF (something) THEN MORE = .FALSE. END END STATUS = SYS$QIO(,%VAL(WRITECHAN),%VAL(IO$_WRITEVBLK .OR. IO$M_NOW),IOSB,,, %REF(WRITEBUFFER),%VAL(32),,,,) IF (.NOT. STATUS) THEN LIB$SIGNAL(%VAL(STATUS), %VAL(0)) ENDIF ENDIF END This particular bit of code went into an infinite loop today. I admit I've abstracted a lot of specifics but the gist remains, so please don't wonder about the nested WHILE and FOR that seem to be pointless, they're actually fine. The crucial point is that the inner test is assumed to be guaranteed --- i.e., eventually the "something" will be true, causing the WHILE to exit. Well, today it didn't, and my main suspicion is a possible race condition resulting from two perfectly valid I/Os. Does anyone else see it? ok dpm ------------------------------ Date: Wed, 22 Aug 2007 20:24:35 -0500 (CDT) From: sms@antinode.org (Steven M. Schweda) Subject: Re: is this a race condition? Message-ID: <07082220243563_20200296@antinode.org> From: "dpm_google@myths.com" > SUBROUTINE FOREVER > [...] > I admit I've abstracted a lot of specifics [...] Too many for my feeble brain, but I notice that the first QIO is a QIOW, while the second one is not, and I don't see where its IOSB is checked for the final status value. And if the first QIOW gets a good STATUS but a bad IOSB(1), I don't see what stops it. I'd vote for more careful status checking, especially in the IOSB(s). ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Wed, 22 Aug 2007 18:55:40 -0700 From: Bob Gezelter Subject: Re: is this a race condition? Message-ID: <1187834140.971153.295890@q4g2000prc.googlegroups.com> On Aug 22, 9:01 pm, "dpm_goo...@myths.com" wrote: > 23 years ago, fresh out of university, my first job was maintaining > FORTRAN on a VAX. > Last month I started a new job, and I am . . . maintaining FORTRAN on > a VAX. (sigh) > The operating-system part is nice, the language is not. Check this > out: > > SUBROUTINE FOREVER > > IMPLICIT NONE > > INTEGER*4 I > INTEGER*4 STATUS > INTEGER*2 IOSB(4) > INTEGER*2 READCHAN > INTEGER*2 WRITECHAN > LOGICAL*1 MORE > BYTE READBUFFER(64) > BYTE WRITEBUFFER(32) > > STATUS = SYS$CREMBX(,READCHAN,%VAL(64),%VAL(128),,,'MYMBX') > IF (.NOT. STATUS) THEN LIB$SIGNAL(%VAL(STATUS), %VAL(0)) > STATUS = SYS$ASSIGN('YOURMBX',WRITECHAN) > IF (.NOT. STATUS) THEN LIB$SIGNAL(%VAL(STATUS), %VAL(0)) > > WHILE (.TRUE.) > STATUS = SYS$QIOW(,%VAL(READCHAN),%VAL(IO$_READVBLK),IOSB,,, > %REF(READBUFFER),%VAL(64),,,,) > IF (STATUS) THEN > IF (IOSB(1)) THEN > MORE = .TRUE. > WHILE (MORE) > FOR I=1,READBUFFER(4) > IF (something) THEN MORE = .FALSE. > END > END > STATUS = SYS$QIO(,%VAL(WRITECHAN),%VAL(IO$_WRITEVBLK .OR. > IO$M_NOW),IOSB,,, > %REF(WRITEBUFFER),%VAL(32),,,,) > IF (.NOT. STATUS) THEN LIB$SIGNAL(%VAL(STATUS), %VAL(0)) > ENDIF > ENDIF > END > > This particular bit of code went into an infinite loop today. > I admit I've abstracted a lot of specifics but the gist remains, > so please don't wonder about the nested WHILE and FOR > that seem to be pointless, they're actually fine. The crucial > point is that the inner test is assumed to be guaranteed --- > i.e., eventually the "something" will be true, causing the WHILE > to exit. Well, today it didn't, and my main suspicion is a > possible race condition resulting from two perfectly valid I/Os. > Does anyone else see it? > > ok > dpm dpm, I would not consider the language an issue. The features that attract my eye on first glance would be essentially the same in any language (down to and including MACRO-32). In addition to the QIO/QIOW problem cited earlier in this thread, I would be concerned about the use of a default event flag. In particular, WAIT operations are on an event flag, not anything else. If two things use the event flag, then they will both release. In this case, I wonder if the QIO is resulting in the event flag being tripped at an odd moment. Other things may have been deleted from the code during the abstraction process, but that does look suspicious to my eye (fair warning: I am writing this following a 16+hour day). - Bob Gezelter, http://www.rlgsc.com ------------------------------ Date: Wed, 22 Aug 2007 19:04:08 -0700 From: "dpm_google@myths.com" Subject: Re: is this a race condition? Message-ID: <1187834648.077914.313130@j4g2000prf.googlegroups.com> On Aug 22, 9:55 pm, Bob Gezelter wrote: > I would not consider the language an issue. The features that attract > my eye on first glance would be essentially the same in any language > (down to and including MACRO-32). I will not rant about C being better than FORTRAN. I will not rant about C being better than FORTRAN. I will not rant about C being better than FORTRAN. . . . > In addition to the QIO/QIOW problem cited earlier in this thread, I > would be concerned about the use of a default event flag. In > particular, WAIT operations are on an event flag, not anything else. > If two things use the event flag, then they will both release. In this > case, I wonder if the QIO is resulting in the event flag being tripped > at an odd moment. That is _exactly_ what I'm thinking. Both operations are using the same event flag (zero) and the same area of memory as their I/O status block, so if the WRITEVBLK happens to delay completing until the READVBLK has been queued, the QIO() will cause the QIOW() to return even though no read has actually occurred. At that point the data in the read- buffer being used for loop control will be zero, meaning the FOR loop is never entered, causing MORE to remain .TRUE. . . . voila! infinite loop. It's easy enough to fix, of course, if that's the real problem. I can't think of a way to test it, though. Thanks for the help, Bob and Steven. ok dpm ------------------------------ Date: Thu, 23 Aug 2007 04:09:04 -0000 From: Hein RMS van den Heuvel Subject: Re: is this a race condition? Message-ID: <1187842144.920556.275800@i38g2000prf.googlegroups.com> On Aug 22, 10:04 pm, "dpm_goo...@myths.com" wrote: > On Aug 22, 9:55 pm, Bob Gezelter wrote: > > > I would not consider the language an issue. The features that attract > > my eye on first glance would be essentially the same in any language > > (down to and including MACRO-32). > > I will not rant about C being better than FORTRAN. > I will not rant about C being better than FORTRAN. > I will not rant about C being better than FORTRAN. > . > . > . > > > In addition to the QIO/QIOW problem cited earlier in this thread, I > > would be concerned about the use of a default event flag. In > > particular, WAIT operations are on an event flag, not anything else. > > If two things use the event flag, then they will both release. In this > > case, I wonder if the QIO is resulting in the event flag being tripped > > at an odd moment. > > That is _exactly_ what I'm thinking. Both operations are using the > same > event flag (zero) and the same area of memory as their I/O status > block, > so if the WRITEVBLK happens to delay completing until the READVBLK > has been queued, the QIO() will cause the QIOW() to return even though > no read has actually occurred. At that point the data in the read- > buffer > being used for loop control will be zero, meaning the FOR loop is > never > entered, causing MORE to remain .TRUE. . . . voila! infinite loop. > > It's easy enough to fix, of course, if that's the real problem. I > can't > think of a way to test it, though. > > Thanks for the help, Bob and Steven. > > ok > dpm In addition... in the code as posted, if status from the first qio is ever false (bad channel, quota) then it will also loop as true remains true. Of course that could easily be a consequence of overly excessive code path reduction for purpose of sharing here, leaving out a signal on the else branch. fwiw, Hein. ------------------------------ Date: 23 Aug 2007 04:47:34 GMT From: "dave weatherall" Subject: Re: Looking for SEDT source code Message-ID: <5j4hr6F3ss1c5U1@mid.individual.net> Paul McIlfatrick wrote: > > I'll check. I think the one I have was from Anker's site, which > > seems not to be working now. If not I'll mail you a copy. The > > source is in > > What do you know - following my original post Anker Berg-Sonne > e-mailed me! > > He has made his source code available to me and I have now downloaded > it. > > Asked about the status of his source code, Anker replied "You can do > anything you want with the source code. I stopped working on Sedt > many years ago (probably a mistake, but too late now), and just wish > that the work benefits as many as possible." > > Also, he has OKed making his e-mail address available. > > It is: bostonsearover gmail com > > > Regards > > > Paul Thanks Paul. I'll drop him a line. -- Cheers - Dave ------------------------------ Date: Wed, 22 Aug 2007 15:57:05 -0700 From: Sue Subject: OpenVMS Customer Lab Message-ID: <1187823425.307850.54310@q3g2000prf.googlegroups.com> Dear Newsgroup, I emailed this a few minutes ago and since the topic of migrations has come up here I wanted to make sure you were aware of the lab. Warm Regards as always, Sue ----------- Dear Distribution Lists, The OpenVMS Group has a wonderful tool in its arsenal that you may not be aware of. This is the OpenVMS Customer Lab. The Customer Lab has recently been moved and remodeled so along with an amazing team of technical resources and new hardware and software the Customer Lab is open and ready for your use. Enclosed is information about the customer lab which you will find useful. If you have additional questions please send email to either Roxanne Young (Roxanne.Young@hp.com) or John Egolf (John.Egolf@hp.com) Congratulations to the Customer Lab Team. Warm Regards, Sue ------------------------- OpenVMS Customer Lab The OpenVMS Customer Lab is located in Nashua, New Hampshire, at the HP Spit Brook Road facility. The lab is a dedicated lab that offers a secure application-testing environment. It is designed to provide OpenVMS partners, ISV's, and customers access to the cutting edge technology developed by Hewlett-Packard and the OpenVMS Engineering Group. With access to hardware, software, and engineering resources for pre-scheduled amounts of time, guests are able to stage their applications in a controlled environment before going live in their own production environments. Typical engagements include... Porting to Integrity - Create a side by side environment of your Alpha and Integrity configuration and have the experts close by to assist as needed to answer your questions and look over your shoulder Validation of solutions on new hardware or a new version of the operating system - will my solution work as expected on the new platform? How about mixed architecture clusters? Performance characterization - how will my solution perform on an 8P system? 16P, 32P or 64P system? How does memory effect performance? Proof of Concept - configure an environment that closely resembles the actual desired configuration and validate solution before purchasing equipment OpenVMS Porting Workshops We offer, to qualified customers and partners, a 2-3 day workshop where you can bring all your sources, build files, data files, etc. We will provide an Integrity Server for your use and assist you in the porting of your code to OpenVMS Integrity. The workshops, provided in Nashua NH, make use of the vast OpenVMS engineering expertise available for assistance. We have had many successes with this program and customers have walked away after only 2 days with their solution completely ported from Alpha to Integrity. ------------------------------ Date: Thu, 23 Aug 2007 00:06:28 +0000 (UTC) From: david20@alpha2.mdx.ac.uk Subject: Re: Peer review (was Re: Wisconsin professor says global warming a hoax!) Message-ID: In article , John Santos writes: >david20@alpha2.mdx.ac.uk wrote: >> In article , Ron Johnson writes: >> >>>On 08/21/07 22:07, Neil Rieck wrote: >>>[snip] >>> >>>>As an aside, let us all remember that 400 years ago most people >>>>believed the Sun moved around the Earth. Some people may still believe >>>>this today but the majority of educated people know it is the other >>>>way around. It was mathematicians and astronomers who first learned >>>>the new truth but it took a while to ripple into other scientific >>>>disciplines. So when greater than 95% of the peer reviewed >>>>climatologists say that global warming is real AND that mankind's >>> >>>The problem is that humans (and scientists *are* human) prefer >>>orthodoxy, and peer review is the *perfect* guardian of scientific >>>orthodoxy. >>> >> >> Except of course thirty years ago the scientific orthodoxy was worrying about >> an imminent ice age. > >This statement is not true. In the late 70's a small minority of climate >scientists were speculating about this, but it was never "orthodoxy". > The prevailing opinion at that time was that the average interglacial lasted about 11000 years and since the start of the current interglacial was 11500 years ago we were rapidly approaching the onset of a new ice age. Later evidence from ice cores showed that interglacials could last much longer and it has been argued that the current interglacial may be more analagous to a previous one which lasted around 30000 years. see http://news.bbc.co.uk/1/hi/sci/tech/4081541.stm http://www.bbc.co.uk/weather/features/understanding/iceage_01.shtm http://www.geography-site.co.uk/pages/physical/glaciers/iceage.html and http://www.msnbc.msn.com/id/5174246/ So yes I think it is fair to say that the orthodoxy in the 1970s was that the next ice age was due. David Webb Security team leader CCSS Middlesex University >"Orthodoxy" is of course a loaded word, since it means something entirely >different in science than it does in a religious context. > > > Global warming has only become the scientific orthodoxy >> relatively recently. As you imply with your "peer review is the *perfect* >> guardian of scientific orthodoxy" science tends to be conservative and only >> changes to a new orthodox position when the evidence supporting the new >> position and undermining the old orthodoxy is fairly massive. >> >> David Webb >> Security team leader >> CCSS >> Middlesex University >> >> >> >>>-- >>>Ron Johnson, Jr. >>>Jefferson LA USA >>> >>>Give a man a fish, and he eats for a day. >>>Hit him with a fish, and he goes away for good! > > >-- >John Santos >Evans Griffiths & Hart, Inc. >781-861-0670 ext 539 ------------------------------ Date: Wed, 22 Aug 2007 22:02:17 GMT From: John Santos Subject: Re: Peer review (was Re: Wisconsin professor says global warming a hoax!) a hoax Message-ID: david20@alpha2.mdx.ac.uk wrote: > In article , Ron Johnson writes: > >>On 08/21/07 22:07, Neil Rieck wrote: >>[snip] >> >>>As an aside, let us all remember that 400 years ago most people >>>believed the Sun moved around the Earth. Some people may still believe >>>this today but the majority of educated people know it is the other >>>way around. It was mathematicians and astronomers who first learned >>>the new truth but it took a while to ripple into other scientific >>>disciplines. So when greater than 95% of the peer reviewed >>>climatologists say that global warming is real AND that mankind's >> >>The problem is that humans (and scientists *are* human) prefer >>orthodoxy, and peer review is the *perfect* guardian of scientific >>orthodoxy. >> > > Except of course thirty years ago the scientific orthodoxy was worrying about > an imminent ice age. This statement is not true. In the late 70's a small minority of climate scientists were speculating about this, but it was never "orthodoxy". "Orthodoxy" is of course a loaded word, since it means something entirely different in science than it does in a religious context. Global warming has only become the scientific orthodoxy > relatively recently. As you imply with your "peer review is the *perfect* > guardian of scientific orthodoxy" science tends to be conservative and only > changes to a new orthodox position when the evidence supporting the new > position and undermining the old orthodoxy is fairly massive. > > David Webb > Security team leader > CCSS > Middlesex University > > > >>-- >>Ron Johnson, Jr. >>Jefferson LA USA >> >>Give a man a fish, and he eats for a day. >>Hit him with a fish, and he goes away for good! -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: Wed, 22 Aug 2007 21:02:23 -0400 From: Bob Willard Subject: Re: Peer review (was Re: Wisconsin professor says global warming a hoax!) a hoax Message-ID: Ron Johnson wrote: > Einstein was a Mathmetician, not a Physicist. Albert Einstein was both. In 1896, he entered the Swiss Federal Polytechnic School in Zurich to be trained as a teacher in physics and mathematics. He was a Professor of Theoretical Physics at Prague, and he was (later) a Professor of Theoretical Physics at Princeton. And, of course, he was awarded a Nobel Prize in Physics in 1921. -- Cheers, Bob ------------------------------ Date: 23 Aug 2007 04:58:19 GMT From: "dave weatherall" Subject: Re: Peer review (was Re: Wisconsin professor says global warminga hoax!) Message-ID: <5j4ifaF3r24voU1@mid.individual.net> Bob Willard wrote: > Ron Johnson wrote: > > > Einstein was a Mathmetician, not a Physicist. > > Albert Einstein was both. In 1896, he entered the Swiss > Federal Polytechnic School in Zurich to be trained as a > teacher in physics and mathematics. He was a Professor of > Theoretical Physics at Prague, and he was (later) a > Professor of Theoretical Physics at Princeton. And, of > course, he was awarded a Nobel Prize in Physics in 1921. Aha! Peer Review in operation :-) -- Cheers - Dave ------------------------------ Date: Wed, 22 Aug 2007 20:23:32 -0500 From: David J Dachtera Subject: Re: Reading non-VMS DAT tape Message-ID: <46CCE194.2189946@spam.comcast.net> rtk wrote: > > Thanks for all the helpful replies! > > I tried reading the tape as suggested and received an error about end > of file (or similar) and nothing was read. So, I decided to just > trash the tape and use it to back up the system disk. I booted the > Hobbyist CD and went to DCL and did something along these lines: > > $$$ mount dka0: > $$$ mount/foreign mka300: > $$$ backup/image/verify dka0: mka300:22_aug_07.bck/save_set > > and it appears to be working, though I'm not sure this is exactly what > I want. I got an error about the tape label and chose the OVERWRITE > option. Doing this: > > $$$ backup/image/verify dka0: mka300: > > save me an error about requiring a save set name. But, if I need to > restore my system disk at some future point I should be able to do it > from the save set after booting the Hobbyist CD, correct? Correct. Backup expects a saveset name because the default for magtape media is to write/read a saveset, and there is no way to over-ride that. -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: Wed, 22 Aug 2007 20:24:55 -0500 From: David J Dachtera Subject: Re: Reading non-VMS DAT tape Message-ID: <46CCE1E7.BC6C81EF@spam.comcast.net> rtk wrote: > > On Aug 22, 8:03 am, bri...@encompasserve.org wrote: > > I guess it's trash now and the above explanation is largely useless. > > Nope, it isn't. I have another DAT tape, plus my brother has a few he > might want read. Thanks, this is helpful. That tape was written on a > Macintosh, so heaven knows how it might be formatted. > > Also, thanks for the help on how to make the backup. I think I'll > start again once this one finishes and do as you suggested to make > sure it is a useful backup. The drive is 2.1GB in size, I hope that > fits on one tape. A note of caution about 4mm/DAT - it stretches REAL easy! Handle with care always, and don't use for archival storage. -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: Wed, 22 Aug 2007 20:31:01 -0500 From: David J Dachtera Subject: Re: Reading non-VMS DAT tape Message-ID: <46CCE355.277948A8@spam.comcast.net> AEF wrote: > > On Aug 22, 9:17 am, rtk wrote: > > Thanks for all the helpful replies! > > > > I tried reading the tape as suggested and received an error about end > > of file (or similar) and nothing was read. So, I decided to just > > trash the tape and use it to back up the system disk. I booted the > > Hobbyist CD and went to DCL and did something along these lines: > > > > $$$ mount dka0: > > $$$ mount/foreign mka300: > > $$$ backup/image/verify dka0: mka300:22_aug_07.bck/save_set > > > > and it appears to be working, though I'm not sure this is exactly what > > I want. I got an error about the tape label and chose the OVERWRITE > > option. Doing this: > > > > $$$ backup/image/verify dka0: mka300: > > > > save me an error about requiring a save set name. But, if I need to > > restore my system disk at some future point I should be able to do it > > from the save set after booting the Hobbyist CD, correct? > > > > Ron > > No save set name?! Make sure each save set on the same tape has a > different name. Otherwise you will get a mismatch during the verify > pass! And you'll have trouble selecting a save set, of course. > > Why the triple dollar signs? That's the DCL prompt in the Boot CD's "stand-alone" environment. In essence, it's a SPAWNed subprocess of the STARTUP process. In VAX-land, boot from root 1 on VMS V6.2 and later. In Alpha or I64 land, just boot up the CD. In either case, a menu of options is offered. One of the options is to execute commands. -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: Wed, 22 Aug 2007 18:27:13 -0500 From: Ron Johnson Subject: St. Linus on GPLv2, v3 & BSD licenses Message-ID: http://www.efytimes.com/archive/147/news.htm It's about half way down. Search for "Q: 386BSD". It gives his thoughts on why he likes GPLv2 better than other licenses, even though BSD has absolute freedom to use it wherever you want to. -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: 22 Aug 2007 23:36:16 GMT From: healyzh@aracnet.com Subject: Re: VMS 8.3 and TCPIP X.Y: the killer application Message-ID: Paul Raulerson wrote: > > -----Original Message----- > > From: healyzh@aracnet.com [mailto:healyzh@aracnet.com] > > Sent: Tuesday, August 21, 2007 6:15 PM > > To: Info-VAX@Mvb.Saic.Com > > Subject: Re: VMS 8.3 and TCPIP X.Y: the killer application > > > > This was why I upgraded. Some ******** was sending out spam that > > claimed to be coming from my domain. An emergency upgrade to OpenVMS > > V8.3 and TCPIP V5.6 solved the problem with all the bounces I was the > > target of. > > > > Though the problem I had was that "Symbiont-Checks-Deliverability: > > FALSE" wouldn't drop email to addresses over the legal lenght, but > > instead tried to deliver them. > I am very curious - how in the world did this solve your problem, since the > ******** was sending from some remote system and (assumedly) just forging > your return address? The fake FROM: addresses weren't valid for my server (thankfully). Ones that were short enough were dropped thanks to the "Symbiont-Checks-Deliverability: FALSE". However, an attempt to deliver any that were to long would fail, resulting in a bounce, and then I'd get a bounce back on most of those. It was ugly to say the least. Upgrading to OpenVMS V8.3 and TCPIP V5.6 with "Symbiont-Checks-Deliverability: FALSE" set meant all non-valid addresses were dropped, and peace and quite reigned. :^) It also meant that my server weathered the remainder of the mess in a much more friendly fashion. Thankfully I'd already started working towards the upgrade, so I was able to "quickly" take my system off the net and upgrade. Getting spam is bad, being the target of all the bounces from a forged FROM: address is a LOT worse. Zane ------------------------------ End of INFO-VAX 2007.461 ************************