INFO-VAX Tue, 15 Jul 2008 Volume 2008 : Issue 393 Contents: Re: Another BIND vulnerability (cache poisoning) EXPERT SAP INSTALLATIONS - ANY TYPE Re: File modified date a week late Monitoring Runaway CPU Processes Re: Monitoring Runaway CPU Processes Re: Q: Configure TCP/IP Services for a node not yet booted? Re: Q: Configure TCP/IP Services for a node not yet booted? Re: Q: Configure TCP/IP Services for a node not yet booted? Re: Q: Configure TCP/IP Services for a node not yet booted? Re: RFC: Switching to WASD after 15 yrs with OSU... Re: RFC: Switching to WASD after 15 yrs with OSU... Re: RFC: Switching to WASD after 15 yrs with OSU... Re: RFC: Switching to WASD after 15 yrs with OSU... Visio 2007 Prof and Rdb... ---------------------------------------------------------------------- Date: Tue, 15 Jul 2008 13:39:08 -0400 From: JF Mezei Subject: Re: Another BIND vulnerability (cache poisoning) Message-ID: <487ce0dc$0$1841$c3e8da3@news.astraweb.com> JF Mezei wrote: > Slashdot article: > http://it.slashdot.org/article.pl?sid=08/07/08/195225 > > Offfical CERT article: > http://www.kb.cert.org/vuls/id/800113 Just a reminder that HP has yet to provide CERT with any information about its many DNS implementations. Linux had patches available day of this announcement, as did Microsoft. As one analyst put it some time ago, it isn't the number of patches tha is important, it is the number of days before a patch is issued that matters because that is the number of days a system remains vulnerable. ------------------------------ Date: Tue, 15 Jul 2008 04:46:21 -0700 (PDT) From: Nick101 <1sapmate@googlemail.com> Subject: EXPERT SAP INSTALLATIONS - ANY TYPE Message-ID: <9b703eb9-4454-4033-b36e-df5c5c204e33@k13g2000hse.googlegroups.com> SAP IDES INSTALLATIONS We can provide installation service for any type of following SAP IDES System in your stand alone home Laptop & Desktop and external USB Hard discs SAP R\3 4.7 EE, SAP ECC 5.0, SAP ECC 6.0 SAP CRM 5.0, SCM 5.0, SAP SRM 5.0, SAP BI 7.0, SAP SEM 6.0, SAP BW 3.1, IS- Utilities IS- Retail IS- Oil IS- Media IS- Healthcare Solution Manager SAP Netweaver with EP 7.0, Development framework SAP Middleware Connections for BW Extractions All R\3 systems comes with these core modules SAP HR (Human Resource) SAP FI CO (Finance & Controlling) SAP SD (Sales & Distribution) SAP MM (Materials Management ) SAP PP (Production Planning) We believe in 100 % CUSTOMER SATISFACTION and are dedicated to provide not only QUICK High Quality Service but lot of other intangible benefits and are NOT in just money making business like any TOM, DICK and HARRY so it is ALWAYS WORTH to have one telephonic discussion with our expert advisor before you decide to opt "Cheap Service Provider". We never take any advance and always deal face to face. Please have a link to this url for more details http://1sapmate.googlepages.com/home ------------------------------ Date: Tue, 15 Jul 2008 09:39:18 -0400 From: norm.raphael@metso.com Subject: Re: File modified date a week late Message-ID: This is a multipart message in MIME format. --=_alternative 004B022B85257487_= Content-Type: text/plain; charset="US-ASCII" JF Mezei wrote on 07/14/2008 06:10:57 PM: > The modified date/time seems to match the start time of the next job. > > So it is possible that when that job starts, it examines the previous > log and does something to them (perhaps open/read/write and only reads > them to check previous job for errors ?) > The job us unaware of previous log files. More likely, when the directory file gets opened to write a new version number of the log file, it forces the modified date on the prior version. I still think it's a directory cache situation. --=_alternative 004B022B85257487_= Content-Type: text/html; charset="US-ASCII"
JF Mezei <jfmezei.spamnot@vaxination.ca> wrote on 07/14/2008 06:10:57 PM:

> The modified date/time seems to match the start time of the next job.
>
> So it is possible that when that job starts, it examines the previous
> log and does something to them (perhaps open/read/write and only reads
> them to check previous job for errors ?)
>
The job us unaware of previous log files.  More likely, when the directory

