Re: Possibly stupid question for you IBM mainframers... :-)

From: Edward G. Nilges (spinoza1111_at_yahoo.com)
Date: 07/15/04

  • Next message: Scott Hooper: "Reading COBOL "data files"" 
    Date: 14 Jul 2004 19:55:32 -0700

    rsteiner@visi.com (Richard Steiner) wrote in message news:<vfs8ApHpvioW092yn@visi.com>...
    > Hi, guys...
    >
    > I've been out of work for a while, and while I know COBOL well enough
    > on both the Unisys 2200 and A-series platforms (I've written code in
    > both of those environments now), most of the mainframe work I see out
    > there is in IBMland.

    Many companies and other institutions talk a good game about getting
    rid of their mainframes and their inventory of Cobol programs, because
    structurally "the mainframe" has become the intended focus of user
    resentment, in a structure wherein the phenomenon is divided between
    "usable, direct, honest" speech, and "unusable, overly complex, and
    dishonest" writing.

    This bifurcation pervades technical and media discourse...to the
    extent that in the celebrations of the "heroes" of September 11 one
    finds firefighters and cops (who deserved their honors, of course) but
    none at all of the achievement of air traffic controllers, who
    systematically landed thousands of aircraft when the FAA grounded
    flights on that date. In the public psyche, the fire-fighter or cop is
    admirable in part because he's able to create a defensible
    self-definition and culture around his work, and exclude others,
    whereas the air traffic controllers failed signally to do so in 1981,
    and, ever since, have been a suspect crew and hence, in the media,
    invisible. Their work becomes a form of writing which is taken for
    granted and as such cannot be named or celebrated.

    [Parenthetically we find a similar economy in Grigorii Medvedev's
    account of Chernobyl: the Russian firefighters are celebrated, but the
    nuclear technicians, despite similar self-sacrifice, are in effect
    blamed for the disaster.]

    As a result companies and institutions have concealed their ongoing
    dependence on a morass of ill-understood software in mainframes, and,
    in answer to your question, still need Cobol people...and are willing
    in many cases to overlook platform dependencies. You do need to learn
    JCL and the IBM mainframe "utilities". CICS, as another poster has
    pointed out, is somewhat optional.

    My experience in the 1970s was that one could go far if one troubled
    to learn the amazingly primitive "utilities" for common tasks such as
    printing the contents of a file. They turned out even then to have all
    sorts of options and giz mos added over time which made them useful
    for real work, as long as one reconciled oneself to their weirdness.

    Be sure to learn Rexx, which is a language developed at IBM UK in the
    early 1980s by Mike Cowlishaw. Originally intended as a way to write
    procedures on Conversational Monitor System, REXX is now also used on
    MVS and Time Squandering Option (TSO).

    Rexx is based on PL/I and as such has a reasonably up to date syntax.
    Its semantics is based on the traditional IBM MIS idea (which I think
    dates to the IBM 1401, a character, decimal machine introduced in
    1959) that all data worth processing is a completely variable length
    string or a completely variable length decimal number.

    As such Rexx is a powerful tool for getting fast results on the
    mainframe.

    >
    > No, this isn't a surprise to me. :-)
    >
    > My question, though: How does a person like me go about learning more
    > about CICS, COBOL2, DB2, etc., on the IBM side...?
    >
    > I already know how to operate in environments like TSO/ISPF (having
    > used various tools in that environment for over a decade at a former
    > workplace), and I have a couple of Doug Lowe's books on CICS "for the
    > COBOL programmer" which seem quite interesting at first glance, but
    > I've been too busy reading up on Javascript and other seemingly more
    > marketable things to spend too much time reading things IBMish.
    >
    > So many books, so little time. :-(
    >
    > How does one learn about the IBM world nowadays? Or is that something
    > which is no longer a realistic desire?
    >
    > Am I crazy for even being interested?
    >
    > Is there a better newsgroup to ask this? Maybe I'll also fork this to
    > a.f.c (since I know a lot of former IBMers post there as well).

  • Next message: Scott Hooper: "Reading COBOL "data files""

    Relevant Pages

    • Re: (For Amir) - "esplorinng IBM Mainframe COBOL Language Capabilities"
      ... tools that are "taken as read" by people on mainframe sites. ... English as a first language and I HATE reading computer reference ... Most people here take the 80-column punched card image that COBOL was built ... "We are going to plan for migrate to IBM Mainframe environment. ...
      (comp.lang.cobol)
    • Various "debuggin" tools (for IBM mainframe development)
      ... both training and systems programming for a "major utility" using IBM mainframe ... COBOL and tools before that. ... During much of my "mainframe support" time, ... Xpediter, Intertest, ViaTest, etc for interactive debugging ...
      (comp.lang.cobol)
    • Re: My First C# (warning - long post)
      ... but ever since the days when VS COBOL II first came ... this HAS been one place where IBM ... "Performance considerations for using CALLs (measuring CALL overhead ... In several IBM mainframe shops ...
      (comp.lang.cobol)
    • Re: Possibly stupid question for you IBM mainframers... :-)
      ... >> I've been out of work for a while, and while I know COBOL well enough ... of the IBM systems they allow for personal use, ... struck by how much this resembles the mainframe way. ... >Be sure to learn Rexx, which is a language developed at IBM UK in the ...
      (comp.lang.cobol)
    • Re: Need for COBOL 64 bit on mainframe
      ... And, please limit your responses to COBOL, because ... overhead in switching between XPLINK and non-XPLINK environments is ... If the IBM and user strategy is to ... there was a 64 bit JAVA for z/OS. ...
      (comp.lang.cobol)