From: Pete Dashwood on


<docdwarf(a)panix.com> wrote in message news:fk76nh$9se$1(a)reader1.panix.com...
> In article <5soie6F1a5e45U1(a)mid.individual.net>,
> Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote:
>>
>>
>>"Richard" <riplin(a)azonic.co.nz> wrote in message
>>news:f810a73e-cd25-43b8-ac63-10523d5a29b3(a)d4g2000prg.googlegroups.com...
>
> [snip]
>
>>> This may be why the style that I use has not been constructed around
>>> HIPO charts, arcane IBMisms and other stuff that derives directly from
>>> the 60s.
>>>
>>
>>As an old-time CICS programmer and someone who has therefore been exposed
>>to
>>EIBCALEN I agree with Richard that this archaic.
>>
>>The code is testing to see if this is an initial conversation or not, and
>>it
>>is as simple as that. As such, I find Richard's objections to be pefectly
>>reasonable.
>
> Mr Dashwood, I can see why Mr Plinston doesn't catch on so very quickly...
> but can you, as well, really say that you object to the test for EIBCALEN

<sorry for mid-sentence interruption, but the sentence does go on a bit...
:-)>

No, Doc, I'm not objecting to the test for EIBCALEN being zero; that would
be stupid. It HAS to be tested. What I'm objecting to (and I believe it was
also Richard's objection...) is the WAY in which it is tested. It is not
informative or immediately obvious what the test is for or why it is needed.
To me, it smacks of the old "Well, we are a closed Brotherhood here and if
you don't know CICS you shouldn't be maintaining our code" school of COBOL
Priesthood. That defeats te purpose of COBOL and, at least in my opinion,
demeans the language.

> (essentially, for those out there not familiar with the conventions of the
> Customer Information Command System, the Exec(ution) Interface Block
> Common Area Length, set, by definition, to zero the first time the program
> is entered and to greater-than-zero for each subsequent entry) and see no
> similarity to Mr Plinston's pseudocoding of
>
> Procedure Division.
>
> If ( Already-Read NOT = "Y" )
> read ..
> MOVE "Y" TO Already-Read
> END-IF
>
> do whatever with data ..
>
> ... as both being similar 'first time in' methods?
>
> [snip]
>
>>In my opinion, it would be better to simply change the COMM-AREA copy book
>>so that EIBCALEN had an 88 as follows:
>>
>>....EIBCALEN PIC S9(whatever...depending on your version of CICS)
>> 88 NEW-CONVERSATION VALUE ZERO.
>
> An 88-level? Mr Plinston has raised objections to those, as well... but
> that's for another time, perhaps.

Yes, I know Richard doesn't like 88 levels and I understand why he doesn't,
but I don't necessarily share his aversion... :-)

Pete.
--
"I used to write COBOL...now I can do anything."


From: Pete Dashwood on


"Howard Brazee" <howard(a)brazee.net> wrote in message
news:dd8em3do4luk6tha74poeiaig874822g0t(a)4ax.com...
> On Mon, 17 Dec 2007 18:39:57 -0500, "Charles Hottel"
> <chottel(a)earthlink.net> wrote:
>
>>By having all paragraph names start with a sequence number of the same
>>size
>>I can use a ROSCOE command like "DELETEX 13 13 /-/ " to delete all lines
>>that do not have a dash in column 13. This allows me to get all the
>>paragraph names in the program with a single command and save then in a
>>ROSCOE member named T1. Then using DELETEX commands to find all PERFORM,
>>CALL, GO TO, EXEC CICS LINK, EXEC CICS XCTL etc I save each result in T2,
>>T3, .... Then I can MERGE T1, T2, .... Tn and see at a glance the flow
>>of
>>control through the program and its paragraphs.
>
> In ISPF, it is easy to find paragraph names if I know they follow such
> a standard f p'#' 8
>
> Sometimes an obsolete fashion fits "obsolete" tools and environments.
> Changing a style to fit the strengths of an editor that I don't have
> is not constructive.

As usual, a very apposite observation.

