brain teaser
Frank Swarbrick
me?
The latter, but here it is anyway. Refactor the following paragraph in
order to eliminate the gotos.
SEND-PAGE.
PERFORM CALC-PAGE-FIELDS-BEFORE
PERFORM SEND-OUT
SUBTRACT DOCSND FROM BYTES-TO-SEND
COMPUTE REFLEN = DOCUMENT-LEN + SAVE-LEN - DOCSNDTOT
IF BYTES-TO-SEND > ZERO
MOVE DOCUMENT-AREA (DOCREF:) TO SAVE-AREA (1:REFLEN)
IF LAST-CALL
OR REFLEN > EXT-OUTPUT-LEN
ADD DOCSND TO DOCREF
IF LAST-CALL
SET LAST-SEND TO TRUE
END-IF
GO TO SEND-PAGE
ELSE
MOVE REFLEN TO SAVE-LEN
END-IF
ELSE
IF EXTRA-PAGE-NEEDED
GO TO SEND-PAGE
END-IF
END-IF
EXIT.
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
Richard
It is probably going to be something like:
Send-Page.
PERFORM
WITH TEST AFTER
UNTIL Bytes-To-Send NOT > ZERO
AND NOT Extra-Page-Needed
....
END-PERFORM
.
Oliver Wong
"Frank Swarbrick" <Frank.S...@efirstbank.com> wrote in message
news:4c9qskF...@individual.net...
* Add a new 88 called TIME-TO-STOP
SEND-PAGE.
PERFORM
WITH TEST AFTER
UNTIL ((BYTES-TO-SEND <= ZERO AND NOT EXTRA-PAGE-NEEDED) OR
TIME-TO-STOP)
PERFORM CALC-PAGE-FIELDS-BEFORE
PERFORM SEND-OUT
SUBTRACT DOCSND FROM BYTES-TO-SEND
COMPUTE REFLEN = DOCUMENT-LEN + SAVE-LEN - DOCSNDTOT
IF BYTES-TO-SEND > ZERO
MOVE DOCUMENT-AREA (DOCREF:) TO SAVE-AREA (1:REFLEN)
IF LAST-CALL
OR REFLEN > EXT-OUTPUT-LEN
ADD DOCSND TO DOCREF
IF LAST-CALL
SET LAST-SEND TO TRUE
END-IF
ELSE
MOVE REFLEN TO SAVE-LEN
SET TIME-TO-STOP TO TRUE
END-IF
END-IF
END-PERFORM
EXIT.
- Oliver
Roberto
> eliminate the gotos
* add ws sw-loop-off
SEND-PAGE.
move 0 to sw-loop-off
perform until sw-loop-off = 0
move 1 to sw-loop-off
PERFORM CALC-PAGE-FIELDS-BEFORE
PERFORM SEND-OUT
SUBTRACT DOCSND FROM BYTES-TO-SEND
COMPUTE REFLEN = DOCUMENT-LEN + SAVE-LEN - DOCSNDTOT
IF BYTES-TO-SEND > ZERO
MOVE DOCUMENT-AREA (DOCREF:) TO SAVE-AREA (1:REFLEN)
IF LAST-CALL
OR REFLEN > EXT-OUTPUT-LEN
ADD DOCSND TO DOCREF
IF LAST-CALL
SET LAST-SEND TO TRUE
END-IF
move 0 to sw-loop-off
ELSE
MOVE REFLEN TO SAVE-LEN
END-IF
ELSE
IF EXTRA-PAGE-NEEDED
move 0 to sw-loop-off
END-IF
END-IF
end-perform.
EXIT.
----------------------
* Better:
routine-before.
move 0 to sw-loop-off
perform send-page until sw-loop-off = 0
....
SEND-PAGE.
move 1 to sw-loop-off
PERFORM CALC-PAGE-FIELDS-BEFORE
PERFORM SEND-OUT
SUBTRACT DOCSND FROM BYTES-TO-SEND
COMPUTE REFLEN = DOCUMENT-LEN + SAVE-LEN - DOCSNDTOT
IF BYTES-TO-SEND > ZERO
MOVE DOCUMENT-AREA (DOCREF:) TO SAVE-AREA (1:REFLEN)
IF LAST-CALL
OR REFLEN > EXT-OUTPUT-LEN
ADD DOCSND TO DOCREF
IF LAST-CALL
SET LAST-SEND TO TRUE
END-IF
move 0 to sw-loop-off
ELSE
MOVE REFLEN TO SAVE-LEN
END-IF
ELSE
IF EXTRA-PAGE-NEEDED
move 0 to sw-loop-off
END-IF
END-IF
EXIT.
Roger While
The default if neither TEST BEFORE nor TEST AFTER phrase
is sepecified is TEST BEFORE.
Therefore you will not perform anything.
"Roberto" <re.l...@kataLAmail.com> schrieb im Newsbeitrag
news:1hf2bsv.1bvmkwfqdabhaN%re.l...@kataLAmail.com...
Howard Brazee
<Frank.S...@efirstbank.com> wrote:
>Is this a brain teaser or am I just trying to get someone to do my work for
>me?
It doesn't qualify as a brain teaser.
Günther De Vogelaere
PERFORM SEND-PAGE UNTIL JOBDONE
SEND-PAGE.
PERFORM CALC-PAGE-FIELDS-BEFORE
PERFORM SEND-OUT
SUBTRACT DOCSND FROM BYTES-TO-SEND
COMPUTE REFLEN = DOCUMENT-LEN + SAVE-LEN - DOCSNDTOT
IF BYTES-TO-SEND > ZERO
MOVE DOCUMENT-AREA (DOCREF:) TO SAVE-AREA (1:REFLEN)
IF LAST-CALL
ADD DOCSND TO DOCREF
SET LAST-SEND TO TRUE
ELSE
IF REFLEN > EXT-OUTPUT-LEN THEN
ADD DOCSND TO DOCREF
ELSE
MOVE REFLEN TO SAVE-LEN
SET JOBDONE TO TRUE
END-IF
END-IF
ELSE
IF NOT EXTRA-PAGE-NEEDED
SET JOBDONE TO TRUE
END-IF
END-IF
.
Roberto
> The default if neither TEST BEFORE nor TEST AFTER phrase
> is sepecified is TEST BEFORE.
Oopps, I know it. I wroted wrong sentence, sorry.
This the correct source:
SEND-PAGE.
move 0 to sw-loop-off
* ---------------------------------------- changed
perform until sw-loop-off = 1
* ----------------------------------------
Frank Swarbrick
IBM COBOL for VSE does not require EXIT to be in a paragraph by itself
(thank goodness!). Even if it did I'd just use CONTINUE instead, though
it's meaning would not be as obvious...
>It is probably going to be something like:
>
> Send-Page.
> PERFORM
> WITH TEST AFTER
> UNTIL Bytes-To-Send NOT > ZERO
> AND NOT Extra-Page-Needed
> ....
>
> END-PERFORM
> .
That doesn't seem to take in to account the case when LAST-CALL is true or
REFLEN > EXT-OUTPUT-LEN, in which case we want to do another send unless
BYTES-TO-SEND = ZERO.
I just think it's cleaner and easier to understand *with* the GOTOs...
Anyway, to clarify what my goal is here... We'll always send one "page".
If DOCUMENT-AREA contains more than one page (REFLEN > EXT-OUTPUT-LEN) then
it should send the remaining *full* pages. Any partial page that is left
over should be saved in SAVE-AREA and not sent, unless there are no more
pages to be sent (LAST-CALL is true), in which case we do want to send the
partial page.
(When we come back through we concatinate DOCUMENT-AREA to the end of
SAVE-AREA and do it all again.)
Just for the heck of it, here's the entire routine:
ID DIVISION.
PROGRAM-ID. 'SEND-DOCUMENT'.
THIS ROUTINE WILL SEND THE CURRENT DOCUMENT (PLUS ANY
HOLDOVER) AND SAVE ANY (NEW) HOLDOVER FOR THE NEXT TIME
THIS ROUTINE IS CALLED.
IF WE KNOW THAT THIS IS THE LAST TIME THIS ROUTINE
WILL BE CALLED WE'LL GO AHEAD AND SEND THE SAVE-LEN ALSO.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 CONSTANTS.
05 MSG-START-CHAR PIC X VALUE '{'.
05 MSG-END-CHAR PIC X VALUE '}'.
05 MSG-FIELD-DELIMITER PIC X VALUE 'Ś'.
01.
05 X PIC X.
05 SAVE-LEN PIC S9(5) COMP-3 VALUE ZERO.
05 SEND-LEN PIC S9(4) COMP.
05 BYTES-TO-SEND PIC S9(9) COMP-3.
05 REFPOS PIC S9(4) COMP.
05 REFLEN PIC S9(4) COMP.
05 ADJ PIC S9(4) COMP VALUE ZERO.
05 DOCREF PIC S9(4) COMP.
05 DOCSND PIC S9(4) COMP.
05 DOCSNDTOT PIC S9(5) COMP-3.
05 LAST-SEND-SW PIC X VALUE 'N'.
88 LAST-SEND VALUE 'Y'.
05 EXTRA-PAGE-SW PIC X VALUE 'N'.
88 EXTRA-PAGE-NEEDED VALUE 'Y'.
01 DOCUMENT-AREA.
05 PIC X OCCURS 0 TO 9999 TIMES
DEPENDING ON DOCUMENT-LEN.
01 DOCUMENT-LEN PIC S9(8) COMP.
01 TERM-ID PIC X(4).
01 MSG-ID PIC X(4).
01 LAST-CALL-FLAG PIC X.
88 LAST-CALL VALUE 'Y'.
01 SAVE-AREA.
05 PIC X(20000).
01 SEND-AREA.
05 PIC X OCCURS 0 TO 9999 TIMES
DEPENDING ON SEND-LEN.
PROCEDURE DIVISION USING DOCUMENT-AREA DOCUMENT-LEN
LAST-CALL-FLAG
TERM-ID MSG-ID.
IF ADDRESS OF SAVE-AREA = NULL
PERFORM INIT
END-IF
PERFORM CALC-DOC-FIELDS
PERFORM SEND-PAGE
EXIT PROGRAM.
INIT.
EXEC CICS GETMAIN
SET (ADDRESS OF SAVE-AREA)
FLENGTH (LENGTH OF SAVE-AREA)
END-EXEC
MOVE LENGTH OF MSG-START-CHAR TO SAVE-LEN
MOVE MSG-START-CHAR TO SAVE-AREA (1:SAVE-LEN)
EXIT.
CALC-DOC-FIELDS.
COMPUTE REFPOS = SAVE-LEN + 1
COMPUTE BYTES-TO-SEND = DOCUMENT-LEN + SAVE-LEN
COMPUTE REFLEN = EXT-OUTPUT-LEN - REFPOS + 1
MOVE DOCUMENT-AREA TO SAVE-AREA (REFPOS:REFLEN)
COMPUTE DOCREF = REFLEN + 1
MOVE ZEROES TO DOCSNDTOT
EXIT.
SEND-PAGE.
PERFORM CALC-PAGE-FIELDS-BEFORE
PERFORM SEND-OUT
SUBTRACT DOCSND FROM BYTES-TO-SEND
COMPUTE REFLEN = DOCUMENT-LEN + SAVE-LEN - DOCSNDTOT
IF BYTES-TO-SEND > ZERO
MOVE DOCUMENT-AREA (DOCREF:) TO SAVE-AREA (1:REFLEN)
IF LAST-CALL
OR REFLEN > EXT-OUTPUT-LEN
ADD DOCSND TO DOCREF
IF LAST-CALL
SET LAST-SEND TO TRUE
END-IF
GO TO SEND-PAGE
ELSE
MOVE REFLEN TO SAVE-LEN
END-IF
ELSE
IF EXTRA-PAGE-NEEDED
GO TO SEND-PAGE
END-IF
END-IF
CALC-PAGE-FIELDS-BEFORE.
IF BYTES-TO-SEND > EXT-OUTPUT-LEN
COMPUTE DOCSND = EXT-OUTPUT-LEN
ELSE
COMPUTE DOCSND = BYTES-TO-SEND
END-IF
ADD DOCSND TO DOCSNDTOT
COMPUTE REFPOS = DOCSND + 1
COMPUTE REFLEN = FUNCTION LENGTH(MSG-ID)
IF (LAST-CALL AND DOCSND = BYTES-TO-SEND)
OR LAST-SEND
* IF THERE IS ROOM FOR THE MSG-ID BUT NOT FOR THE
* MSG-END CHAR WE NEED TO JUST SEND THE MSG-ID
* AND THEN FOLLOW IT WITH AN EXTRA PAGE CONTAINING
* ONLY THE MSG-END CHAR AND THE MSG-ID
IF DOCSND + REFLEN > EXT-OUTPUT-LEN
SET EXTRA-PAGE-NEEDED TO TRUE
ELSE
MOVE LENGTH OF MSG-END-CHAR TO ADJ
MOVE MSG-END-CHAR TO SAVE-AREA (REFPOS:ADJ)
ADD ADJ TO REFPOS
END-IF
END-IF
MOVE MSG-ID TO SAVE-AREA (REFPOS:REFLEN)
COMPUTE SEND-LEN = DOCSND + REFLEN + ADJ
SET ADDRESS OF SEND-AREA TO ADDRESS OF SAVE-AREA
EXIT.
SEND-OUT.
IF EIBTRMID > SPACES
PERFORM TERMINAL-OUT
ELSE
PERFORM PSEUDOTERMINAL-OUT
END-IF
EXIT.
TERMINAL-OUT.
EXEC CICS SEND
FROM (SEND-AREA)
LENGTH (SEND-LEN)
ERASE
END-EXEC
EXEC CICS RECEIVE
INTO (X)
MAXLENGTH (1)
NOHANDLE
END-EXEC
IF EIBAID = DFHCLEAR
EXEC CICS RETURN
END-EXEC
END-IF
EXIT.
'SEND-DOCUMENT' should be called when DOCUMENT (which is the part of an XML
document that we have built but not yet "sent") is at least the size of one
"page", or we've built the entire document. As you can see, it inserts a
'{' as the first character of the first page, puts a four character MSG-ID
at the end of every page, and puts a '}' after the end of the document. (a
'legacy' interface depends on these special delimiters, otherwise I wouldn't
bother...)
Anyway, it all seems to be working, so I'm hesitant to screw with it, but
that "don't use goto" voice still niggles at me...
Frank Swarbrick
That might work (haven't tried it yet), but there are two things I don't
like about it:
1) I hate using extra flags just for this kind of thing.
2) I don't like to perform the same basic calculation twice (UNTIL
BYTES-TO-SEND <= ZERO; IF BYTES-TO-SEND > ZERO)
Howard Brazee
<Frank.S...@efirstbank.com> wrote:
>IBM COBOL for VSE does not require EXIT to be in a paragraph by itself
>(thank goodness!). Even if it did I'd just use CONTINUE instead, though
>it's meaning would not be as obvious...
Are you sure? I use IBM COBOL for OS/390 & VM 2.2.2, and when I
have added a display statement to an EXIT paragraph, I got an error.
So if I want the display to be with a "D" in column 7, I started
changing existing EXIT to CONTINUE a while ago. It may be long
enough ago that I was using a different compiler though.
My programs don't have EXIT paragraphs, but I do maintenance as well.
Frank Swarbrick
You're right. It's more of "make it cleaner, if possible, with out using
GOTO's".
I'm not go to fan, honestly. But sometimes they are useful, at least in the
absense of things such as "EXIT PERFORM" and "EXIT PERFORM CYCLE".
Frank Swarbrick
This is my favorite (someone else posted something similar). It still has
the extra flag, which again I don't care for, but its very easy to follow
and doesn't have the "redundant calculation".
Here's my "final" version:
MOVE 'Y' TO SEND-MORE
PERFORM SEND-PAGE UNTIL SEND-MORE = 'N'
SEND-PAGE.
PERFORM CALC-PAGE-FIELDS-BEFORE
PERFORM SEND-OUT
SUBTRACT DOCSND FROM BYTES-TO-SEND
COMPUTE REFLEN = DOCUMENT-LEN + SAVE-LEN - DOCSNDTOT
IF BYTES-TO-SEND > ZERO
MOVE DOCUMENT-AREA (DOCREF:) TO SAVE-AREA (1:REFLEN)
IF LAST-CALL
OR REFLEN > EXT-OUTPUT-LEN
ADD DOCSND TO DOCREF
IF LAST-CALL
SET LAST-SEND TO TRUE
END-IF
ELSE
MOVE 'N' TO SEND-MORE
MOVE REFLEN TO SAVE-LEN
END-IF
ELSE
IF NOT EXTRA-PAGE-NEEDED
MOVE 'N' TO SEND-MORE
END-IF
END-IF
EXIT.
Not too bad. I think I'll keep it. (I just got hung up on not wanting the
extra flag.)
Howard Brazee
<Frank.S...@efirstbank.com> wrote:
>
>I'm not go to fan, honestly. But sometimes they are useful, at least in the
>absense of things such as "EXIT PERFORM" and "EXIT PERFORM CYCLE".
At least when doing significant maintenance to an existing program.
But at least one of the solutions involved GO TO THIS-PARAGRAPH, which
is not replaced by an EXIT PERFORM. (Some languages have this
option).
Howard Brazee
<Frank.S...@efirstbank.com> wrote:
>Not too bad. I think I'll keep it. (I just got hung up on not wanting the
>extra flag.)
What sets LAST-CALL? Two flags appear to be similar, LAST-CALL and
SEND-MORE.
Richard
Frank Swarbrick wrote:
> IBM COBOL for VSE does not require EXIT to be in a paragraph by itself
> (thank goodness!).
No, but Cobol standard does and that makes your code less portable.
> Even if it did I'd just use CONTINUE instead, though
> it's meaning would not be as obvious...
What is 'obvious' is entirely what one is used to. To some an 'EXIT'
may _obviously_, well, do an exit. I have seen an attempt to EXIT from
inside the middle of an IF.
> That doesn't seem to take in to account the case when LAST-CALL is true or
> REFLEN > EXT-OUTPUT-LEN,
Those are only tested when Bytes-To-Send > ZERO so they don't need to
be in the UNTIL.
> in which case we want to do another send unless
> BYTES-TO-SEND = ZERO.
Exactly.
> I just think it's cleaner and easier to understand *with* the GOTOs...
What is 'easier to understand' is entirely what one is used to. If you
were to work with clean gotoless code then it would become easier to
understand, but you need to force yourself by either doing it or
working with other languages such as C or Python or and/by doing OO.
Fiddling with single paragraphs to remove a couple of gotos is not
going to make the transition to a better way of dealing with program
structure.
It is like having wattle and daub huts and then hearing that
wood-framing with siding is better. Trying to put in a piece of
wood-frame or putting siding over the wattle just doesn't do it.
> Anyway, to clarify what my goal is here... We'll always send one "page".
> If DOCUMENT-AREA contains more than one page (REFLEN > EXT-OUTPUT-LEN) then
> it should send the remaining *full* pages. Any partial page that is left
> over should be saved in SAVE-AREA and not sent, unless there are no more
> pages to be sent (LAST-CALL is true), in which case we do want to send the
> partial page.
Having a specification for what 'send-page' does is good.
One of the reasons that I said 'probably' in the original is that
without the full spec or the full program it may have not been possible
to see all the conditions that may occur.
Richard
Frank Swarbrick wrote:
> I'm not go to fan, honestly. But sometimes they are useful, at least in the
> absense of things such as "EXIT PERFORM" and "EXIT PERFORM CYCLE".
I dislike the use of the 'EXIT ...' statements which are a form of
goto. The main reason is that I move code around: cut a block from
within an inline perform or a nested if and make it into a paragraph so
I can reuse it, or just to simplify the levels of nesting. _Anything_
that is positionally dependent is just not used.
Frank Swarbrick
>
>Frank Swarbrick wrote:
>
>> IBM COBOL for VSE does not require EXIT to be in a paragraph by itself
>> (thank goodness!).
>
>No, but Cobol standard does and that makes your code less portable.
I'll use EXIT PARAGRAPH as soon as its available for my compiler. Until
then I'm sticking with what works for me...
>> Even if it did I'd just use CONTINUE instead, though
>> it's meaning would not be as obvious...
>
>What is 'obvious' is entirely what one is used to. To some an 'EXIT'
>may _obviously_, well, do an exit. I have seen an attempt to EXIT from
>inside the middle of an IF.
I know it *doesn't* work, but whoever came up with that was deranged
anyway... :-)
>> That doesn't seem to take in to account the case when LAST-CALL is true
or
>> REFLEN > EXT-OUTPUT-LEN,
>
>Those are only tested when Bytes-To-Send > ZERO so they don't need to
>be in the UNTIL.
>
>> in which case we want to do another send unless
>> BYTES-TO-SEND = ZERO.
>
>Exactly.
OK. I didn't do a long analysis of it. It may in fact, work. But too me
its not, umm, obvious, so I'm going to stick with what works for me.
>> I just think it's cleaner and easier to understand *with* the GOTOs...
>
>What is 'easier to understand' is entirely what one is used to. If you
>were to work with clean gotoless code then it would become easier to
>understand, but you need to force yourself by either doing it or
>working with other languages such as C or Python or and/by doing OO.
I do program (a bit) with languages such as C# and Ruby (Ruby doesn't even
*have* a goto statement; not sure about C# or Python), but they offer other
things (Ruby has Break, Next, Redo and Retry) that my COBOL compiler does
not. So until my COBOL compiler does have them I'm stuck with what I have.
If I were to do it in Ruby I might have...
def sendPage
loop do
calcPageFieldsBefore
sendOut
bytes_to_send -= doc_send
reflen = document_len + save_len - doc_snd_tot
break if bytes_to_send == 0
save_area[0...reflen] = document_area[docref...reflen] # don't
think this is quite right
if last_call or ref_len > ext_output_len
doc_ref += doc_snd
last_send = true if last_call
else
save_len = reflen
break
end
else
break unless extra_page_needed
end
end
The above probably isn't quite right, because Ruby ranges are [begin..end]
instead of (begin:length), and also start at 0 instead of 1, but anyway...
>Fiddling with single paragraphs to remove a couple of gotos is not
>going to make the transition to a better way of dealing with program
>structure.
>
>It is like having wattle and daub huts and then hearing that
>wood-framing with siding is better. Trying to put in a piece of
>wood-frame or putting siding over the wattle just doesn't do it.
True. But is that meant to imply that my code is totally wrong and should
be thrown out and replace with something totally different? If so, I'd be
curious to see it...
>> Anyway, to clarify what my goal is here... We'll always send one
"page".
>> If DOCUMENT-AREA contains more than one page (REFLEN > EXT-OUTPUT-LEN)
then
>> it should send the remaining *full* pages. Any partial page that is
left
>> over should be saved in SAVE-AREA and not sent, unless there are no more
>> pages to be sent (LAST-CALL is true), in which case we do want to send
the
>> partial page.
>
>Having a specification for what 'send-page' does is good.
>
>One of the reasons that I said 'probably' in the original is that
>without the full spec or the full program it may have not been possible
>to see all the conditions that may occur.
True enough. Which is why I later decided to post the entire routine.
Frank Swarbrick
>On Tue, 9 May 2006 10:27:32 -0600, "Frank Swarbrick"
><Frank.S...@efirstbank.com> wrote:
>
>>
>>I'm not go to fan, honestly. But sometimes they are useful, at least in
the
>>absense of things such as "EXIT PERFORM" and "EXIT PERFORM CYCLE".
>
>At least when doing significant maintenance to an existing program.
In this case this is a brand new program, written by me. (Yes, some people
do write brand new COBOL programs, contrary to what the tech magazines might
say... :-))
Frank
Frank Swarbrick
LAST-CALL-FLAG is an input parameter to the routine, indicating that "You
won't be called again, so you better send everything I'm giving you!".
LAST-SEND indicates that, not only is this the last time this routine is to
be performed but this is the last page that this routine is to send.
SEND-MORE indicates that we want to send another page during this current
iteration of the routine. But SEND-MORE = 'N' does not imply, in and of
itself, LAST-CALL or LAST-SEND.
Frank Swarbrick
I can't speak to that other IBM mainframe OS, but I can say for sure that
VSE supports it (and it's even documented as being an IBM extension).
William M. Klein
Are you certain?
According to:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3LR30/APPENDIX1.1
"Specifying the EXIT statement in a sentence that has statements before or
after the EXIT statement or in a paragraph that has other sentences. [Standard
COBOL 85 requires that the EXIT statement be specified in a sentence by itself
and that the sentence be the only sentence in the paragraph."
And although that has "revision bars" - I think it has been true of IBM
compilers for years.
--
Bill Klein
wmklein <at> ix.netcom.com
"Howard Brazee" <how...@brazee.net> wrote in message
news:9vf162d9tf8rqgo90...@4ax.com...
William M. Klein
If you didn't know, the '02 ANSI/ISO Standard *also* removed that restriction
(I beleive).
--
Bill Klein
wmklein <at> ix.netcom.com
"Richard" <rip...@Azonic.co.nz> wrote in message
news:1147202754....@u72g2000cwu.googlegroups.com...
HeyBub
> In this case this is a brand new program, written by me. (Yes, some
> people do write brand new COBOL programs, contrary to what the tech
> magazines might say... :-))
>
Only those too lazy to find reusable code !
For example, Wally reused code from an antique payroll program to build a
new, complete, air-traffic control system.
Don't fly on payday.
Howard Brazee
<wmk...@nospam.netcom.com> wrote:
>Howard,
> Are you certain?
>
>According to:
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3LR30/APPENDIX1.1
>
>"Specifying the EXIT statement in a sentence that has statements before or
>after the EXIT statement or in a paragraph that has other sentences. [Standard
>COBOL 85 requires that the EXIT statement be specified in a sentence by itself
>and that the sentence be the only sentence in the paragraph."
>
>And although that has "revision bars" - I think it has been true of IBM
>compilers for years.
A quick test shows that you are correct for my current compiler.
Sometimes I keep up a good practice when the need is no longer there
without knowing that it is no longer needed.
Howard Brazee
<Frank.S...@efirstbank.com> wrote:
>I do program (a bit) with languages such as C# and Ruby (Ruby doesn't even
>*have* a goto statement; not sure about C# or Python), but they offer other
>things (Ruby has Break, Next, Redo and Retry) that my COBOL compiler does
>not. So until my COBOL compiler does have them I'm stuck with what I have.
>If I were to do it in Ruby I might have...
Oddly enough, Java does have a limited GOTO statement, which was the
topic of a thread a couple of months ago.
Howard Brazee
<Frank.S...@efirstbank.com> wrote:
>>>I'm not go to fan, honestly. But sometimes they are useful, at least in
>the
>>>absense of things such as "EXIT PERFORM" and "EXIT PERFORM CYCLE".
>>
>>At least when doing significant maintenance to an existing program.
>
>In this case this is a brand new program, written by me. (Yes, some people
>do write brand new COBOL programs, contrary to what the tech magazines might
>say... :-))
With brand new programs, I have no reason to put in GO TOs. It is
easy enough to structure the program so that they are not needed
without adding clumsy switches.
babar
nothing. They don't mean anything. They should be used when you need
a statement and you don't want to say anything.
In the PROCEDURE DIVISION I use the CONTINUE statement to set off the
period at the end of a paragraph. I don't like a period on a line by
itself.
And sometimes I use it to make a positive IF statement. Sometimes a
positive IF statement just reads better. So I will code the following.
IF POSITIVE-CONDITION
CONTINUE
ELSE
PERFORM DO-NEGATIVE-THINGS
END-IF
Usually the POSITIVE-CONDITION is something like IF A = B AND (E = D OR
F not = G). Trying to get a negative of that has never been something
I am good at.
I also prefer CONTINUE to EXIT because there should be less confusion
with CONTINUE statement. The name EXIT just sounds like it is going to
do something, but it is not going to do anything.
I guess you could say that if the EXIT/CONTINUE statement does anything
it satisfies the compiler's need to have a statement in certain places.
Otherwise the compiler would generate an error.
William M. Klein
inside) a conditional statement. Many (some?) compilers allow this as an
extension, but it really should NOT be confused with CONTINUE.
--
Bill Klein
wmklein <at> ix.netcom.com
"babar" <wcr...@cityofchesapeake.net> wrote in message
news:1149621322....@f6g2000cwb.googlegroups.com...
Chuck Stevens
PERFORM, PROGRAM and SECTION rather than EXIT itself.
But to your main point, Bill, I agree: in my opinion *none* of them should
be considered equivalent to CONTINUE.
"The EXIT statement shall appear in a sentence by itself that shall be the
only sentence in the paragraph." states Syntax Rule 1 in the '02 standard
and the draft. Less rigorous wording with the same intent appears in the
'85, '74, and yes, '68 standards.
CONTINUE was introduced alongside scope-delimited statements in the '85
standard and can be used anywhere a conditional statement or imperative
statement may appear.
-Chuck Stevens
"William M. Klein" <wmk...@nospam.netcom.com> wrote in message
news:Yxkhg.274384$aA3.2...@fe06.news.easynews.com...
Roger While
confused world of Cobol syntax knows at least
some semblance of sanity, then this is Bill,
Thanks Bill.
Roger
"William M. Klein" <wmk...@nospam.netcom.com> schrieb im Newsbeitrag
news:Yxkhg.274384$aA3.2...@fe06.news.easynews.com...
Richard
babar wrote:
> Usually the POSITIVE-CONDITION is something like IF A = B AND (E = D OR
> F not = G). Trying to get a negative of that has never been something
> I am good at.
IF NOT ( positive statemnet )
eg
IF NOT ( A = B AND (E = D OR > F not = G) )
Roger While
Roger
"Richard" <rip...@Azonic.co.nz> schrieb im Newsbeitrag
news:1149627222....@g10g2000cwb.googlegroups.com...
Roger While
Roger
"Richard" <rip...@Azonic.co.nz> schrieb im Newsbeitrag
news:1149627222....@g10g2000cwb.googlegroups.com...
>
Richard
Roger While wrote:
> And try it as a condition on a WHEN syntax on an EVALUATE sentence.
When I cut and pasted from the original it left the spurious '>' quote
mark in.
> > IF NOT ( A = B AND (E = D OR > F not = G) )
IF NOT ( A = B AND (E = D OR F not = G) )
EVALUATE TRUE
WHEN ( A = B AND (E = D OR F not = G) )
DISPLAY "TRUE"
WHEN NOT ( A = B AND (E = D OR F not = G) )
DISPLAY "NOT TRUE"
WHEN OTHER
DISPLAY "There is no 'Other'"
END-EVALUATE
Roger While
Roger
"Richard" <rip...@Azonic.co.nz> schrieb im Newsbeitrag
news:1149630859....@g10g2000cwb.googlegroups.com...
charles hottel
"Roger While" <si...@sim-basis.de> wrote in message
news:e64u10$ndu$03$1...@news.t-online.com...
Richard
Roger While wrote:
> Without the initial parantheses
Why would I want to do it without the parentheses ?
In fact when I put it as: "IF NOT ( positive condition )" this implied
that the parentheses were required. So what point are you trying to
make ?
Rick Smith
> "Richard" <rip...@Azonic.co.nz> schrieb im Newsbeitrag
> news:1149627222....@g10g2000cwb.googlegroups.com...
> >
> > babar wrote:
> >
> >> Usually the POSITIVE-CONDITION is something like IF A = B AND (E = D OR
> >> F not = G). Trying to get a negative of that has never been something
> >> I am good at.
> >
> > IF NOT ( positive statemnet )
> >
> > eg
> > IF NOT ( A = B AND (E = D OR > F not = G) )
> >
EVALUATE positive-condition
WHEN FALSE
...
END-EVALUATE
Or
EVALUATE FALSE
WHEN positive-condition
...
END-EVALUATE
Howard Brazee
following code:
MY-EXIT.
EXIT.
D DISPLAY 'Found the exit'.
When we compile that code WITH DEBUGGING MODE, it turns the DISPLAY
from a comment into real code. Except now the program doesn't
compile because the EXIT is not in a paragraph by itself.
The following code is identical to the previous, except it will
compile correctly.
MY-EXIT.
CONTINUE.
D DISPLAY 'Found the exit'.
(I still don't code original programs with EXIT statements though).
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
Howard Brazee
If it's confusing to you, it will be confusing to a rookie programmer
who is called in the middle of the night to do some fix.
One way to make things more obvious to CoBOL programmers is to
remember the ELSE command:
IF (positive statement)
CONTINUE
ELSE
...
docd...@panix.com
Howard Brazee <how...@brazee.net> wrote:
>On 6 Jun 2006 13:53:42 -0700, "Richard" <rip...@Azonic.co.nz> wrote:
>
>>> Usually the POSITIVE-CONDITION is something like IF A = B AND (E = D OR
>>> F not = G). Trying to get a negative of that has never been something
>>> I am good at.
>>
>> IF NOT ( positive statemnet )
>>
>>eg
>> IF NOT ( A = B AND (E = D OR > F not = G) )
>
>If it's confusing to you, it will be confusing to a rookie programmer
>who is called in the middle of the night to do some fix.
>
>One way to make things more obvious to CoBOL programmers is to
>remember the ELSE command:
>
>IF (positive statement)
> CONTINUE
>ELSE
> ...
O'er the years I've fallen into the habit of building multiple conditions
into step-by-step comparisons. For (a grossly simplified) example:
01 MULTI-COND-FLAG PIC X VALUE SPACES.
88 CLIENT-OVER-55 VALUE 'O'.
88 CLIENT-SMOKES VALUE 'S'.
88 CLIENT-DRINKS-3RMORE VALUE 'D'.
88 CHARGE-OUT-D-BAZOO VALUE 'C'.
...
MOVE SPACES TO MULTI-COND-FLAG.
CALL 'CALCDATE' USING C17258-CUSTMAST-DOB,
DATE-OF-RUN.
IF CALCDATE-DATE-SPAN > 55
SET CLIENT-OVER-55 TO TRUE.
...
IF LAST-TEST-COTININE-LEVEL > 200
AND CLIENT-OVER-55
SET CLIENT-SMOKES TO TRUE.
...
IF C17258-CUSTMAST-ADMISSION = 'Y'
AND CLIENT-SMOKES
SET CUST-DRINKS-3RMORE TO TRUE.
...
IF LAST-TEST-CHOL-LEVEL > 165
AND CUST-DRINKS-3RMORE
SET CHARGE-OUT-D-BAZOO TO TRUE.
DD
Frank Swarbrick
>On 6 Jun 2006 13:53:42 -0700, "Richard" <rip...@Azonic.co.nz> wrote:
>
>>> Usually the POSITIVE-CONDITION is something like IF A = B AND (E = D OR
>>> F not = G). Trying to get a negative of that has never been something
>>> I am good at.
>>
>> IF NOT ( positive statemnet )
>>
>>eg
>> IF NOT ( A = B AND (E = D OR > F not = G) )
>
>If it's confusing to you, it will be confusing to a rookie programmer
>who is called in the middle of the night to do some fix.
>
>One way to make things more obvious to CoBOL programmers is to
>remember the ELSE command:
>
>IF (positive statement)
> CONTINUE
>ELSE
Some other languages (Ruby, and I believe Perl) support an interesting way
of doing this:
unless (something)
do_a_thing
end
I like it.
Pete Dashwood
<docd...@panix.com> wrote in message news:e66l79$4vs$1...@reader2.panix.com...
It is implicit if the CHARGE-OUT-D-BAZOO flag is set, because these
conditions must be true to reach the setting of it.
But this is not realistic. What about someone who drinks 3 or more and
ISN'T over 55?
What about someone who smokes and isn't over 55?
The flag above won't handle it. This flag has a single state. Therefore, the
state it represents must imply other states if it is to be a truly MULTI
cond-flag.
You CAN have a single flag with multiple states, but it has to be smarter...
01 MULTI-STATE-IND-FLAG PIC 99 VALUE ZERO.
01 CLIENT-OVER-55 PIC 9 VALUE 1.
01 CLIENT-SMOKES PIC 9 VALUE 2.
01 CLIENT-DRINKS-3RMORE PIC 9 VALUE 4.
01 CHARGE-OUT-D-BAZOO PIC 9 VALUE 8.
I have taken some liberties with the supplied code and used lower case so
you can see where...
MOVE zero TO MULTI-STATE-IND-FLAG.
CALL 'CALCDATE' USING C17258-CUSTMAST-DOB,
DATE-OF-RUN.
IF CALCDATE-DATE-SPAN > 55
add CLIENT-OVER-55 TO MULTI-STATE-IND-FLAG.
...
IF LAST-TEST-NICOTINE-LEVEL > 200
AND MULTI-STATE-IND-FLAG not < CLIENT-OVER-55
add CLIENT-SMOKES TO MULTI-STATE-IND-FLAG.
...
IF C17258-CUSTMAST-ADMISSION = 'Y'
AND MULTI-STATE-IND-FLAG not < CLIENT-SMOKES
add CUST-DRINKS-3RMORE TO MULTI-STATE-IND-FLAG.
...
IF LAST-TEST-CHOL-LEVEL > 165
AND MULTI-STATE-IND-FLAG not < CUST-DRINKS-3RMORE
add CHARGE-OUT-D-BAZOO TO MULTI-STATE-IND-FLAG.
This is logically equivalent to the original, and it didn't require too
drastic amendment.
However there are some inelegancies in the contrived code above. We see that
conditions are still dependent on existing conditions.(This will depend on
the application; it might be that some of the conditions being considered
can ONLY arise if there is a dependency.)
However, this is no longer a REQUIREMENT....(at least as far as this
exercise is concerned)
MOVE zero TO MULTI-STATE-IND-FLAG.
CALL 'CALCDATE' USING C17258-CUSTMAST-DOB,
DATE-OF-RUN.
IF CALCDATE-DATE-SPAN > 55
add CLIENT-OVER-55 TO MULTI-STATE-IND-FLAG.
...
IF LAST-TEST-NICOTINE-LEVEL > 200
add CLIENT-SMOKES TO MULTI-STATE-IND-FLAG.
...
IF C17258-CUSTMAST-ADMISSION = 'Y'
add CUST-DRINKS-3RMORE TO MULTI-STATE-IND-FLAG.
...
IF LAST-TEST-CHOL-LEVEL > 165
add CHARGE-OUT-D-BAZOO TO MULTI-STATE-IND-FLAG.
Now there is no dependency on previous conditions, yet we can still detect
the multiple conditions without having them implicit. (Of course, this may
not be what is specifically required; it will depend on actual
applications...)
The benefit comes when we need to test multiple states....
evaluate MULTI-STATE-IND-FLAG
when 1
*> client is over 55
when 2
*> client smokes
when 3
*> client is over 55 AND client smokes
when 4
*> client drinks 3 or more
when 5
*> client is over 55 AND client drinks 3 or more
when 6
*> client smokes AND drinks 3 or more
when 7
*> client is over 55 AND client smokes AND drinks 3 or more
when 8
*> charge out Bazoo
when 9
*> client is over 55 AND charge out Bazoo
when 10
*> client smokes AND charge out Bazoo
when 11
*> client is over 55 AND client smokes AND charge out Bazoo
when 12
*> client drinks 3 or more AND charge out Bazoo
when 13
*> client is over 55 AND client drinks 3 or more AND charge
out Bazoo
when 14
*> client smokes AND client drinks 3 or more AND charge out
Bazoo
when 15
*> client is over 55 AND client smokes AND client drinks 3 or
more AND charge out Bazoo
when other
*> there are no valid states stored for this client
end evaluate
Pete.
docd...@panix.com
Pete Dashwood <dash...@enternet.co.nz> wrote:
>
><docd...@panix.com> wrote in message news:e66l79$4vs$1...@reader2.panix.com...
[snip]
By coding it differently, of course... the example was labelles as
'grossly simplified'.
>
>It is implicit if the CHARGE-OUT-D-BAZOO flag is set, because these
>conditions must be true to reach the setting of it.
>
>But this is not realistic.
It was called 'grossly simplified', not 'realistic'.
[snip]
>You CAN have a single flag with multiple states, but it has to be smarter...
At that point it might not be 'grossly simplified'.
[snip]
Hmmmmm... starting to look more like what one might find in Prod rather
than a gross simplification, aye.
DD