INFO-VAX Sat, 10 Nov 2007 Volume 2007 : Issue 615 Contents: Re: "Latch" style Batch Queue Re: "Latch" style Batch Queue Re: Disbelief! ---------------------------------------------------------------------- Date: Fri, 09 Nov 2007 12:58:01 -0800 From: AEF Subject: Re: "Latch" style Batch Queue Message-ID: <1194641881.526977.166990@d55g2000hsg.googlegroups.com> On Nov 9, 8:05 am, "Richard B. Gilbert" wrote: > Michael D. Ober wrote: > > Is there a way in VMS 8.3 to create a queue that when it is started, > > will only process the jobs in the queue at the time it's started, but > > then hold any additional jobs that are submitted until it starts again. > > Basically, I need to create a queue that will accumulate jobs during the > > day and then start after the system completes database cleanups at night > > and then immediately stop. > > > Thanks, > > Mike Ober. > > Why don't you create a second batch queue that runs jobs to start and > stop the first? Or, if there is some reason not to create a second > queue ISTR that the RUN command can be used to run things at some later > time. Sorry, I'm to lazy to look it up for you unless you offer payment! Didn't you recently complain about off-topic posts and threads? Now you complain about one that's on-topic. So which do you want? Off- topic or on-topic? It's not like this newsgroup is being flooded with on-topic posts. Scare both away and there won't be much left! AEF ------------------------------ Date: Fri, 09 Nov 2007 16:23:20 -0500 From: "Richard B. Gilbert" Subject: Re: "Latch" style Batch Queue Message-ID: <4734CFC8.1040402@comcast.net> AEF wrote: > On Nov 9, 8:05 am, "Richard B. Gilbert" > wrote: > >>Michael D. Ober wrote: >> >>>Is there a way in VMS 8.3 to create a queue that when it is started, >>>will only process the jobs in the queue at the time it's started, but >>>then hold any additional jobs that are submitted until it starts again. >>>Basically, I need to create a queue that will accumulate jobs during the >>>day and then start after the system completes database cleanups at night >>>and then immediately stop. >> >>>Thanks, >>>Mike Ober. >> >>Why don't you create a second batch queue that runs jobs to start and >>stop the first? Or, if there is some reason not to create a second >>queue ISTR that the RUN command can be used to run things at some later >>time. Sorry, I'm to lazy to look it up for you unless you offer payment! > > > Didn't you recently complain about off-topic posts and threads? Now > you complain about one that's on-topic. So which do you want? Off- > topic or on-topic? It's not like this newsgroup is being flooded with > on-topic posts. Scare both away and there won't be much left! I thought I had offered at least a semi constructive reply to the original post. And if he wants me to do his work for him, the very least he can do is pay me. ------------------------------ Date: Sat, 10 Nov 2007 11:19:45 +0800 From: "Richard Maher" Subject: Re: Disbelief! Message-ID: Hi Arne, > > It is a good framework. Can't have too many of those I suppose. RoR not cutting the mustard? (Surely the "How systems are developed" debate hasn't been important (sadly) for over 15 years? If a pampered group of prima donna developers was still a must have for all the world's IT depts then why is Bangalore doing so well?) Me? I think it might have been a bit more useful to have two-phase commit functionality between SQL Server and Rdb et al on VMS and to continue COM support to COM+ all those years (*ten*) ago. But wait; ACMSxp had latent support for TIP, and Tier3 supports it now, and seven years after begging Rdb engineering to support it (and listen to their dismissive arrogance about how nobody wants it) they've suddenly "invented" 2PC interoperability with .NET. Oh well. . . > I doubt it. Too expensive. I think you drastically underestimate VMS Middle-Management's capacity for squandering license fees on hare-brained job-creation schemes such as BridgeWorks, WSIT and gSOAP. The porting of Mono to VMS would honestly be just a drop in the bucket. > So you think available apps for VMS and the numbers of VMS systems > around is going the right direction, so need to change ? No I don't. What we seem to be agreed upon is that there is a problem. It is the solution(s) that I feel must be debated more vigorously, especially given the finite funds for such endeavours; there is place for pluralism here. Try and control your Cromwellian zeal for one moment and please consider that the way forward for attracting *new* customers to VMS may well be a different path than that chosen by existing Procedural-3GL customers. It's a broad church. Please show me where I can find the list of New ISP Applications that are now being supported on VMS as a direct result of VMS's support for C, C++, Threads, POSIX, Java (speaking of money, what development price-tag would you put on that little basket of "goodies"?) I look forward to reviewing the list on a regular basis. I will also be happy to begin a list of loyal VMS customers who will choose to stay with VMS purely because Tier3 will provide them with the infrastructure needed to integrate their trusted VMS back-ends with modern, feature-rich GUIs. What none of them at HP/VMS want you to see is the breakdown ROI figures on a strategy by strategy basis. Just look at the Forms development *group*; just try and get a breakdown of the figures between FMS, TDMS, and DECforms over the years. But let me hasten to add that I am by no means appologizing to you for existing VMS software! There are miilions of lines of procedural 3GL code out there on VMS systems in financial exchanges, banks and on the factory floor. These systems are keeping these business going and are doing a fabulous job of it! And long with they continue to do it as long as their supplier stops shafting them. What's wrong with that? > The reality is that most companies are using a plethora of technologies > today and that integration is necessary. I couldn't agree more; Integration is essential to survival! Second rate emulation, on the other hand, is a waste of everyone's time and money :-( > The tools you don't like provides the necessary capabilities to do that. There are one very useful addition to the armoury, another string in the bow. "Best tool for the job" - yes? Or are we back to puritanical village- razing again? > The reasons that it is not happening is non technical. I disagree most strongly. Technical reasons are playing a huge part as well as the politics of no one in VMS middle-Management wishing to listen to the requirements of the installed base that is footing the bills for their numerous flights of fancy. Telling all of your existing customer that they need to re-tool and paradigm-shift overight is not only unbelievably arrogant and misguided, it is also financially suicidal! I don't claim to speak for *all* VMS customers, but I have developed on VMS for 25 years, at close to 20 companies, in four countries, ranging from Retailers to Telcos to Banks and I know a little bit about at least what they want (or sadly "wanted" in many cases) but then I don't get my opinions from Gartner or FHM, I wish VMS Middle-Management could say the same. Cheers Richard Maher "Arne Vajhøj" wrote in message news:472d408a$0$90275$14726298@news.sunsite.dk... > Richard Maher wrote: > > Why anyone would want .NET on VMS escapes me; > > It is a good framework. > > > The point I was trying to make was that this is exactly the type of > > Fool's-errand that VMS middle management will stump up the funds for. > > I doubt it. Too expensive. > > > Sadly, one simple fact that no one (certainly not at VMS) seems interested > > in, is that all of the VMS installed-base out there (Read: Existing > > Customers that are paying the bills) are using *Procedural* languages such > > as COBOL, BASIC, Pascal and Fortran > > So you think available apps for VMS and the numbers of VMS systems > around is going the right direction, so need to change ? > > > They do not want (feel the the need or shame) to wrapper their "legacy" > > architecture in some object-oriented ribbon just so as to make it more > > palatable (digestable) to an Apache, Tomcat, PHP, SOAP, Axis, Java > > architecture that barely runs on VMS and must've had a development-budget > > that'd make the US Defence Department blush! They don't understand the > > whole concept of WSDL and having to "Serialize" an object to a stream of > > bytes to send it over a Socket (that they could be doing themselves anyway) > > and reassemble the nodes/attributes/values on the server side only to > > flatten it out again to present it to their 3GL! They do not understand > > using > > a poorly performing connectionless page-trabsfer protocol such as HTTP > > as an application middlware backbone! (Networks are pretty unreliable > > these days eh?) > > The reality is that most companies are using a plethora of technologies > today and that integration is necessary. > > Platforms that are not integratable is a endangered species. > > > VMS still *is* the best server OS on the market! All your customers are > > crying out for (and if you ever spent any time developing "with them" rather > > than preaching "at them" you'd realize) is just a modern GUI and Webifying > > options for their existing, reliable, and high-performance servers. This has > > *never* required/mandated a complete re-tooling of their server-development > > departments or a paradigm-shift with their existing workforce. The sad truth > > is that VMS has been able to do this for years :-( > > HTML,JavaScript,CSS,Flex,Java GUI front-ends should be standard for VMS > > applications and true integration with Windows and *NIX in multi-cultural > > data centres a reality. Why is this not the case? > > The tools you don't like provides the necessary capabilities to do that. > > The reasons that it is not happening is non technical. > > Arne ------------------------------ End of INFO-VAX 2007.615 ************************