By Chris Leland, Royal Cyber

If you listen to the old guard at IBM bluster about using LPEX/ISPF vs. the COBOL Editor* you’ll hear things such as:

• Because COBOL is a fixed-LRECL block style language, it benefits from block (think the Prefix Area) commands for editing – provided by LPEX in ISPF mode. And because Java/C++/HTML etc. are free-form languages use an Eclipse-style editor**.
• Asking z/OS guys to learn:
  • New IDE + New procedures/work processes + New vocabulary/terms + New SCM interfaces – and new REXX/CLIST interfaces +
  • New Data Editing and SQL development tools + new ISPF 3.x tools (esp. Search) + escalation in mouse-development skills …
  • And to top it off – asking programmers to give up 10, 20, 30, 40 years of ISPF Edit mastery seems hardly an intelligent on-ramp for veteran developers.
  • Show me where the Filters and Autocomment features are in the COBOL Editor
  • Until RDz completely replaces ISPF we’ll have to maintain our ISPF (including =2/editing) skills. So how is this easier?
  • LPEX/ISPF has hot-key support for almost everything, etc.

And if you listen to new-age developers – or early adopter types – or perhaps RDz experienced/power users you’ll hear this about why the COBOL Editor is superior:

• All of the above is just emotional push-back. The COBOL Editor is clearly superior technology – it’s barely Street Legal.
• And it’s the future of editing tools/technology.
• And it provides an on-ramp to Java/C++/HTML/SOA coding projects.
• Show me where really cool features like collapsing paragraphs/sections, and auto-formatting your source code are in LPEX/ISPF
• And would you really do block-style editing with LPEX? (short answer – not really – at least in the current LPEX release)
• And isn’t Hex editing far easier with the COBOL Editor? (short answer – absolutely, yes)

Naturally, each of these viewpoints is valid.

• The more change you impose on veteran technologists – especially developers for whom software is a means to an end (i.e. making the rent money) – the more likely they are to reject RDz – citing initial loss of productivity. By teaching the LPEX/ISPF editor this issue is reduced.
• For anyone who’s used/used to (and likes) Eclipse-style editing, productivity in text/free-form languages OR COBOL, JCL, PL/I, Assembler, etc. the COBOL Editor will be a better choice.
• The LPEX/ISPF editor supports almost all – but not all (not 100%) of ISPF functionality. O note – there’s no support for ISPF Edit Macros in either editor.
• The COBOL Editor contains more advanced functionality (see Table x).
• However having more advanced functionality is a double-edged sword:
  • It’s great to have extended functionality – as new skills are assimilated and new options discovered for productivity/ease-of-work
  • But “more” can be more daunting – even more intimidating to veteran TSO developers – who are often quite happy with their typing-oriented ISPF editing craft ( thank you very much)

• Starting in v9.0 RDz added a simple Context Menu “Open With…” function that provides one click switching, between LPEX/ISPF and the COBOL Editor and vice-versa. Let’s see if this new simple “swap my editor” ends the RDz Editor Wars.

Our view

Stay focused on both the human factors and “big picture” of your Rollout. If your veteran COBOL programmers are taking their first run at RDz do everything you can to max-out their confidence in using new, modern tools – by onboarding them with LPEX/ISPF. After doing a deep-dive editing/usage modeling survey – used to establish your (not IBM’s) out-of-the-box defaults for the RDz editor workspace preferences. For Entry-Level programmers or anyone who’s seen carrying around a book on Eclipse, definitely start them off with the COBOL Editor.

After a few months of RDz use you should introduce the veteran programmers to the COBOL Editor. Some will jump all over it – others will not. Which is fine, as not every z/OS developer is dying to use a fully tricked-out “Barely Street Legal” editor. Some of us get to work (quite happily) in a minivan.

* Because there is considerably less functionality in the LPEX/ISPF for PL/I than for COBOL (or even for LPEX/Assembler) – the “PL/I Editor” is a much more beguiling prospect. So that war more of a skirmish.

** We @ Royal Cyber are very interested in discussing the premises that block/coding style editors are better for COBOL, JCL, and Assembler. And free-form text editors are better for Java/HTML/C++, etc. And using ISPF for HTML or a Java-style editor for COBOL is an impedance mismatch. Your thoughts on this?

Feature/Function Table – RDz v9.0.1

Next steps…

RDz is one of the primary strengths of Royal Cyber. In 2014 IBM chose Royal Cyber to manage its RDz “Distance Learning” program – out of all the RDz business partners world-wide. We offer deep and quality service engagements in every phase or RDz – from Installation and Deployment, to Training/Mentoring and adoption, to administering and supporting both the RDz client and server – and finally, to evaluating your RDz Adoption and Return-on-Investment.

• For details on the Royal Cyber RDz Rollout and project/task usage modeling contact us: inquires@royalcyber.com
• To sign up for Royal Cyber RDz Free Distance Learning: http://royalcyber.com/royal-cyber-rdz-distance-learning-training-schedule/
• To get a copy of the January 2014 Newsletter – including additional deep-dive articles on RDz and RAAi: http://royalcyber.org/mn/index.html

Chris Leland; Chris is Royal Cyber’s primary RDz technical instructor – having worked full-time with RDz for almost four years; developing applications in COBOL, teaching RDz classes and mentoring in COBOL and Assembler, installing and configuring RDz, delivering custom workspace design sessions, writing an RDz evaluation exam, and integrating RDz with Rational Asset Analyzer. Chris passed the IBM/RDz Certification exam with flying colors in 2011.