INFO-VAX Sat, 08 Dec 2007 Volume 2007 : Issue 671 Contents: Re: 20+ year old encrypted source code Re: Apache 2, Multiple Tomcat (5.5.9) instances on OpenVMS Re: HP loses another large customer Re: HP loses another large customer Re: HP loses another large customer Re: Installation of DEGPA-TA on VMS 7.2-1 system Re: OT: "Inventory Control" for non-VMS Re: RX2600 hangs (VMS 8.3) Re: RX2600 hangs (VMS 8.3) Re: RX2600 hangs (VMS 8.3) Re: Unix for VMS guys Re: Unix for VMS guys Re: Unix for VMS guys Re: What causes a STKOVF Re: What causes a STKOVF ---------------------------------------------------------------------- Date: Fri, 07 Dec 2007 23:40:32 -0500 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: 20+ year old encrypted source code Message-ID: <475a203e$0$90273$14726298@news.sunsite.dk> Michael Moroney wrote: > billg999@cs.uofs.edu (Bill Gunshannon) writes: >> In article <47537cd1$0$90276$14726298@news.sunsite.dk>, >> Arne Vajhøj writes: >>> Richard B. Gilbert wrote: >>>> ISTR that some BASIC interpreters allowed you to encrypt the source! It >>>> seemed like a dumb thing to do and I never tried it. . . . >>> I did in the early DOS days. >>> >>> It was a type of protection of the source code in an interpreted >>> context. >> I don't remember any of the original microcomputer BASIC's that >> encrypted their source. Almost all of them used "tokenization" >> of all reserved words which may have looked like encryption as >> it was definitely not ASCII. > > Yes, that was done to save a few valuable bytes on disk or memory, not > for encryption. I suspect "tokenized" BASIC would have recognizable code > or text, particularly the rest of a PRINT statement, so the unrecognizable > code is unlikely "tokenized" BASIC code. I remember loosing the source code a couple of times, because the conversion I am thinking about was one way. :-( Arne ------------------------------ Date: Fri, 7 Dec 2007 22:26:27 -0800 (PST) From: bcole@emjmetals.com Subject: Re: Apache 2, Multiple Tomcat (5.5.9) instances on OpenVMS Message-ID: <987856a6-39d8-4e49-bd0a-b9b694e43dee@a35g2000prf.googlegroups.com> On Dec 6, 5:41 pm, Arne Vajh=F8j wrote: > > After thinking a bit about it then I can not come up with a > mod_jk2 solution to do that mapping. > > It would not work well anyway if you app outputs links that > include context path. > > If you do not deploy many apps you can define the contexts > explicit and specify a path as /dev/app1 . > > Arne- Hide quoted text - > > - Show quoted text - Thanks for the info. I guess I am concerned a bit about switching to "mod_jk" from "mod_jk2" since it does not seem to be the default which HP pushes when setting up this stuff on OpenVMS. It kind of makes me concerned about how up to date the "mod_jk.exe" port is but it looks like it should be at least worth trying out. ------------------------------ Date: Fri, 07 Dec 2007 23:09:30 -0500 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: HP loses another large customer Message-ID: <475a18f6$0$90273$14726298@news.sunsite.dk> Bob Koehler wrote: > In article <474a3981$0$90270$14726298@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= writes: >> Some of the most popular OO languages (C++, Java and C#) are 3GL >> languages. > > Some of the best OO code I've ever seen was written in Macro-32 > decades before the term was coined. It is true that you can write OO code in any language. But it it becomes a bit easier if the language support it. I believe the term OO was first used about Smalltalk which was release to the public in 1980. Arne ------------------------------ Date: Fri, 07 Dec 2007 23:12:29 -0500 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: HP loses another large customer Message-ID: <475a19a9$0$90273$14726298@news.sunsite.dk> Larry Kilgallen wrote: > In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: >> In article <474AFAED.5040108@comcast.net>, "Richard B. Gilbert" writes: >>> The idea behind OO is that you represent an "object" as a package >>> consisting of a data structure and all the allowed operations, called >>> methods, on that data structure. If the language in use requires OO, >>> you can't easily do stupid things like trying to add two windows or >>> multiply a window by a file! >> I'm quite sure I could do both of those in C++. 8( > > Those are _not_ easy to do in Ada 83, which did not have the big > Object Oriented upgrade of Ada 95. So while Object Oriented > features might be appropriate for some purposes, they are not > needed to avoid adding two windows or multiplying a window by a file. The entire Pascal/Modula-2/Ada/Oberon family has a more strict point of view on type safeness than C/C++ (and also partly newer languages like Java and C#). Arne ------------------------------ Date: Sat, 08 Dec 2007 00:24:28 -0500 From: JF Mezei Subject: Re: HP loses another large customer Message-ID: <61cbb$475a2a8d$cef8887a$25281@TEKSAVVY.COM> Arne Vajh=F8j wrote: > I believe the term OO was first used about Smalltalk which > was release to the public in 1980. While this came after 1980, the Macintosh (1984) was very much object=20 oriented and the programming was originally designed for Pascal as the=20 pain language. When you look at the original drawing programs such as MacDraw, they=20 were very much object oriented with different functions available to=20 different types of objects (lines, circles, text, squares, polygons etc).= Also, the GUI was quite object oriented by the standards of that time=20 since windows/widgets were identified by some opaque value and=20 programmers didn't have to know about what was behind the scenes. (After a few years on VMS desktops, this is my first post back on a MAC) ------------------------------ Date: Fri, 07 Dec 2007 21:45:35 +0200 From: =?ISO-8859-1?Q?Uusim=E4ki?= Subject: Re: Installation of DEGPA-TA on VMS 7.2-1 system Message-ID: <47599f2f$0$27841$9b536df3@news.fv.fi> Malcolm Dunnett wrote: > David Turner, Island Computers wrote: >> Customer is having a problem with installation of DEGPA-TA copper >> Gigabit card (old style) in a ES40 >> Can anyone PLEASE send an install guide (I can't find one anywhere in >> our docs) and or user guide to dturner@islandco.com > > What sort of problem? > > I've found that the ES40 console firmware has trouble with these > (IIRC it can't see them, or at least can't boot from them) but that once > you start VMS they work fine (that's with VMS 8.x though) DEGPA was not supported for network booting, but the newer DEGXA does support network boot. That's why. Regards, Kari ------------------------------ Date: Fri, 07 Dec 2007 21:02:15 -0600 From: David J Dachtera Subject: Re: OT: "Inventory Control" for non-VMS Message-ID: <475A0937.E5A0F28E@spam.comcast.net> Marc Van Dyck wrote: > > David J Dachtera wrote on 5/12/2007 : > > Apologies for the OT post. I know some of my fellow VMSers here are also > > AIX knowledgeable. > > > > I'm looking for any tools that anyone is aware of which will allow me to > > keep files synchronized across multiple AIX instances (LPARs). We lose > > the shared disk paradigm of OpenVMS clusters. Hence, scripts, etc. must > > be copied to each individual instance's private storage. > > > > Any tips that anyone might have would be most helpful. > > > > I asked this question on the Cerner listserv and got no responses. > > > > David J Dachtera > > DJE Systems > > Some plumbing with NFS, MAKE, and CRON will do the trick, won't it ? Depends. The source might be any one of 16 or more PCs in the developer's areas. David J Dachtera DJE Systems ------------------------------ Date: Fri, 07 Dec 2007 11:03:09 -0800 From: Malcolm Dunnett Subject: Re: RX2600 hangs (VMS 8.3) Message-ID: <475998ee$1@flight> Robert Deininger wrote: > This cascading series of system events involves a "Machine Check" a.k.a. > "Machine Check Abort". > > While an MCA can be caused by software -- a wayward device driver or > other inner-mode code -- the general situation you describe sounds more > like a hardware-initiated problem. > The system hung again yesterday afternoon. It would not respond to the ^P on the console to get the IPC> prompt so that I could take a crash dump. I suspect this would most likely only happen with a hardware failure. I swapped another server in for this one and I'll see what happens with it (so far it's good since yesterday afternoon whereas the other one failed twice in 24 hours). > Does this system have the optional Management Processor card? Yes. > Lots of information from the status and error registers in the chipset > is logged in a separate section of NVRAM. You can view this from the > EFI shell, using the "errdump" command. "errdump MCA" would be of > interest here. If you can capture the errdump information, the services > folks have a tool that can interpret it in great detail. The tool can > often point right at the component that most likely caused the failure. > I somehow managed to blow this away (or it never got logged ), in either case there's nothing in there now. Thanks for the information - I now know better what to capture next time something like this happens. ps. I have to concur with those others who have bemoaned the quality of the service since it got transferred to India. The person I was dealing with said that the log entries (same ones I posted here that clearly show Machine Checks) were "nothing special there - just a machine initated messages." ------------------------------ Date: Fri, 7 Dec 2007 16:34:03 -0500 From: "Carl Friedberg" Subject: Re: RX2600 hangs (VMS 8.3) Message-ID: <890539d90712071334t44e6d551v940bf33c67c46da4@mail.gmail.com> Malcolm, I have to agree on the India problem (and Costa Rica). I have a few names and e-mail addresses of some very special people within support for whom English is a native language and VMS a specialty. I open the call with Bangalore or Costa Rica, describe the problem (knowing that the phone 'droid likely doesn't understand me, nor the problem), and get the case number. Then I send an e-mail with the case-number in the subject line, to one of those people. They then help to dispatch the case to someone appropriate. I don't know what happens to those VMS support cases when the default HP policies are followed. For instance, 3 days after my last problem (combination hardware and VMS diagnostic tools) was solved, the Indian support person sent me an e-mail wondering if I needed any assistance .. 3 days... sigh Carl Friedberg On Dec 7, 2007 2:03 PM, Malcolm Dunnett wrote: > ps. I have to concur with those others who have bemoaned the quality > of the service since it got transferred to India. The person I was > dealing with said that the log entries (same ones I posted here that > clearly show Machine Checks) were "nothing special there - just a > machine initated messages." ------------------------------ Date: Fri, 07 Dec 2007 20:54:14 -0500 From: Robert Deininger Subject: Re: RX2600 hangs (VMS 8.3) Message-ID: In article <475998ee$1@flight>, Malcolm Dunnett wrote: > Robert Deininger wrote: > > > This cascading series of system events involves a "Machine Check" a.k.a. > > "Machine Check Abort". > > > > While an MCA can be caused by software -- a wayward device driver or > > other inner-mode code -- the general situation you describe sounds more > > like a hardware-initiated problem. > > > The system hung again yesterday afternoon. It would not respond to > the ^P on the console to get the IPC> prompt so that I could take a > crash dump. I suspect this would most likely only happen with a hardware > failure. There are a few failure modes where the crash message sent via ^P never arrives. I'm not convinced they are entirely hardware-related. But you have clear symptoms of a hardware problem. The hardware indications need to be diagnosed. If they point to possible OS involvement, then worry about getting a crash dump. > I swapped another server in for this one and I'll see what happens > with it (so far it's good since yesterday afternoon whereas the other > one failed twice in 24 hours). > > > Does this system have the optional Management Processor card? > > Yes. > > > Lots of information from the status and error registers in the chipset > > is logged in a separate section of NVRAM. You can view this from the > > EFI shell, using the "errdump" command. "errdump MCA" would be of > > interest here. If you can capture the errdump information, the services > > folks have a tool that can interpret it in great detail. The tool can > > often point right at the component that most likely caused the failure. > > > > I somehow managed to blow this away (or it never got logged ), in > either case there's nothing in there now. If it never got logged, it's probably a hardware problem. > Thanks for the information - I now know better what to capture next > time something like this happens. > > ps. I have to concur with those others who have bemoaned the quality > of the service since it got transferred to India. The person I was > dealing with said that the log entries (same ones I posted here that > clearly show Machine Checks) were "nothing special there - just a > machine initated messages." Grrr. So what is the status of the case now? Did it get logged as a hardware problem, or a VMS problem? Hardware support should be dealing with it. Did you get any useful progress on the case yet? Are you waiting for 2nd-level support to take a look? -- Robert ------------------------------ Date: Fri, 07 Dec 2007 20:52:21 -0500 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: Unix for VMS guys Message-ID: <4759f8d2$0$90265$14726298@news.sunsite.dk> Bill Gunshannon wrote: >> Richard B. Gilbert wrote: >>> RUN AUTHORIZE vi /etc/passwd > > And the example above would be akin to using EDT to change entries in > SYSUAF. Not quite. EDT would ruin SYSUAF.DAT every time. I am sure vi passwd would succeed in most cases. Arne ------------------------------ Date: Fri, 07 Dec 2007 22:00:07 -0500 From: "Richard B. Gilbert" Subject: Re: Unix for VMS guys Message-ID: <475A08B7.80707@comcast.net> Arne Vajhøj wrote: > Bill Gunshannon wrote: > >>> Richard B. Gilbert wrote: >>> >>>> RUN AUTHORIZE vi /etc/passwd >>> >> >> And the example above would be akin to using EDT to change entries in >> SYSUAF. > > > Not quite. EDT would ruin SYSUAF.DAT every time. I am sure vi passwd > would succeed in most cases. > > Arne > I think Bill is coming from a data center/large server environment whereas I'm coming from a small server/workstation environment. If you have a couple of thousand users with three or four hundred logged on at any one time, vi /etc/password would be a very dangerous thing to do! In a workstation environment vi /etc/password is not a terribly dangerous thing to do. Those, BTW, are the circumstances under which I learned to do it that way. BTW, does Unix even HAVE mandatory locking yet? Twenty years or so ago I had to write a script to add a new user; if IRIX had such a thing I never found it. It added an entry to /etc/passwd, created a directory for the new user, set the ownership and permissions, gave him a .login and .profile etc, etc. IRIX may well have had such a script but, given the Unix tradition of naming things after dogs or with the initials of the author I might never have found it. VMS makes it a lot easier by using the obvious English words for things; e.g. COPY, PRINT, TYPE, EDIT, etc. I've never actually seen it but I believe that VMS has command tables available in languages other than English. ------------------------------ Date: Fri, 07 Dec 2007 22:03:43 -0600 From: David J Dachtera Subject: Re: Unix for VMS guys Message-ID: <475A179F.F860F583@spam.comcast.net> JF Mezei wrote: > > many thanks to all who have contributed to this (and to those who sent > me private emails). Sent a number of hours reading and fiddling with stuff. > > Also started to look at the netbsd.org web site which has "non man" > documentation (aka: readable stuff) that explains a lot about it (and > has config tips for postfix etc, (the mail MTA ). > > Question: > > is /etc/rc.conf (on the mac there isn't a .conf) the moral equivalent > of STARTUP.COM or SYSTARTUP_VMS.COM ? Well, no. It - in conjunction with /etc/inittab - is more closely akin to the STARTUP database as maintained thru SYSMAN (SYS$STARTUP:VMS$VMS.DAT?). The rc (Run Control) program is most closely akin to STARTUP.COM. David J Dachtera DJE Systems ------------------------------ Date: Fri, 7 Dec 2007 12:03:50 -0800 (PST) From: Bob Gezelter Subject: Re: What causes a STKOVF Message-ID: <854de914-e03c-4f8b-bf33-dd0df67afae5@a39g2000pre.googlegroups.com> On Dec 7, 10:36 am, Joe Sewell wrote: > The following involves OpenVMS V8.3A with various ECOs applied. It > happens in a DECwindows app. I'd have to find out hardware & firmware > details, if necessary. > > Okay, I've read the OpenVMS FAQ and the pertinent portions of Hoff's > Wizard stuff on stack overflow exceptions, but most of them simply say > "get a reproducer and talk with the support center." > > First off, I don't know how to reproduce the particular stack overflow > we're seeing (it's in a large multiprocess system with external inputs > out the wazoo); I'm not even sure I know if it was operator actions > that caused it or the external inputs. The code for just the one > process that got the SS$_STKOVF exception is huge. > > What I need is an idea of when the RTL or lower layers detect a "stack > overflow" in a non-threaded situation (though it's a DECwindows app, > just in case it's multithreading for some reason), so I might get some > idea of where to look. (The place where the exception happened didn't > reveal too much.) > > It sounds like the RTL actually pre-checks for a case where pushing n > bytes onto the stack would cause the stack to overflow the thread's > stated stack size (in a multithreaded app), and signal SS$_STKOVF > before it goes off the deep end. What does it do for a single threaded > app? Joe, First, let me welcome you to posting in COMP.OS.VMS. The actual details of the stack overflow handling are likely (I do not have one of my copies handy) in the Internals and Data Structures manual. The gross details of this have not changed in a VERY long time. I would also be concerned about the possibility that someone has overwitten a saved stack pointer in a call frame, and as a result the stack is effectively corupt when the RETURN is executed. These can be devilishly difficult to localize (been there, done that). There are a variety of strategies that can be used to localize this type of problem. Which is appropriate depends on many factors. The most central question is: What (if any) tracking/debugging code is already present in your application that can help reduce the size of the search. - Bob Gezelter, http://www.rlgsc.com ------------------------------ Date: 7 Dec 2007 15:43:48 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: What causes a STKOVF Message-ID: In article <854de914-e03c-4f8b-bf33-dd0df67afae5@a39g2000pre.googlegroups.com>, Bob Gezelter writes: > > I would also be concerned about the possibility that someone has > overwitten a saved stack pointer in a call frame, and as a result the > stack is effectively corupt when the RETURN is executed. These can be > devilishly difficult to localize (been there, done that). One of the first problems I had to debug on my first Alpha was a return to 0. I'd never seen one on a VAX and it didn't occur to me that a program running on VMS could do such a stupid thing until I saw it. What I got first was a last-chance exception handler dump of registers that didn't point anywhere usefull. (At that point the process seems to have no stack, so no traceback handler). A process dump in that case didn't tell me anything I didn't already know, return to 0 pretty much wiped out pointers to everything usefull. I had to run with the debugger many times, doing a binary search for the line of code that caused the error, and then study the machine listing to figure out what was going on. (Reading through compiler generated prolog code is such fun! Made me really miss CALLx/RET!) ------------------------------ End of INFO-VAX 2007.671 ************************