info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
RFE for new SMPP support in zOS
66 views
Skip to first unread message
Tim Hare
May 10, 2016, 11:06:18 PM5/10/16
to
After discussion at SHARE, I created an RFE (back in March... sorry for the late notice, but life happened and I forgot about it) to add support for the SMPP (Short Message Peer-to-Peer) protocol, for outbound messages. This is the protocol used to communicate the the servers that support the short message service (SMS) also known as text messaging. As stated in the RFE this would allow applications to send notifications to mobile devices via text message. This would use the same port that they're using for the HTTP support.
If this sounds like something you'd be interested in you can vote for the RFE at
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=85091
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
If this sounds like something you'd be interested in you can vote for the RFE at
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=85091
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
Timothy Sipples
May 11, 2016, 3:58:09 AM5/11/16
to
It's fair to say that SMPP is rapidly becoming a legacy protocol if it
isn't already. The SMS Forum, which developed SMPP, disbanded nearly 10
years ago. Those aren't necessarily arguments against adding some sort of
IBM-delivered SMPP support to z/OS in some fashion, but they probably don't
help. By the way, the IANA-assigned TCP port for SMPP is 2775, not 80 or
443.
The newer/hipper/modern-er way to send a carrier text message is via
JSON/RESTful interfaces, and z/OS already supports those via the z/OS
Client Web Enablement Toolkit. That toolkit is included in the base z/OS
2.2 operating system and available via the service stream for z/OS 2.1 as
well. You can test that path right now using, as one example, Twilio:
https://www.twilio.com/docs/api/rest
That said, if you're a z/OS licensee there's nothing stopping you from
grabbing your favorite SMPP library and using it right away on z/OS. Take a
look at OpenSmpp as one example:
http://opensmpp.org
and Cloudhopper-smpp as another:
https://github.com/fizzed/cloudhopper-smpp
There are others, too.
Are there any other operating systems that include SMPP support as a
standard, included feature? I can't think of any. It's always some library
that you grab, isn't it? Mind you, I think z/OS needs to continue to be
best in class, but we're probably not talking about a big, gaping hole
here.
You also have the new/hip/modern push message options to consider, usually
within the context of a mobile application on iOS and/or Android. Then you
don't have carrier SMS/MMS in the loop at all, meaning (among other things)
you can still reach mobile clients connected via Wi-Fi, including those
mobile clients that don't even have cellular sections such as the iPod
touch and non-cellular iPads. There are already various ways to push
messages from z/OS through those mechanisms.
Another interesting issue to consider is whether you want z/OS to respond
to messages also, to support bidirectional conversations. You might need to
handle incoming messages at least for regulatory/legal reasons (e.g.
unsubscribe functionality). Yes, that's possible to do, today, and there
are a few different ways to do it. SMPP doesn't necessarily help, but z/OS
Connect probably does.
My current thinking is that this whole area is fertile ground for an IBM
Redbook, to create some documentation on how to take advantage of all these
technical capabilities. I may have just created that Redbook's first draft
outline. :-) If you'd like to see such a redbook, "Please ask your friendly
IBM representative." Also mention if you'd like to participate in writing
such a redbook. No promises, of course, but it can't hurt to ask.
--------------------------------------------------------------------------------------------------------
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sip...@sg.ibm.com
isn't already. The SMS Forum, which developed SMPP, disbanded nearly 10
years ago. Those aren't necessarily arguments against adding some sort of
IBM-delivered SMPP support to z/OS in some fashion, but they probably don't
help. By the way, the IANA-assigned TCP port for SMPP is 2775, not 80 or
443.
The newer/hipper/modern-er way to send a carrier text message is via
JSON/RESTful interfaces, and z/OS already supports those via the z/OS
Client Web Enablement Toolkit. That toolkit is included in the base z/OS
2.2 operating system and available via the service stream for z/OS 2.1 as
well. You can test that path right now using, as one example, Twilio:
https://www.twilio.com/docs/api/rest
That said, if you're a z/OS licensee there's nothing stopping you from
grabbing your favorite SMPP library and using it right away on z/OS. Take a
look at OpenSmpp as one example:
http://opensmpp.org
and Cloudhopper-smpp as another:
https://github.com/fizzed/cloudhopper-smpp
There are others, too.
Are there any other operating systems that include SMPP support as a
standard, included feature? I can't think of any. It's always some library
that you grab, isn't it? Mind you, I think z/OS needs to continue to be
best in class, but we're probably not talking about a big, gaping hole
here.
You also have the new/hip/modern push message options to consider, usually
within the context of a mobile application on iOS and/or Android. Then you
don't have carrier SMS/MMS in the loop at all, meaning (among other things)
you can still reach mobile clients connected via Wi-Fi, including those
mobile clients that don't even have cellular sections such as the iPod
touch and non-cellular iPads. There are already various ways to push
messages from z/OS through those mechanisms.
Another interesting issue to consider is whether you want z/OS to respond
to messages also, to support bidirectional conversations. You might need to
handle incoming messages at least for regulatory/legal reasons (e.g.
unsubscribe functionality). Yes, that's possible to do, today, and there
are a few different ways to do it. SMPP doesn't necessarily help, but z/OS
Connect probably does.
My current thinking is that this whole area is fertile ground for an IBM
Redbook, to create some documentation on how to take advantage of all these
technical capabilities. I may have just created that Redbook's first draft
outline. :-) If you'd like to see such a redbook, "Please ask your friendly
IBM representative." Also mention if you'd like to participate in writing
such a redbook. No promises, of course, but it can't hurt to ask.
--------------------------------------------------------------------------------------------------------
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sip...@sg.ibm.com
Tim Hare
May 11, 2016, 9:59:02 AM5/11/16
to
Thanks for the info... Using a RESTFUL interface is probably the way to go for the use cases I had in mined - primarily having an automated operations tool send notifications to support personnel. We used to have a way to do it for pagers but never got one built when cell phones became the standard issue for on call people.
John McKown
May 11, 2016, 10:07:16 AM5/11/16
to
On Wed, May 11, 2016 at 8:58 AM, Tim Hare <HareSyste...@comcast.net>
wrote:
> Thanks for the info... Using a RESTFUL interface is probably the way to go
> for the use cases I had in mined - primarily having an automated operations
> tool send notifications to support personnel. We used to have a way to do
> it for pagers but never got one built when cell phones became the standard
> issue for on call people.
>
>
We do that by using a "email to SMS gateway". That is, we define a MS
Exchange email address for the support person which is like:
john.mckown(cell) . On z/OS, we send an email, using XMITIP, to this
address. The MS Exchange
then relays it on to the "telephone_number@cell-provider" address which
sends it out (MMS actuall) to the cell phone.
--
The unfacts, did we have them, are too imprecisely few to warrant our
certitude.
Maranatha! <><
John McKown
wrote:
> Thanks for the info... Using a RESTFUL interface is probably the way to go
> for the use cases I had in mined - primarily having an automated operations
> tool send notifications to support personnel. We used to have a way to do
> it for pagers but never got one built when cell phones became the standard
> issue for on call people.
>
>
Exchange email address for the support person which is like:
john.mckown(cell) . On z/OS, we send an email, using XMITIP, to this
address. The MS Exchange
then relays it on to the "telephone_number@cell-provider" address which
sends it out (MMS actuall) to the cell phone.
--
The unfacts, did we have them, are too imprecisely few to warrant our
certitude.
Maranatha! <><
John McKown
Mark Regan
May 11, 2016, 10:17:00 AM5/11/16
to
I highly recommend using XMITIP too if you are running SMTP. We've been
using it at my site for over 10 years now without any issues for sending
email to Lotus Notes, MS Exchange, pagers, cell phones and Fax.
Mark T. Regan, K8MTR
CTO1, USNR-Retired
1969-1991
On Wed, May 11, 2016 at 10:07 AM, John McKown <john.arch...@gmail.com>
wrote:
using it at my site for over 10 years now without any issues for sending
email to Lotus Notes, MS Exchange, pagers, cell phones and Fax.
Mark T. Regan, K8MTR
CTO1, USNR-Retired
1969-1991
On Wed, May 11, 2016 at 10:07 AM, John McKown <john.arch...@gmail.com>
wrote:
Timothy Sipples
May 12, 2016, 5:59:26 AM5/12/16
to
Yes, e-mail-to-SMS/MMS is fairly common in the United States among other
places, but it's not common everywhere. For example, it's not available
with Singapore's mobile carriers as far as I know. It's not terribly common
in Europe either. The RESTful interfaces to SMS/MMS message centers are a
better option at this point in time, at least if you're implementing
something new, more global, and/or more reliable (fewer
hops/intermediaries/gateways). But you might also want to send an e-mail in
addition to a carrier text message and/or mobile push message. Or even
trigger an automatic voice call.
As another example, Japan really never hopped on the SMS/MMS bandwagon,
instead jumping straight to mobile handset-based "full" e-mail clients. So
the e-mail path works for them, but there's no e-mail-to-SMS gateway in the
loop.
By the way, please take advantage of the lovely CICS SupportPac CA1Y, just
recently updated:
http://www.ibm.com/support/docview.wss?uid=swg24033197
This SupportPac is provided "as is," but it's a great little kit
nonetheless. It equips CICS Transaction Server for z/OS with a very
easy-to-consume capability, based on JavaMail, to send e-mails either
asynchronously (recommended) or synchronously. Although not tested, the
same SupportPac includes functions for CICS programs to *retrieve* e-mails
as well, via standard IMAP and POP3 protocols. TLS encryption is supported,
you can generate PDF and other attachments -- loads of wonderful stuff
there, all at no additional charge to those of you with CICS Transaction
Server.
If you don't have a CICS Transaction Server license then you can go grab
JavaMail from here:
https://java.net/projects/javamail/pages/Home
and use it right away on z/OS's JVM in other contexts.
--------------------------------------------------------------------------------------------------------
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sip...@sg.ibm.com
places, but it's not common everywhere. For example, it's not available
with Singapore's mobile carriers as far as I know. It's not terribly common
in Europe either. The RESTful interfaces to SMS/MMS message centers are a
better option at this point in time, at least if you're implementing
something new, more global, and/or more reliable (fewer
hops/intermediaries/gateways). But you might also want to send an e-mail in
addition to a carrier text message and/or mobile push message. Or even
trigger an automatic voice call.
As another example, Japan really never hopped on the SMS/MMS bandwagon,
instead jumping straight to mobile handset-based "full" e-mail clients. So
the e-mail path works for them, but there's no e-mail-to-SMS gateway in the
loop.
By the way, please take advantage of the lovely CICS SupportPac CA1Y, just
recently updated:
http://www.ibm.com/support/docview.wss?uid=swg24033197
This SupportPac is provided "as is," but it's a great little kit
nonetheless. It equips CICS Transaction Server for z/OS with a very
easy-to-consume capability, based on JavaMail, to send e-mails either
asynchronously (recommended) or synchronously. Although not tested, the
same SupportPac includes functions for CICS programs to *retrieve* e-mails
as well, via standard IMAP and POP3 protocols. TLS encryption is supported,
you can generate PDF and other attachments -- loads of wonderful stuff
there, all at no additional charge to those of you with CICS Transaction
Server.
If you don't have a CICS Transaction Server license then you can go grab
JavaMail from here:
https://java.net/projects/javamail/pages/Home
and use it right away on z/OS's JVM in other contexts.
--------------------------------------------------------------------------------------------------------
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sip...@sg.ibm.com
0 new messages