Oh ok ... guess I didn't realize that WET is being provided primarily for 'backward compatibility'. Thanks for the clarification on the other bits.
> Using cURL or libcurl is not inherently dangerous. Any code that goes > into production should be peer reviewed. You can write bad code in any > language using any tool. Again ... you've over-generalized a very specific scenario I said folks should be wary of. I didn't say curl or any other tool is dangerous, piping source-unknown scripts to bash is! - KB ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, July 24, 2020 10:15 AM, David Crayford <[email protected]> wrote: > On 2020-07-24 12:02 PM, kekronbekron wrote: > > > > I wouldn't. I would recommend using a sophisticated networking library > > > like Java or whatever your favorite language is on the JVM. > > > Can't figure out if you're kidding... > > No, I'm not kidding! IMO, unless you have a critical requirement to web > enable legacy languages then I would avoid WET at all costs. A quick > browse of the samples is enough to conclude that > while it may work it is hideously complicated compared to similar > function in modern languages. So, why not just use a better language? I > almost died laughing when I saw how complicated it > is to parse JSON in REXX using the WET. > > > > Who told you that? My employer offers a cURL port for z/OS and it's well > > > maintained with support for production environment. > > > Ok, Rocket's curl? > > > What's the percentage of clients that want a separate product for > > > something that also comes with (or at least used to?) the OS (Ported > > > Tools). > > FYI, IBM sold ported tools to Rocket years ago. There is no cURL that > comes with z/OS. > > > Yes, everything I'm saying is subjective... > > Adoption would be much higher if Ported Tools' curl were actively developed. > > It is! And you can download it for free if you just want to write > in-house tooling. If you want to use cURL in production then you will > have to buy support. > > > Eh ... I didn't say curl-ing a script is dangerous and CWET isn't. > > I meant piping any source-unknown script direct for execution is not a > > great idea. > > Using cURL or libcurl is not inherently dangerous. Any code that goes > into production should be peer reviewed. You can write bad code in any > language using any tool. > > > - KB > > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > On Friday, July 24, 2020 8:53 AM, David Crayford [email protected] wrote: > > > > > On 2020-07-24 11:12 AM, kekronbekron wrote: > > > > > > > Just mentioned ASM / COB CWET for options really. > > > > They're a a lot more involved than the Python client (when that's > > > > available). > > > > curl is ok as a user, but when you want to productionize something, I > > > > would think the recommendation would be to use CWET. > > > > I wouldn't. I would recommend using a sophisticated networking library > > > > like Java or whatever your favorite language is on the JVM. > > > > > > > Not saying curl is a bad tool, it is handy & does what it does. > > > > Ease of use does not mean it's the solution of choice in many > > > > controlled environments. > > > > By loved I mean does it get upgrades/improvements? > > > > Who told you that? My employer offers a cURL port for z/OS and it's well > > > > maintained with support for production environment. > > > > > > > I don't know I'm just asking.. > > > > curl-ing a shell script directly is bit ... dangerous. > > > > That's purely subjective. I don't see why cURL would be any more > > > > dangerous than writing a Python script or using CWET. > > > > > > Lots of people are using Git for DevOps on z/OS and that uses cURL for > > > ssh and https transport. > > > > > > > Not in this case as the script is available to inspect. > > > > -- > > > > > > 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
