INFO-VAX Wed, 29 Aug 2007 Volume 2007 : Issue 473 Contents: Re: Alan Winston, when are you correcting your WASD book? Re: DEC 3000/800 AXP boot problem Re: DEC 3000/800 AXP boot problem Re: DEC 3000/800 AXP boot problem Re: Hanging TNA ports. Re: Itanium Port Question Re: Itanium Port Question Re: Itanium Port Question RE: Itanium Port Question Re: Itanium Port Question RE: Itanium Port Question Lock problem with SAMBA/NMBD Re: Lock problem with SAMBA/NMBD Re: Lock problem with SAMBA/NMBD Re: Lock problem with SAMBA/NMBD Re: SMB backup "solutions" (was:Re: COBOL Transactions?) The Common System Interface: Intel's Future Interconnect Re: Wisconsin professor says global warming a hoax! Re: Wisconsin professor says global warming a hoax! ---------------------------------------------------------------------- Date: 28 Aug 2007 14:54:45 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Alan Winston, when are you correcting your WASD book? Message-ID: In article <5jimssF3rm2qcU1@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: > > Apparently, as of 31 March 2004, Preston Burch the HST Program Manager > disagrees with you. :-) Can you point out any available documents to > support the idea that The HST Project has gone back to running VMS? I know Preston Burch. I read what he wrote. There are no conflicts between the technical content of his statements and mine. The replacement of the UNIX systems first used to replace old VAXen came up after 2004. ------------------------------ Date: Tue, 28 Aug 2007 12:45:50 -0700 From: urbancamo Subject: Re: DEC 3000/800 AXP boot problem Message-ID: <1188330350.273447.325990@o80g2000hse.googlegroups.com> On 28 Aug, 16:50, "Tom Linden" wrote: > Try cleaning the temperature sensor. Tom, do you have any idea where it is on an '800? I tried the tech man but couldn't find a mention. I'm presuming it's gonna be near the processor? Cheers, Mark. ------------------------------ Date: Tue, 28 Aug 2007 16:22:41 -0700 From: "Tom Linden" Subject: Re: DEC 3000/800 AXP boot problem Message-ID: On Tue, 28 Aug 2007 12:45:50 -0700, urbancamo wrote: > On 28 Aug, 16:50, "Tom Linden" wrote: >> Try cleaning the temperature sensor. > > Tom, do you have any idea where it is on an '800? I tried the tech man > but couldn't find a mention. I'm presuming it's gonna be near the > processor? It is usually near the fan on the power supply, But I have never even seen an 800 > > Cheers, Mark. > -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Tue, 28 Aug 2007 20:57:42 -0400 From: Robert Deininger Subject: Re: DEC 3000/800 AXP boot problem Message-ID: In article <1188330350.273447.325990@o80g2000hse.googlegroups.com>, urbancamo wrote: > On 28 Aug, 16:50, "Tom Linden" wrote: > > Try cleaning the temperature sensor. > > Tom, do you have any idea where it is on an '800? I tried the tech man > but couldn't find a mention. I'm presuming it's gonna be near the > processor? I don't believe there is a temperature sensor in these systems. ------------------------------ Date: Tue, 28 Aug 2007 21:32:59 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: Hanging TNA ports. Message-ID: R.A.Omond wrote: > Jan-Erik Söderholm wrote: > >> [...snip...] >> >> I need a method to trace down those three "ref counts". Maybe >> I can run a SDA> SHO DEV on all procs to some file and try >> a few SEARCH'es... > > Here are the commands you're looking for: > Perfect ! > $ anal/sys > SDA> set out x.x > SDA> show proc/chann all > SDA> exit OK, got a 2.500+ block file. With a little more then 13.000 channels... > > And then search x.x for your TNA device. Yep, found it ! Assigned from a process. Now, tomorrow I'll check with the application guy why *that* process has *that* TNA port assigned... Now, if one *defenitely* want to "telnet delete" that TNA port, I have to find out a way to automate the above process. Doesn't seems to hard. Or, maybe better/safer, to simply report the process holding the port assigned... Regards, Jan-Erik. ------------------------------ Date: Tue, 28 Aug 2007 19:40:14 -0500 From: Ron Johnson Subject: Re: Itanium Port Question Message-ID: On 08/26/07 18:48, 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. You'd think that something as complex as a COBOL compiler would already align TOP-LEVEL. -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Tue, 28 Aug 2007 18:17:07 -0700 From: "Tom Linden" Subject: Re: Itanium Port Question Message-ID: On Tue, 28 Aug 2007 17:40:14 -0700, Ron Johnson wrote: > On 08/26/07 18:48, 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. > > You'd think that something as complex as a COBOL compiler would > already align TOP-LEVEL. > Alignment is a relatively recent restriction, at least in the severity of the performance penalties. Cobol and PL/I both had the ability to move data directly from disc or tape to Cobol Records and PL/I Structures. These were typically densely packed, meaning members were not naturally aligned. Because Alpha and Itanium didn't provide for unaligned access which didn't significantly deteriate performance, the design was deficient. This is essentially failure to provide backward compatibility and is incredibly stupid and a dismal failure on the part of VMS management. But then you have VAX->Alpha->Itanium. Your unaligned Cobol and PL/I code runs just fine on ALL IBM machines. -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Wed, 29 Aug 2007 01:59:37 GMT From: "John Vottero" Subject: Re: Itanium Port Question Message-ID: "Ron Johnson" wrote in message news:Of3Bi.69048$GO6.41099@newsfe21.lga... > On 08/26/07 18:48, 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. > > You'd think that something as complex as a COBOL compiler would > already align TOP-LEVEL. I'm not a compiler writer but, I don't think that example would create an alignment *fault* because the COBOL compiler would avoid it. The compiler would know that DATA-ITEM-2 isn't aligned so it would generate extra instructions to load a quadword and bit shift any time it referenced DATA-ITEM-2. That's a few extra instructions which usually isn't a big deal. You get an alignment fault when the compiler doesn't know the alignment at compile time so it generates instructions which assume aligned data then, if it turns out that the data isn't aligned, you get an alignment fault which gets trapped and handled at the cost of hundreds of instructions. So, I would say that Macro programs would tend to generate more alignment faults because there's usually more pointer arithmetic in macro programs than there is in COBOL programs. ------------------------------ Date: Tue, 28 Aug 2007 21:04:32 -0500 From: "Paul Raulerson" Subject: RE: Itanium Port Question Message-ID: <00d401c7e9e0$f0ec69c0$d2c53d40$@com> > -----Original Message----- > From: Ron Johnson [mailto:ron.l.johnson@cox.net] > Sent: Tuesday, August 28, 2007 7:40 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Itanium Port Question > > On 08/26/07 18:48, 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. > > You'd think that something as complex as a COBOL compiler would > already align TOP-LEVEL. > It did, really. Here's part of the generated code on an Alpha, which I am refraining from explaining because perhaps someone more familiar with Alpha will explain. (Please? :) Oddly enough, the generated CODE is exactly the same, which gives me reason to pause. I wonder if someone would post the generated code from an Itanium system please? Anyways- the complete listings are included below the two snippets below, for completeness. -Paul This is generated from: 1 IDENTIFICATION DIVISION. 2 PROGRAM-ID. TEST3. 3 4 ENVIRONMENT DIVISION. 5 6 DATA DIVISION. 7 WORKING-STORAGE SECTION. 8 01 TOP-LEVEL. 9 03 DATA-ITEM-1 PIC X(1). 10 03 DATA-ITEM-2 PIC S9(9) COMP. 11 12 PROCEDURE DIVISION. 13 START-PROGRAM. 14 MOVE 'Z' TO DATA-ITEM-1 15 MOVE -212 TO DATA-ITEM-2 16 STOP RUN .. [snip] .. 00000001 0078 .LONG X^1 ; .LONG 1 00000001 007C .LONG X^1 ; .LONG 1 00000000 0080 .LONG X^0 ; .LONG 0 00000004 0088 .ADDRESS TOP-LEVEL+4 00000001 0090 .LONG X^1 ; .LONG 1 00000004 0094 .LONG X^4 ; .LONG 4 This is generated from: 1 IDENTIFICATION DIVISION. 2 PROGRAM-ID. TEST2. 3 4 ENVIRONMENT DIVISION. 5 6 DATA DIVISION. 7 WORKING-STORAGE SECTION. 8 01 TOP-LEVEL. 9 03 DATA-ITEM-2 PIC S9(9) COMP. 10 03 DATA-ITEM-1 PIC X(1). 11 12 PROCEDURE DIVISION. 13 START-PROGRAM. 14 MOVE 'Z' TO DATA-ITEM-1 15 MOVE -212 TO DATA-ITEM-2 16 STOP RUN .. [snip] .. 00000004 007C .LONG X^4 ; .LONG 4 20 0080 .ASCII \ \ 00000004 0088 .ADDRESS TOP-LEVEL+4 00000001 0090 .LONG X^1 ; .LONG 1 00000001 0094 .LONG X^1 ; .LONG 1 ========== Cut here- complete listings included below ================ TEST2 Source Listing 28-AUG-2007 20:51:10 Compaq COBOL V2.8-1286 Page 1 0 28-AUG-2007 20:50:41 DKB100:[PAUL.SRC.COBOL]TEST2.COB;4 1 IDENTIFICATION DIVISION. 2 PROGRAM-ID. TEST2. 3 4 ENVIRONMENT DIVISION. 5 6 DATA DIVISION. 7 WORKING-STORAGE SECTION. 8 01 TOP-LEVEL. 9 03 DATA-ITEM-2 PIC S9(9) COMP. 10 03 DATA-ITEM-1 PIC X(1). 11 12 PROCEDURE DIVISION. 13 START-PROGRAM. 14 MOVE 'Z' TO DATA-ITEM-1 15 MOVE -212 TO DATA-ITEM-2 16 STOP RUN 17 . TEST2 Source Listing 28-AUG-2007 20:51:10 Compaq COBOL V2.8-1286 Page 2 0 Program Section Summary 28-AUG-2007 20:50:41 DKB100:[PAUL.SRC.COBOL]TEST2.COB;4 PROGRAM SECTION INDEX Index Name Bytes Alignment Attributes ----- ------------------------------- ---------- --------- ------------------------------------------------------------- 1 $CODE$ 92 OCTA 4 PIC CON REL LCL SHR EXE NORD NOWRT NOVEC 2 $LOCAL$ 152 OCTA 4 NOPIC CON REL LCL NOSHR NOEXE RD WRT NOVEC 3 $LINK$ 96 OCTA 4 NOPIC CON REL LCL NOSHR NOEXE RD NOWRT NOVEC 7 COB$NAMES_____2 48 OCTA 4 PIC CON REL LCL NOSHR NOEXE RD WRT NOVEC DIAGNOSTICS SUMMARY Informationals 1 (suppressed) ---------------------- Total 1 TEST2 Machine Code Listing 28-AUG-2007 20:51:10 Compaq COBOL V2.8-1286 Page 3 0 Source Listing 28-AUG-2007 20:50:41 DKB100:[PAUL.SRC.COBOL]TEST2.COB;4 .PSECT $CODE$, OCTA, PIC, CON, REL, LCL, SHR,- EXE, NORD, NOWRT 0000 TEST2:: A41B0030 0000 LDQ R0, 48(R27) 23DEFFD0 0004 LDA SP, -48(SP) A61B0038 0008 LDQ R16, 56(R27) 47E03419 000C MOV 1, R25 B75E0010 0010 STQ R26, 16(SP) B77E0000 0014 STQ R27, (SP) A75B0050 0018 LDQ R26, 80(R27) B7FE0008 001C STQ R31, 8(SP) B45E0018 0020 STQ R2, 24(SP) B7BE0020 0024 STQ FP, 32(SP) 63FF0000 0028 TRAPB 47FE041D 002C MOV SP, FP 47FB0402 0030 MOV R27, R2 B7E0FFC8 0034 STQ R31, -56(R0) A7620058 0038 LDQ R27, 88(R2) B3E00000 003C STL R31, (R0) 6B5A4000 0040 JSR R26, DCOB$CALLED ; R26, R26 A4220030 0044 LDQ R1, 48(R2) A7420040 0048 LDQ R26, 64(R2) ; 000016 47FF0419 004C CLR R25 A7620048 0050 LDQ R27, 72(R2) B401FFD0 0054 STQ R0, -48(R1) ; 000002 6B5A4000 0058 JSR R26, DCOB$STOP ; R26, R26 ; 000016 Routine Size: 92 bytes, Routine Base: $CODE$ + 0000 .PSECT $LOCAL$, OCTA, NOPIC, CON, REL, LCL,- NOSHR, NOEXE, RD, WRT TOP-LEVEL: 00000000 0000 .LONG X^0 ; .LONG 0 20 0004 .ASCII \ \ $$1: 54534554 0020 .ASCII \TEST2\ 32 0024 RETURN-CODE: 00000001 0028 .LONG X^1 ; .LONG 1 $$2: 00000000 0030 .ADDRESS $$3 00000000 0038 .QUAD X^0 ; .QUAD 0 00000000 003C 00000003 0040 .LONG X^3 ; .LONG 3 00000000 0044 .LONG X^0 ; .LONG 0 00000001 0048 .LONG X^1 ; .LONG 1 $$3: 00000001 0050 .LONG X^1 ; .LONG 1 00000000 0058 .ADDRESS RETURN-CODE 00000001 0060 .LONG X^1 ; .LONG 1 00000004 0064 .LONG X^4 ; .LONG 4 00000000 0068 .LONG X^0 ; .LONG 0 00000000 0070 .ADDRESS TOP-LEVEL 00000001 0078 .LONG X^1 ; .LONG 1 TEST2 Machine Code Listing 28-AUG-2007 20:51:10 Compaq COBOL V2.8-1286 Page 4 0 TEST2 28-AUG-2007 20:50:41 DKB100:[PAUL.SRC.COBOL]TEST2.COB;4 00000004 007C .LONG X^4 ; .LONG 4 20 0080 .ASCII \ \ 00000004 0088 .ADDRESS TOP-LEVEL+4 00000001 0090 .LONG X^1 ; .LONG 1 00000001 0094 .LONG X^1 ; .LONG 1 .PSECT $LINK$, OCTA, NOPIC, CON, REL, LCL,- NOSHR, NOEXE, RD, NOWRT 0000 ; Stack-Frame invocation descriptor Entry point: TEST2 Entry Length: 48 Static Handler: DCOB$SIGNAL_HANDLER Registers used: R0-R2, R16, R25-R26, R28-FP Registers saved: R2, FP Fixed Stack Size: 48 00000000 ; Handler data for DCOB$SIGNAL_HANDLER 00000000 00000000 00000000 00000048 0030 .ADDRESS $LOCAL$+72 00000000 0038 .ADDRESS TEST2 0040 .LINKAGE DCOB$STOP 0050 .LINKAGE DCOB$CALLED .PSECT COB$NAMES_____2, OCTA, PIC, CON, REL,- LCL, NOSHR, NOEXE, RD, WRT $$4: 00000000 0000 .ADDRESS $$1 00000000 0008 .ADDRESS TEST2 00000000 0010 .QUAD X^0 ; .QUAD 0 00000000 0014 00000000 0018 .ADDRESS $$2 00000005 0020 .LONG X^5 ; .LONG 5 00000000 0024 .LONG X^0 ; .LONG 0 00000000 0028 .LONG X^0 ; .LONG 0 00000000 002C .LONG X^0 ; .LONG 0 Source Listing 28-AUG-2007 20:51:10 Compaq COBOL V2.8-1286 Page 5 Compilation Summary 28-AUG-2007 20:50:41 DKB100:[PAUL.SRC.COBOL]TEST2.COB;4 COMMAND QUALIFIERS COBOL /NOALIGNMENT /GRANULARITY = QUAD /NOANALYSIS_DATA /NOINCLUDE /NOANSI_FORMAT /LIST /ARCHITECTURE = GENERIC /MACHINE_CODE /ARITHMETIC = NATIVE /NOMAP /NOAUDIT /MATH_INTERMEDIATE = FLOAT /CHECK = (NOPERFORM, NOBOUNDS, NODECIMAL, NODUPLICATE_KEYS) /NATIONALITY = US /NOCONDITIONALS /OBJECT /NOCONVERT = LEADING_BLANKS /OPTIMIZE = (LEVEL=4,TUNE=GENERIC) /NOCOPY_LIST /RESERVED_WORDS = (XOPEN, NOFOREIGN_EXTENSIONS, NO200X) /NOCROSS_REFERENCE /NOSEPARATE_COMPILATION /DEBUG = (NOSYMBOLS, TRACEBACK) /NOSEQUENCE_CHECK /NODEPENDENCY_DATA /STANDARD = (NOXOPEN, NOSYNTAX, NOV3, 85, NOMIA) /NODIAGNOSTICS /NOTIE /NODISPLAY_FORMATTED /NOTRUNCATE /NOFIPS /VFC /NOFLAGGER /WARNINGS = (NOINFORMATION, OTHER) /FLOAT = D_FLOAT COMPILATION STATISTICS CPU time: 0.15 seconds Elapsed time: 0.28 seconds Pagefaults: 681 I/O Count: 29 Source lines: 17 6800 lines per CPU minute. ---- ---- --- TEST3 Source Listing 28-AUG-2007 20:51:23 Compaq COBOL V2.8-1286 Page 1 0 28-AUG-2007 20:50:25 DKB100:[PAUL.SRC.COBOL]TEST3.COB;4 1 IDENTIFICATION DIVISION. 2 PROGRAM-ID. TEST3. 3 4 ENVIRONMENT DIVISION. 5 6 DATA DIVISION. 7 WORKING-STORAGE SECTION. 8 01 TOP-LEVEL. 9 03 DATA-ITEM-1 PIC X(1). 10 03 DATA-ITEM-2 PIC S9(9) COMP. 11 12 PROCEDURE DIVISION. 13 START-PROGRAM. 14 MOVE 'Z' TO DATA-ITEM-1 15 MOVE -212 TO DATA-ITEM-2 16 STOP RUN 17 . TEST3 Source Listing 28-AUG-2007 20:51:23 Compaq COBOL V2.8-1286 Page 2 0 Program Section Summary 28-AUG-2007 20:50:25 DKB100:[PAUL.SRC.COBOL]TEST3.COB;4 PROGRAM SECTION INDEX Index Name Bytes Alignment Attributes ----- ------------------------------- ---------- --------- ------------------------------------------------------------- 1 $CODE$ 92 OCTA 4 PIC CON REL LCL SHR EXE NORD NOWRT NOVEC 2 $LOCAL$ 152 OCTA 4 NOPIC CON REL LCL NOSHR NOEXE RD WRT NOVEC 3 $LINK$ 96 OCTA 4 NOPIC CON REL LCL NOSHR NOEXE RD NOWRT NOVEC 7 COB$NAMES_____2 48 OCTA 4 PIC CON REL LCL NOSHR NOEXE RD WRT NOVEC DIAGNOSTICS SUMMARY Informationals 1 (suppressed) ---------------------- Total 1 TEST3 Machine Code Listing 28-AUG-2007 20:51:23 Compaq COBOL V2.8-1286 Page 3 0 Source Listing 28-AUG-2007 20:50:25 DKB100:[PAUL.SRC.COBOL]TEST3.COB;4 .PSECT $CODE$, OCTA, PIC, CON, REL, LCL, SHR,- EXE, NORD, NOWRT 0000 TEST3:: A41B0030 0000 LDQ R0, 48(R27) 23DEFFD0 0004 LDA SP, -48(SP) A61B0038 0008 LDQ R16, 56(R27) 47E03419 000C MOV 1, R25 B75E0010 0010 STQ R26, 16(SP) B77E0000 0014 STQ R27, (SP) A75B0050 0018 LDQ R26, 80(R27) B7FE0008 001C STQ R31, 8(SP) B45E0018 0020 STQ R2, 24(SP) B7BE0020 0024 STQ FP, 32(SP) 63FF0000 0028 TRAPB 47FE041D 002C MOV SP, FP 47FB0402 0030 MOV R27, R2 B7E0FFC8 0034 STQ R31, -56(R0) A7620058 0038 LDQ R27, 88(R2) B3E00000 003C STL R31, (R0) 6B5A4000 0040 JSR R26, DCOB$CALLED ; R26, R26 A4220030 0044 LDQ R1, 48(R2) A7420040 0048 LDQ R26, 64(R2) ; 000016 47FF0419 004C CLR R25 A7620048 0050 LDQ R27, 72(R2) B401FFD0 0054 STQ R0, -48(R1) ; 000002 6B5A4000 0058 JSR R26, DCOB$STOP ; R26, R26 ; 000016 Routine Size: 92 bytes, Routine Base: $CODE$ + 0000 .PSECT $LOCAL$, OCTA, NOPIC, CON, REL, LCL,- NOSHR, NOEXE, RD, WRT TOP-LEVEL: 20 0000 .ASCII \ \ 00000000 0004 .LONG X^0 ; .LONG 0 $$1: 54534554 0020 .ASCII \TEST3\ 33 0024 RETURN-CODE: 00000001 0028 .LONG X^1 ; .LONG 1 $$2: 00000000 0030 .ADDRESS $$3 00000000 0038 .QUAD X^0 ; .QUAD 0 00000000 003C 00000003 0040 .LONG X^3 ; .LONG 3 00000000 0044 .LONG X^0 ; .LONG 0 00000001 0048 .LONG X^1 ; .LONG 1 $$3: 00000001 0050 .LONG X^1 ; .LONG 1 00000000 0058 .ADDRESS RETURN-CODE 00000001 0060 .LONG X^1 ; .LONG 1 00000004 0064 .LONG X^4 ; .LONG 4 20 0068 .ASCII \ \ 00000000 0070 .ADDRESS TOP-LEVEL TEST3 Machine Code Listing 28-AUG-2007 20:51:23 Compaq COBOL V2.8-1286 Page 4 0 TEST3 28-AUG-2007 20:50:25 DKB100:[PAUL.SRC.COBOL]TEST3.COB;4 00000001 0078 .LONG X^1 ; .LONG 1 00000001 007C .LONG X^1 ; .LONG 1 00000000 0080 .LONG X^0 ; .LONG 0 00000004 0088 .ADDRESS TOP-LEVEL+4 00000001 0090 .LONG X^1 ; .LONG 1 00000004 0094 .LONG X^4 ; .LONG 4 .PSECT $LINK$, OCTA, NOPIC, CON, REL, LCL,- NOSHR, NOEXE, RD, NOWRT 0000 ; Stack-Frame invocation descriptor Entry point: TEST3 Entry Length: 48 Static Handler: DCOB$SIGNAL_HANDLER Registers used: R0-R2, R16, R25-R26, R28-FP Registers saved: R2, FP Fixed Stack Size: 48 00000000 ; Handler data for DCOB$SIGNAL_HANDLER 00000000 00000000 00000000 00000048 0030 .ADDRESS $LOCAL$+72 00000000 0038 .ADDRESS TEST3 0040 .LINKAGE DCOB$STOP 0050 .LINKAGE DCOB$CALLED .PSECT COB$NAMES_____2, OCTA, PIC, CON, REL,- LCL, NOSHR, NOEXE, RD, WRT $$4: 00000000 0000 .ADDRESS $$1 00000000 0008 .ADDRESS TEST3 00000000 0010 .QUAD X^0 ; .QUAD 0 00000000 0014 00000000 0018 .ADDRESS $$2 00000005 0020 .LONG X^5 ; .LONG 5 00000000 0024 .LONG X^0 ; .LONG 0 00000000 0028 .LONG X^0 ; .LONG 0 00000000 002C .LONG X^0 ; .LONG 0 Source Listing 28-AUG-2007 20:51:23 Compaq COBOL V2.8-1286 Page 5 Compilation Summary 28-AUG-2007 20:50:25 DKB100:[PAUL.SRC.COBOL]TEST3.COB;4 COMMAND QUALIFIERS COBOL /ALIGNMENT /GRANULARITY = QUAD /NOANALYSIS_DATA /NOINCLUDE /NOANSI_FORMAT /LIST /ARCHITECTURE = GENERIC /MACHINE_CODE /ARITHMETIC = NATIVE /NOMAP /NOAUDIT /MATH_INTERMEDIATE = FLOAT /CHECK = (NOPERFORM, NOBOUNDS, NODECIMAL, NODUPLICATE_KEYS) /NATIONALITY = US /NOCONDITIONALS /OBJECT /NOCONVERT = LEADING_BLANKS /OPTIMIZE = (LEVEL=4,TUNE=GENERIC) /NOCOPY_LIST /RESERVED_WORDS = (XOPEN, NOFOREIGN_EXTENSIONS, NO200X) /NOCROSS_REFERENCE /NOSEPARATE_COMPILATION /DEBUG = (NOSYMBOLS, TRACEBACK) /NOSEQUENCE_CHECK /NODEPENDENCY_DATA /STANDARD = (NOXOPEN, NOSYNTAX, NOV3, 85, NOMIA) /NODIAGNOSTICS /NOTIE /NODISPLAY_FORMATTED /NOTRUNCATE /NOFIPS /VFC /NOFLAGGER /WARNINGS = (NOINFORMATION, OTHER) /FLOAT = D_FLOAT COMPILATION STATISTICS CPU time: 0.19 seconds Elapsed time: 0.30 seconds Pagefaults: 664 I/O Count: 30 Source lines: 17 5368 lines per CPU minute. ------------------------------ Date: Wed, 29 Aug 2007 03:40:00 -0000 From: Hein RMS van den Heuvel Subject: Re: Itanium Port Question Message-ID: <1188358800.478369.44400@50g2000hsm.googlegroups.com> On Aug 28, 10:04 pm, "Paul Raulerson" wrote: > > -----Original Message----- > > From: Ron Johnson [mailto:ron.l.john...@cox.net] : > It did, really. Here's part of the generated code on an Alpha, which I am > refraining from explaining because perhaps someone more familiar with Alp= ha > will explain. (Please? :) Oddly enough, the generated CODE is exactly t= he > same, which gives me reason to pause. It should. Use the pause to study the code. There is NO code generated for line 14,15. It's optimized away. All you have is program prologue + epilogue. Toss in a line like: 16 call "test" using DATA-ITEM-1, DATA-ITEM-2 Now you'll see... line 15 exploding into 10 instructions to do the unalignment protection. : LDQ_U R18, -4(R3) ; 000015 LDQ_U R17, -7(R3) MOV -212, R1 LDA R16, -7(R3) INSLH R1, R16, R20 INSLL R1, R16, R19 LDQ R23, 48(R2) ; 000002 LDQ R26, 96(R2) ; 000016 LDQ R27, 104(R2) MOV 2, R25 MSKLH R18, R16, R18 ; 000015 MSKLL R17, R16, R17 LDA R16, -8(R3) ; 000016 BIS R18, R20, R18 ; 000015 BIS R17, R19, R17 STQ_U R18, -4(R3) STQ_U R17, -7(R3) Flip the two fields around to natually align them, or tell the compiler to go ahead and alignt and you''l get 2 instuctions: : MOV -212, R1 ; 000015 : STL R1, -8(R3) ; 000015 : So you will NOT get a run time aligment faults in either case. Personally I would appreciate an informational at compile that that this is dumb coding, but that's not available. ps 1... There is rally no strong reason to make a primary key be the first field in the record, if that creates any trouble at all. RMS will store the primary key as the first bytes for quicker comparesm and re-assemble if the records is select later anyway. ps 2... Rounding records (for indexed files) to be a 'nice' 512 bytes or some such make NO sense at all, as RMS has odd sized headers, and it likely to compress the data. Cheers, Hein. I wonder if someone would post the > generated code from an Itanium system please? > > Anyways- the complete listings are included below the two snippets below, > for completeness. > -Paul > > This is generated from: > 1 IDENTIFICATION DIVISION. > 2 PROGRAM-ID. TEST3. > 3 > 4 ENVIRONMENT DIVISION. > 5 > 6 DATA DIVISION. > 7 WORKING-STORAGE SECTION. > 8 01 TOP-LEVEL. > 9 03 DATA-ITEM-1 PIC X(1). > 10 03 DATA-ITEM-2 PIC S9(9) COMP. > 11 > 12 PROCEDURE DIVISION. > 13 START-PROGRAM. > 14 MOVE 'Z' TO DATA-ITEM-1 > 15 MOVE -212 TO DATA-ITEM-2 > 16 STOP RUN > .. > [snip] > .. > > 00000001 0078 .LONG X^1 ; .LONG 1 > 00000001 007C .LONG X^1 ; .LONG 1 > 00000000 0080 .LONG X^0 ; .LONG 0 > 00000004 0088 .ADDRESS TOP-LEVEL+4 > 00000001 0090 .LONG X^1 ; .LONG 1 > 00000004 0094 .LONG X^4 ; .LONG 4 > > This is generated from: > 1 IDENTIFICATION DIVISION. > 2 PROGRAM-ID. TEST2. > 3 > 4 ENVIRONMENT DIVISION. > 5 > 6 DATA DIVISION. > 7 WORKING-STORAGE SECTION. > 8 01 TOP-LEVEL. > 9 03 DATA-ITEM-2 PIC S9(9) COMP. > 10 03 DATA-ITEM-1 PIC X(1). > 11 > 12 PROCEDURE DIVISION. > 13 START-PROGRAM. > 14 MOVE 'Z' TO DATA-ITEM-1 > 15 MOVE -212 TO DATA-ITEM-2 > 16 STOP RUN > .. > [snip] > .. > > 00000004 007C .LONG X^4 ; .LONG 4 > 20 0080 .ASCII \ \ > > 00000004 0088 .ADDRESS TOP-LEVEL+4 > 00000001 0090 .LONG X^1 ; .LONG 1 > 00000001 0094 .LONG X^1 ; .LONG 1 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Cut here- complete listings included below= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > TEST2 Source Listing 28-AUG-20= 07 > 20:51:10 Compaq COBOL V2.8-1286 Page 1 > 0 28-AUG-20= 07 > 20:50:41 DKB100:[PAUL.SRC.COBOL]TEST2.COB;4 > > 1 IDENTIFICATION DIVISION. > 2 PROGRAM-ID. TEST2. > 3 > 4 ENVIRONMENT DIVISION. > 5 > 6 DATA DIVISION. > 7 WORKING-STORAGE SECTION. > 8 01 TOP-LEVEL. > 9 03 DATA-ITEM-2 PIC S9(9) COMP. > 10 03 DATA-ITEM-1 PIC X(1). > 11 > 12 PROCEDURE DIVISION. > 13 START-PROGRAM. > 14 MOVE 'Z' TO DATA-ITEM-1 > 15 MOVE -212 TO DATA-ITEM-2 > 16 STOP RUN > 17 . > > TEST2 Source Listing 28-AUG-20= 07 > 20:51:10 Compaq COBOL V2.8-1286 Page 2 > 0 Program Section Summary 28-AUG-20= 07 > 20:50:41 DKB100:[PAUL.SRC.COBOL]TEST2.COB;4 > > PROGRAM SECTION INDEX > > Index Name Bytes Alignment Attribu= tes > ----- ------------------------------- ---------- --------- > ------------------------------------------------------------- > 1 $CODE$ 92 OCTA 4 PIC > CON REL LCL SHR EXE NORD NOWRT NOVEC =20 > 2 $LOCAL$ 152 OCTA 4 NOPIC > CON REL LCL NOSHR NOEXE RD WRT NOVEC =20 > 3 $LINK$ 96 OCTA 4 NOPIC > CON REL LCL NOSHR NOEXE RD NOWRT NOVEC =20 > 7 COB$NAMES_____2 48 OCTA 4 PIC > CON REL LCL NOSHR NOEXE RD WRT NOVEC =20 > > DIAGNOSTICS SUMMARY > > Informationals 1 (suppressed) > ---------------------- > Total 1 > > TEST2 Machine Code Listing 28-AUG-20= 07 > 20:51:10 Compaq COBOL V2.8-1286 Page 3 > 0 Source Listing 28-AUG-20= 07 > 20:50:41 DKB100:[PAUL.SRC.COBOL]TEST2.COB;4 > > .PSECT $CODE$, OCTA, PIC, CON, REL, LCL, > SHR,- > EXE, NORD, NOWRT > 0000 TEST2:: > A41B0030 0000 LDQ R0, 48(R27) > 23DEFFD0 0004 LDA SP, -48(SP) > A61B0038 0008 LDQ R16, 56(R27) > 47E03419 000C MOV 1, R25 > B75E0010 0010 STQ R26, 16(SP) > B77E0000 0014 STQ R27, (SP) > A75B0050 0018 LDQ R26, 80(R27) > B7FE0008 001C STQ R31, 8(SP) > B45E0018 0020 STQ R2, 24(SP) > B7BE0020 0024 STQ FP, 32(SP) > 63FF0000 0028 TRAPB > 47FE041D 002C MOV SP, FP > 47FB0402 0030 MOV R27, R2 > B7E0FFC8 0034 STQ R31, -56(R0) > A7620058 0038 LDQ R27, 88(R2) > B3E00000 003C STL R31, (R0) > 6B5A4000 0040 JSR R26, DCOB$CALLED > ; R26, R26 > A4220030 0044 LDQ R1, 48(R2) > A7420040 0048 LDQ R26, 64(R2) > ; 000016 > 47FF0419 004C CLR R25 > A7620048 0050 LDQ R27, 72(R2) > B401FFD0 0054 STQ R0, -48(R1) > ; 000002 > 6B5A4000 0058 JSR R26, DCOB$STOP > ; R26, R26 ; 000016 > > Routine Size: 92 bytes, Routine Base: $CODE$ + 0000 > > .PSECT $LOCAL$, OCTA, NOPIC, CON, REL, > LCL,- > NOSHR, NOEXE, RD, WRT > TOP-LEVEL: > 00000000 0000 .LONG X^0 ; .LONG 0 > 20 0004 .ASCII \ \ > > $$1: > 54534554 0020 .ASCII \TEST2\ > 32 0024 > > RETURN-CODE: > 00000001 0028 .LONG X^1 ; .LONG 1 > $$2: > 00000000 0030 .ADDRESS $$3 > 00000000 0038 .QUAD X^0 ; .QUAD 0 > 00000000 003C > 00000003 0040 .LONG X^3 ; .LONG 3 > 00000000 0044 .LONG X^0 ; .LONG 0 > 00000001 0048 .LONG X^1 ; .LONG 1 > $$3: > 00000001 0050 .LONG X^1 ; .LONG 1 > 00000000 0058 .ADDRESS RETURN-CODE > 00000001 0060 .LONG X^1 ; .LONG 1 > 00000004 0064 .LONG X^4 ; .LONG 4 > 00000000 0068 .LONG X^0 ; .LONG 0 > 00000000 0070 .ADDRESS TOP-LEVEL > 00000001 0078 .LONG X^1 ; .LONG 1 > > TEST2 Machine Code Listing 28-AUG-20= 07 > 20:51:10 Compaq COBOL V2.8-1286 Page 4 > 0 TEST2 28-AUG-20= 07 > 20:50:41 DKB100:[PAUL.SRC.COBOL]TEST2.COB;4 > > 00000004 007C .LONG X^4 ; .LONG 4 > 20 0080 .ASCII \ \ > > 00000004 0088 .ADDRESS TOP-LEVEL+4 > 00000001 0090 .LONG X^1 ; .LONG 1 > 00000001 0094 .LONG X^1 ; .LONG 1 > > .PSECT $LINK$, OCTA, NOPIC, CON, REL, LC= L,- > NOSHR, NOEXE, RD, NOWRT > > 0000 ; Stack-Frame invocation descriptor > Entry point: TEST2 > Entry Length: 48 > Static Handler: DCOB$SIGNAL_HANDLER > Registers used: R0-R2, R16, R25-R2= 6, > R28-FP > Registers saved: R2, FP > Fixed Stack Size: 48 > 00000000 ; Handler data for DCOB$SIGNAL_HANDLER > 00000000 > 00000000 > 00000000 > > 00000048 0030 .ADDRESS $LOCAL$+72 > 00000000 0038 .ADDRESS TEST2 > 0040 .LINKAGE DCOB$STOP > 0050 .LINKAGE DCOB$CALLED > > .PSECT COB$NAMES_____2, OCTA, PIC, CON, > REL,- > LCL, NOSHR, NOEXE, RD, WRT > $$4: > 00000000 0000 .ADDRESS $$1 > 00000000 0008 .ADDRESS TEST2 > 00000000 0010 .QUAD X^0 ; .QUAD 0 > 00000000 0014 > 00000000 0018 .ADDRESS $$2 > 00000005 0020 .LONG X^5 ; .LONG 5 > 00000000 0024 .LONG X^0 ; .LONG 0 > 00000000 0028 .LONG X^0 ; .LONG 0 > 00000000 002C .LONG X^0 ; .LONG 0 > > Source Listing 28-AUG-20= 07 > 20:51:10 Compaq COBOL V2.8-1286 Page 5 > Compilation Summary 28-AUG-20= 07 > 20:50:41 DKB100:[PAUL.SRC.COBOL]TEST2.COB;4 > > COMMAND QUALIFIERS > > COBOL > > /NOALIGNMENT > /GRANULARITY =3D QUAD =20 > /NOANALYSIS_DATA > /NOINCLUDE =20 > /NOANSI_FORMAT /LIST > > /ARCHITECTURE =3D GENERIC > /MACHINE_CODE =20 > /ARITHMETIC =3D NATIVE /N= OMAP > > /NOAUDIT > /MATH_INTERMEDIATE =3D FLOAT =20 > /CHECK =3D (NOPERFORM, NOBOUNDS, NODECIMAL, NODUPLICATE_KEYS) > /NATIONALITY =3D US =20 > /NOCONDITIONALS /OBJ= ECT > > /NOCONVERT =3D LEADING_BLANKS > /OPTIMIZE =3D (LEVEL=3D4,TUNE=3DGENERIC) =20 > /NOCOPY_LIST > /RESERVED_WORDS =3D (XOPEN, NOFOREIGN_EXTENSIONS, NO200X) =20 > /NOCROSS_REFERENCE > /NOSEPARATE_COMPILATION =20 > /DEBUG =3D (NOSYMBOLS, TRACEBACK) > /NOSEQUENCE_CHECK =20 > /NODEPENDENCY_DATA > /STANDARD =3D (NOXOPEN, NOSYNTAX, NOV3, 85, NOMIA) =20 > /NODIAGNOSTICS /NOT= IE > > /NODISPLAY_FORMATTED > /NOTRUNCATE =20 > ... > > read more =BB- Hide quoted text - > > - Show quoted text - ------------------------------ Date: Tue, 28 Aug 2007 22:58:56 -0500 From: "Paul Raulerson" Subject: RE: Itanium Port Question Message-ID: <001201c7e9f0$ec210bc0$c4632340$@com> > -----Original Message----- > From: Hein RMS van den Heuvel [mailto:heinvandenheuvel@gmail.com] > Sent: Tuesday, August 28, 2007 10:40 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Itanium Port Question > > On Aug 28, 10:04 pm, "Paul Raulerson" wrote: > > > -----Original Message----- > > > From: Ron Johnson [mailto:ron.l.john...@cox.net] > : > > It did, really. Here's part of the generated code on an Alpha, which > I am > > refraining from explaining because perhaps someone more familiar with > Alpha > > will explain. (Please? :) Oddly enough, the generated CODE is > exactly the > > same, which gives me reason to pause. > > It should. Use the pause to study the code. > There is NO code generated for line 14,15. > It's optimized away. > All you have is program prologue + epilogue. > Yeah, I rather thought that is what it did; I wasn't sure though, which is why I asked. :) Thanks for explaining that much more clearly. It did show the alignment generation of the data items, which is what I quoted up top. > Toss in a line like: > > 16 call "test" using DATA-ITEM-1, DATA-ITEM-2 > > Now you'll see... line 15 exploding into 10 instructions > to do the unalignment protection. > > : > LDQ_U R18, -4(R3) ; 000015 > LDQ_U R17, -7(R3) > MOV -212, R1 > LDA R16, -7(R3) > INSLH R1, R16, R20 > INSLL R1, R16, R19 > LDQ R23, 48(R2) ; 000002 > LDQ R26, 96(R2) ; 000016 > LDQ R27, 104(R2) > MOV 2, R25 > MSKLH R18, R16, R18 ; 000015 > MSKLL R17, R16, R17 > LDA R16, -8(R3) ; 000016 > BIS R18, R20, R18 ; 000015 > BIS R17, R19, R17 > STQ_U R18, -4(R3) > STQ_U R17, -7(R3) > > Flip the two fields around to natually align them, or tell the > compiler to go ahead and alignt and you''l get 2 instuctions: > : > MOV -212, R1 ; 000015 > : > STL R1, -8(R3) ; 000015 > : > > So you will NOT get a run time aligment faults in either case. > > Personally I would appreciate an informational at compile that that > this is dumb coding, but that's not available. > Ah, that is much like what I expected to see. Much better example. > > ps 1... There is rally no strong reason to make a primary key be the > first field in the record, if that creates any trouble at all. RMS > will store the primary key as the first bytes for quicker comparesm > and re-assemble if the records is select later anyway. Ugh- I usually find it good practice to put the keys at the first of the record, but then again, I deal a lot with variable length records. I expect RMS knows what it is doing, but I don't like the idea of it rearranging data for me. ;) > ps 2... Rounding records (for indexed files) to be a 'nice' 512 bytes > or some such make NO sense at all, as RMS has odd sized headers, and > it likely to compress the data. Interesting; doesn't it tend to cause a bit of a performance hit, especially in high transaction environments though? -Paul > > Cheers, > Hein. > > > > > > > > I wonder if someone would post the > > generated code from an Itanium system please? > > > > Anyways- the complete listings are included below the two snippets > below, > > for completeness. > > -Paul > > > > This is generated from: > > 1 IDENTIFICATION DIVISION. > > 2 PROGRAM-ID. TEST3. > > 3 > > 4 ENVIRONMENT DIVISION. > > 5 > > 6 DATA DIVISION. > > 7 WORKING-STORAGE SECTION. > > 8 01 TOP-LEVEL. > > 9 03 DATA-ITEM-1 PIC X(1). > > 10 03 DATA-ITEM-2 PIC S9(9) COMP. > > 11 > > 12 PROCEDURE DIVISION. > > 13 START-PROGRAM. > > 14 MOVE 'Z' TO DATA-ITEM-1 > > 15 MOVE -212 TO DATA-ITEM-2 > > 16 STOP RUN > > .. > > [snip] > > .. > > > > 00000001 0078 .LONG X^1 ; .LONG 1 > > 00000001 007C .LONG X^1 ; .LONG 1 > > 00000000 0080 .LONG X^0 ; .LONG 0 > > 00000004 0088 .ADDRESS TOP-LEVEL+4 > > 00000001 0090 .LONG X^1 ; .LONG 1 > > 00000004 0094 .LONG X^4 ; .LONG 4 > > > > This is generated from: > > 1 IDENTIFICATION DIVISION. > > 2 PROGRAM-ID. TEST2. > > 3 > > 4 ENVIRONMENT DIVISION. > > 5 > > 6 DATA DIVISION. > > 7 WORKING-STORAGE SECTION. > > 8 01 TOP-LEVEL. > > 9 03 DATA-ITEM-2 PIC S9(9) COMP. > > 10 03 DATA-ITEM-1 PIC X(1). > > 11 > > 12 PROCEDURE DIVISION. > > 13 START-PROGRAM. > > 14 MOVE 'Z' TO DATA-ITEM-1 > > 15 MOVE -212 TO DATA-ITEM-2 > > 16 STOP RUN > > .. > > [snip] > > .. > > > > 00000004 007C .LONG X^4 ; .LONG 4 > > 20 0080 .ASCII \ \ > > > > 00000004 0088 .ADDRESS TOP-LEVEL+4 > > 00000001 0090 .LONG X^1 ; .LONG 1 > > 00000001 0094 .LONG X^1 ; .LONG 1 > > > > ========== Cut here- complete listings included below > ================ > > > > TEST2 Source Listing 28- > AUG-2007 > > 20:51:10 Compaq COBOL V2.8-1286 Page 1 > > 0 28- > AUG-2007 > > 20:50:41 DKB100:[PAUL.SRC.COBOL]TEST2.COB;4 > > > > 1 IDENTIFICATION DIVISION. > > 2 PROGRAM-ID. TEST2. > > 3 > > 4 ENVIRONMENT DIVISION. > > 5 > > 6 DATA DIVISION. > > 7 WORKING-STORAGE SECTION. > > 8 01 TOP-LEVEL. > > 9 03 DATA-ITEM-2 PIC S9(9) COMP. > > 10 03 DATA-ITEM-1 PIC X(1). > > 11 > > 12 PROCEDURE DIVISION. > > 13 START-PROGRAM. > > 14 MOVE 'Z' TO DATA-ITEM-1 > > 15 MOVE -212 TO DATA-ITEM-2 > > 16 STOP RUN > > 17 . > > > > TEST2 Source Listing 28- > AUG-2007 > > 20:51:10 Compaq COBOL V2.8-1286 Page 2 > > 0 Program Section Summary 28- > AUG-2007 > > 20:50:41 DKB100:[PAUL.SRC.COBOL]TEST2.COB;4 > > > > PROGRAM SECTION INDEX > > > > Index Name Bytes Alignment > Attributes > > ----- ------------------------------- ---------- --------- > > ------------------------------------------------------------- > > 1 $CODE$ 92 OCTA 4 > PIC > > CON REL LCL SHR EXE NORD NOWRT NOVEC > > 2 $LOCAL$ 152 OCTA 4 > NOPIC > > CON REL LCL NOSHR NOEXE RD WRT NOVEC > > 3 $LINK$ 96 OCTA 4 > NOPIC > > CON REL LCL NOSHR NOEXE RD NOWRT NOVEC > > 7 COB$NAMES_____2 48 OCTA 4 > PIC > > CON REL LCL NOSHR NOEXE RD WRT NOVEC > > > > DIAGNOSTICS SUMMARY > > > > Informationals 1 (suppressed) > > ---------------------- > > Total 1 > > > > TEST2 Machine Code Listing 28- > AUG-2007 > > 20:51:10 Compaq COBOL V2.8-1286 Page 3 > > 0 Source Listing 28- > AUG-2007 > > 20:50:41 DKB100:[PAUL.SRC.COBOL]TEST2.COB;4 > > > > .PSECT $CODE$, OCTA, PIC, CON, REL, > LCL, > > SHR,- > > EXE, NORD, NOWRT > > 0000 TEST2:: > > A41B0030 0000 LDQ R0, 48(R27) > > 23DEFFD0 0004 LDA SP, -48(SP) > > A61B0038 0008 LDQ R16, 56(R27) > > 47E03419 000C MOV 1, R25 > > B75E0010 0010 STQ R26, 16(SP) > > B77E0000 0014 STQ R27, (SP) > > A75B0050 0018 LDQ R26, 80(R27) > > B7FE0008 001C STQ R31, 8(SP) > > B45E0018 0020 STQ R2, 24(SP) > > B7BE0020 0024 STQ FP, 32(SP) > > 63FF0000 0028 TRAPB > > 47FE041D 002C MOV SP, FP > > 47FB0402 0030 MOV R27, R2 > > B7E0FFC8 0034 STQ R31, -56(R0) > > A7620058 0038 LDQ R27, 88(R2) > > B3E00000 003C STL R31, (R0) > > 6B5A4000 0040 JSR R26, DCOB$CALLED > > ; R26, R26 > > A4220030 0044 LDQ R1, 48(R2) > > A7420040 0048 LDQ R26, 64(R2) > > ; 000016 > > 47FF0419 004C CLR R25 > > A7620048 0050 LDQ R27, 72(R2) > > B401FFD0 0054 STQ R0, -48(R1) > > ; 000002 > > 6B5A4000 0058 JSR R26, DCOB$STOP > > ; R26, R26 ; 000016 > > > > Routine Size: 92 bytes, Routine Base: $CODE$ + 0000 > > > > .PSECT $LOCAL$, OCTA, NOPIC, CON, > REL, > > LCL,- > > NOSHR, NOEXE, RD, WRT > > TOP-LEVEL: > > 00000000 0000 .LONG X^0 ; .LONG 0 > > 20 0004 .ASCII \ \ > > > > $$1: > > 54534554 0020 .ASCII \TEST2\ > > 32 0024 > > > > RETURN-CODE: > > 00000001 0028 .LONG X^1 ; .LONG 1 > > $$2: > > 00000000 0030 .ADDRESS $$3 > > 00000000 0038 .QUAD X^0 ; .QUAD 0 > > 00000000 003C > > 00000003 0040 .LONG X^3 ; .LONG 3 > > 00000000 0044 .LONG X^0 ; .LONG 0 > > 00000001 0048 .LONG X^1 ; .LONG 1 > > $$3: > > 00000001 0050 .LONG X^1 ; .LONG 1 > > 00000000 0058 .ADDRESS RETURN-CODE > > 00000001 0060 .LONG X^1 ; .LONG 1 > > 00000004 0064 .LONG X^4 ; .LONG 4 > > 00000000 0068 .LONG X^0 ; .LONG 0 > > 00000000 0070 .ADDRESS TOP-LEVEL > > 00000001 0078 .LONG X^1 ; .LONG 1 > > > > TEST2 Machine Code Listing 28- > AUG-2007 > > 20:51:10 Compaq COBOL V2.8-1286 Page 4 > > 0 TEST2 28- > AUG-2007 > > 20:50:41 DKB100:[PAUL.SRC.COBOL]TEST2.COB;4 > > > > 00000004 007C .LONG X^4 ; .LONG 4 > > 20 0080 .ASCII \ \ > > > > 00000004 0088 .ADDRESS TOP-LEVEL+4 > > 00000001 0090 .LONG X^1 ; .LONG 1 > > 00000001 0094 .LONG X^1 ; .LONG 1 > > > > .PSECT $LINK$, OCTA, NOPIC, CON, > REL, LCL,- > > NOSHR, NOEXE, RD, NOWRT > > > > 0000 ; Stack-Frame invocation descriptor > > Entry point: TEST2 > > Entry Length: 48 > > Static Handler: > DCOB$SIGNAL_HANDLER > > Registers used: R0-R2, R16, > R25-R26, > > R28-FP > > Registers saved: R2, FP > > Fixed Stack Size: 48 > > 00000000 ; Handler data for > DCOB$SIGNAL_HANDLER > > 00000000 > > 00000000 > > 00000000 > > > > 00000048 0030 .ADDRESS $LOCAL$+72 > > 00000000 0038 .ADDRESS TEST2 > > 0040 .LINKAGE DCOB$STOP > > 0050 .LINKAGE DCOB$CALLED > > > > .PSECT COB$NAMES_____2, OCTA, PIC, > CON, > > REL,- > > LCL, NOSHR, NOEXE, RD, WRT > > $$4: > > 00000000 0000 .ADDRESS $$1 > > 00000000 0008 .ADDRESS TEST2 > > 00000000 0010 .QUAD X^0 ; .QUAD 0 > > 00000000 0014 > > 00000000 0018 .ADDRESS $$2 > > 00000005 0020 .LONG X^5 ; .LONG 5 > > 00000000 0024 .LONG X^0 ; .LONG 0 > > 00000000 0028 .LONG X^0 ; .LONG 0 > > 00000000 002C .LONG X^0 ; .LONG 0 > > > > Source Listing 28- > AUG-2007 > > 20:51:10 Compaq COBOL V2.8-1286 Page 5 > > Compilation Summary 28- > AUG-2007 > > 20:50:41 DKB100:[PAUL.SRC.COBOL]TEST2.COB;4 > > > > COMMAND QUALIFIERS > > > > COBOL > > > > /NOALIGNMENT > > /GRANULARITY = QUAD > > /NOANALYSIS_DATA > > /NOINCLUDE > > /NOANSI_FORMAT > /LIST > > > > /ARCHITECTURE = GENERIC > > /MACHINE_CODE > > /ARITHMETIC = NATIVE > /NOMAP > > > > /NOAUDIT > > /MATH_INTERMEDIATE = FLOAT > > /CHECK = (NOPERFORM, NOBOUNDS, NODECIMAL, NODUPLICATE_KEYS) > > /NATIONALITY = US > > /NOCONDITIONALS > /OBJECT > > > > /NOCONVERT = LEADING_BLANKS > > /OPTIMIZE = (LEVEL=4,TUNE=GENERIC) > > /NOCOPY_LIST > > /RESERVED_WORDS = (XOPEN, NOFOREIGN_EXTENSIONS, NO200X) > > /NOCROSS_REFERENCE > > /NOSEPARATE_COMPILATION > > /DEBUG = (NOSYMBOLS, TRACEBACK) > > /NOSEQUENCE_CHECK > > /NODEPENDENCY_DATA > > /STANDARD = (NOXOPEN, NOSYNTAX, NOV3, 85, NOMIA) > > /NODIAGNOSTICS > /NOTIE > > > > /NODISPLAY_FORMATTED > > /NOTRUNCATE > > ... > > > > read more ;- Hide quoted text - > > > > - Show quoted text - > ------------------------------ Date: Tue, 28 Aug 2007 20:01:18 +0200 From: Albrecht Schlosser Subject: Lock problem with SAMBA/NMBD Message-ID: I'm experiencing a problem with SAMBA's NMBD process. This process seems to acquire an increasing number of locks. I know that there is a SAMBA specific group, but I'd like to learn more about the locks themselves before I try to post there (once again). When NMBD has run for a long time, MONI LOCK shows an increasing number of locks. The last time I stopped the NMBD process, this process had more than 18000 locks, but some time ago, there had been more than 50000 or maybe 70000 locks. If that happens, then SAMBA doesn't work anymore, and the system may become very slow. I used ANA/SYSTEM with SHO PROC/LOCK/ID= and found that there have been 18257 locks in total, with 18252/1/2/2 granted at NL/PW/PR/EX, resp. There was one lock with 18236 sublocks (for details see below). There are only a few files opened by NMBD on one device, shown here from a later instance of NMBD: Files accessed on device ALPHA1$DKB300: on 28-AUG-2007 19:31:00.00 NMBD 0000AC9F [VMS$COMMON.SYSEXE]RIGHTSLIST.DAT;1 NMBD 0000AC9F [SAMBA.VAR]NMBD_STARTUP.LOG;13 NMBD 0000AC9F [SAMBA.BIN]NMBD_STARTUP.COM;10 NMBD 0000AC9F [SAMBA.BIN]NMBD.EXE;6 NMBD 0000AC9F [SAMBA.VAR]LOG.NMBD;1 NMBD 0000AC9F [SAMBA.VAR.LOCKS]MESSAGES.TDB;1 NMBD 0000AC9F [SAMBA.VAR.LOCKS]UNEXPECTED.TDB;1 Question: Does anyone have an idea where to look next, or what could be helpful to analyze the problem? What a kind of locks can these be? VMS/Alpha V7.3-2, SAMBA-2_2_8-20050817 (Jean-Yves Collot's port, latest version). TIA, Albrecht Details of 3 selected locks follow (the volume label of the disk is ALPHA_73-2, which seems to be part of the first shown lock info): ---------------------------------------------- OpenVMS (TM) Operating System, Version V7.3-2 -- System Dump Analysis ... Process index: 012C Name: NMBD Extended PID: 00007F2C Lock data: Lock id: 2800BFC2 PID: 003F012C Flags: SYSTEM NOQUOTA EXPEDIT Par. id: 00000000 SUBLCKs: 18236 LKB: FFFFFFFF.669F7580 BLKAST: 00000000 Priority: 0000 Granted at NL 00000000-FFFFFFFF RSB: FFFFFFFF.668A3B80 Resource: 4C417624 42313146 F11B$vAL Status: NOQUOTA VALBLKR VALBLKW Length 18 322D3337 5F414850 PHA_73-2 Kernel mode 00000000 00002020 ...... System 00000000 00000000 ........ Local copy ---------------------------------------------- Process index: 012C Name: NMBD Extended PID: 00007F2C Lock data: Lock id: 55000084 PID: 003F012C Flags: SYSTEM NOQUOTA EXPEDIT Par. id: 2800BFC2 SUBLCKs: 0 LKB: FFFFFFFF.66894D80 BLKAST: 00000000 Priority: 0000 Granted at NL 00000000-FFFFFFFF RSB: FFFFFFFF.6707E380 Resource: 39537324 42313146 F11B$sS9 Status: NOQUOTA VALBLKR VALBLKW Length 10 00000000 00000000 ........ Kernel mode 00000000 00000000 ........ System 00000000 00000000 ........ Local copy ---------------------------------------------- Process index: 012C Name: NMBD Extended PID: 00007F2C Lock data: Lock id: 7B00CB59 PID: 003F012C Flags: SYSTEM NOQUOTA EXPEDIT Par. id: 2800BFC2 SUBLCKs: 0 LKB: FFFFFFFF.66A27080 BLKAST: 00000000 Priority: 0000 Granted at NL 00000000-FFFFFFFF RSB: FFFFFFFF.66950480 Resource: 83137324 42313146 F11B$s.. Status: NOQUOTA VALBLKR VALBLKW Length 10 00000000 00000000 ........ Kernel mode 00000000 00000000 ........ System 00000000 00000000 ........ Local copy ---------------------------------------------- ------------------------------ Date: 28 Aug 2007 15:00:15 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Lock problem with SAMBA/NMBD Message-ID: In article , Albrecht Schlosser writes: > > Question: Does anyone have an idea where to look next, or what could > be helpful to analyze the problem? What a kind of locks can these be? All though some of the locks you've shown do have to do with the file system, not all locks do. Locks can be used for any resource that needs to be coordinated. Are you looking at values that represent the number of locks currently held, or the number of locks held at some time? You seem to claim that the process holds a lot more locks than you list, did you just trim the list to keep from flooding c.o.v.? Possibly the code is not cleaning up some resources that it should, like closing files, or dequeuing locks that it is done with. Keeping locks around in a null state can be a performance improvement with locks that come and go a lot, but could be mis-implemented to not dequeue locks that should be. ------------------------------ Date: Wed, 29 Aug 2007 00:41:52 +0200 From: Albrecht Schlosser Subject: Re: Lock problem with SAMBA/NMBD Message-ID: Bob Koehler wrote: > In article , Albrecht Schlosser writes: >> Question: Does anyone have an idea where to look next, or what could >> be helpful to analyze the problem? What a kind of locks can these be? > > All though some of the locks you've shown do have to do with the > file system, not all locks do. Locks can be used for any resource > that needs to be coordinated. > > Are you looking at values that represent the number of locks > currently held, or the number of locks held at some time? You > seem to claim that the process holds a lot more locks than you > list, did you just trim the list to keep from flooding c.o.v.? Yes and yes, as I wrote before, the number of locks is increasing over time. This happens even, if no SAMBA users are currently active (there are no SMBDxxx processes, but there is always the NMBD process - that's okay so far). And yes, I selected the parent lock that has 18236 sublocks (if that's what SUBLCKs means), and just two of those 18236 sublocks to show an example. They're all looking the same, and they're all null (NL) locks. > Possibly the code is not cleaning up some resources that it should, > like closing files, or dequeuing locks that it is done with. Yes, that's what I suspect, but maybe someone can say more about the nature of these locks ? > Keeping > locks around in a null state can be a performance improvement with > locks that come and go a lot, but could be mis-implemented to not > dequeue locks that should be. I looked into the code, but didn't really know _where_ to look. Also, I didn't find any explicit "ENQ" or "DEQ" string occurrences in the NMBD source directory, but there might be some in other directories (NMBD is linked together with another object library). Thanks for your help, Albrecht ------------------------------ Date: Wed, 29 Aug 2007 07:35:34 +0200 From: Jur van der Burg <"lddriver at digiater dot nl"> Subject: Re: Lock problem with SAMBA/NMBD Message-ID: <46d505aa$0$236$e4fe514c@news.xs4all.nl> Looks like a bug to me. The F11B$s locks are filesystem serialization locks, taken out by the XQP when processing an IO$_ACCESS request for a file. It appears that under certain circumstances no IO$_DEACCESS is done, leaving the locks hanging around. Report this to HP. Jur. Albrecht Schlosser wrote: > I'm experiencing a problem with SAMBA's NMBD process. This process seems > to acquire an increasing number of locks. > > I know that there is a SAMBA specific group, but I'd like to learn more > about the locks themselves before I try to post there (once again). > > When NMBD has run for a long time, MONI LOCK shows an increasing number > of locks. The last time I stopped the NMBD process, this process had > more than 18000 locks, but some time ago, there had been more than 50000 > or maybe 70000 locks. If that happens, then SAMBA doesn't work anymore, > and the system may become very slow. > > I used ANA/SYSTEM with SHO PROC/LOCK/ID= and found that > there have been 18257 locks in total, with 18252/1/2/2 granted at > NL/PW/PR/EX, resp. There was one lock with 18236 sublocks (for details > see below). > > There are only a few files opened by NMBD on one device, shown here > from a later instance of NMBD: > > Files accessed on device ALPHA1$DKB300: on 28-AUG-2007 19:31:00.00 > > NMBD 0000AC9F [VMS$COMMON.SYSEXE]RIGHTSLIST.DAT;1 > NMBD 0000AC9F [SAMBA.VAR]NMBD_STARTUP.LOG;13 > NMBD 0000AC9F [SAMBA.BIN]NMBD_STARTUP.COM;10 > NMBD 0000AC9F [SAMBA.BIN]NMBD.EXE;6 > NMBD 0000AC9F [SAMBA.VAR]LOG.NMBD;1 > NMBD 0000AC9F [SAMBA.VAR.LOCKS]MESSAGES.TDB;1 > NMBD 0000AC9F [SAMBA.VAR.LOCKS]UNEXPECTED.TDB;1 > > Question: Does anyone have an idea where to look next, or what could > be helpful to analyze the problem? What a kind of locks can these be? > > > VMS/Alpha V7.3-2, > SAMBA-2_2_8-20050817 (Jean-Yves Collot's port, latest version). > > TIA, > > Albrecht > > Details of 3 selected locks follow (the volume label of the disk is > ALPHA_73-2, which seems to be part of the first shown lock info): > > ---------------------------------------------- > > OpenVMS (TM) Operating System, Version V7.3-2 -- System Dump Analysis > ... > Process index: 012C Name: NMBD Extended PID: 00007F2C > > Lock data: > > Lock id: 2800BFC2 PID: 003F012C Flags: SYSTEM NOQUOTA > EXPEDIT > Par. id: 00000000 SUBLCKs: 18236 > LKB: FFFFFFFF.669F7580 BLKAST: 00000000 > Priority: 0000 > > Granted at NL 00000000-FFFFFFFF > > RSB: FFFFFFFF.668A3B80 > Resource: 4C417624 42313146 F11B$vAL Status: NOQUOTA VALBLKR > VALBLKW > Length 18 322D3337 5F414850 PHA_73-2 > Kernel mode 00000000 00002020 ...... > System 00000000 00000000 ........ > > Local copy > > ---------------------------------------------- > > Process index: 012C Name: NMBD Extended PID: 00007F2C > > > > Lock data: > > Lock id: 55000084 PID: 003F012C Flags: SYSTEM NOQUOTA > EXPEDIT > Par. id: 2800BFC2 SUBLCKs: 0 > LKB: FFFFFFFF.66894D80 BLKAST: 00000000 > Priority: 0000 > > Granted at NL 00000000-FFFFFFFF > > RSB: FFFFFFFF.6707E380 > Resource: 39537324 42313146 F11B$sS9 Status: NOQUOTA VALBLKR > VALBLKW > Length 10 00000000 00000000 ........ > Kernel mode 00000000 00000000 ........ > System 00000000 00000000 ........ > > Local copy > > > ---------------------------------------------- > > Process index: 012C Name: NMBD Extended PID: 00007F2C > > > > Lock data: > > Lock id: 7B00CB59 PID: 003F012C Flags: SYSTEM NOQUOTA > EXPEDIT > Par. id: 2800BFC2 SUBLCKs: 0 > LKB: FFFFFFFF.66A27080 BLKAST: 00000000 > Priority: 0000 > > Granted at NL 00000000-FFFFFFFF > > RSB: FFFFFFFF.66950480 > Resource: 83137324 42313146 F11B$s.. Status: NOQUOTA VALBLKR > VALBLKW > Length 10 00000000 00000000 ........ > Kernel mode 00000000 00000000 ........ > System 00000000 00000000 ........ > > Local copy > > ---------------------------------------------- ------------------------------ Date: Tue, 28 Aug 2007 19:35:41 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: SMB backup "solutions" (was:Re: COBOL Transactions?) Message-ID: In article , bradhamilton@comcast.net (Brad Hamilton) writes: > > >In article <002b01c7e7ef$b3bc98b0$1b35ca10$@com>, Paul Raulerson wrote: >[...] >>But to swing this around to a more productive subject, what backup options >>are available on low end Itanimum Integrity systems that would be suitable >>for daily use by non-technical users. >> >>Hardly any of the very small SMB shops will have the backup capability I >>have here, nor the skill to engineer a disaster recovery situation. I >>need to do that for them, on the cheap, and in such as way as it is not >>too ornerous for them to do every day. >> >>Stick a tape in and go away will probably be about the level I need to >>get to. >[...] > >I can't speak to Itaniums, since I don't use them - however, the last VMS job I >had needed this kind of "stick a tape in and change it every day" solution at >the customer site(s). 4mm DAT was chosen for its (relative) cheapness, minimal >footprint for drive and tapes, and relative ease of use (stick the tape in and >walk away). > >Will 4mm DAT work on an Itanium? Don't know. Why not. I've connected my ol' d|i|g|i|t|a|l TLZ07 to the Itanium and it seemed perfectly happy to talk to it. -- 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: Tue, 28 Aug 2007 19:54:56 +0000 From: "Main, Kerry" Subject: The Common System Interface: Intel's Future Interconnect Message-ID: All, The following article may be of interest: (August 28, 2007) http://www.realworldtech.com/page.cfm?ArticleID=3DRWT082807020032&p=3D1 "In the competitive x86 microprocessor market, there are always swings and = shifts based on the latest introductions from the two main protagonists: Intel and AMD. The= next anticipated shift is coming in 2008-9 when Intel will finally replace their front side = bus architecture. This report details Intel's next generation system interconnect and the ass= ociated cache coherency protocol, likely deployment plans across the desktop, notebook an= d server market as well as the economic implications." [Snip - see article] Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-592-4660 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT) OpenVMS - the secure, multi-site OS that just works. ------------------------------ Date: Tue, 28 Aug 2007 19:45:47 -0500 From: David J Dachtera Subject: Re: Wisconsin professor says global warming a hoax! Message-ID: <46D4C1BB.483EBD4@spam.comcast.net> Neil Rieck wrote: > > On Aug 25, 11:09 am, David J Dachtera > wrote: > > > > I would opine that it may be possible to buffer the effects of a naturally > > occuring phenomenon - "may": no guarantees - within the limits of our > > technology. "Stopping" would be rather akin to adjusting the output of old Sol > > out there, adjusting the orbit of Terra around it or Terra's rotation about its > > axis, or otherwise attempting to modify the very nature of either the planet, > > the solar system or the universe. > > > > I'll repeat my conviction here as well: humankind did not cause climate change, > > humankind will not prevent it. > > > > You are speaking "black and white" but the answer is really in the > thousand shades of gray in between. But I do not accept your defeatist > attitude. (sorry) To paraphrase e-plan Peter's .sig, "I'm not a defeatist - I'm a realist". If futility is your thing, go for it. With luck, you'll be too busy to notice when "the big one" hits. On the other hand, if you dedicate your efforts to launching some artifacts of human society into space such that they will eventually land back on what ever is left of Mother Earth, that may actually prove useful in the long run if found and eventually studied by whatever intelligent life form succeeds us. > Mars is much colder than it should be, and this is ...possibly... > caused by the lack > of an atmosphere. ... indirectly, or directly by whatever caused Mars's atmosphere - assuming it ever had one - to be stripped away (which might even be the ultimate fate of Terra - who knows?). > Venus is much hotter than it should be, and this is ...believed to be... > caused by a run-away greenhouse effect of the atmosphere. ...or is the run-away "greenhouse effect" the result of being much hotter since it is closer to the Sun? The jury is still out on that question, though a large portion of the scientific community seems convinced as you are based onthe incomplete evidence in our possession. > So it is > obvious to me that tweaking the atmosphere is the primary key to > solving this problem. Well, I had to qualify your statements above. In the purest sense, they do not support your conclusion - the current understanding of the issues is incomplete, and the conclusion is, therefore, brash and not well founded. It also ignores factors outside of the planet and its atmosphere which produces an incomplete data set. Conclusions based on incomplete data are, at best, faulty. > There are other factors in global warming but I think we can get > control of the atmosphere. But we just can't give up now after coming > so far! How far have we come? Have we managed to change the precession of the earth's axis? ...the orbit of the Earth around the Sun? What did I miss? Earth's climate has changed cyclically since before the dawn of recorded history. It will continue to change long after humankind goes the way of the dinosaur and the dodo. > > ...and if you think now is bad, do a little research into "the dust bowl days". > > We can cause weather patterns to shift through mismanaging our soil and other > > resources, but we cannot effect factors that operate on a cosmic scale. > > > > I'm not sure if the dirty-thirties was a world-wide phenomenon or > something local to North America. Well, given that I said: > > We can cause weather patterns to shift through mismanaging our soil and other > > resources, but we cannot effect factors that operate on a cosmic scale. ..., I believe its is safe to say that the "Dust Bowl" phenomenon was local to the Central Plains of the U.S. Other places on other continents may have experienced similar issues - I did not address them, nor did I intend to. > However, everyone in the field of > agriculture (no pun) has been taught that the top soil just blew and > that this was caused by poor agricultural practices (such as always > plowing fields in a straight line; plowing too deeply; not rotating > crops; not letting a field go fallow; not having a wind-break of > trees; etc.). That is why the US Department of Agriculture uses county > agents to eductate farmers. ...which seems to support my statement. If you disagree with me and still think I'm a "defeatist", read this again, and see if you can understand what I'm trying to say here: > > ..., but we cannot effect factors that operate on a cosmic scale. -- 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: Tue, 28 Aug 2007 20:33:07 -0500 From: Ron Johnson Subject: Re: Wisconsin professor says global warming a hoax! Message-ID: On 08/28/07 19:45, David J Dachtera wrote: > Neil Rieck wrote: >> On Aug 25, 11:09 am, David J Dachtera >> wrote: [snip] > > On the other hand, if you dedicate your efforts to launching some artifacts of > human society into space such that they will eventually land back on what ever > is left of Mother Earth, that may actually prove useful in the long run if found > and eventually studied by whatever intelligent life form succeeds us. Unless (70.8% chance) it lands in water. Or the 90% of the terra firma that is uninhabited. >> Mars is much colder than it should be, and this is > > ...possibly... > >> caused by the lack >> of an atmosphere. > > ... indirectly, or directly by whatever caused Mars's atmosphere - assuming it > ever had one - to be stripped away (which might even be the ultimate fate of > Terra - who knows?). http://en.wikipedia.org/wiki/Mars Mars lost its magnetosphere 4 billion years ago, so the solar wind interacts directly with the Martian ionosphere, keeping the atmosphere thinner than it would otherwise be by stripping away atoms from the outer layer. Both Mars Global Surveyor and Mars Express have detected these ionised atmospheric particles trailing off into space behind Mars.[31][32] The atmosphere of Mars is now relatively thin. >> Venus is much hotter than it should be, and this is > > ...believed to be... > >> caused by a run-away greenhouse effect of the atmosphere. > > ...or is the run-away "greenhouse effect" the result of being much hotter since > it is closer to the Sun? The jury is still out on that question, though a large > portion of the scientific community seems convinced as you are based onthe > incomplete evidence in our possession. Shhhhh. Don't say that too loud! >> So it is >> obvious to me that tweaking the atmosphere is the primary key to >> solving this problem. > > Well, I had to qualify your statements above. In the purest sense, they do not > support your conclusion - the current understanding of the issues is incomplete, > and the conclusion is, therefore, brash and not well founded. It also ignores > factors outside of the planet and its atmosphere which produces an incomplete > data set. Conclusions based on incomplete data are, at best, faulty. But they serve so many purposes. [snip] -- 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! ------------------------------ End of INFO-VAX 2007.473 ************************