INFO-VAX Sat, 29 Nov 2008 Volume 2008 : Issue 637 Contents: Re: 150 year Re: Autogen params report... Re: Autogen params report... 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: 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: 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: 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: Black and White Printing Re: Black and White Printing Re: Black and White Printing Re: Black and White Printing Re: Black and White Printing Date centre design Re: forwarding email to a distribution list Re: forwarding email to a distribution list Re: forwarding email to a distribution list 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: 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: 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 Re: How to make an FTP through a .com file Re: How to make an FTP through a .com file Re: How to make an FTP through a .com file Re: LAT BARCODE PRINTER Re: LAT BARCODE PRINTER Re: LAT BARCODE PRINTER Re: MUTEX Re: MUTEX Re: MUTEX Re: MUTEX Re: PPL$ documentation Re: PPL$ documentation Re: PPL$ documentation Re: search list, surprising error, inconsistent behavior ---------------------------------------------------------------------- Date: 28 Nov 2008 16:03:30 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: 150 year Message-ID: In article <6p3jo9F65vkgU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes: > > Well, it's been a long time so things may have gotten better but I once > built a "digital" clock for our living room that used the line freq. for > it's time standard (Heathkit). It differed from the proverbial broken > clock in that it was not even correct twice a day. It has also been a > long time since I was in a place that needed to monitor the powerline > but I remember the chart recorder showing a lot of variance in both > the voltage and frequency. Heathkit elecronics work, but they're not exactly the best. While I did play Sargon several times on a Heathkit PDP-11 based computer, I'd be wary of craft kit electronic clocks being sussceptable to noise. A good electronic clock filters out a lot of noise. ------------------------------ Date: 28 Nov 2008 16:49:26 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Autogen params report... Message-ID: In article , =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= writes: > Hi. > Today we had som problem with a number > of processes going into RWMBX state. > > This has something with mailbox devices > to do, as far as I understand. > > I've tried with ana/sys, sda>set proc/id=xxx and > sda> sh proc/chan to find the MB devices, > but none of the RWMBX processes has any > channels to any MBA device. > Never seen that. Did you make sure you checked possibly multiple pages of "show proc/chan"? Generally this has to do with processes writing to mailboxes that nobody is reading, a common application mistake. The temporary solution, after finding the mailbox device, is to copy it somewhere. A file might be nice for debugging, but once you understand the bug you can just copy it to the null device. The permanent solution is to make sure the receiving application keeps an asynchronous read on the mailbox. If the processes aren't intentionally using mailboxes, look for process startups that return status to the starting process via a mailbox. The second process does not need any knowledge of this. ------------------------------ Date: Fri, 28 Nov 2008 23:32:17 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: Autogen params report... Message-ID: <5c%Xk.4494$U5.33773@newsb.telia.net> Bob Koehler wrote: > In article , =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= writes: >> Hi. >> Today we had som problem with a number >> of processes going into RWMBX state. >> >> This has something with mailbox devices >> to do, as far as I understand. >> >> I've tried with ana/sys, sda>set proc/id=xxx and >> sda> sh proc/chan to find the MB devices, >> but none of the RWMBX processes has any >> channels to any MBA device. >> > > Never seen that. Did you make sure you checked possibly multiple > pages of "show proc/chan"? I replied to myself in a later post saying that I had "missed" the "press return for next page"... :-) And the problem was later found and reported back here on c.o.v. I'm currently digging into something called TTCOM, an interprocess communication tool written at DEC/Sweden using mailboxes as the transfer medium. The last revision to the manual was 10-June-1985... :-). The manual describes VAX/VMS and PDP/RSX but the prod envir right now is Alpha OpenVMS 8.2. Interesting... :-) Jan-Erik. > > Generally this has to do with processes writing to mailboxes that > nobody is reading, a common application mistake. > > The temporary solution, after finding the mailbox device, is to copy > it somewhere. A file might be nice for debugging, but once you > understand the bug you can just copy it to the null device. > > The permanent solution is to make sure the receiving application > keeps an asynchronous read on the mailbox. > > If the processes aren't intentionally using mailboxes, look for > process startups that return status to the starting process via > a mailbox. The second process does not need any knowledge of this. > > ------------------------------ Date: Fri, 28 Nov 2008 20:17:06 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Message-ID: Running AUTOGEN on a DEC 3000/600 with VMS 7.3-2 results in the following error: %AUTOGEN-I-BEGIN, GENFILES phase is beginning. %SYSTEM-W-HEADERFULL, file header is full ** WARNING ** - Error creating SYS$SYSROOT:[SYSEXE]SYSDUMP.DMP. ** ERROR ** - error creating SYSDUMP.DMP. SYSDUMP.DMP needs to be created manually with 393258 blocks $ dir SYS$SYSROOT:[SYSEXE]SYSDUMP.DMP Directory SYS$SYSROOT:[SYSEXE] SYSDUMP.DMP;4 215910 Total of 1 file, 215910 blocks. $ sh dev disk$alphasys_3 Device Device Error Volume Free Trans Mnt Name Status Count Label Blocks Count Cnt DSA133: Mounted 0 ALPHASYS_3 1910871 1 3 $33$DKB100: (GLADIA) ShadowSetMember 0 (member of DSA133:) $33$DKB600: (GLADIA) ShadowSetMember 0 (member of DSA133:) Question: since the error is %SYSTEM-W-HEADERFULL, file header is full how can I create it manually if AUTOGEN can't? When initialising disks, I'm always rather liberal with the /HEADERS qualifier, so I don't think that's the problem. How can I solve this problem? ------------------------------ Date: Fri, 28 Nov 2008 12:25:32 -0800 (PST) From: Hein RMS van den Heuvel Subject: Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Message-ID: <406a5819-ddae-4b45-ace8-c9ea02e58687@k19g2000yqg.googlegroups.com> On Nov 28, 3:17=A0pm, hel...@astro.multiCLOTHESvax.de (Phillip Helbig--- remove CLOTHES to reply) wrote: > Question: since the error is > > =A0 =A0%SYSTEM-W-HEADERFULL, file header is full > > how can I create it manually if AUTOGEN can't? Because Autogen has some temp file already created? HEADERFULL is a very explicit error there is no negotiaing with that. > When initialising disks, I'm always rather liberal with the /HEADERS > qualifier, so I don't think that's the problem. Don't think. Use DFU REPORT Also... /HEADER is a less critical value. /MAXIMUM_FILES is the one that really counts. > How can I solve this problem? That will depend on what the problem is. You may be able to clean out some files for now, but you may well need to re-init a disk with /MAX=3D'more' and $BACKUP/ NOINIT/IMAGE ... hth, Hein. ------------------------------ Date: Fri, 28 Nov 2008 15:27:53 -0500 From: JF Mezei Subject: Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Message-ID: <001c317c$0$12261$c3e8da3@news.astraweb.com> Phillip Helbig---remove CLOTHES to reply wrote: > %SYSTEM-W-HEADERFULL, file header is full > > how can I create it manually if AUTOGEN can't? defragment the disk and then try to create it again. With a fragmented disk, creating a very large fil will require that it scavenge free disk space from all over the disk and thus cannot build a file with a single contiguous area of disk. Each time it uses one area of disk, it takes one header, and for a large file it may use up enough separate areas of the disk that the space for headers for a single file becomes full. Does the dumpfile need to be contiguous ? ------------------------------ Date: Fri, 28 Nov 2008 20:46:13 +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 <406a5819-ddae-4b45-ace8-c9ea02e58687@k19g2000yqg.googlegroups.com>, Hein RMS van den Heuvel writes: > On Nov 28, 3:17 pm, hel...@astro.multiCLOTHESvax.de (Phillip Helbig--- > remove CLOTHES to reply) wrote: > > > Question: since the error is > > > > %SYSTEM-W-HEADERFULL, file header is full > > > > how can I create it manually if AUTOGEN can't? > > Because Autogen has some temp file already created? Sorry, I don't follow you here. > HEADERFULL is a very explicit error there is no negotiaing with that. I seem to remember there is the bad HEADERFULL and the harmless HEADERFULL. Or am I remembering wrongly? > > When initialising disks, I'm always rather liberal with the /HEADERS > > qualifier, so I don't think that's the problem. > Also... /HEADER is a less critical value. > /MAXIMUM_FILES is the one that really counts. Maximum files allowed 419004 $ set default disk$alphasys_3:[000000] $ dir/gra [...]/exc=([.sys0.syscommon...],[.vms$common...]) Grand total of 805 directories, 34738 files. Can /MAXIMUM_FILES really be too low? > > How can I solve this problem? > > That will depend on what the problem is. > You may be able to clean out some files for now, > but you may well need to re-init a disk with /MAX='more' and $BACKUP/ > NOINIT/IMAGE ... In the next few days, I am going to shut down each of my nodes, pull one of the members of the system-disk shadow set (so I have a backup I can quickly revert to), do an ANA/DISK/REPAIR (and, while I am at it, install some patches if necessary) then, when everything looks OK, add the backup member back to the shadow set. A similar procedure for non--system-disk shadow sets. If necessary, when the shadow set above has just one member, I could privately mount the other (backup) member, do a backup to another disk after having initialised it properly, then reboot from this third disk. However, I'm not sure that there is really a problem. Maybe it will go away after I do an ANA/DISK/REPAIR? ------------------------------ Date: Fri, 28 Nov 2008 12:53:48 -0800 (PST) From: AEF Subject: Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Message-ID: <247c8523-54cc-45f4-bcd7-8f1054c3a91a@v4g2000yqa.googlegroups.com> On Nov 28, 3:25 pm, Hein RMS van den Heuvel wrote: > On Nov 28, 3:17 pm, hel... (Phillip Helbig--- > remove CLOTHES to reply) wrote: > > > Question: since the error is > > > %SYSTEM-W-HEADERFULL, file header is full > > > how can I create it manually if AUTOGEN can't? > > Because Autogen has some temp file already created? > > HEADERFULL is a very explicit error there is no negotiaing with that. > > > When initialising disks, I'm always rather liberal with the /HEADERS > > qualifier, so I don't think that's the problem. > > Don't think. > Use DFU REPORT > Also... /HEADER is a less critical value. > /MAXIMUM_FILES is the one that really counts. Not for this problem. Also, the default value for /MAXIMUM_FILES is half of the maximum value allowed for the given drive anyway. The problem here is that INDEXF.SYS is so fragmented that its single- block file header has run out of room for pointers to its own extents (and that this header is required to be only one block in size). > > > How can I solve this problem? If manually creating the dump file doesn't work, you will have to reduce the number of file headers in use (by deleting files) so that they become available for new files. The best solution is to back up the disk to tape and restore from tape or back up the drive to another drive and use that drive. I don't think you'll ever get this problem on this disk again if you do that. > > That will depend on what the problem is. > You may be able to clean out some files for now, > but you may well need to re-init a disk with /MAX='more' and $BACKUP/ > NOINIT/IMAGE ... Upping /MAXIMUM_FILES will not help. Simply using BACKUP to move the drive's data to tape and back or to another disk will keep you going for quite a while. In the 1990's I found that when you reach about 50000 files (or file headers), you will fill up the header for INDEXF.SYS, after which I never had the same problem again (on the given disk, of course). However, the extension algorithm for INDEXF.SYS has been greatly improved since then to avoid this very problem, but there has been at least one buggy version (which cause me a problem once!). Either your disk is severely fragmented or you have a buggy version of the algorithm. "Repack" the disk and all will be well. (You could help things even more by estimating the total number of extents you will ever have on the disk and set /HEADERS to that, but with the new extension algorithm this may not matter much at all.) > > hth, > Hein. AEF ------------------------------ Date: Fri, 28 Nov 2008 13:06:45 -0800 (PST) From: AEF Subject: Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Message-ID: <390ada30-3698-4620-81b7-6c6f1bb2e7ea@v13g2000yqm.googlegroups.com> On Nov 28, 3:27 pm, JF Mezei wrote: > Phillip Helbig---remove CLOTHES to reply wrote: > > > %SYSTEM-W-HEADERFULL, file header is full > > > how can I create it manually if AUTOGEN can't? > > defragment the disk and then try to create it again. With a fragmented > disk, creating a very large fil will require that it scavenge free disk > space from all over the disk and thus cannot build a file with a single > contiguous area of disk. This should help, but I don't think you can defragment INDEXF.SYS itself while the disk is mounted. (I assume you're talking on-line defragging.) Still, defragmenting enough files may solve the problem for now. If you have the downtime, the best thing to do is "repack" the disk (offline defragging). > > Each time it uses one area of disk, it takes one header, and for a large > file it may use up enough separate areas of the disk that the space for > headers for a single file becomes full. This is not true. Each file header can hold the mappings for many extents. When you get so many extents that it fills up the file header, an extension file header is created which is then referenced by the first file header. And when that file header fills up, . . . You can verify this by running the DUMP command with the appropriate qualifiers. (I think it's $ DUMP /HEADER /BLOCK=COUNT=0 /FORMATTED but I'm not going to test it right now.) > > Does the dumpfile need to be contiguous ? I don't know, but I wouldn't be surprised if it does or at least "Contiguous best try". AEF ------------------------------ Date: Fri, 28 Nov 2008 16:12:55 -0500 From: JF Mezei Subject: Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Message-ID: <0022372a$0$9223$c3e8da3@news.astraweb.com> AEF wrote: > This is not true. Each file header can hold the mappings for many > extents. Isn't there a limit on how many extents a file can have and trying to create an additional extent then fails ? What is the error message generated at that time ? I remember circa 5.5-2 on VAX a user having so many mail messages in her mail directory that reception of new messages created s similar message (since the .dir file could not be extended anymore). ------------------------------ Date: Fri, 28 Nov 2008 21:14:09 +0000 (UTC) From: moroney@world.std.spaamtrap.com (Michael Moroney) Subject: Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Message-ID: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes: >Running AUTOGEN on a DEC 3000/600 with VMS 7.3-2 results in the >following error: >%AUTOGEN-I-BEGIN, GENFILES phase is beginning. >%SYSTEM-W-HEADERFULL, file header is full > ** WARNING ** - Error creating SYS$SYSROOT:[SYSEXE]SYSDUMP.DMP. > ** ERROR ** - error creating SYSDUMP.DMP. SYSDUMP.DMP needs > to be created manually with 393258 blocks >$ dir SYS$SYSROOT:[SYSEXE]SYSDUMP.DMP >Directory SYS$SYSROOT:[SYSEXE] >SYSDUMP.DMP;4 215910 >Total of 1 file, 215910 blocks. Certain system files, like SYSDUMP.DMP, don't have to be contiguous, however the file header information must fit in one file header. The usual reason why it doesn't is if there are too many fragments to fit all of them in one header. And the usual reason for this is the disk is fragmented. Solution: defragment the disk, however if you're lucky, sometimes deleting an old pagefile.sys will free enough large chunks to create the other file. Easiest way to defragment (and get a free backup) is $ BACKUP/IMAGE to another drive and back. ------------------------------ Date: Fri, 28 Nov 2008 13:25:09 -0800 (PST) From: AEF Subject: Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Message-ID: On Nov 28, 3:46 pm, hel...@astro.multiCLOTHESvax.de (Phillip Helbig--- remove CLOTHES to reply) wrote: > In article > <406a5819-ddae-4b45-ace8-c9ea02e58...@k19g2000yqg.googlegroups.com>, > Hein RMS van den Heuvel writes: > > > On Nov 28, 3:17 pm, hel...@astro.multiCLOTHESvax.de (Phillip Helbig--- > > remove CLOTHES to reply) wrote: > > > > Question: since the error is > > > > %SYSTEM-W-HEADERFULL, file header is full > > > > how can I create it manually if AUTOGEN can't? > > > Because Autogen has some temp file already created? > > Sorry, I don't follow you here. The temp file will consume at least one file header, thus leaving less room in INDEXF.SYS for the file header(s?) needed for SYSDUMP.DMP. It seems to me to be rather unlikely, but I would need to investigate it more. > > > HEADERFULL is a very explicit error there is no negotiaing with that. > > I seem to remember there is the bad HEADERFULL and the harmless > HEADERFULL. Or am I remembering wrongly? I've never seen a "harmless" version. Whenever I see it I go, "Yikes!" > > > > When initialising disks, I'm always rather liberal with the /HEADERS > > > qualifier, so I don't think that's the problem. > > Also... /HEADER is a less critical value. > > /MAXIMUM_FILES is the one that really counts. > > Maximum files allowed 419004 > > $ set default disk$alphasys_3:[000000] > > $ dir/gra [...]/exc=([.sys0.syscommon...],[.vms$common...]) > > Grand total of 805 directories, 34738 files. > > Can /MAXIMUM_FILES really be too low? Not in this case, but it can be too low in other cases. If you ever do accumulate enough file headers to exhaust the /MAXIMUM_FILES bitmap inside of INDEXF.SYS, you will not be able to create more files without either deleting some files first or initializing the disk. (There is one bit reserved for each file header. This is NOT BITMAP.SYS; it is a different bitmap and it resides in INDEXF.SYS.) > > > > How can I solve this problem? > > > That will depend on what the problem is. > > You may be able to clean out some files for now, > > but you may well need to re-init a disk with /MAX='more' and $BACKUP/ > > NOINIT/IMAGE ... > > In the next few days, I am going to shut down each of my nodes, pull one > of the members of the system-disk shadow set (so I have a backup I can > quickly revert to), do an ANA/DISK/REPAIR (and, while I am at it, > install some patches if necessary) then, when everything looks OK, add > the backup member back to the shadow set. A similar procedure for > non--system-disk shadow sets. > > If necessary, when the shadow set above has just one member, I could > privately mount the other (backup) member, do a backup to another disk > after having initialised it properly, then reboot from this third disk. If you do this, you will lose any new data on the one-member system disk. You probably don't need to manually re-init the disk. If you do, make the value for /HEADERS larger than the maximum number of file headers (including extension headers) you think you will ever have on this disk, and then add some for a safety cushion. Even if you don't, you will probably get only one or two more extensions of INDEXF.SYS and the header will not fill up becuse of it. > However, I'm not sure that there is really a problem. Then why did you post this?! > > Maybe it will go away after I do an ANA/DISK/REPAIR? Most likely no. If ANAL/DISK/REPAIR by chance happens to free up enough file headers, then it will work, at least for a while. The best approach is to "repack" the volume and you will almost certainly never need to do it again. (I've never had to repeat this operation on a given disk in my entire VMS career.) Check out the "Guide to OpenVMS File Applications" manual for details on all of this, esp. the description of INDEXF.SYS. AEF ------------------------------ Date: Fri, 28 Nov 2008 16:29:30 -0500 From: "Richard B. Gilbert" Subject: Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Message-ID: Phillip Helbig---remove CLOTHES to reply wrote: > Running AUTOGEN on a DEC 3000/600 with VMS 7.3-2 results in the > following error: > > %AUTOGEN-I-BEGIN, GENFILES phase is beginning. > %SYSTEM-W-HEADERFULL, file header is full > > ** WARNING ** - Error creating SYS$SYSROOT:[SYSEXE]SYSDUMP.DMP. > > ** ERROR ** - error creating SYSDUMP.DMP. SYSDUMP.DMP needs > to be created manually with 393258 blocks > > $ dir SYS$SYSROOT:[SYSEXE]SYSDUMP.DMP > > Directory SYS$SYSROOT:[SYSEXE] > > SYSDUMP.DMP;4 215910 > > Total of 1 file, 215910 blocks. > > $ sh dev disk$alphasys_3 > > Device Device Error Volume Free Trans Mnt > Name Status Count Label Blocks Count Cnt > DSA133: Mounted 0 ALPHASYS_3 1910871 1 3 > $33$DKB100: (GLADIA) ShadowSetMember 0 (member of DSA133:) > $33$DKB600: (GLADIA) ShadowSetMember 0 (member of DSA133:) > > Question: since the error is > > %SYSTEM-W-HEADERFULL, file header is full > > how can I create it manually if AUTOGEN can't? > > When initialising disks, I'm always rather liberal with the /HEADERS > qualifier, so I don't think that's the problem. > > How can I solve this problem? > Try a BACKUP /IMAGE and restore. You might have to re-init the disk. Digging into the statistics a little: number of files, number of extents per file, etc, might be revealing! IIRC each file header supports a fairly limited number of extents, if you need more extents, you need a second file heard and sometimes a third, fourth. . . . 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! Programs were written to get a reasonable allocation in the first place and to get a reasonably sized extent if one was needed. I learned this the hard way when my poor old VAX 11/750 ground almost to a halt due to disk file fragmentation! I spent most of a weekend doing an image backup and restore of an RA81 to/from a 1600 BPI tape. It made a huge difference in performance. ------------------------------ Date: Fri, 28 Nov 2008 16:41:42 -0500 From: "Richard B. Gilbert" Subject: Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Message-ID: JF Mezei wrote: > Phillip Helbig---remove CLOTHES to reply wrote: > >> %SYSTEM-W-HEADERFULL, file header is full >> >> how can I create it manually if AUTOGEN can't? > > defragment the disk and then try to create it again. With a fragmented > disk, creating a very large fil will require that it scavenge free disk > space from all over the disk and thus cannot build a file with a single > contiguous area of disk. > > Each time it uses one area of disk, it takes one header, and for a large > file it may use up enough separate areas of the disk that the space for > headers for a single file becomes full. > > Does the dumpfile need to be contiguous ? > I don't recall if it's required or not but as a practical matter, yes, the dump file must be contiguous. Writing a dump file takes long enough when the space is contiguous. If it has to bounce the heads all over the disk, it will take even longer! Remember that if your system is writing a crash dump it's effectively down until it finishes writing the dump and reboots. ISTR that an Alphaserver 4100 required almost 15 minutes to dump 2 GB of memory. The boss wanted me to terminate the dump and get the machine up again but I argued that, without the dump, we wouldn't know WHY the machine crashed and it would almost certainly crash again at the next opportunity. It turned out that the machine had run out of some resource allocated by SYSGEN. It was easily fixed as soon as we had the dump interpreted. ------------------------------ Date: Fri, 28 Nov 2008 16:47:53 -0500 From: JF Mezei Subject: Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Message-ID: <001c443b$0$12281$c3e8da3@news.astraweb.com> Richard B. Gilbert wrote: > I don't recall if it's required or not but as a practical matter, yes, > the dump file must be contiguous. Isn't the dumpfile written by the firmware instead of the OS ? If it is written by th firmware, would the firmware be aware of ODS file structures and extents ? Or would it just have the ability to find the starting block for the dumpfile (like it does for the boot file) and then dump the content of memory block by block sequentially ? ------------------------------ Date: Fri, 28 Nov 2008 16:52:48 -0500 From: "Richard B. Gilbert" Subject: Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Message-ID: Phillip Helbig---remove CLOTHES to reply wrote: > In article > <406a5819-ddae-4b45-ace8-c9ea02e58687@k19g2000yqg.googlegroups.com>, > Hein RMS van den Heuvel writes: > >> On Nov 28, 3:17 pm, hel...@astro.multiCLOTHESvax.de (Phillip Helbig--- >> remove CLOTHES to reply) wrote: >> >>> Question: since the error is >>> >>> %SYSTEM-W-HEADERFULL, file header is full >>> >>> how can I create it manually if AUTOGEN can't? >> Because Autogen has some temp file already created? > > Sorry, I don't follow you here. > >> HEADERFULL is a very explicit error there is no negotiaing with that. > > I seem to remember there is the bad HEADERFULL and the harmless > HEADERFULL. Or am I remembering wrongly? > >>> When initialising disks, I'm always rather liberal with the /HEADERS >>> qualifier, so I don't think that's the problem. > >> Also... /HEADER is a less critical value. >> /MAXIMUM_FILES is the one that really counts. > > Maximum files allowed 419004 > > $ set default disk$alphasys_3:[000000] > > $ dir/gra [...]/exc=([.sys0.syscommon...],[.vms$common...]) > > Grand total of 805 directories, 34738 files. > > Can /MAXIMUM_FILES really be too low? > >>> How can I solve this problem? >> That will depend on what the problem is. >> You may be able to clean out some files for now, >> but you may well need to re-init a disk with /MAX='more' and $BACKUP/ >> NOINIT/IMAGE ... > > In the next few days, I am going to shut down each of my nodes, pull one > of the members of the system-disk shadow set (so I have a backup I can > quickly revert to), do an ANA/DISK/REPAIR (and, while I am at it, > install some patches if necessary) then, when everything looks OK, add > the backup member back to the shadow set. A similar procedure for > non--system-disk shadow sets. > > If necessary, when the shadow set above has just one member, I could > privately mount the other (backup) member, do a backup to another disk > after having initialised it properly, then reboot from this third disk. > However, I'm not sure that there is really a problem. > > Maybe it will go away after I do an ANA/DISK/REPAIR? > Probably not. An IMAGE backup and restore should straighten things out for a while. The underlying problem is almost certainly due to applications creating files with too little space and extending them a small amount at a time. The fix, as I mentioned earlier, is to get your applications to use reasonable initial allocations and reasonable extent sizes. If an application writes a file that is never smaller than X blocks, it should allocate X blocks initially! Most well behaved applications do exactly that. Stuff written without consideration for the likely amount of output or applications borrowed from Unix will probably need some work! ------------------------------ Date: 28 Nov 2008 22:06:40 GMT From: "Bob Eager" Subject: Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Message-ID: <176uZD2KcidF-pn2-ddnUvNuNBcqU@rikki.tavi.co.uk> On Fri, 28 Nov 2008 21:06:45 UTC, AEF wrote: > On Nov 28, 3:27 pm, JF Mezei wrote: > > Phillip Helbig---remove CLOTHES to reply wrote: > > > > > %SYSTEM-W-HEADERFULL, file header is full > > > > > how can I create it manually if AUTOGEN can't? > > > > defragment the disk and then try to create it again. With a fragmented > > disk, creating a very large fil will require that it scavenge free disk > > space from all over the disk and thus cannot build a file with a single > > contiguous area of disk. > > This should help, but I don't think you can defragment INDEXF.SYS > itself while the disk is mounted. (I assume you're talking on-line > defragging.) Still, defragmenting enough files may solve the problem > for now. If you have the downtime, the best thing to do is "repack" > the disk (offline defragging). > > > > > Each time it uses one area of disk, it takes one header, and for a large > > file it may use up enough separate areas of the disk that the space for > > headers for a single file becomes full. > > This is not true. Each file header can hold the mappings for many > extents. When you get so many extents that it fills up the file > header, an extension file header is created which is then referenced > by the first file header. And when that file header fills up, . . . Almost. The first file header references the second (via the file ID). The second references the third...etc. All back-reference to the first. So extension headers don't fill up the initial file header. The problem is that eventually all the file headers in INDEXF.SYS are used, and INDEXF.SYS has to be extended, usually with another extent. When the file header for INDEXF.SYS fills up (~55 extents as I recall), it needs to allocate an extension header. But INDEXF.SYS is full up... Solution is to delete files so that spare headers become available, but that's a temporary fix. INDEXF.SYS has to be defragmented, and so (probably) does the rest of the disk. Easy, cheap but time consuming back is an image backup and restore. -- Bob Eager Use the BIG mirror service in the UK: http://www.mirrorservice.org ------------------------------ Date: Fri, 28 Nov 2008 22:07:08 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: > Running AUTOGEN on a DEC 3000/600 with VMS 7.3-2 results in the > following error: > > %AUTOGEN-I-BEGIN, GENFILES phase is beginning. > %SYSTEM-W-HEADERFULL, file header is full > > ** WARNING ** - Error creating SYS$SYSROOT:[SYSEXE]SYSDUMP.DMP. > > ** ERROR ** - error creating SYSDUMP.DMP. SYSDUMP.DMP needs > to be created manually with 393258 blocks > > $ dir SYS$SYSROOT:[SYSEXE]SYSDUMP.DMP > > Directory SYS$SYSROOT:[SYSEXE] > > SYSDUMP.DMP;4 215910 > > Total of 1 file, 215910 blocks. > > $ sh dev disk$alphasys_3 > > Device Device Error Volume Free Trans Mnt > Name Status Count Label Blocks Count Cnt > DSA133: Mounted 0 ALPHASYS_3 1910871 1 3 > $33$DKB100: (GLADIA) ShadowSetMember 0 (member of DSA133:) > $33$DKB600: (GLADIA) ShadowSetMember 0 (member of DSA133:) > > Question: since the error is > > %SYSTEM-W-HEADERFULL, file header is full > > how can I create it manually if AUTOGEN can't? > > When initialising disks, I'm always rather liberal with the /HEADERS > qualifier, so I don't think that's the problem. > > How can I solve this problem? > What does "$dump/head/count=block=0/form indexf.sys" says on that disk ? Check "Map area->Retrieval pointers" like in this case : Map area Retrieval pointers Count: 138 LBN: 0 Count: 69 LBN: 966 Count: 69 LBN: 35882622 Count: 38640 LBN: 35843982 I think the max number of pointers is something around 100. We had a lot of this on the old mVAX systems that was used as Pathworks server disks (a lot of small files). You have to re-INIT using the switch that sizes the indexf.sys file (/headers=nnnn). Also not that all fragmentet files uses up mor indexf.sys space. And files using a lot of ACE (as when running Pathworks) can use multiple headers from indexf.sys. But first, check the number of "Retrieval pointers" in indexf.sys ! Jan-Erik. ------------------------------ Date: Fri, 28 Nov 2008 17:07:08 -0500 From: "Richard B. Gilbert" Subject: Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Message-ID: <3KidnWoYMo6M8a3UnZ2dnUVZ_rLinZ2d@giganews.com> JF Mezei wrote: > Richard B. Gilbert wrote: > >> I don't recall if it's required or not but as a practical matter, yes, >> the dump file must be contiguous. > > Isn't the dumpfile written by the firmware instead of the OS ? If it is > written by th firmware, would the firmware be aware of ODS file > structures and extents ? Or would it just have the ability to find the > starting block for the dumpfile (like it does for the boot file) and > then dump the content of memory block by block sequentially ? I no longer recall the details! Sorry about that. ------------------------------ Date: 28 Nov 2008 17:13:48 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Message-ID: <3ynenEP63tPk@eisner.encompasserve.org> In article , helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes: > Running AUTOGEN on a DEC 3000/600 with VMS 7.3-2 results in the > following error: > > %AUTOGEN-I-BEGIN, GENFILES phase is beginning. > %SYSTEM-W-HEADERFULL, file header is full You need to defrag the file before it can be further extended. You will not be able to do this while VMS is using it. You may have to defrag the disk. Try renaming it, then running autogen. VMS will keep using the old one even though you renamed it. Authogen will try to make a whole new file, which may work if your disk is not too fragmented. Then reboot and delete the old file. If that doesn't work, there's a single file defragger I put on the freedware site several years ago. And if that doesn't work I'd just use backup/image to save and restore the system disk. ------------------------------ Date: 28 Nov 2008 17:15:09 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Message-ID: In article <001c443b$0$12281$c3e8da3@news.astraweb.com>, JF Mezei writes: > Richard B. Gilbert wrote: > > > Isn't the dumpfile written by the firmware instead of the OS ? If it is > written by th firmware, would the firmware be aware of ODS file > structures and extents ? Or would it just have the ability to find the > starting block for the dumpfile (like it does for the boot file) and > then dump the content of memory block by block sequentially ? The dump file is written by the OS. It must be at least contiguous-best-try. ------------------------------ Date: Fri, 28 Nov 2008 15:32:30 -0800 (PST) From: AEF Subject: Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Message-ID: <699ae598-0afa-4a5e-b344-d4fe9806acdb@k36g2000yqe.googlegroups.com> On Nov 28, 4:12=A0pm, JF Mezei wrote: > AEF wrote: > > This is not true. Each file header can hold the mappings for many > > extents. > > Isn't there a limit on how many extents a file can have and trying to > create an additional extent then fails ? What is the error message Not for most files. For INDEXF.SYS there certainly is! > generated at that time ? I remember circa 5.5-2 on VAX a user having so HEADERFULL > many mail messages in her mail directory that reception of new messages > created s similar message (since the .dir file could not be extended > anymore). Directories MUST be contiguous; there are no exceptions. MAIL files can become corrupted, esp. if they becoming ridiculously large. AEF ------------------------------ Date: Fri, 28 Nov 2008 23:47:30 +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 , "Richard B. Gilbert" writes: > > Maybe it will go away after I do an ANA/DISK/REPAIR? > > Probably not. An IMAGE backup and restore should straighten things out > for a while. The underlying problem is almost certainly due to > applications creating files with too little space and extending them a > small amount at a time. The fix, as I mentioned earlier, is to get your > applications to use reasonable initial allocations and reasonable extent > sizes. If an application writes a file that is never smaller than X > blocks, it should allocate X blocks initially! > > Most well behaved applications do exactly that. Stuff written without > consideration for the likely amount of output or applications borrowed > from Unix will probably need some work! This is the system disk. There is nothing on it except official DEC stuff. No applications (third-party software is on DISK$SOFT) or user programs (they are on DISK$USER). All files for which one can define a logical name and move off the system disk are no longer there (SYSUAF etc). I'll try PURGE just in case, then try to create the file by hand (still not sure why this might work if AUTOGEN can't do it), try on online DEFRAG perhaps and then ANA/DISK/REPAIR to be sure then if all else fails an image backup. Probably the only write activity on the disk (apart from the occasional AUTOGEN) is TCPIP. It creates a lot of log files, especially for the TCPIP receiver. They are purged regularly (by the TCPIP software) and I rename those that are there every night so I don't hit ;32767. (It is not uncommon to get over a thousand such log files per day.) ------------------------------ Date: Fri, 28 Nov 2008 23:49:36 +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: > What does "$dump/head/count=block=0/form indexf.sys" > says on that disk ? That /COUNT is an unknown qualifier. ------------------------------ Date: Sat, 29 Nov 2008 00:04:49 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: > 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 ? So what does : "$ dump/head/block=count=0/format indexf.sys" have to say about "Retrieval pointers" ? ------------------------------ Date: Fri, 28 Nov 2008 19:47:29 -0500 From: JF Mezei Subject: Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Message-ID: <00226975$0$9171$c3e8da3@news.astraweb.com> If you already have a dump file, you might wish to disable the dumpfile via SYSGEN, reboot. Then you can delete the dumpfile and attempt to create a new one with the size suggested by autogen, and if it works, you can then reset the sysgen parameter and reboot. The idea being that once you have deleted the existing dumpfile, it will free up more or less contiguous space that can be used when you create the new one. Also do a dir/nohead/size=all/select=size=min=15000 on the whole disk to spot any overly large file you could delete (old log files for instance). ------------------------------ Date: Fri, 28 Nov 2008 16:59:42 -0800 (PST) From: AEF Subject: Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Message-ID: <396d7d7f-7f42-4fec-936e-490192de404f@t11g2000yqg.googlegroups.com> On Nov 28, 5:06 pm, "Bob Eager" wrote: > On Fri, 28 Nov 2008 21:06:45 UTC, AEF wrote: > > On Nov 28, 3:27 pm, JF Mezei wrote: > > > Phillip Helbig---remove CLOTHES to reply wrote: > > > > > %SYSTEM-W-HEADERFULL, file header is full > > > > > how can I create it manually if AUTOGEN can't? > > > > defragment the disk and then try to create it again. With a fragmented > > > disk, creating a very large fil will require that it scavenge free disk > > > space from all over the disk and thus cannot build a file with a single > > > contiguous area of disk. > > > This should help, but I don't think you can defragment INDEXF.SYS > > itself while the disk is mounted. (I assume you're talking on-line > > defragging.) Still, defragmenting enough files may solve the problem > > for now. If you have the downtime, the best thing to do is "repack" > > the disk (offline defragging). > > > > Each time it uses one area of disk, it takes one header, and for a large > > > file it may use up enough separate areas of the disk that the space for > > > headers for a single file becomes full. > > > This is not true. Each file header can hold the mappings for many > > extents. When you get so many extents that it fills up the file > > header, an extension file header is created which is then referenced > > by the first file header. And when that file header fills up, . . . > > Almost. The first file header references the second (via the file ID). > The second references the third...etc. All back-reference to the first. > So extension headers don't fill up the initial file header. That's what I meant. I thought the ellipsis would be enough but I guess not; I should have gone one or two more iterations. Yes, you are absolutely right: Each new extension header is referenced by the previous header, be it the original file header or the previously last extension header. > > The problem is that eventually all the file headers in INDEXF.SYS are > used, and INDEXF.SYS has to be extended, usually with another extent. > When the file header for INDEXF.SYS fills up (~55 extents as I recall), > it needs to allocate an extension header. But INDEXF.SYS is full up... > > Solution is to delete files so that spare headers become available, but > that's a temporary fix. INDEXF.SYS has to be defragmented, and so > (probably) does the rest of the disk. Easy, cheap but time consuming > back is an image backup and restore. I think just defragging INDEXF.SYS would be sufficient in most normal circumstances. I'm really surprised that anyone actually still gets the dreaded HEADERFUL problem anymore as the extension algorithm has improved considerably. Back before approx. V5.x or so, the extension algorithm was to simply extend INDEXF.SYS by 1000 blocks. After approx. 50 or so extensions, you're done for. The new algorithm (from ECO kit VAXF11X01_U2055) is much better. > > -- > Bob Eager > Use the BIG mirror service in the UK:http://www.mirrorservice.org AEF ------------------------------ Date: Fri, 28 Nov 2008 17:09:38 -0800 (PST) From: AEF Subject: Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Message-ID: On Nov 28, 4:29=A0pm, "Richard B. Gilbert" wrote: > Phillip Helbig---remove CLOTHES to reply wrote: > > > > > Running AUTOGEN on a DEC 3000/600 with VMS 7.3-2 results in the > > following error: > > > %AUTOGEN-I-BEGIN, GENFILES phase is beginning. > > %SYSTEM-W-HEADERFULL, file header is full > > > =A0 =A0 =A0 =A0 ** WARNING ** - Error creating SYS$SYSROOT:[SYSEXE]SYSD= UMP.DMP. > > > =A0 =A0 =A0 =A0 ** ERROR ** - error creating SYSDUMP.DMP. =A0SYSDUMP.DM= P needs > > =A0 =A0 =A0 =A0 =A0 =A0to be created manually with 393258 blocks > > > $ dir SYS$SYSROOT:[SYSEXE]SYSDUMP.DMP > > > Directory SYS$SYSROOT:[SYSEXE] > > > SYSDUMP.DMP;4 =A0 =A0 =A0 =A0 215910 > > > Total of 1 file, 215910 blocks. > > > $ sh dev disk$alphasys_3 > > > Device =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Device =A0 =A0 =A0 =A0 =A0 Er= ror =A0 =A0Volume =A0 =A0 =A0 =A0 Free =A0Trans Mnt > > =A0Name =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Status =A0 =A0 =A0 =A0 =A0 = Count =A0 =A0 Label =A0 =A0 =A0 =A0Blocks Count Cnt > > DSA133: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Mounted =A0 =A0 =A0 =A0 =A0 =A0= =A00 =A0ALPHASYS_3 =A0 =A0 1910871 =A0 =A0 1 =A0 3 > > $33$DKB100: =A0 (GLADIA) =A0ShadowSetMember =A0 =A0 =A00 =A0(member of = DSA133:) > > $33$DKB600: =A0 (GLADIA) =A0ShadowSetMember =A0 =A0 =A00 =A0(member of = DSA133:) > > > Question: since the error is > > > =A0 =A0%SYSTEM-W-HEADERFULL, file header is full > > > how can I create it manually if AUTOGEN can't? > > > When initialising disks, I'm always rather liberal with the /HEADERS > > qualifier, so I don't think that's the problem. > > > How can I solve this problem? > > Try a BACKUP /IMAGE and restore. =A0You might have to re-init the disk. > > Digging into the statistics a little: number of files, number of extents > per file, etc, might be revealing! =A0IIRC each file header supports a > fairly limited number of extents, if you need more extents, you need a > second file heard and sometimes a third, fourth. . . . 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've always tried to keep my files contiguous. =A0Some users, or some > processes, tend =A0to create two block files and extend them two blocks a= t > a time. =A0In my working days, I tried very hard to stomp on such when > found! =A0 Yikes! Programs were written to get a reasonable allocation in the > first place and to get a reasonably sized extent if one was needed. > > I learned this the hard way when my poor old VAX 11/750 ground almost to > a halt due to disk file fragmentation! =A0I spent most of a weekend doing > an image backup and restore of an RA81 to/from a 1600 BPI tape. =A0It mad= e > a huge difference in performance. AEF ------------------------------ Date: Fri, 28 Nov 2008 18:56:39 -0800 (PST) From: AEF Subject: Re: AUTOGEN reports: %SYSTEM-W-HEADERFULL, file header is full Message-ID: <77742553-0a13-448e-96bf-e2567782e843@k12g2000yqk.googlegroups.com> On Nov 28, 6:13=A0pm, koeh...@eisner.nospam.encompasserve.org (Bob Koehler) wrote: > In article , hel...@astro.multiCLOTHESvax.de (Phi= llip Helbig---remove CLOTHES to reply) writes: > > > Running AUTOGEN on a DEC 3000/600 with VMS 7.3-2 results in the > > following error: > > > %AUTOGEN-I-BEGIN, GENFILES phase is beginning. > > %SYSTEM-W-HEADERFULL, file header is full > > =A0 =A0You need to defrag the file before it can be further extended. > =A0 =A0You will not be able to do this while VMS is using it. > > =A0 =A0You may have to defrag the disk. > > =A0 =A0Try renaming it, then running autogen. =A0VMS will keep using the = old > =A0 =A0one even though you renamed it. =A0Authogen will try to make a who= le > =A0 =A0new file, which may work if your disk is not too fragmented. =A0Th= en > =A0 =A0reboot and delete the old file. > > =A0 =A0If that doesn't work, there's a single file defragger I put on the > =A0 =A0freedware site several years ago. =A0And if that doesn't work I'd > =A0 =A0just use backup/image to save and restore the system disk. Of course! This has nothing to do with INDEXF.SYS. Usually it does, but since the dump file can only have one file header (which I didn't know before, but it's not really surprising nonetheless), Bob is spot on. Never mind all the other stuff about INDEXF.SYS. Interestingly (or not), HELP/MESS HEADERFULL seems to be only about INDEXF.SYS. Are there any other files that are limited to having only one file header? I quick search found something about pagefiles, but are there any others? I know directory files have to be contiguous. Any others? Is this stuff documented anywhere? (I'm not doubting what's been posted here; I'd just like to know and check it out.) Thanks! AEF ------------------------------ Date: Fri, 28 Nov 2008 12:18:57 -0700 From: Glen Herrmannsfeldt Subject: Re: Black and White Printing Message-ID: Bfraga wrote: (snip) > The printer is a HP business inkjet 2280dn, and we use postscript to > print the files. Is there a command in postscript to set it to b&w? I believe there are operators to set colors or color printing modes. If you removed those from the print stream, color printing would fail. For some PS printers, you can redefine the appropriate operators at the beginning of the job and then let it go through. A reset at the end will remove those definitions. Then you redefine def such that the user can't undo the new definitions. -- glen ------------------------------ Date: Fri, 28 Nov 2008 14:47:41 -0500 From: JF Mezei Subject: Re: Black and White Printing Message-ID: <001c2810$0$12301$c3e8da3@news.astraweb.com> To the original poster: Can you describe under what circumstances the postscript files sent from VMS to the printer would contain colour printing postscript code ? Or is it a case of jobs being submitted from PCs/Macs via LPD to the VMS system and then printed to the printer ? In other words, would it be simpler to get whatever application which generates the potscript to generate it in black/white ? If not, then you can use setup and reset modules (stored in a text library such as the DCPS$DEVCTL.TLB in SYS$LIBRARY which would set the printer in black/white mode. Redefining "setcolor" to "setgray" is not enough since the arguments don't match. Also, it would not affect bitmap imaging. You can try to insert DeviceGray setcolorspace in the postcript (via a /SETUP module). You might also need to redefine setcolorspace to be an inop command that just pops the arguments given to it (you would need code in there to pop args individually because setcolorspace has variable number of arguments. If you have complete documentation on the printer, you may also find that it may have some printer specific (in the setpagedevice dictionary) variables that force the printer to go to grayscale mode which would be the foolproof method since the printer itself would convert colours to b/w and there would be no need to redefine any poscript operators. ------------------------------ Date: 28 Nov 2008 17:03:35 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Black and White Printing Message-ID: In article <8a3c6139-7a84-43ff-8512-2e5e69f4f731@o2g2000yqd.googlegroups.com>, Bfraga writes: > Hello, > > I have several alphaservers running OpenVMS. To print we use the > command PRINT/QUEUE filename to send the file to the printer queue and > print it. > I want to know if there is a way to print only black and white, to > reduce the printing cost. 1) buy a black and white printer 2) fire everyone who sends color printouts to the color printer 3) write your own filters for every type of thing your printers understand and embed them in your own printer symbionts ------------------------------ Date: Fri, 28 Nov 2008 15:58:17 -0800 (PST) From: dooleys@snowy.net.au Subject: Re: Black and White Printing Message-ID: <6b04d21c-bbce-4aa5-8454-2c97c734b477@r15g2000prd.googlegroups.com> On Nov 29, 3:10=A0am, Bfraga wrote: > On Nov 28, 1:46=A0pm, VAXman- =A0@SendSpamHere.ORG wrote: > > > > > > > In article , Bfraga writes: > > > >On 28 nov, 12:17, Mike Rechtman wrote: > > >> Bfraga wrote: > > >> > Hello, > > > >> > I have several alphaservers running OpenVMS. To print we use the > > >> > command PRINT/QUEUE filename to send the file to the printer queue= and > > >> > print it. > > >> > I want to know if there is a way to print only black and white, to > > >> > reduce the printing cost. > > > >> > Thank > > > >> Probably easiest to change printer setup. (can be done per-job) > > >> If hou can find the escape sequence that switches the printers int b= &w > > >> only, you could create a module containing those in DEVCTL.TLB, and > > >> create a form with that module in /SETUP. > > >> Start at $HELP DEF /FORM =3DA0and continue to "Batch and Print" in S= YSMAN > > >> documentation. > > > >> -- > > >> Mike R.http://alpha.mike-r.com/ > > > >> -- > > > >I can't set the printer to b&w because it's shared with other systems. > > >There is a command to do this in the queue creation? Or in the print > > >command? > > > It didn't occur to you to tell us what TYPE (brand, model,etc.) of prin= ter > > you have associated with the queue in question? > > > If it's postscript, it might be possible to define the set{}color to be= a > > setgray command. =A0Or, there might be control commands that would set = the > > printer to B&W mode for your job. =A0Of course, this is just wasting ba= nd- > > width without some knowledge of the printer. > > > -- > > VAXman- A Bored Certified VMS Kernel Mode Hacker =A0 =A0 =A0VAXman(at)T= MESIS(dot)COM > > > ... pejorative statements of opinion are entitled to constitutional pro= tection > > no matter how extreme, vituperous, or vigorously expressed they may be.= (NJSC) > > > Copr. 2008 Brian Schenkenberger. =A0Publication of _this_ usenet articl= e outside > > of usenet _must_ include its contents in its entirety including this co= pyright > > notice, disclaimer and quotations.- Hide quoted text - > > > - Show quoted text - > > The printer is a HP business inkjet 2280dn, and we use postscript to > print the files. Is there a command in postscript to set it to b&w?- Hide= quoted text - > > - Show quoted text - You could use ghostscript to convert your ps files before printing. If you tell gs that its printer is a model that only supports b&w then it will create postscript with no colour. This is defined in PPD files that ghostscript uses. Phil ------------------------------ Date: Sat, 29 Nov 2008 00:19:07 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: Black and White Printing Message-ID: <00A83516.A5D858CF@SendSpamHere.ORG> In article <6b04d21c-bbce-4aa5-8454-2c97c734b477@r15g2000prd.googlegroups.com>, dooleys@snowy.net.au writes: >On Nov 29, 3:10=A0am, Bfraga wrote: >> On Nov 28, 1:46=A0pm, VAXman- =A0@SendSpamHere.ORG wrote: >> >> >> >> >> >> > In article ps.com>, Bfraga writes: >> >> > >On 28 nov, 12:17, Mike Rechtman wrote: >> > >> Bfraga wrote: >> > >> > Hello, >> >> > >> > I have several alphaservers running OpenVMS. To print we use the >> > >> > command PRINT/QUEUE filename to send the file to the printer queue= > and >> > >> > print it. >> > >> > I want to know if there is a way to print only black and white, to >> > >> > reduce the printing cost. >> >> > >> > Thank >> >> > >> Probably easiest to change printer setup. (can be done per-job) >> > >> If hou can find the escape sequence that switches the printers int b= >&w >> > >> only, you could create a module containing those in DEVCTL.TLB, and >> > >> create a form with that module in /SETUP. >> > >> Start at $HELP DEF /FORM =3DA0and continue to "Batch and Print" in S= >YSMAN >> > >> documentation. >> >> > >> -- >> > >> Mike R.http://alpha.mike-r.com/ >> >> > >> -- >> >> > >I can't set the printer to b&w because it's shared with other systems. >> > >There is a command to do this in the queue creation? Or in the print >> > >command? >> >> > It didn't occur to you to tell us what TYPE (brand, model,etc.) of prin= >ter >> > you have associated with the queue in question? >> >> > If it's postscript, it might be possible to define the set{}color to be= > a >> > setgray command. =A0Or, there might be control commands that would set = >the >> > printer to B&W mode for your job. =A0Of course, this is just wasting ba= >nd- >> > width without some knowledge of the printer. >> >> > -- >> > VAXman- A Bored Certified VMS Kernel Mode Hacker =A0 =A0 =A0VAXman(at)T= >MESIS(dot)COM >> >> > ... pejorative statements of opinion are entitled to constitutional pro= >tection >> > no matter how extreme, vituperous, or vigorously expressed they may be.= > (NJSC) >> >> > Copr. 2008 Brian Schenkenberger. =A0Publication of _this_ usenet articl= >e outside >> > of usenet _must_ include its contents in its entirety including this co= >pyright >> > notice, disclaimer and quotations.- Hide quoted text - >> >> > - Show quoted text - >> >> The printer is a HP business inkjet 2280dn, and we use postscript to >> print the files. Is there a command in postscript to set it to b&w?- Hide= > quoted text - >> >> - Show quoted text - >You could use ghostscript to convert your ps files before printing. >If you tell gs that its printer is a model that only supports b&w >then it will create postscript with no colour. >This is defined in PPD files that ghostscript uses. ...or modify currentpagedevice characteristics and setpagedevice. ...or redefine setrgbcolor/sethsbcolor/setcmykcolor to be setgray. It's postscript! -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM ... pejorative statements of opinion are entitled to constitutional protection no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC) Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside of usenet _must_ include its contents in its entirety including this copyright notice, disclaimer and quotations. ------------------------------ Date: Fri, 28 Nov 2008 18:48:25 -0800 (PST) From: dooleys@snowy.net.au Subject: Re: Black and White Printing Message-ID: <4418c78d-28da-4f9f-89b7-8a627f950526@w1g2000prk.googlegroups.com> On Nov 29, 3:10=A0am, Bfraga wrote: > On Nov 28, 1:46=A0pm, VAXman- =A0@SendSpamHere.ORG wrote: > > > > > > > In article , Bfraga writes: > > > >On 28 nov, 12:17, Mike Rechtman wrote: > > >> Bfraga wrote: > > >> > Hello, > > > >> > I have several alphaservers running OpenVMS. To print we use the > > >> > command PRINT/QUEUE filename to send the file to the printer queue= and > > >> > print it. > > >> > I want to know if there is a way to print only black and white, to > > >> > reduce the printing cost. > > > >> > Thank > > > >> Probably easiest to change printer setup. (can be done per-job) > > >> If hou can find the escape sequence that switches the printers int b= &w > > >> only, you could create a module containing those in DEVCTL.TLB, and > > >> create a form with that module in /SETUP. > > >> Start at $HELP DEF /FORM =3DA0and continue to "Batch and Print" in S= YSMAN > > >> documentation. > > > >> -- > > >> Mike R.http://alpha.mike-r.com/ > > > >> -- > > > >I can't set the printer to b&w because it's shared with other systems. > > >There is a command to do this in the queue creation? Or in the print > > >command? > > > It didn't occur to you to tell us what TYPE (brand, model,etc.) of prin= ter > > you have associated with the queue in question? > > > If it's postscript, it might be possible to define the set{}color to be= a > > setgray command. =A0Or, there might be control commands that would set = the > > printer to B&W mode for your job. =A0Of course, this is just wasting ba= nd- > > width without some knowledge of the printer. > > > -- > > VAXman- A Bored Certified VMS Kernel Mode Hacker =A0 =A0 =A0VAXman(at)T= MESIS(dot)COM > > > ... pejorative statements of opinion are entitled to constitutional pro= tection > > no matter how extreme, vituperous, or vigorously expressed they may be.= (NJSC) > > > Copr. 2008 Brian Schenkenberger. =A0Publication of _this_ usenet articl= e outside > > of usenet _must_ include its contents in its entirety including this co= pyright > > notice, disclaimer and quotations.- Hide quoted text - > > > - Show quoted text - > > The printer is a HP business inkjet 2280dn, and we use postscript to > print the files. Is there a command in postscript to set it to b&w?- Hide= quoted text - > > - Show quoted text - 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. The printer definitions are in PPD files. Phil it so that ------------------------------ Date: Fri, 28 Nov 2008 14:13:10 -0500 From: JF Mezei Subject: Date centre design Message-ID: <00221b1a$0$9201$c3e8da3@news.astraweb.com> If you foresee the need to redesign your data centre in the near future, you may wish to look at the following: http://royal.pingdom.com/2008/11/14/the-worlds-most-super-designed-data-center-fit-for-a-james-bond-villain/ The architect's web page: http://www.archdaily.com/9257/pionen-%E2%80%93-white-mountain-albert-france-lanord-architects/\ The actual data centre (colocation business) http://www.bahnhof.se/colocation.php (swedish only). ------------------------------ Date: Fri, 28 Nov 2008 14:44:31 -0500 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: forwarding email to a distribution list Message-ID: <49304a13$0$90266$14726298@news.sunsite.dk> Phillip Helbig---remove CLOTHES to reply wrote: > In article <492f52d6$0$90270$14726298@news.sunsite.dk>, > =?ISO-8859-1?Q?Arne_Vajh=F8j?= writes: >> Phillip Helbig---remove CLOTHES to reply wrote: >>> What am I doing wrong? From a priviledged account: >>> >>> MAIL> set forward/user=test-user @TEST.DIS >>> >>> didn't work. (TEST.DIS is located in TCPIP$SMTP_COMMON or, rather, in >>> the second directory in the search list which is my definition of this >>> logical (and works fine for other things which use TCPIP$SMTP_COMMON, >>> such as SMTP.CONFIG).) Specifying the path explicitly (i.e. the second >>> directory in the search list) didn't work either. >>> >>> What am I missing? >> If my memory is correct (but I was wrong last time I tried >> to remember back in time), then this was explicit forbidden >> by MAIL and is the reason why DELIVER was invented. > > As pointed out later in the thread, it does work. What post was that ? Arne ------------------------------ Date: Fri, 28 Nov 2008 20:00:48 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: forwarding email to a distribution list Message-ID: In article <49304a13$0$90266$14726298@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= writes: > Phillip Helbig---remove CLOTHES to reply wrote: > > In article <492f52d6$0$90270$14726298@news.sunsite.dk>, > > =?ISO-8859-1?Q?Arne_Vajh=F8j?= writes: > >> Phillip Helbig---remove CLOTHES to reply wrote: > >>> What am I doing wrong? From a priviledged account: > >>> > >>> MAIL> set forward/user=test-user @TEST.DIS > >>> > >>> didn't work. (TEST.DIS is located in TCPIP$SMTP_COMMON or, rather, in > >>> the second directory in the search list which is my definition of this > >>> logical (and works fine for other things which use TCPIP$SMTP_COMMON, > >>> such as SMTP.CONFIG).) Specifying the path explicitly (i.e. the second > >>> directory in the search list) didn't work either. > >>> > >>> What am I missing? > >> If my memory is correct (but I was wrong last time I tried > >> to remember back in time), then this was explicit forbidden > >> by MAIL and is the reason why DELIVER was invented. > > > > As pointed out later in the thread, it does work. > > What post was that ? http://groups.google.de/group/comp.os.vms/msg/c4b3f6eba7d0f3a6?hl=de&dmode=source ------------------------------ Date: Fri, 28 Nov 2008 15:45:02 -0500 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: forwarding email to a distribution list Message-ID: <49305842$0$90271$14726298@news.sunsite.dk> Phillip Helbig---remove CLOTHES to reply wrote: > In article <49304a13$0$90266$14726298@news.sunsite.dk>, > =?ISO-8859-1?Q?Arne_Vajh=F8j?= writes: >> Phillip Helbig---remove CLOTHES to reply wrote: >>> In article <492f52d6$0$90270$14726298@news.sunsite.dk>, >>> =?ISO-8859-1?Q?Arne_Vajh=F8j?= writes: >>>> Phillip Helbig---remove CLOTHES to reply wrote: >>>>> What am I doing wrong? From a priviledged account: >>>>> >>>>> MAIL> set forward/user=test-user @TEST.DIS >>>>> >>>>> didn't work. (TEST.DIS is located in TCPIP$SMTP_COMMON or, rather, in >>>>> the second directory in the search list which is my definition of this >>>>> logical (and works fine for other things which use TCPIP$SMTP_COMMON, >>>>> such as SMTP.CONFIG).) Specifying the path explicitly (i.e. the second >>>>> directory in the search list) didn't work either. >>>>> >>>>> What am I missing? >>>> If my memory is correct (but I was wrong last time I tried >>>> to remember back in time), then this was explicit forbidden >>>> by MAIL and is the reason why DELIVER was invented. >>> As pointed out later in the thread, it does work. >> What post was that ? > > http://groups.google.de/group/comp.os.vms/msg/c4b3f6eba7d0f3a6?hl=de&dmode=source I saw that post. It does not set forward to a distribution list. It does the same that DELIVER does. It set forward to an address that gets handled by an external mail transport that takes action based on the file. It is probably nicer than DELIVER, because all systems with DEC/DIgital/Compaq/HP TCP/IP will have it. Arne ------------------------------ Date: Fri, 28 Nov 2008 11:10:50 -0800 (PST) From: yyyc186 Subject: Re: Good example of C and MACRO Message-ID: On Nov 26, 1:38=A0pm, Mark Wickens wrote: > Jan-Erik S=F6derholm wrote: > > =A0On Nov 26, 4:39 pm, Mark Wickens wrote: > >> Hi, > > >> Could anyone suggest a program with a decent amount of C and MACRO cod= e? > >> =A0I'm also after suggestions as to what library I should use to write= a > >> character-terminal screen based application in C/MACRO. > > >> Thanks for the help, > > >> Mark. > > > I can't help to ask, why ? > > Why write an "application" (whatever that is) in MACRO ? > > > And, as have said, a lot of the VMS freeware tools are > > probably written in MACRO and/or C. > > Thanks for the replies - yes asking 'why' is a good question. > > This is purely an academic exercise - I am doing my 'learn one language > a year' and this year it is MACRO-32. I have done more than my fair > share of C programming, but I'm now entrenched in the Java/Web > programming arena. As programming for the internet is my day job I > wanted a suitably different scenario to 'play' with. > > To be honest I'm pretty sick of web programming. It would be hard to > think of a more clunky way of providing a minimal level of user > interaction. I've investigated a number of options, the most pure of > which appears to be google web toolkit (pure-java based solution that > autogenerates the required client side javascript) but they're all > horrible - either everything happens in one window (so page > navigation/bookmarking doesn't work) or every interaction must fit into > the web 'page-at-a-time' cycle. Bolt on functionality that would be > integral to any decent application development environment has to be > performed using highly browser-dependent javascript (don't even get me > started with that!) > > I've done Java Swing programming before which is where the 'application' > part of the requirement comes into it. More flexible interaction is > great and entirely possible, but at the cost of increased complexity. > > I'd welcome anyones experience of application development using other > tools and languages. I find that most of the people I work with now have > a very narrowly-focused mindset based exclusively around web development. > > I looked at character-based application toolkits, and just decided that > as I have no 'run-everywhere' requirement I would concentrate on > developing for a platform and toolset which is stable and reliable - > OpenVMS. In that sense I would like to broker people's opinions on the > 'nicest' screen-oriented library available for the platform. I've come > across ncurses before and wondered if any of the VMS-specific libraries > offer a more pleasant development experience. > > Kind regards, > > Mark. Pleasant development would be FMS. There are lots of examples on how to use it. If you are looking for something "interesting" to do, why don't you look into porting the opensource Qt library to OpenVMS? All of the source code is out there. If that is a bit much, you could look into reserecting the OpenVMS code in Postgresql. Yes, it originally ran on VAX/VMS. ------------------------------ Date: Fri, 28 Nov 2008 11:14:04 -0800 (PST) From: yyyc186 Subject: Re: Good example of C and MACRO Message-ID: <02389b20-dae8-4909-a600-8a251b4dc2cf@j32g2000yqn.googlegroups.com> On Nov 26, 5:38=A0pm, "Tim E. Sneddon" wrote: > John Reagan wrote: > > "Mark Wickens" wrote in message > >news:ggk8j0$gpo$1@news.motzarella.org... > >> This is purely an academic exercise - I am doing my 'learn one languag= e > >> a year' and this year it is MACRO-32. > > > Not to discourage you, but honestly why learn the instruction set of a > > computer from the 1970's which isn't even made anymore? > > > At least do X86 or Itanium assembly if you must satisify some urge to > > twiddle bits. > > Anyone who *willingly* chooses Itanium assembly to write anything > should immediately get themselves to a doctor! > > Tim. Anyone who *willingly* chooses an Itanium boat anchor should get themselves to a doctor. ------------------------------ Date: Fri, 28 Nov 2008 16:23:33 -0500 From: "John Reagan" Subject: Re: Good example of C and MACRO Message-ID: "JF Mezei" wrote in message news:0019f8d3$0$12352$c3e8da3@news.astraweb.com... > Richard B. Gilbert wrote: > >> There is little reason to write anything in Macro today; device drivers >> can be written in C. What else was Macro good for? > > > Making transfer vectors for sharable images ? Are there now tools to > make those without Macro ? You haven't need Macro to create transfer vectors since VAX. Replaced with SYMBOL_VECTOR in the LINKER options file on Alpha and I64. John ------------------------------ Date: Fri, 28 Nov 2008 16:25:59 -0500 From: "John Reagan" Subject: Re: Good example of C and MACRO Message-ID: "Jur van der Burg" <"lddriver at digiater dot nl"> wrote in message news:492e8d19$0$197$e4fe514c@news.xs4all.nl... > > Anyone who *willingly* chooses Itanium assembly to write anything > > should immediately get themselves to a doctor! > > Well, then it's time for me to see a doctor.... and soon! > > I'm working on an application generating native itanium code on > the fly (running on VMS), so I play for compiler myself. Lots of fun.... > :-) > Code on the fly? You are in for a whole bunch of fun. Besides figuring out template, stop-bits, computing bundle-relative offsets, you'll also have to create unwind descriptors (also on the fly) and register them with the appropriate system service. And you're doing this in elevated mode, there is more fun to make sure the unwind descriptors are unmapped at the right times. John ------------------------------ Date: Fri, 28 Nov 2008 16:29:06 -0500 From: "John Reagan" Subject: Re: Good example of C and MACRO Message-ID: "Michael Kraemer" wrote in message news:ggljto$85k$00$2@news.t-online.com... > Richard B. Gilbert schrieb: > >> >> Assembler language programming is just about dead. The only time it's >> really necessary is when you are bootstrapping a new hardware platform. >> Even device drivers are now written in C. > > Not every CPU instruction has an equivalent HL construct. > Think of byte swapping or "compare & swap" and friends. > > Our C compiler (and BLISS and Pascal) have builtins to let you access such atomic sequences. You don't need asm() and you don't need to write in assembler. On I64, the only place where assembler makes sense is where you are way outside the Calling Standard doing argument shuffling. VMS' exception handling comes to mind. John ------------------------------ Date: 28 Nov 2008 16:19:03 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Good example of C and MACRO Message-ID: In article <492dcf0f$0$90264$14726298@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= writes: > > C has macros. ROTFLOL. ------------------------------ Date: 28 Nov 2008 16:18:17 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Good example of C and MACRO Message-ID: In article , "John Reagan" writes: > > Not to discourage you, but honestly why learn the instruction set of a > computer from the 1970's which isn't even made anymore? > I've worked with a whole lot of assemblers over the years, and I'm glad I learned VAX first. The CISC instruction set of the VAX does what programmers want to do: artithmetic, string searches, and HLL calls. IA-32 is a good example of the other end. It's CISC insructions do what hardware engineers want to do: move data and jump. IMHO a lot of RISC instruction sets are easier to learn than all the hacks that went into making an 8 bit 8086 architecture 16 bit and then 32 bit. I'm going to teach my kids assembly, using a VAX. And I'll keep running my Macro-32 code on all my VMS machines. ------------------------------ Date: 28 Nov 2008 16:12:07 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Good example of C and MACRO Message-ID: <$1cAfMrdFE2Q@eisner.encompasserve.org> In article , Glen Herrmannsfeldt writes: > Mark Wickens wrote: > >> Could anyone suggest a program with a decent amount of C and MACRO code? >> I'm also after suggestions as to what library I should use to write a >> character-terminal screen based application in C/MACRO. > > My first thought was Kermit, but I believe that is mostly Bliss-32. > > The beginning of VMS was before C, or at least before C was > well known. > > Kermit is a character/terminal screen based application, though. While there is a version of kermit implemented in BLISS, the current and maintained version is in C. ------------------------------ Date: 28 Nov 2008 16:20:48 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Good example of C and MACRO Message-ID: 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. ------------------------------ Date: 28 Nov 2008 16:25:26 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Good example of C and MACRO Message-ID: In article , "Richard B. Gilbert" writes: > > But note that, given the proper software, you can compile VAX Macro to > produce Alpha object code. I wouldn't be surprised if this could also > be done on Itanic. I would be very surprised if all the Macro-32 came out of VMS by the time the port to Itanium was done. In any case the Macro-32 compiler for Itanium ships with VMS. Macro was good for making quick access to instructions like MOVC5 back before there were LIB$x routines for them. Also for writing device drivers on VAXen so that we could hang just about anything off our systems. And, of course, for user written system services to provide things VMS 2.x didn't. It was also good when I was trying to learn C quickly, because I could look at the listing to see what that totaly inconsistent syntax had actually meant. ------------------------------ Date: 28 Nov 2008 16:29:24 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Good example of C and MACRO Message-ID: In article , "Richard B. Gilbert" writes: > > Assembler language programming is just about dead. The only time it's > really necessary is when you are bootstrapping a new hardware platform. Which means people who can do it will be rare and demand higher salaries. While the masses slave on in Visual Basic. ------------------------------ Date: 28 Nov 2008 16:30:38 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Good example of C and MACRO Message-ID: Ever try to do dump analysis without knowing the instruction set? OS and embedded systems programmers do it all the time. ------------------------------ Date: 28 Nov 2008 16:32:25 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Good example of C and MACRO Message-ID: In article , m.kraemer@gsi.de (Michael Kraemer) writes: > > Assembly on 68K is almost like C. Hmm. In my experience it's more like C thinks like a PDP-11. ------------------------------ Date: 28 Nov 2008 16:34:42 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Good example of C and MACRO Message-ID: <2yMV4nij1wsO@eisner.encompasserve.org> In article , johnwallace4@yahoo.co.uk writes: > > It is an allegedly well known fact that much of C was inspired by > PDP11 assembly, opcodes, and addressing modes, and at first glance it > seems plausible. However, I'm not sure I believe it as (a) I think > I've read an interview (with Dennis Ritchie?, who may perhaps be > considered definitive) which claims there's no truth to it, though I > can't remember where I read it (b) you can subtract two bytes in C and > you can't (trivially) subtract bytes on a PDP11, even though most > other popular PDP11 instructions had byte variants where applicable. I think it's ideas like autoincrement and autodecrement that point out common thinking between C and PDP-11. That, and PDP-11 seemed to be quite popular at Bell Labs at about the time C was invented. ------------------------------ Date: Fri, 28 Nov 2008 17:33:09 -0500 From: "Richard B. Gilbert" Subject: Re: Good example of C and MACRO Message-ID: 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. 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. . . . ------------------------------ Date: 28 Nov 2008 16:39:02 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Good example of C and MACRO Message-ID: 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. 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). ------------------------------ Date: 28 Nov 2008 16:41:07 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Good example of C and MACRO Message-ID: 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? ------------------------------ Date: Fri, 28 Nov 2008 14:48:09 -0800 (PST) From: Neil Rieck Subject: Re: Good example of C and MACRO Message-ID: <08836ed6-870a-4b4b-81f7-bfa53c930a51@t2g2000yqm.googlegroups.com> On Nov 28, 1:12=A0pm, Arne Vajh=F8j wrote: > Neil Rieck wrote: > > Correct. Unless you are attending a college course titled "ancient > > programming tools from the CISC era", C is a much better choice. > > Sometimes "C" is even a better choice for CISC projects. > > CISC seems to be living very well. > > I don't think Intel and AMD are that scared by PPC, SPARC and IA-64. > > Arne 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 never think of the descendants of Pentium4 as pure RISC architectures. Neil ------------------------------ Date: Fri, 28 Nov 2008 17:53:14 -0500 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: Good example of C and MACRO Message-ID: <4930765c$0$90276$14726298@news.sunsite.dk> Neil Rieck wrote: > On Nov 28, 1:12 pm, Arne Vajhøj wrote: >> Neil Rieck wrote: >>> Correct. Unless you are attending a college course titled "ancient >>> programming tools from the CISC era", C is a much better choice. >>> Sometimes "C" is even a better choice for CISC projects. >> CISC seems to be living very well. >> >> I don't think Intel and AMD are that scared by PPC, SPARC and IA-64. > > 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 never > think of the descendants of Pentium4 as pure RISC architectures. Not even close. They are CISC. They were CISC 20 years ago and *adding* more complex instructions did not make them RISC by magic. Arne PS: I don't think I have ever seen Intel/AMD claim that x86 or x86-64 to be RISC. ------------------------------ Date: 28 Nov 2008 22:55:50 GMT From: "Bob Eager" Subject: Re: Good example of C and MACRO Message-ID: <176uZD2KcidF-pn2-7tZHnLP7ZNd1@rikki.tavi.co.uk> On Fri, 28 Nov 2008 22:39:02 UTC, koehler@eisner.nospam.encompasserve.org (Bob Koehler) wrote: > 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. > > 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). I tried to use MARK once when I was writing a compiler. I gave up in the end! -- Bob Eager Use the BIG mirror service in the UK: http://www.mirrorservice.org ------------------------------ Date: 28 Nov 2008 22:55:50 GMT From: "Bob Eager" Subject: Re: Good example of C and MACRO Message-ID: <176uZD2KcidF-pn2-MwrSYerRKT27@rikki.tavi.co.uk> On Fri, 28 Nov 2008 22:41:07 UTC, koehler@eisner.nospam.encompasserve.org (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? Not sure if this was rhetorical or not. But anyway...no autoincrement or autodecrement in BCPL. Memory was word addressable although a byte indexing operator (%) eventually appeared. It used a 'stack machine' and it was actually harder to use the PDP-11 stack than it was to use a separate one. I did do a compiler for the VAX later, and managed to use FP and SP (but not really AP). Don't know about B. -- Bob Eager Use the BIG mirror service in the UK: http://www.mirrorservice.org ------------------------------ Date: Fri, 28 Nov 2008 15:58:14 -0700 From: Glen Herrmannsfeldt Subject: Re: Good example of C and MACRO Message-ID: yyyc186 wrote: (snip) > Anyone who *willingly* chooses an Itanium boat anchor should get > themselves to a doctor. Have you priced boat anchors lately? -- glen ------------------------------ Date: Fri, 28 Nov 2008 16:00:25 -0700 From: Glen Herrmannsfeldt Subject: Re: Good example of C and MACRO Message-ID: Bob Koehler wrote: (snip) >>Kermit is a character/terminal screen based application, though. > While there is a version of kermit implemented in BLISS, the current > and maintained version is in C. It might have been around 1985 when I first started using Kermit with VMS. Mostly transferring files to/from RT-11 and then DOS systems. -- glen ------------------------------ Date: Fri, 28 Nov 2008 16:04:51 -0700 From: Glen Herrmannsfeldt Subject: Re: Good example of C and MACRO Message-ID: Neil Rieck wrote: (snip) > 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 never > think of the descendants of Pentium4 as pure RISC architectures. I believe AMD started, and Intel continued, the idea of having the processor internally convert the CISC instruction stream to RISCops and pass them through to the RISC part of the processor. I don't know if any will let you write RISCop code directly, though. It is much easier to do out-of-order execution at the RISCop level. -- glen -- glen ------------------------------ Date: Fri, 28 Nov 2008 18:03:57 -0500 From: "Richard B. Gilbert" Subject: Re: Good example of C and MACRO Message-ID: 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! ------------------------------ Date: 28 Nov 2008 23:07:26 GMT From: "Bob Eager" Subject: Re: Good example of C and MACRO Message-ID: <176uZD2KcidF-pn2-gfKy1RdgUebf@rikki.tavi.co.uk> On Fri, 28 Nov 2008 22:53:14 UTC, Arne Vajhj 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 never > > think of the descendants of Pentium4 as pure RISC architectures. > > Not even close. > > They are CISC. > > They were CISC 20 years ago and *adding* more complex > instructions did not make them RISC by magic. > > PS: I don't think I have ever seen Intel/AMD claim that x86 or x86-64 > to be RISC. I think the origin of this is simply that internally, that's how they work. All the instructions are broken down into RISC equivalents, as that makes lots of things (pipe scheduling for one) much easier. -- Bob Eager Use the BIG mirror service in the UK: http://www.mirrorservice.org ------------------------------ Date: Fri, 28 Nov 2008 18:05:44 -0500 From: "Richard B. Gilbert" Subject: Re: Good example of C and MACRO Message-ID: Neil Rieck wrote: > On Nov 28, 1:12 pm, Arne Vajhøj wrote: >> Neil Rieck wrote: >>> Correct. Unless you are attending a college course titled "ancient >>> programming tools from the CISC era", C is a much better choice. >>> Sometimes "C" is even a better choice for CISC projects. >> CISC seems to be living very well. >> >> I don't think Intel and AMD are that scared by PPC, SPARC and IA-64. >> >> Arne > > 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 never > think of the descendants of Pentium4 as pure RISC architectures. > > Neil ISTR reading that the Pentium was actually RISC underneath and had a CISC "outer layer". ------------------------------ Date: Sat, 29 Nov 2008 08:17:32 +0800 From: "Richard Maher" Subject: Re: Good example of C and MACRO Message-ID: Hi Richard, > 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) but let me say that MACRO is a far superior language for User-Written System Services. The ability for layered products like RMS, Rdb, and Tier3 to execute securely, with elevated privilege and inner-mode-protected resources, in the context of the user process is one of the things that makes VMS great and distinguishes it from the rest of the pack! (Having said that, most of you probably just give your VAMP servers SYSPRV anyway and couldn't care less :-( ) MACRO is also good for compile-time initialization of global PSECTs and external symbol definition. BTW, I recall some guys at Digital in CHCH circa '92 finding Macro useful as they could COBOL/MACHINE_CODE and work out how the quadword arithmatic was being done and then try to copy it in C :-) Regards Richard Maher PS. Why is there so many on-topic and interesting posts lately? COV is taking a lot longer to read. "Richard B. Gilbert" wrote in message news:zIGdndSzyOBLebDUnZ2dnUVZ_vninZ2d@giganews.com... > Arne Vajhøj wrote: > > Mark Wickens wrote: > >> Jan-Erik Söderholm wrote: > >>> I can't help to ask, why ? > >>> Why write an "application" (whatever that is) in MACRO ? > > > >> Thanks for the replies - yes asking 'why' is a good question. > >> > >> This is purely an academic exercise - I am doing my 'learn one language > >> a year' and this year it is MACRO-32. > > > > If you want to code in assembler, then Macro-32 is probably one > > of the easiest instruction sets to code in - its CISC'ness > > makes it much easier that anything else I have tried. > > > > But note that VAX'es stopped being produced in the mid 90's. > > > > But note that, given the proper software, you can compile VAX Macro to > produce Alpha object code. I wouldn't be surprised if this could also > be done on Itanic. > > ISTR doing this once nine or ten years ago. I had some useful snippet > written in macro and wanted to use it on Alpha. . . . > > There is little reason to write anything in Macro today; device drivers > can be written in C. What else was Macro good for? > > The days when the ability to hand optimize code was useful are long gone > along with the machines on which hand optimization could make a > significant difference! ------------------------------ Date: 28 Nov 2008 23:17:25 GMT From: "Bob Eager" Subject: Re: Good example of C and MACRO Message-ID: <176uZD2KcidF-pn2-d5gLddf5x11Y@rikki.tavi.co.uk> On Fri, 28 Nov 2008 23:05:44 UTC, "Richard B. Gilbert" wrote: > Neil Rieck wrote: > > On Nov 28, 1:12 pm, Arne Vajhj wrote: > >> Neil Rieck wrote: > >>> Correct. Unless you are attending a college course titled "ancient > >>> programming tools from the CISC era", C is a much better choice. > >>> Sometimes "C" is even a better choice for CISC projects. > >> CISC seems to be living very well. > >> > >> I don't think Intel and AMD are that scared by PPC, SPARC and IA-64. > >> > >> Arne > > > > 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 never > > think of the descendants of Pentium4 as pure RISC architectures. > > > > Neil > > ISTR reading that the Pentium was actually RISC underneath and had a > CISC "outer layer". Yup. As previously stated, it makes out-of-order stuff much easier. There's quite a bit here: http://tinyurl.com/stokes-book -- Bob Eager Use the BIG mirror service in the UK: http://www.mirrorservice.org ------------------------------ Date: 28 Nov 2008 23:17:24 GMT From: "Bob Eager" Subject: Re: Good example of C and MACRO Message-ID: <176uZD2KcidF-pn2-t5Ie6vw1Lm1k@rikki.tavi.co.uk> On Fri, 28 Nov 2008 23:03:57 UTC, "Richard B. Gilbert" wrote: > 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! BCPL did. In quite heavy use here at one point. I did a substantial compiler for a query language for Dun and Bradstreet once. Initially on an ICL 2900, where BCPL was the only available and suitable language (don't even ask!). But I then very quickly got it going very nicely on VMS (the BCPL compiler and then the query language compiler written in BCPL). We also wrote some nice little Z80-based terminal concentrators in BCPL. I sold a compiler to someone for a massive teleprocessing project written in BCPL. Quite a few others, too. A nice little earner. Remember that BCPL came from the UK....Bell Labs just derived B from it. -- Bob Eager Use the BIG mirror service in the UK: http://www.mirrorservice.org ------------------------------ Date: Fri, 28 Nov 2008 18:21:21 -0500 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: Good example of C and MACRO Message-ID: <49307cf1$0$90272$14726298@news.sunsite.dk> Glen Herrmannsfeldt wrote: > Neil Rieck 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 never >> think of the descendants of Pentium4 as pure RISC architectures. > > I believe AMD started, and Intel continued, the idea of having > the processor internally convert the CISC instruction stream > to RISCops and pass them through to the RISC part of the processor. > > I don't know if any will let you write RISCop code directly, though. > > It is much easier to do out-of-order execution at the RISCop level. Sure. But that is not the exposed instruction set. It is more like a specific way of implementing microcode. Arne ------------------------------ Date: Fri, 28 Nov 2008 18:48:04 -0500 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: Good example of C and MACRO Message-ID: <49308334$0$90263$14726298@news.sunsite.dk> Glen Herrmannsfeldt wrote: > Bob Koehler wrote: >>> Kermit is a character/terminal screen based application, though. >> While there is a version of kermit implemented in BLISS, the current >> and maintained version is in C. > > It might have been around 1985 when I first started using > Kermit with VMS. Mostly transferring files to/from RT-11 and > then DOS systems. 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. Arne ------------------------------ Date: Fri, 28 Nov 2008 20:22:55 -0700 From: Glen Herrmannsfeldt Subject: Re: Good example of C and MACRO Message-ID: 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. -- glen ------------------------------ Date: Fri, 28 Nov 2008 20:57:33 -0800 From: "Tom Linden" Subject: Re: Good example of C and MACRO Message-ID: On Fri, 28 Nov 2008 10:08:47 -0800, Arne Vajhøj wrote: > Tom Linden wrote: >> On Fri, 28 Nov 2008 08:16:25 -0800, Arne Vajhøj wrote: >>> Tom Wade wrote: >>>>> "Good example in C" I would suggest is an oxymoron. >>>> C is a language that combines the power and flexibility of assembler >>>> with the readability and ease of use of assembler. >>> >>> Even if it is a joke, then it has some foundation in reality. It >>> is not possible to create a language that gives you full flexibility >>> to do the tricks you want and still prevent you from doing mistakes. >>> Either you have the cake or you eat it. >> Some cakes are tastier than others. > > We all know that you prefer [BCDFGHJKLMNPQRSTWVXZ]{2}/[AEIOUY]{1} > cakes. > > :-) > > Arne cute -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Fri, 28 Nov 2008 21:06:18 -0800 From: "Tom Linden" Subject: Re: Good example of C and MACRO Message-ID: On Fri, 28 Nov 2008 15:20:21 -0800, Arne Vajhøj wrote: > Bob Eager wrote: >> On Fri, 28 Nov 2008 22:53:14 UTC, Arne Vajhj 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 never >>>> think of the descendants of Pentium4 as pure RISC architectures. >>> Not even close. >>> They are CISC. >>> They were CISC 20 years ago and *adding* more complex >>> instructions did not make them RISC by magic. >>> PS: I don't think I have ever seen Intel/AMD claim that x86 or x86-64 >>> to be RISC. >> I think the origin of this is simply that internally, that's how they >> work. All the instructions are broken down into RISC equivalents, as >> 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. They started building RISC cores at some point with the 386. I had a few discussions with John Crawford at that time, must have been late 80's. Basically they are emulation engines. If 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. Prime actully did both V-mode (accumulator architecture) and I-mode (general register) with the same hardware by reprogramming the microcode. -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Fri, 28 Nov 2008 21:12:56 -0800 From: "Tom Linden" Subject: Re: Good example of C and MACRO Message-ID: On Fri, 28 Nov 2008 19:22:55 -0800, Glen Herrmannsfeldt wrote: > 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. I used it around 1981 > > -- glen > -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Fri, 28 Nov 2008 14:09:34 -0500 From: JF Mezei Subject: Re: How to make an FTP through a .com file Message-ID: <001c1f21$0$12277$c3e8da3@news.astraweb.com> If you need to transfer just one file, then, as someone else said, COPY/FTP is your friend. HELP COPY/FTP gives you the relevant syntax and options as well as examples. If you are transfering a whole bunch of files, then you may be better off writing a command procedure on the fly that contains the FTP commands in the right sequence. This way, you only have to establish the FTP control session once which will last across each file transfer. $define/user sys$command sys$input $ftp target.host user pass TYPE IMAGE CD /inboundfiles SEND file1.txt SEND file2.bin SEND file3.jpg SEND chocolates to.jf SEND file4.exe EXIT $EXIT This above will run quicker than individual COPY/FTP commands. However, with individual COPY/FTP, you can catch error for an individual file and retry it, or skip that file. With the batch file approach, you only have a generic exit status without knowledge of where the transfer failed (unless a human looks at the log file). ------------------------------ Date: Fri, 28 Nov 2008 22:27:27 +0200 From: =?ISO-8859-1?Q?Kari_Uusim=E4ki?= Subject: Re: How to make an FTP through a .com file Message-ID: <4930542f$0$20329$9b536df3@news.fv.fi> Naveen wrote: > Dear Sir/ Maidam > > I want to transfer some file from one system to another through a .com > file. File name is not constant, so i want to make a .com file, in > which it will inquire the name of file, and after that, that file > should be transferred. Normal FTP works fine, but i want to do with > a .com file > > I tried this but it is not working > > $ inquire p1 "file name to transfer:-" > $ftp 192.168.68.51 > hsm ! username of system to which file has to be > transferred > HotstripmilL ! password of system > put ' ' p1 > bye > $exit > > Thinking you in advance I suggest you take a look at the utility called FTSO, which can be found in the OpenVMS Freeware V7 distribution. It is very flexible and has many advantages compared to the plain ftp client. You can of course create a command procedure for submitting your ftp jobs to FTSO. Regards, Kari ------------------------------ Date: 28 Nov 2008 17:07:53 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: How to make an FTP through a .com file Message-ID: In article <6fd401ee-c36f-408a-bdec-27c1f2aae436@w1g2000prkgooglegroups.com>, Naveen writes: > > Thinking you in advance I'd rather be thanked. (I guess English is not your first language?) You can do one of three things depending on your version of VMS and which IP stack you're using. 1) Use the command "COPY/FTP" 2) Use an FTP command with all the data on one line, like COPY/FTP 3) Write the FTP commands to a file and run your FTP client with that file as it's input stream. ------------------------------ Date: Fri, 28 Nov 2008 19:18:10 -0800 (PST) From: FrankS Subject: Re: How to make an FTP through a .com file Message-ID: On Nov 28, 12:09=A0pm, Naveen wrote: > Dear Sir/ Maidam > > I want to transfer some file from one system to another through a .com > file. File name is not constant, so i want to make a .com file, in > which it will inquire the name of file, and after that, that file > should be transferred. Normal FTP works fine, but i want to do with > a .com file > > I tried this but it is not working > > $ inquire p1 "file name to transfer:-" > $ftp 192.168.68.51 > =A0 hsm =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0! username of system to which file= has to be > transferred > =A0 HotstripmilL =A0 =A0 ! password of system > put ' ' p1 > bye > $exit > > Thinking you in advance I would agree with the others to use COPY/FTP for single file transfers. If you'd still prefer to use the FTP utility then you can avoid the need to generate an interim script procedure by using a logical name. For example: $! $! FTP_ONE_FILE $! $ set noon $ set noverify $ $! $ ploop: $ if (p1 .nes. "") then goto do_ftp $ inquire p1 "File Specification" $ goto ploop $ $! $ do_ftp: $ define /process putfile 'p1' $ $ ftp ftp.mydomain.com /username=3D"ftp_login" /password=3D"ftp_password" cd /target_directory/ put putfile: $ $! ------------------------------ Date: Sat, 29 Nov 2008 00:10:20 -0600 (CST) From: sms@antinode.info (Steven M. Schweda) Subject: Re: How to make an FTP through a .com file Message-ID: <08112900102006_2020048A@antinode.info> 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.) ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-info 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Fri, 28 Nov 2008 22:32:44 +0200 From: =?ISO-8859-1?Q?Kari_Uusim=E4ki?= Subject: Re: LAT BARCODE PRINTER Message-ID: <4930556c$0$20329$9b536df3@news.fv.fi> Ramon Jimenez wrote: > Hi we have ported a Pascal App. from a VAX to an Integrity. > > The source code has not been changed just recompiled on the new > platform. > > Applications sends data to a Printronix T5308 label printer. In the > old plattform it prints barcodes on the label but in the new the label > is generated but the barcode is not shown. > > LAT configuration is the same in the both machines, and seems like > ports on decservers are ok, in fact they are the same decservers. > > Another program which has been also recompiled is able to print the > barcode. > > Any suggestion about the way to troubleshot and fix this issue? > > Regards Ramon > Does your application send the barcodes to the printer as fonts? If so, you might not have transferred the barcode fonts to the Integrity machine. Regards, Kari ------------------------------ Date: 28 Nov 2008 16:51:09 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: LAT BARCODE PRINTER Message-ID: In article <134476b0-3b3a-4adc-9b53-5c8b1e271e5a@k12g2000yqk.googlegroups.com>, Ramon Jimenez writes: > > Any suggestion about the way to troubleshot and fix this issue? Yes. There is a bug in your code. Compile with and use the debugger nutil you find and fix it. ------------------------------ Date: Fri, 28 Nov 2008 16:11:10 -0800 (PST) From: dooleys@snowy.net.au Subject: Re: LAT BARCODE PRINTER Message-ID: <0c6076a7-46df-4a59-800d-07ebc70fcd0a@o40g2000prn.googlegroups.com> On Nov 28, 1:21=A0am, Ramon Jimenez wrote: > Hi we have ported a Pascal App. from a VAX to an Integrity. > > The source code has not been changed just recompiled on the new > platform. > > Applications sends data to a Printronix T5308 label printer. In the > old plattform it prints barcodes on the label but in the new the label > is generated but the barcode is not shown. > > LAT configuration is the same in the both machines, and seems like > ports on decservers are ok, in fact they are the same decservers. > > Another program which has been also recompiled is able to print the > barcode. > > Any suggestion about the way to troubleshot and fix this issue? > > Regards Ramon is the terminal "width" (and other settings) the same the width is DEVBUFSIZ on the device the barcodes may need long lines (255?) Phil ------------------------------ Date: 28 Nov 2008 18:56:42 GMT From: "Bob Eager" Subject: Re: MUTEX Message-ID: <176uZD2KcidF-pn2-TBBnZBDJMUon@rikki.tavi.co.uk> On Fri, 28 Nov 2008 18:38:06 UTC, JF Mezei wrote: > Is there a simple explanation of what a MUTEX is ? Stands for MUTual EXclusion primitive - quite often using a semaphore (q.v.). It's a mechanism that allows one to limit the number of threads of execution which access some resource to be limited to N. The value N is often, but not always, one. A real life example is the old time system for making sure that trains don't collide on a single track line. The driver is not allowed to enter the controlled section unless he possesses (physically, has in the cab) a large piece of metal (or similar) called the 'token'. There is only one such piece of metal. When leaving the controlled section, he surrenders it to the signalman. There is mutual exclusion applied to the use of the controlled section since only one driver/train can hold the token at a time. In computing, the token is usually a value in a byte/word/whatever, access to which is controlled by the operating system. > What sort of operation requires the use of a MUTEX ? Operation on any shared resource (e.g. a table, a linked list, whatever), to stop access by two processes at once (think SMP particularly, although it's also necessary on single processors due to the nondeterministic nature of the system's overall behaviour). Of course, on a VAX one doesn't have to worry about linked lists if one is prepared to take the hit/limitations of the interlocked queue operations. -- Bob Eager Use the BIG mirror service in the UK: http://www.mirrorservice.org ------------------------------ Date: Fri, 28 Nov 2008 14:04:53 -0500 From: "Richard B. Gilbert" Subject: Re: MUTEX Message-ID: JF Mezei wrote: > Is there a simple explanation of what a MUTEX is ? > > What sort of operation requires the use of a MUTEX ? A MUTEX is a MUTual EXclusion semaphore. It provides a method to ensure that a nonshareable resource is used by only one process at a time. ------------------------------ Date: 28 Nov 2008 16:56:58 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: MUTEX Message-ID: In article , =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= writes: > > I have severe problem with a batch job going into MUTEX. > And I have severe problem to finding out *why* (and then > getting rid of it. DELETE/ENTRY doesn't work (says > -JBC-E-INCOMPLETE, previous incomplete operation > prevents execution). STOP/ID doesn't work (no message > at all, process is still there). MUTEX are quite rare in VMS these days. IIRC the EFN being waited on will actually contain the address of the MUTEX. After you get that you need the source listing kit to figure out which MUTEX it is. > > The batch job seems to hang an a "telnet delete " > command. I've tried to "tcpip disconnect dev ", > no message but the bg-device still exists. > > The TNA port exists and is owned by the MUTEX'ed batch job. Do you have the TNA set up as spooled device? That would be the "printer" MUTEX. You may have to unspool the device. > > I've tried to build a couple of tools from the > freeware kits (FREE_RSN and MWAIT) but both gives > some MACRO errors when built on Alpha (8.2). Maybe > they are VAX-only, the readme's doesn't say... Most likely these tools build on a specific architecture and VMS version and you'ld need the source listings kit to port them to another architecture or version. ------------------------------ Date: Fri, 28 Nov 2008 23:35:05 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: MUTEX Message-ID: Bob Koehler wrote: > In article , =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= writes: >> I have severe problem with a batch job going into MUTEX. >> And I have severe problem to finding out *why* (and then >> getting rid of it. DELETE/ENTRY doesn't work (says >> -JBC-E-INCOMPLETE, previous incomplete operation >> prevents execution). STOP/ID doesn't work (no message >> at all, process is still there). > > MUTEX are quite rare in VMS these days. IIRC the EFN being > waited on will actually contain the address of the MUTEX. After > you get that you need the source listing kit to figure out > which MUTEX it is. >> The batch job seems to hang an a "telnet delete " >> command. I've tried to "tcpip disconnect dev ", >> no message but the bg-device still exists. >> >> The TNA port exists and is owned by the MUTEX'ed batch job. > > Do you have the TNA set up as spooled device? That would be the > "printer" MUTEX. You may have to unspool the device. > >> I've tried to build a couple of tools from the >> freeware kits (FREE_RSN and MWAIT) but both gives >> some MACRO errors when built on Alpha (8.2). Maybe >> they are VAX-only, the readme's doesn't say... > > Most likely these tools build on a specific architecture and VMS > version and you'ld need the source listings kit to port them to > another architecture or version. > They are FREE_RSN and MWAIT from the latest freeware kit (8) and they are both in MACRO. Anyone can try to build them. ------------------------------ Date: Fri, 28 Nov 2008 13:57:50 -0500 From: "Richard B. Gilbert" Subject: Re: PPL$ documentation Message-ID: Pierre wrote: >> is there something that replace it ? > > I have M processes which want to use a resource which may be used at > most by N the wheel rewriting semaphores routines that use $ENQ/$DEQ, I thought > I may use PPL$ routines. > > maybe it is not the right choice. duno. that's why I'm looking for the > PPL$ doc... > > Pierre AFAIK all the VMS documentation is available on line. http://h71000.www7.hp.com/DOC/ ------------------------------ Date: Fri, 28 Nov 2008 21:50:03 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: PPL$ documentation Message-ID: Pierre wrote: > but I can not find anything about PPL on the freeware CD :( http://h71000.www7.hp.com/openvms/freeware/V4_00freeware_abstract.txt ------------------------------ Date: 28 Nov 2008 17:09:26 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: PPL$ documentation Message-ID: In article , Pierre writes: > hi, > > I'm trying to find the documentation of the PPL$ routines on HP site > but the latest one I find in the VMS 7.3 one > http://h71000.www7.hp.com/doc/73final/documentation/pdf/OVMS_RTL_PPL.pdf?jumpid=reg_R1002_USEN > > is there a documentation for VMS 8.x? Have you looked in the obsolete features manual (whatever it's called today)? PPL$ was replaced by DECthreads, but should still work as originally documented. ------------------------------ Date: Fri, 28 Nov 2008 14:03:28 -0500 From: JF Mezei Subject: Re: search list, surprising error, inconsistent behavior Message-ID: <001f7765$0$6616$c3e8da3@news.astraweb.com> This problem is fairly easy to reproduce: $ CREATE/DIR disk:[VMS$COMMON.SYSMGR.SUE] $ CD SYS$MANAGER (searchlist of SYS0.SYSMGR and VMS$COMMON.SYSMGR) $ create [.sue]skonetski.txt %CREATE-E-OPENOUT, error opening SYS$SYSROOT:[SYSMGR.SUE]SKONETSKI.TXT; as output -RMS-E-DNF, directory not found -SYSTEM-W-NOSUCHFILE, no such file This fails because it tries to create the file using the first item in the search list and this tries to create SYS$SYSROOT:[SYSMGR.SUE]SKONETSKI.TXT and this can't work because SUE.DIR doesn't exist in that path. ---------- You can however $ CREATE disk:[vms$common.sysmgr.sue]skonetski.txt without problem, and $ CD SYS$MANAGER: $ dir [.sue] Directory SYS$COMMON:[SYSMGR.sue] skonetski.txt;1 Total of 1 file. The above works even though there isn't a [.sue] directory under the sys0.sysmgr path. ----------- If you create [.sue] under the sys0.msymgr path, but not under vms$common, then the problem doesn't happen because VMS will be able to find the path in the first translation and not realise that directory doesn't exist in subsequent translations. ------------------------------ End of INFO-VAX 2008.637 ************************