1 INFO-VAX	Sun, 05 Oct 2003	Volume 2003 : Issue 551       Contents: Re: AMD64 sales figures  Re: AMD64 sales figures  Re: AMD64 sales figures  Re: AMD64 sales figures 3 Re: Another huge bug: DECwindows MAIL: include file 3 Re: Another huge bug: DECwindows MAIL: include file 3 Re: Another huge bug: DECwindows MAIL: include file 3 Re: Another huge bug: DECwindows MAIL: include file 3 Re: Another huge bug: DECwindows MAIL: include file  Re: Cable for RAID Array 310 ? Re: Cable for RAID Array 310 ? Re: DCL improvements Re: DCL improvements Re: DCL improvements Re: DCL improvements@ Re: Fee Based Email (From Re: Process's PreciseMail AntiSpam...)D Re: Process's PreciseMail AntiSpam Gateway - any experience so far ?D Re: Process's PreciseMail AntiSpam Gateway - any experience so far ?D Re: Process's PreciseMail AntiSpam Gateway - any experience so far ?D Re: Process's PreciseMail AntiSpam Gateway - any experience so far ?D Re: Process's PreciseMail AntiSpam Gateway - any experience so far ?' Re: RMS provide API to directory files?  Re: SHOW DEVICE/FULL DSA' Re: Simple question : foum DCL -> ici ? ' Re: Simple question : foum DCL -> ici ? 	 test news   F ----------------------------------------------------------------------  % Date: Sat, 04 Oct 2003 14:47:03 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com>  Subject: Re: AMD64 sales figures( Message-ID: <3F7F15A6.D72C459@istop.com>   "Stanley F. Quayle" wrote:H > >    The only reason that Charon is pratical is because it's emulatingL > >    such slow processors and processor speed has increased so much in the > >    meantime. > 1 > Let's all chant, "Moore's Law is our friend"...   N Is Moore's Law about to end its rule ? I have this strange feeling that we areJ getting to a point where sprint runners have come to. Initially, they wereL able to chop off huge amounts from their time. Then it came down to seconds.? Now, they compete with differences in the hundredts of seconds.   K Note that now the emphasis isn't so much more on speed of individual chips, ) but on how you can couple multiple chips.    ------------------------------  % Date: Sat, 04 Oct 2003 14:56:00 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com>  Subject: Re: AMD64 sales figures) Message-ID: <3F7F17BE.2A0CBFC7@istop.com>    Tom Linden wrote: A > I would have thought that you might have empirically determined $ > that (with certain qualifications) > x Ghz Alpha = y Ghz Pentium   L Does Charron-VAX emulated a pure VAX architecture, and thus the VMS OS isn'tL aware at all of its trye environment, or does Charron-VAX include some extra@ drivers that provide an interface between VMS and the emulator ?  J In the case of the Insignia Solutions Windows emulator on MACs (and on VAXH too), they had a few different drivers that would overwrite the standardK windows ones. When a Windows application made a call that used that driver, M the code would then execute natively on the MAC, not only in PowerPc opcodes, M but also in MAC-OS mode. (for instance, a TCPIP request from Windows would be $ funnelled to the MAC's TCPIP stack.)   ------------------------------  % Date: Sat, 04 Oct 2003 18:53:49 -0400 * From: "Stanley F. Quayle" <stan@stanq.com>  Subject: Re: AMD64 sales figures. Message-ID: <3F7F173D.17545.A9C94A5@localhost>  ' On 4 Oct 2003 at 14:56, JF Mezei wrote: N > Does Charron-VAX emulated a pure VAX architecture, and thus the VMS OS isn'tN > aware at all of its trye environment, or does Charron-VAX include some extraB > drivers that provide an interface between VMS and the emulator ?  F CHARON-VAX emulates a VAX completely, and so the OS doesn't even know E that it's not on a "real" VAX.  CHARON-VAX has been tested by HP and   certified as a real VAX.  L > In the case of the Insignia Solutions Windows emulator on MACs (and on VAXJ > too), they had a few different drivers that would overwrite the standardM > windows ones. When a Windows application made a call that used that driver, O > the code would then execute natively on the MAC, not only in PowerPc opcodes, O > but also in MAC-OS mode. (for instance, a TCPIP request from Windows would be & > funnelled to the MAC's TCPIP stack.)  C That approach has been tried -- FreeVMS is the current open-source  F attempt to do exactly that.  However, that leaves to some very strong ? version-dependencies on the part of the VMS version "emulated".   C The pure emulation of CHARON-VAX also allows VAXELN, Digital Unix,  ( and FreeBSD to run without modification.
 --Stan Quayle  Quayle Consulting Inc.  
 ----------C Stanley F. Quayle, P.E. N8SQ  +1 614-868-1363  Fax: +1 614 868-1671 1 8572 North Spring Ct. NW, Pickerington, OH  43147 = Preferred address:  stan@stanq.com       http://www.stanq.com    ------------------------------  * Date: Sat, 4 Oct 2003 22:13:21 -0400 (EDT)+ From: Lord Isildur <isildur@andrew.cmu.edu>   Subject: Re: AMD64 sales figuresI Message-ID: <Pine.LNX.4.58-035.0310042210280.22114@unix44.andrew.cmu.edu>   C Digital UNIX (OSF1) and FreeBSD do not run on VAX. Ultrix was DEC's A unix for VAX, and NetBSD and OpenBSD run on VAX, but not FreeBSD. D (also of course the old classic BSD's from Berkeley itself.. i still? run 4.3-tahoe on a uVAX-3 for retro coolness value for example)    Isildur     , On Sat, 4 Oct 2003, Stanley F. Quayle wrote:D > The pure emulation of CHARON-VAX also allows VAXELN, Digital Unix,* > and FreeBSD to run without modification. > --Stan Quayle  > Quayle Consulting Inc.   ------------------------------  % Date: Sat, 04 Oct 2003 12:50:13 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> < Subject: Re: Another huge bug: DECwindows MAIL: include file' Message-ID: <3F7F0855.D319A79F@fsi.net>    JF Mezei wrote:  > K > Ok, I seem to be finding bugs in VMS at a faster rate that people produce  > viruses for Microsoft :-)  > I > VAX VMS 7.2. In DECwindows MAIL, while composing a message, if I try to P > include a VMS file (FILE ->INCLUDE FILE),  I am not allowed to include a fullyA > readable log file from an executing job because it is locked...  > M > So I must open a decterm windown, type the log file, then cut and paste the - > contents into the decwindows mail edit box.  > P > Why would decwindows mail try to open the file with exclusive access (probably$ > write) just to read its contents ?  F Because the process writing the file may have an exclusive lock on it.D Not sure why TYPE doesn't care (may predate some layers of the DLM -G dunno), but since EDT exhibits similar behavior, I have trouble calling 5 it a "bug". "Annoyance" may be more appropriate, IMO.   O > Sue, get your whip, and find the engineer responsible for this and get him to , > fix this quick :-) ;-) ;-) ;-) :-) ;-) ;-)  F If there's ever a fix, it'd probably be in a DECwindows after the loss of Display-PostScript. :-(   --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  $ Date: Sat, 4 Oct 2003 14:49:02 -0500% From: "Mike Naime" <mnaime@kc.rr.com> < Subject: Re: Another huge bug: DECwindows MAIL: include file7 Message-ID: <tqFfb.7726$%C5.6810@twister.rdc-kc.rr.com>   5 JF Mezei <jfmezei.spamnot@istop.com> wrote in message # news:3F7E7E21.10219CD6@istop.com... K > Ok, I seem to be finding bugs in VMS at a faster rate that people produce  > viruses for Microsoft :-)   K Mud slingers can quote whatever they want.  It's a free country that allows K you to do this.  It's also a free country that allows us to tell the idiots J that they are idiots no matter who they are, or whatever office they hold. (Example: Bill Clinton)   , FUD is FUD no matter how you try to hide it.  I > VAX VMS 7.2. In DECwindows MAIL, while composing a message, if I try to J > include a VMS file (FILE ->INCLUDE FILE),  I am not allowed to include a fully A > readable log file from an executing job because it is locked...   H File Locking is an OS level security feature.  For someone who claims toK know VMS, you should know this shit!  It does not matter if you are in mail J or at the OS level.  When you are trying to copy the entire contents of anH open file, (your Include in mail) the OS does not allow this because theL file is not closed.  The file is Open and Writelocked by another process for good reason.  K So, If I cannot copy a file at the OS level, Why should I be able to make a K copy in mail?    BUG??  I think not.  Sounds like it is functioning exactly L how it was designed to function.  This keep idiots from messing up their VMS systems!  I How does Mail know that it is a log file?  YOU know that it is a log file J because you know your system, and know what the files are doing before youL selected it.   The mail program does not have this information.  All that it5 can do is attempt to open the file that you selected.   I > So I must open a decterm windown, type the log file, then cut and paste  the - > contents into the decwindows mail edit box.   K This is the only way to look at a Writelocked Open file without closing it. % Gee, Even you seem to know that!  :-)   F > Why would decwindows mail try to open the file with exclusive access	 (probably $ > write) just to read its contents ?  D It isn't.  The original process that opened it has Exclusive Access.< Therefore your process, and any other process is locked out.  L > Sue, get your whip, and find the engineer responsible for this and get him to, > fix this quick :-) ;-) ;-) ;-) :-) ;-) ;-)   ------------------------------  % Date: Sat, 04 Oct 2003 16:48:05 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com>< Subject: Re: Another huge bug: DECwindows MAIL: include file) Message-ID: <3F7F31FC.B6CAEFA8@istop.com>    Mike Naime wrote: J > File Locking is an OS level security feature.  For someone who claims toM > know VMS, you should know this shit!  It does not matter if you are in mail  > or at the OS level.   J So you agree then that if at the OS level, the lock allows one to read theK file, as demonstrated by the ability to TYPE the file, then any application ! should be able to read the file ?   N > file is not closed.  The file is Open and Writelocked by another process for > good reason.  I Mail isn't trying to write to the file. It just wants to read it. (unless K there are some really heavy duty stuff done by an include that goes so much  beyond what TYPE needs to do)   M > So, If I cannot copy a file at the OS level, Why should I be able to make a ' > copy in mail?    BUG??  I think not.    N But if I can TYPE the file, and I can OPEN/READ/SHARE temp <log file>, then itG means that the process who controls the writing to the file has allowed N readers to the file. It is only because poorly written applications attempt to= take a greater-than-necessary lock on the file that it fails.   M I can understand COPY failing because Copy is expected to also handle indexed M files, and you don't want to copy an index file while folks are writing to it N since the copy may take a snapshot of the index at the wrong time resulting in corruption in the new copy.   F And I can understand EDT failing since it does not read the whole fileH sequentially, it only reads a portion that you need. However, TPU has no problem reading log files.  K But if it is safe to TYPE the file, if it is safe for TPU to read the file, N why should MAIL be prohibited from reading a file to include it ? In all theseK cases, the operation acesses only the data/text portion of the file and the % index (if any) itself isn't included.   M > This is the only way to look at a Writelocked Open file without closing it. ' > Gee, Even you seem to know that!  :-)   K TYPE is not the only way.  DCL can be used ( OPEN/READ/SHARE ), so can TPU. = And I suspect any C program that uses fopen to read the file.   N If, as you propose, the VMS locking system is doing its job by preventing MAILM from reading the file, this would suggest that VMS is failing to prevent TYPE  from displaying the contents.   J If TYPE is allowed to display the contents, this would mean to me that theJ process writing to the file has allowed read operations to occur. So it isJ just a matter of applications such as MAIL to open their files for readingN with the proper flags set to ensure that they can access those files which are( opened but for which reading is allowed.  K my complaint still stands: DECW$MAIL should open files for include with the . right flags to enable it to include log files.   ------------------------------  % Date: Sun, 05 Oct 2003 00:06:19 -0400 ( From: David Froble <davef@tsoft-inc.com>< Subject: Re: Another huge bug: DECwindows MAIL: include file, Message-ID: <3F7F98BB.4030701@tsoft-inc.com>   Mike Naime wrote:   7 > JF Mezei <jfmezei.spamnot@istop.com> wrote in message % > news:3F7E7E21.10219CD6@istop.com...  > K >>Ok, I seem to be finding bugs in VMS at a faster rate that people produce  >>viruses for Microsoft :-)  >> > M > Mud slingers can quote whatever they want.  It's a free country that allows M > you to do this.  It's also a free country that allows us to tell the idiots L > that they are idiots no matter who they are, or whatever office they hold. > (Example: Bill Clinton)     L While agreeing on billy clinton, I must observe that you're being a bit too P critical.  I don't think that JF wrote anything that deserved such a reply.  So  let's see how 'right' you are.    . > FUD is FUD no matter how you try to hide it. >  > I >>VAX VMS 7.2. In DECwindows MAIL, while composing a message, if I try to J >>include a VMS file (FILE ->INCLUDE FILE),  I am not allowed to include a >> > fully  > A >>readable log file from an executing job because it is locked...  >> > / > File Locking is an OS level security feature.     M Actually, totally false.  VMS does nothing to prohibit access to files.  VMS  Q does provide a rather dandy tool called the Distributed Lock Manager (DLM) which  K allows cooperating procedures to coordinate access to files and many other  Q resources.  Thus a process that wants access to a file will queue a lock request  M to the DLM which will be granted if in granting the lock there will not be a  L violation of a prior granted lock request.  If the lock is not granted, the 0 process CHOOSES to not access the file/resource.  J Normal file accesses occur using RMS, which can arguably be considered an Q application running on top of VMS, and not really part of the OS.  This argument  N gets quite murky when RMS is used by many of the utilities, library routines, N languages, and such that are bundled into VMS, as is RMS itself.  Regardless, M from a purist perspective, it's the QIO service part of the OS that actually  Q performs file access, and these services can be utilized without asking leave of  , the DLM.  It's RMS which respects DLM locks.   >  For someone who claims to& > know VMS, you should know this shit!     Opps, pot and kettle!   ' > It does not matter if you are in mail L > or at the OS level.  When you are trying to copy the entire contents of anJ > open file, (your Include in mail) the OS does not allow this because theN > file is not closed.  The file is Open and Writelocked by another process for > good reason.    O Actually, the lock on the file doesn't have to be denying all access, just the  A access method(s) granted exclusively to the already granted lock.     M > So, If I cannot copy a file at the OS level, Why should I be able to make a M > copy in mail?    BUG??  I think not.  Sounds like it is functioning exactly N > how it was designed to function.  This keep idiots from messing up their VMS
 > systems! > K > How does Mail know that it is a log file?  YOU know that it is a log file L > because you know your system, and know what the files are doing before youN > selected it.   The mail program does not have this information.  All that it7 > can do is attempt to open the file that you selected.  >  > I >>So I must open a decterm windown, type the log file, then cut and paste  >> > the  > - >>contents into the decwindows mail edit box.  >> > M > This is the only way to look at a Writelocked Open file without closing it. ' > Gee, Even you seem to know that!  :-)     K Well, if you assign a channel to the file, and read it using QIOs, there's  P nothing standing guard that will prohibit you from doing so.  (Not going to get - into directory info not yet written to disk.)    Dave   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Sun, 05 Oct 2003 00:20:53 -0400 ( From: David Froble <davef@tsoft-inc.com>< Subject: Re: Another huge bug: DECwindows MAIL: include file, Message-ID: <3F7F9C25.9050409@tsoft-inc.com>   JF Mezei wrote:    > Mike Naime wrote:  > J >>File Locking is an OS level security feature.  For someone who claims toM >>know VMS, you should know this shit!  It does not matter if you are in mail  >>or at the OS level.  >> > L > So you agree then that if at the OS level, the lock allows one to read theM > file, as demonstrated by the ability to TYPE the file, then any application # > should be able to read the file ?     K Here's the logic flaw.  'Should be able to read' and 'should read' are two  O entirely seperate issues.  In the first case, if the log file is opened ACCESS  O WRITE ALLOW READ they the ability to open the file for reading is there.  Note  O that usually two processes cannot both open a sequential file for ALLOW WRITE,  D and that there is a difference between ALLOW WRITE and ALLOW MODIFY.    N >>file is not closed.  The file is Open and Writelocked by another process for >>good reason. >> > K > Mail isn't trying to write to the file. It just wants to read it. (unless M > there are some really heavy duty stuff done by an include that goes so much  > beyond what TYPE needs to do)  >  > M >>So, If I cannot copy a file at the OS level, Why should I be able to make a ' >>copy in mail?    BUG??  I think not.   >> > P > But if I can TYPE the file, and I can OPEN/READ/SHARE temp <log file>, then itI > means that the process who controls the writing to the file has allowed P > readers to the file. It is only because poorly written applications attempt to? > take a greater-than-necessary lock on the file that it fails.  > O > I can understand COPY failing because Copy is expected to also handle indexed O > files, and you don't want to copy an index file while folks are writing to it P > since the copy may take a snapshot of the index at the wrong time resulting in > corruption in the new copy.  > H > And I can understand EDT failing since it does not read the whole fileJ > sequentially, it only reads a portion that you need. However, TPU has no > problem reading log files. > M > But if it is safe to TYPE the file, if it is safe for TPU to read the file, P > why should MAIL be prohibited from reading a file to include it ? In all theseM > cases, the operation acesses only the data/text portion of the file and the ' > index (if any) itself isn't included.     P It's not necessarily SAFE to TYPE the file.  TYPE will show what's been written N to the file, but doesn't assure that nothing else will be written to the file.  M >>This is the only way to look at a Writelocked Open file without closing it. ' >>Gee, Even you seem to know that!  :-)  >> > M > TYPE is not the only way.  DCL can be used ( OPEN/READ/SHARE ), so can TPU. ? > And I suspect any C program that uses fopen to read the file.     S It's RMS that uses the DLM.  Any I/O at a lower level can choose to ignore the DLM.     P > If, as you propose, the VMS locking system is doing its job by preventing MAILO > from reading the file, this would suggest that VMS is failing to prevent TYPE  > from displaying the contents.  > L > If TYPE is allowed to display the contents, this would mean to me that theL > process writing to the file has allowed read operations to occur. So it isL > just a matter of applications such as MAIL to open their files for readingP > with the proper flags set to ensure that they can access those files which are* > opened but for which reading is allowed. > M > my complaint still stands: DECW$MAIL should open files for include with the 0 > right flags to enable it to include log files.    M If the design of DECW$MAIL is to only send complete files that are included,  E then I'd disagree with this statement.  What you're discussing is an  P implementation decision.  You may not like the decision, but it's certainly NOT  a bug.  N A bug is when something is documented to perform in a specific manner, and it   does not perform in that manner.   Dave   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Sat, 04 Oct 2003 19:37:44 +0200 9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com> ' Subject: Re: Cable for RAID Array 310 ? ' Message-ID: <3F7F0568.F11D1CE7@aaa.com>    INFORMENTOR AB wrote:  > F > I suppose it's the KZPBA-CB diff SCSI-adapter? [KZPBA-CA (CX) is SE]   It sounds like that card, yes.  * > IIRC KZPBA is software terminated ?? ok?  + In what software ? from the console (>>>) ?   A > Correct termination in both ends?  Check HSZ20 jumper settings?   . I belive all shold be OK with the terminators. Just "out of the box".  	 Jan-Erik.    ------------------------------  $ Date: Sun, 5 Oct 2003 00:39:22 -04000 From: "Jeff Morgan" <vmswiz@geonospamcities.com>' Subject: Re: Cable for RAID Array 310 ? - Message-ID: <blo7f5$f01r$1@news3.infoave.net>   J For an alternative, here's the cable I bought from www.scsisource.com (aka pc-pitstop.com) for my RA310/HSZ20.  I Qty  Part No        Name                                    Price   Total L  ---  -------------  --------------------------------------  ------  ------ K    1  ESC-H6868L-36  3ft HD68 Male to HD68 Male U160/LVD/SE  $19.50  $19.50    Works great!  I Now, does anyone know where I can get a new cache battery? I haven't gone K inside the box yet, but I fear it may be a difficult part since the owner's I manual says "call Digital and your field service rep will bring you a new  HSZ20 controller"    Yikes!  L Apparently, all I can do is jbod without the battery. Nice old box though. II loaded it with 5 x 18GB SCA-2 IBM drives from Hard Drive Outlet for about  $50   (                                     Jeff    3 "Jan-Erik Sderholm" <aaa@aaa.com> wrote in message ! news:3F7F0568.F11D1CE7@aaa.com...  > INFORMENTOR AB wrote:  > > G > > I suppose it's the KZPBA-CB diff SCSI-adapter? [KZPBA-CA (CX) is SE  >   > It sounds like that card, yes. > , > > IIRC KZPBA is software terminated ?? ok? > - > In what software ? from the console (>>>) ?  > C > > Correct termination in both ends?  Check HSZ20 jumper settings?  > 0 > I belive all shold be OK with the terminators. > Just "out of the box". >  > Jan-Erik.    ------------------------------  % Date: Sat, 04 Oct 2003 12:44:38 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>  Subject: Re: DCL improvements ' Message-ID: <3F7F0706.B697F2F8@fsi.net>    H Vlems wrote: > [snip]N > 3) A CHECK command would be nice: it would check the syntax of a DCL command* > procedure without actually executing it.  @ Would be nice, yes, but probably not comprehensive if it doesn't> execute. Sometimes portions of commands or entire commands areC "compiled" by code. The results could not be checked if code didn't  execute.  M > 4) F$GETDVI("<diskdevice>","AVL") returns an error message when a device is L > not available, and crash the DCL code. Would it break other software if it > would return FALSE instead?   D I seem to recall an extensive thread on that topic not long ago. OneG camp agrees that a valid device name where the device is not present in G teh system should cause "AVL" to return "FALSE" rather than device does G not exist. The other camp agrees that this is what the "EXISTS" ketword  is for. Six of one...   L > 5) Is it possible to implement FUNCTIONs with parameters that allow return	 > values?  >  >     FUNCTION FUNC(I,J) >     .  >     .  >     RETURN  (I+J)   C That'd be like user-defined lexical functions, which would also "be  nice".  H Something I found useful many years ago in an interpretive BASIC was the ability to do this:    1010 GOSUB 5010 4 1020 GOTO 9000	! The subroutine encountered an error" 1030 REM Resume mainstream code... 	. 	. 	. 5010 (some code) 5020 IF condition RETURN+1 5030 IF not-condition RETURN  ? Line 5020 would return to the second line after the GOSUB. In a F non-structured language, that's one way to reduce code and standardizeD error handling, though not the best. Dunno if anyone else would findC that useful, but I've wished for it in DCL on occasion - not often.    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  $ Date: Sat, 4 Oct 2003 21:03:03 +0200( From: "H Vlems" <hvlems.nieuw@zonnet.nl> Subject: Re: DCL improvements 9 Message-ID: <bln5kp$ei3hl$1@ID-143435.news.uni-berlin.de>   > "David J. Dachtera" <djesys.nospam@fsi.net> schreef in bericht! news:3F7F0706.B697F2F8@fsi.net...  > H Vlems wrote:
 > > [snip]H > > 3) A CHECK command would be nice: it would check the syntax of a DCL command , > > procedure without actually executing it. > B > Would be nice, yes, but probably not comprehensive if it doesn't@ > execute. Sometimes portions of commands or entire commands areE > "compiled" by code. The results could not be checked if code didn't 
 > execute.  K Agreed, but it'd be better than having nothing at all. ISTR that there is a L DCL-checker somewhere out there. Having similar functionality built-in wouldC at least ensure version compatibility with respect to new features.  > L > > 4) F$GETDVI("<diskdevice>","AVL") returns an error message when a device isK > > not available, and crash the DCL code. Would it break other software if  it > > would return FALSE instead?  > F > I seem to recall an extensive thread on that topic not long ago. OneI > camp agrees that a valid device name where the device is not present in I > teh system should cause "AVL" to return "FALSE" rather than device does I > not exist. The other camp agrees that this is what the "EXISTS" ketword  > is for. Six of one...   3 I remembered that thread too, hence the request :-)  > G > > 5) Is it possible to implement FUNCTIONs with parameters that allow  return > > values?  > >  > >     FUNCTION FUNC(I,J)	 > >     . 	 > >     .  > >     RETURN  (I+J)  > E > That'd be like user-defined lexical functions, which would also "be  > nice". > J > Something I found useful many years ago in an interpretive BASIC was the > ability to do this:  >  > 1010 GOSUB 5010 6 > 1020 GOTO 9000 ! The subroutine encountered an error$ > 1030 REM Resume mainstream code... > .  > .  > .  > 5010 (some code) > 5020 IF condition RETURN+1 > 5030 IF not-condition RETURN > A > Line 5020 would return to the second line after the GOSUB. In a H > non-structured language, that's one way to reduce code and standardizeF > error handling, though not the best. Dunno if anyone else would findE > that useful, but I've wished for it in DCL on occasion - not often.  > I Neta, but GOSUB may offer a similar possibility: IF not-OK-condition THEN & (set error value; GOSUB error handler)L The error handler decides whether to return or abort the procedure. This hasK more to do with coding style and preferences than functionality. There's no / such thing as a computed GOTO in DCL either :-)   < Let's see if Guy Peleg agrees; if he sees the thread at all.   Hans   ------------------------------  % Date: Sat, 04 Oct 2003 16:18:38 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com> Subject: Re: DCL improvements ) Message-ID: <3F7F2B16.B7DFD38A@istop.com>    H Vlems wrote:M > more to do with coding style and preferences than functionality. There's no 1 > such thing as a computed GOTO in DCL either :-)      $mylabel = "LOOP1" $goto 'mylabel     I call that a "computed" goto.   ------------------------------  $ Date: Sat, 4 Oct 2003 23:26:09 +0200+ From: "Hans Vlems" <hvlems.nieuw@zonnet.nl>  Subject: Re: DCL improvements 9 Message-ID: <blndtj$e942s$1@ID-143435.news.uni-berlin.de>   9 "JF Mezei" <jfmezei.spamnot@istop.com> schreef in bericht # news:3F7F2B16.B7DFD38A@istop.com...  > H Vlems wrote:L > > more to do with coding style and preferences than functionality. There's no3 > > such thing as a computed GOTO in DCL either :-)  >  >  > $mylabel = "LOOP1" > $goto 'mylabel >  >   > I call that a "computed" goto.  ? I was thinking FORTRAN. OTOH your example may be expanded into:    $ i=1  $loop: $   if ... then goto case'i  . 
 $   goto loop  .  $ case1: .    ------------------------------  $ Date: Sat, 4 Oct 2003 21:57:33 +0200+ From: "Rik Steenwinkel" <rsteenw@xs4all.nl> I Subject: Re: Fee Based Email (From Re: Process's PreciseMail AntiSpam...) : Message-ID: <Ysd2q9KROUC1-pn2-u6kH2CjUbl71@news.xs4all.nl>  F On Wed, 1 Oct 2003 05:04:58 UTC, JF Mezei <jfmezei.spamnot@istop.com>  wrote:  O } You want the sender to give you a summary of the attachement ? He'll give you L } a nice summary you are happy with, and when the recipient gives you the goK } ahead, you then send contents which totally differ and contain the virus.   B OK, if the sender promises to send 31849 bytes of attachment, you F close the pipe at 31850 bytes. Or at any other point where the actual * transmission violates the initial message.   --  > // Rik Steenwinkel  #  VMS mercenary  #  Enschede, Netherlands // 1024D/CDBAE5C1    ------------------------------  $ Date: Sat, 4 Oct 2003 21:40:56 +0200+ From: "Rik Steenwinkel" <rsteenw@xs4all.nl> M Subject: Re: Process's PreciseMail AntiSpam Gateway - any experience so far ? : Message-ID: <Ysd2q9KROUC1-pn2-0sO6r2dRfGcd@news.xs4all.nl>  @ On Wed, 1 Oct 2003 02:00:44 UTC, david20@alpha2.mdx.ac.uk wrote:  P } The receiver is in compete control. If it doesn't like something it sends back+ } a 5xx response and closes the connection.   F You mean the receiver as the end-user's MTA. I read Don's protocol as F the actual end-user controlling whether the message body gets fetched @ or not. Although, for offline reading, that functionality being F delegated to the receiver's MTA being desirable, probably through some whitelist mechanism.     --  > // Rik Steenwinkel  #  VMS mercenary  #  Enschede, Netherlands // 1024D/CDBAE5C1    ------------------------------  $ Date: Sat, 4 Oct 2003 21:50:55 +0200+ From: "Rik Steenwinkel" <rsteenw@xs4all.nl> M Subject: Re: Process's PreciseMail AntiSpam Gateway - any experience so far ? : Message-ID: <Ysd2q9KROUC1-pn2-ldey2ZnX2t82@news.xs4all.nl>  / On Mon, 29 Sep 2003 19:00:34 UTC, Mike Bartman  " <omni@foolie.omniphile.com> wrote:  7 } On Mon, 29 Sep 2003 12:41:44 +0200, "Rik Steenwinkel"  } <rsteenw@xs4all.nl> wrote: } G } >Leaving the mail fees issue for a moment, Don's mail protocol still  G } >has merit without it. As said, it allows the recipient much greater  @ } >control whether to accept (rather: collect) a message or not. } H } That means the user has to do more work, and take more time, and couldH } STILL get SPAM, since SPAMmers tend to lie.  The user might think it'sH } a message he wants to read, request it, pay for it, and then find thatF } the headers were inaccurate and he just got to pay for junk mail.  I! } don't think that's a benefit...   C Like I said, view the fees issue separately for a moment. It's not  F essential to the protocol. And you're 'paying' (in time and bandwidth)F for spam now anyway, unless it's caught by whatever anti-spam measures your ISP and you have in place.   F } The basic idea is that when mail gets sent to you, your server sends> } back an address verification before you get to the mail.  No) } verification and the mail is deleted.     F And Don's protocol is rather similar, but rather asks the receiver if B this is a mail he wants to receive. Answers can be used to feed a D whitelist for auto-retrieval (you don't need a blacklist here) just 	 the same.    --  > // Rik Steenwinkel  #  VMS mercenary  #  Enschede, Netherlands // 1024D/CDBAE5C1    ------------------------------  $ Date: Sat, 4 Oct 2003 21:43:42 +0200+ From: "Rik Steenwinkel" <rsteenw@xs4all.nl>	M Subject: Re: Process's PreciseMail AntiSpam Gateway - any experience so far ?a: Message-ID: <Ysd2q9KROUC1-pn2-dfiP6MhdudRp@news.xs4all.nl>  F On Mon, 29 Sep 2003 18:21:44 UTC, JF Mezei <jfmezei.spamnot@istop.com> wrote:  N } You are assuming that the message originator is still online at the time theO } recipient gets the request to send the message. What happens if you have justEF } walked out of a wifi coverage area and the sending node is no longer } reacheable ?  B Are you, as a mobile or occasionally connected user, sending mail , directly to the receiver's MTA? I think not.   --  > // Rik Steenwinkel  #  VMS mercenary  #  Enschede, Netherlands // 1024D/CDBAE5C1y   ------------------------------  # Date: Sun, 05 Oct 2003 00:25:22 GMTp. From: Express Designer <anonymous@pacbell.net>M Subject: Re: Process's PreciseMail AntiSpam Gateway - any experience so far ?w+ Message-ID: <3F7F65AA.5E21FA7C@pacbell.net>r   david20@alpha1.mdx.ac.uk wrote:p > W > In article <3F7B8754.3623EC0F@pacbell.net>, Don Sykes <anonymous@pacbell.net> writes:p > >e > > " > >david20@alpha2.mdx.ac.uk wrote: > >>Z > >> In article <3F79CE46.5E40D800@pacbell.net>, Don Sykes <anonymous@pacbell.net> writes: > >> > > >> >% > >> >david20@alpha2.mdx.ac.uk wrote:  > >> >>FR > >> >> In article <blag7c$kfg$1@news.mdx.ac.uk>, david20@alpha2.mdx.ac.uk writes:^ > >> >> >In article <3F789087.7B990DE0@pacbell.net>, Don Sykes <anonymous@pacbell.net> writes:
 > >> >> >>
 > >> >> >>) > >> >> >>david20@alpha2.mdx.ac.uk wrote:  > >> >> >>>e` > >> >> >>> In article <3F74CF7F.9D265CA@pacbell.net>, Don Sykes <anonymous@pacbell.net> writes:
 > >> >> >>> >o
 > >> >> >>> >t, > >> >> >>> >david20@alpha2.mdx.ac.uk wrote: > >> >> >>> >>f > >> >> >>> >> In article <vn5s22g2nrds0e@news.supernews.com>, "John Vottero" <John@mvpsi.com> writes:; > >> >> >>> >> ><david20@alpha2.mdx.ac.uk> wrote in messaget3 > >> >> >>> >> >news:bkuhsq$dk3$1@news.mdx.ac.uk...oG > >> >> >>> >> >> In article <3F71D664.D92AAC37@pacbell.net>, Don Sykes / > >> >> >>> >> ><anonymous@pacbell.net> writes:- > >> >> >>> >> >> >-2 > >> >> >>> >> >> >david20@alpha2.mdx.ac.uk wrote: > >> >> >>> >> >> >>J > >> >> >>> >> >> >> In article <3F70934A.3C36DD45@pacbell.net>, Don Sykes/ > >> >> >>> >> ><anonymous@pacbell.net> writes:o > >> >> >>> >> >> >> > > >> >> >>> >> >> >l > >> >> >>>  > >>S > >> The receiver is in compete control. If it doesn't like something it sends backe. > >> a 5xx response and closes the connection. > >iB > >The receiver can set aside accepting an email until a time moreA > >convenient to them. They're not required to accept mail at thehJ > >convinience of the sender. This allows options that are impossible in aJ > >one phase protocol, like retrieving large or low priority emails duringE > >slow times and sending a pre-email notification to the user - e.g. K > >       I have a request from smutpeddler@legitdomain.com, do you want to E > >accept a 2MB avi file? do you want to charge him? If so, how much?eA > >that sort of thing. A one phase protocol requires a continuous 6 > >interaction until the mail is rejected or accepted. > >: > L > You are at least one level away from the sender or receiver at the centralK > mailhub level. Your default policy is you are going to delay all mail not1$ > explicitly requested by the user ?  6 Again. That's up to what the domain (ESP) wants to do.  Q > My mail users complain that mail is not instantaneous. They expect it to all beaO > instantaneous. Adding extra delays is not acceptable. Even if a simple methodXO > is supplied for them to update what they want to delay on the central mailhub"K > they won't immediately update it after they get off the phone to that new O > contact who is going to mail them - that is if they remember to get his email . > address rather than just telling him theirs.  E In your situation, you would probably wouldn't delay based on size or A priority. Adding the 2nd phase could take only an extra couple ofe seconds.H As for your new customer who just got off the phone with a new customer,H he would have told that new customer, "be sure to start the Subject withF 'NEW123'", a code which he previously set up for all new customers, so9 the receiver ESP will pass it on without charge or delay.   M > Anyone running a central mailhub will immediately turn off any such delays.e >  > >> > >>R > >> >> At the moment there does exist a small possiblity of spoofing however your@ > >> >> system is exactly as vulnerable as the current standards > >> >N > >> >I don't agree, because in phase 2 the receiver initiates the connection.N > >> >So unless the spoofer can control the DNS I don't see how they will ever" > >> >get their message delivered.M > >> >And if they can control the DNS, they can jolly well force all of us tod4 > >> >a smut site when we try to http to Google.com. > >>N > >> Yes as I say a small chance of spoofing which is exactly the same for theB > >> current protocol since it can do exactly the same DNS lookup.R > >> Since this is at the central mailhub rather than the desktop sender level theS > >> chances of anyone wanting to spoof this are pretty remote anyway. Any spoofingAF > >> would be done between the desktop system and the central mailhub. > >3H > >Give me an example of what you mean. I don't see it. When the desktopK > >user goes to retrieve his mail he logs onto a POP or IMAP server, passesQJ > >his userid & password and downloads the mails that are waiting for him." > >Where would the spoofing occur? > >D > N > I'm talking about in sending the mail from the desktop to the central server" > in order to avoid being charged.  @ You mean desktop user 'A' will send an email to the sending ESP,C pretending to be desktop user 'B'? Why don't you require a userid &e- password? You must have the same problem now.w   >  > >>Q > >> As to controlling the DNS and redirecting to smut sites - yes it happens all)P > >> the time. Though the preference is usually to redirect to their own versionJ > >> of a companies site so they can gather credit card and other details. > >> > >> > > >> >> - this can be improvedO > >> >> in the future by use of server certificates and SSL/TSL to provide moreh* > >> >> trustworthy mutual authentication. > >> >> S > >> >> The problems of identity are to do with tracking within organisations, withlM > >> >> non-compliant and badly configured mail systems and with open relays.-P > >> >> These are NOT protocol issues.  Nobody should be running an open-relay -: > >> >> there is even an RFC which states this - RFC 2505. > >> >N > >> >I don't run an open relay and I can't stop the 100's of spams per day orE > >> >force anyone to pay if I deliver a spam message to an end user.b > >> > > >>S > >> But apart from the fee paying idea which won't work unless you really know whoyQ > >> to charge the fee to your protocol doesn't provide anything extra which willw > >> control spammers. > >-2 > >Apart from that, Mrs Lincoln, how was the play?# > >The fee IS the pertenient point.< > >e > >>M > >> >I agree that identity problems WITHIN an organisation are not solved byDJ > >> >this, but that' by design. IMO all those problems are implementationJ > >> >issues, ones, I might add, that are just as likely to cause problems > >> >using any protocol.V > >> > > >>T > >> What I am saying is your protocol is irrelevent. Communications between centralQ > >> mailhubs are already adequately controlled. It is the injection of spam intoeN > >> the sending central mailhubs and direct sending of mail bypassing central% > >> mailhubs which need controlling.. > >a8 > >How can you bypass the receiving ESP? Example please. > K > I'm talking abiout the current setup. Not everybody has central mailhubs,tQ > not everybody has firewall rules blocking direct sending from desktop machines.   G Everybody clearly has a receiving ESP. Bypassing the sending domain ESP E wouldn't help you in the new protocol. At best you could pass a bogus F phase 1, but when the receiving mail's ESP went to the sending domain, the mail would exist.    >  > > O > >> Unfortunately even after solving those problems we will still be left withlS > >> open-relays and misconfigured or non-compliant systems. The systems which wererO > >> being put in place to handle those - blacklists - have been hounded out oftN > >> existence by court proceedings and latterly by targeted denial of service
 > >> attacks.  > >>O > >> >> I note in passing that your protocol is actually pretty weak on this :-s > >> >>eQ > >> >> "The receiving ESP has no obligation to relay messages outside of its owna > >> >> domain"s > >> >J > >> >The point of this statement is to clarify that this protocol doesn'tJ > >> >deal with issues of routing beyond the receiver ESP. If they want to7 > >> >route beyond their domain, that's their business.  > >> > > >>: > >> NO system should ever be configured as an open-relay. > >> > >> >> W > >> >> The only features of your protocol different from current ESMTP implementationsh > >> >> are :- > >> >>eP > >> >> 1) Two separate connections  - As stated above this is pretty pointless. > >> >L > >> >Not at all pointless as I mentioned. Control of the mail receipt is in  > >> >the hands of the receiver. > >>P > >> Control in the current protocol is in the hands of the receiver without any" > >> need for a second connection. > >nE > >Partial control in the current protocol. Full control in a 2 phase; > >protocol. > >- > K > I get the impression that your model is the telephone system and dialbackMI > modems. IP has always had a super charged version of caller-id display. J > It knows what number called it and can do a lookup in it's equivalent of? > yellow pages - the DNS - to confirm validity of that address.mO > Dialback gains you nothing - Many companies still use it but the major reason > > nowadays is so that the Company is paying for the phonecall. >  > >> > >> >T > >> >> 2) The provision of attachment numbers, sizes and mime types up front before% > >> >>    the actual data is passed. - > >> >>    I'm not sure of the point of this.d > >> >I > >> >The point is to allow the receiver ESP to use this info in decidingiM > >> >whether to accept this message. Maybe a policy is not to accept msword, J > >> >due to the infection possibilities. Or maybe an organization doesn't > >> >want avi or other video. > >> >. > >> >>   Virus writers and Microsoft products1 > >> >>    either lie or ignore this information.  > >> >L > >> >Yes, they can, but if you try to launch an msword attachment as an exeF > >> >it's not going to work. Mail readers use the MIME info to decideN > >> >whether, and how, to launch it. So lying isn't going to get you what you > >> >want.g > >> >I > >> Microsoft products ignore the MIME type they use the file extension.lP > >> This is why most mailhubs have a large - ever growing - list of banned file > >> extensions. > >lJ > >That's Microsoft's problem. Maybe they'll be more MIME compliant in the4 > >future if they see it's better for them to do so. > >  > K > No it's your (and everybody elses) problem. Why should Microsoft change ?nQ > People have been complaining about Microsoft's attitude to standards for years. H > But so long as they have a dominent desktop position and can use theirP > tweaking/ignoring of standards to allow them to leverage that for dominence in) > other areas they aren't likely to stop.sI > Microsoft are standards compliant - it's just it's their version of the' > standard.  >  > >>* > >> >> Mime is also not the only encodingV > >> >>    mechanism used in mail messages - eg uuencoded mail, pgp encrypted mail etcT > >> >>    Also since this is at the central mailhub level only organisational level0 > >> >>    checks and blocks can be done anyway. > >> >M > >> >That depends completely on your implementation. For businesses like HP,eN > >> >they probably would use organizational-wide parameters. AOL on the otherN > >> >hand will defininately not. They will allow each user to specify all the. > >> >options for themselves, including price. > >> >T > >> How ? Your protocol is central mailhub to central mailhub it says nothing about7 > >> any mechanism for a user to request these options.r > >tJ > >Of course it doesn't. Why should it? SMTP doesn't tell you to do an RBL= > >lookup, or to go check a user list when you get a RCPT_TO:fC > >anybody@abc.com. That's up to whoever is implemting the receiver I > >service. E.G. HP's TCPIP SMTP Service doesn't even give you the option  > >to check a user's list. > >nC > SMTP never touted these as advantages to it's protocol - you are. ; > Hence you need to provide something more than handwaving.o  A I am. That's why I put this idea on my website and then asked foreF comments and suggestions. Even though you disagree with the concept of$ pay mail, your comments are helpful.   > M > To get people  to buy into your new protocol you need to prove it is betterwP > than the existing protocols. People have spent a lot of money on systems usingI > the existing protocols - they will need a bl**dy good reason to move tot > something else.   H There is one BIG reason: a billion spam emails a day...maybe 10 billion!  8 > So far I don't see anything which improves on existing > protocols.   We disagree.   >  > >>. > >> >> I cannot see any reason for wanting toC > >> >>    specify individual size blocks for different Mime types.  > >> >N > >> >Options. Just because you can't see it now, doesn't mean you won't see aK > >> >reason for it in the future. The "cost" to provide it is zero, so why  > >> >not give the option. > >> >W > >> >>    ESMTP can already apply blocks up front for actual size of messages, numbersy > >> >>    of recipients etc > >> >>.) > >> >> 3) The provision of fee charging.l > >> >> V > >> >>    Assuming that 100% identification could be achieved which is a prerequisite# > >> >>    for any charging system.nU > >> >>    Firstly the costs per MB or whatever should be up front before any sending V > >> >>    of from or recipient addresses. THis could be achieved with ESMP with costsL > >> >>    being relayed back to the sender in response to the EHLO command.V > >> >>    Rather than providing a new protocol the additional commands required for aV > >> >>    feebased system could be added to ESMTP - thats the whole point of ESMTP it > >> >>    is extensible.  > >> >K > >> >Unless ESMTP provides that 2nd phase, it's not going to be effective.i > >> > > >>R > >> As I have said time and time again your second connection provides absolutely
 > >> nothing.a > >s > >See previous responses. > >c > >> > >> >>SP > >> >>    In short I don't see that this protocol provides anything not alreadyT > >> >>    available in the existing protocols (or which could not be added - in theS > >> >>    case of charging). In particular it does not provide any additional helpt8 > >> >>    in identifying the sender of a piece of mail. > >> >>o > >> >H > >> >That's the beauty, I don't have to care who the sender is if I can% > >> >collect a fee for receiving it!e > >> > > >>R > >> Good luck in trying to collect that fee. The lawyers will make a lot of money > >> I doubt you will. > > H > >I'm not trying to make a lot of money on this. If there is continuingE > >trouble collecting fees from an ESP they will be marked as such by  > >eosawki.org.e > >e > K > Sorry I didn't mean you personally. Just saying that any fee based systemnP > which doesn't provide full end to end accountability will be open to all sorts > of legal challenges. >   H Ideally, a user to user, guaranteed receipt is the best, but MUCH harder to deliver on.C Legally, in my model, most ESPs would put in as part of the serviceoC acceptance that paying for an email cannot guarantee the final useriG would get it. They could only guarantee that a user's ESP would get it,e4 but after that of course they couldn't guarantee it.     Have VMS, Will Travel  Wire paladin, San Francisco>   (paladinATalphaseDOTcom)   ------------------------------  # Date: Sun, 05 Oct 2003 00:39:25 GMT . From: Express Designer <anonymous@pacbell.net>M Subject: Re: Process's PreciseMail AntiSpam Gateway - any experience so far ?a+ Message-ID: <3F7F68F6.26BD9252@pacbell.net>g   david20@alpha2.mdx.ac.uk wrote:i > W > In article <3F79CF7E.20753515@pacbell.net>, Don Sykes <anonymous@pacbell.net> writes:a > >r > > " > >david20@alpha2.mdx.ac.uk wrote: > >>m > >> In article <Ysd2q9KROUC1-pn2-tn8Iv2d2WoN9@news.xs4all.nl>, "Rik Steenwinkel" <rsteenw@xs4all.nl> writes:cG > >> >On Tue, 23 Sep 2003 13:49:54 UTC, david20@alpha1.mdx.ac.uk wrote:- > >> >P > >> >} How will you enforce this. To work it has to be applied worldwide to allT > >> >} "ISPs" (or at least a majority - since I suppose you would refuse to receive+ > >> >} mail from those who don't sign up). Q > >> >} However until a majority have signed up it pays for an ISP NOT TO charge.oS > >> >} They will get more customers if they don't charge and their competitor downr > >> >} the road does charge.l > >> >} T > >> >} Also until all systems are charging you will be causing chaos since you willE > >> >} have destroyed any hope of consistent reliable mail delivery.  > >> >I > >> >Leaving the mail fees issue for a moment, Don's mail protocol still I > >> >has merit without it. As said, it allows the recipient much greatersI > >> >control whether to accept (rather: collect) a message or not. Also,tK > >> >the meta-message gives a From: someone@sender.domain , so your MUA orcI > >> >MTA then resolves sender.domain and requests its MX to hand out theiK > >> >actual message associated with the Message-ID in the meta-message. SoeL > >> >then, even if a spammer puts a plausible-looking From: and Subject: inF > >> >the meta-message (based on which you decide to accept), the mailD > >> >servers in the From: domain won't have the message the spammerJ > >> >intended to send you, and will probably not even have a message with! > >> >matching Message-ID at all.o > >> >R > >> As the second version of this makes clear this protocol is central mailhub toJ > >> central mailhub. Neither the sender or receiver are the desktop user. > >eJ > >No, but they can act as proxies for the desktop user and if they chooseH > >to implement it, each desktop user can decide on what, who, when, how > >big and how much. > >kR > >> The protocol provides pretty much nothing which isn't already provided by theR > >> existing protocols. The second connection provides nothing since the existingK > >> protocol allows the receiver to end the connection at any point in theeS > >> dialogue. ESMTP already allows for rejecting messages based on size and numbereS > >> of recipients etc. You can already do reverse lookups of from domains, you candT > >> already have lists of blacklisted ip addresses and domains (either generated byK > >> the people looking after the mailhubs or using centralised RBL lists). O > >> The protocol proposed does NOT provide a mechanism for individual users to F > >> specify additinal blocks to be provided at the receiving mailhub. > >> > >e3 > >By design, because it's an implementation issue.s > >y > P > Like getting mail from a mail store is an implementation issue which is why we$ > have protocols like POP and IMAP ?  C Not the same thing at all, because a protocol describes a method ofnE delivery. A implementation issue is how your particular site uses the>	 protocol.EE POP and IMAP would work as they do today, I would guess, because they E just provide a method of transfer for stored emails that have already % gone through the various validations.    > J > If you are going to tout this as an advantage of your system you need toN > provide a mechanism to accomplish it. Saying everything is an implementation > issue is a cop out.i  H Not so. It's just that each domain may have different requirements. SomeG may only use a  simple list of parameters, others, a sophisticated rulecB based system, while others may allow an interactive component. TheE protocol provides the rules to follow not how you're going to use it.r   -- g   Have VMS, Will Travel  Wire paladin, San Franciscoc   (paladinATalphaseDOTcom)   ------------------------------  # Date: Sun, 05 Oct 2003 05:07:52 GMTd; From: "John Gemignani, Jr." <jon-nope@thiswontworkossc.net> 0 Subject: Re: RMS provide API to directory files?= Message-ID: <IGNfb.13510$qj6.1708419@news1.news.adelphia.net>i  H "Bob Koehler" <koehler@eisner.nospam.encompasserve.org> wrote in message- news:ql+2XbtfDUqX@eisner.encompasserve.org...i? > In article <139d5a58.0310020632.41e554d0@posting.google.com>, , cgilley@bravewc.com (Charles Gilley) writes:J > > I want to be able to do a dir/total via code.  I know I can use systemH > > to execute dir/total.  Is there an API call to do this? How does theH > > DCL dir/total command execute so quickly?  lib$find_file is just too	 > > slow.c >mF >    directory.exe was written long before lib$find_file was supplied.D >    RMS contains all the tools you need to do this stuff "by hand". >5E >    I've been down the same path.  Any data produceable by DIR comes1D >    from the FAB, RAB, NAM, or an XAB.  To get at it in a hurry youD >    must use RMS asynchronously, start multiple RMS calls then haveD >    an AST process the data and restart the call for the next file.@ >    Since VMS ASTs are serialized, you only need to supply one. > G >    By simply keeping 3 RMS calls outstanding I was able to solve thiseK >    kind of performance problem for another group years ago.  I was lucky,k@ >    they had already written the code to use RMS synchronously. >2J >    You will need to use $SEARCH, $OPEN, and $CLOSE.  It's the $OPEN thatG >    takes time, so keep multiple asynchronous $OPENs going.  Setup the ? >    FABs and whatever other RMS blocks you need ahead of time.. >   J Actually, there is no need to do open and close.  You can use XQP QIO's toG read the file's attributes with the information in the NAM.  You keep a-
 channel toL the device specified in the NAM and use the FID returned to do an IO$_ACCESSI (do not specify the IO$M_ACCESS bit or you will open the file).  When the  dvi < info in the NAM changes, $DASSGN and $ASSIGN the new device.  J This interface is documented.  I use it extensively in NFS server and it's actuallyI quite easy.  Just make sure that the sturcures and such are in read/writei memory,pJ even for stuff that's only being read.  There is a one liner in the manual	 about it,i and it's not obvious.r   -John    ------------------------------  * Date: Sat, 4 Oct 2003 22:27:57 +0000 (UTC)7 From: moroney@world.std.spaamtrap.com (Michael Moroney) ! Subject: Re: SHOW DEVICE/FULL DSA ( Message-ID: <blnhhd$pba$1@pcls4.std.com>  * "H Vlems" <hvlems.nieuw@zonnet.nl> writes:  J >shadow sets must (still) contain identical devices so AFAIK the DS deviceL >can inherit the device type from its members. This is what I see on AXP/VMS >7.3 (no patches):  C No, the requirement for identical drives was dropped long ago.  TheaB current requirement is that device MAXBLOCKS must be the same, but  even this will change real soon.  J I believe if you create a shadowset of dissimilar members the DSAx: deviceE type will be of one of the members (either the 'first' or at random).D   -- 0 -Mike7   ------------------------------  % Date: Sat, 04 Oct 2003 19:35:03 +0200i9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com> 0 Subject: Re: Simple question : foum DCL -> ici ?' Message-ID: <3F7F04C7.29857D3B@aaa.com>d   Wilm Boerhout wrote: > G > For automatic compilation and linking of Fortran files, a tool calledt/ > MMS (Module Management System) is prescribed. $ > It does not come for free however.  4 MMK is a MMS compatible build tool that is freeware.% It reads the same input files as MMS.r   You can find a copy here :  ) http://www.process.com/openvms/index.htmll  ? Click on "View the entire list of packages" and look for MMK...h  	 Jan-Erik.v   ------------------------------  % Date: Sat, 04 Oct 2003 14:43:07 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com>0 Subject: Re: Simple question : foum DCL -> ici ?) Message-ID: <3F7F14BA.5C8E9CBB@istop.com>.   "Nicol@s" wrote: > I > Salut  tous, j'aimerais de l'aide pour rediger un script DCL servant  8 > compiler automatiquement des fichiers Fortran sous VMS  M C'est le bon forum, cependant la langue de ce forum est l'anglais. Donc tu ne ? recevra pas beaucoup de rponses si tu le demandes en franais.i  M Les scripts DCL sont les mmes que les commandes DCL, la seule diffrence estsQ que tu les a rdigs dans un fichier dont chaque ligne DCL dbute avec un sign $.0  R le terme anglais que tu recherche est pas "script" mais bien "command procedures".  - HELP Hints te donnera une bonne introduction.    ------------------------------  * Date: Sat, 4 Oct 2003 19:24:15 +0000 (UTC) From: silvia@onairos.com Subject: test news0 Message-ID: <bln6ov$pu1$1@localhost.localdomain>  	 test newso -- a Silvia	 Sex Fotos % http://www.personal.able.es/ensorianot   ------------------------------   End of INFO-VAX 2003.551 ************************