INFO-VAX Tue, 13 Feb 2007 Volume 2007 : Issue 88 Contents: Re: DST changes and VMS 7.2 Re: Guidelines for converting programs to ODS-5? Re: Guidelines for converting programs to ODS-5? Re: Guidelines for converting programs to ODS-5? Re: Guidelines for converting programs to ODS-5? Re: Guidelines for converting programs to ODS-5? Re: Guidelines for converting programs to ODS-5? Re: How to synchronize two directory trees Re: How to synchronize two directory trees Re: How to synchronize two directory trees Re: Intel 80 core chip revealed in full detail Re: Migrating C application from VMS to LINUX Re: Migrating C application from VMS to LINUX RE: Migrating C application from VMS to LINUX Re: Migrating C application from VMS to LINUX Re: Migrating C application from VMS to LINUX Migrating C application from VMS to LINUX Re: Migrating C application from VMS to LINUX Re: Migrating C application from VMS to LINUX Re: SPANNING BACKUP TAPES Re: Understanding DSL10L cabinet/hardware Re: X Windows App Re: X Windows App ---------------------------------------------------------------------- Date: Tue, 13 Feb 2007 10:04:12 -0500 From: Stephen Hoffman Subject: Re: DST changes and VMS 7.2 Message-ID: heywood.floyd@yahoo.com wrote: > Timezone files for unsupported versions of VMS can be downloaded from: > > System: hprc.external.hp.com > Login: tz > Password: timezone (NOTE: CASE-sensitive) > > FTP Access: ftp://tz:timezone@hprc.external.hp.com/ > > Heywood.Floyd@yahoo.com That TZ area reminds me of the Monolith in orbit around Jupiter. I've been studying it, but I don't understand it. Have you checked the orbit? Puzzlement: You can get the entire set of timezone definitions directly from the master TZ site (ftp://elsie.nci.nih.gov/pub/), re-zic them, and you don't need to deal with the weird zippage at the HP site. I see the master timezone definitions were changed yesterday, too. Dimitri Moisevitch -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ Date: 13 Feb 2007 08:07:25 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Guidelines for converting programs to ODS-5? Message-ID: In article <6G8wLPHFOEIE@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes: > In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > >> For adding ODS-5 feature access from a program, I've conditionally >> compiled my RMS code for VAX vs. other, using NAM vs. NAML. > > That does add a limitation against running on earlier versions of VMS. > > Then again, all my current code assumes the longer filenames introduced > at VMS V4.0, so it is just a matter of where one draws the line :-) I generally also use $GETDVI to see whether I'm using ODS-5. I've got some code, not completely debugged, that works with ODS-1, ODS-2, ODS-5, and labeled tapes. To do this I've had to conditionally add the definition of the ODS-5 symbol (not defined on VAX VMS 7.3 even though $GETDVI can return it there). And I put all the ODS-5 specific handling inside an #ifndef VAX type construct (if ODS-5 is detected from my VAX the code treats it like ODS-2). For ODS-1 testing I have to fire up LDDRIVER on a VAX since ODS-1 is not supported unless on VAX, nor on any disk as large as my smallest. ------------------------------ Date: 13 Feb 2007 08:09:24 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Guidelines for converting programs to ODS-5? Message-ID: In article <45D08DFA.7040401@comcast.net>, "Richard B. gilbert" writes: > > Many years ago, the standard advice was NOT to try to parse a filespec > yourself. Anybody who's been around long enough can construct a legal > file spec that your routine cannot parse correctly (unless you're in VMS > Engineering). Now this was before ODS-5 but it wouldn't surprise me to > learn that it's still good advice. > I prefer SYS$FILESCAN when I must parse a file name, but some folks prefer SYS$PARSE. And lots of folks don't follow the recommended approach. Which leads to unecessary maintenance work. ------------------------------ Date: 13 Feb 2007 08:15:03 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Guidelines for converting programs to ODS-5? Message-ID: In article <07021209583700_202B6533@antinode.org>, sms@antinode.org (Steven M. Schweda) writes: > > Not if you give them ODS5 extended file names to work with, > obviously, which seems almost inevitable if you use them with an ODS5 > file system. > > Or did you mean to say something which made some sense? If the OP just needs the program to keep running on an ODS-5 disk as it had on an ODS-2 disk, there's no problem. If it needs to handle ODS-5 capabilities not accounted for when it was written then adding those capabilities may be language/compiler-version dependent. If you call RMS routines directly, you can do the work from any language. When ODS-5 first came out I found my Fortran compiler at the time could not deal with the extended names no matter what I did without replacing Fortran I/O with RMS calls (I couldn't even pass an extended name to a USEROPEN). I'm not sure if all compilers and RTLs have been updated yet. ------------------------------ Date: Tue, 13 Feb 2007 07:55:25 -0800 From: "Tom Linden" Subject: Re: Guidelines for converting programs to ODS-5? Message-ID: On Tue, 13 Feb 2007 06:15:03 -0800, Bob Koehler wrote: > In article <07021209583700_202B6533@antinode.org>, sms@antinode.org > (Steven M. Schweda) writes: >> >> Not if you give them ODS5 extended file names to work with, >> obviously, which seems almost inevitable if you use them with an ODS5 >> file system. >> >> Or did you mean to say something which made some sense? > > If the OP just needs the program to keep running on an ODS-5 disk > as it had on an ODS-2 disk, there's no problem. If it needs to > handle ODS-5 capabilities not accounted for when it was written > then adding those capabilities may be language/compiler-version > dependent. > > If you call RMS routines directly, you can do the work from any > language. When ODS-5 first came out I found my Fortran compiler > at the time could not deal with the extended names no matter what > I did without replacing Fortran I/O with RMS calls (I couldn't > even pass an extended name to a USEROPEN). I'm not sure if all > compilers and RTLs have been updated yet. > This prompted me to check, and in PL/I the expanded file name is limited to 128 chars, we may have to exentend that. What limit does Fortran have? -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ------------------------------ Date: Tue, 13 Feb 2007 11:24:11 -0500 From: Stephen Hoffman Subject: Re: Guidelines for converting programs to ODS-5? Message-ID: Tom Linden wrote: > This prompted me to check, and in PL/I the expanded file name is limited > to 128 chars, we may have to exentend that. What limit does Fortran have? ODS-2 is NAM$C_MAXRSS (255) and ODS-5 is NAML$C_MAXRSS (4095). -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ Date: Tue, 13 Feb 2007 08:47:03 -0800 From: "Tom Linden" Subject: Re: Guidelines for converting programs to ODS-5? Message-ID: On Tue, 13 Feb 2007 08:24:11 -0800, Stephen Hoffman wrote: > Tom Linden wrote: > >> This prompted me to check, and in PL/I the expanded file name is limited >> to 128 chars, we may have to exentend that. What limit does Fortran >> have? > > > ODS-2 is NAM$C_MAXRSS (255) and ODS-5 is NAML$C_MAXRSS (4095). > On further checking it is 4K, but now we can fix the documentation, which probably stems from ODS-1 :-) -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ------------------------------ Date: Tue, 13 Feb 2007 09:39:59 -0500 From: Stephen Hoffman Subject: Re: How to synchronize two directory trees Message-ID: vancouvercancun@yahoo.ca wrote: > Does anyone know of a tool/utility to synchronize the content of 2 > directory trees ? ... > Before I take the time to write my own command procedure, do you have > suggestions ? Not exactly what you want, but it's pretty close. It doesn't delete stuff and it doesn't actually copy stuff, (both are trivial changes) but it deals with the rest of the requirements. http://h71000.www7.hp.com/freeware/freeware80/hoffman_examples/ diff_directories.com Since the directory and file-level merge it provides is inherently a manual process, I didn't want to delete and I didn't want to copy. But that's a small change to the procedure. The DCL involved is simple, so creating a new tool or altering an existing tool is a simple task. I'm certain there are other options and other tools around. There might well be commercial products, or ports of various tools. (This is a pretty standard "merge" task in a software development environment.) The best solution might be to serve the directory somehow, and to have but one copy of it around. -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ Date: Tue, 13 Feb 2007 07:48:28 -0800 From: "Tom Linden" Subject: Re: How to synchronize two directory trees Message-ID: On Tue, 13 Feb 2007 06:39:59 -0800, Stephen Hoffman wrote: > vancouvercancun@yahoo.ca wrote: > >> Does anyone know of a tool/utility to synchronize the content of 2 >> directory trees ? > ... >> Before I take the time to write my own command procedure, do you have >> suggestions ? > > > Not exactly what you want, but it's pretty close. It doesn't delete > stuff and it doesn't actually copy stuff, (both are trivial changes) but > it deals with the rest of the requirements. > > http://h71000.www7.hp.com/freeware/freeware80/hoffman_examples/ > > diff_directories.com > > Since the directory and file-level merge it provides is inherently a > manual process, I didn't want to delete and I didn't want to copy. But > that's a small change to the procedure. > > The DCL involved is simple, so creating a new tool or altering an > existing tool is a simple task. > > I'm certain there are other options and other tools around. There might > well be commercial products, or ports of various tools. (This is a > pretty standard "merge" task in a software development environment.) > > The best solution might be to serve the directory somehow, and to have > but one copy of it around. > > Why not CMS and a little discipline? -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ------------------------------ Date: Tue, 13 Feb 2007 11:21:33 -0500 From: Stephen Hoffman Subject: Re: How to synchronize two directory trees Message-ID: Tom Linden wrote: > Why not CMS and a little discipline? Because it's not applicable to all situations? If the universe and the directories are consistently and continuously connected through a sufficient and secure network, then yes, something like CMS can be useful. (And should you have CMS available. Some don't.) (And if you're doing stuff where you want to be able to access and to share and to update the contents CMS. Sometimes you really just want to be disconnected, so you don't stomp on something.) Put another way, there are cases when keeping a couple of directories synchronized through DCL worked sufficiently for local needs. In my case, that tool helped me maintain and merge code that was part of off-line development and testing work, and code that was later feed into CMS. The DCL code involved spotted potential skewage before the sources went back into CMS. The best solution I've seen -- CMS is comparatively primitive in its UI and its presentation, and the DCL tool I referenced is yet massively more brute-force -- is the approach used by ClearCase and other such tools. Where you have a virtual volume, as presented by the source system. That's incredibly slick, and equally powerful. particularly when you can compare views. When you set your library and class (stream, in VDE), you are presented with what looks like a standard disk, and the files shown are the source code. The source library database is certainly there behind the presentation, but the presentation is entirely different than that of CMS. I haven't looked to see if there's an equivalent presentation layer for Subversion or for CVS. But back the the brute-force DCL procedure or other such manual or near-line directory synchronization tasks. It works, it has few or even no dependencies, and it works well enough for my particular needs. -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ Date: 13 Feb 2007 09:02:21 -0800 From: etmsreec@yahoo.co.uk Subject: Re: Intel 80 core chip revealed in full detail Message-ID: <1171386141.078749.325170@a75g2000cwd.googlegroups.com> Why would Intel spend lots developing 8086? IA64 is WELL ahead of 8086. Or did you mean x86-64? Steve JF Mezei wrote: > Arne Vajh=F8j wrote: > > They are currently behind Intel in the commodity market. > > Intel and AMD are in a tight race. Some times Intel will be ahead, > sometimes AMD will be ahead. > > The big question now is whether AMD will stay in the "I leap ahead, you > lead ahead" cycles, or whether its recent period of being ahead of Intel > was a single blip and AMD won't be able to beat Intel again. > > But even if AMD doesn't consisently beat Intel at regular intervals, the > gap between the two will force Intel to continue to focus on improving the > 8086 to stay ahead of AMD. And that means resources will be assigned to t= he > 8086, not that IA64 thing. ------------------------------ Date: 13 Feb 2007 13:27:30 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: Migrating C application from VMS to LINUX Message-ID: <53dsm2F1sclo3U1@mid.individual.net> In article , Dave Froble writes: > Bill Gunshannon wrote: >> In article , >> Dave Froble writes: >>> Bill Gunshannon wrote: >>> >>>> I would guess he's porting because he (or his management) has seen the >>>> writting on the wall and is not going to wait till disaster strikes >>>> before looking at solutions. >>> It's never been explained to me. Perhaps you could again try to help me >>> understand. What exactly is going to be harder to port in the future, >>> thus making it necessary to port now? >> >> Lack of availability of replacement equipment. Bugs that get discovered >> that are not going to be fixed because your a little fish and there is >> no incentive to spend the money. And just plain not waiting til the >> last minute. >> >> I have been out of the applications level of computing for quite some time, >> but the last major conversion I worked on (Honeywell to Univac 1100) took >> more than 2 years. Now, if your whole VMS library consists of one or two >> programs of ~100 lines each, then maybe it's not such a big thing, but if >> I were a major player I would be concerned. The conversion from IBM to >> VMS here (which used all packaged applications as we are a Banner shop) >> took more than a year and had ripples for long after that. >> >> A conversion from one major system to another is not something that >> should be taken lightly. The old and new systems whould be run in >> paralel for some length of time to ensure the conversion is going to >> give consistant results. Once it becomes obvious that the original >> system is a dead end what possible reason can there be for putting >> off the inevitable? Start now and spend some extra time on the design >> phase. Maybe the right answer is a total re-write in a differnt language. >> Especially if the language chosen in the first place (in this case "C") >> might not have been the best choice even then. >> > > I really don't think you've directly addressed the question. Boy, sure seems like it to me. I take it you're one of those people who waits till the last minute for everything. I am definitely not. > > Lack of available replacement equipment. Yeah, at that time, I guess > you'd have to move. But that hasn't happened, and today's equipment is > not going to just stop working. So what, does your equipment make announcements to you that it is going to fail next November 12th? Unless you have a spare of everything you can not plan on being able to buy anything that is EOL. (Hint: tell me where I can buy a Kingston KNE100TX PCI Ethernet card? And this is a real business, Ebay is not an option.) Once the vendor says, "This product is dead" it is time to start the process of moving on. Unless yopur business doesn't really rely on those computing resources. > I'd have to feel that something would > always be available long enough to perform any conversion. If the conversion is going to take a year or more? Look at my example above. And they had full-time teams provided by Univac to do the bulk of the conversion. Testing and verification alone took more than 6 months. These systems were critical to the operation of the business. We couldn't just throw something together and patch it as mistakes were found. How important is your computing infrastructure to your business? > > Bugs? They don't just appear. If they exist, and you don't have > problems now, you won't start to have problems, just because something > is no longer supported. You must be assuming that the programs are static. Every time you make a change you risk coming upon a bug that didn't botrher you before but is a show-stopper now. Just a re-compile with a newer version compiler can do that. > > It seems your major argument is why put off until tomorrow what can be > done today. My argument is why not put it off until you're sure it's > necessary, Unless you are happy going to Itanium, even given its very dubious future, it is necessary now. Unless you think you can make the conversion over- night. If your systems make heavy use of things like RMS and other VMS specific libraries, how long do you think conversion, testing and verification are likey to take, assuming non-trivial program? > and then, there will be no more effort than you'd put into it > today. No one is saying the effort increases with time, but the time needed is pretty much fixed. If it is going to take a year, that's either a year from now, when you still have working systems on which your company can continue to operate or a year from some arbitrary date in the future when your systems may or may not be still in good health. How much does your business rely on your computer infrastructure? Given a catastrophic failure, how long can your business survive without it? And I haven't even addressed the need to have both systems in operation at the same time in order to move old data to the new system, possibly including large quantites of archived data. How far back do you keep backups? How long will it take to convert all of that to a media that the new system can deal with? Trust me, I have been through a number of major system conversions in my career and it is nothing to be taken lightly. (Contrary to popular belief, I wasn't always an academic!!) > > So let's explore these two points of view. So far, we haven't left one > human alive forever. Everyone is going to die. It's only a question of > when. So, from your perspective, why put off until later what you can > do today? Me, I think I'll squeeze every bit I can out of what I have > today, putting off the inevitable as long as possible. I am advocating what you are int his last paragraph. Only you are looking at the machine while I am looking at the Information System and the business that relies on it. Using your human analogy, why bother having a heart transplant as long as the diseased one is still ticking? Why not wait til it stops? Oh wait, then it's too late! And that is why people opt to replace them while the old one is still working. And usually try to get on the list for new one at the earliest possible time once it is determined that the change is going to be necessary. If your IS is the heart of your business, why treat it any different? Just out of curiosity, How long can your business continue to operate if your VMS system went down tomorrow and you could not replace the part that failed? 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: 13 Feb 2007 13:59:25 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: Migrating C application from VMS to LINUX Message-ID: <53duhtF1rnhpnU1@mid.individual.net> In article <2b80$45d1c077$cef8887a$18417@teksavvy.com>, JF Mezei writes: > Bill Gunshannon wrote: >> Just out of curiosity, How long can your business continue to >> operate if your VMS system went down tomorrow and you could not >> replace the part that failed? > > Spare parts for VAX and Alphas are plentiful if you know where to look for > them. For hobbyists, maybe. But many businesses can not/will not deal with anyone but primaries. No Ebay, no 9to5computer, And, if the part is no longer being manufactured by the primary, you can not plan on it being available when you need it. Not from any source!! As I said, unless you have replacement parts for everything in your system on site, or you can rely on HP to have available parts and be willing/able to deliver them in a timely manner, you do not have a system you can rely on. How much does your business rely in your IS? How long can you survive if it went down today? Hobbyists need not reply!! 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, 13 Feb 2007 09:12:53 -0500 From: "Main, Kerry" Subject: RE: Migrating C application from VMS to LINUX Message-ID: > -----Original Message----- > From: bill@triangle.cs.uofs.edu=20 > [mailto:bill@triangle.cs.uofs.edu] On Behalf Of Bill Gunshannon > Sent: February 13, 2007 8:28 AM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Migrating C application from VMS to LINUX >=20 [snip ...] >=20 > Just out of curiosity, How long can your business continue to > operate if your VMS system went down tomorrow and you could not > replace the part that failed? >=20 > bill > =20 Bill - you are confusing end of new product sales with end of product suupport.=20 HP commitments for HW support extend to *AT LEAST* 5 years after the last official Alpha Sales date. If the business requires it, simply get a HW support contract. Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-592-4660 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20 OpenVMS - the secure, multi-site OS that just works. ------------------------------ Date: 13 Feb 2007 15:10:28 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: Migrating C application from VMS to LINUX Message-ID: <53e2n4F1qu77dU1@mid.individual.net> In article , "Main, Kerry" writes: > >> -----Original Message----- >> Sent: February 13, 2007 8:28 AM >> To: Info-VAX@Mvb.Saic.Com >> Subject: Re: Migrating C application from VMS to LINUX >>=20 > > [snip ...] > >>=20 >> Just out of curiosity, How long can your business continue to >> operate if your VMS system went down tomorrow and you could not >> replace the part that failed? > > Bill - you are confusing end of new product sales with end of product > suupport.=20 > > HP commitments for HW support extend to *AT LEAST* 5 years after the > last official Alpha Sales date. If the business requires it, simply get > a HW support contract. And this is somehow more affordable than just biting the bullet and starting your porting effort now? Based on HP's track record, I for one would not trust them with the survival of my business. Now, I suppose if you are the DOD or the NYSE you can, but I hardly expect that extends to someone like us. 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, 13 Feb 2007 22:03:06 +0800 From: Paul Repacholi Subject: Re: Migrating C application from VMS to LINUX Message-ID: <8764a6kvdx.fsf@k9.prep.synonet.com> "Main, Kerry" writes: > OK, so you tried to port an application written in 2004 to an OS > released in 1999? > Whats wrong with this picture? Five years perhaps? What is wrong is that there are now many people who even THINK it might be an issue. So what Kerry is wrong with that picture? Wrong DLLs? .so files not in the same place? God help us that we should expect the OS to `just work'. ------------------------------ Date: 9 Feb 2007 02:32:27 -0800 From: "klaus_austria" Subject: Migrating C application from VMS to LINUX Message-ID: <1171017147.288767.101230@a34g2000cwb.googlegroups.com> Hi! I plan to migrate from VMS to Linux. I have lots of c applications with interprocess communication like global logs and sections. Do exist any identical tools, to migrate to Linux in an easy way? I have some SNA connections using the sna protocoll. Is there a chance in Unix too? What else could cause problems? Please reply. Thanks, Klaus ------------------------------ Date: Tue, 13 Feb 2007 11:06:00 -0500 From: Stephen Hoffman Subject: Re: Migrating C application from VMS to LINUX Message-ID: Bill Gunshannon wrote: > And this is somehow more affordable than just biting the bullet and > starting your porting effort now? It's certainly reasonable to incrementally move toward more portable code, regardless of the platform and the porting plans. This means jacketing calls that are not available, and moving non-portable code and APIs into defined modules, and moving toward more portable high-level implementation platforms, and toward calls into common C add-on libraries. The Java platform can get the press and the marketeering, but there are other excellent platform choices available. -- For the local C code porting and beyond the non-portable system service calls and other such obvious limitations, a more subtle portability effort tends to be around dependencies on RMS. There's MySQL and PostgreSQL and commercial database packages, but sliding a database in to replace RMS can be problematic. But jacketing these RMS calls and OpenVMS extensions to existing C calls and the designs that tend to follow capabilities in the existing code is certainly a prelude to a port. -- As for portability of C code itself, when there are common C calls that are missing from the OpenVMS C RTL (and there are a few of these), I'd strongly encourage you to not implement the function under the standard name, but to have your local copy under a private name. Reference your function with /FIRST_INCLUDE or local definitions, where the real code uses the real name, and your local code uses a local name. This avoids the inevitable namespace collisions as functions are added. More than a few folks have erroneously used the reserved routine name for their own local function that implements a missing standard routine, and that usage can unnecessarily derail cross-platform work and porting. -- The "fun" with moving to Linux or such is around the volatility of the APIs and the packages. The churn rates in some areas here can be quite impressive. I've been chasing some platform-level (PHP, MySQL, Apache CMS; an xAMP-based CMS) code, and keeping up can be something you just have to plan for. It's not something most long-time OpenVMS users might be familiar with -- Linux and Mac OS X and particularly the constituent parts of same can and do move forward rather more quickly. And not necessarily with the desired degree of compatibly. "TANSTAAFL". And if you are considering porting, ask yourself why, and ask yourself how much you're going to spend in the effort. More than a few folks have underestimated the costs of porting and testing and of chasing the standards and tools and platforms, or overestimated the benefits of the port. Or both. Once your code is largely portable, you can more easily migrate for lower cost or higher performance or such -- but even then, such a migration is not free. You will be messing with the APIs and the UI and the file system and other such. -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ Date: 13 Feb 2007 17:11:38 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: Migrating C application from VMS to LINUX Message-ID: <53e9q9F1sff41U1@mid.individual.net> In article , Stephen Hoffman writes: > Bill Gunshannon wrote: > >> And this is somehow more affordable than just biting the bullet and >> starting your porting effort now? > > It's certainly reasonable to incrementally move toward more portable > code, regardless of the platform and the porting plans. This means > jacketing calls that are not available, and moving non-portable code and > APIs into defined modules, and moving toward more portable high-level > implementation platforms, and toward calls into common C add-on > libraries. The Java platform can get the press and the marketeering, > but there are other excellent platform choices available. I agree, and said as much early in this discussion. But getting back to Dave's problem with my suggestion, what is better, start working on the change sooner rather than later and taking the extra time to properly engineer the new system or wait til the last minute because old Alpha boxes are still available ont he used market? > > -- > > For the local C code porting and beyond the non-portable system service > calls and other such obvious limitations, a more subtle portability > effort tends to be around dependencies on RMS. There's MySQL and > PostgreSQL and commercial database packages, Well, I would scratch MySQL from that list. Thankfully, at the suggestion of the professor who teaches databases here (and has seriously looked at most of them) we are no longer offering MySQL for studxent projects. > but sliding a database in > to replace RMS can be problematic. But jacketing these RMS calls and > OpenVMS extensions to existing C calls and the designs that tend to > follow capabilities in the existing code is certainly a prelude to a port. Well, RMS seems particularly problematic to me but then, no moreso than using any proprietary interfaces. People mentioned Unix Calls but with the exception of things like "fork()" that may not be possible under the OS most C implentations I have run into include a library that does most of the Unix specific stuff. > > -- > > As for portability of C code itself, when there are common C calls that > are missing from the OpenVMS C RTL (and there are a few of these), I'd > strongly encourage you to not implement the function under the standard > name, but to have your local copy under a private name. Reference your > function with /FIRST_INCLUDE or local definitions, where the real code > uses the real name, and your local code uses a local name. This avoids > the inevitable namespace collisions as functions are added. More than a > few folks have erroneously used the reserved routine name for their own > local function that implements a missing standard routine, and that > usage can unnecessarily derail cross-platform work and porting. But what is missing? Mostly things that don't have functional equivalence under VMS like fork(). My experience has been that VMS did a real good job of implementing C. The big question then is, "Is C the right language for the job?" I would bet that for most business programming, the answer is "No". (And y'all thought I was a "C" bigot. :-) If you are going to have ti undertake a major re-write anyway, now would be a good time to start at the beginning with your engineering and look at your choice of language. And I am not advocating moving to Java, either. > > -- > > The "fun" with moving to Linux or such is around the volatility of the > APIs and the packages. The churn rates in some areas here can be quite > impressive. I've been chasing some platform-level (PHP, MySQL, Apache > CMS; an xAMP-based CMS) code, and keeping up can be something you just > have to plan for. It's not something most long-time OpenVMS users might > be familiar with -- Linux and Mac OS X and particularly the constituent > parts of same can and do move forward rather more quickly. And not > necessarily with the desired degree of compatibly. "TANSTAAFL". WHich is why I have always suggested that any programming project start with seriously looking at the language to be used. What's in vogue is not a good reason for the choice you make. WHile I am sure many people will scoff, COBOL is still a very good business language. And modern COBOL's even moreso. With the ability to interface to DB's and even the Web as well as still having real good support for character cell applications. Or Pascal, or Ada. Look at the application and pick a language that best fits the task at hand. Even if it's PL/I. :-) > > And if you are considering porting, ask yourself why, and ask yourself > how much you're going to spend in the effort. More than a few folks > have underestimated the costs of porting and testing and of chasing the > standards and tools and platforms, or overestimated the benefits of the > port. Or both. But sometimes the port is forced by factors outside the company's control. In that case, make the most of it. Think back to all the things that went badly the first time around and look at how you can try to keep this from happening again. And, consider now that this may not be the last time, etiher. > Once your code is largely portable, you can more easily > migrate for lower cost or higher performance or such -- but even then, > such a migration is not free. You will be messing with the APIs and the > UI and the file system and other such. Excelent advice, but then, it is this kind of expertise that we had come to expect, so no surpirse. Hope your new venture is going well, Hoff. 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: 13 Feb 2007 06:40:22 -0800 From: "AEF" Subject: Re: SPANNING BACKUP TAPES Message-ID: <1171377622.800750.63530@s48g2000cws.googlegroups.com> On Feb 13, 7:07 am, Paul Sture wrote: > In article <1171058360.256570.308...@h3g2000cwc.googlegroups.com>, > > > > > > "AEF" wrote: > > On Feb 9, 6:01 am, Paul Sture wrote: > > > In article , > > > > "R.A.Omond" wrote: > > > > > You don't need TAPESYS to guard against the inadvertant overwriting of > > > > backup tapes. Sometimes I get the feeling that I'm the only one on > > > > the planet who makes use of the very useful feature of Backup's > > > > /Tape_Expiration qualifier. > > > > I forgot to add to my previous post that I've had good results with > > > /EXACT_ORDER. > > > > For those not familiar with it: > > > > BACKUP > > > > /EXACT_ORDER > > > > Depending on the other qualifiers you specify on the command > > > line, the /EXACT_ORDER qualifier allows you to perform the > > > following actions: > > > > o Specify the exact order of tape volume labels that you want to > > > use in a BACKUP operation. > > > > o Preserve the existing volume label on a tape. > > > > o Prevent previous volumes of a multivolume save operation from > > > being overwritten. > > > > It does, in my experience, work as advertised wrt the last point. > > > > -- > > > Paul Sture > > > What about /LABEL? This prevents you from overwriting tapes whose > > label doesn't match the /LABEL argument according to some slightly > > complex rules, but you need /EXACT_ORDER to additionally prevent > > BACKUP from overwriting tapes from the same save set. > > /LABEL is inferred in the description above with the "Depending on other > qualifiers..." sentence. Well, it seemed to me that people were suggesting all sorts of "exotic" BACKUP qualifiers to avoid overwriting the second tape when ISTR that this normally is not a problem unless the label on the wrong tape matches or if you specified /IGNORE=LABEL. So I was just mentioning the /LABEL bit which is the most basic and probably oldest way to safeguard against overwriting the wrong tape. > > > I just tried this and it worked fine. But I did have another problem. > > I did not specify /ASSIST or /NOASSIST, and I was running the BACKUP > > command interactively. But when it needed a second tape, it asked me > > at the terminal to mount it and type YES when ready. Also, running > > SHOW DEVICE MK on another session showed that the tape drive was not > > allocated! > > If you really want to keep the tape allocated for the duration of the > backup process, then do it manually. > > The behaviour you describe is correct. It allows you or an operator to > mount a tape and check its identity or initialize a fresh tape with the > correct label, before the backup continues. > > Imagine the scenario where you only have one tape drive; if BACKUP kept > the tape allocated here, you'd have to abort the backup to get at the > drive. ISTR that the drive normally stays allocated across tape changes. I thought that was to prevent another user from interrupting someone else's backup or from another user putting in *his* tape and having it overwritten by the first user. You prefer that to having to abort a backup to check a tape because you have only one drive? I'll have to check again the next time I make a multi-tape backup if the drive stays allocated. > > > > > Wasn't the system supposed to send the request for a second tape to an > > operator terminal and keep the drive allocated? > > If you are working standalone on the console, that behaviour would > completely snooker you, as there isn't a separate terminal to issue the > operator reply from. Going back to circa V5, it did do that, and it's > why I got into the habit of using SPAWN for backups done at the console. There were other terminal sessions enabled for OPCOM messages and such, so I don't see why it did this. I mean, what's the whole point of the /NOASSIST qualifier anyway? > > > OpenVMS V6.2 with all mandatory ECO kits applied. But I admittedly > > have not applied VAXBACK03_062, but I didn't see anything in its > > release notes that would apply to my situation. > > > I guess the problem has something to do with the > > > %MOUNT-F-VOLINV, volume is not software enabled > > > error. I don't know why it was trying to mount the second tape before > > I put it in. Maybe it's just another screwy thing with the 4mm DAT > > DDS-2 drives (it's a TLZ07-DA)? > > That error typically comes from trying to mount a DAT or DLT tape when a > tape is in the drive, after an UNLOAD/DISMOUNT. Well, I started the backup interactively from a terminal session and came back to the session later to find all the messages I included in my original post. And the tape was ejected. > > -- > Paul Sture- Hide quoted text - > > - Show quoted text - Thanks for your help. AEF ------------------------------ Date: Tue, 13 Feb 2007 08:13:22 +0100 From: Michael Unger Subject: Re: Understanding DSL10L cabinet/hardware Message-ID: <53dkgqF1rmubbU1@mid.individual.net> On 2007-02-13 02:05, "JF Mezei" wrote: > re: Resistor to provide base load. > > Wouldn't the motherboard provide a base load ? With the CPU installed and running? Probably yes. But you can still disconnect the power plug from (just) the motherboard ... > And in the case of the DS10L, if you have 2 disk drives, do you still need > that base load ? Is that base load there in case you have a diskless system? AFAIK disk drives don't spin up immediately when power is applied. So there is a (short) period of time where they don't draw much (read "enough") current. But a simple resistor isn't the most elegant (but a rather reliable) solution of course ... Michael -- Real names enhance the probability of getting real answers. My e-mail account at DECUS Munich is no longer valid. ------------------------------ Date: Tue, 13 Feb 2007 12:14:55 -0600 From: Dan Foster Subject: Re: X Windows App Message-ID: In article <1171389358.513434.209100@v33g2000cwv.googlegroups.com>, DJ wrote: > > Since I am new to OpenVMS I would like to make sure I am not missing > something in my OpenVMS environment that would be causing me not to > run X Windows applications remotely. I have been reading a non-VMS > specific Xlib threads but have not found a solution. > > I have Cygwin running on my workstation connecting to one of my Linux > servers. From my linux server I connect to a client's Linux server > via a command similar to: > > ssh -X me@them If your OpenVMS system is running a sufficiently recent TCP/IP stack, you may be able to do the same: ssh -X into the VMS system. Quickest way to check would probably be to login to the VMS system and see if it has a 'ssh' command. If it does, you may be able to just ssh -X into it. If not, probably would need the traditional way of doing X. I think the FAQ has steps if you want to do a search for ... say, DISPLAY, at http://www.hoffmanlabs.com. It's there somewhere. (I'd be happy to look up exact details for you when I'm feeling better.) -Dan ------------------------------ Date: 13 Feb 2007 10:45:19 -0800 From: "DJ" Subject: Re: X Windows App Message-ID: <1171392316.753683.230040@h3g2000cwc.googlegroups.com> On Feb 13, 1:14 pm, Dan Foster wrote: > In article <1171389358.513434.209...@v33g2000cwv.googlegroups.com>, DJ wrote: > > > Since I am new to OpenVMS I would like to make sure I am not missing > > something in my OpenVMS environment that would be causing me not to > > run X Windows applications remotely. I have been reading a non-VMS > > specific Xlib threads but have not found a solution. > > > I have Cygwin running on my workstation connecting to one of my Linux > > servers. From my linux server I connect to a client's Linux server > > via a command similar to: > > > ssh -X me@them > > If your OpenVMS system is running a sufficiently recent TCP/IP stack, > you may be able to do the same: ssh -X into the VMS system. > > Quickest way to check would probably be to login to the VMS system and > see if it has a 'ssh' command. If it does, you may be able to just ssh > -X into it. If not, probably would need the traditional way of doing X. > > I think the FAQ has steps if you want to do a search for ... say, > DISPLAY, athttp://www.hoffmanlabs.com. It's there somewhere. > > (I'd be happy to look up exact details for you when I'm feeling better.) > > -Dan Thanks! I shall check out the site you list shortly ... ------------------------------ End of INFO-VAX 2007.088 ************************