LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (December 2007, week 2)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
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


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

Back to: Top of message | Previous page | Main SAS-L page