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