For people who have not worked in the IBM mainframe environment, ((but have
worked in multiple other modern environments) it is really difficult to see
how tools like ISPF (which most mainframe programmers get to know and love)
are so "limited". The fact is (as you pointed out) that they AREN'T limited
to people who are used to working within those particular constraints and
the users don't even see them as "constraining".

This was brought home to me a few days after I made the transition from
using the Fujitsu IDE to using VS 2005 with C#. I had never realised how
much I was actually "constrained" by the old tool, until I was "set free" by
the new one.

Pete.
--
"I used to write COBOL...now I can do anything."


From: Richard on
On Dec 19, 10:30 am, "Pete Dashwood"
<dashw...(a)removethis.enternet.co.nz> wrote:
> <docdw...(a)panix.com> wrote in messagenews:fk76nh$9se$1(a)reader1.panix.com...
> > In article <5soie6F1a5e4...(a)mid.individual.net>,
> > Pete Dashwood <dashw...(a)removethis.enternet.co.nz> wrote:
>
> >>"Richard" <rip...(a)azonic.co.nz> wrote in message
> >>news:f810a73e-cd25-43b8-ac63-10523d5a29b3(a)d4g2000prg.googlegroups.com...
>
> > [snip]
>
> >>> This may be why the style that I use has not been constructed around
> >>> HIPO charts, arcane IBMisms and other stuff that derives directly from
> >>> the 60s.
>
> >>As an old-time CICS programmer and someone who has therefore been exposed
> >>to
> >>EIBCALEN I agree with Richard that this archaic.
>
> >>The code is testing to see if this is an initial conversation or not, and
> >>it
> >>is as simple as that. As such, I find Richard's objections to be pefectly
> >>reasonable.
>
> > Mr Dashwood, I can see why Mr Plinston doesn't catch on so very quickly...
> > but can you, as well, really say that you object to the test for EIBCALEN
>
> <sorry for mid-sentence interruption, but the sentence does go on a bit...
> :-)>
>
> No, Doc, I'm not objecting to the test for EIBCALEN being zero; that would
> be stupid. It HAS to be tested. What I'm objecting to (and I believe it was
> also Richard's objection...) is the WAY in which it is tested. It is not
> informative or immediately obvious what the test is for or why it is needed.
> To me, it smacks of the old "Well, we are a closed Brotherhood here and if
> you don't know CICS you shouldn't be maintaining our code" school of COBOL
> Priesthood. That defeats te purpose of COBOL and, at least in my opinion,
> demeans the language.
>
>
>
> > (essentially, for those out there not familiar with the conventions of the
> > Customer Information Command System, the Exec(ution) Interface Block
> > Common Area Length, set, by definition, to zero the first time the program
> > is entered and to greater-than-zero for each subsequent entry) and see no
> > similarity to Mr Plinston's pseudocoding of
>
> > Procedure Division.
>
> > If ( Already-Read NOT = "Y" )
> > read ..
> > MOVE "Y" TO Already-Read
> > END-IF
>
> > do whatever with data ..
>
> > ... as both being similar 'first time in' methods?
>
> > [snip]
>
> >>In my opinion, it would be better to simply change the COMM-AREA copy book
> >>so that EIBCALEN had an 88 as follows:
>
> >>....EIBCALEN PIC S9(whatever...depending on your version of CICS)
> >> 88 NEW-CONVERSATION VALUE ZERO.

Looking at your 88 level which has an alleged meaningful name of "New-
Conversation" I now find that it is even less of a 'first-time-in'.

The actual EIBCALEN, I had determined by scanning the documentation,
is the LENgth of some data. That alone just means 'there is some data'
or 'there is no data' without indicating first, last, between, or
random.

Now it would seem, from your name, that it may be zero on many
occasions, or is this routine CANCELled at the end of each
conversation ?

So, even with knowing what EIBCALEN is, and your interpretation of
what it means when zero, it is still not clear, without reading
further documentation, that it is Doc's alleged 'first-time-in' (when
it is actually a separate 'initialization' anyway).

It seems that 'Good Style' is 'whatever deliberately keeps code
obscure'.


> > An 88-level? Mr Plinston has raised objections to those, as well... but
> > that's for another time, perhaps.
>
> Yes, I know Richard doesn't like 88 levels and I understand why he doesn't,
> but I don't necessarily share his aversion... :-)
>
> Pete.
> --
> "I used to write COBOL...now I can do anything."

From: Richard on
On Dec 19, 1:37 am, docdw...(a)panix.com () wrote:
> In article <28fef15e-4fb6-475c-935c-1fd98b65a...(a)e23g2000prf.googlegroups.com>,
>
>
>
> Richard <rip...(a)azonic.co.nz> wrote:
> >On Dec 18, 2:11 pm, docdw...(a)panix.com () wrote:
> >> In article <5soie6F1a5e4...(a)mid.individual.net>,
>
> >> Pete Dashwood <dashw...(a)removethis.enternet.co.nz> wrote:
>
> >> >"Richard" <rip...(a)azonic.co.nz> wrote in message
> >> >news:f810a73e-cd25-43b8-ac63-10523d5a29b3(a)d4g2000prg.googlegroups.com...
>
> >> [snip]
>
> >> >> This may be why the style that I use has not been constructed around
> >> >> HIPO charts, arcane IBMisms and other stuff that derives directly from
> >> >> the 60s.
>
> >> >As an old-time CICS programmer and someone who has therefore been exposed to
> >> >EIBCALEN I agree with Richard that this archaic.
>
> >> >The code is testing to see if this is an initial conversation or not, and it
> >> >is as simple as that. As such, I find Richard's objections to be pefectly
> >> >reasonable.
>
> >> Mr Dashwood, I can see why Mr Plinston doesn't catch on so very quickly...
> >> but can you, as well, really say that you object to the test for EIBCALEN
> >> (essentially, for those out there not familiar with the conventions of the
> >> Customer Information Command System, the Exec(ution) Interface Block
> >> Common Area Length, set, by definition, to zero the first time the program
> >> is entered and to greater-than-zero for each subsequent entry) and see no
> >> similarity to Mr Plinston's pseudocoding of
>
> >> Procedure Division.
>
> >> If ( Already-Read NOT = "Y" )
> >> read ..
> >> MOVE "Y" TO Already-Read
> >> END-IF
>
> >> do whatever with data ..
>
> >> ... as both being similar 'first time in' methods?
>
> >Actually the 'EIBCALEN code' was an alternate. It used an ELSE and did
> >one thing _or_ the other.
>
> That might be why, Mr Plinston, it was described as 'similar' and not
> 'identical'. The difference between the two might be discenred by those
> with access to an English dictionary or a bit of education.
>
> >> To be similar it should be:
>
> >>> IF EIBCALEN = 0
> >>> PERFORM 0000-HOUSEKEEPING THRU 0000-HSK-EX
> > END-IF
> > PERFORM 5000-PROCESS-INPUT THRU 5000-PI-EX.
>
> That, to my eye, would change it from similar -

