INFO-VAX Thu, 27 Dec 2007 Volume 2007 : Issue 709 Contents: Between 6 to 20% employers look up your social networking page CPU Looper Monitor Script Re: CPU Looper Monitor Script Re: CPU Looper Monitor Script Re: CPU Looper Monitor Script Re: CPU Looper Monitor Script Re: CPU Looper Monitor Script Re: CPU Looper Monitor Script Re: Hobbyist Public Access OpenVMS VAX V7.3 System ONLINE Re: Question about INSTALLing shared images Re: Question about INSTALLing shared images Re: Question about INSTALLing shared images Re: Question about INSTALLing shared images Re: Question about INSTALLing shared images Setting Reflection 2 window titles from VMS Re: Singapore Server Rescue ---------------------------------------------------------------------- Date: Wed, 26 Dec 2007 20:51:43 -0800 (PST) From: gorecroot Subject: Between 6 to 20% employers look up your social networking page Message-ID: <0dd30fe2-c540-4b2f-9eb9-a6337ec95ad0@a35g2000prf.googlegroups.com> Source : http://www.gorecroot.com Enjoying the anonymity of the internet in social networking? Are you revealing a bit more in Orkut, Facebook, MySpace, YouTube, or BlogSpot? Extreme political opinions, photos, college pranks, "weekend" preferences and more? An increasingly popular trend, graduates stepping out of universities and looking ahead for their first interviews are closing their social networking pages. Reason: Big brother is watching. Job hunters are increasingly conscious of anything they put into the online sphere--even e-mail, which, of course, can be forwarded to anyone. These are not entirely paranoia. There is anecdotal evidence and some HR reports talk about corporate recruiters are Googling potential employees, having interns log onto social networking sites to check out an applicant's profile, and using the online world as another way to check references. This trend, combined with the growing population of sites like Orkut, Facebook and MySpace, has many young people uneasy and unsure about how to navigate a new world. B-school administrators and professors are beginning to advise students on maintaining a professional presence on social networking sites, in e-mail, on personal Web sites, and blogs. "Even if it's password protected, recruiters have profiles, too, and can get into your groups." In a survey by AfterCollege.com a little more than 70% of the 60 students say they continue to post the same things they always did, even though potential employers might be taking a look. About 20% of the 90 employers who have so far responded to the same survey, say they investigate new hires by visiting social networking sites. A considerable 6% of employers say they've decided not to hire someone based on what they saw online, but another 26% responded to that same question with "no comment." To quote Roberto Angulo of AfterCollege.com "Students should be more concerned than they are". ------------------------------ Date: Wed, 26 Dec 2007 10:55:21 -0800 (PST) From: tcarterhb@gmail.com Subject: CPU Looper Monitor Script Message-ID: <5cdc7f43-93b9-4c0d-b6bb-5a4fb8b0f686@j64g2000hsj.googlegroups.com> Hi, I need to write a script that will check for looping processes on a VMS system. I have no problem writing it, but was just checking whether anyone has something they could post that has already been written to save me the time. Basically just something that would check all process over an interval and identify those with high cpu utilization. thanks ------------------------------ Date: Wed, 26 Dec 2007 19:35:39 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: CPU Looper Monitor Script Message-ID: In article <5cdc7f43-93b9-4c0d-b6bb-5a4fb8b0f686@j64g2000hsj.googlegroups.com>, tcarterhb@gmail.com writes: > I need to write a script that will check for looping processes on a > VMS system. I have no problem writing it, but was just checking > whether anyone has something they could post that has already been > written to save me the time. Basically just something that would > check all process over an interval and identify those with high cpu > utilization. Depending on your needs, you might want to check high CPU usage coupled with no I/O. ------------------------------ Date: Wed, 26 Dec 2007 11:42:05 -0800 (PST) From: tcarterhb@gmail.com Subject: Re: CPU Looper Monitor Script Message-ID: On Dec 26, 11:35=A0am, hel...@astro.multiCLOTHESvax.de (Phillip Helbig--- remove CLOTHES to reply) wrote: > In article > <5cdc7f43-93b9-4c0d-b6bb-5a4fb8b0f...@j64g2000hsj.googlegroups.com>, > > tcarte...@gmail.com writes: > > I need to write a script that will check for looping processes on a > > VMS system. =A0I have no problem writing it, but was just checking > > whether anyone has something they could post that has already been > > written to save me the time. =A0 Basically just something that would > > check all process over an interval and identify those with high cpu > > utilization. > > Depending on your needs, you might want to check high CPU usage coupled > with no I/O. Yes, you are correct. I was just looking for a DCL script someone has already written, so I don't have to re-invent the wheel. I haven't found anything yet at openvms.org, or dcl.openvms.org. I guess it would be the opposite of a Watchdog type procedure that monitors idle users, Anyone have anything? thanks. ------------------------------ Date: Wed, 26 Dec 2007 13:16:35 -0800 (PST) From: David_Murphy@murphyfamily.org Subject: Re: CPU Looper Monitor Script Message-ID: <60e0aecb-2348-477d-9e7f-3bf053b895cf@b40g2000prf.googlegroups.com> I can't imagine writing this in DCL without suffering memory leaks. In fact I have a hard time imagining writing it in DCL at all, due to the limited array capabilities. I've written performance monitoring software for years, and trying to capture the running history of 'n' processes over a long period of time is not a job DCL is suited for. That said, I suppose it would look like this: $ limit = 300 ! hundredths of a second $ OUTLOOP: $ context = "" $ PIDLOOP: $ runpid = f$pid(context) $ if runpid .nes. "" $ then $ curcpu = f$getjpi(runpid, "CPUTIM") $ if f$type(array_'runpid'_cpu) .eqs. "" $ then $ ! first time this process has been seen, nothing to compare $ else $ delta = curcpu - array_'runpid'_cpu $ if delta .gt. limit then - write sys$output "process ''runpid' has exceeded the CPU threshold" $ endif $ array_'runpid'_cpu = curcpu $ goto PIDLOOP $ endif $ wait 00:10:00 $ goto OUTLOOP Notice the problems? For example, what happens when a pid is re-used? How meaningful is it that a process uses 3 CPU seconds in 10 realtime seconds? How many intervals do you want to track before deciding a process is looping? ok dpm ------------------------------ Date: Wed, 26 Dec 2007 13:39:13 -0800 (PST) From: tcarterhb@gmail.com Subject: Re: CPU Looper Monitor Script Message-ID: On Dec 26, 1:16=A0pm, David_Mur...@murphyfamily.org wrote: > I can't imagine writing this in DCL without suffering > memory leaks. =A0In fact I have a hard time imagining > writing it in DCL at all, due to the limited array capabilities. > I've written performance monitoring software for years, > and trying to capture the running history of 'n' processes > over a long period of time is not a job DCL is suited for. > That said, I suppose it would look like this: > > $ =A0 =A0 limit =3D 300 =A0 =A0! hundredths of a second > $ OUTLOOP: > $ =A0 =A0 =A0 context =3D "" > $ PIDLOOP: > $ =A0 =A0 =A0 runpid =3D f$pid(context) > $ =A0 =A0 =A0 if runpid .nes. "" > $ =A0 =A0 =A0 then > $ =A0 =A0 =A0 =A0 =A0 =A0 =A0 curcpu =3D f$getjpi(runpid, "CPUTIM") > $ =A0 =A0 =A0 =A0 =A0 =A0 =A0 if f$type(array_'runpid'_cpu) .eqs. "" > $ =A0 =A0 =A0 =A0 =A0 =A0 =A0 then > $ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ! first time this process ha= s been seen, nothing to compare > $ =A0 =A0 =A0 =A0 =A0 =A0 =A0 else > $ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 delta =3D curcpu - array_'ru= npid'_cpu > $ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if delta .gt. limit then - > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 write sys$= output "process ''runpid' has exceeded the CPU > threshold" > $ =A0 =A0 =A0 =A0 =A0 =A0 =A0 endif > $ =A0 =A0 =A0 =A0 =A0 =A0 =A0 array_'runpid'_cpu =3D curcpu > $ =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto PIDLOOP > $ =A0 =A0 =A0 endif > $ =A0 =A0 =A0 wait 00:10:00 > $ =A0 =A0 =A0 goto OUTLOOP > > Notice the problems? =A0For example, what happens when > a pid is re-used? =A0How meaningful is it that a process uses > 3 CPU seconds in 10 realtime seconds? =A0How many intervals > do you want to track before deciding a process is looping? > > ok > dpm Yes, I see the potential problems, but this will really only check every 5 minutes or so, and compare the delta (5 min) with the cpu time of a process, so if I check every 5 minutes, and a process has almost 5 minutes of CPU time, it is a potential looper. Just a ballpark. Yes , I know that there will be plenty of times when the system has processes that utilize more cpu, but this is just to catch any problems. We had a problem the past few days where a user was connected via Putty and SSH protocol,and he just disconnected his vpn connection without logging out, and it sent the lingering SSH process looping away, 100% cpu. Bug in SSH client for VMS (TCPIP v5.4 eco 6, vms v7.3-2) I would think. Anyway, The powers that be are looking for ways to prevent, or detect this so it doesn't happen in the future. I don;t want to be looking at a Monitor window all day long. I have caught more than a few SSH BG devices looping in the past week. I'll call HP and see if they have had this problem reported. There used to be an old DEC product called System Watchdog that did a nice job with this, but I think it got swallowed up by Computer Associates and their outrageous Unicenter family. thanks. ------------------------------ Date: Wed, 26 Dec 2007 22:12:32 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: CPU Looper Monitor Script Message-ID: In article , tcarterhb@gmail.com writes: > > >On Dec 26, 1:16{equal}A0pm, David_Mur...@murphyfamily.org wrote: >> I can't imagine writing this in DCL without suffering >> memory leaks. {equal}A0In fact I have a hard time imagining >> writing it in DCL at all, due to the limited array capabilities. >> I've written performance monitoring software for years, >> and trying to capture the running history of 'n' processes >> over a long period of time is not a job DCL is suited for. >> That said, I suppose it would look like this: >> >> $ {equal}A0 {equal}A0 limit {equal}3D 300 {equal}A0 {equal}A0! hundredths of a second >> $ OUTLOOP: >> $ {equal}A0 {equal}A0 {equal}A0 context {equal}3D "" >> $ PIDLOOP: >> $ {equal}A0 {equal}A0 {equal}A0 runpid {equal}3D f$pid(context) >> $ {equal}A0 {equal}A0 {equal}A0 if runpid .nes. "" >> $ {equal}A0 {equal}A0 {equal}A0 then >> $ {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 curcpu {equal}3D f$getjpi(runpid, "CPUTIM") >> $ {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 if f$type(array_'runpid'_cpu) .eqs. "" >> $ {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 then >> $ {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 ! first time this process ha{equal} >s been seen, nothing to compare >> $ {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 else >> $ {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 delta {equal}3D curcpu - array_'ru{equal} >npid'_cpu >> $ {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 if delta .gt. limit then - >> {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 write sys${equal} >output "process ''runpid' has exceeded the CPU >> threshold" >> $ {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 endif >> $ {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 array_'runpid'_cpu {equal}3D curcpu >> $ {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 {equal}A0 goto PIDLOOP >> $ {equal}A0 {equal}A0 {equal}A0 endif >> $ {equal}A0 {equal}A0 {equal}A0 wait 00:10:00 >> $ {equal}A0 {equal}A0 {equal}A0 goto OUTLOOP >> >> Notice the problems? {equal}A0For example, what happens when >> a pid is re-used? {equal}A0How meaningful is it that a process uses >> 3 CPU seconds in 10 realtime seconds? {equal}A0How many intervals >> do you want to track before deciding a process is looping? >> >> ok >> dpm > >Yes, I see the potential problems, but this will really only check I see another problem because your news software sends quoted-printable. I've substitued every = with {equal} so you can see how UGLY this is for those of us who have news readers which send out and read plain text as usenet was intended. I'd suspect your reader would translate the = and hex code such that you couldn't see the problem if I didn't use {equal}. David's initial post was fine. It's your news reader that quoted David and horked up his code. >every 5 minutes or so, and compare the delta (5 min) with the cpu >time of a process, so if I check every 5 minutes, and a process has >almost 5 minutes of CPU time, it is a potential looper. Just a >ballpark. Yes , I know that there will be plenty of times when the >system has processes that utilize more cpu, but this is just to catch >any problems. We had a problem the past few days where a user was >connected via Putty and SSH protocol,and he just disconnected his vpn >connection without logging out, and it sent the lingering SSH process >looping away, 100% cpu. Bug in SSH client for VMS (TCPIP v5.4 eco >6, vms v7.3-2) I would think. Anyway, The powers that be are >looking for ways to prevent, or detect this so it doesn't happen in >the future. I don;t want to be looking at a Monitor window all day >long. I have caught more than a few SSH BG devices looping in the >past week. I'll call HP and see if they have had this problem >reported. > >There used to be an old DEC product called System Watchdog that did a >nice job with this, but I think it got swallowed up by Computer >Associates and their outrageous Unicenter family. Yup. That's what Google shows. -- 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: Wed, 26 Dec 2007 20:59:54 -0600 From: David J Dachtera Subject: Re: CPU Looper Monitor Script Message-ID: <4773152A.B859DAE7@spam.comcast.net> tcarterhb@gmail.com wrote: > > Hi, > > I need to write a script that will check for looping processes on a > VMS system. I have no problem writing it, but was just checking > whether anyone has something they could post that has already been > written to save me the time. Basically just something that would > check all process over an interval and identify those with high cpu > utilization. > > thanks Take a look at this: http://www.djesys.com/freeware/vms/sys_mon.zip This a VMS .ZIP archive containing a piece of DCL code I'm currently running at work. Admittedly, it's rather a "q and d", and as such, needs to be stopped and restarted daily due to the "memory leak" issues noted by other posters. To make it "release quality", you'd want to add a list of PIDs being watched to see if any have gone away, and then clean the associated symbols out of the process environment. All that before scanning using F$CONTEXT() and F$PID() to find new processes or gather stat.'s on existing processes for comparison to the previous samples. SYS_MON tracks CPU utilization and I/O counts to determine whether action should be taken. It might make a good starting point for some considerably more sophisticated DCL code. It is intended run as a daemon (detached process), and is designed to issue notification by both e-mail and pager; however, the paging interface will likely need to be customized for any given site. Ours uses the former archwireless.com and sends pages using POST method via WGET (Thanx, SMS!). SYS_MON was written in haste to handle a problem with Cerner code which can get its undies in a bunch. Dunno if the same issue exists in the AIX version of that same Cerner code. ("Server 200".) David J Dachtera DJE Systems ------------------------------ Date: Wed, 26 Dec 2007 17:36:12 -0800 (PST) From: "tomarsin2015@comcast.net" Subject: Re: Hobbyist Public Access OpenVMS VAX V7.3 System ONLINE Message-ID: <804ce33b-d75e-4228-907f-83c84f1448f9@i29g2000prf.googlegroups.com> On Dec 24, 3:30=A0am, Alexander Horn wrote: > Hi VMS-Guys and Ladies, > > My FREE and Public Access OpenVMS VAX V7.3 is ONLINE: > > Host: BIRD.MARWAY.ORG (85.214.95.107) > (...) > Username: NEWUSER > Password: NEWUSER > (...) > > Thanks to Hoff from HoffmanLabs and ``Da Beave'' from Deathrow OpenVMS > =A0 =A0 =A0 =A0 =A0 Cluster in North-Carolina, USA. > > FYI, Compaq C Compiler V6.4-005 and DEC Notes V2.5 is installed :) > =A0 =A0 =A0This week, an VMS IRC Client, ZIP/UNZIP, TAR etc. will come... > > C YA and MERRY X-Mas, > -Vaxima > > -- > Alexander Horn, Hostmaster (of staff) =A0 | OpenVMS (TM) rocks! > 10 Bruckner, Sindelfingen 71065 Germany |http://www.marway.org/ > eMail: vax...@marlabs.net =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Trouble with Windo= ws? Reboot! > =A0 =A0 =A0 =A0vax...@vaxima.net =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Trouble = wth UNIX? Be root! Greetings Add this system to public access 68.35.165.150 Username guest password guest This is mostly a test bed system. Depending on how much useage the system gets, will depend if it stays up or gets retired. phillip ------------------------------ Date: Wed, 26 Dec 2007 14:33:42 -0500 From: JF Mezei Subject: Re: Question about INSTALLing shared images Message-ID: <4772acfa$0$16214$c3e8da3@news.astraweb.com> AEF wrote: To answer your question, generally, the way VMS is setup, you won't have shared writeable sections between instances of the same shared images unless you're taken active steps to make it happen. The one area to be careful is externally defined variables. There are some which you can define as being writeable. You could write a small application that defines variables in every way that they were defined in your real application. Then the application prompts for an option to display those variables, and an option to set them to some value. One user runs the app and displays the values, while another user runs the app and sets the values. You should then be able to prove that n9one of the means to define variables in your production aopplication would result in shared data. >> Similarly, your executable must be linked/NOTRACEBACK when it is >> installed/shared. > > Really? What if it isn't? How does it fail or err? There is an error generated by link if there are incompatible options. Similarly, if install detects bad image attributes, it won't let you do the install/share. (I think it applies to traceback as well as /debug as well). ------------------------------ Date: Wed, 26 Dec 2007 19:34:44 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: Question about INSTALLing shared images Message-ID: In article <47729ddb$0$4320$c3e8da3@news.astraweb.com>, JF Mezei writes: > AEF wrote: > > > When you INSTALL an executable as a shared image, can it be any > > executable? > > No. You can't install a OS-X executable on VMS. :-) Perhaps not, but you can install an Alpha image on Itanium and/or vice versa. ------------------------------ Date: Wed, 26 Dec 2007 17:40:15 -0600 From: Chris Scheers Subject: Re: Question about INSTALLing shared images Message-ID: <5tg72tF1ctm3mU1@mid.individual.net> AEF wrote: > On Dec 26, 2:29 pm, JF Mezei wrote: >> AEF wrote: >>> When you INSTALL an executable as a shared image, can it be any >>> executable? >> No. You can't install a OS-X executable on VMS. :-) >> >> If your application is written in C, there are certain constructs with >> public variables which may prevent it from being installed/shared if I >> remember correctly. If I recall, the "extern" type of declaration is not >> compatible with installing image/shared. > > Written in Pascal. I'm not familiar with the implementation details for Pascal, but there are some issues with FORTRAN and C, so there may be some for Pascal as well. If I understand your intent, you want all read only data/code to be shared and all writable variables to be private. (The stack is always private.) By default FORTRAN COMMON blocks are shared writable as can be some C "extern" variables. IIRC, any PSECT with the "GBL" and "WRT" attributes is problematic. Fortunately, INSTALL will tell you if you have any such PSECTS, so you have some warning. Also fortunately, managing this does not require any code changes or special compiler switches. You can override the PSECT attributes with a linker options file. So as long as your image is not installed writable, I think you are OK. >> (Or this could be a linker issue not allowing /SHARED to be used in such >> circumstances). >> >> Similarly, your executable must be linked/NOTRACEBACK when it is >> installed/shared. > > Really? What if it isn't? How does it fail or err? > >> This is all from fairly distant memory with no parity bit. > > OK. > > AEF -- ----------------------------------------------------------------------- Chris Scheers, Applied Synergy, Inc. Voice: 817-237-3360 Internet: chris@applied-synergy.com Fax: 817-237-3074 ------------------------------ Date: Wed, 26 Dec 2007 15:49:53 -0800 (PST) From: Bob Gezelter Subject: Re: Question about INSTALLing shared images Message-ID: <15bd3e73-8525-44be-acab-3a7013a791f2@r60g2000hsc.googlegroups.com> On Dec 26, 10:19 am, AEF wrote: > Season's Greetings (I actually saw this in big letters hanging from > the ceiling of a Wegmans supermarket!) > > My apologies if this is a dumb question, but I want to be 100% > certain. (Hey, at least it's on topic!!!) > > When you INSTALL an executable as a shared image, can it be any > executable? I once discussed this with my developer for a program run > by multiple traders and he said we'd have to check for traders > stepping on each other, so to speak. So my question is: Doesn't VMS > automatically provide each process running shared executable its own > private data area in memory or does the program have to be explicitly > written with the assumption that it will be installed shared? > > Thanks > > AEF AEF, A key comment in your posting (and followup) is that this is a VAX executable. Some compilers on VAX flagged certain variables as shareable. This does no harm, so long as the image is not INSTALLed. It can produce [spectacular] failing results if this is the case. (While I have never fallen into this trap [I was aware of it from the PDP-11 days, and always thought it was a poor default then], I have had several clients fall into it. The cure is straightforward. A review of the LINK map, together with an appropriate LINK options file and a reLINK will quite happily resolve the problem. I cannot write any more at the moment, since I am in the middle of a client reconfiguration, and have to get back to preparing for tomorrow. - Bob Gezelter, http://www.rlgsc.com ------------------------------ Date: Thu, 27 Dec 2007 02:16:55 GMT From: "John E. Malmberg" Subject: Re: Question about INSTALLing shared images Message-ID: AEF wrote: > On Dec 26, 11:33 am, "Richard B. Gilbert" > wrote: >> AEF wrote: >> My recollection is that the writeable areas are unique while the read >> only stuff (code, constants, etc.) is shared. > > Thanks! That is correct. >> ISTR that the subject is covered in some detail in the FM. Go thou, and >> RTFM. > > Well, perhaps I should have stated my motivation. I'm running a mature > app (very mature!). I need to consolidate to running on fewer > MicroVAXes. My app starts a process for each trader. Each of these > processes runs the same executable and it is not INTSTALed. I was > concnerned that memory might get a little tight so I thought: Why not > install it shared to save a little memory? In general, any executable that will be run by more than one person will probably benefit from being installed shared. Installed share/header_resident will reduce the amount of memory used by the process, and it will also speed up the image activation. There is a small memory penalty system wide for installing images. It is less than the amount of memory consumed by the second copy of the image running. Especially if it is commonly used. If you want candidates of images to be installed, then do the DCL command $show dev/files/nosystem on each of your disks. If you see any executables in there more than once, you will probably be better off installing them. Note that you may have to increase the sysgen parameters for global sections and pages. Other SYSGEN tuning including RMS parameters can also help. But the biggest gains can be from buying faster hardware of course. > I mentioned this to my > developer (this occurred years ago) and he said we'd have to test > every possible combination of posting prices and executing trades > among multiple simultaneous users. I thought he was wrong but let it > go. Now it's a little more urgent (but not immediate) so I thought I'd > ask here to be certain. (Perhaps he was thinking of installing the way > we install our shared memory files with INSTALL/SHARE/WRITABLE! Then I > could understand his concern.) A writable image requires special coding to link and the writable image can not be shared between nodes on a cluster. Older VMS versions did not enforce that restriction. > Now, if the answer is that it's okay to INSTALL any old image with / > SHARE and private data won't get mixed among concurrent processes > running the same image, then I can INSTALL/SHARE this image and I'm > done. That is pretty much it. > If the answer is: You have to write your app such and such a way > to prevent private data corruption then I will not INSTALL/SHARE > anything and I'm done. No one is going to rewrite this app for this. If the application has a linked in memory area that is shared between two processes, then it already needed to be installed for this to work. > So I don't see any need to RTFM. I just wanted to know if anything > special needs to be done when writing the program or any old program > can safely be INSTALL/SHAREd without having to become an expert on > programming when I'm not going to write or rewrite any code and > haven't touched 3GL's since 1993 and then only writing FORTRAN > programs to do physics calculations (no fancy stuff like global > sections, shared this, shared that, privs, macro, etc.) Privileged images must be linked /notrace to be installed. Non-privileged images do not need any special treatment. -John wb8tyw@qsl.network Personal Opinion Only ------------------------------ Date: Thu, 27 Dec 2007 05:38:40 GMT From: "John E. Malmberg" Subject: Setting Reflection 2 window titles from VMS Message-ID: I am trying to find a way that I can set the titles of my R2 terminal emulation session from VMS. I am running Reflection R2 version 5.20 This is so that after the frequent reboots of the PC, I can reconnect to the existing sessions on VMS and then just run a script or program to fix the titles. Ideally I would want to identify the terminal emulator in use so that I can have one script work for what ever is in use. R2 has some private escape sequences that return its serial number, and that seems to be a possible way to identify it. So far what I have determined: R2 (V5.20) claims to be a VT400 with soft characters. It also supports ANSI color, but set term/inquire does not appear to probe for this feature if there is a way to do so. DecTERMs claim to be VT300 with no soft characters and support for ANSI color. Decterms use a DEC private escape sequence to set the window titles. The free version of IVT claims to be a VT200 with soft characters. I have not tested it to see if it supports ANSI colors. IVT window titles can be set with the "xterm" escape sequences. Putty by default claims to be a VT102. It supports ANSI colors, as noted above, set term/inq does not indicate so. Putty window titles can be set with the "xterm" escape sequences. I have not yet found any way to positively identify any of the above terminal emulators. For my local LAN, I can put in a hint in the answerback message, but I would prefer a generic solution. That way I can also have the SYLOGIN.COM accurately set what the terminal emulators can really do for the terminal characteristics. -John wb8tyw@qsl.network Personal Opinion Only ------------------------------ Date: Thu, 27 Dec 2007 00:54:09 -0600 From: pechter@pcp09822625pcs.eatntn01.nj.comcast.net (Bill Pechter) Subject: Re: Singapore Server Rescue Message-ID: In article , Bob Koehler wrote: >In article <82e$4768e886$cef8887a$13093@TEKSAVVY.COM>, JF Mezei > writes: >> P. Sture wrote: >>> >>> >>> I'm pretty sure that this was in the smallest PDP I ever saw that a >>> local word processing company were using in 1984. >> >> There was a VT100 terminal with some sort of expansion box about the >> time of 1981, the expansion box was a PDP11. >> >> Data Terminal Mart in Canada was carrying it ins its stores. > > Sounds like the Mini-MINC. MINC and Mini-MINC were third party > systems using DEC components. Mini-MINC was one of those ROM-based > BASIC computers that everyone was selling prior to the first IBM > PC. > Nope. Mini-Minc was a renamed PDT11/150. MINC was a lab Real-Time PDP11 (usually an 11/23) with A-to-D and D-to-A add-ons and other digital interfaces. Owned one of those Mini-Minc's as part of DEC's PDT11/150 employee purchase program when they cleaned out the warehouse of overstock Ran RT11 real nice... Just needed a hard disk and it would've been a killer box. bill -- -- Be comforted that in the face of all erridity and disallusionment, and despite the changing fortunes of time, there is always a big future in computer maintainance. --Deteriorata (pechter-at-gmail-dot-com) ------------------------------ End of INFO-VAX 2007.709 ************************