file gets opened to write a new version number of the log file, it forces
the modified date on the prior version.  I still think it's a directory
cache situation. --=_alternative 004B022B85257487_=-- ------------------------------ Date: Tue, 15 Jul 2008 09:02:29 -0700 (PDT) From: "James J. O'Shea" Subject: Monitoring Runaway CPU Processes Message-ID: <905692.32818.qm@web83905.mail.sp1.yahoo.com> Hello, Does anyone know if there is a utility, free or otherwise, that will alert when there is a runaway CPU process? Thanks, Jim O'Shea Chicago, IL USA ------------------------------ Date: Tue, 15 Jul 2008 12:14:19 -0400 From: "Richard B. Gilbert" Subject: Re: Monitoring Runaway CPU Processes Message-ID: James J. O'Shea wrote: > Hello, > > Does anyone know if there is a utility, free or > otherwise, that will alert when there is a runaway > CPU process? > > Thanks, > Jim O'Shea > Chicago, IL USA Define "runaway process". If you are talking about an "infinite loop", you can shut it down with a limit on CPU time; e.g. RUN /TIME_LIMIT=. There may be quotas and limits you can set in AUTHORIZE that will shut it down for you. You can avoid the whole problem by not coding infinite loops! ------------------------------ Date: Tue, 15 Jul 2008 01:16:01 -0700 (PDT) From: etmsreec@yahoo.co.uk Subject: Re: Q: Configure TCP/IP Services for a node not yet booted? Message-ID: <3b4f46af-a57c-41df-995b-f378253b7da0@s50g2000hsb.googlegroups.com> On 14 Jul, 23:56, Ken.Fairfi...@gmail.com wrote: > On Jul 14, 3:38 pm, JF Mezei wrote: > > > K > > > > =A0 =A0Am I correct to assume that when Roy (and JF) said that > > > entries in TCP$CONFIGURATION are "indexed by node", > > > that "node" in this cases is, e.g., SCSNODE or SCSSYTEMID? > > > I believe it is SCSNODE > > > DUMP/RECORD is your friend there. Get the SCSSYSTEMID value and look fo= r > > it in hex in the dump just to make sure. But the nodename is definitely > > there. > > Will do, later in the week when I have more time. =A0Thanks for the > various hints, JF. :-) > > > > Then it would seem I could proceed with the "pre-configuration" > > > step. > > > Could you shutdown D, separate it from the cluster, and then boot it > > minimal as Node A, you could then use TCPIP$CONFIG at your leasure, shu= t > > it down, boot it as Node B, rin TCPIP$CONFIG at your leasure and do the > > same for node C. > > That's probably more scary (risky?) to me. =A0I know it should be > OK in principle, but fat-fingering can lead to some issues I'd > rather not deal with (yes, the new node won't be allowed to > join the cluster, but I saw something close to a cluster hang > when changed SHADOW_SYS_UNIT for node D in the *wrong* > ALPHAVMSSYS.PAR and it tried to mount DSA10 as DSA0 > first time around(!)...). > > [...] > > > The other option, as I originally suggested is to use the TCPIP utility > > on each of the node to affect the files on DSA10: by refining the > > logicals to point to the DSA10: files. > > This is what I'm leaning toward doing. > > > You *MIGHT* (with a lot of checking) be able to use TCPIP$CONFIG on Nod= e > > A (with proper logicals defined, and SET COMMAND for TCPIP) and then yo= u > > would need to backup the node specific directories that are created whe= n > > you configure services over to DSA10: to the appropriate roots for each > > node. (this can be cloned for all 3 nodes since those directories are > > populated with files from TCPIP$TEMPLATES.TLB ) > > I agree that it seem like this ought to work, but doing the individual > configuration commands inside the TCPIP utility seems somewhat > more controlled (at least to the extent that I'm confident what's > going on). > > [...] > > > How much of downtime is allowed ? Could could boot without starting you= r > > apps (halfway between minuimum and full boot) and then manually use > > TCPIP$CONFIG, and then reboot fully. =A0This might be the safest bet. > > Well, agreed about suppressing all the disk mounts and applications > startup that aren't needed. =A0But running TCPIP$CONFIG.COM is not > particularly quick and leads to typos under time pressure. =A0If I have > to wait to boot the new system disk before configuring, then I'll do > that > configuration via a DCL command procedure. > > > What we don't know is how your 3 nodes share the loads/applications and > > how long you can have one node shutdown at any point in time. > > In this case, I want all three (production) nodes using the same IP > stack at > any time the application is up (Cerner Millennium), so we'll make it a > full > application, full cluster downtime. > > Thanks for all the ideas, Ken If it's full applicaiton, full cluster downtime, the safest way is going to be to run TCPIP$CONFIG when the nodes come back up. There is likely to be stuff going on behind the command procedure that you wouldn't necessarily be able to see from the effects (a bit like if you don't let net$configure start the network then DECnet Plus won't work properly!) Steve ------------------------------ Date: Tue, 15 Jul 2008 02:06:08 -0700 (PDT) From: "Bart.Zorn@gmail.com" Subject: Re: Q: Configure TCP/IP Services for a node not yet booted? Message-ID: <66374f44-1c59-45e1-8a64-b24316bcbf57@p25g2000hsf.googlegroups.com> On Jul 15, 12:56=A0am, Ken.Fairfi...@gmail.com wrote: > On Jul 14, 3:38 pm, JF Mezei wrote: [ S n i p . . . ] > > You *MIGHT* (with a lot of checking) be able to use TCPIP$CONFIG on Nod= e > > A (with proper logicals defined, and SET COMMAND for TCPIP) and then yo= u > > would need to backup the node specific directories that are created whe= n > > you configure services over to DSA10: to the appropriate roots for each > > node. (this can be cloned for all 3 nodes since those directories are > > populated with files from TCPIP$TEMPLATES.TLB ) > > I agree that it seem like this ought to work, but doing the individual > configuration commands inside the TCPIP utility seems somewhat > more controlled (at least to the extent that I'm confident what's > going on). Be VERY careful here. The entire TCP/IP Services package is VERY intolerant for any disk except for the system disk. SYS$SPECIFIC and SYS$SYSDEVICE are being used hardcoded all over the place. I once tried to persuade TCP/IP services to run from a non-system disk but I gave up. At DECUS in San Diego, in 1999, I had a lengthy discussion with several members of the TCP/IP engineering team. One item was just this aspect. They agreed that it should be possible to configure TCP/IP on an other disk than the system disk. Unfortunately, it is still on the list of possible future enhancements (I hope). They even had a dedicated QA engineer at that time! Bart ------------------------------ Date: Tue, 15 Jul 2008 06:01:56 -0400 From: JF Mezei Subject: Re: Q: Configure TCP/IP Services for a node not yet booted? Message-ID: <487c75b7$0$5438$c3e8da3@news.astraweb.com> Bart.Zorn@gmail.com wrote: > Be VERY careful here. The entire TCP/IP Services package is VERY > intolerant for any disk except for the system disk. SYS$SPECIFIC and > SYS$SYSDEVICE are being used hardcoded all over the place. I once > tried to persuade TCP/IP services to run from a non-system disk but I > gave up. The setup of the core stuff requires only the use of one utility, the TCPIP utility (TCPIP$UCP.EXE). It can be easier to control. Worse case scenario, copy the TCPIP$*.DAT files from the "D" system disk over to the A-B-C system disk. Those files will contain the D setup. Then use TCPIP utility on each of the A-B-C nodes to add each node's specific stuff. This would have a fully polyulated TCPIP*.DAT files residing on DSA1, and you can move them back over to the DSA10: system disk. Where system disk dependencies really exist in in TCPIP$CONFIG because it creates directories specific to each service and those are created either in the specific root or vms$common depending on the service. Some are treated at the top of the system disk as well. Note to the OP: Make sure you scan thorugh TCPIP$CONFIG.COM to look at the code that determines, based on name of the ethernet device, the name of the interfaces you will have on that system. If the ethernet device names on all 4 systems are the same device names, then you can assume the same interface names. But if the ethernet devices are different, then you'll have different interface names. here is the relevant definition: TCPIP$EDEV = "0 XE:DE XQ:QE ES:SE ET:NE EX:XE EF:FE EZ:ZE EC:CE" + - "ER:RE EW:WE EB:BE EI:IE LL:LE EG:GE VL:VE" My ethernet devide is an EWA0, which means my internet interface is WE0 (from the EW:WE item) ------------------------------ Date: Tue, 15 Jul 2008 11:29:47 +0100 From: "R.A.Omond" Subject: Re: Q: Configure TCP/IP Services for a node not yet booted? Message-ID: <487c7c1c$0$90262$14726298@news.sunsite.dk> JF Mezei wrote: > Bart.Zorn@gmail.com wrote: > >> Be VERY careful here. The entire TCP/IP Services package is VERY >> intolerant for any disk except for the system disk. SYS$SPECIFIC and >> SYS$SYSDEVICE are being used hardcoded all over the place. I once >> tried to persuade TCP/IP services to run from a non-system disk but I >> gave up. > > > [...snip...] > Note to the OP: Make sure you scan thorugh TCPIP$CONFIG.COM to look at > the code that determines, based on name of the ethernet device, the name > of the interfaces you will have on that system. > > If the ethernet device names on all 4 systems are the same device names, > then you can assume the same interface names. But if the ethernet > devices are different, then you'll have different interface names. > > here is the relevant definition: > TCPIP$EDEV = "0 XE:DE XQ:QE ES:SE ET:NE EX:XE EF:FE EZ:ZE EC:CE" + - > "ER:RE EW:WE EB:BE EI:IE LL:LE EG:GE VL:VE" > > My ethernet devide is an EWA0, which means my internet interface is WE0 > (from the EW:WE item) To Ken (Fairfield), I was just about to add a similar reply to JF's. Unless the interfaces are all the same on all 4 systems, you're going to get into a *huge* mess, even if you manage to get round the indexed-by-node-name issue. I think you'd be well advised to not go ahead with your original plan. Just my 2c worth. ------------------------------ Date: Tue, 15 Jul 2008 08:04:37 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: RFC: Switching to WASD after 15 yrs with OSU... Message-ID: JF Mezei wrote: > etmsreec@yahoo.co.uk wrote: > >> Important feature for me is that WASD doesn't require installation on >> an ODS5 volume. CSWS requires an ODS5 installation volume so you >> either need to have a container file, a data disk or the system disk >> initialized / converted to this. > > > OSU is multi threaded and is very efficient. Ran fine on an all mighty > microvax II. Yes, it has served me just fine on anything from MV-3100's to DS20's. > > Apache is not VMS friendly because of the number of processes constantly > being created. As I understdand it also. Only political reasons would make that the "best" alternative... :-) > > Not sure what architecture WASD uses (threads, AST driven or multi process) Seems to be a very efficient architecture. One thing are the "persistant serverprocesses", where a server process can be keept alive between calls. Saves a lot of image activation when using tools like perl, Python or Java. If I'm right, this also supports the "$persona" services, so each run can be under different VMS users, even if it's the same server process running... Jan-Erik. ------------------------------ Date: Tue, 15 Jul 2008 01:13:00 -0700 (PDT) From: Rob Subject: Re: RFC: Switching to WASD after 15 yrs with OSU... Message-ID: <4147b7e3-abb6-404d-9459-9451e75fb941@x41g2000hsb.googlegroups.com> On Jul 13, 9:49=A0pm, Jan-Erik S=F6derholm wrote: > Hi. > > After 15 yrs with the OSU http server, I'm now > thinking of switching to the WASD server instead. > Mostly becuse the WASD server seem to be more > actively developed and since JFP's (Jean-Fran=E7ois > PI=C9RONNE) very nice Python distribution seems to > have a closer connection and better integration > with WASD then OSU. > > Now, is there any reason I should make this switch ? > > Bets regards, > Jan-Erik. > > PS: Yes, I know about "secure web server" also, but > I think both OSU and WASD are more VMS-ish then > Apache... The one and only reason that I wouldn't (and couldn't) make WASD my Production Web server was the lack of formal support. If Mark wasn't around then things would get very problematic, despite the excellent WASD support community. With CSWS we know we have a guaranteed response from HP, which is something a large business has to have. If this isn't a problem, i.e. you're not running a high availability Production system, then certainly WASD is much better than Apache. Having said all this, I think Mark now does offer a formal, paid support agreement. In fact, he's always fixed any problems I've had within hours or days - I wish HP gave that kind of response! Rob. ------------------------------ Date: Tue, 15 Jul 2008 08:25:10 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: RFC: Switching to WASD after 15 yrs with OSU... Message-ID: Rob wrote: > On Jul 13, 9:49 pm, Jan-Erik Söderholm > wrote: >> Hi. >> >> After 15 yrs with the OSU http server, I'm now >> thinking of switching to the WASD server instead. >> Mostly becuse the WASD server seem to be more >> actively developed and since JFP's (Jean-François >> PIÉRONNE) very nice Python distribution seems to >> have a closer connection and better integration >> with WASD then OSU. >> >> Now, is there any reason I should make this switch ? >> >> Bets regards, >> Jan-Erik. >> >> PS: Yes, I know about "secure web server" also, but >> I think both OSU and WASD are more VMS-ish then >> Apache... > > The one and only reason that I wouldn't (and couldn't) make WASD my > Production Web server was the lack of formal support. If Mark wasn't > around then things would get very problematic, despite the excellent > WASD support community. OK, so either worse or better then with OSU, right ? :-) > With CSWS we know we have a guaranteed response from HP, which is > something a large business has to have. If this isn't a problem, i.e. > you're not running a high availability Production system, then > certainly WASD is much better than Apache. No, not that important right now... Jan-Erik. ------------------------------ Date: Tue, 15 Jul 2008 06:55:24 -0700 From: "Tom Linden" Subject: Re: RFC: Switching to WASD after 15 yrs with OSU... Message-ID: On Tue, 15 Jul 2008 01:13:00 -0700, Rob wrote: > On Jul 13, 9:49 pm, Jan-Erik Söderholm > wrote: >> Hi. >> >> After 15 yrs with the OSU http server, I'm now >> thinking of switching to the WASD server instead. >> Mostly becuse the WASD server seem to be more >> actively developed and since JFP's (Jean-François >> PIÉRONNE) very nice Python distribution seems to >> have a closer connection and better integration >> with WASD then OSU. >> >> Now, is there any reason I should make this switch ? >> >> Bets regards, >> Jan-Erik. >> >> PS: Yes, I know about "secure web server" also, but >> I think both OSU and WASD are more VMS-ish then >> Apache... > > The one and only reason that I wouldn't (and couldn't) make WASD my > Production Web server was the lack of formal support. If Mark wasn't > around then things would get very problematic, despite the excellent > WASD support community. > > With CSWS we know we have a guaranteed response from HP, which is > something a large business has to have. If this isn't a problem, i.e. > you're not running a high availability Production system, then > certainly WASD is much better than Apache. > > Having said all this, I think Mark now does offer a formal, paid > support agreement. In fact, he's always fixed any problems I've had > within hours or days - I wish HP gave that kind of response! He has for several years and I happy to have been the recipient of his support. I think if you delve into it, your large company is better support on WASD than with HP, of course, being a brit you are more enured to the accent of the subcontinent. > > Rob. -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Tue, 15 Jul 2008 15:07:29 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Visio 2007 Prof and Rdb... Message-ID: Hi. I've also posted this to the JCC Rdb mailling list, but there might be someone here who aren't on that list. Full posting below. This was the second post to the list, that's why the first remark was done... I also forgot to mention : WinXP SP3 Professional. Visio Professional 2007 with SP1 patch. Latest Oracle Rdb ODBC driver (3.2) $ rmu/sh ver Executing RMU for Oracle Rdb V7.2-010 SQLSRV> show version; Version: V7.2-0 Best Regards, Jan-Erik. Hi again... I'm not sure that this made it to the list, but I'd like to add some info also... First I used Visio Prof to add a data source to ODBC. This made all table names corrupt (unprintable characters and sometimes (what looked like) chinese chars). The *number* of tables was correct, so I guess the connection as such worked. Then I switched to Excel/MS-Query. Using the same ODBC source as above, I got similar problems in Excel. When I added another data source using the tools in Excel, all worked OK in Excel and MS-Query. OK, so far so good... Now back to Visio... Problem now is that I can not see/find the data source I created in Excel when using the tools in Visio... So there am I stuck right now. I anyone have been successfully loading a Rdb database design into Visio, I'd be glad to hear how it was done. Jan-Erik. ------------------------------ End of INFO-VAX 2008.393 ************************