INFO-VAX Thu, 04 Oct 2007 Volume 2007 : Issue 542 Contents: Re: backup problem Re: backup problem Re: backup problem Re: backup problem Re: backup problem CIXCD jumpers Re: CIXCD jumpers Re: compatible disk for vaxstation 4000 model 90 Re: compatible disk for vaxstation 4000 model 90 Re: compatible disk for vaxstation 4000 model 90 Re: despair Re: DFU on the freeware disks Re: DFU on the freeware disks Re: DFU on the freeware disks Re: DSPP PAK diffs I64/Alpha getting MAC in 7.3 Re: Guidance with OpenVMS IA64 8.3 with Java 1.5 Problems Problems with KGPSA-B and 2gb Fibrechannel Re: SmartArray errors on system boot Re: SmartArray errors on system boot Re: SmartArray errors on system boot Re: SmartArray errors on system boot Re: SmartArray errors on system boot Re: still not convinced global warming a hoax? Re: still not convinced global warming a hoax? Re: We're VMS - Please do not discuss the outside world Re: We're VMS - Please do not discuss the outside world ---------------------------------------------------------------------- Date: 4 Oct 2007 08:11:23 -0500 From: briggs@encompasserve.org Subject: Re: backup problem Message-ID: <6VF$WebZz9d+@eisner.encompasserve.org> In article <1191462774.523707.326480@y42g2000hsy.googlegroups.com>, AEF writes: [...] >> > -SYSTEM-F-EXQUOTA, process quota exceeded [...] > I think it may be a disk quota. Use the SHOW QUOTA/DISK=disk/USER=user > command to see. There is a difference between EXQUOTA and EXDISKQUOTA. The error code here indicates that it is the former. > Unfortunately you've run into one of VMS's few weaknesses. Which quota > is exceeded? Check the disk quota and please report back. It is indeed difficult to figure out which quota triggered SS$_EXQUOTA. But it will not be disk quota... Barring corner cases where exceeding disk quota triggered error processing that tripped over a process quota error and changed the resulting exit code that is presented to the user anyway. ------------------------------ Date: 4 Oct 2007 08:22:48 -0500 From: briggs@encompasserve.org Subject: Re: backup problem Message-ID: <2ryKnUUJT4Qd@eisner.encompasserve.org> In article , JF Mezei writes: > jhjr4381 wrote: >>> %BACKUP-F-WRITEERR, error writing DKA100:[BACKUP]DUA510FUL.LOG;202 >> -RMS-E-EXT, ACP file extend failed >> -SYSTEM-F-EXQUOTA, process quota exceeded > > From a programming point of view: > > would it be fair to state that BACKUP was doing a simple "write" > (SYS$PUT or whatever) and it got a "RMS-E-EXT" status code and then > called LIB$SIGNAL with it own error message (the WRITEERR) and the > RMS-E-EXT status code it got from LIB$PUT ? No. An unhandled exception would have triggered the "unhandled condition, image exit forced" exit path. That's noticably ugly and not the kind of thing that you usually expect VMS utilities to produce. A handled exception would have required that BACKUP field the exception and use $PUTMSG or similar with the associated message vector. That's somewhat plausible. But it doesn't help with your question of how BACKUP got the %SYSTEM-F-EXQUOTA status in the first place. > I am curious as the mechanism that resulted in the underlying error code > (EXQUOTA) to be included in the LIB$SIGNAL output ? That's easy enough. If you do an RMS call, you get back a return status. And you get a field in the associated RMS control block (FAB, RAB or whatever), RMS$L_STV, that contains the underlying status code. > Or does the fact that multiple error messages was issued mean that > BACKUP called LIB$PUT with a error procedure and the later would have > had access to an error vector that would have contained both the EXQUOTA > and the RMS-E-EXT ? BACKUP isn't likely to be using LIB$ routines to write data to the log file or list file. It's going to be using RMS directly. So it's going to have access to the STV field directly. ------------------------------ Date: Thu, 04 Oct 2007 12:54:19 -0400 From: JF Mezei Subject: Re: backup problem Message-ID: briggs@encompasserve.org wrote: > It is indeed difficult to figure out which quota triggered SS$_EXQUOTA. Well, we know it happened while the file system tried to enlarge a log file to fit an extra record being written by the application (backup). By following what the ACP does while extending a file, one might be able to get a clue as to what resources/quotas are being used up. ------------------------------ Date: Thu, 04 Oct 2007 10:35:31 -0700 From: jhjr4381 Subject: Re: backup problem Message-ID: <1191519331.338752.282160@g4g2000hsf.googlegroups.com> On Oct 3, 9:52 pm, AEF wrote: > On Oct 3, 6:57 pm, AEF wrote: > > > On Oct 3, 4:14 pm, jhjr4381 wrote: > > > > I'm still getting an error while running BACKUP, as follows(ALPHA VMS > > > 6.2-1h3 ): > > > > $ BACKUP/NOREWIND/LIST=DKA100:[BACKUP]DUA510FUL.LOG/IMAGE - > > > /NOALIAS - > > > /RECORD/IGNORE=(INTERLOCK,LABEL)/NOASSIST $1$DUA510: - > > > RDAXP$MKB500:DUA510.BCK > > > %BACKUP-F-WRITEERR, error writing DKA100:[BACKUP]DUA510FUL.LOG;202 > > > -RMS-E-EXT, ACP file extend failed > > > -SYSTEM-F-EXQUOTA, process quota exceeded > > > > I understand that this /LIST file DKA100:[BACKUP]DUA510FUL.LOG is a > > > listing of files stored in the save-set. > > Correct. > > > > However, I'm at a loss as to how to determine which "process" QUOTA is > > > being exceeded here. It looks like backup was trying to make the file > > > larger in order to write to it, but failed to do so (maybe). > > I think it may be a disk quota. Use the SHOW QUOTA/DISK=disk/USER=user > command to see. > > Unfortunately you've run into one of VMS's few weaknesses. Which quota > is exceeded? Check the disk quota and please report back. > > > > Is this an error because I need x blocks of contiguous space (to > > > extend the file)? > > > I doubt it. You could run ANAL/DISK and see if there are any > > filesystem errors, but I don't think that's your problem. Hmmm, could > > it be disk quota?! Run the SHOW QUOTA command to see. I think that > > would do it! > > > > Did this error stop the backup, or just the writing to this .log file? > > > Being a Fatal error, it probably stopped the backup, as another poster > > pointed out. > > You can check by mounting the tape (write-protected!) and running > > $ BACKUP/LIST > > and see if it abruptly ends on error or gives you the expected full > listing. > > [...] > > AEF aef - I don't know what happened, but I replied erlier and the response disappeared. I have now quotas on the disk so that's not an issue. After submitting this yesterday, I changed the system account as such (according to the sysmgr's manual on backup processing) and still have the problem: Maxjobs: 0 Fillm: 1000 Bytlm: 300000 Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0 Maxdetach: 0 BIOlm: 1100 JTquota: 4096 Prclm: 10 DIOlm: 500 WSdef: 4096 Prio: 4 ASTlm: 600 WSquo: 40000 Queprio: 0 TQElm: 40 WSextent: 165000 CPU: (none) Enqlm: 2000 Pgflquo: 500000 I also checked the calculations in Richhard Gilberts .com file above against what I had reconfigured the system account to and they're close. I may have fudged things slightly higher. I'll check other responses on the board as well. BTW - I did increase the diolm/biolm/bytlm etc that you mentioned the other day as well. thanks all! ------------------------------ Date: 4 Oct 2007 12:37:47 -0500 From: briggs@encompasserve.org Subject: Re: backup problem Message-ID: In article , JF Mezei writes: > briggs@encompasserve.org wrote: >> It is indeed difficult to figure out which quota triggered SS$_EXQUOTA. > > > Well, we know it happened while the file system tried to enlarge a log > file to fit an extra record being written by the application (backup). > > By following what the ACP does while extending a file, one might be able > to get a clue as to what resources/quotas are being used up. There's a standard strategy in cases like this: Swap out each tire until you find the one that's flat. i.e. Increase the quotas one at a time until the problem goes away. Personally, I favor a binary search. Increase all the quotas. If the problem goes away and you still care, decrease half of them and try again. Repeat as needed. That or use some of the excellent suggestions elsewhere in this thread. ------------------------------ Date: Thu, 04 Oct 2007 06:45:00 -0700 From: FrankS Subject: CIXCD jumpers Message-ID: <1191505500.125282.3430@y42g2000hsy.googlegroups.com> Does anyone know where I can find information on setting the CIXCD node number jumpers? I have to renumber the CI port assignments on CIPCA and CIXCD adapters. I found the CIPCA guide, but no joy on the CIXCD. I understand it's a mechanical jumper somewhere on the backplane, but that's all I can dig up. Any help would be appreciated. ------------------------------ Date: Thu, 4 Oct 2007 10:43:54 -0400 From: "Jeff Goodwin" Subject: Re: CIXCD jumpers Message-ID: <4704fc42$0$24253$4c368faf@roadrunner.com> "FrankS" wrote in message news:1191505500.125282.3430@y42g2000hsy.googlegroups.com... > Does anyone know where I can find information on setting the CIXCD > node number jumpers? > > I have to renumber the CI port assignments on CIPCA and CIXCD > adapters. I found the CIPCA guide, but no joy on the CIXCD. I > understand it's a mechanical jumper somewhere on the backplane, but > that's all I can dig up. > > Any help would be appreciated. > The CIXCD jumpers are in here for the XMI bus: http://deathrow.vistech.net/~cvisors/DEC94MDS/600ebin2.pdf -Jeff ------------------------------ Date: Thu, 04 Oct 2007 03:31:45 -0700 From: urbancamo Subject: Re: compatible disk for vaxstation 4000 model 90 Message-ID: <1191493905.343764.136990@r29g2000hsg.googlegroups.com> Hi, A google search didn't reveal much - can you tell us what size the drive is, interface type, whether you used an adapter (what brand if so), and what version of OpenVMS you are running. I have had varying success with drives on my model 4000/90. My DEC 3000/600 supports a lot more models. Regards, Mark. ------------------------------ Date: Thu, 04 Oct 2007 03:37:59 -0700 From: urbancamo Subject: Re: compatible disk for vaxstation 4000 model 90 Message-ID: <1191494279.326548.78630@k79g2000hse.googlegroups.com> OK, Sorry, I found it when I searched for HP C2490-60062. HP C2490-60062 2.1GB SCSI-2 Fast 3.5" 50-Pin Narrow Hard Drive (C249060062) This drive must have been manufactured by HP before their acquisition of DEC. I've had good success with various Seagate 50 pin drives upto about 9 GB capacity on my 4000/90. I believe Seagate made most of the DEC branded drives. Look out for any whose mode number ends in 'N' (ST*N) - these are 50 pin narrow SCSI models. Thanks for the info, Mark. ------------------------------ Date: Thu, 04 Oct 2007 05:41:20 -0700 From: "Tom Linden" Subject: Re: compatible disk for vaxstation 4000 model 90 Message-ID: On Thu, 04 Oct 2007 03:31:45 -0700, urbancamo wrote: > Hi, > > A google search didn't reveal much - can you tell us what size the > drive is, interface type, whether you used an adapter (what brand if > so), and what version of OpenVMS you are running. > > I have had varying success with drives on my model 4000/90. My DEC > 3000/600 supports a lot more models. > > Regards, > > Mark. > What is the problem? I think I could put almost any SCSI drive in mine. -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: 4 Oct 2007 10:39:47 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: despair Message-ID: <5mju7jFdkjtjU1@mid.individual.net> In article , "P. Sture" writes: > In article , > VAXman- @SendSpamHere.ORG wrote: > >> Q: What is the difference between a law(ie)yer and a pile of shit? > > ??? Dunno. That one has me stumped. Nothing. 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: Thu, 04 Oct 2007 03:00:38 -0400 From: JF Mezei Subject: Re: DFU on the freeware disks Message-ID: <711b8$47048f9e$cef8887a$32018@TEKSAVVY.COM> Jur van der Burg wrote: > > No OpenVMS VAX. Is it really that hard to write portable code? > > Not at all, it's called progress. Support for 64-bit things on > Vax is tricky and not worth the effort, to name one thing. Senior HP execs have been on record (including a recent statement from Ann Livermore) that they are focusing on the installed base for VMS, hoping they will stay with HP when they migrate from VMS. So not many new customers are to be expected, and many alpha customers will be moving to other computer suppliers when their current software package is no longer available on VMS (many examples have been pointed to in recent months right here, including Cerner). Those still on VAX are still on VAX because they can't migrate. Based on what I have been told, the VAX installed base is between 25% and 33% of the total VMS installed base. Not something to sneer at. Since nobody is focusing on attracting new customers or new markets, one would presume that the focus would be on the installed base, and since VAX represents a very sizeable chunk of the installed base, ignoring it might be dangerous. Then again, with the downsizing of VMS engineering probably happening faster than the downsizing of the installed base, it may not be an issue for very long. ------------------------------ Date: Thu, 04 Oct 2007 02:47:06 -0700 From: IanMiller Subject: Re: DFU on the freeware disks Message-ID: <1191491226.185136.76650@g4g2000hsf.googlegroups.com> On Oct 4, 8:00 am, JF Mezei wrote: > Jur van der Burg wrote: > > > > No OpenVMS VAX. Is it really that hard to write portable code? > > > Not at all, it's called progress. Support for 64-bit things on > > Vax is tricky and not worth the effort, to name one thing. > > Senior HP execs have been on record (including a recent statement from > Ann Livermore) that they are focusing on the installed base for VMS, > hoping they will stay with HP when they migrate from VMS. So not many > new customers are to be expected, and many alpha customers will be > moving to other computer suppliers when their current software package > is no longer available on VMS (many examples have been pointed to in > recent months right here, including Cerner). Those still on VAX are > still on VAX because they can't migrate. > > Based on what I have been told, the VAX installed base is between 25% > and 33% of the total VMS installed base. Not something to sneer at. > > Since nobody is focusing on attracting new customers or new markets, one > would presume that the focus would be on the installed base, and since > VAX represents a very sizeable chunk of the installed base, ignoring it > might be dangerous. Then again, with the downsizing of VMS engineering > probably happening faster than the downsizing of the installed base, it > may not be an issue for very long. DFU was created by someone in their own time. It is up to them how they choose to direct their effort not HP. ------------------------------ Date: Thu, 04 Oct 2007 11:59:44 +0200 From: Jur van der Burg <"vdburg at hotmail dot com"> Subject: Re: DFU on the freeware disks Message-ID: <4704b9fa$0$234$e4fe514c@news.xs4all.nl> I'm not ignoring the Vax base, DFU runs perfectly fine on Vax although it's not the latest version. Spending loads of time keeping a Vax version on par with Alpha or Ia64 is not high on my list of things, and it would prevent using new things that are possible on Alpha/Ia64 and not on Vax. Fwiw, Jur. JF Mezei wrote, On 4-10-2007 9:00: > Jur van der Burg wrote: >> > No OpenVMS VAX. Is it really that hard to write portable code? >> >> Not at all, it's called progress. Support for 64-bit things on >> Vax is tricky and not worth the effort, to name one thing. > > > Senior HP execs have been on record (including a recent statement from > Ann Livermore) that they are focusing on the installed base for VMS, > hoping they will stay with HP when they migrate from VMS. So not many > new customers are to be expected, and many alpha customers will be > moving to other computer suppliers when their current software package > is no longer available on VMS (many examples have been pointed to in > recent months right here, including Cerner). Those still on VAX are > still on VAX because they can't migrate. > > Based on what I have been told, the VAX installed base is between 25% > and 33% of the total VMS installed base. Not something to sneer at. > > Since nobody is focusing on attracting new customers or new markets, one > would presume that the focus would be on the installed base, and since > VAX represents a very sizeable chunk of the installed base, ignoring it > might be dangerous. Then again, with the downsizing of VMS engineering > probably happening faster than the downsizing of the installed base, it > may not be an issue for very long. ------------------------------ Date: Thu, 04 Oct 2007 02:51:27 -0700 From: IanMiller Subject: Re: DSPP PAK diffs I64/Alpha Message-ID: <1191491487.076764.63150@57g2000hsv.googlegroups.com> On Oct 3, 5:08 pm, "Tom Linden" wrote: > FYI, made a list paks in Alpha but not IA64http://www.kednos.com/missing.txt > > -- > PL/I for OpenVMSwww.kednos.com This is just a differences list. This does not account for licences you no longer need like DCPS or that VAXSET is included so separate licences for DTM, LSE are not needed. VMS-USER is not needed. UCX is included in the FOE. and so on ------------------------------ Date: Thu, 04 Oct 2007 10:33:20 -0700 From: "Tom Linden" Subject: getting MAC in 7.3 Message-ID: In 8.3 I can say REX> write sys$output f$getdvi("EWA0","LAN_DEFAULT_MAC_ADDRESS") 00-30-6E-4C-9A-FB How do you find it in earlier versions -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Thu, 04 Oct 2007 05:48:00 -0700 From: "Tom Linden" Subject: Re: Guidance with OpenVMS IA64 8.3 with Java 1.5 Problems Message-ID: On Wed, 03 Oct 2007 13:54:09 -0700, wrote: > On 3 oct, 15:22, "Tom Linden" wrote: >> On Mon, 01 Oct 2007 22:00:46 -0700, wrote: >> > Note that the architecture of Itanium and Java are big memory >> > consumers. 256 Mb ram on Intel x86 32bits is roughly equivalent to 4 >> > Gb ram on Itanium. >> >> How would you compare it Alpha? >> >> -- >> PL/I for OpenVMSwww.kednos.com > > > ~ 1 Gb ram on Alpha > Makes you wonder where mangement was at the first design review. Reminds me of an event at Boeing in the mid 60s, A team was presenting their concept for a new aircraft, when a VP asked one of them how many engines there were, the presenter responded 5, The VP told him to sit down, "We don't build aircraft with 5 engines" -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Thu, 04 Oct 2007 10:39:12 -0700 From: Malcolm Dunnett Subject: Problems with KGPSA-B and 2gb Fibrechannel Message-ID: <47052541$1@flight> Alphaserver DS20, VMS 7.3-2, Console firmware 7.3, KGPSA-B firmware 3.20x7 I know it's not supported but just for the benefit of hobbyists or others looking to extend the life of older systems I thought I'd post my experience with trying to get a KGPSA-B (Emulex Lp7000) to talk to a Brocade 2gb fibre switch. The problem appears at the console level (ie with trying to set up the system to boot from a disk connected to the 2gb switch via a KGPSA-B). What I observed was inconsistent and drove me nuts for a while trying to figure out if I had bad cables, etc. If one tries to use wwidmgr to set up a mapping ( eg wwidmgr -quickset -udid nnn) to a drive under this configuration you may get a "timeout probing pgx0" error, or it may appear to work (ie show you the drive mappings). Trying the command several times will produce one of these results in an apparently random fashion. Even if wwidmgr appears to work it was my experience that when I did the reset afterwards the disks would not appear at the console level, even though their parameters were stored in the console variables. Replacing the 2gb switch with a 1gb switch made the problem go away, as did replacing the KGPSA-B with a KGPSA-C (LP8000). Interestingly, if one boots the system some other way VMS is able to see the drives on the KGPSA-B/2gb switch combination and appears to access them with no problems (so it's really an Alphaserver console problem rather than a VMS issue). ------------------------------ Date: Thu, 04 Oct 2007 06:44:22 -0700 From: etmsreec@yahoo.co.uk Subject: Re: SmartArray errors on system boot Message-ID: <1191505462.667462.80830@50g2000hsm.googlegroups.com> On 3 Oct, 21:43, "David Turner, Island Computers" wrote: > Are your disks HP/Compaq firmwared disks? > Are they all identical sizes? > > wrote in message > > news:1191425849.767217.202610@57g2000hsv.googlegroups.com... > > > > > Hiya, > > > I've got about five logs open with support at the moment, but I'm > > wondering if anyone else has experienced similar... > > > I've got a mix of 5302A and 6402A SmartArray cards in Alphas and, more > > recently, a couple of A9890A 6402 SmartArrays in a couple of Integrity > > servers (one per server). > > > When the system boots, the system logs errors against the PK port > > device (SCSI bus resets maybe?) then, usually, calms down and behaves > > itself. The disks never log any errors. > > > At first we thought maybe a bad card. When a second one did it we > > thought maybe the MSA30 shelves that they are connected to were the > > culprits, maybe having their interface cards damaged in transit. This > > weekend, we had problems on an Integrity which has caused the other > > SmartArray and MSA30 installations that were planned to be pulled, > > pending a response from HP. > > > Anybody seen this kind of behaviour before? > > > Full config is VMS (either Alpha or I64), 8.2 on Alpha and 8.3 on > > I64. RAID software v3.0 on both platforms to enable us to partition > > the disk that the SmartArray is configured with so that we can size > > the DPA devices that VMS sees appropriately. > > > Thanks in advance > > > Steve- Hide quoted text - > > - Show quoted text - Yes to both David - some have 36GB hot pluggable disks on, other have 73GB. Steve ------------------------------ Date: Thu, 4 Oct 2007 10:05:43 -0400 From: "Jilly" Subject: Re: SmartArray errors on system boot Message-ID: <4704f2a5$0$24906$ec3e2dad@news.usenetmonster.com> wrote in message news:1191425849.767217.202610@57g2000hsv.googlegroups.com... > Hiya, > > I've got about five logs open with support at the moment, but I'm > wondering if anyone else has experienced similar... > > I've got a mix of 5302A and 6402A SmartArray cards in Alphas and, more > recently, a couple of A9890A 6402 SmartArrays in a couple of Integrity > servers (one per server). > > When the system boots, the system logs errors against the PK port > device (SCSI bus resets maybe?) then, usually, calms down and behaves > itself. The disks never log any errors. > > At first we thought maybe a bad card. When a second one did it we > thought maybe the MSA30 shelves that they are connected to were the > culprits, maybe having their interface cards damaged in transit. This > weekend, we had problems on an Integrity which has caused the other > SmartArray and MSA30 installations that were planned to be pulled, > pending a response from HP. > > Anybody seen this kind of behaviour before? > > Full config is VMS (either Alpha or I64), 8.2 on Alpha and 8.3 on > I64. RAID software v3.0 on both platforms to enable us to partition > the disk that the SmartArray is configured with so that we can size > the DPA devices that VMS sees appropriately. > > Thanks in advance > > Steve > Can you show us what the errorlog entries are? From my vague recollection you may get 1 or 2 SCSI Bus Resets logged at boot time as the IO autoconfig mechanism triggers these and they end up getting logged by the device drivers to the EMBs and ERRFMT then dumps those when it starts. We used to field a number of calls like this in shared SCSI bus configs. ------------------------------ Date: Thu, 4 Oct 2007 11:02:06 -0400 From: "David Turner, Island Computers" Subject: Re: SmartArray errors on system boot Message-ID: I assume you have these set correctly On a 5302a >>>set heap_expand 2MB On a 5304a >>>set heap_expand 4MB Also the set command is correct >>>set bootbios pya0 DT wrote in message news:1191425849.767217.202610@57g2000hsv.googlegroups.com... > Hiya, > > I've got about five logs open with support at the moment, but I'm > wondering if anyone else has experienced similar... > > I've got a mix of 5302A and 6402A SmartArray cards in Alphas and, more > recently, a couple of A9890A 6402 SmartArrays in a couple of Integrity > servers (one per server). > > When the system boots, the system logs errors against the PK port > device (SCSI bus resets maybe?) then, usually, calms down and behaves > itself. The disks never log any errors. > > At first we thought maybe a bad card. When a second one did it we > thought maybe the MSA30 shelves that they are connected to were the > culprits, maybe having their interface cards damaged in transit. This > weekend, we had problems on an Integrity which has caused the other > SmartArray and MSA30 installations that were planned to be pulled, > pending a response from HP. > > Anybody seen this kind of behaviour before? > > Full config is VMS (either Alpha or I64), 8.2 on Alpha and 8.3 on > I64. RAID software v3.0 on both platforms to enable us to partition > the disk that the SmartArray is configured with so that we can size > the DPA devices that VMS sees appropriately. > > Thanks in advance > > Steve > ------------------------------ Date: Thu, 04 Oct 2007 08:04:22 -0700 From: etmsreec@yahoo.co.uk Subject: Re: SmartArray errors on system boot Message-ID: <1191510262.273359.16290@22g2000hsm.googlegroups.com> On 4 Oct, 16:02, "David Turner, Island Computers" wrote: > I assume you have these set correctly > > On a 5302a > > >>>set heap_expand 2MB > > On a 5304a > > >>>set heap_expand 4MB > > Also the set command is correct > > >>>set bootbios pya0 > > DT > > wrote in message > > news:1191425849.767217.202610@57g2000hsv.googlegroups.com... > > > > > Hiya, > > > I've got about five logs open with support at the moment, but I'm > > wondering if anyone else has experienced similar... > > > I've got a mix of 5302A and 6402A SmartArray cards in Alphas and, more > > recently, a couple of A9890A 6402 SmartArrays in a couple of Integrity > > servers (one per server). > > > When the system boots, the system logs errors against the PK port > > device (SCSI bus resets maybe?) then, usually, calms down and behaves > > itself. The disks never log any errors. > > > At first we thought maybe a bad card. When a second one did it we > > thought maybe the MSA30 shelves that they are connected to were the > > culprits, maybe having their interface cards damaged in transit. This > > weekend, we had problems on an Integrity which has caused the other > > SmartArray and MSA30 installations that were planned to be pulled, > > pending a response from HP. > > > Anybody seen this kind of behaviour before? > > > Full config is VMS (either Alpha or I64), 8.2 on Alpha and 8.3 on > > I64. RAID software v3.0 on both platforms to enable us to partition > > the disk that the SmartArray is configured with so that we can size > > the DPA devices that VMS sees appropriately. > > > Thanks in advance > > > Steve- Hide quoted text - > > - Show quoted text - Yup, we've set those. S. ------------------------------ Date: Thu, 4 Oct 2007 11:32:56 -0400 From: "David Turner, Island Computers" Subject: Re: SmartArray errors on system boot Message-ID: Firmware version? DT wrote in message news:1191510262.273359.16290@22g2000hsm.googlegroups.com... > On 4 Oct, 16:02, "David Turner, Island Computers" islandco.com> wrote: >> I assume you have these set correctly >> >> On a 5302a >> >> >>>set heap_expand 2MB >> >> On a 5304a >> >> >>>set heap_expand 4MB >> >> Also the set command is correct >> >> >>>set bootbios pya0 >> >> DT >> >> wrote in message >> >> news:1191425849.767217.202610@57g2000hsv.googlegroups.com... >> >> >> >> > Hiya, >> >> > I've got about five logs open with support at the moment, but I'm >> > wondering if anyone else has experienced similar... >> >> > I've got a mix of 5302A and 6402A SmartArray cards in Alphas and, more >> > recently, a couple of A9890A 6402 SmartArrays in a couple of Integrity >> > servers (one per server). >> >> > When the system boots, the system logs errors against the PK port >> > device (SCSI bus resets maybe?) then, usually, calms down and behaves >> > itself. The disks never log any errors. >> >> > At first we thought maybe a bad card. When a second one did it we >> > thought maybe the MSA30 shelves that they are connected to were the >> > culprits, maybe having their interface cards damaged in transit. This >> > weekend, we had problems on an Integrity which has caused the other >> > SmartArray and MSA30 installations that were planned to be pulled, >> > pending a response from HP. >> >> > Anybody seen this kind of behaviour before? >> >> > Full config is VMS (either Alpha or I64), 8.2 on Alpha and 8.3 on >> > I64. RAID software v3.0 on both platforms to enable us to partition >> > the disk that the SmartArray is configured with so that we can size >> > the DPA devices that VMS sees appropriately. >> >> > Thanks in advance >> >> > Steve- Hide quoted text - >> >> - Show quoted text - > > Yup, we've set those. > > S. > ------------------------------ Date: Thu, 4 Oct 2007 11:41:56 +0200 From: "Dr. Dweeb" Subject: Re: still not convinced global warming a hoax? Message-ID: <4704b566$0$21924$157c6196@dreader1.cybercity.dk> ultradwc@gmail.com wrote: > http://www.worldnetdaily.com/news/article.asp?ARTICLE_ID=57949 Yeah, I saw this one. Falsification of bad science is the hallmark of science. And so it goes ... (Kurt V). CO2 != pollution What, me worry? Dweeb ------------------------------ Date: 4 Oct 2007 16:48:53 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: still not convinced global warming a hoax? Message-ID: <5mkjrlFdvqmgU1@mid.individual.net> In article , JF Mezei writes: > Question: > > In my mind, a religious person has always been a compassionate person > willing to share wealth, help others, live a good honest life and make > sure to protect god's creations (wether humans or animals or the planet). Al-Qaeda is full of "religious" persons. 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: 4 Oct 2007 06:08:32 -0500 From: clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) Subject: Re: We're VMS - Please do not discuss the outside world Message-ID: In article , "P. Sture" writes: > > example 2: > > comp.os.vms "stealth marketing" > > 63 results Try group:comp.os.vms "stealth marketing" I get 206 results. In your first example, google appears to be searching for messages which contain comp.os.vms within the message body. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980's technology to a 21st century world ------------------------------ Date: 4 Oct 2007 06:14:20 -0500 From: clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) Subject: Re: We're VMS - Please do not discuss the outside world Message-ID: In article , "Richard Maher" writes: > > PS. Why is VMS's customer base disappearing again? > Lack of marketing and applications. Linux with both a CLI and GUI environment doesn't seem to have a problem in this area - people can choose whatever mode of operation (GUI/CLI) they prefer and still get the job done. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980's technology to a 21st century world ------------------------------ End of INFO-VAX 2007.542 ************************