INFO-VAX Mon, 01 Dec 2008 Volume 2008 : Issue 641 Contents: Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Re: Date centre design Re: Good example of C and MACRO Re: Good example of C and MACRO Open Source Message Oriented Middleware on OpenVMS? Re: Open Source Message Oriented Middleware on OpenVMS? Re: Torrent Client for VMS Re: ucx Re: ucx Re: ucx Re: ucx Re: ucx Re: ucx Re: VMS SIG Tape released (last from me) Re: VMS, HP and the recession ---------------------------------------------------------------------- Date: Mon, 01 Dec 2008 01:49:02 GMT From: John Santos Subject: Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Message-ID: AEF wrote: > On Nov 28, 3:25 pm, Hein RMS van den Heuvel > wrote: > >>On Nov 28, 3:17 pm, hel... (Phillip Helbig--- >>remove CLOTHES to reply) wrote: >> >> >>>Question: since the error is >> >>> %SYSTEM-W-HEADERFULL, file header is full >> >>>how can I create it manually if AUTOGEN can't? >> >>Because Autogen has some temp file already created? >> >>HEADERFULL is a very explicit error there is no negotiaing with that. >> >> >>>When initialising disks, I'm always rather liberal with the /HEADERS >>>qualifier, so I don't think that's the problem. >> >>Don't think. >>Use DFU REPORT >>Also... /HEADER is a less critical value. >>/MAXIMUM_FILES is the one that really counts. > > > Not for this problem. Also, the default value for /MAXIMUM_FILES is > half of the maximum value allowed for the given drive anyway. > > The problem here is that INDEXF.SYS is so fragmented that its single- > block file header has run out of room for pointers to its own extents > (and that this header is required to be only one block in size). > > >>>How can I solve this problem? > > > If manually creating the dump file doesn't work, you will have to > reduce the number of file headers in use (by deleting files) so that > they become available for new files. The best solution is to back up > the disk to tape and restore from tape or back up the drive to another > drive and use that drive. I don't think you'll ever get this problem > on this disk again if you do that. > > >>That will depend on what the problem is. >>You may be able to clean out some files for now, >>but you may well need to re-init a disk with /MAX='more' and $BACKUP/ >>NOINIT/IMAGE ... > > > Upping /MAXIMUM_FILES will not help. Simply using BACKUP to move the > drive's data to tape and back or to another disk will keep you going > for quite a while. In the 1990's I found that when you reach about > 50000 files (or file headers), you will fill up the header for > INDEXF.SYS, after which I never had the same problem again (on the > given disk, of course). However, the extension algorithm for > INDEXF.SYS has been greatly improved since then to avoid this very > problem, but there has been at least one buggy version (which cause me > a problem once!). Either your disk is severely fragmented or you have > a buggy version of the algorithm. "Repack" the disk and all will be > well. > > (You could help things even more by estimating the total number of > extents you will ever have on the disk and set /HEADERS to that, but > with the new extension algorithm this may not matter much at all.) > > >>hth, >>Hein. > > > AEF The best solution, as Alan and others have suggested, is to use backup to copy the disk (or backup/restore) in order to reduce all files to a single header and make the free space contiguous so that indexf.sys can be extended. Initializing the new disk with appropriate values for /header and /maximum_files would improve this but probably isn't essential. Changing the clustersize *might* also help, but for a system disk the default is probably fine. However, short of that, a disk defragger *might* free up enough headers to solve the immediate problem, by releasing extension headers currently used by badly fragmented files. This has the virtue of no down time. OTOH, it is really only a temporary fix. IIRC, you have a hobbyist system, and the HP defragger (aka "Disk File Optimizer") is included in the hobbyist license PAKs (product is DFG.) I think the Raxco defragger is also available under a hobbyist license, but haven't used that in many years, so someone more familiar with it might jump in. (DSPP also includes the DFG license.) HTH. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: Mon, 1 Dec 2008 05:53:43 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Message-ID: In article , John Santos writes: > The best solution, as Alan and others have suggested, is to use > backup to copy the disk (or backup/restore) in order to reduce all > files to a single header and make the free space contiguous so > that indexf.sys can be extended. OK. I don't think it's INDEXF.SYS, but nevertheless a backup is a good idea, since the disk is rather fragmented. BACKUP/IMAGE. /ALIAS or /NOALIAS? The backup will be done from an ALPHA running VMS 7.3-2. (I mention that since the HELP is different there and on 7.3 VAX.) The HELP is confusing. On 7.3-2 it says a) use /ALIAS only when RESTORING (my emphasis) very old save sets and that in almost all other cases the default is OK---but the default (according to HELP) is /ALIAS. (7.3 recommends /NOALIAS for BACKUP/IMAGE.) ------------------------------ Date: Sun, 30 Nov 2008 20:10:34 +0100 From: "Gorazd Kikelj" Subject: Re: Date centre design Message-ID: "JF Mezei" wrote in message news:00221b1a$0$9201$c3e8da3@news.astraweb.com... > If you foresee the need to redesign your data centre in the near future, > you may wish to look at the following: > > http://royal.pingdom.com/2008/11/14/the-worlds-most-super-designed-data-center-fit-for-a-james-bond-villain/ > > The architect's web page: > > http://www.archdaily.com/9257/pionen-%E2%80%93-white-mountain-albert-france-lanord-architects/\ > > > The actual data centre (colocation business) > > http://www.bahnhof.se/colocation.php (swedish only). > > Here is a good demo how about cooling problems in data centers. http://h20219.www2.hp.com/services/library/GetPage.aspx?pageid=599739&statusid=0&audienceid=0&ccid=225&langid=121 Best, Gorazd ------------------------------ Date: 30 Nov 08 18:40:06 EST From: cook@wvnvms.wvnet.edu (George Cook) Subject: Re: Good example of C and MACRO Message-ID: In article <176uZD2KcidF-pn2-o3F974HdWwBP@rikki.tavi.co.uk>, "Bob Eager" writes: > On Sun, 30 Nov 2008 14:16:04 UTC, moroney@world.std.spaamtrap.com > (Michael Moroney) wrote: > >> =?ISO-8859-1?Q?Arne_Vajh=F8j?= writes: >> >> >Richard B. Gilbert wrote: >> >> >> A six bit >> >> code is sufficient to give you the alphabet, the decimal digits, and >> >> common punctuation with a few characters left over. >> >> > > It's not clear to me that there is any point in packing six characters >> > > into a "REAL*4". >> >> >There are not room for 6 codes of 6 bit in 4 byte either. >> >> >That only gives 5.33 bit per character. >> >> RAD50 gives a character set of 40 characters (50 octal). That's the >> letters A-Z uppercase, digits 0-9, space, two other punctuation characters >> and one code which I think was never defined. I believe this is how PDP-11 >> operating systems stored file names (a 6.3 name with an implicit period >> could be stored as 3 words/6 bytes). > > I said there'd be a pedant along in a minute! Arne is being the pedant - > saying that it's not ASCII without a full character set... > > Yes, I know that RT-11 and DOS/BATCH (who remembers DOS/BATCH?) stored > filenames in RAD50. And I think MACRO-11 stored symbols like that. I still have my DOS/BATCH handbook. It's from my first major paid programming assignment which was to add RK07 drive support to DOS/BATCH. It was actually a pretty neat little OS. George Cook WVNET ------------------------------ Date: 1 Dec 2008 00:03:49 GMT From: "Bob Eager" Subject: Re: Good example of C and MACRO Message-ID: <176uZD2KcidF-pn2-TceOd4IbVzde@rikki.tavi.co.uk> On Sun, 30 Nov 2008 18:40:06 UTC, cook@wvnvms.wvnet.edu (George Cook) wrote: > In article <176uZD2KcidF-pn2-o3F974HdWwBP@rikki.tavi.co.uk>, "Bob Eager" writes: > > On Sun, 30 Nov 2008 14:16:04 UTC, moroney@world.std.spaamtrap.com > > (Michael Moroney) wrote: > > > >> =?ISO-8859-1?Q?Arne_Vajh=F8j?= writes: > >> > >> >Richard B. Gilbert wrote: > >> > >> >> A six bit > >> >> code is sufficient to give you the alphabet, the decimal digits, and > >> >> common punctuation with a few characters left over. > >> > >> > > It's not clear to me that there is any point in packing six characters > >> > > into a "REAL*4". > >> > >> >There are not room for 6 codes of 6 bit in 4 byte either. > >> > >> >That only gives 5.33 bit per character. > >> > >> RAD50 gives a character set of 40 characters (50 octal). That's the > >> letters A-Z uppercase, digits 0-9, space, two other punctuation characters > >> and one code which I think was never defined. I believe this is how PDP-11 > >> operating systems stored file names (a 6.3 name with an implicit period > >> could be stored as 3 words/6 bytes). > > > > I said there'd be a pedant along in a minute! Arne is being the pedant - > > saying that it's not ASCII without a full character set... > > > > Yes, I know that RT-11 and DOS/BATCH (who remembers DOS/BATCH?) stored > > filenames in RAD50. And I think MACRO-11 stored symbols like that. > > I still have my DOS/BATCH handbook. It's from my first major paid > programming assignment which was to add RK07 drive support to DOS/BATCH. > It was actually a pretty neat little OS. Incredibly small. 2K words resident, with masses of overlays at two levels. I remember having to fix a problem with it on RK05s...I think it wouldn't load stuff sometimes due to treating some field as signed when it should have been unsigned. I know we had a very bad printout of the source code. Anyway, I fixed it... -- Bob Eager Use the BIG mirror service in the UK: http://www.mirrorservice.org ------------------------------ Date: Sun, 30 Nov 2008 16:28:41 -0800 (PST) From: ja Subject: Open Source Message Oriented Middleware on OpenVMS? Message-ID: We would be interested to hear about people interested in the above subject and whether they would try out a port of the AMQP (www.amqp.org) specification to OpenVMS. Details on the port and availability of kits etc. may be found at www.johndapps.com, the BC&JA home page. The main reason for doing the port is the belief that software of this nature is missing on OpenVMS and that it provides an ideal solution to those looking for a standards-based, Open Source, solution to their messaging needs. We are doing this work on a completely voluntary basis in our free time and hope to engage with others who would be interested in working with us. Disclaimer: this work is not endorsed or supported by our employers and any opinions expressed are entirely our own. Cheers, John ------------------------------ Date: Mon, 01 Dec 2008 00:44:14 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: Open Source Message Oriented Middleware on OpenVMS? Message-ID: ja wrote: > We would be interested to hear about people interested in the above > subject and whether they would try out a port of the AMQP > (www.amqp.org) specification to OpenVMS. > Details on the port and availability of kits etc. may be found at > www.johndapps.com, the BC&JA home page. > > The main reason for doing the port is the belief that software of this > nature is missing on OpenVMS and that it provides an ideal solution to > those looking for a standards-based, Open Source, solution to their > messaging needs. > > We are doing this work on a completely voluntary basis in our free > time and hope to engage with others who would be interested in working > with us. > > Disclaimer: this work is not endorsed or supported by our employers > and any opinions expressed are entirely our own. > > Cheers, John OK, couldn't find any kit. Did I miss it ? ------------------------------ Date: Mon, 1 Dec 2008 00:45:47 -0600 (CST) From: sms@antinode.info (Steven M. Schweda) Subject: Re: Torrent Client for VMS Message-ID: <08120100454749_2020048A@antinode.info> From: davidpryce123@yahoo.com.au > Does anyone know of any torrent clients for VMS around? I know nothing, but a simple Google search found: http://a.scarywater.net/torrent/clients/ which lists a few with notes like "It runs on any platform Python runs on" or "It should run everywhere Python runs". Python's available on VMS, isn't it? > Are they open source? Would prefer not Java clients if possible. Apparently. There are some of those, too. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-info 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Sun, 30 Nov 2008 14:13:15 -0500 From: "Richard B. Gilbert" Subject: Re: ucx Message-ID: <1dSdnbEPOuYceK_UnZ2dnUVZ_q7inZ2d@giganews.com> Steven M. Schweda wrote: > From: "nierveze" > >> hello everyone,does tcpip5.2 support client dhcp? > > I don't know. (I don't use DHCP on any of my VMS systems.) > >> can it be upgraded from 5.1? > > Probably depends on your VMS version. > >> can it be installed on a vax with vms 7.2 or should I upgrade also vms >> to vms7.3 > > I don't know which TCPIP versions work with which VMS versions. The > TCPIP installation documents should say. I seem to have TCPIP V5.1 on > my VMS V7.3 system, but that may be only because TCPIP V5.1 is what was > on the VAX Hobbyist CD-ROM. Specifically, the Software Product Description should say which version(s) of VMS it works with. ------------------------------ Date: 30 Nov 2008 19:29:36 GMT From: "Bob Eager" Subject: Re: ucx Message-ID: <176uZD2KcidF-pn2-QP2ihsRfklxl@rikki.tavi.co.uk> On Sun, 30 Nov 2008 18:23:39 UTC, sms@antinode.info (Steven M. Schweda) wrote: > From: "nierveze" > > > hello everyone,does tcpip5.2 support client dhcp? > > I don't know. (I don't use DHCP on any of my VMS systems.) > > > can it be upgraded from 5.1? > > Probably depends on your VMS version. > > > can it be installed on a vax with vms 7.2 or should I upgrade also vms > > to vms7.3 > > I don't know which TCPIP versions work with which VMS versions. The > TCPIP installation documents should say. I seem to have TCPIP V5.1 on > my VMS V7.3 system, but that may be only because TCPIP V5.1 is what was > on the VAX Hobbyist CD-ROM. I'm using TCP/IP 5.1 on VMS 7.3. The SPD says it "needs 7.1 or 7.2" but I guess 7.3 is OK too! And I'm using client DHCP on it since I have a DHCP server... -- Bob Eager Use the BIG mirror service in the UK: http://www.mirrorservice.org ------------------------------ Date: Sun, 30 Nov 2008 13:40:54 -0600 (CST) From: sms@antinode.info (Steven M. Schweda) Subject: Re: ucx Message-ID: <08113013405462_2020048A@antinode.info> From: "Bob Eager" > I'm using TCP/IP 5.1 on VMS 7.3. The SPD says it "needs 7.1 or 7.2" but > I guess 7.3 is OK too! The problem is that when TCPIP V5.1 was released, they were unable (or unwilling) to predict all the future VMS versions with which it might work. This leads to SPD rot over time. Judging by: ftp://ftp.itrc.hp.com/openvms_patches/vax/V7.3/DEC-VAXVMS-TCPIP_ECO-V0503-184-4.txt one could also run TCPIP V5.3 on VMS (VAX) V7.3. This suggests that TCPIP V5.2 is likely to work on it, too. > And I'm using client DHCP on it since I have a DHCP server... I have a DHCP server (or two), too, but I find it easier to locate my systems by name when they have reliable (static) IP addresses. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-info 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Sun, 30 Nov 2008 22:02:42 +0100 From: "nierveze" Subject: Re: ucx Message-ID: <00c901c9532e$fedbf9c0$04000005@pc> hello everyone ,thanks all for your answer ,as I understand ucx 5.1provid= es dhcp client ,and can work on vms 7.2,so as my vax uses vms 7.2 and ucx 5.= 0 (both come from the hobbyist cdrom produced in 1999),I will not have to upgrade vms only ucx.Is anyone able to give me the pointer of ucx5.1 spd = ,I did not find it ,only 5.0 and on hp site ,I have found the spd of ucx 5.6 only.I'll buy the last hobbyist cdrom.Is the procedure to upgrade ucx similar to one to upgrade vms?I have never done an upgrade like this.= it it described somewhere?thanks again alain ----- Message d'origine ----- De : "Bob Eager" =C3=80 : Envoy=C3=A9 : dimanche 30 novembre 2008 20:29 Objet : Re: ucx > On Sun, 30 Nov 2008 18:23:39 UTC, sms@antinode.info (Steven M. Schweda) > wrote: > > > From: "nierveze" > > > > > hello everyone,does tcpip5.2 support client dhcp? > > > > I don't know. (I don't use DHCP on any of my VMS systems.) > > > > > can it be upgraded from 5.1? > > > > Probably depends on your VMS version. > > > > > can it be installed on a vax with vms 7.2 or should I upgrade also = vms > > > to vms7.3 > > > > I don't know which TCPIP versions work with which VMS versions. T= he > > TCPIP installation documents should say. I seem to have TCPIP V5.1 o= n > > my VMS V7.3 system, but that may be only because TCPIP V5.1 is what w= as > > on the VAX Hobbyist CD-ROM. > > I'm using TCP/IP 5.1 on VMS 7.3. The SPD says it "needs 7.1 or 7.2" but > I guess 7.3 is OK too! > > And I'm using client DHCP on it since I have a DHCP server... > -- > Bob Eager > Use the BIG mirror service in the UK: > http://www.mirrorservice.org > > ------------------------------ Date: 30 Nov 2008 21:05:38 GMT From: "Bob Eager" Subject: Re: ucx Message-ID: <176uZD2KcidF-pn2-g7MtZVR5HvPg@rikki.tavi.co.uk> On Sun, 30 Nov 2008 19:40:54 UTC, sms@antinode.info (Steven M. Schweda) wrote: > From: "Bob Eager" > > > I'm using TCP/IP 5.1 on VMS 7.3. The SPD says it "needs 7.1 or 7.2" but > > I guess 7.3 is OK too! > > The problem is that when TCPIP V5.1 was released, they were unable > (or unwilling) to predict all the future VMS versions with which it > might work. This leads to SPD rot over time. > > Judging by: > ftp://ftp.itrc.hp.com/openvms_patches/vax/V7.3/DEC-VAXVMS-TCPIP_ECO-V0503-184-4.txt > > one could also run TCPIP V5.3 on VMS (VAX) V7.3. This suggests that > TCPIP V5.2 is likely to work on it, too. > > > And I'm using client DHCP on it since I have a DHCP server... > > I have a DHCP server (or two), too, but I find it easier to locate my > systems by name when they have reliable (static) IP addresses. (or two? hope they are synchronised...) Actually, what I said isn't incompatible with the above. My DHCP server hands out fixed IP addresses on indefinite leases - it just makes maintenance easier. The addresses are locked to MAC addresses. And all of my IP addresses are public ones, since my ISP gives me as many as I want. So all addresses are reliable and predictable. -- Bob Eager Use the BIG mirror service in the UK: http://www.mirrorservice.org ------------------------------ Date: Sun, 30 Nov 2008 22:47:28 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: ucx Message-ID: In article <08113013405462_2020048A@antinode.info>, sms@antinode.info (Steven M. Schweda) writes: > Judging by: > > ftp://ftp.itrc.hp.com/openvms_patches/vax/V7.3/DEC-VAXVMS-TCPIP_ECO-V0503-184-4.txt > > one could also run TCPIP V5.3 on VMS (VAX) V7.3. This suggests that > TCPIP V5.2 is likely to work on it, too. Definitely possible; I've been doing it for years. ------------------------------ Date: Sun, 30 Nov 2008 20:04:12 -0500 From: glenn everhart Subject: Re: VMS SIG Tape released (last from me) Message-ID: IanMiller wrote: > Glenn, > thank for all your work with the tapes over the decades, > > Do you know if this collection will appear on mvb.saic,com ? Likely. Mark Berryman got a blank cd I must have sent by mistake so I sent him another, plus the material on DVD. If that does not make it I will keep trying, but the CDs I sent were all verified after writing, unless I also accidentally grabbed a blank somewhere... ------------------------------ Date: Sun, 30 Nov 2008 12:54:02 -0700 From: "Michael D. Ober" Subject: Re: VMS, HP and the recession Message-ID: "Main, Kerry" wrote in message news:9D02E14BC0A2AE43A5D16A4CD8EC5A593EDA7A2C98@GVW1158EXB.americas.hpqcorp.net... > -----Original Message----- > From: steel_and_alum_engr [mailto:middie1975@gmail.com] > Sent: November 22, 2008 10:09 AM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: VMS, HP and the recession > > On Nov 20, 8:31 am, "Main, Kerry" wrote: > > .. snip ... > > > VMware (and other OS virt technologies) certainly have a place, but > are a > > temporary solution that saves some $'s related to space, maint and > other > > HW type things, but that is only a small part of the overall IT > budget. > > Temporary solution? You're entitled to that opinion, but I couldn't > disagree more. > In our company's case, using VMware's ESX server software, we've > collapsed over 100 servers to less than 10 physical boxes. > Aside from the huge benefit of maintaining far fewer hardware > platforms, the real benefit to us was improved disaster recovery. > And, the "V-motion" technology, allowing VMs to transparently (on the > fly) move from one server to another, is very nice. > We've been running both Microsoft and Linux servers in this > environment for a couple of years now, and it's paying large > dividends. > While one can not paint every Cust with the same brush, let me see if the following is true of your environment: 1. You have more OS instances today than you did before you started with VMware. Likely quite a few more. Especially in Dev/QA 2. While the HW, DC space and electrical costs have decreased, your staffing has not decreased and in fact, may have increased to support the additional OS instances. 3. Your App license costs have increased to cover the additional instances Of the various third party and support products required. 4. Once a VM is created, it almost never gets taken down or reclaimed once its primary reason for creation goes away. I will bet that at least 3 out of the 4 points are true in your shop. > > Unfortunately after implementing OS virtualizing technologies like > VMware, > > many Cust's end up with many more OS's to manage than they had before > i.e. > > if you thought x86 servers used to populate like rabbits, wait until > you > > see how fast VM's populate. > > Your VM rabbit analogy might be true in some settings, but that is not > our experience. > I've heard some say that it's "too easy" to create new virtual > machines, and that might be correct. However, I'd rather something > be "too easy" than so difficult that it doesn't happen. No question > that it's very simple to create/clone a virtual machine. We use this > to our advantage for offline testing, OS and/or application version > upgrades, etc. Much easier to create a VM than to buy/find an unused > hardware box and start from scratch. Virtualization absolutely has benefits. No question about it. Unfortunately, it does not reduce staffing and in most cases, App sw licensing costs. Due to the ease of creating VM's, both of these costs will likely increase. And since IT staffing is usually 60-70% of most IT budgets, virtualization does not address the 800lb gorilla of most IT budgets when it comes to reducing overall IT costs. Now, what will your CIO's answer be when the CEO asks "its great that you have now completed most of the virtualization you had planned, but now tell me how you plan to further reduce IT costs by an additional 15% next year." Imho, VM consolidation with a focus on IT staffing and overall license costs reduction is going to be the "next big thing". And that's when the real tough decisions are going to have to be made. Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-254-8911 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT) OpenVMS - the secure, multi-site OS that just works. Kerry, You're dead on with your analysis. Having gone down the VMWare route, we definitely have more servers than we used to. Virtual machine technology definitely increases the complexity of a network - not only do you have to track which applications are on which servers, but you now must track which servers are hosted on which physical boxes and in many cases, where the virtual disk files are stored as well. Mike Ober. ------------------------------ End of INFO-VAX 2008.641 ************************