INFO-VAX Mon, 27 Aug 2007 Volume 2007 : Issue 469 Contents: 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: Here's one for Bob (hope it makes your head spin) Re: Here's one for Bob (hope it makes your head spin) Re: Itanium Port Question Re: Itanium Port Question Re: Itanium Port Question Re: Itanium Port Question Re: Itanium Port Question Re: Itanium Port Question Re: Itanium Port Question RE: Itanium Port Question Re: Itanium Port Question Re: Itanium Port Question Re: Itanium Port Question Re: Itanium Port Question Re: Itanium Port Question Re: Itanium Port Question Re: Itanium Port Question Re: Wisconsin professor says global warming a hoax! Re: Wisconsin professor says global warming a hoax! ---------------------------------------------------------------------- Date: 26 Aug 2007 14:32:47 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: Alan Winston, when are you correcting your WASD book? Message-ID: In article <07082521421814_2022C7FA@antinode.org>, sms@antinode.org (Steven M. Schweda) writes: > From: winston@SSRL.SLAC.STANFORD.EDU (Alan Winston - SSRL Central Computing) > >> >> $ unzip "-v" htrootxxx.zip >> >> $ unzip "-v" opensslwasdxxxx >> >> >> >> well, it should read >> >> >> >> $ unzip "-v" htrootxxx.zip >> >> $ set def [.ht_root] >> >> $ unzip "-v" [-]opensslwasdxxx > > My question would be, 'Why the quotation of "-v"?' I can see why > "-V" might need quotation, but not "-v". Absent quotation marks, DCL will upcase letters. Thus -v or -V will be seen by the program as -V. I don't know what -v or -V means, and I try to avoid using programs that do not "speak" DCL, but that is how character processing works on a vanilla VMS account. ------------------------------ Date: Mon, 27 Aug 2007 06:21:15 +0930 From: Mark Daniel Subject: Re: Alan Winston, when are you correcting your WASD book? Message-ID: <13d3pv3rp0rnd3c@corp.supernews.com> Larry Kilgallen wrote: > In article <07082521421814_2022C7FA@antinode.org>, sms@antinode.org (Steven M. Schweda) writes: > >>From: winston@SSRL.SLAC.STANFORD.EDU (Alan Winston - SSRL Central Computing) >> >> >>>>>$ unzip "-v" htrootxxx.zip >>>>>$ unzip "-v" opensslwasdxxxx >>>>> >>>>>well, it should read >>>>> >>>>>$ unzip "-v" htrootxxx.zip >>>>>$ set def [.ht_root] >>>>>$ unzip "-v" [-]opensslwasdxxx >> >> My question would be, 'Why the quotation of "-v"?' I can see why >>"-V" might need quotation, but not "-v". > > > Absent quotation marks, DCL will upcase letters. The C-RTL complicates that by ensuring the command-line arguments passed to main() have been lower-cased hence quoting preserves upper-case. > Thus -v or -V will be seen by the program as -V. > > I don't know what -v or -V means, and I try to avoid using programs > that do not "speak" DCL, but that is how character processing works > on a vanilla VMS account. As the original context was a WASD related posting ... $ UNZIP -H describes it as -V retain VMS version numbers in contrast to -v list verbosely/show version info while $ ZIP -H describes it more accurately "-V" save VMS file attributes So the "-V" is specified by the WASD install instructions ensures the original file attributes stored when ZIPed using "-V" are reflected in the files created by the UNZIP. The quotes are required to preserve the upper-case of the option. -- Death: You're an interesting young man. We'll meet again. Young Boris: Don't bother. Death: It's no bother. [Woody Allen; Love and Death] ------------------------------ Date: 26 Aug 2007 21:30:57 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: Alan Winston, when are you correcting your WASD book? Message-ID: In article <13d3pv3rp0rnd3c@corp.supernews.com>, Mark Daniel writes: > The C-RTL complicates that by ensuring the command-line arguments passed > to main() have been lower-cased hence quoting preserves upper-case. Yuck ! ------------------------------ Date: Sun, 26 Aug 2007 22:24:53 -0500 (CDT) From: sms@antinode.org (Steven M. Schweda) Subject: Re: Alan Winston, when are you correcting your WASD book? Message-ID: <07082622245363_20230876@antinode.org> From: Mark Daniel > Larry Kilgallen wrote: > > In article <07082521421814_2022C7FA@antinode.org>, sms@antinode.org (Steven M. Schweda) writes: > > > >>From: winston@SSRL.SLAC.STANFORD.EDU (Alan Winston - SSRL Central Computing) > >> > >>>>>$ unzip "-v" htrootxxx.zip > >>>>>$ unzip "-v" opensslwasdxxxx > >>>>> > >>>>>well, it should read > >>>>> > >>>>>$ unzip "-v" htrootxxx.zip > >>>>>$ set def [.ht_root] > >>>>>$ unzip "-v" [-]opensslwasdxxx > >> > >> My question would be, 'Why the quotation of "-v"?' I can see why > >>"-V" might need quotation, but not "-v". > > > > Absent quotation marks, DCL will upcase letters. > > The C-RTL complicates that by ensuring the command-line arguments passed > to main() have been lower-cased hence quoting preserves upper-case. In fact, newer C RTL versions can be made to do pretty much anything you want, as shown below. > > Thus -v or -V will be seen by the program as -V. > > > > I don't know what -v or -V means, and I try to avoid using programs > > that do not "speak" DCL, but that is how character processing works > > on a vanilla VMS account. The Info-ZIP programs offer optional CLI front-ends for the hyphen-challenged. > As the original context was a WASD related posting ... > > $ UNZIP -H > > describes it as > > -V retain VMS version numbers > > in contrast to > > -v list verbosely/show version info > > while > > $ ZIP -H > > describes it more accurately > > "-V" save VMS file attributes AIEEEE!!! "zip -h" describes Zip (more or less) accurately, while "unzip -h" describes UnZip (more or less) accurately. The "-V" options for the two programs do different things, which is the primary reason that the descriptions in the two help reports are different. > So the "-V" is specified by the WASD install instructions ensures the > original file attributes stored when ZIPed using "-V" are reflected in > the files created by the UNZIP. The quotes are required to preserve the > upper-case of the option. No, and no. The "-v" adds verbosity to UnZip, and never needs quotation. What upper-case option? "-V" would cause UnZip to restore VMS version numbers (if they were stored in the archive, typically as a result of using "zip -w") when it extracts files from the archive. When VMS file attributes are stored in an archive, typically as a result of using 'zip "-V"', _no_ special UnZip command-line options are needed to get the attributes restored when the files are extracted on a VMS system. That is, in general, all you need to do is: zip "-V" archive.zip file_spec unzip archive.zip ! No "-V'. No "-v". As for case, when in doubt, ask the program(s). On a VAX, or on a non-VAX system with SET PROCESS /PARSE_STYLE = TRADITIONAL: alp $ zip -v Copyright (c) 1990-2006 Info-ZIP - Type 'zip "-L"' for software license. This is Zip 2.32 (June 19th 2006), by Info-ZIP. [...] alp $ zip "-v" Copyright (c) 1990-2006 Info-ZIP - Type 'zip "-L"' for software license. This is Zip 2.32 (June 19th 2006), by Info-ZIP. [...] alp $ zip -V Copyright (c) 1990-2006 Info-ZIP - Type 'zip "-L"' for software license. This is Zip 2.32 (June 19th 2006), by Info-ZIP. [...] alp $ zip "-V" zip error: Invalid command arguments (cannot write zip file to terminal) Here, '-v', '"-v"', and '-V' are equivalent, while '"-V"' is different. On a (non-VAX) system with SET PROCESS /PARSE_STYLE = EXTENDED: alp $ zip -v Copyright (c) 1990-2006 Info-ZIP - Type 'zip "-L"' for software license. This is Zip 2.32 (June 19th 2006), by Info-ZIP. [...] alp $ zip "-v" Copyright (c) 1990-2006 Info-ZIP - Type 'zip "-L"' for software license. This is Zip 2.32 (June 19th 2006), by Info-ZIP. [...] alp $ zip -V zip error: Invalid command arguments (cannot write zip file to terminal) alp $ zip "-V" zip error: Invalid command arguments (cannot write zip file to terminal) Here, command-line case is preserved (as if by magic). (Or, as if by using DECC$ARGV_PARSE_STYLE.) With versions older than UnZip 5.52 and Zip 2.32, SET PROCESS /PARSE_STYLE may have no effect, but that doesn't change the (lack of) need to quote '-v'. Now, if you _want_ what 'unzip -v' does, it's ok with me, but it seems unlikely, and, in any case, you should never need to quote '-v'. If your reality differs from mine, feel free to demonstrate. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Sun, 26 Aug 2007 18:33:01 -0700 From: AEF Subject: Re: COBOL Transactions? Message-ID: <1188178381.287418.255120@57g2000hsv.googlegroups.com> On Aug 26, 10:45 am, "Paul Raulerson" wrote: > > Then why, pray tell, are you f*****' around with a 4mm drive? > > LOL! That was the whole point, I'm *not*. I may need to on an Itanium, but > as of today, I haven't even figured out which Itanium to order, or if it > makes > more sense to attend one of those HP sessions where they *give* you one. ;) > > I do not know what the backup options for a low end Itanium are. > > > In another post in this thread you wrote... > > > "I'm excited about it, and know I need to move this to Itanium, but > > being > > cheap, I think I will do a porting event thing as soon as I have > > enough > > ported, working, and tested on the little Alpha here. The only issue > > with > > the Alpha is that the 4mm tape drive on it does not seem to be > > recognized. > > Yep.. "the" Alpha sitting in the equipment room upstairs sure doesn't > know how to talk to the old 4mm that was installed in it. > > > It sure looks like you're saying that the Alpha doesn't know how to > > talk to tape (ANY tape) to me! > > "The" Alpha - meaning the one machine sitting >>> here <<< doesn't > know how to talk to that one tape. There is a hardware issue with > this *one* Alpha. You, uh, mmmmm, forgot one very important part of your self-quoting. Let's see that again in slow motion, shall we? On Aug 23, 9:19 pm, "Paul Raulerson" wrote: > > -----Original Message----- > > From: Richard Maher [mailto:maher...@hotspamnotmail.com] > > Sent: Thursday, August 23, 2007 6:04 AM > > To: Info-...@Mvb.Saic.Com > > Subject: Re: COBOL Transa [...] > I'm excited about it, and know I need to move this to Itanium, but being > cheap, I think I will do a porting event thing as soon as I have enough > ported, working, and tested on the little Alpha here. The only issue with > the Alpha is that the 4mm tape drive on it does not seem to be recognized. OK. Here's where you conveniently snipped a little too much. Here's the continuation of the above quote: > No big matter - source gets backed up to disk > 3 times per day, and FTP'ed off to the UNIX machine which *does* know how to > talk to tape. Tapes go into the library, the safe, and my lower left hand > desk drawer at my "day" job! WOAH! Hold it! Look right there. Right above. It says: > No big matter - source gets backed up to disk > 3 times per day, and FTP'ed off to the UNIX machine which *does* know how to > talk to tape. Did you see that? Shall I replay it again? A little slower maybe? The clear implication is that you're saying that the Alpha (OK, maybe just *your* Alpha), does not know how to talk to tape. Not just your 4mm drive, but just plain old TAPE. QED. > I'm dead sure that Alpha machines running VMS have no trouble talking > to tape drives. OK, maybe you wrote a little carelessly the first time. But please don't try to make it look like you wrote something else. Actually I'm very happy your porting stuff to Alpha and possibly Itanium. Best of luck on your endeavor. [...] > -Paul AEF ------------------------------ Date: Sun, 26 Aug 2007 22:06:11 -0500 From: "Paul Raulerson" Subject: RE: COBOL Transactions? Message-ID: <001701c7e857$39086a00$ab193e00$@com> > You, uh, mmmmm, forgot one very important part of your self-quoting. > Let's see that again in slow motion, shall we? > > On Aug 23, 9:19 pm, "Paul Raulerson" wrote: > > > -----Original Message----- > > > From: Richard Maher [mailto:maher...@hotspamnotmail.com] > > > Sent: Thursday, August 23, 2007 6:04 AM > > > To: Info-...@Mvb.Saic.Com > > > Subject: Re: COBOL Transa > > [...] > > > I'm excited about it, and know I need to move this to Itanium, but > being > > cheap, I think I will do a porting event thing as soon as I have > enough > > ported, working, and tested on the little Alpha here. The only issue > with > > the Alpha is that the 4mm tape drive on it does not seem to be > recognized. > > OK. Here's where you conveniently snipped a little too much. Here's > the continuation of the above quote: > > > No big matter - source gets backed up to disk > > 3 times per day, and FTP'ed off to the UNIX machine which *does* know > how to > > talk to tape. Tapes go into the library, the safe, and my lower left > hand > > desk drawer at my "day" job! > > WOAH! Hold it! Look right there. Right above. It says: > > > No big matter - source gets backed up to disk > > 3 times per day, and FTP'ed off to the UNIX machine which *does* know > how to > > talk to tape. > > Did you see that? Shall I replay it again? A little slower maybe? > > The clear implication is that you're saying that the Alpha (OK, maybe > just *your* Alpha), does not know how to talk to tape. Not just your > 4mm drive, but just plain old TAPE. > Let me be clear and edit it back to the original: I'm excited about it, and know I need to move this to Itanium, but being cheap, I think I will do a porting event thing as soon as I have enough ported, working, and tested on the little Alpha here. The only issue with the Alpha is that the 4mm tape drive on it does not seem to be recognized. No big matter - source gets backed up to disk 3 times per day, and FTP'ed off to the UNIX machine which *does* know how to talk to tape. Tapes go into the library, the safe, and my lower left hand desk drawer at my "day" job! There is nothing in there that implies I ever said all Alpha's could not talk to tape in any way shape manner or form. Nor does it explicty state that the information from a half dozen other machines is backed up to the same UNIX machine and the same set of tape drives attached to it. (That's UNIX, Linux, Mac, as well as Windows stuff.) So no, I understand that what you may have heard is not what I said, but what I said was clear. I'll slow it down for you... "The only issue with the Alpha is that the 4mm tape drive on it does not seem to be recognized." I'm really not going to apologize yet >> again << on this; what I wrote, at least as pertains to the tape drive, was clear and definite and should not have been insulting to anyone. There is *nothing* more too it. -Paul ------------------------------ Date: Sun, 26 Aug 2007 11:20:06 -0700 From: Neil Rieck Subject: Re: Here's one for Bob (hope it makes your head spin) Message-ID: <1188152406.814377.305300@19g2000hsx.googlegroups.com> On Aug 26, 8:12 am, Ron Johnson wrote: [...snip...] > > The *Romans* killed Jesus. Anyone who's read Matthew, and has two > neurons to rub together, knows that. > Many misguided Christians believe that the Sanhedrin maneuvered Pilot into the crucifixion and the Romans obliged in order to avoid a political crisis (Pilot had already been warned twice by Tiberius to keep things quiet in Judea) But if this was supposed to be some sort of divine sacrifice then why blame anyone? NSR ------------------------------ Date: Sun, 26 Aug 2007 23:54:58 -0000 From: ultradwc@gmail.com Subject: Re: Here's one for Bob (hope it makes your head spin) Message-ID: <1188172498.272179.37250@r34g2000hsd.googlegroups.com> On Aug 26, 8:12 am, Ron Johnson wrote: > On 08/26/07 06:11, Neil Rieck wrote: > > > On Aug 25, 1:03 pm, Ron Johnson wrote: > >> On 08/25/07 07:14, Neil Rieck wrote: > > > [...snip...] > >>> Talk to anyone who was an adult during World War 2 and you'll find > >>> that many common folk were anti-Semitic even though they called > >>> themselves Christians. (The people telling you these facts will always > >> "The Jews killed Jesus." > > > Christians are taught that God sent his only son to die for humanity's > > sins. So if it is necessary to blame someone, blame God. > > The *Romans* killed Jesus. Anyone who's read Matthew, and has two > neurons to rub together, knows that. > > Anyway... I could say more about Catholic tradition and theology, > but c.o.v is definitely not the place to start a huge OT flame war. > > But then, there are many atheists/agnostics and Protestants on the > list who would probably agree with me. > > -- > 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! No, Adam and Eve and you and I killed Him ... if it was not for our sins, He would have not had to come here and die for them ... ------------------------------ Date: 26 Aug 2007 14:29:52 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: Itanium Port Question Message-ID: In article , Evert van Dijken writes: > Depends on you programming language, Only macro needs to be rewritten. And Ada. And PLI. ------------------------------ Date: Sun, 26 Aug 2007 20:20:26 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: Itanium Port Question Message-ID: In article , Evert van Dijken writes: > > >Depends on you programming language, Only macro needs to be rewritten. Huh? You need to steer clear of those Amsterdam coffee houses! Macro does NOT need to be rewritten to run on Itanium. It didn't need to be rewritten to run on Alpha either. I recall this "mythconception" when Alpha was first released. A large portion of OpenVMS (VAX/Alpha/Itanium) is written in Macro and it has NOT rewritten. There may need to be some modifications to the source but there is no need to rewrite the code just to port it to Alpha or Itanium. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" http://tmesis.com/drat.jpg ------------------------------ Date: Sun, 26 Aug 2007 21:50:39 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: Itanium Port Question Message-ID: In article , Ron Johnson writes: > > >On 08/26/07 15:20, VAXman- @SendSpamHere.ORG wrote: >> In article , Evert van Dijken writes: >>> >>> Depends on you programming language, Only macro needs to be rewritten. >> >> Huh? You need to steer clear of those Amsterdam coffee houses! >> >> Macro does NOT need to be rewritten to run on Itanium. It didn't need to >> be rewritten to run on Alpha either. I recall this "mythconception" when >> Alpha was first released. A large portion of OpenVMS (VAX/Alpha/Itanium) >> is written in Macro and it has NOT rewritten. There may need to be some >> modifications to the source but there is no need to rewrite the code just >> to port it to Alpha or Itanium. > >Wouldn't alignment faults be more of a problem in Macro than in, >say, COBOL? An alignment fault is an alignment fault regardless of the language used to source the program. I could write code in any language to experience an alignment fault; I could write code in any language to not experience an alignment fault. Rewriting a program sourced in language 'P' to one source in language 'Q' is not necessarily going to remove issues of any alignment fault. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" http://tmesis.com/drat.jpg ------------------------------ Date: Sun, 26 Aug 2007 16:48:58 -0700 From: FrankS Subject: Re: Itanium Port Question Message-ID: <1188172138.417708.74290@50g2000hsm.googlegroups.com> On Aug 26, 5:32 pm, Ron Johnson wrote: > Wouldn't alignment faults be more of a problem in Macro than in, > say, COBOL? This is a COBOL alignment fault ... 01 TOP-LEVEL. 03 DATA-ITEM-1 PIC X(1). 03 DATA-ITEM-2 PIC S9(9) COMP. Data-Item-2 is not on a natural boundary. This likely happens in lots and lots of places in many COBOL programs. I'm sure there's a ton of similar problems in programs I and many others have written over the years. ------------------------------ Date: Mon, 27 Aug 2007 07:59:43 +0800 From: "Richard Maher" Subject: Re: Itanium Port Question Message-ID: Hi Frank, "FrankS" wrote in message news:1188172138.417708.74290@50g2000hsm.googlegroups.com... > On Aug 26, 5:32 pm, Ron Johnson wrote: > > Wouldn't alignment faults be more of a problem in Macro than in, > > say, COBOL? > > This is a COBOL alignment fault ... > > 01 TOP-LEVEL. > 03 DATA-ITEM-1 PIC X(1). > 03 DATA-ITEM-2 PIC S9(9) COMP. > > Data-Item-2 is not on a natural boundary. This likely happens in lots > and lots of places in many COBOL programs. I'm sure there's a ton of > similar problems in programs I and many others have written over the > years. > It's only an alignment fault if the compiler doesn't spot it and/or doesn't generate the instructions to move DATA_ITEM_2 to aligned memory before doing any integer operations on it. The fact that it might now take a few more instructions is neither here nor there as long as the alignment fault is avoided. I believe a problem with early versions of DEC COBOL on Itanium is that it was pretty useless at spotting unaligned references. I also believe that John Reagan's team has corrected most of the problems and a new version is available. (I personally think it's a bit rich to refer to it as a "New Feature" release but there you go.) Cheers Richard Maher ------------------------------ Date: Mon, 27 Aug 2007 08:04:41 +0800 From: "Richard Maher" Subject: Re: Itanium Port Question Message-ID: Forgot to mention that COBOL, like all other compilers, has the /alignment qualifiers if you're happy for it to pad 3 bytes between data_item_1 and data_item_3. Cheers Richard Maher "Richard Maher" wrote in message news:fat4bh$96q$1@news-01.bur.connect.com.au... > Hi Frank, > > "FrankS" wrote in message > news:1188172138.417708.74290@50g2000hsm.googlegroups.com... > > On Aug 26, 5:32 pm, Ron Johnson wrote: > > > Wouldn't alignment faults be more of a problem in Macro than in, > > > say, COBOL? > > > > This is a COBOL alignment fault ... > > > > 01 TOP-LEVEL. > > 03 DATA-ITEM-1 PIC X(1). > > 03 DATA-ITEM-2 PIC S9(9) COMP. > > > > Data-Item-2 is not on a natural boundary. This likely happens in lots > > and lots of places in many COBOL programs. I'm sure there's a ton of > > similar problems in programs I and many others have written over the > > years. > > > > It's only an alignment fault if the compiler doesn't spot it and/or doesn't > generate the instructions to move DATA_ITEM_2 to aligned memory before doing > any integer operations on it. The fact that it might now take a few more > instructions is neither here nor there as long as the alignment fault is > avoided. > > I believe a problem with early versions of DEC COBOL on Itanium is that it > was pretty useless at spotting unaligned references. I also believe that > John Reagan's team has corrected most of the problems and a new version is > available. (I personally think it's a bit rich to refer to it as a "New > Feature" release but there you go.) > > Cheers Richard Maher > > ------------------------------ Date: Sun, 26 Aug 2007 17:26:00 -0700 From: FrankS Subject: Re: Itanium Port Question Message-ID: <1188174360.239654.298340@o80g2000hse.googlegroups.com> On Aug 26, 8:04 pm, "Richard Maher" wrote: > Forgot to mention that COBOL, like all other compilers, has the /alignment > qualifiers if you're happy for it to pad 3 bytes between data_item_1 and > data_item_3. >From a porting perspective, though, I would expect the default qualifiers (no alignment) would be used, particularly if data structures are being used to read/write from files that already exist. That is, if files already exist with records that were not padded then the /ALIGNMENT qualifier wouldn't come into play. (Yes, yes, I know you can use compiler directives to selectively align structures. That's getting way off stream from the question of whether or not alignment faults are more likely to occur in Macro .vs. COBOL.) I'm aware that the compiler will generate instructions to manipulate bytes within an aligned quadword, but I didn't think it would generate instructions to manipulate all data items so that alignment faults are always avoided. There comes a point where the compiler writers need to stop being the data police for users that don't do their own performance analysis. ------------------------------ Date: Sun, 26 Aug 2007 19:45:14 -0500 From: "Paul Raulerson" Subject: RE: Itanium Port Question Message-ID: <000101c7e843$88639930$992acb90$@com> > -----Original Message----- > From: FrankS [mailto:sapienza@noesys.com] > Sent: Sunday, August 26, 2007 6:49 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Itanium Port Question > > On Aug 26, 5:32 pm, Ron Johnson wrote: > > Wouldn't alignment faults be more of a problem in Macro than in, > > say, COBOL? > > This is a COBOL alignment fault ... > > 01 TOP-LEVEL. > 03 DATA-ITEM-1 PIC X(1). > 03 DATA-ITEM-2 PIC S9(9) COMP. > > Data-Item-2 is not on a natural boundary. This likely happens in lots > and lots of places in many COBOL programs. I'm sure there's a ton of > similar problems in programs I and many others have written over the > years. Are you saying the compile does not pad that out correctly? That should not be a problem in COBOL so far as I know. -Paul ------------------------------ Date: Sun, 26 Aug 2007 20:50:13 -0400 From: "Richard B. Gilbert" Subject: Re: Itanium Port Question Message-ID: <46D21FC5.2040005@comcast.net> VAXman- wrote: > In article , Ron Johnson writes: > >> >>On 08/26/07 15:20, VAXman- @SendSpamHere.ORG wrote: >> >>>In article , Evert van Dijken writes: >>> >>>>Depends on you programming language, Only macro needs to be rewritten. >>> >>>Huh? You need to steer clear of those Amsterdam coffee houses! >>> >>>Macro does NOT need to be rewritten to run on Itanium. It didn't need to >>>be rewritten to run on Alpha either. I recall this "mythconception" when >>>Alpha was first released. A large portion of OpenVMS (VAX/Alpha/Itanium) >>>is written in Macro and it has NOT rewritten. There may need to be some >>>modifications to the source but there is no need to rewrite the code just >>>to port it to Alpha or Itanium. >> >>Wouldn't alignment faults be more of a problem in Macro than in, >>say, COBOL? > > > An alignment fault is an alignment fault regardless of the language used > to source the program. I could write code in any language to experience > an alignment fault; I could write code in any language to not experience > an alignment fault. Rewriting a program sourced in language 'P' to one > source in language 'Q' is not necessarily going to remove issues of any > alignment fault. > Alignment faults are basically caused by how you arrange and declare your structures. This was a problem long before there was a VAX or VMS. We worried about it in IBM/360 Fortran IV. If you failed to put your REAL*8 variables first in your COMMON blocks, you could get alignment faults. Fixing them up slowed execution and the machines of yesteryear were slow to begin with. Doing anything to make them slower was anathema!! Those who were REALLY with it, used COMMON very sparingly! Making variables available to code that doesn't need them is seldom good practice! You usually have to work at it to get an alignment fault. Compilers know how to align things and usually do it very well UNTIL some dumb programmer makes it impossible by doing something to defeat the compilers alignment. If you create a struct with float, char, double there is no way the compiler can align it properly and still do what you asked for! Even Macro will align things properly until you create a structure that's impossible to align properly. ------------------------------ Date: Sun, 26 Aug 2007 18:31:30 -0700 From: "Tom Linden" Subject: Re: Itanium Port Question Message-ID: On Sun, 26 Aug 2007 17:50:13 -0700, Richard B. Gilbert wrote: > Alignment faults are basically caused by how you arrange and declare > your structures. This was a problem long before there was a VAX or > VMS. We worried about it in IBM/360 Fortran IV. If you failed to put > your REAL*8 variables first in your COMMON blocks, you could get > alignment faults. Fixing them up slowed execution and the machines of > yesteryear were slow to begin with. Doing anything to make them slower > was anathema!! > IIRC, PL/I on 360 didn't have that problem, afterall it was a byte addressable machine, as is the VAX. -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Sun, 26 Aug 2007 18:39:04 -0700 From: "Tom Linden" Subject: Re: Itanium Port Question Message-ID: On Sun, 26 Aug 2007 16:48:58 -0700, FrankS wrote: > On Aug 26, 5:32 pm, Ron Johnson wrote: >> Wouldn't alignment faults be more of a problem in Macro than in, >> say, COBOL? > > This is a COBOL alignment fault ... > > 01 TOP-LEVEL. > 03 DATA-ITEM-1 PIC X(1). > 03 DATA-ITEM-2 PIC S9(9) COMP. > > Data-Item-2 is not on a natural boundary. This likely happens in lots > and lots of places in many COBOL programs. I'm sure there's a ton of > similar problems in programs I and many others have written over the > years. > Alignment was neglected in Alpha and Itanium, that was a mistake, and is the consequence of bad management, i.e. failing to understand the market. You will note that Power PC does not have this problem. -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: 26 Aug 2007 21:32:35 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: Itanium Port Question Message-ID: In article , "Tom Linden" writes: > On Sun, 26 Aug 2007 17:50:13 -0700, Richard B. Gilbert > wrote: > >> Alignment faults are basically caused by how you arrange and declare >> your structures. This was a problem long before there was a VAX or >> VMS. We worried about it in IBM/360 Fortran IV. If you failed to put >> your REAL*8 variables first in your COMMON blocks, you could get >> alignment faults. Fixing them up slowed execution and the machines of >> yesteryear were slow to begin with. Doing anything to make them slower >> was anathema!! >> > IIRC, PL/I on 360 didn't have that problem, afterall it was a byte > addressable > machine, as is the VAX. Even on VAX, good alignment produces better performance. ------------------------------ Date: Sun, 26 Aug 2007 19:43:01 -0700 From: "Tom Linden" Subject: Re: Itanium Port Question Message-ID: On Sun, 26 Aug 2007 19:32:35 -0700, Larry Kilgallen wrote: > In article , "Tom Linden" > writes: >> On Sun, 26 Aug 2007 17:50:13 -0700, Richard B. Gilbert >> wrote: >> >>> Alignment faults are basically caused by how you arrange and declare >>> your structures. This was a problem long before there was a VAX or >>> VMS. We worried about it in IBM/360 Fortran IV. If you failed to put >>> your REAL*8 variables first in your COMMON blocks, you could get >>> alignment faults. Fixing them up slowed execution and the machines of >>> yesteryear were slow to begin with. Doing anything to make them slower >>> was anathema!! >>> >> IIRC, PL/I on 360 didn't have that problem, afterall it was a byte >> addressable >> machine, as is the VAX. > > Even on VAX, good alignment produces better performance. True, but the degradation was nowhere near as bad as on current HW, it was, as it should be an extra tick. -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Sun, 26 Aug 2007 22:54:18 -0400 From: "Richard B. Gilbert" Subject: Re: Itanium Port Question Message-ID: <46D23CDA.2070103@comcast.net> Tom Linden wrote: > On Sun, 26 Aug 2007 17:50:13 -0700, Richard B. Gilbert > wrote: > >> Alignment faults are basically caused by how you arrange and declare >> your structures. This was a problem long before there was a VAX or >> VMS. We worried about it in IBM/360 Fortran IV. If you failed to >> put your REAL*8 variables first in your COMMON blocks, you could get >> alignment faults. Fixing them up slowed execution and the machines >> of yesteryear were slow to begin with. Doing anything to make them >> slower was anathema!! >> > IIRC, PL/I on 360 didn't have that problem, afterall it was a byte > addressable > machine, as is the VAX. > > I can't swear to it that ALL IBM/360 were sensitive to alignment but the Model 91 certainly was! The model 91 was the super computer of the day. AIRC NASA ordered 17 of them from IBM and several Universities, including Princeton jumped on the bandwagon and wanted one too. Princeton had the model 91 when I started working there ca. January 1970. Just because a machine is byte adressable does not mean that there is no advantage to aligning your accesses. You can access any byte in memory but the machine may retrieve a byte, word, longword, or quadword in order to get that byte and it may like some number of the low order bits of the address to be zero. To retrieve a quadword that was not quadword aligned could require two memory accesses instead of one. ISTR that, at least in the IBM 360, the size of a memory access varied with the model. The model 91 grabbed a quadword at a time from core (real magnetic cores. . . Oh the nostalgia!) and loaded the piece(s) you wanted where you wanted them. Accesses that were quadword aligned were fastest. The model 91 had a sixteen-way interleave and I believe it retrieved sixteen bytes at a time. ------------------------------ Date: Sun, 26 Aug 2007 22:48:29 -0700 From: Bob Gezelter Subject: Re: Itanium Port Question Message-ID: <1188193709.818989.265650@r29g2000hsg.googlegroups.com> On Aug 26, 10:54 pm, "Richard B. Gilbert" wrote: > Tom Linden wrote: > > On Sun, 26 Aug 2007 17:50:13 -0700, Richard B. Gilbert > > wrote: > > >> Alignment faults are basically caused by how you arrange and declare > >> your structures. This was a problem long before there was a VAX or > >> VMS. We worried about it in IBM/360 Fortran IV. If you failed to > >> put your REAL*8 variables first in your COMMON blocks, you could get > >> alignment faults. Fixing them up slowed execution and the machines > >> of yesteryear were slow to begin with. Doing anything to make them > >> slower was anathema!! > > > IIRC, PL/I on 360 didn't have that problem, afterall it was a byte > > addressable > > machine, as is the VAX. > > I can't swear to it that ALL IBM/360 were sensitive to alignment but the > Model 91 certainly was! The model 91 was the super computer of the day. > AIRC NASA ordered 17 of them from IBM and several Universities, > including Princeton jumped on the bandwagon and wanted one too. > Princeton had the model 91 when I started working there ca. January 1970. > > Just because a machine is byte adressable does not mean that there is no > advantage to aligning your accesses. You can access any byte in memory > but the machine may retrieve a byte, word, longword, or quadword in > order to get that byte and it may like some number of the low order bits > of the address to be zero. To retrieve a quadword that was not quadword > aligned could require two memory accesses instead of one. ISTR that, at > least in the IBM 360, the size of a memory access varied with the model. > The model 91 grabbed a quadword at a time from core (real magnetic > cores. . . Oh the nostalgia!) and loaded the piece(s) you wanted where > you wanted them. Accesses that were quadword aligned were fastest. The > model 91 had a sixteen-way interleave and I believe it retrieved sixteen > bytes at a time. Richard, Alignment did matter on all models of the System/360, unless there were special provisions to the contrary (reference, "Systems/360 Principles of Operation"). The alignment restrictions were eased with the advent of the System/ 370. Alignment faults can generally be detected by the compiler's code generator and dealt with appropriately. This is even true for MACRO-32, which is a compiler on all architectures other than the original VAX. The problem is not unaligned data per se, but data whose alignment is misrepresented to the compiler. The simplest cases of this occur with data passed to subroutines as parameters. Probably the more common case is data that is contained within structures that are themselves within other structures. Somewhere along the chain, some piece of code violates the alignment presumption. There are two alternatives: provide hardware support for the mis- alignment consequences, or take a fault and use software to sort it out. The increased overhead on Alpha and Itanium generally results from the inherent overhead of taking the fault and winding down processing. The more an architecture pre-fetches and pipelines, the higher the penalty for faulting and other interrupts. Note that the penalty on a non- pipelined, non-optimized machine is zero for faults, but it is also a far slower machine in all other aspects. Please remember that the problem is not how many alignment errors there are in the code, the problem is how often they are executed. Many of the cases of performance sapping alignment faults have not, I strongly suspect, been systematic coding errors, but unrealized errors that happened to be embedded in a frequently used code path. - Bob Gezelter, http://www.rlgsc.com ------------------------------ Date: Sun, 26 Aug 2007 11:42:53 -0700 From: Neil Rieck Subject: Re: Wisconsin professor says global warming a hoax! Message-ID: <1188153773.764212.287700@o80g2000hse.googlegroups.com> On Aug 26, 10:55 am, "Tom Linden" wrote: > On Sun, 26 Aug 2007 05:34:17 -0700, Neil Rieck > wrote: [...snip...] > > Read up on Sunspots. AGM is not a fait accompli. Increased CO2 could be > a cause of increased global temperature, or it could be a coincidence, I > don't think we have enough data to answer that question, afterall, we > have had warmer periods in the past. I promise this is my last post on > this Off Topic. > I don't need to "read up on sunspots" to agree with you. Stellar evolution, as described by Hertzsprung-Russell, predicts that stars will get hotter as they get older. Our Sun is now 30% hotter than it was 4 billion years ago and it will get really hot long before it reaches the Red-Giant phase billions of years from now. All this heat is releasing another green house gas, methane, currently trapped under melting ice. So as the sun gets hotter we can't say that an expected ice-age is just around the corner because at some point there just won't be anymore ice. But the bigger point is this: we've been provided with brains and technology so it would be a terrible waste if we didn't try to do something about this problem. NSR ------------------------------ Date: Sun, 26 Aug 2007 18:15:46 -0700 From: "Tom Linden" Subject: Re: Wisconsin professor says global warming a hoax! Message-ID: On Sun, 26 Aug 2007 11:42:53 -0700, Neil Rieck wrote: > On Aug 26, 10:55 am, "Tom Linden" wrote: >> On Sun, 26 Aug 2007 05:34:17 -0700, Neil Rieck >> wrote: > [...snip...] >> >> Read up on Sunspots. AGM is not a fait accompli. Increased CO2 could >> be >> a cause of increased global temperature, or it could be a coincidence, I >> don't think we have enough data to answer that question, afterall, we >> have had warmer periods in the past. I promise this is my last post on >> this Off Topic. >> > > I don't need to "read up on sunspots" to agree with you. Stellar > evolution, as described by Hertzsprung-Russell, predicts that stars > will get hotter as they get older. Our Sun is now 30% hotter than it > was 4 billion years ago and it will get really hot long before it > reaches the Red-Giant phase billions of years from now. All this heat > is releasing another green house gas, methane, currently trapped under > melting ice. > Neil, your are confusing the issue, stellar evoultion has nothing to do with this discussion, that is an entirely different time scale. > So as the sun gets hotter we can't say that an expected ice-age is > just around the corner because at some point there just won't be > anymore ice. We will have a thousand ice ages before the sun gets that big. > > But the bigger point is this: we've been provided with brains and > technology so it would be a terrible waste if we didn't try to do > something about this problem. It may not be a problem but rather a phenomenon, or manifestation > > NSR > -- PL/I for OpenVMS www.kednos.com ------------------------------ End of INFO-VAX 2007.469 ************************