Date:         Tue, 11 Dec 2007 00:38:03 -0500
Reply-To:     David Johnson <d@DKVJ.BIZ>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         David Johnson <d@DKVJ.BIZ>
Subject:      Re: Can SAS send text messages to cell phones?

Reliability of message delivery is always a problem with automated
systems.  In the days of my managing an emergency response unit, pagers
were used to contact key personnel.  Unlike mobile phones however, the
early generation of these were receivers only and did not sign on to a
service when they emerged from a radio dead spot, nor acknowledge receipt
of a message.  The delivery time of the pager messages indeed was only
guaranteed "within the hour".  While this time was only approached once,
and was for a routine message, there was blood on the carpet during the
debrief for the delay in delivery.

SMS and mobile telephones have improved the delivery expectations, but
getting someone on a telephone to another carbon based lifeform who
communicates meaningfully is a little more reliable than expecting
automated systems to be a panacea.  Still "lights-off" data centres are
desired by many so the technology is employed, tested, made more robust and
will evolve.

Shanks comment on frequent job start reports might soon cause him grief.
Jobs are more often run in parallel, making schedule status an analysis of
multiple messages.  I am also strongly in favour of managing by exception.
If the scheduler sends me a message saying it is four hours late waiting
for the XYZ transaction file, I would be more interested than in getting a
series of "happy talk" messages.  I would expect jobs in a schedule to be
rigorously tested, and verifying the job in minutiae would be an
annoyance.  If you awaken me at 4am, it had better be for something I would
be concerned about, and something I can fix.

If you are paying for each of these messages, then I think I would be
demanding something more than "best efforts" for delivery, if we are
generating a lot of traffic.

It all comes down to the purpose for which you employ the technique.

Kind regards

David

On Mon, 10 Dec 2007 22:32:54 +0530, Shanks N <shanks.n@GMAIL.COM> wrote:

>David Johnson <d@DKVJ.BIZ> writes:
>
>
>[...]
>
>> Two cautions: the telephone companies don't guarantee delivery times or
>> even completions on SMS messages, so diversifying providers and sending
>> mission critical messages to multiple destinations is a good idea.
>
>Second David here.  Keep this in mind.  SMS is best effort delivery,
>like email.  And there is the stuff on your phone.  If your sms inbox
>is full, the message might be held for only 24 hours or less on the
>service provider side. And then thrown into the bit bucket.
>
>
>> Secondly, if step 15 in a program develops an error, and step 90 sends
the
>> email, be aware that the error may set Obs to 0 and the email data step
>> will be compiled but not executed.  You need to work around that issue.
>
>Don't people interleave the SMS/email sending of a long job?   I
>thought that was good design, a starter email saying
>
>"Job X starting...'
>
>and later
>
>"Job Y starting"
>
>and so on.
>
>You only need to keep the last SMS/email received to know the status
>of the actively running job.
>
>
> regards,
> Shanks