INFO-VAX Mon, 12 Feb 2007 Volume 2007 : Issue 85 Contents: Re: Guidelines for converting programs to ODS-5? Re: Guidelines for converting programs to ODS-5? Re: Migrating C application from VMS to LINUX Re: Virtual tape libraries ---------------------------------------------------------------------- Date: 11 Feb 2007 21:29:27 -0600 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: Guidelines for converting programs to ODS-5? Message-ID: In article , Paul Sture writes: > Hi folks, > > Are there any guidelines out there for ensuring that programs developed > before the days of ODS-5 are ODS-5 aware? Looking over my code (aside from bugs that were eliminated) I find the main difference is that when a disk is mounted EFS I use NAML blocks and otherwise (including VAX) I use NAM blocks. I know there is some degree to which ODS-5 disks are accessible on VAX, but my approach has been to say those should be accessed from Alpha. ------------------------------ Date: Sun, 11 Feb 2007 22:20:41 -0600 (CST) From: sms@antinode.org (Steven M. Schweda) Subject: Re: Guidelines for converting programs to ODS-5? Message-ID: <07021122204111_202B6533@antinode.org> From: Paul Sture > Are there any guidelines out there for ensuring that programs developed > before the days of ODS-5 are ODS-5 aware? Strictly speaking, it would be hard to ensure it, as it's probably not true. Adapting to ODS5 involves changing from NAM to NAML (if NAML$C_MAXRSS is defined), but there's a lot of fine print. I find it convenient to have C programs set their own DECC$feature flags (like DECC$ARGV_PARSE_STYLE, DECC$EFS_CASE_PRESERVE, and DECC$EFS_CHARSET). If using SYS$QIO[W] for disk I/O, look into naml$l_filesys_name (and naml$l_filesys_name_alloc), as the encoding for QIO is quirky. File names can be longer, so look for hard-coded string lengths which are now too small. Case-insensitive comparisons may not always be appropriate now. Processing funny extended file names may involve caret removal after parsing (for more UNIX-like display, for example). File spec parsing _not_ done using system services will probably be easy to confuse with funny names. Many formerly special characters (":", "[", "]". ";", ".", and so on) may now appear in file names as (almost) ordinary characters (give or take a caret). I assume that there are more worries, but this is what leaps out from a glance at the changes for the new Info-ZIP programs. Feel free to look over the pre-release Zip 3 and UnZip 6 sources (and let me know when you find the problems). ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Sun, 11 Feb 2007 21:21:25 -0500 From: "Richard B. gilbert" Subject: Re: Migrating C application from VMS to LINUX Message-ID: <45CFCF25.4010105@comcast.net> David J Dachtera wrote: > "Richard B. gilbert" wrote: > >>David J Dachtera wrote: >> >>>[snip] >>>With today's demands to down-size the datacenter (google for "VMware"), this is >>>even less practical than it was when it first became the norm. >>> >>>Because of the situation this propagates, we have close to 500 "servers" in our >>>data center. Management would to cut that by 90%. >>> >> >>Well, if Windows weren't such a "one trick pony", things would be very >>different in the data center. Nobody wants to give a Windows Server two >>jobs to do. Windows just isn't very good at protecting applications >>from each other! >> >>VMWare ESX does a pretty good job of "virtualizing" servers. Buy a box >>with enough "horse power" and you can put three or four virtual servers >>on it. VMware will protect them from each other. >> >>BTW, unless those 500 servers are mostly idle, you aren't going to be >>able to make a 90% cut. > > > Dunno 'bout that. The great bulk of the servers we have are largely idle (5% to > 10% utilization). It may not as unrecahable as it seems at first glance. > > That said, if machines appeared that were prime candidates to run VMware ESX and > 5 to 10 instances of WhineBloze, 80% to 90% reductions would come within reach. > > Shades of VM on the IBM Mainframe! What was old is new again! > Well, of course! My humble $700 PC would blow the doors off the mainframes of that generation. A modern server typically runs two to four processors, has at least 4 GB of memory, etc, etc. If it could execute the 370 instruction set, it could run VM without working up a sweat!! ------------------------------ Date: Sun, 11 Feb 2007 18:23:16 -0600 From: David J Dachtera Subject: Re: Virtual tape libraries Message-ID: <45CFB374.FD1014A0@spam.comcast.net> Marc Van Dyck wrote: > > After serious thinking David J Dachtera wrote : > [snip] > > Did you ever explore the Remote Device facility (3rd(4th?) party product) > > that ships with SLS? > > Yes, we tried that at the time the typical network speeds were around > 10 Mb/s. Data size was around 500 MB per cluster. Now we're connected > at 1 Gb/s but total data size is over 10 TB, still not very realistic > for backups over the network. Well, considering that 1Gb Ethernet is where 1Gb FC was just recently, it's a bit less impractical that it was before. I do believe the backup resource broker would be what you want to develop. Could even become a lucrative piece to productize. -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ End of INFO-VAX 2007.085 ************************