On 26/11/2015 3:13 PM, Rob Schramm wrote:
Hmm.. I wonder if NetRexx has anything to help?

Never used it. If I wanted to run a JVM language I would pick Scala which has the succinct feel of a scripting language but is strongly typed. And forget writing TSO applications with a JVM based language. You can use bpxwunit and have a go but will quickly find out the limitations. The design of REXX only having one type, the string, also is showing it's age.

What I do know is that oorexx is an absolute dog wrt performance. But if REXX is your bag then whatever flicks your switch.


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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to