INFO-VAX Sat, 25 Aug 2007 Volume 2007 : Issue 465 Contents: ACLS and WebServers... Re: ACLS and WebServers... Re: ACLS and WebServers... Re: Alan Winston, when are you correcting your WASD book? Re: Alan Winston, when are you correcting your WASD book? Re: Alan Winston, when are you correcting your WASD book? Re: Alan Winston, when are you correcting your WASD book? Re: Alan Winston, when are you correcting your WASD book? Re: Alan Winston, when are you correcting your WASD book? 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: 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: 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: 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: DECnet-Plus for a hobbyist Re: DECnet-Plus for a hobbyist 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: How to detect duplicate auto-resubmiting batch job Re: Logical name translation under Apache New blood (was Re: COBOL Transactions?) 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: PWS500 au console transitions Re: PWS500 au console transitions Re: PWS500 au console transitions Re: Volume Shadowing Availability [OpenVMS] Context lexical functions ---------------------------------------------------------------------- Date: Fri, 24 Aug 2007 23:34:33 -0500 From: "Paul Raulerson" Subject: ACLS and WebServers... Message-ID: <009701c7e6d1$3c4bc360$b4e34a20$@com> Well, here is a totally honest question. :) Just wrote my first serious CGI-BIN program under VMS, and found that I had to do "SET SECURITY/ACL=(IDENT=APACHE$WWW,ACCESS=READ)" or variants thereof so that the program could access various data files. I had to grant read access on each directory starting at the root of the device that the web server CGI program needs access to. The question is, is there a central facility to manage these settings for all the files and users in the system, similar perhaps to RACF on a z/OS mainframe? For example, can I easily produce a list of all the files/directories that the web server has access permissions to? If not, are there good ways and methods to keep track of which files need which permissions? From a System Admin point of view I mean. Thanks -Paul ------------------------------ Date: Fri, 24 Aug 2007 23:47:32 -0500 From: Ron Johnson Subject: Re: ACLS and WebServers... Message-ID: On 08/24/07 23:34, Paul Raulerson wrote: > Well, here is a totally honest question. :) > > Just wrote my first serious CGI-BIN program under VMS, and found > that I had to do "SET > SECURITY/ACL=(IDENT=APACHE$WWW,ACCESS=READ)" or variants thereof > so that the program could access various data files. I had to > grant read access on each directory starting at the root of the > device that the web server CGI program needs access to. > > The question is, is there a central facility to manage these > settings for all the files and users in the system, similar > perhaps to RACF on a z/OS mainframe? For example, can I easily > produce a list of all the files/directories that the web server > has access permissions to? I don't have the answer, but I *can* say that this is how questions are supposed to be asked. > If not, are there good ways and methods to keep track of which > files need which permissions? From a System Admin point of view I > mean. -- 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: Sat, 25 Aug 2007 07:37:37 +0200 From: "Martin Vorlaender" Subject: Re: ACLS and WebServers... Message-ID: Paul Raulerson wrote: > Just wrote my first serious CGI-BIN program under VMS, and found thatI= had to do "SET SECURITY/ACL=3D(IDENT=3DAPACHE$WWW,ACCESS=3DREAD)" orvar= iants thereof so that the program could access various data files.I had = to grant read access on each directory starting at the root ofthe device= that the web server CGI program needs access to. Another way of doing this (other issues aside) would be to let APACHE$WWW be the owner of that directories and files, or at least have the files' owner be in the same group as APACHE$WWW. > The question is, is there a central facility to manage these settingsf= or all the files and users in the system, similar perhaps to RACF ona z/= OS mainframe? For example, can I easily produce a list of all thefiles/d= irectories that the web server has access permissions to? The decision whether a process has access to a file is a complicated one, see e.g. the OpenVMS Guide to System Security, http://h71000.www7.hp.com/doc/732FINAL/aa-q2hlg-te/00/00/39-con.html It even requires a flowchart to explain it ;-) Answering your question, I don't know of a central management facility. > If not, are there good ways and methods to keep track of which filesne= ed which permissions? > > From a System Admin point of view I mean. Set the permissions right for the top-level directory. All files created= in the directory will by default take on those permissions. For ACL-base= d security, this involves setting a default ACL on the directory. cu, Martin -- = One OS to rule them all | Martin Vorlaender | OpenVMS rules! One OS to find them | work: mv@pdv-systeme.de One OS to bring them all | http://www.pdv-systeme.de/users/martin= v/ And in the Darkness bind them.| home: martin.vorlaender@t-online.de ------------------------------ Date: Fri, 24 Aug 2007 13:09:24 -0700 From: ultradwc@gmail.com Subject: Re: Alan Winston, when are you correcting your WASD book? Message-ID: <1187986164.174446.47620@r23g2000prd.googlegroups.com> On Aug 24, 1:30 pm, ultra...@gmail.com wrote: > no wonder the WASD SSL compile failed ... > > my associate after failing with the WASD creators > instructions used Alans book ... > > well it tuns out the instructions in that book how > to configure WASD are WRONG ... > > 4.2.4 states to create a dir such as [WASD], put > the zips into it > > then > > $ unzip "-v" htrootxxx.zip > $ unzip "-v" opensslwasdxxxx > > well, it should read > > $ unzip "-v" htrootxxx.zip > $ set def [.ht_root] > $ unzip "-v" [-]opensslwasdxxx > > because then the openssl would actually load > into [WASD.HT_ROOT.SRC] instead of into > [WASD.SRC] ... > > then the install routine might actually find the > openssl source sub dir ... > > but don't feel too bad Alan, the web servers > author got his docs wrong too ... > > do you give refunds Alan? :) > > P.S. before placing your tin foil hat on Alan, be > advised that the refund line was a JOKE ... > we will commence with the rest of your book > to find out if we are getting our $60 worth ... :) also as another item, you mention CSWS requires at least 7.2-1 to run which is not the case ... we tried 1.0 on 7.1 and 1.1 also runs on 7.1 ... ------------------------------ Date: Sat, 25 Aug 2007 05:42:30 +0930 From: Mark Daniel Subject: Re: Alan Winston, when are you correcting your WASD book? Message-ID: <13cueueq00p9f00@corp.supernews.com> ultradwc@gmail.com wrote: > no wonder the WASD SSL compile failed ... > > my associate after failing with the WASD creators > instructions used Alans book ... > > well it tuns out the instructions in that book how > to configure WASD are WRONG ... Not wishing to steal Alan's thunder nor become his advocate unnecessarily but he did ask at least myself (and I suspect also David Jones, though the memory is beginning to become unreliable after six years) to proofread relevant portions of the early manuscript. I've just checked my archive of those manuscripts and that error went by me uncorrected. In a section that does have one other (minor) redline it shows: If you want SSL support, you can get precompiled binaries of current OpenSSL objects as WASDOPENSSL096C_AXP.ZIP (or WASDOPENSSL096C_VAX.ZIP). Put the zip files in a handy directory, say [WASD]. $ UNZIP "-V" HTROOT_721 $ UNZIP "-V" WASDOPENSSL096C_AXP.ZIP So yours truly shares the responsibility (but of course didn't share in the royalties :-) > 4.2.4 states to create a dir such as [WASD], put > the zips into it > > then > > $ unzip "-v" htrootxxx.zip > $ unzip "-v" opensslwasdxxxx > > well, it should read > > $ unzip "-v" htrootxxx.zip > $ set def [.ht_root] > $ unzip "-v" [-]opensslwasdxxx Yes. > because then the openssl would actually load > into [WASD.HT_ROOT.SRC] instead of into > [WASD.SRC] ... > > then the install routine might actually find the > openssl source sub dir ... > > but don't feel too bad Alan, the web servers > author got his docs wrong too ... Now not wishing to become too adversarial too early in this process the WASD documentation nowhere describes installing the WASD OpenSSL support package concurrently with a new installation, only as an update to an existing package. In fact the WASD OpenSSL kit advises (note the line beginning 'PREREQUISITE:') * SSL components of WASD ... OpenSSL 0.9.8c (5 Sep 2006) ************************************************************* * SUPPORT AND OBJECT MODULES FOR THE AXP (Alpha) PLATFORM * ************************************************************* * PREREQUISITE: basic WASD 9.n must be installed and configured. * To install files: $ SET DEFAULT HT_ROOT:[000000] $ UNZIP "-V" device:[dir]OPENSSLWASD098C-AXP.ZIP * To link images use: $ @HT_ROOT:[000000]UPDATE SSL It's considered an 'update' because right from the early days of WASD SSL support (circa 1998) SSL was considered a 'munition' by the USA and therefore a controlled export in/to some countries. For a non-USA-domestic grade encryption (40 bit) package (SSLeay was 128 bit) you had to be careful to decouple it and add it in later if you chose to. (Remember the Win32 Netscape Navigator 'hack' that upgraded it's 40 bit 'export' capability to 'domestic' grade 128 bit?) Of course this restriction was relaxed by the USA once the computing at Fort Meade no longer found 256 bit encryption a significant obstacle (think your transactions are 'secure'? - think again!) Of course you can create a new installation containing SSL support, including from the WASD SSL package. WASD installs also support other sources of SSL functionality; HP SSL (Secure Sockets Layer) for OpenVMS Alpha/Itanium/VAX product, Jean-François Piéronne OpenSSL package, as well as from an independently built OpenSSL package http://wasd.vsm.com.au/ht_root/doc/htd/htd_1800.html#hd_ssl_sources Now here is a fundamental difference between a (currently maintained) OSS package and a non- or semi- maintained commercial one ... when a problem is reported or noticed it does tend to be promptly fixed. I certainly would agree that the WASD documentation is unclear about using the WASD OpenSSL package as an input to an initial installation and that your solution shown above is the correct approach. So I've just updated the documentation sources to read (Either) UNZIP the WASD SSL package into a new installation $ SET DEFAULT [.HT_ROOT] $ UNZIP "-V" device:[dir]archive.ZIP (OR) into an existing installation $ SET DEFAULT HT_ROOT:[000000] $ UNZIP "-V" device:[dir]archive.ZIP (Yup, it's done with DECdocument.) I've also modified the WASD SSL package notes to read * To install files and build in an NEW installation: $ SET DEFAULT [.HT_ROOT] $ UNZIP "-V" device:[dir]OPENSSLWASDnnnn-AXP.ZIP $ @INSTALL * To install files and update in an EXISTING installation: $ SET DEFAULT HT_ROOT:[000000] $ UNZIP "-V" device:[dir]OPENSSLWASDnnnn-AXP.ZIP $ @UPDATE SSL So the next releases of either will contain these revisions. This is the first time someone has reported stumbling over this particular issue, perhaps this will prevent someone else doing so. > do you give refunds Alan? :) > > P.S. before placing your tin foil hat on Alan, be > advised that the refund line was a JOKE ... > we will commence with the rest of your book > to find out if we are getting our $60 worth ... :) Just keep in mind that Alan's book was written against v7.n of WASD and subsequently it has moved on to v9.n. While many fundamentals remain much the same some of the detail has certainly changed. Considering how much WASD and OpenVMS Apache have moved on since publication and how ubiquitous Web services are in modern environments I think Digital Press / Elsevier should provide an advance to Alan for a second edition. Of course now he understands how much effort it requires to undertake something like this it might need to be a large one ;-) ------------------------------ Date: Fri, 24 Aug 2007 22:00:41 GMT From: winston@SSRL.SLAC.STANFORD.EDU (Alan Winston - SSRL Central Computing) Subject: Re: Alan Winston, when are you correcting your WASD book? Message-ID: <00A6C9E8.00CAD78D@SSRL.SLAC.STANFORD.EDU> Bob wrote: In article <1187976303.792533.209020@l22g2000prc.googlegroups.com>, ultradwc@gmail.com writes: >no wonder the WASD SSL compile failed ... > >my associate after failing with the WASD creators >instructions used Alans book ... > >well it tuns out the instructions in that book how >to configure WASD are WRONG ... > >4.2.4 states to create a dir such as [WASD] > >then > >$ unzip "-v" htrootxxx.zip >$ unzip "-v" opensslwasdxxxx > >well, it should read > >$ unzip "-v" htrootxxx.zip >$ set def [.ht_root] >$ inzip "-v" [-]opensslwasdxxx "unzip", presumably. > >because then the openssl would actually load >into [WASD.HT_ROOT.SRC] instead of into >[WASD.SRC] ... > >then the install routine might actually find the >openssl source sub dir ... > >do you give refunds Alan? :) Ooh, sorry about that. I'll make a note for the errata if there's ever a second edition. (The publishers have asked for one but I have no time. Of course, by then I'll need to revisit the whole WASD section in detail; when I started writing we were in version 7, it was into 8 by the time the book came out, and it's up in the 10s somewhere. Mark keeps adding functionality.) -- Alan ------------------------------ Date: Fri, 24 Aug 2007 22:02:08 GMT From: winston@SSRL.SLAC.STANFORD.EDU (Alan Winston - SSRL Central Computing) Subject: Re: Alan Winston, when are you correcting your WASD book? Message-ID: <00A6C9E8.34581F6B@SSRL.SLAC.STANFORD.EDU> In article <1187986164.174446.47620@r23g2000prd.googlegroups.com>, ultradwc@gmail.com writes: >On Aug 24, 1:30 pm, ultra...@gmail.com wrote: >> no wonder the WASD SSL compile failed ... >> >> my associate after failing with the WASD creators >> instructions used Alans book ... >> >> well it tuns out the instructions in that book how >> to configure WASD are WRONG ... >> >> 4.2.4 states to create a dir such as [WASD], put >> the zips into it >> >> then >> >> $ unzip "-v" htrootxxx.zip >> $ unzip "-v" opensslwasdxxxx >> >> well, it should read >> >> $ unzip "-v" htrootxxx.zip >> $ set def [.ht_root] >> $ unzip "-v" [-]opensslwasdxxx >> >> because then the openssl would actually load >> into [WASD.HT_ROOT.SRC] instead of into >> [WASD.SRC] ... >> >> then the install routine might actually find the >> openssl source sub dir ... >> >> but don't feel too bad Alan, the web servers >> author got his docs wrong too ... >> >> do you give refunds Alan? :) >> >> P.S. before placing your tin foil hat on Alan, be >> advised that the refund line was a JOKE ... >> we will commence with the rest of your book >> to find out if we are getting our $60 worth ... :) > >also as another item, you mention CSWS requires >at least 7.2-1 to run which is not the case ... > >we tried 1.0 on 7.1 and 1.1 also runs on 7.1 ... > Cool! I was going by the statement of what system this is supported on. (I didn't run 7.1 very long myself, and I never even installed it on the system I bought to do webserver tests for the books, starting right at 7.2-1.) -- Alan ------------------------------ Date: 24 Aug 2007 22:38:02 GMT From: healyzh@aracnet.com Subject: Re: Alan Winston, when are you correcting your WASD book? Message-ID: Mark Daniel wrote: > Considering how much WASD and OpenVMS Apache have moved on since > publication and how ubiquitous Web services are in modern environments I > think Digital Press / Elsevier should provide an advance to Alan for a > second edition. Of course now he understands how much effort it > requires to undertake something like this it might need to be a large > one ;-) I've said it before, I'll say it again, I will buy a 2nd Edition of the book if it is ever done. I've gotten a lot of use out of the 1st Edition. Zane ------------------------------ Date: Fri, 24 Aug 2007 15:56:37 -0700 From: Rich Jordan Subject: Re: Alan Winston, when are you correcting your WASD book? Message-ID: <1187996197.671400.220420@z24g2000prh.googlegroups.com> On Aug 24, 5:00 pm, wins...@SSRL.SLAC.STANFORD.EDU (Alan Winston - SSRL Central Computing) wrote: > Bob wrote: > In article <1187976303.792533.209...@l22g2000prc.googlegroups.com>, ultra...@gmail.com writes: > >no wonder the WASD SSL compile failed ... > > >my associate after failing with the WASD creators > >instructions used Alans book ... > > >well it tuns out the instructions in that book how > >to configure WASD are WRONG ... > > >4.2.4 states to create a dir such as [WASD] > > >then > > >$ unzip "-v" htrootxxx.zip > >$ unzip "-v" opensslwasdxxxx > > >well, it should read > > >$ unzip "-v" htrootxxx.zip > >$ set def [.ht_root] > >$ inzip "-v" [-]opensslwasdxxx > > "unzip", presumably. > > > > >because then the openssl would actually load > >into [WASD.HT_ROOT.SRC] instead of into > >[WASD.SRC] ... > > >then the install routine might actually find the > >openssl source sub dir ... > > >do you give refunds Alan? :) > > Ooh, sorry about that. > > I'll make a note for the errata if there's ever a second edition. (The > publishers have asked for one but I have no time. Of course, by then I'll > need to revisit the whole WASD section in detail; when I started writing > we were in version 7, it was into 8 by the time the book came out, and it's > up in the 10s somewhere. Mark keeps adding functionality.) > > -- Alan Alan, I'm in line for an updated edition too, _when_ (not if) you get the time to do one. Yes, thats an imperative there ;) Rich ------------------------------ Date: 24 Aug 2007 17:55:58 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: COBOL Transactions? Message-ID: <5j8kddF3sj2ffU1@mid.individual.net> In article <4qEzi.90812$dI1.77306@newsfe08.phx>, Ron Johnson writes: > On 08/24/07 08:18, Bill Gunshannon wrote: >> In article , >> Ron Johnson writes: >>> On 08/23/07 20:02, Tom Linden wrote: >>>> On Thu, 23 Aug 2007 07:25:52 -0700, Ron Johnson >>>> wrote: >>>> >>>>> On 08/23/07 08:25, Tom Linden wrote: >>>>>> On Wed, 22 Aug 2007 21:37:53 -0700, Paul Raulerson >>>>>> wrote: >>>>>> >>>>>>> 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... >>>>>> Indexed file handling is in the PL/I semantics. >>>>> Yeah, but anyone in his right mind knows that PL/1 sucks. >>>>> >>>> That would be PL/I BTW, you obviously know little about programming >>>> languages. >>> So you also say that PL/I sucks? >>> >>> (Just jerking your chain, Tom, since you are such a big booster of a >>> not-so-popular-anymore language. Was it ever very popular outside >>> the mainframe?) >> >> Minicomputers. Prime used it and much of the OS and utilites was written >> in PL/1 :-) and various subset dialects. > > Prime has been dead for how many years now? 15? > >> Microcomputers. PL/M (well, it may not be PL/1, but I think it qualifies >> as a dialect.) > > Who used PL/M besides DRI? According to Wikipaedia Gary Kildall developed it for Intel, so I would guess they did. It also states, "Also the firmware of the Service Processor component of CISC AS/400 was written in PL/M." so I guess IBM was using it, too. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 24 Aug 2007 18:05:48 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: COBOL Transactions? Message-ID: <5j8kvsF3sj2ffU2@mid.individual.net> In article , Kilgallen@SpamCop.net (Larry Kilgallen) writes: > In article , "Paul Raulerson" writes: > >> COBOL (and I assume PL/I :) running under UNIX has to supply a record ori= >> ented file system layered over the UNIX filesystem. > > As do Ada implementations. > > There is a distinct problem with an operating system written by folks > who think the lowest common denominator programming language is the > only one. Once again, don't assume your worldview is the only one. The entire paradigm underlying Unix was "The Software Tools" paradigm in which things are reduced to their simplest form and complexity is created by adding layers. Thus the "pipe" concept as used by things like troff which required other utilities like col, eqn, greek and tbl in order to create more complex documents. C-ISAM was around and available for Unix since at least the early to mid 80's. I first used a database and COBOL on Unix in the mid 80's. One advantage to the Unix paradigm is you don't end out paying for features you neither need nor want. I have never used RMS on VMS. explicitly. I can't think of anything I have done that actually needed it. And don't say "you don't pay for it because it is bundled in" because you pay for everything that comes with the system wether it is listed on the invoice or not. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 24 Aug 2007 14:41:59 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: COBOL Transactions? Message-ID: In article <5j8kvsF3sj2ffU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: > In article , > Kilgallen@SpamCop.net (Larry Kilgallen) writes: >> In article , "Paul Raulerson" writes: >> >>> COBOL (and I assume PL/I :) running under UNIX has to supply a record ori= >>> ented file system layered over the UNIX filesystem. >> >> As do Ada implementations. >> >> There is a distinct problem with an operating system written by folks >> who think the lowest common denominator programming language is the >> only one. > C-ISAM was around and available for Unix since at least the early to > mid 80's. But never something one could always count on being there ? > One advantage to the Unix paradigm is you don't end out paying for > features you neither need nor want. I have never used RMS on VMS. > explicitly. I can't think of anything I have done that actually > needed it. If you write all your programs with a "stream of bytes" language, that may be the case. In my experience programs written with a "stream of bytes" mentality are a major source of lousy software. ------------------------------ Date: Fri, 24 Aug 2007 20:34:08 GMT From: John Santos Subject: Re: COBOL Transactions? Message-ID: <4hHzi.60$hV.38@trnddc02> Paul Raulerson wrote: > >>-----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 Hi Paul, Just a sanity check here... It sounds like you're porting an application for eventual resale to 3rd parties, which makes you a Software Provider in the context of the HP DSPP program. If you haven't signed up, do so! You get free [for some small value of "free"] licenses to most of HP's compilers and development tools, including RMS journaling (separate license on VAX and Alpha, part of MCOE which is included in the DSPP license set on Itanium) and lots of other stuff. This doesn't help your customers, but it's a great deal for you, especially if you are running on fumes because you don't have any customers yet. I don't know what an RMS journaling license costs a la carte, it might be helpful if someone posted here or if you could talk to a VMS Ambassador. RMS journaling is also included in the EOE package, which seems to add about $5300 to the base system list price for an rx2620. (From the HP web site, system configurator page.) You should be able to get a much better price from a reseller, or from HP if you sell lots of boxes. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: 24 Aug 2007 15:51:40 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: COBOL Transactions? Message-ID: In article , "Paul Raulerson" writes: > > P.S. It it were working, I believe it should be on the DKA600: slot. It is > LUN 6 on the PKA0: SCSI Adapter. A disk drive at SCSI slot 6 on the 1st bus shows up as DKA600:, a tape drive at the same LUN shows up as MKA600: . VMS for Alpha has almost (not quite) always been quite good at finding disk and tape drives on SCSI. > ALPHIE$DKA0: Online 0 > ALPHIE$DKA400: Online wrtlck 0 > ALPHIE$DKB0: Mounted 0 VMS83$IPL 14262672 476 1 > ALPHIE$DKB100: Mounted 0 VMS0100 17636144 2 1 > ALPHIE$DKB200: Mounted 0 VMSA00000000 0 2 1 > ALPHIE$DKB300: Mounted 0 VMSA00000001 0 2 1 > ALPHIE$DKB400: Mounted 0 VMSA00000002 0 2 1 > ALPHIE$DKB500: Mounted 0 VMSA00000003 0 2 1 > ALPHIE$DKB600: Mounted 0 VMS0600 12952864 2 1 I forget which model you're using. Generally DKA is the internal bus (a hard drive and a CD drive, that sounds about right) and DKB is the external bus. If you put that tape drive on the DBK at LUN 6 it and DKB600 can't both be seen. Is DKB600 working correctly? If not, then the tape drive is probably on DKB. Back in the early days of SCSI, they told us to have our devices powered on before powering on the controller, if we had a choice. Power cycling the controller (probably the whole Alpha) would be a possible step in investigation. OBTW VMS83$IPL sounds like some IBM fellow was managing your Alpha. ------------------------------ Date: Fri, 24 Aug 2007 14:04:12 -0700 From: "Tom Linden" Subject: Re: COBOL Transactions? Message-ID: On Fri, 24 Aug 2007 10:18:56 -0700, Ron Johnson wrote: > On 08/24/07 08:18, Bill Gunshannon wrote: >> In article , >> Ron Johnson writes: >>> On 08/23/07 20:02, Tom Linden wrote: >>>> On Thu, 23 Aug 2007 07:25:52 -0700, Ron Johnson >>>> >>>> wrote: >>>> >>>>> On 08/23/07 08:25, Tom Linden wrote: >>>>>> On Wed, 22 Aug 2007 21:37:53 -0700, Paul Raulerson >>>>>> >>>>>> wrote: >>>>>> >>>>>>> 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... >>>>>> Indexed file handling is in the PL/I semantics. >>>>> Yeah, but anyone in his right mind knows that PL/1 sucks. >>>>> >>>> That would be PL/I BTW, you obviously know little about programming >>>> languages. >>> So you also say that PL/I sucks? >>> >>> (Just jerking your chain, Tom, since you are such a big booster of a >>> not-so-popular-anymore language. Was it ever very popular outside >>> the mainframe?) >> >> Minicomputers. Prime used it and much of the OS and utilites was >> written >> in PL/1 :-) and various subset dialects. > > Prime has been dead for how many years now? 15? > >> Microcomputers. PL/M (well, it may not be PL/1, but I think it qualifies >> as a dialect.) > > Who used PL/M besides DRI? > Before Gary Kildall started DRI he did a stint at Intel where developed PL/M http://en.wikipedia.org/wiki/Gary_Kildall He was also on the PL/I standards committee. It was the high level programming language at Intel for 8080 onward thru 8086 PL/M-86 was fairly widely distributed. -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Fri, 24 Aug 2007 14:10:12 -0700 From: "Tom Linden" Subject: Re: COBOL Transactions? Message-ID: On Fri, 24 Aug 2007 11:05:48 -0700, Bill Gunshannon = wrote: > In article , > Kilgallen@SpamCop.net (Larry Kilgallen) writes: >> In article , "Paul Raulerson" = >> writes: >> >>> COBOL (and I assume PL/I :) running under UNIX has to supply a recor= d = >>> ori=3D >>> ented file system layered over the UNIX filesystem. >> >> As do Ada implementations. >> >> There is a distinct problem with an operating system written by folks= >> who think the lowest common denominator programming language is the >> only one. > > Once again, don't assume your worldview is the only one. The entire > paradigm underlying Unix was "The Software Tools" paradigm in which > things are reduced to their simplest form and complexity is created > by adding layers. Thus the "pipe" concept as used by things like > troff which required other utilities like col, eqn, greek and tbl > in order to create more complex documents. > > C-ISAM was around and available for Unix since at least the early to > mid 80's. I first used a database and COBOL on Unix in the mid 80's. > One advantage to the Unix paradigm is you don't end out paying for > features you neither need nor want. I have never used RMS on VMS. > explicitly. I can't think of anything I have done that actually > needed it. And don't say "you don't pay for it because it is > bundled in" because you pay for everything that comes with the system > wether it is listed on the invoice or not. > C-ISAM which was written by Roger Sippl, was a pretty limited implentati= on without secondary keys, for example, and this later morphed into Informi= x = IIRC. > bill > -- = PL/I for OpenVMS www.kednos.com ------------------------------ Date: 24 Aug 2007 15:59:04 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: COBOL Transactions? Message-ID: In article <5j8kvsF3sj2ffU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: > > I have never used RMS on VMS. > explicitly. I can't think of anything I have done that actually > needed it. You only program in C,C++,Java and you never view your files on a terminal (type or edit) or printer? You never perused a directory? Yes, those can be done without RMS, UNIX and DOS are examples. As long as someone provided the missing component somewhere. Your terminal and printer didn't come out of the box thinking LF implied CR, although some hardware is settable to provide that. ------------------------------ Date: Fri, 24 Aug 2007 21:11:48 GMT From: John Santos Subject: Re: COBOL Transactions? Message-ID: Bob Koehler wrote: > In article <5j8kvsF3sj2ffU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: > >>I have never used RMS on VMS. >>explicitly. I can't think of anything I have done that actually >>needed it. > > > You only program in C,C++,Java and you never view your files on a > terminal (type or edit) or printer? You never perused a directory? > > Yes, those can be done without RMS, UNIX and DOS are examples. As > long as someone provided the missing component somewhere. Your > terminal and printer didn't come out of the box thinking LF implied > CR, although some hardware is settable to provide that. > Not to mention never logging in.... SYSUAF.DAT is an RMS indexed file. :-) -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: Fri, 24 Aug 2007 21:24:34 +0000 From: "Main, Kerry" Subject: RE: COBOL Transactions? Message-ID: > -----Original Message----- > From: John Santos [mailto:john@egh.com] > Sent: August 24, 2007 4:34 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: COBOL Transactions? > [snip] > > > > 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 > > Hi Paul, > > Just a sanity check here... It sounds like you're porting an > application > for eventual resale to 3rd parties, which makes you a Software Provider > in > the context of the HP DSPP program. If you haven't signed up, do so! > > You get free [for some small value of "free"] licenses to most of HP's > compilers and development tools, including RMS journaling (separate > license on VAX and Alpha, part of MCOE which is included in the DSPP > license set on Itanium) and lots of other stuff. This doesn't help > your > customers, but it's a great deal for you, especially if you are running > on fumes because you don't have any customers yet. > > I don't know what an RMS journaling license costs a la carte, it might > be helpful if someone posted here or if you could talk to a VMS > Ambassador. > RMS journaling is also included in the EOE package, which seems to add > about $5300 to the base system list price for an rx2620. (From the HP > web site, system configurator page.) You should be able to get a much > better price from a reseller, or from HP if you sell lots of boxes. > > > -- > John Santos > Evans Griffiths & Hart, Inc. > 781-861-0670 ext 539 Re: license considerations: Here is pretty good brochure on new Integrity licenses and what is in each = FOE, EOE, MCOE level. http://h71028.www7.hp.com/ERC/downloads/4AA0-2321ENW.pdf And if there is any question as to what is supported, the SPD (software pro= duct description) is the legal doc that says What is officially supported. Refer= ence: http://h18000.www1.hp.com/info/XAV12X/XAV12XPF.PDF 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: Fri, 24 Aug 2007 16:29:44 -0500 From: Ron Johnson Subject: Re: COBOL Transactions? Message-ID: On 08/24/07 14:41, Larry Kilgallen wrote: [snip] > > If you write all your programs with a "stream of bytes" language, > that may be the case. In my experience programs written with a > "stream of bytes" mentality are a major source of lousy software. More importantly, the data that is needed to generate my paycheck isn't is "stream of bytes" format. -- 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: Fri, 24 Aug 2007 16:44:11 -0500 From: Ron Johnson Subject: Re: COBOL Transactions? Message-ID: On 08/24/07 16:11, John Santos wrote: [snip] > > Not to mention never logging in.... SYSUAF.DAT is an RMS indexed file. :-) I was delighted the first time I opened SYSUAF in EDT, and learned the interesting lesson (*not* on SYSUAF!) that saving an indexed file converts it into a flat file... -- 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: Fri, 24 Aug 2007 14:54:20 -0700 From: FrankS Subject: Re: COBOL Transactions? Message-ID: <1187992460.394381.181590@i13g2000prf.googlegroups.com> On Aug 24, 11:15 am, "Paul Raulerson" wrote: >>What you *seem* to be objecting to is when I say, "Here is what I >>need to do, here is how I would normally do it, what is the facility >>under VMS that does this?" Without rereading everything you've ever posted I'd have to say that I don't recall ever seeing you pose a question in that form. What you have done -- and what disturbs me -- is make statements (or implications) about OpenVMS' inability to perform a variety of tasks when you have no knowledge of whether or not it can do those things. For example, here are some things you have said ... >>> The only issue with the Alpha is that the 4mm tape drive on it >>> does not seem to be recognized. ... and off to the UNIX machine >>> which *does* know how to talk to tape. The implication is that OpenVMS *doesn't* "know how to talk to tape" so you have to revert to a Unix box to get that done. Well, of course OpenVMS does work with tapes, and if it's a working SCSI drive then you'd see either an MK or GK device name. >>> When I create an indexed file in COBOL, is it using Rdb? If so, >>> it quacks a lot like a filesystem to me. >>> if they are VSAM (which is the the same as RDB on VMS) >>> I looked at Rdb mainly in relation to how it acts as an indexed >>> file system, not as a database. >>> DB2 has had federated databases for more than a decade, well before >>> Oracle. RDB is file based, I'm not sure how it can do that, >>> especially over slower global WAN connections. You made a lot of statements about RDB's limitations when comparing it to DB2. Unfortunately, in your ignorance of OpenVMS, what you were really doing was comparing RMS to DB2. Applying your new question format (at the top of this posting) then what you should have written was something like "DB2 has had federated databases for more than a decade, what is the facility under VMS that does this?" You might have had to explain "federated databases" since it's not terminology that's used in the OpenVMS space, but at least asking the question rather than making statements about what RDB can't do because you think it's similar to VSAM wouldn't make you look so foolish. >>> How about little things like really erasing the data on a DASD unit? That was a perfect opportunity for the new question format: "z/OS has a facility for writing erase patterns on disk. What is the method for erasing the data on a DASD unit under OpenVMS?" Oh, but you didn't do that. Instead you listed a bunch of things you felt weren't available in OpenVMS. Sure, you put a question mark on the end but your implication was that the facilities weren't available in OpenVMS at all. I can go on and on, and you probably know it. >> In the partial quote you used as an example above, you left out the >> part that the hardware the tape is on is an Alpha that I picked up >> for just about nothing, and I also said I need to move it to a new >> (or used) supported Itanium machine. Not relevant, as I pointed out above that the issue I had was with your implication that OpenVMS couldn't handle tapes at all. I've bought used systems on eBay as well and never had a problem getting the hardware to work. Of course, I've got a lot more experience with OpenVMS than you do. While we're here, though, are you sure that your dirt cheap Alpha was qualified by Digital/Compaq/HP to run OpenVMS at all? >> Why in heavens name would I, or *anyone* for that matter, go chasing >> around a hunk of hardware that is either not supported or simply >> broken when the needed capabilty is available on another resource >> which is working? Because it's your development system and most people I know would like their development systems to be fully functional. How will you develop a backup procedure for your client's on Alpha if you can't get it to work at home? How will you back up your ported source code at the HP porting event if you haven't practiced it under OpenVMS at home? (And, even though you profess to port to Integrity you may come across a potential sale of your software at a client that already has Alpha and doesn't want to buy new systems. Be prepared.) >> Better yet, why in heavens name would you assume I would NOT backup >> valuable (at least to me) work on which I have spent much time >> and effort? Huh? Where did I make that assumption? Never mind, don't answer. I suspect you'll go off on a trillion tangents like this last posting of yours. The "baffle them with bullshit" method. >> if a device shows up in the bios when you do a SHOW DEV, but not in >> VMS when you do a SHOW DEV, chances are it is not recognized by VMS. Let's try this in the new question format: "If a device shows up in the bios when you do a SHOW DEV, but not in VMS when you do a SHOW DEV, does that mean it is not recognized by VMS?" Notice the difference. A question rather than a statement that "chances are it is not recognized by VMS". What do you base that statement on? Your two months of OpenVMS experience? How much do you know about how OpenVMS handles unrecognized drive types? ------------------------------ Date: Fri, 24 Aug 2007 21:50:22 GMT From: winston@SSRL.SLAC.STANFORD.EDU (Alan Winston - SSRL Central Computing) Subject: Re: COBOL Transactions? Message-ID: <00A6C9E6.8FFD5BF1@SSRL.SLAC.STANFORD.EDU> In article , "Paul Raulerson" writes: >, "is there >>an RPG compiler for OpenVMS", > >Kerry sent a link on that the other day. The reason I did not reply is th= >at the website maintains it is an RPG-II compiler. Being first as it was = >very kind of Kerry to do so, and second, as most people here have probabl= >y never ever seen RPG, I did not publicy reply that the current version o= >f RPG is RPGIV, and is based upon an ILE base. A modern RPGIV program wou= >ld be virutally unrecognizable to an RPG-II programmer, given as most mod= >ern programs do *not* use "the cycle", have a ton of built in fuctions, a= >re written in free-form syntax, and so on and so forth. In other words, i= >t is less trouble to convert the RPG to COBOL or even Assembler than it i= >s to try and rewrite it RPG-II. Wow. (I took an RPG-II class in school about 1979. The language you're describing really isn't something I'd recognize. I would have thought those features (column orientation, easy automatic totals, etc, etc) were the main reasons for the language to even *exist*. How did it evolve in this way? > >Now that everyone is throughly bored by a paragraph talking about somethi= >ng that is not really even relevant in the VMS world... > Well, not everyone. > >"is it RDB or RMS that handles indexed >>file support" > >Okay, what is the equivalent in RMS of sepcifying the CI intervals to con= >trol splits? How large a file can RMS support, and where and when does th= >e indexing start to bog down because of size? Is there an significant imp= >act on the indexing performance with software raid and if so, what is the= > cost/benefit ratio that determines when it makes sense to move to hardwa= >re raid? I bet Hein can answer those questions for you. (I am _not_ an RMS jock.) >How easy is it to expand VMS volumes when necessary, and when/wh= >ere does degration of performance set in? (If you don't understand what I= > mean by degredation, consider it in light of the CI question above.) > If volumes means what I think it means (and maybe it doesn't), if you have a 'disk' on a SAN (so the actualy underlying volume can actually change size when you twiddle the SAN bits to allocate more apce to it), life is good if you initially did a $ SET VOLUME/LIMIT when you first set the disk up, since that enables the volume to have its size reset up to the VMS limit (1 Terabyte per volume) without having to dismount the volume or otherwise take it out of service, just by using the $ SET VOLUME/SIZE command. (If you neglected to do the $ SET VOLUME /LIMIT while you had the disk mounted privately, you have to dismount it and remount it privately to issue the command.) I guess you could also use this if you did an image backup from a small real disk to a large one, but there you could also have done an INIT of the large disk with the parameters you wanted and a BACKUP/IMAGE/NOINIT to copy the data but keep your new strucutre. -- Alan ------------------------------ Date: 24 Aug 2007 22:17:19 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: COBOL Transactions? Message-ID: <5j93nfF3sloleU1@mid.individual.net> In article , Kilgallen@SpamCop.net (Larry Kilgallen) writes: > In article <5j8kvsF3sj2ffU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: >> In article , >> Kilgallen@SpamCop.net (Larry Kilgallen) writes: >>> In article , "Paul Raulerson" writes: >>> >>>> COBOL (and I assume PL/I :) running under UNIX has to supply a record ori= >>>> ented file system layered over the UNIX filesystem. >>> >>> As do Ada implementations. >>> >>> There is a distinct problem with an operating system written by folks >>> who think the lowest common denominator programming language is the >>> only one. > >> C-ISAM was around and available for Unix since at least the early to >> mid 80's. > > But never something one could always count on being there ? Because the majority of users didn't need or want it. So, why should they have to pay for it? > >> One advantage to the Unix paradigm is you don't end out paying for >> features you neither need nor want. I have never used RMS on VMS. >> explicitly. I can't think of anything I have done that actually >> needed it. > > If you write all your programs with a "stream of bytes" language, > that may be the case. In my experience programs written with a > "stream of bytes" mentality are a major source of lousy software. I have written programs on Unix systems in COBOL, Fortran, Pascal, Ada, Algol, PL/I, BASIC, Modula2, various assemblers and I am sure a few languages I have forgotten. Just because the underlying systems doesn't have your favorite file type on it doesn't mean all programs are written with a "stream of bytes" mentality. Part of real Software Engineering is picking the right tools for the job. It's nice to know that some tool is not being forced down my throat when I know it is the wrong answer to a problem. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 24 Aug 2007 22:20:04 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: COBOL Transactions? Message-ID: <5j93skF3sloleU2@mid.individual.net> In article , Ron Johnson writes: > On 08/24/07 14:41, Larry Kilgallen wrote: > [snip] >> >> If you write all your programs with a "stream of bytes" language, >> that may be the case. In my experience programs written with a >> "stream of bytes" mentality are a major source of lousy software. > > More importantly, the data that is needed to generate my paycheck > isn't is "stream of bytes" format. Only because the machine doing the work has imposed a format on the raw data, wethere it is necessary or not. What exactly is needed to generate a paycheck that can not be done with data stored as a stream of bytes? (Hint: at the lowest level all data is stored as a stream of bytes even on VMS!!) bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 24 Aug 2007 22:25:13 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: COBOL Transactions? Message-ID: <5j9469F3sloleU3@mid.individual.net> In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > In article <5j8kvsF3sj2ffU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: >> >> I have never used RMS on VMS. >> explicitly. I can't think of anything I have done that actually >> needed it. > > You only program in C,C++,Java and you never view your files on a > terminal (type or edit) or printer? You never perused a directory? I didn't say that. I know VMS is using RMS for all that. But I do the same taskes quite well on machines without it so I guess it really isn't necessary. It is just forced on me. Kind of like the common rant, "Bill Gates knows what's best for you." Apparently DEC/Compaq/HP have pretty much the same attitude. > > Yes, those can be done without RMS, UNIX and DOS are examples. As > long as someone provided the missing component somewhere. Your > terminal and printer didn't come out of the box thinking LF implied > CR, although some hardware is settable to provide that. At one time, almost every printer I had ever seen knew that. Today, they all do postscript which means without a "missing component somewhere" you couldn't print any of your RMS based files either. And don't even try saying that you can view raw RMS files on a terminal or edit them without a "missing component somewhere" to convert them from RMS format to juat another pile of bytes. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 24 Aug 2007 22:26:58 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: COBOL Transactions? Message-ID: <5j949iF3sloleU4@mid.individual.net> In article , John Santos writes: > Bob Koehler wrote: >> In article <5j8kvsF3sj2ffU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: >> >>>I have never used RMS on VMS. >>>explicitly. I can't think of anything I have done that actually >>>needed it. >> >> >> You only program in C,C++,Java and you never view your files on a >> terminal (type or edit) or printer? You never perused a directory? >> >> Yes, those can be done without RMS, UNIX and DOS are examples. As >> long as someone provided the missing component somewhere. Your >> terminal and printer didn't come out of the box thinking LF implied >> CR, although some hardware is settable to provide that. >> > > Not to mention never logging in.... SYSUAF.DAT is an RMS indexed file. :-) I login to lots of systems everyday without the help of RMS. Tell me again why it is "needed" for this task? RMS may be great at what it does but for a very large number of tasks it is just overhead. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 24 Aug 2007 17:46:15 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: COBOL Transactions? Message-ID: In article , Ron Johnson writes: > On 08/24/07 14:41, Larry Kilgallen wrote: > [snip] >> >> If you write all your programs with a "stream of bytes" language, >> that may be the case. In my experience programs written with a >> "stream of bytes" mentality are a major source of lousy software. > > More importantly, the data that is needed to generate my paycheck > isn't is "stream of bytes" format. Banks are slow to cash checks made out in an amount of \/. ------------------------------ Date: 24 Aug 2007 17:47:58 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: COBOL Transactions? Message-ID: In article , Ron Johnson writes: > On 08/24/07 16:11, John Santos wrote: > [snip] >> >> Not to mention never logging in.... SYSUAF.DAT is an RMS indexed file. :-) > > I was delighted the first time I opened SYSUAF in EDT, and learned > the interesting lesson (*not* on SYSUAF!) that saving an indexed > file converts it into a flat file... I know of at least six sites where privileged users did that to SYSALF.DAT and then exited, meaning even their existing entries no longer worked. One of the best security measures a site can institute is mandatory competency testing for those who want privileges on their username. ------------------------------ Date: 24 Aug 2007 17:50:19 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: COBOL Transactions? Message-ID: In article <5j93nfF3sloleU1@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: > In article , > Kilgallen@SpamCop.net (Larry Kilgallen) writes: >> In article <5j8kvsF3sj2ffU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: >>> In article , >>> Kilgallen@SpamCop.net (Larry Kilgallen) writes: >>>> In article , "Paul Raulerson" writes: >>>> >>>>> COBOL (and I assume PL/I :) running under UNIX has to supply a record ori= >>>>> ented file system layered over the UNIX filesystem. >>>> >>>> As do Ada implementations. >>>> >>>> There is a distinct problem with an operating system written by folks >>>> who think the lowest common denominator programming language is the >>>> only one. >> >>> C-ISAM was around and available for Unix since at least the early to >>> mid 80's. >> >> But never something one could always count on being there ? > > Because the majority of users didn't need or want it. So, why should > they have to pay for it? Good idea. Can you help me get HP to remove the "stream of bytes" support from VMS ? ------------------------------ Date: 24 Aug 2007 17:52:14 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: COBOL Transactions? Message-ID: In article <5j93skF3sloleU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: > In article , > Ron Johnson writes: >> On 08/24/07 14:41, Larry Kilgallen wrote: >> [snip] >>> >>> If you write all your programs with a "stream of bytes" language, >>> that may be the case. In my experience programs written with a >>> "stream of bytes" mentality are a major source of lousy software. >> >> More importantly, the data that is needed to generate my paycheck >> isn't is "stream of bytes" format. > > Only because the machine doing the work has imposed a format on the > raw data, wethere it is necessary or not. What exactly is needed > to generate a paycheck that can not be done with data stored as a > stream of bytes? (Hint: at the lowest level all data is stored as > a stream of bytes even on VMS!!) No, it is organized as a series of extents containing blocks containing records. Implicit in that for most file formats is some implicit carriage control format specified in the file header. ------------------------------ Date: Sat, 25 Aug 2007 01:41:40 +0200 From: "Dr. Dweeb" Subject: Re: COBOL Transactions? Message-ID: <46cf6c29$0$21925$157c6196@dreader1.cybercity.dk> Larry Kilgallen wrote: > In article , Ron Johnson > writes: >> On 08/24/07 16:11, John Santos wrote: >> [snip] >>> >>> Not to mention never logging in.... SYSUAF.DAT is an RMS indexed >>> file. :-) >> >> I was delighted the first time I opened SYSUAF in EDT, and learned >> the interesting lesson (*not* on SYSUAF!) that saving an indexed >> file converts it into a flat file... > > I know of at least six sites where privileged users did that to > SYSALF.DAT and then exited, meaning even their existing entries > no longer worked. > File versioning to the rescue ? > One of the best security measures a site can institute is mandatory > competency testing for those who want privileges on their username. ------------------------------ Date: Fri, 24 Aug 2007 20:04:18 -0400 From: JF Mezei Subject: Re: COBOL Transactions? Message-ID: <8a9c4$46cf7205$cef8887a$6008@TEKSAVVY.COM> Bill Gunshannon wrote: > RMS may be great at what it does but for a very large number of tasks > it is just overhead. Before you declare RMS "overhead", you would need to look into the code that allows you to read "lines" of text in Unix (fgets for instance). VMS doesn't need to scan the data for cr/lfs, it looks at the 2 byte record header and knows exactly how many bytes of data are in that record. And when you look at the many Unix/windows applications that work only on sequential files, many end up reading the whole file in memory and the scanning in memory (but that in the end results in a lot of paging to the pagefile). Also, whenever you change a preference, it has to rewrite the whole config file instead of just changing one record. And this has interesting consequences in a multi-user system due to file locking and other processes that may have the cofig file already in memory when when they update their configs, they will overwrite previously modified files without the changes that had been made by other processes. ------------------------------ Date: Fri, 24 Aug 2007 19:05:23 -0500 From: Ron Johnson Subject: Re: COBOL Transactions? Message-ID: <8nKzi.20836$Pv4.10871@newsfe19.lga> On 08/24/07 18:41, Dr. Dweeb wrote: > Larry Kilgallen wrote: >> In article , Ron Johnson >> writes: >>> On 08/24/07 16:11, John Santos wrote: >>> [snip] >>>> Not to mention never logging in.... SYSUAF.DAT is an RMS indexed >>>> file. :-) >>> I was delighted the first time I opened SYSUAF in EDT, and learned >>> the interesting lesson (*not* on SYSUAF!) that saving an indexed >>> file converts it into a flat file... >> I know of at least six sites where privileged users did that to >> SYSALF.DAT and then exited, meaning even their existing entries >> no longer worked. >> > > File versioning to the rescue ? Great minds think alike. -- 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: 24 Aug 2007 19:12:20 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: COBOL Transactions? Message-ID: <+jFZMmmojOiG@eisner.encompasserve.org> In article <8nKzi.20836$Pv4.10871@newsfe19.lga>, Ron Johnson writes: > On 08/24/07 18:41, Dr. Dweeb wrote: >> Larry Kilgallen wrote: >>> In article , Ron Johnson >>> writes: >>>> On 08/24/07 16:11, John Santos wrote: >>>> [snip] >>>>> Not to mention never logging in.... SYSUAF.DAT is an RMS indexed >>>>> file. :-) >>>> I was delighted the first time I opened SYSUAF in EDT, and learned >>>> the interesting lesson (*not* on SYSUAF!) that saving an indexed >>>> file converts it into a flat file... >>> I know of at least six sites where privileged users did that to >>> SYSALF.DAT and then exited, meaning even their existing entries >>> no longer worked. >>> >> >> File versioning to the rescue ? > > Great minds think alike. But not the great minds that failed to realize what they had broken until a security assessment several years later. ------------------------------ Date: Fri, 24 Aug 2007 19:52:34 -0500 From: Ron Johnson Subject: Re: COBOL Transactions? Message-ID: On 08/24/07 19:12, Larry Kilgallen wrote: > In article <8nKzi.20836$Pv4.10871@newsfe19.lga>, Ron Johnson writes: >> On 08/24/07 18:41, Dr. Dweeb wrote: >>> Larry Kilgallen wrote: >>>> In article , Ron Johnson >>>> writes: >>>>> On 08/24/07 16:11, John Santos wrote: >>>>> [snip] >>>>>> Not to mention never logging in.... SYSUAF.DAT is an RMS indexed >>>>>> file. :-) >>>>> I was delighted the first time I opened SYSUAF in EDT, and learned >>>>> the interesting lesson (*not* on SYSUAF!) that saving an indexed >>>>> file converts it into a flat file... >>>> I know of at least six sites where privileged users did that to >>>> SYSALF.DAT and then exited, meaning even their existing entries >>>> no longer worked. >>>> >>> File versioning to the rescue ? >> Great minds think alike. > > But not the great minds that failed to realize what they had broken > until a security assessment several years later. But how do you log in or run MCR AUTHORIZE on a flat-file SYSUAF? -- 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: Fri, 24 Aug 2007 19:58:02 -0500 From: "Paul Raulerson" Subject: RE: COBOL Transactions? Message-ID: <008601c7e6b2$fd1caab0$f7560010$@com> > -----Original Message----- > From: John Santos [mailto:john@egh.com] > Sent: Friday, August 24, 2007 3:34 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: COBOL Transactions? > > Hi Paul, > > Just a sanity check here... It sounds like you're porting an > application > for eventual resale to 3rd parties, which makes you a Software Provider > in > the context of the HP DSPP program. If you haven't signed up, do so! > > You get free [for some small value of "free"] licenses to most of HP's > compilers and development tools, including RMS journaling (separate > license on VAX and Alpha, part of MCOE which is included in the DSPP > license set on Itanium) and lots of other stuff. This doesn't help > your > customers, but it's a great deal for you, especially if you are running > on fumes because you don't have any customers yet. > > I don't know what an RMS journaling license costs a la carte, it might > be helpful if someone posted here or if you could talk to a VMS > Ambassador. > RMS journaling is also included in the EOE package, which seems to add > about $5300 to the base system list price for an rx2620. (From the HP > web site, system configurator page.) You should be able to get a much > better price from a reseller, or from HP if you sell lots of boxes. > > > -- > John Santos > Evans Griffiths & Hart, Inc. > 781-861-0670 ext 539 Thank John - great advice. I did sign up with the DSPP program, which was really one of the things that convinced me to move ahead with a port. HP looks to be trying very hard to attract and support developers. Current customers are all on the mainframe or iSeries machines, which is partly why I tend to relate to those things, often to the aggravation of some long term VMS people, I understand. 8] It's really a lot of fun, I am in the stage where I stay up till my eyes just close of their own accord, and then I wake up an hour later with a different or better way to accomplish what I want to do. It's also a lot of fun to find "new" solutions for old problems. I could build a near mainframe equivalent environment with VMS, including transaction processing and all the good stuff. But it is fun to see if I can drive this into a solution set for the small small business crowd. Hard to compete with $500 PC's, at least until the people realize what they crappy "free" software that came with the PC, or the Windows Visual Basic database their brother-in-law wrote for them is really costing them. I intend to sell a lot of HP boxes, all nicely loaded with significant software loads. Indeed, when I talked to a couple of my existing customers and floated the idea of moving to HP hardware, they were very excited about it. It surprised me to no end how excited in fact! :) ------------------------------ Date: Fri, 24 Aug 2007 20:04:07 -0500 From: "Paul Raulerson" Subject: RE: COBOL Transactions? Message-ID: <008701c7e6b3$d6a8f540$83fadfc0$@com> > -----Original Message----- > From: Bob Koehler [mailto:koehler@eisner.nospam.encompasserve.org] > Sent: Friday, August 24, 2007 3:52 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: COBOL Transactions? > > In article , "Paul Raulerson" > writes: > > > > P.S. It it were working, I believe it should be on the DKA600: slot. > It is > > LUN 6 on the PKA0: SCSI Adapter. > > A disk drive at SCSI slot 6 on the 1st bus shows up as DKA600:, a > tape > drive at the same LUN shows up as MKA600: . VMS for Alpha has > almost > (not quite) always been quite good at finding disk and tape drives > on > SCSI. It's seems very good at finding and using gear on the SCSI bus, much better than say, a Sun or AIX box. > > > ALPHIE$DKA0: Online 0 > > ALPHIE$DKA400: Online wrtlck 0 > > > ALPHIE$DKB0: Mounted 0 VMS83$IPL > 14262672 476 1 > > ALPHIE$DKB100: Mounted 0 VMS0100 > 17636144 2 1 > > ALPHIE$DKB200: Mounted 0 VMSA00000000 > 0 2 1 > > ALPHIE$DKB300: Mounted 0 VMSA00000001 > 0 2 1 > > ALPHIE$DKB400: Mounted 0 VMSA00000002 > 0 2 1 > > ALPHIE$DKB500: Mounted 0 VMSA00000003 > 0 2 1 > > ALPHIE$DKB600: Mounted 0 VMS0600 > 12952864 2 1 > > I forget which model you're using. Generally DKA is the internal > bus > (a hard drive and a CD drive, that sounds about right) and DKB is > the > external bus. If you put that tape drive on the DBK at LUN 6 it and > DKB600 can't both be seen. > > Is DKB600 working correctly? If not, then the tape drive is > probably > on DKB. Yeah, DKB600: is in an external SCSI array, and it works just fine. The tape is connected on the internal bus and does show up as MKA600: or something very close to that, in the BIOS (is "SRM" the right term?) list. I just power cycled the machine to be sure. > > Back in the early days of SCSI, they told us to have our devices > powered on before powering on the controller, if we had a choice. > Power cycling the controller (probably the whole Alpha) would be a > possible step in investigation. > > OBTW VMS83$IPL sounds like some IBM fellow was managing your Alpha. LOL! Thank you, I'll take that as a complement. At least I put a "$" in there. ;) The unmounted DKA0: drive is a duplicate of it, but labeled VMS83$AIPL.... What would you suggest is a more appropriate VMS name? I can change... :) ------------------------------ Date: Fri, 24 Aug 2007 20:10:16 -0500 From: "Paul Raulerson" Subject: RE: COBOL Transactions? Message-ID: <008c01c7e6b4$b2fb8bc0$18f2a340$@com> >Here is pretty good brochure on new Integrity licenses and what is in each FOE, EOE, MCOE level. > >http://h71028.www7.hp.com/ERC/downloads/4AA0-2321ENW.pdf Aw gee Kerry- this is EXACTLY what I have been pestering people at HP for. All I need to add (so far), for the very small SMB customers, is RMS Journaling to the base package. This little nugget of information has helped to turn a pretty lousy week into a nice weekend... Thank you. -Paul > -----Original Message----- > From: Main, Kerry [mailto:Kerry.Main@hp.com] > Sent: Friday, August 24, 2007 4:25 PM > To: Info-VAX@Mvb.Saic.Com > Subject: RE: COBOL Transactions? > > > > -----Original Message----- > > From: John Santos [mailto:john@egh.com] > > Sent: August 24, 2007 4:34 PM > > To: Info-VAX@Mvb.Saic.Com > > Subject: Re: COBOL Transactions? > > > > [snip] > > > > > > > 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 > > > > Hi Paul, > > > > Just a sanity check here... It sounds like you're porting an > > application > > for eventual resale to 3rd parties, which makes you a Software > Provider > > in > > the context of the HP DSPP program. If you haven't signed up, do so! > > > > You get free [for some small value of "free"] licenses to most of > HP's > > compilers and development tools, including RMS journaling (separate > > license on VAX and Alpha, part of MCOE which is included in the DSPP > > license set on Itanium) and lots of other stuff. This doesn't help > > your > > customers, but it's a great deal for you, especially if you are > running > > on fumes because you don't have any customers yet. > > > > I don't know what an RMS journaling license costs a la carte, it > might > > be helpful if someone posted here or if you could talk to a VMS > > Ambassador. > > RMS journaling is also included in the EOE package, which seems to > add > > about $5300 to the base system list price for an rx2620. (From the > HP > > web site, system configurator page.) You should be able to get a > much > > better price from a reseller, or from HP if you sell lots of boxes. > > > > > > -- > > John Santos > > Evans Griffiths & Hart, Inc. > > 781-861-0670 ext 539 > > Re: license considerations: > > Here is pretty good brochure on new Integrity licenses and what is in > each FOE, EOE, > MCOE level. > > http://h71028.www7.hp.com/ERC/downloads/4AA0-2321ENW.pdf > > And if there is any question as to what is supported, the SPD (software > product > description) is the legal doc that says What is officially supported. > Reference: > http://h18000.www1.hp.com/info/XAV12X/XAV12XPF.PDF > > 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: Sat, 25 Aug 2007 01:22:30 -0000 From: Hein RMS van den Heuvel Subject: Re: COBOL Transactions? Message-ID: <1188004950.630596.189890@q4g2000prc.googlegroups.com> On Aug 24, 5:50 pm, wins...@SSRL.SLAC.STANFORD.EDU (Alan Winston - SSRL Central Computing) wrote: > In article , "Paul Raulerson" writes: > >"is it RDB or RMS that handles indexed file support" An important claim to fame for RMS is native support for indexed files, available to all OpenVMS languaes, DCL included. > >Okay, what is the equivalent in RMS of sepcifying the CI intervals to con trol splits? Dunno. A quick google did not enlighten me as to what either might mean. >> How large a file can RMS support It is limited to 1 Terabyte. It really should be, and actually might be 2**32 * 512 bytes, but the sign bit is not trusted to have been ignored everywhere. >> and where and when does the indexing start to bog down because of size? Never. It is a simlpe semi-balanced B-tree not known to bog down ever. A well designed large index file often only needs 3 index levels, 4 absolutely worst case. But I've seen poorly designed (NOT designed) indexed files with 10 index level where the end users where just happy, oblivious to significant performance potential available to them. RMS Just keeps on working. A blessing and a problem at the same time. Last weekend I helped a customer convert a 3-key 100GB indexed file in less than 2 hours. That's about as big as they are currently in use. On the same box RMS was managing a 150GB fixed length record sequential file. >> Is there an significant impact on the indexing performance with software raid That question does not compute for VMS. Raid and indexing are orthogonal, independend technologies. Raid and help or hurt indexed file access (it tends to help) but your typical, even your sophisticated, indexed file user would only worry abot raid as a last recourse. >> and if so, what is the cost/benefit ratio that determines when it makes sense to move to hardware raid? That still does not compute. At best it is of marginal relevance (less than 10% performance potential) > I bet Hein can answer those questions for you. (I am _not_ an RMS jock.) Was my name called? :-) > >How easy is it to expand VMS volumes when necessary, Somewhat easy, but best avoided. You can MOUNT a second disk to create a bound volume set. >> and when/where does degration of performance set in? (If you don't understand what I mean by degredation, consider it in light of the CI question above.) ZERO degradation (well, ok, an extra file header access at times). > If volumes means what I think it means (and maybe it doesn't), if you have a 'disk' on a SAN (so the actualy underlying volume can actually change size when you twiddle the SAN bits to allocate more apce to it), life is good if you Yes. Life is good. (since a few years now) The big beauty of RMS perhpas is TRANSPARANCY. It isolates program from storage considerations. hth, Hein ------------------------------ Date: Fri, 24 Aug 2007 21:29:41 -0400 From: "Richard B. Gilbert" Subject: Re: COBOL Transactions? Message-ID: <46CF8605.7080709@comcast.net> Bill Gunshannon wrote: > In article , > John Santos writes: > >>Bob Koehler wrote: >> >>>In article <5j8kvsF3sj2ffU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: >>> >>> >>>>I have never used RMS on VMS. >>>>explicitly. I can't think of anything I have done that actually >>>>needed it. >>> >>> >>> You only program in C,C++,Java and you never view your files on a >>> terminal (type or edit) or printer? You never perused a directory? >>> >>> Yes, those can be done without RMS, UNIX and DOS are examples. As >>> long as someone provided the missing component somewhere. Your >>> terminal and printer didn't come out of the box thinking LF implied >>> CR, although some hardware is settable to provide that. >>> >> >>Not to mention never logging in.... SYSUAF.DAT is an RMS indexed file. :-) > > > I login to lots of systems everyday without the help of RMS. Tell me again > why it is "needed" for this task? > > RMS may be great at what it does but for a very large number of tasks > it is just overhead. > > bill > RMS is "needed" to access an Indexed Sequential file! In Unix you have to do a sequential search of /etc/passwd and/or /etc/shadow to find the user name. It's no problem if you have ten or fifteen users. If you have 1500 users it could get a little slow. User authorization is one of those applications that does not really lend itself to sequential access! ------------------------------ Date: Fri, 24 Aug 2007 20:36:02 -0500 From: "Paul Raulerson" Subject: RE: COBOL Transactions? Message-ID: <008d01c7e6b8$4bf7cb10$e3e76130$@com> > > On Aug 24, 11:15 am, "Paul Raulerson" wrote: > > >>What you *seem* to be objecting to is when I say, "Here is what I > >>need to do, here is how I would normally do it, what is the facility > >>under VMS that does this?" > > Without rereading everything you've ever posted I'd have to say that > I don't recall ever seeing you pose a question in that form. > Well, that could well be. Electronic communications often lack the richness of face to face or more formal communications. That does not, however, imply that there was any malicious, or other intent. Or in other words, you are reading far more into a simple statement than what is really there. > What you have done -- and what disturbs me -- is make statements (or > implications) about OpenVMS' inability to perform a variety of tasks > when you have no knowledge of whether or not it can do those things. > > For example, here are some things you have said ... > > >>> The only issue with the Alpha is that the 4mm tape drive on it > >>> does not seem to be recognized. ... and off to the UNIX machine > >>> which *does* know how to talk to tape. > I'll use this one as an example. Perhaps if I had said "talk to *a* tape" it would have disturbed you less. But in actual, plain, unassailable fact, the ALPHA *machine* does NOT know how to talk to a tape right now. The UNIX *machine* does. There is not implication at all regarding a comparison to Operating Systems there. > >>> When I create an indexed file in COBOL, is it using Rdb? If so, > >>> it quacks a lot like a filesystem to me. > > >>> if they are VSAM (which is the the same as RDB on VMS) So ignorance is a crime? Several people pointed out to the that RDB is a database, and RMS is a file system. I believe I expressed embarrassment at that. On the other hand, how many people here might mix up a 3390 and 3990 in the mainframe world? Probably a few. > >> Why in heavens name would I, or *anyone* for that matter, go chasing > >> around a hunk of hardware that is either not supported or simply > >> broken when the needed capabilty is available on another resource > >> which is working? > > Because it's your development system and most people I know would like > their development systems to be fully functional. How will you > develop > a backup procedure for your client's on Alpha if you can't get it to > work at home? How will you back up your ported source code at the > HP porting event if you haven't practiced it under OpenVMS at home? > I won't be supporting Alphas - only Itanium. There might be some compelling reasons to support Alpha's I don't know about. There are probably reasons to support Vax's. But, to the best of my knowledge, the compelling business case is to support Itanium. > (And, even though you profess to port to Integrity you may come across > a potential sale of your software at a client that already has Alpha > and doesn't want to buy new systems. Be prepared.) > > >> Better yet, why in heavens name would you assume I would NOT backup > >> valuable (at least to me) work on which I have spent much time > >> and effort? > > Huh? Where did I make that assumption? > When you assumed I was complaining that VMS would not talk to tape of course. What else could you possibly have meant? I do believe again you are reading much more into simple questions, sometimes driven by excitement, than is reasonable to assume. I am really developing a passion for VMS, but - I don't have time to explore all the things I would like to do now. I really really don't have much time at all to fight with hardware I intend to replace. In the meantime, I intend to use that same resource to best effect. By the way, when I bought it, it was just to play with. I had no idea that VMS was a viable platform to port our software to, or use for some of the things I have learned it is useful for. As for my experience level - well- I'll send you a set of mainframe disks if you wish. You are welcome to try and get to a comparable level of inexperience in a few months. The situations are very close. If you feel that I am being abrasive in some way, then I feel bad for you and will try to be more polite to you in the future. If on the other hand, you think I have time to waste and should not be able to make decisions about hardware and such, then I am truly sorry but I disagree. Especially about something as simple as a misbehaving tape drive. (Again note, I am talking about hardware - a tape drive - has nothing to do with VMS.) By the way, just would your experience tell is the case when a tape device shows up in the bios SHOW DEV but not in the VMS SHOW DEV? -Paul ------------------------------ Date: Fri, 24 Aug 2007 20:53:07 -0500 From: "Paul Raulerson" Subject: RE: COBOL Transactions? Message-ID: <008e01c7e6ba$aeffbe50$0cff3af0$@com> LOL! Well Alan, thank you for that thoughtful answer. I layered a bit of sarcasm in there which you gallantly and kindly ignored. Comments below... -Paul > -----Original Message----- > From: Alan Winston - SSRL Central Computing > [mailto:winston@SSRL.SLAC.STANFORD.EDU] > Sent: Friday, August 24, 2007 4:50 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: COBOL Transactions? > > Wow. (I took an RPG-II class in school about 1979. The language > you're > describing really isn't something I'd recognize. I would have thought > those > features (column orientation, easy automatic totals, etc, etc) were the > main > reasons for the language to even *exist*. How did it evolve in this > way? > (Truth in Posting: I do have a financial interest in a commercial RPG Compiler for Windows.) It really isn't the same language anymore. Here's a snippet of fairly modern RPG code: // Loop through replacing FILENAME with the value from the input parameter. Read QFTPSRC; // Priming read. DoW NOT %eof(QFTPSRC); // Begin main processing loop. position =%Scan('FILENAME':SRCDTA); if position > 0; SRCDTA = %Replace(%TrimR(filename):SRCDTA:position:8); Update FTPREC; endif; Read QFTPSRC; // Get next record for loop. EndDo; // End main processing loop. The language evolved primarily on the AS/400 systems, because people just started doing pretty fantastic things with it. The snippet above, for instance is working with a programmatic FTP transfer. > > I bet Hein can answer those questions for you. (I am _not_ an RMS > jock.) > I bet he can too. > >How easy is it to expand VMS volumes when necessary, and when/wh= > >ere does degration of performance set in? (If you don't understand > what I= > > mean by degredation, consider it in light of the CI question above.) > > > > If volumes means what I think it means (and maybe it doesn't), if you > have a > 'disk' on a SAN (so the actualy underlying volume can actually change > size when > you twiddle the SAN bits to allocate more apce to it), life is good if > you > initially did a > > $ SET VOLUME/LIMIT > > when you first set the disk up, since that enables the volume to have > its size > reset up to the VMS limit (1 Terabyte per volume) without having to > dismount > the volume or otherwise take it out of service, just by using the > > $ SET VOLUME/SIZE > I think we mean the same things by a "volume." :) Very cool information. The one terabyte limit is not a problem in the SMB world I think, though it could grow to be I suppose. Or there are ways around it I bet. Thanks -Paul ------------------------------ Date: Fri, 24 Aug 2007 21:25:00 -0500 From: "Paul Raulerson" Subject: RE: COBOL Transactions? Message-ID: <008f01c7e6bf$233079f0$69916dd0$@com> Aw gee- now I feel a bit abashed again at the mild sarcasm in the referenced message. A few comments below. > -----Original Message----- > From: Hein RMS van den Heuvel [mailto:heinvandenheuvel@gmail.com] > Sent: Friday, August 24, 2007 8:23 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: COBOL Transactions? > > On Aug 24, 5:50 pm, wins...@SSRL.SLAC.STANFORD.EDU (Alan Winston - > SSRL Central Computing) wrote: > > In article , "Paul Raulerson" > writes: > > > >"is it RDB or RMS that handles indexed file support" > > An important claim to fame for RMS is native support for indexed > files, available to all OpenVMS languaes, DCL included. > Yes, and this is more than just claim to fame, it is *really* good stuff. And impressive work. Simple in some ways, but elegant. > > >Okay, what is the equivalent in RMS of sepcifying the CI intervals > to con trol splits? > > Dunno. A quick google did not enlighten me as to what either might > mean. This was really unfair, since it is involved with VSAM tuning, a black art if ever there was one. CI is Control-Interval and CA is Control Area. A CA is formed by two or more CIs put together, are fixed length, and continguous on the DASD. They are *usually* the size of the DASD cylinder. When a CI is full and there is no room to insert a new record, a CI split will occur, meaning half the records will be moved to a new CI in the same CA. A CI split will cause I/O to the index (which can cause splits as well) and to several other components that I cannot really remember. If the CA fills up (or a couple other strange conditions) then a CA split will occur, which is as you imagine, relatively expensive in terms of I/O. That's before you look into updating the alternate indicies and such as well. VSAM looks at this stuff, and in general, the CI size you pick, especially for the data component of a VSAM file, can really affect performance. Picking a large CI in an online environment is usually less than optimal. What it boils down to is that on a mainframe, the VSAM performance can be highly tuned based on hardware knowledge and so forth. VSAM has been optimized for many years, as I am sure, has RMS, and they are always hunting for more efficient strategies. VSAM is the underlying technology for DB/2 on the mainframe as well. If you are really interested, I can send you plenty of good reading. ;) > > >> How large a file can RMS support > > It is limited to 1 Terabyte. > It really should be, and actually might be 2**32 * 512 bytes, but the > sign bit is not trusted to have been ignored everywhere. > I think VSAM is currently limited to a couple terabytes per individual file, but I have not ran into that limit recently.;) > >> and where and when does the indexing start to bog down because of > size? > > Never. It is a simlpe semi-balanced B-tree not known to bog down ever. > A well designed large index file often only needs 3 index levels, 4 > absolutely worst case. That's sweet- I assume it is doing something under the covers like storing the block address for the each record in the index(s) and then just searching the relevant data block for the actual record? (Greatly simplified I am sure... :) >But I've seen poorly designed (NOT designed) > indexed files with 10 index level where the end users where just > happy, oblivious to significant performance potential available to > them. RMS Just keeps on working. A blessing and a problem at the same > time. > Yes indeed. Seen that, been guilty of it once myself. I learned. > Last weekend I helped a customer convert a 3-key 100GB indexed file in > less than 2 hours. That's about as big as they are currently in use. > On the same box RMS was managing a 150GB fixed length record > sequential file. > That's quite respectable. I have a project in mind I want to explore that would keep a lot of tiny little files on the system, and provide them upon request to the web. How does RMS handle variable length sequential (and indexed) records? Is it very efficient with them, packing them well into data blocks, or does it overlay them on fixed length records? > >> Is there an significant impact on the indexing performance with > software raid > > That question does not compute for VMS. > Raid and indexing are orthogonal, independend technologies. > Raid and help or hurt indexed file access (it tends to help) but your > typical, even your sophisticated, indexed file user would only worry > abot raid as a last recourse. > I can see that. It would on a mainframe because of the tight tuning in terms of hardware. Different DASD, different tuning parameters. > >> and if so, what is the cost/benefit ratio that determines when it > makes sense to move to hardware raid? > > That still does not compute. At best it is of marginal relevance (less > than 10% performance potential) On the mainframe, RAID storage in a SAN is "cheap" compared to just about any other type of available storage. Cheap is relative - around $15K per terabyte used, and $48K per terabyte new is average. > > > I bet Hein can answer those questions for you. (I am _not_ an RMS > jock.) > > Was my name called? :-) > > > >How easy is it to expand VMS volumes when necessary, > > Somewhat easy, but best avoided. > You can MOUNT a second disk to create a bound volume set. > Ah- how large can "volume sets" grow? I was thinking of a volume as what you have identified as a "volume set." > >> and when/where does degration of performance set in? (If you don't > understand what I mean by degredation, consider it in light of the CI > question above.) > > ZERO degradation (well, ok, an extra file header access at times). > I like that, though I am not sure how it can be true. Are there any good books about VMS RMS? I just scanned Ebay and Powells, but didn't find anything. > > If volumes means what I think it means (and maybe it doesn't), if you > have a 'disk' on a SAN (so the actualy underlying volume can actually > change size when you twiddle the SAN bits to allocate more apce to it), > life is good if you > > Yes. Life is good. (since a few years now) > > The big beauty of RMS perhpas is TRANSPARANCY. > It isolates program from storage considerations. > Amen- that is a beautiful thing, but also a bit scary in a way. Not really anything to worry about in any case. > hth, > Hein ------------------------------ Date: Sat, 25 Aug 2007 02:21:57 GMT From: winston@SSRL.SLAC.STANFORD.EDU (Alan Winston - SSRL Central Computing) Subject: RE: COBOL Transactions? Message-ID: <00A6CA0C.801F865F@SSRL.SLAC.STANFORD.EDU> In article <008e01c7e6ba$aeffbe50$0cff3af0$@com>, "Paul Raulerson" writes: >LOL! Well Alan, thank you for that thoughtful answer. I layered a bit of >sarcasm in there >which you gallantly and kindly ignored. Comments below... I read you as being involved in making a serious effort to port code that you believe will let you sell VMS into the SMB space, which is someplace that I have long felt VMS ought to be, and which HP hasn't seemed to be particularly interested in. (An OS that, once configured properly, is pretty close to bulletproof and doesn't require a full-time system administrator makes a whole lot of space, for, eg, the system that runs a video store or a clothing store, etc. But HP needs to make it cheap enough and provide entry-level systems.) Anyway, your project is something I'm very much in favor of, since I want more new/more customers for VMS so that the division remains profitable and I get to keep working on it. I don't want this to be an exclusive club. That motivates me to ignore sarcasm. >> -----Original Message----- >> From: Alan Winston - SSRL Central Computing >> [mailto:winston@SSRL.SLAC.STANFORD.EDU] >> Sent: Friday, August 24, 2007 4:50 PM >> To: Info-VAX@Mvb.Saic.Com >> Subject: Re: COBOL Transactions? >> >> Wow. (I took an RPG-II class in school about 1979. The language >> you're >> describing really isn't something I'd recognize. I would have thought >> those >> features (column orientation, easy automatic totals, etc, etc) were the >> main >> reasons for the language to even *exist*. How did it evolve in this >> way? >> > >(Truth in Posting: I do have a financial interest >in a commercial RPG Compiler for Windows.) > >It really isn't the same language anymore. >Here's a snippet of fairly modern RPG code: > >// Loop through replacing FILENAME with the value from the input parameter. > > > Read QFTPSRC; // Priming read. > DoW NOT %eof(QFTPSRC); // Begin main >processing loop. > position =%Scan('FILENAME':SRCDTA); > if position > 0; > SRCDTA = %Replace(%TrimR(filename):SRCDTA:position:8); > Update FTPREC; > endif; > Read QFTPSRC; // Get next record for >loop. > EndDo; // End main processing >loop. > >The language evolved primarily on the AS/400 systems, because people just >started doing pretty fantastic things with it. The snippet above, for >instance >is working with a programmatic FTP transfer. Wow. If you'd just shown me that code and asked me to guess what language it was in, RPG would have been below SNOBOL on the list. (I would probably have guessed REXX because I don't know Rexx but this looks like a shell script or glue language with a wordy-rather-than-terse background. -- Alan ------------------------------ Date: Sat, 25 Aug 2007 02:42:10 +0000 From: "Main, Kerry" Subject: RE: COBOL Transactions? Message-ID: > -----Original Message----- > From: Paul Raulerson [mailto:paul@raulersons.com] > Sent: August 24, 2007 9:10 PM > To: Main, Kerry; Info-VAX@Mvb.Saic.Com > Subject: RE: COBOL Transactions? > > >Here is pretty good brochure on new Integrity licenses and what is in > each > FOE, EOE, MCOE level. > > > >http://h71028.www7.hp.com/ERC/downloads/4AA0-2321ENW.pdf > > Aw gee Kerry- this is EXACTLY what I have been pestering people at HP > for. > All I need to add (so far), for the very small SMB customers, is RMS > Journaling to the base package. This little nugget of information has > helped > to turn a pretty lousy week into a nice weekend... > > Thank you. > -Paul > Just remember us Canucks work for beer .. and we are pretty picky. It has to be cold and have alcohol in it. :-) 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: Fri, 24 Aug 2007 22:16:35 -0500 From: Ron Johnson Subject: Re: COBOL Transactions? Message-ID: On 08/24/07 20:36, Paul Raulerson wrote: >> On Aug 24, 11:15 am, "Paul Raulerson" wrote: >> [snip] >> >> For example, here are some things you have said ... >> >>>>> The only issue with the Alpha is that the 4mm tape drive on it >>>>> does not seem to be recognized. ... and off to the UNIX machine >>>>> which *does* know how to talk to tape. > > I'll use this one as an example. Perhaps if I had said "talk to *a* tape" > it would have disturbed you less. But in actual, plain, unassailable fact, > the ALPHA *machine* does NOT know how to talk to a tape right now. And you'd *still* be blindingly wrong. It's stunningly arrogant of you to, in essence, say that since you can't figure it out, it can't be done. I *GUARANTEE* you that thousands of small VMS sites over the years have used 4mm and 8mm DAT drives to backup their data. You've *obviously* and *definitely* done something wrong, and are too dense to realize that you are making insultingly *stupid* comments. > The UNIX *machine* does. There is not implication at all regarding > a comparison to Operating Systems there. [snip > > By the way, just would your experience tell is the case when a tape device > shows > up in the bios SHOW DEV but not in the VMS SHOW DEV? Misconfigured SCSI. -- 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: Fri, 24 Aug 2007 22:20:48 -0500 From: Ron Johnson Subject: Re: COBOL Transactions? Message-ID: On 08/24/07 20:29, Richard B. Gilbert wrote: [snip] > > RMS is "needed" to access an Indexed Sequential file! In Unix you have > to do a sequential search of /etc/passwd and/or /etc/shadow to find the > user name. It's no problem if you have ten or fifteen users. If you > have 1500 users it could get a little slow. > > > User authorization is one of those applications that does not really > lend itself to sequential access! But how often do people actually log in? Twice (morning and after lunch) a day, if you've beaten your users into submission. And during that time when there's heavy login activity, /etc/passwd & /etc/shadow should be buffered by the first few accesses. -- 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: Fri, 24 Aug 2007 22:26:34 -0500 From: Ron Johnson Subject: Re: COBOL Transactions? Message-ID: On 08/24/07 20:04, Paul Raulerson wrote: [snip] > > LOL! Thank you, I'll take that as a complement. At least I put a > "$" in there. ;) The unmounted DKA0: drive is a duplicate of it, > but labeled VMS83$AIPL.... > > What would you suggest is a more appropriate VMS name? I can > change... :) VMS83$IPL is a perfectly adequate name. No need to change! We give our system packs and crazy names like AXPVMSSYS, ALPHASYS and nodenameSYS. -- 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: Sat, 25 Aug 2007 03:48:25 GMT From: John Santos Subject: Re: COBOL Transactions? Message-ID: Paul Raulerson wrote: >>On Aug 24, 11:15 am, "Paul Raulerson" wrote: >> >> >>>>What you *seem* to be objecting to is when I say, "Here is what I >>>>need to do, here is how I would normally do it, what is the facility >>>>under VMS that does this?" >> >>Without rereading everything you've ever posted I'd have to say that >>I don't recall ever seeing you pose a question in that form. >> > > > Well, that could well be. Electronic communications often lack the richness > of face to face or more formal communications. That does not, however, > imply that there was any malicious, or other intent. > > Or in other words, you are reading far more into a simple statement than > what is really there. > > >>What you have done -- and what disturbs me -- is make statements (or >>implications) about OpenVMS' inability to perform a variety of tasks >>when you have no knowledge of whether or not it can do those things. >> >>For example, here are some things you have said ... >> >> >>>>>The only issue with the Alpha is that the 4mm tape drive on it >>>>>does not seem to be recognized. ... and off to the UNIX machine >>>>>which *does* know how to talk to tape. >> > > I'll use this one as an example. Perhaps if I had said "talk to *a* tape" > it would have disturbed you less. But in actual, plain, unassailable fact, > the ALPHA *machine* does NOT know how to talk to a tape right now. > The UNIX *machine* does. There is not implication at all regarding > a comparison to Operating Systems there. > > > >>>>>When I create an indexed file in COBOL, is it using Rdb? If so, >>>>>it quacks a lot like a filesystem to me. >> >>>>>if they are VSAM (which is the the same as RDB on VMS) > > > So ignorance is a crime? Several people pointed out to the that RDB > is a database, and RMS is a file system. I believe I expressed > embarrassment at that. On the other hand, how many people here > might mix up a 3390 and 3990 in the mainframe world? Probably a > few. > > >>>>Why in heavens name would I, or *anyone* for that matter, go chasing >>>>around a hunk of hardware that is either not supported or simply >>>>broken when the needed capabilty is available on another resource >>>>which is working? >> >>Because it's your development system and most people I know would like >>their development systems to be fully functional. How will you >>develop >>a backup procedure for your client's on Alpha if you can't get it to >>work at home? How will you back up your ported source code at the >>HP porting event if you haven't practiced it under OpenVMS at home? >> > > > I won't be supporting Alphas - only Itanium. There might be some compelling > reasons to support Alpha's I don't know about. There are probably reasons > to support Vax's. But, to the best of my knowledge, the compelling business > case is to support Itanium. > > >>(And, even though you profess to port to Integrity you may come across >>a potential sale of your software at a client that already has Alpha >>and doesn't want to buy new systems. Be prepared.) >> >> >>>>Better yet, why in heavens name would you assume I would NOT backup >>>>valuable (at least to me) work on which I have spent much time >>>>and effort? >> >>Huh? Where did I make that assumption? >> > > > When you assumed I was complaining that VMS would not talk to tape of > course. > What else could you possibly have meant? > > I do believe again you are reading much more into simple questions, > sometimes driven by excitement, than is reasonable to assume. I am > really developing a passion for VMS, but - I don't have time to explore > all the things I would like to do now. I really really don't have much > time at all to fight with hardware I intend to replace. In the meantime, > I intend to use that same resource to best effect. > > By the way, when I bought it, it was just to play with. I had no idea that > VMS was a viable platform to port our software to, or use for some of the > things I have learned it is useful for. > > As for my experience level - well- I'll send you a set of mainframe disks if > you wish. You are welcome to try and get to a comparable level of > inexperience > in a few months. The situations are very close. > > If you feel that I am being abrasive in some way, then I feel bad for you > and > will try to be more polite to you in the future. If on the other hand, you > think I have time to waste and should not be able to make decisions about > hardware and such, then I am truly sorry but I disagree. Especially about > something as simple as a misbehaving tape drive. (Again note, I am talking > about hardware - a tape drive - has nothing to do with VMS.) > > By the way, just would your experience tell is the case when a tape device > shows > up in the bios SHOW DEV but not in the VMS SHOW DEV? > > -Paul 4 reasons I can think of: 1) The tape drive is broken (but usually, a broken tape drive will show up; it just won't work.) 2) It's an unsupported model. (What does srm's SHOW DEV show about it? What model number is it? Is there a sticker or label on the back (assuming it's an external tape drive that you can look at.) 3a) Configuration problem. I think it is possible to disable devices by messing with sys$system:sys$config.dat or sys$user_config.dat. Maybe yours is broken? (If you installed the system yourself, this is very unlikely. If you inherited it from someone else, maybe they broke it. In this case, booting from the CD drive and picking the "Execute DCL commands" option and then doing a SHOW DEVICE from the $$$ prompt might be revealing. 3b) Configuration problem. Maybe there is a problem with the SCSI cables (bad cable, bus length) or termination (missing, double) or a dip switch, etc. on the drive itself. 4) Software problem. I think you said you're running V8.3... I don't remember too many problems with this stuff in that version, but maybe there is a patch (ECO) to the tape driver or system routines that would fix this. (I couldn't find anything obvious in a brief scan of the ECO release notes.) -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: Fri, 24 Aug 2007 22:52:20 -0500 From: "Paul Raulerson" Subject: RE: COBOL Transactions? Message-ID: <009401c7e6cb$56d86400$04892c00$@com> > -----Original Message----- > From: Ron Johnson [mailto:ron.l.johnson@cox.net] > Sent: Friday, August 24, 2007 10:17 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: COBOL Transactions? > > On 08/24/07 20:36, Paul Raulerson wrote: > >> On Aug 24, 11:15 am, "Paul Raulerson" wrote: > >> > [snip] > >> > >> For example, here are some things you have said ... > >> > >>>>> The only issue with the Alpha is that the 4mm tape drive on it > >>>>> does not seem to be recognized. ... and off to the UNIX machine > >>>>> which *does* know how to talk to tape. > > > > I'll use this one as an example. Perhaps if I had said "talk to *a* > tape" > > it would have disturbed you less. But in actual, plain, unassailable > fact, > > the ALPHA *machine* does NOT know how to talk to a tape right now. > Why do you insist on reading anything into this other than the tape device is not working? What in the world are you hearing? Whatever it is, it is NOT what I am saying. > And you'd *still* be blindingly wrong. It's stunningly arrogant of > you to, in essence, say that since you can't figure it out, it can't > be done. > > I *GUARANTEE* you that thousands of small VMS sites over the years > have used 4mm and 8mm DAT drives to backup their data. > And what has that go to do with anything? > You've *obviously* and *definitely* done something wrong, and are > too dense to realize that you are making insultingly *stupid* comments. > Really? Well, I guess I will just go on being dense then. Please explain to me why I should believe I have misconfigured a SCSI bus that everything else, disk, CD, etc, *works* on, the device is seen by the BIOS, and oh yeah, if I pull the drive, like I just did, and put it on another machine, it works fine. I'd say that VMS does not support that device. Now if ***you*** want to be silly and associate with the word "device", with every tape drive in the world and assume someone else is stupid enough to not know the difference, that is *your* problem. > > The UNIX *machine* does. There is not implication at all regarding > > a comparison to Operating Systems there. > [snip > > > > By the way, just would your experience tell is the case when a tape > device > > shows > > up in the bios SHOW DEV but not in the VMS SHOW DEV? > > Misconfigured SCSI. > Just to be thorough, I'm not entirely sure how you could misconfigure a single SCSI device and not have any other effects on the bus. People whose opinions I really respect have indicated that SCSI drives under VMS are pretty about what devices they will accept. I see no reason to doubt or question that. Perhaps you know more than I do though. If you insist on putting silly meanings on this, then you might as well assume I said something *totally* silly, like VMS blew up my tape drive or something. At least that would be humorous. -Paul > -- > 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: Fri, 24 Aug 2007 23:50:49 -0500 From: Ron Johnson Subject: Re: COBOL Transactions? Message-ID: On 08/24/07 22:52, Paul Raulerson wrote: > >> -----Original Message----- >> From: Ron Johnson [mailto:ron.l.johnson@cox.net] >> Sent: Friday, August 24, 2007 10:17 PM >> To: Info-VAX@Mvb.Saic.Com >> Subject: Re: COBOL Transactions? >> >> On 08/24/07 20:36, Paul Raulerson wrote: >>>> On Aug 24, 11:15 am, "Paul Raulerson" wrote: >>>> >> [snip] >>>> For example, here are some things you have said ... >>>> >>>>>>> The only issue with the Alpha is that the 4mm tape drive on it >>>>>>> does not seem to be recognized. ... and off to the UNIX machine >>>>>>> which *does* know how to talk to tape. >>> I'll use this one as an example. Perhaps if I had said "talk to *a* >> tape" >>> it would have disturbed you less. But in actual, plain, unassailable >> fact, >>> the ALPHA *machine* does NOT know how to talk to a tape right now. > > Why do you insist on reading anything into this other than the tape > device is not working? What in the world are you hearing? You've developed an "I don't know how to do it, so VMS must not be able to do it" reputation. > Whatever it is, it is NOT what I am saying. In the post that began this threadlet, you wrote: UNIX machine which *does* know how to talk to tape. Which, given your poor reputation, leads us to read that you think that VMS does *not* know how to talk to tape. >> And you'd *still* be blindingly wrong. It's stunningly arrogant of >> you to, in essence, say that since you can't figure it out, it can't >> be done. >> >> I *GUARANTEE* you that thousands of small VMS sites over the years >> have used 4mm and 8mm DAT drives to backup their data. >> > > And what has that go to do with anything? Shows that VMS does (and has for ages) recognize 4mm DAT drives. >> You've *obviously* and *definitely* done something wrong, and are >> too dense to realize that you are making insultingly *stupid* comments. >> > > Really? Well, I guess I will just go on being dense then. Please explain > to me why I should believe I have misconfigured a SCSI bus that everything > else, disk, CD, etc, *works* on, the device is seen by the BIOS, and oh > yeah, > if I pull the drive, like I just did, and put it on another machine, it > works > fine. SCSI is finicky and easy to misconfigure. > I'd say that VMS does not support that device. > > Now if ***you*** want to be silly and associate with the word "device", > with every tape drive in the world and assume someone else is stupid enough > to not know the difference, that is *your* problem. > > > >>> The UNIX *machine* does. There is not implication at all regarding >>> a comparison to Operating Systems there. >> [snip >>> By the way, just would your experience tell is the case when a tape >> device >>> shows >>> up in the bios SHOW DEV but not in the VMS SHOW DEV? >> Misconfigured SCSI. >> > > Just to be thorough, I'm not entirely sure how you could misconfigure > a single SCSI device and not have any other effects on the bus. People Forgot to terminate the bus? VMS is improperly configured? > whose opinions I really respect have indicated that SCSI drives under VMS > are pretty about what devices they will accept. I see no reason to doubt or Petty? > question that. > > Perhaps you know more than I do though. About VMS? Sure. COBOL? No. -- 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: Fri, 24 Aug 2007 18:04:20 GMT From: John Santos Subject: Re: decnet startup failing Message-ID: Peter 'EPLAN' LANGSTOeGER wrote: > 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. > The default is to start DECnet (any version) before starting TCP/IP, so unless you've messed around with it, you won't see the problem. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: 24 Aug 2007 12:58:42 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: DECnet-Plus for a hobbyist Message-ID: In article , JF Mezei writes: > Bob Koehler wrote: >> I think that's a bit stronger statement than reality. The only >> thing DECnet Phase IV and MOP have in common is using NCP and the >> NCP database as management tools. I can see why you might use >> "control" in that context, but the DECnet stack does not control >> the MOP stack. > > Out of curiosity, who registers with the ethernet driver the "if you see > a MOP packet, send it to me" ? Yes, there is a MOP stack in VMS somewhere. > In an environment where you have LANCP, is it correct that while a boot > node boots, it will not serve any MOP requests until LANACP has started ? Don't know, but I think so. > In an environment that predates LANCP, did LANACP exist ? I don't know where the code which is now in LANACP existed before, it might actually have been stuck in the NETACP, but it's not really the same stack as DECnet. ------------------------------ Date: Fri, 24 Aug 2007 14:45:12 -0400 From: "Richard B. Gilbert" Subject: Re: DECnet-Plus for a hobbyist Message-ID: <46CF2738.7010703@comcast.net> Robert Jarratt wrote: > "Bob Koehler" wrote in message > news:ZqOiOHVCP9HG@eisner.encompasserve.org... > >>In article <46CCE489.38A33AB4@spam.comcast.net>, David J Dachtera >> writes: >> >>>Post the output of SHOW DEVICE E and maybe we can figure out where >>>NETCONFIG > > Is there a relationship between DECnet addresses and SCSSYSTEMID? If so what > is it? Is there a simple explanation somewhere of Phase IV addresses? > SCSSYSTEMID:==AREA*1024+NODE e.g. if your DECnet address 2.7 your SCSYSTEMID= 2*1024+7=2055 There is nothing terribly complicated about DECnet Phase IV addresses. They consist of an "Area" from 1-63 (or 64?? I'm too lazy to look it up!) and a "Node" number from 1-??. Most organizations don't have DECnet networks large enough to tax this addressing scheme; Digital was one of the few organizations larger enough to have a problem. NASA was another. Most of the world now uses TCP/IP which has become the de facto standard. ------------------------------ Date: Fri, 24 Aug 2007 23:50:01 +0300 From: =?ISO-8859-1?Q?Uusim=E4ki?= Subject: Re: DECnet-Plus for a hobbyist Message-ID: <46cf42fd$0$27847$9b536df3@news.fv.fi> JF Mezei wrote: > Bob Koehler wrote: >> I think that's a bit stronger statement than reality. The only >> thing DECnet Phase IV and MOP have in common is using NCP and the >> NCP database as management tools. I can see why you might use >> "control" in that context, but the DECnet stack does not control >> the MOP stack. > > > Out of curiosity, who registers with the ethernet driver the "if you see > a MOP packet, send it to me" ? > > > In an environment where you have LANCP, is it correct that while a boot > node boots, it will not serve any MOP requests until LANACP has started ? > > In an environment that predates LANCP, did LANACP exist ? MOP DL requests are sent to a multicast address, which nodes with MOP enabled will listen to. All the nodes with MOP gets the request and the fastest one serves the request. Did this answer your question? Regards, Kari ------------------------------ Date: Fri, 24 Aug 2007 20:56:40 GMT From: "Robert Jarratt" Subject: Re: DECnet-Plus for a hobbyist Message-ID: "Uusimäki" wrote in message news:46cf42fd$0$27847$9b536df3@news.fv.fi... > JF Mezei wrote: >> Bob Koehler wrote: >>> I think that's a bit stronger statement than reality. The only >>> thing DECnet Phase IV and MOP have in common is using NCP and the >>> NCP database as management tools. I can see why you might use >>> "control" in that context, but the DECnet stack does not control >>> the MOP stack. >> >> >> Out of curiosity, who registers with the ethernet driver the "if you see >> a MOP packet, send it to me" ? >> >> >> In an environment where you have LANCP, is it correct that while a boot >> node boots, it will not serve any MOP requests until LANACP has started ? >> >> In an environment that predates LANCP, did LANACP exist ? > > MOP DL requests are sent to a multicast address, which nodes with MOP > enabled will listen to. All the nodes with MOP gets the request and the > fastest one serves the request. > > Did this answer your question? > > > Regards, > > Kari > I successfully ran DVSCONFIG.COM to configure the DECserver firmware download, but the DECserver fail to download it. I am having other console issues with the DECserver so I don't know if it works, but it may be that there is something else that I have to start on the VMS side, what do I need to check is running? This is VMS 7.3. And this is the output of SH SYS: Pid Process Name State Pri I/O CPU Page flts Pages 00000081 SWAPPER HIB 16 0 0 00:00:00.54 0 0 00000084 LANACP HIB 13 61 0 00:00:00.44 368 796 00000086 IPCACP HIB 10 7 0 00:00:00.07 99 167 00000087 ERRFMT HIB 8 612 0 00:00:02.58 145 216 00000089 OPCOM HIB 8 158 0 00:00:00.54 314 153 0000008A AUDIT_SERVER HIB 10 56 0 00:00:00.55 525 679 0000008B JOB_CONTROL HIB 10 33 0 00:00:00.17 153 294 0000008C SECURITY_SERVER HIB 10 22 0 00:00:26.22 757 1014 0000008D NETACP HIB 9 240 0 00:00:01.33 205 323 0000008E EVL HIB 6 139 0 00:00:00.57 365 582 N 0000008F REMACP HIB 8 18 0 00:00:00.07 111 69 00000090 TCPIP$INETACP HIB 8 113 0 00:00:00.98 713 810 00000095 SYSTEM LEF 9 4194 0 00:00:45.45 30170 288 00000096 _TNA5: CUR 4 541 0 00:00:06.78 4223 340 Thanks Rob ------------------------------ Date: Fri, 24 Aug 2007 21:08:55 GMT From: "Robert Jarratt" Subject: Re: DECnet-Plus for a hobbyist Message-ID: "Richard B. Gilbert" wrote in message news:46CF2738.7010703@comcast.net... > Robert Jarratt wrote: >> "Bob Koehler" wrote in message >> news:ZqOiOHVCP9HG@eisner.encompasserve.org... >> >>>In article <46CCE489.38A33AB4@spam.comcast.net>, David J Dachtera >>> writes: >>> >>>>Post the output of SHOW DEVICE E and maybe we can figure out where >>>>NETCONFIG > >> >> Is there a relationship between DECnet addresses and SCSSYSTEMID? If so >> what is it? Is there a simple explanation somewhere of Phase IV >> addresses? >> > SCSSYSTEMID:==AREA*1024+NODE > e.g. if your DECnet address 2.7 your SCSYSTEMID= 2*1024+7=2055 > > There is nothing terribly complicated about DECnet Phase IV addresses. > They consist of an "Area" from 1-63 (or 64?? I'm too lazy to look it up!) > and a "Node" number from 1-??. Most organizations don't have DECnet > networks large enough to tax this addressing scheme; Digital was one of > the few organizations larger enough to have a problem. NASA was another. > Most of the world now uses TCP/IP which has become the de facto standard. > > So what happens if I use an SCSSYSTEMID of 1025 and then I set a DECnet address of 1.2 (say)? ------------------------------ Date: Fri, 24 Aug 2007 22:17:47 GMT From: "Robert Jarratt" Subject: Re: DECnet-Plus for a hobbyist Message-ID: "Richard B. Gilbert" wrote in message news:46CF2738.7010703@comcast.net... > Robert Jarratt wrote: >> "Bob Koehler" wrote in message >> news:ZqOiOHVCP9HG@eisner.encompasserve.org... >> >>>In article <46CCE489.38A33AB4@spam.comcast.net>, David J Dachtera >>> writes: >>> >>>>Post the output of SHOW DEVICE E and maybe we can figure out where >>>>NETCONFIG > >> >> Is there a relationship between DECnet addresses and SCSSYSTEMID? If so >> what is it? Is there a simple explanation somewhere of Phase IV >> addresses? >> > SCSSYSTEMID:==AREA*1024+NODE > e.g. if your DECnet address 2.7 your SCSYSTEMID= 2*1024+7=2055 > > There is nothing terribly complicated about DECnet Phase IV addresses. > They consist of an "Area" from 1-63 (or 64?? I'm too lazy to look it up!) > and a "Node" number from 1-??. Most organizations don't have DECnet > networks large enough to tax this addressing scheme; Digital was one of > the few organizations larger enough to have a problem. NASA was another. > Most of the world now uses TCP/IP which has become the de facto standard. > > I think my posts are sometimes going missing, so again I am posting this again and apologise for any duplication: What happens if the SCSSYSTEMID and the DECnet address don't correspond according to the formula above? Thanks ------------------------------ Date: Fri, 24 Aug 2007 22:20:57 GMT From: "Robert Jarratt" Subject: Re: DECnet-Plus for a hobbyist Message-ID: "Bob Koehler" wrote in message news:TSU5oNDbetbA@eisner.encompasserve.org... > In article , JF Mezei > writes: >> Bob Koehler wrote: >>> I think that's a bit stronger statement than reality. The only >>> thing DECnet Phase IV and MOP have in common is using NCP and the >>> NCP database as management tools. I can see why you might use >>> "control" in that context, but the DECnet stack does not control >>> the MOP stack. >> >> Out of curiosity, who registers with the ethernet driver the "if you see >> a MOP packet, send it to me" ? > > Yes, there is a MOP stack in VMS somewhere. > >> In an environment where you have LANCP, is it correct that while a boot >> node boots, it will not serve any MOP requests until LANACP has started ? > > Don't know, but I think so. > >> In an environment that predates LANCP, did LANACP exist ? > > I don't know where the code which is now in LANACP existed before, > it might actually have been stuck in the NETACP, but it's not really > the same stack as DECnet. > I think my posts are sometimes going missing, so again I am posting this again and apologise for any duplication: I have used DVSCONFIG to set up the firmware download to a DECserver, but the DECserver is failing to download. I am not entirely confident that the DECserver works (I can't get a console), what needs to be running on the VAX for the download to work. Here is the output from SH SYS: $ sh sys OpenVMS V7.3 on node VLC 24-AUG-2007 23:21:58.62 Uptime 1 00:15:09 Pid Process Name State Pri I/O CPU Page flts Pages 00000081 SWAPPER HIB 16 0 0 00:00:00.57 0 0 00000084 LANACP HIB 13 61 0 00:00:00.44 368 796 00000086 IPCACP HIB 10 7 0 00:00:00.07 99 167 00000087 ERRFMT HIB 8 652 0 00:00:02.77 145 216 00000089 OPCOM HIB 8 171 0 00:00:00.57 315 154 0000008A AUDIT_SERVER HIB 10 60 0 00:00:00.57 525 679 0000008B JOB_CONTROL HIB 10 38 0 00:00:00.17 153 294 0000008C SECURITY_SERVER HIB 10 26 0 00:00:28.14 1774 1628 0000008D NETACP HIB 10 267 0 00:00:01.42 209 327 0000008E EVL HIB 6 139 0 00:00:00.57 365 582 N 0000008F REMACP HIB 8 18 0 00:00:00.07 111 69 00000090 TCPIP$INETACP HIB 8 127 0 00:00:01.04 713 810 0000009D SYSTEM CUR 4 132 0 00:00:01.39 1030 367 ------------------------------ Date: Fri, 24 Aug 2007 19:06:51 -0400 From: JF Mezei Subject: Re: DECnet-Plus for a hobbyist Message-ID: <3cfd6$46cf648c$cef8887a$31301@TEKSAVVY.COM> Uusimäki wrote: > MOP DL requests are sent to a multicast address, which nodes with MOP > enabled will listen to. All the nodes with MOP gets the request and the > fastest one serves the request. > > Did this answer your question? Nop. At the VMS level, in an environment without LANCP database, which process: 1- Tells the ethernet driver to forward received MOP protocol requests to whatever will handle them ? 2- When a MOP request comes in, is a new process created, or ir there an existing process which does it ? (and if so, which process). With LANCP, it is obvious that LANACP is probably the one registering itself to the ethernet driver as the handler of packets with the MOP protocol bytes. But without LANCP, it has never been obvious to me which one it would have been (if it wasn't DECNET). ------------------------------ Date: Fri, 24 Aug 2007 19:08:22 -0400 From: JF Mezei Subject: Re: DECnet-Plus for a hobbyist Message-ID: <3a305$46cf64e6$cef8887a$31301@TEKSAVVY.COM> Robert Jarratt wrote: > What happens if the SCSSYSTEMID and the DECnet address don't correspond > according to the formula above? When you configure DECNET, it will suggest the right etwork address if SCSSYSTEMID is already set. I suspect it will warn you or perhaps not allow you to make a mistake. If you subsequently reset SCSYSTEMID to something else, I suspect DECNET will fail to start. ------------------------------ Date: Fri, 24 Aug 2007 21:05:11 -0400 From: "Richard B. Gilbert" Subject: Re: DECnet-Plus for a hobbyist Message-ID: <46CF8047.4030008@comcast.net> Robert Jarratt wrote: > "Uusimäki" wrote in message > news:46cf42fd$0$27847$9b536df3@news.fv.fi... > >>JF Mezei wrote: >> >>>Bob Koehler wrote: >>> >>>> I think that's a bit stronger statement than reality. The only >>>> thing DECnet Phase IV and MOP have in common is using NCP and the > > > I successfully ran DVSCONFIG.COM to configure the DECserver firmware > download, but the DECserver fail to download it. I am having other console > issues with the DECserver so I don't know if it works, but it may be that > there is something else that I have to start on the VMS side, what do I need > to check is running? This is VMS 7.3. And this is the output of SH SYS: > > Pid Process Name State Pri I/O CPU Page flts > Pages > 00000081 SWAPPER HIB 16 0 0 00:00:00.54 0 > 0 > 00000084 LANACP HIB 13 61 0 00:00:00.44 368 > 796 > 00000086 IPCACP HIB 10 7 0 00:00:00.07 99 > 167 > 00000087 ERRFMT HIB 8 612 0 00:00:02.58 145 > 216 > 00000089 OPCOM HIB 8 158 0 00:00:00.54 314 > 153 > 0000008A AUDIT_SERVER HIB 10 56 0 00:00:00.55 525 > 679 > 0000008B JOB_CONTROL HIB 10 33 0 00:00:00.17 153 > 294 > 0000008C SECURITY_SERVER HIB 10 22 0 00:00:26.22 757 > 1014 > 0000008D NETACP HIB 9 240 0 00:00:01.33 205 > 323 > 0000008E EVL HIB 6 139 0 00:00:00.57 365 > 582 N > 0000008F REMACP HIB 8 18 0 00:00:00.07 111 > 69 > 00000090 TCPIP$INETACP HIB 8 113 0 00:00:00.98 713 > 810 > 00000095 SYSTEM LEF 9 4194 0 00:00:45.45 30170 > 288 > 00000096 _TNA5: CUR 4 541 0 00:00:06.78 4223 > 340 > > Thanks > > Rob > > At least some DECservers can boot using either MOP or BOOTP (TCP/IP protocol). It attempts to boot using whatever was successful the last time. If you have, as I once did, something that will answer a BOOTP request, and a MOP boot fails, you can get a situation where the DECserver switches over to BOOTP. The way out is to connect it to a VMS system with a crossover cable making sure that VMS cannot respond to a BOOTP request. When BOOTP fails it will try MOP which succeeds and resets things. ------------------------------ Date: Fri, 24 Aug 2007 21:13:21 -0400 From: "Richard B. Gilbert" Subject: Re: DECnet-Plus for a hobbyist Message-ID: <46CF8231.1090901@comcast.net> Robert Jarratt wrote: > "Richard B. Gilbert" wrote in message > news:46CF2738.7010703@comcast.net... > >>Robert Jarratt wrote: >> >>>"Bob Koehler" wrote in message >>>news:ZqOiOHVCP9HG@eisner.encompasserve.org... >>> >>> >>>>In article <46CCE489.38A33AB4@spam.comcast.net>, David J Dachtera >>>> writes: >>>> >>>> >>>>>Post the output of SHOW DEVICE E and maybe we can figure out where >>>>>NETCONFIG >>>> >> >> >>>Is there a relationship between DECnet addresses and SCSSYSTEMID? If so >>>what is it? Is there a simple explanation somewhere of Phase IV >>>addresses? >>> >> >>SCSSYSTEMID:==AREA*1024+NODE >>e.g. if your DECnet address 2.7 your SCSYSTEMID= 2*1024+7=2055 >> >>There is nothing terribly complicated about DECnet Phase IV addresses. >>They consist of an "Area" from 1-63 (or 64?? I'm too lazy to look it up!) >>and a "Node" number from 1-??. Most organizations don't have DECnet >>networks large enough to tax this addressing scheme; Digital was one of >>the few organizations larger enough to have a problem. NASA was another. >>Most of the world now uses TCP/IP which has become the de facto standard. >> >> > > > So what happens if I use an SCSSYSTEMID of 1025 and then I set a DECnet > address of 1.2 (say)? > > > I couldn't say, I never tried it! You really have to work at it to screw it up. If you use the configuration (.COM) files provided, that stuff all gets set up for you when you configure DECnet. FWIW, the 1-?? in my original response should be something like 1-1023 or 1-1024. (I'm still too lazy to look it up!) ------------------------------ Date: Sat, 25 Aug 2007 04:12:28 GMT From: John Santos Subject: Re: DECnet-Plus for a hobbyist Message-ID: Richard B. Gilbert wrote: > Robert Jarratt wrote: > >> "Uusimäki" wrote in message >> news:46cf42fd$0$27847$9b536df3@news.fv.fi... >> >>> JF Mezei wrote: >>> >>>> Bob Koehler wrote: >>>> >>>>> I think that's a bit stronger statement than reality. The only >>>>> thing DECnet Phase IV and MOP have in common is using NCP and the > > > >> >> >> I successfully ran DVSCONFIG.COM to configure the DECserver firmware >> download, but the DECserver fail to download it. I am having other >> console issues with the DECserver so I don't know if it works, but it >> may be that there is something else that I have to start on the VMS >> side, what do I need to check is running? This is VMS 7.3. And this is >> the output of SH SYS: >> >> Pid Process Name State Pri I/O CPU Page flts >> Pages >> 00000081 SWAPPER HIB 16 0 0 00:00:00.54 0 0 >> 00000084 LANACP HIB 13 61 0 00:00:00.44 368 >> 796 >> 00000086 IPCACP HIB 10 7 0 00:00:00.07 99 >> 167 >> 00000087 ERRFMT HIB 8 612 0 00:00:02.58 145 >> 216 >> 00000089 OPCOM HIB 8 158 0 00:00:00.54 314 >> 153 >> 0000008A AUDIT_SERVER HIB 10 56 0 00:00:00.55 525 >> 679 >> 0000008B JOB_CONTROL HIB 10 33 0 00:00:00.17 153 >> 294 >> 0000008C SECURITY_SERVER HIB 10 22 0 00:00:26.22 757 >> 1014 >> 0000008D NETACP HIB 9 240 0 00:00:01.33 205 >> 323 >> 0000008E EVL HIB 6 139 0 00:00:00.57 365 >> 582 N >> 0000008F REMACP HIB 8 18 0 00:00:00.07 111 69 >> 00000090 TCPIP$INETACP HIB 8 113 0 00:00:00.98 713 >> 810 >> 00000095 SYSTEM LEF 9 4194 0 00:00:45.45 30170 >> 288 >> 00000096 _TNA5: CUR 4 541 0 00:00:06.78 4223 >> 340 >> >> Thanks >> >> Rob >> > > At least some DECservers can boot using either MOP or BOOTP (TCP/IP > protocol). It attempts to boot using whatever was successful the last > time. If you have, as I once did, something that will answer a BOOTP > request, and a MOP boot fails, you can get a situation where the > DECserver switches over to BOOTP. The way out is to connect it to a VMS > system with a crossover cable making sure that VMS cannot respond to a > BOOTP request. When BOOTP fails it will try MOP which succeeds and > resets things. There is a bit of magic that will cause a DECServer to reset to its factory default configuration. The exact sequence varies with model, but for some, I think you hold down the reset button while it's powering up. Does your DECServer have a 7-segment LED display? If so, what is it doing? (IIRC, for most models, it counts down from about 8 to about 3 while it selftests, and then waits for a download.) Do you have a terminal or emulator you can connect to port 1? Does it print anything? (8 bit, no parity, 9600 baud, IIRC.) Do you see any OPCOM messages on the VMS system when you power up the DECServer? If the load server (of whatever ilk, DECnet MOP, LANACP MOP, BOOTP) is running, it should notice the download request and log an OPCOM message, and then a 2nd message when it succeeds or fails or defers to another load host. If there are no OPCOM messages, two possibilities: 1) If this is an AUI/Thin-wire DECServer, is the selector switch in the right position. (Twisted-pair DEC servers shouldn't have this issue :-) 2) If the DECServer doesn't get a response to its load request, it will back off for a while and try again. Initially the back off is a minute or two, but I think it can grow to longer than you're probably willing to wait... like hours. Power-cycling should reset this. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: Fri, 24 Aug 2007 22:29:09 -0500 From: David J Dachtera Subject: Re: Here's one for Bob (hope it makes your head spin) Message-ID: <46CFA205.21A68C9A@spam.comcast.net> Ron Johnson wrote: > > On 08/23/07 20:06, David J Dachtera wrote: > > Tom Linden wrote: > >> On Wed, 22 Aug 2007 10:09:40 -0700, wrote: > >> > >>> 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. > >> It suggests a psychosis. > > > > Eh, I don't know as I'd go quite that far until the subject turns to homicide > > bombers and other terrorists. (They're usually called "suicide" bombers; but, > > homicide is their actual intent. Their own death is merely incidental.) > > > > At the risk of sounding like I'm defending anyone, I can't help thinking about > > the early Christians facing the lions and other horrible fates. Surely, these > > innocents did nothing to deserve to die that way. THEY were truly martyrs, dying > > for their chosen convictions, and "convicted" of nothing worthy of death. > > Or Jews in Europe and blacks in America. Well, be careful there. The British Colonists (before they became "America") brought Africans to North America against their will under deplorable conditions to live and work under deplorable conditions, but that had nothing to do with the religious (or any other) convictions of the Africans. A bit of stupidity on the part of our forefathers was that they considered the Africans to be human-like, but not entirely human. During the first part of the 20th Century, Jews in Europe were persecuted because they were Jewish. Remember: Jews were considered a race more than a religious denomination. It could just as easily have been purple people persecuting the green because they were green and not purple. The Nazis targetted racial purity more than religious leanings (the "master race" thing). -- 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: Fri, 24 Aug 2007 22:30:37 -0500 From: David J Dachtera Subject: Re: Here's one for Bob (hope it makes your head spin) Message-ID: <46CFA25D.8D42E644@spam.comcast.net> "Dr. Dweeb" wrote: > > Ron Johnson wrote: > > On 08/23/07 14:00, FredK wrote: > > [snip] > >> > >> Now, now Bob. Please. We know that both the Old and New Testaments > >> *have* changed over time. First translation IN ITSELF can change > >> the meaning. Second we know that there were several major revisions > >> made to the New > > > > Which is why old Muslims are smart to make young Muslims (no matter > > their ethnicity) learn Arabic, so that they can read the Koran in > > the original language. > > > > Errr - not quite. The Koran is noted for its "mistranslation" as a matter of > dogma as much as any other reason. > Knock yourself out here, or any other place that documents this issue > http://www.blessedcause.org/Quran.htm After reading some of this tuff - I tell ya: its frightening! -- 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: Fri, 24 Aug 2007 18:26:38 GMT From: Tad Winters Subject: Re: How to detect duplicate auto-resubmiting batch job Message-ID: vancouvercancun@yahoo.ca wrote in news:1187122509.791422.293350 @l22g2000prc.googlegroups.com: > Hi everybody > I have a auto-resubmiting daily disk cleaning job. It is submitted at > startup and should be resubmitting itself after running every day at > 8h00. Yesterday, I noticed I now have 3 entries for the same job, all > waiting to execute at the same time. Notwithstanding the fact that > some startup job is submitting the batch more than once(I will need to > find it!), I need to add code to my DCL procedure to verify that only > one job is present. > > What is the usual way to detect that there is only one instance/job/ > batch of the procedure running daily ? What code can I use in DCL to > verify that I have only one version of the batch job present in the > queue ? Can you provide examples ? > > Here is a part of my cleaning.com procedure: > > $ datelog = f$cvtime("tomorrow","comparison","date") > $ submit /queue=sys$batch /noprinter /nonotify /restart /log=my > $log:cleaning-'datelog'.log - > /after="tomorrow+08:" cleaning.com > $ delete my$log:*.log;*/cre/before=today-30-0 > $ ... > > Yesterday, I had 3 entries waiting to execute at 8h00. I would like > entries 2 and 3 to kill themselves if there is already a same job > present in the queue. Notice all 3 will be begin executing in the same > split second. > Suggestions ? Examples ? Links to code ? > TIA > Van > It's interesting to see the variety of solutions. Since you only want the job to run once a day, it would seem that the job should immediately create a file unique for that day, e.g. cleaning.2007- 08-24;32767, in a directory which only grants write access to the username running this job. If the creation of the file fails and it is then found to exist, the current job should be aborted (because another job is running or already ran.) If this test is performed before the resubmit logic, the queue will be cleaned by attrition. The problem I see with using a process naming method is the potential for an interactive user setting their own process name to match, as they tinker. Similarly, users can create jobs with the same name. If you plan to use the F$GETQUI lexical, you'd certainly want to check the username and/or the command procedure for the jobs with matching names. If you were only concerned with the command procedure running concurrent to other instances, the solution there is probably something like a clusterwide resource lock, or even an empty file opened with exclusive access, and then just looping (with some delay) until it is able to open that file. Hopefully, the solution you find will serve you well for future situations so that you may avoid working on problems that consume many hours. ------------------------------ Date: Fri, 24 Aug 2007 21:53:44 GMT From: winston@SSRL.SLAC.STANFORD.EDU (Alan Winston - SSRL Central Computing) Subject: Re: Logical name translation under Apache Message-ID: <00A6C9E7.07FD165A@SSRL.SLAC.STANFORD.EDU> In article <1187966270.557910.313900@m37g2000prh.googlegroups.com>, issinoho writes: >Chaps, > >What is the best method for returning the value of a logical name from >within server-side script under Apache (SWS)? > >I had a look at the OPENVMS extension for PHP but it only has a subset >of lexicals, none of which account for logical names. > >Any help much appreciated. In PERL you can just look in the %ENV array; the logical names are available as 'environment' variables. Maybe PHP has something similar? -- Alan ------------------------------ Date: Fri, 24 Aug 2007 22:31:44 -0500 From: Ron Johnson Subject: New blood (was Re: COBOL Transactions?) Message-ID: <46CFA2A0.7000404@cox.net> On 08/24/07 19:58, Paul Raulerson wrote: [snip] > > I intend to sell a lot of HP boxes, all nicely loaded with > significant software loads. Indeed, when I talked to a couple of > my existing customers and floated the idea of moving to HP > hardware, they were very excited about it. It surprised me to no > end how excited in fact! :) Despite our grumpiness at some of your statements, we really *are* glad that you are here, and really *do* hope that you succeed. Just remember that whatever bit of computing that you want to do (except run RPG-IV), VMS and your Alpha *can* do it. -- 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: Fri, 24 Aug 2007 14:20:51 -0700 From: "Tom Linden" Subject: Re: Peer review (was Re: Wisconsin professor says global warming a hoax!) Message-ID: On Fri, 24 Aug 2007 09:07:00 -0700, wrote: > In article , "Tom Linden" > writes: >> On Thu, 23 Aug 2007 08:54:05 -0700, wrote: >> >>>> That is not accurate, the period of precession of the equinoxes is >>>> 25,600 >>>> years, IIRC, advancing one degree about every 70 years (perhelion >>>> currently is >>>> January 4) >>>> >>> The predominant astronomical cycle affecting glaciation for the last >>> 800,000 years has been a 100,000 year cycle of ice ages punctuated by >>> briefer >>> usually 9000 - 12000 year long interglacials. There are a number of >>> different >>> astronomical cycles which acting together may explain this. I believe >>> the >>> interglacial can generally be thought of as lasting for about one half >>> of the >>> equinox precessional period (the exact length depending upon how all >>> the >>> cycles mesh together and probably also modulated by other >>> non-astronomical >>> factors). The variation caused by the precession of the equinoxes >>> obviously >>> occurs repeatedly during the 100,000 year period but only leads to >>> interglacial >>> conditions at the beginning/end of the 100,000 year cycle. >>> However as indicated in some of the links below more recent findings >>> from ice >>> cores point to some interglacials having lasted much longer than half >>> the >>> equinox precessional period. >> >> >> >> Because there are a number of different repeating factors ( google >> Milankovitch) >> there is a beat phenomenon that can occur resulting in extremes. >> I copied the following article which I think is well put together >> http://www.kednos.com/physics/CLIMATOLOGY/ICEAGE.HTML >> >> Note the graph on insolation, the 100K period to which you refer is >> clearly significant, >> the 400K period is caused by perturbation of the earths orbit by >> planetary >> alignments >> resulting in the eccentricity becoming as high as 0.04 (currently almost >> circular, 0.01) >> but also not that the last ice age in which the ice was several km thick >> on northern Europe >> was maybe 12000 years ago and that is outside the 100KA cycle. >> > > I'm not sure then why you objected so strenuously to my statement that > the last > interglacial started about 11500 years ago (there are a number of > different > ways to measure when the interglacial started and hence figures from > 10,000 > upto 12,000 years ago are often quoted but I'm sure you can't have been > objecting on that basis - The links I provided used all of those > figures). > I don't think it was strenuous;-) In any event my reading of your post left the impression that ice ages occurred on 100KA cycle and all I was saying is that it is about every 26000 years. But then that may have been my misreading. > > The only other thing you could have been objecting to was the statement > that > in the 1970s it was thought that interglacial's generally lasted about > 11,000 > years again the links provide adequate support for that statement. > > I'm also not sure what you mean by "outside the 100KA cycle" in your last > remark. > > See > > http://en.wikipedia.org/wiki/image:Ice_Age_Temperature.png > > for a diagram showing Antarctic temperature changes during the last > several > glacial/interglacial cycles over the past 450,000 years (unfortunately > the date > scale isn't linear - stretching out the recent past and compressing the > more > distant past). > > > David Webb > security team leader > CCSS > Middlesex University > > > > >> -- >> PL/I for OpenVMS >> www.kednos.com -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Fri, 24 Aug 2007 19:17:23 GMT From: John Santos Subject: Re: Peer review (was Re: Wisconsin professor says global warming a hoax!) a hoax Message-ID: <79Gzi.337$Bv1.179@trnddc06> david20@alpha2.mdx.ac.uk wrote: > 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. I think you are talking about something else. It was probably true that the scientific orthodoxy may have been that "we're due" in the same sense that we may be due for a large asteroid strike. (They average every X years, and it has been order X years since the last one...) but when global warming deniers talk about this, they are citing specific work done in the 1970's that predicted an imminent Northern Hemisphere ice age. That work was highly controversial at the time, and most climatologists doubted it due to lack of data and lack of adequate understanding of the underlying mechanisms and lack of suitable models. See the NAS/NRC 1975 report on the subject, summarized in > > 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 -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: Sat, 25 Aug 2007 06:40:04 +0200 From: "Martin Vorlaender" Subject: Re: PWS500 au console transitions Message-ID: Jim Mehlhop wrote: > I need to run the ra200rcu utility to configure my raid controller. It > is run from the ARC console. Needless to say I run VMS from the SRM > console. When my battery died I learned how to get from the ARC to the > SRM, but I can not find any documentation to get from the SRM to the > ARC. On the as1200, which I used to have the Users guide said to > > >>> set alphabios > > This did not seem to work on the PWS500. Anyone have a PWS500 Users > Guide? barring that how the heck do you accomplish this?? >>> arc If HELP doesn't show what you're looking for, try LS at the SRM console (or better LS | MORE). cu, Martin -- One OS to rule them all | Martin Vorlaender | OpenVMS rules! One OS to find them | work: mv@pdv-systeme.de One OS to bring them all | http://www.pdv-systeme.de/users/martinv/ And in the Darkness bind them.| home: martin.vorlaender@t-online.de ------------------------------ Date: Fri, 24 Aug 2007 21:47:02 -0700 From: "johnhreinhardt@yahoo.com" Subject: Re: PWS500 au console transitions Message-ID: <1188017222.674529.220550@x40g2000prg.googlegroups.com> On Aug 24, 7:31 pm, Jim Mehlhop wrote: > I need to run the ra200rcu utility to configure my raid controller. It > is run from the ARC console. Needless to say I run VMS from the SRM > console. When my battery died I learned how to get from the ARC to the > SRM, but I can not find any documentation to get from the SRM to the > ARC. On the as1200, which I used to have the Users guide said to > > >>> set alphabios > > This did not seem to work on the PWS500. Anyone have a PWS500 Users > Guide? barring that how the heck do you accomplish this?? > > Thanks in advance > Jim IIRC it's just >>>alphabios ------------------------------ Date: Sat, 25 Aug 2007 05:07:26 GMT From: Tad Winters Subject: Re: PWS500 au console transitions Message-ID: Jim Mehlhop wrote in news:46cf6a39$0$497$815e3792 @news.qwest.net: > I need to run the ra200rcu utility to configure my raid controller. It > is run from the ARC console. Needless to say I run VMS from the SRM > console. When my battery died I learned how to get from the ARC to the > SRM, but I can not find any documentation to get from the SRM to the > ARC. On the as1200, which I used to have the Users guide said to > > >>> set alphabios > > This did not seem to work on the PWS500. Anyone have a PWS500 Users > Guide? barring that how the heck do you accomplish this?? > > Thanks in advance > Jim > Have you tried typing arc? I've used that many times to get to where I can run ra200rcu, or ra200srl. ------------------------------ Date: Fri, 24 Aug 2007 14:48:25 -0400 From: "Richard B. Gilbert" Subject: Re: Volume Shadowing Availability Message-ID: <46CF27F9.2050604@comcast.net> Neil Lowden wrote: >>Have you tried Google? Plug in what you remember about the title, >>author, publisher, date, content, etc. > > > Yeah, I exhausted Google. I originally had only a hardcopy which I > think was a handout at some Digital (possibly Compaq) bash. > > -Neil > > The only thing I have ever encountered that goes into any detail about RAID is a document called "The RAID Book". It was, at one time, available from Digital. I got my copy when a former boss dropped his copy in the trash! I've found it quite handy and that former boss saved me $29.95! ------------------------------ Date: 24 Aug 2007 22:09:15 +0200 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOeGER) Subject: [OpenVMS] Context lexical functions Message-ID: <46cf570b$1@news.langstoeger.at> As you might know there are some lexical functions for getting information of a particular entity (like F$GETDVI, F$GETJPI, F$FILE_ATTRIBUTE) and a companion lexical function for wildcard searches of these entities (like F$DEVICE, F$CONTEXT/F$PID, F$SEARCH). Now with ODS5 and/or symbolic links, I think, there should be some improvement in the F$SEARCH function area. eg. How to specify that F$SEARCH should not follow a subdirectory (just like a DIR/EXC does, but lexical functions are there to not need to parse DCL output in temporary files, right?) or symbolic link? This would be handy to avoid an endless loop via SYS$COMMON:[GNV.MNT...] (which is an alias for usually SYS$SYSDEVICE:[PSX$ROOT.MNT...]) eg. How to specify that F$SEARCH should look case sensitive? Is the SET PROCESS/CASE_LOOKUP the (only) way to go? Does anyone know of planned feature enhancements here? A F$FILCTX perhaps? TIA -- 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 ------------------------------ End of INFO-VAX 2007.465 ************************