Re: working storage values



Thanks for your support, Arnold.

I thought it was a "lost cause"... :-)

Pete.

TOP POST -nothing more below...
--
"I used to write COBOL...now I can do anything."
"Arnold Trembley" <arnold.trembley@xxxxxxxxxxxxxxxx> wrote in message
news:MQpaj.62339$MJ6.60290@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Pete Dashwood wrote:
((snip) No, the fact is that CICS is a susbsystem and the program is in
COBOL. Therefore, a COBOL programmer SHOULD have a fighting chance of
being able to maintain it. I would contend that, even without having had
training in CICS, a competent COBOL programmer SHOULD be able to see from
various calls made by the program, how it interfaces with CICS.
(Especially if it is coded for the command level pre-processor; macro
level is somewhat more esoteric and that may be why it has fallen into
disuse...) You don't need to know every detail of every possible CICS
call in order to MAINTAIN a CICS program written in COBOL; you might need
to know a lot more in order to CREATE a CICS program. It isn't quite as
black and white as you suggest.

I agree with you that a competent COBOL programmer should be able to
maintain a CICS COBOL program without knowing CICS. But the Command Level
CICS is the only supported interface since CICS 3.x was released in the
early 1990's. The Macro-level interface is no longer supported. Back in
1985 IBM was telling us that macro-level CICS would be dropped at some
point in the future.


This leads me to my point that there is no reason for CICS to be
deliberately obtuse or arcane, when used in a COBOL environment. The
standard "good practices" used to make COBOL programs more intelligible
CAN be applied to CICS, but they AREN'T because "we've always done it
that way".

Again, I agree with you, and I try to write CICS COBOL programs so they
are understandable. Not all CICS programs are pseudo-conversational, but
I do know that upon entry to a CICS program, if EIBCALEN=0 there is no
dialog input in DFHCOMMAREA. It's not an error, it just means that the
program must send the first dialog message before any User dialog input
can be received.

(snip)

Well the "Anciente Wisdome" is a bit off the beam here... (maybe that's
why we're having this discussion...:-))

A modern programmer will have had minimal COBOL and be required to pick
it up, and if CICS is added to that mix, anything we can do to make life
easier for him/her has to be a "Good Thing".

I don't see how anyone can disagree with that, and I would argue that it's
still a good thing even if the maintenance programmer is an expert in both
COBOL and CICS.


I am not arguing about what is DESIRABLE, rather about what ACTUALLY
HAPPENS... (Don't let's get sidetracked into lack of training and so
on...)

Pete.

With kindest regards,


--
http://arnold.trembley.home.att.net/


.



Relevant Pages

  • Re: working storage values
    ... I would contend that, even without having had training in CICS, a competent COBOL programmer SHOULD be able to see from various calls made by the program, how it interfaces with CICS. ... But the Command Level CICS is the only supported interface since CICS 3.x was released in the early 1990's. ...
    (comp.lang.cobol)
  • when to use CICS
    ... Not sure if this is a CICS q but since the CICS group seems to be ... need to display is in DB2 tables on a z/OS box. ... So, being an ex COBOL programmer, I can write some trivial CICS ... into my Java app and display formatted as HTML. ...
    (bit.listserv.ibm-main)
  • help and direction
    ... I am a Cobol programmer on IBM MF, with all the going on I would like ... I would have like to learn how to connect CICS to web browsers (if it ...
    (comp.lang.cobol)