INFO-VAX Thu, 13 Sep 2007 Volume 2007 : Issue 499 Contents: Re: -SYSTEM-F-WRITLCK, write lock error changes to MONITOR PROCESS/TOPCPU Re: changes to MONITOR PROCESS/TOPCPU Re: changes to MONITOR PROCESS/TOPCPU Re: changes to MONITOR PROCESS/TOPCPU Re: DECServer 700 help Free DS10L Drawing again ! 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: Is this a bug or expected behaviour in C99? Re: Is this a bug or expected behaviour in C99? Re: Is this a bug or expected behaviour in C99? Itanium: determine object file main or sub Re: Product Install, UNDO and recovery data (again!) Re: Product Install, UNDO and recovery data (again!) Re: Product Install, UNDO and recovery data (again!) ---------------------------------------------------------------------- Date: 12 Sep 2007 21:26:24 +0200 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOeGER) Subject: Re: -SYSTEM-F-WRITLCK, write lock error Message-ID: <46e85980$1@news.langstoeger.at> In article , Albrecht Schlosser writes: >Peter 'EPLAN' LANGSTOeGER wrote: >> In article <...>, Albrecht Schlosser <...> writes: >>> The real problem is that PCSI ($ PRODUCT ...) seems to open the >>> ..PCSI file on the DVD read/write, or really tries to write to the >>> source .PCSI file! Hence my question: "Is this a PCSI bug?" >> >> Think again. If PCSI does it this way, then how to do a VMS install? >> (eg. OpenVMS Alpha from the VMS CD) > >Why think, about what? ;-) > >It's fine, if it works for OpenVMS installations, and sure you're >right, but here it doesn't work, as it was shown. > > From the OP: > >%PCSI-E-WRITEERR, error writing DONKEY$DQA0:[FORT0811.KIT]HP-I64VMS-FORTRAN-V080 >1-2-1.PCSI;1 >-SYSTEM-F-WRITLCK, write lock error >%PCSI-E-S_OPFAIL, operation failed >%PCSIUI-E-ABORT, operation terminated due to an unrecoverable error condition I know what the OP wrote, I answered (a simple don't know, maybe the DVD). I only wanted to oppose your statement of a likely (or possible) cause "PCSI can't handle write locked sources" (or at least I read your post so)... Currently, I (still) suspect a PCSI$DESTINATION logical pointing to the DVD device or suspect the kit, but again, I don't know (and I also don't have this kitfile to check for other reasons)... -- Peter "EPLAN" LANGSTOEGER Network and OpenVMS system specialist E-mail peter@langstoeger.at A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist ------------------------------ Date: Wed, 12 Sep 2007 18:37:16 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: changes to MONITOR PROCESS/TOPCPU Message-ID: Using MONITOR PROCESS/TOPCPU on 8.3 today, nice to see that essential VMS tools continue to be developed: o there are now no blank lines in the list (giving twice as many on a screen) o the all-time top VMS mystery of why the highest quartile is 25% larger than the other three has been eliminated However, I don't see why the vertical lines were removed! Please put them back! ------------------------------ Date: Wed, 12 Sep 2007 12:19:44 -0700 From: "AlexNOSPAMDaniels@themail.co.uk" Subject: Re: changes to MONITOR PROCESS/TOPCPU Message-ID: <1189624784.031775.326030@22g2000hsm.googlegroups.com> On 12 Sep, 19:37, hel...@astro.multiCLOTHESvax.de (Phillip Helbig--- remove CLOTHES to reply) wrote: > Using MONITOR PROCESS/TOPCPU on 8.3 today, nice to see that essential > VMS tools continue to be developed: More like just a difference from when it was reimplimented, from PLI to C. > o the all-time top VMS mystery of why the highest quartile is 25% > larger than the other three has been eliminated > > However, I don't see why the vertical lines were removed! Please put > them back! They are not removed, hold down CTRL-W, you'll see them. If you are meaning the ones, that indicated the 0,25,50,75,100 marks, I believe they used to be on the "blank" lines you mentioned earlier, that have now been removed. I would suggest this is most likely a bug introduced in the PLI to C port. Alex ------------------------------ Date: Wed, 12 Sep 2007 20:28:56 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: changes to MONITOR PROCESS/TOPCPU Message-ID: In article <1189624784.031775.326030@22g2000hsm.googlegroups.com>, "AlexNOSPAMDaniels@themail.co.uk" writes: > On 12 Sep, 19:37, hel...@astro.multiCLOTHESvax.de (Phillip Helbig--- > remove CLOTHES to reply) wrote: > > Using MONITOR PROCESS/TOPCPU on 8.3 today, nice to see that essential > > VMS tools continue to be developed: > > More like just a difference from when it was reimplimented, from PLI > to C. OK, but some things were changed as well. Hopefully nothing was broken like when MAIL went from BLISS to C. > They are not removed, hold down CTRL-W, you'll see them. OK, I'll give it a try, but running the 7.3-2 and 8.3 montors side by side, they were always visible in the former. > If you are meaning the ones, that indicated the 0,25,50,75,100 marks, > I believe they used to be on the "blank" lines you mentioned earlier, > that have now been removed. Aahhh, that could be it. They could be put back, but that would be a bit trickier, perhaps beyond the C-programmer in question! > I would suggest this is most likely a bug introduced in the PLI to C > port. Indeed. Sic transit gloria mundi. ------------------------------ Date: Wed, 12 Sep 2007 22:27:12 +0000 (UTC) From: moroney@world.std.spaamtrap.com (Michael Moroney) Subject: Re: changes to MONITOR PROCESS/TOPCPU Message-ID: "AlexNOSPAMDaniels@themail.co.uk" writes: >On 12 Sep, 19:37, hel...@astro.multiCLOTHESvax.de (Phillip Helbig--- >remove CLOTHES to reply) wrote: >> >> However, I don't see why the vertical lines were removed! Please put >> them back! >They are not removed, hold down CTRL-W, you'll see them. >If you are meaning the ones, that indicated the 0,25,50,75,100 marks, >I believe they used to be on the "blank" lines you mentioned earlier, >that have now been removed. If you look carefully, they're drawn at startup but quickly erased. >I would suggest this is most likely a bug introduced in the PLI to C >port. Almost certainly unintentional. ------------------------------ Date: Wed, 12 Sep 2007 21:09:14 -0500 From: David J Dachtera Subject: Re: DECServer 700 help Message-ID: <46E89BCA.BB50C3B2@spam.comcast.net> Albrecht Schlosser wrote: > > David J Dachtera wrote: > > > > The point remains, however, that these are in conflict with the device's port > > configuration as indicated by the OP. > > Sorry, if I insist, but ... > > no, he said XON, but you said hardware flow control. Well, actually, no I didn't. Go back and re-read the earlier posts - you may be confusing yourself. If English is not your first language, be careful - some of my contextual constructs can be complex and potentially confusing. > And it's configured > with XON. ...which IS what he said, as I quoted. I also indicated that the TERMINAL SERVER PORT (-NOT- the device port) was configured for hardware flow control, and then you indicated that signalling was disabled which is effectively NO flow control. So, that's still a mismatch. Are there any other questions? -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: Wed, 12 Sep 2007 17:00:01 -0400 From: "David Turner, Island Computers" Subject: Free DS10L Drawing again ! Message-ID: <13egkq6krrfpb44@news.supernews.com> If you haven't sent in your request to be in the drawing then do so with DS10L in the subject line If you sent in your request then don't worry, your request is still in the system and will be in the draw later this month FYI - Alpha systems have been selling like Hot Cakes with VMS I would say 90% with VMS and the others with T64 David Turner -- David B Turner Island Computers US Corp 2700 Gregory St, Suite 180 Savannah GA 31404 T: 877-6364332 x201 Intl: 001 912 447 6622 E: dturner@islandco.com F: 912 201 0402 W: http://www.islandco.com ------------------------------ Date: Wed, 12 Sep 2007 21:01:14 -0700 From: AEF Subject: Re: Here's one for Bob (hope it makes your head spin) Message-ID: <1189656074.218009.35920@19g2000hsx.googlegroups.com> On Sep 11, 10:53 am, davi...@alpha2.mdx.ac.uk wrote: > In article , koeh...@eisner.nospam.encompasserve.org (Bob Koehler) writes:>In article , VAXman- @SendSpamHere.ORG writes: > > >> FYI; Today, I stopped for gas at a station on the border of Lakewood, > >> a hasidic Jewish community. I watched two Hasidim standing outside of > >> the associated convenience store inhaling the shit combustibles exuded > >> from an ignited cigarette and thought to myself that the regulations > >> in Leviticus prohibit the injesting of a ham sandie but putting that > >> carcinogenic shit into one's system was OK. Sure seems hypocritical > >> to me. The above makes no sense to me. The Hasidim were smoking. Fine. But they were not telling others not to smoke. So where is the hypocrisy (someone OTHER than VAXMAN please)? Leviticus has the kashrut laws but doesn't forbid smoking. How is this hypocritical? (someone other than VAXMAN please). Leviticus is not supposed to be a book to outlaw all dangerous acts. That would make it a very long book indeed! There seems to be a serious misconception here of the motivation of the kashrut laws (kosher). Nowhere in the Torah does it say these are for health reasons. Many of the kashrut laws clearly have nothing to do with health. See http://en.wikipedia.org/wiki/Kosher#Hygiene and the rest of the article for details. And even if that were the motivation: so what? Why do some of you think that this should imply that all possible dangers in the world should be enumerated in Leviticus? > > Interesting because pork was known to Jews (and everyone else in the > > region) at the time the writings were collected, but tobacco was only > > known in then "undiscovered" the Americas. Exactly and that's why tobacco isn't mentioned in the Torah. What's the big mystery here? > > > You'ld think God would have known about the dangers of tobacco and > > included it in His word knowing we'd all need to know someday, > > wouldn't you? Who's making an argument about who wrote the Torah? > > Well he might have had a bit of trouble getting the message across. > > Look there's this plant which doesn't grow around here and which you've never > seen but whatever you do don't set light to it and breathe in the smoke when you > do see it in a millenium or two. > > But there are other drugs the ancient Jews would have recognised. > > Is there any mention of hemp in the Bible ? > (It is apparently listed as medicinal plant in the Zend-Avesta a sacred text > of the persian prophet Zoraster in 550 BC). > > Are there any warnings about the Opium Poppy (which was cultivated in lower > Mesopotania as long ago as 3400 BC) ? > > David Webb > Security team leader > CCSS > Middlesex University> What other dangers would He have known about that coincidentally were > > not Given to the people of the mideast? Again, the kashrut laws are not necessarily motivated by "danger". No one alive today knows their true motivation. Yes, some of them have health benefits, but the rest do not. So what? Does this somehow mean that all possible dangers should be listed in Leviticus? AEF ------------------------------ Date: Thu, 13 Sep 2007 01:09:43 -0400 From: JF Mezei Subject: Re: Here's one for Bob (hope it makes your head spin) Message-ID: <9298a$46e8c619$cef8887a$19085@TEKSAVVY.COM> AEF wrote: > The above makes no sense to me. The Hasidim were smoking. Fine. But > they were not telling others not to smoke. So where is the hypocrisy > (someone OTHER than VAXMAN please)? Leviticus has the kashrut laws but > doesn't forbid smoking. How is this hypocritical? (someone other than > VAXMAN please). > > Leviticus is not supposed to be a book to outlaw all dangerous acts. > That would make it a very long book indeed! The problem is with people who take the Bible too litterally. If one bases his lifestyle on what the bible says, that person will be allowed to do all sorts of truly nasty modern stuff (like smoking) and still claiming to follow his religion and being good to his body as per what the bible says. A religion must either be able to update its "guide to hygiene/health" with the times, or change the bible/documents to only contain general guidelines and let the health care systems of each time period decide what is good and bad for a body. While some of the bible's recommendations are still applicable today, many are not and there are many which are missing. The hyprocrisy lies in people who follow outdated bible rules, but do nasty modern stuff like smoking, and then condemn people who don't follow those outdated bible rules but follow modern health rules such as not smoking. > the kashrut laws (kosher). Nowhere in the Torah does it say these are > for health reasons. Many of the kashrut laws clearly have nothing to > do with health. See Not sure about Torah. But in one of the links that Boob had pointed to (Leviticus stuff), there was a whole section on various rituals (such as the little op to baby boys and nutrition rules) which started off with a "in order to ensure the success of the religion" (or something akin to this). To me, it was obvious that it was a darwinian statement. Success of the religion relies on its members being healthy and reproducing. Success lies in having lifestyles that would slow down propagation of diseases (hence ban on anal sex, sex with animals, and killing those who have done it (on order to ensure that if they caught some disease from a white fluffy sheep, they don't get to pass this diseases to other humans). And success lies in having safe nutrition. Back in those days, those riles really would have made a difference. (besides, they were probably already widely accepted rules in those days). > And even if that were the motivation: so what? Why do some of you > think that this should imply that all possible dangers in the world > should be enumerated in Leviticus? You either enumerate all the dangers, or none of them and instead provide general guidelines. Or, you update the manual as new knowledge about health/hygiene arises. But it is not smart to take information that is thousands of years old and still apply it litterally today. Blindly following health rules that are thousands of years old just because they are in the Bible is like still believing that the earth is flat and at the centre of the solar system. ------------------------------ Date: Wed, 12 Sep 2007 15:58:32 -0400 From: "Ed Vogel" Subject: Re: Is this a bug or expected behaviour in C99? Message-ID: "Jim Duff" wrote in message news:46e71344@dnews.tpgi.com.au... > Questions: Is my code legal C99? If so, is this expected compiler > behaviour, or is it a bug? I can't find anything in the 7.3/7.2 release > notes (yes, I'm aware I'm on an old compiler) that seems to address this. I asked our expert (and C standard rep) about this. He confirms what others have said. This is not valid C99. There is no compiler bug here. Ed Vogel HP/Compaq/DEC C/C++ Engineering. ------------------------------ Date: Wed, 12 Sep 2007 14:44:21 -0700 From: chrisj.doran@proemail.co.uk Subject: Re: Is this a bug or expected behaviour in C99? Message-ID: <1189633461.659903.38360@57g2000hsv.googlegroups.com> On 12 Sep, 21:58, "Ed Vogel" wrote: > "Jim Duff" wrote in message > > news:46e71344@dnews.tpgi.com.au... > > > Questions: Is my code legal C99? If so, is this expected compiler > > behaviour, or is it a bug? I can't find anything in the 7.3/7.2 release > > notes (yes, I'm aware I'm on an old compiler) that seems to address this. > > I asked our expert (and C standard rep) about this. He confirms what > others > have said. This is not valid C99. There is no compiler bug here. > > Ed Vogel > > HP/Compaq/DEC C/C++ Engineering. Further investigation finds this article on exactly what is and is not valid C99 or an extension to it: http://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html Chris ------------------------------ Date: Thu, 13 Sep 2007 08:27:16 +1000 From: Jim Duff Subject: Re: Is this a bug or expected behaviour in C99? Message-ID: <46e867c4$1@dnews.tpgi.com.au> Ed Vogel wrote: > "Jim Duff" wrote in message > news:46e71344@dnews.tpgi.com.au... >> Questions: Is my code legal C99? If so, is this expected compiler >> behaviour, or is it a bug? I can't find anything in the 7.3/7.2 >> release notes (yes, I'm aware I'm on an old compiler) that seems to >> address this. > > I asked our expert (and C standard rep) about this. He confirms what > others have said. This is not valid C99. There is no compiler bug > here. > > Ed Vogel > > HP/Compaq/DEC C/C++ Engineering. > > Ed, Thanks for the definitive reply. Jim. -- www.eight-cubed.com ------------------------------ Date: Thu, 13 Sep 2007 00:59:26 -0000 From: dreherthomi Subject: Itanium: determine object file main or sub Message-ID: <1189645166.206842.89610@k79g2000hse.googlegroups.com> Integrity/Itanium: Does anybody know how to determine from an object file whether it is a main module or a sub module? On the Alpha, the output of analyze/object contained data about a transfer address and made it possible to distinguish that. ------------------------------ Date: Wed, 12 Sep 2007 18:32:29 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: Product Install, UNDO and recovery data (again!) Message-ID: In article <5kp4e3F4snqaU1@mid.individual.net>, Ken Fairfield writes: > At the end of 2005 and early in 2006, there were about 3 threads > asking about PCSI and deletion of recovery data. In particular, > doing a PRODUCT INSTALL leads to a message similar > to this: > I've run into this trying to install DFU 3.2 on VMS/Alpha 7.3-2 and > find I cannot avoid the warning no matter what combination of > /SAVE, /NOSAVE, etc., qualifiers I use. Just a sanity check. I used to worry about this until I started using /SAVE on the PRODUCT INSTALL command. I think Peter Langstoeger finally cleared up my confusion. ------------------------------ Date: Wed, 12 Sep 2007 18:34:32 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: Product Install, UNDO and recovery data (again!) Message-ID: In article <46e7a69e@news.langstoeger.at>, peter@langstoeger.at (Peter 'EPLAN' LANGSTOeGER) writes: > 3) Always use an installation log file > a) always use /SAVE_RECOVERY_DATA (or DEFINE PCSI$$SAVE_RECOVERY_DATA YES) > b) always use /LOG (or define PCSI$LOG TRUE) > c) always use /TRACE (or define PCSI$TRACE TRUE) Good advice. In addition, before starting I do SET HOST/LAT/LOG to have a log of the entire session. ------------------------------ Date: Wed, 12 Sep 2007 20:35:51 -0700 From: Ken Fairfield Subject: Re: Product Install, UNDO and recovery data (again!) Message-ID: <5krph7F54itfU1@mid.individual.net> Peter 'EPLAN' LANGSTOeGER wrote: > In article <5kp4e3F4snqaU1@mid.individual.net>, Ken Fairfield writes: >> I *think* the conclusion from those discussions, particularly John >> Santos' post(s), was that (1) when doing PROCICT INSTALL of >> ECOs/patches, the recovery data is, or can be, saved and the patch >> backed out with a PRODUCT UNDO command; and (2) that a PRODUCT INSTALL >> of some product (not a patch) will delete the recovery data. >> >> My questions are: >> >> a) Is this summary pretty much correct? >> b) It doesn't matter if the patches are VMS patches and >> the product is something unrelated (Fortran for example), >> the VMS recovery data will *still* be deleted? > > Yes and yes. OK, thanks for the confirmation. > Recovery data are saved in the PCSI$UNDO directories regardless whether > it is an ECO for VMS or for a layered product. > > "Full kit" (you know, the kits with "*-1.PCSI*") installations delete > the recovery data (saved by this "*-4.PCSI*") before their installation. > > Therefore my install recommendations are still: > > 1) Install one kit after the other (and not more than one on the same time) > 2) Group them so that you have > a) VMSINSTAL kits > b) full PCSI kits > c) ECO PCSI kits > 3) Always use an installation log file > a) always use /SAVE_RECOVERY_DATA (or DEFINE PCSI$$SAVE_RECOVERY_DATA YES) > b) always use /LOG (or define PCSI$LOG TRUE) > c) always use /TRACE (or define PCSI$TRACE TRUE) > 4) Always delete all recovery data before the installation session begins [...] That process is all fine and well (3a,b,c), but in a case like mine, DFU wasn't installed when the other full kits were, and indeed, subsequent ECO kits were installed, thus the various PSCI$UNDO directories are present. But now I'm installing a "full kit" for DFU. Just seems counter-intuitive to me that DFU installation deletes recovery data for VMS732* ECO's. But such is life... :-} Thanks again, Ken -- Ken & Ann Fairfield What: Ken dot And dot Ann Where: Gmail dot Com ------------------------------ End of INFO-VAX 2007.499 ************************