1 INFO-VAX	Sat, 10 Jul 2004	Volume 2004 : Issue 379       Contents:+ Re: Accuweather video mentions VMS (TWICE!) + Re: Accuweather video mentions VMS (TWICE!) P Re: Cockadoodledoo! (Was: Re: User-written system service, how to protect data?)& Re: Getting the RFA of Record in COBOL& Re: Getting the RFA of Record in COBOL& Re: Getting the RFA of Record in COBOL MySQL 4.1.3-beta on ODS2 volume / Re: OpenVMS license transfer  policies and fees ) SIMH 3.2-1 released - important bug fixes ) RE: VAX Users See the Writing on the Wall ) Re: VAX Users See the Writing on the Wall   F ----------------------------------------------------------------------    Date: 10 Jul 2004 00:07:27 -0700. From: spamsink2001@yahoo.com (Alan E. Feldman)4 Subject: Re: Accuweather video mentions VMS (TWICE!)= Message-ID: <b096a4ee.0407092307.7fc92d43@posting.google.com>   e David J Dachtera <djesys.nospam@comcast.net> wrote in message news:<40EF484B.6FFF29CF@comcast.net>... H > winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr")E > wrote in message news:<00A348A8.2DF7BAB4@SSRL.SLAC.STANFORD.EDU>... @ > > In article <40EDF146.B11E6051@comcast.net>, David J Dachtera' > > <djesys.nospam@comcast.net> writes:  > > >"Alan E. Feldman" wrote:  > > >>  D > > >> David J Dachtera <djesys.nospam@comcast.net> wrote in message* >  news:<40EC9D16.6F16C23E@comcast.net>...! > > >> > "Alan E. Feldman" wrote: 
 > > >> > >H > > >> > > Charles Shannon Hendrix <shannon@news.widomaker.com> wrote in2 >  message news:<bi5fcc.lt2.ln@escape.goid.lan>...D > > >> > > > On 2004-07-06, Alan E. Feldman <spamsink2001@yahoo.com>	 >  wrote:  [...] I > > >Should we tell that to the families who lost loved ones in the hotel F > > >balcony collapse in St Louis some years back? ...in various DC-10" > > >crashes? ...Ford Pinto fires? > > H > > The only plausible assumption I can come up with here is that you're >  just F > > arguing for fun, since you surely can't believe that putting a VMS >  promotionalG > > video in a WMP-only format is really going to lead to loss of life.  >  If you'reI > > arguing seriously, you've just made an unjustified appeal to emotion.  > I > Not quite. It's logic, and machine logic at that: either the "principle F > bit" is "on" or it's "off". Either you have principles or you don't.+ > Potential for loss of life is irrelevant.   ; If it sells more VMS systems, who the hell cares about your D principles? Still, I find your loss of life examples irrelevant. YouA don't make paper clips to the same standard as the Space Shuttle.    [...] H > > I'm a webmaster on a moderately-busy site that gets a million hits a	 >  month, C > > many from scientific personnel who presumably use their regular I > > workstations.  This isn't randomly-assorted home users.  According to  >  my G > > logs, the overwhelming majority of hits are from Windows platforms,  >  even ) > > from this highly-technical community.  > F > So, folks who don't "follow the piper" deserve to be left out in theG > cold? That point doesn't wash with me. As I've said before, "How many   < Much less so than we VMSers deserving more VMS in the world!  D Hey, people with a message are not under any obligation to make sureE everyone in the world hears it. If someone publishes a book, and it's B not available in every book store, guess what? You'll have to shop around until you find it.   J > wrongs does it take to make a right?" (Although I acknowledge that three > rights make a left. ;-)   2 Perhaps more "relevant": three lefts make a right.   [...] % > > But your complaints are about the D > > same as, if HP ran a commercial promoting VMS on the Super Bowl,6 > > complaining that they'd deliberately neglected the >  non-football-watchingE > > audience and they should have bought time on whatever was running 
 >  againstD > > it too, without ever saying "Cool! A VMS commercial on the Super > Bowl!" > , > Non-sequitur and an invalid extrapolation. > G > ....and if hp were dumb enough to advertise VMS at the Super Bowl and ? > nowhere else, they'd deserve to lose their entire advertising B > investment. True, they consistently make dumb business decisionsB > concerning VMS, but that would be truly amazingly dumb and truly > disappointing.  E Well, to do the Super Bowl and not follow up with more ads soon after D would perhaps be foolish. But we're talking the Super Bowl here. I'mE probably the only one in the country who doesn't watch it every year! ? I can't see it being a dumb move except perhaps for the cost of C running the ad. Hey, Apple did it and I'm not aware of that hurting  them.    Point ... Winston.   [...] / > > Ah, so your claim is that it's a conspiracy  > I > Nope, don't find that one either. Are you reading the same thread I am?  > ! > > among the marketing mavens to F > > sell people on Windows by producing promotional videos for VMS.  I	 >  don't  " > > find that entirely convincing. > H > Considering that I never attempted to promote that statement, I'd have > to agree with you. > H > My point was that sometimes what is done speaks more convincingly than > what is said.  >  > Try this:  > H > Note that the SAN management appliance software is based on M$ and notG > x/Motif, and VMS-side utilities are virtually non existant aside from H > SSSU and HSZTERM$SCSIPAD (which is not supported by CSC, and as of theI > HSG80 firmware version 871-7, is (reportedly) not even supported by the  > HSGs). >   > What statement does this make? >  > Why?  - That you don't know how to spell 'existent'?    ( If it sells more VMS systems, who cares?   [...] G > I don't recall that either, nor do I recall anyone saying anything so J > negative in this case, either, although Brian feels (and I agree that heF > is) justified in complaining that VMS users who choose to exclude M$H > from their homes/offices were left out. He expressed that *HE* was theD > one who had been insulted, rather than issuing a vitriolic insult.  A So go view it in a library! or an Internet Cafe, if any are still  around.   D Hey, I do not have a television set. Does that mean that advertisersF are dopes/immoral/whatever for putting ads on TV because I, and others  who don't have TV, won't see it?  ) There's just no pleasing some people. ;-)    [...]  > Whaddaya think?  >  > D.J.D.  < I don't recall *you* making any efforts with your tabbed DCLC formatting example to make *that* work on all browsers. Yeah, screw D the users who don't have Netscape or whatever you used. Let them eat
 bits!  ;-)  = Yeah, tabs. Talk about device/configuration/and_whatever_else 
 dependency!!!    ------------------------------    Date: 10 Jul 2004 00:50:01 -0700. From: spamsink2001@yahoo.com (Alan E. Feldman)4 Subject: Re: Accuweather video mentions VMS (TWICE!)= Message-ID: <b096a4ee.0407092350.4f937b09@posting.google.com>   d David J Dachtera <djesys.nospam@comcast.net> wrote in message news:<40EF4C87.D0E7DF5@comcast.net>... > "Alan E. Feldman" wrote: > > i > > David J Dachtera <djesys.nospam@comcast.net> wrote in message news:<40EDF146.B11E6051@comcast.net>...  > > > "Alan E. Feldman" wrote: > > > > m > > > > David J Dachtera <djesys.nospam@comcast.net> wrote in message news:<40EC9D16.6F16C23E@comcast.net>... " > > > > > "Alan E. Feldman" wrote: > > > > > > y > > > > > > Charles Shannon Hendrix <shannon@news.widomaker.com> wrote in message news:<bi5fcc.lt2.ln@escape.goid.lan>... L > > > > > > > On 2004-07-06, Alan E. Feldman <spamsink2001@yahoo.com> wrote:
 > > > > > > >  [...] R > > > > > > > If they aren't providing it in a standard format, just how seriously3 > > > > > > > can you take this "promotion" of VMS?  > > > > > > O > > > > > > You would prefer a promotion of something else on a VMS-friendly or ( > > > > > > otherwise "standard" format?	 > > > > >  > > > > > Non-sequitur.  > > > > J > > > > I disagree. What's more important? Promoting VMS or using standard > > > > formats? > > > N > > > Careful, there. Do you mean INDUSTRY standards (negotiated industry-wideM > > > through a recognized standards body), or de-facto standards? What about M > > > vendor-specific (and not necessarily compatible) extensions to industry  > > > standards? > > A > > I mean this: Pick A or B. Pick only one, as they are mutually  > > exclusive: > > G > > A) HP makes a VMS promotional video with Accuweather as the star of F > > the video as it just did, the same way, same bat channel, same bat > > format, etc. > > ( > > B) HP doesn't make the video at all. > G > Hp makes the same mistake of trying to force two equally unacceptable H > options down customer/prospect's the user's throat, then wondering why > they lost the sale.    Huh?   > H > I believe your question answers itself, but since you repeat it below,! > we'll discuss it further there.  > D > > > > Promoting VMS, of course! So why be more upset of the lesserI > > > > of the two? Don't miss the forest for the trees, or whatever that  > > > > saying is! > > > B > > > How 'bout, "A nod is as good as a wink - to a blind horse."? > >  > > Not applicable.  > E > Well, actually yes it is. Put it another way: if I cannot view your ? > little piece of media schtick, does the content matter to me?   B Then why are you writing all this stuff about something you didn'tA even see? Besides, you are already a VMS advocate. Why waste time  preaching to the choir!    [...]  > > > [snip] > > > > 0.5 > 0 Eq. (1)  > > > M > > > On some systems I worked on years ago, "true" was indicated by the sign N > > > (highest order) bit, not the lowest order bit. Negative was "true", zero: > > > or positive was false (business BASIC on DCC's EOS). > >  > > Not the least bit relevant.  >  > Excellent pun, by the way...   Thanks!     [...]  > > > [snip] > > > > And a video M > > > > promoting VMS is a video promoting VMS. Do you think people are going E > > > > to view the window promoting VMS and Accuweather and think to , > > > > themselves "Hmmm. Some psychic power > > > J > > > Try the little messagebox explaining that (insert name of UN*X mediaJ > > > player) cannot understand the file format. Nothing psychic about it. > > J > > Uh, the Windows users won't see that and so won't be affected. Read itI > > again. I wrote of people viewing the video. If they can view it, then G > > they probably have Windows and won't see the "cannot understand..."  > > message. > < > If their player won't read the data, how did they view it?  D OK, I think I what you're saying is that the non-Windows people willE see that they'll need Windows to view it, so that will encourage them B to get Windows. I don't think many will. And besides, most alreadyD have Windows anyway. But those who do switch to Windows will then beE able to view the video. But those who see the video, some of them may % buy VMS systems! That's a good thing.   E Well, you snipped too much for me to be sure what you said before and B I don't want to go back and find it. But I still say the good from? this video outweighs the bad. Yes, it would be better in a more F universal format, but as it is, it is better than not having been done at all:  1 > 0.5 > 0   > ' > > > > is penetrating my brain telling G > > > > me that this video only runs on Windows. Therefore, the VMS and H > > > > AccuWeather(TM) really means I should invest more in Windows andK > > > > forget everything else". I don't know, Dave, sounds pretty silly to  > > > > me!  > > > M > > > ...but not to the masses, or to the marketing mavens who introduce such B > > > subtleties quite intentionally to achieve that exact result! > > D > > Yes, a video that talks about nothing but how hp and OpenVMS areD > > extremely important to the success of Accuweather is obviously aA > > clever Billy plot to sell more Windows. Nope, I don't see it.  > 7 > Good - because that's not what I said. Read it again.   F Sure sounds like what you said. What did you say? I don't have time to dig it up again.   > O > > > > > > If you did something you thought was good and people just yelled at Q > > > > > > you for not doing it quite right, would that encourage you to do more 2 > > > > > > and try to correct what you did wrong?	 > > > > > K > > > > > Ask that question of a child development expert. The answer might  > > > > > surprise you.  > > > >   > > > > Well, hp is not a child. > > >  > > > That's debatable.  > > 2 > > Well, if it is a child, it's not *your* child. > = > Teachers spend their whole day with children not their own.    HP is not in your class.   [...]  > ) > > > > > > If Guy Peleg implemented some R > > > > > > cool new DCL function but did something slightly wrong, would you yellQ > > > > > > at him for it instead of thanking him and then expect him to continue N > > > > > > to be enthusiastic about adding functionality to DCL? I think not!	 > > > > > R > > > > > Well, typically this group will be among the first to find/point out theQ > > > > > faults. I like to think that the likes of Guy, Fred, etc. would exploit R > > > > > that to their best advantage (a ready group of beta-testers, if somewhat > > > > > sharp-toothed).  > > > > F > > > > But the group would sensibly avoid nasty insults and the like, > > > G > > > Your observation is inconsistent with this group's experience and  > > > history. > >  > > References, please?  > F > http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&group=comp.os.vms   I'll check this later.   > 
 > > [snip]  > > A or B? Which do you prefer? >  > Well, let's see: > ' > A is relevant, but only 95% complete. % > B is irrelevant, and 100% complete.  > @ > Meanwhile, vendor #2 has option C: relevant and 100% complete. >   > Sorry, you snoozed - you lose!  ? Sorry, that's not the choice. The choice is A and C or B and C. ( Clearly, A and C is better than B and C.   ------------------------------  + Date: Sat, 10 Jul 2004 13:12:57 +0000 (UTC) 3 From: "Richard Maher" <maher_rj@hotspamnotmail.com> Y Subject: Re: Cockadoodledoo! (Was: Re: User-written system service, how to protect data?) / Message-ID: <ccoq0o$rd7$1@titan.btinternet.com>    Hi,   & I'm all dressed up and no where to go!  8 I've mailed yo my mobile in case you get e-mail on hols.   Cheers Richard  L PS. Truth be told, there's a ballet thing tonight and Pizza Express at lunch= tomorrow but if you're up for a beer in Richmond Sunday arvo?    Search Result 11= From: VAXman-__@SendSpamHere.ORG (VAXman-__@SendSpamHere.ORG) J Subject: Re: Cockadoodledoo! (Was: Re: User-written system service, how to protect data?)" View: Complete Thread (2 articles) Original Format  Newsgroups: comp.os.vms  Date: 2004-03-09 13:05:42 PST     B In article <c2l30n$4ru$1@hercules.btinternet.com>, "Richard Maher"% <maher_rj@hotspamnotmail.com> writes:   >On 08/03/2004 20:43 Hoff wrote: > J >> I tell you I don't know this VMS that you speak of; I am not one of its >followers!  > A >As far as the original poster goes: Your main problem is you are  programming F >in C where memory allocation appears to be a complete mystery to most peopleI >including the authors of the UWSS examples in sys$examples on Alpha. Now L >because C is a piece o' shit for User-written System Services you should beJ >using the MACRO-32 compiler but you'll quickly find that this is anathema toI >the nanny-state revisionists that have poisoned the well at VMS for many @ >years. If you think I'm being paranoid and delusional about VMSL >engineering's Fahrenheit 451 approach to MACRO programming then show me theH >MACRO examples in sys$examples: Go on! Get on your VAX and do a $DIR ofK >examples and its sub-directories for .MAR and then compare to what you get J >on Alpha. Don't worry, I'm sure all of "The Disappeared" will be returned to >their loved ones on Itanium.  >  >Cheers Richard Maher  >  >PS. Device Driver my arse!   * Well said and filed in my archive Richard.  B FYI, I'll be in London 9-12 July.  Let's try to link up this trip.     --B http://www.legacy-2000.com  for the *best* OpenVMS system securityC                             solutions that others only claim to be.  --K VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM   4   "Well my son, life is like a beanstalk, isn't it?"    L ---------------------------------------------------------------------------- ----   ------------------------------  + Date: Sat, 10 Jul 2004 12:42:40 +0000 (UTC) 3 From: "Richard Maher" <maher_rj@hotspamnotmail.com> / Subject: Re: Getting the RFA of Record in COBOL / Message-ID: <ccoo7u$oir$1@titan.btinternet.com>    Hi,    > Maybe some things just ought > not be done in COBOL.   G While this may be true, may I suggest that it is equally true that some I people should simply not be cutting code. As Clint used to say - "A man's ; gotta know his limitations." Personally, I use MACRO for: -   L 1) External symbol definitions that aren't supplied by default in the system	 libraries G 2) Initializing COBOL EXTERNAL data PSECTs at compile time for a bit of  performance H 3) Inner mode code to obtain privilege (But I've had plenty of EXEC mode ASTs in COBOL)< 4) Yes, when I *really* want to access RMS and block i/o etcI 5) EXEC mode rundown handlers when it really, really has to be cleaned up   J Apart from that, I can conceive of no situation where COBOL cannot satisfyJ requirements. If you tell me exactly what it is that you find particularlyI difficult with the following example (Or why it doesn't do what you want. H I'm still none the wiser as to what you're trying to do.) then as I haveJ previously stated, I'm more than willing to help. So please don't take theH opportunity to slag-off COBOL in a presumably adolescent attempt to gainI some sort of street-cred with the downwards spiralling conference that is  COV.  G Yes, you are right! If you'd asked something like "I hear there've been K great improvements with fork() functionality in DECC to speed things up and G improve portability with UNIX?" then you would have been inundated with G replies from numerous top level VMS engineers and an entire sub-project I would have been established at HP to make sure you're a happy chappy. But L that's just because the self-opinionated wanker quota at VMS engineering farL exceeds that of the general public (I hope the irony of the pot/kettle thing isn't missed on anyone here :-)   L Anyway I've just had to finish cooking our BBQ brunch under an umbrella (GodK bless the English summer (Still I managed to go for a run and get the lawns C mowed)) so I'll probably have alot more to say about the IN CROWD's J treatment of COBOL in more detail while the paddling pool get's filled forG free. I can't believe COBOL has been left to die at HP but then I can't K believe that Cluster functionality at Rdb engineering has been left to die! I But maybe everyone else is right and I'm just a slow learner? (But then I I don't get to eek out a living in the rarefied atmosphere of the sheltered * workshop that is Rdb and VMS engineering!)  K Oh, and I agree with whoever mentioned device drivers. I certainly wouldn't L write one with COBOL but then I certainly wouldn't and COULDN'T write one atJ all. I am not selling some weird hardware. I suggest that you treat anyoneF that suggests such a thing with the total disbelief that they deserve.   Regards Richard Maher.   identification division. program-id.    rfa_demo.   environment division.  input-output section. 
 file-control.   ,     select optional my_file assign some_name+                     organization is indexed +                     access mode  is dynamic +                     record key   is my_key.    data division.
 file section.    fd  my_file. 01  my_rec. "     03  my_key          pic x(10)."     03  my_data         pic x(60).   working-storage section.; 01  rab$w_rfa           pic  9(9)       comp    value   16. : 01  rab$s_rfa           pic  9(9)       comp    value   6.0 01  my_rab_addr                         pointer.0 01  my_rfa_addr                         pointer. 01  out_rfa.-     03  or1             pic 9(4)        comp. -     03  or2             pic 9(4)        comp. -     03  or3             pic 9(4)        comp.  01  user_output.?     03                  pic x(4)                value   "RFA(". !     03  or1             pic 9(4). <     03                  pic x(1)                value   ",".!     03  or2             pic 9(4). <     03                  pic x(1)                value   ",".!     03  or3             pic 9(4). <     03                  pic x(1)                value   ")". *  procedure division. 
 declaratives.  in_file_problems section. 2     use after standard error procedure on my_file. 00. 6     call "lib$stop" using by value rms_sts of my_file. *  end declaratives.  kick_off section.  00.  *+ * Code for initialize  *-"     open i-o my_file allowing all.  3     call "dcob$rms_current_rab" giving my_rab_addr. 4     add rab$w_rfa to my_rab_addr giving my_rfa_addr. *+  * Code for mainline read routine *-     write my_rec.      move "fred" to my_key.     write my_rec.      read my_file.   6     call "get_rfa" using out_rfa by value my_rfa_addr.  %     move corr out_rfa to user_output.      display user_output. *+ * Code for rundown *-     close my_file.
     stop run.  *  end program rfa_demo.  identification division. program-id.    get_rfa.  data division. linkage section.! 01  out_rfa             pic x(6). ! 01  rms_rfa             pic x(6).  * * procedure division using out_rfa, rms_rfa. 00.      move rms_rfa to out_rfa      exit program.  *  end program get_rfa.    * Scott <lsk55@hotmail.com> wrote in message7 news:926edf3b.0407070719.19b07997@posting.google.com... ? > David J Dachtera <djesys.nospam@comcast.net> wrote in message ' news:<40E9DF5F.A70B34E1@comcast.net>...  > > Scott wrote: > > > H > > > I need a way to obtain the RFA of an indexed file record that I'veH > > > just read from COBOL.  Anyone know of a way to do this?  Thanks so > > > much!  --Scott > > I > > Interesting question. I wonder if there is a routine in the BASIC RTL L > > called "BAS$GETRFA" that could be used. Then, you'd just have figure outK > > which register contains the result and issue the appropriate LIB$mumble . > > call to retrive the value in the register. > > B > > ...or perhaps a "walk" through the RMS manual might be useful. > > 
 > > D.J.D. > I > Unfortunately, the BAS$GETRFA function isn't the complete answer, since I > BASIC needs a channel number.  So, I bagged it all and wrote a 10 (+/-) H > line BASIC program to do it for me.  :-)  Maybe some things just ought > not be done in COBOL.  > K > Sort will produce a tag file with RFA's in it too, if I remember rightly.  > # > Thank you for your answers, guys.    ------------------------------  + Date: Sat, 10 Jul 2004 13:21:49 +0000 (UTC) 3 From: "Richard Maher" <maher_rj@hotspamnotmail.com> / Subject: Re: Getting the RFA of Record in COBOL / Message-ID: <ccoqhb$shj$1@titan.btinternet.com>    Hi,   D Here is a VAX example which might not be of any use but it does haveH diagrams in the comments which may help. (Just imagine if you could findK this sort of information for COBOL in sys$examples! Wouldn't that be easy?) K Yes I (now) know there are much easier ways to get a file's FID but this is F very old code and included only because I've got nothing betetr to do)   Cheers Richard  K *************************************************************************** K *                                                                         * K * Progarm Name : GETFID                                                   * K * Author       : Richard Maher                                            * K * Inputs       : RMS Filename        By Descriptor                        * K * Outputs      : File Id             By Reference                         * K *              : Return Status       By Value                             * K *                                                                         * K * GETFID accepts a filename and meanders through RMS internal data        * K * structures to locate that file's File Id. The path trodden is depicted  * K * in the diagram below. Unfortunately this awkward piece of navigation is * K * necessary when you wish to reach the FID field in the NAM block and all * K * you've got to start will is the address of the STS field in the RAB     * K * block.                                                                  * K *                                                                         * K * NB: COBOL engineering would undoubtedly claim that the reliance on the  * K *     RMS_STS field(s) mapping directly to the RAB$L_STS RMS field(s) is  * K *     unsupported. Having said that it makes a lot of sense to leave it   * K *     as it is, certainly for performance reasons.                        * K *                                                                         * K *************************************************************************** K *             /                                                           * K *   Local     /                                                           * K *  Working    /       COBOL internal and RMS Working Storage              * K *  Storage    /                                                           * K *             /  Record Access       File Access           Name           * K *             /      Block              Block              Block          * K *             /      (RAB)              (FAB)              (NAM)          * K *             /  +-----------+  +-->+-----------+  +-->+-----------+      * K *             /  |           |  |   |           |  |   |           |      * K * sts_ptr ----/->| rab$l_sts |  |   |           |  |   | nam$w_fid |      * K *             /  |           |  |   | fab$l_nam |--+   | (3 words) |      * K *             /  | rab$l_fab |--+   |           |      |           |      * K *             /  |           |      |           |      |           |      * K *             /  +-----------+      +-----------+      +-----------+      * K *             /                                                           * K ***************************************************************************  identification division. program-id.    getfid.   environment division.  input-output section. 
 file-control.   #     select in_file assign sys$disk.    data division.
 file section.  *+L * As we're not interested in the file's organization we'll treat them all asL * sequential and as there is no record i/o performed we'll just pretend that * they're all one byte records.  *- fd  in_file       value of id is in_file_name.   01  in_rec              pic x.   working-storage section. * @ 01  ss$_normal          pic s9(9)       comp    value   external ss$_normal. - 01  sys_status          pic s9(9)       comp. " 01  in_file_name        pic x(63). *+" * RMS control block field offsets. *-L 01  rab$l_sts           pic s9(9)       comp    value   external  rab$l_sts.L 01  rab$l_fab           pic s9(9)       comp    value   external  rab$l_fab.  L 01  fab$l_nam           pic s9(9)       comp    value   external  fab$l_nam.L 01  nam$w_fid           pic s9(9)       comp    value   external  nam$w_fid. *+J * COBOL initializes the STS_PTR field in local working-storage to point to the A * RAB$L_STS field in the RMS Record Access Block (RAB) structure.  *-L 01  sts_ptr                             pointer value   reference rms_sts of in_file. *+I * The following VMS string descriptors are used to pull chunks out of the  * various RMS data structures. *- 01  fab_blk_desc. :     03                  pic s9(4)       comp    value   4.-     03                  pic s9(4)       comp. 0     03  fab_blk_ptr                     pointer. 01  nam_blk_desc. :     03                  pic s9(4)       comp    value   4.-     03                  pic s9(4)       comp. 0     03  nam_blk_ptr                     pointer.
 01  fid_desc. L     03                  pic s9(4)       comp    value   external  nam$s_fid.-     03                  pic s9(4)       comp. 0     03  fid_ptr                         pointer. *- linkage section.  ! 01  in_file_desc        pic x(8).   ! 01  out_fid             pic x(6).   - procedure division using        in_file_desc, '                                 out_fid +                         giving  sys_status. 
 declaratives.  in_file_problems section. 2     use after standard error procedure on in_file. *+@ * Simply return any file i/o errors for the caller to deal with. *- set_return_status.*     move rms_sts of in_file to sys_status. *  end declaratives. 
 root section.  00.  *+F * We have to copy the input filename parameter to local Working-StorgeF * before we can do anything with it. That is, the filename is receivedG * BY DESCRIPTOR so we simply pass the address of that string descriptor  * to lib$scopy_dxdx. *-     call "lib$scopy_dxdx" ,         using   by reference    in_file_desc,                 by descriptor   in_file_name         giving  sys_status. .     if sys_status not = ss$_normal go to fini. *+E * STS_PTR has been initialized to point to the RMS$L_STS field in the A * Record Access Block (RAB) for IN_FILE. In the following code we F * subtract this offset to obtain the start address of the RAB and thenI * add on the RAB$L_FAB offset so we can copy the 4 byte File Access Block ) * (FAB) address to the NAM_BLK_PTR field.  *-:     compute fab_blk_ptr = sts_ptr - rab$l_sts + rab$l_fab.     call "lib$scopy_dxdx" ,         using   by reference    fab_blk_desc+                 by descriptor   nam_blk_ptr          giving  sys_status. .     if sys_status not = ss$_normal go to fini. *+F * Now that we have the FAB address we have to add the FAB$L_NAM offsetG * to it so that we can get the 4 byte Name Block (NAM) address into the  * FID_PTR field. *-!     add fab$l_nam to nam_blk_ptr.      call "lib$scopy_dxdx" ,         using   by reference    nam_blk_desc'                 by descriptor   fid_ptr          giving  sys_status. .     if sys_status not = ss$_normal go to fini. *+D * Now open the file so that RMS can populate the File Id (FID) fieldB * for us. The file is immediately closed again, as no other i/o is * necessary. *-$     open input in_file allowing all..     if sys_status not = ss$_normal go to fini.       close in_file..     if sys_status not = ss$_normal go to fini. *+H * Finally, we add the FID offset to the NAM address, and copy the 6 byte" * FID to the caller's buffer area. *-     add nam$w_fid to fid_ptr.      call "lib$scopy_dxdx" (         using   by reference    fid_desc'                 by descriptor   out_fid          giving  sys_status.  *  fini.      exit program.  *  end program getfid.    ------------------------------  + Date: Sat, 10 Jul 2004 13:23:13 +0000 (UTC) 3 From: "Richard Maher" <maher_rj@hotspamnotmail.com> / Subject: Re: Getting the RFA of Record in COBOL / Message-ID: <ccoqk1$ln$1@sparta.btinternet.com>    Hi,     And here's the Alpha equivilent.   Cheers Richard   identification division. program-id.    getfid. *  environment division.  input-output section. 
 file-control.   $     select fid_file assign fid_file.   data division.
 file section.    fd  fid_file      value of id is fid_file_name(     record varying depending on rec_len.   01  fid_rec pic x.   working-storage section.E 01  rms$_normal                         pic 9(9)        comp    value  external rms$_normal. E 01  ss$_normal                          pic 9(9)        comp    value  external ss$_normal.= 01  sys_status                          pic 9(9)        comp.  * E 01  fab$l_nam                           pic 9(9)        comp    value  external fab$l_nam. E 01  nam$w_fid                           pic 9(9)        comp    value  external nam$w_fid. @ 01  fab_addr                                            pointer.3 01  fid_file_name                       pic x(255). = 01  rec_len                             pic 9(9)        comp.  01  nam_addr_desc.J     03                                  pic 9(9)        comp    value   4.@     03  nam_addr                                        pointer.
 01  fid_desc. J     03                                  pic 9(9)        comp    value   6.@     03  fid_addr                                        pointer. linkage section. 01  file_name_desc. =     03  file_name_len                   pic 9(4)        comp. /     03                                  pic xx. @     03  file_name_addr                                  pointer.1 01  out_fid                             pic x(6).2 *	C procedure division using file_name_desc, out_fid giving sys_status.o
 declaratives.  fid_file_problems section.3     use after standard error procedure on fid_file.r 00.t+     move rms_sts of fid_file to sys_status.  *t end declaratives.r kick_off section.t 00.h     call "lib$scopy_dxdx"e.         using   by reference    file_name_desc-                 by descriptor   fid_file_namen         giving  sys_status.H.     if sys_status not = ss$_normal go to fini.  %     open input fid_file allowing all.A.     if sys_status not = ss$_normal go to fini.  0     call "dcob$rms_current_fab" giving fab_addr.  .     add fab$l_nam to fab_addr giving nam_addr.     call "lib$scopy_dxdx"(-         using   by reference    nam_addr_desco(                 by descriptor   nam_addr         giving  sys_status.n.     if sys_status not = ss$_normal go to fini.  .     add nam$w_fid to nam_addr giving fid_addr.     call "lib$scopy_dxdx"i(         using   by reference    fid_desc'                 by descriptor   out_fids         giving  sys_status.S.     if sys_status not = ss$_normal go to fini.       close fid_file.e *  fini.      exit program.y   end program getfid.r   ------------------------------  % Date: Sat, 10 Jul 2004 11:39:24 +0200d From: jf.pieronne@laposte.net ( Subject: MySQL 4.1.3-beta on ODS2 volume2 Message-ID: <ccodgh$7aj$1@news-reader4.wanadoo.fr>  O It has been reported that initial kit of MySQL 4.1.3 can't run an ODS-2 volume  C (during startup of innodb  MySQL server try to create a file named 0' innodb.status.id where id is a number).aN A new kit is, now, online which fix this problem, the offending file has been  renamed innodb_startup.id).    Sorry for any inconvience.    
 Jean-Franois.   ------------------------------  # Date: Sat, 10 Jul 2004 09:19:20 GMTpL From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr")8 Subject: Re: OpenVMS license transfer  policies and fees6 Message-ID: <00A349AC.C5EF5472@SSRL.SLAC.STANFORD.EDU>  ` In article <40EF5964.A876859D@comcast.net>, David J Dachtera <djesys.nospam@comcast.net> writes: >Rich Jordan wrote:o >>  - >> Every step forward comes with a step back.c >> h	 >> <rant>t >> rE >> Its not enough that DEC's archaic and restrictive license transferoI >> policies for OpenVMS have been retained.  Its not enough that a recentVI >> Alpha with OpenVMS base license and the enterprise integration packagelD >> could ONLY be transferred with the base license, that NONE of theH >> networking or other licenses could be relicensed, and that the DECnetF >> for Alpha was the one special nontransferable DECnet license so youH >> can't even keep DECnet (unlike all the VAX versions).  Its not enough> >> that the cost of repurchasing those licenses all over again5 >> eviscerates potential sale after potential sale...W >> sG >> Now they've raised the relicense fee from $300 to $400... for moving B >> that one single base license.  No changes in what is allowed toG >> transfer, no relaxation of the heavy restrictions... just more blood = >> money to keep an OpenVMS system running in a new location.! >> e
 >> </rant> >> m >> Thanks tons, HP.a >> l >> Richo >k
 ><co-rant>: >O.K. Who's going to be the first blasting his negativity? ></co-rant>v >a   Not me.y   -- Alan,   -- wO ===============================================================================m0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056.M  Paper mail to: SSRL -- SLAC BIN 99, 2575 Sand Hill Rd, Menlo Park CA   94025mO ===============================================================================y   ------------------------------  % Date: Sat, 10 Jul 2004 09:20:10 -0400 , From: Bob Supnik <bob.supnik@sun.nospam.com>2 Subject: SIMH 3.2-1 released - important bug fixes8 Message-ID: <86rve0d8ukjcenvlj1qs9bi5k4aoqf1njt@4ax.com>  : SIMH 3.2-1 was released this morning to the SIMH web site, http://simh.trailing-edge.com.  E This bug fix release contains a fix s to a serious bug in the VAX CPU F (improper execution of DIVBx and DIVWx), as well as to problems in the( PDP-11 and VAX MSCP tape drive emulator.  ) It also has numerous fixes to the HP2100.l  D Users of other simulators need not upgrade, but users of the PDP-11,6 VAX, and HP simulators should upgrade to this release.   /Bob Supnikb   ------------------------------  % Date: Sat, 10 Jul 2004 06:59:43 -0700e# From: "Tom Linden" <tom@kednos.com> 2 Subject: RE: VAX Users See the Writing on the Wall9 Message-ID: <NDEMLKKEBOIFBMJLCECIEEFADIAA.tom@kednos.com>s  B If you condier the points you enumerated in a bit more detail, youC would have to conclude that the launch of Alpha was poorly planned.      -----Original Message-----9   From: Stanley F. Quayle [mailto:squayle@insight.rr.com]t%   Sent: Friday, July 09, 2004 8:04 PM    To: Info-VAX@Mvb.Saic.Comn4   Subject: RE: VAX Users See the Writing on the Wall      F   > The article didn't explain why there are still so many VAXen.  WhyI   > didn't they migrate to Alpha?  I think that would make an interesting 
   > story.   >   There are several reasons, in my experience with CHARON-VAX 
   migrations:,   8   - Works great, why change it?  (Easily the #1 reason.)    - Code is highly VAX-specific.<   - Application can't be migrated to Alpha using DECmigrate.B   - Application vendor doesn't exist anymore, or didn't migrate to
     Alpha.0   - Application uses special or custom hardware.@   - Migration to Alpha (or whatever) would require re-validation>     (for military applications, this can cost millions of $$).   E   Just today, I spoke with someone considering the "future" of their  H   application.  A newer version is available off the shelf.  Of course, F   they have to migrate to Sun hardware, buy Enterprise Oracle, and re-G   do their customizations by cotracting with the application vendor .  nC   It's $200k -- vs less than $20k for CHARON-VAX.  Seems like a no-e   brainer to me...      ?   [Yes, Another Shameless Plug (tm) from your local CHARON-VAX     reseller.]      --Stan Quayle/   Quayle Consulting Inc.      ----------/   Stanley F. Quayle, P.E. N8SQ  +1 614-868-1363r5   8572 North Spring Ct., Pickerington, OH  43147  USAd2   stan-at-stanq-dot-com       http://www.stanq.com            ---i(   Incoming mail is certified Virus Free.<   Checked by AVG anti-virus system (http://www.grisoft.com).A   Version: 6.0.717 / Virus Database: 473 - Release Date: 7/8/2004     ---a& Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).? Version: 6.0.717 / Virus Database: 473 - Release Date: 7/8/2004o   ------------------------------  % Date: Sat, 10 Jul 2004 17:56:20 +0200)9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com>c2 Subject: Re: VAX Users See the Writing on the Wall' Message-ID: <40F011A4.9733E33A@aaa.com>c   "Stanley F. Quayle" wrote: > > > [Yes, Another Shameless Plug (tm) from your local CHARON-VAX > reseller.]   *MY* local reseller ???@& Maybe the whole Internet is "local"...  	 Jan-Erik.  (Sweden)   ------------------------------   End of INFO-VAX 2004.379 ************************