1 INFO-VAX	Tue, 13 Apr 2004	Volume 2004 : Issue 205       Contents:@ Re: AMD OpteronT Processor Powers New Family of Sun Fire Servers" archiving save sets on a linux box& RE: archiving save sets on a linux box Back in the saddle% Re: Backup command / Tape help needed % Re: Backup command / Tape help needed % RE: Backup command / Tape help needed % Re: Backup command / Tape help needed % Re: Backup command / Tape help needed % Re: Backup command / Tape help needed % Re: Backup command / Tape help needed % RE: Backup command / Tape help needed % Re: Backup command / Tape help needed @ Re: Configuring TCPIP SMTP server to ignore undeliverable mail??@ RE: Configuring TCPIP SMTP server to ignore undeliverable mail?? copy file to tape with vms$ Re: OT - Outsourced customer service Re: Postscript Restore using backup& Re: SKHPC: A Total Eclipse of the Sun? Re: VMS newbie  F ----------------------------------------------------------------------    Date: 13 Apr 2004 08:16:31 -0700' From: icerq4a@spray.se (David Svensson) I Subject: Re: AMD OpteronT Processor Powers New Family of Sun Fire Servers = Message-ID: <734da31c.0404130716.2a735fb4@posting.google.com>    Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> wrote in message news:<c5gf8b$2s4$1@new-usenet.uk.sun.com>...  > Nigel Barker wrote: 7 > > On Fri, 19 Mar 2004 18:58:50 +0000, Andrew Harrison . > > <andrew_._remove_harrison@su_n.com> wrote: > >  > >  > >>UltraSPARC IV+ > >>UltraSPARC V > >>Niagara  > >>Rock > >>: > >>All currently under development, some in first silicon > >  > > L > > Shock! Horror! Did Sun lie to their customers when they promised to shipK > > UltraSPARC V etc? No, they told them what was true to the best of their K > > knowledge at the time. Circumstances change, fortunes change. Just like # > > decisions made regarding Alpha.  > >  > 8 > Nice try but the chip that you and the market think of; > as UltraSPARC V may have been cancelled but SPARC hasn't.  > < > One of the reasons why the chip you think of as UltraSPARC9 > V was cancelled is because it had to compete internally  > with Rock. > ; > Trying in the well tried HP choirister way to compare and = > contrast this with the demise of Alpha is only funny if you : > arn't an Alpha cutomer. To everyone else its hillarious. > 	 > Regards  > Andrew HArrison   F You would gain some credibility if you at least sometimes say that Sun4 has done something bad. Is everything Sun does good?   ------------------------------  # Date: Tue, 13 Apr 2004 16:47:45 GMT - From: Larry Elson <lelson49@worldnet.att.net> + Subject: archiving save sets on a linux box G Message-ID: <RQUec.26679$i74.528703@bgtnsc04-news.ops.worldnet.att.net>   B I am running VMS 6.2 on an alpha 2100. I am trying to archive vms 7 save sets on a linux box running suse 9.0 (2.4 kernel).   H I ftp'ed (binary) a save set to the linux box and then brought it back.   K I have been unable to read the save sets after bringing them back from the  
 linux box.  4 Before I ftp the save set to linux dir/full reports:K         File attributes: Allocation: 156, Extend: 0, Global buffer count: 0 $                     No version limit;         Record format:      Fixed length 32256 byte records           Record attributes:  None   After I bring the file back:K         File attributes: Allocation: 136, Extend: 0, Global buffer count: 0 $                     No version limitL         Record format: Variable length, maximum 0 bytes, longest 32256 bytes<         Record attributes:  Carriage return carriage control  + Any advice would be appreciated. Thank you.    Larry Elson    ------------------------------  % Date: Tue, 13 Apr 2004 09:59:39 -0700 # From: "Tom Linden" <tom@kednos.com> / Subject: RE: archiving save sets on a linux box 9 Message-ID: <NDEMLKKEBOIFBMJLCECIAEFHDBAA.tom@kednos.com>   I Try fetching ftp://ftp.kednos.com/pub/reset_backup_saveset_attributes.com      -----Original Message-----6   From: Larry Elson [mailto:lelson49@worldnet.att.net]'   Sent: Tuesday, April 13, 2004 9:48 AM    To: Info-VAX@Mvb.Saic.Com -   Subject: archiving save sets on a linux box       D   I am running VMS 6.2 on an alpha 2100. I am trying to archive vms 9   save sets on a linux box running suse 9.0 (2.4 kernel).    J   I ftp'ed (binary) a save set to the linux box and then brought it back.    D   I have been unable to read the save sets after bringing them back    from the     linux box.   6   Before I ftp the save set to linux dir/full reports:>           File attributes: Allocation: 156, Extend: 0, Global    buffer count: 0 &                       No version limit=           Record format:      Fixed length 32256 byte records "           Record attributes:  None      After I bring the file back:>           File attributes: Allocation: 136, Extend: 0, Global    buffer count: 0 &                       No version limitC           Record format: Variable length, maximum 0 bytes, longest  
   32256 bytes >           Record attributes:  Carriage return carriage control   -   Any advice would be appreciated. Thank you.    
   Larry Elson       --- (   Incoming mail is certified Virus Free.<   Checked by AVG anti-virus system (http://www.grisoft.com).A   Version: 6.0.655 / Virus Database: 420 - Release Date: 4/8/2004     --- & Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).? Version: 6.0.655 / Virus Database: 420 - Release Date: 4/8/2004    ------------------------------    Date: 13 Apr 2004 10:47:03 -0700& From: mike-spam@yelof.com (Mike Foley) Subject: Back in the saddle < Message-ID: <8edb64a.0404130947.425276dd@posting.google.com>   Hi Everyone,  A It's been about 10 years since I managed VMS systems on a regular  basis.D (Some of you may remember me from when I was managing VMS systems in5 the VMS Group! STAR::MFOLEY or AXEL::FOLEY back then)   A Well, I've accepted a contract at a large university in Boston to @ manage some VMS systems. There's not much in the way of TecnicalE Marketing positions out there! So, back in the well-worn saddle I go. E It's ironic that I accepted this job the week John W. passed away. He ; would have been happy to hear someone getting a VMS job. :(   < I'm behind the curve in what's up with VMS so I've got a few
 questions:  < 1 What documentation should I have on my bookshelf at work?   D 2. What stuff should I read to get me back up to speed? My expertise
 was in the    6.x timeframe.   9 Any other insights and tips would be greatly appreciated.  Thanks!   ! Back to my audits of the systems,    mike   ------------------------------  % Date: Tue, 13 Apr 2004 12:22:56 +0100 - From: Roy Omond <Roy.Omond@BlueBubble.UK.Com> . Subject: Re: Backup command / Tape help needed9 Message-ID: <c5gijk$1d5lt$1@ID-225674.news.uni-berlin.de>    David J. Dachtera wrote:   > NeedHelp wrote:  > M >>I tried the first option below without success.  I'm not sure of the syntax 8 >>for record format fixed...... and the convert command. >>$ >>The second option looks like this:$ >>A1000:> dismount /nounload mkb400:+ >>A1000:> mount mkb400: /over=id/block=8192 , >>%MOUNT-I-WRITELOCK, volume is write locked4 >>%MOUNT-I-MOUNTED, 032994 mounted on _A1000$MKB400:& >>A1000:> copy mkb400:a11f.bck [] /log4 >>%COPY-E-READERR, error reading MKB400:[]A11F.BCK;1 >>-RMS-F-RER, file read error   >>-SYSTEM-F-PARITY, parity error= >>%COPY-W-NOTCMPLT, MKB400:[]A11F.BCK;1 not completely copied 	 >>A1000:>  >  >  > Yecch! That's ugly.  > F > Since the DUMPs posted earlier illustrate that the label records areC > indeed present and are the right size, I'm wondering if the label H > content might be an issue... (don't have the necessary doc.'s to check	 > it out)  > H > If not for the labels issue, BACKUP *MIGHT* get past the parity error, > and then again it might not. > ' > Are data recovery services an option?    What has been established:  $ 1) the header labels appear to be OK8 2) the first (few) blocks of the saveset appear to be OK/ 3) you get a parity error further down the tape + 4) BACKUP complains about the tape *labels*   > Please try John Briggs's suggestion, mounting the tape foreign i.e.  + 	$ mount/foreign/nowrite/block=8192 mkb400: < 	$ set mag/skip=file=1 mkb400:	! skip past the header labels 	$ copy mkb400: x.x   = If the problem is indeed with the trailer labels, then you've : been lucky, and file X.X will be an intact BACKUP saveset.  9 If you get a parity error on the copy, then you're stuck. 9 Not even BACKUP will be able to get past the parity error @ (cf. 9-track tapes, where it would have very probably succeeded)? since this is a helical-scan tape, where everything on the tape   depends on everything before it.  ? Depending on how far down the tape the parity error occurs, you $ might get *something* usable in X.X.  	 Roy Omond  Blue Bubble Ltd.   ------------------------------    Date: 13 Apr 2004 07:18:41 -0600 From: briggs@encompasserve.org. Subject: Re: Backup command / Tape help needed3 Message-ID: <22F6X+xO30K2@eisner.encompasserve.org>   a In article <KRCec.4125$hg1.4060@nwrddc02.gnilink.net>, "NeedHelp" <eckmant@earthlink.net> writes: M > I tried the first option below without success.  I'm not sure of the syntax 8 > for record format fixed...... and the convert command.  + Transcript, please?  I gave you the syntax.    >> $ set mag /rewind mkb400: >> $ copy mkb400: nl: /log! >> $ convert mkb400: tapefile.dat 	 >> record  >> format fixed  >> size 8192   - Oh.  I forgot to tell you to press control-Z.    > $ > The second option looks like this:$ > A1000:> dismount /nounload mkb400:+ > A1000:> mount mkb400: /over=id/block=8192 , > %MOUNT-I-WRITELOCK, volume is write locked4 > %MOUNT-I-MOUNTED, 032994 mounted on _A1000$MKB400:& > A1000:> copy mkb400:a11f.bck [] /log4 > %COPY-E-READERR, error reading MKB400:[]A11F.BCK;1 > -RMS-F-RER, file read error   > -SYSTEM-F-PARITY, parity error    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  2 And there we have it.  The dreaded parity error.     	John Briggs   ------------------------------  % Date: Tue, 13 Apr 2004 15:13:52 -0700 4 From: "Darren Boyle" <Darren_Boyle@BlueYonder.co.UK>. Subject: RE: Backup command / Tape help neededG Message-ID: <000201c421a4$9b2b8410$e9542b52@adept.adeptconsultants.net>   J It's been a very long time since I've tried this but if this is a mag tapeI and you do not mind losing the first couple of files in the save set then E you should be able to use the following.  BUT BE WARNED once you have K written the new header to the tape you WILL NOT be able to retrieve the old  one.  " Try this to write the new header..   BACKUP/LOG X.X MKB400:*.*/SAVE CTRL_Y  ? Next mount the tape and select all the files from the save set. - BACK/SEL=*.* MKB400:*.*/SAVE [DIRECTORY]*.*;*   K check the command syntax of the above with HELP BACK before proceeding as I   can't verify it from where I am. - Darren   -----Original Message-----4 From: Roy Omond [mailto:Roy.Omond@BlueBubble.UK.Com] Sent: 13 April 2004 04:23  To: Info-VAX@Mvb.Saic.Com . Subject: Re: Backup command / Tape help needed     David J. Dachtera wrote:   > NeedHelp wrote:  > F >>I tried the first option below without success.  I'm not sure of the syntax8 >>for record format fixed...... and the convert command. >>$ >>The second option looks like this:$ >>A1000:> dismount /nounload mkb400:+ >>A1000:> mount mkb400: /over=id/block=8192 , >>%MOUNT-I-WRITELOCK, volume is write locked4 >>%MOUNT-I-MOUNTED, 032994 mounted on _A1000$MKB400:& >>A1000:> copy mkb400:a11f.bck [] /log4 >>%COPY-E-READERR, error reading MKB400:[]A11F.BCK;1 >>-RMS-F-RER, file read error   >>-SYSTEM-F-PARITY, parity error= >>%COPY-W-NOTCMPLT, MKB400:[]A11F.BCK;1 not completely copied 	 >>A1000:>  >  >  > Yecch! That's ugly.  > F > Since the DUMPs posted earlier illustrate that the label records areC > indeed present and are the right size, I'm wondering if the label H > content might be an issue... (don't have the necessary doc.'s to check	 > it out)  > H > If not for the labels issue, BACKUP *MIGHT* get past the parity error, > and then again it might not. > ' > Are data recovery services an option?    What has been established:  $ 1) the header labels appear to be OK8 2) the first (few) blocks of the saveset appear to be OK/ 3) you get a parity error further down the tape + 4) BACKUP complains about the tape *labels*   > Please try John Briggs's suggestion, mounting the tape foreign i.e.  + 	$ mount/foreign/nowrite/block=8192 mkb400: < 	$ set mag/skip=file=1 mkb400:	! skip past the header labels 	$ copy mkb400: x.x   = If the problem is indeed with the trailer labels, then you've : been lucky, and file X.X will be an intact BACKUP saveset.  9 If you get a parity error on the copy, then you're stuck. 9 Not even BACKUP will be able to get past the parity error @ (cf. 9-track tapes, where it would have very probably succeeded)? since this is a helical-scan tape, where everything on the tape   depends on everything before it.  ? Depending on how far down the tape the parity error occurs, you $ might get *something* usable in X.X.  	 Roy Omond  Blue Bubble Ltd.   ------------------------------  % Date: Tue, 13 Apr 2004 15:26:44 +0100 - From: Roy Omond <Roy.Omond@BlueBubble.UK.Com> . Subject: Re: Backup command / Tape help needed9 Message-ID: <c5gtbr$1h0tq$1@ID-225674.news.uni-berlin.de>    Darren Boyle wrote:   L > It's been a very long time since I've tried this but if this is a mag tapeK > and you do not mind losing the first couple of files in the save set then G > you should be able to use the following.  BUT BE WARNED once you have M > written the new header to the tape you WILL NOT be able to retrieve the old  > one. > $ > Try this to write the new header.. >   > BACKUP/LOG X.X MKB400:*.*/SAVE > CTRL_Y > A > Next mount the tape and select all the files from the save set. / > BACK/SEL=*.* MKB400:*.*/SAVE [DIRECTORY]*.*;*  > M > check the command syntax of the above with HELP BACK before proceeding as I " > can't verify it from where I am.  . (Please do not top-post - my original snipped)  5 I have no idea what you hope to achieve by the above.    It's, ahem, ehhh, rubbish.  	 Roy Omond  Blue Bubble Ltd.   ------------------------------  % Date: Tue, 13 Apr 2004 15:48:56 +0100 - From: Roy Omond <Roy.Omond@BlueBubble.UK.Com> . Subject: Re: Backup command / Tape help needed9 Message-ID: <c5gule$1iit1$1@ID-225674.news.uni-berlin.de>    John Laird wrote:   M > On Tue, 13 Apr 2004 12:22:56 +0100, Roy Omond <Roy.Omond@BlueBubble.UK.Com>  > wrote: >  > [... snip ...] > ; >>If you get a parity error on the copy, then you're stuck. ; >>Not even BACKUP will be able to get past the parity error B >>(cf. 9-track tapes, where it would have very probably succeeded)A >>since this is a helical-scan tape, where everything on the tape " >>depends on everything before it. > M > Is that right ?  I used to have an article detailing the enormous amount of M > redundancy and error-checking on 8mm devices.  Even if the drive insists on G > returning errors, BACKUP's own redundancy blocks may still be able to N > recover the data.  A lot may depend on BACKUP's behaviour, and my experience0 > with 8mm tapes was not all that good, however.  @ Yep, 'fraid so.  Once you get a parity error on any helical-scanA tape technology (including modern DLT's) that's it, party's over. D Not even good old BACKUP will save you.  8mm was *awful* technology.4 I know no-one who's had anything but bad experience.  7 Btw: I've got a dual Exabyte 8500 pizza box at home ;-|   A >>Depending on how far down the tape the parity error occurs, you & >>might get *something* usable in X.X. > N > Just keep going with the COPY commands, would be my recommendation, until anI > end-of-file is reached and the last command exits without errors.  Then C > append the bits to one another and see what BACKUP/LIST produces.   D Sorry, won't work.  As above, once you've hit the first parity error you can't go any further.   	 Roy Omond  Blue Bubble Ltd.   ------------------------------  % Date: Tue, 13 Apr 2004 15:51:54 +0100 5 From: "Robert A.M. van Lopik" <lopik@mail.telepac.pt> . Subject: Re: Backup command / Tape help needed9 Message-ID: <c5gv2r$1hh18$1@ID-191217.news.uni-berlin.de>   + <briggs@encompasserve.org> wrote in message - news:OEaYptTDpZu$@eisner.encompasserve.org...   	  < snip >   E >This technique is viable on 9 track, but is not useful on any modern B > media.  It is pretty much guaranteed to introduce a parity error  J pretty much? My understanding of parity is that that probability of having the wrong parity is 50% ;-)   
 rob van lopik    ------------------------------  % Date: Tue, 13 Apr 2004 16:11:57 +0100 - From: Roy Omond <Roy.Omond@BlueBubble.UK.Com> . Subject: Re: Backup command / Tape help needed9 Message-ID: <c5h00p$1ki57$1@ID-225674.news.uni-berlin.de>    Darren Boyle wrote:   6 > From: Roy Omond [mailto:Roy.Omond@BlueBubble.UK.Com]1 >> (Please do not top-post - my original snipped)  > N > What is the problem here, the mail was not sent to you it is for the benefit? > of the group, I simply replied to them, it's easier that way.   @ Oh dear.  Please (and this is meant to be helpful) try to changeB your e-mail settings (I can't tell which mail system you're using)@ to use bottom-posting.  Most decent systems can be configured toC do that.  It's just common netiquette, and makes following a thread 
 much simpler.   8 >> I have no idea what you hope to achieve by the above. > H > Hope?, this will begin by writing a new header (BOT) over the originalJ > header, then the CTRL_Y will abort the write operation without writing aJ > logical EOT marker.  Due to no EOT marker the backup command will simplyN > read to the physical end of the tape pulling off all files found on the tapeL > (with a few read errors for the first couple of files).  Hence MOST of the$ > data on the tape can be recovered.  F As stated earlier, this sort of techinque does *not* work for anything; but ancient 9-track (and probably 7-track) tape technology.   C And by the way, as specified in your posting, it wouldn't even have ( achieved what you think on 9-track tape.   >> It's, ahem, ehhh, rubbish. G > And you know this for a fact do you, have you even tried it.  I have.   D I have used similar techniques on 9-track tapes going back more thanF 20 years.  So I guess the answer is a definite "yes".  Heck I can evenH remember the stuff you could pour on tapes and read the individual bits.C What was it called - magnetovox ?  7-track 200 bpi was readable :-)   = Now have you tried anything even remotely similar on anything > commonly available in the last decade ?  Hint: it doesn't work? any more.  That's the whole issue - it has no chance of working = on anything remotely "modern", if we can dare to classify the 5 original poster's Exabyte 8mm technology as "modern".    Ah the good old days ...  	 Roy Omond  Blue Bubble Ltd.   ------------------------------  % Date: Tue, 13 Apr 2004 15:51:37 -0700 4 From: "Darren Boyle" <Darren_Boyle@BlueYonder.co.UK>. Subject: RE: Backup command / Tape help neededG Message-ID: <000c01c421a9$e15e4da0$e9542b52@adept.adeptconsultants.net>   4 From: Roy Omond [mailto:Roy.Omond@BlueBubble.UK.Com]. (Please do not top-post - my original snipped)  L What is the problem here, the mail was not sent to you it is for the benefit= of the group, I simply replied to them, it's easier that way.   5 I have no idea what you hope to achieve by the above.   F Hope?, this will begin by writing a new header (BOT) over the originalH header, then the CTRL_Y will abort the write operation without writing aH logical EOT marker.  Due to no EOT marker the backup command will simplyL read to the physical end of the tape pulling off all files found on the tapeJ (with a few read errors for the first couple of files).  Hence MOST of the" data on the tape can be recovered.   It's, ahem, ehhh, rubbish.E And you know this for a fact do you, have you even tried it.  I have.    ------------------------------  # Date: Tue, 13 Apr 2004 17:54:12 GMT 0 From: glen herrmannsfeldt <gah@ugcs.caltech.edu>. Subject: Re: Backup command / Tape help needed- Message-ID: <ZNVec.31742$rg5.50363@attbi_s52>    briggs@encompasserve.org wrote:   8 (snip discussing previously snipped control-Y technique)  G > Yeah.  I've seen the technique described many years ago.  The classic H > case in which it is useful is when a BACKUP tape has been accidentally > re-initialized.  But...   A I have seen before descriptions of a technique for DDS tapes that B requires that the drive be powered off while writing.  The successF rate is not high, but better than nothing.  It seems that the hardware5 will write the EOT mark without any help from the OS.    (snip)  H > The reference to a "BOT" header is potentially misleading.  On classicC > 9 track tape, there is a "BOT" marker which is a reflective strip G > glued to the media.  That obviously can't be overwritten in software. E > (nice VAX Magic war story "Dual Density mag tape" involved multiple D > BOT markers).  What you're writing over would be the VOL1 and HDR1 > labels appearing at BOT.  @ I don't know the VMS stories.  There are some interesting OS/360> stories related to dual density tapes.  OS/360 will verify theA label, backspace to before the label, and then rewrite the label.   @ In writing the first file on the tape, a dual density drive willE verify the label at the density it was written at, and then overwrite E it at the newly specified density.  (Or default density if one forgot > to specify it.   Yes, I learned this from experience.  To stay9 on topic, that tape was supposed to be read by VAX/VMS on + an 11/780, but was then the wrong density.)   > In writing other than the first file, it will again verify theB label at the original density and overwrite it at the new density,> such that different files on the tape are written at differentA densities.  Such a tape can only be read on a drive that supports  both densities.   D > "Logical EOT marker" is also potentially misleading.  On classic 9B > track tape, there is an "EOT" marker which is another reflectiveF > strip located near the physical end of tape.  The real end of volume? > indication is two back-to-back tape marks (a single tape mark ? > being taken as end-of-file rather than end-of-volume).  It is @ > this pair of tape marks that the control-Y prevents from beingA > written.  (On ANSI labelled mag tape, the waters are muddied by B > the possibility of an empty file, resulting in back to back tape& > marks not indicating end-of-volume).  @ The S/360 tradition is that on writing the physical mark is usedC to indicate that the end is near, and the system should then finish < the operation and write the logical mark.  On read, only the; logical EOT mark is used.   Mounting a blank tape on OS/360 ? causes a request to read the label, (or tape mark for unlabeled ; tapes) which will run the tape off the reel while the drive + tries to find anything written on the tape.    -- glen    ------------------------------    Date: 13 Apr 2004 09:27:39 -0700" From: bob@jfcl.com (Bob Armstrong)I Subject: Re: Configuring TCPIP SMTP server to ignore undeliverable mail?? = Message-ID: <dc5428e3.0404130827.2e8515a5@posting.google.com>   [ JF Mezei <jfmezei.spamnot@istop.com> wrote in message news:<407AE809.E21E471F@istop.com>... L > Not sending back a non-delivery notification in case a username is invalid& > goes against the spirit of the RFCs.  ?   This (not returning delivery failure notification back to the E sender) has been discussed in other groups and many (though certainly ; not all) people agree that it's a necessary evil.  The only F alternative is to generate hundreds (and that's for a small site, likeD mine) of bogus bounced mail messages for emails that were never sent" from my domain in the first place.  F   JF Mezei is right, though, that my idea for TCPIP$SMTP_RECEIVER onlyC works when all the mail is delivered to a single machine or cluster C (anything that shares a common VMSMAIL_PROFILE.DATA file, really).  F That's not a general purpose solution but it'd help people like me andF Don a lot, and anybody with a more complex internal network could justC disable the user name checking and they'd be no worse off than they  are now.  D   Bummer!  I wish I had a source license!  It would not be very hard; to hack up TCPIP$SMTP_RECEIVER to look up the user names in F VMSMAIL_PROFILE.DATA and return "550 no such user" for any name that's
 not there.   Bob    ------------------------------  % Date: Tue, 13 Apr 2004 09:35:41 -0700 # From: "Tom Linden" <tom@kednos.com> I Subject: RE: Configuring TCPIP SMTP server to ignore undeliverable mail?? 9 Message-ID: <NDEMLKKEBOIFBMJLCECIEEFGDBAA.tom@kednos.com>      -----Original Message-----+   From: Bob Armstrong [mailto:bob@jfcl.com] '   Sent: Tuesday, April 13, 2004 9:28 AM    To: Info-VAX@Mvb.Saic.Com D   Subject: Re: Configuring TCPIP SMTP server to ignore undeliverable   mail??      8   JF Mezei <jfmezei.spamnot@istop.com> wrote in message '   news:<407AE809.E21E471F@istop.com>... D   > Not sending back a non-delivery notification in case a username    is invalid(   > goes against the spirit of the RFCs.   A     This (not returning delivery failure notification back to the G   sender) has been discussed in other groups and many (though certainly =   not all) people agree that it's a necessary evil.  The only H   alternative is to generate hundreds (and that's for a small site, likeF   mine) of bogus bounced mail messages for emails that were never sent$   from my domain in the first place.   H     JF Mezei is right, though, that my idea for TCPIP$SMTP_RECEIVER onlyE   works when all the mail is delivered to a single machine or cluster E   (anything that shares a common VMSMAIL_PROFILE.DATA file, really).  H   That's not a general purpose solution but it'd help people like me andH   Don a lot, and anybody with a more complex internal network could justE   disable the user name checking and they'd be no worse off than they 
   are now.   F     Bummer!  I wish I had a source license!  It would not be very hard=   to hack up TCPIP$SMTP_RECEIVER to look up the user names in H   VMSMAIL_PROFILE.DATA and return "550 no such user" for any name that's   not there.  G Switch to MX  and you will have solved the problem, it kicks back a 550       Bob       --- (   Incoming mail is certified Virus Free.<   Checked by AVG anti-virus system (http://www.grisoft.com).A   Version: 6.0.655 / Virus Database: 420 - Release Date: 4/8/2004     --- & Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).? Version: 6.0.655 / Virus Database: 420 - Release Date: 4/8/2004    ------------------------------    Date: 13 Apr 2004 10:43:00 -0700! From: yausername2@yahoo.com (Sun) # Subject: copy file to tape with vms = Message-ID: <ec063da7.0404130943.640546ed@posting.google.com>    Hello folks,  
 The short:  6 I need to copy a file to tape with certain parameters.  	 The long:   E I have a 9-track tape that I have dumped to a file. After editing the F file, I need to copy it back onto another tape which will then be read% and processed by one of our programs. E The problem is that while I can dump and edit the file, I do not know E how to create the tape with the same parameters as the original tape. D The original is created outside of our firm. Also, I have no controlC over the program that reads the tape either leaving me with editing E and creating a new tape as my only option where I can inject a change E into the system. Obviously, the issue here is first creating the tape F and then making sure it is right so the program that reads it gets the file as it expects.   < The label printed on the tape has the following information:  " 1600/9T/FB LRECL=00320 BLKSZ=32640 PRODUCTION DATE: 04/02/04 SL  F When in file format, I know the file consists of 320 byte records with line feeds after each record.   F It may be in 160 chunks too. When I dump it with a utility provided byF a vendor and want to put the file back together, I have to tie the 160< byte lines together to get the original 320 byte lines back.  ; My tape drive has the following logical associated with it: ( "TAPE" = "$1$MKD400:" (LNM$SYSTEM_TABLE)   Details: OpenVMS  Dec Alpha server 1200 " Tape Drive: Digital TSZ07 9-Track.  B Any help would be greatly appreciated. If any other information is necessary, let me know.    Thanks,  Sun    ------------------------------  % Date: Tue, 13 Apr 2004 15:00:08 +0200 * From: Paul Sture <nospam@sture.homeip.net>- Subject: Re: OT - Outsourced customer service 9 Message-ID: <c5go92$1gbfe$1@ID-132135.news.uni-berlin.de>    Nigel Barker wrote: M > On 12 Apr 2004 14:55:58 -0600, koehler@eisner.nospam.encompasserve.org (Bob  > Koehler) wrote:  >  > H >>  IIRC US English got ZEE from English English a long time back.  ThenJ >>  the English changed to ZED to be compatable with the French.  I don't I >>  know if the monarch ever made note.  That is, I understand there is a H >>  concept of "the Queen's Engligh", but is there a "Queen's alphabet"? >  > Q > I doubt that we changed to conform to the French. More than half our vocabulary R > is derived from French in any case although not pronunciation of most letters ofQ > the alphabet. ZED is probably an exception. K7 is French shorthand for an audio O > or video cassette perhaps non-French speakers would care to hazard a guess at  > the derivation.  >    From  : http://www.wordreference.com/english/definition.asp?en=zed  + noun  the Brit. spoken form of the letter z  U.S. word: zeeD [ETYMOLOGY: 15th Century: from Old French zede, via Late Latin from  Greek zeta]    ------------------------------  % Date: Tue, 13 Apr 2004 14:44:09 +0200 * From: Paul Sture <nospam@sture.homeip.net> Subject: Re: Postscript 9 Message-ID: <c5gnap$1dhoo$1@ID-132135.news.uni-berlin.de>    Michael Unger wrote:, > On 2004-04-12 20:31, "Hoff Hoffman" wrote: >  > p >>In article <c5ei00$p5fl$1@ID-152801.news.uni-berlin.de>, Michael Unger <spam.to.unger@spamgourmet.com> writes:H >>:Then I really don't understand why HP don't convert these PS files toI >>:PDF and make them available on the "OpenVMS Documentation" site. (From J >>:my experiences, PDF is about one order of magnitude *smaller* than PS.) >>J >>  That depends highly on the particular Postscript converter involved.   >  >          ^^^^^^^^^^^^^^  > K >>  In practice, generated Postscript can be very tight and very efficient. K >>  Unfortunately, some of the Postscript converters can be exceedingly to  D >>  extremely inefficient, and can generate huge and wasteful files. >  > C > Agreed. But as far as I know Adobe's "distiller" uses compression H > (ZIP-like) for the contents (with the exception of metadata describingN > the document) while PS is plain text. (I don't know about other converters.) > H > And it still doesn't explain why the PDF documents aren't available on
 > the web. >    They are now :-)  H I converted 'em from the PostScript files. No bookmarks, but thumbnails 
 of the pages.   , http://www.sture.homeip.net/cc065/index.html   ------------------------------  % Date: Tue, 13 Apr 2004 07:45:23 -0700 # From: "Tom Linden" <tom@kednos.com>  Subject: Restore using backup 9 Message-ID: <NDEMLKKEBOIFBMJLCECIGEFEDBAA.tom@kednos.com>   . Create backup tapes using following qualifiers2 backup/rewind/image/verify/record/ignore=interlock   Had to replace a drive mount/foreign disk mount/foreign tape backup/image tape disk  G Did I need any other qualifiers?  I suppose I should have used /verify.    Tom  --- & Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).? Version: 6.0.655 / Virus Database: 420 - Release Date: 4/8/2004    ------------------------------    Date: 13 Apr 2004 08:10:32 -0700' From: icerq4a@spray.se (David Svensson) / Subject: Re: SKHPC: A Total Eclipse of the Sun? = Message-ID: <734da31c.0404130710.1aa9e713@posting.google.com>    Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> wrote in message news:<c5gcqd$22a$1@new-usenet.uk.sun.com>...  > David Svensson wrote:  >  > > None of them.  > > G > > I am referring to the arrogance of Sun sales people during the good I > > years. "Sun is the best, everything else is shit etc." The CEO of Sun J > > and the marketing people of Sun also have a tone of arrogance, but the  > > sales people were the worst. > D > So you are talking about arrogance based on your perception of SunC > and its senior managers rather than any actions from Sun that you  > may consider to be arrogant.  B Yes, the Sun people I have been involved in were not as gentle and nice as the DEC/HP people.  E > HP's marketing retoric is full of the "S**T" you refer to sometimeseC > so full of "S**T" that the people supplying the data which HP use A > to support their claims have publically refuted HP's claims. OrmB > had you forgotten HP's spat with IDC/Gartner over their inflated > market share claims ?e  E I didn't know about in the first place, so it is not forgotten, but I C don't care much anyway. I care more about the local people who havePE not been nice when things have gone in the wrong direction from their  perspective.  D > If I was you I would be rather more concerned about actions ratherG > than words though I can see why you would not want that kind of light-, > shone on HP and OpenVMS's previous owners.  E The OpenVMS situation is known and I don't care as much of VMS as you 5 might think. My concern is most likely my Sun stocks.f   ------------------------------    Date: 13 Apr 2004 10:37:28 -0700% From: ethiobite@yahoo.com (sebastien)o Subject: Re: VMS newbiei= Message-ID: <bfd5f3ca.0404130937.5834ed1b@posting.google.com>-  o peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) wrote in message news:<newscache$pqiwvh$ele1$1@news.sil.at>...eg > In article <bfd5f3ca.0404090322.6d4500a6@posting.google.com>, ethiobite@yahoo.com (sebastien) writes:> > >How do I get the name of my e > >workstation on a network ?l >  > Praying or guessing ?H > + > Now seriously, what do you want to know ?r. > Ambigous questions beg for ambigous answers.M > Can you ask the same questions you want to know for a M$ or a U**X client ?s > H > Do you use DHCP ? Does the DHCP server provide a name for the client ?1 > Ask your network administrator these questions.t > K > Do you know $ WRITE SYS$OUTPUT F$GETSYI ("NODENAME") and $ SHOW NETWORK ? ! > Is this what you want to know ?i   Just starting under VMS, Thanks,    The $show network was  what I was searching for.   " I've been working under linux/unix  systems before, vms seems great.  
 Sebastien.   ------------------------------   End of INFO-VAX 2004.205 ************************