INFO-VAX Sat, 29 Nov 2008 Volume 2008 : Issue 638 Contents: Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Re: Black and White Printing Re: Good example of C and MACRO Re: Good example of C and MACRO Re: Good example of C and MACRO Re: Good example of C and MACRO Re: Good example of C and MACRO Re: Good example of C and MACRO Re: Good example of C and MACRO Re: Good example of C and MACRO Re: Good example of C and MACRO Re: Good example of C and MACRO Re: Good example of C and MACRO Re: Good example of C and MACRO Re: Good example of C and MACRO Re: Good example of C and MACRO Re: Good example of C and MACRO Re: Good example of C and MACRO Re: Good example of C and MACRO Re: How to make an FTP through a .com file Re: How to make an FTP through a .com file patch-checksum strangeness Re: patch-checksum strangeness ---------------------------------------------------------------------- Date: 29 Nov 2008 10:11:53 GMT From: "Bob Eager" Subject: Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Message-ID: <176uZD2KcidF-pn2-2yxke5sNn90L@rikki.tavi.co.uk> On Sat, 29 Nov 2008 01:09:38 UTC, AEF wrote: > There are 77 extends per header, at least that's what a quick test on > a highly fragmented file on one of my systems (V6.2) has. I suppose > there could be fewer for newer versions of VMS if new fields were > added to the header format. I think it's clever enough to use smaller extent descriptors if the block number will fit in them; ISTR a 'rule of thumb' of ~ 55 extents, under normal circumstances. The problem is also all the other variable size stuff in the file header! -- Bob Eager Use the BIG mirror service in the UK: http://www.mirrorservice.org ------------------------------ Date: Sat, 29 Nov 2008 11:15:48 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Message-ID: In article , =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= writes: > Phillip Helbig---remove CLOTHES to reply wrote: > > In article , > > =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= > > writes: > > > >> What does "$dump/head/count=block=0/form indexf.sys" > >> says on that disk ? > > > > That /COUNT is an unknown qualifier. > > Right, 10 sec with HELP DUMP had shown that I had swapped > "count" and "block" around. Why didn't you just try with > *that* and reported back the result ? Because it was late. :-| > So what does : > "$ dump/head/block=count=0/format indexf.sys" > have to say about "Retrieval pointers" ? Dump of file DSA133:[000000]INDEXF.SYS;1 on 29-NOV-2008 12:13:56.33 File ID (1,1,0) End of file block 38608 / Allocated 100143 File Header Header area Identification area offset: 40 Map area offset: 100 Access control area offset: 255 Reserved area offset: 255 Extension segment number: 0 Structure level and version: 2, 1 File identification: (1,1,0) Extension file identification: (0,0,0) VAX-11 RMS attributes Record type: Fixed File organization: Sequential Record attributes: Record size: 512 Highest block: 100143 End of file block: 38609 End of file byte: 0 Bucket size: 0 Fixed control area size: 0 Maximum record size: 512 Default extension size: 0 Global buffer count: 0 Directory version limit: 0 File characteristics: Contiguous best try Caching attribute: Writethrough Map area words in use: 11 Access mode: 0 File owner UIC: [1,1] File protection: S:RWED, O:RWED, G:RE, W: Back link file identification: (4,4,0) Journal control flags: Active recovery units: None Highest block written: 100143 Client attributes: None Identification area File name: INDEXF.SYS;1 Revision number: 1256 Creation date: 21-APR-1997 09:47:56.89 Revision date: 28-NOV-2008 12:10:20.91 Expiration date: Backup date: 7-NOV-1998 15:57:43.50 Map area Retrieval pointers Count: 18 LBN: 0 Count: 9 LBN: 1026 Count: 9 LBN: 4290390 Count: 100107 LBN: 4190283 Checksum: 41150 ------------------------------ Date: Sat, 29 Nov 2008 04:02:20 -0800 (PST) From: AEF Subject: Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Message-ID: On Nov 29, 6:15=A0am, hel...@astro.multiCLOTHESvax.de (Phillip Helbig--- remove CLOTHES to reply) wrote: > In article , > =3D?ISO-8859-1?Q?Jan-Erik_S=3DF6derholm?=3D > writes: > > > Phillip Helbig---remove CLOTHES to reply wrote: > > > In article , > > > =3D?ISO-8859-1?Q?Jan-Erik_S=3DF6derholm?=3D > > > writes: > > > >> What does "$dump/head/count=3Dblock=3D0/form indexf.sys" > > >> says on that disk ? > > > > That /COUNT is an unknown qualifier. > > > Right, 10 sec with HELP DUMP had shown that I had swapped > > "count" and "block" around. Why didn't you just try with > > *that* and reported back the result ? > > Because it was late. =A0:-| > > > So what does : > > "$ dump/head/block=3Dcount=3D0/format indexf.sys" > > have to say about "Retrieval pointers" ? > > Dump of file DSA133:[000000]INDEXF.SYS;1 on 29-NOV-2008 12:13:56.33 > File ID (1,1,0) =A0 End of file block 38608 / Allocated 100143 > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0File Header > > Header area > =A0 =A0 Identification area offset: =A0 =A0 =A0 =A0 =A0 40 > =A0 =A0 Map area offset: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0100 > =A0 =A0 Access control area offset: =A0 =A0 =A0 =A0 =A0 255 > =A0 =A0 Reserved area offset: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 255 > =A0 =A0 Extension segment number: =A0 =A0 =A0 =A0 =A0 =A0 0 > =A0 =A0 Structure level and version: =A0 =A0 =A0 =A0 =A02, 1 > =A0 =A0 File identification: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(1,1,0) > =A0 =A0 Extension file identification: =A0 =A0 =A0 =A0(0,0,0) > =A0 =A0 VAX-11 RMS attributes > =A0 =A0 =A0 =A0 Record type: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0F= ixed > =A0 =A0 =A0 =A0 File organization: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Sequent= ial > =A0 =A0 =A0 =A0 Record attributes: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 Record size: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A05= 12 > =A0 =A0 =A0 =A0 Highest block: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0100= 143 > =A0 =A0 =A0 =A0 End of file block: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A038609 > =A0 =A0 =A0 =A0 End of file byte: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0 > =A0 =A0 =A0 =A0 Bucket size: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00 > =A0 =A0 =A0 =A0 Fixed control area size: =A0 =A0 =A0 =A0 =A00 > =A0 =A0 =A0 =A0 Maximum record size: =A0 =A0 =A0 =A0 =A0 =A0 =A0512 > =A0 =A0 =A0 =A0 Default extension size: =A0 =A0 =A0 =A0 =A0 0 > =A0 =A0 =A0 =A0 Global buffer count: =A0 =A0 =A0 =A0 =A0 =A0 =A00 > =A0 =A0 =A0 =A0 Directory version limit: =A0 =A0 =A0 =A0 =A00 > =A0 =A0 File characteristics: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Contiguous = best try > =A0 =A0 Caching attribute: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Writeth= rough > =A0 =A0 Map area words in use: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A011 > =A0 =A0 Access mode: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00 > =A0 =A0 File owner UIC: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [1,1] > =A0 =A0 File protection: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0S:RWE= D, O:RWED, G:RE, W: > =A0 =A0 Back link file identification: =A0 =A0 =A0 =A0(4,4,0) > =A0 =A0 Journal control flags: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 Active recovery units: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0None > =A0 =A0 Highest block written: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0100143 > =A0 =A0 Client attributes: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0None > > Identification area > =A0 =A0 File name: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0INDEXF.SYS;1 > =A0 =A0 Revision number: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01256 > =A0 =A0 Creation date: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A021-= APR-1997 09:47:56.89 > =A0 =A0 Revision date: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A028-= NOV-2008 12:10:20.91 > =A0 =A0 Expiration date: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 Backup date: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = 7-NOV-1998 15:57:43.50 > > Map area > =A0 =A0 Retrieval pointers > =A0 =A0 =A0 =A0 Count: =A0 =A0 =A0 =A0 18 =A0 =A0 =A0 =A0LBN: =A0 =A0 =A0= =A0 =A00 > =A0 =A0 =A0 =A0 Count: =A0 =A0 =A0 =A0 =A09 =A0 =A0 =A0 =A0LBN: =A0 =A0 = =A0 1026 > =A0 =A0 =A0 =A0 Count: =A0 =A0 =A0 =A0 =A09 =A0 =A0 =A0 =A0LBN: =A0 =A042= 90390 > =A0 =A0 =A0 =A0 Count: =A0 =A0 100107 =A0 =A0 =A0 =A0LBN: =A0 =A04190283 > > Checksum: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= 41150 OK, how about the same for SYSDUMP.DMP. AEF ------------------------------ Date: Sat, 29 Nov 2008 14:39:37 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Message-ID: In article , AEF writes: > OK, how about the same for SYSDUMP.DMP. Dump of file SYS$SYSROOT:[SYSEXE]SYSDUMP.DMP;4 on 29-NOV-2008 15:38:17.30 File ID (15153,9,0) End of file block 215910 / Allocated 215910 File Header Header area Identification area offset: 40 Map area offset: 100 Access control area offset: 255 Reserved area offset: 255 Extension segment number: 0 Structure level and version: 2, 1 File identification: (15153,9,0) Extension file identification: (0,0,0) VAX-11 RMS attributes Record type: Undefined File organization: Sequential Record attributes: Record size: 0 Highest block: 215910 End of file block: 215910 End of file byte: 512 Bucket size: 0 Fixed control area size: 0 Maximum record size: 0 Default extension size: 0 Global buffer count: 0 Directory version limit: 0 File characteristics: No backup, Contiguous best try, MoveFile disabled Caching attribute: No_caching Map area words in use: 154 Access mode: 0 File owner UIC: [1,1] File protection: S:RWED, O:RWED, G:, W: Back link file identification: (12,1,0) Journal control flags: Active recovery units: None File entry linkcount: 0 Highest block written: 215910 Client attributes: None Identification area File name: SYSDUMP.DMP;4 Revision number: 6 Creation date: 19-MAY-2005 10:57:12.42 Revision date: 28-NOV-2008 21:04:45.25 Expiration date: Backup date: Map area Retrieval pointers Count: 64629 LBN: 1256157 Count: 33723 LBN: 1493595 Count: 28269 LBN: 4046571 Count: 26478 LBN: 6462810 Count: 26181 LBN: 4020219 Count: 54 LBN: 1122822 Count: 108 LBN: 1122930 Count: 3411 LBN: 1123047 Count: 27 LBN: 1126467 Dump of file SYS$SYSROOT:[SYSEXE]SYSDUMP.DMP;4 on 29-NOV-2008 15:38:17.30 File ID (15153,9,0) End of file block 215910 / Allocated 215910 Count: 9 LBN: 1148967 Count: 9 LBN: 1149048 Count: 9 LBN: 1149210 Count: 9 LBN: 2030211 Count: 9 LBN: 2065446 Count: 9 LBN: 2065599 Count: 9 LBN: 2065617 Count: 9 LBN: 4110894 Count: 9 LBN: 4132359 Count: 9 LBN: 4132521 Count: 243 LBN: 6849396 Count: 2610 LBN: 6849648 Count: 324 LBN: 6862257 Count: 45 LBN: 6862725 Count: 207 LBN: 6862779 Count: 1494 LBN: 6863130 Count: 1872 LBN: 6864768 Count: 558 LBN: 6871095 Count: 999 LBN: 6871671 Count: 9 LBN: 6872976 Count: 360 LBN: 6873435 Count: 1935 LBN: 6873813 Count: 450 LBN: 6876369 Count: 126 LBN: 6877044 Count: 81 LBN: 6877179 Count: 3573 LBN: 6877674 Count: 144 LBN: 6881265 Count: 171 LBN: 6881463 Count: 9 LBN: 4110768 Count: 9 LBN: 4110804 Count: 5445 LBN: 4110975 Count: 5013 LBN: 4122144 Count: 9 LBN: 4132242 Count: 9 LBN: 4132269 Count: 9 LBN: 4132377 Count: 9 LBN: 4132395 Count: 9 LBN: 4132530 Count: 18 LBN: 4132548 Count: 819 LBN: 4132845 Count: 99 LBN: 4135302 Count: 90 LBN: 4135500 Count: 270 LBN: 4135680 Count: 351 LBN: 4136220 Count: 36 LBN: 4136922 Count: 45 LBN: 4136994 Count: 90 LBN: 4137084 Count: 369 LBN: 4137264 Count: 126 LBN: 4138002 Count: 4896 LBN: 4138254 Count: 9 LBN: 4143240 Checksum: 62586 Dump of file SYS$SYSROOT:[SYSEXE]SYSDUMP.DMP;4 on 29-NOV-2008 15:38:17.30 File ID (15153,9,0) End of file block 215910 / Allocated 215910 Virtual block number 1 (00000001), 512 (0200) bytes FFFFFFFF 83C91DA4 00000000 000000B8 00080002 00000002 000800C1 000009BF ¿...Á...........¸.......¤.É..... 000000 2020322D 332E3756 FFFFFFFF 83C8F000 FFFFFFFF 83C8F000 FFFFFFFF 83C93000 .0É......ðÈ......ðÈ.....V7.3-2 000020 FCFFFFFF 03000000 00034B40 00034B40 82DB7EA0 82DA3330 002B000D 8102C000 .À....+.03Ú..~Û.@K..@K.........ü 000040 FFFFFEFC 00000000 FFFFFEFD BF6FC000 FFFFFEFD BF000000 00010001 00040A00 ...........¿ýþ...Ào¿ýþ......üþ.. 000060 00000000 00000000 00000000 00000000 00A5B556 91FCC41D 00A81BE1 F8322B5E ^+2øá.¨..Äü.Vµ¥................. 000080 00000000 00000000 00000000 00000008 0002B4C0 00000C00 00000000 00000001 ............À´.................. 0000A0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 0000C0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 0000E0 08000000 00020100 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000100 30303320 4345440F 00000000 00000000 0000004C 4C554E04 20204149 44414C47 GLADIA .NULL............DEC 300 000120 00000000 000008B4 00000000 00000000 00000000 00000000 3030364D 202D2030 0 - M600................´....... 000140 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000160 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000180 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 0001A0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 0001C0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 0001E0 ------------------------------ Date: Sat, 29 Nov 2008 10:44:11 -0500 From: JF Mezei Subject: Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Message-ID: <001d4083$0$12248$c3e8da3@news.astraweb.com> AEF wrote: >> I've always tried to keep my files contiguous. Some users, or some >> processes, tend to create two block files and extend them two blocks at >> a time. In my working days, I tried very hard to stomp on such when >> found! > > Yikes! For log files, or other more or less sporadic non permanent files, doesn't it make sense to let them grow little by little and use up hidden areas of 1 or 2 free blocks (clusters would be the more accurate term) on the disk ? If some huge log file ends up being highly fragmented but uses disk areas that wouldn't be usable by other files that need better performance (contiguous), then you are using up disk real estate that is much less valuable, leaving the larger contiguous areas available for files that do need the better performance. Same thing for emails. If your average email is 3 blocks or less and your cluster size is 3 blocks, then letting new emails use isolated small areas of free blocks is a good idea instead of reducing the size of contiguous areas. The one caveat in this is if you have 2 free blocks between 2 large contiguous areas, and you delete the files occupying those 2 contiguous areas, that small file in the middle will prevent those two large contiguous areas from being combined into one very large area. ------------------------------ Date: Sat, 29 Nov 2008 11:00:15 -0500 From: "Richard B. Gilbert" Subject: Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Message-ID: JF Mezei wrote: > AEF wrote: > >>> I've always tried to keep my files contiguous. Some users, or some >>> processes, tend to create two block files and extend them two blocks at >>> a time. In my working days, I tried very hard to stomp on such when >>> found! >> Yikes! > > > For log files, or other more or less sporadic non permanent files, > doesn't it make sense to let them grow little by little and use up > hidden areas of 1 or 2 free blocks (clusters would be the more accurate > term) on the disk ? Not to me! I'd prefer an initial allocation big enough to last till the next time the application is restarted! I fought the file fragmentation issue back in the days when there were no tools to help other than backup/restore. Given the speeds available at the time, doing a backup and restore of an RA81 ate about fourteen hours during which I had to mount a tape every thirty minutes or so! Applications that allocated large files two blocks at a time were the bane of my existence! > > If some huge log file ends up being highly fragmented but uses disk > areas that wouldn't be usable by other files that need better > performance (contiguous), then you are using up disk real estate that is > much less valuable, leaving the larger contiguous areas available for > files that do need the better performance. Using sensible file allocations in the first place tends to reduce fragmentation and lengthen the time between required defragmentations. ------------------------------ Date: 29 Nov 2008 16:28:28 GMT From: "Bob Eager" Subject: Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Message-ID: <176uZD2KcidF-pn2-GzEUF0kVbR11@rikki.tavi.co.uk> On Sat, 29 Nov 2008 16:00:15 UTC, "Richard B. Gilbert" wrote: > Not to me! I'd prefer an initial allocation big enough to last till the > next time the application is restarted! > > I fought the file fragmentation issue back in the days when there were > no tools to help other than backup/restore. Given the speeds available > at the time, doing a backup and restore of an RA81 ate about fourteen > hours during which I had to mount a tape every thirty minutes or so! > > Applications that allocated large files two blocks at a time were the > bane of my existence! Yes, I have similar problems. The worst offender was an application that created thousands and thousands of small files - ANU News. I was lucky - I'd specified a spare RA81 so I used to do an image copy and swap the plugs.. -- Bob Eager Use the BIG mirror service in the UK: http://www.mirrorservice.org ------------------------------ Date: Sat, 29 Nov 2008 16:37:38 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Message-ID: Phillip Helbig---remove CLOTHES to reply wrote: > >> OK, how about the same for SYSDUMP.DMP. > > Dump of file SYS$SYSROOT:[SYSEXE]SYSDUMP.DMP;4... > ... ... > Map area > Retrieval pointers > Count: 64629 LBN: 1256157 ... ... [about 50 lines snipped...] ... > Count: 126 LBN: 4138002 > Count: 4896 LBN: 4138254 > Count: 9 LBN: 4143240 > Right then, there is your fragmented file! As someone else said, the dump file can't use multiple headers. Someway you have to make new space for this file. It *might* be that it was fragmented earier and there might be space *now* for a dump file with fewer fragments (without any other changes to the current disk). Clear up as much space as possible and just try to re-create the DMP file from scratch. ------------------------------ Date: Sat, 29 Nov 2008 10:46:38 -0500 From: JF Mezei Subject: Re: Black and White Printing Message-ID: <001d4113$0$12248$c3e8da3@news.astraweb.com> dooleys@snowy.net.au wrote: > You could use ghostscript to convert the postscript file. > If gs thinks its printer is b&w only, then it will convert the > ps file so that there is no colour in the output file. Are you sure about that ? It is my understanding that printers are the engines who internally convert a colour into a greyscale value. So you send a postscript that has colour information and the printer will do the job of converting to greyscale. Some applications are able to convert to greyscale, but generally, they don't seem too concerned about sending colour postscript to a b/W printer. ------------------------------ Date: Fri, 28 Nov 2008 23:08:59 -0800 (PST) From: johnwallace4@yahoo.co.uk Subject: Re: Good example of C and MACRO Message-ID: <21689c7a-4734-4bc6-8ff9-6c5514e33c9f@c1g2000yqg.googlegroups.com> On Nov 29, 5:06=A0am, "Tom Linden" wrote: > On Fri, 28 Nov 2008 15:20:21 -0800, Arne Vajh=F8j wrote= : > > Bob Eager wrote: > >> On Fri, 28 Nov 2008 22:53:14 UTC, Arne Vajh j wrote: > > >>>> I don't want to start a flame war but both Intel and AMD call their > >>>> popular products RISC machines which happen to be able to run CISC > >>>> code. This claim was probably engineered by sales folk because I nev= er > >>>> think of the descendants of Pentium4 as pure RISC architectures. > >>> =A0Not even close. > >>> =A0They are CISC. > >>> =A0They were CISC 20 years ago and *adding* more complex > >>> instructions did not make them RISC by magic. > >>> =A0PS: I don't think I have ever seen Intel/AMD claim that x86 or x86= -64 > >>> =A0 =A0 =A0to be RISC. > >> =A0I think the origin of this is simply that internally, that's how th= ey =A0 > >> work. All the instructions are broken down into RISC equivalents, as = =A0 > >> that makes lots of things (pipe scheduling for one) much easier. > > > Maybe. > > > But I believe that CISC/RISC always has been in the context of the > > exposed instruction set. > > > Arne > > Bob is correct. =A0They started building RISC cores at some point with th= e > 386. =A0I had a few discussions with John Crawford at that time, =A0must = have > been late 80's. =A0Basically they are emulation engines. =A0If you think = about > it this is not a lot different than was done in the early 70's with the > 2901 bit slice machines, but they were a lot harder to program and build > instructions sets with. =A0Prime actully did both V-mode (accumulator =A0 > architecture) > and I-mode (general register) with the same hardware by reprogramming the > microcode. > > -- > PL/I for OpenVMSwww.kednos.com Bitslice wasn't just for division 2 players like Prime. The VAX 730 was a 2900 (29000?)-series bitslice machine, wasn't it? What else could folk have done with a 730 if they'd known what magick to put on the TU58s? Probably not much of any great usefulness, as the whole point was to run VMS - if you didn't need VMS, there were x86s, and 68ks and other trendy young cheap'n'cheerful things coming up fast (but without VMS). ------------------------------ Date: Sat, 29 Nov 2008 13:34:50 +0000 (UTC) From: moroney@world.std.spaamtrap.com (Michael Moroney) Subject: Re: Good example of C and MACRO Message-ID: "Richard Maher" writes: >> There is little reason to write anything in Macro today; device drivers >> can be written in C. What else was Macro good for? >Many have already pointed out the benefits of macros (not to mention >MACRO-32's string and descriptor support being feature-rich when compared to >C's) Another interesting use of Macro-32 and macros I've seen is to "compile" data files into binary tables, for use in an application where the tables change occasionally. For each table, there's one set of macros that define the data structure (kind of like a C .H file with struct definitions) and a second set of macros that process the table commands themselves, the "source" consists of macro calls that fill the tables, one macro call per table row. The second set of macros contains largely of .BYTE/.WORD/.LONG/.ASCII references, the object of which may be pointers to table entries in other tables. These tables are linked against each other, resolved by the macro assembler/compiler. You don't want to know how to get from the "executable" images to data files, esp. how to get the process working on the Itanium. As kludgy as this process is, I don't know of a better way. ------------------------------ Date: 29 Nov 2008 14:20:59 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Good example of C and MACRO Message-ID: <6pd1ebF7jdkuU1@mid.individual.net> In article , "Richard B. Gilbert" writes: > Bob Koehler wrote: >> In article , "Richard B. Gilbert" writes: >>> There are a few situations where a programmer must work around the >>> typing rules. They are rare and generally occur when somebody has to >>> convert binary data from platform "A" for use on platform "B". >> >> Just try passing the address of an array to a $QIO in Ada 86, so you >> can talk to a DRQ3B. >> > > My knowledge of ADA is almost non-existent! The people I've talked with > who do use ADA say that you CAN do almost anything; but you may have > to provide the compiler with an extensive explanation of what you are > trying to do. Ah yes, Ada. I remember hearing about all the bad things that C does that Ada doesn't, which is what made Ada so superior. Until you look at the last chapter of the Ada textbook they used here that basicly showed how to get around all that string typecasting stiff. :-) And all kinds of other dirty little tricks that someone decided really were necesary writing programs in the real world. > This is as it should be. A program that uses the same > address to store a float and a long int is a disaster waiting to happen. > The original may work just fine but when it's modified. . . . OK. But what about storing 6 ASCII characters packed into one REAL*4 variable? :-) bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 29 Nov 2008 14:22:19 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Good example of C and MACRO Message-ID: <6pd1grF7jdkuU2@mid.individual.net> In article , Glen Herrmannsfeldt writes: > Arne Vajhøj wrote: > >> C Kermit is from around 1989-1990. I believe that it >> took a few years until C-Kermit was stable enough to replace >> the old VMS Kermit. > > Unix C kermit is older than that. For other than unix, > that might be about right. > The BLISS version worked just fine as far as I was concerned. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Sat, 29 Nov 2008 09:36:09 -0500 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: Good example of C and MACRO Message-ID: <49315359$0$90262$14726298@news.sunsite.dk> Bill Gunshannon wrote: > In article , > Glen Herrmannsfeldt writes: >> Arne Vajhøj wrote: >> >>> C Kermit is from around 1989-1990. I believe that it >>> took a few years until C-Kermit was stable enough to replace >>> the old VMS Kermit. >> Unix C kermit is older than that. For other than unix, >> that might be about right. >> > > The BLISS version worked just fine as far as I was concerned. The Bliss version was rock solid. But if I remember correctly, then the C version had better performance (due to ability to use larger buffers or something like that). Arne ------------------------------ Date: Sat, 29 Nov 2008 07:01:43 -0800 From: "Tom Linden" Subject: Re: Good example of C and MACRO Message-ID: On Sat, 29 Nov 2008 01:09:08 -0800, Glen Herrmannsfeldt wrote: > Roger Ivie wrote: > (snip) > >> To veer back slightly towards topic, one of the things that I do with >> MACRO32 is assemble microcode for a 2910/29116 controller. The microcode >> was originally written using META29R, which we only have on a VAX. Since >> I moved the microcode to MACRO32, I can now assemble microcode on VAXen, >> Alphas, and Itania. > > Is Itania the oxide of Itanium? Yes, it is a sun block > > Actually, I don't like the convention, but it is popular > with chemists. > > -- glen > -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Sat, 29 Nov 2008 16:00:38 +0100 From: Johnny Billquist Subject: Re: Good example of C and MACRO Message-ID: Richard B. Gilbert skrev: > Bob Koehler wrote: >> In article , Glen Herrmannsfeldt >> writes: >>> Yes, but C descended from BCPL and B, which were older >>> than the PDP-11. >> >> Did BCPL or B have ++ and -- operators? Did they assume byte >> addressable memory and a built in stack? >> > > I suspect that the ONLY way to find out at this point would be to catch > Kernighan or Plauger and ask them. I'm not sure that either language > ever escaped from the research laboratories! I havae BCPL for RSX here. It actually comes from DECUS. I also think that parts of the system in the AMIGA was written in BCPL. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol ------------------------------ Date: Sat, 29 Nov 2008 16:03:37 +0100 From: Johnny Billquist Subject: Re: Good example of C and MACRO Message-ID: Bob Koehler skrev: > In article <176uZD2KcidF-pn2-zSoxvSJxPRqB@rikki.tavi.co.uk>, "Bob Eager" writes: >> I programmed PDP-11 stuff for years, and never actually noticed the lack >> of a byte subtract...! Never needed it I guess... I may have been too >> ashamed to say so earlier... >> > > Yeah, but did anybody evfer actually find a use for the MARK > instruction? The best I could do was to push MARK on the stack > and then remeber where I'd left it. Yes, that's the way it is intended to be used. > Not in the least bit surprising that MARK was the only user mode > instruction that wasn't needed in compatability mode (RSX-11M/M+ > don't use it and thier compilers don't generate it). MARK is actually a very shitty instruction, which don't even work if you have split I/D space. It was a nice idea, but it just didn't turn out that nice in reality. And VAX then went in another, saner direction for stack handling, call frames and argument pointers. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol ------------------------------ Date: Sat, 29 Nov 2008 07:13:23 -0800 From: "Tom Linden" Subject: Re: Good example of C and MACRO Message-ID: On Sat, 29 Nov 2008 05:34:50 -0800, Michael Moroney wrote: > "Richard Maher" writes: > >>> There is little reason to write anything in Macro today; device drivers >>> can be written in C. What else was Macro good for? > >> Many have already pointed out the benefits of macros (not to mention >> MACRO-32's string and descriptor support being feature-rich when >> compared to >> C's) > > Another interesting use of Macro-32 and macros I've seen is to "compile" > data files into binary tables, for use in an application where the tables > change occasionally. For each table, there's one set of macros that > define the data structure (kind of like a C .H file with struct > definitions) > and a second set of macros that process the table commands themselves, > the > "source" consists of macro calls that fill the tables, one macro call per > table row. The second set of macros contains largely of > .BYTE/.WORD/.LONG/.ASCII references, the object of which may be pointers > to table entries in other tables. > > These tables are linked against each other, resolved by the macro > assembler/compiler. > > You don't want to know how to get from the "executable" images to data > files, esp. how to get the process working on the Itanium. > > As kludgy as this process is, I don't know of a better way. Maybe I missed something, but that sounds like a commonplace activity for PL/I. You don't need executable code to define dynamic data structures. The second set is standard I/O. > -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Sat, 29 Nov 2008 16:32:11 +0100 From: Johnny Billquist Subject: Re: Good example of C and MACRO Message-ID: johnwallace4@yahoo.co.uk skrev: > On Nov 28, 12:54 am, Roger Ivie wrote: >> On 2008-11-27, johnwalla...@yahoo.co.uk wrote: >> >>> Now if you'd said the National >>> Semiconductor NS16000 had been inspired by VAX with the additional >>> design goals of modernisation, removal of cruft, and simple support >>> for ROMable code, I'd have agreed with that. >> Pfft. I've never understood how people can say that when the NS16000 >> doesn't even have the PC as a general-purpose register. >> -- >> roger ivie >> ri...@ridgenet.net > > NS16000 wasn't a VAX clone (the Russians did those, right?), it wasn't > even trying to be VAX compatible, but chunks of it might well have > been VAX-inspired. Anyway, if you can still achieve all the relevant > addressing modes using PC-relative addressing, module pointers, etc, > which iirc the NS16000 could, what do you actually lose by not having > the PC as a general register? (or is it my turn for a sense of humour > failure?) Obviously you can't do the usual party tricks like MOV - > (R7), -(R7) like some PDP11s could, but so what? Anyway, history has > shown that a nice instruction set architecture is not necessarily > guarantee of, or even a prerequisite for, market success. Not then, > not now. The big point of having the PC as a general register is that you don't need special opcodes for the instructions when you want to address things PC-relative. It's just a normal addressing mode, with a general register. It makes a lot of things easier. But sure, you can accomplish the same thing without that feature. But it makes life more difficult. Let me give you an example: The 68K are pretty inspired by the PDP11 and VAX. But they don't have the PC as a general register. Instead you have specific opcodes for variations of the instruction. Take CMP (compare) - in the 68K you have compare, and you have compare immediate. In an assembler, you'd write CMP.B #'A,D0 for instance. And the assembler would know that that's actually a special version of CMP.B, which takes one immediate argument, and one (data) register. If you instead wrote CMP.B D0,D1 it would assemble to another opcode. And you might say "so what". That's all the responsobility of the assembler, and I as a programmer don't have to worry or think about it. And it causes the same end result as if you would have programmed on a PDP11 or a VAX. All very true. But consider this. On a PDP11 or a VAX, you could also have written this: CMPB R0,#'A and you just can't do that on a 68K. The immediate mode argument can only be the first argument, since it's actually a different opcode, and not a generic argument to the CMPB instruction (or CMP.B as it would be called on a 68K). And no, it's not the same. While one can be replaced by the other, they will cause different results in the condition codes, and code following it will have to be adjusted accordingly. And if you write in assembler, you would probably prefer the code to reflect your through instead of having to be adjusted to fit into what can be expressed by the instruction set. There are a whole bunch of variations that can't be expressed because the 68K have several different opcodes for CMP which caters to various special situations. It's all a *mess*! > I think Ritchie's in-depth history of C (http://cm.bell-labs.com/cm/cs/ > who/dmr/chist.html) says the auto-increment/auto-decrement stuff came > from PDP7. I doubt it. The PDP7 don't stuff like that, and besides, C wasn't designed until they had moved to the PDP-11. The first few versions of Unix on the PDP-11 was still written in assembler before they moved to C. But Ritche have also been very clear that the autoincrement and autodecrement elements in C were *not* inspired by the PDP-11. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol ------------------------------ Date: Sat, 29 Nov 2008 16:48:34 +0100 From: Michael Kraemer Subject: Re: Good example of C and MACRO Message-ID: Johnny Billquist schrieb: > I also think that parts of the system in the AMIGA was written in BCPL. Yes, AmigaDOS, i.e. the part which deals with the file system. Not a good idea in hindsight, because the rest of the system is coded in C and assembly. BCPL API expects pointers to 4-byte entities, whereas "normal" pointers are supposed to be byte address. Confusing these two is a major pitfall and most Amigans view BCPL-based AmigaDOS as the odd man out of the system. ------------------------------ Date: 29 Nov 2008 15:50:20 GMT From: "Bob Eager" Subject: Re: Good example of C and MACRO Message-ID: <176uZD2KcidF-pn2-rfsGVdt9vN3v@rikki.tavi.co.uk> On Sat, 29 Nov 2008 14:36:09 UTC, Arne Vajhj wrote: > Bill Gunshannon wrote: > > In article , > > Glen Herrmannsfeldt writes: > >> Arne Vajhj wrote: > >> > >>> C Kermit is from around 1989-1990. I believe that it > >>> took a few years until C-Kermit was stable enough to replace > >>> the old VMS Kermit. > >> Unix C kermit is older than that. For other than unix, > >> that might be about right. > >> > > > > The BLISS version worked just fine as far as I was concerned. > > The Bliss version was rock solid. > > But if I remember correctly, then the C version had > better performance (due to ability to use larger > buffers or something like that). And sliding windows....allowing overlap between send and acknowledge. -- Bob Eager Use the BIG mirror service in the UK: http://www.mirrorservice.org ------------------------------ Date: 29 Nov 2008 15:54:09 GMT From: "Bob Eager" Subject: Re: Good example of C and MACRO Message-ID: <176uZD2KcidF-pn2-b1HzP6fgmgdc@rikki.tavi.co.uk> On Sat, 29 Nov 2008 15:00:38 UTC, Johnny Billquist wrote: > I havae BCPL for RSX here. It actually comes from DECUS. > I also think that parts of the system in the AMIGA was written in BCPL. I may not have made it clear, but I have BCPL for VMS! Not from DECUS....I wrote it. -- Bob Eager Use the BIG mirror service in the UK: http://www.mirrorservice.org ------------------------------ Date: 29 Nov 2008 15:54:09 GMT From: "Bob Eager" Subject: Re: Good example of C and MACRO Message-ID: <176uZD2KcidF-pn2-vojyydTuUdQK@rikki.tavi.co.uk> On Sat, 29 Nov 2008 15:00:38 UTC, Johnny Billquist wrote: > I also think that parts of the system in the AMIGA was written in BCPL. Yup...it was based on the TRIPOS operating system, written by some undergraduates at the University of Cambridge (UK). I have a copy of TRIPOS somewhere...the source code, anyway. I ran it on a PDP-11 for a while, after patching the kernel image so it would work on an 11/34! -- Bob Eager Use the BIG mirror service in the UK: http://www.mirrorservice.org ------------------------------ Date: 29 Nov 2008 16:42:31 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Good example of C and MACRO Message-ID: <6pd9nnF7inb9U1@mid.individual.net> In article <176uZD2KcidF-pn2-rfsGVdt9vN3v@rikki.tavi.co.uk>, "Bob Eager" writes: > On Sat, 29 Nov 2008 14:36:09 UTC, Arne Vajhj wrote: > >> Bill Gunshannon wrote: >> > In article , >> > Glen Herrmannsfeldt writes: >> >> Arne Vajhj wrote: >> >> >> >>> C Kermit is from around 1989-1990. I believe that it >> >>> took a few years until C-Kermit was stable enough to replace >> >>> the old VMS Kermit. >> >> Unix C kermit is older than that. For other than unix, >> >> that might be about right. >> >> >> > >> > The BLISS version worked just fine as far as I was concerned. >> >> The Bliss version was rock solid. >> >> But if I remember correctly, then the C version had >> better performance (due to ability to use larger >> buffers or something like that). > > And sliding windows....allowing overlap between send and acknowledge. Too bad there was no one to just add those features to the Bliss version. Hmmmm... Might be fun to try. Especially for someone like me who's only experience with Bliss is knowing it's reputation. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 29 Nov 2008 16:44:44 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Good example of C and MACRO Message-ID: <6pd9rsF7inb9U2@mid.individual.net> In article <176uZD2KcidF-pn2-vojyydTuUdQK@rikki.tavi.co.uk>, "Bob Eager" writes: > On Sat, 29 Nov 2008 15:00:38 UTC, Johnny Billquist > wrote: > >> I also think that parts of the system in the AMIGA was written in BCPL. > > Yup...it was based on the TRIPOS operating system, written by some > undergraduates at the University of Cambridge (UK). I have a copy of > TRIPOS somewhere...the source code, anyway. I ran it on a PDP-11 for a > while, after patching the kernel image so it would work on an 11/34! Any chance of getting the PDP-11 stuff? Some of us still enjoy playing with ours and I never heard anyone mention this OS. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Sat, 29 Nov 2008 12:03:25 -0500 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: Good example of C and MACRO Message-ID: <493175dd$0$90262$14726298@news.sunsite.dk> Bill Gunshannon wrote: > In article <176uZD2KcidF-pn2-rfsGVdt9vN3v@rikki.tavi.co.uk>, > "Bob Eager" writes: >> On Sat, 29 Nov 2008 14:36:09 UTC, Arne Vajhj wrote: >> >>> Bill Gunshannon wrote: >>>> In article , >>>> Glen Herrmannsfeldt writes: >>>>> Arne Vajhj wrote: >>>>> >>>>>> C Kermit is from around 1989-1990. I believe that it >>>>>> took a few years until C-Kermit was stable enough to replace >>>>>> the old VMS Kermit. >>>>> Unix C kermit is older than that. For other than unix, >>>>> that might be about right. >>>>> >>>> The BLISS version worked just fine as far as I was concerned. >>> The Bliss version was rock solid. >>> >>> But if I remember correctly, then the C version had >>> better performance (due to ability to use larger >>> buffers or something like that). >> And sliding windows....allowing overlap between send and acknowledge. > > Too bad there was no one to just add those features to the Bliss > version. Hmmmm... Might be fun to try. Especially for someone > like me who's only experience with Bliss is knowing it's reputation. FDC probably wanted to standardize on C Kermit on all/many platforms (with a few OS specific modules) to lower the burden of maintenance. Arne ------------------------------ Date: Sat, 29 Nov 2008 09:57:27 -0500 From: "Richard B. Gilbert" Subject: Re: How to make an FTP through a .com file Message-ID: Steven M. Schweda wrote: > From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) > >>> Thinking you in advance >> I'd rather be thanked. (I guess English is not your first language?) > >> 3) Write the FTP commands to a file and run your FTP client with >> that file as it's input stream. > > "[...] with that file as [it is] input stream"? I guess that English > is not _your_ first language, either, unless you have some other excuse. > (I'll let the reader decide whose (or should I say, "who's"?) English > usage needs more help, and who's (or should I say, "whose"?) fit to > provide it.) > Some people never learned to use their NATIVE language properly. I once heard a grown man, presumably one who attended school for at least ten years, say "Her and Bruce went to a movie." !!!!!!!!! ------------------------------ Date: Sat, 29 Nov 2008 12:29:34 -0600 (CST) From: sms@antinode.info (Steven M. Schweda) Subject: Re: How to make an FTP through a .com file Message-ID: <08112912293427_2020048A@antinode.info> From: "Richard B. Gilbert" > Some people never learned to use their NATIVE language properly. > > I once heard a grown man, presumably one who attended school for at > least ten years, say "Her and Bruce went to a movie." !!!!!!!!! I'm more annoyed by the over-correctors who think that "between you and I" is ok. Or that always using "myself" instead of (the evil) "me" shows refinement. But I'm easily annoyed. On a recent book-store visit, I noticed a new illustrated edition of "Eats, Shoots & Leaves", presumably an attempt to expand its market beyond the limited set of people who can read. SMS. ------------------------------ Date: Sat, 29 Nov 2008 17:25:55 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: patch-checksum strangeness Message-ID: I'm catching up on VAX 7.3 patches. As always, I downloaded them with LYNX. After unpacking them, the checksum matches what is in the corresponding description in the .TXT file on the patch site. However, the zipped checksums don't match. Could that be because the zipped file has the wrong attributes or something, thus changing the checksum, but still unpacks OK? Also, check this out: $ checks VAXMONT01_073.A;1 $ sh sym checksu* CHECKSUM$CHECKSUM = "1502668639" $ checks VAXSMGRMUP01_073.A;1 $ sh sym checksu* CHECKSUM$CHECKSUM = "3788353911" $ checks VAXTZ02_073.A;1 $ sh sym checksu* CHECKSUM$CHECKSUM = "3788353911" $ dir/siz Directory SYS$SYSROOT:[SYSUPD.PATCHES.OS.7_3.20081129] VAXMONT01_073.A;1 522 VAXSMGRMUP01_073.A;1 342 VAXTZ02_073.A;1 270 Total of 3 files, 1134 blocks. What are the chances of VAXSMGRMUP01_073.A;1 and VAXTZ02_073.A;1 having the same checksum? Note that my values match (for the unzipped files) the values at the patch site. (I guess it's theoretically possible. I once had a file with a checksum of 0. Also unlikely.) ------------------------------ Date: Sat, 29 Nov 2008 12:18:46 -0600 (CST) From: sms@antinode.info (Steven M. Schweda) Subject: Re: patch-checksum strangeness Message-ID: <08112912184592_2020048A@antinode.info> From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) > I'm catching up on VAX 7.3 patches. > > As always, I downloaded them with LYNX. After unpacking them, the > checksum matches what is in the corresponding description in the .TXT > file on the patch site. However, the zipped checksums don't match. > Could that be because the zipped file has the wrong attributes or > something, thus changing the checksum, but still unpacks OK? Sounds likely. Change the attributes and see what happens. In any case, Zip archives have built-in checksums, so UnZip should complain about normal corruption, making this a case for Lady Redundant Woman. And, of course, building checksums into files can affect the distribution of those files' checksums. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-info 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ End of INFO-VAX 2008.638 ************************