INFO-VAX Fri, 18 Jul 2008 Volume 2008 : Issue 398 Contents: Re: "Network tape drive" for VMS Re: "Network tape drive" for VMS Re: "Network tape drive" for VMS Re: "Network tape drive" for VMS Re: "Network tape drive" for VMS Re: "Network tape drive" for VMS Re: "Network tape drive" for VMS Re: "Network tape drive" for VMS Re: "Network tape drive" for VMS Re: "Network tape drive" for VMS Re: "Network tape drive" for VMS Re: "Network tape drive" for VMS RE: "Network tape drive" for VMS Any known BASIC/SMG issues on Itanium? Re: Any known BASIC/SMG issues on Itanium? Re: Imagemagick 6.30 and text drawing ? ---------------------------------------------------------------------- Date: Thu, 17 Jul 2008 14:19:05 -0400 From: "Richard B. Gilbert" Subject: Re: "Network tape drive" for VMS Message-ID: <487F8D19.2070302@comcast.net> R.A.Omond wrote: > Albrecht Schlosser wrote: >> Is there anything available that could be called a >> "network tape drive" that is supported with >> >> (a) OpenVMS / Alpha 7.3-2 >> (b) OpenVMS / I64, 8.2 or 8.3 ff. ? >> >> The reason is to have the backup tape drive separated from the >> server for easier access to change the backup tapes. >> >> Please don't ask, why would you want to do that. It's simply >> because of a user's request. And this should *not* be another >> VMS server (cluster node) with a tape drive ;-) > > I always have real difficulty trying to comprehend such > requests. > > What's the limit on xxx-SCSI cable length ? 25 metres ? > Why can't you simply place the tape drive in e.g. a separate > room. It's 25 meters ONLY for differential SCSI. It's more like two meters for single ended. > > And why can't it be another VMS server/cluster-node with > a tape drive ? What's wrong with that idea ? You would have to: 1. Buy another computer, 2. Cluster it. 3. Keep it OUTSIDE the computer room which makes it a security hole all by itself. 4. The OP did say "And this should *not* be another VMS server (cluster node) with a tape drive ;-)" ------------------------------ Date: 17 Jul 2008 13:39:43 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: "Network tape drive" for VMS Message-ID: In article , Albrecht Schlosser writes: > > Please don't ask, why would you want to do that. It's simply > because of a user's request. And this should *not* be another > VMS server (cluster node) with a tape drive ;-) OK, I could do that with a VMS workstation (cluser node) with a tape drive. ;-) Multinet supports remote tapes, and is probably compatable with some UNIX implementations. You really want a tape as network attached storage? How about an Infoserver? ------------------------------ Date: Thu, 17 Jul 2008 15:18:03 -0400 From: JF Mezei Subject: Re: "Network tape drive" for VMS Message-ID: <487f9b0f$0$18527$c3e8da3@news.astraweb.com> Richard B. Gilbert wrote: > It's 25 meters ONLY for differential SCSI. It's more like two meters > for single ended. What about iSCSI ? Could this be a solution ? Does VMS support iSCSI ? I recall one TCPIP engineer having done work on it at about the time he was made redudant by Seniorita La Carly. ------------------------------ Date: Thu, 17 Jul 2008 15:31:49 -0400 From: "Richard B. Gilbert" Subject: Re: "Network tape drive" for VMS Message-ID: JF Mezei wrote: > Richard B. Gilbert wrote: > >> It's 25 meters ONLY for differential SCSI. It's more like two meters >> for single ended. > > > What about iSCSI ? Could this be a solution ? Does VMS support iSCSI ? I > recall one TCPIP engineer having done work on it at about the time he > was made redudant by Seniorita La Carly. > No experience with iSCSI! I worked for technologically backward employers who used only wired SCSI. I once looked into SAN sometime between 1999 and 2004 and was told that VMS did not support the available hardware! Fiber SCSI might be a solution. ------------------------------ Date: Thu, 17 Jul 2008 21:36:14 +0100 From: Mark McIntyre Subject: Re: "Network tape drive" for VMS Message-ID: <23Ofk.219092$Uf4.54936@en-nntp-08.dc1.easynews.com> Seems to me this is the wrong problem to be solving - the requirement arises because end-users are changing the backup tapes themselves. I'm sure they're only doing that because 'historically' the server was in their office. Surely the /right/ solution is to get someone in IT to do that? Why move the server to the DC, if not to make it more secure, more maintainable and more reliable. ------------------------------ Date: Thu, 17 Jul 2008 14:39:11 -0700 (PDT) From: johnwallace4@gmail.com Subject: Re: "Network tape drive" for VMS Message-ID: <1f7df0f8-b35f-4319-b040-028d3383f5f7@59g2000hsb.googlegroups.com> On Jul 17, 9:36 pm, Mark McIntyre wrote: > Seems to me this is the wrong problem to be solving - the requirement > arises because end-users are changing the backup tapes themselves. I'm > sure they're only doing that because 'historically' the server was in > their office. > > Surely the /right/ solution is to get someone in IT to do that? Why move > the server to the DC, if not to make it more secure, more maintainable > and more reliable. Why move the server? Because "policy" says it's the done thing, perhaps, without actually considering the real advantages and disadvantages in any particular circumstances? A long time ago, when I wanted to solve the problem being addressed here, ie there was no guarantee that a server-room-authorised person would be on site to change tapes, the "clustered VMS node with tape drive, outside the server room" was the exact solution chosen. We put the tape drive (and its host) where there *was* always going to be a person available to change tapes, because in the circumstances at that time, we considered the "security risks" of having a VMS system outside the computer room were outweighed by the value of having reasonable confidence that the daily backups would still get completed even if multiple tapes were needed. Sites with particularly sensitive data or other different factors to consider might end up making different decisions. One size does not necessarily suit all. 2p John ------------------------------ Date: Fri, 18 Jul 2008 00:01:45 +0100 From: Mark McIntyre Subject: Re: "Network tape drive" for VMS Message-ID: johnwallace4@gmail.com wrote: > Why move the server? Because "policy" says it's the done thing, > perhaps, without actually considering the real advantages and > disadvantages in any particular circumstances? Well, the advantages could be significant. I once worked in a firm where the fileserver was in the admin office. And, no shaggy dog story, someone once powered it off by mistake to plug in their razor. Most amusing. I've also had kit nicked from offices. Racked in a DC a server is secure, on redundant PSUs, on the UPS, can have multiple network paths and so forth. > A long time ago, when I wanted to solve the problem being addressed > here, ie there was no guarantee that a server-room-authorised person > would be on site to change tapes, I find it a little tricky to understand how that circumstance can arise. If you have a secure server room, you have people managing it. A friday afternoon job can be to swap tapes. I suspect the problem only arises when some PHB decrees there shall be a locked server room, but doesn't hire an IT team to manage it.... > One size does not necessarily suit all. I agree. Why invest in a secure server room if your data isn't important? :-) ------------------------------ Date: Thu, 17 Jul 2008 16:21:04 -0700 From: "Tom Linden" Subject: Re: "Network tape drive" for VMS Message-ID: On Thu, 17 Jul 2008 07:01:15 -0700, Tom Linden wrote: > On Thu, 17 Jul 2008 06:11:14 -0700, Albrecht Schlosser > wrote: > >> Is there anything available that could be called a >> "network tape drive" that is supported with >> >> (a) OpenVMS / Alpha 7.3-2 >> (b) OpenVMS / I64, 8.2 or 8.3 ff. ? >> >> The reason is to have the backup tape drive separated from the >> server for easier access to change the backup tapes. >> >> Please don't ask, why would you want to do that. It's simply >> because of a user's request. And this should *not* be another >> VMS server (cluster node) with a tape drive ;-) >> >> Albrecht > > If you have fibre, put it on a Modular Data Router > You didn't say whether you had fibre or not, but I just checked an MDR will run you ~$500. You can get a fibre switch for less than $300 and HBAs can be had for $20-40 each. This is your best solution, allowing you to put the tape unit as far away as you please from the computer room -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Thu, 17 Jul 2008 16:34:12 -0700 (PDT) From: FrankS Subject: Re: "Network tape drive" for VMS Message-ID: On Jul 17, 9:11=A0am, Albrecht Schlosser wrote: > Is there anything available that could be called a > "network tape drive" that is supported with > > (a) OpenVMS / Alpha 7.3-2 > (b) OpenVMS / I64, 8.2 or 8.3 ff. ? > > The reason is to have the backup tape drive separated from the > server for easier access to change the backup tapes. > > Please don't ask, why would you want to do that. It's simply > because of a user's request. And this should *not* be another > VMS server (cluster node) with a tape drive ;-) > > Albrecht I'll second the many comments about getting a fibre HBA installed in the system (if it doesn't already have one), and a fibre switch, and an MDR or NSR (is that what the newer ones are called?), and putting the tape outside the data center. However, there's also this new technology called "auto loaders". Pretty nifty. You can have multiple LTO or DLT cartridges in the thing and they load automatically. Only been around, oh, 25 years or so. That would allow you to leave the tape drive in the data center, where it belongs, and let the operator/IT admin worry about it. To more directly answer your question about whether network tape backups are available for OpenVMS: probably. Just keep in mind, though, that a network tape backup device is just another server with a tape drive attached. ------------------------------ Date: Thu, 17 Jul 2008 19:44:32 -0400 From: "Richard B. Gilbert" Subject: Re: "Network tape drive" for VMS Message-ID: <35idnacSntCIR-LVnZ2dnUVZ_j2dnZ2d@comcast.com> Mark McIntyre wrote: > johnwallace4@gmail.com wrote: >> Why move the server? Because "policy" says it's the done thing, >> perhaps, without actually considering the real advantages and >> disadvantages in any particular circumstances? > > Well, the advantages could be significant. I once worked in a firm where > the fileserver was in the admin office. And, no shaggy dog story, > someone once powered it off by mistake to plug in their razor. Most > amusing. I've also had kit nicked from offices. Racked in a DC a server > is secure, on redundant PSUs, on the UPS, can have multiple network > paths and so forth. > >> A long time ago, when I wanted to solve the problem being addressed >> here, ie there was no guarantee that a server-room-authorised person >> would be on site to change tapes, > > I find it a little tricky to understand how that circumstance can arise. > If you have a secure server room, you have people managing it. A friday > afternoon job can be to swap tapes. I suspect the problem only arises > when some PHB decrees there shall be a locked server room, but doesn't > hire an IT team to manage it.... > > > One size does not necessarily suit all. > > I agree. Why invest in a secure server room if your data isn't > important? :-) Backups can, and sometimes do, run for many hours and require multiple tapes. Usually, you schedule backups for "off hours" when very few people, ideally no one, is using the system. Do you pay an operator for eight hours of swing shift or graveyard shift only to change a backup tape? Some do. It may be cheaper than paying the capital and maintenance costs of an automated tape library. I had operators to mount tapes so I only had to schedule the batch job, and check the log for errors in the morning. ------------------------------ Date: Thu, 17 Jul 2008 20:01:44 -0400 From: "Richard B. Gilbert" Subject: Re: "Network tape drive" for VMS Message-ID: FrankS wrote: > On Jul 17, 9:11 am, Albrecht Schlosser wrote: >> Is there anything available that could be called a >> "network tape drive" that is supported with >> >> (a) OpenVMS / Alpha 7.3-2 >> (b) OpenVMS / I64, 8.2 or 8.3 ff. ? >> >> The reason is to have the backup tape drive separated from the >> server for easier access to change the backup tapes. >> >> Please don't ask, why would you want to do that. It's simply >> because of a user's request. And this should *not* be another >> VMS server (cluster node) with a tape drive ;-) >> >> Albrecht > > I'll second the many comments about getting a fibre HBA installed in > the system (if it doesn't already have one), and a fibre switch, and > an MDR or NSR (is that what the newer ones are called?), and putting > the tape outside the data center. > > However, there's also this new technology called "auto loaders". > Pretty nifty. You can have multiple LTO or DLT cartridges in the > thing and they load automatically. Only been around, oh, 25 years or > so. That would allow you to leave the tape drive in the data center, > where it belongs, and let the operator/IT admin worry about it. > > To more directly answer your question about whether network tape > backups are available for OpenVMS: probably. Just keep in mind, > though, that a network tape backup device is just another server with > a tape drive attached. I've used such a gadget, actually two. One was just a "stacker that held seven or eight DLT tapes and would load them in sequence. The other was a "robot" from Storage Technology that held some large number of tapes (50??, 100????) and could select a particular tape using a barcode scanner, mount that tape and let you access it over the network. That gadget backed up just about the whole data center! ------------------------------ Date: Thu, 17 Jul 2008 17:07:51 -0700 (PDT) From: johnwallace4@gmail.com Subject: Re: "Network tape drive" for VMS Message-ID: <69755f51-0707-446d-90ee-40054683fbc5@m73g2000hsh.googlegroups.com> On Jul 18, 12:01 am, Mark McIntyre wrote: > johnwalla...@gmail.com wrote: > > Why move the server? Because "policy" says it's the done thing, > > perhaps, without actually considering the real advantages and > > disadvantages in any particular circumstances? > > Well, the advantages could be significant. I once worked in a firm where > the fileserver was in the admin office. And, no shaggy dog story, > someone once powered it off by mistake to plug in their razor. Most > amusing. I've also had kit nicked from offices. Racked in a DC a server > is secure, on redundant PSUs, on the UPS, can have multiple network > paths and so forth. > > > A long time ago, when I wanted to solve the problem being addressed > > here, ie there was no guarantee that a server-room-authorised person > > would be on site to change tapes, > > I find it a little tricky to understand how that circumstance can arise. > If you have a secure server room, you have people managing it. A > friday afternoon job can be to swap tapes. I suspect the problem only > arises when some PHB decrees there shall be a locked server room, but > doesn't hire an IT team to manage it.... > > > One size does not necessarily suit all. > > I agree. Why invest in a secure server room if your data isn't > important? :-) "If you have a secure server room, you have people managing it." Indeed, but does "managing it" routinely imply "physically present in it", except on special occasions (e.g. kit adds/moves/changes and the odd emergency)? "Lights out computing" [1] isn't a phrase you hear much these days, but once upon a time, there was a widespread goal of keeping people OUT of the computer room as much as was possible, because a routinely locked and routinely unoccupied computer room was (and still should be) a safer computer room. Once upon a time, "managing" a server room didn't require physical access to PeeCee consoles or whatever, stuff could mostly be done remotely without requiring people actually present in the computer room. In principle, systems could be managed from anywhere on the corporate network using things called VT100s and terminal servers and VAXcluster Console Systems (if you were lucky), and related cleverness. These days, with a few honourable exceptions, you routinely have people in the server room because you routinely need access to the kbd/mouse/monitor to do routine sysadmin stuff on x86 boxes and and whatever other PC-centric kit is in there, and you routinely have people in there adding new servers (or maybe blades) every time a new production app arrives... I believe some people call it progress. You want a shaggy dog true story? A former colleague commissioned the VMS-based multi-site SCADA network for a major UK utility. One day, his host for the day on a particular site was off sick, and therefore because my colleague would have been unescorted, the security folks didn't allow him on that particular site. Did it stop him doing what he'd planned for the day? No. He explained the situation to an understanding manager on a different site, who was happy to allow access to his network and **the day's work was done remotely** over the WAN, invisible to the security man who said you can't come in because you need an escort. How does that work these days with PCs and the like (unless you've spent a small fortune on Proliant-class high end server management option cards and high-bandwidth low-latency inter-site links)? Whatever. [1] http://www.it-analysis.com/technology/infrastructure/content.php?cid=8169 ------------------------------ Date: Fri, 18 Jul 2008 02:04:18 +0000 From: "Main, Kerry" Subject: RE: "Network tape drive" for VMS Message-ID: > -----Original Message----- > From: johnwallace4@gmail.com [mailto:johnwallace4@gmail.com] > Sent: July 17, 2008 8:08 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: "Network tape drive" for VMS > > On Jul 18, 12:01 am, Mark McIntyre > wrote: > > johnwalla...@gmail.com wrote: > > > Why move the server? Because "policy" says it's the done thing, > > > perhaps, without actually considering the real advantages and > > > disadvantages in any particular circumstances? > > > > Well, the advantages could be significant. I once worked in a firm > where > > the fileserver was in the admin office. And, no shaggy dog story, > > someone once powered it off by mistake to plug in their razor. Most > > amusing. I've also had kit nicked from offices. Racked in a DC a > server > > is secure, on redundant PSUs, on the UPS, can have multiple network > > paths and so forth. > > > > > A long time ago, when I wanted to solve the problem being addressed > > > here, ie there was no guarantee that a server-room-authorised > person > > > would be on site to change tapes, > > > > I find it a little tricky to understand how that circumstance can > arise. > > If you have a secure server room, you have people managing it. A > > friday afternoon job can be to swap tapes. I suspect the problem only > > arises when some PHB decrees there shall be a locked server room, but > > doesn't hire an IT team to manage it.... > > > > > One size does not necessarily suit all. > > > > I agree. Why invest in a secure server room if your data isn't > > important? :-) > > "If you have a secure server room, you have people managing it." > > Indeed, but does "managing it" routinely imply "physically present in > it", except on special occasions (e.g. kit adds/moves/changes and the > odd emergency)? > > "Lights out computing" [1] isn't a phrase you hear much these days, > but once upon a time, there was a widespread goal of keeping people > OUT of the computer room as much as was possible, because a routinely > locked and routinely unoccupied computer room was (and still should > be) a safer computer room. Once upon a time, "managing" a server room > didn't require physical access to PeeCee consoles or whatever, stuff > could mostly be done remotely without requiring people actually > present in the computer room. In principle, systems could be managed > from anywhere on the corporate network using things called VT100s and > terminal servers and VAXcluster Console Systems (if you were lucky), > and related cleverness. These days, with a few honourable exceptions, > you routinely have people in the server room because you routinely > need access to the kbd/mouse/monitor to do routine sysadmin stuff on > x86 boxes and and whatever other PC-centric kit is in there, and you > routinely have people in there adding new servers (or maybe blades) > every time a new production app arrives... I believe some people call > it progress. > > You want a shaggy dog true story? A former colleague commissioned the > VMS-based multi-site SCADA network for a major UK utility. One day, > his host for the day on a particular site was off sick, and therefore > because my colleague would have been unescorted, the security folks > didn't allow him on that particular site. Did it stop him doing what > he'd planned for the day? No. He explained the situation to an > understanding manager on a different site, who was happy to allow > access to his network and **the day's work was done remotely** over > the WAN, invisible to the security man who said you can't come in > because you need an escort. How does that work these days with PCs and > the like (unless you've spent a small fortune on Proliant-class high > end server management option cards and high-bandwidth low-latency > inter-site links)? > > Whatever. > > [1] http://www.it- > analysis.com/technology/infrastructure/content.php?cid=3D8169 John, What's new is old and what's old is new .. :-) There is a huge push in most large corps these days to not only consolidate Servers, but also server rooms and even entire DC's as well. Goal is to reduce redundant facility, electrical and cooling costs which in many cases are huge. The target environment is usually classified as "lights out" unmanned DC's which have very high HA capabilities - including multi-site capabilities. Sound familiar? Btw, one of my favourite lines to shock some Cust's into today's modern way of looking at DC's is absolutely no tours of the DC are allowed. Nada. Reason - while a certain number of OPS staffers are required, for every person who enters the DC, you run the risk of shutting down the entire DC, because that person may have unknowingly been exposed to SARS or any other number of pandemic issues. This is not speculation as it actually happened to a large DC in Toronto during the SARS crisis a few years ago. An entire facility was shutdown by the guys in white suits and big guns after an Operations staffer returne= d a day early after being told to stay home for 10 days when it was thought that he "may" have been exposed to someone who had SARS at a family picnic. Luckily, the site was part of a dual site and the one site could mostly be remotely managed from the other site. Everyone in that *entire* facility had to go home for 10 days (no backups, no "can I just do .." - leave and go home immediately), so think about alternate staffing plans as well and whether your staff can work effectively from home. To readers of this list - think about your own environments and how you would handle a white suit showing up on your doorstep and telling everyone in that facility where your primary DC is to go home for 10 days. And with many companies resources travelling globally, bringing resources from Asia and other parts of the globe to train locally etc, the chances of this happening are not that small. Pretty spooky in most cases. Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-254-8911 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT) OpenVMS - the secure, multi-site OS that just works. ------------------------------ Date: Thu, 17 Jul 2008 16:26:02 -0700 (PDT) From: Rich Jordan Subject: Any known BASIC/SMG issues on Itanium? Message-ID: One of our VMS customers who recently switched from Alpha to Itanium just turned up a problem with a not-commonly used feature. The programs they use are in VMS BASIC and use the SMG libraries for screen display. One function for print-screen uses the SMG $PUT_PASTEBOARD call, which uses a user-written subroutine to actually output each line of the pasteboard in sequence to a file/device/etc. The code has been working for decades on VAX and Alpha. It fails on I64 VMS, both V8.3 and V8.2-1 using the same source files and the same compile/link commands. We pulled out the two library modules used and built them independently on each system using the same BASIC command lines just to be sure (no other user library functions are involved in the test program). The V8.2-1 system is up to date on ECOs including the BASRTL ones. The V8.3 system is behind but running Update V4 with BASRTL V2. The test program works fine, built from the same source with the same BASIC command line options, on Alpha V7.3-2 and V8.3. BASIC is V1.6 on the itaniums, V1.5 on the V7.3-2 Alpha, and V1.6 on the V8.3 Alpha. Running with debug I can trace it into the SMG call. The problem appears to be the SMG routine's call to the user action routine, which takes two arguments: string descriptor (for one line of screen info) unsigned long user argument by value (defaults to '0') The action routine is supposed to output or otherwise deal with the one screen line per call and is called once for each line in the pasteboard. Here it is called but the program dies as the routine is entered, the source for the action routine pops up in the debug window, but the error has already occurred. Error message received from the error handler is: %BAS-F-TOOFEWARGS, Too few arguments -BAS-I-FROLINSUB, from line 2140 in line VT.PRINT_SCREEN -BAS-I-FROMOD, In module TEST I know the argument setup for both the VT.PRINT_SCREEN call, and the SMG$PUT_PASTEBOARD call are correct and we've updated the two print subs (including the action routine) to 'modern' standards with prototyping of arguments to the extent BASIC allows. No change. Just thought I'd ask here before talking to HP about it in case anyone has seen something similar. So far this is the only porting issue we've had outside of translating some very old VAX MACRO files to BASIC. Thanks ------------------------------ Date: Fri, 18 Jul 2008 04:01:21 GMT From: John Santos Subject: Re: Any known BASIC/SMG issues on Itanium? Message-ID: Rich Jordan wrote: > One of our VMS customers who recently switched from Alpha to Itanium > just turned up a problem with a not-commonly used feature. The > programs they use are in VMS BASIC and use the SMG libraries for > screen display. One function for print-screen uses the SMG > $PUT_PASTEBOARD call, which uses a user-written subroutine to actually > output each line of the pasteboard in sequence to a file/device/etc. > The code has been working for decades on VAX and Alpha. > > It fails on I64 VMS, both V8.3 and V8.2-1 using the same source files > and the same compile/link commands. We pulled out the two library > modules used and built them independently on each system using the > same BASIC command lines just to be sure (no other user library > functions are involved in the test program). > > The V8.2-1 system is up to date on ECOs including the BASRTL ones. > The V8.3 system is behind but running Update V4 with BASRTL V2. The > test program works fine, built from the same source with the same > BASIC command line options, on Alpha V7.3-2 and V8.3. BASIC is V1.6 > on the itaniums, V1.5 on the V7.3-2 Alpha, and V1.6 on the V8.3 Alpha. > > Running with debug I can trace it into the SMG call. The problem > appears to be the SMG routine's call to the user action routine, which > takes two arguments: > string descriptor (for one line of screen info) > unsigned long user argument by value (defaults to '0') > > The action routine is supposed to output or otherwise deal with the > one screen line per call and is called once for each line in the > pasteboard. Here it is called but the program dies as the routine is > entered, the source for the action routine pops up in the debug > window, but the error has already occurred. > > Error message received from the error handler is: > > %BAS-F-TOOFEWARGS, Too few arguments > -BAS-I-FROLINSUB, from line 2140 in line VT.PRINT_SCREEN > -BAS-I-FROMOD, In module TEST > > I know the argument setup for both the VT.PRINT_SCREEN call, and the > SMG$PUT_PASTEBOARD call are correct and we've updated the two print > subs (including the action routine) to 'modern' standards with > prototyping of arguments to the extent BASIC allows. No change. > > Just thought I'd ask here before talking to HP about it in case anyone > has seen something similar. So far this is the only porting issue > we've had outside of translating some very old VAX MACRO files to > BASIC. > > Thanks > We had a problem with code in a "USEROPEN" function not executing correctly that is fixed in BASIC V1.7. Compiling /nooptimize in V1.6 was a workaround. That was the only porting issue we have found so far. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: Thu, 17 Jul 2008 15:50:34 -0400 From: JF Mezei Subject: Re: Imagemagick 6.30 and text drawing ? Message-ID: <487fa2b8$0$1829$c3e8da3@news.astraweb.com> For the sake of deja news archiving: I copied all .XML files to the current directory, then edited type-ghosttscript.xml and changed the /usr/share/fonts/default/Type1/ to "gs_lib:" (which points to the ghostscript fonts) And Eureka ! I was able to add text to an image ! I would still need to work out how to make the unix software find the .XML files "naturally" in the software directories instead of having to use brite force and copy all those files over to the current working directory to ensure that imagemagick can find them. Is there some mechanism on VMS that could help C software lookin for "X.XML" file use some sort of search path that would look at list of directories instead of just the current directory ? ------------------------------ End of INFO-VAX 2008.398 ************************