"IF a END-IF b". is not 'similar' to "IF a ELSE b END-IF". They are
different structures. Or do you think that all code is 'similar'. You
may even want to claim that a triangle is 'similar' to a square.

> having the characteristic
> of a first-time-in test in common -

That is only because your eye has arcane codes burnt into it. Without
that there is nothing that identifies it as a 'first time-in test'. No
meaningful name to indicate what it is, no isolation of the first-time-
in code, no setting of the flag to prevent rerunning that code.

And more importantly it seems that in your code 'Process-Input' is
_not_ performed when 'Housekeeping' is. This may be a
'initialization' (with no input), or a 'first-time' (is Process-Input'
is performed from Housekeeping) or a 'after-end-of-input', or a
'between inputs'.

You see what you are used to and consistently fail to recognise that
others have different experience.

> to being identical. What
> characteristics do you see in your change which prevent this?

No identification that this is a first-time-in flag.

No resetting of the flag to prevent re-executing the code.

And the code itself is stylistically different, with PERFORM THRU vs
PERFORM.

You haven't denied that you think of this as 'Good Style', yet it
obviously fails the clarity test, except of course to those who
already have been told what it does.

You obviously recognised that _my_ code was 'first-time-in' because I
had deliberately included the characteristics of this to make it
clear: a meaningful name, even to those who don't live with CICS;
explicit initial value; resetting the flag within the IF branch
(rather than externally or in the PERFORMed code); continuing after
the first-time-in with the every-time-in.



From: Richard on
On Dec 19, 1:30 am, docdw...(a)panix.com () wrote:
> In article <a2c7c77f-c37a-4388-8e39-790d9f1c9...(a)s8g2000prg.googlegroups.com>,
>
>
>
> Richard <rip...(a)azonic.co.nz> wrote:
> >On Dec 18, 2:15 pm, docdw...(a)panix.com () wrote:
> >> In article
> ><52f573e5-d849-4edd-b14d-b36d4a516...(a)e23g2000prf.googlegroups.com>,
>
> >> Richard <rip...(a)azonic.co.nz> wrote:
> >> >On Dec 18, 1:58 pm, docdw...(a)panix.com () wrote:
> >> >> In article
> ><93ab7ada-5595-4c0f-ad9d-3c5d77d13...(a)b1g2000pra.googlegroups.com>,
>
> >> >> Richard <rip...(a)azonic.co.nz> wrote:
> >> >> >On Dec 18, 6:43 am, docdw...(a)panix.com () wrote:
> >> >> >> In article <u7bdm3tu3vjc5vof12f5mfu48e6einq...(a)4ax.com>,
> >> >> >> Howard Brazee <how...(a)brazee.net> wrote:
>
> >> >> >> [snip]
>
> >> >> >> >But
> >> >> >> >having or not having sequence numbers in paragraph names says nothing
> >> >> >> >about the quality of the code.
>
> >> >> >> Mr Brazee, some people feel *very* deeply about these matters... my memory
> >> >> >> is, admittedly, porous but I recall someone posting to this newsgroup
> >> >> >> claiming that changing the case in which code was written, from mixed to
> >> >> >> upper, changed it from 'good' to 'bad' code.
>
> >> >> >It certainly would do in very many languages.
>
> >> >> There was only one being discussed at the time, Mr Plinston... care to
> >> >> muster a guess as to which? As a hint I'll pass along that it was not one
> >> >> that requires one a verb at the end of a sentence to put.
>
> >> >Which appears to indicate that you are not prepared to learn anything
> >> >from other languages.
>
> >> I'll take that as a 'no, I cannot guess what was being discussed at that
> >> time'.
>
> >That would not be an answer to the actual question asked.
>
> >An actual answer may be: "No, I don't care".
>
> And yet... you spend so much time at it!

I didn't spend any time at all on your question. Nor on guessing. Nor
on attempting to work out what "it was not one
that requires one a verb at the end of a sentence to put." was
supposed to mean.