Jerry,
I've found that the SDSF REXX API works well in USS and have written
several scripts to do useful stuff like bounce web server started tasks.
We use this from Atlassians Bamboo CI tooling to deploy web applications
to z/OS triggered from git merges in Bitbucket. Rockets git port has
been a game changer for us! If there was a curses library for REXX it
would be possible to write something similar to SDSF for the shell.
There is also the oeconsol command to execute MVS commands from the
shell which is really cool.
Like you I prefer to work in z/OS UNIX with all the code in the file
system. It's so much better than using data sets. We don't have Linux on
Z installed but do a lot of work on x86 Linux servers. You mentioned
hipersockets which is great for shuttling data around at high speeds for
JDBC and stuff in production systems but what other advantages does it
offer for development?
On 16/03/2018 8:21 PM, Jerry Callen wrote:
I'm going to be an EXTREME outlier here.
Background: I learned computing on OS/360 thru MVS, first using cards, then
TSO/ISPF. I jumped ship to Unix in the mid 80s and now I'm back on the
mainframe, doing ports of open source software to z/OS (under USS) at Rocket
Software.
I am logged into both USS (via ssh from PuTTY) and TSO/ISPF (via BlueZone) from
a Windows laptop all day long. If I had a decent tool for accessing JES
(there's no avoiding SDSF for the time being) from USS, I'd NEVER be in TSO.
I use emacs as my development environment. I don't call it an "editor" because it does so
much more than edit text. In particular, the "shell buffer" feature is indispensible;
think of TSO session manager, but on insane steroids. The USS port of emacs is ancient and creaky
(though I dearly hope we can remedy that within the next year), and I will grant that emacs has a
very stiff learning curve, but once you know it, it's unbelievably productive.
For source control, I use the Rocket port of git. Essentially all of our
mainframe development is moving from other source control systems (SCLM, cvs,
svn) to git; there are good open source tools for converting from cvs and svn
that preserve all the history and branches.
For builds, I use whatever the open source project I'm currently working on
uses, which is generally some variation on automake/autoconf/configure/make.
The automake/autoconf situation on z/OS isn't yet what it wants to be. For my
own projects, I just use raw make. I often create make files that work on both
USS and Linux on Z (my go-to Unix when I need to use a tool not yet on USS).
In short: I treat z/OS as a Unix box. Nearly all of the compilers (COBOL, PL/I, C/C++,
plus the assembler and binder) can be used from USS, on Unix files (no need to move
source, maclibs, include files, etc. into a PDS). IBM has provided very good, albeit
complex and tricky to use well, ASCII/EBCDIC "bimodal" encoding support to ease
the encoding problem. IBM is actively porting newer languages (like JavaScript in
node.js) to z/OS.
I can run TSO commands from the shell prompt (using, of course, the "tsocmd"
command...) when I need to. I keep building tools to help insulate me from TSO and batch
(like my SMP query interface at https://github.com/zorts/smpapi), and of course Rocket
continues to release new and updated tools for free (though our bandwidth is limited...).
The big remaining hole is JES queue access. I can, of course, submit jobs from USS, but
getting the output in a nice, consumable manner remains a challenge; hence, my TSO
session.
We have a cadre of younger developers who follow a similar path, though often
using vim instead of emacs, and im some cases Windows-based editors (Eclipse,
Webstorm, SlickEdit, etc.) and FTP.
Bear in mind that my first "real" editor was ISPF, which I used for years. Even
with that history, I can't imagine using it for any serious editing at this point.
Slight diversion: Linux on Z is a VERY nice platform. I have rarely encountered
any problems porting x86 Unix code to Linux on Z, and usually I don't have to;
it's already a real, well-equipped Unix. Given hipersocket connectivity to
z/OS, I think it's got potential to be a terrific alternative to USS. However,
it's still just too weird for many shops: it requires a completely new set of
system administration skills, its own LPAR or VM, and it just doesn't seem to
getting much traction.
-- Jerry
----------------------------------------------------------------------
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
