INFO-VAX Thu, 30 Oct 2008 Volume 2008 : Issue 587 Contents: Alpha 800 4/500 Another DST issue Re: Another DST issue Re: DCPS setpagedevice PS error on a Xerox WCP 35 Re: Fortran, debugger and Alpha/VMS 7.3-2 Re: Good news: HP has retaken the VMS trademark ! Re: IO TIME vs COMputable Re: IO TIME vs COMputable Re: Name that VAX/VMS version based on banner Re: Name that VAX/VMS version based on banner Re: Name that VAX/VMS version based on banner NTP stratum problem Re: NTP stratum problem Re: NTP stratum problem Re: Restricting Access to TCP/IP and DECnet Re: Seamonkey browser port for Alpha now available Re: Seamonkey browser port for Alpha now available Re: Submit to run at 01:05 after EDT becomes EST Re: Submit to run at 01:05 after EDT becomes EST Re: supported SCSI interfaces in a VMS cluster Re: USB to Serial Line interface for OpenVMS Itanium/VMS 8.3 Re: USB to Serial Line interface for OpenVMS Itanium/VMS 8.3 RE: VAX-11/785 microdiagnostics help requested Re: VAX-11/785 microdiagnostics help requested ---------------------------------------------------------------------- Date: Thu, 30 Oct 2008 13:47:39 -0400 From: Chuck Aaron Subject: Alpha 800 4/500 Message-ID: Would this have an EV3 or EV5.6? Thanks. ------------------------------ Date: Thu, 30 Oct 2008 15:56:00 +0000 (UTC) From: moroney@world.std.spaamtrap.com (Michael Moroney) Subject: Another DST issue Message-ID: We have an application that until this spring was running on a VAX running V7.3. It has been ported to an Itanium running V8.3. The application is (very) old and does not handle DST time changes. What they've done in the past for DST time changes is wait until a quiet time, stop the application, manually set the time and restart the application. However, the new system has been set up using NTP and with SYSGEN parameter AUTO_DLIGHT_SAV set to 1. This means that VMS will automatically set the clock back this Sunday for us. However, this parameter is _not_ dynamic. Is there a way to change things so as to not set the time back, short of rebooting with AUTO_DLIGHT_SAV 0? (I've already set it back to 0 in the CURRENT parameters so this won't bite us again this spring (assuming there is a reboot before then, not a good assumption with VMS!) Stopping NTP is simple enough, it's the auto time change that's the issue. We can't predict when there will be a quiet time. ------------------------------ Date: Thu, 30 Oct 2008 12:35:55 -0500 From: norm.raphael@metso.com Subject: Re: Another DST issue Message-ID: This is a multipart message in MIME format. --=_alternative 0060AAEB852574F2_= Content-Type: text/plain; charset="US-ASCII" moroney@world.std.spaamtrap.com (Michael Moroney) wrote on 10/30/2008 11:56:00 AM: > We have an application that until this spring was running on a VAX running > V7.3. It has been ported to an Itanium running V8.3. The application is > (very) old and does not handle DST time changes. What they've done in the > past for DST time changes is wait until a quiet time, stop the > application, manually set the time and restart the application. > > However, the new system has been set up using NTP and with SYSGEN parameter > AUTO_DLIGHT_SAV set to 1. This means that VMS will automatically set the > clock back this Sunday for us. However, this parameter is _not_ dynamic. > Is there a way to change things so as to not set the time back, short of > rebooting with AUTO_DLIGHT_SAV 0? (I've already set it back to 0 in the > CURRENT parameters so this won't bite us again this spring (assuming there > is a reboot before then, not a good assumption with VMS!) > > Stopping NTP is simple enough, it's the auto time change that's the issue. > We can't predict when there will be a quiet time. Someone should correct me if I'm wrong and provide details if I'm not, but if you remove the TimeZoneRule from the logical name tables the reset should fail. --=_alternative 0060AAEB852574F2_= Content-Type: text/html; charset="US-ASCII"
moroney@world.std.spaamtrap.com (Michael Moroney) wrote on 10/30/2008 11:56:00 AM:

> We have an application that until this spring was running on a VAX running
> V7.3.  It has been ported to an Itanium running V8.3.  The application is
> (very) old and does not handle DST time changes.  What they've done in the
> past for DST time changes is wait until a quiet time, stop the
> application, manually set the time and restart the application.
>
> However, the new system has been set up using NTP and with SYSGEN parameter
> AUTO_DLIGHT_SAV set to 1.  This means that VMS will automatically set the
> clock back this Sunday for us.  However, this parameter is _not_ dynamic.
> Is there a way to change things so as to not set the time back, short of
> rebooting with AUTO_DLIGHT_SAV 0?  (I've already set it back to 0 in the
> CURRENT parameters so this won't bite us again this spring (assuming there
> is a reboot before then, not a good assumption with VMS!)
>
> Stopping NTP is simple enough, it's the auto time change that's the issue.
> We can't predict when there will be a quiet time.
Someone should correct me if I'm wrong and provide details if I'm not, but if

