Home > Archive > Cobol > November 2007 > COBOL's Influence on C
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
COBOL's Influence on C
|
|
| Rick Smith 2007-11-05, 6:55 pm |
|
From an ISO draft technical document:
-----
ISO/IEC JTC1 SC22 WG14 N1176
Date: 2006-05-24
Reference number of document: ISO/IEC WDTR 24732
Committee identification: ISO/IEC JTC1 SC22 WG14
SC22 Secretariat: ANSI
Information Technology -
Programming languages, their environments and system software interfaces -
Extension for the programming language C to support decimal floating-point
arithmetic -
---
Even though the hardware may not provide decimal arithmetic
operations, the support can still be emulated by software.
Programming languages used for business applications either
have native decimal types (such as PL/I, COBOL, C#, or
Visual Basic) or provide decimal arithmetic libraries (such as
the BigDecimal class in Java). The arithmetic used, nowadays,
is almost invariably decimal floating-point; the COBOL 2002
ISO standard, for example, requires that all standard decimal
arithmetic calculations use 32-digit decimal floating-point.
-----
| |
|
| On 11/05/07 11:02 am, Rick Smith wrote:
> From an ISO draft technical document:
> -----
> ISO/IEC JTC1 SC22 WG14 N1176
> Date: 2006-05-24
> Reference number of document: ISO/IEC WDTR 24732
> Committee identification: ISO/IEC JTC1 SC22 WG14
> SC22 Secretariat: ANSI
> Information Technology -
> Programming languages, their environments and system software interfaces -
> Extension for the programming language C to support decimal floating-point
> arithmetic -
> ---
> Even though the hardware may not provide decimal arithmetic
> operations, the support can still be emulated by software.
> Programming languages used for business applications either
> have native decimal types (such as PL/I, COBOL, C#, or
> Visual Basic) or provide decimal arithmetic libraries (such as
> the BigDecimal class in Java). The arithmetic used, nowadays,
> is almost invariably decimal floating-point; the COBOL 2002
> ISO standard, for example, requires that all standard decimal
> arithmetic calculations use 32-digit decimal floating-point.
I don't intend to get into a debate about the pros/cons of various
internal representations of data, nor how they are processed in the
languages. The following is simply to state a few facts that expands on
the above:
1) IBM System z [mainframe systems] do have hardware implementation of
decimal float.
2) Support for the hardware in #1 is provided for programs written in
[in alphabetical order]:
a) Assembler Language
b) C/C++
c) PL/I
d) The SHARE User Group has requested support for COBOL,
but IBM has not yet responded to the requirement.
Carl
| |
| Clark F Morris 2007-11-10, 6:55 pm |
| On Mon, 05 Nov 2007 13:08:21 -0500, CG
<Carl.Gehr.ButNoSPAMStuff5@MCGCG.Com> wrote:
>On 11/05/07 11:02 am, Rick Smith wrote:
>
>I don't intend to get into a debate about the pros/cons of various
>internal representations of data, nor how they are processed in the
>languages. The following is simply to state a few facts that expands on
>the above:
>1) IBM System z [mainframe systems] do have hardware implementation of
>decimal float.
>2) Support for the hardware in #1 is provided for programs written in
>[in alphabetical order]:
> a) Assembler Language
> b) C/C++
> c) PL/I
> d) The SHARE User Group has requested support for COBOL,
> but IBM has not yet responded to the requirement.
Does IBM's action on this and other requirements tell everybody
whether IBM corporate really thinks COBOL has a future? On another
forum Tom Ross has said there are changes coming but I fear they are
years too late.
>
>Carl
| |
| Robert Jones 2007-11-11, 7:55 am |
| On Nov 5, 4:02 pm, "Rick Smith" <ricksm...@mfi.net> wrote:
> From an ISO draft technical document:
> -----
> ISO/IEC JTC1 SC22 WG14 N1176
> Date: 2006-05-24
> Reference number of document: ISO/IEC WDTR 24732
> Committee identification: ISO/IEC JTC1 SC22 WG14
> SC22 Secretariat: ANSI
> Information Technology -
> Programming languages, their environments and system software interfaces -
> Extension for the programming language C to support decimal floating-point
> arithmetic -
> ---
> Even though the hardware may not provide decimal arithmetic
> operations, the support can still be emulated by software.
> Programming languages used for business applications either
> have native decimal types (such as PL/I, COBOL, C#, or
> Visual Basic) or provide decimal arithmetic libraries (such as
> the BigDecimal class in Java). The arithmetic used, nowadays,
> is almost invariably decimal floating-point; the COBOL 2002
> ISO standard, for example, requires that all standard decimal
> arithmetic calculations use 32-digit decimal floating-point.
> -----
The COBOL 2002 version of standard arithmetic is being superceded by
two IEEE754r compliant forms called standard binary arithmetic and
standard decimal arithmetic. The new IEEE754r is still in draft, but
now seems fairly stable, at least in so far as J4 COBOL plans to
implement it. As I understand it from J4 dccuments, no one has yet
implemented the standard ariihmetic of the 2002 COBOL standard and, in
view of the forthcoming changes, it is extremely unlikely that any
will. Whether or not they implement the new forms remains to be seen,
I believe that IEEE754r recommends that at least standard decimal
arithmetic be implemented by programming languages.
As a practical expedient, COBOL will diverge slightly from full
compliance from IEEE754r. The default rounding form for the new types
of standard arithmetic will still be done in the traditional COBOL
manner, presumably and reasonably for backward compatibility.
Programmers can still get effective compliance with IEEE754r by
explicitly defining the rounding mode.
| |
| Rick Smith 2007-11-11, 7:55 am |
|
"Robert Jones" <rjones0@hotmail.com> wrote in message
news:1194781359.463558.183080@v2g2000hsf.googlegroups.com...
> On Nov 5, 4:02 pm, "Rick Smith" <ricksm...@mfi.net> wrote:
interfaces -[color=darkred]
floating-point[color=darkred]
>
> The COBOL 2002 version of standard arithmetic is being superceded by
> two IEEE754r compliant forms called standard binary arithmetic and
> standard decimal arithmetic. The new IEEE754r is still in draft, but
> now seems fairly stable, at least in so far as J4 COBOL plans to
> implement it. As I understand it from J4 dccuments, no one has yet
> implemented the standard ariihmetic of the 2002 COBOL standard and, in
> view of the forthcoming changes, it is extremely unlikely that any
> will. Whether or not they implement the new forms remains to be seen,
> I believe that IEEE754r recommends that at least standard decimal
> arithmetic be implemented by programming languages.
Yes, all true, as I understand it; but did you at least smile,
knowing that part of the rationale for extending the C standard
was something from the COBOL standard that is effectively dead!
[I posted the quote from the C technical report as an inside
joke for those familar with the activities regarding the COBOL
standard. <g>]
| |
| Robert Jones 2007-11-11, 6:55 pm |
| On Nov 11, 1:39 pm, "Rick Smith" <ricksm...@mfi.net> wrote:
> "Robert Jones" <rjon...@hotmail.com> wrote in message
>
> news:1194781359.463558.183080@v2g2000hsf.googlegroups.com...
>
>
>
> interfaces -
> floating-point
>
>
> Yes, all true, as I understand it; but did you at least smile,
> knowing that part of the rationale for extending the C standard
> was something from the COBOL standard that is effectively dead!
>
> [I posted the quote from the C technical report as an inside
> joke for those familar with the activities regarding the COBOL
> standard. <g>]
Yes I agree, I think (and hope) all programming languages tend to
adopt useful features from other languages.
| |
| Charles Hottel 2007-11-11, 6:55 pm |
|
"Clark F Morris" <cfmpublic@ns.sympatico.ca> wrote in message
news:5akcj3t2umrpdv949h4m96nosnq0cli31r@
4ax.com...[color=darkred]
> On Mon, 05 Nov 2007 13:08:21 -0500, CG
> <Carl.Gehr.ButNoSPAMStuff5@MCGCG.Com> wrote:
>
>
> Does IBM's action on this and other requirements tell everybody
> whether IBM corporate really thinks COBOL has a future? On another
> forum Tom Ross has said there are changes coming but I fear they are
> years too late.
I think IBM's current view of COBOL's future is called Java.
| |
| Charles Hottel 2007-11-11, 6:55 pm |
|
"Rick Smith" <ricksmith@mfi.net> wrote in message
news:13je1inhintak13@corp.supernews.com...
>
> "Robert Jones" <rjones0@hotmail.com> wrote in message
> news:1194781359.463558.183080@v2g2000hsf.googlegroups.com...
> interfaces -
> floating-point
>
> Yes, all true, as I understand it; but did you at least smile,
> knowing that part of the rationale for extending the C standard
> was something from the COBOL standard that is effectively dead!
>
> [I posted the quote from the C technical report as an inside
> joke for those familar with the activities regarding the COBOL
> standard. <g>]
>
>
I f they really want to improve C they should add an EVALUATE statement.
| |
| Judson McClendon 2007-11-11, 6:55 pm |
| "Charles Hottel" <chottel@earthlink.net> wrote:
>
> I f they really want to improve C they should add an EVALUATE statement.
AFAIK, C has always had the 'switch' statement, Pascal has the 'case'
statement, modern BASICs have the SELECT statement, etc., all of which
predated EVALUATE, and from which I suspect EVALUATE was taken.
Unlike the other languages, C's 'switch' statement 'drops through' successive
'case' phrases. EVALUATE is more powerful (flexible) than the others;
perhaps that was what you meant. :-)
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
| |
|
| Charles Hottel wrote:
> I f they really want to improve C they should add an EVALUATE statement.
As Judson said, you do have switch(). But, I've really missed the
EVALUATE TRUE form of the verb. In C (or Java, my current project), you
can't say
switch (true) {
case a = b:
doSomethingCool();
}
Add this to the restriction that you can't switch on a string, and I
really have little to no use for the Java switch statement at all. :(
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \/ _ o ~ Live from Albuquerque, NM! ~
~ _ /\ | ~ ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ Business E-mail ~ daniel @ "Business Website" below ~
~ Business Website ~ http://www.djs-consulting.com ~
~ Tech Blog ~ http://www.djs-consulting.com/linux/blog ~
~ Personal E-mail ~ "Personal Blog" as e-mail address ~
~ Personal Blog ~ http://daniel.summershome.org ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ !O M--
V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e h---- r+++ z++++
"Who is more irrational? A man who believes in a God he doesn't see,
or a man who's offended by a God he doesn't believe in?" - Brad Stine
| |
| Rick Smith 2007-11-12, 6:55 pm |
|
"Judson McClendon" <judmc@sunvaley0.com> wrote in message
news:gYHZi.2085$2n.224@bignews8.bellsouth.net...
> "Charles Hottel" <chottel@earthlink.net> wrote:
>
> AFAIK, C has always had the 'switch' statement, Pascal has the 'case'
> statement, modern BASICs have the SELECT statement, etc., all of which
> predated EVALUATE, and from which I suspect EVALUATE was taken.
Microsoft QuickBASIC's SELECT CASE appears
to date from about 1987. COBOL's EVALUATE was
in the 1985 standard; but was first recommended by the
CODASYL COBOL Committee in 1978. I suspect that
1978 predates every concept of "modern BASICs".
Both C's switch and Pascal's case have labels.
FORTRAN's computed GOTO and COBOL's GO TO
DEPENDING have labels and predate both C's switch
and Pascal's case. Each of the languages: FORTRAN,
COBOL, C, and Pascal, use, similarly, an integral value
to transfer control to a label.
COBOL's EVALUATE uses conditions, instead of labels.
Conditions and labels are not the same despite the
appearance of similarity in some circumstances.
I suspect that EVALUATE was designed to accommodate
decision tables, to include a capability to replace some uses
of GO TO DEPENDING, and that other programming
languages had no influence in regard to EVALUATE.
Modern BASICs also use conditions in the SELECT CASE
statement and may have been influenced by COBOL. <g>
| |
| Richard 2007-11-12, 6:55 pm |
| On Nov 12, 5:17 pm, LX-i <lxi0...@netscape.net> wrote:
> Charles Hottel wrote:
>
> As Judson said, you do have switch(). But, I've really missed the
> EVALUATE TRUE form of the verb. In C (or Java, my current project), you
> can't say
>
> switch (true) {
> case a = b:
> doSomethingCool();
>
> }
Why would you want to ? The
if (..)
{..}
else if (..)
...
does exactly what is required.
The only advantage of EVALUATE TRUE over a COBOL IF .. ELSE IF is that
you don't have to count the END-IFs, otherwise it is just a change of
spelling. With C/Java you don't have to count END-~.
| |
| Howard Brazee 2007-11-12, 6:55 pm |
| On Mon, 12 Nov 2007 10:36:34 -0800, Richard <riplin@Azonic.co.nz>
wrote:
>Why would you want to ? The
> if (..)
> {..}
> else if (..)
> ...
>
>does exactly what is required.
>
>The only advantage of EVALUATE TRUE over a COBOL IF .. ELSE IF is that
>you don't have to count the END-IFs, otherwise it is just a change of
>spelling. With C/Java you don't have to count END-~.
Some languages give more options on whether to fall through or not
after a condition check.
It can be much clearer if there was only one condition check...
IF A = B
...
ELSE IF A = C
...
ELSE IF A = D
...
ELSE IF D = E
OR D = F
....
If this code gets modified often (Federal regulations), the closer to
making it a logic table, the easier it will be to see what is
intended.
| |
| John Reagan 2007-11-12, 6:55 pm |
| Rick Smith wrote:
>
>
> Microsoft QuickBASIC's SELECT CASE appears
> to date from about 1987. COBOL's EVALUATE was
> in the 1985 standard; but was first recommended by the
> CODASYL COBOL Committee in 1978. I suspect that
> 1978 predates every concept of "modern BASICs".
>
> Both C's switch and Pascal's case have labels.
The BLISS language has SELECT and SELECTONE. SELECT will match as many
subsections as possible, SELECTONE has a 'break' at the end of each
subsection. There are also ALWAYS and OTHERWISE sections which can
appear more than once in the list of subsections. All allow full
run-time expressions, not just compile-time case labels. So you can do
SELECT True OF; 'case over strings'; etc. Plus SELECT[ONE] returns a
value so you can even use it as an expression (all BLISS statements are
really expressions.) Circa 1969 at CMU.
All taken together does pretty much what EVALUATE does (although EVALUTE
is slightly more flexible).
I'm certain that COBOL wasn't influenced by BLISS. Sometimes smart
people arrive at the same solution independently.
--
John Reagan
OpenVMS Pascal/Macro-32/COBOL Project Leader
Hewlett-Packard Company
| |
|
| In article <fhacfj$gqq$1@usenet01.boi.hp.com>,
John Reagan <john.reagan@hp.com> wrote:
[snip]
>Sometimes smart
>people arrive at the same solution independently.
Oh, I *cannot* resist...
.... you know, I had that *very* thought *just* the other day!
DD
| |
| Michael Mattias 2007-11-12, 6:55 pm |
| <docdwarf@panix.com> wrote in message news:fhacik$ehb$1@reader1.panix.com...
> In article <fhacfj$gqq$1@usenet01.boi.hp.com>,
> John Reagan <john.reagan@hp.com> wrote:
>
> [snip]
>
>
> Oh, I *cannot* resist...
>
> ... you know, I had that *very* thought *just* the other day!
'Smart' also includes "smart-ass?"
(you should have resisted).
MCM
| |
| Robert 2007-11-12, 6:55 pm |
| On Mon, 12 Nov 2007 10:19:38 -0500, "Rick Smith" <ricksmith@mfi.net> wrote:
>Modern BASICs also use conditions in the SELECT CASE
>statement and may have been influenced by COBOL. <g>
Speaking of modern BASICs ...
GOSUB, which is the same as Cobol's out of line PERFORM, has been depreciated by many/most
compilers and dropped from VB.NET. It was replaced by SUB, which is a local function
call. In my opinion, Cobol should have done the same.
| |
| Richard 2007-11-13, 3:55 am |
| On Nov 13, 12:23 pm, Robert <n...@e.mail> wrote:
> On Mon, 12 Nov 2007 10:19:38 -0500, "Rick Smith" <ricksm...@mfi.net> wrote:
>
> Speaking of modern BASICs ...
>
> GOSUB, which is the same as Cobol's out of line PERFORM, has been depreciated by many/most
> compilers and dropped from VB.NET. It was replaced by SUB, which is a local function
> call. In my opinion, Cobol should have done the same.
Cobol added nested programs which are exactly 'a local function call'.
If this had _replaced_, ie removed, the out of line PERFORM then
almost 100% of Cobol programs would have been broken. That would have
destroyed Cobol faster than anything else.
What MS did with VB.NET is irrelevant because there was no continuum
of VB to VB.NET, they did different things.
| |
|
| Richard wrote:
> On Nov 12, 5:17 pm, LX-i <lxi0...@netscape.net> wrote:
>
> Why would you want to ? The
> if (..)
> {..}
> else if (..)
> ...
>
> does exactly what is required.
>
> The only advantage of EVALUATE TRUE over a COBOL IF .. ELSE IF is that
> you don't have to count the END-IFs, otherwise it is just a change of
> spelling. With C/Java you don't have to count END-~.
True. But with not being able to switch on a string, it would be nice
to be able to twist it around and still have the format. However, it is
nice to be able to have if {} else if {} else if {} else {} without
having to have 5 braces at the end. :)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \/ _ o ~ Live from Albuquerque, NM! ~
~ _ /\ | ~ ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ Business E-mail ~ daniel @ "Business Website" below ~
~ Business Website ~ http://www.djs-consulting.com ~
~ Tech Blog ~ http://www.djs-consulting.com/linux/blog ~
~ Personal E-mail ~ "Personal Blog" as e-mail address ~
~ Personal Blog ~ http://daniel.summershome.org ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ !O M--
V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e h---- r+++ z++++
"Who is more irrational? A man who believes in a God he doesn't see,
or a man who's offended by a God he doesn't believe in?" - Brad Stine
| |
| tlmfru 2007-11-13, 6:55 pm |
|
Robert <no@e.mail> wrote in message
news:dsmhj317b7236kep9l7j2i53jp39dcvlo6@
4ax.com...
> On Mon, 12 Nov 2007 10:19:38 -0500, "Rick Smith" <ricksmith@mfi.net>
wrote:
>
>
> Speaking of modern BASICs ...
>
> GOSUB, which is the same as Cobol's out of line PERFORM, has been
depreciated by many/most
> compilers and dropped from VB.NET. It was replaced by SUB, which is a
local function
> call. In my opinion, Cobol should have done the same.
In my opinion and usage, the word SUB, short for SUBroutine, refers to a
stand-alone piece of code not included with the source program under
consideration. (It can certainly be in the same compilation unit, of
course). A function in this context is some common routine which isn't
compiled (I say this to keep OO vocabulary out of the discussion), usually
supplied by the compiler writers: e.g., calls on the OS. There should be a
completely different verb to execute sections of code within the source
program as opposed to that used to execute wholly external sections.
COBOL's PERFORM does the first perfectly well - unambiguous,
understandable - and CALL (or INVOKE, etc.) does the second: and neither can
be mistaken for the other. Why change?
In PROGRESS, a language I have little love for but have had to use quite a
bit, the in-line perform is WHILE, and the out-of-line perform is RUN: but
RUN is also used as the CALL. If the label isn't defined within the current
source, it's assumed to be an external routine: no precautionary diagnostic.
So it's very common to have a clean compile which then blows up with
unresolved linkages when attempting to execute. Not the same situation as
what Robert's suggesting but a cautionary tale.
PL
| |
| Robert 2007-11-13, 6:55 pm |
| On Tue, 13 Nov 2007 12:47:57 -0600, "tlmfru" <lacey@mts.net> wrote:
>
>Robert <no@e.mail> wrote in message
> news:dsmhj317b7236kep9l7j2i53jp39dcvlo6@
4ax.com...
>wrote:
>depreciated by many/most
>local function
>
>In my opinion and usage, the word SUB, short for SUBroutine, refers to a
>stand-alone piece of code not included with the source program under
>consideration. (It can certainly be in the same compilation unit, of
>course). A function in this context is some common routine which isn't
>compiled (I say this to keep OO vocabulary out of the discussion), usually
>supplied by the compiler writers: e.g., calls on the OS. There should be a
>completely different verb to execute sections of code within the source
>program as opposed to that used to execute wholly external sections.
>COBOL's PERFORM does the first perfectly well - unambiguous,
>understandable - and CALL (or INVOKE, etc.) does the second: and neither can
>be mistaken for the other. Why change?
The target of a Cobol CALL can be in the same source or it can be external.
>In PROGRESS, a language I have little love for but have had to use quite a
>bit, the in-line perform is WHILE, and the out-of-line perform is RUN: but
>RUN is also used as the CALL. If the label isn't defined within the current
>source, it's assumed to be an external routine: no precautionary diagnostic.
>So it's very common to have a clean compile which then blows up with
>unresolved linkages when attempting to execute. Not the same situation as
>what Robert's suggesting but a cautionary tale.
Cobol, along with most compiled languages, is the same. Depending on linker options, you
learn of missing external names either at link or execution time.
Unlike most compiled languages, Cobol lets you CALL a name stored in a variable. That kind
can only be bound at execution time. The calling program can handle missing names with an
ON condition, but it's usually too late to do anything but abort. I've never really needed
that feature. It is a bad idea for two reasons. First, it usually slows every call, not
just the first. Second, the linker/loader nor tools like ldd cannot check those references
because they don't know what value will be in the variable at execution time. It's usually
a constant, but there's no way to declare that.
On Unix, you can check for missing externals by running "ldd -r (program)', both after
compilation and before execution. Do z/OS or CA-7 have that ability?
| |
| Robert 2007-11-13, 6:55 pm |
| On Mon, 12 Nov 2007 10:36:34 -0800, Richard <riplin@Azonic.co.nz> wrote:
>On Nov 12, 5:17 pm, LX-i <lxi0...@netscape.net> wrote:
>
>Why would you want to ? The
> if (..)
> {..}
> else if (..)
> ...
>
>does exactly what is required.
>
>The only advantage of EVALUATE TRUE over a COBOL IF .. ELSE IF is that
>you don't have to count the END-IFs, otherwise it is just a change of
>spelling. With C/Java you don't have to count END-~.
You don't have to count END-IF. Just stick a period at the end. :)
| |
| Frank Swarbrick 2007-11-13, 6:55 pm |
| >>> On 11/13/2007 at 11:35 AM, in message
<LcqdnVQM-s7nc6TanZ2dnUVZ_vvinZ2d@comcast.com>, LX-i<lxi0007@netscape.net>
wrote:
> Richard wrote:
statement.[color=darkred]
you[color=darkred]
>
> True. But with not being able to switch on a string, it would be nice
> to be able to twist it around and still have the format. However, it is
>
> nice to be able to have if {} else if {} else if {} else {} without
> having to have 5 braces at the end. :)
Yeah, this is actually a somewhat confusing difference between C and Cobol.
C et al are different in that you have code blocks (surrounded by braces),
while COBOL has statement terminators. This is why in C you can say:
if (something-1)
{
...
}
else if (something-2)
{
...
}
else if (something-3)
{
...
}
else
{
...
}
whereas in Cobol, if you tried something similar, you'd end up with
if something-1
...
else if something-2
...
else if something-3
...
else
...
end-if
end-if
end-if
In Cobol, the statement terminator terminates the entire statement, whereas
in C at al you are terminating just a block of code. It took me quite a bit
of brain damage before I realized why all of those END- clauses where needed
in Cobol, but not in C.
One option I think that Cobol could have taken is an elsif clause, like
several other languages
if something-1
...
elsif something-2
...
elsif something-3
...
else
...
end-if
In this case a elsif is just a clause of the if statement, just like else
is. It doesn't start a new 'level', if you will. (I am having a hard time
thinking of the correct terminology!)
Ruby and others do this, because if they didn't you'd end up with the same
issue that Cobol has.
Of course, Cobol does have the very powerful EVALUATE statement, which is
most likely why ELSIF or whatever was not added to Cobol for the 1985
standard.
I'm getting deja vu here. I'm pretty sure I've written this message before!
:-) Oh well, take this message for whatever it's worth, which is probably
not much...
Frank
| |
| Richard 2007-11-14, 3:56 am |
| On Nov 14, 1:23 pm, Robert <n...@e.mail> wrote:
> On Mon, 12 Nov 2007 10:36:34 -0800, Richard <rip...@Azonic.co.nz> wrote:
>
>
>
>
>
>
>
> You don't have to count END-IF. Just stick a period at the end. :)
Which may, or may not, work correctly depending on whether the IF
structure is the imperitive statement of another statement.
| |
| Richard 2007-11-14, 3:56 am |
| On Nov 14, 1:18 pm, Robert <n...@e.mail> wrote:
> On Tue, 13 Nov 2007 12:47:57 -0600, "tlmfru" <la...@mts.net> wrote:
>
>
>
>
>
>
> The target of a Cobol CALL can be in the same source or it can be external.
>
>
> Cobol, along with most compiled languages, is the same. Depending on linker options, you
> learn of missing external names either at link or execution time.
>
> Unlike most compiled languages, Cobol lets you CALL a name stored in a variable. That kind
> can only be bound at execution time. The calling program can handle missing names with an
> ON condition, but it's usually too late to do anything but abort. I've never really needed
> that feature. It is a bad idea for two reasons. First, it usually slows every call, not
> just the first. Second, the linker/loader nor tools like ldd cannot check those references
> because they don't know what value will be in the variable at execution time. It's usually
> a constant, but there's no way to declare that.
>
> On Unix, you can check for missing externals by running "ldd -r (program)', both after
> compilation and before execution. Do z/OS or CA-7 have that ability?
It is certainly _not_ a bad idea. It is also not true that abort is
the only option. Simply because you have never discovered how to
exploit it to build dynamic systems does not make it bad.
| |
| Howard Brazee 2007-11-14, 6:55 pm |
| On Tue, 13 Nov 2007 17:26:47 -0700, "Frank Swarbrick"
<Frank.Swarbrick@efirstbank.com> wrote:
>One option I think that Cobol could have taken is an elsif clause, like
>several other languages
Except the EVALUATE has mitigated for this lack.
| |
| Judson McClendon 2007-11-14, 6:55 pm |
| "Howard Brazee" <howard@brazee.net> wrote:
> "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote:
>
>
> Except the EVALUATE has mitigated for this lack.
In general, I prefer using EVALUATE or it's cousins in other languages
to chained ELSEIF, unless there are only a very few.
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
| |
| Frank Swarbrick 2007-11-14, 6:55 pm |
| >>> On 11/13/2007 at 5:18 PM, in message
<snckj3564s4rjul5ctvffht6imaih84m4q@4ax.com>, Robert<no@e.mail> wrote:
> On Tue, 13 Nov 2007 12:47:57 -0600, "tlmfru" <lacey@mts.net> wrote:
>
> usually
[color=darkred]
> a
> can
>
> The target of a Cobol CALL can be in the same source or it can be
> external.
>
> a
but[color=darkred]
> current
> diagnostic.
> as
>
> Cobol, along with most compiled languages, is the same. Depending on
> linker options, you
> learn of missing external names either at link or execution time.
>
> Unlike most compiled languages, Cobol lets you CALL a name stored in a
> variable. That kind
> can only be bound at execution time. The calling program can handle
> missing names with an
> ON condition, but it's usually too late to do anything but abort. I've
> never really needed
> that feature. It is a bad idea for two reasons. First, it usually slows
> every call, not
> just the first. Second, the linker/loader nor tools like ldd cannot
> check those references
> because they don't know what value will be in the variable at execution
> time. It's usually
> a constant, but there's no way to declare that.
>
> On Unix, you can check for missing externals by running "ldd -r
> (program)', both after
> compilation and before execution. Do z/OS or CA-7 have that ability?
I don't have much Cobol experience on the PC (or Unix et al), but on the
mainframe we use dynamic calls (CALL data-name) almost exclusively. While
I'm sure a static call is faster, we've never had a performance issue. It's
very nice to be able to change a subroutine and not have to do a static
relink of all calling programs.
Frank
| |
| Frank Swarbrick 2007-11-14, 6:55 pm |
| >>> On 11/14/2007 at 9:45 AM, in message
<gf9mj35rlkk45cvqs70r5bphuhv8v6ks5r@4ax.com>, Howard
Brazee<howard@brazee.net> wrote:
> On Tue, 13 Nov 2007 17:26:47 -0700, "Frank Swarbrick"
> <Frank.Swarbrick@efirstbank.com> wrote:
>
>
> Except the EVALUATE has mitigated for this lack.
Which I also stated in my message...
Frank
| |
| Frank Swarbrick 2007-11-14, 6:55 pm |
| >>> On 11/13/2007 at 5:23 PM, in message
<htfkj3pnit9n8uorm8o0vfboies4csu3lt@4ax.com>, Robert<no@e.mail> wrote:
> On Mon, 12 Nov 2007 10:36:34 -0800, Richard <riplin@Azonic.co.nz> wrote:
>
> statement.
you[color=darkred]
>
> You don't have to count END-IF. Just stick a period at the end. :)
Hopefully this was a joke.
| |
| Robert Jones 2007-11-14, 6:55 pm |
| On Nov 14, 7:54 pm, "Frank Swarbrick" <Frank.Swarbr...@efirstbank.com>
wrote:
> <snckj3564s4rjul5ctvffht6imaih84...@4ax.com>, Robert<n...@e.mail> wrote:
>
>
>
>
>
>
>
> but
>
>
>
>
> I don't have much Cobol experience on the PC (or Unix et al), but on the
> mainframe we use dynamic calls (CALL data-name) almost exclusively. While
> I'm sure a static call is faster, we've never had a performance issue. It's
> very nice to be able to change a subroutine and not have to do a static
> relink of all calling programs.
>
> Frank
The term dynamic can get very confusing at times. If you use CALL
data-name the call is always dynamic, while if you use CALL literal,
it may or may not be, depending upon your compiler and consequent
linkage editor or binder options. It has been possible to do dynamic
calls with both CALL literal and CALL data-name from the late 1970s.
The difference in performance between dynamic and static linkage is
insignificant, unless one is also repetitively cancelling dynamically
called program. One would expect an overall performance improvement
in a multitasking environmnet due to the lack of need for multiple
copies of all the COBOL language subroutines in memory, which should
reduce the amount of paging required. However, if one wants to run
multiple instances of the same COBOl program at once, then the user
written subroutines can't be in the link pack area (I have a feeling
that is called the RRR (I don't know what it stands for, perhaps
resident routines region?)in DOS/VSE), but they can still be invoked
from the JOBLIB and STEPLIB library specs.
Anyone care to elaborate?
| |
| William M. Klein 2007-11-14, 6:55 pm |
| Robert's reply seems to "assume" an IBM mainframe environment. Most of what he
says MAY be available in other environments, but may not be universally
"relevant".
--
Bill Klein
wmklein <at> ix.netcom.com
"Robert Jones" <rjones0@hotmail.com> wrote in message
news:1195079026.976230.183910@o3g2000hsb.googlegroups.com...
> On Nov 14, 7:54 pm, "Frank Swarbrick" <Frank.Swarbr...@efirstbank.com>
> wrote:
>
> The term dynamic can get very confusing at times. If you use CALL
> data-name the call is always dynamic, while if you use CALL literal,
> it may or may not be, depending upon your compiler and consequent
> linkage editor or binder options. It has been possible to do dynamic
> calls with both CALL literal and CALL data-name from the late 1970s.
>
> The difference in performance between dynamic and static linkage is
> insignificant, unless one is also repetitively cancelling dynamically
> called program. One would expect an overall performance improvement
> in a multitasking environmnet due to the lack of need for multiple
> copies of all the COBOL language subroutines in memory, which should
> reduce the amount of paging required. However, if one wants to run
> multiple instances of the same COBOl program at once, then the user
> written subroutines can't be in the link pack area (I have a feeling
> that is called the RRR (I don't know what it stands for, perhaps
> resident routines region?)in DOS/VSE), but they can still be invoked
> from the JOBLIB and STEPLIB library specs.
>
> Anyone care to elaborate?
>
| |
| Robert 2007-11-14, 6:55 pm |
| On Wed, 14 Nov 2007 12:54:56 -0700, "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com>
wrote:
><snckj3564s4rjul5ctvffht6imaih84m4q@4ax.com>, Robert<no@e.mail> wrote:
>but
>
>I don't have much Cobol experience on the PC (or Unix et al), but on the
>mainframe we use dynamic calls (CALL data-name) almost exclusively. While
>I'm sure a static call is faster, we've never had a performance issue. It's
>very nice to be able to change a subroutine and not have to do a static
>relink of all calling programs.
In the Windows and Unix worlds, dynamic (run time) binding is the standard, as well.
The format standard for executables and called programs is called Portable Executable (PE)
on Windows, Executable and Linkable Format (ELF) on Unix. Common file extensions for
called programs are .dll and .ocx on Windows, .so and .sl on Unix.
Static linking is so Old School that Micro Focus dropped support for linker options on the
compiler command line. If you really insist on static, you have to execute the linker as a
separate step.
The question was: can z/OS or a commonly used tool (not a debuger) verify the existance of
all called program files after compilation and again before execution? If yes, how can it
verify Cobol programs?
| |
| Robert 2007-11-14, 6:55 pm |
| On Wed, 14 Nov 2007 13:41:42 -0600, "Judson McClendon" <judmc@sunvaley0.com> wrote:
>"Howard Brazee" <howard@brazee.net> wrote:
>
>In general, I prefer using EVALUATE or it's cousins in other languages
>to chained ELSEIF, unless there are only a very few.
How few? How did you arrive at that number? Why is your choice better than 1 or 5 or ZERO?
Why not use EVALUATE always? Wouldn't this spelling change work in all cases?
c/if/evaluate true when/
c/else if/when/
c/else/when other/
c/end-if/end-evaluate/
| |
| Robert 2007-11-14, 9:55 pm |
| On Wed, 14 Nov 2007 00:55:56 -0800, Richard <riplin@Azonic.co.nz> wrote:
>On Nov 14, 1:18 pm, Robert <n...@e.mail> wrote:
>
>It is certainly _not_ a bad idea. It is also not true that abort is
>the only option. Simply because you have never discovered how to
>exploit it to build dynamic systems does not make it bad.
This issue requires a rant on the inadequacies of programming language designers. They
cause UNINTENDED CONSEQUENCES because they think like programmers rather administrators.
Two examples are fresh in my mind because I'm fighting with them right now.
Picture a very large shop that runs hundreds of thousands of batch jobs that execute
millions of programs every month. Imagine an administrator writing automated
'verification' of those jobs BEFORE they run, so errors can be fixed BEFORE the jobs blow
up in production. The existance of data files is the easiest thing to check. What about
the existance of program files (verifying they are the correct version is the next step)?
Unix's ELF standard and the aforementioned ldd (LoaDer Diagnostics) tool makes it easy to
verify the existance of called programs, recursively checking for ALL of them. It works
for every language EXCEPT Cobol (and other programs calling dlopen() directly, which is
rare). Why do Cobol programmers need the flexibility to determine the names of child
programs at execution time? In the vast majority of cases, they don't. A few creative
programmers will write 'dynamic systems' driven by decision tables (or similar) stored in
databases, from which they get the names of child programs. That allows them to add child
programs without having to recompile the parents .. provided someone installs the child
program BEFORE putting its name into the database. That's fine for small systems with a
small number of users. The programmer will personally install the child program. It
doesn't work when there are dozens to hundreds of machines. Worse, the list of child
programs is in a NON-STANDARD location unknown to a general verification tool. Each
creative programmer will design a DIFFERENT location. One might put the list in a load
module, one in a database, one on his laptop's floppy mounted via NFS.
This is anarcy. In order to verify programs, I need ALL externals stored in ELF headers.
For Cobol programs calling via variables (data-names), I have to extract the VALUE from
the data-name definition, look for MOVE 'prognm' TO DATA-NAME, use the values to build a
dummy object that gets linked into the executable so the program's child names are in its
symbol table. THIS SHOULD NOT BE NECESSARY. If someone on the Cobol Standards Committee
had known the requirements of LARGE systems, the language would make a distinction between
dynamic binding (a good thing) and dynamic determination of called program name (a bad
thing).
------
My second gripe is over nested COPYs. The '85 Cobol Standard says they are not allowed.
The unintended consequence of that stupid restriction is that our builds take 18 hours
rather than 2 hours. Here's why. We don't write copybooks manually, we generate them from
data dictionaries, for several languages -- .h files for C, .cpy for Cobol. We produce
separate copybooks for 88 levels and for types. A Cobol type looks like "pic x(10)". The
top level copybook for a structure looks like:
05 customer-number copy custno.typ..
05 customer-status copy status.typ..
copy status.val. *> contains 88 levels
Because the '85 Cobol Standard says nested COPYs are a no-no, we run a pre-pre-processor
that combines the nested COPYs into a single one, which looks like this:
custrow.cpy:
05 customer-number pic x(10).
05 customer-status pic x(01).
88 active value 'A'.
88 cancelled value 'C'.
Our compilations are driven by make files, which are driven by generated dependency (make
rule) files, which are created from source code. The problem is, we cannot determine the
dependencies from reading Cobol source programs. All we see is "copy custrow.cpy". We
cannot tell that status.val is a dependent. (Make decides what to compile by comparing
timestamps of dependents to the timestamp of the executable.) One way to make it work
would be to generate custrow.cpy into a temp area, compare it to the previous custrow.cpy,
replacing custrow.cpy only if there is a difference. THIS SHOULD NOT BE NECESSARY,
especially since Micro Focus and the '02 Cobol Standard both support nested COPYs. A
better way to make it work would be to simply eliminate the pre-pre-processor. Instead we
run 18 hour full builds because somebody back in the early '80s thought nested COPYs were
too much trouble or unnecessary. They WERE unnecessary for small systems. If someone on
the '85 Standards Committee had known the requirements of LARGE systems (10,000s of
programs), our builds would already be running in 2 hours.
| |
| Judson McClendon 2007-11-15, 7:55 am |
| "Robert" <no@e.mail> wrote:
> "Judson McClendon" <judmc@sunvaley0.com> wrote:
>
> How few? How did you arrive at that number? Why is your choice better than 1 or 5 or ZERO?
>
> Why not use EVALUATE always? Wouldn't this spelling change work in all cases?
>
> c/if/evaluate true when/
> c/else if/when/
> c/else/when other/
> c/end-if/end-evaluate/
One could use either IF or EVALUATE all the time, of course. My preference
is simply a judgment call. In the case of one, using IF is usually simpler,
quicker and I believe more intuitive. Sometimes I will use one ELSEIF for
two cases, but beyond that EVALUATE or equivalent seems more appropriate.
Also, this can be more efficient, unless you use temporary variables, when
the EVALUATE object is an expression. Logically, it's clearer and cleaner
when you do not have to create and reference a temporary variable, for the
same reasons HLLs are more "human effective" than assembly.
Example, you are following a section of code that is dealing with XXX, and
you see either this:
TEMP = <expression of XXX>
IF <test1 TEMP>
....
ELSEIF <test2 TEMP>
...
or you see this:
EVALUATE <expression of XXX>
WHEN <test1>
...
WHEN <test2>
...
I believe the latter is slightly clearer, even if there are only two,
because no reference is made to TEMP, which is only used here for
efficiency, not clarity.
In fact, for those same reasons, I sometimes use EVALUATE or equivalent
for a single CASE. Recently I've been writing 32 bit BASIC replacements
for a number of old DOS command line utilities I've used forever, and
have often used this bit of code:
SELECT CASE UCASE$(TRIM$(COMMAND$))
CASE "/?", "-?", "/H", "-H"
ShowHelp()
EXIT FUNCTION
END SELECT
Though there's only one CASE, I believe this code is clearer and more
efficient than an equivalent IF construct. EVALUATE would have the same
advantages in a similar situation.
(For anyone not familiar with command line programs, the use of one of
those four values as a command line option to request help for the
program is almost ubiquitous. In BASIC '$' indicates a string, and built
in functions COMMAND$ returns the command line entered after the program
name, TRIM$ removes spaces from left and right, and UCASE$ converts to
upper case.)
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
| |
| Michael Mattias 2007-11-15, 7:55 am |
| "Robert" <no@e.mail> wrote in message
news:3e0nj3taf1db7d0e95bcr8831ak8ds81vb@
4ax.com...
> The question was: can z/OS or a commonly used tool (not a debuger) verify
> the existance of
> all called program files after compilation and again before execution? If
> yes, how can it
> verify Cobol programs?
How useful could that really be?
Consider most programs are compiled within a "development" environment,
where LIBLST or $JOBLIB or PATH depending on operating system will make the
'availability' of called files totally different in 'development' versus
'production' anyway.
I 'suppose' someone could invent a utilty to do check a program file "in its
current environment" for called file availability, but with the ability do
dynamically change the called program file name based on the value of
variables, I can't see how that could be done without having the source code
handy AND being able to test for all possible values and permutations of
values..
e.g., I have three commercial applications in which the name of the called
library is (yes, it's true) USER-DEFINED. How on earth can that be tested
from without?
Better I think for applications developers to include some kind of "called
program availability checking" support within the application itself.
MCM
| |
| Howard Brazee 2007-11-15, 6:55 pm |
| On Wed, 14 Nov 2007 21:02:27 -0600, Robert <no@e.mail> wrote:
>Unix's ELF standard and the aforementioned ldd (LoaDer Diagnostics) tool makes it easy to
>verify the existance of called programs, recursively checking for ALL of them. It works
>for every language EXCEPT Cobol (and other programs calling dlopen() directly, which is
>rare). Why do Cobol programmers need the flexibility to determine the names of child
>programs at execution time? In the vast majority of cases, they don't. A few creative
>programmers will write 'dynamic systems' driven by decision tables (or similar) stored in
>databases, from which they get the names of child programs. That allows them to add child
>programs without having to recompile the parents .. provided someone installs the child
>program BEFORE putting its name into the database. That's fine for small systems with a
>small number of users. The programmer will personally install the child program. It
>doesn't work when there are dozens to hundreds of machines. Worse, the list of child
>programs is in a NON-STANDARD location unknown to a general verification tool. Each
>creative programmer will design a DIFFERENT location. One might put the list in a load
>module, one in a database, one on his laptop's floppy mounted via NFS.
>
>This is anarcy. In order to verify programs, I need ALL externals stored in ELF headers.
>For Cobol programs calling via variables (data-names), I have to extract the VALUE from
>the data-name definition, look for MOVE 'prognm' TO DATA-NAME, use the values to build a
>dummy object that gets linked into the executable so the program's child names are in its
>symbol table. THIS SHOULD NOT BE NECESSARY. If someone on the Cobol Standards Committee
>had known the requirements of LARGE systems, the language would make a distinction between
>dynamic binding (a good thing) and dynamic determination of called program name (a bad
>thing).
On a VAX, if the DCL doesn't define a new file, the CoBOL creates it
using the Assign name. Make sure your new standards don't lose that
ability.
>My second gripe is over nested COPYs. The '85 Cobol Standard says they are not allowed.
Agreed.
| |
| Howard Brazee 2007-11-15, 6:55 pm |
| On Wed, 14 Nov 2007 14:23:46 -0800, Robert Jones <rjones0@hotmail.com>
wrote:
>The term dynamic can get very confusing at times. If you use CALL
>data-name the call is always dynamic, while if you use CALL literal,
>it may or may not be, depending upon your compiler and consequent
>linkage editor or binder options. It has been possible to do dynamic
>calls with both CALL literal and CALL data-name from the late 1970s.
I've tried to picture a case where someone wanted a non-dynamic call
for a purpose other than (obsolete) performance.
| |
| Howard Brazee 2007-11-15, 6:55 pm |
| On Thu, 15 Nov 2007 05:04:51 -0600, "Judson McClendon"
<judmc@sunvaley0.com> wrote:
>One could use either IF or EVALUATE all the time, of course. My preference
>is simply a judgment call. In the case of one, using IF is usually simpler,
>quicker and I believe more intuitive. Sometimes I will use one ELSEIF for
>two cases, but beyond that EVALUATE or equivalent seems more appropriate.
>Also, this can be more efficient, unless you use temporary variables, when
>the EVALUATE object is an expression. Logically, it's clearer and cleaner
>when you do not have to create and reference a temporary variable, for the
>same reasons HLLs are more "human effective" than assembly.
If doing maintenance, your needs change from a simple IF to a more
complex IF, do your maintenance programmers rewrite it as an EVALUATE,
or start nesting IF-ELSEs?
| |
| Frank Swarbrick 2007-11-15, 6:55 pm |
| >>> On 11/14/2007 at 4:36 PM, in message
<3e0nj3taf1db7d0e95bcr8831ak8ds81vb@4ax.com>, Robert<no@e.mail> wrote:
> On Wed, 14 Nov 2007 12:54:56 -0700, "Frank Swarbrick"
> <Frank.Swarbrick@efirstbank.com>
> wrote:
>
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
While[color=darkred]
> It's
>
> In the Windows and Unix worlds, dynamic (run time) binding is the
> standard, as well.
> The format standard for executables and called programs is called
> Portable Executable (PE)
> on Windows, Executable and Linkable Format (ELF) on Unix. Common file
> extensions for
> called programs are .dll and .ocx on Windows, .so and .sl on Unix.
>
> Static linking is so Old School that Micro Focus dropped support for
> linker options on the
> compiler command line. If you really insist on static, you have to
> execute the linker as a
> separate step.
>
> The question was: can z/OS or a commonly used tool (not a debuger)
> verify the existance of
> all called program files after compilation and again before execution?
> If yes, how can it
> verify Cobol programs?
I can't really answer this question. I understand (I think!) the difference
between static and dynamic binding on the VSE mainframe operating system. I
assume that z/OS is similar, but not having used it I don't know for sure.
I have a feeling, from what you have said, that Windows and Unix-like
operating systems have some sort of third, 'in the middle', kind of binding?
But I have little understanding of it.
I personally have little need for CALL data-name *other* than the fact that
it is the default way, in VSE, of doing a dynamic call. With the default
compile option NODYNAM, CALL literal will always resolve the entry-point
name at compile time and attempt to link the OBJ at link-edit time. If the
an OBJ with that name does not exist (in the OBJ search chain), and there is
not explicit include of an OBJ that includes that name as an entry point,
then the link-edit will warn about that.
On the other hand, if you use CALL data-name then, obviously, at link-edit
time there is not any knowledge of the name of the routine to be called.
This is determined only at run-time.
The compile option names are actually rather deceptive. NODYNAM doesn't
mean that dynamic calls are not allowed, but rather they are not the
default. DYNAM, on the other-hand should really be NOSTATIC, as both CALL
data-name and CALL literal perform static calls.
I would be all for some way of having a 'dynamic' call of a 'static' name.
But I'm not really sure how that would work. Is the following possible in
the Windows/Unix world?
- Create a DLL that contains some subroutines.
- Create an EXE that uses some of the subroutines in the DLL.
- Install the DLL and EXE to a production system.
- Make some changes to the internals (but not the interface) of the DLL.
- Install the new version of the DLL to the production system, not touching
the EXE at all.
- Run the EXE
When you run the EXE will it use the newly installed DLL?
If it does, I am interested in how this works. Not necessarily in Cobol,
but maybe in C.
If it does not work then, well, I prefer the Cobol way, even with it's
faults in that at compile/link time there's no simple way to know what
'entry points' will be called at run-time.
I know of no way of, in VSE, doing what you ask above. I won't say we've
never had a problem, but it is indeed rare for a program to have problems at
run time because of an attempt to dynamically call a non-existent routine.
(We did, in fact, have a problem recently where we intentionally removed the
executable of a dynamically called routine because we thought we had
eliminated all use of it, and in fact we had not. But still, it's rare.)
Frank
| |
| Frank Swarbrick 2007-11-15, 6:55 pm |
| >>> On 11/15/2007 at 9:05 AM, in message
<hgroj3t505d387haethamve41scrqnbv7t@4ax.com>, Howard
Brazee<howard@brazee.net> wrote:
> On Thu, 15 Nov 2007 05:04:51 -0600, "Judson McClendon"
> <judmc@sunvaley0.com> wrote:
>
> preference
> simpler,
> when
> the
>
> If doing maintenance, your needs change from a simple IF to a more
> complex IF, do your maintenance programmers rewrite it as an EVALUATE,
> or start nesting IF-ELSEs?
I can't speak for everyone, but I and several people at my shop would
convert an IF to an EVALUATE in this case.
Which is one reason for my use of the following indentation rule for
EVALUATE: Put the WHEN phrase at the same indentation level as the EVALUATE.
See the following example:
if the-type = 'a'
move 'description a' to the-description
else
move 'default description' to the-description
end-if
evaluate the-type
when 'a'
move 'description a' to the-description
when 'b'
move 'description b' to the-description
when other
move 'default description' to the-description
end-evaluate
We have an editor/source control system that 'dates' each line when it's
changed. With my changes from IF to EVALAUTE the two 'move' lines will not
have been changed. If I had indented the when clause four spaces then I
would have had to indent the moves as well, causing it to look like an
entirely brand new set of statements, rather than just a change of a
pre-existing set.
Big deal? Probably not. But that's my point of view. The other being that
this way the indentation of conditional statements in a EVALUATE are the
same as those of IF; specifically, four spaces. (I used to indent the WHEN
2 spaces and the conditional statements another 2, but I now prefer this new
way.)
Personally, I have a tendency now of often doing something like this:
evaluate the-type
when 'a'
move 'description a' to the-description
when other
move 'default description' to the-description
end-evaluate
Just in anticipation of future WHEN phrases.
Frank
| |
| Frank Swarbrick 2007-11-15, 6:55 pm |
| >>> On 11/15/2007 at 10:12 AM, in message
<473C1B7E.6F0F.0085.0@efirstbank.com>, Frank
Swarbrick<Frank.Swarbrick@efirstbank.com> wrote:
>
> Personally, I have a tendency now of often doing something like this:
> evaluate the-type
> when 'a'
> move 'description a' to the-description
> when other
> move 'default description' to the-description
> end-evaluate
>
> Just in anticipation of future WHEN phrases.
Interesting; here is some code I wrote a few years ago:
4150-TC24-FEE-DESCRIPTION.
IF D-TRAN-SERIAL-NBR NUMERIC
EVALUATE D-TRAN-SERIAL-NBR
WHEN 56
WHEN 57
MOVE 'FEE FOR INTERNATIONAL TRANSACTION'
TO TDESC-FEE-DESCRIPTION
WHEN OTHER
MOVE 'SERVICE CHARGE' TO TDESC-FEE-DESCRIPTION
END-EVALUATE
ELSE
MOVE 'SERVICE CHARGE' TO TDESC-FEE-DESCRIPTION
END-IF.
We just so happen to have a request for a new fee description, so the new
code will now look like this:
4150-TC24-FEE-DESCRIPTION.
IF D-TRAN-SERIAL-NBR NUMERIC
EVALUATE D-TRAN-SERIAL-NBR
WHEN 56
WHEN 57
MOVE 'FEE FOR INTERNATIONAL TRANSACTION'
TO TDESC-FEE-DESCRIPTION
WHEN 64
MOVE 'FOREIGN BANK SURCHARGE FEE'
TO TDESC-FEE-DESCRIPTION
WHEN OTHER
MOVE 'SERVICE CHARGE' TO TDESC-FEE-DESCRIPTION
END-EVALUATE
ELSE
MOVE 'SERVICE CHARGE' TO TDESC-FEE-DESCRIPTION
END-IF.
All I had to do was add the "WHEN 64" and it's conditional statement. I
like that! (Yes, I can get excited by small things.)
Of course there's no guarantee that the level 1 IF won't ever become a more
complex conditional, but I rolled the dice that it won't. Probably will be
proven wrong some day.
Frank
| |
|
| In article <473C1D06.6F0F.0085.0@efirstbank.com>,
Frank Swarbrick <Frank.Swarbrick@efirstbank.com> wrote:
[snip]
>We just so happen to have a request for a new fee description, so the new
>code will now look like this:
>
> 4150-TC24-FEE-DESCRIPTION.
> IF D-TRAN-SERIAL-NBR NUMERIC
> EVALUATE D-TRAN-SERIAL-NBR
> WHEN 56
> WHEN 57
> MOVE 'FEE FOR INTERNATIONAL TRANSACTION'
> TO TDESC-FEE-DESCRIPTION
> WHEN 64
> MOVE 'FOREIGN BANK SURCHARGE FEE'
> TO TDESC-FEE-DESCRIPTION
> WHEN OTHER
> MOVE 'SERVICE CHARGE' TO TDESC-FEE-DESCRIPTION
> END-EVALUATE
> ELSE
> MOVE 'SERVICE CHARGE' TO TDESC-FEE-DESCRIPTION
> END-IF.
[snip]
>Of course there's no guarantee that the level 1 IF won't ever become a more
>complex conditional, but I rolled the dice that it won't. Probably will be
>proven wrong some day.
First, Mr Swarbrick, my compliments on the Obviously Superior Style, Good
Taste and Sense of Music indicated by alternating IF and EVALUATE.
Second... there are two possibilities for the IF... NUMERIC ELSE becoming
more complex, that 'something else' needs to be done with numbers or that
'something else' needs to be done with a non-numeric.
If 'something else' needs to be done with numbers then the EVALUATE should
be able to handle things... if 'something else' needs to be done with an
alphanumeric then it might be along the lines of:
4150-TC24-FEE-DESCRIPTION.
IF D-TRAN-SERIAL-NBR NUMERIC
EVALUATE D-TRAN-SERIAL-NBR
WHEN 56
WHEN 57
MOVE 'FEE FOR INTERNATIONAL TRANSACTION'
TO TDESC-FEE-DESCRIPTION
WHEN 64
MOVE 'FOREIGN BANK SURCHARGE FEE'
TO TDESC-FEE-DESCRIPTION
WHEN OTHER
MOVE 'SERVICE CHARGE' TO TDESC-FEE-DESCRIPTION
END-EVALUATE
ELSE
EVALUATE D-TRAN-SERIAL-NBR(1:1)
WHEN 'A'
PERFORM 4150A-BOSTON-NOTE THRU 4150A-BN-EX
WHEN 'B'
PERFORM 4150B-NY-NOTE THRU 4150B-NN-EX
WHEN 'C'
PERFORM 4150C-PHILA-NOTE THRU 4150C-PN-EX
WHEN 'D'
PERFORM 4150D-CLEVE-NOTE THRU 4150D-EX
....
WHEN OTHER
MOVE 'SERVICE CHARGE' TO TDESC-FEE-DESCRIPTION
END-IF.
.... or something along those lines.
DD
| |
| Pete Dashwood 2007-11-15, 6:55 pm |
|
--
"I used to write COBOL...now I can do anything."
"Robert" <no@e.mail> wrote in message
news:snckj3564s4rjul5ctvffht6imaih84m4q@
4ax.com...
> On Tue, 13 Nov 2007 12:47:57 -0600, "tlmfru" <lacey@mts.net> wrote:
>
>
> The target of a Cobol CALL can be in the same source or it can be
> external.
>
>
> Cobol, along with most compiled languages, is the same. Depending on
> linker options, you
> learn of missing external names either at link or execution time.
>
> Unlike most compiled languages, Cobol lets you CALL a name stored in a
> variable. That kind
> can only be bound at execution time. The calling program can handle
> missing names with an
> ON condition, but it's usually too late to do anything but abort. I've
> never really needed
> that feature. It is a bad idea for two reasons. First, it usually slows
> every call, not
> just the first. Second, the linker/loader nor tools like ldd cannot check
> those references
> because they don't know what value will be in the variable at execution
> time. It's usually
> a constant, but there's no way to declare that.
>
> On Unix, you can check for missing externals by running "ldd -r
> (program)', both after
> compilation and before execution. Do z/OS or CA-7 have that ability?
>
| |
| Pete Dashwood 2007-11-15, 6:55 pm |
|
<snip>>
> Unlike most compiled languages, Cobol lets you CALL a name stored in a
> variable. That kind
> can only be bound at execution time. The calling program can handle
> missing names with an
> ON condition, but it's usually too late to do anything but abort. I've
> never really needed
> that feature.
>It is a bad idea for two reasons.
I think late binding is one of the best things in COBOL, and strongly
disagree it is a "bad idea" :-)
In both OO and procedural implementations, the flexibility this affords far
outweighs any slight inefficiency, in my opinion.
Small, modular, component based systems, NEED the flexibility this affords,
in order to be responsive. Depending on user selection, code is loaded as
needed. Cool!
>First, it usually slows every call, not
> just the first.
Don't care. And disagree that subsequent calls are slower once the required
module has loaded.They certainly will be if you keep cancelling your loaded
module, but the days when we needed to do that are long gone.
> Second, the linker/loader nor tools like ldd cannot check those references
> because they don't know what value will be in the variable at execution
> time. It's usually
> a constant, but there's no way to declare that.
With early bound OO COBOL the compiler will check for compliance and that
the parameter lists conform to the requirements of the called component;
with late bound, as you point out, it cannot. But, if you REALLY care about
this (and I don't...) then there is nothing to stop you adding a prototype
for your late bound call and this will be validated against the Repository.
(At least, it will if you use Fujitsu...)
From procedural COBOL on mainframes using dynamic linkage, to OO Components
on the Network, I have used late binding for decades and found it powerful,
flexible, and useful. No way, is this a "bad idea"...
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| Richard 2007-11-15, 6:55 pm |
| On Nov 15, 4:02 pm, Robert <n...@e.mail> wrote:
> On Wed, 14 Nov 2007 00:55:56 -0800, Richard <rip...@Azonic.co.nz> wrote:
> This issue requires a rant on the inadequacies of programming language designers. They
> cause UNINTENDED CONSEQUENCES because they think like programmers rather administrators.
> Two examples are fresh in my mind because I'm fighting with them right now.
>
> Picture a very large shop that runs hundreds of thousands of batch jobs that execute
> millions of programs every month. Imagine an administrator writing automated
> 'verification' of those jobs BEFORE they run, so errors can be fixed BEFORE the jobs blow
> up in production. The existance of data files is the easiest thing to check.
Excuse me, but you dismiss the idea that data file names are in data
items in the program and may be built arbitrarily by the program (as I
in fact do with all my systems) and then rant on about how the same
thing for programs might be a problem.
> What about
> the existance of program files (verifying they are the correct version is the next step)?
>
> Unix's ELF standard and the aforementioned ldd (LoaDer Diagnostics) tool makes it easy to
> verify the existance of called programs, recursively checking for ALL of them. It works
> for every language EXCEPT Cobol (and other programs calling dlopen() directly, which is
> rare).
Actually you need to start with the job scripts, REXX scripts and
whatever else can start a binary executable, including system() calls.
You are merely ignoring real world in attempting to 'prove' that your
rant has any substance at all.
> Why do Cobol programmers need the flexibility to determine the names of child
> programs at execution time? In the vast majority of cases, they don't.
That may be. But dynamic calls are not just so one can 'make up' a
program name. In most cases the names are not arbitrary but are in
menu files or system control. In an interactive system the user is
presented with a range of options to select from which is the menu
file. On selecting a particular operation the particular program used
may depend on who the user is or what system options are in force.
> A few creative
> programmers will write 'dynamic systems' driven by decision tables (or similar) stored in
> databases, from which they get the names of child programs. That allows them to add child
> programs without having to recompile the parents .. provided someone installs the child
> program BEFORE putting its name into the database.
That's another use.
> That's fine for small systems with a
> small number of users. The programmer will personally install the child program. It
> doesn't work when there are dozens to hundreds of machines.
Yes it does work. For a system all programs are issued and the menu or
control file establishes which are valid for a particular user or
system option. In fact with my systems it also does access level and
password control.
> Worse, the list of child
> programs is in a NON-STANDARD location unknown to a general verification tool.
You have simply 'made up' a hypothetical so-called 'general'
verification tool which is inadequate and is not 'general' at all and
then criticized the design of it. Well, duh, do better next time.
> Each
> creative programmer will design a DIFFERENT location.
Only is situations where you have advocated the removal of 'shop
standards'.
> One might put the list in a load
> module, one in a database, one on his laptop's floppy mounted via NFS.
>
> This is anarcy. In order to verify programs, I need ALL externals stored in ELF headers.
'Need' all you want. I need other things and I care not about what you
want.
Dynamic calls are easily checked prior to the call or excepted via ON
EXCEPTION by the program itself. Well mine certainly do that and I
don't know any system that I have worked on that didn't.
> For Cobol programs calling via variables (data-names), I have to extract the VALUE from
> the data-name definition, look for MOVE 'prognm' TO DATA-NAME, use the values to build a
> dummy object that gets linked into the executable so the program's child names are in its
> symbol table. THIS SHOULD NOT BE NECESSARY.
I really don't care whether you use dynamic loading or not. It solves
problems for me and for many others. Problems such as isolating
changes so that module testing can be done and new routines issued
without having to relink and retest all programs. In fact the problem
of not relinking and thus leaving an old routine in production buried
in a static linked program is worse that your nonsense arguments.
> If someone on the Cobol Standards Committee
> had known the requirements of LARGE systems, the language would make a distinction between
> dynamic binding (a good thing) and dynamic determination of called program name (a bad
> thing).
That is only your opinion that it is 'bad'. In fact many modern
languages use reflection.
I suppose that you would also claim that building file names from,
say, company indicator and function was also 'bad' because your
'verification' cannot know this.
> My second gripe is over nested COPYs. The '85 Cobol Standard says they are not allowed.
> The unintended consequence of that stupid restriction is that our builds take 18 hours
> rather than 2 hours. Here's why. We don't write copybooks manually, we generate them from
> data dictionaries, for several languages -- .h files for C, .cpy for Cobol. We produce
> separate copybooks for 88 levels and for types. A Cobol type looks like "pic x(10)". The
> top level copybook for a structure looks like:
> 05 customer-number copy custno.typ..
> 05 customer-status copy status.typ..
> copy status.val. *> contains 88 levels
>
> Because the '85 Cobol Standard says nested COPYs are a no-no, we run a pre-pre-processor
> that combines the nested COPYs into a single one, which looks like this:
> custrow.cpy:
> 05 customer-number pic x(10).
> 05 customer-status pic x(01).
> 88 active value 'A'.
> 88 cancelled value 'C'.
>
> Our compilations are driven by make files, which are driven by generated dependency (make
> rule) files, which are created from source code. The problem is, we cannot determine the
> dependencies from reading Cobol source programs. All we see is "copy custrow.cpy". We
> cannot tell that status.val is a dependent. (Make decides what to compile by comparing
> timestamps of dependents to the timestamp of the executable.) One way to make it work
> would be to generate custrow.cpy into a temp area, compare it to the previous custrow.cpy,
> replacing custrow.cpy only if there is a difference. THIS SHOULD NOT BE NECESSARY,
> especially since Micro Focus and the '02 Cobol Standard both support nested COPYs. A
> better way to make it work would be to simply eliminate the pre-pre-processor. Instead we
> run 18 hour full builds because somebody back in the early '80s thought nested COPYs were
> too much trouble or unnecessary. They WERE unnecessary for small systems. If someone on
> the '85 Standards Committee had known the requirements of LARGE systems (10,000s of
> programs), our builds would already be running in 2 hours.
Excuse me, but nested COPYs would _not_ solve the problem because if
you changed a 2nd level that was in several 1st level COPY books then
your dependency building should (is required to) find that and thus be
equivalent to all the 1st levels being changed.
Alternately, only do your pre-pre-processing based on a make of the
1st level COPY and don't rebuild everything regardless of dependecies.
The problem isn't COBOL it is the stupid way that you build your
copybooks.
| |
| Richard 2007-11-15, 6:55 pm |
| On Nov 16, 1:49 am, "Michael Mattias" <mmatt...@talsystems.com> wrote:
> "Robert" <n...@e.mail> wrote in message
>
> news:3e0nj3taf1db7d0e95bcr8831ak8ds81vb@
4ax.com...
>
>
> How useful could that really be?
>
> Consider most programs are compiled within a "development" environment,
> where LIBLST or $JOBLIB or PATH depending on operating system will make the
> 'availability' of called files totally different in 'development' versus
> 'production' anyway.
>
> I 'suppose' someone could invent a utilty to do check a program file "in its
> current environment" for called file availability, but with the ability do
> dynamically change the called program file name based on the value of
> variables, I can't see how that could be done without having the source code
> handy AND being able to test for all possible values and permutations of
> values..
>
> e.g., I have three commercial applications in which the name of the called
> library is (yes, it's true) USER-DEFINED. How on earth can that be tested
> from without?
>
> Better I think for applications developers to include some kind of "called
> program availability checking" support within the application itself.
>
> MCM
In my systems I can, having logged into the application's menu system
with sufficient 'access level', hit a key and type in a program name
to run it. This may be a special non-menu program or a one-off fixit.
The application checks that the program exists, checks in the control
file if there is a password lock or access level control on the name
and then attempts to call it. On failure it simply reports that it
couldn't do that. No abend, no drama.
| |
| Richard 2007-11-15, 6:55 pm |
| On Nov 16, 5:54 am, "Frank Swarbrick" <Frank.Swarbr...@efirstbank.com>
wrote:
> <3e0nj3taf1db7d0e95bcr8831ak8ds8...@4ax.com>, Robert<n...@e.mail> wrote:
>
>
>
>
>
>
>
>
> While
>
>
>
>
> I can't really answer this question. I understand (I think!) the difference
> between static and dynamic binding on the VSE mainframe operating system. I
> assume that z/OS is similar, but not having used it I don't know for sure.
> I have a feeling, from what you have said, that Windows and Unix-like
> operating systems have some sort of third, 'in the middle', kind of binding?
> But I have little understanding of it.
>
> I personally have little need for CALL data-name *other* than the fact that
> it is the default way, in VSE, of doing a dynamic call. With the default
> compile option NODYNAM, CALL literal will always resolve the entry-point
> name at compile time and attempt to link the OBJ at link-edit time. If the
> an OBJ with that name does not exist (in the OBJ search chain), and there is
> not explicit include of an OBJ that includes that name as an entry point,
> then the link-edit will warn about that.
>
> On the other hand, if you use CALL data-name then, obviously, at link-edit
> time there is not any knowledge of the name of the routine to be called.
> This is determined only at run-time.
>
> The compile option names are actually rather deceptive. NODYNAM doesn't
> mean that dynamic calls are not allowed, but rather they are not the
> default. DYNAM, on the other-hand should really be NOSTATIC, as both CALL
> data-name and CALL literal perform static calls.
>
> I would be all for some way of having a 'dynamic' call of a 'static' name.
> But I'm not really sure how that would work. Is the following possible in
> the Windows/Unix world?
> - Create a DLL that contains some subroutines.
> - Create an EXE that uses some of the subroutines in the DLL.
> - Install the DLL and EXE to a production system.
> - Make some changes to the internals (but not the interface) of the DLL.
> - Install the new version of the DLL to the production system, not touching
> the EXE at all.
> - Run the EXE
>
> When you run the EXE will it use the newly installed DLL?
>
> If it does, I am interested in how this works. Not necessarily in Cobol,
> but maybe in C.
> If it does not work then, well, I prefer the Cobol way, even with it's
> faults in that at compile/link time there's no simple way to know what
> 'entry points' will be called at run-time.
>
> I know of no way of, in VSE, doing what you ask above. I won't say we've
> never had a problem, but it is indeed rare for a program to have problems at
> run time because of an attempt to dynamically call a non-existent routine.
>
> (We did, in fact, have a problem recently where we intentionally removed the
> executable of a dynamically called routine because we thought we had
> eliminated all use of it, and in fact we had not. But still, it's rare.)
>
> Frank
If this removal was to avoid the action that routine did then it is
best to replace it with a dummy routine of the same name that logs its
activation and returns. In fact I have done this where replacement
programs were developed. Both the old and new were available for an
overlap period then the old was replaced by a routine that simply made
the link to the new.
| |
| Pete Dashwood 2007-11-15, 6:55 pm |
|
"Robert" <no@e.mail> wrote in message
news:ao5nj3htd2qp1g6p1r7r2c8pvmp8556ul5@
4ax.com...
> On Wed, 14 Nov 2007 00:55:56 -0800, Richard <riplin@Azonic.co.nz> wrote:
>
>
> This issue requires a rant on the inadequacies of programming language
> designers. They
> cause UNINTENDED CONSEQUENCES because they think like programmers rather
> administrators.
> Two examples are fresh in my mind because I'm fighting with them right
> now.
>
I would have severe resevations about using a programming language designed
by Administrators.... :-)
> Picture a very large shop that runs hundreds of thousands of batch jobs
> that execute
> millions of programs every month. Imagine an administrator writing
> automated
> 'verification' of those jobs BEFORE they run, so errors can be fixed
> BEFORE the jobs blow
> up in production. The existance of data files is the easiest thing to
> check. What about
> the existance of program files (verifying they are the correct version is
> the next step)?
This should be a "write once" exercise by a team of people who know
something about JCL... It doesn't matter how many millions of programs are
being used, they get invoked by a Job Control language of some kind, and
that's where the problem should be addressed.
Your XXXXX is that with dynamic calling they can't know what will be loaded.
How is that the fault of the language designers?
Leaving that aside for a moment, there must be approaches that can provide a
"skeleton" JCL procedure, or set of JCL (or equivalent) for ANY program
that is doing dynamic calling. If you can't know what is being called, then
you can't pre-check individual load module names/versions, but, you CAN make
sure that the libraries containing ANYTHING that might be called are on line
to the job. Shop Programming Standards can ensure that every program logs
itself and its version when loaded, if that is a concern, so there is an
audit trail if required. There are always solutions, and they don't
necessarily involve analysing load modules to obtain symbols...
>
> Unix's ELF standard and the aforementioned ldd (LoaDer Diagnostics) tool
> makes it easy to
> verify the existance of called programs, recursively checking for ALL of
> them. It works
> for every language EXCEPT Cobol (and other programs calling dlopen()
> directly, which is
> rare). Why do Cobol programmers need the flexibility to determine the
> names of child
> programs at execution time? In the vast majority of cases, they don't.
Who are you to decide what COBOL programmers need or want? :-)
The people who designed the language needed to cater for every possible use
they could reasonably envision. Your site has exceptional needs.
Nevertheless, the facilites exist to meet even those needs. It is just a
question of looking at various approaches, and taking a wholistic view; not
just a language based one.
> A few creative
> programmers will write 'dynamic systems' driven by decision tables (or
> similar) stored in
> databases, from which they get the names of child programs. That allows
> them to add child
> programs without having to recompile the parents .. provided someone
> installs the child
> program BEFORE putting its name into the database. That's fine for small
> systems with a
> small number of users. The programmer will personally install the child
> program. It
> doesn't work when there are dozens to hundreds of machines. Worse, the
> list of child
> programs is in a NON-STANDARD location unknown to a general verification
> tool. Each
> creative programmer will design a DIFFERENT location. One might put the
> list in a load
> module, one in a database, one on his laptop's floppy mounted via NFS.
And that is one reason why installations have Local Standards... To ensure a
consistent approach.
(Actually, most of the dynamic systems I have worked with or designed, DON'T
use a list of possible candidates for calling. Instead they CALCULATE the
name of the needed module. This is possible because the standards require a
certain naming convention, and program names are carefully controlled and
allocated in accordance with that convention. A given module name will
indicate what it does, and which sub-system it applies to...)
>
> This is anarcy.
It is anarchic only if you expect conformance with ONE specific approach...
Flexibility CAN become anarchic if it isn't controlled, that is why it is,
for the most part, controlled.
> In order to verify programs, I need ALL externals stored in ELF headers.
That is a requirement that is extremely specific and nothing to do with
COBOL.
> For Cobol programs calling via variables (data-names), I have to extract
> the VALUE from
> the data-name definition, look for MOVE 'prognm' TO DATA-NAME, use the
> values to build a
> dummy object that gets linked into the executable so the program's child
> names are in its
> symbol table. THIS SHOULD NOT BE NECESSARY.
It isn't. You find it necessary because of a specific approach you have
CHOSEN. A guy as bright and imaginative as you, Robert, could certainly find
alternative approaches. I reckon you're just not trying... :-)
>If someone on the Cobol Standards Committee
> had known the requirements of LARGE systems, the language would make a
> distinction between
> dynamic binding (a good thing) and dynamic determination of called program
> name (a bad
> thing).
Nothing is Good or Bad, but thinking makes it so.
>
> ------
>
> My second gripe is over nested COPYs. The '85 Cobol Standard says they are
> not allowed.
> The unintended consequence of that stupid restriction is that our builds
> take 18 hours
> rather than 2 hours.
Very short sighted for a committee to not foresee (over twenty years ago)
that there would be this "unintended consequence" from what they decided...
:-)
>Here's why. We don't write copybooks manually, we generate them from
> data dictionaries, for several languages -- .h files for C, .cpy for
> Cobol. We produce
> separate copybooks for 88 levels and for types. A Cobol type looks like
> "pic x(10)". The
> top level copybook for a structure looks like:
> 05 customer-number copy custno.typ..
> 05 customer-status copy status.typ..
> copy status.val. *> contains 88 levels
>
> Because the '85 Cobol Standard says nested COPYs are a no-no, we run a
> pre-pre-processor
> that combines the nested COPYs into a single one, which looks like this:
> custrow.cpy:
> 05 customer-number pic x(10).
> 05 customer-status pic x(01).
> 88 active value 'A'.
> 88 cancelled value 'C'.
>
> Our compilations are driven by make files, which are driven by generated
> dependency (make
> rule) files, which are created from source code. The problem is, we cannot
> determine the
> dependencies from reading Cobol source programs. All we see is "copy
> custrow.cpy". We
> cannot tell that status.val is a dependent. (Make decides what to compile
> by comparing
> timestamps of dependents to the timestamp of the executable.) One way to
> make it work
> would be to generate custrow.cpy into a temp area, compare it to the
> previous custrow.cpy,
> replacing custrow.cpy only if there is a difference. THIS SHOULD NOT BE
> NECESSARY,
> especially since Micro Focus and the '02 Cobol Standard both support
> nested COPYs. A
> better way to make it work would be to simply eliminate the
> pre-pre-processor. Instead we
> run 18 hour full builds because somebody back in the early '80s thought
> nested COPYs were
> too much trouble or unnecessary. They WERE unnecessary for small systems.
> If someone on
> the '85 Standards Committee had known the requirements of LARGE systems
> (10,000s of
> programs), our builds would already be running in 2 hours.
If you are that bothered by this, you could certainly write your own COPY
processor. (I just finished doing that for a code generator I delivered a
few days ago. It's not rocket science... :-))
If you did a hardware upgrade, it wouldn't take 18 hours to build.... :-)
There are always options.
Hmmmmm..... :-)
It's hardly fair to expect a Standards Committee to predict HOW people are
going to use the provided facilities, before the applications have ever been
written... :-)
I was interested to see your post, Robert, and I recognise the problems you
are encountering, but this is not the fault of the people who designed
COBOL, or even those who later took responsibility for it.
Installations CHOOSE how they are going to do stuff.
It isn't the fault of the language.
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| Robert 2007-11-16, 3:55 am |
| On Thu, 15 Nov 2007 12:49:11 GMT, "Michael Mattias" <mmattias@talsystems.com> wrote:
>"Robert" <no@e.mail> wrote in message
> news:3e0nj3taf1db7d0e95bcr8831ak8ds81vb@
4ax.com...
>
>How useful could that really be?
>
>Consider most programs are compiled within a "development" environment,
>where LIBLST or $JOBLIB or PATH depending on operating system will make the
>'availability' of called files totally different in 'development' versus
>'production' anyway.
That's why I said "after compilation and again before execution."
>I 'suppose' someone could invent a utilty to do check a program file "in its
>current environment" for called file availability,
I said Unix has such a utility, named ldd, and asked whether z/OS has the same. Since you
refer to it as a hypothetical, I'll take that as a No.
>but with the ability do
>dynamically change the called program file name based on the value of
>variables, I can't see how that could be done without having the source code
>handy AND being able to test for all possible values and permutations of
>values..
That's why I asked.
>e.g., I have three commercial applications in which the name of the called
>library is (yes, it's true) USER-DEFINED. How on earth can that be tested
>from without?
By searching a library path, same as the OS does at execution time.
>Better I think for applications developers to include some kind of "called
>program availability checking" support within the application itself.
Fifty years of experience has shown applications cannot be trusted to do that. Moreover,
it is inefficient for every application program to do its own administration. JCL was
invented so that applications didn't have to worry about the application environment, at
least for data files.
| |
| Robert 2007-11-16, 3:55 am |
| On Thu, 15 Nov 2007 13:50:03 -0800 (PST), Richard <riplin@azonic.co.nz> wrote:
>On Nov 15, 4:02 pm, Robert <n...@e.mail> wrote:
>
>
>Excuse me, but you dismiss the idea that data file names are in data
>items in the program and may be built arbitrarily by the program (as I
>in fact do with all my systems) and then rant on about how the same
>thing for programs might be a problem.
Mainframes don't allow a program to specify a data file name. Instead the program
specifies a 'DD name', which JCL associates with the actual file name. That's why it is so
easy to verify mainframe jobs.
Data files are no longer a major concern because we no longer store data in them. They're
used only to exchange data with other systems. The job scheduler won't start a batch job
until its input files are available.
>
>Actually you need to start with the job scripts, REXX scripts and
>whatever else can start a binary executable, including system() calls.
>You are merely ignoring real world in attempting to 'prove' that your
>rant has any substance at all.
You're right. Scripts contain names of the programs to be verified.
>
>That may be. But dynamic calls are not just so one can 'make up' a
>program name. In most cases the names are not arbitrary but are in
>menu files or system control. In an interactive system the user is
>presented with a range of options to select from which is the menu
>file. On selecting a particular operation the particular program used
>may depend on who the user is or what system options are in force.
What you're actually trying to protect is DATA -- who can see it and who can change it.
While you're busily locking the front door, bad guys are taking your data out through the
back door. They're not running your application programs, they're writing their own or
using general-purose query languages.
I've seen lots of home-grown security and none of it is worth a crap.
>
>That's another use.
>
>
>Yes it does work. For a system all programs are issued and the menu or
>control file establishes which are valid for a particular user or
>system option. In fact with my systems it also does access level and
>password control.
You are verifying what people CAN'T do. You're not verifying that they CAN do what they're
supposed to be able to.
We get many complaints from legitimate users; bad guys never call for support.
>
>You have simply 'made up' a hypothetical so-called 'general'
>verification tool which is inadequate and is not 'general' at all and
>then criticized the design of it. Well, duh, do better next time.
Here is an account of job verification from a shop smaller than mine. Note especially
"requested module not found." You should write to the website's owner with the news that
it's all made up.
"The customer uses the scheduling system “TWS for z/OS” (OPC) to run more than 65,000 z/OS
jobs and 15,000 decentralized processes each day. HORIZONT SmartJCL was used to check the
JCL. SmartJCL’s integrated simulation system made it possible to completely simulate the
eleven production days required and to identify all possible errors in advance (“DATA SET
NOT FOUND”, “REQUESTED MODULE NOT FOUND”, “UNDEFINED VARIABLE XYZ LINE 00008 OF ORIG JCL”)
A total of 453,406 jobs containing approx. 3 million steps were checked in approx. 6
hours.
Production planning has now started using the SmartJCL catalog check feature for other
purposes, for example, checking an entire production month of approx. 870,000 jobs in
advance."
http://www.horizont-it.com/public_html/jckdhvbe.htm
>
>Only is situations where you have advocated the removal of 'shop
>standards'.
>
>
>'Need' all you want. I need other things and I care not about what you
>want.
>
>Dynamic calls are easily checked prior to the call or excepted via ON
>EXCEPTION by the program itself. Well mine certainly do that and I
>don't know any system that I have worked on that didn't.
So you've never used a third-party library. You wrote the middleware and database yourself
... and the address verification .. and the GUI library. I don't dispute the home-grown
security.
>
>I really don't care whether you use dynamic loading or not. It solves
>problems for me and for many others. Problems such as isolating
>changes so that module testing can be done and new routines issued
>without having to relink and retest all programs. In fact the problem
>of not relinking and thus leaving an old routine in production buried
>in a static linked program is worse that your nonsense arguments.
I'm talking about verifying dynamic links. You set up the straw man, static links, then
knock him down. I guess there MIGHT be someone who doesn't see the irrelevance of your
argument.
>
>That is only your opinion that it is 'bad'. In fact many modern
>languages use reflection.
They can't reflect on a component that's missing.
>I suppose that you would also claim that building file names from,
>say, company indicator and function was also 'bad' because your
>'verification' cannot know this.
That should be done outside the program and passed to its script, if batch, or passed to
the program via environment variables.
>
>Excuse me, but nested COPYs would _not_ solve the problem because if
>you changed a 2nd level that was in several 1st level COPY books then
>your dependency building should (is required to) find that and thus be
>equivalent to all the 1st levels being changed.
When building make rules, it would recursively look at all copy books. The 2nd level ones
would be listed as dependencies.
>Alternately, only do your pre-pre-processing based on a make of the
>1st level COPY and don't rebuild everything regardless of dependecies.
It's a chicken and egg problem. You can't use dependency rules to build dependency rules
because you don't know what the dependencies are until the rules are built.
>The problem isn't COBOL it is the stupid way that you build your copybooks.
You think we should stop generating them from data dictionaries and go back to writing
them manually. Will your next suggestion be to stop using databases and go back to indexed
files?
| |
|
| |