Gee, Bill, you really know how to drag a "good idea" down! :-)
But seriously, I think everything you have said is unfortunately true. :-(
It's worth noting that the latest COBOL standard(s) do allow for both BIT (PIC
1 BIT) and DISPLAY (PIC 1 DISPLAY) (and probably NATIONAL as well) fields, in
which case you don't need an 88 level condition to check if they are true or
false. For example:
01 X PIC 1.
IF X
DISPLAY "X IS TRUE"
ELSE
DISPLAY "X IS FALSE"
END-IF
Doesn't address all of your issues, but it is something of interest. And of
course a function can return a PIC 1, and thus we could have:
PERFORM UNTIL NOT GET-NEXT-REC(NEXT-RECORD)
PERFORM PROCESS-MY-RECORD
END-PERFORM
Good idea? Umm, well.
Now what would be (IMHO!) ideal would be if COBOL supported a cross between
other languages "enumerated types", COBOL "level 88" condition names and COBOL
user defined types. By that I mean that one could define a "TYPE" with a USAGE
and/or PICTURE clause as appropriate, but it could also have level 88s under it
representing "valid values" for the TYPE. Something like:
01 FILE-STATUS_T IS TYPEDEF
USAGE IS DISPLAY
PICTURE IS X.
88 AT-END VALUE IS 'E'.
88 NORMAL VALUE IS SPACE.
FUNCTION-ID. 'GET-NEXT-REC'.
[...]
LINKAGE SECTION.
01 FILE-RECORD PICTURE X(80).
01 FILE-STATUS-FLAG TYPE FILE-STATUS_T.
PROCEDURE DIVISION USING FILE-RECORD RETURNING FILE-STATUS-FLAG.
READ MY-FILE INTO FILE-RECORD
AT END
SET FILE-STATUS-FLAG TO AT-END
NOT AT END
SET FILE-STATUS-FLAG TO NORMAL
END-READ
EXIT FUNCTION.
[...]
PERFORM UNTIL GET-NEXT-REC(NEXT-RECORD) IS AT-END
PERFORM PROCESS-MY-RECORD
END-PERFORM
Frank
________________________________
From: IBM Mainframe Discussion List <[email protected]> on behalf of
Bill Woodger <[email protected]>
Sent: Thursday, July 14, 2016 2:31 PM
To: [email protected]
Subject: Considering Enterprise COBOL 5.2 "exit" enhancements
Well, "way to stay on-topic". :-) I should have left the discussion in the "now
impossible to determine (so more interesting) S0C1 in COBOL" topic.
I was going to wait for Frank's comment, then realised he'd already posted the
same code.
I thought we'd agreed "always check the file status". So.... which of the two
possible states indicates a bad file-status? 0, which means no record, or 1
which means record? Which of the two states indicates end-of-file? 0, which
means no record, or 1 which means record? Both must answer as 0, and now you
have to test "file up the creek, or plain normal, business-as-usual,
end-of-file". Birds.
No existing intrinsic FUNCTION modifies its parameters, so don't assume. Your
record-area is not even a "parameter" as such, is it, it another return-value.
Its value when the function is called is... irrelevant. So it's not a parameter.
What else. Oh, you can't have an 88 on a function, so re-enter the world of
proliferating literals in the PROCEDURE DIVISION. That's gotta be great. I
don't mind literals as numbers which are just numbers (have no significance
beyond the obvious) but if you have ADD 1 TO BANANA and some-function-return()
= 1, you've overloaded 1, and impacted everyone who looks at the program in the
future. 1 is a trivial example, yet bad enough. However, I assume people won't
limit themselves to returning 0 or 1.
Wait for the call around the room "anyone know what 7 means coming out of
splurge? Is it 'policy found' or 'policy cancelled'?".
Next. Reference-modification. Why? Because subscripts use ( and ). Someone
decided that rather than creating extra "COBOL characters", just bang a : in
there, and it's easy to tell. FUNCTIONs arrive. Has the word FUNCTION, so no
problem with using ( and ) as well. FUNCTIONs later change, and with
User-Defined Functions, the word FUNCTION can potentially be done away with.
What could this mean?
PERFORM UNTIL GET-NEXT-REC(NEXT-RECORD) = 0
PERFORM PROCESS-MY-RECORD
END-PERFORM
It means you have to find out/know whether GET-NEXT-REC is a data-structure or
a function... before you can read that line of code. That's great.
Let's call it PerlBOL and have done with it. You have to understand the line of
code before you can understand the line of code (deliberate overloading of
"understand", just for effect). Mirroring some elements of IBM documentation,
but remember. That is Not a Good Thing.
On Thursday, 14 July 2016 19:41:06 UTC+2, Victor Gil wrote:>
=========================
> Indeed, Victor, you are quite correct! And as soon as Enterprise COBOL
> supports user-written functions I will start using them!
>
>
> FWIW, I don't think your code would work as-in even then, because END-PERFORM
> is only for inline performs, but you are doing an "out of line" perform.
> You'd really have to use one of the following:
>
>
> PERFORM PROCESS-MY-RECORD
> UNTIL GET-NEXT-REC(NEXT-RECORD) = 0
>
>
> PERFORM UNTIL GET-NEXT-REC(NEXT-RECORD) = 0
>
> PERFORM PROCESS-MY-RECORD
> END-PERFORM
>
>
> The first option, even if it works, looks (to me) "a bit weird", because
> structurally it looks like PROCESS-MY-RECORD is done prior to GET-NEXT-REC(),
> so I would stick with the second option; even if its a bit more verbose.
>
>
> Now that I think about it, though, I'm not sure if this would work. The
> above assumes that function GET-NEXT-REC not only returns a result, where 0
> means "end of file", but it also assumes that the parameter is passed by
> reference and can be updated by the function. Are we sure the COBOL standard
> allows for that? I'll look at some point, but not right this.
>
>
> Frank
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
> Yes, thanks for catching the wrong END-PERFORM, I meant to suggest this -
>
> PERFORM UNTIL GET-NEXT-REC(NEXT-RECORD) = 0
> <PROCESS MY RECORD logic>
> END-PERFORM
>
> As far as updating parameters passed to functions - there is no real
> functional difference between passing parameters to functions vs called
> subroutines as they are both just entry names to be resolved by either the
> compiler or the linker.
>
> And we all know that subroutines can update passed parameters [e.g. COMMAREA
> on a CICS LINK].
>
> -Victor-
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
