INFO-VAX Sun, 19 Aug 2007 Volume 2007 : Issue 453 Contents: RE: Alpha/Integrity Dead Pool RE: Alpha/Integrity Dead Pool Re: Free to good home. Microvaxes, Vaxstations, Alphas Re: Free to good home. Microvaxes, Vaxstations, Alphas Re: Fun with bugs Re: Gzip 1.3.12? Re: Gzip 1.3.12? Re: Gzip 1.3.12? Re: Gzip 1.3.12? Re: Gzip 1.3.12? Re: Gzip 1.3.12? Re: Intel marginalizing Itanium even faster than expected? Re: Intel marginalizing Itanium even faster than expected? Re: Looking for SEDT source code RE: Nasty? was: SSH login welcome message? RE: Nasty? was: SSH login welcome message? Re: Oracle Tutorial For Beginners ! Re: SSH login welcome message? Re: To HP: How To Stop Negativity on C.O.V. Useful paper on Network Security, in Particular IPsec Re: Wonderful things happen to an OS when it has an internal champion Re: Wonderful things happen to an OS when it has an internal champion Re: Wonderful things happen to an OS when it has an internal champion RE: Write locked file Re: Write locked file Re: Zip (was Re: Gzip 1.3.12?) ---------------------------------------------------------------------- Date: Sat, 18 Aug 2007 17:59:48 +0000 From: "Main, Kerry" Subject: RE: Alpha/Integrity Dead Pool Message-ID: > -----Original Message----- > From: Paul Raulerson [mailto:paul@raulersons.com] > Sent: August 18, 2007 1:04 PM > To: Info-VAX@Mvb.Saic.Com > Subject: RE: Alpha/Integrity Dead Pool > > > > > Sure, but prior to this announcement there was no offical tie-up in > > > place, > > > now there is. IBM will be an OEM for Solaris and will be able to > > offer > > > service subsciptions. > > > > > > The more interesting part of the announcement is regarding the > > > port of Solaris to POWER. > > > > > And Solaris is being ported to the mainframe under z/VM as well. > > http://www.sinenomine.net/node/607 > > Now I wonder what it would take to port VMS to the mainframe? I wonder what it would take to port z/OS to OpenVMS? :-) Actually, I used to say there was only two OS platforms that supported true active-active clustering and they had the same initials VMS and MVS. Course, then the names were changed :-) Btw, not sure if you knew this but z/OS runs on Integrity. Reference: http://www.platform-solutions.com/news/system64_announcement.pdf And Solaris is coming to Integrity as well: http://www.transitive.com/news/news_20070620_2.htm http://www.itjungle.com/breaking/bn062007-story01.html Who says there is a shortage of platforms for Integrity? :-) Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-592-4660 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT) OpenVMS - the secure, multi-site OS that just works. ------------------------------ Date: Sat, 18 Aug 2007 19:44:15 -0500 From: "Paul Raulerson" Subject: RE: Alpha/Integrity Dead Pool Message-ID: <001f01c7e1fa$11aa8550$34ff8ff0$@com> > -----Original Message----- > From: Main, Kerry [mailto:Kerry.Main@hp.com] > Sent: Saturday, August 18, 2007 1:00 PM > To: Info-VAX@Mvb.Saic.Com > Subject: RE: Alpha/Integrity Dead Pool > > > -----Original Message----- > > From: Paul Raulerson [mailto:paul@raulersons.com] > > Sent: August 18, 2007 1:04 PM > > To: Info-VAX@Mvb.Saic.Com > > Subject: RE: Alpha/Integrity Dead Pool > > > > > > > > Sure, but prior to this announcement there was no offical tie-up > in > > > > place, > > > > now there is. IBM will be an OEM for Solaris and will be able to > > > offer > > > > service subsciptions. > > > > > > > > The more interesting part of the announcement is regarding the > > > > port of Solaris to POWER. > > > > > > > > And Solaris is being ported to the mainframe under z/VM as well. > > > > http://www.sinenomine.net/node/607 > > > > Now I wonder what it would take to port VMS to the mainframe? > > I wonder what it would take to port z/OS to OpenVMS? > > :-) > > Actually, I used to say there was only two OS platforms that supported > true > active-active clustering and they had the same initials VMS and MVS. > > Course, then the names were changed :-) > > Btw, not sure if you knew this but z/OS runs on Integrity. > Yep- we had lunch with those folks last Tuesday, and got a good long look at the brand new 64 core model they put out. It is definitely sweet, since the PSI guys are all Amdahl folks, and really know what they are talking about. The box is limited to 2000 Mainfame MIPS though (with 64 cores running!), less if you are running concurrent Windows on it. That's kind of iffy for a lot of installations. And of course, IBM will NOT license anything to run on the beastie, so legally, all you can run is zLinux. But it is SWEET. You can move processor cores from Windows to zArch and back seamlessly. Applications never even know it happened, except that they suddenly find they have more or less processors. So you *can* run z/OS on Integrity, just requires the PSI firmware "enhancements." They are pretty adamant in claiming it is not an emulator, but I've yet to see the Itanium chip that can execute: MVC 0(40,R1),0(R2) AHI R2,40 ... ... and so on. :) > Reference: > http://www.platform-solutions.com/news/system64_announcement.pdf > > And Solaris is coming to Integrity as well: > http://www.transitive.com/news/news_20070620_2.htm > http://www.itjungle.com/breaking/bn062007-story01.html > > Who says there is a shortage of platforms for Integrity? > > :-) > > Regards > > > Kerry Main > Senior Consultant > HP Services Canada > Voice: 613-592-4660 > Fax: 613-591-4477 > kerryDOTmainAThpDOTcom > (remove the DOT's and AT) > > OpenVMS - the secure, multi-site OS that just works. > > > ------------------------------ Date: 19 Aug 2007 05:48:45 GMT From: "dave weatherall" Subject: Re: Free to good home. Microvaxes, Vaxstations, Alphas Message-ID: <5iq3ttF3qgq4mU1@mid.individual.net> Elliott Roper wrote: > In article <5inn4tF3q4kqpU1@mid.individual.net>, dave weatherall > wrote: > > > Elliott Roper wrote: > > > > > > Translating the e-mail addy is a bit of a waste now. Almost all > > > the good stuff is gone. I have three semi-broken Alpha 4/100's , > > > one DECServer 200, 2 VLCs, and a broken Alpha 3000. Oh, and a > > > pile of CRT monitors that is not getting too much attention. > > > > Cursing the fact that you didn't announce this in June while I was > > back in the UK enjoying a break in the country's wettest June ever > > :) Or did you? I was also making the newsreader move from OS/2 to > > (sorry to admit) Windows and missed lots of stuff. (Some very sad). > > No, it was Phillip Helbig while visiting from Germany who came to grab > some long promised bits who convinced me I could easily do better than > sending the rest to the tip. > I should have made a cleaner break with it all three years ago. It > took me that long to realise I'd never get it all working again, I'm > so pleased that nearly all of it has found a good home. I know the probem with time and kit. I'm pleased the kit found good homes. -- Cheers - Dave ------------------------------ Date: 19 Aug 2007 05:52:04 GMT From: "dave weatherall" Subject: Re: Free to good home. Microvaxes, Vaxstations, Alphas Message-ID: <5iq444F3q22g2U1@mid.individual.net> Ron Johnson wrote: > On 08/18/07 02:58, dave weatherall wrote: > [snip] > > you? I was also making the newsreader move from OS/2 to (sorry to > > admit) Windows and missed lots of stuff. (Some very sad). > > Shame on you for not moving to Linux. You'd be happier. I did consider it Ron. I even considered OS/2 in a VM but I was moving the machine it was on back to the UK and didn't have so much time to plan it. Might still do so. I run my Simh VAX on DEBIAN when I have the time (a truly valuable commodity). -- Cheers - Dave ------------------------------ Date: 18 Aug 2007 14:09:44 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: Fun with bugs Message-ID: In article <1187385572.866590.233810@i13g2000prf.googlegroups.com>, Doug Phillips writes: > On Aug 17, 3:47 pm, John Reagan wrote: >> I didn't say value, I said state. BOOLEAN variable has 3 states (TRUE, >> FALSE, and UNDEFINED). Only when the state isn't UNDEFINED can one >> trust the value in memory. >> > > Sorry. Please substitute the word "state" for the one appearance of > the word "value" in my question. > >> We didn't pick TRUE for UNDEFINED, we picked the only store (albeit a >> conditional one) earlier in the code. > > I understand now. I've been burned by that in the past. I found one of those in the past year (in code someone else wrote) on a different architecture in a different programming language. Illegal programs are just one more method for the computer to do other than what I wanted. ------------------------------ Date: 18 Aug 07 14:43:09 EDT From: cook@wvnvms.wvnet.edu (George Cook) Subject: Re: Gzip 1.3.12? Message-ID: <5FYipUAjv2xN@wvnvms> In article , "John E. Malmberg" writes: > Steven M. Schweda wrote: >> As always, complaints are welcome. Getting it to build with VAX C >> was more of an ordeal than before. > > Unless you are sure that a package will still build on VMS 5.4 or > earlier, there is no point in leaving any VAX C specific build > procedures or hacks in the code. I always make it a point to be sure that as much of VMS Mosaic as possible will build with VAX C (on both VMS 5.4-3 and 7.3). That way I can be reasonably sure that it will build with any version of DEC C. Unfortunately some versions of DEC C were unable to build the last Mosaic release because I was unable (without doing significant cleanup of the code) to build LibTIFF with VAX C. For the same reason, I always ensure that Mosaic will build with DECwindows V1.1. That way I know it will probably build with all other old DECwindows releases. The fact that I know of no user who has built it with VAX C or DECwindows V1.1 since the last century (if I recall correctly) is beside the point. Users do build it with versions of DEC C, VMS and DECwindows which are far from current. George Cook WVNET ------------------------------ Date: Sat, 18 Aug 2007 21:04:12 GMT From: "John E. Malmberg" Subject: Re: Gzip 1.3.12? Message-ID: George Cook wrote: > In article , "John E. Malmberg" writes: > >>Steven M. Schweda wrote: >> >>> As always, complaints are welcome. Getting it to build with VAX C >>>was more of an ordeal than before. >> >>Unless you are sure that a package will still build on VMS 5.4 or >>earlier, there is no point in leaving any VAX C specific build >>procedures or hacks in the code. > > > I always make it a point to be sure that as much of VMS Mosaic as > possible will build with VAX C (on both VMS 5.4-3 and 7.3). That way > I can be reasonably sure that it will build with any version of DEC C. VAX C is an ancient pre-standard dialect of C that only sightly resembles ANSI C. While it can be used to build useful programs, anytime that a version of HP/CPQ/DEC C can be used, VAX C should not be used. And the newer version of DEC/HP/Compaq C, the better. Successful compiling under VAX C does not guarantee forward compatibility with DEC C or future version of HP C because VAX C does not know how to diagnose many programming errors. Using the /STANDARD=VAXC flag on DEC C is really just suppressing compiler diagnostics. These are the main differences: 1. DEC/CPQ/HP C is more compliant with the C language standard. 2. DEC/CPQ/HP C produces better code, it has a far superior optimizer. 3. The DEC C rtl is being maintained and has had many bug fixes and enhancements to comply with the ANSI and X/Open standards. 4. The DEC C compiler, unless you tell it to be in VAX C mode will diagnose many errors in a program that VAX C will happily compile. If you need to provide C code for before VMS 5.5-2, GCC/VAX might actually be a more viable build option than VAX C. Both are unsupported, but at least with GCC/VAX, you can redistribute it, and rebuild/repair most of the compiler as needed. Too bad some of the source code to GCC/VAX got lost so that the GCC.EXE wrapper program can not be rebuilt. If you want the most portability and maintainability: I would recommend that you start out with the programs building under the current HP C, with out specifying VAX C compatibility mode and put in the fixes needed to make sure that it compiles and links cleanly. Chances are that any changes you need to make the current HP C compiler happy are latent bugs in the original code that are bugs on all platforms. Until recently GCC by default did not diagnose some classes of bugs. Then only put in the minimum changes needed to make it work on the older compilers, and have that code only conditionally active when those ancient compilers are detected. In most cases, you will probably find that the VAX C changes where actually not needed. If you are building using the old GCC/VAX, then you need the header files that I submitted to the DECUS archive in the 1998 - 2000 timeframe. The code there also shows how to have GCC/VAX use the better performing DECC$SHR instead of the VAXCRTL. -John wb8tyw@qsl.network Personal Opinion Only ------------------------------ Date: Sat, 18 Aug 2007 19:48:06 -0500 (CDT) From: sms@antinode.org (Steven M. Schweda) Subject: Re: Gzip 1.3.12? Message-ID: <07081819480621_20200296@antinode.org> From: "John E. Malmberg" > Please take a look at the packages that I have put in the GNV directory > of ftp.encompasserve.org, particularly the pkg-config tool, and the > release notes for it. Are you offering any hints as to what I'll find there, or do I need to unpack the PCSI kit to have a look? > I just took a quick look at the code. It is not returning the correct > exit status codes for either DCL, MMS, make or bash. > 1. You must compile with DEC C or later. (can be worked around with > some pain) Requiring DEC/Compaq/HP C is ok with me. > 2. You must compile with /DEFINE=_POSIX_EXIT and you must make sure that > the header files with exit() and wait() are #include. LOCAL_GZIP=_POSIX_EXIT=1 I didn't see any %CC-I-IMPLICITFUNC complaints, so, pending contrary evidence, I'm willing to assume that the right headers were used. > 3a. If you are using HP C/CXX 7.1 or later, you must use the > /MAIN=POSIX_EXIT on the command line when compiling the module > containing the main function. It can be used on other modules too, but > will be ignored. "CCOPTS=/MAIN=POSIX_EXIT" > 3b. If you are using HP/DEC/Compaq C/CXX earlier than 7.1, you need put > a wrapper around the main functions to make sure that exit() is called > and not return. It's ok with me if a newer compiler is needed to make it work as you'd like. > The more recent DEC/Compaq/HP C Compilers have a "/FIRST_INCLUDE" > qualifier that allows doing these steps with out modifying the UNIX source. > > This is a sample of a wrapper: > [...] See "CCOPTS" usage, above. > It is possible that a wrapper to the pipe() code may be needed when it > is used by other GNV utilities. Wouldn't amaze me at all. So, if you build the thing as below (with a recent compiler), what's still bad? mms /desc = [.vms] /macr = (LARGE=1, LOCAL_GZIP=_POSIX_EXIT=1, - "CCOPTS=/MAIN=POSIX_EXIT") ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: 18 Aug 07 22:47:23 EDT From: cook@wvnvms.wvnet.edu (George Cook) Subject: Re: Gzip 1.3.12? Message-ID: In article , "John E. Malmberg" writes: > George Cook wrote: >> In article , "John E. Malmberg" writes: >> >>>Steven M. Schweda wrote: >>> >>>> As always, complaints are welcome. Getting it to build with VAX C >>>>was more of an ordeal than before. >>> >>>Unless you are sure that a package will still build on VMS 5.4 or >>>earlier, there is no point in leaving any VAX C specific build >>>procedures or hacks in the code. >> >> >> I always make it a point to be sure that as much of VMS Mosaic as >> possible will build with VAX C (on both VMS 5.4-3 and 7.3). That way >> I can be reasonably sure that it will build with any version of DEC C. > > VAX C is an ancient pre-standard dialect of C that only sightly > resembles ANSI C. > > While it can be used to build useful programs, anytime that a version of > HP/CPQ/DEC C can be used, VAX C should not be used. And the newer > version of DEC/HP/Compaq C, the better. My main build environment always has the latest versions of DEC C, VMS and DECwindows that I can safety introduce without affecting other users of the system. Alpha HP C is currently at V7.3 (the latest if I recall correctly). I only do VAX C builds after major code additions or during the final stages of testing a new release. > Successful compiling under VAX C does not guarantee forward > compatibility with DEC C or future version of HP C because VAX C does > not know how to diagnose many programming errors. True, never said it did, but compiling with VAX C will catch stuff that early versions of DEC C also couldn't deal with. For example, DEC C V6.0 gives a warning (causing a standard Mosaic build to fail) for the following in LibTIFF due to the 'inline': inline static int32 find0span (unsigned char* bp, int32 bs, int32 be) { I believe I would have found this issue if I had been able to compile LibTIFF with VAX C. Instead a user had to find it for me. > Using the /STANDARD=VAXC flag on DEC C is really just suppressing > compiler diagnostics. Mosaic last made use of /STANDARD=VAXC in 1998. > These are the main differences: > > 1. DEC/CPQ/HP C is more compliant with the C language standard. > > 2. DEC/CPQ/HP C produces better code, it has a far superior optimizer. > > 3. The DEC C rtl is being maintained and has had many bug fixes and > enhancements to comply with the ANSI and X/Open standards. > > 4. The DEC C compiler, unless you tell it to be in VAX C mode will > diagnose many errors in a program that VAX C will happily compile. > > If you need to provide C code for before VMS 5.5-2, GCC/VAX might > actually be a more viable build option than VAX C. > > Both are unsupported, but at least with GCC/VAX, you can redistribute > it, and rebuild/repair most of the compiler as needed. Too bad some of > the source code to GCC/VAX got lost so that the GCC.EXE wrapper program > can not be rebuilt. > > If you want the most portability and maintainability: > > I would recommend that you start out with the programs building under > the current HP C, with out specifying VAX C compatibility mode and put > in the fixes needed to make sure that it compiles and links cleanly. That has always been standard procedure since I started maintaining Mosaic over ten years ago. > Chances are that any changes you need to make the current HP C compiler > happy are latent bugs in the original code that are bugs on all > platforms. Until recently GCC by default did not diagnose some classes > of bugs. > > Then only put in the minimum changes needed to make it work on the older > compilers, and have that code only conditionally active when those > ancient compilers are detected. The Mosaic code base (except LibTIFF and libpng) contains only a dozen conditional code changes required for VAX C compilation and linking, and a number of those could be easily eliminated (some are little more than historical artifacts form the first port of X Mosaic to VMS). > In most cases, you will probably find that the VAX C changes where > actually not needed. > > If you are building using the old GCC/VAX, then you need the header > files that I submitted to the DECUS archive in the 1998 - 2000 > timeframe. The code there also shows how to have GCC/VAX use the better > performing DECC$SHR instead of the VAXCRTL. I also do builds using GCC/VAX V2.7.1. Keeping it supported is actually more work than supporting VAX C, but building with it also sometimes catches stuff which might cause some versions of DEC C to have problems. George Cook WVNET ------------------------------ Date: Sat, 18 Aug 2007 22:25:08 -0500 (CDT) From: sms@antinode.org (Steven M. Schweda) Subject: Re: Gzip 1.3.12? Message-ID: <07081822250877_20200296@antinode.org> From: cook@wvnvms.wvnet.edu (George Cook) > [...] Alpha HP C is currently at V7.3 [...] I don't suppose that there's a freely accessible download spot for a kit, is there? The old ftp.compaq.com C-CXX spot seems to have stopped at V7.1, and I haven't noticed a flood of cheap recent SPL kits on Ebay recently. Is it time for a new Hobbyist CD (or even DVD) set yet? (I'd say that it's past time for a nice Hobbyist download site. What's that old saying about beggars and choosers? Still, while VMS beats HP-UX in this department, it's hard to beat the Sun Solaris and Sun Studio (now version 12) offerings. (Which reminds me, I'm still using Studio 11. Must be time for another free download.)) ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Sun, 19 Aug 2007 04:18:26 GMT From: "John E. Malmberg" Subject: Re: Gzip 1.3.12? Message-ID: Steven M. Schweda wrote: > From: "John E. Malmberg" > >>Please take a look at the packages that I have put in the GNV directory >>of ftp.encompasserve.org, particularly the pkg-config tool, and the >>release notes for it. > > Are you offering any hints as to what I'll find there, or do I need > to unpack the PCSI kit to have a look? It has a few hints about building using GNV bash, but also shows a lot of the stuff that I needed to do to get the things to both build and pass the built in tests. Most of it is done with out editing the source modules or the UNIX build procedures. The GNV bash based builds both run the self tests, and also run the install phase to identify what files are installed on UNIX. As far as I know, there is really nothing that would stop building the portion of GNV that is needed to this type of build on VAX. The main issues with building newer stuff on VAX is the lack of support for 64 bit integers by DECC C, and the expectation that filenames can contain characters from the EFS character set. For some applications there is also the issue that IEEE floating point is required. Most of the GNU build tools are made to be cross platform so that they do not require any of those features. If the current GCC could be ported to VAX, it would provide the solution to the 64 bit integer support, as it provides it on other 32 bit platforms. The EFS character set issue, has been solved with SAMBA with some success by putting a wrapper around calls to the CRTL filename functions. Might be nice if the other tools on VAX or even ODS-2 on AXP/I64 could also handle those encoded filenames. > So, if you build the thing as below (with a recent compiler), what's > still bad? > > mms /desc = [.vms] /macr = (LARGE=1, LOCAL_GZIP=_POSIX_EXIT=1, - > "CCOPTS=/MAIN=POSIX_EXIT") Those options should work. I was looking for those in either the DCL command file or in the header files. I did not look in the mms file, as I only had time for a quick look. How are you dealing with UTF-8 v.s. VTF-7 issues? Many existing applications expect that UTF-8 encoded filenames be stored on ODS-5 disks in VTF-7 format, and VTF-7 format filenames can not be translated to UNIX syntax by the CRTL. -John wb8tyw@qsl.network Personal Opinion Only ------------------------------ Date: Sat, 18 Aug 2007 16:15:51 -0500 From: David J Dachtera Subject: Re: Intel marginalizing Itanium even faster than expected? Message-ID: <46C76187.5C42C512@spam.comcast.net> Ron Johnson wrote: > > On 08/17/07 13:42, JF Mezei wrote: > > Ron Johnson wrote: > >> Gah! I agree with Kerry!!!! > > > > > > Don't worry. That is not as bad/dangerous as "agreeing with JF". The > > former is just an oddity. The latter has the potential to cause > > disruptions in the fabric of space/time :-) > > Then what happens when one agrees with Boob? See the Book of Revelation. -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: Sat, 18 Aug 2007 18:00:57 -0500 From: Ron Johnson Subject: Re: Intel marginalizing Itanium even faster than expected? Message-ID: On 08/18/07 12:00, FredK wrote: [snip] > > Golly. On the one hand I appear untaleted/unexperienced (since I haven't > left) and on the other hand I can't be replaced. > > The one thing I have noticed in the last 30 years of working in the computer > industry - many people think they are unique and can't be replaced - they > are invariably wrong. Sure you can be instantly replaced. By someone who is equally knowledgeable and talented. > FredK has done many things and knows many things and likes to think he is > irreplaceable - but he knows deep down that it isn't true. A 20-something > who doesn't know any better can pick up and take over his code. That's just a big steaming pile of poo. A *good* 30yo developer could pick it up with 6-12 months of mentoring (and I'm taking about the deep internals, not cloning and modifying SCSI drivers). A *good* humble 25yo developer who realizes he doesn't know every- thing and that what he was taught in school was usually wrong, could also pick it up with 6-12 months of mentoring. But how many of those are there? > Sure. > FredK has a lot of historical knowledge - but in fact sometimes a clean > slate can be very useful. But not with the ton of legacy that is VMS. Rdb seems to be suffering a similar fate, and bugs are slipping in at a rate that I don't remember happening before. > VMS is less vulnerable from loss of engineers, than from people who spend > their time spreading FUD about Integrity just because they are POed about > Alpha. -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: 19 Aug 2007 05:55:00 GMT From: "dave weatherall" Subject: Re: Looking for SEDT source code Message-ID: <5iq49kF3p4q0tU1@mid.individual.net> VAXman- @SendSpamHere.ORG wrote: > In article <000301c7e1b2$38556fa0$7ef1a8c0@hpxp>, "Hank Vander Waal" > writes: {...snip...} > > Thanks for the trigger. I tried some years ago to build SEDT on > > Solaris (I use it everywhere else) but had trouble with the 'make' > > process and had too many more interesting things to do on VMS :) > > > > There are a couple of bugs in the VMS version that I've meant to fix > > for years, if I had the time, the source and the build procedure. > > The simplest is to increase the storage for filenames from 80 to > > 255 (well it's enough for ODS-2). Thanks to Brian's link to the > > DECUS library, I might just try again. > > Let me know if you do and how successful you are with it. Will do Brian -- Cheers - Dave ------------------------------ Date: Sat, 18 Aug 2007 19:33:22 -0500 From: "Paul Raulerson" Subject: RE: Nasty? was: SSH login welcome message? Message-ID: <001a01c7e1f8$8c940b80$a5bc2280$@com> > -----Original Message----- > From: VAXman-@SendSpamHere.ORG [mailto:VAXman-@SendSpamHere.ORG] > Sent: Saturday, August 18, 2007 12:40 PM > To: Info-VAX@Mvb.Saic.Com > Subject: RE: Nasty? was: SSH login welcome message? > > In article <001201c7e1b4$5d75c2b0$18614810$@com>, "Paul Raulerson" > writes: > > > > > >Yeah- well- I am a little ashamed for snapping like that. No excuse at > all > >to do that. The reason however, was exhaustion and frustration. :/ > > > >Apologies again. > > > >-Paul > > Everyone has their bad day(s); I've had a bad lifetime. > > I've been under incredible stress and strain for, at least, the past 2 > years which I thought was unbearable but that was trumped in the past > month. I've been acerbic more than my fair share of late but if you'd > have the shit in your life that I have, you'd tend to be a bit caustic > too. > Come to Austin- I'll buy you a beer or root-beer, whatever your preference. I think I am going to need to change jobs soon and that is something I just really did not want to do at this time in my life. That offer is pretty much open to anyone coming into the area by the way. -Paul > I only commented that I didn't the the google link was negative or in > way nasty is all I was saying. Every now and then we all just let off > some stream -- just watch that you don't boil over. :) > > -- > VAXman- A Bored Certified VMS Kernel Mode Hacker > VAXman(at)TMESIS(dot)COM > > "Well my son, life is like a beanstalk, isn't it?" > > http://tmesis.com/drat.html ------------------------------ Date: Sun, 19 Aug 2007 02:08:00 GMT From: VAXman- @SendSpamHere.ORG Subject: RE: Nasty? was: SSH login welcome message? Message-ID: <4CNxi.82$9x7.8@newsfe12.lga> In article <001a01c7e1f8$8c940b80$a5bc2280$@com>, "Paul Raulerson" writes: {...snip...} > Come to Austin- I'll buy you a beer or root-beer, whatever your preference. Too much sugar in root-beer so I'll hold out for a pint of Guinness... assuming you know of a watering hole which pumps Guinness. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" http://tmesis.com/drat.html ------------------------------ Date: Sat, 18 Aug 2007 18:03:40 -0500 From: Ron Johnson Subject: Re: Oracle Tutorial For Beginners ! Message-ID: On 08/18/07 11:45, P. Sture wrote: > In article <46C7114A.2060406@cox.net>, > Ron Johnson wrote: >> On 08/18/07 03:26, seotutor wrote: >>> This is just a short introduction to Oracle for beginners, to give a >>> brief history of databases and Oracle's role in that history, explain >>> relational theory and provide a few practical examples to show how >>> relational databases work.There is also a very brief discussion of >>> object-oriented design ... >>> >>> http://flying-rugs.com/oracle >> It's got formatting "issues". >> >> http://members.cox.net/ron.l.johnson/flying-rugs.png > > Er, yes. Did you think to look up the poster's IP address first? > > Sorry, that's not a fair question - Peter Weaver would know why I looked > it up. It's a Chinese address. It seemed pretty dubious from the get-go, but I decided to try it anyway, since it's not like my system could be infected with Windows malware. -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: 18 Aug 2007 14:22:22 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: SSH login welcome message? Message-ID: In article <000001c7e14a$b9150320$2b3f0960$@com>, "Paul Raulerson" writes: > This is a multipart message in MIME format. > > ------=_NextPart_000_0001_01C7E120.D03EFB20 > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: 7bit > > What file(s) hold the welcome message for SSH logins? > > -Paul > > > ------=_NextPart_000_0001_01C7E120.D03EFB20 > Content-Type: text/html; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > xmlns:o=3D"urn:schemas-microsoft-com:office:office" = > xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = > xmlns=3D"http://www.w3.org/TR/REC-html40"> > > > charset=3Dus-ascii"> > > > > > > > >
> >

