INFO-VAX Sat, 26 May 2007 Volume 2007 : Issue 287 Contents: Re: Active Batch from Advanced Systems Concepts Re: Active Batch from Advanced Systems Concepts Re: Active Batch from Advanced Systems Concepts Re: Indexed file (RMS) IRC$V_RRV question Re: Indexed file (RMS) IRC$V_RRV question Re: Indexed file (RMS) IRC$V_RRV question Re: Indexed file (RMS) IRC$V_RRV question Re: Is VMS losing the Financial Sector, also? Re: Is VMS losing the Financial Sector, also? Re: OM Group acquired by Nasdaq - VMS probably out Re: OM Group acquired by Nasdaq - VMS probably out Re: OM Group acquired by Nasdaq - VMS probably out Re: OM Group acquired by Nasdaq - VMS probably out SYSMAN: No SYS$SCRATCH/SYS$LOGIN ? Re: SYSMAN: No SYS$SCRATCH/SYS$LOGIN ? ---------------------------------------------------------------------- Date: Fri, 25 May 2007 14:34:52 -0400 From: "Richard B. Gilbert" Subject: Re: Active Batch from Advanced Systems Concepts Message-ID: <46572C4C.4030105@comcast.net> John Vottero wrote: > "Dr. Dweeb" wrote in message > news:46560936$0$7604$157c6196@dreader2.cybercity.dk... > >> Folks, >> >> We are evaluation a product called Active Batch >> http://h21007.www2.hp.com/dspp/mop/mop_partner_product_detail_IDX/1,1331,5496,00.html >> >> for use in our Win2003AS environment. It all looks very familiar, >> like a graphical front end to the VMS queue manager, with concepts I >> know. >> >> Are there any users of the product here who would like to offer me the >> benefit of their experience with the product and equally importantly, >> their experiences when dealing with the company for support etc. >> > > I don't know anything about ActiveBatch but, I hope you'll take a look > at our competing product, JAMS. > > We've been creating enterprise grade scheduling software for over 20 > years and we're now trying to bring that expertise to the Windows > platform. JAMS for OpenVMS is still marketed, developed and supported > and I think most (all?) of our OpenVMS customers are happy (with JAMS at > least). JAMS for Windows .NET is the same basic architecture as JAMS > for OpenVMS but, it's all new code for the Windows platform. > > You can download the free Developer's Edition at: > > http://www.mvpsi.com/Free.html > > There's also a link on that page that will get you a full blown evaluation. > > Thanks for listening. > > John Vottero > JAMS Technical Support > I'll blow John's horn for him! JAMS is good stuff. I used it to do my batch scheduling for about six years. It's a joy to work with. It can parse date specifications like "Tuesday after the first Monday in November" (that's election day). You can define your own special dates and give them names; e.g. your company's fiscal calendar. You can tell it to run a job "at 6:00 PM every Thursday except Holidays". I don't think I ever encountered a scheduling problem that I couldn't solve with JAMS. It also helps with error handling and failure notification. My systems used to send E-mail to my cell phone when they needed "professional help". JAMS made that easy. It would page a developer when one of his jobs screwed up! It's a damned fine tool! Try it, you'll like it! ------------------------------ Date: Fri, 25 May 2007 23:59:30 +0200 From: "Dr. Dweeb" Subject: Re: Active Batch from Advanced Systems Concepts Message-ID: <46575c9e$0$21925$157c6196@dreader1.cybercity.dk> VAXman- @SendSpamHere.ORG wrote: > In article <46560936$0$7604$157c6196@dreader2.cybercity.dk>, "Dr. > Dweeb" writes: >> >> >> Folks, >> >> We are evaluation a product called Active Batch >> http://h21007.www2.hp.com/dspp/mop/mop_partner_product_detail_IDX/1,1331,5496,00.html >> for use in our Win2003AS environment. It all looks very familiar, >> like a graphical front end to the VMS queue manager, with concepts I >> know. >> >> Are there any users of the product here who would like to offer me >> the benefit of their experience with the product and equally >> importantly, their experiences when dealing with the company for >> support etc. >> >> Dr. Dweeb > > I wouldn't deal with the Active Batch people even if they gave me free > Active blow-jobs every hour on the hour with double-suck on holidays > and > weekends! If you would care to elaborate on that offline, I would be interested to know why. Dweeb ------------------------------ Date: Sat, 26 May 2007 01:52:59 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: Active Batch from Advanced Systems Concepts Message-ID: <00A6829F.8614E00E@SendSpamHere.ORG> In article <46575c9e$0$21925$157c6196@dreader1.cybercity.dk>, "Dr. Dweeb" writes: > > >VAXman- @SendSpamHere.ORG wrote: >> In article <46560936$0$7604$157c6196@dreader2.cybercity.dk>, "Dr. >> Dweeb" writes: >>> >>> >>> Folks, >>> >>> We are evaluation a product called Active Batch >>> http://h21007.www2.hp.com/dspp/mop/mop_partner_product_detail_IDX/1,1331,5496,00.html >>> for use in our Win2003AS environment. It all looks very familiar, >>> like a graphical front end to the VMS queue manager, with concepts I >>> know. >>> >>> Are there any users of the product here who would like to offer me >>> the benefit of their experience with the product and equally >>> importantly, their experiences when dealing with the company for >>> support etc. >>> >>> Dr. Dweeb >> >> I wouldn't deal with the Active Batch people even if they gave me free >> Active blow-jobs every hour on the hour with double-suck on holidays >> and >> weekends! > > >If you would care to elaborate on that offline, I would be interested to >know why. You know where to find me (see below). -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" ------------------------------ Date: 25 May 2007 13:05:41 -0700 From: Hein RMS van den Heuvel Subject: Re: Indexed file (RMS) IRC$V_RRV question Message-ID: <1180123541.408682.305960@p47g2000hsd.googlegroups.com> > Would this be an accurate description ? No. >> Now, after adding lots of records between A and M, it splits into buckets 1 and 2. Bucket 1 has "A", and bucket 2 has "M" and "Z". That would only happen if M + Z was as large (in compressed bytes) as A + "lots of records", because splits are simple 50/50. Still, it could happen that way, notably if just one additional record already was too much for the bucket free space. >> Bucket 1 would have an RRV record pointing to Bucket 2 It would have two of them, one for each record split. If the records were added in order A, Z, M, B, Q, P then bucket 1 would read: (1,1) A --> (1,1) (1,4) B --> (1,4) (1,3) --> (2,1) M (1,2) --> (2,2) Z and bucket 2: (2,1) M --> (1,3) (2,2) Z --> (1,2) After adding Q and P it could become: (1,1) A --> (1,1) (1,4) B --> (1,4) (1,1) --> (2,1) M (1,2) --> (2,2) Z and bucket 2: (2,1) M --> (1,1) (2,4) P --> (2,4) (2,3) --> (3,1) Q bucket 3: (3,1) Q --> (2,3) (3,2) Z --> (1,2) >> Now, if you access the file via an alternate key, you'll be told the "Z" record is at bucket 1 (its original location). WITH A SPECIFIC RECORD ID... let's say 2 in your scenario. >> RMS scans bucket 1, reaches end of bucket without finding it, but sees the RRV record pointing to bucket 2 No. That will point directly to the current location of 'Z'. So it will jump to bucket 3 >> so RMS now scans bucket 2 for the "Z" record No. Well sort of. It would not scan for "Z" but for a record with an RRV reading (1,2) This means that when 2 was split (into 2 and 3) that 1 was updated as well. A bucket split can cause dozens of write IOs in pathalogical situation. Hein. ------------------------------ Date: Fri, 25 May 2007 20:01:14 -0400 From: Bill Todd Subject: Re: Indexed file (RMS) IRC$V_RRV question Message-ID: JF Mezei wrote: ... > The way I understand it, bucket 1 contains an RRV record pointing to > bucket 2 (from the first split), and bucket 2 contains an RRV record > pointing to bucket 3 (from second split). Exactly what part of "[the RRV record] is a direct pointer to the original record in whatever bucket now contains it, wherever that bucket may be" in the post to which you are responding was too difficult for you to assimilate? - bill ------------------------------ Date: Fri, 25 May 2007 20:15:55 -0400 From: JF Mezei Subject: Re: Indexed file (RMS) IRC$V_RRV question Message-ID: Bill Todd wrote: > Exactly what part of "[the RRV record] is a direct pointer to the > original record in whatever bucket now contains it, wherever that bucket > may be" in the post to which you are responding was too difficult for > you to assimilate? I had originally been given the impression that there was to be only one RRV record per bucket and it would be at its end. Hein now explained today that there is one RRV record per former record of that bucket which has now moved to a new bucket due to a split. This changes my understanding quite a bit. I have now also checked the IRCDEF module and found that for RRV record, the overhead is 9 bytes instead of 11 for variable length records (eg: the length is not included at the end of the record header). And this changes my logic since I not only need to scan beyond an RRV record, but also advance the pointed by 2 fewer bytes for the start of the next record header. ------------------------------ Date: Fri, 25 May 2007 20:39:37 -0400 From: Bill Todd Subject: Re: Indexed file (RMS) IRC$V_RRV question Message-ID: JF Mezei wrote: > Bill Todd wrote: >> Exactly what part of "[the RRV record] is a direct pointer to the >> original record in whatever bucket now contains it, wherever that >> bucket may be" in the post to which you are responding was too >> difficult for you to assimilate? > > > I had originally been given the impression that there was to be only one > RRV record per bucket and it would be at its end. An impression which should not have persisted beyond my earlier response that "the RRV has nothing to do with finding the next bucket: its purpose is to find a record that originated in the bucket but has since moved elsewhere (and there's one for each such record)". > > Hein now explained today that there is one RRV record per former record > of that bucket which has now moved to a new bucket due to a split. This > changes my understanding quite a bit. Were you asleep when I explained that earlier (as noted above)? > > > I have now also checked the IRCDEF module and found that for RRV record, > the overhead is 9 bytes instead of 11 for variable length records (eg: > the length is not included at the end of the record header). Perhaps you were also asleep when I suggested "If the 'random' size you saw was in fact beyond the end of the valid data in the bucket (rather than any actual part of the 'record' you described), that seems the likely explanation." - bill ------------------------------ Date: 25 May 2007 13:39:19 -0700 From: Rob Fowler Subject: Re: Is VMS losing the Financial Sector, also? Message-ID: <1180125559.345619.43610@j4g2000prf.googlegroups.com> On May 25, 4:40 pm, "Dr. Dweeb" wrote: > > Shanghai is based on the Deautsche B=F6rse/Swiss Stock Exchange software,= not > OM. > No, not yet. A replacement for the existing system is an ongoing project. Shanghai A/B runs an early version of the popularl X-stream platform, a C Unix (in this case HPUX) based trading system, originally called ASTS at the time. OMX owns this platform through the aquisition of Computershare Markets Technology. ------------------------------ Date: Sat, 26 May 2007 00:10:59 +0200 From: "Dr. Dweeb" Subject: Re: Is VMS losing the Financial Sector, also? Message-ID: <46575f4f$0$21924$157c6196@dreader1.cybercity.dk> Rob Fowler wrote: > On May 25, 4:40 pm, "Dr. Dweeb" wrote: >> >> Shanghai is based on the Deautsche Börse/Swiss Stock Exchange >> software, not OM. >> > No, not yet. A replacement for the existing system is an ongoing > project. Shanghai A/B runs an early version of the popularl X-stream > platform, a C Unix (in this case HPUX) based trading system, > originally called ASTS at the time. OMX owns this platform through the > aquisition of Computershare Markets Technology. Sorry about jumping the gun. I was unaware that OM owned the incumbent system. Dweeb ------------------------------ Date: Sat, 26 May 2007 00:11:38 +0200 From: "Dr. Dweeb" Subject: Re: OM Group acquired by Nasdaq - VMS probably out Message-ID: <46575f76$0$21926$157c6196@dreader1.cybercity.dk> John Smith wrote: > http://online.wsj.com/article/SB118007353287814521.html?mod=home_whats_news_ > us > > In the article, Nasdaq's Mr. Greifeld described at a conference in > New York on Monday what he called "the magic of exchange > consolidation." > > "It's about getting to a single platform, sucking the costs out, > providing a better economic experience for your customer and a > superior return to your investors," he said. > > > According to what I hear this morning, VMS will be phased out. Bye bye Rdb! Dweeb ------------------------------ Date: Sat, 26 May 2007 00:13:23 +0200 From: "Dr. Dweeb" Subject: Re: OM Group acquired by Nasdaq - VMS probably out Message-ID: <46575fde$0$21925$157c6196@dreader1.cybercity.dk> John Smith wrote: > http://online.wsj.com/article/SB118007353287814521.html?mod=home_whats_news_ > us > > In the article, Nasdaq's Mr. Greifeld described at a conference in > New York on Monday what he called "the magic of exchange > consolidation." > > "It's about getting to a single platform, sucking the costs out, > providing a better economic experience for your customer and a > superior return to your investors," he said. > > > According to what I hear this morning, VMS will be phased out. I think the first thing to be phased out will be Magnus Böcker. Shall we open a book on how long he lasts? Dr. Dweeb ------------------------------ Date: 25 May 2007 17:30:56 -0500 From: clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) Subject: Re: OM Group acquired by Nasdaq - VMS probably out Message-ID: In article <97c47$4656dd61$cef89d8d$19181@TEKSAVVY.COM-Free>, "John Smith" writes: > > According to what I hear this morning, VMS will be phased out. > I don't suppose anyone from HP can go and have a chat ? [Or can I assume that things are too far along for this to do any good ? :-(] It's not nice been forced onto other platforms because VMS doesn't offer a competitive application portfolio anymore. :-( If we are to lose VMS, I don't suppose there's any chance that VMS technology could be contributed to other operating systems rather than seeing it be lost ? Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980's technology to a 21st century world ------------------------------ Date: Fri, 25 May 2007 20:30:31 -0400 From: Bill Todd Subject: Re: OM Group acquired by Nasdaq - VMS probably out Message-ID: Simon Clubley wrote: > In article <97c47$4656dd61$cef89d8d$19181@TEKSAVVY.COM-Free>, "John Smith" writes: >> According to what I hear this morning, VMS will be phased out. >> > > I don't suppose anyone from HP can go and have a chat ? > > [Or can I assume that things are too far along for this to do any good ? :-(] > > It's not nice been forced onto other platforms because VMS doesn't offer > a competitive application portfolio anymore. :-( > > If we are to lose VMS, I don't suppose there's any chance that VMS technology > could be contributed to other operating systems rather than seeing it be > lost ? To a large degree it already has been. Whatever patents may have existed for VAX/VMS clustering expired long ago (of course, most such technology was created before software was very patentable anyway). The VMS DLM was aped by AIX around 1994, reimplemented to a significant degree in Tru64, and IIRC at least in part open-sourced at some point (in any event, open-source clones have been created by others). Cluster implementations elsewhere in the industry don't differ from VMS's because they can't use its technology: they differ because their implementors felt that different choices were more desirable (and in at least some cases they may well have been right: there are significant performance optimizations that VMS's powerful, general, and regrettably Files-11-specific implementation makes virtually impossible - sometimes less really is more, at least for *most* workloads). There's little that's not cluster-related in VMS's file system (or in RMS) that hasn't been surpassed by better designs long ago (not that other *implementations* may be as reliable, of course). A great deal of core VMS-ness (again, at least in terms of design - though not necessarily implementation quality) has existed in Windows NT and its successors for well over a decade. VMS just doesn't have any unique technology monopoly to export any more: most of the impediments to picking up sticks and moving to a different platform are far more idiosyncratic (which is not to say minor) than fundamental. Matching the quality and integration of the environment as a whole may still be a major challenge but - again - that's not technology-related. - bill ------------------------------ Date: Fri, 25 May 2007 15:22:20 -0400 From: JF Mezei Subject: SYSMAN: No SYS$SCRATCH/SYS$LOGIN ? Message-ID: <7b251$4657378a$cef8887a$16480@TEKSAVVY.COM> $ mc sysman SYSMAN> set env/node=velo %SYSMAN-I-ENV, current command environment: Individual nodes: VELO Username JFMEZEI will be used on nonlocal nodes SYSMAN> do show log sys$scratch %SYSMAN-I-OUTPUT, command execution on node VELO %SHOW-S-NOTRAN, no translation for logical name SYS$SCRATCH SYSMAN> There is also no SYS$LOGIN defined. (VAX 7,3 and Alpha 8.3) What is the reason behind the lack of those logicals ? ------------------------------ Date: Fri, 25 May 2007 18:05:20 -0400 From: "Richard B. Gilbert" Subject: Re: SYSMAN: No SYS$SCRATCH/SYS$LOGIN ? Message-ID: <46575DA0.4030908@comcast.net> JF Mezei wrote: > $ mc sysman > SYSMAN> set env/node=velo > %SYSMAN-I-ENV, current command environment: > Individual nodes: VELO > Username JFMEZEI will be used on nonlocal nodes > > SYSMAN> do show log sys$scratch > %SYSMAN-I-OUTPUT, command execution on node VELO > %SHOW-S-NOTRAN, no translation for logical name SYS$SCRATCH > SYSMAN> > > There is also no SYS$LOGIN defined. > > (VAX 7,3 and Alpha 8.3) > > What is the reason behind the lack of those logicals ? Perhaps because LOGINOUT.EXE has not run? Those logicals are created when you log in to a node but I don't thing SYSMAN actually logs you in! ------------------------------ End of INFO-VAX 2007.287 ************************