INFO-VAX Wed, 05 Jan 2005 Volume 2005 : Issue 9 Contents: C File sharing issue with multiple writers Re: C File sharing issue with multiple writers Re: Canadian Internet Policy Re: Guest appearance by Carly in today's Dilbert Help - SYSUAF and $SETUAI on UAI$_USER_DATA field Re: How to get Tape Tools to recognize terminfo database? Re: How to get Tape Tools to recognize terminfo database? Re: How to get Tape Tools to recognize terminfo database? Re: How to get Tape Tools to recognize terminfo database? Re: HP pulls out of IA64 chip development Re: HP pulls out of IA64 chip development Re: HP pulls out of IA64 chip development Re: HP pulls out of IA64 chip development Re: Legato vs VMS Backup -- Recover Speed Re: More on Tru64 Re: More on Tru64 Re: need help in decoding VAXstation 4000/60 console error message Re: Need help with user-written routine in SOR$ Re: Need help with user-written routine in SOR$ Re: Need help with user-written routine in SOR$ Re: Need help with user-written routine in SOR$ Re: Need help with user-written routine in SOR$ Re: Need help with user-written routine in SOR$ Re: Need help with user-written routine in SOR$ Re: Need help with user-written routine in SOR$ Re: Need UNIX clarification Re: Need UNIX clarification Re: SCSI ON A VAX 4000/500 - WHAT DO I NEED? TCP/IP mailing problem Re: TCP/IP mailing problem Re: VMS and digital cameras VMS trialware CD Re: VMS trialware CD Re: What's the state of USB 2.0 support in VMS 8.2? Re: What's the state of USB 2.0 support in VMS 8.2? ---------------------------------------------------------------------- Date: 4 Jan 2005 18:47:40 -0800 From: "Kannan" Subject: C File sharing issue with multiple writers Message-ID: <1104893260.841985.178950@z14g2000cwz.googlegroups.com> Hi, I am in the process of porting a high availabilty unix application that is part of ORACLE DB server on to VMS and hitting with the following issue. Will greatly appreciate your inputs to get a resloution on this. brief description of the functionality . There is a file Oracle configuration Repository (a streamlf mode file on VMS Cluster file system), which has resources registered by a daemon process that can run on multiple nodes and share this common file. At any point of time one will be a master which can write into this OCR. Problem Description: I scanned the related messages posted in this group and arrived at the open call mentioned below to properly open this file in shared mode. The open call I am using to open this file in shared mode is the following open((const char *)filename,O_RDWR|O_DSYNC,"ctx=rec","rfm=stmlf","shr=get,put,upd","rop=rea"); and the writes and reads on the file is done using pwrite and pread C runtime calls, which reads/writes based on offset information. And I am doing fsync call after every pwrite , so that the data gets written to the disk immediately. The problem I am observing is 1. Daemon 1 on the first node, opens the OCR file in rdwr mode and writes the basic information. After this write is completed, the file size is 1040 blocks. 2. Daemon 2 on the other node, now opens the file(when the file size was 1040 blocks) in rdwr mode and initiates a write request to daemon 1 (which acts as a master) to register its basic information . Daemon 1 starts writing node2 information and at the end of it the file size is 1048 blocks. Now for some reason if the Daemon 2 exits/crashes, the file size on VMS gets truncated to 1040 blocks essentially corrupting this file. Also, now if daemon 1 exits and daemon 2 attempts to read beyond 1040 blocks, it gets an error My guess is the new EOF pointer is not known to daemon2 and hence closing this file with the EOF pointer it had when it opened the file and same is the case with read. I was told that on UNIX, the EOF file pointer is updated across the processes dynamically. Not sure how we can achieve this on VMS. Please correct if my above theory is wrong. I will greatly appreciate if you could provide some pointers as to what could be the issue here and if there are ways to workaround this issue on VMS. Please Thanks in advance. Kannan. ------------------------------ Date: Tue, 04 Jan 2005 21:09:54 -0600 From: David J Dachtera Subject: Re: C File sharing issue with multiple writers Message-ID: <41DB5A82.6DC568EF@comcast.net> Kannan wrote: > > Hi, > > I am in the process of porting a high availabilty unix application that > is part of ORACLE DB server on to VMS and hitting with the following > issue. Will greatly appreciate your inputs to get a resloution on this. > > brief description of the functionality . > There is a file Oracle configuration Repository (a streamlf mode file > on VMS Cluster file system), which has resources registered by a daemon > process that can run on multiple nodes and share this common file. At > any point of time one will be a master which can write into this OCR. > > Problem Description: > I scanned the related messages posted in this group and arrived at the > open call mentioned below to properly open this file in shared mode. > > The open call I am using to open this file in shared mode is the > following > open((const char > *)filename,O_RDWR|O_DSYNC,"ctx=rec","rfm=stmlf","shr=get,put,upd","rop=rea"); > > and the writes and reads on the file is done using pwrite and pread C > runtime calls, which reads/writes based on offset information. And I am > doing fsync call after every pwrite , so that the data gets written to > the disk immediately. > > The problem I am observing is > 1. Daemon 1 on the first node, opens the OCR file in rdwr mode and > writes the basic information. After this write is completed, the file > size is 1040 blocks. > 2. Daemon 2 on the other node, now opens the file(when the file size > was 1040 blocks) in rdwr mode and initiates a > write request to daemon 1 (which acts as a master) to register its > basic information . Daemon 1 starts writing node2 information and at > the end of it the file size is 1048 blocks. > > Now for some reason if the Daemon 2 exits/crashes, the file size on VMS > gets truncated to 1040 blocks essentially corrupting this file. Also, > now if daemon 1 exits and daemon 2 attempts to read beyond 1040 blocks, > it gets an error > > My guess is the new EOF pointer is not known to daemon2 and hence > closing this file with the EOF pointer it had when it opened the file > and same is the case with read. I was told that on UNIX, the EOF file > pointer is updated across the processes dynamically. Not sure how we > can achieve this on VMS. Please correct if my above theory is wrong. > > I will greatly appreciate if you could provide some pointers as to what > could be the issue here and if there are ways to workaround this issue > on VMS. Please First guess time: open the file, write it, then close it. -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ ------------------------------ Date: Tue, 04 Jan 2005 21:05:02 GMT From: Lucas Tam Subject: Re: Canadian Internet Policy Message-ID: Nomen Nescio wrote in news:9a28fd487b88a3f623eeffde1ad37c87@dizum.com: > Just go to > > alt.anonymous.messages > > and look at thousands of terrorist to terrorist messages. Usenet is the > only foolproof method terrorists can use to speedily transmit their > sinister plans to each other. For all I know Bin Laden himself speaks on > that anti-civilization newsgroup. oh well, such is free speech. -- Lucas Tam (REMOVEnntp@rogers.com) Please delete "REMOVE" from the e-mail address when replying. http://members.ebay.com/aboutme/coolspot18/ ------------------------------ Date: Tue, 04 Jan 2005 20:16:24 GMT From: Rick Jones Subject: Re: Guest appearance by Carly in today's Dilbert Message-ID: > HP 57 Tri-color Inkjet Print Cartridge Typically used in conjunction with the HP 56 Black Inkjet cartridge/pen (some old timers still call them pens in reference to plotter days) and also the HP 58 Photo Cartridge. IIRC the numbers correspond to the last two digits of their "proper" HP product numbers. The idea being it is easier for a customer to remember that his printer uses a "56" than a "C23456." (not the real product number - I don't have _those_ memorized) If you go into a store that carries HP printer supplies, you will see those numbers displayed prominently on the front of the packaging. Something like this: http://www.shopping.hp.com/shopping/images/products/c6657an_400.jpg rick jones owner of a PhotoSmart 7150 printer - which happens to use those three cartidges -- a wide gulf separates "what if" from "if only" these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to raj in cup.hp.com but NOT BOTH... ------------------------------ Date: Tue, 04 Jan 2005 21:34:27 -0700 From: Lorin Ricker Subject: Help - SYSUAF and $SETUAI on UAI$_USER_DATA field Message-ID: <14nmt0peo98q2rvcdfu8noj7evb7e0pd6q@4ax.com> I'm at my wit's end trying to find & fix some buggy behavior in a utility program I've written which uses the system RTL routines $GETUAI and $SETUAI -- I need help and perspective from someone with more experience, and perhaps who has access to relevant VMS system service code listings. Apologies in advance for the length of this post. PROGRAM DESCRIPTION: I've written a utility, SETUAI.EXE in Pascal v5.8-92 on VMS v7.2-1, which can fetch (display with an application /SHOW), insert &/or update (with /ADD="string"), and delete/remove data in the UAI$_USER_DATA field of a SYSUAF.DAT user/account record, via the system RTLs $GETUAI and $SETUAI. The basic utility command line syntax looks like: $ SETUAI username - [/SHOW[=(keyword[,keyword]...] - [/ADD="string"] - [/TIMEZONE=tzstring] - [/DELETE[=keyword]] - [/LOG] - [/VERSION] The data I'm attempting to get/put in the UAI$_USER_DATA field is interpreted as a counted-string of ASCII, basically an image of a Pascal VARYING string simply laid into that field-area. (The semantics aren't relevant here, but for the curious: We encode application-specific and timezone information on a per-user/account basis so that we can reasonably represent date/time fields in an Rdb database for users across the country. The application-side code for this is well-developed; this UAF data is just the "starter seed" for each username/account, fetched and interpreted at app-startup/initialization, to define their local TZ and other application-specific stuff for the application environment to interpret and use.) Although the documentation in the System Services Manual for these two routines is rather brief/sketchy for this itemlist function, it seems straightforward enough ("...returns/sets up to 255 bytes of information from the user data area of the system user authorization file SYSUAF"). IFAIK, I don't think the relevant paragraphs for these RTLs have been updated since my DEC-printed copy of the System Services Ref Man (AA-QSBNA-TE, December 1995). I've encapsulated these two RTLs in Pascal application jackets which set up simple itemlists and which carefully attend to resulting condition-codes. In all of my attempts to step through these application jackets with the Debugger, I've never seen either RTL return anything other than SS$_NORMAL, so I presume my arg-lists, itemlist values, etc. are OK, and that each RTL invocation must be "working right", eh? If needed, I can post these two jacket routines, &/or other code fragments... The whole program is not particularly long or complicated, mostly consists of absorbing the command-line qualifiers and guiding data strings around -- the $GETUAI and $SETUAI are the guts of it all. PROBLEM DESCRIPTION: Overall, SETUAI's logic/code is well-developed and has been pretty thoroughly debugged. The problem is in the apparent and random failure of $SETUAI to actually write (commit?... if I can use a database term) data reliably to *every* user/account record in the SYSUAF.DAT. Perhaps naively, I'm expecting that for each call to $SETUAI with a userdata string, I should be able to write that string to the UAI$_USER_DATA field, and then to retrieve that same data back with $GETUAI to verify the write... right? Well, this happens for *some* UAF records, but not all... In short, SETUAI in its present form can read/fetch userdata strings from every UAF record. It can also write (add or update) userdata strings to *some* records, but not all. And the records for which it fails to write userdata strings is unpredictable. In other words, attempts to do a $SETUAI on UAI$_USER_DATA works for some records, but fails on nearly half of them (out of approx 600 records in my SYSUAF) --- and which ones succeed and which fail is impossible to predict ahead of time. However, individual UAF records themselves behave repeatably -- the ones that succeed can be updated with different userdata with reckless abandon (and that data can be reliably read/fetched & displayed); the ones that fail, they always fail. Visual inspection of the records, with UAF> SHOW USERNAME, doesn't help me see any pattern or clues. In particular, stepping through the $SETUAI jacket with the Debugger with data for a record which "should fail", and checking the cond-code after the RTL's call, always returns SS$_NORMAL, no indication of runtime error. SUMMARY & QUESTIONS: I'm baffled, and don't have much more information to go on or share. To date, I have (at least): a) Done both a CONVERT /RECLAIM and an RMS file CONVERT on copies of the SYSUAF.DAT file to attempt to "clean up" file buckets, records marked as deleted, etc. No change in behavior. b) Looked for asynchronous and volatile data issues/problems, and I've used all available Pascal attributes and directives to be sure that I'm not being tripped up by this sort of thing. No change in behavior. I'm pretty darn sure that compiler-optimization issues are not at fault here. c) Looked long and hard for any multi-user/concurrency/sharing issues with the SYSUAF.DAT file itself --- can't see any, and besides, shouldn't the RTLs $GETUAI and $SETUAI take care of these things for me anyway? With what tinkering I've done in this regard, no change in behavior. d) While developing/debugging, I use a copy of my SYSUAF.DAT in a development directory, and point a /JOB logical SYSUAF at that copy, in the hopes that $GET/SETUAI are honoring that logical redirection. * Do $GET/SETUAI honor the logical name "SYSUAF" to redirect operations to test-copies of SYSUAF.DAT, or are these RTL routines "hard-wired" to the official system instance in SYS$SYSTEM? * Is there better/improved documentation for the UAI$_USER_DATA function of $GET/SETUAI? * Are there undocumented "tricks" for getting $SETUAI to actually write updated information in the userdata field each and every time it's called? * The unpredictable behavior of this makes me want to believe that there's a latent bug in the UAI$_USER_DATA itemlist functionality of $SETUAI (although it's still more likely that the problem is in my code &/or approach, based on ignorance). Are there VMS bugs in this vicinity that need reporting, or have they been already discovered and fixed in a release subsequent to v7.2-1? * Any wisdom, experience, expertise to share? Help! I'll appreciate any tidbits of knowledge which helps me gain some new traction on this... at the moment, I've skidded to a halt. TIA. ------------------------------ Date: Tue, 04 Jan 2005 23:40:50 GMT From: winston@SSRL.SLAC.STANFORD.EDU (Alan Winston - SSRL Central Computing) Subject: Re: How to get Tape Tools to recognize terminfo database? Message-ID: <00A3D5FC.3B4BBFA1@SSRL.SLAC.STANFORD.EDU> In article <41DAD3B8.4030304@csdco.com>, John Nebel writes: John -- (Sorry for top-posting; it seems to make more sense here.) Thanks so much for this! I foolishly followed the advice in the online manual, and didn't look through the installed directory for a readme. This got the LTT tool running right away. (And I see that my drives fail testing, but I don't see why.) Thanks! -- Alan > >See the VMS readme in [.misc] > >Directory $1$DGA101:[VMS$COMMON.OPT.LTT] > >CATALOGS.DIR;1 FIRMWARE.DIR;1 HP_LTT.EXE;1 LOGS.DIR;1 > >MISC.DIR;1 SCRIPTS.DIR;1 > > >Hera $ sho defau > $1$DGA101:[VMS$COMMON.OPT.LTT] >Hera $ DEFINE USR SYS$SYSDEVICE:[VMS$COMMON.OPT.LTT.MISC.USR] >Hera $ run hp_ltt > >(and the screen comes up) > > > +- Informational: hp L&TT ------------------------------------------+ > | > | > | hp StorageWorks library and tape tools - Version 3.5 SR1 > | > | > | > | Please stop all software and services that may access any > | > | devices that L&TT may access. > | > | > | > | Note: This tool uses keyboard commands for navigation, however > | > | on most screens you can also enter a blank command to access a > | > | numbered menu to select commands. > | > | > | > | > | > +- Press any key to continue >---------------------------------------+ > > >John > > >Alan Winston - SSRL Central Computing wrote: > >> OpenVMS Alpha 7.3-2 >> DS20E >> "HP StorageWorks Library and Tape Tools User Guide" >> DCL; GNV not installed. >> >> I downloaded the tape tool PCSI kit, reset file attributes, and INSTALLed it. >> According to the docs, it needs the terminfo database to run. I googled around >> and found somebody else had been looking for this last June, and I followed the >> suggestion that guy had gotten to get termtypes.ti.giz off Eric Raymond's web >> page. >> >> So I GUNZIPed the file and put it in SYS$SYSDEVICE:[USR.LOCAL.SHARE.TERMINFO] >> as TERMTYPES.TI >> >> It seems to be a readable text file. Manual says to define USR to point at >> the the top level directory, so I did: >> >> $sho log usr >> "USR" = "SYS$SYSDEVICE:[USR]" (LNM$PROCESS_TABLE) >> >> $ SET TERM/DEV=VT100 >> $ run sys$common:[opt.ltt]hp_ltt >> Error opening terminal: vt100. >> >> Which apparently tries to run the project, but I guess t can't find the VT100 >> entry in the database. >> >> $ SET WATCH FILE /CLASS=MAJOR >> >> doesn't seem to show it looking for this file. >> >> TERMINFO>set watch file/class=major >> %XQP, Thread #0, Deaccess (549,7,0) Reads: 6, Writes: 0, Status: 00000001 >> TERMINFO>run sys$common:[opt.ltt]hp_ltt >> %XQP, Thread #0, Access HP_LTT.EXE;1 (50203,60,0) Status: 00000001 >> %XQP, Thread #0, Access PPLRTL.EXE;1 (1792,7,0) Status: 00000001 >> %XQP, Thread #0, Lookup (50203,60,0) Status: 00000001 >> %XQP, Thread #0, Lookup HP_LTT.EXE;1 (50203,60,0) Status: 00000001 >> %XQP, Thread #0, Lookup (37111,3,0) Status: 00000001 >> %XQP, Thread #0, Lookup DECC$SHR_EV56.EXE;1 (37111,3,0) Status: 00000001 >> %XQP, Thread #0, Lookup (20874,16,0) Status: 00000001 >> %XQP, Thread #0, Lookup DPML$SHR.EXE;1 (20874,16,0) Status: 00000001 >> %XQP, Thread #0, Lookup (1792,7,0) Status: 00000001 >> %XQP, Thread #0, Lookup PPLRTL.EXE;1 (1792,7,0) Status: 00000001 >> %XQP, Thread #0, Lookup (44897,1440,0) Status: 00000001 >> %XQP, Thread #0, Lookup PTHREAD$RTL.EXE;1 (44897,1440,0) Status: 00000001 >> %XQP, Thread #0, Lookup (1636,7,0) Status: 00000001 >> %XQP, Thread #0, Lookup CMA$TIS_SHR.EXE;1 (1636,7,0) Status: 00000001 >> %XQP, Thread #0, Lookup (44595,31,0) Status: 00000001 >> %XQP, Thread #0, Lookup LIBRTL.EXE;1 (44595,31,0) Status: 00000001 >> %XQP, Thread #0, Lookup (1759,7,0) Status: 00000001 >> %XQP, Thread #0, Lookup LIBOTS.EXE;1 (1759,7,0) Status: 00000001 >> %XQP, Thread #0, Lookup (1634,7,0) Status: 00000001 >> %XQP, Thread #0, Access CMA$RTL.EXE;1 (1634,7,0) Status: 00000001 >> %XQP, Thread #0, Control function (1634,7,0) Status: 00000001 >> %XQP, Thread #0, Deaccess (1634,7,0) Reads: 3, Writes: 0, Status: 00000001 >> %XQP, Thread #0, Lookup (0,0,0) Status: 00000910 >> %XQP, Thread #0, Lookup (0,0,0) Status: 00000910 >> %XQP, Thread #0, Lookup (0,0,0) Status: 00000910 >> Error opening terminal: vt100. >> %XQP, Thread #0, Deaccess (50203,60,0) Reads: 249, Writes: 0, Status: 00000001 >> %XQP, Thread #0, Deaccess (1792,7,0) Reads: 10, Writes: 0, Status: 00000001 >> >> >> Where can I put my terminfo file and what can I define to get LTT to use it? >> If this isn't the problem, what is? >> >> Thanks, >> >> -- Alan > ------------------------------ Date: Tue, 04 Jan 2005 20:53:29 -0600 From: David J Dachtera Subject: Re: How to get Tape Tools to recognize terminfo database? Message-ID: <41DB56A9.DABF2726@comcast.net> Alan Winston - SSRL Central Computing wrote: > > In article <41DAD3B8.4030304@csdco.com>, John Nebel writes: > John -- > > (Sorry for top-posting; it seems to make more sense here.) > > Thanks so much for this! I foolishly followed the advice in the online manual, > and didn't look through the installed directory for a readme. > > This got the LTT tool running right away. (And I see that my drives fail > testing, but I don't see why.) If you could post clearer details of what you did and the effect it had, I personally would appreciate it, and perhaps others, but I can't speak for them. That said, last time I inquired, LTT was only alpha-quality, not yet in full beta release. -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ ------------------------------ Date: Wed, 05 Jan 2005 03:12:03 GMT From: winston@SSRL.SLAC.STANFORD.EDU (Alan Winston - SSRL Central Computing) Subject: Re: How to get Tape Tools to recognize terminfo database? Message-ID: <00A3D619.BCFEFC64@SSRL.SLAC.STANFORD.EDU> In article <41DB56A9.DABF2726@comcast.net>, David J Dachtera writes: >Alan Winston - SSRL Central Computing wrote: >> >> In article <41DAD3B8.4030304@csdco.com>, John Nebel writes: >> John -- >> >> (Sorry for top-posting; it seems to make more sense here.) >> >> Thanks so much for this! I foolishly followed the advice in the online manual, >> and didn't look through the installed directory for a readme. >> >> This got the LTT tool running right away. (And I see that my drives fail >> testing, but I don't see why.) > >If you could post clearer details of what you did and the effect it had, >I personally would appreciate it, and perhaps others, but I can't speak >for them. > I defined USR to point to a top-level sys$sysdevice:[usr] and installed a terminfo database several steps down that tree. This didn't enable LTT to find terminfo. The advice John gave me (included below) let LTT find a terminfo and start up. Is that what you were asking? >That said, last time I inquired, LTT was only alpha-quality, not yet in >full beta release. It certainly seems kind of flaky (features in the menu that turn out to be unsupported, etc), but I didn't see any warnings on it when I found it on the hp web site. -- Alan ------------------------------ Date: Wed, 05 Jan 2005 03:35:00 +0000 From: David B Sneddon - bigpond Subject: Re: How to get Tape Tools to recognize terminfo database? Message-ID: <41DB6064.8070609@bigpond.com> David J Dachtera mentioned in passing: > Alan Winston - SSRL Central Computing wrote: > >>In article <41DAD3B8.4030304@csdco.com>, John Nebel writes: >>John -- >> >>(Sorry for top-posting; it seems to make more sense here.) >> >>Thanks so much for this! I foolishly followed the advice in the online manual, >>and didn't look through the installed directory for a readme. >> >>This got the LTT tool running right away. (And I see that my drives fail >>testing, but I don't see why.) > > > If you could post clearer details of what you did and the effect it had, > I personally would appreciate it, and perhaps others, but I can't speak > for them. > > That said, last time I inquired, LTT was only alpha-quality, not yet in > full beta release. > From the file SYS$SYSDEVICE:[VMS$COMMON.OPT.LTT.MISC]README_OVMS.TXT RUNNING LTT: ------------ 1) Set the term to vt100, this can be done using the command SET TERM /DEV=VT100 2) Create the logical name USR such that it points to the directory sys$sysdevice:[vms$common.opt.ltt.misc.usr]. This can be done using the following command. DEFINE USR SYS$SYSDEVICE:[VMS$COMMON.OPT.LTT.MISC.USR] 3) To run LTT, go to the directory sys$sysdevice:[vms$common.opt.ltt] and give the following command. RUN HP_LTT.EXE I tried it without the SET TERM (I was using a DECterm) and it ran with no problems. Regards, Dave -- David B Sneddon (dbs) VMS Systems Programmer dbsneddon@bigpond.com Sneddo's quick guide ... http://www.users.bigpond.com/dbsneddon/ DBS freeware http://www.users.bigpond.com/dbsneddon/software.htm ------------------------------ Date: Tue, 4 Jan 2005 16:05:36 -0500 From: "John Smith" Subject: Re: HP pulls out of IA64 chip development Message-ID: JF Mezei wrote: > John Reagan wrote: >> For product, they received Fortran. For years, people praised >> DEC/Compaq's Visual Fortran product so that seemed to be a winner >> over any existing Intel product. > > > What is "Visual Fortran" ??? Is that a Windows product that was > totally unrelated to the real fortran compiler on VMS ? IIRC, Digital and Microsoft did a deal back when NT Affinity was a hot item.....I believe that Digital absorbed and supported the Microsoft Fortran compiler product and made it have both VMS and NT extension constructs....and some other stuff. I stand to be corrected. ------------------------------ Date: Tue, 04 Jan 2005 22:42:01 GMT From: John Reagan Subject: Re: HP pulls out of IA64 chip development Message-ID: John Smith wrote: > > IIRC, Digital and Microsoft did a deal back when NT Affinity was a hot > item.....I believe that Digital absorbed and supported the Microsoft Fortran > compiler product and made it have both VMS and NT extension > constructs....and some other stuff. I stand to be corrected. > > Steve Lionel would know for sure, but that doesn't sound correct to me. I don't believe that Microsoft Fortran was ever "absorbed" or "supported" by Digital. -- John Reagan HP Pascal/{A|I}MACRO for OpenVMS Project Leader Hewlett-Packard Company ------------------------------ Date: Tue, 04 Jan 2005 23:01:47 GMT From: CJT Subject: Re: HP pulls out of IA64 chip development Message-ID: <41DB205D.7030101@prodigy.net> John Reagan wrote: > John Smith wrote: > >> >> IIRC, Digital and Microsoft did a deal back when NT Affinity was a hot >> item.....I believe that Digital absorbed and supported the Microsoft >> Fortran >> compiler product and made it have both VMS and NT extension >> constructs....and some other stuff. I stand to be corrected. >> >> > > Steve Lionel would know for sure, but that doesn't sound correct to me. > I don't believe that Microsoft Fortran was ever "absorbed" or > "supported" by Digital. > > I think it's more like Digital added Microsoft's extensions to its own compiler and supported _those_. -- The e-mail address in our reply-to line is reversed in an attempt to minimize spam. Our true address is of the form che...@prodigy.net. ------------------------------ Date: Tue, 4 Jan 2005 21:23:35 -0500 From: "John Smith" Subject: Re: HP pulls out of IA64 chip development Message-ID: CJT wrote: > John Reagan wrote: >> John Smith wrote: >> >>> >>> IIRC, Digital and Microsoft did a deal back when NT Affinity was a >>> hot item.....I believe that Digital absorbed and supported the >>> Microsoft Fortran >>> compiler product and made it have both VMS and NT extension >>> constructs....and some other stuff. I stand to be corrected. >>> >>> >> >> Steve Lionel would know for sure, but that doesn't sound correct to >> me. I don't believe that Microsoft Fortran was ever "absorbed" or >> "supported" by Digital. >> >> > I think it's more like Digital added Microsoft's extensions to its own > compiler and supported _those_. This explains it: http://www.microsoft.com/presspass/press/1997/Mar97/digitlpr.asp DIGITAL and Microsoft Announce Developer Studio Licensing Agreement Combination of DIGITAL's Fortran 90 Compiler Technology, Microsoft Development Environment Provides Powerful Scientific and Engineering Solutions for Windows NT And Windows 95 Operating Systems MAYNARD, Mass., and REDMOND, Wash. - March 11, 1997 - DIGITAL Equipment Corp. and Microsoft Corp. today announced an agreement under which DIGITAL will license the Microsoft® Developer StudioT visual development system. DIGITAL's first product under the arrangement, DIGITALT Visual Fortran 5.0 for the Microsoft Windows® 95 and Windows NT® operating systems, can be ordered beginning March 19 for shipments starting next month. It features the combined strengths of DIGITAL's Fortran 90 compiler technology and Microsoft Developer Studio. Microsoft is discontinuing sales of its own Fortran PowerStation 4.0 to the channel effective April 1, 1997, and is recommending DIGITAL's Visual Fortran 5.0 as the approved upgrade for current scientific and engineering customers. Microsoft and DIGITAL will ensure a smooth migration path and support for existing Microsoft Fortran PowerStation customers. Microsoft will continue to provide current levels of support until Oct. 1, 1997, and subsequent paid support until April 1, 1998. DIGITAL will provide 90-day warranty support and post-warranty service options for DIGITAL Visual Fortran 5.0 customers. The move enables DIGITAL to extend its line of development tools for high-performance scientific and engineering computing and enables Microsoft to continue to focus on corporate- and ISV-oriented development tools, including the Visual StudioT 97 suite of development tools. "DIGITAL's reputation as a leader in quality Fortran compilers, along with its global distribution capabilities, commitment to high-quality support and strong technology alliance with Microsoft, was key to our decision," said Paul Gross, vice president, developer tools at Microsoft. "We are confident that DIGITAL's proven expertise in the high-performance computing, scientific and engineering market will benefit the large installed base of Microsoft Fortran PowerStation customers." "Today's announcement is further evidence of the strong alliance between DIGITAL and Microsoft," said Jesse Lipcon, DIGITAL vice president of systems product management and development. "DIGITAL Visual Fortran combines leadership technologies from DIGITAL and Microsoft in an integrated desktop product that is unrivaled in the technical marketplace. With the introduction of DIGITAL Visual Fortran, we now offer the most scalable set of solutions for the technical marketplace of any vendor in the industry." DIGITAL's Proven Excellence in Fortran Technology DIGITAL is a leader in Fortran technology, establishing its VAX Fortran product as the de facto standard during the 1980s. Today, the company provides high-quality Fortran compilers for its 64-bit DIGITAL UNIX and OpenVMST operating systems. In 1995, DIGITAL extended its compiler technology to the Windows NT-based desktop with the release of DIGITAL Fortran for Windows NT on Alpha systems. The explosive growth in use of the Windows NT and Windows 95 operating systems has resulted in increasing demand from the high-performance, scientific and engineering market for the same technology to be available for Intel-based systems. Smooth Migration for Microsoft Fortran PowerStation Users Microsoft and DIGITAL have been working closely to ensure that users of Microsoft Fortran PowerStation can easily upgrade to DIGITAL Visual Fortran 5.0. The DIGITAL compiler has been enhanced to provide compatibility with Microsoft Fortran PowerStation 4.0 and to include enhancements proposed in the ISO/ANSI Fortran 95 language standard. Because it shares the same integrated development environment, DIGITAL Visual Fortran 5.0 can be used with other Microsoft development tools that are integrated in Developer Studio, an integrated development environment. DIGITAL will offer current customers of Microsoft Fortran PowerStation a low-cost upgrade option to the standard edition kit of DIGITAL Visual Fortran 5.0. The upgrade price of $360 (U.S.) will be available to users of Microsoft PowerStation as well as current users of any PC-based Fortran product from any vendor until Aug. 31, 1997. DIGITAL will provide continued support and future product enhancements to DIGITAL Visual Fortran. DIGITAL also announced today that DIGITAL Visual Fortran, Professional Edition, will be available later this year. This product will include the popular Fortran 77 and Fortran 90 IMSL mathematics libraries from Visual Numerics Inc. DIGITAL Visual Fortran, Standard Edition, for Windows NT for Intel systems and Windows 95 is list priced at $599 (U.S.). Special pricing is available for academic versions, in addition to the upgrade price for customers of Microsoft and other PC-based Fortran products. For additional information on DIGITAL Fortran, please visit the company's Web site at (http://www.digital.com/fortran/) The DIGITAL Microsoft Alliance for Enterprise Computing, formed in August 1995, combines Microsoft client/server products with DIGITAL's leadership in enterprise systems, service, support and systems integration. Customers can deploy business solutions on the Microsoft Windows and Windows NT operating systems with assurance of integration into the most complex business environments (for more information, refer to (http://www.alliance.digital.com/)). DIGITAL Equipment Corp. is a world leader in open client/server solutions from personal computing to integrated worldwide information systems. DIGITAL's scalable Intel and Alpha platforms, storage, networking, software and services, together with industry-focused solutions from business partners, help organizations compete and win in today's global marketplace. Founded in 1975, Microsoft (NASDAQ "MSFT") is the worldwide leader in software for personal computers. The company offers a wide range of products and services for business and personal use, each designed with the mission of making it easier and more enjoyable for people to take advantage of the full power of personal computing every day. DIGITAL, the DIGITAL logo and Open VMS are trademarks of Digital Equipment Corp. Microsoft, Developer Studio, Windows, Windows NT and Visual Studio are either registered trademarks or trademarks of Microsoft Corp. in the United States and/or other countries. Other product and company names herein may be trademarks of their respective owners. These pages offer other info: http://www.hearne.com.au/cgi-bin/product.cgi?id=90 http://www.cs-software.com/software/fortran/compaq/cvf_relnotoc.html http://www.emsps.com/oldtools/msforv.htm ------------------------------ Date: Tue, 4 Jan 2005 13:09:36 -0500 From: Wayne Sewell Subject: Re: Legato vs VMS Backup -- Recover Speed Message-ID: <00A3D5E7.1A747E05.1@tachysoft.com> >X-MX-Warning: Warning -- Invalid "From" header. >From: none <""arobert\"@(none)"> >X-Newsgroups: comp.os.vms >Subject: Re: Legato vs VMS Backup -- Recover Speed >Date: Tue, 04 Jan 2005 09:38:19 -0500 > > > >I personally prefer the VMS backup because it is native but it was >decided that the company should standardize on a single backup solution. > >That being said, I found a way to get around the bare-metal restore problem. > >I create a DR backup of the main system and applications disks to DLT >and store it at Iron Mountain. > >In the event of a disaster event, the DLT is recalled to Sungard and the >basic system is built from that. > >Once the Veritas server is built, restoring the remaining volumes using >the NetBackup client is easy to do. > >I've tested this solution and it works like a charm. > Would it work if the legato server(s) was destroyed in the disaster? You would not be able to get the remaining volumes until it was repaired. Or presumably not be able to resore *any* of the non-vms systems at all. =============================================================================== Wayne Sewell, Tachyon Software Consulting (281)812-0738 wayne@tachysoft.com http://www.tachysoft.com/www/tachyon.html and wayne.html =============================================================================== Larry(sniffing):"I smell something awful." Moe:"Yeah, well don't brag about it." ------------------------------ Date: 4 Jan 2005 23:14:18 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: More on Tru64 Message-ID: <340maaF44n821U1@individual.net> In article <41DAC212.79E174B5@teksavvy.com>, JF Mezei writes: > Larry Kilgallen wrote: >> Preferring PL/I for an arbitrary purpose is not related to preferring >> C for that same purpose. For a purpose like Payroll, Cobol, PL/I and >> Ada are all equally adept (I claim). But I am certain someone somewhere >> has implemented Payroll in C :-) > > Interestingly, COBOL is not good to convert a numeric value into text suitable > to write on cheques, especially not when you need to generate those strings in > more than one language. I always found it easy to do.(at least in english). Other languages would not be a problem of COBOL but of the way some languages mangle decimal numbers when expressing them as words. But I'll bet I could do it easy enough in any of the languages I am familiar with. (Note: While I haven't done any real COBOL in about 2 decades, I still have the utmost confidence in my ability to use it should the opportunity ever arise again. Sometimes, I really miss that kind of work.) > > My second summer job was on a payroll system and I succesfully convinced my > bosses that they should allow an exception and allow me to write the "convert > to string" routine in IBM assembler instead of COBOL and it was not difficult > to convince them. I find it hard to believe it was easier in any assembler rather than COBOL. Unless I am misunderstanding just what it is your really talking about doing here. :-) > > Later on, when on VMS, I had a mixture of COBOL and C routines because there > was stuff which was much easier to do in C than in Cobol. Cobol's report > writer feature was much better than what C had to offer (printf). I would hardly compare printf to Report Writer. That would be like comparing a bicycle wheel to a Hummer. > > Each language has its strengths. But should know where a lnaguage is strong > and where it is weak and make best use of the available tools on a platform > where there is a standard calling convention that does allow varous modules > from different languages to work together. I agree with this completely and have always been a supporter of "the right tool for the job". But I still can't see where the task above was easier in any language other than COBOL. :-) 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: Tue, 04 Jan 2005 19:47:41 -0500 From: JF Mezei Subject: Re: More on Tru64 Message-ID: <1104885471.6152cab2b3595e1555ab968b0f2a309d@teranews> Bill Gunshannon wrote: > I find it hard to believe it was easier in any assembler rather than COBOL. > Unless I am misunderstanding just what it is your really talking about > doing here. :-) French language has some elaborate rules about writing numbers and the ability to write either french or english text representing the amount on the cheque required a lot of variable size text which just wasn't very good with COBOL. Consider the task of adding an S to a word in COBOL, or concatenating two strings with either a blank or a - separating the two words. > I would hardly compare printf to Report Writer. That would be like > comparing a bicycle wheel to a Hummer. Bicycle wheels don't destroy the environment and block roads :-) However, C doesn't have a report writer in it, COBOL does. In fairness, if one now outputs to postscript, you can use postscript as a report writer and just dump your raw data from C to be read/formatted by a postscript program. Again, it is a question of recognizing the strengths and weaknesses of each language. > right tool for the job". But I still can't see where the task above > was easier in any language other than COBOL. :-) Try converting 23487 to "Twenty three thousand four hundred and eighty seven dollars" or "vingt trois mille quatre cent quatre-vingt sept dollars" in COBOL with fixed length strings. The lack of pointers in COBOL and the lack of a F$EDIT("string with lots of blanks","TRIM") makes assembling text in cobol rather tedious. Note that at that shop, ASSEMBLER wasn't yet outlawed since they needed some of the batch jobs written entirely in assembler for performance reasons. Going through their database of adresses to calculate what type of offer to send you after christmas took about a week of computing on their mainframe at that time. (early 1980s). When they upgraded to a biggr machine, they were able to cut that job down to 1 full day. The database was on tapes. With modern languages, the above task is probably trivial (although french language rules are still complex :-( ------------------------------ Date: Tue, 4 Jan 2005 15:59:40 -0500 From: "John Smith" Subject: Re: need help in decoding VAXstation 4000/60 console error message Message-ID: Phillip Helbig---remove CLOTHES to reply wrote: > In article <9jFBd.353998$b5.17411840@news3.tin.it>, "-----" > <-----@-----.--> writes: > >>> Subject says it all; who can tell me what this means? In >>> particular, >>> >>> ?? 130 10 SCSI 0034 >> >> ??: failure is FATAL >> 130: SCSI ID 3 >> 10: SCSI controller ID >> SCSI: mnemonic for SCSI :) >> 0034: Non-DMA inquiry has failed >> >> it seems that (at least) disk 3 is broken > > Thanks. After a few power cycles (always leaving the power off for a > couple of minutes), the VAXstation booted (which it is set to do > automatically if it can) and the disk is now mounted on all 3 nodes in > the cluster and is working fine. May be a thermal fault. Have you opened the case and blown all the accumulated dust away? ------------------------------ Date: 4 Jan 2005 11:19:27 -0800 From: hoefelmeyer@hotmail.com Subject: Re: Need help with user-written routine in SOR$ Message-ID: <1104866367.832988.35210@c13g2000cwb.googlegroups.com> briggs@encompasserve.org wrote: > In article <1104825470.751996.158350@f14g2000cwb.googlegroups.com>, hoefelmeyer@hotmail.com writes: > > > > Dave Froble wrote: > >> hoefelmeyer@hotmail.com wrote: > >> > don't have a clue what those structures consist of. > >> > >> > >> A word. > >> > > No, a word is not the same as a word structure. > > Thanks for giving it a shot, though. > > Dollars to doughnuts, a "word structure" is a structure consisting > of exactly one field which is a 16 bit unsigned word in this context. > > If you don't have a clue, don't spit on those that you are offered. > Whoa, there, now! What part of "thanks" is considered "spitting"? I simply disagreed with Mr. Froble. Disagreement <> Disrespect. Again, I thank Mr. Froble for his effort - he could be correct, but I suspect there's more to it and would like further clarification. It is possible that it consists of a single field, but the documentation does not specify exactly what constitutes the structure. Likewise, I appreciate your assistance as well. > For reference, here's the relevant extract from the grey wall: > > <> > > user_equal > > OpenVMS usage: procedure > type: procedure value > access: function call > mechanism: by reference > > User-written routine that resolves the sort order when records have duplicate > keys. (This argument is not currently supported by the high-performance > Sort/Merge utility.) The user_equal argument is the address of the procedure > value for this user-written routine. If you specify SOR$M_STABLE or > SOR$M_NODUPS in the options argument, do not use this argument. > SORT/MERGE calls the duplicate key routine with five reference > arguments > > ---ADRS1, ADRS2, LENG1, LENG2, CNTX--- > > corresponding to the addresses > of the two records that compare equally, the lengths of the two records that > compare equally, and the context longword. The LENG1 and LENG2 arguments are > addresses that point to 16-bit word structures that contain the length > information. > > <> > > I take that to mean that > > ADRS1 is one record contents by reference > > ADRS2 is the other record contents by reference > > LENG1 is a 16 bit word containing the length of the one record by reference > > LENG2 is a 16 bit word containing the length of the other record by reference > > CNTX is an unininterpreted argument. The type and mechanism you choose > when you pass it in SOR$BEGIN_SORT should match the ones you use when > you retrieve it in your user equal routine. > > John Briggs I just wonder - if LENG1 and LENG2 are pointers to words with the length, why does it say a "word structure containing the length information" rather than a "word containing the length"? That is why I suspect there's more to it than that. Unless it has to be a structure for some obscure VMS reason. ------------------------------ Date: 4 Jan 2005 11:46:30 -0800 From: hoefelmeyer@hotmail.com Subject: Re: Need help with user-written routine in SOR$ Message-ID: <1104867989.968799.157870@c13g2000cwb.googlegroups.com> Cool! The structure wrapper must be needed by VMS for some reason, then. I was just worried that it was something significant that was glossed over in the docs. Well, that makes it a lot easier for me! I'm very pleased to have my fears proved groundless. Thank you very much! A couple of other questions come to mind, with passing pointers - first, since ADRS1 and ADRS2 are pointers to my records, if I dereference them and modify non-key fields in them in my user_equal routine, it would indeed change the actual record, correct? I know the answer in C, but am not sure in BASIC, i.e., is my function accessing a pointer to the actual record, as does C, or is it a pointer to a local copy of the record? The latter doesn't seem likely. And if I can, would doing so make the sort choke? I don't see why, because I'm not changing keys, but you never know. I'll check this out empirically. ------------------------------ Date: Tue, 4 Jan 2005 15:51:53 -0500 From: "Hein" Subject: Re: Need help with user-written routine in SOR$ Message-ID: <41db0214$1@usenet01.boi.hp.com> wrote in message news:1104866367.832988.35210@c13g2000cwb.googlegroups.com... > briggs@encompasserve.org wrote: > > If you don't have a clue, don't spit on those that you are offered. > > > Whoa, there, now! What part of "thanks" is considered "spitting"? I don't want to put oil on a fire, but just in the fyi department, IMHO the reply to mr Froble's helpful attempt came accross unpleasantly. Just tone thing perhaps. It was not clear to me whether your function was working or not. Does it give an error (which)? Behave unexpectantly (how)? >> I have to pass the routine by reference, so it has to be an external routine to use LOC I've seen a few problems in the past where folks ended up calling the routine and passing the result instead of the address. But your solution should do it, allthough I believe that after the EXTERNAL LONG you no longer need to good through the LOC construct. Just pass it. Also, you are not using some prototype defintion for SOR$BEGIN_SORT are you? I seem to recall an problem with SMG specifying `by value' for the broadcast ast-routine address (routine address by value = procedure entry mask by reference). You could fix that by declaring EXTERNAL LONG CONSTANT your-message-function, as that would get rid of one `indirection level' I assume you tried a simple test with few record, printing the user_equal argument addresses and values? BASIC would not be my first choice of language to do this compare function, even if woudl be the language of choice for the main program. Just look at BAS/LIS/MACH output. Too much overhead for a quick and often called procedure. Check out: OPTION INACTIVE=SETUP to reduce the overhead. There are restrictions though. Form an old 1987 note: "You can't use dynamic strings, WHEN blocks, or GRAPHIC's statements. Stack locals are OK. If you have to use a stack array, you had better stick it in a RECORD structure; otherwise, stick it in a COMMON or MAP psect." Finally, I would think that changing the date of the record addresses passed is unsupported and unpredictable. Like you wrote, just try it and see if you like the results, but don't complain if it ever breaks in the future. The addresses might be directly (unlikely) in a protected RMS buffer (after a $GET with RAB$V_LOC option). Hope this help some, Hein. ------------------------------ Date: 4 Jan 2005 14:59:11 -0600 From: briggs@encompasserve.org Subject: Re: Need help with user-written routine in SOR$ Message-ID: In article <1104866367.832988.35210@c13g2000cwb.googlegroups.com>, hoefelmeyer@hotmail.com writes: > > briggs@encompasserve.org wrote: >> In article <1104825470.751996.158350@f14g2000cwb.googlegroups.com>, >> ADRS1 is one record contents by reference >> >> ADRS2 is the other record contents by reference >> >> LENG1 is a 16 bit word containing the length of the one record by > reference >> >> LENG2 is a 16 bit word containing the length of the other record by > reference >> >> CNTX is an unininterpreted argument. The type and mechanism you > choose >> when you pass it in SOR$BEGIN_SORT should match the ones you use when >> you retrieve it in your user equal routine. >> > > I just wonder - if LENG1 and LENG2 are pointers to words with the > length, why does it say a "word structure containing the length > information" rather than a "word containing the length"? That is why I > suspect there's more to it than that. Unless it has to be a structure > for some obscure VMS reason. I don't like the wording either. But since I know the quality to expect from the VMS documentation team and I know the calling interface to expect from VMS engineers, I was able to read past the obfuscation and guess correctly at the actual interface. As I wrote previously, I have verified that LENG1 and LENG2 are actually 16 bit words. (Not pointers to 16 bit words. That's an example of sub-optimal VMS documentation. You can have a pointer to a word by value. Or a word by reference. Those two notions are equivalent. But a pointer to a word by reference is a double indirect and that's not how the SOR$xxx calls are actually implemented. Yes, the thing on the argument list is a pointer to a word. But if you describe it that way then also saying that it is "by reference" is wrong). The idiots writing VMS documentation need to establish a firmer grasp of what "mechanism" means and decide whether they are going to document the thing that appears in the argument list or the thing that is passed using the argument list. There's no way to distinguish between a pointer to a word and a pointer to a structure containing a word. Both involve the same bits in memory. There's no magic to VMS in that regard. At least not when passing things by reference. When passing by descriptor, there might plausibly be a distinction to be made. John Briggs ------------------------------ Date: 4 Jan 2005 15:09:21 -0600 From: briggs@encompasserve.org Subject: Re: Need help with user-written routine in SOR$ Message-ID: In article <1104867989.968799.157870@c13g2000cwb.googlegroups.com>, hoefelmeyer@hotmail.com writes: > Cool! The structure wrapper must be needed by VMS for some reason, > then. I was just worried that it was something significant that was > glossed over in the docs. Well, that makes it a lot easier for me! I'm > very pleased to have my fears proved groundless. Thank you very much! > > A couple of other questions come to mind, with passing pointers - > first, since ADRS1 and ADRS2 are pointers to my records, if I > dereference them and modify non-key fields in them in my user_equal > routine, it would indeed change the actual record, correct? I think that would be invoking undefined behavior. There is no way to know whether you are being handed an actual record or merely a copy thereof. > I know the > answer in C, but am not sure in BASIC, i.e., is my function accessing a > pointer to the actual record, as does C, or is it a pointer to a local > copy of the record? The latter doesn't seem likely. Since the record is being passed by reference, you know that you will be modifying storage owned by the caller. But what the caller will do with that modified storage is not documented. It seems likely that the caller will, in fact, pass you a pointer to his "live" copy of the record and that changes you make will actually make it to the output file. Unless, of course, you are using a tag sort, in which case the behavior might be different. > And if I can, would doing so make the sort choke? I don't see why, > because I'm not changing keys, but you never know. I'll check this out > empirically. The empirical approach is a good choice. Just beware of trusting the results. Undocumented and unsupported behavior can change without notice. John Briggs ------------------------------ Date: 4 Jan 2005 14:44:45 -0800 From: hoefelmeyer@hotmail.com Subject: Re: Need help with user-written routine in SOR$ Message-ID: <1104878684.989285.278280@f14g2000cwb.googlegroups.com> Hein wrote: > I don't want to put oil on a fire, but just in the fyi department, IMHO the > reply to mr Froble's helpful attempt came accross unpleasantly. Just tone > thing perhaps. > Oh, my, it certainly wasn't intended that way. My apologies to Mr. Froble if he felt it did, and to anyone else who was offended on his behalf. It does help to bear in mind, though, that in text, in the absence of emotional-clue words tone is always in the eye of the beholder. I find it most useful to assume everyone has good intentions unless they are actively spewing insults. Sure, that's not always true, but there's no harm in it. At any rate, I'll do my best to write less ambiguous responses. > It was not clear to me whether your function was working or not. > Does it give an error (which)? Behave unexpectantly (how)? > I haven't run the function yet, I was in the process of writing it yesterday, and just needed syntax verification. I will be running a prototype today (don't have records yet for the actual function), employing the helpful information everyone has kindly provided. > >> I have to pass the routine by reference, so it has to be an external > routine to use LOC > > I've seen a few problems in the past where folks ended up calling the > routine and passing the result instead of the address. But your solution > should do it, allthough I believe that after the EXTERNAL LONG you no > longer need to good through the LOC construct. Just pass it. I'll try that. > Also, you are > not using some prototype defintion for SOR$BEGIN_SORT are you? I seem to > recall an problem with SMG specifying `by value' for the broadcast > ast-routine address (routine address by value = procedure entry mask by > reference). You could fix that by declaring EXTERNAL LONG CONSTANT > your-message-function, as that would get rid of one `indirection level' > > I assume you tried a simple test with few record, printing the user_equal > argument addresses and values? > I hadn't tried using user-equal before, but Mr. Briggs' example shows values. I'll write out addresses when I run. > BASIC would not be my first choice of language to do this compare function, > even if woudl be the language of choice for the main program. Just look at > BAS/LIS/MACH output. Too much overhead for a quick and often called > procedure. Check out: OPTION INACTIVE=SETUP to reduce the overhead. There > are restrictions though. Form an old 1987 note: "You can't use dynamic > strings, WHEN blocks, or GRAPHIC's statements. Stack locals are OK. If you > have to use a stack array, you had better stick it in a RECORD structure; > otherwise, stick it in a COMMON or MAP psect." > Alas, BASIC isn't my first choice, either, but I am constrained by the resources available. > Finally, I would think that changing the date of the record addresses passed > is unsupported and unpredictable. > Like you wrote, just try it and see if you like the results, but don't > complain if it ever breaks in the future. > The addresses might be directly (unlikely) in a protected RMS buffer (after > a $GET with RAB$V_LOC option). > I am concerned about that. It'll be interesting to see what it does. > Hope this help some, > Hein. It has, thanks! Cheryl ------------------------------ Date: 4 Jan 2005 14:44:50 -0800 From: hoefelmeyer@hotmail.com Subject: Re: Need help with user-written routine in SOR$ Message-ID: <1104878689.992537.66920@z14g2000cwz.googlegroups.com> Hein wrote: > I don't want to put oil on a fire, but just in the fyi department, IMHO the > reply to mr Froble's helpful attempt came accross unpleasantly. Just tone > thing perhaps. > Oh, my, it certainly wasn't intended that way. My apologies to Mr. Froble if he felt it did, and to anyone else who was offended on his behalf. It does help to bear in mind, though, that in text, in the absence of emotional-clue words tone is always in the eye of the beholder. I find it most useful to assume everyone has good intentions unless they are actively spewing insults. Sure, that's not always true, but there's no harm in it. At any rate, I'll do my best to write less ambiguous responses. > It was not clear to me whether your function was working or not. > Does it give an error (which)? Behave unexpectantly (how)? > I haven't run the function yet, I was in the process of writing it yesterday, and just needed syntax verification. I will be running a prototype today (don't have records yet for the actual function), employing the helpful information everyone has kindly provided. > >> I have to pass the routine by reference, so it has to be an external > routine to use LOC > > I've seen a few problems in the past where folks ended up calling the > routine and passing the result instead of the address. But your solution > should do it, allthough I believe that after the EXTERNAL LONG you no > longer need to good through the LOC construct. Just pass it. I'll try that. > Also, you are > not using some prototype defintion for SOR$BEGIN_SORT are you? I seem to > recall an problem with SMG specifying `by value' for the broadcast > ast-routine address (routine address by value = procedure entry mask by > reference). You could fix that by declaring EXTERNAL LONG CONSTANT > your-message-function, as that would get rid of one `indirection level' > > I assume you tried a simple test with few record, printing the user_equal > argument addresses and values? > I hadn't tried using user-equal before, but Mr. Briggs' example shows values. I'll write out addresses when I run. > BASIC would not be my first choice of language to do this compare function, > even if woudl be the language of choice for the main program. Just look at > BAS/LIS/MACH output. Too much overhead for a quick and often called > procedure. Check out: OPTION INACTIVE=SETUP to reduce the overhead. There > are restrictions though. Form an old 1987 note: "You can't use dynamic > strings, WHEN blocks, or GRAPHIC's statements. Stack locals are OK. If you > have to use a stack array, you had better stick it in a RECORD structure; > otherwise, stick it in a COMMON or MAP psect." > Alas, BASIC isn't my first choice, either, but I am constrained by the resources available. > Finally, I would think that changing the date of the record addresses passed > is unsupported and unpredictable. > Like you wrote, just try it and see if you like the results, but don't > complain if it ever breaks in the future. > The addresses might be directly (unlikely) in a protected RMS buffer (after > a $GET with RAB$V_LOC option). > I am concerned about that. It'll be interesting to see what it does. > Hope this help some, > Hein. It has, thanks! Cheryl ------------------------------ Date: Tue, 4 Jan 2005 23:43:20 -0500 From: "Neil Rieck" Subject: Re: Need help with user-written routine in SOR$ Message-ID: wrote in message news:1104809219.123603.315000@z14g2000cwz.googlegroups.com... > Hi, everyone, I hope someone can help with this... > > OS: OpenVMS 7.3 > System: Alpha > Language: BASIC > > I'm trying to write a user-written routine for the user_equal parameter > in SOR$BEGIN_SORT. I have to pass the routine by reference, so it has > to be an external routine to use LOC. Also, Sort/merge calls the > routine with 5 reference arguments ADRS1, ADRS2, LENG1, LENG2, CNTX, > which are the addresses of the two records to compare, pointers to word > structures containing length information, and the context longword. In > the user-written routine, I want to compare a non-sort-key field of the > two records and select which of the two to discard based on those > values. I will always keep one and discard the other. > > Here's what I think I need to do -- > > Main module: > ... > EXTERNAL LONG FUNCTION FN_SORT_EQ% > ... > SORT_EQ% = LOC(FN_SORT_EQ%) > ... > STATUS% = SOR$BEGIN_SORT(SORT.BUF,LRL%,,,,SORT_EQ%,,SRTTYPE%) > ... > > External function module: > FUNCTION LONG FN_SORT_EQ% (STRING REC_1 BY REF, STRING REC_2 BY REF, > WORD LEN_1 BY REF, WORD LEN_2 BY REF, LONG CTX) > EXTERNAL WORD SOR$_DELETE1, SOR$_DELETE2 > IF SEG$(REC_1, 350%, 358%) < SEG$(REC_2, 350%, 358%) THEN > FN_SORT_EQ% = SOR$_DELETE1 > ELSE > FN_SORT_EQ% = SOR$_DELETE2 > END IF > END FUNCTION > > The outcome I wish is that if the REC_1 field < the REC_2 field, REC_1 > is discarded, otherwise REC_2 is discarded. > > Is this correct? I think I'm missing something (or perhaps several > things). The 3rd and 4th arguments passed to the function are supposed > to be pointers to word structures containing length information, but I > don't have a clue what those structures consist of. I don't really care > what's in them because I don't need them - the records I am comparing > will always be the same length, but I'm not certain if I can just not > declare them and they would be ignored. Is this even close or am I > completely misunderstanding the VMS docs? > > Thanks in advance, > Cheryl > I have posted a workable solution for you here: http://www3.sympatico.ca/n.rieck/demo_vms/basic-sort-demo.zip hopefully this is something you can use. Neil Rieck Kitchener/Waterloo/Cambridge, Ontario, Canada. http://www3.sympatico.ca/n.rieck/links/cool_openvms.html ------------------------------ Date: 4 Jan 2005 13:07:04 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Need UNIX clarification Message-ID: In article , clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) writes: > > IE: VMS has been multitasking from day 1, but was not multi-threaded until > later. You've confused multi-threaded application support within the kernel with multi-threaded kernels. The VMS kernel was multi-threaded from day 1, and via ASTs it provided multi-threaded application support from day 1. What it did not provide is the current day multi-threaded application designs such as POSIX threads. That kind of capability and support for it was first seen within, and specific too, the Ada run time environment. ------------------------------ Date: 4 Jan 2005 13:09:12 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Need UNIX clarification Message-ID: In article <41DABF71.416894DD@teksavvy.com>, JF Mezei writes: > Bob Koehler wrote: >> The number of CPUs is also irrelavent. VMS was multi-threaded from >> day one, on single CPU VAX 11/780 so that it could do things the old >> single threaded UNIX kernels can not. > Any specific examples of what it could do that Unix couldn't ? Deterministic real-time support, especially as reguards interrupt to task and return timing. Modern multi-threaded UNIX still have trouble with this, it's not something their end users are asking for a lot. ------------------------------ Date: Tue, 04 Jan 2005 20:58:23 GMT From: hoff@hp.nospam (Hoff Hoffman) Subject: Re: SCSI ON A VAX 4000/500 - WHAT DO I NEED? Message-ID: In article , "John E. Malmberg" writes: :[followups set to comp.os.vms] :Michael Kukat wrote: :> :> Sure, CD-ROM and TK50Z and stuff works. It's made for this and supported by the :> firmware. It even might be the firmware has no limitations in this place and :> can boot from hard disks here. But VMS doesn't support this controller as a :> hard disk controller. Pure political stuff. It has "just" 128KB buffer, and is :> not so intelligent like MSCP adapters, that's the reason why DEC sold this just :> as an interface for CD-ROMs and tapes. I didn't get any information about this :> thing, otherwise i would have written a driver for NetBSD for it :) But in my :> research i heard about the very bad implementation of this board. IIRC, it was :> something with the SCSI bus itself, no so much the controller logic. : :As the KZQSA is an "ancient" adapter, I do not know the exact reasons :that support is limited to CD-ROMs and Tapes. : :It may be that it was never tested on magnetic disks, or that one of the :tests with then supported magnetic disks failed, and there was no way to :make it work. The KZQSA isn't expected to operate reliably with SCSI configuratious outside those that were explicitly supported. Sometimes it worked, and sometimes it didn't. We traditionally don't usually describe why we don't support a particular unsupported configuration, nor specifically detailing what was wrong (if we tested it), as that can obviously approach a support statement. We can also obviously choose not to support a configuration for other reasons -- though in this particular case, the reason was technical. While Michael Kukat has apparently had this configuration work within those configuration(s) tested, I've had the KZQSA lock up on me. (For better or worse, all ancient SCSI configurations are somewhat unstable.) The HSD05 or similar is the usual and official solution for SCSI on a Q-bus configuration, and there are (or once were) various third-party SCSI Q-bus controllers available. The series of MicroVAX referenced does have DSSI, so DSSI to SCSI adapters are available. An alternative fix is to find and replace the VAX 4000 series system with a MicroVAX or VAXstation series system with native SCSI -- this might be easier, and it might even be cheaper. (This assumes that the Q-bus is not being used for an "unusual" Q-bus adapter, of course.) ---------------------------- #include ----------------------------- For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq --------------------------- pure personal opinion --------------------------- Hoff (Stephen) Hoffman OpenVMS Engineering hoff[at]hp.com ------------------------------ Date: Wed, 05 Jan 2005 16:32:30 +1300 From: Martin Hunt Subject: TCP/IP mailing problem Message-ID: VMS V7.3 on VAX, TCP/IP Services for OpenVMS VAX Version V5.3 - ECO 2 Well, the emails go out, but the "To:" address is being partly translated to upper case, which some recipients object to. For example: $ Mail nl: "abc@w.x.y" When it gets to the recipient, the address appears as ABC@x.y.z (only the first part is translated to upper case). If I have a forwarding address set up, as in: MAIL> set forward abc "abc@w.x.y" and send to abc, the mail gets forwarded without translating the email address. How do I retain the correct case of the email address (should be all lower case), without setting up a forwarding address for all the addresses anyone wants to use? --- Martin Hunt Systems Administrator Fairfax New Zealand Limited Wellington New Zealand ------------------------------ Date: Wed, 05 Jan 2005 07:28:23 +0100 From: labadie Subject: Re: TCP/IP mailing problem Message-ID: <41db899d$0$27157$8fcfb975@news.wanadoo.fr> Martin Hunt a écrit : > VMS V7.3 on VAX, TCP/IP Services for OpenVMS VAX Version V5.3 - ECO 2 > > Well, the emails go out, but the "To:" address is being partly > translated to upper case, which some recipients object to. > > For example: > > $ Mail nl: "abc@w.x.y" apply the last Tcpip Eco, and try to triple the quotes, so $ Mail nl: """abc@w.x.y""" ------------------------------ Date: Tue, 04 Jan 2005 21:22:14 GMT From: hoff@hp.nospam (Hoff Hoffman) Subject: Re: VMS and digital cameras Message-ID: In article , "FredK" writes: :Hmmm. I have a digital camera, and I have a DS10 that can see a HD. I'll :have to see if it works (and if it doesn't, maybe Forrest can hack it ;-). :That would be cool. I know of no current plans to officially support these configurations, and all of the code necessary is not available within V8.2 or earlier releases -- as Forrest says in another reply, please let Sue Skonetski and Mark Gorham know if this addition is a product requirement. We have had various informal discussions among various of the OpenVMS engineers involved, of course. :> USB is standard, as well as the DOS FAT disk format. Thanks for the laugh! :-) But seriously, the world is filled with buggy USB devices, and with buggy FAT implementations. USB is, after all, little more than a way to send SCSI packets over a hot-pluggable serial bus, and we all know how much "fun" traditional (and non-hot-pluggable) SCSI can be. Most cameras will be using FAT16 or FAT28 (the latter format is often somewjat confusingly refered to as FAT32 :-), and many of the FAT tools around are limited to FAT12; to the floppy-sized volumes. Cameras tend to use either FAT16 or FAT28. How we might know (any of) this is left to the imagination of the reader. ---------------------------- #include ----------------------------- For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq --------------------------- pure personal opinion --------------------------- Hoff (Stephen) Hoffman OpenVMS Engineering hoff[at]hp.com ------------------------------ Date: Tue, 4 Jan 2005 17:03:28 -0500 From: "John Smith" Subject: VMS trialware CD Message-ID: Let's presume for a moment that VMS is actually going to get released on Itanic and that Itanic is going to be around for a while. There have been a number of calls for a low-cost Itanic box to be available for VMS use. Let's even suppose that will be true. As I had mentioned some time ago, why isn't/won't there be a DVD with the following bits of software..... OpenVMS Oracle Classic Rdb some compilers Communigate Pro Apache / CSWS WASD & others Multinet etc... shrink-wrapped to the cover of every printed copy of Datamation, Information Week, eWeek, Computerworld etc....that is addressed to 'C'-level execs and anyone who has the word 'manager' in their address label info for those publications to coincide with the launch of VMS on the good ship Itanic? Magazines can do that - target their readership in a variety of ways by mining the subscriber info by sector, sales, title, employee count, etc... Packaged with the DVD is a 'why VMS is good for your corporate computing health' brochure and an 800 number to call to get 6-month trial licence paks for the software on the DVD's. And some pointers to the ITRC, comp.os.vms, Encompass, and openvms.org support/information mechanisms. Seems logical - a few hundred thousand bucks to target people - hell I know guys who spend more than that on fishing gear to try and match wits with fish. But I don't expect it from HP. ------------------------------ Date: Tue, 04 Jan 2005 23:16:52 +0100 From: labadie Subject: Re: VMS trialware CD Message-ID: <41db166e$0$27163$8fcfb975@news.wanadoo.fr> John Smith a écrit : > Let's presume for a moment that VMS is actually going to get released on > Itanic and that Itanic is going to be around for a while. > > There have been a number of calls for a low-cost Itanic box to be available > for VMS use. Let's even suppose that will be true. > > As I had mentioned some time ago, why isn't/won't there be a DVD with the > following bits of software..... > > OpenVMS > Oracle Classic > Rdb > some compilers > Communigate Pro > Apache / CSWS > WASD & others > Multinet > etc... interesting J2EE being increasingly popular, Jonas and Jboss are available, as the language Ruby, too ------------------------------ Date: Tue, 04 Jan 2005 20:59:58 -0600 From: David J Dachtera Subject: Re: What's the state of USB 2.0 support in VMS 8.2? Message-ID: <41DB582E.F25D9A69@comcast.net> Larry Kilgallen wrote: > > In article <41da9747@news.deckpoint.ch>, Robert Boers writes: > > > For tapes with CHARON-VAX on a laptop, you can use a PCMCIA SCSI adapter > > with e.g. a TKZ50. The only disadvantage is that the TKZ50 is bigger > > than the laptop... > > I thought a TKZ50 was something other than SCSI and a TKZ30 was SCSI. As someone else noted, TK50Z-GA is "real" SCSI. It was sold in a MicroVAX-2000 style external case. TZ30 is a half-height, 5-1/2 inch form factor component that could be installed in a portable case, I suppose, through a bit of chicanery. I have a MicroVAX-3100 "parts" machine with a TZ30 in it. -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ ------------------------------ Date: Tue, 04 Jan 2005 21:01:41 -0600 From: David J Dachtera Subject: Re: What's the state of USB 2.0 support in VMS 8.2? Message-ID: <41DB5895.441117D3@comcast.net> Larry Kilgallen wrote: > > In article <41da97f8@news.deckpoint.ch>, Robert Boers writes: > > JF Mezei wrote: > >> Re: USB drives on VMS > >> > >> Forget Itanium. I want USB on my all mighty Microvax II. Backing up 10 gigs > >> on TK50s takes more than a year :-) ;-) > > > > FYI, USB memory sticks can be used as ODS-2 formatted drives with > > CHARON-VAX. VMS nicely recognizes them as removable media. > > Is that true even on Alpha ? That would likely depend on the level of USB support provided by OpenVMS-Alpha. (That's a hint, by the way, for the I64 team: strong USB support will be a big selling point, considering these devices and their kin.) -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ ------------------------------ End of INFO-VAX 2005.009 ************************