INFO-VAX Thu, 22 Mar 2007 Volume 2007 : Issue 161 Contents: Re: AMD's well may be running dry Re: AMD's well may be running dry Re: Cool new features in OpenVMS 8.3 Re: end of DLT? Belluzzo strikes again Re: end of DLT? Belluzzo strikes again For Sale - Infotower w/ 7 CD drives Re: Not on latest Roadmap: OpenVMS VAX Version 8.x "under investigation" Re: Not on latest Roadmap: OpenVMS VAX Version 8.x "under investigation" Re: Not on latest Roadmap: OpenVMS VAX Version 8.x "under investigation" Re: Not on latest Roadmap: OpenVMS VAX Version 8.x "under investigation" Re: Not on latest Roadmap: OpenVMS VAX Version 8.x "under investigation" Re: Not on latest Roadmap: OpenVMS VAX Version 8.x "under investigation" Re: Problems zipping RBF file Re: Problems zipping RBF file Re: Problems zipping RBF file Re: Problems zipping RBF file Re: Problems zipping RBF file Re: Problems zipping RBF file Re: Problems zipping RBF file Question about foreign/compound characters. Re: Question about foreign/compound characters. Re: Question about foreign/compound characters. Re: Question about foreign/compound characters. Re: Question about foreign/compound characters. Re: Question about foreign/compound characters. Re: RMS indexed file structure questions SNA SDLC connection problems Re: vme data transactios Re: Willing to bet this is Windows at its best Re: Willing to bet this is Windows at its best Re: Willing to bet this is Windows at its best ---------------------------------------------------------------------- Date: Thu, 22 Mar 2007 04:35:24 +0800 From: Paul Repacholi Subject: Re: AMD's well may be running dry Message-ID: <878xdqgws3.fsf@k9.prep.synonet.com> JF Mezei writes: > Dave Weatherall wrote: >> are 'natural'. The problem is that the human action increases the >> imbalance and increases the likelihood of catastrophe if we continue >> as we are. No action because its 'natural' won't help avoid the >> effects. > And the last time the global temperature was warm enough that ice > shelves had melted, there were high concentrations of people and > buildings on the coasts. Now that there are, a rise in sea levels will > not only zap a large part fo florida, but also affect New York, > Boston, Amsterdam, Venise, Los Angeles, Sydney, Hong Kong and there > are so many other cities on shores of the ocean.... Go to http://flood.firetree.net/ and have fun. Keep in mind that you only need a few meters above high high tide level for most of the developed world ports to be out of action as the loaders/cranes etc won't have the lift reserve to work the higher vesels. > Also flooded will be a huge chunk of Bengladesh, some whole islands in > the pacific and indian oceans (incuding the Maldives). And a certain lump of former swamp-land. ------------------------------ Date: Thu, 22 Mar 2007 04:28:05 +0800 From: Paul Repacholi Subject: Re: AMD's well may be running dry Message-ID: <87d532gx4a.fsf@k9.prep.synonet.com> koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > Nobody knows. It's like asking how long GM expects to continue > support for the last Chevy. Niether Itanium nor Chevrolet are > making any end of life plans. The Edsel would be a better comparision. ------------------------------ Date: 21 Mar 2007 21:44:37 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: Cool new features in OpenVMS 8.3 Message-ID: In article , - writes: > 'Twould be nice if VMS allowed one to switch ciphers. Wouldn't be AES > (i.e. interoperable & filled w/ yummy NSA goodness), but it /might/ be > more "secure". One release of VMS Encryption allowed substitution of algorithms. That was changed when the US government decided that made it less exportable. ------------------------------ Date: Wed, 21 Mar 2007 17:36:34 -0400 From: JF Mezei Subject: Re: end of DLT? Belluzzo strikes again Message-ID: <68998$4601a566$cef8887a$16117@TEKSAVVY.COM> VAXman- @SendSpamHere.ORG wrote: > I have not yet played with the new /ENCRYPT feature on V8.3 BACKUP but I'm > still likely to avoid it and lock my DLTs in the safety deposit box in the > bank's vault for security. ;) In many instances, previous commercial data was "lost" in transit between the data centre and the secure bank vaults... ------------------------------ Date: Thu, 22 Mar 2007 00:28:53 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: end of DLT? Belluzzo strikes again Message-ID: <00A64F77.9FA3013C@SendSpamHere.ORG> In article <68998$4601a566$cef8887a$16117@TEKSAVVY.COM>, JF Mezei writes: > > >VAXman- @SendSpamHere.ORG wrote: >> I have not yet played with the new /ENCRYPT feature on V8.3 BACKUP but I'm >> still likely to avoid it and lock my DLTs in the safety deposit box in the >> bank's vault for security. ;) > >In many instances, previous commercial data was "lost" in transit between the >data centre and the secure bank vaults... ...and the question begs to be asked: Where will the keys for these encrypted tapes be stored? On some *other* tapes bound for secure storage only to risk being lost as well? Then the whole of all encrypted tapes is useless. While the prying eyes can't read the tapes neither can the entities who wrote them. Or, will these keys be stored in some Micro$oft keys management solution only to be lost to some virus which attacks this "solution". Entrusting the transit of important backup tape to "two potheads and a pickup truck", encrypted or otherwise, is unwise. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" ------------------------------ Date: Wed, 21 Mar 2007 18:12:25 -0400 From: "Jilly" Subject: For Sale - Infotower w/ 7 CD drives Message-ID: <4601add6$0$30588$ec3e2dad@news.usenetmonster.com> I am selling an Infotower w/ 7 CD drives in it plus a hub. See http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&rd=1&item=180097978588&ssPageName=STRK:MESE:IT&ih=008 for the item. Jilly ------------------------------ Date: Wed, 21 Mar 2007 17:34:45 -0400 From: JF Mezei Subject: Re: Not on latest Roadmap: OpenVMS VAX Version 8.x "under investigation" Message-ID: Galen wrote: > Should we read into the statement's deletion/omission that HP has > completed its assessment of customer demand and found it insufficient > to proceed with a VAX release? I don't think "customer demand" was a big factor per say. I think that they looked at their new reduced headcount and had to prioritise where resources are allocated. Right now, VMS is being tasked by HP to help prop up that IA64 thing. And once HP finally announces the end of IA64, resources will go to porting VMS to the 8086. What customers should demand however would be a 7.3-1 version that would bring the same DCL improvements and lexicals as current VMS 8.3, and fixing the MONITOR CLUSTER to work like the SPD says it should work. ------------------------------ Date: 21 Mar 2007 12:42:35 -0700 From: "Ian Miller" Subject: Re: Not on latest Roadmap: OpenVMS VAX Version 8.x "under investigation" Message-ID: <1174506155.103834.70240@y66g2000hsf.googlegroups.com> For the last few years at previous events (bootcamps, TUD) etc it was always stated there was no customer demand for another version of VMS for VAX. If anyone knows of demand for a new version then do let HP know, ------------------------------ Date: 21 Mar 2007 16:07:05 -0500 From: brooks@cuebid.zko.hp.nospam (Rob Brooks) Subject: Re: Not on latest Roadmap: OpenVMS VAX Version 8.x "under investigation" Message-ID: <9tpbN3lkdcbw@cuebid.zko.hp.com> "Ian Miller" writes: > For the last few years at previous events (bootcamps, TUD) etc it was > always stated there was no customer demand for another version of VMS > for VAX. > > If anyone knows of demand for a new version then do let HP know, If anyone plans to "let HP know", you'd be best served by making a coherent argument why you *need* it, as opposed to why you'd *like* to have it. Leave out the bleating and vituperative dogma; that won't help your case. -- Rob Brooks MSL -- Nashua brooks!cuebid.zko.hp.com ------------------------------ Date: Wed, 21 Mar 2007 17:40:13 -0400 From: JF Mezei Subject: Re: Not on latest Roadmap: OpenVMS VAX Version 8.x "under investigation" Message-ID: etmsreec@yahoo.co.uk wrote: > As such, > there was thought to be little point or economic sense in building/ > coding v8.x for VAX. Eventually, when incompatibilities between 7.3 and Alpha X.X become so great, you may find a lot of customers stuc at Alpha X.X and unable to upgrade because the interoperability with VAX would be lost. Another thing VAX needs is the AUTO_DAYLIGHT_SAVING time change in JOB_CONTROL/SYSGEN so that in a mixed cluster, the time change is seamless. Right now, one must handle alphas and vaxen differently because alphas support automated time change, vax doesn't. ------------------------------ Date: Wed, 21 Mar 2007 17:45:24 -0400 From: JF Mezei Subject: Re: Not on latest Roadmap: OpenVMS VAX Version 8.x "under investigation" Message-ID: Ian Miller wrote: > For the last few years at previous events (bootcamps, TUD) etc it was > always stated there was no customer demand for another version of VMS > for VAX. This could very well be just propaganda from HP which is self fulfilling. Also, remember that the vast majority of VAX customers have no contact with HP and just sign a contract renewall form once a year. Some do not even know that VAX was replaced with Alpha. ------------------------------ Date: Wed, 21 Mar 2007 17:48:49 -0400 From: JF Mezei Subject: Re: Not on latest Roadmap: OpenVMS VAX Version 8.x "under investigation" Message-ID: Rob Brooks wrote: > If anyone plans to "let HP know", you'd be best served by making > a coherent argument why you *need* it, as opposed to why you'd *like* > to have it. For microsoft: If you built it they will come. For VMS: don't let them tell you they desire it. This way you can justify not building it. Tell me again which OS has greater market share ? There is a HUGE untapped potential in reactivating all those dormant VAX accounts hat just blinding renew the contract every year for that one or two remaining apps while everything else is being developped on competitor's platforms. But if VMS is to run on industry standard machines in a couple of years, then best wait until this is announced before contacting these dormant customers to convince them to upgrade their VMS boxes to more modern hardware and sofware. ------------------------------ Date: Wed, 21 Mar 2007 11:09:25 -0700 From: - Subject: Re: Problems zipping RBF file Message-ID: DeanW wrote: > Oh, what a tangled web... > > On a DS20, VMS 7.2-1 / RDB 7.1-240 / ZIP 2.3 > > To be careful, we want to encapsulate those in a ZIP file, right? Sorry to be clueless, but what does this mean? Can you elaborate on "careful"? Perhaps there's another answer here... ------------------------------ Date: Wed, 21 Mar 2007 19:01:15 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: Problems zipping RBF file Message-ID: <%hfMh.36818$E02.14847@newsb.telia.net> DeanW wrote: > b) It *shouldn't* work- my input file is nearly twice the expected > capabilities of zip 2.x. More work needs to be done... From earlier posts it was not clear (IMO) if that limitation was on the input file *or* the zipped output file (or both!). Theoretical ("worst case") it could be that ZIP could *create* an ZIP file smaller then 2GB from an input file *larger* then 2GB, but UNZIP could not re-create the larger the 2GB output file later... Not a nice situation... :-) Regards, Jan-Erik. ------------------------------ Date: Wed, 21 Mar 2007 13:08:21 -0700 From: - Subject: Re: Problems zipping RBF file Message-ID: sol gongola wrote: > - wrote: >> DeanW wrote: >>> Oh, what a tangled web... >>> >>> On a DS20, VMS 7.2-1 / RDB 7.1-240 / ZIP 2.3 >>> >>> To be careful, we want to encapsulate those in a ZIP file, right? >> >> Sorry to be clueless, but what does this mean? >> >> Can you elaborate on "careful"? Perhaps there's another answer here... > > It looks like he wants to copy the file to a non vms system. Doing this > will often lose the vms attributes that are part of the file definition. > > The VMS version of ZIP preserves these attributes so that they can be > used in reconstituting the file when it needs to be restored. Well, there's always set file/attribute? It's easy enough to devise a round-trip test involving a system w/ a FAT or NTFS system. ------------------------------ Date: Wed, 21 Mar 2007 21:20:09 +0100 From: Paul Sture Subject: Re: Problems zipping RBF file Message-ID: In article <3f119ada0703211007s7d9c0fh371ce677c193d0c2@mail.gmail.com>, DeanW wrote: > (The issue with BACKUP causing performance issues- I noted that the > BACKUP account had DIOLM=4000, for unknown reasons, possibly done by a > former system manager so it'd get all the bandwidth it wanted. We > cranked that down to 100; waiting for reports from users to see if > that helps.) Likely derived from an old DSNlink article "Setting Up Parameters For the VMS BACKUP Operation (V5.2 or later)" My copy of it contains this: > 4. Set the process limit DIOLM to its maximum value of 32767 to > allow as many parallel disk I/Os as possible. The minimum > value for DIOLM should be the larger of (3*FILLM) or 4096.> -- Paul Sture ------------------------------ Date: Wed, 21 Mar 2007 15:33:03 -0700 From: DeanW Subject: Re: Problems zipping RBF file Message-ID: <3f119ada0703211533m7abd8825m4ef2b0617244410f@mail.gmail.com> On 3/21/07, - wrote: > DeanW wrote: > > Oh, what a tangled web... > > > > On a DS20, VMS 7.2-1 / RDB 7.1-240 / ZIP 2.3 > > > > To be careful, we want to encapsulate those in a ZIP file, right? > > Sorry to be clueless, but what does this mean? > > Can you elaborate on "careful"? Perhaps there's another answer here... They're being FTPd to a Windows box. If we don't encapsulate them, they come back with the attributes FUBAR. Rather than worry about remembering this and restoring the attributes should we ever have to rely on an RBF to restore the database from a catastrophic event, we encapsulate the file with VMS attributes (RBF or BACKUP saveset) in a ZIP file, which is much more attribute neutral. Yes, we could hassle with resetting them, but we'd rather not. Getting some degree compression out of it is a bonus not to be overlooked when you're shooting ~4GB of data across town. ------------------------------ Date: Wed, 21 Mar 2007 16:02:22 -0700 From: - Subject: Re: Problems zipping RBF file Message-ID: DeanW wrote: > [Update...] > > On 3/19/07, David J Dachtera wrote: >> DeanW wrote: >> Well, Steve Schweda *IS* the ZIP/UNZIP guru these days! >> >> That said, yes - "stored 0%" means the file *WAS* stored in the >> archive, but was >> not compressed. > > Er, not exactly. The resulting ZIP file is 1 block, and shows 0 bytes > stored at 0% compression. If we ZIP the BCK, it reports "62% > deflated"... but comparing file sizes suggests a compression ratio of > 40:1. > > And the input file (RBF) is ~7.8M blocks- yeah, ~3.9GB: > -------------------->8 cut here 8<-------------------- > LT$2007-03-21.RBF;1 File ID: (234520,10,0) > Size: 7831908/7831936 Owner: [CONSULT,SYSTEM] > Created: 21-MAR-2007 01:01:25.62 > Revised: 21-MAR-2007 02:50:56.80 (2) > Expires: > Backup: > Effective: > Recording: > File organization: Sequential > Shelved state: Online > Caching attribute: Writethrough > File attributes: Allocation: 7831936, Extend: 2048, Global buffer > count: 0, No version limit, Backups disabled > Record format: Fixed length 32256 byte records > Record attributes: None > RMS attributes: None > Journaling enabled: None > File protection: System:RWED, Owner:RWED, Group:RE, World: > Access Cntrl List: None > Client attributes: None > > Total of 1 file, 7831908/7831936 blocks. > -------------------->8 cut here 8<-------------------- > > So, theoretically, this shouldn't work *at all*. Zip 2.32 actually > does seem to work with the RBF itself, and I'm told they've > successfully extracted the RBF and built a database from it. Scary. make sure your dba does an rmu/verify/full/all ------------------------------ Date: Wed, 21 Mar 2007 17:42:59 -0500 (CDT) From: sms@antinode.org (Steven M. Schweda) Subject: Re: Problems zipping RBF file Message-ID: <07032117425895_2020028F@antinode.org> From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= > From earlier posts it was not clear (IMO) if that > limitation was on the input file *or* the zipped > output file (or both!). Theoretical ("worst case") > it could be that ZIP could *create* an ZIP file > smaller then 2GB from an input file *larger* then > 2GB, but UNZIP could not re-create the larger the > 2GB output file later... Not a nice situation... :-) Zip archives include file size data, and the original Zip archive format allows 32 bits for a file size, so it's not possible to store a large file _properly_ in a Zip archive without using the newer "ZIP64" archive format, support for which arrives with Zip 3.x. http://www.pkware.com/documents/casestudies/APPNOTE.TXT Of course, "improper" and "completely unsuccessful" are not the same, and you could get lucky. UnZip 5.x expects to be able to dance around in an archive using 32-bit seek() and tell() functions, based, in part, on 32-bit size values stored in the archive. (Guess where this leads.) I don't think that anyone has documented all the possible failure modes for different compressed and uncompressed sizes in the 2GB-to-4GB and bigger-than-4GB ranges for different [Un}Zip versions on different operating systems. (Nor is anyone likely to, I'd guess. And the OS does matter. On at least some Linux systems, for example, large files are essentially invisible -- open() can fail with ENOENT "No such file or directory".) Things could easily be worse if an archive contains more than one file (which may cause more dancing). In general, I would expect more problems than just defective display of compression ratios. "BETA" or not, I'd expect Zip 3.x and UnZip 6.x to have higher success rates on large files (of either type) than anything earlier. From: - > Well, there's always set file/attribute? It's easy enough to devise a > round-trip test involving a system w/ a FAT or NTFS system. Files may have attributes other than record format which a user may wish to preserve. Disk space is finite. Everything's complicated. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Wed, 21 Mar 2007 16:43:20 -0500 From: norm.raphael@metso.com Subject: Question about foreign/compound characters. Message-ID: I have a file from outside created with (for example) the foreign compound character +<'>, an oh with an acute accent over it. The local application hates this. This character comes into VMS as a 2-byte pair x and messes up the fixed-field definitions in the record after it (As the field is filled, it pushes all data after it into misalignment by one byte). Is there a way to get this and others (like <~>) back to their vanilla english spelling equivalents so the processing is not messed up? ------------------------------ Date: Wed, 21 Mar 2007 18:01:26 -0400 From: JF Mezei Subject: Re: Question about foreign/compound characters. Message-ID: norm.raphael@metso.com wrote: > Is there a way to get this and others (like <~>) back to their > vanilla english spelling equivalents so the processing is not > messed up? You need to translate it yourself. Assuming ISO-8851-1: The first table uppercases characters, retainining their accented charact= eristics. The second table maintains casing, but converts to the nearest non-accent= ed=20 character (there are a few that don't map properly). extern char char88591_upcase_simple[] =3D { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f, ' ', '!', '"', '#', '$', '%', '&', '\'', '(', ')', '*', '+', ',', '-', '.', '/', '0', '1', '2', '3', '4', '5', '6', '7', '8', '9', ':', ';', '<', '=3D', '>', '?', '@', 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', '[', '\\', ']', '^', '_', '`', 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', '{', '|', '}', '~', 0x7f, 0x80, 0x81, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87, 0x88, 0x89, 0x8a, 0x8b, 0x8c, 0x8d, 0x8e, 0x8f, 0x90, 0x91, 0x92, 0x93, 0x94, 0x95, 0x96, 0x97, 0x98, 0x99, 0x9a, 0x9b, 0x9c, 0x9d, 0x9e, 0x9f, 0xa0, '=A1', '=A2', '=A3', '=A4', '=A5', '=A6', '=A7', '=A8', '=A9', '=AA', '=AB', '=AC', '=AD', '=AE', '=AF', '=B0', '=B1', '=B2', '=B3', '=B4', '=B5', '=B6', '=B7', '=B8', '=B9', '=BA', '=BB', '=BC', '=BD', '=BE', '=BF', '=C0', '=C1', '=C2', '=C3', '=C4', '=C5', '=C6', '=C7', '=C8', '=C9', '=CA', '=CB', '=CC', '=CD', '=CE', '=CF', '=D0', '=D1', '=D2', '=D3', '=D4', '=D5', '=D6', '=D7', '=D8', '=D9', '=DA', '=DB', '=DC', '=DD', '=DE', '=DF', '=C0', '=C1', '=C2', '=C3', '=C4', '=C5', '=C6', '=C7', '=C8', '=C9', '=CA', '=CB', '=CC', '=CD', '=CE', '=CF', '=F0', '=D1', '=D2', '=D3', '=D4', '=D5', '=D6', 0xF7, '=D8', '=D9', '=DA', '=DB', '=DC', '=DD', 0xFE, 0xFF }; extern char char88591_noaccent [] =3D { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f, ' ', '!', '"', '#', '$', '%', '&', '\'', '(', ')', '*', '+', ',', '-', '.', '/', '0', '1', '2', '3', '4', '5', '6', '7', '8', '9', ':', ';', '<', '=3D', '>', '?', '@', 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', '[', '\\', ']', '^', '_', '`', 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z', '{', '|', '}', '~', 0x7f, 0x80, 0x81, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87, 0x88, 0x89, 0x8a, 0x8b, 0x8c, 0x8d, 0x8e, 0x8f, 0x90, 0x91, 0x92, 0x93, 0x94, 0x95, 0x96, 0x97, 0x98, 0x99, 0x9a, 0x9b, 0x9c, 0x9d, 0x9e, 0x9f, 0xa0, '=A1', '=A2', '=A3', '=A4', '=A5', '=A6', '=A7', '=A8', '=A9', '=AA', '=AB', '=AC', '=AD', '=AE', '=AF', '=B0', '=B1', '=B2', '=B3', '=B4', '=B5', '=B6', '=B7', '=B8', '=B9', '=BA', '=BB', '=BC', '=BD', '=BE', '=BF', 'A', 'A', 'A', 'A', 'A', 'A', '=C6', 'C', 'E', 'E', 'E', 'E', 'I', 'I', 'I', 'I', '=D0', 'N', 'O', 'O', 'O', 'O', 'O', '=D7', 'O', 'U', 'U', 'U', 'U', 'Y', '=DE', '=DF', 'a', 'a', 'a', 'a', 'a', 'a', '=E6', 'c', 'e', 'e', 'e', 'e', 'i', 'i', 'i', 'i', 'o', 'n', 'o', 'o', 'o', 'o', 'o', '=F7', 'o', 'u', 'u', 'u', 'u', 'y', '=FE', 'y' }; ------------------------------ Date: Wed, 21 Mar 2007 17:13:07 -0500 From: norm.raphael@metso.com Subject: Re: Question about foreign/compound characters. Message-ID: Thanks. 1) Would you supply the lower-case tables as well? 2) Is there a program around to do this or that can easily be canibalized to do it (It seems a bit beyond DCL)? (Maybe Larry has a TECO routine that does it in one command.) = JF Mezei = = = To 03/21/2007 06:01 PM Info-VAX@Mvb.Saic.Com= = cc = = Subject Re: Question about fo= reign/compound characters. = = = = = = norm.raphael@metso.com wrote: > Is there a way to get this and others (like <~>) back to their > vanilla english spelling equivalents so the processing is not > messed up? You need to translate it yourself. Assuming ISO-8851-1: The first table uppercases characters, retaining their accented characteristics. The second table maintains casing, but converts to the nearest non-acce= nted character (there are a few that don't map properly). extern char char88591_upcase_simple[] =3D { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f, ' ', '!', '"', '#', '$', '%', '&', '\'', '(', ')', '*', '+', ',', '-', '.', '/', '0', '1', '2', '3', '4', '5', '6', '7', '8', '9', ':', ';', '<', '=3D', '>', '?', '@', 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', '[', '\\', ']', '^', '_', '`', 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', '{', '|', '}', '~', 0x7f, 0x80, 0x81, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87, 0x88, 0x89, 0x8a, 0x8b, 0x8c, 0x8d, 0x8e, 0x8f, 0x90, 0x91, 0x92, 0x93, 0x94, 0x95, 0x96, 0x97, 0x98, 0x99, 0x9a, 0x9b, 0x9c, 0x9d, 0x9e, 0x9f, 0xa0, '=A1', '=A2', '=A3', '=A4', '=A5', '=A6', '=A7',= '=A8', '=A9', '=AA', '=AB', '=AC', '=AD', '=AE', '=AF'= , '=B0', '=B1', '=B2', '=B3', '=B4', '=B5', '=B6', '=B7'= , '=B8', '=B9', '=BA', '=BB', '=BC', '=BD', '=BE', '=BF'= , '=C0', '=C1', '=C2', '=C3', '=C4', '=C5', '=C6', '=C7'= , '=C8', '=C9', '=CA', '=CB', '=CC', '=CD', '=CE', '=CF'= , '=D0', '=D1', '=D2', '=D3', '=D4', '=D5', '=D6', '=D7'= , '=D8', '=D9', '=DA', '=DB', '=DC', '=DD', '=DE', '=DF'= , '=C0', '=C1', '=C2', '=C3', '=C4', '=C5', '=C6', '=C7'= , '=C8', '=C9', '=CA', '=CB', '=CC', '=CD', '=CE', '=CF'= , '=F0', '=D1', '=D2', '=D3', '=D4', '=D5', '=D6', 0xF7,= '=D8', '=D9', '=DA', '=DB', '=DC', '=DD', 0xFE, 0xFF }= ; extern char char88591_noaccent [] =3D { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f, ' ', '!', '"', '#', '$', '%', '&', '\'', '(', ')', '*', '+', ',', '-', '.', '/', '0', '1', '2', '3', '4', '5', '6', '7', '8', '9', ':', ';', '<', '=3D', '>', '?', '@', 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', '[', '\\', ']', '^', '_', '`', 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z', '{', '|', '}', '~', 0x7f, 0x80, 0x81, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87, 0x88, 0x89, 0x8a, 0x8b, 0x8c, 0x8d, 0x8e, 0x8f, 0x90, 0x91, 0x92, 0x93, 0x94, 0x95, 0x96, 0x97, 0x98, 0x99, 0x9a, 0x9b, 0x9c, 0x9d, 0x9e, 0x9f, 0xa0, '=A1', '=A2', '=A3', '=A4', '=A5', '=A6', '=A7',= '=A8', '=A9', '=AA', '=AB', '=AC', '=AD', '=AE', '=AF'= , '=B0', '=B1', '=B2', '=B3', '=B4', '=B5', '=B6', '=B7'= , '=B8', '=B9', '=BA', '=BB', '=BC', '=BD', '=BE', '=BF'= , 'A', 'A', 'A', 'A', 'A', 'A', '=C6', 'C', 'E', 'E', 'E', 'E', 'I', 'I', 'I', 'I', '=D0', 'N', 'O', 'O', 'O', 'O', 'O', '=D7', 'O', 'U', 'U', 'U', 'U', 'Y', '=DE', '=DF', 'a', 'a', 'a', 'a', 'a', 'a', '=E6', 'c', 'e', 'e', 'e', 'e', 'i', 'i', 'i', 'i', 'o', 'n', 'o', 'o', 'o', 'o', 'o', '=F7', 'o', 'u', 'u', 'u', 'u', 'y', '=FE', 'y' }; = ------------------------------ Date: Wed, 21 Mar 2007 19:30:23 -0500 From: "Craig A. Berry" Subject: Re: Question about foreign/compound characters. Message-ID: In article , norm.raphael@metso.com wrote: > 2) Is there a program around to do this or that can > easily be canibalized to do it (It seems a bit beyond > DCL)? For goodness sake don't do it yourself. Use iconv. Type HELP ICONV CONVERT. Depending on the encodings you are interested in, you may have to install the internationalization kit from the layered products CD. Or if you have any moderately recent version of Perl installed, you can use the piconv utility that comes with it. $ piconv :== @perl_root:[utils]piconv.com $ piconv piconv.com;1 [-f from_encoding] [-t to_encoding] [-s string] [files...] piconv.com;1 -l piconv.com;1 -r encoding_alias   -l,--list      lists all available encodings   -r,--resolve encoding_alias     resolve encoding to its (Encode) canonical name   -f,--from from_encoding       when omitted, the current locale will be used   -t,--to to_encoding         when omitted, the current locale will be used   -s,--string string              "string" will be the input instead of STDIN or files The following are mainly of interest to Encode hackers:   -D,--debug          show debug information   -C N | -c | -p      check the validity of the input   -S,--scheme scheme  use the scheme for conversion -- Posted via a free Usenet account from http://www.teranews.com ------------------------------ Date: Wed, 21 Mar 2007 20:37:13 -0400 From: JF Mezei Subject: Re: Question about foreign/compound characters. Message-ID: <9e9da$4601cfbe$cef8887a$2988@TEKSAVVY.COM> norm.raphael@metso.com wrote: > Thanks. > > 1) Would you supply the lower-case tables as well? The second table char88591_noaccent allows you to get the non accented character equivalent without changing case. in c, converting a string would be something such as: (using evil null terminated strings for simplicity here) ptr1 = mystring ; while(*ptr1) { *ptr1 = char88591_noaccent[*ptr1] ; ptr1 ++ ; } On my http://www.vaxination.ca/vms/ page, you can get the character set tables in JPEG, PS and PDF format and this give you a good idea of what value each character has. ------------------------------ Date: Wed, 21 Mar 2007 20:57:02 -0400 From: JF Mezei Subject: Re: Question about foreign/compound characters. Message-ID: <9b3f2$4601d463$cef8887a$4353@TEKSAVVY.COM> Craig A. Berry wrote: > In article=20 > , > norm.raphael@metso.com wrote: >=20 >> 2) Is there a program around to do this or that can >> easily be canibalized to do it (It seems a bit beyond >> DCL)? >=20 > For goodness sake don't do it yourself. Use iconv. Type HELP ICONV=20 > CONVERT.=20 I typed HELP ICONV CONVERT and it didn't convert the file :-) Was I suppo= sed to=20 press [return] after ? :-) ICONV is good to change the representation of the same character from one= =20 character set to another. But I do not believe that it has conversion tab= les=20 that actuall change characters (eg: replace and "=E9" with an "e".) I recall asking some years ago about the conversion tables and the answer= I got=20 here was that the source files were not public or some such answer. ------------------------------ Date: 21 Mar 2007 11:01:45 -0700 From: "Hein RMS van den Heuvel" Subject: Re: RMS indexed file structure questions Message-ID: <1174500105.184473.135990@y66g2000hsf.googlegroups.com> On Mar 19, 12:56 am, JF Mezei wrote: > The problem I have is to generate the list of bad blocks/buckets. This is a 50k > block file with a few thousand bad blocks. All the standard tools such as > ANA/RMS just choke at the first one. Our Dutch VMS friend Fekko Stubbe has a very elaborate RMS File tool: DIX See: http://www.oooovms.dyndns.org/dix/ Relatively recently he build in ANALYZE RMS support. Even more recently he build in a DECwindows interface to RMS indexed file internal structure. That might just be the ticket for problems like this! Best I can tell that part is not released yet, but may be avaiable on request already Hein. ------------------------------ Date: Wed, 21 Mar 2007 19:11:56 -0400 From: "Glen Thompson" Subject: SNA SDLC connection problems Message-ID: <1ZiMh.36714$_R.15385@newsfe23.lga> I have a Vaxstation 4000 90A running OpenVMS 7.2. The system has a DSW21 card to connect to our mainframe. Connection was working fine until we had an inadvertent shutdown. When the system was restarted, we could not connect to the mainframe. When the SNA software loads I get an error on the first step of SNANCP where it runs the SET LINE command. It gives a "Listener response - Hardware failure" error message. The DSW card was replaced with a spare but still gives the same error message. If I try to issue a LOOP LINE DSW-0-0 AT CONTROLLER test, I get a "no such line" error. Loopback tests from the modem back to the mainframe were fine. At the >>> boot prompt I issued a SHOW CONFIG and it shows COMM OK and the IDs the card properly. After boot I do a SHOW DEV and the ZTA0: dev shows Offline. There were no software or other hardware changes made to the system. Any other tests that I can perform? Suggestions as to what to try? I'm about to pull my hair out over this. TIA, glen ------------------------------ Date: Wed, 21 Mar 2007 19:44:43 -0500 From: David J Dachtera Subject: Re: vme data transactios Message-ID: <4601D17B.C3908F9B@spam.comcast.net> prahlad63@gmail.com wrote: > > I Have PPC 7410 board with TUNDRA asa vme data transactions > pls tell me how to transfer the data through the tundra to vme bus Try newsgroups related to: PPC TUndra VME This group is for OpenVMS, Alpha, VAX and also Itanium (Itanic) as relates to OpenVMS. -- 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/ ------------------------------ Date: 21 Mar 2007 18:23:00 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: Willing to bet this is Windows at its best Message-ID: <56dbg2F28nmbaU1@mid.individual.net> In article <1-ydnYJEv5Ml75zbnZ2dnUVZ_qrinZ2d@bresnan.com>, Maverick writes: > Bill Gunshannon wrote: > >> In article , >> Maverick writes: >> >>>Bob Willard wrote: >>> >>>>tomarsin2015@comcast.net wrote: >>>> >>>> >>>>>Oops! Techie wipes out $38 billion fund >>>>>Keystroke mistake deletes data for Alaska's oil-funded account >>>>> >>>>>JUNEAU, Alaska - Perhaps you know that sinking feeling when a single >>>>>keystroke accidentally destroys hours of work. Now imagine wiping out >>>>>a disk drive containing an account worth $38 billion. >>>>> >>>>>That's what happened to a computer technician reformatting a disk >>>>>drive at the Alaska Department of Revenue. While doing routine >>>>>maintenance work, the technician accidentally deleted applicant >>>>>information for an oil-funded account - one of Alaska residents' >>>>>biggest perks - and mistakenly reformatted the backup drive, as well. >>>>> >>>>>There was still hope, until the department discovered its third line >>>>>of defense, backup tapes, were unreadable >>>>> >>>>>"Nobody panicked, but we instantly went into planning for the worst- >>>>>case scenario," said Permanent Fund Dividend Division Director Amy >>>>>Skow. The computer foul-up last July would end up costing the >>>>>department more than $200,000. >>>>> >>>>>Over the next few days, as the department, the division and >>>>>consultants from Microsoft Corp. and Dell Inc. labored to retrieve the >>>>>data, it became obvious the worst-case scenario was at hand. >>>>> >>>>>Nine months worth of information concerning the yearly payout from the >>>>>Alaska Permanent Fund was gone: some 800,000 electronic images that >>>>>had been painstakingly scanned into the system months earlier, the >>>>>2006 paper applications that people had either mailed in or filed over >>>>>the counter, and supporting documentation such as birth certificates >>>>>and proof of residence. >>>>> >>>>>And the only backup was the paperwork itself - stored in more than 300 >>>>>cardboard boxes. >>>>> >>>>>"We had to bring that paper back to the scanning room, and send it >>>>>through again, and quality control it, and then you have to have a way >>>>>to link that paper to that person's file," Skow said. >>>>> >>>>>Half a dozen seasonal workers came back to assist the regular division >>>>>staff, and about 70 people working overtime and weekends re-entered >>>>>all the lost data by the end of August. >>>>> >>>>>"They were just ready, willing and able to chip in and, in fact, we >>>>>needed all of them to chip in to get all the paperwork rescanned in a >>>>>timely manner so that we could meet our obligations to the public," >>>>>Skow said. >>>>> >>>> >>>>Even the most dedicated M$ haters should not be able to blame WinDuhs for >>>>this goof. This is an obvious case of fumble-fingers at work; multiple >>>>f-f at that. >>> >>>But do you know any other operating system that would allow this? >> >> >> All of them. >> > > But by accident? Yes. > I can't as a user go into a root directory in UNIX and start deleting > files. It won't let you. It won't let you on Windows either. As a matter of fact, there are files on a Windows server that even the administrator can't delete, only the owner. > And I know you can't delete system files in vms as a regular user. If it is set up properly, that is true. And, if it is set up properly the exact same thing is true of Unix and Windows and every other OS I have ever worked on that actually had a distinction between regular users and administrators (I stress this becuase you have OSes like CPM and RT-11 where this is not the case and aa casual user can destroy the system with ease.) > Of course the article didn't give much information on how exactly he did > it either. It is amazing what power in the hands of the incompetent can accomplish. 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: Wed, 21 Mar 2007 15:28:13 -0400 From: "Richard B. gilbert" Subject: Re: Willing to bet this is Windows at its best Message-ID: <4601874D.7050009@comcast.net> Larry Kilgallen wrote: > In article , Maverick writes: > >>Bob Willard wrote: >> >>>tomarsin2015@comcast.net wrote: >> > >>>>That's what happened to a computer technician reformatting a disk >>>>drive at the Alaska Department of Revenue. While doing routine >>>>maintenance work, the technician accidentally deleted applicant >>>>information for an oil-funded account - one of Alaska residents' >>>>biggest perks - and mistakenly reformatted the backup drive, as well. >>> > >>>Even the most dedicated M$ haters should not be able to blame WinDuhs for >>>this goof. This is an obvious case of fumble-fingers at work; multiple >>>f-f at that. >> >>But do you know any other operating system that would allow this? > > > At the first site where all of my work was on VMS, on the first day > I was there, an operator did a DSC backup in the wrong direction, > wiping out the current data with the stale data. DSC?? Talk about ancient history!! Well I hope we have all learned something in the last twenty years. My operators never did a backup on their own! I wrote and scheduled the batch jobs that did backups; the operators just mounted the tapes. ------------------------------ Date: Wed, 21 Mar 2007 14:45:18 -0500 From: norm.raphael@metso.com Subject: Re: Willing to bet this is Windows at its best Message-ID: "Richard B. gilbert" wrote on 03/21/2007 03:28:13 PM: > Larry Kilgallen wrote: > > In article , > Maverick writes: > > > >>Bob Willard wrote: > >> > >>>tomarsin2015@comcast.net wrote: > >> > > > >>>>That's what happened to a computer technician reformatting a disk > >>>>drive at the Alaska Department of Revenue. While doing routine > >>>>maintenance work, the technician accidentally deleted applicant > >>>>information for an oil-funded account - one of Alaska residents' > >>>>biggest perks - and mistakenly reformatted the backup drive, as well. > >>> > > > >>>Even the most dedicated M$ haters should not be able to blame WinDuhs for > >>>this goof. This is an obvious case of fumble-fingers at work; multiple > >>>f-f at that. > >> > >>But do you know any other operating system that would allow this? > > > > > > At the first site where all of my work was on VMS, on the first day > > I was there, an operator did a DSC backup in the wrong direction, > > wiping out the current data with the stale data. > > DSC?? Talk about ancient history!! > > Well I hope we have all learned something in the last twenty years. My > operators never did a backup on their own! I wrote and scheduled the > batch jobs that did backups; the operators just mounted the tapes. > > Well, early on in my VAX career, an operator at midnight did $ SET DEFAULT MUMBLE and fat-fingered something so the default did not change from SYS$SYSTEM, where he was - in a fully priveleged account - and the DELETE *.*:* to empty (he intended) the MUMBLE directory. He did not wait for the error message.... $ show default SYS$SYSROOT:[SYSEXE] = SYS$SYSROOT:[SYSEXE] = SYS$COMMON:[SYSEXE] $ set default foo %RMS-F-DIR, error in directory name $ sho default SYS$SYSROOT:[SYSEXE] = SYS$SYSROOT:[SYSEXE] = SYS$COMMON:[SYSEXE] $ [D%%%%%%%%%] Yes, that deleted all the EXE's. Even then, it did not stop at DELETE.EXE, just marked it for delete (as it was open/running) and kept on going. We had to reboot from a backup diskpack (RM05's IIRC) and restore. Very embarrassing. ------------------------------ End of INFO-VAX 2007.161 ************************