mail notification solution needed
Hello,
i need a trigger solution with emailing.
When a new email is comming in, normaly OpenVMS looks like this:
New mail on node ABC from XYZ::SYSTEM
Now, i need this to use a user action. How can i solve this? Doese have
anybody an idea? Perhaps with a snipple of code?
Thank you very much!
Klaus
Re: mail notification solution needed
Klaus-D. Bohn wrote:[color=blue]
> Hello,
>
> i need a trigger solution with emailing.
>
> When a new email is comming in, normaly OpenVMS looks like this:
>
> New mail on node ABC from XYZ::SYSTEM
>
> Now, i need this to use a user action. How can i solve this? Doese have
> anybody an idea? Perhaps with a snipple of code?[/color]
Check out DELIVER (available from:
[url]http://vms.process.com/scripts/fileserv/fileserv.com?DELIVER[/url]
Re: mail notification solution needed
Klaus-D. Bohn wrote:[color=blue]
> Hello,
>
> i need a trigger solution with emailing.
>
> When a new email is comming in, normaly OpenVMS looks like this:
>
> New mail on node ABC from XYZ::SYSTEM
>
> Now, i need this to use a user action. How can i solve this? Doese have
> anybody an idea? Perhaps with a snipple of code?
>
> Thank you very much!
>
> Klaus
>
>[/color]
DELIVER
Re: mail notification solution needed
Thank you very much. I will check it out.
Klaus
"R.A.Omond" <Roy.Omond@BlueBubble.UK.Com> schrieb im Newsbeitrag
news:fvsfbs$c20$1$8300dec7@news.demon.co.uk...[color=blue]
> Klaus-D. Bohn wrote:[color=green]
>> Hello,
>>
>> i need a trigger solution with emailing.
>>
>> When a new email is comming in, normaly OpenVMS looks like this:
>>
>> New mail on node ABC from XYZ::SYSTEM
>>
>> Now, i need this to use a user action. How can i solve this? Doese have
>> anybody an idea? Perhaps with a snipple of code?[/color]
>
> Check out DELIVER (available from:
>
> [url]http://vms.process.com/scripts/fileserv/fileserv.com?DELIVER[/url][/color]
Re: mail notification solution needed
On May 7, 10:27*am, "Klaus-D. Bohn" <i...@it-bcsb.de> wrote:[color=blue]
> Hello,
>
> i need a trigger solution with emailing.
> When a new email is comming in, normaly OpenVMS looks like this:
> New mail on node ABC from XYZ::SYSTEM[/color]
Outside Deliver folks have often programmed this with Psuedo-Terminals
are trapping broadcast ASTs (SMG has an easy wrapper).
Interupt driven is nice/optimal from a resource consumption point of
view.
But sometimes POLLING is perfectly fine and much easier.
What is the response time requirement? Less than a few seconds? ...
set a trap.
More than minutes? ... poll.
The callable interface to VMSmail makes this easy.
here is an example:
#include <stdio>
#include <jpidef>
#include <maildef>
typedef struct { short len, cod; void *address; int *retlen; } item;
main()
{
int status, user_context = 0;
int SYS$GETJPIW(), MAIL$USER_BEGIN(), MAIL$USER_GET_INFO(), MAIL
$USER_END();
char username[14];
short mess;
item null[] = {0,0,0,0};
item user[] = {12, JPI$_USERNAME, username, (int *)user, 0,0,0,0};
item news[] = {sizeof(mess), MAIL$_USER_NEW_MESSAGES, &mess, 0,
0,0,0,0};
status = MAIL$USER_BEGIN(&user_context, null, null);
if (status & 1) status = SYS$GETJPIW(0,0,0,user,0,0,0);
user[0].cod = MAIL$_USER_USERNAME; /* watch out! Double usage user
itemlist */
if (status & 1) status = MAIL$USER_GET_INFO(&user_context, user,
news);
MAIL$USER_END(&user_context, null, null);
username[user[0].len] = '\0';
printf ("%d new message%s for %s\n", mess, (mess==1)? "": "s",
username);
return status;
}
And once you are in the calleable interface, just use that to read the
Email right?
Now if you already had some DCL loop, then it becomes tempting to read
the Newmail
count directly from DCL.
However, the default protection for VMSMAIL_PROFILE prohibits thist.
you would need to use (READALL) privs, or otherwise change the
protection on the file to allow read access.
$ if p1.eqs."" then p1=f$getjpi("","username")
$ if p2.eqs."" then p2=f$parse("vmsmail_profile","sys$system:.data")
$ open/read/share=write vmsmail 'p2
$ read/key=&p1 vmsmail rec
$ p = 31
$ nam = f$extr(0,p,rec)
$ max = f$len(rec) - 4
$field_loop:
$ if p .gt. max then goto done
$ cod_plus_len = f$extr ( p, 4, rec)
$ cod = f$cvui ( 0, 16, cod_plus_len)
$ len = f$cvui ( 16, 16, cod_plus_len)
$ dat = f$extr ( p + 4, len, rec)
$ p = p + len + 4
$if cod.ne.1 then goto field_loop
$write sys$output "Newmail count for ", -
f$edit(nam,"TRIM"), " is ", f$cvui(0,16,dat), "."
$done:
$close vmsmail
$exit
A good polling program/script (is there such thing? :-) would probably
leave the file open (shared) and/or leaves the MAIL$ context open.
Gutfeel: Once and hour.... close it. Once every few minutes... keep
open
fwiw,
Hein.
Re: mail notification solution needed
Sorry,
but i think that is not what i need. Or i didn't understand DELIVER.
I want to know, how does it works that is comming up this message:
New mail on node ABC from XYZ::SYSTEM
There must be working a listener that is controlling if the are a new
message. I need this to get an automatically asynchron trap for a user
action.
Thank in advanced.
Klaus
"R.A.Omond" <Roy.Omond@BlueBubble.UK.Com> schrieb im Newsbeitrag
news:fvsfbs$c20$1$8300dec7@news.demon.co.uk...[color=blue]
> Klaus-D. Bohn wrote:[color=green]
>> Hello,
>>
>> i need a trigger solution with emailing.
>>
>> When a new email is comming in, normaly OpenVMS looks like this:
>>
>> New mail on node ABC from XYZ::SYSTEM
>>
>> Now, i need this to use a user action. How can i solve this? Doese have
>> anybody an idea? Perhaps with a snipple of code?[/color]
>
> Check out DELIVER (available from:
>
> [url]http://vms.process.com/scripts/fileserv/fileserv.com?DELIVER[/url][/color]
Re: mail notification solution needed
Thank you very much.
I think that is the right way.
I will try that.
Klaus
"Hein RMS van den Heuvel" <heinvandenheuvel@gmail.com> schrieb im
Newsbeitrag
news:19a30a97-469f-4b2e-a823-6a3a4b78d03b@k37g2000hsf.googlegroups.com...
On May 7, 10:27 am, "Klaus-D. Bohn" <i...@it-bcsb.de> wrote:[color=blue]
> Hello,
>
> i need a trigger solution with emailing.
> When a new email is comming in, normaly OpenVMS looks like this:
> New mail on node ABC from XYZ::SYSTEM[/color]
Outside Deliver folks have often programmed this with Psuedo-Terminals
are trapping broadcast ASTs (SMG has an easy wrapper).
Interupt driven is nice/optimal from a resource consumption point of
view.
But sometimes POLLING is perfectly fine and much easier.
What is the response time requirement? Less than a few seconds? ...
set a trap.
More than minutes? ... poll.
The callable interface to VMSmail makes this easy.
here is an example:
#include <stdio>
#include <jpidef>
#include <maildef>
typedef struct { short len, cod; void *address; int *retlen; } item;
main()
{
int status, user_context = 0;
int SYS$GETJPIW(), MAIL$USER_BEGIN(), MAIL$USER_GET_INFO(), MAIL
$USER_END();
char username[14];
short mess;
item null[] = {0,0,0,0};
item user[] = {12, JPI$_USERNAME, username, (int *)user, 0,0,0,0};
item news[] = {sizeof(mess), MAIL$_USER_NEW_MESSAGES, &mess, 0,
0,0,0,0};
status = MAIL$USER_BEGIN(&user_context, null, null);
if (status & 1) status = SYS$GETJPIW(0,0,0,user,0,0,0);
user[0].cod = MAIL$_USER_USERNAME; /* watch out! Double usage user
itemlist */
if (status & 1) status = MAIL$USER_GET_INFO(&user_context, user,
news);
MAIL$USER_END(&user_context, null, null);
username[user[0].len] = '\0';
printf ("%d new message%s for %s\n", mess, (mess==1)? "": "s",
username);
return status;
}
And once you are in the calleable interface, just use that to read the
Email right?
Now if you already had some DCL loop, then it becomes tempting to read
the Newmail
count directly from DCL.
However, the default protection for VMSMAIL_PROFILE prohibits thist.
you would need to use (READALL) privs, or otherwise change the
protection on the file to allow read access.
$ if p1.eqs."" then p1=f$getjpi("","username")
$ if p2.eqs."" then p2=f$parse("vmsmail_profile","sys$system:.data")
$ open/read/share=write vmsmail 'p2
$ read/key=&p1 vmsmail rec
$ p = 31
$ nam = f$extr(0,p,rec)
$ max = f$len(rec) - 4
$field_loop:
$ if p .gt. max then goto done
$ cod_plus_len = f$extr ( p, 4, rec)
$ cod = f$cvui ( 0, 16, cod_plus_len)
$ len = f$cvui ( 16, 16, cod_plus_len)
$ dat = f$extr ( p + 4, len, rec)
$ p = p + len + 4
$if cod.ne.1 then goto field_loop
$write sys$output "Newmail count for ", -
f$edit(nam,"TRIM"), " is ", f$cvui(0,16,dat), "."
$done:
$close vmsmail
$exit
A good polling program/script (is there such thing? :-) would probably
leave the file open (shared) and/or leaves the MAIL$ context open.
Gutfeel: Once and hour.... close it. Once every few minutes... keep
open
fwiw,
Hein.
Re: mail notification solution needed
Klaus-D. Bohn wrote:[color=blue]
> Sorry,
>
> but i think that is not what i need. Or i didn't understand DELIVER.
>
> I want to know, how does it works that is comming up this message:
>
> New mail on node ABC from XYZ::SYSTEM
>
> There must be working a listener that is controlling if the are a new
> message. I need this to get an automatically asynchron trap for a user
> action.
>
> Thank in advanced.
>
> Klaus
>
>
> "R.A.Omond" <Roy.Omond@BlueBubble.UK.Com> schrieb im Newsbeitrag
> news:fvsfbs$c20$1$8300dec7@news.demon.co.uk...[color=green]
>> Klaus-D. Bohn wrote:[color=darkred]
>>> Hello,
>>>
>>> i need a trigger solution with emailing.
>>>
>>> When a new email is comming in, normaly OpenVMS looks like this:
>>>
>>> New mail on node ABC from XYZ::SYSTEM
>>>
>>> Now, i need this to use a user action. How can i solve this? Doese have
>>> anybody an idea? Perhaps with a snipple of code?[/color]
>> Check out DELIVER (available from:
>>
>> [url]http://vms.process.com/scripts/fileserv/fileserv.com?DELIVER[/url][/color]
>
>[/color]
DELIVER is installed as an "foreign transport".
For the user that should have it's mails processed, you
do a "SET FORWARD DELIVER%user". So DELIVER is called by
VMS-mail as soon as a mail is received. In the MAIL.DELIVERY
file your can specify any command you'd like (usualy some
COM file that should be run to process the mail). When
DELIVER has finished processing the mail if can be delivered as
usual to the receivers MAIL.MAI, or deleted (if it's not needed
any more). It's up to you.
I've used DELIVER for aprox 10 years in an fully automated
server that processes 1000's of mails each day. Never had
a single problem (with DELIVER)...
Note !
This is *NOT* a polled solution. Nothing is run until
a mail arrives. No background processes, nothing.
All processing is triggered by the mail itself.
Jan-Erik.
Re: mail notification solution needed
Klaus-D. Bohn wrote:[color=blue]
> Thank you very much.
> I think that is the right way.
>
> I will try that.[/color]
Are you talking about the polled solution ?
Then you haven't understod how DELIVER works... :-)
It's much simpler. No code to write. No polling
processes than have to be running (batch or deteched).
I think that you should check DELIVER again.
Best Regards,
Jan-Erik.
[color=blue]
>
> Klaus
>
> "Hein RMS van den Heuvel" <heinvandenheuvel@gmail.com> schrieb im
> Newsbeitrag
> news:19a30a97-469f-4b2e-a823-6a3a4b78d03b@k37g2000hsf.googlegroups.com...
> On May 7, 10:27 am, "Klaus-D. Bohn" <i...@it-bcsb.de> wrote:[color=green]
>> Hello,
>>
>> i need a trigger solution with emailing.
>> When a new email is comming in, normaly OpenVMS looks like this:
>> New mail on node ABC from XYZ::SYSTEM[/color]
>
> Outside Deliver folks have often programmed this with Psuedo-Terminals
> are trapping broadcast ASTs (SMG has an easy wrapper).
>
> Interupt driven is nice/optimal from a resource consumption point of
> view.
>
> But sometimes POLLING is perfectly fine and much easier.
> What is the response time requirement? Less than a few seconds? ...
> set a trap.
> More than minutes? ... poll.
>
> The callable interface to VMSmail makes this easy.
> here is an example:
>
> #include <stdio>
> #include <jpidef>
> #include <maildef>
> typedef struct { short len, cod; void *address; int *retlen; } item;
> main()
> {
> int status, user_context = 0;
> int SYS$GETJPIW(), MAIL$USER_BEGIN(), MAIL$USER_GET_INFO(), MAIL
> $USER_END();
> char username[14];
> short mess;
> item null[] = {0,0,0,0};
> item user[] = {12, JPI$_USERNAME, username, (int *)user, 0,0,0,0};
> item news[] = {sizeof(mess), MAIL$_USER_NEW_MESSAGES, &mess, 0,
> 0,0,0,0};
>
> status = MAIL$USER_BEGIN(&user_context, null, null);
> if (status & 1) status = SYS$GETJPIW(0,0,0,user,0,0,0);
> user[0].cod = MAIL$_USER_USERNAME; /* watch out! Double usage user
> itemlist */
> if (status & 1) status = MAIL$USER_GET_INFO(&user_context, user,
> news);
> MAIL$USER_END(&user_context, null, null);
> username[user[0].len] = '\0';
> printf ("%d new message%s for %s\n", mess, (mess==1)? "": "s",
> username);
> return status;
> }
>
> And once you are in the calleable interface, just use that to read the
> Email right?
>
>
> Now if you already had some DCL loop, then it becomes tempting to read
> the Newmail
> count directly from DCL.
> However, the default protection for VMSMAIL_PROFILE prohibits thist.
> you would need to use (READALL) privs, or otherwise change the
> protection on the file to allow read access.
>
> $ if p1.eqs."" then p1=f$getjpi("","username")
> $ if p2.eqs."" then p2=f$parse("vmsmail_profile","sys$system:.data")
> $ open/read/share=write vmsmail 'p2
> $ read/key=&p1 vmsmail rec
> $ p = 31
> $ nam = f$extr(0,p,rec)
> $ max = f$len(rec) - 4
> $field_loop:
> $ if p .gt. max then goto done
> $ cod_plus_len = f$extr ( p, 4, rec)
> $ cod = f$cvui ( 0, 16, cod_plus_len)
> $ len = f$cvui ( 16, 16, cod_plus_len)
> $ dat = f$extr ( p + 4, len, rec)
> $ p = p + len + 4
> $if cod.ne.1 then goto field_loop
> $write sys$output "Newmail count for ", -
> f$edit(nam,"TRIM"), " is ", f$cvui(0,16,dat), "."
> $done:
> $close vmsmail
> $exit
>
> A good polling program/script (is there such thing? :-) would probably
> leave the file open (shared) and/or leaves the MAIL$ context open.
> Gutfeel: Once and hour.... close it. Once every few minutes... keep
> open
>
> fwiw,
> Hein.
>
>[/color]
Re: mail notification solution needed
You could be right.
I think DELIVER will be a little bit to big for this little solution.I need
only an asynchron trap when a new mail is comming in to start a user
transaction. Not more.
I will try DELIVER and will compare both.
Thank you very very much for your help and hints.
Klaus
"Jan-Erik Söderholm" <jan-erik.soderholm@telia.com> schrieb im Newsbeitrag
news:6zkUj.7086$R_4.5751@newsb.telia.net...[color=blue]
> Klaus-D. Bohn wrote:[color=green]
>> Thank you very much.
>> I think that is the right way.
>>
>> I will try that.[/color]
>
> Are you talking about the polled solution ?
> Then you haven't understod how DELIVER works... :-)
>
> It's much simpler. No code to write. No polling
> processes than have to be running (batch or deteched).
>
> I think that you should check DELIVER again.
>
> Best Regards,
> Jan-Erik.
>[color=green]
>>
>> Klaus
>>
>> "Hein RMS van den Heuvel" <heinvandenheuvel@gmail.com> schrieb im
>> Newsbeitrag
>> news:19a30a97-469f-4b2e-a823-6a3a4b78d03b@k37g2000hsf.googlegroups.com...
>> On May 7, 10:27 am, "Klaus-D. Bohn" <i...@it-bcsb.de> wrote:[color=darkred]
>>> Hello,
>>>
>>> i need a trigger solution with emailing.
>>> When a new email is comming in, normaly OpenVMS looks like this:
>>> New mail on node ABC from XYZ::SYSTEM[/color]
>>
>> Outside Deliver folks have often programmed this with Psuedo-Terminals
>> are trapping broadcast ASTs (SMG has an easy wrapper).
>>
>> Interupt driven is nice/optimal from a resource consumption point of
>> view.
>>
>> But sometimes POLLING is perfectly fine and much easier.
>> What is the response time requirement? Less than a few seconds? ...
>> set a trap.
>> More than minutes? ... poll.
>>
>> The callable interface to VMSmail makes this easy.
>> here is an example:
>>
>> #include <stdio>
>> #include <jpidef>
>> #include <maildef>
>> typedef struct { short len, cod; void *address; int *retlen; } item;
>> main()
>> {
>> int status, user_context = 0;
>> int SYS$GETJPIW(), MAIL$USER_BEGIN(), MAIL$USER_GET_INFO(), MAIL
>> $USER_END();
>> char username[14];
>> short mess;
>> item null[] = {0,0,0,0};
>> item user[] = {12, JPI$_USERNAME, username, (int *)user, 0,0,0,0};
>> item news[] = {sizeof(mess), MAIL$_USER_NEW_MESSAGES, &mess, 0,
>> 0,0,0,0};
>>
>> status = MAIL$USER_BEGIN(&user_context, null, null);
>> if (status & 1) status = SYS$GETJPIW(0,0,0,user,0,0,0);
>> user[0].cod = MAIL$_USER_USERNAME; /* watch out! Double usage user
>> itemlist */
>> if (status & 1) status = MAIL$USER_GET_INFO(&user_context, user,
>> news);
>> MAIL$USER_END(&user_context, null, null);
>> username[user[0].len] = '\0';
>> printf ("%d new message%s for %s\n", mess, (mess==1)? "": "s",
>> username);
>> return status;
>> }
>>
>> And once you are in the calleable interface, just use that to read the
>> Email right?
>>
>>
>> Now if you already had some DCL loop, then it becomes tempting to read
>> the Newmail
>> count directly from DCL.
>> However, the default protection for VMSMAIL_PROFILE prohibits thist.
>> you would need to use (READALL) privs, or otherwise change the
>> protection on the file to allow read access.
>>
>> $ if p1.eqs."" then p1=f$getjpi("","username")
>> $ if p2.eqs."" then p2=f$parse("vmsmail_profile","sys$system:.data")
>> $ open/read/share=write vmsmail 'p2
>> $ read/key=&p1 vmsmail rec
>> $ p = 31
>> $ nam = f$extr(0,p,rec)
>> $ max = f$len(rec) - 4
>> $field_loop:
>> $ if p .gt. max then goto done
>> $ cod_plus_len = f$extr ( p, 4, rec)
>> $ cod = f$cvui ( 0, 16, cod_plus_len)
>> $ len = f$cvui ( 16, 16, cod_plus_len)
>> $ dat = f$extr ( p + 4, len, rec)
>> $ p = p + len + 4
>> $if cod.ne.1 then goto field_loop
>> $write sys$output "Newmail count for ", -
>> f$edit(nam,"TRIM"), " is ", f$cvui(0,16,dat), "."
>> $done:
>> $close vmsmail
>> $exit
>>
>> A good polling program/script (is there such thing? :-) would probably
>> leave the file open (shared) and/or leaves the MAIL$ context open.
>> Gutfeel: Once and hour.... close it. Once every few minutes... keep
>> open
>>
>> fwiw,
>> Hein.
>>[/color][/color]
Re: mail notification solution needed
Klaus-D. Bohn wrote:
[color=blue]
> I want to know, how does it works that is comming up this message:
>
> New mail on node ABC from XYZ::SYSTEM
>
> There must be working a listener that is controlling if the are a new[/color]
There is a shareable image on VMS that provides mail delivery.
Mail can arrive in a mailbox in a number of ways:
Local MAIL from one user to another user. The Sending user runs code
that is privileged and deposits the message in the destination's mailbox
AND checks if the destination user is logged in, and if so, will send a
terminal boradcast to his terminal (the "New mail" message you mentioned).
When mail comes from another DECnet node, a decnet mail image is started
as a network task and it handles local delivery. Again, if the user is
logged in, it sends a broadcast to his/her terminal.
When SMTP mail arrives, the SMTP symbiont calls up the callable mail
interface to create a VMSmail message to be delivered to the VMSmail
recipient, and the callable mail interface takes care of doing the
broadcast to the user's terminal if the user is logged in.
Re: mail notification solution needed
Klaus-D. Bohn wrote:[color=blue]
> You could be right.
>
> I think DELIVER will be a little bit to big for this little solution.I need
> only an asynchron trap when a new mail is comming in to start a user
> transaction. Not more.[/color]
OK, fine. :-)
I've no idea what your defenitions of "big" or "small" is.
Or what a "user transaction" is supposed to do, so it's
quite hard for me to tell. :-)
I'd be very interested to know in what way
DELIVER is "big". It's less then 1 MB diskspace
and it takes no memory at all when there is no
mail-processing going on.
And what should happen when the mail arrives ?
Are you talking about a "real" AST's ?
How is the "user transaction" started ?
Regards,
Jan-Erik.
Re: mail notification solution needed
:-))))))))))))))
Yes, big and small is a difference.
I mean not the size of code or disk space. I mean the solution.
The problem is that my customer has new USV. But there is no support for
OpenVMS.
The USV can send an email (smtp). So, when an email is arriving to OpenVMS
from the USV we will start an shutdown script or another script. That is the
backround.
For that, i need only a listener that look if there is comming an email from
the USV. When yes, then do the action script.
I have tested the source from Hein and it is running well:
PLUTO_AXP/SYSTEM> run check_mail
1 new message for SYSTEM
PLUTO_AXP/SYSTEM>
Now, i will build up for some more features to control and to use it.
Klaus
"Jan-Erik Söderholm" <jan-erik.soderholm@telia.com> schrieb im Newsbeitrag
news:E_kUj.7088$R_4.5643@newsb.telia.net...[color=blue]
> Klaus-D. Bohn wrote:[color=green]
>> You could be right.
>>
>> I think DELIVER will be a little bit to big for this little solution.I
>> need only an asynchron trap when a new mail is comming in to start a user
>> transaction. Not more.[/color]
>
> OK, fine. :-)
>
> I've no idea what your defenitions of "big" or "small" is.
> Or what a "user transaction" is supposed to do, so it's
> quite hard for me to tell. :-)
>
> I'd be very interested to know in what way
> DELIVER is "big". It's less then 1 MB diskspace
> and it takes no memory at all when there is no
> mail-processing going on.
>
> And what should happen when the mail arrives ?
> Are you talking about a "real" AST's ?
> How is the "user transaction" started ?
>
> Regards,
> Jan-Erik.[/color]
Re: mail notification solution needed
On Wed, 07 May 2008 09:56:16 -0700, Klaus-D. Bohn <info@it-bcsb.de> wrote:
What is USV?
[color=blue]
> :-))))))))))))))
>
> Yes, big and small is a difference.
>
> I mean not the size of code or disk space. I mean the solution.
>
> The problem is that my customer has new USV. But there is no support for
> OpenVMS.
> The USV can send an email (smtp). So, when an email is arriving to
> OpenVMS
> from the USV we will start an shutdown script or another script. That is
> the
> backround.
> For that, i need only a listener that look if there is comming an email
> from
> the USV. When yes, then do the action script.
>
> I have tested the source from Hein and it is running well:
>
> PLUTO_AXP/SYSTEM> run check_mail
> 1 new message for SYSTEM
> PLUTO_AXP/SYSTEM>
>
> Now, i will build up for some more features to control and to use it.
>
> Klaus
>
>
> "Jan-Erik Söderholm" <jan-erik.soderholm@telia.com> schrieb im
> Newsbeitrag
> news:E_kUj.7088$R_4.5643@newsb.telia.net...[color=green]
>> Klaus-D. Bohn wrote:[color=darkred]
>>> You could be right.
>>>
>>> I think DELIVER will be a little bit to big for this little solution.I
>>> need only an asynchron trap when a new mail is comming in to start a
>>> user
>>> transaction. Not more.[/color]
>>
>> OK, fine. :-)
>>
>> I've no idea what your defenitions of "big" or "small" is.
>> Or what a "user transaction" is supposed to do, so it's
>> quite hard for me to tell. :-)
>>
>> I'd be very interested to know in what way
>> DELIVER is "big". It's less then 1 MB diskspace
>> and it takes no memory at all when there is no
>> mail-processing going on.
>>
>> And what should happen when the mail arrives ?
>> Are you talking about a "real" AST's ?
>> How is the "user transaction" started ?
>>
>> Regards,
>> Jan-Erik.[/color]
>
>[/color]
--
PL/I for OpenVMS
[url]www.kednos.com[/url]
Re: mail notification solution needed
In article <4821bc85$0$6926$9b622d9e@news.freenet.de>, "Klaus-D. Bohn" <info@it-bcsb.de> writes:[color=blue]
>
> Now, i need this to use a user action. How can i solve this? Doese have
> anybody an idea? Perhaps with a snipple of code?[/color]
It would be much easier to inteface with the mail system using the
documented mail API than it would be to capture and process the
broadcast message.
Re: mail notification solution needed
In article <op.uaso1lvzhv4qyg@murphus.hsd1.ca.comcast.net>, "Tom Linden" <tom@kednos.company> writes:[color=blue]
>On Wed, 07 May 2008 09:56:16 -0700, Klaus-D. Bohn <info@it-bcsb.de> wrote:
>
>What is USV?[/color]
Uninterruptible power supply => UPS
Regards,
Christoph Gartmann
--
Max-Planck-Institut fuer Phone : +49-761-5108-464 Fax: -452
Immunbiologie
Postfach 1169 Internet: gartmann@immunbio dot mpg dot de
D-79011 Freiburg, Germany
[url]http://www.immunbio.mpg.de/home/menue.html[/url]