INFO-VAX Wed, 16 May 2007 Volume 2007 : Issue 268 Contents: Re: Another x86-64 price war is coming Re: Another x86-64 price war is coming Re: Another x86-64 price war is coming Re: Another x86-64 price war is coming Re: Another x86-64 price war is coming Another x86-64 price war is coming Re: Another x86-64 price war is coming Re: Another x86-64 price war is coming Re: Digital *is* a Software Company? (Was Re: Sun Studio 11 (Solaris IDE)) IDE)) Re: How can I get scanf to terminate on when the buffer is empty? How to have the exact DCPS version number Re: How to have the exact DCPS version number Re: How to have the exact DCPS version number Re: How to have the exact DCPS version number Re: How to have the exact DCPS version number Re: How to have the exact DCPS version number Re: How to have the exact DCPS version number Re: How to have the exact DCPS version number Re: IP Clusters and security Re: Logikal Solutions Announces Logic Book Re: MicroVAX with KDA50, RQDX3 and KFQSA configuration ?? Re: Movie Promo for HP Partners Roundhouse in Nashua on Tuesday, May 22 May 22 M Re: Movie Promo for HP Partners Roundhouse in Nashua on Tuesday, May 22 May 22 M Re: OT: Logikal Solutions Announces Logic Book Re: OT: Logikal Solutions Announces Logic Book Re: OT: Logikal Solutions Announces Logic Book Re: OT: Polish language Re: Printers and ink (was: Shouldn't we be helping HP ?) Re: PRODUCT EXTRACT RELEASE_NOTES /DESTINATION Re: Shouldn't we be helping HP ? Re: Shouldn't we be helping HP ? Re: TCPIP programming (sockaddr_in question) [TCPIP] How to specify Reply-To address? ---------------------------------------------------------------------- Date: 16 May 2007 03:42:04 -0700 From: Neil Rieck Subject: Re: Another x86-64 price war is coming Message-ID: <1179312123.938287.304740@n59g2000hsh.googlegroups.com> On May 16, 12:30 am, JF Mezei wrote: > Neil Rieck wrote: > > In the most updated plan, Intel Quad-Core Core 2 Quad Q6600 (2.4GHz/ > > 4MB L2 x2/1066MHzFSB) will be further cut to $266, a second drop > > within 4 months since its release on March > > AMD is about to release a true quad core chip. Intel will follow shortly > thereafter with its own true quad core. (its current offering is a > combination of 2 dial cores in the same package). > > It is called competition. Intel no longer assumes it has automatic > rights to 90% of the market. So prices are diven down. Food for the market. > > Carly/Culry's original predictions of commodity chips for the enterprise > will come true. It just won't be that IA64 thing. Yep and let's hope HP has a skunk works working on a port of OpenVMS to x86-64. p.s. Attention HP: please don't tell me that you have no intention to do this. Just have it waiting in the wings when the axe falls. Neil Rieck Kitchener/Waterloo/Cambridge, Ontario, Canada. http://www3.sympatico.ca/n.rieck/ ------------------------------ Date: 16 May 2007 03:52:33 -0700 From: Neil Rieck Subject: Re: Another x86-64 price war is coming Message-ID: <1179312752.965566.170440@q23g2000hsg.googlegroups.com> On May 15, 10:42 pm, Neil Rieck wrote: > [...snip...] More info: http://www.dailytech.com/article.aspx?newsid=7293 Neil Rieck Kitchener/Waterloo/Cambridge, Ontario, Canada.http://www3.sympatico.ca/n.rieck/ ------------------------------ Date: 16 May 2007 11:45:42 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: Another x86-64 price war is coming Message-ID: <5b0976F2r33b2U1@mid.individual.net> In article <1179312123.938287.304740@n59g2000hsh.googlegroups.com>, Neil Rieck writes: > On May 16, 12:30 am, JF Mezei wrote: >> Neil Rieck wrote: >> > In the most updated plan, Intel Quad-Core Core 2 Quad Q6600 (2.4GHz/ >> > 4MB L2 x2/1066MHzFSB) will be further cut to $266, a second drop >> > within 4 months since its release on March >> >> AMD is about to release a true quad core chip. Intel will follow shortly >> thereafter with its own true quad core. (its current offering is a >> combination of 2 dial cores in the same package). >> >> It is called competition. Intel no longer assumes it has automatic >> rights to 90% of the market. So prices are diven down. Food for the market. >> >> Carly/Culry's original predictions of commodity chips for the enterprise >> will come true. It just won't be that IA64 thing. > > Yep and let's hope HP has a skunk works working on a port of OpenVMS > to x86-64. > > p.s. Attention HP: please don't tell me that you have no intention to > do this. Just have it waiting in the wings when the axe falls. You guys really need to give this a rest. HP got rid of all the people who would have been needed for such a project. When Carly said they burned their boats, she was not kidding. The natives have now driven the conquitadors back to the shore and are ready to drive them into the sea and slaughter the ones who can't swim. 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, 16 May 2007 10:37:42 -0400 From: Stephen Hoffman Subject: Re: Another x86-64 price war is coming Message-ID: Neil Rieck wrote: > On May 16, 12:30 am, JF Mezei wrote: >> Neil Rieck wrote: >>> In the most updated plan, Intel Quad-Core Core 2 Quad Q6600 (2.4GHz/ >>> 4MB L2 x2/1066MHzFSB) will be further cut to $266, a second drop >>> within 4 months since its release on March >> AMD is about to release a true quad core chip. Intel will follow shortly >> thereafter with its own true quad core. (its current offering is a >> combination of 2 dial cores in the same package). VAX 9000-like MCM-style mounting isn't as interesting as the speeds and feeds for the processor(s) involved. If done right, it's all just multiprocessing, after all. If not done right, you can toss as many cores and sockets at the design as you want, and aggregate performance remains static. Or it degrades. Depending on what part of the market you are interested in (whether as a buyer or as a vendor), either the system price is key, or how much can you feed through the design and where the bottleneck(s) lurk can be key. Few folks are purchasing microprocessors or components, after all. Discussing microprocessor and component prices is interesting in the same way that discussions of the price of a barrel of light sweet crude or pork-belly futures, or of how many gazillion tickets were sold for the opening weekend of the Blockbuster Movie De Jour, are interesting. If you're charged with keeping a manufacturing pipeline stoked otherwise purchasing or selling industrial-scale quantities, then you're interested. Otherwise, it's fodder for watercooler discussions. But I digress. With the various Intel 64 designs I've looked at, the traditional technical bottleneck appears to involve the FSB out through the northbridge; bandwidth through that has not matched that of AMD64 designs, nor that of the EV7 design. The oft-quoted current Intel FSB is 1.3 GHz, though I haven't seen nor calculated the width and latency discussed for that -- EV7 bandwidth was massive, and the latency among the processors was was very low. EV7: http://64.223.189.234/node/20 At some level, the system design inevitably goes from a uniform interconnection to non-uniform; from the on-chip multicore designs to the MCM-like shared-carrier designs, and to the local system interconnect to a switch- or cell-like design, or to a torus. Just considering the current-generation multicore processors, all multi-socket system designs have some non-uniform characteristics. Multicore and SMP: http://64.223.189.234/node/13 I've not looked at the Santa Rosa speeds and feeds beyond the 1.3 GHz FSB, and there's little real material available for the next-generation Intel CSI design as yet. There are details of the AMD64 design around. Given Intel retired the processor GHz marketing a while back, it would not surprise me to see Intel drop off the FSB GHz bus with the advent of any significant future change to the northbridge and related design used for the Intel chips. (I don't know if they plan that marketing change, but the underlying issues here appear very similar to marketing relative chip performance that doesn't scale with processor clock speed.) In aggregate, however, the hardware cost is something of interest for low-end buyers. This has not traditionally been the target for OpenVMS sales, and OpenVMS itself and its software and hardware ecosystem simply isn't suited for low-end users and applications. Microsoft Windows, Mac OS and Linux all have significant advantages in the low-end market. (If Sun gets off its collective corporate duff and mails me that DVD, I might or might not add Solaris to that list. But based on the last set of web client statistics I looked at, Windows owns it, Mac OS has some few seats, and everything else -- yes, including Linux -- is a rounding error. (Of course, even a rounding-error-sized market with good profits is a Good Thing.) OpenVMS and its applications simply aren't something that competes on hardware cost. The hardware cost is a rounding error in the whole product equation. The hardware cost of an AlphaServer GS1280 or SuperDome is one piece of the puzzle, and the other pieces tend to be (far) larger. This in the part of the computing market that measures its finances in cubic meters of cash per second. The other part of the equation is that the power available on the low end is increasing, so mechanisms such as the message-passing design of most Mac OS applications can potentially have some scaling advantages, for instance. The traditional low-end systems can and will continue to solve ever-larger problems, whether via grid or loosely-coupled designs. A port of OpenVMS to x86-64 looks technically feasible given the existence of four rings plus VM and of various other core features, though the low-level results will undoubtedly see differences from other platforms. The memory management uses segmentation, which means the page protections are gone; it's now protection on a range of pages. The memory management design for x86-64 looks rather nicer than that of x86-32 in certain regards. Simpler. Whether or not the expenditure involved with a port is a discussion of maximizing ROI, and a decision that HP owns. And something that HP ISVs would also have to decide. And yes, that HP OpenVMS customers would have to decide. >> It is called competition. Intel no longer assumes it has automatic >> rights to 90% of the market. So prices are diven down. Food for the market. >> >> Carly/Culry's original predictions of commodity chips for the enterprise >> will come true. It just won't be that IA64 thing. The prediction has been true for quite a while; the processor itself isn't the central distinguishing characteristic for computer products. Stuff further up the stack is more central. "Central" here meaning "far more expensive". For many applications, porting to and purchasing a new Integrity is typically cheaper than porting off. If we're discussing industrial-scale operations, you might or might not port to Integrity. For most folks that need to move an application, a newer (used) Alpha or an upgrade to Integrity is typically the cheapest ticket. > Yep and let's hope HP has a skunk works working on a port of OpenVMS > to x86-64. > > p.s. Attention HP: please don't tell me that you have no intention to > do this. Just have it waiting in the wings when the axe falls. Would I like to see OpenVMS on the x86-64 platform? Sure. Do I know if HP plans this port? No. Do I know if there would be sufficient ROI here for HP -- or for the ISVs, or for the customers -- to make a port justified? No. Conversely, x86-64 boxes are already widely available and are already running various applications, and with entirely functional operating systems and user environments. And Integrity boxes are available for folks that have applications based on OpenVMS -- and the Integrity boxes can and do work nicely, and also at prices below those of Alpha systems based on what I've seen. [All of this being blog fodder, of course.] -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ Date: Wed, 16 May 2007 07:32:16 -0700 From: "Tom Linden" Subject: Re: Another x86-64 price war is coming Message-ID: On Wed, 16 May 2007 07:37:42 -0700, Stephen Hoffman wrote: > Neil Rieck wrote: >> On May 16, 12:30 am, JF Mezei wrote: >>> Neil Rieck wrote: >>>> In the most updated plan, Intel Quad-Core Core 2 Quad Q6600 (2.4GHz/ >>>> 4MB L2 x2/1066MHzFSB) will be further cut to $266, a second drop >>>> within 4 months since its release on March >>> AMD is about to release a true quad core chip. Intel will follow >>> shortly >>> thereafter with its own true quad core. (its current offering is a >>> combination of 2 dial cores in the same package). > > VAX 9000-like MCM-style mounting isn't as interesting as the speeds > and feeds for the processor(s) involved. > > If done right, it's all just multiprocessing, after all. > > If not done right, you can toss as many cores and sockets at the > design as you want, and aggregate performance remains static. Or it > degrades. > > Depending on what part of the market you are interested in (whether > as a buyer or as a vendor), either the system price is key, or how much > can you feed through the design and where the bottleneck(s) lurk can be > key. > > Few folks are purchasing microprocessors or components, after all. > > Discussing microprocessor and component prices is interesting in the > same way that discussions of the price of a barrel of light sweet crude > or pork-belly futures, or of how many gazillion tickets were sold for > the opening weekend of the Blockbuster Movie De Jour, are interesting. > If you're charged with keeping a manufacturing pipeline stoked otherwise > purchasing or selling industrial-scale quantities, then you're > interested. Otherwise, it's fodder for watercooler discussions. But I > digress. > > With the various Intel 64 designs I've looked at, the traditional > technical bottleneck appears to involve the FSB out through the > northbridge; bandwidth through that has not matched that of AMD64 > designs, nor that of the EV7 design. The oft-quoted current Intel FSB > is 1.3 GHz, though I haven't seen nor calculated the width and latency > discussed for that -- EV7 bandwidth was massive, and the latency among > the processors was was very low. > > EV7: http://64.223.189.234/node/20 > > At some level, the system design inevitably goes from a uniform > interconnection to non-uniform; from the on-chip multicore designs to > the MCM-like shared-carrier designs, and to the local system > interconnect to a switch- or cell-like design, or to a torus. > > Just considering the current-generation multicore processors, all > multi-socket system designs have some non-uniform characteristics. > > Multicore and SMP: http://64.223.189.234/node/13 > > I've not looked at the Santa Rosa speeds and feeds beyond the 1.3 GHz > FSB, and there's little real material available for the next-generation > Intel CSI design as yet. There are details of the AMD64 design around. > > Given Intel retired the processor GHz marketing a while back, it > would not surprise me to see Intel drop off the FSB GHz bus with the > advent of any significant future change to the northbridge and related > design used for the Intel chips. (I don't know if they plan that > marketing change, but the underlying issues here appear very similar to > marketing relative chip performance that doesn't scale with processor > clock speed.) > > In aggregate, however, the hardware cost is something of interest for > low-end buyers. This has not traditionally been the target for OpenVMS > sales, and OpenVMS itself and its software and hardware ecosystem simply > isn't suited for low-end users and applications. Microsoft Windows, Mac > OS and Linux all have significant advantages in the low-end market. (If > Sun gets off its collective corporate duff and mails me that DVD, I > might or might not add Solaris to that list. But based on the last set > of web client statistics I looked at, Windows owns it, Mac OS has some > few seats, and everything else -- yes, including Linux -- is a rounding > error. (Of course, even a rounding-error-sized market with good profits > is a Good Thing.) > > OpenVMS and its applications simply aren't something that competes on > hardware cost. The hardware cost is a rounding error in the whole > product equation. The hardware cost of an AlphaServer GS1280 or > SuperDome is one piece of the puzzle, and the other pieces tend to be > (far) larger. This in the part of the computing market that measures > its finances in cubic meters of cash per second. > > The other part of the equation is that the power available on the low > end is increasing, so mechanisms such as the message-passing design of > most Mac OS applications can potentially have some scaling advantages, > for instance. The traditional low-end systems can and will continue to > solve ever-larger problems, whether via grid or loosely-coupled designs. > > A port of OpenVMS to x86-64 looks technically feasible given the > existence of four rings plus VM and of various other core features, > though the low-level results will undoubtedly see differences from other > platforms. The memory management uses segmentation, which means the > page protections are gone; it's now protection on a range of pages. The > memory management design for x86-64 looks rather nicer than that of > x86-32 in certain regards. Simpler. > > Whether or not the expenditure involved with a port is a discussion > of maximizing ROI, and a decision that HP owns. And something that HP > ISVs would also have to decide. And yes, that HP OpenVMS customers > would have to decide. > > >>> It is called competition. Intel no longer assumes it has automatic >>> rights to 90% of the market. So prices are diven down. Food for the >>> market. >>> >>> Carly/Culry's original predictions of commodity chips for the >>> enterprise >>> will come true. It just won't be that IA64 thing. > > > The prediction has been true for quite a while; the processor itself > isn't the central distinguishing characteristic for computer products. > Stuff further up the stack is more central. "Central" here meaning "far > more expensive". For many applications, porting to and purchasing a new > Integrity is typically cheaper than porting off. If we're discussing > industrial-scale operations, you might or might not port to Integrity. > For most folks that need to move an application, a newer (used) Alpha or > an upgrade to Integrity is typically the cheapest ticket. Not for my customers, Alpha is the only option. > > >> Yep and let's hope HP has a skunk works working on a port of OpenVMS >> to x86-64. >> p.s. Attention HP: please don't tell me that you have no intention to >> do this. Just have it waiting in the wings when the axe falls. > > > Would I like to see OpenVMS on the x86-64 platform? Sure. > > Do I know if HP plans this port? No. > > Do I know if there would be sufficient ROI here for HP -- or for the > ISVs, or for the customers -- to make a port justified? No. > > Conversely, x86-64 boxes are already widely available and are already > running various applications, and with entirely functional operating > systems and user environments. > > And Integrity boxes are available for folks that have applications > based on OpenVMS -- and the Integrity boxes can and do work nicely, and > also at prices below those of Alpha systems based on what I've seen. > > [All of this being blog fodder, of course.] > > > -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ------------------------------ Date: Tue, 15 May 2007 06:05:55 -0400 From: "Neil Rieck" Subject: Another x86-64 price war is coming Message-ID: <4649799d$0$16410$88260bb3@free.teranews.com> According to this article... http://www.hkepc.com/bbs/itnews.php?tid=789466 ...another price war is brewing between Intel and AMD and only (x86-64) customers will benefit. Intel's prices are scheduled to drop on July-22. ### In the most updated plan, Intel Quad-Core Core 2 Quad Q6600 (2.4GHz/4MB L2 x2/1066MHzFSB) will be further cut to $266, a second drop within 4 months since its release on March with 68.7% accumulated price drop. For the original price segment of Core 2 Quad Q6600, now it will be replaced by a new model Quad Q6700 (2.66GHz/4MB L2 x2/1066MHzFSB), pricing at $530. ### Wow a 68% drop in price. This will result in market place pressures on that Itanic thing. Neil Rieck Kitchener/Waterloo/Cambridge, Ontario, Canada. http://www3.sympatico.ca/n.rieck/ -- Posted via a free Usenet account from http://www.teranews.com ------------------------------ Date: Wed, 16 May 2007 11:46:38 -0400 From: Stephen Hoffman Subject: Re: Another x86-64 price war is coming Message-ID: Tom Linden wrote: > Not for my customers, Alpha is the only option. As I had wrote, "...a newer (used) Alpha, or..." There are always options... In your case, this would involve the creation of or the licensing of a code generator for IA-64. (I haven't looked to see if Intel is licensing this stuff, and I would tend to expect you've already discussed licensing GEM with the folks at HP.) Potentially creating an open-source version of the current PL/I front-end, tied to the GCC code generation capabilities, and selling support and services for same. Haven't looked to see if there's a PL/I for IA-64 around, beyond http://pl1gcc.sourceforge.net/ Or you could conceivably sell rights and/or partner with an organization that can assist with the port of PL/I to IA-64. But all that is your call. In the case of current PL/I users, continued use of Alpha is an obvious and easy option. There will continue to be a viable market for used Alpha systems for some years. But Alpha isn't the only option here. Porting off PL/I is certainly an option, as is porting off of OpenVMS and to another platform with PL/I. Or both. The IBM AIX kernel was ported off of PL/I at V3, IIRC. In some cases this port will be viable and appropriate, and in others it will not be economical. The hunks of PL/I that were once within OpenVMS were ported over into C, IIRC. It may well be economical for a sufficiently large user to contract for or to custom-create a PL/I compiler for the target platform, or to contract for the creation of translations tools, as well. (Or to fund some folks to work on the pl1gcc stuff, for that matter.) SRI was offering PL/I to C/C++ translation services for OpenVMS customers. There are some details of that service here: http://h71000.www7.hp.com/openvms/integrity/transition/app_tools.html Again, there are always options. -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ Date: Wed, 16 May 2007 09:00:50 -0700 From: "Tom Linden" Subject: Re: Another x86-64 price war is coming Message-ID: On Wed, 16 May 2007 08:46:38 -0700, Stephen Hoffman wrote: > Tom Linden wrote: > >> Not for my customers, Alpha is the only option. > > As I had wrote, "...a newer (used) Alpha, or..." > > There are always options... > > In your case, this would involve the creation of or the licensing of > a code generator for IA-64. (I haven't looked to see if Intel is > licensing this stuff, and I would tend to expect you've already > discussed licensing GEM with the folks at HP. I have written a number of code generators over the years and it doesn't make any sense to write a new one when GEM has already the PL/I support. > > Potentially creating an open-source version of the current PL/I > front-end, tied to the GCC code generation capabilities, and selling > support and services for same. Haven't looked to see if there's a PL/I > for IA-64 around, beyond http://pl1gcc.sourceforge.net/ pl1gcc is so far from reality that it will likely never result in anything > > Or you could conceivably sell rights and/or partner with an > organization that can assist with the port of PL/I to IA-64. Any ideas there? > > But all that is your call. > > In the case of current PL/I users, continued use of Alpha is an > obvious and easy option. There will continue to be a viable market for > used Alpha systems for some years. True enough, we have committed to 2012 > > But Alpha isn't the only option here. Porting off PL/I is certainly > an option, as is porting off of OpenVMS and to another platform with > PL/I. Or both. > > The IBM AIX kernel was ported off of PL/I at V3, IIRC. Well, it wasn't PL/I, but PL8, a variant of PL/I and I thought it was still used in the Kernel. Most of their languages as well as backend are in PL8 > > In some cases this port will be viable and appropriate, and in others > it will not be economical. The hunks of PL/I that were once within > OpenVMS were ported over into C, IIRC. What a waste of effort. > > It may well be economical for a sufficiently large user to contract > for or to custom-create a PL/I compiler for the target platform, or to > contract for the creation of translations tools, as well. (Or to fund > some folks to work on the pl1gcc stuff, for that matter.) > > SRI was offering PL/I to C/C++ translation services for OpenVMS > customers. There are some details of that service here: Translating from a high-level to a low-level language is not easy. > > http://h71000.www7.hp.com/openvms/integrity/transition/app_tools.html > > Again, there are always options. > > -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ------------------------------ Date: Wed, 16 May 2007 09:06:13 +0200 From: Martin Krischik Subject: Re: Digital *is* a Software Company? (Was Re: Sun Studio 11 (Solaris IDE)) IDE)) Message-ID: <464aad66$1@news.post.ch> Richard B. Gilbert schrieb: > Bill Gunshannon wrote: >> In article , >> "John Smith" writes: >> >>> Arne Vajhøj wrote: >>> >>>> Martin Krischik wrote: >>>> >>>>> http://www.tiobe.com/tpci.htm >>>> >>>> I know that one reader here will think one language is >>>> missing ... >>>> >>> >>> APL ??? >> Jovial ??? > Coral? Same advice as for the BLISS supporter: Start APL/Jovial/Coral Websites, APL/Jovial/Coral Blogs, Discuss APL/Jovial/Coral on the usenet - and make sure the phrase "APL/Jovial/Coral Programming" is used as well. Once APL/Jovial/Coral makes it into the Top 100 then you are in. And for say place 17 you only need about 264,000 Google hits ;-). Martin PS: I belive that APL had once been in the Top 100 - but it must have dropped out since. -- Martin Krischik ------------------------------ Date: 16 May 2007 04:42:38 -0700 From: Fatz Subject: Re: How can I get scanf to terminate on when the buffer is empty? Message-ID: <1179315758.861668.209430@e65g2000hsc.googlegroups.com> > scanf("%[^\n]\n", buf) Nice as this is, it just reverses the problem. When text is entered, a is then echoed. I've gone with gets and sscanf in a wrapper. Thanks to the other posters their contributions, including the "hire a programmer" guy, whose comment whilst not being at all funny wasn't helpful either. Fatz. ------------------------------ Date: Wed, 16 May 2007 14:49:48 +0200 From: "Michel HERRSCHER" Subject: How to have the exact DCPS version number Message-ID: Hello, I have to check the version number of a running OpenVms Alpha. the command product show product * give that : ----------------------------------- ----------- ------------ PRODUCT KIT TYPE STATE ----------------------------------- ----------- ------------ CPQ AXPVMS CSWS T1.2 Full LP Installed CPQ AXPVMS CSWS_PERL T1.1 Full LP Installed CPQ AXPVMS CSWS_PHP T1.0 Full LP Installed CPQ AXPVMS PERL T5.6-1 Full LP Installed DEC AXPVMS BNU V2.1 Full LP Installed DEC AXPVMS DECNET_OSI V7.2-1 Full LP Installed DEC AXPVMS DWMOTIF V1.2-5 Full LP Installed DEC AXPVMS FORRTL V7.3-1 Full LP Installed DEC AXPVMS FORTRAN V7.3-1 Full LP Installed DEC AXPVMS HYPERHELP V5.1-2 Full LP Installed DEC AXPVMS NS_NAV_EXPORT V3.3 Full LP Installed DEC AXPVMS ODL V2.1 Platform Installed DEC AXPVMS OPENVMS V7.2-1 Platform Installed DEC AXPVMS TCPIP V5.0-10 Full LP Installed DEC AXPVMS VMS V7.2-1 Oper System Installed ----------------------------------- ----------- ------------ no trace of DCPS.... How to find this Thanks for your help. -- Michel HERRSCHER ------------------------------ Date: Wed, 16 May 2007 09:05:43 -0400 From: norm.raphael@metso.com Subject: Re: How to have the exact DCPS version number Message-ID: Try $ PRODUCT SHOW HISTORY * "Michel HERRSCHER" wrote on 05/16/2007 08:49:48 AM: > Hello, > I have to check the version number of a running OpenVms Alpha. > > the command > product show product * > > give that : > > ----------------------------------- ----------- ------------ > PRODUCT KIT TYPE STATE > ----------------------------------- ----------- ------------ > CPQ AXPVMS CSWS T1.2 Full LP Installed > CPQ AXPVMS CSWS_PERL T1.1 Full LP Installed > CPQ AXPVMS CSWS_PHP T1.0 Full LP Installed > CPQ AXPVMS PERL T5.6-1 Full LP Installed > DEC AXPVMS BNU V2.1 Full LP Installed > DEC AXPVMS DECNET_OSI V7.2-1 Full LP Installed > DEC AXPVMS DWMOTIF V1.2-5 Full LP Installed > DEC AXPVMS FORRTL V7.3-1 Full LP Installed > DEC AXPVMS FORTRAN V7.3-1 Full LP Installed > DEC AXPVMS HYPERHELP V5.1-2 Full LP Installed > DEC AXPVMS NS_NAV_EXPORT V3.3 Full LP Installed > DEC AXPVMS ODL V2.1 Platform Installed > DEC AXPVMS OPENVMS V7.2-1 Platform Installed > DEC AXPVMS TCPIP V5.0-10 Full LP Installed > DEC AXPVMS VMS V7.2-1 Oper System Installed > ----------------------------------- ----------- ------------ > > no trace of DCPS.... > > > How to find this > > Thanks for your help. > -- > Michel HERRSCHER > > ------------------------------ Date: Wed, 16 May 2007 09:22:39 -0400 From: Stephen Hoffman Subject: Re: How to have the exact DCPS version number Message-ID: Michel HERRSCHER wrote: > I have to check the version number of a running OpenVms Alpha. > > the command product show product * ... > no trace of DCPS.... Short Answer: Look in SYS$UPDATE:VMSINSTAL.HISTORY Long Answer: The DECprint Supervisor DCPS package switched from VMSINSTAL kit installations to PCSI installations at the DCPS V2.4 release, IIRC. Given the comparative antiquity of the (other) product versions shown in the PCSI display, it's quite probable this system is also running an older release of DCPS. I'd look over in SYS$UPDATE:VMSINSTAL.HISTORY for the installation data. That file is the other place where these installation records are written. -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ Date: Wed, 16 May 2007 09:22:54 -0400 From: Paul Anderson Subject: Re: How to have the exact DCPS version number Message-ID: In article , "Michel HERRSCHER" wrote: > the command > product show product * > ...snip... > > no trace of DCPS.... > > How to find this DCPS started using PCSI to install with V2.4, so if you are running an earlier version, you would have installed it with VMSINSTAL, and therefore DCPS would not show up with a PRODUCT SHOW PRODUCT command. Starting with DCPS V2.2, the logical name DCPS$VERSION is defined when DCPS starts. If you still have no answer, you can do an $ ANALYZE /IMAGE /SELECT=IDENTIFICATION SYS$SYSTEM:DCPS$SMB.EXE to get the version number. If your version of OpenVMS is too old for the /SELECT qualifier, just do an ANALYZE /IMAGE /INTERACTIVE instead and look for the "image file identification". Paul -- Paul Anderson OpenVMS Engineering Hewlett-Packard Company ------------------------------ Date: 16 May 2007 15:37:11 +0200 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOeGER) Subject: Re: How to have the exact DCPS version number Message-ID: <464b2527$1@news.langstoeger.at> In article , "Michel HERRSCHER" writes: >I have to check the version number of a running OpenVms Alpha. The version of what? VMS ($ SHOW SYS/NOPROC or PROD SHO PROD VMS or F$GETS("VERSION") or ...) or DCPS ($ @SYS$STARTUP:DCPS$GET_VERSION and $ SHOW LOG DCPS_VERSION or $ ANAL/IMAG/SELE=IDEN SYS$SYSTEM:DCPS$SMB or $ SEAR SYS$UPDATE:VMSINSTAL.HISTORY DCPS or $ DIR SYS$HELP:*DCPS*.REL* or ...)? -- Peter "EPLAN" LANGSTOEGER Network and OpenVMS system specialist E-mail peter@langstoeger.at A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist ------------------------------ Date: 16 May 2007 15:42:29 +0200 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOeGER) Subject: Re: How to have the exact DCPS version number Message-ID: <464b2665$1@news.langstoeger.at> In article , Paul Anderson writes: >Starting with DCPS V2.2, the logical name DCPS$VERSION is defined when >DCPS starts. I don't see it on my systems. I do see however a (process) logical DCPS_VERSION and only after I ran @SYS$STARTUP:DCPS$GET_VERSION Please clarify -- Peter "EPLAN" LANGSTOEGER Network and OpenVMS system specialist E-mail peter@langstoeger.at A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist ------------------------------ Date: Wed, 16 May 2007 11:15:49 -0400 From: Paul Anderson Subject: Re: How to have the exact DCPS version number Message-ID: In article <464b2665$1@news.langstoeger.at>, peter@langstoeger.at (Peter 'EPLAN' LANGSTOeGER) wrote: > In article , Paul > Anderson writes: > >Starting with DCPS V2.2, the logical name DCPS$VERSION is defined when > >DCPS starts. > > I don't see it on my systems. > > I do see however a (process) logical DCPS_VERSION and only after I ran > @SYS$STARTUP:DCPS$GET_VERSION > > Please clarify DCPS$GET_VERSION defines the process logical name DCPS_VERSION and is run by DCPS$STARTUP and DCPS$IVP. It's DCPS$STARTUP that defines the system logical name DCPS$VERSION so the logical name will exist only on those systems that start DCPS with DCPS$STARTUP. Paul -- Paul Anderson OpenVMS Engineering Hewlett-Packard Company ------------------------------ Date: Wed, 16 May 2007 18:39:32 +0200 From: "Michel HERRSCHER" Subject: Re: How to have the exact DCPS version number Message-ID: Dans un message Stephen Hoffman disait : > Michel HERRSCHER wrote: > >> I have to check the version number of a running OpenVms Alpha. >> >> the command product show product * > ... >> no trace of DCPS.... > > Short Answer: Look in SYS$UPDATE:VMSINSTAL.HISTORY > > Long Answer: The DECprint Supervisor DCPS package switched from > VMSINSTAL kit installations to PCSI installations at the DCPS V2.4 > release, IIRC. Given the comparative antiquity of the (other) product > versions shown in the PCSI display, it's quite probable this system is > also running an older release of DCPS. > > I'd look over in SYS$UPDATE:VMSINSTAL.HISTORY for the installation data. > That file is the other place where these installation records are > written. Found here : it is 2.0 thanks to all of you -- Michel HERRSCHER CONSULTANT Tel : +33450870912 http://www.mhc.herrscher.fr Président de WINDASSO - Association des utilisateurs WxxDEV(c) http://www.windasso.org ------------------------------ Date: Wed, 16 May 2007 11:19:01 -0400 From: Stephen Hoffman Subject: Re: IP Clusters and security Message-ID: JF Mezei wrote: > Doc wrote: >> The sooner you have that the better. Hobbyists can start having >> competitions over who can form the largest geographical cluster. :) One could conceivably operate a cluster within the passenger cabin of an aircraft, for instance, assuming an IR connection was available. (I haven't looked to see if IR is permissible under FAA regulations, though I'd tend to expect most regulations in this area would target emissions in the radio-frequency portion of the spectrum.) > Perhaps what is needed is a cluster of clusters, where each cluster > defines what resources the supercluster has access to. The analog here being some sort of Kerberos or LDAP distributed authentication. > Right now, clusters are protected by physical boundary of an ethernet > and physical cables to disk drives. All unencrypted traffic. Not just that of the cluster. > But once you open it up to IP, it will open a whole can of worms in > terms of hackers trying to join a cluster. If hackers get hodl of > cluster_authorize.dat, they can then join the cluster and have access to > all the data on any disk. If a cracker gains access to the wire and the traffic is unencrypted, the cracker has all necessary access. Having the full contents of CLUSTER_AUTHORIZE in your possession is not centrally relevant; if an attacker has wire-level (unencrypted) or WiFi-level (unencrypted or WEP) access to the data links, then the configuration is already pwned. This concern isn't specific to IP, in other words. As for clustering and its (current) use of IP, various SANs already operate over IP. FCIP is in use at a number of OpenVMS sites. The host-to-host communications do not traverse IP, but the FC storage does. -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ Date: Wed, 16 May 2007 05:31:07 -0400 From: "Neil Rieck" Subject: Re: Logikal Solutions Announces Logic Book Message-ID: <464ac2f0$0$31271$88260bb3@free.teranews.com> wrote in message news:1179243904.775113.99780@n59g2000hsh.googlegroups.com... > This is slightly off-topic, but some of you have asked about it. > There are mentions of VMS in it, but the book is not specific to > OpenVMS. > > "The Minimum You Need to Know About Logic to Work in IT" > > Teaches newbies the long lost skills of flowcharting, pseudocoding, > and how to solve problems without writing a single line of source. > You can read more about it at http://theminimumyouneedtoknow.com. > > Thank you, > Roland > Your books are well written and I've just ordered a copy of this one for my department. Thanks for your efforts. Neil Rieck Kitchener/Waterloo/Cambridge, Ontario, Canada. http://www3.sympatico.ca/n.rieck/ -- Posted via a free Usenet account from http://www.teranews.com ------------------------------ Date: Wed, 16 May 2007 11:02:58 -0400 From: Stephen Hoffman Subject: Re: MicroVAX with KDA50, RQDX3 and KFQSA configuration ?? Message-ID: Bob Armstrong wrote: > I have a MicroVAX-3900 system that already has a KDA50 (CSR 772150 - > primary MSCP controller) and a RQDX3 (secondary MSCP - CSR 760334) and > I want to add a KFQSA DSSI controller with five RFxx drives (yes, it's > a big system :-). I've posted up some info on Q-bus configuration a while bac, and have recently added some text around the KFQSA. http://64.223.189.234/node/10 The KFQSA creates one UQSSP controller for each DSSI IDE, so adding or removing DSSI ISE disks can mean a trip through the console CONFIG or the SYSGEN CONFIG tool, and a trip through all of the modules with a lower priority. The CPU-integrated DSSI found on Spitfire, Pele and later systems is easier to use in this regard; on the VAX 4000 series boxes. With these, you can add or remove DSSI disk ISEs (and DSSI tape ISEs) without having to manage and potentially reconfigure the Q-bus. -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ Date: Tue, 15 May 2007 07:42:30 +0800 From: Tim Sneddon Subject: Re: Movie Promo for HP Partners Roundhouse in Nashua on Tuesday, May 22 May 22 M Message-ID: <4648e7d4$0$16297$88260bb3@free.teranews.com> DeanW wrote: > On 5/14/07, JF Mezei wrote: >> William Webb wrote: >> > I'm not so sure that Blade Runner is such a good selection. >> > Remember, OpenVMS turns 30 this year... >> >> Blade Runner != Logan's Run. > > The movie "Blade Runner' != 'BladeRunner'. The latter is a book by > Alan E. Nourse, about a society that embraces Eugenics as a solution > to the deterorating gene pool (caused by medicine allowing people with > bad genes living long enough to breed, where before they would die > out) . > > I'd be seriously surprised to see that made into a movie... > > How "Do Androids Dream of Electric Sheep" got retitled "Blade Runner" > has always confused me. > According to Wikipedia the name "Blade Runner" was taken from the book by Alan E. Nourse. Read the article here for more: http://en.wikipedia.org/wiki/The_Bladerunner Regards, Tim. -- Posted via a free Usenet account from http://www.teranews.com ------------------------------ Date: Thu, 17 May 2007 00:08:40 +0800 From: Paul Repacholi Subject: Re: Movie Promo for HP Partners Roundhouse in Nashua on Tuesday, May 22 May 22 M Message-ID: <877ir8hhtj.fsf@k9.prep.synonet.com> DeanW writes: > How "Do Androids Dream of Electric Sheep" got retitled "Blade > Runner" has always confused me. It didn't. ADES was the basis for the screen play and also the novel Blade Runner by Jetter(?) He also did Replicant Night and Edge of Human as follow ons. ------------------------------ Date: 16 May 2007 01:35:57 -0700 From: Dave Gullen Subject: Re: OT: Logikal Solutions Announces Logic Book Message-ID: <1179304557.280485.85800@o5g2000hsb.googlegroups.com> Perhaps we're all forgetting how slow things could be in the past, booking cpu time, being charged for it, overnight compilations, trying to do everything on one VT52 screen instead of all the nice Telnet windows we now have, working within disk quotas etc etc, maybe even working with punch-cards and teletypes. All emphasising the need to get it right first time, hence the need for a lot of off-line and up- front design. So I think there's an element of truth in saying mcuh of the old ways are not needed. That said, any coding I do these days still starts with some written design, not very formal, but it is there. I never had any 'proper' IT training, it was all apprentice-style, looking over shoulders an sitting next to people. I had my chance. Back in 1978 at Uni, studying to be a Plant Biologist, I chose geology over computing as my second subject thinking 'I will probably never use one.' Make God laugh by telling him your plans, as they say. Now my son is doing his finals in an IT and AI course. He's been pretty surprised about how many of his fellow students have no idea about modular coding and other skills, struggling with the great monolithic things they've written on the fly. ------------------------------ Date: 16 May 2007 02:55:45 -0700 From: Ian Miller Subject: Re: OT: Logikal Solutions Announces Logic Book Message-ID: <1179309345.468222.246740@u30g2000hsc.googlegroups.com> The link on island web site for world wide shipping is not correct. I have emailed them. ------------------------------ Date: 16 May 2007 11:52:58 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: OT: Logikal Solutions Announces Logic Book Message-ID: <5b09kpF2r33b2U2@mid.individual.net> In article <1179304557.280485.85800@o5g2000hsb.googlegroups.com>, Dave Gullen writes: > Perhaps we're all forgetting how slow things could be in the past, > booking cpu time, being charged for it, overnight compilations, trying > to do everything on one VT52 screen instead of all the nice Telnet > windows we now have, working within disk quotas etc etc, maybe even > working with punch-cards and teletypes. All emphasising the need to > get it right first time, hence the need for a lot of off-line and up- > front design. Oh, right, no reason to get it right the first time. Tell me again that it is the fault of the C language that we have all this crap software floating around? Can you imagine if Boeing took that attitude to engineering? "Don't worry about getting it right the first time, just get it in the air and let's see what happens!" Is it any wonder that some places (like Pennsylvania) refuse to let software people use the term "Engineer" to describe themselves? > > So I think there's an element of truth in saying mcuh of the old ways > are not needed. That said, any coding I do these days still starts > with some written design, not very formal, but it is there. > > I never had any 'proper' IT training, Yeah, that's rather obvious from your statements above. But don't feel bad, the academic world has caught up to you. :-) > it was all apprentice-style, > looking over shoulders an sitting next to people. I had my chance. > Back in 1978 at Uni, studying to be a Plant Biologist, I chose geology > over computing as my second subject thinking 'I will probably never > use one.' Make God laugh by telling him your plans, as they say. Now > my son is doing his finals in an IT and AI course. He's been pretty > surprised about how many of his fellow students have no idea about > modular coding and other skills, struggling with the great monolithic > things they've written on the fly. And you still stick to the idea that design before coding is "not necessary"? I really need to get back into the programming game. Seems like the majority today offer no competition. 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: 16 May 2007 07:50:54 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: OT: Polish language Message-ID: In article , "Tom Linden" writes: > On Tue, 15 May 2007 14:33:48 -0700, Bob Koehler > wrote: > >> In article , "Tom Linden" >> writes: >>> >>> cabbage cheese, last phonem of the first word with first of the second, >>> now try to >>> isolate them >> >> IMHO you have some pretty odd cabbage. >> > You know, I meant to write cottage cheese and from some reason it > became cabbage cheese, I guess I am guilty of ethnic profiling. > Yeah, but I was still left trying to figure out the cheese who's name ended in a sh sound (or is the sh in question a phoneme for the English j)? ------------------------------ Date: Wed, 16 May 2007 09:26:05 -0600 From: Keith Parris Subject: Re: Printers and ink (was: Shouldn't we be helping HP ?) Message-ID: Dr. Dweeb wrote: > HP are no better My HP printer warns me it's out of ink a good while before the ink actually stops flowing, but it continues to happily print away until the last drop runs out. ------------------------------ Date: 16 May 2007 04:08:22 -0700 From: Georgepag Subject: Re: PRODUCT EXTRACT RELEASE_NOTES /DESTINATION Message-ID: <1179313702.153144.46930@k79g2000hse.googlegroups.com> The "PRODUCT EXTRACT ** /DESTINATION = " command works for every type of file in a patch kit, except the Release Notes. The tool that creates this part of the documentation has been updated to reflect reality and future patch kits will have the correct command syntax. I'm also reviewing any other PRODUCT commands in the docs to make sure they work as expected, not as assumed. Peter, I don't remember this coming up before. George Pagliarulo ECO Release Process OpenVMS Sustaining Engineering On May 13, 2:51 pm, p...@langstoeger.at (Peter 'EPLAN' LANGSTOeGER) wrote: > In article <464728ef$0$20101$ec3e2...@news.usenetmonster.com>, "Jilly" writes: > >/DESTINATION is used when installing a product. Thanks for reporting this > >issue, it will be officially reported to the patch maintainers. > > This was reported more than once in the past. (At least once by me). > I hope this now leads finally to a fix... > > -- > Peter "EPLAN" LANGSTOEGER > Network and OpenVMS system specialist > E-mail p...@langstoeger.at > A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist ------------------------------ Date: Wed, 16 May 2007 08:05:53 +0200 From: "Dr. Dweeb" Subject: Re: Shouldn't we be helping HP ? Message-ID: <464a9e29$0$7605$157c6196@dreader2.cybercity.dk> David J Dachtera wrote: > "Dr. Dweeb" wrote: >> >> genius@marblecliff.com wrote: >>> On May 11, 12:59 pm, JF Mezei wrote: >>>> Is it really worth fighting against HP for the survival of VMS ? >>>> >>>> What would happen if the VMS community were to start to help HP in >>>> very visible and public ways and convince the press and people that >>>> HP is truly winding down VMS and expecting people to switch to >>>> HP-UX ? >>>> >>>> The community has been fighting actively for the last 15 years, and >>>> while the various owners may not have had the guts to officially >>>> retire VMS, the community has not been succesful at changing the >>>> owner's minds on the concept of promoting and growing VMS. >>>> >>>> The Cerner bit about moving from VMS to HP-UX really shows that the >>>> Stallards of HP are having they ways and that the original May 7th >>>> 2002 memo has always been HP's strategy towards VMS and that HP has >>>> worked behind the scenes to slowly implement it. >>>> >>>> is it really worth fighting ? >>>> >>>> When you consider that many VMS engineers are leaving one by one, >>>> (like rats leaving a sinking ship), and you consider the Cerner >>>> issue, perhaps VMS is now truly terminal ? >>>> >>>> VMS has been attacked by the Palmer cancer, by Compaq and now folks >>>> like Stallard et all at HP. The community may have been able to >>>> slow the cancer's growth, but eventually it does grow to a point >>>> where you can't control its downfall anymore, at which point, you >>>> give the patient morphine for a peaceful death. >>>> >>>> When it gets to that point, you do not wish to prolong life. >>>> >>>> Is there really a point in fighting for VMS ? >>> >>> they should not be lying to customers! And if HP does not want >>> VMS then you should tell them to sell it to someone who has >>> the goal of making it the number one os where it should be ... >>> >>> you tell them like we have that we have a lot invested in vms and >>> we are not leaving, and if forced to we will go to IBM and NEVER >>> buy another HP product (incl. ink cartridges) again! >> >> Well, donøt buy an Epson either. I just printed several hundred >> black text pages, it now tells me my 5 colour cartridges are empty >> and will print nothing. >> >> ALL printer manufacturers are thieves and rogues - sadly there are >> no good choices. > > Laser printer for B&W? I have a RX600 - if you see what that is, you will understand that I need an all-in-one solution. Anyway, the fact I needed to print a few contracts does not excuse the Epson design that forces you to buy ink !!! Dweeb ------------------------------ Date: 16 May 2007 07:52:01 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Shouldn't we be helping HP ? Message-ID: <65Zp14VAvrP0@eisner.encompasserve.org> In article <464a56be$0$7611$157c6196@dreader2.cybercity.dk>, "Dr. Dweeb" writes: > JF Mezei wrote: >> Is there really a point in fighting for VMS ? > > Nope. I have bailed for good after 20+ years - cest la vie Then why are you here? (Not meaning to chase you away.) ------------------------------ Date: Wed, 16 May 2007 10:10:05 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: TCPIP programming (sockaddr_in question) Message-ID: <00A67B09.4FAB7135@SendSpamHere.ORG> In article , "John Gemignani, Jr." writes: > > > > wrote in message >news:00A67A7C.E34FD775@SendSpamHere.ORG... >> In article <00A67A68.F7818E9B@SendSpamHere.ORG>, VAXman- >> @SendSpamHere.ORG writes: >>>{...snip...} >> >> A little more info... the socket name structures are documented on section >> 5.5 of >> the HP TCPIP Services "Sockets API and System Services Programming"; >> particularly >> in figures 5.8, 5.9 and 5.10. >> >> When using the IO$_SENSEMODE, is there anyway to enforce one format over >> another? >> >> -- >> VAXman- A Bored Certified VMS Kernel Mode Hacker >> VAXman(at)TMESIS(dot)COM >> >> "Well my son, life is like a beanstalk, isn't it?" > >I coded up the QIO interface when TCPIP added support for IPv6. This >required the BSD 4.4 interface which included the new length field. To use >the BSD 4.4 interface (SIN44$), you need to set a special bit in the QIO >modifiers. I think it was something like the IO$M_EXTEND bit. Otherwise a >BSD 4.3 block (SIN$) is returned. I have just IO$_ACPCONTROL and I am getting back a SIN6$ structure without the use of the IO$M_EXTEND modifier bit. >Note how the data is encoded ... the old 4.3 SIN had a 16-bit address >family. The 4.4 SIN carves this into an 8-bit length and 8-bit family and >can return IPv4 or IPv6 addresses. The SIN6 overlays the SIN44 and describes >the IPv6 details. > >Don't set extend and you get a SIN$. Set extend and you get a SIN44$. Check >the SIN44$B_FAMILY and if it's AF_SIN6 (TCPIP$C_SIN6?) then it's a SIN6. >Keep in mind that IPv4 addresses can be encoded in IPv6 format. Not so in my case. >When compiling C modules, you select SIN44 by including the following line >before your includes (check the underscores): > >#define _SOCKADDR_LEN > >Sorry that I can't recall the exact modifier, but it should not be hard to >find. I'm looking at the first byte nor (SIN44$B_LEN/SIN6$B_LEN) to determine the structure being returned. The documentation would seem to indicate that the IO$M_EXTEND modifier bit is the decision maker but I am getting back a SIN6$ structure on V8.3 with HP TCP/IP Services for OpenVMS Alpha Version V5.6. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" ------------------------------ Date: 16 May 2007 15:52:24 +0200 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOeGER) Subject: [TCPIP] How to specify Reply-To address? Message-ID: <464b28b8$1@news.langstoeger.at> I know of the TCPIP$SMTP_FROM logical to specify my own "From:" address (eg. Firstname.LASTNAME@domain.name instead of username@domain.name) but I still don't know how to specify a (different) "Reply-To:" addr IN ADDITION. Is this really (still) not possible in (vanilla) TCPIP ? (In MX you define a MX_REPLY_TO logical) TIA -EPLAN -- Peter "EPLAN" LANGSTOEGER Network and OpenVMS system specialist E-mail peter@langstoeger.at A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist ------------------------------ End of INFO-VAX 2007.268 ************************