INFO-VAX Tue, 01 May 2007 Volume 2007 : Issue 238 Contents: Re: Apache on OpenVMS 7.2 Alpha Re: Apache on OpenVMS 7.2 Alpha Re: Bob's brain missing. Was Re: Noahs ark found! Re: C++ Garbage Collector on VMS? Re: COPYTREE Question Re: COPYTREE Question Re: cvs client for OpenVMS 7.3-2 Re: Has Linux Peaked ? Re: Has Linux Peaked ? RE: Has Linux Peaked ? Re: Has Linux Peaked ? RE: Has Linux Peaked ? Re: Has Linux Peaked ? Making LIB$*_VM_PAGE Caller's-mode safe Re: Making LIB$*_VM_PAGE Caller's-mode safe Motif routines uses by DECterms Re: Neocons destroying America Re: Neocons destroying America Re: Noahs ark found! RE: numerical libraries on integrity Re: numerical libraries on integrity OT: Favorite movies of the VMS crowd? Re: OT: Kodak Nipping at HP's heels Re: SSH trouble (Was: Has Linux Peaked ?) Re: VAXStation 3100 M38 Re: VAXStation 3100 M38 ---------------------------------------------------------------------- Date: Tue, 01 May 2007 11:19:27 -0400 From: Stephen Hoffman Subject: Re: Apache on OpenVMS 7.2 Alpha Message-ID: jrandrew@hotmail.com wrote: > I am interested in running Apache on OpenVMS (Alpha platform), but the > sysadmins I'm working with have told me that they are running on > OpenVMS version 7.2. HP's website on Apache (and their port to VMS, > Secure Web Server) > http://h71000.www7.hp.com/openvms/products/ips/apache/csws_download.html > > indicates that you need OpenVMS version 7.3-1 at a minimum. > > Is there any way to run Apache on 7.2, or will standard Apache run on > 7.2, i.e. not HP's ported version? What would be some of the issues in > getting Apache to run on 7.2, if possible? Most anything is possible in this particular problem space, given the availability of and the application of appropriate incentives and skills and time. IIRC, the baseline requirement within Secure Web Server (Apache) was due to the availability of C APIs expected by the server. The standard C library has seen a massive influx of new calls in recent OpenVMS releases. In this case, you'll either end up backporting and dealing with your own Apache build, or you'll end up upgrading OpenVMS and dealing with the HP build. Or out-sourcing the backport or the OpenVMS upgrade. WASD is certainly a good option here. Haven't looked for a LightTPD port, but I'd certainly consider that approach. Apache is very powerful, and certainly also not a light-weight web server environment. TANSTAAFL. Staying on an older software release might look to be a free solution, but the approach is not without eventual costs. The costs just tend to sneak up on you. Sometimes incrementally and peripherally, and sometimes a wallet-monster leaps out and consumes your entire down-rev savings. And more. -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ Date: Tue, 1 May 2007 12:46:05 -0400 From: "Neil Rieck" Subject: Re: Apache on OpenVMS 7.2 Alpha Message-ID: <46376265$0$16351$88260bb3@free.teranews.com> "Stephen Hoffman" wrote in message news:f17lq3$21k4$1@pyrite.mv.net... > jrandrew@hotmail.com wrote: > [...snip...] > > Most anything is possible in this particular problem space, given the > availability of and the application of appropriate incentives and skills > and time. > > IIRC, the baseline requirement within Secure Web Server (Apache) was due > to the availability of C APIs expected by the server. The standard C > library has seen a massive influx of new calls in recent OpenVMS releases. > It's been a while since I looked at the release notes but I was under the impression that Apache needed the UNIX Portability APIs associated with OpenVMS-7.3 (and that might be what Hoff was referring to in the paragraph above). But is there some reason the author is trapped on OpenVMS-7.2 ? There are some really cool speed ups built into 7.3-2 and I wouldn't run any Alpha system below that level. In fact, a recent Bruden OSSG presentation states that OpenVMS just keeps getting faster with each incarnation so I can hardly wait to upgrade from 8.2 to 8.3 Neil Rieck Kitchener/Waterloo/Cambridge, Ontario, Canada. http://www3.sympatico.ca/n.rieck/links/cool_openvms.html -- Posted via a free Usenet account from http://www.teranews.com ------------------------------ Date: Tue, 01 May 2007 12:08:29 -0400 From: Dave Froble Subject: Re: Bob's brain missing. Was Re: Noahs ark found! Message-ID: Dirk Munk wrote: > Do you realy think Aren't you aware that such as boob don't think? They mindlessly accept whatever they want to believe. Reality, and thinking, has no place with them. -- David Froble Tel: 724-529-0450 Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc. 170 Grimplin Road Vanderbilt, PA 15486 ------------------------------ Date: Tue, 01 May 2007 11:47:25 -0400 From: Stephen Hoffman Subject: Re: C++ Garbage Collector on VMS? Message-ID: John Santos wrote: > Michael D. Ober wrote: >> "Main, Kerry" wrote in message >> news:FA60F2C4B72A584DBFC6091F6A2B8684022F2EDC@tayexc19.americas.cpqcorp.net... ... >>> From: Michael D. Ober [mailto:"obermd."@.alum.mit.edu.nospam] ... >>> I guess I am still grappling to understand why an application needs to >>> worry about memory management in a virtual memory OS design. I can >>> understand this in the case whereby perhaps an OS does not provide >>> virtual memory capabilities, but memory management seems to me the dept >>> of the OS. The Operating System (OS) most definitely has to worry about this from the perspective of preventing a leak from destabilizing the system. Within the context of a (contained) leaking environment, the level of assistance and even of interest can vary. Most OS environments choose to contain the damage to the process. The Language and the Language Run-Time is generally left holding the proverbial bag, if the bag isn't passed directly to the programmer. (And even when the language helps, the programmer is often required to indicate the relative lifetime of the allocation. The gcc Objective-C (ObjC) environment calls this the autorelease pool, for instance. > ...Note this is *not* an OS issue. It is at best a run-time library > issue, or a compiler issue. Or the programmer can do all the work, > basically implementing a private heap management scheme, which is > a terrible use of programming resources (though probably a very > good educational experience.) It's much better to have someone > or some group of programmers do it once (correctly) and have the > programmers work on the application. Once for each language environment. Mayhap a generic set of routines, but most any OO would have to be modified to call into the generic routines. >> VMS is the only OS that actually has primitives for OS level memory >> management for an application. Examples of these primitives are the >> LIB$ calls. Now look at the market size for VMS - >> tiny compared to Unix/Linux, Windows, and Mac. Given this reality in >> the market place, programmers have had to worry about memory >> management issues. Memory leaks are indigenous to most platforms. If you're working outside of a fixed-allocation environment, you are subject to leaks. On OpenVMS, this is the basis for constructs such as process quotas. >>> What happens when you start virtualizing the application that depends on >>> GC under such environments like VMware (e.g. Windows/Linux) or when you >>> start application stacking with other app's on the same system (e.g. >>> OpenVMS)? GC and virtualization are orthagonal. A proper virtualization won't care about GC, though GC could make the VM more efficient through lower memory requirements and more potentially expensive through increased processor resources. In a perverse view, scheduling is a form of GC for processors. :-) >> This is why the OS itself should really be doing all the memory >> management. > > I'm distinguishing the OS (kernel) from the RTL's. The OS has its own > internal memory management issues (what happens to a BG: device DDB when > the network connection goes away?), but for user code, the proper place > for all this is in the LIB$ or language-specific RTL's (or buried in the > guts of the Java VM, etc.) rather than in the application code. Fully transparent GC isn't cheap, and the caller has to provide some clues as to the expected lifetime of the memory object. Traditional languages don't have this. > > As I stated in another part of this thread, there are research > projects in > > both academia and industry that are working on OS level GC systems. > > In the kernel, executing outside of process context, or as part of the > system library memory heap management package, called by the application > automatically when it allocates or deallocates strings, structures or > other objects? GC has to operate within the application run-time environment, as GC targets application-level memory resources. For one example of this, see the gcc ObjC pieces. Or you have to architect some way to keep these structures isolated -- OpenVMS uses the process and process quotas for this course-grained separation. Implementing your own temporary pools is trivial on OpenVMS. The underlying pieces, however, won't know about these -- only your own memory management calls. It's a limited form of GC. Another discussion of GC is at ; at the HoffmanLabs site. -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ Date: 1 May 2007 07:47:12 +0100 From: "Dave Weatherall" Subject: Re: COPYTREE Question Message-ID: On Tue, 1 May 2007 00:38:25 UTC, JF Mezei wrote: > Chuck Aaron wrote: > > I want to copy a directory and all it's sub directories and files from one > > server to a new server where the directories do not currently exist. > > what is the best way to do this with or without copytree? > > > BACKUP is the tool. But it requires a magic incarnation to get it to > rebuild a new tree that is identical to the original one under the new root. > > Use google for comp.os.vms in the last 2 years search for BACKUP and > [...*] and you'll find a coupl;e of posts of the magic incantation that > ended up working. I do somthing like :- $ backup drive:[root....] other_server::root_1.bck /sav /log /ver It assumes you have an account on other_server and root_1.bck will be placed in SYS$LOGIN there. You can drop the /log but i would keep the /ver. The /log is there to ensure the command has been taken (entered) as I intend it... If you need to specify a username of other server then :- $ backup drive:[root....] other_server"name password"::root_1.bck /sav /log /ver Log on to other_server and then :- $ backup root_1.bck /sav /sel=[root...] new_drive:[root...] /lo /ver /by_own=original This will rebuild the directory tree, maintain file protections, Owner and any ACL's. If you do have ACL identifiers, it would be a good idea to ensure they exist on other_server first. Hope I've not forgotten anything. -- Cheers - Dave W. ------------------------------ Date: 1 May 2007 07:22:02 -0500 From: briggs@encompasserve.org Subject: Re: COPYTREE Question Message-ID: In article , "Dave Weatherall" writes: > On Tue, 1 May 2007 00:38:25 UTC, JF Mezei > wrote: > >> Chuck Aaron wrote: >> > I want to copy a directory and all it's sub directories and files from one >> > server to a new server where the directories do not currently exist. >> > what is the best way to do this with or without copytree? >> >> >> BACKUP is the tool. But it requires a magic incarnation to get it to >> rebuild a new tree that is identical to the original one under the new root. >> >> Use google for comp.os.vms in the last 2 years search for BACKUP and >> [...*] and you'll find a coupl;e of posts of the magic incantation that >> ended up working. > > I do somthing like :- > > $ backup drive:[root....] other_server::root_1.bck /sav /log /ver > > It assumes you have an account on other_server and root_1.bck will be > placed in SYS$LOGIN there. You can drop the /log but i would keep the > /ver. The /log is there to ensure the command has been taken (entered) > as I intend it... > > If you need to specify a username of other server then :- > > $ backup drive:[root....] other_server"name password"::root_1.bck > /sav /log /ver > > > Log on to other_server and then :- > > $ backup root_1.bck /sav /sel=[root...] new_drive:[root...] /lo /ver > /by_own=original > > This will rebuild the directory tree, maintain file protections, Owner > and any ACL's. If you do have ACL identifiers, it would be a good idea > to ensure they exist on other_server first. Those commands look right. Note that BACKUP preserves the numeric values of the rights identifiers appearing in ACLs. It does not preserve the identifier names. One needs to ensure not only that the identifiers exist but also that they have the same numeric value on the target system as the one they had on the source system. It does no good to have ORACLE_ADMINISTRATORS on the source machine with hex code %x80001357 and ORACLE_ADMINISTRATORS on the target machine with hex code %x80001358. And it would be especially unfortunate if the target machine had BAD_HACKERS at %x80001357. The /INTERCHANGE qualifier to BACKUP will cause it to restore the new files using default ACLs picked up from the target directory tree. If the rights database on the source and target machines are not consistent then this may be of considerable use. Of course you lose the original ACLs. If files are owned by UICs or identifiers that do not exist or are not consistently numbered on the target system then one would obviously not want to use /BY_OWNER=ORIGINAL. ------------------------------ Date: 1 May 2007 10:59:01 +0200 From: huber@NIRWANA-mppmu.mpg.de (Joseph Huber) Subject: Re: cvs client for OpenVMS 7.3-2 Message-ID: <+qMrNvdvW239@vms.mppmu.mpg.de> In article <1177977713.806063.37860@n59g2000hsh.googlegroups.com>, RandyG271 writes: > Joseph & Bob, > > Thank you so much for your kind assistance -- it was very helpful. > Here is the changes I made. CVS.EXE now compiles and appears to work > (minus "login" which has been noted on the web). Alas, I'm still left > to wonder about a few things (see below) > > [XX.CVS.LIB]$ diff getopt.h > ************ > File SYSTEMS$HOME:[XX.CVS.LIB]GETOPT.H;2 > 124 /* extern int getopt (); -RandyG */ > 125 extern int getopt (int __argc, char * const __argv[], const > char *__optstring); > 126 extern int getopt_long (int argc, char *const *argv, const > char *shortopts, > ****** > File SYSTEMS$HOME:[XX.CVS.LIB]GETOPT.H;1 > 124 extern int getopt (); > 125 > 126 extern int getopt_long (int argc, char *const *argv, const > char *shortopts, > ************ > ************ > File SYSTEMS$HOME:[XX.CVS.LIB]GETOPT.H;2 > 138 /* extern int getopt (); -RandyG */ > 139 extern int getopt (int __argc, char * const __argv[], const > char *__optstring); > 140 extern int getopt_long (); > ****** > File SYSTEMS$HOME:[XX.CVS.LIB]GETOPT.H;1 > 138 extern int getopt (); > 139 extern int getopt_long (); > ************ > > [XX.CVS.LIB]$ diff getopt.c > ************ > File SYSTEMS$HOME:[PHXPROD.GALBRARA.CVS.LIB]GETOPT.C;2 > 674 char * const argv[]; > 675 const char *optstring; > 676 /* int argc; > 677 char *const *argv; > 678 const char *optstring; -RandyG */ > 679 { > ****** > File SYSTEMS$HOME:[PHXPROD.GALBRARA.CVS.LIB]GETOPT.C;1 > 674 char *const *argv; > 675 const char *optstring; > 676 { > ************ > > The above changes do fix the fatal compile error, however I'm now left > with this warning... > > $ CC getopt.c > > extern int getopt (int __argc, char * const __argv[], const char > *__optstring); > ...........^ > %CC-W-NOTCOMPAT, In this declaration, the type of "cvs_getopt" is not > compatible with the type of a previous declaration of "cvs_get > opt" at line number 583 in file SYS$COMMON:[SYSLIB]DECC$RTLDEF.TLB;2. > at line number 139 in file SYSTEMS$HOME: > [PHXPROD.GALBRARA.CVS.LIB]GETOPT.H;2 > The error message shows the getopt definition is STILL included from DECC$RTLDEF, not from the local getopt.h: if Your CC is not a symbol definition , then no /exclude=(getopt,... is there. You have to be sure also not to have unistd (and possibly stdio) in the getopt compile unit. -- Joseph Huber , Muenchen,Germany: http://www.huber-joseph.de/ ------------------------------ Date: 1 May 2007 02:01:23 -0700 From: shofu_au@yahoo.com.au Subject: Re: Has Linux Peaked ? Message-ID: <1178010083.563277.139040@o5g2000hsb.googlegroups.com> In Australia - IBM is Qantas' outsourcing company. This I think would effect any 'options' Qantas have. ------------------------------ Date: Tue, 01 May 2007 11:33:37 +0200 From: Martin Krischik Subject: Re: Has Linux Peaked ? Message-ID: <46370972$1@news.post.ch> david20@alpha2.mdx.ac.uk schrieb: > In article , Doc writes: >> Martin Krischik wrote in >> news:4635e67a$1@news.post.ch: >>> No syntax highlight, no folding, no code completion, no tabbed edit, >>> no code explorer... You don't know what you have been missing the last >>> 15 years. > Doesn't LSE (The Language sensitive Editor) on VMS do this sort of thing ? LSE certainly has the potential to provide some of those functions thou it's scripting language but apart from folding I don't think LSE does so. And LSE could never provide syntax highlight as this feature needs multiple text colours. Martin ------------------------------ Date: Tue, 1 May 2007 06:31:48 -0400 From: "Main, Kerry" Subject: RE: Has Linux Peaked ? Message-ID: > -----Original Message----- > From: Richard Maher [mailto:maher_rj@hotspamnotmail.com] > Sent: April 30, 2007 11:38 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Has Linux Peaked ? >=20 > Hi Kerry, >=20 > > Heck, many shops I know of are still running 1.4 versions of Java. >=20 > Presumably that includes the 99.9% of any VMS shops that may have been > running Java, 'cos up until very very recently they didn't have a > whole lot > of choice, did they? Didn't Sun release 1.6 of Java before VMS > announced > support for 1.5? >=20 Don't know.=20 Having stated this, if I were running a mission critical shop, I would certainly not allow my developers to be be jumping on the absolute latest and greatest version as soon as it comes out.=20 There is just way to much "version envy/hype" going on today.=20 Good news is that Cust's are staring to realize that unless it has some features that absolutely are required to meet new functionality requirements (vs. app programmers "that would be neat to be able to do ."), or if there are support issues, then it is not going to happen. Not news for most OpenVMS and established Solaris/AIX/HP-UX shops, but it will begin to some shops. Imho, Windows/Linux shops are going to feel this big time. This where version envy and keeping up with the Jones is really at a much higher level. Case in point - read the news about sagging Windows Vista sales. Also, how many UNIX / Windows shops are still running Oracle 9? Heck, even Oracle 8. How many shops are still running Solaris 9? Answer - a very large number based on the data I see in multi-platform consolidation engagements. > Is that project still underway to provide a high-performance industry > compatible C compiler and RTL on VMS? After 20 years and 200million I > reakon > you guys must have just about nailed that fork() thing by now? >=20 Well, I am not sure where that fork piece is in the grand scheme of things, but as you well know, there are other ways of accomplishing the same thing on OpenVMS that take advantage of OpenVMS's architecture features vs that of some other OS features. > Did I also hear that the POSIX shell was making a come back? What was > the > ROI like on that anyway? >=20 > So now the Goal Posts have been set up next to Java? Is that so ISVs > can > port their vast catalogues of Java-based software products to VMS? (Or > is > the installed base supposed to pick up the tab and justify the expense > by, > once again, 180ing their inhouse development strategy to suite the > whim of > DEC/Compaq/HP?) I'd be happy if we just invested the money in keeping > the > ISVs we've already got :-( There is typically no porting of 100% Java app's required for OpenVMS .. after some testing to verify config's, quotas, logicals, performance etc, simply deploy & run the App's on OpenVMS. That's a pretty strong business driver. I have heard of shops that develop Java Apps on Windows for the WS benefits, but deploy on OpenVMS for the stability / security. I suspect the 5-20 security patches released *every month* for Windows/Linux might have something to do with this? [Side bar - for those who think these monthly security patches are not a problem because they have good firewalls, remember that security analysts will tell you that 50-60% of most security issues are caused by internal issues] Hey - I am not saying I believe Java/OO (.Net/J2EE) is the right approach for every application design (actually I am beginning to believe very much the opposite), but at least with Java and IDE tools like NetBeans on OpenVMS, Cust's have a choice in this regard. [snip...] Kerry Main Senior Consultant HP Services Canada Voice: 613-592-4660 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20 OpenVMS - the secure, multi-site OS that just works. ------------------------------ Date: Tue, 01 May 2007 12:54:33 +0200 From: Martin Krischik Subject: Re: Has Linux Peaked ? Message-ID: <46371c69$1@news.post.ch> Main, Kerry schrieb: > Key features are: > - Support for the Java, C/C++, XML, and HTML But no Ada :-( . Martin ------------------------------ Date: Tue, 1 May 2007 07:09:43 -0400 From: "Main, Kerry" Subject: RE: Has Linux Peaked ? Message-ID: -----Original Message----- > From: Martin Krischik [mailto:krischik@users.sourceforge.net] > Sent: May 1, 2007 6:55 AM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Has Linux Peaked ? >=20 > Main, Kerry schrieb: >=20 > > Key features are: > > - Support for the Java, C/C++, XML, and HTML >=20 > But no Ada :-( . >=20 > Martin Not yet.=20 However, if you have a business requirement for this vs. "neat to have", then there are channels to request this be added. Case in point for other language plug-in's: http://h71000.www7.hp.com/openvms/products/ips/netbeans/distnb.html "Distributed NetBeans contains all of the functionality provided in NetBeans for OpenVMS plug-in modules: BASIC, C/C++, COBOL, FORTRAN, and PASCAL language support, and MMS, BASH, DCL, and EDT Keypad support. Distributed NetBeans supports access to your files using a built-in FTP filesystem. The IDE Server runs on both OpenVMS Alpha and OpenVMS I64.=20 Distributed NetBeans includes support for the Web Services Integration Toolkit template and the Ant Import statement for remote Ant execution." Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-592-4660 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20 OpenVMS - the secure, multi-site OS that just works. ------------------------------ Date: Tue, 1 May 2007 07:37:06 -0400 From: "William Webb" Subject: Re: Has Linux Peaked ? Message-ID: <8660a3a10705010437j639eda02y66afd9b2457b9eee@mail.gmail.com> ------=_Part_168255_12093758.1178019426342 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I'd say it works because of the diligence of people like Hunter Goatley and Dan O'Reilly and the people that they've hired to work underneath them. And, for the record, I don't work for Process- but I've worked extensively with both TCP/IP Services (UCX) and Multinet. Each product does certain things better than the other. WWWebb On 30 Apr 2007 11:54:52 GMT, Doc wrote: > > genius@marblecliff.com wrote in > news:1177933256.937443.28610@c35g2000hsg.googlegroups.com: > > > funny, TCPware ssh2 works just fine ... configures in minutes ... > > And - yet again - you prove you're a clueless git Boob. > > TCPware only works because God wants it to. > > Or was it the fact that you're too dense to understand what the guy's > problem with ssh is? He wants to use a key, not a password. > > Personally I suspect that any/all of the Process staff that lurk in this > newsgroup wish you'd stop mentioning their products and being an > embarrassing associate. > > > Doc. > ------=_Part_168255_12093758.1178019426342 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I'd say it works because of the diligence of people like Hunter Goatley and Dan O'Reilly and the people that they've hired to work underneath them.
 
