Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
My case against using COPY
85 views
Skip to first unread message
Pete Dashwood
Apr 11, 2013, 9:50:07 PM4/11/13
to
There is an interesting thread about the wording and lengths of COPY
statements going on currently and it made me think about why I don't care.
Back in Anciente Tymes we realized it was pretty tedious (not to mention
error prone) to physically include cards for SELECTs and FDs into a program
deck before compiling it.
Initially, (at least on one site where I worked) these definitions were
punched onto cards of a different colour and a "marker" card was inserted
by the programmer in the main deck. The Operator then inserted the required
definitions at each marker and compiled the program... Although this meant
that there was only ONE definition of each file, it split the responsibility
between Programming and Operations and there were arguments whenever
something went wrong. (The most common problem was an Operator dropping a
deck of cards (ever wondered why cobol supports sequence numbers in source
statements? Now you know :-) We also ruled a diagonal line, using a marker
pen, from end to end of the card deck. It was amazng how effective this was;
if a card was out of sequence you could see it immediately, however, as
cards got deliberately re-sequenced for debugging and maintenance it meant a
new deck had to be produced and card punches were not so fast at copying...)
Eventually most sites made Programming responsible for the content of
program card decks and just accepted that there would be multiple copies of
the file definitions, spread across different decks.
As time progressed and disk drives arrived, the source decks were now
fetched from disk and it was therefore possible to randomly access a Source
Library and insert the file definitions where they were needed before going
on to compile.
COBOL implemented a COPY statement to facilitiate this, and this evolved to
a point where you could actually replace tokens in the file definition at
the time you COPYed it.
It was not unusual to see things like:
01 XXX-MASTER-FILE.
12 XXX-MASTER-ID PIC X(7).
12 XXX-FIELD1 PIC ...
You could change the XXX to be "IN" or "OUT" with a COPY...REPLACING
statement.
Much better than physically inserting punched cards...
The trouble with this was that everyone went berserk and never even thought
about possible alternatives to it.
Every time a program needed a file, it included COPY statements to get that
file definition. Hundreds of programs, many containing the same code for
defining the files they used.
Well, it didn't matter because it was still fetching ONE copy from disk,
right?
But, imagine for a moment if there had been NO COPY facility.
If you wanted to use a file, you would write ONE sub-program which contained
the definition of it and the various actions you could do against it. Then
you would CALL that module and pass a data buffer and the action you
required, it would do the action and return the updated buffer, along with a
status code.
Can you imagine the number of lines of source code this approach would save
if you had, say, 50 programs all using the same file?
I was actually tasked to do this with a team in England for VSAM/KSDSes in
the late 1970s.
We designed a "Database" using VSAM indexed files (about 200 of them) and we
built a Data Access Layer using templated COBOL code with a single module
for each of the files.
(Of course we didn't know about things like "encapsulation" and
"multi-tiered design" or "separation layers", we just did it because it
seemed sensible.)
To everyone's astonishment it worked extremely well and we found we could
add modules into the layer when we needed to define relationships and
"joined views" of data. In fact, it was so successful that when the Company
decided to move to IMS some years later, there was fierce resistance from
the UK part of the company who said they were perfectly happy with what they
had.... :-)
Since then, the Object Oriented paradigm has kind of replaced the kind of
"programming think" that led to extended use of COPY books. Things ARE
encapsulated (automatically) in the form of object instances, and you would
write a single class to handle database or file access. (The PRIMA Migration
Toolset actually generates these Classes, based on your database design,
which it also generates, based on your COBOL COPY books... These days, there
is no need for programmers to even worry about it.)
Given the above, I contend that COPY really has no place in modern
programming and is obsolete.
(Even in the COBOL I have written over the past 20 years, I have not had
occasion to use COPY...)
The proper place for COPY is in Legacy code and as that gets phased out, so
should the need for COPY.
Pete.
--
"I used to write COBOL...now I can do anything."
statements going on currently and it made me think about why I don't care.
Back in Anciente Tymes we realized it was pretty tedious (not to mention
error prone) to physically include cards for SELECTs and FDs into a program
deck before compiling it.
Initially, (at least on one site where I worked) these definitions were
punched onto cards of a different colour and a "marker" card was inserted
by the programmer in the main deck. The Operator then inserted the required
definitions at each marker and compiled the program... Although this meant
that there was only ONE definition of each file, it split the responsibility
between Programming and Operations and there were arguments whenever
something went wrong. (The most common problem was an Operator dropping a
deck of cards (ever wondered why cobol supports sequence numbers in source
statements? Now you know :-) We also ruled a diagonal line, using a marker
pen, from end to end of the card deck. It was amazng how effective this was;
if a card was out of sequence you could see it immediately, however, as
cards got deliberately re-sequenced for debugging and maintenance it meant a
new deck had to be produced and card punches were not so fast at copying...)
Eventually most sites made Programming responsible for the content of
program card decks and just accepted that there would be multiple copies of
the file definitions, spread across different decks.
As time progressed and disk drives arrived, the source decks were now
fetched from disk and it was therefore possible to randomly access a Source
Library and insert the file definitions where they were needed before going
on to compile.
COBOL implemented a COPY statement to facilitiate this, and this evolved to
a point where you could actually replace tokens in the file definition at
the time you COPYed it.
It was not unusual to see things like:
01 XXX-MASTER-FILE.
12 XXX-MASTER-ID PIC X(7).
12 XXX-FIELD1 PIC ...
You could change the XXX to be "IN" or "OUT" with a COPY...REPLACING
statement.
Much better than physically inserting punched cards...
The trouble with this was that everyone went berserk and never even thought
about possible alternatives to it.
Every time a program needed a file, it included COPY statements to get that
file definition. Hundreds of programs, many containing the same code for
defining the files they used.
Well, it didn't matter because it was still fetching ONE copy from disk,
right?
But, imagine for a moment if there had been NO COPY facility.
If you wanted to use a file, you would write ONE sub-program which contained
the definition of it and the various actions you could do against it. Then
you would CALL that module and pass a data buffer and the action you
required, it would do the action and return the updated buffer, along with a
status code.
Can you imagine the number of lines of source code this approach would save
if you had, say, 50 programs all using the same file?
I was actually tasked to do this with a team in England for VSAM/KSDSes in
the late 1970s.
We designed a "Database" using VSAM indexed files (about 200 of them) and we
built a Data Access Layer using templated COBOL code with a single module
for each of the files.
(Of course we didn't know about things like "encapsulation" and
"multi-tiered design" or "separation layers", we just did it because it
seemed sensible.)
To everyone's astonishment it worked extremely well and we found we could
add modules into the layer when we needed to define relationships and
"joined views" of data. In fact, it was so successful that when the Company
decided to move to IMS some years later, there was fierce resistance from
the UK part of the company who said they were perfectly happy with what they
had.... :-)
Since then, the Object Oriented paradigm has kind of replaced the kind of
"programming think" that led to extended use of COPY books. Things ARE
encapsulated (automatically) in the form of object instances, and you would
write a single class to handle database or file access. (The PRIMA Migration
Toolset actually generates these Classes, based on your database design,
which it also generates, based on your COBOL COPY books... These days, there
is no need for programmers to even worry about it.)
Given the above, I contend that COPY really has no place in modern
programming and is obsolete.
(Even in the COBOL I have written over the past 20 years, I have not had
occasion to use COPY...)
The proper place for COPY is in Legacy code and as that gets phased out, so
should the need for COPY.
Pete.
--
"I used to write COBOL...now I can do anything."
Arnold Trembley
Apr 12, 2013, 5:17:59 AM4/12/13
to
On 4/11/2013 8:50 PM, Pete Dashwood wrote:
> <SNIP>
Pete,
I enjoyed your post, but I am confused about one thing. If you have 50
programs all calling the same file-access subprogram, what do they use
for the record layout of the returned buffer? How do you avoid using a
copybook for that?
There are other problems with copybooks you didn't mention. I have seen
two different departments access the same file but each has their own
copybook for it, which means when one changes the other must also be
changed or errors will occur.
Sometimes in the course of development you need to compile a program
that has multiple copybooks, but some need to be retrieved from a test
library and some need to be retrieved from the production library. An
emergency bug fix might force you to recompile with an older version of
a production copybook. Naturally this makes the programmer's job harder.
I have seen ASSIGN statements and FD's in copybooks, but very rarely. I
have also seen copybooks containing procedure division code, which is
also uncommon, even though I created one once.
We normally use copybooks only for 01 record layouts, and we sometimes
use COPY..REPLACING to modify the data name prefix. I think the details
of COPY..REPLACING changed between OS/VS COBOL and COBOL II in a way
that required making additional source code changes.
> <SNIP>
of ALTER in early COBOL programs.
It is certainly possible to write COBOL programs without using available
copybooks. I have done that, but generally for throwaway programs. In
a production program I would use the copybook, because it is relatively
easy to scan the library for all programs that use a particular
copybook. It helps identify the impact of a proposed change.
Kind regards,
--
http://www.arnoldtrembley.com/
> <SNIP>
>
> But, imagine for a moment if there had been NO COPY facility.
>
> If you wanted to use a file, you would write ONE sub-program which contained
> the definition of it and the various actions you could do against it. Then
> you would CALL that module and pass a data buffer and the action you
> required, it would do the action and return the updated buffer, along with a
> status code.
>
> Can you imagine the number of lines of source code this approach would save
> if you had, say, 50 programs all using the same file?
> <SNIP>
> But, imagine for a moment if there had been NO COPY facility.
>
> If you wanted to use a file, you would write ONE sub-program which contained
> the definition of it and the various actions you could do against it. Then
> you would CALL that module and pass a data buffer and the action you
> required, it would do the action and return the updated buffer, along with a
> status code.
>
> Can you imagine the number of lines of source code this approach would save
> if you had, say, 50 programs all using the same file?
Pete,
I enjoyed your post, but I am confused about one thing. If you have 50
programs all calling the same file-access subprogram, what do they use
for the record layout of the returned buffer? How do you avoid using a
copybook for that?
There are other problems with copybooks you didn't mention. I have seen
two different departments access the same file but each has their own
copybook for it, which means when one changes the other must also be
changed or errors will occur.
Sometimes in the course of development you need to compile a program
that has multiple copybooks, but some need to be retrieved from a test
library and some need to be retrieved from the production library. An
emergency bug fix might force you to recompile with an older version of
a production copybook. Naturally this makes the programmer's job harder.
I have seen ASSIGN statements and FD's in copybooks, but very rarely. I
have also seen copybooks containing procedure division code, which is
also uncommon, even though I created one once.
We normally use copybooks only for 01 record layouts, and we sometimes
use COPY..REPLACING to modify the data name prefix. I think the details
of COPY..REPLACING changed between OS/VS COBOL and COBOL II in a way
that required making additional source code changes.
> <SNIP>
>
> Given the above, I contend that COPY really has no place in modern
> programming and is obsolete.
>
> (Even in the COBOL I have written over the past 20 years, I have not had
> occasion to use COPY...)
>
> The proper place for COPY is in Legacy code and as that gets phased out, so
> should the need for COPY.
>
> Pete.
>
That seems like a provocative statement for someone who defended the use
> Given the above, I contend that COPY really has no place in modern
> programming and is obsolete.
>
> (Even in the COBOL I have written over the past 20 years, I have not had
> occasion to use COPY...)
>
> The proper place for COPY is in Legacy code and as that gets phased out, so
> should the need for COPY.
>
> Pete.
>
of ALTER in early COBOL programs.
It is certainly possible to write COBOL programs without using available
copybooks. I have done that, but generally for throwaway programs. In
a production program I would use the copybook, because it is relatively
easy to scan the library for all programs that use a particular
copybook. It helps identify the impact of a proposed change.
Kind regards,
--
http://www.arnoldtrembley.com/
Alistair Maclean
Apr 12, 2013, 7:27:33 AM4/12/13
to
On Friday, 12 April 2013 02:50:07 UTC+1, Pete Dashwood wrote:
> But, imagine for a moment if there had been NO COPY facility. If you wanted > to use a file, you would write ONE sub-program which contained the definition > of it and the various actions you could do against it. Then you would CALL
> that module and pass a data buffer and the action you required, it would do
> the action and return the updated buffer, along with a status code. Can you
> imagine the number of lines of source code this approach would save if you
> had, say, 50 programs all using the same file?
I have done this on a series of programs for a hobby database and was appalled at the added complexity and the increase in source size to achieve this.
> But, imagine for a moment if there had been NO COPY facility. If you wanted > to use a file, you would write ONE sub-program which contained the definition > of it and the various actions you could do against it. Then you would CALL
> that module and pass a data buffer and the action you required, it would do
> the action and return the updated buffer, along with a status code. Can you
> imagine the number of lines of source code this approach would save if you
> had, say, 50 programs all using the same file?
> We built a Data Access Layer using templated COBOL code with a single module
> for each of the files.
I shall persist (like a bad pollutant) with the data access layer philosophy pro temps even though I see drawbacks associated with it. Should I ever work in IT again I shall probably use the method there too.
> I contend that COPY really has no place in modern programming and is
> obsolete. (Even in the COBOL I have written over the past 20 years, I have
> not had occasion to use COPY...)
Robin Vowels
Apr 12, 2013, 10:57:52 AM4/12/13
to
On Apr 12, 11:50 am, "Pete Dashwood"
100 cards per minute, verifying the copied cards as it went.
<dashw...@removethis.enternet.co.nz> wrote:
> There is an interesting thread about the wording and lengths of COPY
> statements going on currently and it made me think about why I don't care.
>
> Back in Anciente Tymes we realized it was pretty tedious (not to mention
> error prone) to physically include cards for SELECTs and FDs into a program
> deck before compiling it.
>
> Initially, (at least on one site where I worked) these definitions were
> punched onto cards of a different colour and a "marker" card was inserted
> by the programmer in the main deck. The Operator then inserted the required
> definitions at each marker and compiled the program... Although this meant
> that there was only ONE definition of each file, it split the responsibility
> between Programming and Operations and there were arguments whenever
> something went wrong. (The most common problem was an Operator dropping a
> deck of cards (ever wondered why cobol supports sequence numbers in source
> statements? Now you know :-) We also ruled a diagonal line, using a marker
> pen, from end to end of the card deck. It was amazng how effective this was;
> if a card was out of sequence you could see it immediately, however, as
> cards got deliberately re-sequenced for debugging and maintenance it meant a
> new deck had to be produced and card punches were not so fast at copying...)
A card reproducer, standard on sites back then, did the job at
> There is an interesting thread about the wording and lengths of COPY
> statements going on currently and it made me think about why I don't care.
>
> Back in Anciente Tymes we realized it was pretty tedious (not to mention
> error prone) to physically include cards for SELECTs and FDs into a program
> deck before compiling it.
>
> Initially, (at least on one site where I worked) these definitions were
> punched onto cards of a different colour and a "marker" card was inserted
> by the programmer in the main deck. The Operator then inserted the required
> definitions at each marker and compiled the program... Although this meant
> that there was only ONE definition of each file, it split the responsibility
> between Programming and Operations and there were arguments whenever
> something went wrong. (The most common problem was an Operator dropping a
> deck of cards (ever wondered why cobol supports sequence numbers in source
> statements? Now you know :-) We also ruled a diagonal line, using a marker
> pen, from end to end of the card deck. It was amazng how effective this was;
> if a card was out of sequence you could see it immediately, however, as
> cards got deliberately re-sequenced for debugging and maintenance it meant a
> new deck had to be produced and card punches were not so fast at copying...)
100 cards per minute, verifying the copied cards as it went.
SkippyPB
Apr 12, 2013, 11:17:27 AM4/12/13
to
by when I don't use a COPY statement to pull in a record description
of some sort or the other. And not just in COBOL code either.
Utilities like DYL280 and Ezytrieve can use COBOL copybooks as well.
Regards,
--
////
(o o)
-oOO--(_)--OOo-
My Dictionary: Marriage: It's an agreement in which a man
loses his bachelor degree and a woman gains her masters.
-- Unknown
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Remove nospam to email me.
Steve
Richard
Apr 12, 2013, 3:20:38 PM4/12/13
to
On Apr 12, 1:50 pm, "Pete Dashwood"
The CALL statement wasn't part of COBOL until the '74 standard.
Earlier ICL COBOL compilers used ENTER to call library routines but
these were bound into the executable at compile time.
In order to ensure that the CALLer and the CALLed have consistent
record layouts in the data buffers then they should use COPY.
Most programming languages have a COPY like facility, it is 'import'
or 'use' or '#include'.
> Can you imagine the number of lines of source code this approach would save
> if you had, say, 50 programs all using the same file?
Approximately NONE.
> I was actually tasked to do this with a team in England for VSAM/KSDSes in
> the late 1970s.
>
> We designed a "Database" using VSAM indexed files (about 200 of them) and we
> built a Data Access Layer using templated COBOL code with a single module
> for each of the files.
>
> (Of course we didn't know about things like "encapsulation" and
> "multi-tiered design" or "separation layers", we just did it because it
> seemed sensible.)
>
> To everyone's astonishment it worked extremely well and we found we could
> add modules into the layer when we needed to define relationships and
> "joined views" of data. In fact, it was so successful that when the Company
> decided to move to IMS some years later, there was fierce resistance from
> the UK part of the company who said they were perfectly happy with what they
> had.... :-)
>
> Since then, the Object Oriented paradigm has kind of replaced the kind of
> "programming think" that led to extended use of COPY books. Things ARE
> encapsulated (automatically) in the form of object instances, and you would
> write a single class to handle database or file access. (The PRIMA Migration
> Toolset actually generates these Classes, based on your database design,
> which it also generates, based on your COBOL COPY books... These days, there
> is no need for programmers to even worry about it.)
>
> Given the above, I contend that COPY really has no place in modern
> programming and is obsolete.
I don't know what C# uses for 'import' but it will be a synonym for
COPY.
Earlier ICL COBOL compilers used ENTER to call library routines but
these were bound into the executable at compile time.
In order to ensure that the CALLer and the CALLed have consistent
record layouts in the data buffers then they should use COPY.
Most programming languages have a COPY like facility, it is 'import'
or 'use' or '#include'.
> Can you imagine the number of lines of source code this approach would save
> if you had, say, 50 programs all using the same file?
> I was actually tasked to do this with a team in England for VSAM/KSDSes in
> the late 1970s.
>
> We designed a "Database" using VSAM indexed files (about 200 of them) and we
> built a Data Access Layer using templated COBOL code with a single module
> for each of the files.
>
> (Of course we didn't know about things like "encapsulation" and
> "multi-tiered design" or "separation layers", we just did it because it
> seemed sensible.)
>
> To everyone's astonishment it worked extremely well and we found we could
> add modules into the layer when we needed to define relationships and
> "joined views" of data. In fact, it was so successful that when the Company
> decided to move to IMS some years later, there was fierce resistance from
> the UK part of the company who said they were perfectly happy with what they
> had.... :-)
>
> Since then, the Object Oriented paradigm has kind of replaced the kind of
> "programming think" that led to extended use of COPY books. Things ARE
> encapsulated (automatically) in the form of object instances, and you would
> write a single class to handle database or file access. (The PRIMA Migration
> Toolset actually generates these Classes, based on your database design,
> which it also generates, based on your COBOL COPY books... These days, there
> is no need for programmers to even worry about it.)
>
> Given the above, I contend that COPY really has no place in modern
> programming and is obsolete.
COPY.
Pete Dashwood
Apr 13, 2013, 8:07:28 PM4/13/13
to
Arnold Trembley wrote:
> On 4/11/2013 8:50 PM, Pete Dashwood wrote:
>> <SNIP>
>>
>> But, imagine for a moment if there had been NO COPY facility.
>>
>> If you wanted to use a file, you would write ONE sub-program which
>> contained the definition of it and the various actions you could do
>> against it. Then you would CALL that module and pass a data buffer
>> and the action you required, it would do the action and return the
>> updated buffer, along with a status code.
>>
>> Can you imagine the number of lines of source code this approach
>> would save if you had, say, 50 programs all using the same file?
>> <SNIP>
>
> Pete,
>
> I enjoyed your post, but I am confused about one thing. If you have
> 50 programs all calling the same file-access subprogram, what do they
> use for the record layout of the returned buffer? How do you avoid
> using a copybook for that?
Yes, a good point. (the "returned buffer" becomes part of an interface
> On 4/11/2013 8:50 PM, Pete Dashwood wrote:
>> <SNIP>
>>
>> But, imagine for a moment if there had been NO COPY facility.
>>
>> If you wanted to use a file, you would write ONE sub-program which
>> contained the definition of it and the various actions you could do
>> against it. Then you would CALL that module and pass a data buffer
>> and the action you required, it would do the action and return the
>> updated buffer, along with a status code.
>>
>> Can you imagine the number of lines of source code this approach
>> would save if you had, say, 50 programs all using the same file?
>> <SNIP>
>
> Pete,
>
> I enjoyed your post, but I am confused about one thing. If you have
> 50 programs all calling the same file-access subprogram, what do they
> use for the record layout of the returned buffer? How do you avoid
> using a copybook for that?
block which also contains control and status information.). If the access
interface is generated (as mine invariably is) then you don't need a COPY
book because the interface is inserted into your program by a transformation
process. (The GENERATOR has access to a base copy which is always the same
in every program using that interface). The SAME Transformation process also
inserts the actual code you need to access the "file-access subprogram".
But you were right; because of the way I have become accustomed to working,
I had overlooked that COBOL needs that buffer defined and COPY is the
accepted way to do that.
It is not a serious issue for me and I just wanted to point out that life
can continue without it. If it makes people think a bit more (even if they
vehemenetly disagree) then the post was worth making.
I don't use it myself and I honestly believe it causes far more trouble than
it is worth (see your points above), but that is just my opinion.
>
> It is certainly possible to write COBOL programs without using
> available copybooks. I have done that, but generally for throwaway
> programs. In a production program I would use the copybook, because
> it is relatively easy to scan the library for all programs that use a
> particular copybook. It helps identify the impact of a proposed
> change.
> Kind regards,
Thanks for the response,
> It is certainly possible to write COBOL programs without using
> available copybooks. I have done that, but generally for throwaway
> programs. In a production program I would use the copybook, because
> it is relatively easy to scan the library for all programs that use a
> particular copybook. It helps identify the impact of a proposed
> change.
> Kind regards,
Pete Dashwood
Apr 13, 2013, 8:09:13 PM4/13/13
to
Pete Dashwood
Apr 13, 2013, 8:12:47 PM4/13/13
to
COBOL source deck would be around 3000 cards. You would think twice about
something that took 30 minutes, and within a day or two would need redoing.
Pete Dashwood
Apr 13, 2013, 8:16:23 PM4/13/13
to
whether I have a "sheltered coding life" (whatever that means; I would bet I
have had at least as much experience writing COBOL as you have). We use
different approaches, that's all.
Pete
Pete Dashwood
Apr 13, 2013, 8:31:01 PM4/13/13
to
IBM had a similar ENTER BAL (I think... not sure about that one), and
Burroughs used ENTER ASSEMBLER...
And you are right that we used these facilities in the same way we would use
CALL when it became available. In particular, when disk drives first became
available, the ONLY way to use them on ICL equipment was by using the
provided PLAN routines, with ENTER PLAN.
>
> In order to ensure that the CALLer and the CALLed have consistent
> record layouts in the data buffers then they should use COPY.
>
> Most programming languages have a COPY like facility, it is 'import'
> or 'use' or '#include'.
>
you would understand why.
>
>
>> (Even in the COBOL I have written over the past 20 years, I have not
>> had occasion to use COPY...)
>>
>> The proper place for COPY is in Legacy code and as that gets phased
>> out, so should the need for COPY.
>>
>> Pete.
>> --
>> "I used to write COBOL...now I can do anything."
The point I was trying to explore is not about COPY (that's just an example
>
>> (Even in the COBOL I have written over the past 20 years, I have not
>> had occasion to use COPY...)
>>
>> The proper place for COPY is in Legacy code and as that gets phased
>> out, so should the need for COPY.
>>
>> Pete.
>> --
>> "I used to write COBOL...now I can do anything."
of it, from COBOL). Rather, it is about the whole IDEA of duplicating
something in code.
BECAUSE this is facilitated (through mechanisms like COPY), programmers go
right ahead and do it.
My argument is that they probably shouldn't and there should be better ways
to achieve the result of propagating the same structure and functionality
into different places where it is needed..
I know you are a fan of templates, and I agree with that approach. If you
extend that to have the templates automatically updated, you may not need to
use a COPY.
Clark F Morris
Apr 13, 2013, 9:09:04 PM4/13/13
to
recompile all afflicted/oops affected programs.
Clark Morris
>
>Pete.
Alistair Maclean
Apr 14, 2013, 3:38:46 PM4/14/13
to
On Sunday, 14 April 2013 01:09:13 UTC+1, Pete Dashwood wrote:
> Why not use Cut & Paste? :-)
Sacrilige (other spellings are available).
> Why not use Cut & Paste? :-)
Richard
Apr 14, 2013, 3:57:22 PM4/14/13
to
On 14 Apr, 12:31, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
wrote:
> > The CALL statement wasn't part of COBOL until the '74 standard.
> > Earlier ICL COBOL compilers used ENTER to call library routines but
> > these were bound into the executable at compile time.
>
> Yes, I remember ENTER PLAN on 1900s and used it for some years.
>
> IBM had a similar ENTER BAL (I think... not sure about that one), and
> Burroughs used ENTER ASSEMBLER...
>
> And you are right that we used these facilities in the same way we would use
> CALL when it became available. In particular, when disk drives first became
> available, the ONLY way to use them on ICL equipment was by using the
> provided PLAN routines, with ENTER PLAN.
The original intent of the ENTER statement in COBOL was to allow
inline assembler:
some cobol
ENTER language
some language code
ENTER COBOL
more cobol code
ICL didn't do that. It used it like a call. You could call routines in
PLAN, FORTRAN or Algol and write your own routines in these. Mostly
though it was used to call DAHousekeeping (Direct Access ie Disks) in
the days before the compiler had DISK as an option in the SELECT.
All the routines and the libraries for the appropriate languages had
to be linked into the executable before it could be run.
> > In order to ensure that the CALLer and the CALLed have consistent
> > record layouts in the data buffers then they should use COPY.
>
> > Most programming languages have a COPY like facility, it is 'import'
> > or 'use' or '#include'.
>
> Yes, I know. That isn't the point.
>
> >> Can you imagine the number of lines of source code this approach
> >> would save if you had, say, 50 programs all using the same file?
>
> > Approximately NONE.
I should clarify that point. In the case of having called routines it
will use a CALL instead of an OPEN, a CALL instead of a READ, a CALL
instead of a WRITE, etc. Both will use a COPY, in one for the FD, in
the other for the call's record buffer.
> >> Given the above, I contend that COPY really has no place in modern
> >> programming and is obsolete.
>
> > I don't know what C# uses for 'import' but it will be a synonym for
> > COPY.
>
> I don't use it. And have never needed to. If you got the point of this post
> you would understand why.
In Java the 'import java.io.*;', and similar, bring in the namespace
of the system routines so that the compiler can check the types of the
attributes and the availability of the methods. In C it is '#include
<stdlib.h>' and such.
In C# the 'using' keyword does much the same. Typically, it seems, a
typical C# program will start with:
using System;
using System.IO;
using System.xml;
which will _COPY_ in the namespaces of those classes.
> >> (Even in the COBOL I have written over the past 20 years, I have not
> >> had occasion to use COPY...)
>
> >> The proper place for COPY is in Legacy code and as that gets phased
> >> out, so should the need for COPY.
have been specific about that instead of a blanket rant about COPY.
COPY is used to ensure that the FDs are identical in all programs, and
for CALLed routines, that linkage section is consistent with the
caller's parameters. This does not 'duplicate code', it reduces the
source code required and ensures that it is correct. It is easy to add
the COPYed files to the dependencies of the programs that use them so
that programs are automatically recompiled if the data is changed.
> My argument is that they probably shouldn't and there should be better ways
> to achieve the result of propagating the same structure and functionality
> into different places where it is needed..
> I know you are a fan of templates, and I agree with that approach. If you
> extend that to have the templates automatically updated, you may not need to
> use a COPY.
Templates have nothing to do with COPY*. They are text files: HTML
fragments, Postscript, or plain text; where the templating routine
merges the data into the text.
The COBOL programs that CALL the templating routine have a COPY for
the data structure that is used in the CALL, there is a COPY for that
in the LINKAGE SECTION of the templating program. This file is a
dependency of the program so if I were to extend the data structure
the programs that CALL templating will be recompiled rather than
failing.
* My templates typically have an INSERT facility that allows common
code, such as HTML headers and trailers to be included without having
to duplicate the code in every template.
wrote:
> > The CALL statement wasn't part of COBOL until the '74 standard.
> > Earlier ICL COBOL compilers used ENTER to call library routines but
> > these were bound into the executable at compile time.
>
> Yes, I remember ENTER PLAN on 1900s and used it for some years.
>
> IBM had a similar ENTER BAL (I think... not sure about that one), and
> Burroughs used ENTER ASSEMBLER...
>
> And you are right that we used these facilities in the same way we would use
> CALL when it became available. In particular, when disk drives first became
> available, the ONLY way to use them on ICL equipment was by using the
> provided PLAN routines, with ENTER PLAN.
inline assembler:
some cobol
ENTER language
some language code
ENTER COBOL
more cobol code
ICL didn't do that. It used it like a call. You could call routines in
PLAN, FORTRAN or Algol and write your own routines in these. Mostly
though it was used to call DAHousekeeping (Direct Access ie Disks) in
the days before the compiler had DISK as an option in the SELECT.
All the routines and the libraries for the appropriate languages had
to be linked into the executable before it could be run.
> > In order to ensure that the CALLer and the CALLed have consistent
> > record layouts in the data buffers then they should use COPY.
>
> > Most programming languages have a COPY like facility, it is 'import'
> > or 'use' or '#include'.
>
> Yes, I know. That isn't the point.
>
> >> Can you imagine the number of lines of source code this approach
> >> would save if you had, say, 50 programs all using the same file?
>
> > Approximately NONE.
will use a CALL instead of an OPEN, a CALL instead of a READ, a CALL
instead of a WRITE, etc. Both will use a COPY, in one for the FD, in
the other for the call's record buffer.
> >> Given the above, I contend that COPY really has no place in modern
> >> programming and is obsolete.
>
> > I don't know what C# uses for 'import' but it will be a synonym for
> > COPY.
>
> I don't use it. And have never needed to. If you got the point of this post
> you would understand why.
of the system routines so that the compiler can check the types of the
attributes and the availability of the methods. In C it is '#include
<stdlib.h>' and such.
In C# the 'using' keyword does much the same. Typically, it seems, a
typical C# program will start with:
using System;
using System.IO;
using System.xml;
which will _COPY_ in the namespaces of those classes.
> >> (Even in the COBOL I have written over the past 20 years, I have not
> >> had occasion to use COPY...)
>
> >> The proper place for COPY is in Legacy code and as that gets phased
> >> out, so should the need for COPY.
> The point I was trying to explore is not about COPY (that's just an example
> of it, from COBOL). Rather, it is about the whole IDEA of duplicating
> something in code.
>
> BECAUSE this is facilitated (through mechanisms like COPY), programmers go
> right ahead and do it.
If you wanted to discuss COPY of procedure division then you should
> of it, from COBOL). Rather, it is about the whole IDEA of duplicating
> something in code.
>
> BECAUSE this is facilitated (through mechanisms like COPY), programmers go
> right ahead and do it.
have been specific about that instead of a blanket rant about COPY.
COPY is used to ensure that the FDs are identical in all programs, and
for CALLed routines, that linkage section is consistent with the
caller's parameters. This does not 'duplicate code', it reduces the
source code required and ensures that it is correct. It is easy to add
the COPYed files to the dependencies of the programs that use them so
that programs are automatically recompiled if the data is changed.
> My argument is that they probably shouldn't and there should be better ways
> to achieve the result of propagating the same structure and functionality
> into different places where it is needed..
> I know you are a fan of templates, and I agree with that approach. If you
> extend that to have the templates automatically updated, you may not need to
> use a COPY.
fragments, Postscript, or plain text; where the templating routine
merges the data into the text.
The COBOL programs that CALL the templating routine have a COPY for
the data structure that is used in the CALL, there is a COPY for that
in the LINKAGE SECTION of the templating program. This file is a
dependency of the program so if I were to extend the data structure
the programs that CALL templating will be recompiled rather than
failing.
* My templates typically have an INSERT facility that allows common
code, such as HTML headers and trailers to be included without having
to duplicate the code in every template.
Richard
Apr 14, 2013, 6:05:15 PM4/14/13
to
On Apr 14, 12:07 pm, "Pete Dashwood"
So, what you are saying now is that you don't use the built-in COBOL
COPY pre-processing statement because you have your own pre-processor/
generator that inserts the code into the program source in a way that
others use COPY to do so.
I have code generators. I built one to take in text screen layouts and
field descriptions and create data and code for the ACCEPTs and
DISPLAYs using ADIS (I dislike SCREEN SECTION). I could have had the
generator read the complete program source and output a new source
file but it was more convenient to separate the generated code from
the program source that will use it and have this with COPY statements
that read the generated source code.
It is simply an issue of whether the copying is done with the standard
compiler facilities or by writing your own copying routines.
BTW: The only compiled language that deliberately avoided having a
'copy' facility was Wirth's original Pascal (Algol-68W). He wanted it
so that _all_ the program's source code was in the one source file. Of
course all implementations other than his had some form of COPY
facility.
COPY pre-processing statement because you have your own pre-processor/
generator that inserts the code into the program source in a way that
others use COPY to do so.
I have code generators. I built one to take in text screen layouts and
field descriptions and create data and code for the ACCEPTs and
DISPLAYs using ADIS (I dislike SCREEN SECTION). I could have had the
generator read the complete program source and output a new source
file but it was more convenient to separate the generated code from
the program source that will use it and have this with COPY statements
that read the generated source code.
It is simply an issue of whether the copying is done with the standard
compiler facilities or by writing your own copying routines.
BTW: The only compiled language that deliberately avoided having a
'copy' facility was Wirth's original Pascal (Algol-68W). He wanted it
so that _all_ the program's source code was in the one source file. Of
course all implementations other than his had some form of COPY
facility.
Pete Dashwood
Apr 14, 2013, 8:50:49 PM4/14/13
to
Richard wrote:
> On 14 Apr, 12:31, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
> wrote:
>
>
> I should clarify that point. In the case of having called routines it
> will use a CALL instead of an OPEN, a CALL instead of a READ, a CALL
> instead of a WRITE, etc. Both will use a COPY, in one for the FD, in
> the other for the call's record buffer.
>
Not the way I do it. The called routine doesn't contain a COPY. The code is
> On 14 Apr, 12:31, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
> wrote:
>
>
> I should clarify that point. In the case of having called routines it
> will use a CALL instead of an OPEN, a CALL instead of a READ, a CALL
> instead of a WRITE, etc. Both will use a COPY, in one for the FD, in
> the other for the call's record buffer.
>
embedded in it and it COULD contain a COPY, but it doesn't.
>
>>>> Given the above, I contend that COPY really has no place in modern
>>>> programming and is obsolete.
>>
>>> I don't know what C# uses for 'import' but it will be a synonym for
>>> COPY.
>>
>> I don't use it. And have never needed to. If you got the point of
>> this post you would understand why.
>
A "using" statement in C# doesn't COPY anything. It makes a connection to
>>>> Given the above, I contend that COPY really has no place in modern
>>>> programming and is obsolete.
>>
>>> I don't know what C# uses for 'import' but it will be a synonym for
>>> COPY.
>>
>> I don't use it. And have never needed to. If you got the point of
>> this post you would understand why.
>
the specified namespace.
> In Java the 'import java.io.*;', and similar, bring in the namespace
> of the system routines so that the compiler can check the types of the
> attributes and the availability of the methods. In C it is '#include
> <stdlib.h>' and such.
>
> In C# the 'using' keyword does much the same. Typically, it seems, a
> typical C# program will start with:
>
> using System;
> using System.IO;
> using System.xml;
>
> which will _COPY_ in the namespaces of those classes.
those namespaces is included in your program. (It is actually in the .Net
Framework so it doesn't NEED to be COPYed.)
>
>> The point I was trying to explore is not about COPY (that's just an
>> example of it, from COBOL). Rather, it is about the whole IDEA of
>> duplicating something in code.
>>
>> BECAUSE this is facilitated (through mechanisms like COPY),
>> programmers go right ahead and do it.
>
> If you wanted to discuss COPY of procedure division then you should
> have been specific about that instead of a blanket rant about COPY.
I can discuss anything I like without permission from you and I can be
>> The point I was trying to explore is not about COPY (that's just an
>> example of it, from COBOL). Rather, it is about the whole IDEA of
>> duplicating something in code.
>>
>> BECAUSE this is facilitated (through mechanisms like COPY),
>> programmers go right ahead and do it.
>
> If you wanted to discuss COPY of procedure division then you should
> have been specific about that instead of a blanket rant about COPY.
specific or general about it. There was no "rant" because I really don't
care what people do. I explained in my OP how a separate thread simply made
me wonder why I don't care. During the course of that I posted somethng that
might have made a few people think about the whole issue of duplicated code
in programs. It is worth thinking about.
Certainly, some of the responses (not yours) made me think further about it.
Whatever conclusion you reach is fine by me. Use COPY or don't use it; it
has no bearing on what I ACTUALLY do.
Richard
Apr 14, 2013, 10:19:15 PM4/14/13
to
On Apr 15, 12:50 pm, "Pete Dashwood"
the equivalent of generating a file and having a COPY in the target
program is because your generate program does that code merge
directly.
> >>>> Given the above, I contend that COPY really has no place in modern
> >>>> programming and is obsolete.
>
> >>> I don't know what C# uses for 'import' but it will be a synonym for
> >>> COPY.
>
> >> I don't use it. And have never needed to. If you got the point of
> >> this post you would understand why.
>
> A "using" statement in C# doesn't COPY anything. It makes a connection to
> the specified namespace.
> > In Java the 'import java.io.*;', and similar, bring in the namespace
> > of the system routines so that the compiler can check the types of the
> > attributes and the availability of the methods. In C it is '#include
> > <stdlib.h>' and such.
>
> > In C# the 'using' keyword does much the same. Typically, it seems, a
> > typical C# program will start with:
>
> > using System;
> > using System.IO;
> > using System.xml;
>
> > which will _COPY_ in the namespaces of those classes.
>
> No, it WON'T. It will bind to them. Neither the source nor the object of
> those namespaces is included in your program. (It is actually in the .Net
> Framework so it doesn't NEED to be COPYed.)
A COPY of an FD or in LINKAGE SECTION could also just include the
'namespace' and (depending on the system) need not create a data area
in the object program. The actual data is in the filesystem library
(in the case of an FD) or in the calling program.
Using the same copybook for the calling and the called program ensures
consistency. I could create a pre-processor that could could read the
called program source code (where available) and extract the linkage
section and include it in the working-storage of the program being
processed. That would avoid the COPY statement but retain the required
functionality.
> >> The point I was trying to explore is not about COPY (that's just an
> >> example of it, from COBOL). Rather, it is about the whole IDEA of
> >> duplicating something in code.
>
> >> BECAUSE this is facilitated (through mechanisms like COPY),
> >> programmers go right ahead and do it.
COPY is there to _avoid_ having duplicate source code. In particular
having one place where an FD or a data structure is defined no matter
how many programs use it.
And, if there are two programs that go through your generator has some
reference to the same 'file' (or table), does it generate the _same_
source code for those table columns ? Does it actually create
_duplicate_ code (at least for the interface data) ?
<dashw...@removethis.enternet.co.nz> wrote:
> Richard wrote:
> > On 14 Apr, 12:31, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
> > wrote:
>
> > I should clarify that point. In the case of having called routines it
> > will use a CALL instead of an OPEN, a CALL instead of a READ, a CALL
> > instead of a WRITE, etc. Both will use a COPY, in one for the FD, in
> > the other for the call's record buffer.
>
> Not the way I do it. The called routine doesn't contain a COPY. The code is
> embedded in it and it COULD contain a COPY, but it doesn't.
It seems that the reason there is no COPY is that your program does
> Richard wrote:
> > On 14 Apr, 12:31, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
> > wrote:
>
> > I should clarify that point. In the case of having called routines it
> > will use a CALL instead of an OPEN, a CALL instead of a READ, a CALL
> > instead of a WRITE, etc. Both will use a COPY, in one for the FD, in
> > the other for the call's record buffer.
>
> Not the way I do it. The called routine doesn't contain a COPY. The code is
> embedded in it and it COULD contain a COPY, but it doesn't.
the equivalent of generating a file and having a COPY in the target
program is because your generate program does that code merge
directly.
> >>>> Given the above, I contend that COPY really has no place in modern
> >>>> programming and is obsolete.
>
> >>> I don't know what C# uses for 'import' but it will be a synonym for
> >>> COPY.
>
> >> I don't use it. And have never needed to. If you got the point of
> >> this post you would understand why.
>
> A "using" statement in C# doesn't COPY anything. It makes a connection to
> the specified namespace.
> > In Java the 'import java.io.*;', and similar, bring in the namespace
> > of the system routines so that the compiler can check the types of the
> > attributes and the availability of the methods. In C it is '#include
> > <stdlib.h>' and such.
>
> > In C# the 'using' keyword does much the same. Typically, it seems, a
> > typical C# program will start with:
>
> > using System;
> > using System.IO;
> > using System.xml;
>
> > which will _COPY_ in the namespaces of those classes.
>
> No, it WON'T. It will bind to them. Neither the source nor the object of
> those namespaces is included in your program. (It is actually in the .Net
> Framework so it doesn't NEED to be COPYed.)
'namespace' and (depending on the system) need not create a data area
in the object program. The actual data is in the filesystem library
(in the case of an FD) or in the calling program.
Using the same copybook for the calling and the called program ensures
consistency. I could create a pre-processor that could could read the
called program source code (where available) and extract the linkage
section and include it in the working-storage of the program being
processed. That would avoid the COPY statement but retain the required
functionality.
> >> The point I was trying to explore is not about COPY (that's just an
> >> example of it, from COBOL). Rather, it is about the whole IDEA of
> >> duplicating something in code.
>
> >> BECAUSE this is facilitated (through mechanisms like COPY),
> >> programmers go right ahead and do it.
having one place where an FD or a data structure is defined no matter
how many programs use it.
And, if there are two programs that go through your generator has some
reference to the same 'file' (or table), does it generate the _same_
source code for those table columns ? Does it actually create
_duplicate_ code (at least for the interface data) ?
Arnold Trembley
Apr 16, 2013, 2:57:33 AM4/16/13
to
On 4/13/2013 7:09 PM, Pete Dashwood wrote:
> Alistair Maclean wrote:
>> (SNIP)
code re-use. Unlike COPY, you cannot pick up a new version with a
recompile, but you also avoid the version control issues associated with
COPY. It's very similar to cloning a COBOL program.
It might not be as sophisticated as calling a dynamically loaded
subprogram, or re-using an object, but it still saves some work.
--
http://www.arnoldtrembley.com/
> Alistair Maclean wrote:
>> (SNIP)
>>
>> I am happy using COPY on my hobby database as it allows me to
>> modularise and more easily develop/maintain a modelling program that
>> I am experimenting with. I even use the COPY for SELECTS, FDs,
>> working storage and procedure code. Bliss.
>
> Why not use Cut & Paste? :-)
>
> Pete.
>
There's no need for a smiley. Cut & paste is a perfectly valid form of
>> I am happy using COPY on my hobby database as it allows me to
>> modularise and more easily develop/maintain a modelling program that
>> I am experimenting with. I even use the COPY for SELECTS, FDs,
>> working storage and procedure code. Bliss.
>
> Why not use Cut & Paste? :-)
>
> Pete.
>
code re-use. Unlike COPY, you cannot pick up a new version with a
recompile, but you also avoid the version control issues associated with
COPY. It's very similar to cloning a COBOL program.
It might not be as sophisticated as calling a dynamically loaded
subprogram, or re-using an object, but it still saves some work.
--
http://www.arnoldtrembley.com/
Pete Dashwood
Apr 16, 2013, 4:50:56 AM4/16/13
to
OK, I stand chastised... :-)
The original comment was tongue-in-cheek but I take your point.
There are so many problems inherent in using COPY (as was pointed out
previously regarding test and production library versions etc. and trying to
control it where many people are using it in different programs at the same
time) I'm tempted to think Cut & Paste MIGHT be better...
Another thing I hate about COPY is when people send me code for help, and
completely forget that without all the COPY books I simply can't even
compile it. I ask for the COPY books and get a ZIP file that doesn't match
what they are using. I've had occasions where a complete solution was
provided to them after several days work, but it was useless because of
wrong COPY books.
Then there is the cryptic Fujitsu message about the COPY library being not
properly constructed or defined (when it is perfectly OK).
Not to mention that over 90% of the problems we have when migrating people
is caused by bad COPY book definitions. You can save days of work just by
getting the COPY books compliant with the standard...(ensuring group fields,
REDEFINES, OCCURS etc are legal. It is quite amazing how many source books
we get that are not.)
But I sound like I'm ranting so I better stop.
At least when you look at our generated code it contains the expanded COPY
book that was used. It is deliberately hard coded. This is a check so you
can see exactly which definitions were used to build your database and to
generate the access against it. It CAN'T change because someone changed a
COPY book somewhere.
(If it does HAVE to change, it is a matter of seconds to regenerate the
Table Set on the RDB and the COM component/interface block that manages it
in the DAL layer. The new interface needs to be recompiled into the affected
application programs and this means re-running them through Transformation.
(That could take a few minutes if there are a number of programs. Another
way to do it is to simply make the new interface a COPY book (if you
normally use COPY) and just recompile the affected, already Transformed,
programs.)
As a general rule, it is good not to mess with COPY books any more than you
absolutely have to.
Richard
Apr 16, 2013, 5:26:12 PM4/16/13
to
On Apr 16, 8:50 pm, "Pete Dashwood"
paste' that should be used.
The problem with using 'copy&paste' is that if there is a change
required then it must be tracked down in _every_ program that this was
pasted into.
From earlier:
""" The point I was trying to explore is not about COPY (that's just
an example
of it, from COBOL). Rather, it is about the whole IDEA of duplicating
something in code.
BECAUSE this is facilitated (through mechanisms like COPY),
programmers go
right ahead and do it.
you advocate duplicating code.
If you have a problem with alleged 'VCS issues' then maybe you are
using the wrong VCS. I like Bazaar.
> > It might not be as sophisticated as calling a dynamically loaded
> > subprogram, or re-using an object, but it still saves some work.:-)
>
> OK, I stand chastised... :-)
>
> The original comment was tongue-in-cheek but I take your point.
>
> There are so many problems inherent in using COPY (as was pointed out
> previously regarding test and production library versions etc. and trying to
> control it where many people are using it in different programs at the same
> time) I'm tempted to think Cut & Paste MIGHT be better...
You did mention the problems associated with using card packs, yes.
Copybooks, especially FDs and Linkage areas, and even WS data
structures, must be put under special control, such as a db admin.
> Another thing I hate about COPY is when people send me code for help, and
> completely forget that without all the COPY books I simply can't even
> compile it. I ask for the COPY books and get a ZIP file that doesn't match
> what they are using. I've had occasions where a complete solution was
> provided to them after several days work, but it was useless because of
> wrong COPY books.
I suspect that 'when people send me code for help' is because they no
longer have anyone who knows anything at all about the system. Either
because the programmers have left or because it has been ignored for
many years. I get systems like that handed to me too.
> Then there is the cryptic Fujitsu message about the COPY library being not
> properly constructed or defined (when it is perfectly OK).
I have never seen that.
> Not to mention that over 90% of the problems we have when migrating people
> is caused by bad COPY book definitions. You can save days of work just by
> getting the COPY books compliant with the standard...(ensuring group fields,
> REDEFINES, OCCURS etc are legal. It is quite amazing how many source books
> we get that are not.)
That doesn't seem special to copybooks, bad code can be anywhere. How
would 'copy & paste' from the copybook directly into the program
source magically make it better code ?
> But I sound like I'm ranting so I better stop.
>
> At least when you look at our generated code it contains the expanded COPY
> book that was used. It is deliberately hard coded. This is a check so you
> can see exactly which definitions were used to build your database and to
> generate the access against it. It CAN'T change because someone changed a
> COPY book somewhere.
That 'someone' can change program code too.
<dashw...@removethis.enternet.co.nz> wrote:
> Arnold Trembley wrote:
> > On 4/13/2013 7:09 PM, Pete Dashwood wrote:
> >> Alistair Maclean wrote:
> >>> (SNIP)
>
> >>> I am happy using COPY on my hobby database as it allows me to
> >>> modularise and more easily develop/maintain a modelling program that
> >>> I am experimenting with. I even use the COPY for SELECTS, FDs,
> >>> working storage and procedure code. Bliss.
>
> >> Why not use Cut & Paste? :-)
>
> >> Pete.
>
> > There's no need for a smiley. Cut & paste is a perfectly valid form
> > of code re-use. Unlike COPY, you cannot pick up a new version with a
> > recompile, but you also avoid the version control issues associated
> > with COPY. It's very similar to cloning a COBOL program.
While 'cut & paste' may be the generic term, it is actually 'copy &
> Arnold Trembley wrote:
> > On 4/13/2013 7:09 PM, Pete Dashwood wrote:
> >> Alistair Maclean wrote:
> >>> (SNIP)
>
> >>> I am happy using COPY on my hobby database as it allows me to
> >>> modularise and more easily develop/maintain a modelling program that
> >>> I am experimenting with. I even use the COPY for SELECTS, FDs,
> >>> working storage and procedure code. Bliss.
>
> >> Why not use Cut & Paste? :-)
>
> >> Pete.
>
> > There's no need for a smiley. Cut & paste is a perfectly valid form
> > of code re-use. Unlike COPY, you cannot pick up a new version with a
> > recompile, but you also avoid the version control issues associated
> > with COPY. It's very similar to cloning a COBOL program.
paste' that should be used.
The problem with using 'copy&paste' is that if there is a change
required then it must be tracked down in _every_ program that this was
pasted into.
From earlier:
""" The point I was trying to explore is not about COPY (that's just
an example
of it, from COBOL). Rather, it is about the whole IDEA of duplicating
something in code.
BECAUSE this is facilitated (through mechanisms like COPY),
programmers go
right ahead and do it.
My argument is that they probably shouldn't and there should be better
ways
to achieve the result of propagating the same structure and
functionality
into different places where it is needed.."""
So first you argued that duplicating code shouldn't be done, and now
ways
to achieve the result of propagating the same structure and
functionality
into different places where it is needed.."""
you advocate duplicating code.
If you have a problem with alleged 'VCS issues' then maybe you are
using the wrong VCS. I like Bazaar.
> > It might not be as sophisticated as calling a dynamically loaded
> > subprogram, or re-using an object, but it still saves some work.:-)
>
> OK, I stand chastised... :-)
>
> The original comment was tongue-in-cheek but I take your point.
>
> There are so many problems inherent in using COPY (as was pointed out
> previously regarding test and production library versions etc. and trying to
> control it where many people are using it in different programs at the same
> time) I'm tempted to think Cut & Paste MIGHT be better...
Copybooks, especially FDs and Linkage areas, and even WS data
structures, must be put under special control, such as a db admin.
> Another thing I hate about COPY is when people send me code for help, and
> completely forget that without all the COPY books I simply can't even
> compile it. I ask for the COPY books and get a ZIP file that doesn't match
> what they are using. I've had occasions where a complete solution was
> provided to them after several days work, but it was useless because of
> wrong COPY books.
longer have anyone who knows anything at all about the system. Either
because the programmers have left or because it has been ignored for
many years. I get systems like that handed to me too.
> Then there is the cryptic Fujitsu message about the COPY library being not
> properly constructed or defined (when it is perfectly OK).
> Not to mention that over 90% of the problems we have when migrating people
> is caused by bad COPY book definitions. You can save days of work just by
> getting the COPY books compliant with the standard...(ensuring group fields,
> REDEFINES, OCCURS etc are legal. It is quite amazing how many source books
> we get that are not.)
would 'copy & paste' from the copybook directly into the program
source magically make it better code ?
> But I sound like I'm ranting so I better stop.
>
> At least when you look at our generated code it contains the expanded COPY
> book that was used. It is deliberately hard coded. This is a check so you
> can see exactly which definitions were used to build your database and to
> generate the access against it. It CAN'T change because someone changed a
> COPY book somewhere.
Pete Dashwood
Apr 16, 2013, 6:35:10 PM4/16/13
to
Richard wrote:
> On Apr 16, 8:50 pm, "Pete Dashwood"
> <dashw...@removethis.enternet.co.nz> wrote:
>> Arnold Trembley wrote:
>>> On 4/13/2013 7:09 PM, Pete Dashwood wrote:
>>>> Alistair Maclean wrote:
>>>>> (SNIP)
>>
>>>>> I am happy using COPY on my hobby database as it allows me to
>>>>> modularise and more easily develop/maintain a modelling program
>>>>> that I am experimenting with. I even use the COPY for SELECTS,
>>>>> FDs, working storage and procedure code. Bliss.
>>
>>>> Why not use Cut & Paste? :-)
>>
>>>> Pete.
>>
>>> There's no need for a smiley. Cut & paste is a perfectly valid form
>>> of code re-use. Unlike COPY, you cannot pick up a new version with a
>>> recompile, but you also avoid the version control issues associated
>>> with COPY. It's very similar to cloning a COBOL program.
>
> While 'cut & paste' may be the generic term, it is actually 'copy &
> paste' that should be used.
>
Correct.
> On Apr 16, 8:50 pm, "Pete Dashwood"
> <dashw...@removethis.enternet.co.nz> wrote:
>> Arnold Trembley wrote:
>>> On 4/13/2013 7:09 PM, Pete Dashwood wrote:
>>>> Alistair Maclean wrote:
>>>>> (SNIP)
>>
>>>>> I am happy using COPY on my hobby database as it allows me to
>>>>> modularise and more easily develop/maintain a modelling program
>>>>> that I am experimenting with. I even use the COPY for SELECTS,
>>>>> FDs, working storage and procedure code. Bliss.
>>
>>>> Why not use Cut & Paste? :-)
>>
>>>> Pete.
>>
>>> There's no need for a smiley. Cut & paste is a perfectly valid form
>>> of code re-use. Unlike COPY, you cannot pick up a new version with a
>>> recompile, but you also avoid the version control issues associated
>>> with COPY. It's very similar to cloning a COBOL program.
>
> While 'cut & paste' may be the generic term, it is actually 'copy &
> paste' that should be used.
>
But we are having a friendly discussion. Everyone concerned knows what is
meant.
> The problem with using 'copy&paste' is that if there is a change
> required then it must be tracked down in _every_ program that this was
> pasted into.
"Tracking things down in programs", using modern tools, is really no big
deal, though.
>
> From earlier:
>
> """ The point I was trying to explore is not about COPY (that's just
> an example
> of it, from COBOL). Rather, it is about the whole IDEA of duplicating
> something in code.
>
> BECAUSE this is facilitated (through mechanisms like COPY),
> programmers go
> right ahead and do it.
>
> My argument is that they probably shouldn't and there should be better
> ways
> to achieve the result of propagating the same structure and
> functionality
> into different places where it is needed.."""
>
> So first you argued that duplicating code shouldn't be done, and now
> you advocate duplicating code.
pedantic mind. Someone incapable of seeing shades of grey and being unable
to adopt different positions for the sake of discussion?
I'm not "advocating" anything. I would need to care in order to do that and
I already explained that I actually don't.
However, there s nothing wrong with exlorring some of the implications of
points raised, in the form of a general argument.
>
>
> If you have a problem with alleged 'VCS issues' then maybe you are
> using the wrong VCS. I like Bazaar.
the programming team at PRIMA is not so large that we can't talk to each
other.
Besides, I don't use COPY so that particular versioning trap simply doesn't
arise.
>
>
>>> It might not be as sophisticated as calling a dynamically loaded
>>> subprogram, or re-using an object, but it still saves some work.:-)
>>
>> OK, I stand chastised... :-)
>>
>> The original comment was tongue-in-cheek but I take your point.
>>
>> There are so many problems inherent in using COPY (as was pointed out
>> previously regarding test and production library versions etc. and
>> trying to control it where many people are using it in different
>> programs at the same time) I'm tempted to think Cut & Paste MIGHT be
>> better...
>
> You did mention the problems associated with using card packs, yes.
> Copybooks, especially FDs and Linkage areas, and even WS data
> structures, must be put under special control, such as a db admin.
I would agree it is good if they are, but I think "must" is too strong. It
>
>>> It might not be as sophisticated as calling a dynamically loaded
>>> subprogram, or re-using an object, but it still saves some work.:-)
>>
>> OK, I stand chastised... :-)
>>
>> The original comment was tongue-in-cheek but I take your point.
>>
>> There are so many problems inherent in using COPY (as was pointed out
>> previously regarding test and production library versions etc. and
>> trying to control it where many people are using it in different
>> programs at the same time) I'm tempted to think Cut & Paste MIGHT be
>> better...
>
> You did mention the problems associated with using card packs, yes.
> Copybooks, especially FDs and Linkage areas, and even WS data
> structures, must be put under special control, such as a db admin.
depends on the size of the team.
>
>
>> Another thing I hate about COPY is when people send me code for
>> help, and completely forget that without all the COPY books I simply
>> can't even compile it. I ask for the COPY books and get a ZIP file
>> that doesn't match what they are using. I've had occasions where a
>> complete solution was provided to them after several days work, but
>> it was useless because of wrong COPY books.
>
> I suspect that 'when people send me code for help' is because they no
> longer have anyone who knows anything at all about the system. Either
> because the programmers have left or because it has been ignored for
> many years. I get systems like that handed to me too.
>
I can assure you that some very competent people who really DO know what
>
>> Another thing I hate about COPY is when people send me code for
>> help, and completely forget that without all the COPY books I simply
>> can't even compile it. I ask for the COPY books and get a ZIP file
>> that doesn't match what they are using. I've had occasions where a
>> complete solution was provided to them after several days work, but
>> it was useless because of wrong COPY books.
>
> I suspect that 'when people send me code for help' is because they no
> longer have anyone who knows anything at all about the system. Either
> because the programmers have left or because it has been ignored for
> many years. I get systems like that handed to me too.
>
they are doing sometimes send me code to confirm whether it is system
software or their application causing a problem. Mostly this is in the area
of PowerCOBOL, where support has been poor and a lot goes on "under the
covers". It has become less frequent lately and I think this is because more
and more people are moving off PowerCOBOL and also because the support from
offical vendors has improved. It is still annoying when they nforget the
COPY books, and that was my point.
>
>> Then there is the cryptic Fujitsu message about the COPY library
>> being not properly constructed or defined (when it is perfectly OK).
>
> I have never seen that.
Be thankful... :-)
>> Then there is the cryptic Fujitsu message about the COPY library
>> being not properly constructed or defined (when it is perfectly OK).
>
> I have never seen that.
>
>> Not to mention that over 90% of the problems we have when migrating
>> people is caused by bad COPY book definitions. You can save days of
>> work just by getting the COPY books compliant with the
>> standard...(ensuring group fields, REDEFINES, OCCURS etc are legal.
>> It is quite amazing how many source books we get that are not.)
>
> That doesn't seem special to copybooks, bad code can be anywhere.
Yes, it can. But for us the COPY books from Clients are critical because
>> Not to mention that over 90% of the problems we have when migrating
>> people is caused by bad COPY book definitions. You can save days of
>> work just by getting the COPY books compliant with the
>> standard...(ensuring group fields, REDEFINES, OCCURS etc are legal.
>> It is quite amazing how many source books we get that are not.)
>
> That doesn't seem special to copybooks, bad code can be anywhere.
their data repository will be generated from an analysis of it. Most of the
time, it is problems with old Legacy COBOL definitions that get spat out by
the CreateTables tool. If the Source Sets (SELECTs and FDs) are of good
quality and '85 standard compliant, data conversion goes like a dream.
>How
> would 'copy & paste' from the copybook directly into the program
> source magically make it better code ?
>
>
>> But I sound like I'm ranting so I better stop.
>>
>> At least when you look at our generated code it contains the
>> expanded COPY book that was used. It is deliberately hard coded.
>> This is a check so you can see exactly which definitions were used
>> to build your database and to generate the access against it. It
>> CAN'T change because someone changed a COPY book somewhere.
>
> That 'someone' can change program code too.
You're quite right about that. However, in practice over the last four
>
>> But I sound like I'm ranting so I better stop.
>>
>> At least when you look at our generated code it contains the
>> expanded COPY book that was used. It is deliberately hard coded.
>> This is a check so you can see exactly which definitions were used
>> to build your database and to generate the access against it. It
>> CAN'T change because someone changed a COPY book somewhere.
>
> That 'someone' can change program code too.
years, we have never had a client change the templated code that is
generated. They have never needed to and thousands of hours were spent
debugging it and getting it right. We have NEVER had a DAL object fail or
hang in production (always a first time, I guess - I am never smug about
computer programs). The generated COBOL is an open book and people COULD
amend it if they wanted to; they just don't. Occasionally they DO amend
generated code to LOAD their new DB, adding filters and checks of their own,
but most clients don't even do that.
>
>> (If it does HAVE to change, it is a matter of seconds to regenerate
>> the Table Set on the RDB and the COM component/interface block that
>> manages it in the DAL layer. The new interface needs to be
>> recompiled into the affected application programs and this means
>> re-running them through Transformation. (That could take a few
>> minutes if there are a number of programs. Another way to do it is
>> to simply make the new interface a COPY book (if you normally use
>> COPY) and just recompile the affected, already Transformed,
>> programs.)
>>
>> As a general rule, it is good not to mess with COPY books any more
>> than you absolutely have to.
>> (If it does HAVE to change, it is a matter of seconds to regenerate
>> the Table Set on the RDB and the COM component/interface block that
>> manages it in the DAL layer. The new interface needs to be
>> recompiled into the affected application programs and this means
>> re-running them through Transformation. (That could take a few
>> minutes if there are a number of programs. Another way to do it is
>> to simply make the new interface a COPY book (if you normally use
>> COPY) and just recompile the affected, already Transformed,
>> programs.)
>>
>> As a general rule, it is good not to mess with COPY books any more
>> than you absolutely have to.
docd...@panix.com
Apr 17, 2013, 10:11:13 AM4/17/13
to
In article <3b1bd4fb-368a-4614...@l5g2000pbp.googlegroups.com>,
Richard <rip...@Azonic.co.nz> wrote:
>On Apr 16, 8:50?pm, "Pete Dashwood"
><dashw...@removethis.enternet.co.nz> wrote:
[snip]
>> Another thing I hate about COPY is when people send me code for help, and
>> completely forget that without all the COPY books I simply can't even
>> compile it.
[snip]
>I suspect that 'when people send me code for help' is because they no
>longer have anyone who knows anything at all about the system.
I get asked 'Could you look at this ancient code?'
I respond 'Looking is for free, doing costs money.'
On the one hand my best work is done with a sense of love. On the other
hand the Latin word for 'love' is the root for 'amateur'. The executives
of a multinational corporation are not, most likely, expecting the data on
which they base their projections and activities to be processed
amateurishly.
DD
Richard <rip...@Azonic.co.nz> wrote:
>On Apr 16, 8:50?pm, "Pete Dashwood"
><dashw...@removethis.enternet.co.nz> wrote:
[snip]
>> Another thing I hate about COPY is when people send me code for help, and
>> completely forget that without all the COPY books I simply can't even
>> compile it.
>I suspect that 'when people send me code for help' is because they no
>longer have anyone who knows anything at all about the system.
I respond 'Looking is for free, doing costs money.'
On the one hand my best work is done with a sense of love. On the other
hand the Latin word for 'love' is the root for 'amateur'. The executives
of a multinational corporation are not, most likely, expecting the data on
which they base their projections and activities to be processed
amateurishly.
DD
Rick Smith
Apr 23, 2013, 4:31:35 PM4/23/13
to
On Tuesday, April 16, 2013 5:26:12 PM UTC-4, Richard wrote:
[snip]
> If you have a problem with alleged 'VCS issues' then maybe you are
> using the wrong VCS. I like Bazaar.
Why Bazaar < http://bazaar.canonical.com/ > as opposed to
Subversion < http://subversion.apache.org/ >?
I just replaced Ubuntu with Debian 6 and could use a VCS
(along with other software). Having no experience with
either VCS, opinions would be welcomed.
[Maybe Debian was not a good choice either. <g>]
[snip]
> If you have a problem with alleged 'VCS issues' then maybe you are
> using the wrong VCS. I like Bazaar.
Subversion < http://subversion.apache.org/ >?
I just replaced Ubuntu with Debian 6 and could use a VCS
(along with other software). Having no experience with
either VCS, opinions would be welcomed.
[Maybe Debian was not a good choice either. <g>]
Robert Wessel
Apr 23, 2013, 6:44:38 PM4/23/13
to
Rick Smith
Apr 23, 2013, 10:52:57 PM4/23/13
to
svn is centralized and apparently simple to use.
bzr is distributed and apparently simple to use.
git is distributed and apparently complex to use.
Both bzr and git have ability to work with svn.
OpenCOBOL uses svn, though I do not yet know if I will become
involved with that project, or indeed any open source project.
Given that my needs are, probably, simple, svn and bzr are
the front runners.
Robert Wessel
Apr 23, 2013, 11:17:51 PM4/23/13
to
It does have some non-traditional aspects, which presents a certain
amount of unlearning difficulty if you're coming from a SVN-like
background. And if you use an online service like github, quite easy
to set up (they do private repositories too, although then I think you
have to pay for the service).
Nor is setting up a purely private/local Git repository really any
more complex than setting on an SVN one. You do need to think about
the sharing/distributed aspects a (small) bit (again, using something
like github simplifies that).
SVN will certainly be around a long time, given the number of projects
using it, but almost nothing new is going that route.
HeyBub
May 5, 2013, 10:44:18 PM5/5/13
to
Pete Dashwood wrote:
>>
>> I am happy using COPY on my hobby database as it allows me to
>> modularise and more easily develop/maintain a modelling program that
>> I am experimenting with. I even use the COPY for SELECTS, FDs,
>> working storage and procedure code. Bliss.
>
> Why not use Cut & Paste? :-)
>
Copy, paste, compile vs. Compile only.
>>
>> I am happy using COPY on my hobby database as it allows me to
>> modularise and more easily develop/maintain a modelling program that
>> I am experimenting with. I even use the COPY for SELECTS, FDs,
>> working storage and procedure code. Bliss.
>
> Why not use Cut & Paste? :-)
>
Let me think...
0 new messages