INFO-VAX Fri, 09 Mar 2007 Volume 2007 : Issue 135 Contents: Availability Manager problem: missing nodes Re: Building I64 bootable OpenVMS media on Alpha Re: Building I64 bootable OpenVMS media on Alpha Re: Building I64 bootable OpenVMS media on Alpha CP-V and VMS (was: Sigma7) Re: DNS- What I'm NOT doing wrong Re: History of VMS and related operating systems Re: History of VMS and related operating systems OT: IBM's Power to power Boeing's 787 Re: PRODUCT INSTAL question Re: PRODUCT INSTAL question Re: Remove All print jobs from a Print Queue Re: Sigma7 Re: Sigma7 Re: Sigma7 Re: Sigma7 Re: Sigma7 Re: SWAT using Samba v3 on VMS8.2 Re: Time zone/DST change question. Re: Time zone/DST change question. ---------------------------------------------------------------------- Date: 8 Mar 2007 14:45:33 -0800 From: "graff" Subject: Availability Manager problem: missing nodes Message-ID: <1173393933.185126.209110@30g2000cwc.googlegroups.com> I recently installed the Availability Manager on our twelve cluster machines. All have the Data Collector installed and the Data Analyzer is installed on three machines. All machines are Alpha running V8.2. On running the Data Analyzer with avail/avail I get information on only four nodes. I have confirmed: 1) that the group name (AMDS$GROUP_NAME) set in AMDS$LOGICALS.COM is the same on all nodes; 2) that the datalink channel (AMDS$DEVICE) is set to an active network card on each node; 3) that the security triplet in AMDS$DRIVER_ACCESS.LOG is the same on all nodes and that the password agrees with what is used by the Data Analyzer; 4) that each Data Collector has been restarted following any changes made necessary by 1) to 3); and 5) that all machines are on the same VLAN (confirmed by quering our Computation Facility and by using traceroute to reach every node in one hop). What am I missing? I've dug through the manual and scanned previous comp.os.vms postings, to no avail. As far I can see, I should be seeing all twelve machines in the Data Analyzer display. Gareth ------------------------------ Date: Thu, 08 Mar 2007 15:48:08 -0500 From: Stephen Hoffman Subject: Re: Building I64 bootable OpenVMS media on Alpha Message-ID: johnhreinhardt@yahoo.com wrote: > My Alpha system that I'm trying to build this on is a V8.2. Should I > upgrade to V8.3? Would that help with the tools at all? If you are restricted to what is supported by HP OpenVMS, then the El Torito structures are likely what can be officially expected and required, and what Mr. Kleinsorge indicates is undoubtedly correct. El Torito is a disk partitioning scheme built on ISO-9660 structures, and it's one of the ways to boot EFI off various media. Basically, the ISO-9660 and El Torito partitioning structures are overlaid onto an ODS-style disk, and the two are merged together. (There's a technique around for initializing an ODS-2 or ODS-5 disk with the region of the disk that is required for the ISO-9660 and El Torito structures reserved, but that's fodder for another discussion.) There are other and unsupported paths that are available toward bootable media that are present in the EFI specifications, and that have been empirically found to work correctly with optical media devices. And that can boot OpenVMS I64. Details on the alternative CD and DVD media bootstraps? Wander over to the old www.HoffmanLabs.com web site, find the link over to the new HoffmanLabs website at the top of the main page of the old site, and go looking for the document "LabsNotes: Recording CD and DVD Media on OpenVMS" at the new site. It's at /node/28, too. Hopefully everything you want to know about recording disks, including how to master and generate recordable media, as well as generating bootable media for OpenVMS I64 and for OpenVMS Alpha, is included in that document. The mastering description does not use and does not require the El Torito and the ISO-9660 structures. I would certainly expect that Mr. Kleinsorge would indicate the approach is unsupported. But it can and does boot on EFI, so it may well address your requirements pending the availability of supported El Torito and ISO-9660 mastering tools for OpenVMS. Hoff -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ Date: Thu, 08 Mar 2007 21:56:24 GMT From: "FredK" Subject: Re: Building I64 bootable OpenVMS media on Alpha Message-ID: "Stephen Hoffman" wrote in message news:espsqc$t93$1@pyrite.mv.net... > johnhreinhardt@yahoo.com wrote: > >> My Alpha system that I'm trying to build this on is a V8.2. Should I >> upgrade to V8.3? Would that help with the tools at all? > > If you are restricted to what is supported by HP OpenVMS, then the El > Torito structures are likely what can be officially expected and required, > and what Mr. Kleinsorge indicates is undoubtedly correct. > > El Torito is a disk partitioning scheme built on ISO-9660 structures, > and it's one of the ways to boot EFI off various media. Basically, the > ISO-9660 and El Torito partitioning structures are overlaid onto an > ODS-style disk, and the two are merged together. (There's a technique > around for initializing an ODS-2 or ODS-5 disk with the region of the disk > that is required for the ISO-9660 and El Torito structures reserved, but > that's fodder for another discussion.) > > There are other and unsupported paths that are available toward bootable > media that are present in the EFI specifications, and that have been > empirically found to work correctly with optical media devices. And that > can boot OpenVMS I64. > > Details on the alternative CD and DVD media bootstraps? Wander over to > the old www.HoffmanLabs.com web site, find the link over to the new > HoffmanLabs website at the top of the main page of the old site, and go > looking for the document "LabsNotes: Recording CD and DVD Media on > OpenVMS" at the new site. It's at /node/28, too. Hopefully everything > you want to know about recording disks, including how to master and > generate recordable media, as well as generating bootable media for > OpenVMS I64 and for OpenVMS Alpha, is included in that document. > > The mastering description does not use and does not require the El > Torito and the ISO-9660 structures. I would certainly expect that Mr. > Kleinsorge would indicate the approach is unsupported. But it can and > does boot on EFI, so it may well address your requirements pending the > availability of supported El Torito and ISO-9660 mastering tools for > OpenVMS. > Mr K? Such formality. Actually I figured if I waited a few hours before replying, you would probably reply first with a pointer to the information without my having to try and guess. I was right - thanks ;-) ------------------------------ Date: Thu, 08 Mar 2007 16:16:23 -0500 From: JF Mezei Subject: Re: Building I64 bootable OpenVMS media on Alpha Message-ID: Stephen Hoffman wrote: >HoffmanLabs offers OpenVMS mastering services and related assistance. Well, there you go, problem solved. Hire HoffmanLabs to do the dirty work of creating an IA64 bootable media from your Alpha. If you are a hobbyist, I fully expect the owner of HoffmanLabls to have hobbyists rates for his services :-) :-) :-) ------------------------------ Date: Thu, 08 Mar 2007 21:40:07 -0600 From: Chris Scheers Subject: CP-V and VMS (was: Sigma7) Message-ID: <55c38lF24ab7fU1@mid.individual.net> Keith Parris wrote: > Chris Scheers wrote: >> When you say Sigma-7, do you mean CP-V? > > CP-V was the operating system which ran on the Sigma. CP-6 came later > under Honeywell. Yes, I am aware of that. My early computer learning was with CP-V on a Sigma-9. A couple of my friends were on the CP-6 acid test team. IIRC, though, there were OSes other than CP-V which could run on the Sigma-7, so I was asking for clarification. Trivia question to bring this back to a VMS theme: What parts of VMS were influenced by CP-V? -- ----------------------------------------------------------------------- Chris Scheers, Applied Synergy, Inc. Voice: 817-237-3360 Internet: chris@applied-synergy.com Fax: 817-237-3074 ------------------------------ Date: Thu, 8 Mar 2007 10:52:27 -0800 From: "John Gemignani, Jr." Subject: Re: DNS- What I'm NOT doing wrong Message-ID: wrote in message news:OF5A179291.E164B056-ON85257297.006E70F2-85257297.006E823B@metso.com... > > > koehler@eisner.nospam.encompasserve.org (Bob Koehler) wrote on 03/07/2007 > 02:43:05 PM: > >> In article <20070306175701.8c9af71d.m_roguski@yahoo.com>, Marcin >> 'Rambo' Roguski writes: >> > >> > Happy news, AS is now in its third day of uptime, >> > pretty good result for machine that was supposed >> > to be dead :) >> >> Have you put it on a network and given it a node name yet? >> Lazurus perhaps? >> > .. or Dracula? > That's only if it runs at night, is kept in a dark room/closet or squeaks like a bat. Does it smell of smoke? How about Phoenix? Was it wrapped up with tape? How about Mummy? If the console buttons are flaky and you can't shut it off easily, how about Zombie? Chupakabra gets honorable mention here because Wikipedia has such a good article on it. John ------------------------------ Date: Thu, 08 Mar 2007 20:01:58 GMT From: John Reagan Subject: Re: History of VMS and related operating systems Message-ID: Steve Lionel wrote: > > As for languages, VAXELN Pascal was derived at least in part from VAX > Pascal V2 and also used its run-time library with minor edits. My > memory is a bit hazy regarding the compiler, it might have used > Cutler's VCG and the parser might have been independent. Perhaps John > Reagan will chime in with his recollections. > VAXELN Pascal was not derived from any VAX Pascal compiler. VAX Pascal is written in BLISS and has its own VAX code generator. VAXELN Pascal (aka EPASCAL) was written mainly in PL/1 and used an older copy of the VCG code generator. I'm not sure where Don McLaren came up with the language definition or the parser, but given the politics, it certainly wasn't from VAX Pascal. EPASCAL did use the same RTL interface so that you could compile/link/run many EPASCAL programs on VMS, but I'm not sure that was ever documented or supported. Later in EPASCAL's life, it did end up under my control for a year or so. It was after Cutler, et al left the company. I honestly don't remember when it left me since I was working on hooking VAX Pascal to GEM back in the early 1990s. I had a few engineers working solely on EPASCAL and I tried not to learn too much about it. We also added some new features in VAX Pascal to make it more compatible with EPASCAL allegedly for ELN customers who might want to return to VMS with their existing code. However, I doubt that it was useful given the limited set of things we added. -- John Reagan HP Pascal/{A|I}MACRO/COBOL for OpenVMS Project Leader Hewlett-Packard Company ------------------------------ Date: Thu, 08 Mar 2007 18:54:36 -0800 From: "Tom Linden" Subject: Re: History of VMS and related operating systems Message-ID: On Thu, 08 Mar 2007 12:01:58 -0800, John Reagan wrote: > Steve Lionel wrote: > >> As for languages, VAXELN Pascal was derived at least in part from VAX >> Pascal V2 and also used its run-time library with minor edits. My >> memory is a bit hazy regarding the compiler, it might have used >> Cutler's VCG and the parser might have been independent. Perhaps John >> Reagan will chime in with his recollections. >> > > VAXELN Pascal was not derived from any VAX Pascal compiler. VAX Pascal > is written in BLISS and has its own VAX code generator. VAXELN Pascal > (aka EPASCAL) was written mainly in PL/1 and used an older copy of the > VCG code generator. I'm not sure where Don McLaren came up with the > language definition or the parser, but given the politics, it certainly > wasn't from VAX Pascal. I'm curious what you mean by the politics. A few years earlier, Freiburghouse did a LALR style Pascal based on the Wirth definition which we successfully hooked up to the PL/I backend on the Prime. > > EPASCAL did use the same RTL interface so that you could > compile/link/run many EPASCAL programs on VMS, but I'm not sure that was > ever documented or supported. > > Later in EPASCAL's life, it did end up under my control for a year or > so. It was after Cutler, et al left the company. I honestly don't > remember when it left me since I was working on hooking VAX Pascal to > GEM back in the early 1990s. I had a few engineers working solely on > EPASCAL and I tried not to learn too much about it. > > We also added some new features in VAX Pascal to make it more compatible > with EPASCAL allegedly for ELN customers who might want to return to VMS > with their existing code. However, I doubt that it was useful given the > limited set of things we added. > > -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ------------------------------ Date: Thu, 08 Mar 2007 20:28:55 -0500 From: JF Mezei Subject: OT: IBM's Power to power Boeing's 787 Message-ID: <5c597$45f0b873$cef8887a$30850@TEKSAVVY.COM> >=20 http://www.flightglobal.com/articles/2006/09/26/209179/787-special-system= s-advance.html Kerry Main's "server consolidation" takes to the air :-) For its 787, in order to save weigth and power demand, Boeing's contracto= r has=20 decided to consolidate many cockpit systems together. It will be PowerPC = based,=20 running Wind River Systems=92 VxWorks 653 real-time operating system (RT= OS) which=20 will support many applications in the cockpit (about 80 different functio= ns). Interestingly, dropping old military protocols, Boeing is going for Ether= net on=20 the aircraft with ethernet switches, some fibre segment and some twisted = pair. Honneywell is using another OS, Greel Hill RTOS for the FMS system. (Flig= ht=20 management system, not the VMS FMS software :-) Imagine if Alpha were still alive and had won that contract to supply the= =20 systems to Boeing. ------------------------------ Date: Thu, 08 Mar 2007 16:23:07 -0500 From: JF Mezei Subject: Re: PRODUCT INSTAL question Message-ID: <59567$45f07ed5$cef8887a$15355@TEKSAVVY.COM> OK, never mind. Even if I do a PRODUCT INSTALL without the /NORECOVERY, it warns me that the recovery data from the previous patch will be zapped. Is it correct to assume that only the most recently applied patch can be rolled back with that recovery data ? ------------------------------ Date: Thu, 8 Mar 2007 16:49:23 -0500 From: norm.raphael@metso.com Subject: Re: PRODUCT INSTAL question Message-ID: JF Mezei wrote on 03/08/2007 04:23:07 PM: > OK, never mind. Even if I do a PRODUCT INSTALL without the > /NORECOVERY, it warns > me that the recovery data from the previous patch will be zapped. > > Is it correct to assume that only the most recently applied patch > can be rolled > back with that recovery data ? IIRC you can have many ECO recovery subdirectories. If you want to roll back the antipenultimate ECO, however, you need to roll back the uptimate ECO, then the penaultimate ECO, then the antipenultimate ECO, and then reapply what was the penultimate ECO and then reapply what was the ultimate ECO. You've got to back them out one at a time, to the offending ECO, then reapply the ones you backed out that you still need. If you do a product update (like a compiler, for example) or an OS version update, PCSI assumes you will need the disk space and zaps all recovery data. So it depends WHAT you are PRODUCT INSTALLing. ------------------------------ Date: 8 Mar 2007 13:38:34 -0800 From: "bclaremont" Subject: Re: Remove All print jobs from a Print Queue Message-ID: <1173389914.111033.132210@t69g2000cwt.googlegroups.com> I believe the set of procedures at this link will do the trick for you: http://www.migrationspecialties.com/zip/CLEARQ.zip If not, it will provide a good starting point to build your own utility. Description: CLEARQ allows a user to clear entries from a queue. The procedure presents queue entries one at a time and allows the user To remove the entry from the queue via a Y/N query. If a queue name is passed to the procedure, it is validated. If no queue name is passed, it is prompted for. On Entry: P1 - Queue name (Optional) P2 - ALL_JOBS (Optional: Valid for privileged user only) ( Can be abbreviated to ALL. ) Good Luck! Bruce Claremont www.MigrationSpecialties.com OpenVMS Stealth Marketing Squad ------------------------------ Date: 8 Mar 2007 18:56:36 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: Sigma7 Message-ID: <55b4j3F204aguU1@mid.individual.net> In article <55b1ecF23coalU1@mid.individual.net>, Chris Scheers writes: > Bill Gunshannon wrote: >> How's this for a longshot? >> >> Does anyone here have a utility that can run on VMS that can read a >> Sigma7 Backup tape? Our Registrar's Office needs to get at data on >> a very old tape. I am the only one here with 9-tracks anymore so >> they came to me. I can read the raw diles, but because the tape is >> in backup format I can't do much of anything else with it. Can't even >> identify the names of the files. > > When you say Sigma-7, do you mean CP-V? > > Or was some other OS used to write the tape? No idea. I wasn't here at the time and no one who was remembers much about it. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 8 Mar 2007 19:03:12 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: Sigma7 Message-ID: <55b4vfF204aguU2@mid.individual.net> In article , Keith Parris writes: > I used a Sigma 7 (actually the similar Sigma 6) in college as well. As I > recall, it used EBCDIC (or some flavor of that) as the character set, so > that may explain your inability to readily recognize filenames in the > tape dump. Reading EBCDIC isn't a problem. I have read the entire tape into files of the form "file.xxx" where "xxx" is a sequential number. There were about 500 files and a total of 4.7 mb. (It turned out to be an 800 bpi tape.) As I said, U suspect this is just one reel of a backup set and as such is not of much value. In any event, I was able to examine enough of the data to determine that what they are looking for isn't there and even if it were, it would very likely not be in any form they could have used as without the programs to tell you how the data was written, how would you interpret it? I can (obviously) read names and addresses which are in human readable format, but how would you interpret numerical information like a students grades? I checked and this one reeel is all they have. So the project is pretty much dead. It does bring up an interesting point, however. In looking in their vault it is apparent that numerous tapes were kept from the IBM system that was the next in line (followed by a VAX). But, if the data center no longer has the hardware to read them, what good are they? :-) bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 8 Mar 2007 19:42:47 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: Sigma7 Message-ID: <55b79kF24due4U1@mid.individual.net> In article <45F062B0.4040300@comcast.net>, "Richard B. gilbert" writes: > Bill Gunshannon wrote: >> In article , >> Keith Parris writes: >> >>>I used a Sigma 7 (actually the similar Sigma 6) in college as well. As I >>>recall, it used EBCDIC (or some flavor of that) as the character set, so >>>that may explain your inability to readily recognize filenames in the >>>tape dump. >> >> >> Reading EBCDIC isn't a problem. I have read the entire tape into files >> of the form "file.xxx" where "xxx" is a sequential number. There were >> about 500 files and a total of 4.7 mb. (It turned out to be an 800 bpi >> tape.) As I said, U suspect this is just one reel of a backup set and >> as such is not of much value. In any event, I was able to examine enough >> of the data to determine that what they are looking for isn't there and >> even if it were, it would very likely not be in any form they could have >> used as without the programs to tell you how the data was written, how >> would you interpret it? I can (obviously) read names and addresses >> which are in human readable format, but how would you interpret numerical >> information like a students grades? >> >> I checked and this one reeel is all they have. So the project is pretty >> much dead. >> >> It does bring up an interesting point, however. In looking in their >> vault it is apparent that numerous tapes were kept from the IBM >> system that was the next in line (followed by a VAX). But, if the data >> center no longer has the hardware to read them, what good are they? :-) >> > > The obvious answer is: Without the necessary hardware and software to > read the tapes and interpret the data, they are simply a waste of space. That's pretty much what I told them this morning. Although, given what data they were looking for, it would have been possible to write the data to a tape in an agnostic way so that any hardware that could read the tape could return it to the user in a format that would at least allow them to manipulate it manually. > > If there is a requirement that the data be available for some period of > time then hardware and software capable of retrieving the data must be > maintained. Preaching to the choir. And, I can assure you, this incident will change nothing in the local datacenter. I really should start a data recovery business ont he side. Witht he hardware I have in my house I could probably make more doing that than my real job. > > If so, I would suggest copying the tapes to DVD (multiple copies of > course). If the data is in EBCDIC, converting to ASCII would probably > be a good idea while anyone still living remembers how. Converting from EBCDIC was just an option on the command I used to read the tape. (Which, by the way, I did on a VAX. :-) > > It's also worth noting that magnetic tapes have a limited storage life. > The binder which holds the magnetic oxide tends to break down into > useless goo. The tape itself, if not wound forward and rewound every > few years tends to develop stresses that will damage it. Temperature > and humidity controlled storage will keep tapes readable longer but the > usable life is measured in years rather than decades or centuries. Again, preaching to the choir. I am sure that everyone here knows this. But then, we are not the ones coming up with all this old data. I have a half-dozen tapes from the Chem department sitting in the back waiting for me to get the time to actually take a shot at reading them. I suspect I will find the same thing with these. Lots of data which no one will have any idea the format of. :-) But when you are the resident dino- saur and the only one who has the equipment and the knowledge needed to read them.......... bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 8 Mar 2007 20:30:14 GMT From: bill@triangle.cs.uofs.edu (Bill Gunshannon) Subject: Re: Sigma7 Message-ID: <55ba2kF23j9cfU1@mid.individual.net> In article <45F06A60.5010207@comcast.net>, "Richard B. gilbert" writes: > Bill Gunshannon wrote: >> In article <45F062B0.4040300@comcast.net>, >> "Richard B. gilbert" writes: >> >>>Bill Gunshannon wrote: >>> >>>>In article , >>>> Keith Parris writes: >>>> >>>> >>>>>I used a Sigma 7 (actually the similar Sigma 6) in college as well. As I >>>>>recall, it used EBCDIC (or some flavor of that) as the character set, so >>>>>that may explain your inability to readily recognize filenames in the >>>>>tape dump. >>>> >>>> >>>>Reading EBCDIC isn't a problem. I have read the entire tape into files >>>>of the form "file.xxx" where "xxx" is a sequential number. There were >>>>about 500 files and a total of 4.7 mb. (It turned out to be an 800 bpi >>>>tape.) As I said, U suspect this is just one reel of a backup set and >>>>as such is not of much value. In any event, I was able to examine enough >>>>of the data to determine that what they are looking for isn't there and >>>>even if it were, it would very likely not be in any form they could have >>>>used as without the programs to tell you how the data was written, how >>>>would you interpret it? I can (obviously) read names and addresses >>>>which are in human readable format, but how would you interpret numerical >>>>information like a students grades? >>>> >>>>I checked and this one reeel is all they have. So the project is pretty >>>>much dead. >>>> >>>>It does bring up an interesting point, however. In looking in their >>>>vault it is apparent that numerous tapes were kept from the IBM >>>>system that was the next in line (followed by a VAX). But, if the data >>>>center no longer has the hardware to read them, what good are they? :-) >>>> >>> >>>The obvious answer is: Without the necessary hardware and software to >>>read the tapes and interpret the data, they are simply a waste of space. >> >> >> That's pretty much what I told them this morning. Although, given what >> data they were looking for, it would have been possible to write the >> data to a tape in an agnostic way so that any hardware that could read >> the tape could return it to the user in a format that would at least >> allow them to manipulate it manually. >> >> >>>If there is a requirement that the data be available for some period of >>>time then hardware and software capable of retrieving the data must be >>>maintained. >> >> >> Preaching to the choir. And, I can assure you, this incident will >> change nothing in the local datacenter. I really should start a >> data recovery business ont he side. Witht he hardware I have in my >> house I could probably make more doing that than my real job. >> >> >> >>>If so, I would suggest copying the tapes to DVD (multiple copies of >>>course). If the data is in EBCDIC, converting to ASCII would probably >>>be a good idea while anyone still living remembers how. >> >> >> Converting from EBCDIC was just an option on the command I used to >> read the tape. (Which, by the way, I did on a VAX. :-) >> >> >>>It's also worth noting that magnetic tapes have a limited storage life. >>> The binder which holds the magnetic oxide tends to break down into >>>useless goo. The tape itself, if not wound forward and rewound every >>>few years tends to develop stresses that will damage it. Temperature >>>and humidity controlled storage will keep tapes readable longer but the >>>usable life is measured in years rather than decades or centuries. >> >> >> Again, preaching to the choir. I am sure that everyone here knows this. >> But then, we are not the ones coming up with all this old data. I have >> a half-dozen tapes from the Chem department sitting in the back waiting >> for me to get the time to actually take a shot at reading them. I suspect >> I will find the same thing with these. Lots of data which no one will >> have any idea the format of. :-) But when you are the resident dino- >> saur and the only one who has the equipment and the knowledge needed >> to read them.......... >> >> bill >> >> > > Well, if they are legally obligated to preserve the data, someday they > are going to get a whopping big bill from somebody for reading crumbling > media of some sort! I tried to get that point accross to them this morning as well, but I would imagine it fell on deaf ears. I am actually more curious about potential liability when some important record becomes lost due to storage incompatabilities. Especially with the speed at which the technology is changing today. > > Resident dinosaur? I like that. Too bad you don't have a two ton tail > to lash about! ;-) It's worse than that. I understand out newest professor happened to walk by the office when the woman from the Registrar's Office was handing the tape to my boss. He looked at it and asked what it was!! bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Thu, 08 Mar 2007 18:46:12 -0800 From: "Tom Linden" Subject: Re: Sigma7 Message-ID: On Thu, 08 Mar 2007 16:10:15 -0800, Keith Parris wrote: > Chris Scheers wrote: >> When you say Sigma-7, do you mean CP-V? > > CP-V was the operating system which ran on the Sigma. CP-6 came later > under Honeywell. At ESA we ran CP-V and BTM (Batch Time-Sharing Monitor) and maybe RBM -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ------------------------------ Date: Thu, 08 Mar 2007 21:48:02 -0600 From: "Craig A. Berry" Subject: Re: SWAT using Samba v3 on VMS8.2 Message-ID: In article <1173269449.124295.143020@v33g2000cwv.googlegroups.com>, "dky" wrote: > On Mar 5, 5:27 pm, Dan Foster wrote: > > In article <1173096835.192402.101...@p10g2000cwp.googlegroups.com>, dky > > wrote: > > > > > PS: > > > Can someone provide a shell account on an IA64 box running VMS 8.3, I > > > can continue working onSamba. I am no longer with HP and hence no > > > access to a VMS box. > > > > If it doesn't require privileges for porting efforts, you could sign up > > for a HP TestDrive account which has VMS V8.3 on I64 systems and access > > is provided for this kind of purpose (amongst others). > > I have a testdrive account. The last I checked, it did not have MMS, > compiler etc... that I would require for development. I will need just > enough privileges to define system wide logicals and someone need to > create an account with few identifiers. This is required _now_ as we > added UNIX group support which was missing in CRTL. Using the newly > added group support, we can work towards ACL support. The testdrive systems certainly do have a full suite of build tools and always have, as far as I know. For example, here's what's on there now: $ mms/ident %MMS-I-IDENT, MMS T3.8 Copyright 2006 Hewlett-Packard Development Company, L.P. $ cc/vers HP C V7.2-022 on OpenVMS IA64 V8.3 For system logicals and identifiers, that's probably a bit harder to come by. -- Posted via a free Usenet account from http://www.teranews.com ------------------------------ Date: 8 Mar 2007 11:59:30 -0800 From: "n.rieck@sympatico.ca" Subject: Re: Time zone/DST change question. Message-ID: <1173383970.696177.112290@v33g2000cwv.googlegroups.com> "JF Mezei" wrote in message news:f35b8$45ef317b$cef8887a$31024@TEKSAVVY.COM... > After some sleep and a dose of chocolate, I reread the release notes > carefully and the SYS$TIMEZONE_DIFFERENTIAL is not changed. > > Negative still means west of GMT. > > So I have to assume that there is some other command procedure on the > system that was modified to parse GMT* specification for selected time > zones differently and converts it back to normal time differences. > > I really do not understand why someone would have decided to switch the > meaning of the sign around. The concept of negative offset for west of GMT > is truly rooted in so much stuff, including GPS etc. It seems extremely > stupid to change it, especially since the underlying logic still expected > a negative offset for west of GMT. > > I take it that they weren't stupid enough to require all SMTP and NNTP > clients to change the date nomenclature so that times specified as offset > to GMT wouldn't have to have their signs flipped ? > Anything I have found, so far, talks about these GMT changes being necessary for POSIX compliance. And although I can think of a few cases where it would be better to rename the string "GMT-4" to "GMTMINUS4", it makes no sense to me to change the sign. I was shocked when I saw the number of Solaris-8 applications (like LDAP) that needed to interpret time zones. TIMEZONE definitions will change again which means that all OSs should do it only in one place. All other timestamps sent between computers should only be sent in GMT or UTC. Neil Rieck Kitchener/Waterloo/Cambridge, Ontario, Canada. http://www3.sympatico.ca/n.rieck/links/cool_openvms.html http://www3.sympatico.ca/n.rieck/links/openvms_demos.html ------------------------------ Date: Thu, 08 Mar 2007 15:50:41 -0500 From: Stephen Hoffman Subject: Re: Time zone/DST change question. Message-ID: n.rieck@sympatico.ca wrote: > On Mar 7, 9:07 pm, bradhamilton wrote: >> bradhamilton wrote: >> >> "Bad form", but here goes: >> >> After re-reading the release notes for the Nth time, I finally realized >> that "GMT-" and GMTPLUS" referred to menu options in UTC$TIME_SETUP.COM >> that I have never used; therefore the notes were not relevant to my >> situation. >> >> Whoever decided to change a standard to mean the exact opposite of its >> previous meaning should be forced to split rocks for the remainder of >> their natural lives. >> > I was thinking that a little longer time in purgatory may be > appropriate. On a related note, didn't we learn a thing from Y2K? It > seems to me that things have gotten worse since then. It's the POSIX TZ stuff, as this has the positive hour values west of Greenwich, where UTC has negative values in the same regions. Read the timezone definitions -- seriously. The definition files are text files, and the comments can make for some interesting reading. (I've posted some related material over at the new HoffmanLabs web site.) And stay as far away from GMT as you can, as it's very ambiguous. -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ End of INFO-VAX 2007.135 ************************