And, for the record, I don't work for Process-
but I've worked extensively with both TCP/IP Services (UCX) and Multinet.
 
Each product does certain things better than the other.
 
WWWebb

 
On 30 Apr 2007 11:54:52 GMT, Doc <doc@openvms-rocks.com> wrote:
genius@marblecliff.com wrote in
news: 1177933256.937443.28610@c35g2000hsg.googlegroups.com:

> funny, TCPware ssh2 works just fine ... configures in minutes ...

And - yet again - you prove you're a clueless git Boob.

TCPware only works because God wants it to.

Or was it the fact that you're too dense to understand what the guy's
problem with ssh is?  He wants to use a key, not a password.

Personally I suspect that any/all of the Process staff that lurk in this
newsgroup wish you'd stop mentioning their products and being an
embarrassing associate.


Doc.

------=_Part_168255_12093758.1178019426342-- ------------------------------ Date: Tue, 1 May 2007 14:13:15 +0800 From: "Richard Maher" Subject: Making LIB$*_VM_PAGE Caller's-mode safe Message-ID: Hi Fred, (Hoff - haven't been seen here for a while?), and everyone else I'd like to resurrect the attached thread and ask if anyone could champion the cause by taking it further. The state of play was: - 1) I put forward the idea for an enhancement request where there are now two heaps one for inner-modes (in reality EXEC only) and another one for outer-modes (in reality USER only) 2) For performance reasons it was argued that rather than have a UWSS for this, the existing LIB$ RTL routines should simply be made caller's mode tolerant by linking to a Global Psect that had been published by SECURESHRP (or a.n.other "protected" image) This would prevent User-mode corruption of the Exec heap's inventory and pointers. 3) Hoff carried the ball as far as the maintainer of the LIB$*VM* facility who balked at the idea for VMS 8.3 due to time constraints. 4) Everyone contributing to the discussion believed the idea had merit and could see no insurmountable obstacles preventing the introduction of same. (Especially as the "default" VM allocation behaviour would not change and a logical name would be used, if so desired, to redirect LIBRTL to the new caller's-mode safe VM routines) So here we are again. As Hoff may not have the same access to people he used to have, or he may be having to work for a living :-) and doesn't have the time for such things, is there someone else in engineering who wants to pick the ball up and win one for the Gipper? Try not to think of it as just for me, 'cos it's not. Shit, do I not wish big time that I could sit in on Andy Goldstein's A177 session on privileged code at the BootCamp! I'm sure there's much I could learn there, but I'd also like to bring up the old chestnut of sys$persona_create sirening us onto the kernel-mode rocks with lib$get_vm. And now there's the new chestnut of sys$getuai saying "Here's the inner-mode channel/stream identifier I've been using for SYSUAF; make sure you give me back the same one tomorrow!". Ludicrous! If you had a small heap allocator like lib$get_vm then you could make sure the address was in "your" VM zone and not start messing with some other file opened in inner-mode by some other unsuspecting layered product! (It looks like that's what it used to do "index to a context table" and then some bright spark changed it :-() We've been around in circles a few times with the exe$expregpN routines but you know we're talking apples and cumquats? Why did Rdb have to come up with their own LIB$*VM? Would they really have done the same if a caller's mode safe heap manager was already available? Anyway, just in case there is the odd VMS engineer who'd rather stick his head in a boiling chip-pan than help that load-mouthed wanker Maher, could some lovely customer with a support contract care to champion this very worthy cause with a support call? And finally, I don't have access to the source code anymore so if another kind soul could look up sys$getqui and let me know how it allocates context blocks and keeps track of them, that would also be very much appreciated. (I know it's gonna use exe$al*, but you tell me when that memory ever gets freed for anything else.) Cheers Richard Maher PS. I just looked up my "Critique#1" from COV: - "The Crime: Neither SYS$CREATE_USER_PROFILE or SYS$CHECK_ACCESS Probe caller-access to the "context" parameter before passing it on to subsequent routines and ultimately SYS$GETUAI (for writing/corrupting) " Could be worth inclusion in the talk? -------------------------------------------------------------- Here's the original thread for "Making LIB$*_VM_PAGE Caller's-mode safe" : - http://groups.google.com/group/comp.os.vms/browse_frm/thread/7898199bd4ea241a/d597bbad8f2b3c52?lnk=gst&q=exec+mode+lib%24get_vm&rnum=1#d597bbad8f2b3c52 Hi, Yes, it's that paragon of the futile again. Today's installment "How I'd change LIB$*_VM_PAGE to support being called from inner-modes". For those of you with the source listings, please turn to psalm LIBVMPAGE.LIS around line 1199: - I would link LIBRTL.EXE against SECURESHRP.EXE and then export a Global (COMMON) Psect from there called _LIB$VM_COMMON via the SECURESHRP's Symbol_Table. Living in a PROTECTed image, this Psect would have User/Supervisor Read and Exec/Kernel write access. The Psects would then look like this: - .Psect _lib$vm_common Krnl_zone: .long 0, 0 ; Queue Header .long 0, 0, 0 ; Counters Exec_zone: .long 0, 0 ; Queue Header .long 0, 0, 0 ; Counters .Psect _lib$data Super_zone: .long 0, 0 ; Queue Header .long 0, 0, 0 ; Counters User_zone: .long 0, 0 ; Queue Header .long 0, 0, 0 ; Counters I would then obtain the CURR processor mode via MOVPSL and use the appropriate pool for the mode we're in. That is MOVAB xxxx_ZONE,R4. If some hacker tricks the code into thinking it is in Exec-Mode, when it tries to write to lib$vm_common an ACCVIO will be triggered. I didn't spend a lot of time at it, but after a quick glance at the code it seemed that as long as the correct memory queue had been identified then the rest was pretty transparent? (Oh, you'd obviously have to remove the hard-coded psl$c_user on the $expreg call so that each mode allocated pages it owned to its specific queue.) The strategy is simply to move all the "OWN" storage into a protected psect where needed. OK, Exec can mess with Kernel and User can stomp on Supervisor. Anything else? (Leaving lib$*_vm to one side for the moment and hoping that the correct layering of the calls may isolate the change. "Default_Zone" has to go into common etc) The downside as I see it, is that I suspect that there are many and varied lib$*vm_page callers that absolutely rely on sharing a *single* heap pool across processor modes. (As you know, I for one, would like to allocate at Exec and Free at User. An extra "mode" parameter can be later added to lib$get_vm*, so that you can allocate from a lower mode's heap.) So despite Hoffs well-intentioned sabre-rattling, I see VMS engineering being too pragmatic to break a (substantial?) amount of existing code. Unless. . . Like the hypersort RTL, could lib$*vm* call out to a second VM_HEAP RTL that defaults to the current behaviour but if defined, it would point to a UWSS RTL that would interrogate PREV_MOD to decide what heap to allocate from? Why not treat it as an quasi-open-source excersise? Let's keep coming up with solvable problems until there are none left. Ok, it's your turn. Regards Richard Maher PS. "Four Stacks - Four Heaps" - Gotta like the symmetry ------------------------------ Date: 1 May 2007 04:53:11 -0700 From: Ian Miller Subject: Re: Making LIB$*_VM_PAGE Caller's-mode safe Message-ID: <1178020391.733468.51420@n59g2000hsh.googlegroups.com> After a quick BLISSful wander though SYSSNDJBC.LIS It appears that context blocks are allocated by EXE$ALOP1PROC and kept in a linked list (QMAN$GQ_GETQUI_CONTEXT). There are kernel mode routines to manage this list and a image rundown routine to clean up if you do not deallocate the context block yourself. ------------------------------ Date: 1 May 2007 01:51:48 -0700 From: shofu_au@yahoo.com.au Subject: Motif routines uses by DECterms Message-ID: <1178009508.204180.198720@h2g2000hsg.googlegroups.com> Dear Group, I have writen a Motif application that logs data from a TCP socket to a Motif window. I have noticed that the logging is very slow and is compared to displaying the same data to a DECterm (X Windows) using TCPtrace. I have confirmed that the speed of my application when writing to a DECterm terminal with QIO is comparable to running TCPtrace interactively on the same DECTerm That leaves me to believe that the reason for the slowness is the way I am updating my window in Motif. Briefly my application uses AST to read from the TCPIP socket. In the completion AST the received data is inserted into a self relative queue and an event flag is set. Setting the event flag causes the call back routine that is defined XtAppAddInput to be called. In the callback routine, I clear the event flag and drain the self relative queue. I update my Motif window using by getting the last position via XmTextGetLastPosition, then inserting the text via XmTextInsert. This is done inside the call back from XtAppAddInput. I am not enabling or disabling ASTs in this callback. I belive that the usage of these two routines cause the whole process to be so slow. I forgot to say why slow logging effects me. Basically I exhaust my predefined application internal buffer queues at very high transaction rates. Does anyone know what routines that the DECTerms use or how DECTerms display data so promptly? Thanks Mark ------------------------------ Date: Tue, 1 May 2007 07:59:52 +0000 (UTC) From: david20@alpha2.mdx.ac.uk Subject: Re: Neocons destroying America Message-ID: In article <46366aa9$0$7610$157c6196@dreader2.cybercity.dk>, "Dr. Dweeb" writes: >JF Mezei wrote: >> BobH wrote: >>> lines. What do you do? If you are in Lieutenant Calley's unit and >>> he tells you to shoot people and says that he is following the >>> orders of his immediate superior, what do you do? The presumption >>> has to be that your commander's orders are legal, even though you as >>> an individual may not understand why it should be done, or agree >>> with the order. >> >> >> The problem is that the higher up guys protect themselves. When grunts >> were told to torture Iraqis, and some other grunt filmed and >> photographed everything and that media was help by the military for >> quite a long time. Many people knew torture had happened, nothing had >> happened. Hence, there would have been many senior people who >> essentially condoned itl. But when the media got the story and access >> to those tapes, only the grunts were charged and the USA public were >> told this was an isolated incident. >> >> Later on, Condi Rice defended those secret prisons with a very >> qualified "No american personel performed torture since 2005". >> >> This implied that prior to 2005 they did, and implies that post 2005, >> the actual torture was performed by contractors and/or fireigners on >> behalf of americans. >> >> Yet, only 2 grunts have been charged with torture, even though it is >> quite clear to the rest of the world that the "get information at any >> cost and make sure I have deniability" came from very high within the >> white house. >> >> >> So, when the poor kid only obeys orders without challenging illegal >> ones, when the shit hits the fan, he gets blamed for the actions, and >> his superiors get away with it because they claim the grunt acted >> independatly against their orders. >> >> If you're expected to blindly obey orders, then the military justice >> system should also blindly charge a superior whenever grunts make >> mistakes. > >Great, JF is now an expert on Military jurisprudence. > The doctrine of command responsibility codified in Additional protocol 1 to the Geneva convention states " the fact that a breach of the Conventions or of this Protocol was committed by a subordinate does not absolve his superiors from ...responsibility... if they knew, or had information which should have enabled them to conclude in the circumstances at the time, that he was committing or about to commit such a breach and if they did not take all feasible measures within their power to prevent or repress the breach. " It might be argued that a superior was unaware of a single act of torture being carried out by his subordinates but it seems very difficult to argue that knowlege of systematic torture such as that at Abu Ghraib was restricted just to those directly carrying it out. Also note from http://en.wikipedia.org/wiki/Command_responsibility " Operational command: military leadership; in Yamashita it was established that operational command responsibility cannot be ceded for the purpose of the doctrine of command responsibility - operational commanders must exercise the full potential of their authority to prevent war crimes, failure to supervise subordinates or non-assertive orders don't exonerate the commander " Also the cases of POW camp commanders and those in charge of an occupied territory have been established as special cases under International Law " International case law has developed two special types of "de jure commanders." 1. Prisoners-of-war (POW) camp commanders: the ICTY established in Aleskovski that POW camp commanders are entrusted with the welfare of all prisoners, and subordination in this case is irrelevant 2. Executive commanders: supreme governing authority in the occupied territory - subordination is again irrelevant, their responsibility is the welfare of the population in the territory under their control, as established in the High Command and Hostages cases after World War II. " That would appear to pretty much cover the responsibilities of those actually in Iraq. However if it can be shown that the orders for Torture did eminated from the Whitehouse then it is arguable that high US officials could be prosecuted under the principle of command responsibility. " Application in the war on terror Further information: War on terror A number of legal analysts have advanced the argument that the principle of "command responsibility" could make high-ranking officials within the Bush administration guilty of war crimes committed either with their knowledge or by persons under their control.[10] As a reaction to the September 11, 2001 attacks the U.S. Government adopted several controversial measures (e.g., invading Iraq, introducing "unlawful combatant" status, conducting "extraordinary renditions", and allowing "enhanced interrogation methods", which has been described as torture). Alberto Gonzales and others argued that detainees should be considered "unlawful combatants" and as such not protected by the Geneva Conventions in multiple memoranda regarding these perceived legal gray areas.[11] Gonzales' statement that denying coverage under the Geneva Conventions "substantially reduces the threat of domestic criminal prosecution under the War Crimes Act" suggests, at the least, an awareness by those involved in crafting policies in this area that US officials are involved in acts that could be seen to be war crimes.[12] The US Supreme Court challenged the premise on which this argument is based in Hamdan v. Rumsfeld, in which it ruled that Common Article Three of the Geneva Conventions applies to detainees in Guantanamo Bay and that the Military Tribunals used to try these suspects were in violation of US and international law.[13] On April 14, 2006, Human Rights Watch said that Secretary Rumsfeld could be criminally liable for his alleged involvement in the abuse of Mohammad al-Qahtani.[14] Dave Lindorff contends that by ignoring the Geneva Conventions the US administration, including President Bush, as Commander-in-Chief, is culpable for war crimes.[15] In addition, former chief prosecutor of the Nuremberg Trials Benjamin Ferencz has called the invasion of Iraq a "clear breach of law," and as such it constitutes a war crime.[16] On November 14, 2006, invoking universal jurisdiction, legal proceedings were started in Germany - for their alleged involvement of prisoner abuse - against Donald Rumsfeld, Alberto Gonzales, John Yoo, George Tenet and others.[17] Lieutenant Watada has refused to be deployed to Iraq charging that the invasion of iraq was illegal, and as such he is bound by the command responsibility to refuse to take part in an illegal war. Otherwise he himself could face legal challenges. For this he stands trial at this moment. The Military Commissions Act of 2006 is seen as an amnesty law for crimes committed in the War on Terror by retroactively rewriting the War Crimes Act[18] and by abolishing habeas corpus, effectively making it impossible for detainees to challenge crimes committed against them.[19] Luis Moreno-Ocampo has told the Sunday Telegraph he is willing to start an inquiry by the International Criminal Court, and possibly a trial, for war crimes commited in Iraq involving British Prime Minister Tony Blair and American President George W Bush.[20] " David Webb Security team leader CCSS Middlesex University >Dweeb > > ------------------------------ Date: Tue, 01 May 2007 05:38:27 -0400 From: Bill Todd Subject: Re: Neocons destroying America Message-ID: Dr. Dweeb wrote: > Bill Todd wrote: >> Dan O'Reilly wrote: >> >> ... >> >>> I'll tell you a secret: these young kids believe in what they're >>> doing. >> As with most generalizations, that's flat-out wrong. I don't know >> exactly what percentage believe in what they're doing (many reports >> indicate that it's a rather low one, which would hardly be >> surprising), but one need only visit sites like http://www.ivaw.org/ >> and http://www.vaiw.org to see that at least a significant number >> believe nothing exactly the opposite. It's probably safe to say that >> a majority think that there's no real reason they should be where >> they are, even if they're willing to suck it up and do their jobs. >> >>> And I'll tell you another secret: what's going on in Iraq isn't what >>> is being reported by the likes of PBS and Bill Moyers - or NBC, CBS >>> or ABC, for that matter. >> Indeed, all our media sanitize the situation and fail to raise >> anything like the criticism that it merits. Foreign media are a much >> more reliable source. >> > > Bill, > > I really wish you would stop claiming the superiority/objectivity of foreign > media. Don't be such a moron, Dweeb: I made no such *general* assertion, merely one with respect to Iraq war coverage. And beyond any shadow of a doubt, the rest of the world's media does a *far* better job of such coverage than ours does. If some of that media gets a bit 'shrill' about Dubya's criminal behavior, it just might be because nothing has yet even started to be done to curb (let alone punish) it. Given that it affects people far beyond our own borders, you can expect some of them to be fairly concerned about this. When the U.N. Secretary General states flatly that the invasion of Iraq was illegal under international law, and *still* nothing is done about that, when (as David just observed) the former chief prosecutor at Nuremberg concurs and flatly adds that it constitutes a war crime, when (as he also just helpfully pointed out) Germany has begun legal proceedings against top U.S. officials on that basis (and this was hardly the first such instance: years ago there was some serious question about whether Bush could pay a state visit to Canada without being held there for prosecution), holding your eyes firmly shut and chanting "obnoxious hippie crap", while perhaps amusing to the rest of us, isn't really very useful. - bill ------------------------------ Date: Tue, 01 May 2007 12:18:08 -0400 From: Dave Froble Subject: Re: Noahs ark found! Message-ID: david20@alpha2.mdx.ac.uk wrote: > In article , Dirk Munk writes: >> genius@marblecliff.com wrote: >>> On Apr 30, 10:25 am, Dirk Munk wrote: >>>> gen...@marblecliff.com wrote: >>>>> the same researcher who helped bring about the discovery >>>>> of Mount Sinai now believes he has found Noahs ark on a >>>>> mountain in Iran ... scroll to the bottom and look at the >>>>> pictures and video ... >>>>> http://www.arkfever.com/ >>>> This time Boob is right. What you see on the pictures is the stern of >>>> the ark. On it they found the inscription "Noahs Ark - Monrovia" in >>>> Hebrew. That proofs Boob is not mistaken this time. >>> it would be nice to be able to dig all of it out >>> and confirm it, but when you find a 400 foot >>> boat made out of gofer wood in the mountain >>> ranges of Ararat, you seriously need to consider >>> it ... esp. with petrified sea shells around it ... >>> >> Dear Boob, >> >> You can find petrified sea shells on mountains all over the world. That >> is because of the movement of the tectonic plates. The plates collide >> with each other, and on some places mountains appear because one of the >> plates is pushed upwards by the other. That is the reason you can find >> these petrified sea shells on great heights in the mountains. I suppose >> this should be high school knowledge ??? > > Unfortunately Boob doesn't believe in sciences such as Geology and hence > doesn't believe in tectonic plates and mountain building. Such processes take > much too long - He believes the Earth isn't old enough. > > Hence the Earth is exactly how it was when God created it apart from the > effects of the flood - except for those pesky earthquakes, volcanic eruptions > etc (and of course Man's activity eg cutting canals in Suez and Panama, > damming rivers etc ). > > Since the Earth hasn't changed and in particular mountains haven't risen up > then if you find sea shells on the Mountains the only possible explanation is > that there was a worldwide flood. > There isn't enough water. Doesn't matter - this was God's Flood. God can do > whatever he wants. > But then if God can do whatever he wants then maybe there wasn't a flood since > he could just have sprinkled seashells on the mountain tops. Or maybe he even > caused the mountains to rise overnight. Nah! God is much brighter than that. Why waste the effort. Just drug the glorified apes, and subject them to a virtual reality experience of a flood. Much more cost efficient. -- David Froble Tel: 724-529-0450 Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc. 170 Grimplin Road Vanderbilt, PA 15486 ------------------------------ Date: Tue, 1 May 2007 19:24:52 +1000 From: "O'Brien Paddy" Subject: RE: numerical libraries on integrity Message-ID: <0A7046B0A95F2B41B3712F0C5FD1CDC339388F@ex-tg2-pr.corporate.transgrid.local> =20 >Hello >I just read in the Fortran for OpenVMS user manual that CXML libraries are not available >on integrity, only on Alpha. >Does anybody know what is the suggested replacement for integrity? >Perhaps some of the LAPACK, BLAS, LINPACK, etc are now meant to be installed via freeware? > >thanks a lot >anton This is yet another reason that we shall be giving HP away and never intend to go to IA64. Although I still work on VMS as do my users (and I hope to last there till I retire -- soon), a colleague is porting all our programs to the (despicable) PC world. To get maximum benefit from the BLAS and LAPACK (LINPACK is not part of CXML as LAPACK is the "optimised" replacement for that and EISPACK) you need to be able to run a vendor library which has been optimised for your platform. Some years ago I beta-tested the version in CXML of level 3 LAPACK. Yes, Bill, NAG is still alive but only just seemingly on Alpha VMS -- we are several versions (Marks) behind what is current. Whether it is available on IA64, I do not know, but I would guess probably not, given their lack of enthusiasm for VMS. However, NAG is merely compiled and not platform optimised. When CXML became available with the Fortran compiler, I called the platform optimised version from my programs. I forget the actual percentage increases in speed I saw for an eigenvalue/vector program I maintain for dynamic stability of an electrical network, but it was **considerable**. Something like an hour down to 20 minutes for a typical run. We still use a few NAG specialist routines, but although excellent, I am trying to find replacements and give NAG away. Expensive, and no longer really supporting VMS. Back to the OP. You can pick up the source of the BLAS and LAPACK from www.netlib.org . These will compile well, but probably run no better than the NAG routines. Since they use the Alpha (well IA64, probably cribbed from Alpha) compiler, as well as Jack Dongarra's unrolling, it will unroll the loops to a further level. This will increase the code size but beneficially with this further unrolling, but will also increase it with no benefit for the "catch-up" part of the code. I have not looked into this, but it might be worth modifying the BLAS code to not unroll, letting the compiler do it and even possibly use !DEC$ UNROLL (larger). But beware, there is often a cut-off when you gain nothing from extra unrolling. The compiler tries to optimise this, but it works on code size as well as speed and often I have found that I can gain more speed (at the expense of size) in some critical loops by increasing to a bit more than the compiler tried. Something you might also consider looking into is the ATLAS project (masterminded by Danny Sorensen, IIRC) which tries to look at your architecture and optimise for cache, etc. I have not looked at this because we do have CXML :-) Regards, Paddy *********************************************************************** Please consider the environment before printing this email. "This electronic message and any attachments may contain privileged and confidential information intended only for the use of the=20 addressees named above. If you are not the intended recipient of=20 this email, please delete the message and any attachment and advise the sender. You are hereby notified that any use, dissemination,=20 distribution, reproduction of this email is prohibited. If you have received the email in error, please notify TransGrid=20 immediately. Any views expressed in this email are those of the=20 individual sender except where the sender expressly and with=20 authority states them to be the views of TransGrid. TransGrid uses virus-scanning software but excludes any liability for viruses contained in any attachment." *********************************************************************** ------------------------------ Date: Tue, 1 May 2007 11:07:01 +0100 From: Anton Shterenlikht Subject: Re: numerical libraries on integrity Message-ID: <20070501100701.GA23080@mech-aslap33.men.bris.ac.uk> On Tue, May 01, 2007 at 07:24:52PM +1000, O'Brien Paddy wrote: > > >I just read in the Fortran for OpenVMS user manual that CXML libraries > are not available >on integrity, only on Alpha. > >Does anybody know what is the suggested replacement for integrity? > > Something you might also consider looking into is the ATLAS project > (masterminded by Danny Sorensen, IIRC) which tries to look at your > architecture and optimise for cache, etc. I have not looked at this > because we do have CXML :-) Do you know what I can get from EXT_MATH_LIB and EXT_MATH_LIB_RT products available on IA64 (and Alpha) under the educational or hobbyist lisence? Also have you got any comments on Compaq Portable Mathematics Library (don't know if it is available on IA64)? thanks a lot anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 ------------------------------ Date: Tue, 1 May 2007 13:42:09 -0400 From: "Doug Kimball" Subject: OT: Favorite movies of the VMS crowd? Message-ID: <133euv7gd81ki66@corp.supernews.com> So, what are your top three favorite movies, VMSophiles? We need a promo for the upcoming HP Partners Roundhouse in Nashua, and we would love your input. Thanks! Doug -- Doug Kimball Manager, Sales and Support Software Partners, Inc. www.softwarepartners.com ------------------------------ Date: Tue, 01 May 2007 03:27:12 -0400 From: JF Mezei Subject: Re: OT: Kodak Nipping at HP's heels Message-ID: <78587$4636ec21$cef8887a$17395@TEKSAVVY.COM> David J Dachtera wrote: > With Kodak challenging HP in the printer market, and HP giving up in the > HealthCare Enterprise sector, the HP shareholders in this group may wish to > reconsider their holdings and position. Nearby hospital has switched from HP monitors to Phillips monitors. Had seen those at emergency ward, but have now seen them at intensive care units with many of their features turned on. Pretty interesting LAN service (an alarm generated in room 1 will show up on all monitors so that a nurse can they judge if it is necessary to go to room 1). Note sure what OS those monitors run. Probably Vxworks since this is truly life critical stuff. The software seems quite evolved in those, detecting irregular heart beats, missed heart beats, changes in blood pressure, O2 levels etc. They also have an extension rack into which they can plug in a number of additional sensor modules. Makes for a lot of cables going to the patient's body. At emergency, they are not in constant use because some patients don't need heart monitors etc. But at the ICU, they are in constant use 7/24 and this presents interesting challenges for any maintenance windows to the displays and central server. ------------------------------ Date: Tue, 01 May 2007 11:52:11 +0200 From: Martin Krischik Subject: Re: SSH trouble (Was: Has Linux Peaked ?) Message-ID: <46370dcb$1@news.post.ch> Steven M. Schweda schrieb: > From: Martin Krischik > >> Well, don't know which ssh out Administrators supplied us with [...] > > 'ssh "-V"'? Yep - should have thought about that. I am just to used to used "--version": -------------------------------------------- $1$dga1:[sys1.syscommon.][sysexe]tcpip$ssh_ssh2.exe: SSH Secure Shell OpenVMS (V5.5) 3.2.0 on AlphaServer ES40 - VMS V7.3-2 -------------------------------------------- >> ---- Copy File from Windows to VMS --------------------------- >> >scp jusched.log krischik@xxxxx: >> scp1 compatibility mode is not supported. >> Connection to xxxxx closed by remote host. >> ---- Copy File from Windows to VMS --------------------------- >> >> "scp1 compatibility" - Why - both sides should support scp2! > > 'scp -v [...]'? Shure, here it is: -------------------------------------------- >scp -v jusched.log krischikm@gdc00f: Executing: program /usr/bin/ssh host gdc00f, user krischikm, command scp -v -t . OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007 debug1: Reading configuration data /home/krischikm/.ssh/config debug1: Applying options for gdc00f debug1: Connecting to gdc00f [138.191.17.231] port 22. debug1: Connection established. debug1: identity file id_dsa type -1 debug1: identity file id_rsa type -1 debug1: Remote protocol version 2.0, remote software version 3.2.0 SSH Secure Shell OpenVMS V5.5 debug1: no match: 3.2.0 SSH Secure Shell OpenVMS V5.5 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.6 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 zlib debug1: kex: client->server aes128-cbc hmac-md5 zlib debug1: sending SSH2_MSG_KEXDH_INIT debug1: expecting SSH2_MSG_KEXDH_REPLY debug1: Host 'gdc00f' is known and matches the DSA host key. debug1: Found key in /home/krischikm/.ssh/known_hosts:3 debug1: ssh_dss_verify: signature correct debug1: Enabling compression at level 6. debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: password,publickey debug1: Next authentication method: publickey debug1: Offering public key: /home/krischikm/.ssh/id_rsa debug1: Server accepts key: pkalg ssh-rsa blen 533 debug1: Authentication succeeded (publickey). debug1: channel 0: new [client-session] debug1: Entering interactive session. debug1: Sending command: scp -v -t . scp1 compatibility mode is not supported. debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: channel 0: free: client-session, nchannels 1 debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.6 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 debug1: Exit status 0 debug1: compress outgoing: raw data 1839, compressed 1249, factor 0.68 debug1: compress incoming: raw data 3245, compressed 3330, factor 1.03 -------------------------------------------- >> Or I am asked for passwords even when keys are installed: >> >> ---- Login from VMS to VMS ------------------------------------ >> >ssh krischik@xxxxxx >> krischik's password: >> ---- Login from VMS to VMS ------------------------------------ >> >> debugging reveals: >> >> ---- Login from VMS to VMS ------------------------------------ >> debug: SshConfig/SSHCONFIG.C:3193: Unable to open ssh2/id_rsa >> ---- Login from VMS to VMS ------------------------------------ >> >> Now, "ssh2/id_rsa" is a key file which reads OK on Windows, Linux and >> Solaris. Why does VMS alone reject the file? > > 0. You key files are probably in the wrong format for VMS, but it's > hard to tell when we don't know which SSH product you're running. Well, I expect the key is the wrong format as well and if somebody knows of a key converter that would indeed be helpful. > 1. We can't see the file. Of course not - it's my *private* key - it is not be seen by anyone but me (and anybody who got ByPass privilege :-( ). Martin ------------------------------ Date: 1 May 2007 05:29:43 -0700 From: a.drew7@gmail.com Subject: Re: VAXStation 3100 M38 Message-ID: <1178022583.595863.191350@h2g2000hsg.googlegroups.com> > VAXstation 3100 model 38 systems have 4MB on board. > > There were four different memory options. Pass-through cards came in 8MB > (MS42-KA) and 16MB (MS42-CA). Non-passthrough cards came in 12MB (MS42-BA) > and 4MB (MS42-AB). Maximum memory was 32MB, when you used a 12 and a 16 plus > the 4 on-board. > > If you are getting a memory error with no cards inserted, that would tend to > point to the on-board memory. If it won't POST with no memory cards > inserted, then you're most likely looking at a motherboard problem. > Thats looking like the problem. When the machine last posted it reported 12MB, while from your description it should have reported 16. Without any memory boards, the machine produces no output and the diagnostic lights stay at 1111 0000 (ROM read and some instructions executed). Maybe the onboard memory can be disabled somehow - but that would require hacking up the motherboard. > The model 48 used the same motherboard as the model 38, just in a bigger > case. So I can use one of those as a replacement as well. Thanks for all the comments. ------------------------------ Date: 1 May 2007 08:23:22 -0700 From: AEF Subject: Re: VAXStation 3100 M38 Message-ID: <1178033002.707749.145320@y5g2000hsa.googlegroups.com> On Apr 29, 8:35 pm, a.dr...@gmail.com wrote: > I've got a Vaxstation 3100 model 38 that I'm trying to get working. > It booted into VMS twice since I acquired it, but a week later it > refused to start up. Without a monitor, I can only access it through > the serial printer port and a terminal emulator. > > This is the only output I can get from it: > > KA42-B V1.5 ?h?,?...E...D...C...B > > According to the manual for the Model 76, B is the Memory power-up > self-test. I don't know if that is any different for the Model 38. > I've left it there for over an hour with no change. > > The diagnostic lights are lit up like this: > 1001 1011 > > Any ideas? Am I the proud owner of a VAX-shaped paperweight? > > Thanks, > Andrew http://vt100.net/manx/details/1,3620 for VAXstation 3100 Model 38 Owner's Manual There might be other related docs on the manx site. ------------------------------ End of INFO-VAX 2007.238 ************************