INFO-VAX Sat, 30 Jun 2007 Volume 2007 : Issue 354 Contents: Re: expanding shadow size Re: gSOAP on OpenVMS? VMS as Web Service *client* RE: OpenVMS - When downtime is not an option Re: Question on FCS vs RMS on PDP11 RSX SIMH networking Re: SIMH networking Re: SIMH networking Re: SIMH networking Re: SIMH networking Re: SIMH networking Re: SIMH networking ---------------------------------------------------------------------- Date: Sat, 30 Jun 2007 03:36:41 -0700 From: Bob Gezelter Subject: Re: expanding shadow size Message-ID: <1183199801.985587.130670@n2g2000hse.googlegroups.com> On Jun 29, 8:55 pm, David J Dachtera wrote: > "Klaus-D. Bohn" wrote: > > > Hello all together, > > > I have an existing problem with a shadow disk. I would like to increase the > > shadow size without to dismount all the shadow members. > > [snip] > > What must i do to get the full volume size 17773524? > > As Hoff pointed out, can't be done without downtime. > > You'll need to negotiate a scheduled downtime with your customer. Be sure to > explain that this is necessary if they want to realize the desired benefit. > > -- > David J Dachtera > dba DJE Systemshttp://www.djesys.com/ > > Unofficial OpenVMS Marketing Home Pagehttp://www.djesys.com/vms/market/ > > Unofficial Affordable OpenVMS Home Page:http://www.djesys.com/vms/soho/ > > Unofficial OpenVMS-IA32 Home Page:http://www.djesys.com/vms/ia32/ > > Unofficial OpenVMS Hobbyist Support Page:http://www.djesys.com/vms/support/ David, A small note on the comment about downtime. If all that is needed is the SET VOLUME/LIMIT command, it is almost wrong to call it downtime. Planned properly (and executed with a command file) the downtime is limited to the availability of that volume for a matter of seconds. It will take longer to restart those applications that cannot quiesce and reacquire a file than it will take to do the actual change. It is, in my experience, far shorter than even a reboot (and if this is a data disk and not involved in the actual running of the cluster) will not be needed. It is true that even such a "blip" is a downtime, and needs to be handled appropriately, but there is a large difference between such a "blip" and a multi-hour downtime. Indeed, depending on what data is involved, it may not even meet the organization's definition of critical information, at least on the scale of a few minutes. Just my US$ 0.02 to ensure a clean record of the discussion. - Bob Gezelter, http://www.rlgsc.com ------------------------------ Date: Sat, 30 Jun 2007 08:28:00 -0700 From: Bob Gezelter Subject: Re: gSOAP on OpenVMS? VMS as Web Service *client* Message-ID: <1183217280.021384.54610@q69g2000hsb.googlegroups.com> On Jun 29, 10:24 am, ja wrote: > On Jun 27, 11:13 pm, Malcolm Dunnett > wrote: > > > > > Gorazd Kikelj wrote: > > > "ja" wrote in message > > >news:1182887137.550244.102170@o11g2000prd.googlegroups.com... > > >> How many people would be interested in running gSOAP on OpenVMS, Alpha > > >> or Integrity? > > >> Of those, how many would want to: > > > >> 1. use OpenVMS as a Web Service client from any native language > > >> 2. use OpenVMS as a Web Service server from any native language > > >> 3. both of the above > > > > this sounds intriguing. I could certanly use 3. Do this now by hand in cobol > > > and with perl. This sounds very promissing. > > > Same here. I currently do SOAP client using perl on VMS (Alpha and > > soon to be Itanium). I would be very interested in being able > > to do this directly from a BASIC program. > > > I'm not familiar with the features of gSOAP, does it give > > you a nice simple way to call a web service by parsing the WSDL? > > gSOAP is a full-blown implementation of SOAP and WSDL. So, yes, it > does provide a WSDL describing the routine you have wrapped and are > exposing to clients. The same is true in reverse, i.e., it will > process the WSDL from any source to which you have access. John, It is likely to be of interest. It is also important that the packaging be in line with system conventions. In the case of gSOAP, there is the question of how to package things in a useful form for most developers. Having some familiarity with those products, it is also desirable that the kit (or at least a version of it) be usable without installation by the system manager. Offhand, I do not see a reason why (at least for the outgoing scenario) there is a need for system wide installation. It would also make it easier for potential adopters to experiment. - Bob Gezelter, http://www.rlgsc.com ------------------------------ Date: Sat, 30 Jun 2007 10:26:27 -0400 From: "Main, Kerry" Subject: RE: OpenVMS - When downtime is not an option Message-ID: > -----Original Message----- > From: bill@triangle.cs.uofs.edu [mailto:bill@triangle.cs.uofs.edu] On > Behalf Of Bill Gunshannon > Sent: June 29, 2007 3:07 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: OpenVMS - When downtime is not an option >=20 > In article , > koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > > In article <5ekdm1F38esk5U1@mid.individual.net>, bill@cs.uofs.edu > (Bill Gunshannon) writes: > >> > >> And that is a management problem and not a Windows problem. > Management > >> should mandate who can do what on any machine and what is not to be > done > >> on a server. > > > > Management mandates are not a good tool for overcoming poor > quality. > > Management may mandate no surfing from the server console, but > that > > won't stop it from happening. >=20 > It will if you counsel him the first time and fire him the second > time. :-) >=20 [snip ...] Bill, As I alluded to earlier, if you are mandating that browsers not be used from servers, then with all due respect, you really do not understand med-large DC and server environment management.=20 You need to understand that many of today's server management tools and utilities have browser interfaces. Which typically means servers require things like IIS, Apache or some other web server running. So right away, all those IIS/IE issues need to be considered as potentially serious server issues. And while you can argue all you want about "real sysadmins use command line, cryptic commands with exciting qualifiers", that is simply not how modern day DC's are managed and/or monitored on a large scale - especially in the Windows space. Heck, even large SAN environments today use Windows or Web based based mgmt interfaces to Mgmt appliances and have NO access to the console because there often is none. > > > > Poor quality in Microsoft's product is a Microsoft problem and a > > problem for each of thier products, the only fault on the part of > > management is failing to block its use. >=20 > Bull crap. Just because some people have an axe to grind doesn't mean > the fault is all MS's. The products have come a long way (as have > other > products, like Linux). They can be used securely and efficiently and > they > can be made stable. And, that is the job of the sys admin. Otherwise, > why have them? Why not just let the secretary do it? What's that old > adage about a workman and his tools? >=20 > Just how secure would a VMS system be if the sys admin just turned on > all > the ports and services, needed or not. The SYSTEM account had no > password. > And everyone who used the machine just logged in as SYSTEM anyway. > You > would never consider running a VMS system like this, so why accept it > with Windows and then blame MS for the problems? >=20 > bill Both of the Bill's are missing the point. Again, with all due respect, both of you do not appear to have any real experience in med to large DC operations. Let me explain the typical medium DC environment.=20 [Large ones simply take what follows and multiply x 5-10 times. One large US Customer bank server consolidation external RFP stated they had 10K servers WW of which 70-80% were Wintel based (they had no idea if that was real or not since it was a SWAG which was part of the reason for the RFP. The other reason was that they estimated that average peak utilization of those 8K Wintel servers was less than 20%)] Again, assume well managed Windows (Linux), UNIX and OpenVMS servers are the baseline. Cust has trained their staff well in terms of secure processes like disclosing sensitive information over the phone etc. Fine, no issue here. In this environment, there are likely something like 200-400 applications and/or utilities running of varying importance and significance. Before patches are rolled out, they are tested against the important applications.=20 That's the baseline. A single typical medium DC has say 300-500 servers of which about 60-70% (approx 200-400) are Wintel/Linux based. For discussion, lets assume 300. That means about 200+ Wintel based. About 25% (50) of these will be IT infrastructure/operations based so IT OPS has a good feel for what is running on these. That leaves 150+ prod/dev/test Wintel App/DB servers.=20 That's also part of the baseline. Most IT operations staff have little to no understanding of what the applications running on the 150 Wintel/Linux App servers require in terms of things like ActiveX, COM, LDAP, Apache, IIS, what services are running and/or not running. Also, remember that dev/test environments are run by many different App groups who freely install whatever they want. For prod environments, IT Operations simply follow vendor or App provided instructions for installing new software (click set-up.exe and answer default questions) in prod environments. That's also part of the baseline. Now. Introduce 5-20 well documented security issues each and every month for Windows and Linux. Also, keep in mind that most security analysts state that 50-60% of all security issues are internally initiated. Some are inadvertently caused via Trojans, worms on laptops, PDA's, memory sticks, cell phones etc looking for known holes and that regularly travel to and from external networks. So, what is the real cost to an organization like this that now needs to test their important app's against a subset of these monthly security patches? [which really means little as an App test is an App test regardless of 1 or 20 patches applied] And please do not say the IT OPS should have a detailed understanding of what is running on every server because while in theory that might be true in Wonderland, the reality is that they are all under staffed and just trying to keep their nose above water with day to day support issues - let alone planning monthly testing of applications and patch deployments across all these servers because of these monthly Windows/Linux security patches. So, now you see the difference in terms the impact and costs of 1 or 2 security patches every couple of years for OpenVMS vs. 5-20 released *each and every* month for Windows/Linux. And so, yes, regardless of the initial costs, long term OS platform quality really does mean a big difference to the organization. This is likely the issue facing medium to large companies today - one of the true "hidden" reasons why IT costs are so high today as compared to the past. 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: Sat, 30 Jun 2007 08:21:09 -0700 From: Bob Gezelter Subject: Re: Question on FCS vs RMS on PDP11 RSX Message-ID: <1183216869.687703.48040@g4g2000hsf.googlegroups.com> On Jun 29, 8:09 pm, Jeff Cameron wrote: > On 6/28/07 7:37 PM, in article 46846fdf$0$3177$4c368...@roadrunner.com, "LeeK. Gleason" wrote: > > What exactly are you contemplating doing to these files? Just > copying them? > > Yes, just FTP access. We want to make sure that moving the files off the > PDP-11 and then moving them back, they will retain their format and > readability. The file types are of two basic formats. Normal sequential text > files and unformatted direct access binary files. > > If The TCPWare stack uses RMS, wont that pose a problem running on a system > that does not have RMS SYSGENed in? > > Jeff Cameron > > > > > "Jeff Cameron" wrote in message > >news:C2A9A972.29221%roktsci@ca.rr.com... > >> I would like some clarification on FCS (File Control Services) and RMS > >> (Record Management System) in RSX 11M+ for the PDP-11. > > >> I have been told by one of the original MACRO-11 developers for our PDP-11 > >> system that our file system on the RSX systems only supports FCS files and > >> not RMS files. While I fully understand that support for RMS files is a > >> Sysgen option, I don't believe that the files are either in FCS format or > >> RMS format. I had always thought that FCS was a set of basic file control > >> services for manipulating, reading and writing files in RSX, and NOT a > > file > >> format. Further more, I was under the impression that RMS record > > management > >> was layered on top of FCS. > > >> Our old Macro developer was quite vehement that the format of the two > > types > >> of files are very different, specifically the file headers. This seemed > > very > >> wrong to me since the format of file headers are a Files-11 volume > >> attribute. > > >> Now this macro developer is an older man who is not to familiar with newer > >> technologies, who often replies with "It is not true just because you want > >> it to be true." for things I already know to be true. For example we had > >> quite an argument concerning file headers on a Files-11 disk (even ODS1 > > for > >> RSX); It was my position that the actual header information was stored in > >> the volume index file, while he insisted that it was actually a reserved > >> block at the beginning of the physical file. > > >> So, if any of you have any information concerning the FCS/RMS issue, if > > you > >> could site some resource, it would be extremely valuable. > > >> The point of contention is that I am considering using the Process > > Software > >> TCP Stack, TCPWare. The TCPWare SPD says it supports RMS files, but says > >> nothing about FCS, and our developer says it will not work because our > > files > >> are all FCS format. I need irrefutable evidence that it will work, since > > he > >> is the roadblock to my proceeding with this plan. > > >> Jeff Cameron > > > The format of FCS and RMS sequential files, very compatible. FCS can open, > > read and write an RMS sequential file just fine, and vice versa. RMS Indexed > > and Relative files, not so compatible with FCS routines - I don't know if > > it's still true, but there was a time when simply opening and closing an RMS > > indexed file with FCS routines was enough to corrupt it beyond use. Even if > > opening and closing doesn;'t destroy them anymore, you certainly won't be > > reading and writing them with any useful results from FCs code. But, you're > > going the other way, FCS files manipulated by RMS code. > > > RMS is not layered on top of FCS - both of them do their own QIOs to read > > and write blocks. > > > However, I'm thinking, in regards to your question, that the Process > > Sotware stack, since it uses RMS, should be able to handle FCS created files > > just fine. What exactly are you contemplating doing to these files? Just > > copying them? Reading and writing records/blocks? Access via NFS? Given a > > little more detail, we might be able to come closer to a definitive answer. > > -- > > Lee K. Gleason N5ZMR > > Control-G Consultants > > lglea...@houston.rr.com Jeff, I would have to refresh my recollection of what, if anything the RMS questions during SYSGEN actually do. It is not outside the realm of possibility, that the question only represents guaranteeing certain other configuration items, and the copying of some files from the kit (unlike OpenVMS, the RSX-11 SYSGEN was very conscious of disk space consumption; if a file was not needed, it was not copied). Of course, this would have to be verified. Additionally, even if there are changes, a full SYSGEN might not be needed. Having spent quite a few years doing systems level work (including drivers) on RSX, I remember well how many things were documented as "do a SYSGEN" but in actuality did not require anything so drastic. - Bob Gezelter, http://www.rlgsc.com ------------------------------ Date: Sat, 30 Jun 2007 04:19:18 -0700 From: sampsal@gmail.com Subject: SIMH networking Message-ID: <1183202358.161191.144550@m36g2000hse.googlegroups.com> Hi, I've recently started playing around with VMS (7.3-1) on SIMH (version 3.7-1 from DarwinPorts) on my OS X box (Core Duo iMac, OS X Server v10.4.10). The network is set up as follows: - The iMac has the IP address 192.168.77.202 and is running a bunch of services (DNS and SSH etc) - The SIMH VAX machine is configured to use 192.168.77.211 - There's a CISCO PIX 501 firewall/router at 192.168.77.1 that is connected to the outside world The problem is that the VAX can talk to ANY other machine on both the 192.168.77.* network as well as the outside world just fine EXCEPT for the hosting OS X box. That is, I can ping the PIX from the VAX and vice versa, but not the iMac from the VAX or the VAX from the iMac. Any ideas? Sampsa ------------------------------ Date: Sat, 30 Jun 2007 06:35:32 -0700 From: "Tom Linden" Subject: Re: SIMH networking Message-ID: On Sat, 30 Jun 2007 04:19:18 -0700, wrote: > Hi, > > I've recently started playing around with VMS (7.3-1) on SIMH (version > 3.7-1 from DarwinPorts) on my OS X box (Core Duo iMac, OS X Server > v10.4.10). I think you must have meant 7.3. What do you see when you type $ TCPIP ifconfig ze0 ? If it isn't ze0 type $ tcpip sho int > > The network is set up as follows: > > - The iMac has the IP address 192.168.77.202 and is running a bunch of > services (DNS and SSH etc) > - The SIMH VAX machine is configured to use 192.168.77.211 > - There's a CISCO PIX 501 firewall/router at 192.168.77.1 that is > connected to the outside world > > The problem is that the VAX can talk to ANY other machine on both the > 192.168.77.* network as well as the outside world just fine EXCEPT for > the hosting OS X box. That is, I can ping the PIX from the VAX and > vice versa, but not the iMac from the VAX or the VAX from the iMac. > > Any ideas? > > Sampsa > -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Sat, 30 Jun 2007 06:53:04 -0700 From: sampsal@gmail.com Subject: Re: SIMH networking Message-ID: <1183211584.723876.45800@o61g2000hsh.googlegroups.com> > I think you must have meant 7.3. What do you see when you type > $ TCPIP ifconfig ze0 ? > > If it isn't ze0 type > $ tcpip sho int I did actually mean 3.7-1; that's the SIMH version, the VMS version is 7.3-1. Anyway, the TCP/IP stuff SEEMS to be correctly configured, here's SHOW INTEFACES: ==== SNIP ==== TCPIP> show int Packets Interface IP_Addr Network mask Receive Send MTU LO0 127.0.0.1 255.0.0.0 0 0 4096 QE0 192.168.77.211 255.255.255.0 12047 26 1500 ==== SNIP ==== DNS resolution and routing to the outside seems to work, viz: ==== SNIP ==== TCPIP> ping www.google.com PING www.l.google.com (64.233.183.104): 56 data bytes 64 bytes from 64.233.183.104: icmp_seq=0 ttl=245 time=50 ms ==== SNIP ==== And I can ping other machines on the local subnet (192.168.77.1 is the PIX 501 router/firewall): ==== SNIP ==== TCPIP> ping 192.168.77.1 PING 192.168.77.1 (192.168.77.1): 56 data bytes 64 bytes from 192.168.77.1: icmp_seq=0 ttl=255 time=10 ms ==== SNIP ==== However, when I try to ping the machine that the SIMH VAX emulator is running on, it doesn't get through: ==== SNIP ==== TCPIP> ping 192.168.77.202 PING 192.168.77.202 (192.168.77.202): 56 data bytes ----192.168.77.202 PING Statistics---- 4 packets transmitted, 0 packets received, 100% packet loss %SYSTEM-F-TIMEOUT, device timeout TCPIP> ==== SNIP ==== ------------------------------ Date: Sat, 30 Jun 2007 16:33:12 +0200 From: "Martin Vorlaender" Subject: Re: SIMH networking Message-ID: wrote: >> I think you must have meant 7.3. What do you see when you type >> $ TCPIP ifconfig ze0 ? >> >> If it isn't ze0 type >> $ tcpip sho int > I did actually mean 3.7-1; that's the SIMH version, the VMS version is > 7.3-1. I think Tom was right - the VMS version is most likely 7.3 (the last VMS VAX version there is). > Anyway, the TCP/IP stuff SEEMS to be correctly configured ... > DNS resolution and routing to the outside seems to work ... > And I can ping other machines on the local subnet ... > However, when I try to ping the machine that the SIMH VAX emulator is > running on, it doesn't get through: This is because of the libpcap used for network access. It only "sees" inbound packets (and filters those for the MAC address of the SIMH network interface), but it does not see outbound packets. For SIMH to be able to talk to its host system, you must - either use a second host network interface and create a loop - or create a loop using TUN/TAP interfaces in the host system. The latter approach is described e.g. at http://www.itsecuritygeek.com/index/itsgeek/comments/simh-networking/ No idea whether it works with MAC OS X. BTW, when using MS Windows: the OpenVPN project contains a TUN/TAP driver that can be used for that purpose; http://openvpn.net/ . HTH, Martin -- One OS to rule them all | Martin Vorlaender | OpenVMS rules! One OS to find them | work: mv@pdv-systeme.de One OS to bring them all | http://www.pdv-systeme.de/users/martinv/ And in the Darkness bind them.| home: martin.vorlaender@t-online.de ------------------------------ Date: Sat, 30 Jun 2007 11:27:16 -0400 From: JF Mezei Subject: Re: SIMH networking Message-ID: sampsal@gmail.com wrote: > The problem is that the VAX can talk to ANY other machine on both the > 192.168.77.* network as well as the outside world just fine EXCEPT for > the hosting OS X box. Think about ARP. The VAX instance would probably end up seeing the OSX instance has having the same ethernet address as itself and packets going nowhere. My untried and untested instinct would be add a route on both machine for its peer IP address to route via your router. eg: on the vax, you add a route for 192.168.77.202 to go via 192.168.77.1 on the imac, you add a route for 192.168.77.211 to go via 192.168.77.1 The router should bounce packets back to your LAN, at which point the packets will arrive on the physical macintosh and get routed internally to the right OS instance. Alternatively, if you can get a second ethernet card, then each instance would have its own ethernet address and simplify things. ------------------------------ Date: 30 Jun 2007 15:43:14 GMT From: bill@triangle.cs.uofs.edu (Bill Gunshannon) Subject: Re: SIMH networking Message-ID: <5enc0hF39di32U1@mid.individual.net> In article , JF Mezei writes: > sampsal@gmail.com wrote: >> The problem is that the VAX can talk to ANY other machine on both the >> 192.168.77.* network as well as the outside world just fine EXCEPT for >> the hosting OS X box. > > > Think about ARP. The VAX instance would probably end up seeing the OSX > instance has having the same ethernet address as itself and packets > going nowhere. > > My untried and untested instinct would be add a route on both machine > for its peer IP address to route via your router. > > eg: on the vax, you add a route for > 192.168.77.202 to go via 192.168.77.1 > > on the imac, you add a route for 192.168.77.211 to go via 192.168.77.1 > > The router should bounce packets back to your LAN, at which point the > packets will arrive on the physical macintosh and get routed internally > to the right OS instance. Only if it is a very broken router!!! bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Sat, 30 Jun 2007 12:41:50 -0400 From: JF Mezei Subject: Re: SIMH networking Message-ID: Bill Gunshannon wrote: > Only if it is a very broken router!!! Why. Router gets packet destined for subnet X, it routes it to the interface where subnet X is located. The fact that the packet arrives from the same interface shouldn't really matter shouldn't really matter. That is how I had gotten my old mac to talk to my psion via IP. psion was at 10.1.0.20 routed by VELO at 10.0.0.7 the router had a permanent route to 10.1.* via 10.0.0.7 the old mac didn't have the concept of routes, only a default gateway. So it sent the packet to the router and the router sent it back to 10.0.0.7. Oh, another possible way to deal with this would be to get your vax in a 10.*.*.* subnet. And have the router serve both the 192.168 and 10.* subnets. Nodes on the lan would have to go through the router to get to the vax. ------------------------------ End of INFO-VAX 2007.354 ************************