INFO-VAX Thu, 11 Jan 2007 Volume 2007 : Issue 21 Contents: Re: 1,000,000 License PAK's Served! Re: Cluster connection lost when one link fails? CSWB & Video cards, etc. Re: CSWB & Video cards, etc. Re: CSWB & Video cards, etc. Re: CSWB & Video cards, etc. Re: Finding textual information about a device and device driver Re: Finding textual information about a device and device driver Re: INIT volume /VOLUME_CHAR=NOACCESS_DATES fails. Re: KSC CAMAC/VXI OpenVMS drivers Public Release Re: MONITOR X-axis change Re: Need help setting IP address on DS20 (VMS 7.3) Re: Need help setting IP address on DS20 (VMS 7.3) Re: Need help setting IP address on DS20 (VMS 7.3) Re: On-shoring of VMS support?? Re: On-shoring of VMS support?? Re: On-shoring of VMS support?? Re: Star Trek and $CONFIGURE GALAXY Re: Strategy for common DECNET proxy files in cluster ? Re: Stuck TCPIP connections Re: VMS732_UPDATE-V0900 fails Re: VMS732_UPDATE-V0900 fails ---------------------------------------------------------------------- Date: Wed, 10 Jan 2007 20:22:33 +0100 From: martin@radiogaga.harz.de (Martin Vorlaender) Subject: Re: 1,000,000 License PAK's Served! Message-ID: <45a53cf9.524144494f47414741@radiogaga.harz.de> Bob Koehler wrote: > davidc@montagar.com writes: >> The OpenVMS Hobbyist Program has served it's one millionth License PAK! >> >> http://www.openvmshobbyist.com/blog/index.php > > Does the hobbyist with the 1,000,000'th PAK get a prise? I must have > just missed it. Yes. See www.openvms.org/stories.php?story=07/01/08/4315888 cu, Martin -- Emacs would be a great | Martin Vorlaender | OpenVMS rules! operating system, | work: mv@pdv-systeme.de if only it came with | http://www.pdv-systeme.de/users/martinv/ a decent editor... | home: martin@radiogaga.harz.de ------------------------------ Date: Wed, 10 Jan 2007 12:45:49 -0800 From: "Malcolm Dunnett" Subject: Re: Cluster connection lost when one link fails? Message-ID: <45a54fbb$1@flight> "Roy Omond" wrote in message news:jhivQWXElAFR@eisner.encompasserve.org... > In article <45a420a8$1@flight>, "Malcolm Dunnett" > writes: > > I'm a bit confused/worried. > > Is the patch addressing the issue *solely* for the DE500 ? > > I've observed this problem with DEGXAs, so it would appear to be not > restricted to DE500s. Maybe it's generic in all Ethernet drivers ? > I only received a new DE500 driver. I don't have any DEGXA's so I can't comment on them. ------------------------------ Date: Wed, 10 Jan 2007 15:58:41 -0800 From: Ken Fairfield Subject: CSWB & Video cards, etc. Message-ID: <50lctuF1gs4rrU1@mid.individual.net> This post from DT got me thinking: Island Computers, D B Turner wrote: > I believe the Itanium is 1920 x 1440 24 Bit > > Other cards > > > ELSA Gloria Synergy 1280 x 1024 24 Bit *(there is wobble on the side of > screen at 24bit so 16Bit is really the max) > Permedia 2 Island Branded (same as above) > ATI Radeon 7500 PCI Card (1920 x 1440 24Bit) > S3Trio 64 2MB 800 x 600 16 Bit > Powerstorm 3D30 1280 x 1024 8 Bit > Powerstorm 4D20 1280 x 1024 16 Bit > Oxygen vx1 32mb pci 1600 X 1200 > > > That's about all that is affordable > I have a Permedia-2 in my PWS600au, and after a good bunch of upgrading and product installs, I now have functioning CSWB on VMS/Alpha 8.3. However, the color shading on the CSWB buttons, and indeed, on embedded color graphics (jpegs, etc.) is pretty poor compared to a standard PC or Mac. So I looked at the DECW$SERVER_0_ERROR.LOG file and found the Permedia-2 was coming up in 8-bit mode ("depth 8"). I then poked around and found that DECW$DECICE_CONFIG_GZ.COM was setting this as the default depth, but that I could change it by defining an appropriate logical name, so: $ ! The available depth and resolution is monitor dependent. Each $ ! head can have its own pixel depth. $ ! $ ! Pixel depth default is 8BPP. It can be changed to 24 BPP. $ ! $ ! define/exec/system/nolog decw$server_pixel_depth 8,8,8,8,8,8,8,8 $ define/exec/system/nolog decw$server_pixel_depth 16 $ ! I chose 16BPP because of what David had written and also because that is listed as the maximum resolution on this the web page: http://h18002.www1.hp.com/alphaserver/products/graphics/au/ Now I get this in the .LOG file: -------------------------------------------------------------------- Permedia-2 (PowerStorm 4D10T) Server DDX for OpenVMS Copyright © 1999, 2004 Hewlett-Packard Development Company, L.P. All Rights Reserved. Compiled on Jun 29 2006, at 18:33:57 Permedia-2: Init Screen Number 0 Permedia-2: User specified pixel depth: 16 Permedia-2: Invalid pixel depth 16 specified by user Permedia-2: Changing pixel depth to 8 Permedia-2: Screen X 1280, Screen Y 1024, vsync 60 Hz, depth 8, density 100 [...] cometInitProc: Call cometInitVisuals cometInitProc: Visuals Information: - Root depth 8 - Number of depths 2 - Number of visuals 6 - Root Visual 0x21 Permedia-2 on screen 0: Hardware acceleration for text disabled Permedia-2: Setup console for this device ------------------------------------------------------------------ So I'm still stuck at 8bits. I'll try 24bits shortly, but I wonder of there's something else I'm missing? Thanks, Ken -- Ken & Ann Fairfield where: Gmail dot Com who: Ken dot And dot Ann ------------------------------ Date: Wed, 10 Jan 2007 19:56:34 -0600 From: "Craig A. Berry" Subject: Re: CSWB & Video cards, etc. Message-ID: In article <50lctuF1gs4rrU1@mid.individual.net>, Ken Fairfield wrote: > I have a Permedia-2 in my PWS600au, and after a good bunch of > upgrading and product installs, I now have functioning CSWB on > VMS/Alpha 8.3. However, the color shading on the CSWB buttons, > and indeed, on embedded color graphics (jpegs, etc.) is pretty > poor compared to a standard PC or Mac. > > So I looked at the DECW$SERVER_0_ERROR.LOG file and found the > Permedia-2 was coming up in 8-bit mode ("depth 8"). I then > poked around and found that DECW$DECICE_CONFIG_GZ.COM was setting > this as the default depth, but that I could change it by defining > an appropriate logical name, so: > > $ ! The available depth and resolution is monitor dependent. Each > $ ! head can have its own pixel depth. > $ ! > $ ! Pixel depth default is 8BPP. It can be changed to 24 BPP. > $ ! > $ ! define/exec/system/nolog decw$server_pixel_depth 8,8,8,8,8,8,8,8 > $ define/exec/system/nolog decw$server_pixel_depth 16 > $ ! > > I chose 16BPP because of what David had written and also because that > is listed as the maximum resolution on this the web page: > > http://h18002.www1.hp.com/alphaserver/products/graphics/au/ Dunno about 16 bits but 24 should be ok. I've successfully used the following in my DECW$PRIVATE_SERVER_SETUP.COM: $! Set the Resolution X and Y Size in Pixels: $ decw$xsize_in_pixels == 1280 $ decw$ysize_in_pixels == 1024 $! Set the Server Visual Depth: $ define/exec/system/nolog decw$server_pixel_depth 24 $! Set the Vertical Sync Rate (vsync): $ define/exec/system/nolog decw$server_refresh_rate 75 -- Posted via a free Usenet account from http://www.teranews.com ------------------------------ Date: Wed, 10 Jan 2007 19:05:31 -0800 From: Ken Fairfield Subject: Re: CSWB & Video cards, etc. Message-ID: <50lnruF1ggrgnU1@mid.individual.net> Craig A. Berry wrote: > In article <50lctuF1gs4rrU1@mid.individual.net>, > Ken Fairfield wrote: > >> I have a Permedia-2 in my PWS600au, and after a good bunch of >> upgrading and product installs, I now have functioning CSWB on >> VMS/Alpha 8.3. However, the color shading on the CSWB buttons, >> and indeed, on embedded color graphics (jpegs, etc.) is pretty >> poor compared to a standard PC or Mac. >> >> So I looked at the DECW$SERVER_0_ERROR.LOG file and found the >> Permedia-2 was coming up in 8-bit mode ("depth 8"). I then >> poked around and found that DECW$DECICE_CONFIG_GZ.COM was setting >> this as the default depth, but that I could change it by defining >> an appropriate logical name, so: >> >> $ ! The available depth and resolution is monitor dependent. Each >> $ ! head can have its own pixel depth. >> $ ! >> $ ! Pixel depth default is 8BPP. It can be changed to 24 BPP. >> $ ! >> $ ! define/exec/system/nolog decw$server_pixel_depth 8,8,8,8,8,8,8,8 >> $ define/exec/system/nolog decw$server_pixel_depth 16 >> $ ! >> >> I chose 16BPP because of what David had written and also because that >> is listed as the maximum resolution on this the web page: >> >> http://h18002.www1.hp.com/alphaserver/products/graphics/au/ > > Dunno about 16 bits but 24 should be ok. I've successfully used the > following in my DECW$PRIVATE_SERVER_SETUP.COM: > > $! Set the Resolution X and Y Size in Pixels: > $ decw$xsize_in_pixels == 1280 > $ decw$ysize_in_pixels == 1024 > $! Set the Server Visual Depth: > $ define/exec/system/nolog decw$server_pixel_depth 24 > $! Set the Vertical Sync Rate (vsync): > $ define/exec/system/nolog decw$server_refresh_rate 75 OK, that's what I wound up doing, setting it to 24bits, and it works very nicely now: 1280x1024x24bits @ 60hz on a Samsung SyncMaster 172N LCD display. :-) I don't quite understand why the URL above says 16 bits without a 24 bit option. And I don't see any of the negative side-effects that DT mentioned. Thanks! -Ken -- Ken & Ann Fairfield where: Gmail dot Com who: Ken dot And dot Ann ------------------------------ Date: Wed, 10 Jan 2007 22:49:24 -0600 From: "Craig A. Berry" Subject: Re: CSWB & Video cards, etc. Message-ID: In article <50lnruF1ggrgnU1@mid.individual.net>, Ken Fairfield wrote: > Craig A. Berry wrote: > > Dunno about 16 bits but 24 should be ok. I've successfully used the > > following in my DECW$PRIVATE_SERVER_SETUP.COM: > > > > $! Set the Resolution X and Y Size in Pixels: > > $ decw$xsize_in_pixels == 1280 > > $ decw$ysize_in_pixels == 1024 > > $! Set the Server Visual Depth: > > $ define/exec/system/nolog decw$server_pixel_depth 24 > > $! Set the Vertical Sync Rate (vsync): > > $ define/exec/system/nolog decw$server_refresh_rate 75 > > OK, that's what I wound up doing, setting it to 24bits, and > it works very nicely now: 1280x1024x24bits @ 60hz on a Samsung > SyncMaster 172N LCD display. :-) > > I don't quite understand why the URL above says 16 bits without > a 24 bit option. And I don't see any of the negative side-effects > that DT mentioned. It supports 16 bits at its max resolution of 1920 x 1200, but 24 bits at up to 1280 x 1024. I can't say that I know why 16 bits didn't work, buta a more complete discussion of what this card supports is here: http://h71000.www7.hp.com/wizard/wiz_5448.html?jumpid=reg_R1002_USEN -- Posted via a free Usenet account from http://www.teranews.com ------------------------------ Date: Thu, 11 Jan 2007 01:59:24 GMT From: rdeininger@mindspringdot.com (Robert Deininger) Subject: Re: Finding textual information about a device and device driver Message-ID: In article <45a4f213$0$28590$c3e8da3@news.astraweb.com>, JF Mezei wrote: >How does one go about to find out what a particular device and/or device >driver is meant to be doing ? > >For instance, I take a random device on my system SMA0. It is >SYS$SMDRIVER.EXE Looking at the contents of the executable there isn't any >description/hint of what it does. True for device drivers and many other VMS images. >Would I have to buy the sources just to find this out ? Or is there some >file I can search on the system disk that contains a brief description of >each driver that is loaded ? There's no index. SMDRIVER sends requests to the SMHANDLER process, which is described here: http://h71000.www7.hp.com/doc/732FINAL/6668/6668pro_007.html#smhandler ------------------------------ Date: Thu, 11 Jan 2007 02:59:26 GMT From: John Santos Subject: Re: Finding textual information about a device and device driver Message-ID: JF Mezei wrote: > How does one go about to find out what a particular device and/or device > driver is meant to be doing ? > > For instance, I take a random device on my system SMA0. It is > SYS$SMDRIVER.EXE Looking at the contents of the executable there isn't > any description/hint of what it does. > > Would I have to buy the sources just to find this out ? Or is there some > file I can search on the system disk that contains a brief description > of each driver that is loaded ? > > Some drivers are obvious. But others are not. $ help sys_files [sys$ldr] sys$smdriver.exe SYS_FILES [SYS$LDR] SYS$SMDRIVER.EXE Device driver that handles system management events -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: 10 Jan 2007 22:11:41 -0800 From: "Cluster-Karl" Subject: Re: INIT volume /VOLUME_CHAR=NOACCESS_DATES fails. Message-ID: <1168495901.301177.301330@i56g2000hsf.googlegroups.com> The same applies to HARDLINKS, it is also not negatable (in contrast to the help text). regards Kalle ------------------------------ Date: Wed, 10 Jan 2007 18:33:39 -0600 From: "Dirtleg" Subject: Re: KSC CAMAC/VXI OpenVMS drivers Public Release Message-ID: ftp://ftp.ipact.com/Ksc/01/09/2007 09:00PM 6,609,040 kgi10jan07vms.zip 01/09/2007 03:35PM 1,465,012 ksc09jan07.zip "Ian Miller" wrote in message news:1168424933.993869.43870@i56g2000hsf.googlegroups.com... >I looked at the ftp site but could not see > ksc09jan07Vms.zip > ------------------------------ Date: 10 Jan 2007 11:07:53 -0800 From: "Ian Miller" Subject: Re: MONITOR X-axis change Message-ID: <1168456073.209495.15040@o58g2000hsb.googlegroups.com> MONITOR on recent versions of VMS was re-written in another language so it can run on I64 and they can make enhancements to it. ------------------------------ Date: Wed, 10 Jan 2007 21:02:39 -0500 From: "Richard B. Gilbert" Subject: Re: Need help setting IP address on DS20 (VMS 7.3) Message-ID: <6OednRDlycZcBzjYnZ2dnUVZ_rWnnZ2d@comcast.com> Z wrote: > I inherited a DS20 ... I was warned that I would not be able to change > the IP address of it, the warning mentioned that others before me had > tried before, but they always just gave up and let it be. > > Anyway, I *need* to change the IP. > > This was originally a 7.1-2 box, and was upgraded to 7.3 some time back. > > Apparently, perhaps form the upgrade, it's set up in some sort of UCX > compatibility mode - I say that because when I remove the TCP*.DAT and > UCX*.DAT files, and run TCPIP$CONFIG, it creates the TCP*.DAT files > then, also, one UCX dat file. Also, UCX$CONFIG runs TCPIP$CONFIG (after > telling you that it will). > > In TCPIP$CONFIG, there is exactly one interface: IE0. (The SRM > identifies the NIC as EIA0 and TCPIP$CONFIG calls it IE0, if that > matters at all.) > > In TCPIP$CONFIG, I set that interface to IP address 10.210.54.67 (which > I've confirmed is not in use on the subnet), and the mask to > 255.255.255.0. I plug this system into a hub that also has a PC plugged > in (PC's IP is 10.210.54.66). > > I can ping the DS20 from the DS20 (by its name, by its IP and by its > 127.0.0.1 address). > > I cannot ping the PC from the DS20 or the DS20 from the PC (by IP > address). I can ping the other systems in the hub from the PC. > > Have I missed a crucial NIC configuration step? > > Also, I know that on another 7.3 system I worked on, I had to start the > INET driver before I could even see the interfaces with TCPIP SHOW INT. > > But that's not the case on this DS20. Even so, I tried starting INET > and still the pings between the PC and the DS20 all failed. > > Help! What am I doing wrong or forgetting to do? Do you have a link light at both ends? This tells you that you have at least DC connectivity between the hub and DS20. Did you configure anything more than the interface? It's customary to configure things like telnet and ftp if you want to actually use the network for anything! Did you execute SYS$STARTUP:TCPIP$STARTUP.COM? ------------------------------ Date: 10 Jan 2007 18:18:45 -0800 From: "David B Sneddon" Subject: Re: Need help setting IP address on DS20 (VMS 7.3) Message-ID: <1168481925.581099.139460@i39g2000hsf.googlegroups.com> On Jan 11, 1:35 am, Z wrote: [...snip...] > > Help! What am I doing wrong or forgetting to do? You may also need to configure a default gateway... Dave ------------------------------ Date: Wed, 10 Jan 2007 22:08:22 -0500 From: JF Mezei Subject: Re: Need help setting IP address on DS20 (VMS 7.3) Message-ID: <45a5a9aa$0$17836$c3e8da3@news.astraweb.com> Z. wrote: > Yes. I've also tried different cables and different (known good) ports > on the hub, to no avail. What does $MC LANCP SHOW DEV /CHAR say about the ethernet interface ? Also, this may be silly, but are you sure it was plugged into the right plug on the aloha ? (it has 2 ethernet ports) RE: output of the LANCP, make sure the speed and duplex are set right. If on a hub, is that hub capable of 100mbps ? > I've also done a shutdown and an init and then show device. As far as I > can tell, while in the SRM, device EIA0 looks fine. Do you have a BGA0: device created ? If you run: @SYS$MANAGER:TCPIP$DEFINE_COMMANDS you can then use $ifconfig -a This will show your your currently running interfaces. You can also do a $TCPIP SHOW INTERFACE/FULL to get similar information. ------------------------------ Date: Wed, 10 Jan 2007 14:53:04 -0500 From: "Island Computers, D B Turner" Subject: Re: On-shoring of VMS support?? Message-ID: <12qah0vfpio49c1@news.supernews.com> Anyone remember "it ain't arf 'ot mum?" About an entertainment troop in Burma in WWII? I think it was made in the mid to late 70's "Oh Goodness Gracious Me" was one of many Anglo-Indian phrases used. DT -- Island Computers US Corp 2700 Gregory St Savannah GA 31404 Tel: 912 447 6622 x201 Mail: dturner-atnospam-islandco-com (You know what to do with the dashes) "Bob Koehler" wrote in message news:qgfkHNVYMZyC@eisner.encompasserve.org... > In article <45A44C5E.384DE477@spam.comcast.net>, David J Dachtera writes: > > > > Now - how do we get front-page exposure to OpenVMS's woes? Maybe not a similar > > response, but hey - no harm in trying, to my mind. > > Recipe for VMS exposure: > > 1) get rich > 2) but Gartner > 3) push VMS > ------------------------------ Date: Wed, 10 Jan 2007 23:23:01 +0100 From: "Dr. Dweeb" Subject: Re: On-shoring of VMS support?? Message-ID: <45a56745$0$141$157c6196@dreader2.cybercity.dk> Island Computers, D B Turner wrote: > Anyone remember "it ain't arf 'ot mum?" > About an entertainment troop in Burma in WWII? > I think it was made in the mid to late 70's > > "Oh Goodness Gracious Me" was one of many Anglo-Indian phrases used. > I was terribly distressed when I observed the trouble I had wrought. And so on. Why is it so difficult to understand? Read a Dictionary sometime :) Dr. Dweeb > > > DT > > >> In article <45A44C5E.384DE477@spam.comcast.net>, David J Dachtera > writes: >>> >>> Now - how do we get front-page exposure to OpenVMS's woes? Maybe >>> not a similar response, but hey - no harm in trying, to my mind. >> >> Recipe for VMS exposure: >> >> 1) get rich >> 2) but Gartner >> 3) push VMS ------------------------------ Date: Wed, 10 Jan 2007 23:21:01 +0100 From: "Dr. Dweeb" Subject: Re: On-shoring of VMS support?? Message-ID: <45a566cd$0$137$157c6196@dreader2.cybercity.dk> Bob Koehler wrote: > In article <12q821scn2lm4dc@news.supernews.com>, "Island Computers, D > B Turner" writes: >> Either that or those Indians were trained well in the art of >> "yankee-speek" >> > I've had a fellow with an Indian accent specifically ask me as part > of his "almost done now" interview if his accent was acceptable and > his speach understandable. > > I think theIndian call centers tend to pay more for folks with > better pusedo-American English skill. Most Indians learn an > English derived from British colonial days. My British friends > don't speak it. But we understand it perfectly ! That is the difference, the native English English speakers have little problem with Subcontinentals, Aantipodeans, Americans or Liverpudlians ! This is a defining characteristic, and distinguishes us from Americans who - jusdging by the constant flak one sees in the US computer press - have great difficulties understanding anyone other than themselves. Dr. Dweeb. ------------------------------ Date: Wed, 10 Jan 2007 18:13:31 -0600 From: John Subject: Re: Star Trek and $CONFIGURE GALAXY Message-ID: <45A5812B.2090002@comcast.net> Galen wrote: >>However (and I assume this from experience with the GALAXY GUI) that the >>DS10L would only have a primary CPU and there would be nothing that >>could be done with it. >> >> >Having GALAXY enabled on a single instance obviously doesn't buy you >anything in terms of processing power, but it does enable at least some >of the Galaxy related commands and programming features. This allows >one, in at least a limited fashion, to design, test, and execute code >that uses these features. > > That may be true however would I endeavor to write GALAXY code one a single CPU? I think not - I could only imagine stating to management, well it worked in test... It would be an unrealistic test at that - limited testing or career ending? ------------------------------ Date: 10 Jan 2007 14:16:20 -0800 From: "Ian Miller" Subject: Re: Strategy for common DECNET proxy files in cluster ? Message-ID: <1168467380.352847.222590@o58g2000hsb.googlegroups.com> you can have wildcard proxy entries On node WHEEL BIKE::* */DEFAULT would let any username on BIKE map to the same username on WHEEL. so one entry per node in the cluster should do it. ------------------------------ Date: Wed, 10 Jan 2007 23:52:15 GMT From: Rick Jones Subject: Re: Stuck TCPIP connections Message-ID: mckinneyj@saic.com wrote: > There is no timeout for CLOSE_WAIT state sockets - they will remain > until your local application either closes the socket or the image > holding them open runs down. Seeing a socket in this state indicates > that your TCP stack has received a close request from the remote end > but your local software hasn't reciprocated. In this instance since > it appears that the need to close the sockets will never be > satisfied, therefore it is likely that you have a bug in your local > software. Spot-on. The only thing I would add is that CLOSE_WAIT is a perfectly-valid "send-only" state for a TCP endpoint (the corresponding recv-only state is FIN_WAIT_2). It is just exceedingly rare that applications use this. If the remote end of the connection has gone-away completely, and _if_ keepalives are enabled on the connection, then the keepalive mechanism may cull CLOSE_WIAT (or FIN_WAIT_2) connections. However, even if that happens unless the application calls close() (or its platform-specific equivalent) the keepalive mechanism, while culling the _TCP_ portion of the connection will not cull something like a file descriptor associated with the connection. If the FIN_WAIT_2 end _is_ still there, then the TCP keepalive mechanism will _not_ cull the connection... rick jones used to spin backup tapes on an SAIC contract to NRL :) -- The glass is neither half-empty nor half-full. The glass has a leak. The real question is "Can it be patched?" these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ------------------------------ Date: Wed, 10 Jan 2007 11:43:22 -0800 From: Joe Bloggs Subject: Re: VMS732_UPDATE-V0900 fails Message-ID: <1pfaq2teq1dv6p3dra84qenvlb614jpei0@4ax.com> On Tue, 09 Jan 2007 20:32:54 -0600, David J Dachtera wrote: >I'm consistently getting this when trying to apply VMS732_UPDATE-V0900 on my >AlphaStation 200 4/233: >.... >Portion done: 0%...10%...20%...30%...40%...50%...60%...70%...80% >%PCSI-I-PRCOUTPUT, output from subprocess follows ... >%LIBRAR-F-WRITEERR, error writing DISK$ALPHASYS:[SYS0.SYSCOMMON.][SYSLIB]STARLET >.OLB;1 >-SYSTEM-F-EXQUOTA, process quota exceeded >... >I've increased my UAF process limits to some fairly high values: > the sysgen PQL params take precedence over the UAF values, for detached processes, and subprocesses (iirc). I'd suggest jacking the PQL params as well (most are dynamic). pgflquo, as suggested by others, is a good one to try; as there might be a mem alloc failure deep in the food chain, not noted or flagged, if resources were already low. Maybe also look at the quotas pooled btw the master/owner process and the subprocesses. other things to try: the PQUOTA tool (monitor the subproc from another terminal). that, and turn up the logging/verbosity on PRODUCT INSTALL (/LOG /TRACE) ------------------------------ Date: 10 Jan 2007 12:16:47 -0800 From: "johnhreinhardt@yahoo.com" Subject: Re: VMS732_UPDATE-V0900 fails Message-ID: <1168460207.085352.277030@i39g2000hsf.googlegroups.com> David J Dachtera wrote: > I'm consistently getting this when trying to apply VMS732_UPDATE-V0900 on my > AlphaStation 200 4/233: > > Execution phase starting ... > > The following product will be installed to destination: > DEC AXPVMS VMS732_UPDATE V9.0 DISK$ALPHASYS:[VMS$COMMON.] > > Portion done: 0%...10%...20%...30%...40%...50%...60%...70%...80% > %PCSI-I-PRCOUTPUT, output from subprocess follows ... > %LIBRAR-F-WRITEERR, error writing DISK$ALPHASYS:[SYS0.SYSCOMMON.][SYSLIB]STARLET > .OLB;1 > -SYSTEM-F-EXQUOTA, process quota exceeded > > %PCSI-E-MODREPLERR, error replacing module C$$MAIN in library DISK$ALPHASYS:[SYS > 0.SYSCOMMON.][SYSLIB]STARLET.OLB > -LIBRAR-F-WRITEERR, error writing !AS > %PCSI-E-OPFAILED, operation failed > Terminating is strongly recommended. Do you want to terminate? [YES] > > I've increased my UAF process limits to some fairly high values: > > DJAS02::DDACHTERA$ uaf sh ddachtera > > Username: DDACHTERA Owner: David J Dachtera > Account: UIC: [30,1] ([DDACHTERA]) > CLI: DCL Tables: DCLTABLES > Default: DRIVE000:[DDACHTERA] > LGICMD: > Flags: > Primary days: Mon Tue Wed Thu Fri > Secondary days: Sat Sun > No access restrictions > Expiration: (none) Pwdminimum: 6 Login Fails: 0 > Pwdlifetime: (none) Pwdchange: 25-OCT-2006 21:06 > Last Login: 9-JAN-2007 19:57 (interactive), 7-JAN-2007 10:08 (non-interactive) > Maxjobs: 0 Fillm: 100 Bytlm: 8388608 > Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0 > Maxdetach: 0 BIOlm: 1024 JTquota: 4096 > Prclm: 8 DIOlm: 1024 WSdef: 2000 > Prio: 4 ASTlm: 2048 WSquo: 4000 > Queprio: 4 TQElm: 256 WSextent: 16384 > CPU: (none) Enqlm: 8192 Pgflquo: 50000 > Authorized Privileges: > NETMBX SETPRV TMPMBX > Default Privileges: > NETMBX OPER TMPMBX > > About the only ones I didn't blow through the roof were WSextent and Pgflquota. > > Anyone have any ideas? (V7.3-2, no prior ECOs except PCSI V0300, the machine has > 256MB RAM) Why are you not using the SYSTEM account to update the system? It may not help if quotas are a problem, but it can't hurt. ------------------------------ End of INFO-VAX 2007.021 ************************