I would point out that, with respect to the OP question, that invoking RESTful services from headless code usually involves HTTPS and often client certs.
If you were using Python or Lua on z/OS with standard wrappers you would be using OpenSSL. Who is going to port OpenSSL and keep up with all of the CERTs and issues? I would much prefer to use ports of scripting languages that use bindings for z/OS System SSL (gsk_ calls) and for ciphers either CPACF or ICSF. Then they would integrate with keyrings, SAF, crypto express cards, etc. OTOH, it might be interesting if someone started writing a port of LibreSSL (the OpenSSL fork by BSD) that included a static engine for the implementation of functions via Systems SSL, ICSF, and CPACF. If this were done, then lots of FOSS code could use it, since it is expected that LibreSSL will be the default instead of OpenSSL in a few years. Kirk Wolf Dovetailed Technologies http://dovetail.com On Wed, Nov 25, 2015 at 8:23 AM, Bigendian Smalls < [email protected]> wrote: > Agreed on lua from what I've seen it seems like a fairly competent > language (mostly I've see it from the backside of wireshark/nmap). I'll > give your port a look, thanks for sharing that! > > I'd love to see the python port truly finished, it's still my go-to > prototyping tool on most platforms, quick POC where others like C or ASM > are too wordy for quick mock-ups, but way better for long term and speed. > > > On Nov 24, 2015, at 05:15, David Crayford <[email protected]> wrote: > > > >> On 24/11/2015 11:52 AM, Bigendian Smalls wrote: > >> Fair point on the rocket Python for http tip. Just did some testing on > that - yikes. only ever used that flavor of Python locally - but outside > comm is a huge pain indeed. Good call to stick with curl or Java as you'd > mentioned and leave the Python until it's fully baked for cp conversions. > > > > It gets worse. The JSON libraries are broken too. Unicode escaping is a > case in point. And the URL and base64 stuff. Python has a huge standard > library so a real EBCDIC port is going to be a lot of work and probably > won't happen unless a significant ROI > > can be made. You can try my Lua port which is patched to support EBCDIC > for HTTP, JSON, URL, base64 etc http://lua4z.com/. It smokes REXX by an > order of magnitude wrt performance and has all the modern features that you > get with Python. There's > > even a decent list comprehension implementation in the penlight library. > I haven't implemented Lua-cURL yet but I will now that rocket have made > libcurl available with their port. That should bring a lot of other > powerful HTTP, FTP features available. > > > >>>> On Nov 23, 2015, at 19:30, David Crayford <[email protected]> > wrote: > >>>> > >>>> On 24/11/2015 9:12 AM, Bigendian Smalls wrote: > >>>> Depending on the volume, python's usage of the REST APIs I've used > (like Aws works great). I'm sure it'd be not to hard to do in REXX also > from the few client HTTP code snippets I've seen in Google. > >>> Classic REXX using the socket() API would be doable. But I wouldn't go > there. > >>> > >>>> But the python one works great - using Rocket's ported tools. fwiw. > >>> All of the web APIs (HTTP etc) in Rockets z/OS Python port are broken. > They haven't done the ASCII/EBCDIC work on the HTTP protocol. Until they do > Rockets Python port is nothing but a broken toy. > >>> > >>>> Chad > >>>> > >>>>> On Nov 23, 2015, at 18:17, Frank Swarbrick < > [email protected]> wrote: > >>>>> > >>>>> Sounds interesting. Anyone have any experience with it? > >>>>> We are still on z/OS 1.13. I don't know when we'll go to 2.1, much > less 2.2, but its certainly something to consider. > >>>>> > >>>>> I'm still open to other ideas. > >>>>> > >>>>> Thanks! > >>>>> Frank > >>>>> > >>>>>> Date: Mon, 23 Nov 2015 18:02:20 -0600 > >>>>>> From: [email protected] > >>>>>> Subject: Re: Accessing RESTful services from a z/OS batch job > >>>>>> To: [email protected] > >>>>>> > >>>>>> Maybe the z/OS client web enablement toolkit? > >>>>>> > >>>>>> see the V2R2 docs for latest features - > >>>>>> > https://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.e0za100/mvs_web_enablement.htm > >>>>>> > >>>>>> " > >>>>>> You can use web application APIs to create a client/server > application > >>>>>> using a > >>>>>> request-response protocol that can link a client residing anywhere > in the > >>>>>> world > >>>>>> with any web server. Many web applications have evolved to a simpler > >>>>>> programming model based on representational state transfer (REST). > Governed > >>>>>> by > >>>>>> a set of architectural constraints, RESTful applications can be > much easier > >>>>>> to > >>>>>> develop, enabling the creation of elegant and secure web > applications. > >>>>>> RESTful > >>>>>> applications typically use the ubiquitous Hypertext Transfer > Protocol > >>>>>> (HTTP) as the > >>>>>> means of communication and either JavaScript Object Notation (JSON) > or > >>>>>> Extensible Markup Language (XML) as the format of data exchange > between the > >>>>>> client and server programs > >>>>>> > >>>>>> Kirk Wolf > >>>>>> Dovetailed Technologies > >>>>>> http://dovetail.com > >>>>>> > >>>>>> On Mon, Nov 23, 2015 at 5:32 PM, Frank Swarbrick < > >>>>>> [email protected]> wrote: > >>>>>> > >>>>>>> What are you using to perform this function? > >>>>>>> > >>>>>>> > ---------------------------------------------------------------------- > >>>>>>> For IBM-MAIN subscribe / signoff / archive access instructions, > >>>>>>> send email to [email protected] with the message: INFO > IBM-MAIN > >>>>>> > ---------------------------------------------------------------------- > >>>>>> For IBM-MAIN subscribe / signoff / archive access instructions, > >>>>>> send email to [email protected] with the message: INFO > IBM-MAIN > >>>>> > ---------------------------------------------------------------------- > >>>>> For IBM-MAIN subscribe / signoff / archive access instructions, > >>>>> send email to [email protected] with the message: INFO > IBM-MAIN > >>>> ---------------------------------------------------------------------- > >>>> For IBM-MAIN subscribe / signoff / archive access instructions, > >>>> send email to [email protected] with the message: INFO > IBM-MAIN > >>> ---------------------------------------------------------------------- > >>> For IBM-MAIN subscribe / signoff / archive access instructions, > >>> send email to [email protected] with the message: INFO IBM-MAIN > >> ---------------------------------------------------------------------- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to [email protected] with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
