INFO-VAX Wed, 19 Sep 2007 Volume 2007 : Issue 512 Contents: Alpha VMS In Infinite Boot Cycle Re: Alpha VMS In Infinite Boot Cycle Re: Impact VMS version on CPU speed Re: Impact VMS version on CPU speed Re: Impact VMS version on CPU speed Re: Impact VMS version on CPU speed Re: Impact VMS version on CPU speed Re: Lock problem with SAMBA/NMBD Re: tz88 - green-brick for BA350 shelf VMS 5.5 / DECNet on Windows XP ---------------------------------------------------------------------- Date: Wed, 19 Sep 2007 17:30:35 GMT From: "Robert Jarratt" Subject: Alpha VMS In Infinite Boot Cycle Message-ID: <%0dIi.2434$yN2.1168@newsfe7-gui.ntli.net> I have installed VMS on a DEC 2000 Model 300. I installed DECwindows and now on the console I get this: %DECW-W-BADVALUE, Free GBLSECTIONS is 244, should be at least 280 Some SYSGEN parameters must be reset for DECwindows to start. If you type YES, AUTOGEN will change these parameters and reboot your system. If you type NO, AUTOGEN will not run or cause a reboot, but DECwindows will not start. Do you want the system to run AUTOGEN for you [YES]? If I say yes it goes through a reboot but I get the same prompt again (i.e. no change to the parameter). So I ran sysgen and changed that parameter myself to 280. When it came up again it said the value was 280, but needed to be 600! So I changed it to 600 manually and when it rebooted it said the value was 244 and needed to be 280!!! How to I get out of this loop? Thanks Rob ------------------------------ Date: Wed, 19 Sep 2007 17:47:17 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: Alpha VMS In Infinite Boot Cycle Message-ID: In article <%0dIi.2434$yN2.1168@newsfe7-gui.ntli.net>, "Robert Jarratt" writes: > > >I have installed VMS on a DEC 2000 Model 300. I installed DECwindows and now >on the console I get this: > >%DECW-W-BADVALUE, Free GBLSECTIONS is 244, should be at least 280 >Some SYSGEN parameters must be reset for DECwindows to start. If you type >YES, AUTOGEN will change these parameters and reboot your system. If you >type >NO, AUTOGEN will not run or cause a reboot, but DECwindows will not start. >Do you want the system to run AUTOGEN for you [YES]? > >If I say yes it goes through a reboot but I get the same prompt again (i.e. >no change to the parameter). So I ran sysgen and changed that parameter >myself to 280. When it came up again it said the value was 280, but needed >to be 600! So I changed it to 600 manually and when it rebooted it said the >value was 244 and needed to be 280!!! Did you write the parameters to ALPHAVMSSYS.PAR??? At the SYSGEN prompt, you should have issued: SYSGEN> WRITE CURRENT >How to I get out of this loop? Boot up conversationally: >>> BOOT -FL 0,1 When you get to the SYSBOOT> prompt enter: SYSBOOT> SET GBLSECTIONS 600 SYSBOOT> CONTINUE If this is the only SYSGEN parameter troubling your bootstrap, you should get the system to boot up. Once up, edit MODPARAMS.DAT to adjust GBLSECTIONS, run AUTOGEN and try an- other reboot. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" http://tmesis.com/drat.html ------------------------------ Date: Wed, 19 Sep 2007 01:10:22 -0700 From: wim.versteeg@ns.nl Subject: Re: Impact VMS version on CPU speed Message-ID: <1190189422.605321.306820@w3g2000hsg.googlegroups.com> On 19 sep, 04:39, Robert Deininger wrote: > In article <1190124978.800689.95...@g4g2000hsf.googlegroups.com>, > > > > > > wim.verst...@ns.nl wrote: > > We have two ES40's with each four CPU's. One with openVMS 7.1-2, the > > other with openVMS 7.2.-1. For calculating the CPU speed we use a > > command procedure named VUP.COM: > > > $!---------------------------------------------------------------------- > > $! VUP meter > > $!---------------------------------------------------------------------- > > $ say :== write sys$output > > $ before_cputim = f$getjpi ("","cputim") > > $ i = 1 > > $ loop: > > $ if i .gt. 1000 then goto endloop > > $ a = i * 1000 + i > > $ i = i + 1 > > $ goto loop > > $ ! > > $ endloop: > > $! > > $ after_cputim = f$getjpi ("","cputim") > > $ diff_cputim = after_cputim - before_cputim - 3 > > $! > > $ vup = (24*1200+diff_cputim/2)/diff_cputim > > $ node = f$getsyi("nodename") > > $ mtyp = f$getsyi("hw_name") > > $ say f$fao("VUP rating for !AS (!AS) = !SL.!SL", - > > node,mtyp,vup/10,vup-10*(vup/10)) > > $! > > $ exit > > > The VUP rating on the 7.1-2 system is 576.0. On the 7.2-1 system it is > > just 261.8. When we install 7.1-2 on the second machine the VUP rating > > is what we expect it to be, namely 576.0. We did the same test on a > > couple of DS10's. The result is the same: the CPU speed on a 7.1-2 > > system is about twice the speed of the CPU on a 7.2-1 system. Anybody > > who has a clue ?? > > It appears that your elapsed time is only a few clock ticks on this > system, and the measurement error is not small compared to the quantity > you are trying to measure. > > How many time did you run the measurement on each system? How did the > results vary? > > I ran your procedure several times on a DS25: > VUP rating for BRAMHA (AlphaServer DS25) = 960.0 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 1440.0 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 960.0 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 960.0 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 720.0 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 960.0 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 960.0 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 960.0 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 960.0 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 960.0 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 960.0 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 960.0 > > The difference between 1440.0 VUPs and 960 VUPs is 2 clock ticks, and > the difference between 960 and 720 is 1 clock tick. > > To make this clear, I added some more output to your procedure: > > $ type show_vup.com > $!---------------------------------------------------------------------- > $! VUP meter > $!---------------------------------------------------------------------- > $ say :== write sys$output > $ before_cputim = f$getjpi ("","cputim") > $ i = 1 > $ loop: > $ if i .gt. 1000 then goto endloop > $ a = i * 1000 + i > $ i = i + 1 > $ goto loop > $ ! > $ endloop: > $! > $ after_cputim = f$getjpi ("","cputim") > $ diff_cputim = after_cputim - before_cputim - 3 > $! > $ vup = (24*1200+diff_cputim/2)/diff_cputim > $ node = f$getsyi("nodename") > $ mtyp = f$getsyi("hw_name") > $ say f$fao("VUP rating for !AS (!AS) = !SL.!SL", - > node,mtyp,vup/10,vup-10*(vup/10)) > $ say "After CPUTIM: ",after_cputim > $ say "Before CPUTIM: ",before_cputim > $ say "Difference: ",diff_cputim > $! > $ exit > > ... and ran it a few times on the same system: > > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 960.0 > After CPUTIM: 675 > Before CPUTIM: 669 > Difference: 3 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 960.0 > After CPUTIM: 681 > Before CPUTIM: 675 > Difference: 3 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 960.0 > After CPUTIM: 687 > Before CPUTIM: 681 > Difference: 3 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 960.0 > After CPUTIM: 694 > Before CPUTIM: 688 > Difference: 3 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 960.0 > After CPUTIM: 701 > Before CPUTIM: 695 > Difference: 3 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 720.0 > After CPUTIM: 708 > Before CPUTIM: 701 > Difference: 4 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 960.0 > After CPUTIM: 714 > Before CPUTIM: 708 > Difference: 3 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 960.0 > After CPUTIM: 720 > Before CPUTIM: 714 > Difference: 3 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 960.0 > After CPUTIM: 726 > Before CPUTIM: 720 > Difference: 3 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 960.0 > After CPUTIM: 733 > Before CPUTIM: 727 > Difference: 3 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 960.0 > After CPUTIM: 739 > Before CPUTIM: 733 > Difference: 3 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 960.0 > After CPUTIM: 745 > Before CPUTIM: 739 > Difference: 3 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 960.0 > After CPUTIM: 751 > Before CPUTIM: 745 > Difference: 3 > > (Note that the procedure reduces the actual difference by 3 ticks. I > don't know what is intended by that.) > > These trials took 6 or 7 ticks (reported as 3 or 4 ticks, respectively). > > Then I changed two lines: > $ if i .gt. 1000 then goto endloop > changed to > $ if i .gt. 10000 then goto endloop > > and > > $ vup = (24*1200+diff_cputim/2)/diff_cputim > changed to > $ vup = (24*12000+diff_cputim/2)/diff_cputim > > So roughly speaking, we increase the numerator and denominator each by a > factor of 10. > > $ type show_vup.com > $!---------------------------------------------------------------------- > $! VUP meter > $!---------------------------------------------------------------------- > $ say :== write sys$output > $ before_cputim = f$getjpi ("","cputim") > $ i = 1 > $ loop: > $ if i .gt. 10000 then goto endloop > $ a = i * 1000 + i > $ i = i + 1 > $ goto loop > $ ! > $ endloop: > $! > $ after_cputim = f$getjpi ("","cputim") > $ diff_cputim = after_cputim - before_cputim - 3 > $! > $ vup = (24*12000+diff_cputim/2)/diff_cputim > $ node = f$getsyi("nodename") > $ mtyp = f$getsyi("hw_name") > $ say f$fao("VUP rating for !AS (!AS) = !SL.!SL", - > node,mtyp,vup/10,vup-10*(vup/10)) > $ say "After CPUTIM: ",after_cputim > $ say "Before CPUTIM: ",before_cputim > $ say "Difference: ",diff_cputim > $! > $ exit > > Here are the results on the same system: > > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 505.3 > After CPUTIM: 815 > Before CPUTIM: 755 > Difference: 57 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 505.3 > After CPUTIM: 875 > Before CPUTIM: 815 > Difference: 57 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 505.3 > After CPUTIM: 936 > Before CPUTIM: 876 > Difference: 57 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 505.3 > After CPUTIM: 997 > Before CPUTIM: 937 > Difference: 57 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 514.3 > After CPUTIM: 1056 > Before CPUTIM: 997 > Difference: 56 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 505.3 > After CPUTIM: 1116 > Before CPUTIM: 1056 > Difference: 57 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 496.6 > After CPUTIM: 1177 > Before CPUTIM: 1116 > Difference: 58 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 496.6 > After CPUTIM: 1238 > Before CPUTIM: 1177 > Difference: 58 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 496.6 > After CPUTIM: 1299 > Before CPUTIM: 1238 > Difference: 58 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 496.6 > After CPUTIM: 1360 > Before CPUTIM: 1299 > Difference: 58 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 505.3 > After CPUTIM: 1420 > Before CPUTIM: 1360 > Difference: 57 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 505.3 > After CPUTIM: 1480 > Before CPUTIM: 1420 > Difference: 57 > $ @show_vup > VUP rating for BRAMHA (AlphaServer DS25) = 505.3 > After CPUTIM: 1541 > Before CPUTIM: 1481 > Difference: 57 > > Try running the modified procedure on both systems several times. > > My guess is that you've uncovered a small difference in the overhead > between the OS versions, and it changes your getjpi result by a tick or > so on average. Your too-small measurement interval magnifies this > difference, and makes it look like a significant difference in VUPs. > > Your procedure is almost certainly NOT measuring the CPU speed as > represented by addition and multiplication. > > -- Robert- Tekst uit oorspronkelijk bericht niet weergeven - > > - Tekst uit oorspronkelijk bericht weergeven - Robert, I ran the modified procedure, as you suggested, on both systems and the result is that for the 7.1-2 machine it took between 79 and 83 ticks while the 7.2-1 machine used between 144 and 146 ticks. So it seems that DCL is somewhat slower on the 7.2-1 machine. You're absolute right that this is not the way to measure the CPU speed. It just shows that DCL behaves differently on various versions of openVMS. Read also my reply to John. Anyway thanks for your contribution. Wim. ------------------------------ Date: Wed, 19 Sep 2007 08:21:19 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: Impact VMS version on CPU speed Message-ID: <3_4Ii.9150$ZA.4698@newsb.telia.net> wim.versteeg@ns.nl wrote: > I ran the modified procedure, as you suggested, on both systems and > the result is that for the 7.1-2 machine it took between 79 and 83 > ticks while the 7.2-1 machine used between 144 and 146 ticks. So it > seems that DCL is somewhat slower on the 7.2-1 machine. You're > absolute right that this is not the way to measure the CPU speed. It > just shows that DCL behaves differently on various versions of > openVMS. Read also my reply to John. Anyway thanks for your > contribution. > > Wim. > So the end result is that, do not use these kind of VUP-scripts to compare different versions of VMS, only different versions of hardware (using the same VMS version during the measurment). And VUP was/is a way of comparing *hardware*, not ? And for DCL, I prefer functionality before performance. If I need performance there are better tools (perl, C, whatever). Jan-Erik. ------------------------------ Date: Wed, 19 Sep 2007 01:36:58 -0700 From: wim.versteeg@ns.nl Subject: Re: Impact VMS version on CPU speed Message-ID: <1190191018.068157.47830@d55g2000hsg.googlegroups.com> On 18 sep, 21:22, John Reagan wrote: > wim.verst...@ns.nl wrote: > > We have two ES40's with each four CPU's. One with openVMS 7.1-2, the > > other with openVMS 7.2.-1. For calculating the CPU speed we use a > > command procedure named VUP.COM: > > > The VUP rating on the 7.1-2 system is 576.0. On the 7.2-1 system it is > > just 261.8. When we install 7.1-2 on the second machine the VUP rating > > is what we expect it to be, namely 576.0. We did the same test on a > > couple of DS10's. The result is the same: the CPU speed on a 7.1-2 > > system is about twice the speed of the CPU on a 7.2-1 system. Anybody > > who has a clue ?? > > > Wim Versteeg > > Dutch Railways > > Anything else slower? Just DCL? Do a C/FORTRAN/COBOL compilation and > see if the compiler takes longer or not? Any different SYSGEN > parameters like SYSTEM_CHECK turned on? > > -- > John Reagan > OpenVMS Pascal/Macro-32/COBOL Project Leader > Hewlett-Packard Company- Tekst uit oorspronkelijk bericht niet weergeven - > > - Tekst uit oorspronkelijk bericht weergeven - John, The SYSTEM_CHECK parameter has on both machines the value 0. Both machines are used for production purposes and there are no compilers installed. So i used a very small Pascal program for comparison: {* Calculates the first ten tousend primes by means of trail divisions *} {* Copyright Johan Gerard van der Galien 27 August 2002 galien8@zonnet.nl *} program HBPRM (OUTPUT); var N,a,b,d,f:integer; label 1; begin N:=2; f:=1; 1:while f<10000 do begin N:=N+1; for a:=2 to (N-1) do begin b:=N mod a; if b=0 then goto 1; end; f:=f+1; end; writeln('prime number ',f,' =',N); end On the (stand-alone) 7.2-1 machine it took between 3942 and 4586 ticks to complete and on the 7.1-2 machine (with 40 active users) it took 4230 ticks. I'll repeat the test on both machines when there a no users logged in. But it seems that it is just DCL that behaves different. Wim. ------------------------------ Date: 19 Sep 2007 08:10:44 -0500 From: lederman@encompasserve.org (B. Z. Lederman) Subject: Re: Impact VMS version on CPU speed Message-ID: <1RjDFuaTwQ94@eisner.encompasserve.org> In addition to the suggestions made by others: I don't remember at the moment which version it was, but somewhere in the general time frame of the versions of OpenVMS you are testing, there was a DCL bug which made certain operations run a lot slower. It wasn't reported by a customer until well after the release of that version, and it had already been corrected in the next released version of OpenVMS. Since it only occurred in that one version of OpenVMS, which is now far past it's official support date, there was never a patch kit for it. Your type of MUPS test was one of the few operations that was significantly affected, as I recall. I think you'll find the problem does not occur on any currently supported version of OpenVMS. But keep in mind what others have said about setting priority and running a long enough test for the results to be valid: and, more importantly, running a test which is a closer equivalent to the real work you want to do on the system. -- B. Z. Lederman. My personal opinions. ------------------------------ Date: Wed, 19 Sep 2007 09:47:55 -0400 From: John Reagan Subject: Re: Impact VMS version on CPU speed Message-ID: wim.versteeg@ns.nl wrote: > The SYSTEM_CHECK parameter has on both machines the value 0. Both > machines are used for production purposes and there are no compilers > installed. So i used a very small Pascal program for comparison: > If you want a longer Pascal compilation to reduce the noise level, you can try: $ pascal /terminal=stat /noobject /envir=tmp.pen /align=vax - sys$Library:starlet.pas That should take several seconds of CPU time and even more seconds of elapsed time (lots of I/O to read the source and write the environment file). It took 4 or 5 CPU seconds on my XP1000 along with my pretty slow SCSI disks. On our GS1280 with nice 'n fast fibre disks, it flew. $ pascal/noobj/envir=tmp.pen/terminal=stat/align=vax - sys$Library:starlet.pas CPU time: 0.62 seconds Elapsed time: 1.74 seconds Pagefaults: 1104 I/O Count: 4019 Peak memory: 0 kilobytes Source lines: 49154 0 bytes per source line 4756838 lines per CPU minute 1694965 lines per elapsed minute -- John Reagan OpenVMS Pascal/Macro-32/COBOL Project Leader Hewlett-Packard Company ------------------------------ Date: Wed, 19 Sep 2007 03:27:56 -0700 From: Volker Halle Subject: Re: Lock problem with SAMBA/NMBD Message-ID: <1190197676.886693.108080@57g2000hsv.googlegroups.com> Albrecht, I'm seeing the same problem on our OpenVMS I64 V8.2 system running SAMBA V2.2.8. You can use the File-ID field in the F11B$S resource name to find out about the filename involved. You just need to stop and restart SAMBA from time to time... Note that it might take a couple of minutes for NMBD to run down and $DEQ all those locks ! Volker. ------------------------------ Date: Wed, 19 Sep 2007 08:30:53 -0400 From: "Richard B. Gilbert" Subject: Re: tz88 - green-brick for BA350 shelf Message-ID: <46F1167D.1000804@comcast.net> Michael Austin wrote: > Richard B. Gilbert wrote: > >> Michael Austin wrote: >> >>> Does any one have one of these old devices they want to get rid of - >>> cheaply? I have one that flashes all lights on the front after a >>> power glitch. I had 2 in this shelf - and luckily only one of them >>> got hit. I have tried re-seating and following the instructions to >>> clear the error, but it looks like it is toast. >>> >>> Or if you just have the drive - I am sure my former DEC FS skills can >>> take care of placing it into the canister. >>> >> > You Said: > >> You don't NEED a new drive. All you need to do is replace the >> "Leader". Note that this is a job normally done by field service. If >> you don't know what you're doing, pay someone who does! >> > > "Or if you just have the drive - I am sure my former DEC FS skills can > take care of placing it into the canister. " > > I pioneered replacing the leader tape instead of the drive in the Dallas > office back in the mid-80's working on TK50's. I got these for free and > looks like I now know why. The ribbon cable in the back of this one > was crimped/broken. Hopefully that is all that is wrong with it... I > will take some time later to pull the other drive and replace it with > this one to see if it is indeed just the cable. My guess is that the > controller got fried- replaced a few of those in my time as well... > > Man - these parts dealers are not cheap - the ribbon cable goes from > $145-$200. I hate putting money into something I got for free. > You could try buying the two connectors, a length of cable, and making your own. ISTR that a bench vise can substitute for a crimping tool. ------------------------------ Date: Wed, 19 Sep 2007 09:30:28 -0700 From: Andrew Jackson <7thpresident@gmail.com> Subject: VMS 5.5 / DECNet on Windows XP Message-ID: <1190219428.444815.254420@y42g2000hsy.googlegroups.com> Hi, I have a couple of VAXen running VMS5.5 that currently send data to an old PowerMac (which has a DECNet stack - I can't remember the package - and is thus a DECNet node) by using a direct write to a path on it. I want to replace the PowerMac with a PC running XP and it seems from my internet delving that I need Pathworks 32 V7.4 to provide the basic DECNet connectivity. AFAICS I don't need any of the Advanced Server stuff (and indeed it almost certainly wouldn't run on VMS 5.5). What I need to know is where on earth I can obtain the Pathworks 32 Client CD from. The HP pre-sales technical support sounded a bit surprised and confused. The HP website merrily gives me part numbers for Advanced Server/Pathworks CD Kit (QA-A93AA-H8) but I can't find anyone who actually sells it. Any advice from the accumulated wisdom of comp.os.vms would be much appreciated. Regards Andrew ------------------------------ End of INFO-VAX 2007.512 ************************