INFO-VAX Sat, 08 Sep 2007 Volume 2007 : Issue 490 Contents: Re: DECServer 700 help Re: DECServer 700 help Re: Here's one for Bob (hope it makes your head spin) Re: I think I might understand N3 and the bullet Re: Intel Launches Quad-Core "Tigerton" Re: node and port alloclass, cannot add a node to the cluster Re: SOAP, WSIT, I'm LOST, sort of... Re: SOAP, WSIT, I'm LOST, sort of... Re: SOAP, WSIT, I'm LOST, sort of... Re: VMS License Plates Re: VMS License Plates ---------------------------------------------------------------------- Date: Sat, 08 Sep 2007 06:05:55 GMT From: "John E. Malmberg" Subject: Re: DECServer 700 help Message-ID: <7ZqEi.74064$Xa3.16332@attbi_s22> bakermo wrote: > OK - it's been a while since I worked with a DECServer 700 so I wonder > if anyone can please give me some advice and/or help? > > I am trying to configure a reverse LAT port from an Alpha GS140 to a > DECServer 700. I have a 4800 baud clock signal that will go into the > DECServer on port 7 and have VMS get the signal on LTA7. > > The clock is ansi characters in the format: > > 203:00:00:02B I presume you mean ASCII. ANSI in this context usually applies to escape sequences used to control terminal functions, usually display features. > I have looked at this signal on a VT320 on a crash cart and it is OK. > (4800 baud, XON, 1 stop bit, noparity). The cable is connected via a > null modem into port 7 of the DS700. > > Here's how the server port is configured: > > Port 7: (Remote) Server: RAQ1TS > > Character Size: 8 Input Speed: 4800 > Flow Control: XON Output Speed: 4800 > Parity: None Signal Control: Disabled > Stop Bits: Dynamic Signal Select: CTS-DSR-RTS-DTR Should be 1 stop bit for anything other than 110 baud. > Access: Remote Local Switch: None > Backwards Switch: None Name: PORT_7 > Break: Local Session Limit: 4 > Forwards Switch: None Type: Ansi > Default Protocol: LAT Default Menu: None > Autolink Timer One:10 Two:10 Dialer Script: None > > Preferred Service: None > Authorized Groups: 0-255 > (Current) Groups: 0-255 > > Enabled Characteristics: > > ========================================================== > > Here's the VMS LAT port: > > Local Port Name: _LTA7: Local Port Type: Application > (Queued) > Local Port State: Active > Connected Link: TSLINK > > Target Port Name: PORT_7 Actual Port Name: PORT_7 > Target Node Name: RAQ1TS Actual Node Name: RAQ1TS > Target Service Name: Actual Service Name: > > ========================================================= > > Here's the VMS LTA7 terminal: > > Terminal: _LTA7: Device_Type: Unknown Owner: NAME > Username: USER > > Input: 4800 LFfill: 0 Width: 132 Parity: None > Output: 4800 CRfill: 0 Page: 64 > > Terminal Characteristics: > Passall No Echo No Typeahead No Escape > No Hostsync No TTsync Uppercase No Tab > No Wrap Hardcopy No Remote Eightbit > No Broadcast No Readsync No Form Fulldup > No Modem No Local_echo No Autobaud No Hangup > No Brdcstmbx No DMA Altypeahd Set_speed > No Commsync No Line Editing Overstrike editing No > Fallback > No Dialup No Secure server No Disconnect Pasthru > No Syspassword No SIXEL Graphics No Soft Characters No Printer > Port > Numeric Keypad No ANSI_CRT No Regis No > Block_mode > No Advanced_video No Edit_mode No DEC_CRT No > DEC_CRT2 > No DEC_CRT3 No DEC_CRT4 No DEC_CRT5 No > Ansi_Color > VMS Style Input > > ======================================================== > > A set host/dte LTA7 will show either nothing or sometime a buch of > characters that seem to be a baud rate mismatch. Are you doing: $allocate lta7 $set term lta7:/type $set host/dte lta7: ..... $deallocate lta7: > Here's what the program is getting for the input: > > > > > Fmterr :OEOO˘ > > Fmterr :OEOOŞ > > Fmterr :OEOO² > > Fmterr :OEOOş > > Fmterr :OEOOA > > Fmterr :OEOOE > > Fmterr :OEOO > > Fmterr :OEOO > > Fmterr :EOO > > > Fmterr :EOO > > > Fmterr :EOO˘ > > > ======================================================================== > > Here's what it should look like: > > date= 7-SEP-2007 00:00:02.91 ,len= 23 > date= 7-SEP-2007 03:59:36.00 ,len= 23 > date= 7-SEP-2007 18:13:53.00 ,len= 23 > > ======================================================================== > > The example from a running program is from another server that is > working except it is via a DS900. No - I don't have access to anything > but the DS700 and the other server is across the country in another > datacenter. > > I copied its port and terminal characteristics with three exceptions. > > 1. The working system has NOAltypeahd on its terminal and I have no > idea how to set that on mine. Altypeahd is a larger type ahead buffer. Having it on should improve things in most cases like this. Usually though I have needed to make it larger via AUTOGEN. But for a clock, it is probably not an issue. > 2. The DS900 has no Signal Select: CTS-DSR-RTS-DTR setting Watch how your cable is wired. If the DS900 does not support a signal pair, it should be jumpered at the end of the cable. CTS should be jumpered to RTS, and DTR should be jumpered to DSR if the cable is not supporting them. Some devices will not send data if the CTS signal is not asserted. If the hardware supports it, it is preferable to use CTS/RTS for handshaking instead of XON/XOFF. Normally though, your device should be asserting DTR when it is on, and that signal will be wired to the DECserver DSR line, which the application can monitor as a sanity check. The DECServer should assert DTR when ever is allocated by an application, the crossover cable should connect this to the device DSR line. Devices may decide not to send data if they do not see a DSR signal. The lack of a DSR signal indicates to them that there is nothing on the other end of the wire. Printers tend to use DTR/DSR for flow control instead of RTS/CTS for some reason. This is preferred as some terminals servers forget the state of the XON/XOFF when they are not allocated to a process on a host. > 3. The DS900 has no Autolink Timer One:10 Two:10 setting I am not remembering what this does, and not sure that it means anything in this application. > I have three systems that are all configured the same (all with > DS700's) and none work. I would think that eliminates a hardware > error. It makes it unlikely that there is a malfunction in the DS700, but does not eliminate other errors. > Any thoughts? The type of noise that you are seeing looks like either a baud rate mis-match or of a wiring error. Verify that you have the baud rate right. Some devices will autobaud, which works when they are connected to a real terminal and someone hits enter, but does not work when they are connected to a computer type device. The application should be setting the port to /typeahead after it assigns a channel to the ltann: device. Failure to do that may cause problems. If modtap or modular connectors are involved, be aware that there are two signal commons on the cable. Both must be connected to the single signal common(ground) on the typical D connector. If you only run one, because of the twist in a NULL modem configuration, you actually end up with no signal commons being connected. Surprisingly I have seen this type of mis-configuration work most of the time, but it tends to fail with the phase of the moon. In one case it was found that the safety ground pin in the powerlines was handling the signal return because the modular to D connectors were miswired by having only one signal common connected at each end. -John wb8tyw@qsl.network Personal Opinion Only ------------------------------ Date: Sat, 08 Sep 2007 07:53:44 GMT From: John Santos Subject: Re: DECServer 700 help Message-ID: Richard B. Gilbert wrote: > bakermo wrote: > >> On Fri, 07 Sep 2007 18:26:00 -0400, "Richard B. Gilbert" >> wrote: >> >> >>> bakermo wrote: >>> >>>> OK - it's been a while since I worked with a DECServer 700 so I wonder >>>> if anyone can please give me some advice and/or help? >>>> >>>> I am trying to configure a reverse LAT port from an Alpha GS140 to a >>>> DECServer 700. I have a 4800 baud clock signal that will go into the >>>> DECServer on port 7 and have VMS get the signal on LTA7. >>>> >>>> The clock is ansi characters in the format: >>>> >>>> 203:00:00:02B >>>> >>>> I have looked at this signal on a VT320 on a crash cart and it is OK. >>>> (4800 baud, XON, 1 stop bit, noparity). The cable is connected via a >>>> null modem into port 7 of the DS700. >>>> >>>> Here's how the server port is configured: >>> >>> >>> >>> >>>> The example from a running program is from another server that is >>>> working except it is via a DS900. No - I don't have access to anything >>>> but the DS700 and the other server is across the country in another >>>> datacenter. >>>> I copied its port and terminal characteristics with three exceptions. >>>> 1. The working system has NOAltypeahd on its terminal and I have no >>>> idea how to set that on mine. >>>> >>> >>> $ SET TERMINAL /NOALTYPEAHD LTAnnn: >> >> >> >> If you look in the DCL dictionary you will see there is no such >> qualifier. > > > My bad! > > It appears that once ALTYPEAHD has been set, there is no way to turn it > off short of logging off and on again. > > If there WERE a way to turn it off, it would be /NOALTYPEAHD. > Yeah, but that's not your problem, unless the sysgen parameter TTY_ALTYPAHD is set to something too small to allow a complete message from the clock to be received. (Normally ALTYPEAHD is used to set a LARGER buffer for some terminal ports, i.e. those used for "high-speed" comms, like for Kermit or X modem, where you might be pumping in large quantities of data.) Something must have done a set term LTA7:/altypeahd/permanent for this to have happened (or there's a non-default value for TTY_DEFCHAR or (maybe) someone set LTA0: to use /altypeahd; it's a template device so its characteristics might propagate to cloned devices such as LTA7:. It may well be that SET TERM/NOALTYPEAHD actually works, even though it isn't documented. If not, it should reset to the permanent characteristics when the device becomes free (log out if logged into it or deallocate it from any owning process and close any I/O channels to it.) If the *permanent* characteristics have been set to /ALTYPEAHD (visible with show terminal/permanent), then the only way to clear it is to write a program (requires LOG_IO privilege) to assign a channel to it, read the current permanent characteristics (QIO with IO$_SENSECHAR function code), clear the right bit, and set them back (IO$_SETCHAR function.) But this isn't your problem, I'm pretty sure. You say the clock works with a terminal connected to it. Are you using the null modem cable? If not, the clock is DCE and the the terminal is DTE. Since the terminal server is also DCE, you need a null modem between the clock and the DECServer. On the other hand, if you do have a null modem between the terminal and the clock, then the clock is DTE and so you want a straight-through connection to the DS700, not a null modem. (This gets complicated to determine if they use different connector types, such as DB25 and MMJ or RJ45. Some of the adapters might be crossing the signals over. This kind of thing is much easier to diagnose with a break-out box, if you can find one.) DS700's came in two varieties, one with 8 modem control ports and DB25 connectors, and the other with 16 non-modem ports with RJ45 connectors. IIRC, the VT320 was MMJ, so you must have some kind of adapter which is clouding the picture. I've never used a DS900, but I think they all had RJ45 ports. I doubt the clock requires modem signals, but it might need hardware flow control (RTS/CTS crossed over.) I think both the DS700 and DS900 ran the same software, but the differences you are seeing in the display might be due to different versions of the software, or because one has modem control ports (DS700) and the other does not. SHOW PORT STATUS on the DS700 should show the current state of the modem signals, but I think you've got it set to ignore them anyway. HTH. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: Sat, 8 Sep 2007 16:49:37 +0000 (UTC) From: david20@alpha2.mdx.ac.uk Subject: Re: Here's one for Bob (hope it makes your head spin) Message-ID: In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: >In article <40ea2$46e0317d$cef8887a$11281@TEKSAVVY.COM>, JF Mezei writes: >> >> Unless the various laws that govern the universe (physics etc) change, >> then the future is already pre-determined. > > What century are you living in? The laws of physics specifically say > that is not so and have said that for about 100 years now. > The newtonian classical universe is entirely deterministic ie a clockwork Universe. Relativity is even stronger. Two events separated in space which I regard as happening simultaneously will be regarded as having happened at different times by someone in an inertial frame which is moving with respect to me. The only way to maintain a single consistent universe is to suppose that space-time forms a fixed block and that the "now" which each inertial frame observer sees is a slice through that fixed block - the angle between the slices viewed by different inertial frame observers being determined by the relative velocities of the different inertial frames. The total fixed block is the complete space-time history of the Universe. Hence the total history of the Universe is fixed ie predetermined. In quantum theory (which I didn't really want to get into again) the Schroedinger wave equation is perfectly deterministic however we don't have an accepted mechanism for the collapse of the wave function (or even in some interpretations an acceptance that it does collapse) hence we are unable to say anything about the deterministic nature of that collapse. David Webb Security team leader CCSS Middlesex University ------------------------------ Date: Sat, 08 Sep 2007 10:06:03 -0700 From: Doug Phillips Subject: Re: I think I might understand N3 and the bullet Message-ID: <1189271163.614591.83890@19g2000hsx.googlegroups.com> On Sep 7, 10:14 pm, Ron Johnson wrote: > Hmmm. I think just had an insight!!! > > As a (fast moving) gas molecule strikes the bullet, there is an N3 > reaction. Bullet goes one way, gas molecule goes the other. > Billions of such continuous tiny reactions: > > First overcome it's static inertia, then accelerate it down the > barrel, imparting more and more kinetic inertia as it zooms down the > barrel. > > As it zooms thru the fluid medium (air, usually), it strikes against > other molecules. These opposing reactions are what is, in > aggregate, known as friction. > > Am I still totally off-base? > Newton's laws are not just about "motion" even though they carry that name, but are about the relationship between forces acting upon objects. Other dead scientists expanded upon those ideas to describe the interaction of force fields and such. An N3 reaction happens when any two (or more) masses or forces interact with each other. The explosion within the chamber (or the cartridge contained by the chamber) reacts with its entire surroundings. You describe what happens to the bullet, whose reaction is most obvious. The relationship between energy, mass and velocity along with other factors, many you've already mentioned, will determine the outcome of the interactions. ------------------------------ Date: Sat, 08 Sep 2007 06:56:29 -0700 From: "Tom Linden" Subject: Re: Intel Launches Quad-Core "Tigerton" Message-ID: On Fri, 07 Sep 2007 10:14:31 -0700, Rick Jones wrote: > There are up to 64 sockets in a Superdome. At present, with dual-core > Montecito that means 128 cores or 256 threads. That should keep lmf busy. -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Sat, 08 Sep 2007 07:22:13 GMT From: John Santos Subject: Re: node and port alloclass, cannot add a node to the cluster Message-ID: Bob Koehler wrote: > In article <20070907155014.GA46122@mech-aslap33.men.bris.ac.uk>, Anton Shterenlikht writes: > >>%CNXMAN, Lost connection to system DONKEY > > > Running through all the messages it really looks like you've got > a network problem. > > > >> CAUTION: If this cluster is running with multiple system disks and >> common system files will be used, please, do not proceed >> unless appropriate logical names are defined for cluster >> common files in SYLOGICALS.COM. For instructions, refer to >> the "OpenVMS Cluster Systems" manual. >> >>I understand that I need to adjust EXPECTED_VOTES only after the new >>node is added successfully. Is that correct? > > > I'd set the proper number of VOTES and EXPECTED_VOTES once you > decide what they are. In your case 1 each and 3, or 1 per boot > disk and 2. > > >>I understand that "multiple system disks" means multiple system >>disks for the same architecture, i.e. 2 alpha system disks, or 3 i64 >>system disks. As I only have a single alpha and a single I64 disk I >>presume I don't have "multiple system disks". Is that correct? > > > You do have multiple system disks as far as the logical names refered > to in the above message are concerned. For example, there should > only be one SYSUAF and all three nodes should have a logical name > pointing to it, unless it just happens to be findable in sys$system: > on that node. So if you put it in sys$common:[sysexe] on the disk > the Alphas share then you only really need to define that on the > IA64. > While what Bob says is correct, but I'm pretty sure it's not your problem. You'll end up with multiple SYSUAF's, multiple queue databases, etc., but that's actually legitimate in some cases (non-homogeneous cluster.) And it won't keep the cluster from forming. You mention a pagefile on the local disk on the new DS10L. Do you have local disks on more than one node? If so, you want the allocation classes to be *different* on each node, unless the "local" disks are actually on a shared SCSI bus. If you have 2 $1$dka0:'s because both alphas (or all 3 systems) have a local SCSI disk named DKA0:, you will have problems, and quite possibly the cluster won't form or one of the nodes will get booted out as soon as it tries to access one of the colliding disks. There are three reasons to have allocation classes: 1) shadowing requires them, 2) to prevent colliding disk names so you can serve them to the other systems and 3) to make sure and disks on a shared SCSI bus have the same name when viewed from any of the systems. If you have allocation class set to 0, then the local disks on node HORSE will be called HORSE$DKcnnn:, and the local disks on node ZEBRA will be ZEBRA$DKcnnn:, which will work fine unless you want to shadow, or connect two of the local SCSI buses together. If instead you assign allocation classes to each system, you want them to be different. I.E. HORSE has 255, ZEBRA has 254, etc. Then HORSE's local disk names are $255$DKcnnn: and ZEBRA's disks are $254$DKcnnn:, no collisions in the name space, and now you can shadow. However, shared SCSI buses will not work. To use shared SCSI buses, all the disks on a given bus must have the same name when viewed from any host on that bus. So you can either give all the systems the SAME allocation class (but again break non-shared disks, unless they all happen to have different controller letters and/or unit numbers, maybe), or the best solution is to give each bus a port allocation class that is the same on all systems. In this case, the bus can be connected to different controllers on each system, i.e. the "A" bus on one and the "B" bus on another, since with port allocation classes, VMS uses a fake device name that is always controller "A". For example, if the DKBnnn: bus on one system is connected to the DKCnnn: bus on the other, then if the PKB: controller on the first system and the PKC: controller on the second are both assigned port allocation class 3, the disks will appear as $3$DKAnnn: on both systems. This makes configuring much more flexible. SAN disks, such as MSA1000's, always show up as $1$DGAnnnn:, (always allocation class 1, always device name DG, always controller "A".) They act kind of like a shared SCSI bus with port allocation class 1 on all systems. So you don't have to worry about name collisions there, but you do have to make sure all the unit id's are different if you have more than 1 SAN array. (SAN tapes are always allocation class 2, i.e. $2$MGAnnnn:) What this all boils down to is you need a set of rules for preventing name collisions for different devices and ensuring names are the same for shared devices. Many people do this by assigning each host a different allocation class, counting down from 255. Then they assign each shared SCSI bus a port allocation class, counting up from 3. (Skipping 1 and 2 used by the MSA1000 or other SAN arrays.) Or you could Google back to a fairly recent post where someone else explained all this, probably much better and including some edge cases I've forgotten about.... HTH -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: Sat, 08 Sep 2007 05:42:16 -0700 From: ja Subject: Re: SOAP, WSIT, I'm LOST, sort of... Message-ID: <1189255336.869710.68940@y42g2000hsy.googlegroups.com> Jan-Erik, -- gSOAP, which Bob Gezelter mentioned, is probably the way for you to go as 1) it is a full-blown Web Service implementation offering both client and server functionality, i.e., VMS acts both as client and server whereby WSIT only acts as a server; 2) it is written entirely in 'C', thus fitting nicely into your current environment; 3) it runs on Alpha and Integrity. It would not be hard at all to integrate it into OSU or, use the mod_gsoap module for Apache which we have just finished porting. -- Windows Servers, or more correctly put, Microsoft, has plenty of software to make the use of Web Services more or less transparent to the user and even developer, be it from MS Office, a program, or whatever. -- the Java environment offers many ways of processing Web Service requests -- as do the 'P' (Perl, Python, PHP) languages -- the reason there is not support for the OBJ2IDL.EXE utility on Alpha is, as Bob already pointed out, due to the fact that the format of an object file on Alpha is not standard and therefore very hard to use to obtain the interfaces of the compiled program. On Integrity the format is well documented and it is therefore easy to parse the file and obtain the interfaces. It should be pointed out that the result of OBJ2IDL.EXE on Integrity can be used equally well on Alpha Cheers, John PS: despite my Martinelli car parked in the HP car park, please feel free to contact me directly as I do, occasionally, actually try and do productive work:-) On Sep 7, 4:43 pm, Jan-Erik S=F6derholm wrote: > Jeffrey H. Coffield wrote: > > Jan-Erik S=F6derholm wrote: > > >> To add the the picture, this "new" interface is ment > >> to complement the current that is a simple mail based > >> communication. The "other side" simply sends a mail > >> to a specific user, using an agreed on subject with a > >> datafile ZIP'ed and attachede using standrad MIME format. > >> On the VMS system ("my" system) this mail is taken care > >> of using DELIVER/MPACK/MUNPACK/UNZIP and the datafile > >> is finely FTP'ed over to an IBM mainframe to be stored > >> into a central DB2 database. The mainframe interface is > >> not the target right now. > > >> Now, some users would like to have an alternative to > >> this mail based communication. FTP has been discussed. > >> WEB Services was also mentioned. And that's why I was > >> asking. > > >> OK, I have to dig a little more into this. > >> As you said, one of the problems with open source > >> stuff is that it might be hard to find a consistant > >> set of documentation... > > >> Jan-Erik. > > > If the "other side" is a person, why not put up a web page with a file > > upload? If the "other side" is a program, then some change would have to > > be made since it currently sends a e-mail. That can usually be switched > > to cURL to do the post. The web page on your side is the same. > > > Jeff Coffield > > No, the other side are different client application. And they'd > like to use the latest busniess buzz-words, of course. Whatever > that looks good in the data sheets. :-) And it should be a fully > automated setup. No manual intervention in any part. > > So, the *BEST* solution for *me*, is one where the client can use > WEB services (or whatever "new" tools they like) and I can > continue with the same hardware/VMS/OSU setup. > > I do not now what tools there are on Windows servers, but WEB Services > was mentioned as one that they'd look at as interesting. > > Now, I guess I need some XML tool to receive and decode whetever > the WEB Servicesa/SOAP tools at the client creates, right ? > > Jan-Erik.- Hide quoted text - > > - Show quoted text - ------------------------------ Date: Sat, 08 Sep 2007 06:49:26 -0700 From: "Tom Linden" Subject: Re: SOAP, WSIT, I'm LOST, sort of... Message-ID: On Fri, 07 Sep 2007 07:43:39 -0700, Jan-Erik Söderholm wrote: > Jeffrey H. Coffield wrote: >> Jan-Erik Söderholm wrote: >> >>> >>> To add the the picture, this "new" interface is ment >>> to complement the current that is a simple mail based >>> communication. The "other side" simply sends a mail >>> to a specific user, using an agreed on subject with a >>> datafile ZIP'ed and attachede using standrad MIME format. >>> On the VMS system ("my" system) this mail is taken care >>> of using DELIVER/MPACK/MUNPACK/UNZIP and the datafile >>> is finely FTP'ed over to an IBM mainframe to be stored >>> into a central DB2 database. The mainframe interface is >>> not the target right now. >>> >>> Now, some users would like to have an alternative to >>> this mail based communication. FTP has been discussed. >>> WEB Services was also mentioned. And that's why I was >>> asking. >>> >>> OK, I have to dig a little more into this. >>> As you said, one of the problems with open source >>> stuff is that it might be hard to find a consistant >>> set of documentation... >>> >>> Jan-Erik. >>> >> If the "other side" is a person, why not put up a web page with a file >> upload? If the "other side" is a program, then some change would have >> to be made since it currently sends a e-mail. That can usually be >> switched to cURL to do the post. The web page on your side is the same. >> Jeff Coffield > > No, the other side are different client application. And they'd > like to use the latest busniess buzz-words, of course. Whatever > that looks good in the data sheets. :-) And it should be a fully > automated setup. No manual intervention in any part. > > So, the *BEST* solution for *me*, is one where the client can use > WEB services (or whatever "new" tools they like) and I can > continue with the same hardware/VMS/OSU setup. > > I do not now what tools there are on Windows servers, but WEB Services > was mentioned as one that they'd look at as interesting. > > Now, I guess I need some XML tool to receive and decode whetever > the WEB Servicesa/SOAP tools at the client creates, right ? IBM's PL/I compiler has an embedded XML parser both on windows and z > > Jan-Erik. -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Sat, 08 Sep 2007 16:35:03 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: SOAP, WSIT, I'm LOST, sort of... Message-ID: ja wrote: > Jan-Erik, > > -- gSOAP, which Bob Gezelter mentioned, is probably the way for you to > go as 1)... OK. Now, is it the sourceforge copy I should get, or is there some VMS specific distribution ? Jan-Erik. ------------------------------ Date: Sat, 08 Sep 2007 09:08:11 +0200 From: Dirk Munk Subject: Re: VMS License Plates Message-ID: Sue wrote: > Dear Newsgroup, > > If you remember we have done VMS License plates over the years. The > last one we did had "When downtime is NOT an option" > > I was thinking about doing them again for our 30th. Let me know what > you think. > > Warm Regards, > Sue > You will love this one: OpenVMS - so reliable that the newsgroup is always OT ------------------------------ Date: Sat, 08 Sep 2007 13:38:37 +0200 From: "P. Sture" Subject: Re: VMS License Plates Message-ID: In article , Dirk Munk wrote: > You will love this one: > > OpenVMS - so reliable that the newsgroup is always OT LOL! -- Paul Sture Sue's OpenVMS bookmarks: http://eisner.encompasserve.org/~sture/ovms-bookmarks.html ------------------------------ End of INFO-VAX 2007.490 ************************