Hmm.. I wonder if NetRexx has anything to help? Rob Schramm
On Wed, Nov 25, 2015, 11:53 PM David Crayford <[email protected]> wrote: > On 25/11/2015 10:23 PM, Bigendian Smalls 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! > > There is a JIT variant called LuaJIT which is snapping on the heels of > gcc -O3 speeds which make it perfect for wireshark scripting which > processes a huge amount of data. LuaJIT is so fast I've seen it > consistently beat optimized C++ code on Linux systems. It's used by > Rackspace and CloudFlare for web apps. In the case of CloudFlare, they > replaced C code with Lua > https://blog.cloudflare.com/pushing-nginx-to-its-limit-with-lua/. > > It's also used in Adobe Photoshop, Redis and numerous others > https://sites.google.com/site/marbux/home/where-lua-is-used. > > > > > 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. > > I'm a big fan of Python. It's a well designed language, which I can't > say for Ruby. Rocket should open source their port so others can improve > it. It looks like it's just an update on what was already in the public > domain. > > I personally prefer the minimalist design of Lua to all other scripting > languages. Because the syntax is so small it's easy to learn and tiny > syntax results in a VM so small it fits into a L2 cache line on most > systems, which makes it blazingly fast. > Lua4z also supports VSAM files which REXX does not. Did I mention it was > fast? http://users.tpg.com.au/crayford/rexx-lua-c-io-benchmark.htm. > > >> 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 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
