INFO-VAX Wed, 13 Feb 2008 Volume 2008 : Issue 88 Contents: Re: DIBOL to Re: Dilbert Does Virtualization Re: Multiple system disks and SAN Re: Multiple system disks and SAN Re: Multiple system disks and SAN Re: ODS5, /NAMES = AS_IS, LIBRARY, MMS v. me Re: ODS5, /NAMES = AS_IS, LIBRARY, MMS v. me Re: ODS5, /NAMES = AS_IS, LIBRARY, MMS v. me Re: The "World's First" MicroVAX II Museum is now Open Re: The "World's First" MicroVAX II Museum is now Open Re: Unusual mailbox status value Re: Unusual mailbox status value Re: Unusual mailbox status value VAX 7000 (was: DIBOL to Re: VEST (was: DIBOL to Re: VEST (was: DIBOL to Re: VEST (was: DIBOL to VMS Audio Update on your iPOD (or whatever player you have) Re: VMS license fees? Re: VMS license fees? Re: VMS license fees? Re: VMS license fees? Re: VMS license fees? RE: VMS license fees? Re: VMS license fees? Re: VMS license fees? VMS license fees? (was: DIBOL to Subject: Re: DIBOL to Message-ID: <95285ad2-9ac4-4042-9049-b1ad7fb654f4@d70g2000hsb.googlegroups.com> On Feb 12, 6:33 pm, Tad Winters wrote: > John Reagan wrote innews:fotat3$tf1$1@usenet01.boi.hp.com: > > > Bob Gezelter wrote: > > >> For porting, it depends on the style of code. If you want > >> integrated (non-custom) support for access to indexed and other > >> files, you are probably limited to BASIC, FORTRAN, and COBOL. It is > >> not inherantly difficult to access keyed files from C/C++, but it > >> will be in the nature of a non-integrated add-in (or in the case of > >> C++, probably a class). > > > Not to divert the topic, but Pascal has just as good support for > > indexed and relative files as the langauges listed above. Well, you > > can't CREATE a file with segmented keys from Pascal without > > resorting to a USERACTION routine, but you can open an existing file > > and even use FINDK to lookup a record. > > It seems like DIBOL was quite a good language. Why did Digital drop it > with the move to Alpha? To echo Hank Vander Waal, DBL is DIBOL for the post-VAX era. At the time of the Alpha port, Synergex (or was it still DISC then?) had extended DBL to a higher level, while still keeping DIBOL compatibility, and they were going to port DBL to Alpha anyway. DEC likely decided that their own resources would be better utilized in other areas. Someone only familiar with DEC DIBOL should not harshly judge Synery/ DE (the modern name) by that standard any more than someone who hasn't used VMS since early VAX should prejudge todays VMS by that experience. Beyond setting up the user environment as needed with any platform change, moving from DIBOL to the Synergy product on VMS usually involves little more than compile, rebuild your libraries and link your apps. Then, you can play with all of the fancy new stuff (Synergex offers training, too.) We still have some apps running today that started life on CTS-300/500, then met DBL on TSX+, and moved to VAX and Alpha with little more effort than that. And, don't overlook the DIBOL features you take for granted, like the built-in understanding and support of RMS records/files and the convenience of the Message Manager, that you'll need to "bolt-on" to most other languages. Like HVW said, too, DBL can move to non-VMS platforms easier than most languages. If your stuff is overly hard-coded with VMS specifics then that would be a handicap for other languages, too. But, even if it is, DBL might have a built-in subroutine or function that you could use instead without having to reinvent your own or find a third-party substitute. On non-RMS platforms, DBL has a built-in file/record system that to the programmer looks pretty much like RMS (even has RFA's.) We ported an entire accounting system to Windows in only a few weeks. All of the data files were stripped to sequential, copied over, and we used their utilities to reload them. The first time we did this we were amazed at how easy it was. It isn't 100% simple, but it's 99.99% easier than converting that much code to any other language I know of. Porting everything to a new language sounds like a programmers idea of fun, but what's it really going to cost the business? ------------------------------ Date: Wed, 13 Feb 2008 19:00:42 +0100 From: Wilm Boerhout Subject: Re: Dilbert Does Virtualization Message-ID: <47b3305a$0$25473$ba620dc5@text.nova.planet.nl> on 12-2-2008 14:48 Larry Kilgallen wrote... > http://www.dilbert.com/comics/dilbert/archive/images/dilbert20183362080212.gif I have already included it in one of my presentations! -- Wilm Boerhout Zwolle, NL remove OLD PAINT from return address to reply ------------------------------ Date: Wed, 13 Feb 2008 02:25:59 -0800 (PST) From: etmsreec@yahoo.co.uk Subject: Re: Multiple system disks and SAN Message-ID: <462b9d16-b3c8-48b2-9567-12ac6e18cfff@d21g2000prf.googlegroups.com> On 12 Feb, 20:28, Malcolm Smeaton wrote: > We have Alpha and Integrity servers sharing the same cluster but using > different system disks. However they share the same authorization files > .e.g. > > $ define/system/exec sysuaf > dsa100:[vms$common.sysexe]sysuaf.dat > > $ define/system/exec rightslist > dsa100:[vms$common.sysexe]rightslist.dat > > $ define/system/exec qman$master =A0 =A0 =A0 =A0 =A0dsa100:[vms$common.sys= exe] > > $ define/system/exec vmsmail_profile > dsa100:[vms$common.sysexe]vmsmail_profile.data > > $ define/system/exec netproxy > dsa100:[vms$common.sysexe]netproxy.dat > > $ define/system/exec net$proxy > dsa100:[vms$common.sysexe]net$proxy.dat > > $ define/system/exec vms$objects > dsa100:[vms$common.sysexe]vms$objects.dat > > $ define/system/exec vms$audit_server > dsa100:[vms$common.sysmgr]vms$audit_server.dat > > $ define/system/exec vms$password_history > dsa100:[vms$common.sysexe]vms$password_history.data > > Integrity is running on VMS 8.3 and Alpha is running on VMS 7.3-2. > > I want to upgrade Integrity to VMS 8.3-1H1 first and then Alpha to VMS > 8.3. I can't quite upgrade the Alpha systems yet because of some legacy > applications which we are in the process of decommissioning. > > The shared cluster files are currently on the Alpha system disk, dsa100: > which is on a RAID 7000 StorageWorks disk array. > > At the moment the integrity system disk is locally attached to a rx3600 > server, $10$dka0: We have since purchased a rx2660 itanium server so I > want to copy the integrity system disk to a disk called $1$DGA12 on our > EVA5000 SAN and then upgrade the new system disk to VMS 8.3-1H1. During > this period I want to keep the Alpha systems running because we have > important 24x7 applications on it. > > QUESTION 1: > > The VMS 8.3-1H1 Upgrade and Installation Manual Section 4.5.5 tells me I > need to move the authorization files to the new system disk before I do > the upgrade and then move them back to their original location after the > upgrade. I have some problems with this. > > 1. =A0 =A0These files, particularly sysuaf.dat, rightslist.dat, > vmsmail_profile.data are changing all the time due to password changes > and because we use VMS for our usercode management system accounts come > and go. > > 2. =A0 =A0I do not feel comfortable about copying live files which are ope= n > for update > > 3. =A0 =A0By the time I copy the files back some of the information will b= e > out of date > > Do I have to copy these files back again? As far as I am aware the > upgrade does not modify any of these files. When I originally installed > OpenVMS 8.3 on Integrity I did it as a standalone installation on the > rx3600 and then joined the rx3600 to the Alpha cluster at a later date. > So the integrity system disk still has the original authorization files > on the integrity system disk that were built at the time of the > standalone installation. Why can't I just use those for the upgrade and > go back to the authorization files on the Alpha system disk again after > the upgrade? > > QUESTION 2: > > After the upgrade is complete and the rx3600 systems disk is $1$DGA12 on > the EVA5000 I want to add the rx2660 to the SAN. To do this the Upgrade > and Installation Manual recommends I boot from the installation DVD, > select the DCL prompt and type: > > $$$ @SYS$MANAGER:BOOT_OPTIONS > > This has an option to configure the SAN disk $1$DGA12: as a Boot Options > device. What the Installation Guide doesn't mention is that you are > required to mount the device $1$DGA12 as part of the configuration. This > means a standalone node running off the installation DVD has mounted the > same disk as the rx3600 VMS cluster node server. That seems very risky > to me, although I notice the BOOT_OPTIONS.COM utility does mount the > desk read-only. Can I assume it is safe to do this? I know I could > configure the rx2660 to add $1$DGA12: before using it as a system disk > but I still want to ask the question. > > -- > > Regards > Malcolm > > Malcolm Smeaton, Server Group Leader > Information and Communication Technology Services > University of Canterbury Te Whare Wananga o Waitaha > Private Bag 4800, Christchurch 8140, New Zealand On the first question I don't know - it's not something that I'd expect but there was a change in the documentation between v7.3 and v7.3-2 where this became documented and, apparently, necessary. A colleague thinks that it could be there are changes to the SYSUAF in terms of quota minimums or file structure that need to be carried out during the upgrade. On question 2 (the addition of the rx2660), my approaches would be one of: - boot the rx2660 as a satellite to start with, then use boot_options from the running system to add the SAN disk as the boot device; or - add the rx2660 as a cluster member on the local disk on the rx3600, then back the system disk up onto the rx2660 and boot it into the cluster from there. Once it's in the cluster then you can move its system disk with the rx3600's. That said and IIRC, it is possible to alter the boot device from the menu on the Integrity so maybe that's a third way? Steve ------------------------------ Date: Wed, 13 Feb 2008 03:47:39 -0800 (PST) From: Bob Gezelter Subject: Re: Multiple system disks and SAN Message-ID: <1fda1b87-1983-40ec-8606-d3d9f14be9a4@v4g2000hsf.googlegroups.com> On Feb 13, 5:25 am, etmsr...@yahoo.co.uk wrote: > On 12 Feb, 20:28, Malcolm Smeaton > wrote: > > > > > We have Alpha and Integrity servers sharing the same cluster but using > > different system disks. However they share the same authorization files > > .e.g. > > > $ define/system/exec sysuaf > > dsa100:[vms$common.sysexe]sysuaf.dat > > > $ define/system/exec rightslist > > dsa100:[vms$common.sysexe]rightslist.dat > > > $ define/system/exec qman$master dsa100:[vms$common.sysexe] > > > $ define/system/exec vmsmail_profile > > dsa100:[vms$common.sysexe]vmsmail_profile.data > > > $ define/system/exec netproxy > > dsa100:[vms$common.sysexe]netproxy.dat > > > $ define/system/exec net$proxy > > dsa100:[vms$common.sysexe]net$proxy.dat > > > $ define/system/exec vms$objects > > dsa100:[vms$common.sysexe]vms$objects.dat > > > $ define/system/exec vms$audit_server > > dsa100:[vms$common.sysmgr]vms$audit_server.dat > > > $ define/system/exec vms$password_history > > dsa100:[vms$common.sysexe]vms$password_history.data > > > Integrity is running on VMS 8.3 and Alpha is running on VMS 7.3-2. > > > I want to upgrade Integrity to VMS 8.3-1H1 first and then Alpha to VMS > > 8.3. I can't quite upgrade the Alpha systems yet because of some legacy > > applications which we are in the process of decommissioning. > > > The shared cluster files are currently on the Alpha system disk, dsa100: > > which is on a RAID 7000 StorageWorks disk array. > > > At the moment the integrity system disk is locally attached to a rx3600 > > server, $10$dka0: We have since purchased a rx2660 itanium server so I > > want to copy the integrity system disk to a disk called $1$DGA12 on our > > EVA5000 SAN and then upgrade the new system disk to VMS 8.3-1H1. During > > this period I want to keep the Alpha systems running because we have > > important 24x7 applications on it. > > > QUESTION 1: > > > The VMS 8.3-1H1 Upgrade and Installation Manual Section 4.5.5 tells me I > > need to move the authorization files to the new system disk before I do > > the upgrade and then move them back to their original location after the > > upgrade. I have some problems with this. > > > 1. These files, particularly sysuaf.dat, rightslist.dat, > > vmsmail_profile.data are changing all the time due to password changes > > and because we use VMS for our usercode management system accounts come > > and go. > > > 2. I do not feel comfortable about copying live files which are open > > for update > > > 3. By the time I copy the files back some of the information will be > > out of date > > > Do I have to copy these files back again? As far as I am aware the > > upgrade does not modify any of these files. When I originally installed > > OpenVMS 8.3 on Integrity I did it as a standalone installation on the > > rx3600 and then joined the rx3600 to the Alpha cluster at a later date. > > So the integrity system disk still has the original authorization files > > on the integrity system disk that were built at the time of the > > standalone installation. Why can't I just use those for the upgrade and > > go back to the authorization files on the Alpha system disk again after > > the upgrade? > > > QUESTION 2: > > > After the upgrade is complete and the rx3600 systems disk is $1$DGA12 on > > the EVA5000 I want to add the rx2660 to the SAN. To do this the Upgrade > > and Installation Manual recommends I boot from the installation DVD, > > select the DCL prompt and type: > > > $$$ @SYS$MANAGER:BOOT_OPTIONS > > > This has an option to configure the SAN disk $1$DGA12: as a Boot Options > > device. What the Installation Guide doesn't mention is that you are > > required to mount the device $1$DGA12 as part of the configuration. This > > means a standalone node running off the installation DVD has mounted the > > same disk as the rx3600 VMS cluster node server. That seems very risky > > to me, although I notice the BOOT_OPTIONS.COM utility does mount the > > desk read-only. Can I assume it is safe to do this? I know I could > > configure the rx2660 to add $1$DGA12: before using it as a system disk > > but I still want to ask the question. > > > -- > > > Regards > > Malcolm > > > Malcolm Smeaton, Server Group Leader > > Information and Communication Technology Services > > University of Canterbury Te Whare Wananga o Waitaha > > Private Bag 4800, Christchurch 8140, New Zealand > > On the first question I don't know - it's not something that I'd > expect but there was a change in the documentation between v7.3 and > v7.3-2 where this became documented and, apparently, necessary. A > colleague thinks that it could be there are changes to the SYSUAF in > terms of quota minimums or file structure that need to be carried out > during the upgrade. > > On question 2 (the addition of the rx2660), my approaches would be one > of: > - boot the rx2660 as a satellite to start with, then use boot_options > from the running system to add the SAN disk as the boot device; or > - add the rx2660 as a cluster member on the local disk on the rx3600, > then back the system disk up onto the rx2660 and boot it into the > cluster from there. Once it's in the cluster then you can move its > system disk with the rx3600's. > > That said and IIRC, it is possible to alter the boot device from the > menu on the Integrity so maybe that's a third way? > > Steve Steve, On the question of the authorization files, to be careful, I would log a support call (or do the research by picking the files apart myself) as to what changes are actually made. Offhand, without checking, I cannot think of format-compatible changes that would be made to the files that would continue to be valid in a mixed version cluster. I could see some checking and reorganizing, but you could accomplish that manually. In actuality, I would consider this a documentation bug as it impairs continuous cluster operation. I am not sure that I understand the second question. There is nothing special about an OpenVMS cluster with two disks as opposed to one with three system disks. First, I would create a system root with new SCS ID, node number, and node name for the rx2660 on the Itanium system disk (e.g., SYS2). I would then make a copy of the Itanium system disk on $10$DGA12. At that point it can be dismounted from the existing system. The rx2660 can then be booted from $10$DGA12, and the upgrade can be run. Then the situation will be a mixed version cluster, with the Alpha, rx3600, and rx2660; each running from their own system disk. Changing the rx3660 boot setting to have it boot from the SAN $10$DGA12 and the the upgrade is complete. Have I missed something? - Bob Gezelter, http://www.rlgsc.com ------------------------------ Date: Wed, 13 Feb 2008 07:46:08 -0500 From: Robert Deininger Subject: Re: Multiple system disks and SAN Message-ID: In article <7015937@MVB.SAIC.COM>, Malcolm Smeaton wrote: ... > > QUESTION 2: > > > > After the upgrade is complete and the rx3600 systems disk is $1$DGA12 on > the EVA5000 I want to add the rx2660 to the SAN. To do this the Upgrade > and Installation Manual recommends I boot from the installation DVD, > select the DCL prompt and type: I think you mean you want to add the rx2660 to the cluster, also booting from $1$DGA12. (Adding the system to the SAN isn't really a VMS issue, after all.) The problem is that the EFI environment isn't a very easy place to create boot options for FibreChannel disks, especially on a large SAN. Systems are normally configured to NOT discover all the SAN disks at the firmware level; they only materialize disks that are listed in one or more boot options. And firmware can't create a boot option for a disk it hasn't discovered yet. Classic chicken and egg problem. You can tell the firmware to discover all the SAN disks. (I don't remember the incantation off the top of my head.) If there are a lot of disks, this can take a LONG time. On a small SAN, it would be faster than booting the DVD. That is why the docs recommend using the VMS tool to make the boot option. You don't NEED a boot option to boot VMS. If you can identify the right fsn: device at the EFI shell, all you have to do is run \efi\vms\vms_loader.efi with the right boot flags for your configuration. > > > > $$$ @SYS$MANAGER:BOOT_OPTIONS > > > > This has an option to configure the SAN disk $1$DGA12: as a Boot Options > device. What the Installation Guide doesn't mention is that you are > required to mount the device $1$DGA12 as part of the configuration. This > means a standalone node running off the installation DVD has mounted the > same disk as the rx3600 VMS cluster node server. That seems very risky > to me, although I notice the BOOT_OPTIONS.COM utility does mount the > desk read-only. Can I assume it is safe to do this? I know I could > configure the rx2660 to add $1$DGA12: before using it as a system disk > but I still want to ask the question. Make sure you've properly configured the root for the rx2660 on $1$DGA12 BEFORE you create the boot option. When the rx2660 boots this disk, it needs to join the cluster as a regular member. Then boot the rx2660 from the DVD, infoserver, or whatever, in order to run BOOT_OPTIONS. MOUNT/NOWRITE the disk before running BOOT_OPTIONS.COM. With the /NOWRITE, the rx2660 can't modify the disk so your data is safe. If you forget the /NOWRITE, you'll trash the disk. This is an acceptable "cheat" for the purpose of making a boot option. ------------------------------ Date: Wed, 13 Feb 2008 08:47:53 -0500 From: "Ed Vogel" Subject: Re: ODS5, /NAMES = AS_IS, LIBRARY, MMS v. me Message-ID: "John E. Malmberg" wrote in message news:j%vsj.31289$yE1.11037@attbi_s21... > For the shared images, I have been putting aliases in for uppercase, exact > case, (manually truncated/mangled if needed), and also uppercase crc > shortened, and exact case crc shortened. > > That way it can be used with the maximum number of compiler settings. > John, Assuming the functions in your shared images are defined by header files that the user must include you could consider adding: #pragma names save #pragma names as_is, shortened at the start of your header file, and #pragma names restore at the end. In this way, all external names declared in the header will be as_is and shortened no matter what compiler settings are used. Just a thought. Ed Vogel HP/Compaq/DEC C/C++ for OpenVMS Engineering ------------------------------ Date: Wed, 13 Feb 2008 14:45:17 GMT From: "John E. Malmberg" Subject: Re: ODS5, /NAMES = AS_IS, LIBRARY, MMS v. me Message-ID: <1oDsj.31899$9j6.17068@attbi_s22> Ed Vogel wrote: > "John E. Malmberg" wrote in message > news:j%vsj.31289$yE1.11037@attbi_s21... >> For the shared images, I have been putting aliases in for uppercase, exact >> case, (manually truncated/mangled if needed), and also uppercase crc >> shortened, and exact case crc shortened. >> >> That way it can be used with the maximum number of compiler settings. >> > > John, > > Assuming the functions in your shared images are defined by header > files > that the user must include you could consider adding: > > #pragma names save > #pragma names as_is, shortened > > at the start of your header file, and > > #pragma names restore > > at the end. In this way, all external names declared in the header > will be as_is and shortened no matter what compiler settings are used. > > Just a thought. On the shared images that I am making, I am making the minimum modifications to the source and build procedures needed to get them to build on VMS. I am trying not to maintain or auto-edit the header files. Because of all the interesting ways that the header files are used and generated, automating such edits would not be as simple as it would seem. I am trying to make it as easy as possible to build additional VMS programs against them. One of the things that I have been running into is that many of the previous ports of shared libraries to VMS from *NIX have uppercase symbols only in their their transfer vectors, and their header files have the symbols in lower case. The UNIX "Configure" program does not use header files when testing for the presence of these routines. And when you have some modules requiring AS-IS, SHORTENED, and some shared images that are not compatible with that, it ends up being a pain. Which is why I am advocating that anyone building shared images from a UNIX port, if it previously had only uppercase symbol vectors, add the exact case CRC shortened/truncated, and the others so that they will be compatible with programs that require those settings, and to provide the upper case and CRC shortend/truncated for build procedures that have not been setting those options. And just to do it for new stuff to set as a standard procedure, so that when you refresh something older, the programmer knows what to do and how to do it. -John wb8tyw@qsl.network Personal Opinion Only ------------------------------ Date: 13 Feb 2008 12:04:56 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: ODS5, /NAMES = AS_IS, LIBRARY, MMS v. me Message-ID: In article <1oDsj.31899$9j6.17068@attbi_s22>, "John E. Malmberg" writes: > > On the shared images that I am making, I am making the minimum > modifications to the source and build procedures needed to get them to > build on VMS. I am trying not to maintain or auto-edit the header > files. Because of all the interesting ways that the header files are > used and generated, automating such edits would not be as simple as it > would seem. Off the top of my head (probably needs more work specific to your case): .C.OBJ: $(CC) $(CFLAGS) a.c+$(MMS$SOURCE)+z.c/object=$(MMS$TARGET) Where a.c and z.c contain the needed #pragma entry and exit. ------------------------------ Date: Wed, 13 Feb 2008 06:29:49 -0800 From: "Tom Linden" Subject: Re: The "World's First" MicroVAX II Museum is now Open Message-ID: On Tue, 12 Feb 2008 22:34:28 -0800, alegend wrote: > Hello All, > > After more than a year, which should have taken less than three weeks, > the MicroVAX II museum (or better referred to as "shrine", due to its > size) is now open. > > A partial, lots-to-be-done web presence is at: http://www.microvax2.org > (check out the virtual tour). > > It is located in Israel, and entry is free and by appointment only. > > I have no idea what a visitor might do there after wandering around > the room for a few minutes, but if you are in the neighborhood and in > desparate need for a VMS 5.4 prompt, you can find it there. > > Seriously, this place is all about preserving the MicroVAX II, and as > much software, literature and related hardware as possible. It is > built like a computer room from the late 80's, and a glass wall is the > next thing on the construction plan. > > The history of the 12 sq. meter room in my front yard goes back many > years. But in the last year I have cleared tons of rubbish from it, > lay down a new ceramic tile floor, got it painted, had special-ordered > all the furniture, connected the room to mains power, littered the > ceiling with spot lights, and had the essential air conditioner > installed. > > I would like to take the opportunity to thank all those who helped me, > in this newsgroup and beyond (you know who you are). > > My apologies for the double posting. > > -Al. You should install SDL and PL/I. Aside from possibly Fortran, PL/I probably produced the most efficient code on VAX. -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Wed, 13 Feb 2008 13:36:54 -0500 From: JF Mezei Subject: Re: The "World's First" MicroVAX II Museum is now Open Message-ID: <47b338d6$0$10268$c3e8da3@news.astraweb.com> alegend wrote: > > A partial, lots-to-be-done web presence is at: http://www.microvax2.org > (check out the virtual tour). You can look at http://www.vaxination.ca/vms/microvax/mv_ii.html ------------------------------ Date: Wed, 13 Feb 2008 05:53:18 -0800 (PST) From: FrankS Subject: Re: Unusual mailbox status value Message-ID: On Feb 13, 1:40=A0am, David B Sneddon wrote: > It is my understanding that the definitions are there to allow > the compiler to generate warnings about your code, not change the > code. Well, your understanding is wrong. In BASIC, if the declaration of the external subroutine includes the passing mechanism for the argument then the compiler uses the declared passing mechanism. It can be overridden in the actual CALL or function invocation, but the declared passing mechanism overrides BASIC's default argument passing rules. For example, in the $QIOW the channel number is supposed to be passed by value. BASIC's default passing rule for a word variable is by reference. According to your understanding, the address of the channel number is being passed to the $QIOW and not the value, in which case the service would fail every time with an invalid channel reference. (The odds of the lower-order word of the address of the channel number matching the actual value of the channel number would be astronomical, I think.) Similarly, for the P2 address of the buffer, the default passing rule is BY DESC for a string yet the $QIOW requires it to be passed by reference. If BASIC were sending the address of the descriptor and not the address of the string then there's no chance in hell that the thousands of previous successful I/Os would have had valid data in the buffer area upon completion of the $QIOW. > Your code is wrong. =A0Fix it. I disagree, at least as far as your reason for saying the code is wrong. The code may be wrong for other reasons. If you think you can make a more convincing argument then go right ahead and I will give it another look. ------------------------------ Date: 13 Feb 2008 11:49:23 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Unusual mailbox status value Message-ID: In article <918d5747-7939-4924-9c0c-2059a4d4aa18@s12g2000prg.googlegroups.com>, FrankS writes: > I have a new application that reads from a mailbox, and periodically > the status value returned in the I/O status block is invalid. The > value is consistently %X3033, which doesn't come up with anything in > SYS$GETMSG. > > Since the I/O status block only returns a word (16-bit value) I'm > wondering if the facility code is being truncated. Would be very > unusual, but I'm out of other ideas. > > Based on the low-order bits this an informational message, whatever it > means, so for now I'm ignoring it. > > Anyone have thoughts on what the error condition may be? Since 3033 is a success code (lsb is 1), it can't be even part of a report of a problem. I suspect: 1) some bug somewhere in your code is stepping on the value 2) you're looking at the IOSB before the I/O is complete ($QIO or $QIOW?) 3) the I/O never got on the queue, but you forgot to check the return value of the $QIO and so don't know that ------------------------------ Date: 13 Feb 2008 11:56:43 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Unusual mailbox status value Message-ID: In article <64cc746c-465d-43d4-81aa-0949c9ccb4cc@h11g2000prf.googlegroups.com>, FrankS writes: > > The first test of R0 shows SS$_NORMAL, then the application looks at > the IOSB and anything other than SS$_NORMAL gets reported (and the > application is aborted at that point). None of the other expected > status value from the IOSB would be recoverable, so if it's not SS > $_NORMAL then out we go. > Be carefull how you look at message codes. $QIO can, and at least used to, return 9, which translates as a successfull access violation! It was a side affect of how driver FDT routines worked when a user buffer page had to be paged in. And the $QIO was successfull. We also used to use the reserved to user bit in the high end in condition handling routines. lib$match_cond is your friend. Checking the lsb for success/failure is your friend. ------------------------------ Date: Wed, 13 Feb 2008 10:16:09 -0500 From: "Stanley F. Quayle" Subject: VAX 7000 (was: DIBOL to On 11 Feb 2008 at 13:14, Bill Gunshannon wrote: > And I just watched two lightly used, perfectly functional VAX 7000's > get hauled to the dump. "Lightly used", but certainly not "light". It seems a shame, though. Some should at least parted them out first... --Stan Quayle Quayle Consulting Inc. ---------- Stanley F. Quayle, P.E. N8SQ Toll free: 1-888-I-LUV-VAX 8572 North Spring Ct., Pickerington, OH 43147 USA stan-at-stanq-dot-com http://www.stanq.com/charon-vax.html "OpenVMS, when downtime is not an option" ------------------------------ Date: 13 Feb 2008 16:03:43 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: VAX 7000 (was: DIBOL to In article <47B2C369.26843.18626345@infovax.stanq.com>, "Stanley F. Quayle" writes: > On 11 Feb 2008 at 13:14, Bill Gunshannon wrote: >> And I just watched two lightly used, perfectly functional VAX 7000's >> get hauled to the dump. > > "Lightly used", but certainly not "light". > > It seems a shame, though. Some should at least parted them out first... > I offered them here for nothing. I offered them in other places for free. As a last resort I put them on Ebay. I sold one for $100. Al Kossow asked to have one CPU for his collection (which I sent him). Don't really know what else I could have done. I kept them hanging around for more than a year trying to avoid just dumping them. Sad, really...... 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: Wed, 13 Feb 2008 08:20:12 -0800 (PST) From: FrankS Subject: Re: VAX 7000 (was: DIBOL to On Feb 13, 11:03=A0am, billg...@cs.uofs.edu (Bill Gunshannon) wrote: > I offered them here for nothing. =A0I offered them in other places for > free. =A0As a last resort I put them on Ebay. =A0I sold one for $100. I know of four VAX 7640s that may become available by the end of the year, if not sooner. They will likely be sold by the pound to a computer systems liquidator. If somebody is creating a VAX 7600 museum to complement the MicroVAX II museum in Israel then maybe we'll find a better home for this stuff. :-) ------------------------------ Date: Wed, 13 Feb 2008 08:33:57 -0800 From: "Tom Linden" Subject: Re: VAX 7000 (was: DIBOL to On Wed, 13 Feb 2008 08:20:12 -0800, FrankS wrote: > On Feb 13, 11:03 am, billg...@cs.uofs.edu (Bill Gunshannon) wrote: >> I offered them here for nothing.  I offered them in other places for >> free.  As a last resort I put them on Ebay.  I sold one for $100. > > I know of four VAX 7640s that may become available by the end of the > year, if not sooner. They will likely be sold by the pound to a > computer systems liquidator. > > If somebody is creating a VAX 7600 museum to complement the MicroVAX > II museum in Israel then maybe we'll find a better home for this > stuff. :-) > How about the computer history museum in San Jose? I think I know someone who might be interested, drop me a note offline. -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Wed, 13 Feb 2008 13:41:40 -0500 From: JF Mezei Subject: Re: VEST Message-ID: <47b339f3$0$10268$c3e8da3@news.astraweb.com> FrankS wrote: > If you VEST the DIBOL compiler and are able to mate it to the Alpha > GEM routines then one could expect it to produce Alpha code. It > wouldn't surprise me if some of Digital's earliest efforts at porting > to Alpha involved new GEM code with VESTed compilers. Did any VAX compilers use GEM ? ------------------------------ Date: Wed, 13 Feb 2008 10:00:33 -0500 From: "Stanley F. Quayle" Subject: VEST (was: DIBOL to Message-ID: <47B2BFC1.29026.18541BB0@infovax.stanq.com> > > VESTing the compiler itself? =A0Wouldn't it still create a VAX object = file? > > Not necessarily. Of course, I haven't tried this so it's all > theoretical and maybe it won't work at all. Of course it would. How would the VEST'd compiler "know" it's supposed to= generate Alpha, Itanium, or Power PC instructions?? You'd have to VEST the result of the compiler to get something that runs o= n Alpha, too. > However, I would expect that if it did work the Alpha versions of sharea= ble > images the compiler relied on would generate Alpha code. There's no shareable image that generates Alpha or any other kind of code.= There's a back-end tool called GEM that most VMS compilers use, but it's not somethi= ng that you can just use. --Stan Quayle Quayle Consulting Inc. ---------- Stanley F. Quayle, P.E. N8SQ Toll free: 1-888-I-LUV-VAX 8572 North Spring Ct., Pickerington, OH 43147 USA stan-at-stanq-dot-com http://www.stanq.com/charon-vax.html "OpenVMS, when downtime is not an option" ------------------------------ Date: Wed, 13 Feb 2008 08:16:28 -0800 (PST) From: FrankS Subject: Re: VEST (was: DIBOL to Message-ID: On Feb 13, 10:00=A0am, "Stanley F. Quayle" wrote: > There's no shareable image that generates Alpha or any other kind of code.= =A0There's a > back-end tool called GEM that most VMS compilers use, but it's not somethi= ng that you can > just use. I don't think it was too much of a stretch to guess that the GEM functions common to all compilers would be located in a shareable image. Since, to my knowledge, GEM generates the object files then the Alpha version of the GEM code would generate Alpha objects with Alpha instructions. If you VEST the DIBOL compiler and are able to mate it to the Alpha GEM routines then one could expect it to produce Alpha code. It wouldn't surprise me if some of Digital's earliest efforts at porting to Alpha involved new GEM code with VESTed compilers. And I did say it was all theoretical and that I hadn't actually tried it. Not knowing if the GEM entry points are the same between Alpha & VAX (I would think they are) or how they are packaged (shareable or linked in with each compiler) I thought I left my comments fairly open- ended and full of the necessary disclaimers. ------------------------------ Date: Wed, 13 Feb 2008 12:40:15 -0500 From: "Stanley F. Quayle" Subject: Re: VEST (was: DIBOL to Message-ID: <47B2E52F.19224.18E65066@infovax.stanq.com> On 13 Feb 2008 at 8:16, FrankS wrote: > I don't think it was too much of a stretch to guess that the GEM > functions common to all compilers would be located in a shareable > image. Since, to my knowledge, GEM generates the object files then > the Alpha version of the GEM code would generate Alpha objects with > Alpha instructions. You could ask Tom Linden of Kednos. He now owns the PI/I compiler, which is available for VAX and Alpha. It uses GEM. That's also the reason that PI/I isn't available for Itanium -- GEM changed and HP hasn't released the API. > If you VEST the DIBOL compiler and are able to mate it to the Alpha > GEM routines then one could expect it to produce Alpha code. Sounds like a lot of work compared to running CHARON-VAX [Shameless Plug Alert (tm) I am a CHARON reseller]. In a couple of days, he'd be done. Not all customers are up to reverse-engineering something like a compiler. --Stan Quayle Quayle Consulting Inc. ---------- Stanley F. Quayle, P.E. N8SQ Toll free: 1-888-I-LUV-VAX 8572 North Spring Ct., Pickerington, OH 43147 USA stan-at-stanq-dot-com http://www.stanq.com/charon-vax.html "OpenVMS, when downtime is not an option" ------------------------------ Date: 13 Feb 2008 11:43:41 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: VEST (was: DIBOL to Message-ID: In article , FrankS writes: > > I don't think it was too much of a stretch to guess that the GEM > functions common to all compilers would be located in a shareable > image. Since, to my knowledge, GEM generates the object files then > the Alpha version of the GEM code would generate Alpha objects with > Alpha instructions. The contents of, and use of, the GEM back end is not consistent across compilers. The concept and much of the implementation is the same. ------------------------------ Date: Wed, 13 Feb 2008 07:45:03 -0800 (PST) From: IanMiller Subject: VMS Audio Update on your iPOD (or whatever player you have) Message-ID: <8fa4b894-7b69-47af-9bff-864ce139bdd4@s13g2000prd.googlegroups.com> You can now subscribe to the VMS Audio Update and get the latest episode whenever it is done. http://feeds.feedburner.com/openvms ------------------------------ Date: Wed, 13 Feb 2008 08:24:01 -0800 From: Malcolm Dunnett Subject: Re: VMS license fees? Message-ID: <47b319a1$1@flight> Bill Gunshannon wrote: > Not surprised, but some people actually don't believe in stealing > software. I woould be willing to bet that there are a lot of > commercial VMS systems running with Hobbyist PAKs. > I'd take that bet if there was any way to prove it one way or the other. Personally I doubt there's "a lot" of that going on. For one thing there aren't "a lot" of commercial VMS systems out there (compared to Windows or Linux). An organization sophisticated enough to recognize the value of VMS probably is sophisticated enough to realize the risk they could be at by running pirate software. I would bet that the percentage of VMS systems running with dodgy software licensing is several orders of magnitude below the percentage of Windows systems that are improperly licenses. VMS licenses are actually pretty cheap these days (at least for the "foundation" level). If you can afford an Itanium box from HP you can probably afford the VMS license. I believe that what the OP was actually saying was that there are many VAX sites running older versions of VMS that they aren't paying support fees on anymore ( which is perfectly legal as the licenses are perpetual ). ------------------------------ Date: Wed, 13 Feb 2008 11:44:44 -0500 From: "Richard B. Gilbert" Subject: Re: VMS license fees? Message-ID: <47B31E7C.4050702@comcast.net> Malcolm Dunnett wrote: > Bill Gunshannon wrote: > >> Not surprised, but some people actually don't believe in stealing >> software. I woould be willing to bet that there are a lot of >> commercial VMS systems running with Hobbyist PAKs. >> > > > I'd take that bet if there was any way to prove it one way or the > other. Personally I doubt there's "a lot" of that going on. For one > thing there aren't "a lot" of commercial VMS systems out there (compared > to Windows or Linux). An organization sophisticated enough to recognize > the value of VMS probably is sophisticated enough to realize the risk > they could be at by running pirate software. > > I would bet that the percentage of VMS systems running with dodgy > software licensing is several orders of magnitude below the percentage > of Windows systems that are improperly licenses. > > VMS licenses are actually pretty cheap these days (at least for the > "foundation" level). If you can afford an Itanium box from HP you can > probably afford the VMS license. > > I believe that what the OP was actually saying was that there are > many VAX sites running older versions of VMS that they aren't paying > support fees on anymore ( which is perfectly legal as the licenses are > perpetual ). A support contract on modern equipment is anything but cheap. Supporting antiques usually costs extra! ------------------------------ Date: 13 Feb 2008 17:02:47 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: VMS license fees? Message-ID: <61gm5nF1uuscfU1@mid.individual.net> In article <47b319a1$1@flight>, Malcolm Dunnett writes: > Bill Gunshannon wrote: > >> Not surprised, but some people actually don't believe in stealing >> software. I woould be willing to bet that there are a lot of >> commercial VMS systems running with Hobbyist PAKs. >> > > I'd take that bet if there was any way to prove it one way or the > other. Personally I doubt there's "a lot" of that going on. For one > thing there aren't "a lot" of commercial VMS systems out there (compared > to Windows or Linux). I guess "a lot" is rather subjective. 10 VMS sites doing it would be a lot more relative to the number of legitimate VMS sites than 10,000 MS sites relative to the number of MS systems. > An organization sophisticated enough to recognize > the value of VMS probably is sophisticated enough to realize the risk > they could be at by running pirate software. You would think that, but my experience is quite different. I have spent a lot of time and effort convincing people here that they can't buy one copy of a program and then install it on every machine in site. > > I would bet that the percentage of VMS systems running with dodgy > software licensing is several orders of magnitude below the percentage > of Windows systems that are improperly licenses. Again, it probably depends on your interpretation of "commercial use". I had a lot of people tell me that I should have just been using a hobbyist license for the machines I set up for the students to play with. That is certainly not the way I see it and I never did it. Same thing with the PDP-11's I set up. There is no hobbyist or edu program for them and still I had dozens of people telling me to just go ahead and do it. Software piracy is a bigger problem than many people want to admit and it is not limited to MS products. > > VMS licenses are actually pretty cheap these days (at least for the > "foundation" level). If you can afford an Itanium box from HP you can > probably afford the VMS license. But we are not talking about Itaniums, we are talking about VAX. > > I believe that what the OP was actually saying was that there are > many VAX sites running older versions of VMS that they aren't paying > support fees on anymore ( which is perfectly legal as the licenses are > perpetual ). Not the way I read it: "Paying for licenses? I encounter customers all the time that don't know that HP owns VMS. They're certainly not paying anyone license fees for their VAX." Hard to interpret that as anything short of running VAX without a valid license. 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: Wed, 13 Feb 2008 12:35:32 -0500 From: "Stanley F. Quayle" Subject: Re: VMS license fees? Message-ID: <47B2E414.12511.18E20102@infovax.stanq.com> On 13 Feb 2008 at 17:02, Bill Gunshannon wrote: > Not the way I read it: "Paying for licenses? > I encounter customers all the time that don't know > that HP owns VMS. They're certainly not paying anyone > license fees for their VAX." > > Hard to interpret that as anything short of running VAX without > a valid license. What I meant was that the licenses that came with their VAX, good forever, stay good for, well, forever. --Stan Quayle Quayle Consulting Inc. ---------- Stanley F. Quayle, P.E. N8SQ Toll free: 1-888-I-LUV-VAX 8572 North Spring Ct., Pickerington, OH 43147 USA stan-at-stanq-dot-com http://www.stanq.com/charon-vax.html "OpenVMS, when downtime is not an option" ------------------------------ Date: 13 Feb 2008 17:46:48 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: VMS license fees? Message-ID: <61goo8F1urc24U1@mid.individual.net> In article <47B2E414.12511.18E20102@infovax.stanq.com>, "Stanley F. Quayle" writes: > On 13 Feb 2008 at 17:02, Bill Gunshannon wrote: >> Not the way I read it: "Paying for licenses? >> I encounter customers all the time that don't know >> that HP owns VMS. They're certainly not paying anyone >> license fees for their VAX." >> >> Hard to interpret that as anything short of running VAX without >> a valid license. > > What I meant was that the licenses that came with their VAX, good forever, stay good for, > well, forever. OK, I stand corrected. I guess I have seen so much violation of IP rights I have just become too cynical. 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: Wed, 13 Feb 2008 12:52:26 -0500 From: "Dan Allen" Subject: RE: VMS license fees? Message-ID: <001801c86e69$32094970$1f3a0681@sdct.nist.gov> > -----Original Message----- > From: Stanley F. Quayle [mailto:infovax@stanq.com] > Sent: Wednesday, February 13, 2008 12:36 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: VMS license fees? > > On 13 Feb 2008 at 17:02, Bill Gunshannon wrote: > > Not the way I read it: "Paying for licenses? > > I encounter customers all the time > that don't know > > that HP owns VMS. They're > certainly not paying anyone > > license fees for their VAX." > > > > Hard to interpret that as anything short of running VAX without a > > valid license. > > What I meant was that the licenses that came with their VAX, > good forever, stay good for, well, forever. > > --Stan Quayle > Quayle Consulting Inc. > Indeed. I have a file cabinet drawer full of license PAKS originally purchased for an 11/780 in the early eighties (including a host of unlimited VMS and layerd product licenses) that were transferred as part of an Alpha upgrade and are still good. Too bad there's no interest in the Alpha aside from me.... Dan > ---------- > Stanley F. Quayle, P.E. N8SQ Toll free: 1-888-I-LUV-VAX > 8572 North Spring Ct., Pickerington, OH 43147 USA > stan-at-stanq-dot-com http://www.stanq.com/charon-vax.html > "OpenVMS, when downtime is not an option" > > ------------------------------ Date: Wed, 13 Feb 2008 13:40:48 -0500 From: JF Mezei Subject: Re: VMS license fees? Message-ID: <47b339bf$0$10268$c3e8da3@news.astraweb.com> Bill Gunshannon wrote: > > Not surprised, but some people actually don't believe in stealing > software. I woould be willing to bet that there are a lot of > commercial VMS systems running with Hobbyist PAKs. I don't think so. Your presumption would assume that there would have been new customers who started to use VMS since the hobbyisty programme was started and who would have decided to use those licences "illegally". I would think that almost all customers are long tike VMS customers who have had their licences for a very long time even if they no longer pay for the support fees. Where hobbyist may be "abused" are those legitimate shops needing a new licence to compile some freeware utility etc and being unable to reach Digital to buy such licence, they go the way of hobbyist. ------------------------------ Date: Wed, 13 Feb 2008 19:37:48 +0100 From: Wilm Boerhout Subject: Re: VMS license fees? Message-ID: <47b3390d$0$25498$ba620dc5@text.nova.planet.nl> on 13-2-2008 17:38 Richard B. Gilbert wrote... > And some of us bought systems with licenses included! If you bought them new, that's OK. If you bought'm second hand, (VAX or Alpha), it's only OK for the base OS license + "hardware attached" software (Category 1 software). All other licenses are not transferable outside of the first owner legal entity (relicensing), although they are transferable within the original legal entity (redesignation). Relicensing is not free where it is permitted. Written permission from HP required in all cases. Software License Policy http://licensing.hp.com/swl/view.slm?page=xfer I'm not sure whether HP staff does enforce this policy, well, then again, I'm sure they don't. When I was a Digital employee in the 80's, everyone selling second hand knew this. It was enforced then. -- Wilm Boerhout | Zwolle, | - 'My memory's fine!' The Netherlands | - 'But you keep forgetting your mistakes!' remove OLD PAINT to reply| - 'Exactly!' ------------------------------ Date: Wed, 13 Feb 2008 10:27:04 -0500 From: "Stanley F. Quayle" Subject: VMS license fees? (was: DIBOL to > this not leave you stuck keeping, maintaining and paying licensing for a VAX Paying for licenses? I encounter customers all the time that don't know that HP owns VMS. They're certainly not paying anyone license fees for their VAX. --Stan Quayle Quayle Consulting Inc. ---------- Stanley F. Quayle, P.E. N8SQ Toll free: 1-888-I-LUV-VAX 8572 North Spring Ct., Pickerington, OH 43147 USA stan-at-stanq-dot-com http://www.stanq.com/charon-vax.html "OpenVMS, when downtime is not an option" ------------------------------ Date: 13 Feb 2008 16:00:02 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: VMS license fees? (was: DIBOL to In article <47B2C5F8.23959.186C62D7@infovax.stanq.com>, "Stanley F. Quayle" writes: >> this not leave you stuck keeping, maintaining and paying licensing for a VAX > > Paying for licenses? > > I encounter customers all the time that don't know that HP owns VMS. They're certainly > not paying anyone license fees for their VAX. > Not surprised, but some people actually don't believe in stealing software. I woould be willing to bet that there are a lot of commercial VMS systems running with Hobbyist PAKs. 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: Wed, 13 Feb 2008 11:38:47 -0500 From: "Richard B. Gilbert" Subject: Re: VMS license fees? (was: DIBOL to Bill Gunshannon wrote: > In article <47B2C5F8.23959.186C62D7@infovax.stanq.com>, > "Stanley F. Quayle" writes: > >>>this not leave you stuck keeping, maintaining and paying licensing for a VAX >> >>Paying for licenses? >> >>I encounter customers all the time that don't know that HP owns VMS. They're certainly >>not paying anyone license fees for their VAX. >> > > > Not surprised, but some people actually don't believe in stealing > software. I woould be willing to bet that there are a lot of > commercial VMS systems running with Hobbyist PAKs. > And some of us bought systems with licenses included! ------------------------------ End of INFO-VAX 2008.088 ************************