INFO-VAX Wed, 29 Aug 2007 Volume 2007 : Issue 474 Contents: Re: DEC 3000/800 AXP boot problem Re: DEC 3000/800 AXP boot problem RE: DEC 3000/800 AXP boot problem Exporting data tied up in a VAX/VMS system Re: Exporting data tied up in a VAX/VMS system 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: Lock problem with SAMBA/NMBD Re: Lock problem with SAMBA/NMBD Re: Lock problem with SAMBA/NMBD MONITOR with different architectures RE: MONITOR with different architectures Re: MONITOR with different architectures Re: MONITOR with different architectures Re: MONITOR with different architectures Re: MONITOR with different architectures Re: MONITOR with different architectures Odd disk problem Re: U.S. Report to Congress on Data Centers Re: U.S. Report to Congress on Data Centers ---------------------------------------------------------------------- Date: Wed, 29 Aug 2007 07:51:14 -0000 From: urbancamo Subject: Re: DEC 3000/800 AXP boot problem Message-ID: <1188373874.677892.222960@y42g2000hsy.googlegroups.com> > I don't believe there is a temperature sensor in these systems. As the fans initially spool up and then calm down, surely there must be something controlling the speed. If not a temperature sensor, then maybe something measuring power draw? I found problem causing the ASIC error - there is a post-manufacturing hack on the IO module that involves two pins of a PLCC being lifted from their pads and soldered to a diode and resister in parallel. The other end is soldered via a wire to a pad on the motherboard. The glue holding the hack to the top of the PLCC has long since deteriorated and one of the pins was very close to its' neighbour and pad. I moved this clear and since then a couple of boots have now shown the error. What I'm noticing now however is that the system is hanging intermittently. My focus now is on the power supply. I have heard that capacitors can deteriorate in a power supply - and have personal experience of old capacitors blowing up. What could I check on the power supply to determine if that is the problem? Thanks for the help, Mark. ------------------------------ Date: Wed, 29 Aug 2007 07:59:11 -0000 From: urbancamo Subject: Re: DEC 3000/800 AXP boot problem Message-ID: <1188374351.748252.89850@22g2000hsm.googlegroups.com> urbancamo wrote: > and one of the pins was very close to its' neighbour and pad. I moved > this clear and since then a couple of boots have now shown the error. That should say 'NOT shown the error'. Too early in the morning... ------------------------------ Date: Wed, 29 Aug 2007 12:38:02 +0000 From: "Main, Kerry" Subject: RE: DEC 3000/800 AXP boot problem Message-ID: > -----Original Message----- > From: urbancamo [mailto:mark@wickensonline.co.uk] > Sent: August 29, 2007 3:51 AM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: DEC 3000/800 AXP boot problem > > > I don't believe there is a temperature sensor in these systems. > > As the fans initially spool up and then calm down, surely there must > be something controlling the speed. If not a temperature sensor, then > maybe something measuring power draw? > > I found problem causing the ASIC error - there is a post-manufacturing > hack on the IO module that involves two pins of a PLCC being lifted > from their pads and soldered to a diode and resister in parallel. The > other end is soldered via a wire to a pad on the motherboard. The glue > holding the hack to the top of the PLCC has long since deteriorated > and one of the pins was very close to its' neighbour and pad. I moved > this clear and since then a couple of boots have now shown the error. > > What I'm noticing now however is that the system is hanging > intermittently. My focus now is on the power supply. I have heard that > capacitors can deteriorate in a power supply - and have personal > experience of old capacitors blowing up. What could I check on the > power supply to determine if that is the problem? > > Thanks for the help, Mark. Fwiw, I have had the occasional hang with my DEC 3000 (now running V8.3), b= ut it has never hung if I do an additional INIT command after it powers up and before= entering the boot command. 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: Wed, 29 Aug 2007 17:06:04 -0000 From: richards.alex@gmail.com Subject: Exporting data tied up in a VAX/VMS system Message-ID: <1188407164.551718.115840@q5g2000prf.googlegroups.com> I'm a computer-assisted reporting specialist at a newspaper in Nevada -- my beat is essentially data mining in the public realm. I'm in the middle of negotiations for inspection records kept by the local health district in a VAX minicomputer that probably runs VMS. They are basically telling me that their system has no way of exporting data that's been entered over the years, which I find highly unlikely. Their IT department probably (a) doesn't know how or (b) just doesn't feel like it and hopes that this response will make me go away. All I want is a dump of these records into a file -- ideally as ASCII text, fixed-width or character-delimited. I've talked to some colleagues who have had limited VAX/VMS experience and have been told this is entirely possible: "They should definitely be able to get the data out, they might want to send it on a tape format, but unless they've got some really bizarre system, they should be able to copy it to some physical device or they can probably transfer it over a network to some other system to copy the data on to." Even if they have to dump it to reel-to-reel tapes or cartridges, I have a consultant in Missouri with equipment to transfer it to a different medium. Any help would be greatly appreciated. Specific information like: - Further things to find out about their VAX computer - Commands to transfer this data out of the system in a usable format If I'm just out of luck and will have to spend hours building my own database from paper documents, I'd like to know that too. Thank you, Alex Richards CAR Specialist Las Vegas Sun ------------------------------ Date: Wed, 29 Aug 2007 10:28:41 -0700 From: "Tom Linden" Subject: Re: Exporting data tied up in a VAX/VMS system Message-ID: On Wed, 29 Aug 2007 10:06:04 -0700, wrote: > I'm a computer-assisted reporting specialist at a newspaper in Nevada > -- my beat is essentially data mining in the public realm. I'm in the > middle of negotiations for inspection records kept by the local health > district in a VAX minicomputer that probably runs VMS. They are > basically telling me that their system has no way of exporting data > that's been entered over the years, which I find highly unlikely. > Their IT department probably (a) doesn't know how or (b) just doesn't > feel like it and hopes that this response will make me go away. > > All I want is a dump of these records into a file -- ideally as ASCII > text, fixed-width or character-delimited. I've talked to some > colleagues who have had limited VAX/VMS experience and have been told > this is entirely possible: "They should definitely be able to get the > data out, they might want to send it on a tape format, but unless > they've got some really bizarre system, they should be able to copy it > to some physical device or they can probably transfer it over a > network to some other system to copy the data on to." > > Even if they have to dump it to reel-to-reel tapes or cartridges, I > have a consultant in Missouri with equipment to transfer it to a > different medium. > > Any help would be greatly appreciated. Specific information like: > - Further things to find out about their VAX computer > - Commands to transfer this data out of the system in a usable format > > If I'm just out of luck and will have to spend hours building my own > database from paper documents, I'd like to know that too. > They are giving you the run-around, there is likely many different ways to extract the data, the method chosen depends on how it is stored. > Thank you, > > Alex Richards > CAR Specialist > Las Vegas Sun > -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Wed, 29 Aug 2007 03:47:08 -0500 From: Ron Johnson Subject: Re: Itanium Port Question Message-ID: On 08/28/07 22:58, Paul Raulerson wrote: > >> -----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 [snip] > >> 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? It would if the record lengths grow and change a lot. But simple (RLE) compression can also help by making your IO more effective. -- 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: Wed, 29 Aug 2007 12:12:56 -0000 From: Hein RMS van den Heuvel Subject: Re: Itanium Port Question Message-ID: <1188389576.572037.263420@57g2000hsv.googlegroups.com> On Aug 29, 4:47 am, Ron Johnson wrote: > On 08/28/07 22:58, Paul Raulerson wrote: > >> From: Hein RMS van den Heuvel > >> 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. : > > 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. It is a fine and good practice to have the primary key be the first field, if you have no reason for it to be elsewhere. But if there is even the slightest reason to have it elsewhere, then just let it be elsewhere. That reason could precisely be the natural alignment of things: Don't let the 9-byte 'Social Security Number' if not already replaced by an hash for percieved secutiry reason spoil the potential aligment of fields which migh benefit from that in teh record buffers in the program. Or maybe you finally realized that the SSN is a lousy / stupid primary key and want to relegate it to be an alernate and make the customer number or lastname/firstname the new primary. No reason to write/ script a converter to flip the fields in the record, just redefine the keys in the FDL and the Cobol FD sections and convert and rebuild code base. > > > I expect RMS knows what it is doing, but I don't like the idea of it > > rearranging data for me. ;) By physicaly storing the primary key up front, rms does not have to decompress, or at the very least carefully count the rest of the data to find that primary key. And it will be 'near' the records header which are looked at just earlier, thus the memory caches/transfer arrangments might make it slightly quicker bytes to access than bytes further down in the buffer, possibly on a next page(lette). > >> 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? What might be a performance hit? The compressing or the non-rounding? I found RMS compression to ALWAYS be a net CPU AGAIN. The reason for that is that records are more often (10x) just glanced at versus being actualy decompressed and moved to a user buffer: - scanning the bucket for the right target key - moving records in the bucket to make room for a new or grown record, or expunge the space which was occupied by a now deleted, or shortened record Aligning the end to a 'round number' can not possibly help ever. It will just create more data to lug around. The IOs are performed in BUCKETS of multiple 512-byte blocks. Each bucket had 15 bytes overhead (14 header, 1 tail). Each record typcially has 9 bytes overhead (flag, length, 6-byte RRV) So how is a record having an end-user length of 128 or 512 or 1024 going to help RMS? Make 'm as short as possible, but no shorter! Of course you may want to align the program buffers to receive those records at nice round numbers, but that's an other story alltogether. > It would if the record lengths grow and change a lot. But simple > (RLE) compression can also help by making your IO more effective. Huh? That fails to compute. Is this in response to (non)rounding? Please explain. simple RLE = ??? Record LEngth? Sorry, but I have no clue what that might mean in RMS context. My best guess is that it is about actual length versus maximum length. If variable length records are used then RMS only ever stores the actual data. It does not pre-reserve the full size and aligning either would only serve to hurt both as per above. If actual records lengths grow and change a lot, then you may want to pre-allocate to the max size, and you may want to disable record-data- compression or polute the unused space with non-compressing 'not in use' data contents. Hope this helps some, Hein van den Heuvel (at gmail dot com) HvdH Performance Consulting ------------------------------ Date: Wed, 29 Aug 2007 09:08:21 -0500 From: Ron Johnson Subject: Re: Itanium Port Question Message-ID: On 08/29/07 07:12, Hein RMS van den Heuvel wrote: [snip] > >> It would if the record lengths grow and change a lot. But simple >> (RLE) compression can also help by making your IO more effective. > > Huh? That fails to compute. Is this in response to (non)rounding? > Please explain. > > simple RLE = ??? Record LEngth? > Sorry, but I have no clue what that might mean in RMS context. Run-Length Encoding. Replaces a repeated character (25 spaces, for example, with a repeat-count and the target character). It means that you transfer less data from host to disk, store less data on disk, read less data from disk and transfer less from disk to host. Uses a *slight* amount of CPU to expand the record. Can be a *BIG* win in insert-once/no-update situations, but a BIG LOSER when you update a blank field with non-repeating data. -- 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: Wed, 29 Aug 2007 10:19:41 -0400 From: John Reagan Subject: Re: Itanium Port Question Message-ID: 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. > The COBOL compiler aligns 01 and 77 level items on quadword boundaries by default. It is only the alignment/padding of other level items that defaults to VAX byte alignment. You can ask for more alignment and padding with the /ALIGNMENT qualifier. -- John Reagan OpenVMS Pascal/Macro-32/COBOL Project Leader Hewlett-Packard Company ------------------------------ Date: Wed, 29 Aug 2007 07:41:45 -0700 From: "Tom Linden" Subject: Re: Itanium Port Question Message-ID: On Wed, 29 Aug 2007 07:19:41 -0700, John Reagan wrote: > 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. >> > > The COBOL compiler aligns 01 and 77 level items on quadword boundaries > by default. It is only the alignment/padding of other level items that > defaults to VAX byte alignment. You can ask for more alignment and > padding with the /ALIGNMENT qualifier. > The same is true for PL/I. Of course, you probably don't want to change existing code that does record I/O -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Wed, 29 Aug 2007 10:40:44 -0400 From: John Reagan Subject: Re: Itanium Port Question Message-ID: Paul Raulerson wrote: > same, which gives me reason to pause. I wonder if someone would post the > generated code from an Itanium system please? > Here it is with the CALL statement recommended by Hein to prevent the optimizer from evaporating the MOVEs. The 'st1' for the MOVE on line 12 is at offset 00E0. For the MOVE on line 13, you'll find a sequence scattered in the code that is: 00A03A200180 0082 tbit.z pr6, pr7 = r34, 0 0108022008C0 0090 mov r35 = r34 00AC02348047 00A0 (pr7) st1 [r35] = r36, 1 00A5BA420907 00B1 (pr7) shr.u r36 = r36, 8 00AC42348080 00C0 st2 [r35] = r36, 2 00A57A440900 00C1 shr.u r36 = r36, 16 ;; 008C42348006 00D0 (pr6) st2 [r35] = r36 008C02348007 00D1 (pr7) st1 [r35] = r36 Apparently, the compiler knew it COULD be unaligned, but for some reason it didn't realize it ALWAYS was unaligned. I think it should. I'll put that on our code-quality list. Anyway, the tbit tests the bottom bit the address to pick of byte-aligned data. If byte aligned, we'll do a st1,st2,st1 sequence. If not byte aligned, we'll do the st2,st2 seqeunce. 1 IDENTIFICATION DIVISION. 2 PROGRAM-ID. TEST3. 3 ENVIRONMENT DIVISION. 4 DATA DIVISION. 5 WORKING-STORAGE SECTION. 6 01 TOP-LEVEL. 7 03 DATA-ITEM-1 PIC X(1). 8 03 DATA-ITEM-2 PIC S9(9) COMP. 9 10 PROCEDURE DIVISION. 11 START-PROGRAM. 12 MOVE 'Z' TO DATA-ITEM-1 13 MOVE -212 TO DATA-ITEM-2 14 CALL "test" USING DATA-ITEM-1, DATA-ITEM-2 15 STOP RUN. .psect $CODE$, CON, LCL, SHR, EXE, NOWRT, NOVEC, NOSHORT .proc TEST3 .align 32 .global TEST3 .personality DCOB$SIGNAL_HANDLER .handlerdata 8 TEST3: // 000002 { .mii 002C00B1AA40 0000 alloc r41 = rspfs, 0, 11, 2, 0 0119F8CE0300 0001 adds sp = -16, sp // r12 = -16, r12 010800100A80 0002 mov r42 = gp ;; // r42 = r1 } { .mib 010800C30080 0010 adds r2 = 24, sp // r2 = 24, r12 000188000A00 0011 mov r40 = rp // r40 = br0 004000000000 0012 nop.b 0 ;; } { .mii 008CC0200000 0020 st8 [r2] = r0 012000100200 0021 add r8 = @ltoffx($LOCAL$), gp // r8 = @ltoffx($LOCAL$), r1 012000100800 0022 add r32 = @ltoffx($LOCAL$), gp // r32 = @ltoffx($LOCAL$), r1 } { .mmi 012000100AC0 0030 add out0 = @ltoff(@fptr(TEST3)), // r43 = @ltoff(@fptr(TEST3)), r1 gp ;; 0080C0800200 0031 ld8.mov r8 = [r8], $LOCAL$ 012000002640 0032 mov ai = 1 // r25 = 1 } { .mmi 0080C2000800 0040 ld8.mov r32 = [r32], $LOCAL$ ;; 0080C2B00AC0 0041 ld8 out0 = TEST3 // r43 = [r43] 000008000000 0042 nop.i 0 ;; } { .mii 010800860200 0050 adds r8 = 48, r8 010802040800 0051 adds r32 = 32, r32 000008000000 0052 nop.i 0 ;; } { .mmb 008CC0800000 0060 st8 $LOCAL$ = r0 // [r8] = r0 008C82000000 0061 st4 [r32] = r0 00A000001000 0062 br.call.sptk.many rp = DCOB$CALLED ;; // br0 = DCOB$CALLED } { .mii 0119FA0C2880 0070 adds r34 = -31, r32 // 000013 0119F0058840 0071 adds r33 = -212, r0 010802A00040 0072 mov gp = r42 // r1 = r42 // 000002 } { .mmi 0120000B4980 0080 mov r38 = 90 ;; // 000012 010802100900 0081 mov r36 = r33 // 000013 00A03A200180 0082 tbit.z pr6, pr7 = r34, 0 } { .mii 0108022008C0 0090 mov r35 = r34 012000100940 0091 add r37 = @ltoffx($LOCAL$), gp ;; // r37 = @ltoffx($LOCAL$), r1 // 000002 0119FA0C00C0 0092 adds r3 = -32, r32 // 000014 } { .mii 00AC02348047 00A0 (pr7) st1 [r35] = r36, 1 // 000013 0119FA0C09C0 00A1 adds r39 = -32, r32 // 000012 012000004640 00A2 mov ai = 2 ;; // r25 = 2 // 000014 } { .mii 0080C2500940 00B0 ld8.mov r37 = [r37], $LOCAL$ // 000002 00A5BA420907 00B1 (pr7) shr.u r36 = r36, 8 // 000013 010800300AC0 00B2 mov out0 = r3 ;; // r43 = r3 // 000014 } { .mii 00AC42348080 00C0 st2 [r35] = r36, 2 // 000013 00A57A440900 00C1 shr.u r36 = r36, 16 ;; 010802570940 00C2 adds r37 = 56, r37 ;; // 000002 } { .mmi 008C42348006 00D0 (pr6) st2 [r35] = r36 // 000013 008C02348007 00D1 (pr7) st1 [r35] = r36 0119FA0C0800 00D2 adds r32 = -32, r32 ;; // 000012 } { .mmi 00AC0204C040 00E0 st1 [r32] = r38, 1 008CC2510000 00E1 st8 $LOCAL$ = r8 // [r37] = r8 // 000002 000008000000 00E2 nop.i 0 ;; } { .mfb 010802000B00 00F0 mov out1 = r32 // r44 = r32 // 000014 000008000000 00F1 nop.f 0 00A000001000 00F2 br.call.sptk.many rp = TEST ;; // br0 = TEST } { .mii 012000000640 0100 mov ai = 0 // r25 = 0 // 000015 010802A00040 0101 mov gp = r42 // r1 = r42 // 000014 000008000000 0102 nop.i 0 ;; } { .mfb 000008000000 0110 nop.m 0 000008000000 0111 nop.f 0 00A000001000 0112 br.call.sptk.many rp = DCOB$STOP ;; // br0 = DCOB$STOP // 000015 } { .mfi 010802A00040 0120 mov gp = r42 // r1 = r42 000008000000 0121 nop.f 0 000008000000 0122 nop.i 0 ;; } .endp TEST3 ------------------------------ Date: 29 Aug 2007 15:14:37 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: Itanium Port Question Message-ID: <5jlgqtF6bbjU1@mid.individual.net> In article , John Reagan writes: > 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. >> > > The COBOL compiler aligns 01 and 77 level items on quadword boundaries > by default. It is only the alignment/padding of other level items that > defaults to VAX byte alignment. You can ask for more alignment and > padding with the /ALIGNMENT qualifier. John, As the guy responsible for the Pascal compiler and because playing with Pascal compilers is how I spend my freetime :-) how about answering a quick question for me. How does the PACKED effect all of this alignment stuff? Does the Pascal compiler take care of alignment? And, does using PACKED have any adverse effect on all this? bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Wed, 29 Aug 2007 11:17:22 -0500 From: Ron Johnson Subject: Re: Itanium Port Question Message-ID: On 08/29/07 09:41, Tom Linden wrote: > On Wed, 29 Aug 2007 07:19:41 -0700, John Reagan wrote: > >> 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. >>> >> >> The COBOL compiler aligns 01 and 77 level items on quadword boundaries >> by default. It is only the alignment/padding of other level items >> that defaults to VAX byte alignment. You can ask for more alignment >> and padding with the /ALIGNMENT qualifier. >> > The same is true for PL/I. Of course, you probably don't want to change > existing > code that does record I/O Hmmm. So it does a single "structure copy" instead of knowing that the fields are (not-byte)-aligned and thus moving the fields individually into a temp buffer before doing record IO. -- 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: Wed, 29 Aug 2007 10:21:10 -0700 From: "Tom Linden" Subject: Re: Itanium Port Question Message-ID: On Wed, 29 Aug 2007 09:17:22 -0700, Ron Johnson wrote: > On 08/29/07 09:41, Tom Linden wrote: >> On Wed, 29 Aug 2007 07:19:41 -0700, John Reagan >> wrote: >> >>> 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. >>>> >>> >>> The COBOL compiler aligns 01 and 77 level items on quadword boundaries >>> by default. It is only the alignment/padding of other level items >>> that defaults to VAX byte alignment. You can ask for more alignment >>> and padding with the /ALIGNMENT qualifier. >>> >> The same is true for PL/I. Of course, you probably don't want to change >> existing >> code that does record I/O > > Hmmm. So it does a single "structure copy" instead of knowing that > the fields are (not-byte)-aligned and thus moving the fields > individually into a temp buffer before doing record IO. > Maybe I am not understanding you, but if the shape is the same in memory as external storage why would you need a temporary? -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Wed, 29 Aug 2007 01:59:44 -0700 From: IanMiller Subject: Re: Lock problem with SAMBA/NMBD Message-ID: <1188377984.224639.309510@w3g2000hsg.googlegroups.com> Jur - he is not using the HP port "SAMBA-2_2_8-20050817 (Jean-Yves Collot's port, latest version). " Albrecht - why not try the HP port which is available via http://h71000.www7.hp.com/network/CIFS_for_Samba.html ------------------------------ Date: Wed, 29 Aug 2007 11:32:50 +0200 From: Albrecht Schlosser Subject: Re: Lock problem with SAMBA/NMBD Message-ID: <03rfq4-u04.ln1@news.hus-software.de> IanMiller wrote: > Albrecht - why not try the HP port which is available via > http://h71000.www7.hp.com/network/CIFS_for_Samba.html Thanks for the hint (I knew that it exists), but (a) it's still beta/field test, and (b) "The OpenVMS CIFS product is being built to take advantage of features added to OpenVMS v8.2 and later. v7.3-2 will not be supported." (cited from http://h71000.www7.hp.com/network/faq.html ). Albrecht ------------------------------ Date: Wed, 29 Aug 2007 11:54:01 +0200 From: Albrecht Schlosser Subject: Re: Lock problem with SAMBA/NMBD Message-ID: Jur van der Burg wrote: > 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. Thanks, that's the information I needed / wanted to have. > It appears that under certain circumstances no IO$_DEACCESS is done, > leaving the locks hanging around. So, what could this be in a higher level programming language (here: C), ported from a U*IX environment? A forgotten close wouldn't do that, right? (BTW: I _do_ know that you could use IO$_ACCESS etc. from C, too). Would it be more probable, that this has something to do with indexed files? [SAMBA.VAR.LOCKS]MESSAGES.TDB and [SAMBA.VAR.LOCKS]UNEXPECTED.TDB come to mind. Is there a way to find the file (if any) that causes these locks not to be released? Maybe the file ID encoded in the lock info? Thanks for all help, Albrecht PS: After about 4 hours of users working with the new NMBD process, there is one lock with 522 sublocks again, with a total of 543 locks. The previous instance had been running for about 25 days (18257 locks). ------------------------------ Date: Wed, 29 Aug 2007 11:48:27 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: MONITOR with different architectures Message-ID: JF has been complaining that MONITOR CLUSTER doesn't work between the latest VAX and the latest ALPHA. I've seen the same between ALPHA and Itanium. In each of these cases, does it not work in general, are patches missing or does it "just depend"? ------------------------------ Date: Wed, 29 Aug 2007 12:28:21 +0000 From: "Main, Kerry" Subject: RE: MONITOR with different architectures Message-ID: > -----Original Message----- > From: Phillip Helbig---remove CLOTHES to reply > [mailto:helbig@astro.multiCLOTHESvax.de] > Sent: August 29, 2007 7:48 AM > To: Info-VAX@Mvb.Saic.Com > Subject: MONITOR with different architectures > > JF has been complaining that MONITOR CLUSTER doesn't work between the > latest VAX and the latest ALPHA. I've seen the same between ALPHA and > Itanium. In each of these cases, does it not work in general, are > patches missing or does it "just depend"? While I have not tried monitor cluster with VMS V8.3 (my local V8.3 systems= are still standalone systems), when ever there is an issue reported with this command= , the issue is often linked to a set-up issue. Fwiw, with OpenVMS Alpha V7.3-2, I setup a VAX, Integrity V8.2 and VAX V7.3= cluster and The Monitor command worked fine. I even saved the screen shot to a PPT file= for presentations. Reference: http://h71000.www7.hp.com/wizard/wiz_8333.html (ask the wizard) http://h71000.www7.hp.com/wizard/wiz_8029.html (see vpm$startup.com) http://h71000.www7.hp.com/DOC/82FINAL/6048/6048pro_044.html Issues I have seen include: - miss-matched passwords on accounts used for VPM inter system communicatio= n. - incorrectly defined VPM objects Note that you can establish a VPM log file for troubleshooting this error. = See above links. 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: Wed, 29 Aug 2007 05:50:33 -0700 From: IanMiller Subject: Re: MONITOR with different architectures Message-ID: <1188391833.245566.242860@d55g2000hsg.googlegroups.com> I get a incompatable version error (MONITOR-E-SRVMISMATCH, MONITOR server on remote node is an incompatible version) on a cluster consisting of Alpha V8.3, V7.3-2, VAX V7.3, I64 V8.3 if I do MONITOR CLUSTER on either of the V8.3 nodes. I see only the data for the V8.3 nodes. If I try on the Alpha V7.3-2 node I also get the same error reported for the V8.3 nodes. ------------------------------ Date: Wed, 29 Aug 2007 09:11:17 -0400 From: "Jeff Goodwin" Subject: Re: MONITOR with different architectures Message-ID: <46d57087$0$28863$4c368faf@roadrunner.com> "IanMiller" wrote in message news:1188391833.245566.242860@d55g2000hsg.googlegroups.com... >I get a incompatable version error (MONITOR-E-SRVMISMATCH, MONITOR > server on remote node is an incompatible version) on a cluster > consisting of Alpha V8.3, V7.3-2, VAX V7.3, I64 V8.3 if I do MONITOR > CLUSTER on either of the V8.3 nodes. I see only the data for the V8.3 > nodes. If I try on the Alpha V7.3-2 node I also get > the same error reported for the V8.3 nodes. > I noted this in another non-monitor thread. I'll repost it in case it was missed: I upgraded to Alpha V8.2 last fall and ran into compatibility issues with MONITOR CLUSTER and VAX V7.3. I opened a call and received new VAX MONITOR images to fix MONITOR CLUSTER within a couple of months. Looking at the backup saveset I received, there are MONITOR/VPM fixes for VAX V7.3, Alpha V7.3-2/V8.3 and Itanium V8.3. I haven't seen these images available in a downloadable patch, but you should be able to get them from the Support Center. Specifically, this corrected the SRVMISMATCH mentioned above. -Jeff ------------------------------ Date: Wed, 29 Aug 2007 07:38:32 -0700 From: "Tom Linden" Subject: Re: MONITOR with different architectures Message-ID: On Wed, 29 Aug 2007 06:11:17 -0700, Jeff Goodwin wrote: > > "IanMiller" wrote in message > news:1188391833.245566.242860@d55g2000hsg.googlegroups.com... >> I get a incompatable version error (MONITOR-E-SRVMISMATCH, MONITOR >> server on remote node is an incompatible version) on a cluster >> consisting of Alpha V8.3, V7.3-2, VAX V7.3, I64 V8.3 if I do MONITOR >> CLUSTER on either of the V8.3 nodes. I see only the data for the V8.3 >> nodes. If I try on the Alpha V7.3-2 node I also get >> the same error reported for the V8.3 nodes. >> > > I noted this in another non-monitor thread. I'll repost it in case it > was > missed: > > I upgraded to Alpha V8.2 last fall and ran into compatibility issues with > MONITOR CLUSTER and VAX V7.3. I opened a call and received new VAX > MONITOR > images to fix MONITOR CLUSTER within a couple of months. Looking at the > backup saveset I received, there are MONITOR/VPM fixes for VAX V7.3, > Alpha > V7.3-2/V8.3 and Itanium V8.3. > > I haven't seen these images available in a downloadable patch, but you > should be able to get them from the Support Center. > > > Specifically, this corrected the SRVMISMATCH mentioned above. > > -Jeff > Jeff, could you please post the header from anal/image? -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Wed, 29 Aug 2007 11:48:56 -0400 From: JF Mezei Subject: Re: MONITOR with different architectures Message-ID: <62991$46d59568$cef8887a$24740@TEKSAVVY.COM> Jeff Goodwin wrote: > I haven't seen these images available in a downloadable patch, but you > should be able to get them from the Support Center. So, that explains to total lack of action on HP's part. The patch is there, fixed and ready, but not being widely deployed. Considering that full interopability between 7.3 and 8.3 is specified in the SPD, I would have thought that HP would have posted that patch on the patch download area to remedy this very visible non-confirmance with the SPD. ------------------------------ Date: Wed, 29 Aug 2007 11:52:15 -0400 From: "Jeff Goodwin" Subject: Re: MONITOR with different architectures Message-ID: <46d59641$0$6404$4c368faf@roadrunner.com> "Tom Linden" wrote in message news:op.txtsaiolhv4qyg@murphus.linden... > On Wed, 29 Aug 2007 06:11:17 -0700, Jeff Goodwin > wrote: > >> >> "IanMiller" wrote in message >> news:1188391833.245566.242860@d55g2000hsg.googlegroups.com... >>> I get a incompatable version error (MONITOR-E-SRVMISMATCH, MONITOR >>> server on remote node is an incompatible version) on a cluster >>> consisting of Alpha V8.3, V7.3-2, VAX V7.3, I64 V8.3 if I do MONITOR >>> CLUSTER on either of the V8.3 nodes. I see only the data for the V8.3 >>> nodes. If I try on the Alpha V7.3-2 node I also get >>> the same error reported for the V8.3 nodes. >>> >> >> I noted this in another non-monitor thread. I'll repost it in case it >> was >> missed: >> >> I upgraded to Alpha V8.2 last fall and ran into compatibility issues with >> MONITOR CLUSTER and VAX V7.3. I opened a call and received new VAX >> MONITOR >> images to fix MONITOR CLUSTER within a couple of months. Looking at the >> backup saveset I received, there are MONITOR/VPM fixes for VAX V7.3, >> Alpha >> V7.3-2/V8.3 and Itanium V8.3. >> >> I haven't seen these images available in a downloadable patch, but you >> should be able to get them from the Support Center. >> >> >> Specifically, this corrected the SRVMISMATCH mentioned above. >> >> -Jeff >> > Jeff, could you please post the header from anal/image? > > Ident, etc are the same as the image was patched. Here's the patch date from the header: last patch date/time: 27-FEB-2007 19:09:40.64 > > -- > PL/I for OpenVMS > www.kednos.com ------------------------------ Date: Wed, 29 Aug 2007 10:52:15 -0700 From: tadamsmar Subject: Odd disk problem Message-ID: <1188409935.526087.282070@22g2000hsm.googlegroups.com> I have a shadowed system disks. Initially DKA0 is in the shadow set all by itself. If I try to add DKA100 as a member the system starts logging soft errors on DKA0 like crazy and the DSA0 keeps remounting and the shadow never completes (or at least it bogs way down, I did not wait for a very long time). And, the system bogs down. But I did a ana/med/exer on DKA0 and found no bad blocks. I am going to restore from a tape and try again. ------------------------------ Date: Wed, 29 Aug 2007 11:59:55 -0400 From: "John Smith" Subject: Re: U.S. Report to Congress on Data Centers Message-ID: Main, Kerry wrote: > All, > > On a semi-related note, here is a link to the Aug 2, 2007 report to > Congress on the > projected impact of data centers and future power considerations. > > Very interesting read that really substantiates why so many Customers > are now looking > at Server and Data Center consolidation. It also explains the huge > increase in "green" > or more environmentally friendly data centers. > > http://tinyurl.com/2jz3ft (Report to Congress on Server and Data > Center Energy Efficiency) > http://preview.tinyurl.com/2jz3ft (preview) > > Here is interesting extract: (pg. 7) > "Under current efficiency trends, national energy consumption by > servers and data centers > could nearly double again in another five years (i.e., by 2011) to > more than 100 billion > kWh (Figure ES-1), representing a $7.4 billion annual electricity > cost. The peak load on > the power grid from these servers and data centers is currently > estimated to be > approximately 7 gigawatts (GW), equivalent to the output of about 15 > baseload power > plants. If current trends continue, this demand would rise to 12 GW > by 2011, which would > require an additional 10 power plants." No worries - all that American controlled Iraqi/Iranian/Venezuelan oil will power them. -- OpenVMS - The never-advertised operating system with the dwindling ISV base. ------------------------------ Date: Wed, 29 Aug 2007 11:19:43 -0500 From: Ron Johnson Subject: Re: U.S. Report to Congress on Data Centers Message-ID: On 08/29/07 10:59, John Smith wrote: [snip] > > > No worries - all that American controlled Iraqi/Iranian/Venezuelan oil will > power them. After all, there's a vast swath of the country that believes W invaded Iraq just to make his oil buddies rich. Oh, and Haliburton. Can't forget Eeeeeevvvviiiiillll Haliburton. -- 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.474 ************************