you remove the TimeZoneRule from the logical name tables the reset should fail. --=_alternative 0060AAEB852574F2_=-- ------------------------------ Date: Thu, 30 Oct 2008 11:36:47 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: DCPS setpagedevice PS error on a Xerox WCP 35 Message-ID: JF Mezei wrote: > Jan-Erik Söderholm wrote: > >> tells me that I had missunderstood that. I thought that >> the "DATA_TYPE=PCL" was a way to use the DCPS "infrastructure" >> to print PCL on non-PS printers. Guess not... > > The error message you posted here is typical of a POSTSCRIPT printer. I > would be willing to bet a chocolate bar that the printer does support > Postcript. Of course it does. *That* printer, that is... But it also supports PCL with auto-switch between PS and PCL, so I expect it to also accept a plain PCL file. But there are a lot of non-PS printers at the same site, My hope was to be able to manage them all through DCPS. Seems not. > > As you have seen in the postscript modules sent to the printer, there > are many postscript commands sent to the printer prior to a > setpagedevice command. A PCL-only printer would likely have complained > well before getting to a setpagedevice, and it would have had no concept > of a stack and that a dictionary had been put on the stack just before > calling setpagedevice. A PCL only printer would usualy print a few pages of PS code. ------------------------------ Date: Thu, 30 Oct 2008 06:38:27 GMT From: John Santos Subject: Re: Fortran, debugger and Alpha/VMS 7.3-2 Message-ID: David Weatherall wrote: > tadamsmar wrote: > > >>On Oct 29, 1:17 am, "David Weatherall" wrote: >> >>>tadamsmar wrote: >>> >>>>On Oct 28, 1:43 am, "David Weatherall" >>>>wrote: >>>> >>>>>We finally upgraded the Alphas in our cluster from V7.3-1 to -2 >>>>>last week. As expected, we never saw any problem until my >>>>>colleague needed to use the debugger with her Fortran (V7.5...) >>>>>program. >>> >>>>>It contains a Structure/record like >>> >>>>> structure /asd$record/ >>>>> character*36 asd_name >>>>> character*36 efile_name >>>>> character*12 other_name >>>>>... >>>>> end structure >>> >>>>> record /asd$record/ asd_record >>> >>>>>In the debugger we can >>> >>>>> EXA ASD_RECORD >>> >>>>>without problem but >>> >>>>> EXA ASD_RECORD.ASD_NAME >>> >>>>>generates the following error :- >>> >>>>>%DEBUG-E-INTERR, debugger error in DBGADDEXP\DETERMINE_TYPE >>>>>unknown arg type or session corruption >>> >>>>>T'was fine on 7.3-1. Anybody know what's going on? John? >>> >>>>>Kristine, my colleague, is less than impressed. >>> >>>>>Cheers - Dave >>> >>>>>Now that I look at it, the $ in asd$record is a bit suspicious >>>>>perhaps. >>> >>>>>-- >>> >>>>I just tried it on a 7.3-2 system and it worked. >>> >>>>But, my Fortran ver is 7.2-180 >>> >>>>My fortran symbol was: >>> >>>>"FORTRAN /NOLIST /DEBUG /NOOPT /NOALIGN / >>>>CHECK=(BOUN,FP_E,OVER,NOUNDE) /WARN=(NOALIGN,NOUNINIT)/EXTEND" >>> >>>>Perhaps you should get your patches up to date if you have not >>>>done so. Mine are pretty close to up to date, (within a year or >>>>so maybe). >>> >>>Thanks >>> our Fortran version is 7.5 somethings. I've tried it with two >>>standards. I didn't want to update our Fortran compiler to the >>>latest standard because I'm in a position to do 'incremental Q/A' >>>that way. If I upgrade and can't produce a bit-compatible .EXE I >>>have to do the 3-week Q/A job all over again. Partly because of the >>>rules and partly for peace of mind. >>> >>>Thomas, our SysMAn, is sure that he applied all patches when he >>>upgraded two weeks ago. Could you an ANALYZE /IMAGE on the debugger >>>.EXE please. >>> >>>Cheers - Dave. >>> >>>--- Hide quoted text - >>> >>>- Show quoted text - >> >>Is the be part of the ANALYZE/IMAGE that you want?: >> >> Image Identification Information >> >> image name: "DEBUG" >> image file identification: "V7.3-200" >> image file build identification: "X9ZK-0060100000" >> link date/time: 1-OCT-2003 21:19:12.22 >> linker identification: "A11-50" >> >> Patch Information >> >> There are no patches at this time. > > > Thanks Mark > that is exactly the bit I was after. My memory is that ours > has link date in 2007. I'll forward this to work and check again when I > get there. > > Cheers - Dave. > On my V7.3-2 system: Image Identification Information image name: "DEBUG" image file identification: "V8.3-008" image file build identification: "XA99-0060111007" link date/time: 14-JUN-2006 13:19:07.83 linker identification: "A11-50" This came in the VMS732_DEBUG-V0100 ECO, which is included in the latest 2 UPDATE ECOs, VMS732_UPDATE-V1500 and -V1600. Don't know if it fixes Mark's problem, though. One of the problem descriptions is: o An EXAMINE of a FORTRAN-90 deferred shape array would fail with a "descriptor not set up" error. Not exactly the same, but similar. Another is: An EXAMINE of a FORTRAN record or field within a record would lead to a debugger access violation. The third sounds exactly like the 1st, but with a typo in the description: An EXAMINE of a FORTRAN-90 deferred shape array would fail with a "descriptornot set up" error. HTH. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: 30 Oct 2008 07:53:25 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Good news: HP has retaken the VMS trademark ! Message-ID: In article <6d5b0$472b798b$cef8887a$5047@TEKSAVVY.COM>, JF Mezei writes: > > In this case, it is moot. Just as the case for the use of "ALL-IN-1" for > its printers, HP can use "VMS" for whatever it wants since it owns the > company that owned that trademark. Actually it didn't. HP owns "OpenVMS" but the VMS trademark was allowed to expire before VMS bought Compaq. There are now other software systems trademarked as "VMS" which would prevent HP from using "VMS" as a software trademark, unless they first track down and purchase that from the current owner. ------------------------------ Date: 30 Oct 2008 07:56:29 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: IO TIME vs COMputable Message-ID: <6HxOanFjbTVy@eisner.encompasserve.org> In article , "e.e" writes: > > It's seem at the end of the batch report, there is information like : > Charged CPU time: 0 00:10:21.34 Elapsed time: 0 00:25:18.93 > > i know that the IO time = ELapsed - CPU Time. Actually everything that the software waits for is included in that difference, not just I/O. I don't know of any tracking of I/O time in VMS. ------------------------------ Date: 30 Oct 2008 07:57:21 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: IO TIME vs COMputable Message-ID: In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > In article , "e.e" writes: > >> But , if the batch wait the processor (COMputable state) during the >> executing, the IO time was wrong. (i think) > > CPU time is "CUR" time, not "COM" time. Yes, but if he's in COM instead of CUR, then he's not doing I/O, which is what he wants to know about. ------------------------------ Date: 30 Oct 2008 08:18:30 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Name that VAX/VMS version based on banner Message-ID: In article <1194194073.169572.156550@v3g2000hsg.googlegroups.com>, AEF writes: > > VAX/VMS PTEXT 23-SEP-1981 17:56 LPA0: 23-SEP-1981 > 17:56 _DRA0:[PRIME]PTEXT.DAT;1 VAX/VMS > If the date is right, VMS 1.x - 2.3 or so were available. I don't recall if the banner format changed between 1.x and 2.0, but it has pretty stable since then. ------------------------------ Date: 30 Oct 2008 08:20:31 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Name that VAX/VMS version based on banner Message-ID: In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > In article <1194194073.169572.156550@v3g2000hsg.googlegroups.com>, AEF writes: >> >> VAX/VMS PTEXT 23-SEP-1981 17:56 LPA0: 23-SEP-1981 >> 17:56 _DRA0:[PRIME]PTEXT.DAT;1 VAX/VMS >> > >> >> Anyone have any ideas what version of VAX/VMS these printouts are >> from? > > The banner layout hasn't changed in ages, but the date 1981 means VMS > 2.x or earlier. I think by September VMS 2.5 had shipped, but not > yet 3.0. > Wow. I don't remember writing that. But now I see in the headers it was last year. I better see why these messages are showing up as unread before I spend hours re-reading old news. ------------------------------ Date: 30 Oct 2008 13:41:57 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Name that VAX/VMS version based on banner Message-ID: <6mtrt5FidnapU1@mid.individual.net> In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: >> In article <1194194073.169572.156550@v3g2000hsg.googlegroups.com>, AEF writes: >>> >>> VAX/VMS PTEXT 23-SEP-1981 17:56 LPA0: 23-SEP-1981 >>> 17:56 _DRA0:[PRIME]PTEXT.DAT;1 VAX/VMS >>> >> >>> >>> Anyone have any ideas what version of VAX/VMS these printouts are >>> from? >> >> The banner layout hasn't changed in ages, but the date 1981 means VMS >> 2.x or earlier. I think by September VMS 2.5 had shipped, but not >> yet 3.0. >> > > Wow. I don't remember writing that. But now I see in the headers > it was last year. I better see why these messages are showing up > as unread before I spend hours re-reading old news. I am seeing the replies, but not the original (year old) messages. Are you people using Google Groups? If so, it appears there is the crux of the problem as it appears to have revived a bunch of old messages and somehow marked them as "new". Luckily either Google Groups knows enough not to re-injewct them into the system or the other systems are able to detect they are garbage and are not propogating them. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Thu, 30 Oct 2008 05:13:57 -0700 (PDT) From: jan.andersson@axfood.se Subject: NTP stratum problem Message-ID: <01892b35-2502-4f17-817a-59a05fafd086@p59g2000hsd.googlegroups.com> I have set up two Alphas as timeservers for our other 20 Alphas. They both use the the same copy of TCPIP$NTP.CONF: server ntp1.sth.netnod.se server ntp2.sth.netnod.se server 2.se.pool.ntp.org server 2.europe.pool.ntp.org server 3.europe.pool.ntp.org server 127.127.1.0 fudge 127.127.1.0 stratum 8 I also added that they use each other ass peers HUVUD is running TCP/IP Services Version V5.6 - ECO 2 GLOBAL is running TCP/IP Services Version V5.4 - ECO 2 Node HUVUD which was the first NTP server started looks fine: HUVUD> ntpdc -p remote local st poll reach delay offset disp ======================================================================= *ntp1.sth.netnod 194.14.159.55 1 1024 377 0.02243 0.005199 0.01578 =ntp2.sth.netnod 194.14.159.55 1 1024 377 0.00876 0.006664 0.01581 =irc-cobra.unizh 194.14.159.55 4 1024 377 0.11130 -0.031395 0.01579 =zit-net1.uni-pa 194.14.159.55 1 1024 377 0.03905 -0.005733 0.01581 =LOCAL(0) 127.0.0.1 8 64 377 0.00000 0.000000 0.00287 =212.247.117.169 194.14.159.55 2 1024 377 0.04271 0.015330 0.01579 +global.huv.daga 194.14.159.55 3 64 376 0.00098 -1.054923 0.00308 Node GLOBAL assign the stratum 1 servers a stratum 16 value: GLOBAL_GLOB> ntpdc -p remote local st poll reach delay offset disp ======================================================================= =LOCAL(0) 127.0.0.1 8 64 377 0.00000 0.000000 0.00191 =ntp1.sth.netnod 194.14.159.42 16 128 0 0.00000 0.000000 0.00000 =ntp2.sth.netnod 194.14.159.42 16 128 0 0.00000 0.000000 0.00000 *HUVUD 194.14.159.42 2 64 377 0.00670 1.039268 0.00302 =voodoo.banbook. 194.14.159.42 16 128 0 0.00000 0.000000 0.00000 =public-timehost 194.14.159.42 16 128 0 0.00000 0.000000 0.00000 =ran.r3blog.nl 194.14.159.42 16 128 0 0.00000 0.000000 0.00000 Tried to set up another node with TCP/IP Version V5.5 - ECO 2 but it gave the same result as GLOBAL. All nodes are on the same LAN and the same network. Why is node GLOBAL not accessing the stratum 1 servers? GLOBAL_GLOB> ntpdate -q ntp1.sth.netnod.se Server ntp1.sth.netnod.se (192.36.144.22), stratum 0 offset +0.0000000, delay +0.0000000 No server suitable for synchronization found from those provided. ------------------------------ Date: Thu, 30 Oct 2008 08:40:16 -0400 From: JF Mezei Subject: Re: NTP stratum problem Message-ID: <4909aa36$0$17359$c3e8da3@news.astraweb.com> jan.andersson@axfood.se wrote: > Why is node GLOBAL not accessing the stratum 1 servers? Not sure. However: After a power failure, my Mac will refuse to sync with my alpha for some time. Eventually it does sync. My take on this is that the alpha take some time before it decides to connect to the remote servers and get not only its time but also its stratum, and until it happens, I suspect the alpha remains are stratum 16 and thus unusable as a server. In your config files, do you really need the server 127.127.1.0 and the fudge for it ? This is what may be confusing it. The ntp software acts as a server in any case. There is no need to declare it as a server. It will get its stratum from whatever server it has connected to, and then your clients on the lan will get their time from your alpha. ------------------------------ Date: Thu, 30 Oct 2008 05:50:02 -0700 (PDT) From: Jim Subject: Re: NTP stratum problem Message-ID: On Oct 30, 8:13=A0am, jan.anders...@axfood.se wrote: > I have set up two Alphas as timeservers for our other 20 Alphas. > They both use the the same copy of TCPIP$NTP.CONF: > > server ntp1.sth.netnod.se > server ntp2.sth.netnod.se > server 2.se.pool.ntp.org > server 2.europe.pool.ntp.org > server 3.europe.pool.ntp.org > > server 127.127.1.0 > fudge 127.127.1.0 stratum 8 > > I also added that they use each other ass peers > > HUVUD is running =A0TCP/IP Services Version V5.6 - ECO 2 > GLOBAL is running TCP/IP Services Version V5.4 - ECO 2 > > Node HUVUD which was the first NTP server started looks fine: > > HUVUD> ntpdc -p > =A0 =A0 =A0remote =A0 =A0 =A0 =A0 =A0 local =A0 =A0 =A0st poll reach =A0d= elay =A0 offset =A0 =A0disp > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > *ntp1.sth.netnod 194.14.159.55 =A0 =A01 1024 =A0377 0.02243 =A00.005199 > 0.01578 > =3Dntp2.sth.netnod 194.14.159.55 =A0 =A01 1024 =A0377 0.00876 =A00.006664 > 0.01581 > =3Dirc-cobra.unizh 194.14.159.55 =A0 =A04 1024 =A0377 0.11130 -0.031395 > 0.01579 > =3Dzit-net1.uni-pa 194.14.159.55 =A0 =A01 1024 =A0377 0.03905 -0.005733 > 0.01581 > =3DLOCAL(0) =A0 =A0 =A0 =A0127.0.0.1 =A0 =A0 =A0 =A08 =A0 64 =A0377 0.000= 00 =A00.000000 > 0.00287 > =3D212.247.117.169 194.14.159.55 =A0 =A02 1024 =A0377 0.04271 =A00.015330 > 0.01579 > +global.huv.daga 194.14.159.55 =A0 =A03 =A0 64 =A0376 0.00098 -1.054923 > 0.00308 > > Node GLOBAL assign the stratum 1 servers a stratum 16 value: > GLOBAL_GLOB> ntpdc -p > =A0 =A0 =A0remote =A0 =A0 =A0 =A0 =A0 local =A0 =A0 =A0st poll reach =A0d= elay =A0 offset =A0 =A0disp > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3DLOCAL(0) =A0 =A0 =A0 =A0127.0.0.1 =A0 =A0 =A0 =A08 =A0 64 =A0377 0.000= 00 =A00.000000 > 0.00191 > =3Dntp1.sth.netnod 194.14.159.42 =A0 16 =A0128 =A0 =A00 0.00000 =A00.0000= 00 > 0.00000 > =3Dntp2.sth.netnod 194.14.159.42 =A0 16 =A0128 =A0 =A00 0.00000 =A00.0000= 00 > 0.00000 > *HUVUD =A0 =A0 =A0 =A0 =A0 194.14.159.42 =A0 =A02 =A0 64 =A0377 0.00670 = =A01.039268 > 0.00302 > =3Dvoodoo.banbook. 194.14.159.42 =A0 16 =A0128 =A0 =A00 0.00000 =A00.0000= 00 > 0.00000 > =3Dpublic-timehost 194.14.159.42 =A0 16 =A0128 =A0 =A00 0.00000 =A00.0000= 00 > 0.00000 > =3Dran.r3blog.nl =A0 194.14.159.42 =A0 16 =A0128 =A0 =A00 0.00000 =A00.00= 0000 > 0.00000 > > Tried to set up another node with TCP/IP Version V5.5 - ECO 2 > but it gave the same result =A0as GLOBAL. > > All nodes are on the same LAN and the same network. > > Why is node GLOBAL not accessing the stratum 1 servers? > > GLOBAL_GLOB> ntpdate -q ntp1.sth.netnod.se > Server ntp1.sth.netnod.se (192.36.144.22), stratum 0 > offset +0.0000000, delay +0.0000000 > No server suitable for synchronization found from those provided. Legal strata values are in the range of 1 to 15. I'm not familiar with HP's TCPIP implementation of this but it would appear that the strata 1 servers are not reachable by node GLOBAL. The reach value is an 8 bit bitmask indicating the success of the past 8 polls. Your reach is 0 for each of these servers so you've not been successful in polling them (numerous other values are also 0 indicating the failure of the NTP polls. Since the strata is stated to be 16 I would take this as an indication that the system has never been able to successfully poll the servers so as to learn their strata. I'd look for an intervening firewall or some other blockage or denial of service... ------------------------------ Date: Thu, 30 Oct 2008 12:09:22 +0100 From: Johnny Billquist Subject: Re: Restricting Access to TCP/IP and DECnet Message-ID: Richard B. Gilbert skrev: > Johnny Billquist wrote: >> glen herrmannsfeldt skrev: >>> PacoLinux wrote: >>> (snip) >>> >>>>>> Is it possible to restrict access to TCP/IP (5.1) and DECnet (IV) >>>>>> on a >>>>>> per-user basis? In other words I would like someone to be able to >>>>>> access my >>>>>> machine, but not to go from that machine to anywhere else on the >>>>>> network. >>> (snip) >>> >>>> -> I'm not aware of a way to do this in UN*X, either, without breaking >>>> -> almost the entire system. >>> >>>> You can use a restricted shell : >>> > >>> http://www.gnu.org/software/bash/manual/bashref.html#The-Restricted-Shell >>> >>> >>> I believe it can be done with the restricted shell, but it still >>> isn't easy. >>> >>> You have to give the user a read only directory, otherwise executable >>> files >>> can be loaded and executed. I believe rsh restricts cd and the >>> ability to >>> execute files by path, such as /tmp/xyz. >>> >>> You then need to supply commands that do what the user is supposed to >>> be allowed to do. chroot helps a lot, too. >> >> I havaen't seen the start of this, but in VMS, shouldn't just not >> having TMPMBX solve this? Is there something else you might want to >> run that requires TMPMBX? >> >> Johnny >> > > Did you, by chance, mean NETMBX? Probably yes. :-) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol ------------------------------ Date: 30 Oct 2008 10:56:07 +0100 From: pmoreau@ath.cena.fr (Patrick MOREAU, DTI Athis ex CENA, Tel: 01.69.57.68.40) Subject: Re: Seamonkey browser port for Alpha now available Message-ID: <7I3nwpb2AsY3@sinead> In article , Rich Jordan writes: > From OpenVMS.ORG > > http://www.openvms.org/stories.php?story=08/10/24/9322255 > > I may try to get this downloaded this weekend to try. Has anyone used > it or the previous itanium port yet? Cool !! Just installed it on my DS20E/VMS7.3-2 at work. Some sites undisplayed with mozilla are now OK. Good job HP !! I'll try it on my home DS15A/VMS 8.3 soon. Patrick -- =============================================================================== patrick.moreau@aviation-civile.gouv.fr DSNA/DTI/EOS (ex SDER/CENA) ______ ___ _ Pôle XPE / / / / /| /| Athis-Mons France / /___/ / / | / | __ __ __ __ BP 205 / / / / |/ | | | |__| |__ |__| | | 94542 ORLY AEROGARE CEDEX / / :: / / | |__| | \ |__ | | |__| http://www.ath.cena.fr/~pmoreau/ http://membres.lycos.fr/pmoreau/ =============================================================================== ------------------------------ Date: Thu, 30 Oct 2008 18:05:28 +0100 From: Michael Unger Subject: Re: Seamonkey browser port for Alpha now available Message-ID: <6mu80qFip6mnU1@mid.individual.net> On 2008-10-30 03:03, "Brad Hamilton" wrote: > [...] > > Seamonkey works better for me today, after the nightly reboot. All I really > want to do with it is to play with Mail and Newsgroups. I'm going to attempt > to find out how to invoke *only* the mail program, since the browser, although > more stable than yesterday, is *slow*. > [...] The Windows version has a command line switch "-mail" -- you might try that on VMS as well ... Michael -- Real names enhance the probability of getting real answers. My e-mail account at DECUS Munich is no longer valid. ------------------------------ Date: 30 Oct 2008 07:35:04 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Submit to run at 01:05 after EDT becomes EST Message-ID: In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > In article , norm.raphael@metso.com writes: >> This is a multipart message in MIME format. >> --=_alternative 0071A2FA85257385_= >> Content-Type: text/plain; charset="US-ASCII" >> >> If I want to submit a batch job to execute at 01:05 after the clock resets >> from EDT to EST, >> can I submit it to run after 1:55 and put a >> $WAIT 01:10:00 >> in it, then >> $@whatever.com >> >> In other words, will the WAIT count time units and ignore the clock? > > IIRC, the timers in VMS are all converted to and sorted by absolute > time when they are entered in the timer queue. Yes, but those that were requested as delta time are flagged and handled appropriately when the system time is changed. ------------------------------ Date: 30 Oct 2008 07:38:40 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Submit to run at 01:05 after EDT becomes EST Message-ID: In article , norm.raphael@metso.com writes: > > koehler@eisner.nospam.encompasserve.org (Bob Koehler) wrote on 10/29/2008 > 09:52:36 AM: > >> In article > 0071A2FC@metso.com>, norm.raphael@metso.com writes: >> > >> > If I want to submit a batch job to execute at 01:05 after the clock > resets >> > from EDT to EST, >> > can I submit it to run after 1:55 and put a >> > $WAIT 01:10:00 >> > in it, then >> > $@whatever.com >> > >> > In other words, will the WAIT count time units and ignore the clock? >> >> Not quite the way you wrote it. Absolute times execute when the > clock >> gets to, or passes (if the clock is changed) the time specified. > Delta >> times get massaged when the clock is changed so that the elapsed time > is >> preserved. >> >> So when you submit/after=1:55, then change time from 2:00 to 1:00, >> the following will happen. >> >> The job starts at 1:55 EDT. It hits the wait statement. In 10 >> minutes the time will be 1:05 EST. You're wait statement needs to >> be >> >> $WAIT 00:10:00. >> >> > So in the Spring, this also works to execute five minutes AFTER the time > is > corrected? The concept is always the same, but in the spring the result is that the absolute time after the wait statement will be 3:05 EDT, which is unique and you can just set that as the /after time on the submit command. ------------------------------ Date: Thu, 30 Oct 2008 02:25:08 -0700 (PDT) From: H Vlems Subject: Re: supported SCSI interfaces in a VMS cluster Message-ID: <61b23e1e-57a5-4496-9485-af8144b2b5e0@m74g2000hsh.googlegroups.com> On 28 okt, 19:32, Keith Parris wrote: > H Vlems wrote: > > - the manual doesn't mention the KZPCM at all, perhaps it is supported > > to connect to a common SCSI bus? > > The official source for what's supported is typically the Software > Product Descriptions. Go tohttp://hp.com/go/spdto find those. Some > SCSI adapter support info will be in the OpenVMS SPD athttp://docs.hp.com= /en/12697/OVMS831H1SPD.pdf(I see it notes there is > multi-host support in its description for some SCSI adapters, including > the KZPBA-CB), and more specifics on multi-host SCSI support in a > cluster will be in the OpenVMS Cluster Software SPD athttp://docs.hp.com/= en/12700/SPDClusters.pdf. Sometimes support info will > be in the Release Notes or New Features or Installation Guide for a > given version of OpenVMS. Finally, the OpenVMS Roadmap athttp://hp.com/go= /openvms/roadmapcan provide clues about future (and > recent) additions to capabilities. > > =A0> > - if not supported, will it work (after all this is a hobbyist > =A0> environment)? > =A0> - if it's not supported and won't work, what's the reason? > > The host SCSI adapters on different VMS nodes actually briefly talk to > one another and exchange just enough info that VMS can avoid conflicts > in port allocation class assignments between different systems connected > to the same SCSI bus. There was hope at one time that host-to-host > communcations over SCSI could be broadened to include SCS traffic in > general, but that didn't work out. The NCR chip was the first supported > in multi-host configurations and seems to be used in at least many of > the SCSI adapters which support multi-host operation on Alpha. If a > specific adapter doesn't work, my guess would be that it's probably due > to differences in its SCSI interface chip design. Thank you for the detailed answer Keith. The KZPCM uses an NCR chip, so it might just work. I'll connect two systems and see whether they recognize each others disks. Without errors that is. Hans ------------------------------ Date: Thu, 30 Oct 2008 05:59:34 -0700 (PDT) From: johnwallace4@yahoo.co.uk Subject: Re: USB to Serial Line interface for OpenVMS Itanium/VMS 8.3 Message-ID: <430d753e-49a7-48a2-a026-11ce99e21367@y71g2000hsa.googlegroups.com> On Oct 30, 4:25 am, moro...@world.std.spaamtrap.com (Michael Moroney) wrote: > "John Wallace" writes: > >The core innards of many of the smaller adapters likely come from a company > >called ftdi (seewww.ftdichip.com). In fact some of the bigger USB->serial > >adapters consist of a USB hub and multiple FTDI chips - why not take the lid > >off your Digiboard and see what's inside? > > The Digiboards we have are 2 8 line devices internally. They also seem to > make one with 8 2 line cards with the same part number, but we don't seem > to have them. > > >If you have multiple ports active at the same time, you might want to make > >sure its intermal USB hub chip (if applicable) is a true USB2 hub and not a > >lower-throughput USB1 hub pretending to be a USB2 device, whilst actually > >being unable to keep up the throughput. > > Dunno about that. There are additional expansion USB out jacks so there's > definitely a hub of some sort in there. > > There's not a lot of throughput. The Digi cards are dropping characters > from someone hitting return on a terminal. > > >FTDI have been mentioned previously in comp.os.vms but unfortunately I'm not > >aware of working VMS drivers for FTDI USB->serial hardware (doesn't mean > >they don't exist). > > Forrest has mentioned FDTI parts. > > >Depending on your needs, you may find a LAN->serial device may be more > >appropriate, but you'll have to pay a *lot* more for one of those than for a > >simple USB->serial adapter, However, for a multiport adapter the prices are > >likely to be more comparable. The programmer's view of the device may be > >different than a conventional VMS terminal device (I've no idea how the Digi > >USB boxes are presented to VMS). > > They show up as TXDn:. I think the third letter indicates which driver > (ultimately which chip) is being used. > > Unfortunately, the customer doesn't want to use a terminal server for some > reason. > > >Various folk make PCI->serial cards (obviously including Digi). In some > >cases they can be a more sensible alternative to these trendy new LAN and > >USB things; don't rule them out too quickly. > > Ones that work with VMS I64? Can't comment specifically on the VMS I64-specific bit (but I know what I'd bet on in terms of volume commercial kit). Many mainstream PCI serial cards are based on 16550 UARTs or close relatives. Supporting one of those on (any) VMS would presumably be an exercise in kernel mode hackery for the hardware-specific bits, and as it turns out from a quick search of t'Internerd, VMS on IA64 appears to have SRdriver for 16550-based serial consoles. It may not be quite what you need (console drivers rarely are) but combined with the generic VMS terminal stuff and the trillions of bits of (non-VMS) 16550-based code, there's a few things to look at. Dropping characters from someone hitting return on a terminal doesn't at first glance sound like a particularly demanding application in hardware terms, but USB in the middle does add to the complexity and make it trickier to see what's happening where and when. ------------------------------ Date: Thu, 30 Oct 2008 10:29:17 -0400 From: "forrret.kenney@hp.com_nospam" Subject: Re: USB to Serial Line interface for OpenVMS Itanium/VMS 8.3 Message-ID: The Radio Shack page show the older one with the PL2303. The mapping is. TXA - USB modems that conform to modem specification there were some a Compaq model, a USB that I know of TXB - PL2303 TXC - FTDI 232 TXD - Digiboard If you do the following and post it here I can see it faster than through the support channels. But for an official answer you need to log a case. 1) UCM SET LOG/NEW 2) Plug in device that does not configure 3) UCM sho event/type=all I will pass that to the person who did the digiboard driver. Also the same data for the failing digiboard would help. There are debugging hooks for the digi ones that write data into the log that can be enabled when it gets to that point. I did not do the drivers for Digi so I have to dig some to help. So if I read all this you have some digi controllers that work but drop characters on a single line. Then some others that don't configure at all. The dropping characters on only one line is likely going to be hard to find. We did heavy load loop back testing on the controllers before we shipped them and the test tool detects lost characters. We did not see that problem in our testing. Forrest ------------------------------ Date: Thu, 30 Oct 2008 12:22:48 +0000 From: "Main, Kerry" Subject: RE: VAX-11/785 microdiagnostics help requested Message-ID: <9D02E14BC0A2AE43A5D16A4CD8EC5A593ED83B3BDE@GVW1158EXB.americas.hpqcorp.net> > -----Original Message----- > From: alderson+news@panix5.panix.com > [mailto:alderson+news@panix5.panix.com] On Behalf Of Rich Alderson > Sent: Wednesday, October 29, 2008 8:43 PM > To: Info-VAX@Mvb.Saic.Com > Subject: VAX-11/785 microdiagnostics help requested > > We have rebuilt the power supplies in two 785s (one native, one a 780- > 5, i. e. > field-upgraded from a 780), and are starting out with diagnostics. > > The 11/03 front ends run the LSI-11 diagnostics fine. > > When we boot the system floppy, insert the Microdiagnostics floppy, and > type > TEST, we do not get the results we expect from the documentation. > > On the 785, we get a complaint about the SBI, and drop into ODT. > > On the 780-5, we drop into ODT. > > Does anyone here remember far enough back to impart a clue or two as to > what is > going on? > > -- > Rich Alderson "You get what anybody gets. You get a > lifetime." > news@alderson.users.panix.com --Death, of the > Endless Going back into my memory banks, I seem to remember that the SBI cables can be a real prob troubleshooting and flaky cables did cause issues with Udiags as I recall. One tip I remember us doing is to pwr off and remove the sbi cables and see if the udiag tests got any further. If yes, then you knew the issue was not in the CPU, but on the SBI. Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-254-8911 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT) OpenVMS - the secure, multi-site OS that just works. ------------------------------ Date: Thu, 30 Oct 2008 07:22:53 -0700 (PDT) From: jan.andersson@axfood.se Subject: Re: VAX-11/785 microdiagnostics help requested Message-ID: <37b9bb79-207b-43bb-bd55-6e40d0ac3af3@m32g2000hsf.googlegroups.com> On 30 Okt, 01:43, Rich Alderson wrote: > We have rebuilt the power supplies in two 785s (one native, one a 780-5, = i. e. > field-upgraded from a 780), and are starting out with diagnostics. > > The 11/03 front ends run the LSI-11 diagnostics fine. > > When we boot the system floppy, insert the Microdiagnostics floppy, and t= ype > TEST, we do not get the results we expect from the documentation. > > On the 785, we get a complaint about the SBI, and drop into ODT. > > On the 780-5, we drop into ODT. > > Does anyone here remember far enough back to impart a clue or two as to w= hat is > going on? > > -- > Rich Alderson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"You get what anybody ge= ts. You get a lifetime." > n...@alderson.users.panix.com =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 --Death, of the Endless I have worked with VAXes a long time ago and I don't remember any TEST command. What one do is to boot the diagnostic floppy to get Diagnostic Supervisor prompt. Do you have a DS> prompt? Do you have this manual? http://vt100.net/mirror/hcps/ds780ug2.pdf ------------------------------ End of INFO-VAX 2008.587 ************************