What file(s) hold the welcome message for SSH = > logins?

If that message for SSH is different from that for normal logins, isn't the answer going to depend on which of the TCP/IP implementations you are using ? I did not notice a specification of which stack you were using. >

-Paul

> >
> > > > > > ------=_NextPart_000_0001_01C7E120.D03EFB20-- > ------------------------------ Date: Sat, 18 Aug 2007 16:19:23 -0500 From: David J Dachtera Subject: Re: To HP: How To Stop Negativity on C.O.V. Message-ID: <46C7625B.4501B6C@spam.comcast.net> VAXman-, @SendSpamHere.ORG wrote: > > In article , "FredK" writes: > > > > > > > >Given some of the vitrol that has gone on for years, I may not live long > >enough for #3. > > That's OK. We'll all just wade in the #2 that's filling the comp.os.vms > stream. ;) Envision: Joe Pesci getting out of the Cadillac and ending up flat on his back in the red mud of Alabama. ("My Cousin, Vinny") Make substitutions as appropriate... -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: Sun, 19 Aug 2007 11:20:56 +0800 From: "Richard Maher" Subject: Useful paper on Network Security, in Particular IPsec Message-ID: Hi, If you're fed-up floundering around with SSH, sftp, SSL et al and are wondering if there's any alternative, then this document could well be worth a read! http://csrc.nist.gov/publications/nistpubs/800-77/sp800-77.pdf Cheers Richard Maher ------------------------------ Date: Sat, 18 Aug 2007 17:43:21 -0500 From: Ron Johnson Subject: Re: Wonderful things happen to an OS when it has an internal champion Message-ID: On 08/18/07 11:55, Main, Kerry wrote: [snip] > > After you do OS virtualization using solutions like VMware, Zen or any other > solution, the next question out of the CIO's mouth will be "Great. Now how > are you going to reduce the number of OS's, so I can cut my FTE numbers?" > > And that is where App stacking, Workload Mgmt comes in. What exactly *is* App Stacking, other than "running multiple apps on the same machine"? -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Sat, 18 Aug 2007 21:48:12 -0400 From: "Richard B. Gilbert" Subject: Re: Wonderful things happen to an OS when it has an internal champion Message-ID: <46C7A15C.7050801@comcast.net> Ron Johnson wrote: > On 08/18/07 11:55, Main, Kerry wrote: > [snip] > >>After you do OS virtualization using solutions like VMware, Zen or any other >>solution, the next question out of the CIO's mouth will be "Great. Now how >>are you going to reduce the number of OS's, so I can cut my FTE numbers?" >> >>And that is where App stacking, Workload Mgmt comes in. > > > What exactly *is* App Stacking, other than "running multiple apps on > the same machine"? > The whole problem, as I understand it, is that Windows has traditionally been not very good at protecting applications from each other! Windows has gotten a great deal better in the last seven years or so but it would still take a brave man to run two applications simultaneously on one server. Running multiple virtual servers on one physical server seems to solve this problem; I guess VMWare provides the protection that Windows cannot! ------------------------------ Date: Sat, 18 Aug 2007 22:38:42 -0400 From: JF Mezei Subject: Re: Wonderful things happen to an OS when it has an internal champion Message-ID: Main, Kerry wrote: > Did you actually read the brochure? I even attended the Decus presentations. VMS doesn't need virtualisation. If you want availability, you want your cluster on separate hardware to begin with. The only advantages to HP's "virtualisation" for VMS is a business one where the licensing allows some tricks under the hood. (get a 16 CPU hardware machine, and create a 3 CPU virtualised VMS instance where you only get licences for 3 CPUs but end up being able to sort of use 16 (but not quite). But none of this couldn't be solved by making VMS more competitive and not needing such tricks to get around the expense of licences. Someone else was right: VMS should be use to virtualise others (aka a virtualisation server). But we all know HP doesn't want to develop VMS's market opportunities so it aisnt gonna happen unless VMS is sold to someone who is interested in growing the VMS marketplace. ------------------------------ Date: 18 Aug 2007 14:18:02 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: RE: Write locked file Message-ID: In article <000901c7e133$d66df2e0$8349d8a0$@com>, "Paul Raulerson" writes: > Use the fstat() call and just look up the process ID it returns. Isn't that something specific to the C programming language ? I did not see the post below indicate that the C programming language was in use (or that any programming language was in use) or that there was a C compiler on the system. >> -----Original Message----- >> From: Mike Minor [mailto:mminorhsd@earthlink.net] >> Sent: Thursday, August 16, 2007 8:28 AM >> To: Info-VAX@Mvb.Saic.Com >> Subject: Write locked file >> >> I have a situation where a .txt file is in a write locked state, but I >> can't >> find the process that has the file locked. I have tried the following >> commands to no avail: >> >> show device/files /system >> show device/files /nosystem >> showdevice/files user1 Is this machine in a cluster ? SHOW DEVICE/FILES must be issued on each member of the cluster. >> All show a list of open files on the system, but the file in question >> does >> not show up. Does anyone have any ideas about how to identify the >> process >> that has the file locked? Depending on the exact VMS error code, it might be an older type of locking. Try the command HELP SET FILE/UNLOCK. ------------------------------ Date: Sat, 18 Aug 2007 22:37:26 +0200 From: "P. Sture" Subject: Re: Write locked file Message-ID: In article , Kilgallen@SpamCop.net (Larry Kilgallen) wrote: > In article <000901c7e133$d66df2e0$8349d8a0$@com>, "Paul Raulerson" > writes: > > > Use the fstat() call and just look up the process ID it returns. > > Isn't that something specific to the C programming language ? > I did not see the post below indicate that the C programming > language was in use (or that any programming language was in use) > or that there was a C compiler on the system. > > >> -----Original Message----- > >> From: Mike Minor [mailto:mminorhsd@earthlink.net] > >> Sent: Thursday, August 16, 2007 8:28 AM > >> To: Info-VAX@Mvb.Saic.Com > >> Subject: Write locked file > >> > >> I have a situation where a .txt file is in a write locked state, but I > >> can't > >> find the process that has the file locked. I have tried the following > >> commands to no avail: > >> > >> show device/files /system > >> show device/files /nosystem > >> showdevice/files user1 > > Is this machine in a cluster ? SHOW DEVICE/FILES must be issued on > each member of the cluster. > > >> All show a list of open files on the system, but the file in question > >> does > >> not show up. Does anyone have any ideas about how to identify the > >> process > >> that has the file locked? > > Depending on the exact VMS error code, it might be an older type > of locking. Try the command HELP SET FILE/UNLOCK. You know, it's been so long that I saw a manifestation of that, that I thought "can't be". Still worth a mention though. -- Paul Sture Sue's OpenVMS bookmarks: http://eisner.encompasserve.org/~sture/ovms-bookmarks.html ------------------------------ Date: Sat, 18 Aug 2007 14:43:00 -0500 (CDT) From: sms@antinode.org (Steven M. Schweda) Subject: Re: Zip (was Re: Gzip 1.3.12?) Message-ID: <07081814430093_20200296@antinode.org> From: Ron Johnson > Does VMS Info-Zip now handle successfully handle files larger than > 4.2M blocks? We tried a VMS-ified ZIP a while back, but had > problems accurately decompressing them. Yes, depending a little on how you define "Info-Zip" and "now". Zip 3.0 and UnZip 6.0 will provide large-file support on systems which have the underlying C run-time support. (On VMS, that's approximately non-VAX V7.3, plus a C RTL ECO for VMS versions older than about V7.3-2.) These UnZip and Zip versions have not yet been released. Old, stale, "BETA" kits should be available at: ftp://ftp.info-zip.org/pub/infozip/beta/ I believe that Zip 3.0e and UnZip 6.00c are safe for data, but UnZip 6.00c may emit a spurious warning message (look for "76 bytes") in some cases. There are some hopes for Zip 3.0f to emerge soon (and that may be _very_ close to the real Zip 3.0), and we'd like to get UnZip 6.00d ready to go at the same time, but that's a bit less certain. Continued breath holding is still dangerous, of course. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ End of INFO-VAX 2007.453 ************************