1 INFO-VAX	Fri, 09 Jun 2006	Volume 2006 : Issue 318       Contents:" Re: Compiling Problem with LibCurl" Re: Compiling Problem with LibCurl" Re: Compiling Problem with LibCurl HSJ 50 patches Re: Intel selling Itanium? Re: Intel selling Itanium?= OT: IT glitch results in Cadbury chocolate glut  (SAP again!) 2 Re: OT: Sun release 8-socket/16-way SMP X64 server" RSA FOB/Device Support for OpenVMS& Re: RSA FOB/Device Support for OpenVMS3 Re: SimH 3.6-0 (problems compiling VAX using MinGW) ( Re: Wanted:MAIL.MAI structure definition( Re: Wanted:MAIL.MAI structure definition  F ----------------------------------------------------------------------   Date: 8 Jun 2006 18:40:55 -0500 4 From: kuhrt.nospammy@encompasserve.org (Marty Kuhrt)+ Subject: Re: Compiling Problem with LibCurl 3 Message-ID: <XHuCxi8hatjR@eisner.encompasserve.org>   r In article <1149599442.369748.106310@u72g2000cwu.googlegroups.com>, "Francesco Donini" <fdonini@gmail.com> writes: >  > Bob Koehler ha scritto:  > u >> In article <1149164042.421764.177420@i40g2000cwc.googlegroups.com>, "Francesco Donini" <fdonini@gmail.com> writes: ) >> > david20@alpha2.mdx.ac.uk ha scritto: U >> >> Creating an executable on VMS is a two stage process. Compiling the source into T >> >> object files (.obj files) and then linking these files together with libraries >> >> to create executables. >> >> K >> >> The CC command only does the first step. .olb files are library files M >> >> containing object files and hence shouldn't be included on the CC line. K >> >> The LINK command is then used to link the object files and libraries.  >> >>  >> >> . >> >> What you probably need is something like >> >>  >> >> cc simple.c  >> > >> > Yes u are rightF >> > I tried before what u are telling me but i get only error message >> > compiling the source.D >> > The compiler can't resolve the include files and all the others3 >> > function because doesn't know where find them.  >>I >>    The C compiler has a process for finding include files.  By default K >>    it finds those which ship with the compiler, curl isn't one of those.  >>M >>    curl.h should be located with the libcurl.olb you have.  In a nutshell, B >>    the compiler will find <curl/curl.h> if you define curl as a? >>    logical pointing to the directory which contains curl.h .  >>H >>    If you checkout "help cc /include", you'll find other ways to tell! >>    the compiler where to look.  >  >  > Ok, every things works now. F > The problem was that I had to copy (from a linux soruce) the includeE > files (curl *.h files) to an OpenVMS directroy and create to this a  > logical link. I > Then then compiler didn't complain anymore and now after that i created G > a .obj and linked the object file with olb library every things works  > correctly. >  > Thanks to all for the help.  >   A While I provide the .olb* files in the VMS cURL distribution, you D will need the source kit to build something that references the cURLD include files.  I did this so that if someone wanted to build a cURLC app they didn't have to compile the whole thing from scratch to get  the objects to link against.    > Not really clear in my limited docs with the exe and olb kits. Sorry about that.     A The source kit from haxx.se has all the changes I made to make it ? (reasonably) VMS savvy folded into the distribution.  Building  B the whole VMS obj, olb and exe is pretty easy, but time consuming.  ? The .exe* files in the downloadable zip file from haxx.se is a  B standalone cURL executable that you can use from the command line.@ After defining the foreign command or path, of course.  The olb*@ files are useful only if you write c code (or any compatible HP 0 VMS language, I suppose) to call cURL functions.  @ I guess I should include some sample apps in the [.packages.vms]@ subdirectory of the source tree with some documentation.  I'm a @ version behind in the dist already, so maybe I can add that for  the 7.15.4 version.    Regards, Marty    ------------------------------  % Date: Fri, 09 Jun 2006 10:41:42 +0800 ) From: Tim Sneddon <tesneddon@bigpond.com> + Subject: Re: Compiling Problem with LibCurl 9 Message-ID: <4488d258$0$26888$88260bb3@free.teranews.com>    Marty Kuhrt wrote:C > While I provide the .olb* files in the VMS cURL distribution, you F > will need the source kit to build something that references the cURLF > include files.  I did this so that if someone wanted to build a cURLE > app they didn't have to compile the whole thing from scratch to get   > the objects to link against.   > @ > Not really clear in my limited docs with the exe and olb kits. > Sorry about that.    > C > The source kit from haxx.se has all the changes I made to make it A > (reasonably) VMS savvy folded into the distribution.  Building  D > the whole VMS obj, olb and exe is pretty easy, but time consuming. > A > The .exe* files in the downloadable zip file from haxx.se is a  D > standalone cURL executable that you can use from the command line.B > After defining the foreign command or path, of course.  The olb*B > files are useful only if you write c code (or any compatible HP 2 > VMS language, I suppose) to call cURL functions. > B > I guess I should include some sample apps in the [.packages.vms]B > subdirectory of the source tree with some documentation.  I'm a B > version behind in the dist already, so maybe I can add that for  > the 7.15.4 version.   @ FWIW I have been busy re-organising the latest cURL distribution@ to support a PCSI build. The current PCSI kit that has been madeD available is not as great as I would like. I'm not sure what I'll doB about rolling it into the general cURL distribution as yet. I have? shuffled most of the VMS stuff around and added TECO macros and > DCL to generate some VMS specific bits and pieces. Not sure on& a release date, but it should be soon.  ? There also seems to be some problems related to SSL and cURL on ( VMS that I'm trying to sort out as well.  
 Regards, Tim.    --  = Posted via a free Usenet account from http://www.teranews.com    ------------------------------  * Date: Thu, 8 Jun 2006 23:04:01 -0500 (CDT)* From: sms@antinode.org (Steven M. Schweda)+ Subject: Re: Compiling Problem with LibCurl 2 Message-ID: <06060823040136_2022872F@antinode.org>  ) From: Tim Sneddon <tesneddon@bigpond.com>   A > There also seems to be some problems related to SSL and cURL on * > VMS that I'm trying to sort out as well.  (    No bets on the value, but I did this:  : ALP $ diff [.PACKAGES.VMS]BUILD_VMS.COM_ORIG BUILD_VMS.COM ************U File SYS$SYSDEVICE:[UTILITY.SOURCE.CURL.CURL-7_15_1.PACKAGES.VMS]BUILD_VMS.COM_ORIG;1 3   102   $ if ( openssl .eq. 1) .or. ( hpssl .eq. 1)    103   $ then?   104   $    'vo_c' "%CURL-I-BLDSSL, building with SSL support"    105   $ elseD   106   $    'vo_c' "%CURL-I-BLDNOSSL, building without SSL support"   107   $ endif  ******P File SYS$SYSDEVICE:[UTILITY.SOURCE.CURL.CURL-7_15_1.PACKAGES.VMS]BUILD_VMS.COM;3   102   $ if ( hpssl .eq. 1)   103   $ thenD   104   $    'vo_c' "%CURL-I-BLDHPSSL, building with HP SSL support"   105   $ else!   106   $    if ( openssl .eq. 1)    107   $    then G   108   $       'vo_c' "%CURL-I-BLDOSSL, building with OpenSSL support"    109   $    else G   110   $       'vo_c' "%CURL-I-BLDNOSSL, building with NO SSL support"    111   $    endif   112   $ endif  ************ ************U File SYS$SYSDEVICE:[UTILITY.SOURCE.CURL.CURL-7_15_1.PACKAGES.VMS]BUILD_VMS.COM_ORIG;1 !   216   $   cmd_c = "CC "+cc_qual )   217   $   cmd_msg = "MESSAGE "+msg_qual  ******P File SYS$SYSDEVICE:[UTILITY.SOURCE.CURL.CURL-7_15_1.PACKAGES.VMS]BUILD_VMS.COM;39   221   $   cmd_c = "CC "+cc_qual+ " /float = ieee_float" )   222   $   cmd_msg = "MESSAGE "+msg_qual  ************  & Number of difference sections found: 2& Number of difference records found: 11  <    That last bit should probably be made conditional somehowA (considering the VAX. and all).  I thought that the SSL stuff was 9 working, but I may not have tested all the possibilities.   -    Also, to soothe the compiler, I did these:   # ALP $ diff [.LIB]FILE.C_ORIG FILE.C  ************E File SYS$SYSDEVICE:[UTILITY.SOURCE.CURL.CURL-7_15_1.LIB]FILE.C_ORIG;1    235       if (nread <= 0)    236         break; ******@ File SYS$SYSDEVICE:[UTILITY.SOURCE.CURL.CURL-7_15_1.LIB]FILE.C;2   235       if (nread == 0)    236         break; ************  & Number of difference sections found: 1% Number of difference records found: 1     - ALP $ diff [.LIB]PARSEDATE.C_ORIG PARSEDATE.C  ************J File SYS$SYSDEVICE:[UTILITY.SOURCE.CURL.CURL-7_15_1.LIB]PARSEDATE.C_ORIG;1   394     if(-1 != t) {    395       struct tm *gmt;  ******E File SYS$SYSDEVICE:[UTILITY.SOURCE.CURL.CURL-7_15_1.LIB]PARSEDATE.C;2 !   394     if((time_t)(-1) != t) {    395       struct tm *gmt;  ************  & Number of difference sections found: 1% Number of difference records found: 1   H ------------------------------------------------------------------------  3    Steven M. Schweda               sms@antinode-org 4    382 South Warwick Street        (+1) 651-699-9818    Saint Paul  MN  55105-2547    ------------------------------  $ Date: Thu, 8 Jun 2006 17:54:17 -04000 From: "Scott G. Smith" <s-gsmith@mindspring.com> Subject: HSJ 50 patches ' Message-ID: <g01ig.182$2_4.59@fe06.lga>   K I have a customer who has a couple of HSJ50s controlling a bunch of JBODs.  J One controller failed and was replaced by third paty maintenance.  During : the transfer, it looks like patches to HSOF 5.1 were lost.  L The third party hw maintainer doesn't have any information on patches.  The L HP software contract doesn't cover the HSJs.  I can't find any info on HP's H web site to discuss the patches, download, etc.  Of cource, this is all L terribly old equipment, which has my customer concerned about the downlevel  change.   L Does anyone know how to obtain these patches?  Or what problems the patches ) correct?  Any info would be appreciated.     ------------------------------  # Date: Thu, 08 Jun 2006 17:36:01 GMT % From: Rick Jones <rick.jones2@hp.com> # Subject: Re: Intel selling Itanium? 2 Message-ID: <5eZhg.1670$g23.1453@news.cpqcorp.net>   bob@instantwhip.com wrote:C > pa risc only runs hp unix which most would eventually end up with  > x86 linux ...   E Not that it really matters much for the "discussion" but being the HP @ type I am I feel compelled to point-out that there is actually a PA-RISC Linux port out there.    	http://www.parisc-linux.org/   
 rick jones --  B No need to believe in either side, or any side. There is no cause.E There's only yourself. The belief is in your own precision.  - Jobert F these opinions are mine, all mine; HP might not want them anyway... :)D feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...   ------------------------------  $ Date: Thu, 8 Jun 2006 16:21:03 -0400C From: "David Turner, Island Computers US Corp" <dbturner@icusc.com> # Subject: Re: Intel selling Itanium? 8 Message-ID: <CF%hg.6109$gv2.4325@bignews3.bellsouth.net>   All....    See www.softresint.com  @ I think the future of VMS may be more obvious than people think!   --     David B Turner Island Computers US Corp 2700 Gregory St, Suite 180 Savannah GA 31404  Tel: 912 447 6622 X201 Cell: 912 447 6622 X251  Fax: 912 201 0402  Email: dbturner@icusc.com  Web: http://www.islandco.com% ===================================== < All orders are subject to the following terms and conditions. of sale. These should be read before ordering.% http://www.islandco.com/warranty.html   5 "Bill Todd" <billtodd@metrocast.net> wrote in message A news:i9qdnZPWiIKhNRrZnZ2dnUVZ_rGdnZ2d@metrocastcablevision.com...  > JF Mezei wrote:  >  > ...  > L > > The big question is whether Intel will announce 8086 features that allowJ > > it to scale to Superdome before or at the same time as the end of line > > for IA64 is announced. > H > Exactly what scaling features do you think Itanic has that Intel's x86I > products don't?  People like Sequent were building 32- and 64-processor J > x86 configurations close to a decade ago (I'm not going to look up exactH > dates), and others could (and quite likely would) be doing so today ifF > they hadn't gotten side-tracked by the Itanic hype (a 32- or 64-coreB > Woodcrest machine would handily show its heels to Itanic on mostI > workloads despite having significantly less on-chip cache and therefore G > lower manufacturing cost, and at far lower power to boot - even lower J > power than Montecito will require, despite its vast improvements in that > area). > E > Of course, IBM already offers up to 64-core x86 configurations, but H > using a somewhat cobbled-together approach that doesn't scale superblyH > and uses the far less capable Pentium 4 ('Netburst') architecture (andC > that chipset may not be capable of using the new Woodcrest server B > parts).  Still, even that second-class product has beaten Itanic3 > core-for-core in some up to 32-core benchmarks...  > G > And the 'common system interconnect' (CSI) that Intel is planning for J > 2008 will support both Itanic and x86, so no advantage there for Itanic,	 > either.  > J > The one real performance edge that Itanic used to hold over x86 (runningH > FP-intensive code) has just been erased by Woodcrest (not that OpteronJ > was all that far behind before).  Itanic is looking even more irrelevantE > than ever these days, and I'm certainly not aware of any rabbits it 5 > could pull out of its hat to change that situation.  >  > - bill   ------------------------------  % Date: Thu, 08 Jun 2006 20:31:33 -0400 - From: JF mezei <jfmezei.spamnot@teksavvy.com> F Subject: OT: IT glitch results in Cadbury chocolate glut  (SAP again!), Message-ID: <4488C153.B7561F2E@teksavvy.com>  g > http://news.com.com/IT+glitch+results+in+Cadbury+chocolate+glut/2100-1014_3-6081486.html?tag=nefd.top   D Remember when HP had problems because its SAP implementation stoppedJ production ? Well, now the opposite seems to have happened at Cadbury !!!!  R Note: nobody in this newsgroup should be surprised that I spotted that article....     --------------------F U.K. confectionery giant Cadbury Trebor Bassett has taken a hit in itsG profits after information technology problems caused too many chocolate  bars to be produced.    F Cadbury was left with a glut of chocolate products at the start of theC year, after the installation of a new SAP-based enterprise resource G planning (ERP) system led to an excess of chocolate bars building up at  the end of 2005.     ...   @  This led to a total hit of 32 million pounds ($58.9 million) onA Cadbury's first-quarter financial figures, 12 million pounds ($22 A million) of which the company said was directly related to the IT 
 problems.    -------------------   E Good example of the "mission critical" nature of many IT systems that I can cost a corporation much more money than the IT systems itself costed.       B Have there ever been a succesfull large scale SAP implementation ?   ------------------------------  * Date: Fri, 2 Jun 2006 08:28:36 +0000 (UTC) From: david20@alpha2.mdx.ac.uk; Subject: Re: OT: Sun release 8-socket/16-way SMP X64 server ) Message-ID: <e5osrk$r15$1@news.mdx.ac.uk>   \ In article <447F33A8.4F258A52@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes: >Brainstorming question: > - >If there were to be some petition or survey:  > H >-would vast majority of remaining customers support a port of VMS to 64 >bit 8086s ? > K As a customer I'd have to say definitely. At the moment we have no plans to K move from Alpha to Itanium. The plans are for our Tru64 systems to move to  L Linux and since some of the Alpha systems they are running on are only a fewO years old I'm looking at whether I can redeploy them as VMS systems to replace  M our older Alpha VMS systems. I want to hold off on having to try to persuade  L my bosses to move the VMS systems to Itanium for as long as possible since IO have never thought Itanium has a bright future and developments in recent years  haven't changed my opinion.   H >-would vast majoprity of non customer state that with VMS on 8086, they@ >would be more likely to consider VMS as a platform for their IT >infrastructure ?   O I'd think that VMS being just on Itanium is a disincentive. However porting VMS J to 64 bit 8086 is just the first step to attracting non-current customers.  
 David Webb Security team leader CCSS Middlesex University   ------------------------------  # Date: Thu, 08 Jun 2006 23:07:10 GMT & From: "Hal Kuff" <halkuff@verizon.net>+ Subject: RSA FOB/Device Support for OpenVMS * Message-ID: <y42ig.8599$PY6.5836@trnddc05>  L Folks, I was very happy to hear that there was now support for RSA FOBS and M what-not on OpenVMS... however it seems that Process software gets $200/user  L for the license... seems excessive... anyone have an alternative source for E the loginout support? Does not seem to be that difficult for a crack  J C/Socket programmer... anyone interested in doing a competeing project if  some users pool the  cash?     --Hal    ------------------------------   Date: 8 Jun 2006 22:22:56 -0500 - From: Kilgallen@SpamCop.net (Larry Kilgallen) / Subject: Re: RSA FOB/Device Support for OpenVMS 3 Message-ID: <txfD0C2sH8O2@eisner.encompasserve.org>   S In article <y42ig.8599$PY6.5836@trnddc05>, "Hal Kuff" <halkuff@verizon.net> writes: N > Folks, I was very happy to hear that there was now support for RSA FOBS and O > what-not on OpenVMS... however it seems that Process software gets $200/user  N > for the license... seems excessive... anyone have an alternative source for G > the loginout support? Does not seem to be that difficult for a crack  L > C/Socket programmer... anyone interested in doing a competeing project if  > some users pool the  cash?  - And who is going to pay the RSA license fee ?    ------------------------------   Date: 8 Jun 2006 19:52:33 -0700 ' From: "toby" <toby@telegraphics.com.au> < Subject: Re: SimH 3.6-0 (problems compiling VAX using MinGW)B Message-ID: <1149821553.824525.42010@c74g2000cwc.googlegroups.com>   Alan Greig wrote: 
 > Wilm wrote: K > > I have a problem compiling VAX and VAX780 under Windows, using the SIMH $ > > supplied build_mingw.bat script. > > J > > The VAXen will not build *unless* I copy vax_defs.h, vaxmod_defs.h andH > > vax780_defs.h from the VAX folder into the PDP11 folder. If not, theH > > first PDP11 module to be compiled with either VAX fails with a "file# > > not found" error on vax_defs.h.  > > > I had that problem as well. Also you should turn on full gcc7 > optimization. That almost doubles the emulator speed.   A Hmm, that seems a strange omission from the Makefile. -O0 is very  inappropriate...   > 1 > > The gcc command generated by mingw32-make is:  > > * > > gcc -std=c99 -U__STRICT_ANSI__ -O0 ...   ------------------------------  # Date: Thu, 08 Jun 2006 18:40:17 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>1 Subject: Re: Wanted:MAIL.MAI structure definition 0 Message-ID: <la_hg.1672$L33.62@news.cpqcorp.net>   david20@alpha2.mdx.ac.uk wrote:   P > In recent years pure relational databases such as Oracle have changed to allowP > the storage and retrieval of opaque data such as images so yes you could storeN > and retrieve opaque mail message objects but I don't see what advantage that > gives you.  I    Other than resolving the "the existing mail data store is rather more  % limited than I would prefer?" matter?   G    And commercial databases have been capable of arbitrary storage for  $ eons.  This includes opaque objects.  ? > In a previous message you also mentioned XML with the comment  >  > " J >    I would also propose storing the data in a database, and allowing theI > external software to access the data via XML; to allow data imports and I > exports using XML.  This gets the other software out of the business of J > processing RFC-compliant headers.  (And, going full circle, if SMTP mailE > were to be (re)implemented today, it is exceedingly likely that XML 5 > would have been used as the basis of the wrappers.)  > "  > P > SMTP mail and all the software out there which processes RFC-compliant headers: > is not going to be reimplemented using XML anytime soon.  A    Hence my "if SMTP mail were to be (re)implemented..." comment.   F    The existing SMTP RFC scheme is a very old design, albeit a widely F accepted and functional design.  If most anyone here were to redesign E the SMTP mail traffic, the result would likely be using XML.  (Wanna  G spot bad headers?  Verify it with a schema.  Want to extract data from  B the header?  Grab it.  What to add extensions?  Have at.  Want to ) implement attachment encoding?  Trivial.)   I    And I'd tend to provide the XML in parallel to the existing RFC-based  E approaches -- assuming there isn't already an RFC for XML-based mail.   P > If you store mail messages you must be able to present them with all their RFC4 > headers, Mime structure, PGP signatures etc intactL > This isn't a static environment new headers are being created constantly -F > sometimes pretty much standardised such as the new header lines for P > "anti-forging" techniques such as DomainKeys and SPF - sometimes just locally L > introduced headers (which should be X-???? header lines but often aren't).  G    That software evolves is obvious.  XML is very good at dealing with  F this, both from generating the new information and from being able to ? operate when newer information is presented to an older client.   A    Who's to say that providing a parallel XML interface won't be  C accepted?  It would certainly make a reasonable RFC, as a start --  5 again, if there isn't already an XML MAIL RFC around.   L > Oracle's XML appears to support two types of storage CLOB (which maintainsL > document fidelity and appears just to be an opaque object) and O-R storageM > which maintains document object model fidelity by decomposing the XML into    > the underlying O-R structures.I > I would maintain that to store mail messages you would need to use CLOB 
 > storage.  F    Databases store data.  Data is data.  Data is bytes.  Bytes can be H stored.  Metadata can be stored.  Data structures can be reconstituted. A    You can store a music file as a series of linked data records.   R > Converting SMTP mail to other formats (as for instance Exchange does) is one of L > the main ways of producing software which has problems interoperating withO > other SMTP compliant systems. I think that breaking up mail messages using an N > XML schema to store them in O-R structures and then reconstructing them for H > output to SMTP based tools or for forwarding would be prone to errors.  H    OpenVMS and Windows Exchange Server and most any other tool converts G mail -- from its RFC wire format into the local host on-disk format --  G all the time.  Every mail message arriving into an OpenVMS system gets  I its format converted.  Converted at least twice, if you're using POP3 or  D IMAP to access and read off the messages from the OpenVMS MAIL data 5 store -- once on the way in, and once on the way out.   H    [I have to be being dense here as to not see what the concern is, as E none of this would be difficult to code up using j-random version of  F Oracle Rdb and j-random version of libxml2.  Most any database itself ( has in-built XML capabilities, as well.]   ------------------------------  % Date: Thu, 08 Jun 2006 20:02:33 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 1 Subject: Re: Wanted:MAIL.MAI structure definition , Message-ID: <4488BA89.839F74C8@teksavvy.com>   Hoff Hoffman wrote: H > all the time.  Every mail message arriving into an OpenVMS system getsJ > its format converted.  Converted at least twice, if you're using POP3 orE > IMAP to access and read off the messages from the OpenVMS MAIL data 7 > store -- once on the way in, and once on the way out.   F Properly RFC formatted messages do NOT get reformatted. The RFC headerG is parsed so that the SMTP symbiont can properly fill out the basic VMS G Mail fields, but the RFC header remains intact. And when you use POP or H IMAP, if the RFC header is intact, it is used as is. It is only when theE RFC header is wrong or missing that a new one is synthetized from the  VMS mail enveloppe information.   I >    [I have to be being dense here as to not see what the concern is, as F > none of this would be difficult to code up using j-random version ofG > Oracle Rdb and j-random version of libxml2.  Most any database itself * > has in-built XML capabilities, as well.]  G XML gives you no added functionality. You will still need code to parse E a dynamic RFC header into a fixed XML definition and thene wnever you ? need to access the mesage, code to reconstitute the RFC header, # hopefully exactly as it was before.   E XML is like RFID. A nice bozzword that is greatly abused and misused. G Puttin RFID on a box so you can scan it as it passes near a sensor on a H conveyor belt is great. Putting RFID in a car jey or passports is stupidG because anyone can scan your key/passport without you knowing about it.    ------------------------------   End of INFO-VAX 2006.318 ************************