Cobol - RW error (was: Discussions of COBOL philospphy

Author

RW error (was: Discussions of COBOL philospphy

William M. Klein

2007-09-10, 7:55 am

"Robert" <no@e.mail> wrote in message
news:vch9e314671b25do4scg6p8ul4h62gq7g1@
4ax.com...
> On Sun, 09 Sep 2007 15:24:42 -0700, Richard <riplin@Azonic.co.nz> wrote:
<snip>
>
>
> When the software was written, in the late '90s, typedef was supported by
> Micro Focus
> (their compiler), IBM and Fujitsu. We knew it would be in the next Standard.
>

Typedefs are NOT compatible between Micro Focus and Fujitsu
but
More importantly, even to this day there is no IBM compiler that supports them
(on any platform).

If you (RW) think there is - or was - please provide a link to an LRM showing
support for them.

P.S. The iSeries compiler does support "LIKE" - which is VERY similar to the
'02 Standard "SAME AS" - but certainly not the same as TYPEDEF.

--
Bill Klein
wmklein <at> ix.netcom.com

Robert

2007-09-10, 9:55 pm

On Mon, 10 Sep 2007 05:42:32 GMT, "William M. Klein" <wmklein@nospam.netcom.com> wrote:

>"Robert" <no@e.mail> wrote in message
> news:vch9e314671b25do4scg6p8ul4h62gq7g1@
4ax.com...
><snip>
>
>Typedefs are NOT compatible between Micro Focus and Fujitsu
> but
>More importantly, even to this day there is no IBM compiler that supports them
>(on any platform).
>
>If you (RW) think there is - or was - please provide a link to an LRM showing
>support for them.

ILE COBOL for AS/400
Programmer's Guide
Version 4
dated 1999

What's New in V4R2?

¹ User-defined data types
A user-defined data type is defined by specifying a level-01 entry containing the
TYPEDEF clause; all entries that are subordinate to the level-01 entry are considered
part of the user-defined data type. A user-defined data type can be
used to define new data items of level-01, -77, or -02 through -49, by specifying
a TYPE clause for the new data item, that references the user-defined data
type.

http://publib.boulder.ibm.com/infoc.../c092540528.htm

ILE COBOL Language Reference

+-------------------------------IBM Extension--------------------------------+

TYPEDEF Clause

The TYPEDEF clause is used to create a new user-defined data type, type-name. The name of
the new user-defined data type is the subject of the TYPEDEF clause. Data-name-1 must be
specified with the TYPEDEF clause: FILLER cannot be used. The TYPEDEF clause must
immediately follow data-name-1. After defining a new data type using the TYPEDEF clause,
data items can be declared as this new data type using the TYPE clause. For more
information about the TYPE clause, refer to TYPE Clause.

http://publib.boulder.ibm.com/infoc...c0925395283.htm

>P.S. The iSeries compiler does support "LIKE" - which is VERY similar to the
>'02 Standard "SAME AS" - but certainly not the same as TYPEDEF.

It also had a date data type, XML and pointers.

William M. Klein

2007-09-11, 3:55 am

OK. I'll accept that. So when you said that the programmers SHOULD have known
about TYPEDEFs because they were already available in Micro Focus, Fujitsu and
IBM, then those programmers had ILE COBOL (the iSeries COBOL) and that was the
platform that they were developing for?

--
Bill Klein
wmklein <at> ix.netcom.com
"Robert" <no@e.mail> wrote in message
news:vplbe39v4n96qu5lhs354tp5smc2bb2ken@
4ax.com...
> On Mon, 10 Sep 2007 05:42:32 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
>
>
> ILE COBOL for AS/400
> Programmer's Guide
> Version 4
> dated 1999
>
> What's New in V4R2?
>
> ¹ User-defined data types
> A user-defined data type is defined by specifying a level-01 entry containing
> the
> TYPEDEF clause; all entries that are subordinate to the level-01 entry are
> considered
> part of the user-defined data type. A user-defined data type can be
> used to define new data items of level-01, -77, or -02 through -49, by
> specifying
> a TYPE clause for the new data item, that references the user-defined data
> type.
>
> http://publib.boulder.ibm.com/infoc.../c092540528.htm
>
> ILE COBOL Language Reference
>
> +-------------------------------IBM Extension--------------------------------+
>
> TYPEDEF Clause
>
> The TYPEDEF clause is used to create a new user-defined data type, type-name.
> The name of
> the new user-defined data type is the subject of the TYPEDEF clause.
> Data-name-1 must be
> specified with the TYPEDEF clause: FILLER cannot be used. The TYPEDEF clause
> must
> immediately follow data-name-1. After defining a new data type using the
> TYPEDEF clause,
> data items can be declared as this new data type using the TYPE clause. For
> more
> information about the TYPE clause, refer to TYPE Clause.
>
> http://publib.boulder.ibm.com/infoc...c0925395283.htm
>
>
> It also had a date data type, XML and pointers.

Robert

2007-09-11, 3:55 am

On Tue, 11 Sep 2007 04:58:20 GMT, "William M. Klein" <wmklein@nospam.netcom.com> wrote:

>OK. I'll accept that. So when you said that the programmers SHOULD have known
>about TYPEDEFs because they were already available in Micro Focus, Fujitsu and
>IBM, then those programmers had ILE COBOL (the iSeries COBOL) and that was the
>platform that they were developing for?

They were developing for Micro Focus. I said that.

This is generated code, not hand-written. Even if they didn't know about typedef in the
late '90s, they could have changed the generator after 2002. In 2006, they still didn't
know typedef was available.

Richard

2007-09-11, 3:55 am

On Sep 11, 5:28 pm, Robert <n...@e.mail> wrote:
> On Tue, 11 Sep 2007 04:58:20 GMT, "William M. Klein" <wmkl...@nospam.netcom.com> wrote:
>
>
> They were developing for Micro Focus. I said that.
>
> This is generated code, not hand-written. Even if they didn't know about typedef in the
> late '90s, they could have changed the generator after 2002. In 2006, they still didn't
> know typedef was available.

What would be the point of rewriting all the code to remove the
hundreds of COPYs and replace them with hundreds of TYPEs ?

And then of course it would need to be completely retested and
debugged.

THEN, after reading the '02 standard to learn TYPEDEF they find that
MF doesn't support '02 TYPEDEF, only a MF extension that isn't '02,
and all their changes have to be redone.

But then again, why would they care to use a solution designed for a
completely different language. TYPEDEF is a solution for the C
language and was implemented by MF and Fujitsu (along with 78 and some
other stuff) so it could deal with the MS Windows C based #include
files for writing Windows API code.

Using COPY, as you described, is a Cobol solution to the problem.

TYPEDEF is a 35 year old solution. You may think yourself 'modern' and
'progressive' by using it, but C++ (25 year old) discards it and Java
(a better C++) doesn't even implement it.

Rick Smith

2007-09-11, 7:55 am

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1189492597.664492.70260@19g2000hsx.googlegroups.com...
[snip]
> Using COPY, as you described, is a Cobol solution to the problem.
>
> TYPEDEF is a 35 year old solution. You may think yourself 'modern' and
> 'progressive' by using it, but C++ (25 year old) discards it and Java
> (a better C++) doesn't even implement it.

C++ does not discard typedefs; they may be used as
synonyms for both intrinsic types and user-defined types.
----- (Checked using Microsoft Visual C++ 5.0)
typedef int int32;

struct REC1 { int32 a, b; };
REC1 inrec1, outrec1;

typedef struct { int32 a, b; } REC2;
REC2 inrec2, outrec2;
-----
int32 is a synonym for int.
REC1 is the name of a user-defined type.
inrec1 and outrec1 are instances of REC1.
REC2 is a synonym for an unnamed user-defined type.
inrec2 and outrec2 are implementations of REC2.

[C requires the 'struct' keyword before REC1; but is the
same as C++ when using typedef.]

In this limited context, COBOL library text (COPY)
is similar to the REC1 construct and COBOL typedefs
are similar to the REC2 construct.

Using a single COPY statement to include all typedefs
versus individual COPY statements was mentioned
elsewhere.

William M. Klein

2007-09-11, 6:55 pm

As the MF extension doesn't seem to support STRONG typing (only w

), can you
tell me what advantage that has over COPY. (See my other note asking for any
GENERAL advantages of "weak" typedefs. I know the advantages of strong typing).

--
Bill Klein
wmklein <at> ix.netcom.com
"Robert" <no@e.mail> wrote in message
news:er8ce398t85id9kusf5ruaf4980e9do0ba@
4ax.com...
> On Tue, 11 Sep 2007 04:58:20 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
>
>
> They were developing for Micro Focus. I said that.
>
> This is generated code, not hand-written. Even if they didn't know about
> typedef in the
> late '90s, they could have changed the generator after 2002. In 2006, they
> still didn't
> know typedef was available.

Rick Smith

2007-09-11, 6:55 pm

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:13ed0un9251ec6d@corp.supernews.com...
[snip]
> ----- (Checked using Microsoft Visual C++ 5.0)
> typedef int int32;
>
> struct REC1 { int32 a, b; };
> REC1 inrec1, outrec1;
>
> typedef struct { int32 a, b; } REC2;
> REC2 inrec2, outrec2;
> -----
[snip]
> In this limited context, COBOL library text (COPY)
> is similar to the REC1 construct and COBOL typedefs
> are similar to the REC2 construct.

Upon re-reading this, I realize that I probably should not
have written "similar to"; I think "closer to" is better.
However, these C++ constructs are so similar it is difficult
to translate them to analogous COBOL constructs. Given
that the action of a typedef (as in the REC2 construct) is
closer to a COBOL REPLACE statement, that would leave
the COBOL COPY statement as closer to the REC1
construct. Though I am probably splitting hairs, here. <g>

Robert

2007-09-12, 3:55 am

On Mon, 10 Sep 2007 23:36:37 -0700, Richard <riplin@Azonic.co.nz> wrote:

>On Sep 11, 5:28 pm, Robert <n...@e.mail> wrote:
>
>What would be the point of rewriting all the code to remove the
>hundreds of COPYs and replace them with hundreds of TYPEs ?

1. A developer could SEE all pictures by loading two files into the editor -- the source
and the typedef file.

2. Since semantics are the same between C and Cobol, it is less noisy to use the same
grammar.

>And then of course it would need to be completely retested and
>debugged.

Negative-finding regression tests are easy, the output files are identical.

>THEN, after reading the '02 standard to learn TYPEDEF they find that
>MF doesn't support '02 TYPEDEF, only a MF extension that isn't '02,
>and all their changes have to be redone.

There is a compiler option to replace the word TYPE with a null string. (They don't use
report writer.)

>But then again, why would they care to use a solution designed for a
>completely different language. TYPEDEF is a solution for the C
>language and was implemented by MF and Fujitsu (along with 78 and some
>other stuff) so it could deal with the MS Windows C based #include
>files for writing Windows API code.

They would want to use it because C-like languages are their native tongue.

>Using COPY, as you described, is a Cobol solution to the problem.

It's clunky. They thought it was the only way to get TYPEDEF functionality.

>TYPEDEF is a 35 year old solution. You may think yourself 'modern' and
>'progressive' by using it, but C++ (25 year old) discards it and Java
>(a better C++) doesn't even implement it.

Of course OO languages don't use it, they have a more elegant way of abstracting data
types. The company could define each distinct type as a class in OO Cobol, but they're not
going to.

robertwessel2@yahoo.com

2007-09-12, 3:55 am

On Sep 11, 9:23 pm, Richard <rip...@Azonic.co.nz> wrote:
> Exactly. In C a typedef may be used just so the struct keyword does
> not have to be specified each time, but in C++ a struct is equivalent
> to a class with all public members and so the typedef usage is
> redundant (and thus discarded).

It's more that structs (and classes) have an implicit typedef in C++.

It is true that typedefs are rarer in C++ than in C code, but they're
still often useful for removing redundant/repetitive type definitions,
just like in C. A common use is to define a container object as a
typedef, then the container itself with a reference to the type, and
then iterators using the typedef as a base - that way you're not
having to repeat the definition of the container when you create an
iterator for it.

William M. Klein

2007-09-12, 3:55 am

"Robert" <no@e.mail> wrote in message
news:l7qee3l2khkgihmalldbkbisssja9rchsu@
4ax.com...
> On Mon, 10 Sep 2007 23:36:37 -0700, Richard <riplin@Azonic.co.nz> wrote:
>
>
> 1. A developer could SEE all pictures by loading two files into the editor --
> the source
> and the typedef file.
>
> 2. Since semantics are the same between C and Cobol, it is less noisy to use
> the same
> grammar.
>
>
>
> Negative-finding regression tests are easy, the output files are identical.
>
>
> There is a compiler option to replace the word TYPE with a null string. (They
> don't use
> report writer.)
>
>
> They would want to use it because C-like languages are their native tongue.
>
>
> It's clunky. They thought it was the only way to get TYPEDEF functionality.
>
>
> Of course OO languages don't use it, they have a more elegant way of
> abstracting data
> types. The company could define each distinct type as a class in OO Cobol, but
> they're not
> going to.
>

William M. Klein

2007-09-12, 3:55 am

I sent an unintentional blank note. Sorry about that

--
Bill Klein
wmklein <at> ix.netcom.com
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:gzKFi.102361$M%1.79957@fe10.news.easynews.com...
>
> "Robert" <no@e.mail> wrote in message
> news:l7qee3l2khkgihmalldbkbisssja9rchsu@
4ax.com...
>
>

Robert

2007-09-12, 3:55 am

On Tue, 11 Sep 2007 13:11:09 GMT, "William M. Klein" <wmklein@nospam.netcom.com> wrote:

>As the MF extension doesn't seem to support STRONG typing (only w

), can you
>tell me what advantage that has over COPY. (See my other note asking for any
>GENERAL advantages of "weak" typedefs. I know the advantages of strong typing).

The advantage is a single copybook describing all types, a opposed to a separate copybook
for each type.

Micro Focus offers strong typing in USAGE OBJECT REFERENCE class-name ONLY. Adding strong
typing to non-OO Cobol is no guarantee of type safety because programmers can bypass it
with pointers, just as C++ programmers do by dropping into C.

Richard

2007-09-12, 3:55 am

On Sep 12, 4:34 pm, Robert <n...@e.mail> wrote:
> On Mon, 10 Sep 2007 23:36:37 -0700, Richard <rip...@Azonic.co.nz> wrote:
>
>
>
>
>
> 1. A developer could SEE all pictures by loading two files into the editor -- the source
> and the typedef file.

grep . *.cpy >allcopy

Then the developer can SEE all pictures by load two files ...

<shrug>

> 2. Since semantics are the same between C and Cobol, it is less noisy to use the same
> grammar.

I prefer to have Cobol semantics in Cobol programs. Maybe they do too.

I also prefer to have a solution that has been done and works rather
than re-engineering all the code to a different solution with no
_actual_ benefit.

>
> Negative-finding regression tests are easy, the output files are identical.

Only for the conditions being tested.

But why go through all that change just because some grandstanding
pundit thinks it would be a 'good idea'.

>
> There is a compiler option to replace the word TYPE with a null string. (They don't use
> report writer.)
>
>
> They would want to use it because C-like languages are their native tongue.

No. They seem to want to _NOT_ do it. I got the impression that it was
only _you_ that wanted them to do it.

>
> It's clunky. They thought it was the only way to get TYPEDEF functionality.

The only bit that seems 'clunky' is 'seeing two files in the editor'.
That just isn't hard to fix.

In any case with my editor I have one keystroke to open a file whose
name in under the cursor. How hard is that ?

It also has one keystroke to search for a text item under the cursor
in all open files so where there is

01 Customer-Code COPY "Customer_Code.cpy".

or similar I can search in my grep output file or open the copy file
with a keystroke. How 'clunky' are your tools ?

>
> Of course OO languages don't use it, they have a more elegant way of abstracting data
> types. The company could define each distinct type as a class in OO Cobol, but they're not
> going to.

It seems they're not going to use typedef either.

<shrug>

Richard

2007-09-12, 3:55 am

On Sep 12, 5:22 pm, Robert <n...@e.mail> wrote:
> On Tue, 11 Sep 2007 13:11:09 GMT, "William M. Klein" <wmkl...@nospam.netcom.com> wrote:
>
>
> The advantage is a single copybook describing all types, a opposed to a separate copybook
> for each type.

Already solved using simple tools, but a small modification to the
generator could also write out a summary or directory each time.

> Micro Focus offers strong typing in USAGE OBJECT REFERENCE class-name ONLY. Adding strong
> typing to non-OO Cobol is no guarantee of type safety because programmers can bypass it
> with pointers, just as C++ programmers do by dropping into C.

Robert

2007-09-12, 3:55 am

On Tue, 11 Sep 2007 23:02:46 -0700, Richard <riplin@Azonic.co.nz> wrote:

>In any case with my editor I have one keystroke to open a file whose
>name in under the cursor. How hard is that ?

Ae you using the editor I wrote?

>It also has one keystroke to search for a text item under the cursor
>in all open files so where there is
>
> 01 Customer-Code COPY "Customer_Code.cpy".

Why limit it to open files, how about all files in the path or in directories under the
current?

Richard

2007-09-12, 3:55 am

On Sep 12, 6:44 pm, Robert <n...@e.mail> wrote:
> On Tue, 11 Sep 2007 23:02:46 -0700, Richard <rip...@Azonic.co.nz> wrote:
>
> Ae you using the editor I wrote?

I neither know nor care whether you wrote an editor.

>
>
> Why limit it to open files, how about all files in the path or in directories under the
> current?

Because I don't want to search all files in the path or all files in
the directory, whether it could do that is irrelevant. I want it to do
what _I_ want not some random actions that you may think up.

In the case of having open a single file created by a grep, or by
something similar to ctags, then searching in the open files is what I
would want. It achieves the purpose of seeing the source and the
picture of the item.

Opening the COPY file with one stroke would also achieve that too. Two
different solutions to your perceived problem that you think requires
re-engineering the whole system.

Robert

2007-09-12, 6:55 pm

On Wed, 12 Sep 2007 00:13:36 -0700, Richard <riplin@Azonic.co.nz> wrote:

>On Sep 12, 6:44 pm, Robert <n...@e.mail> wrote:
>
>I neither know nor care whether you wrote an editor.
>
>
>Because I don't want to search all files in the path or all files in
>the directory, whether it could do that is irrelevant. I want it to do
>what _I_ want not some random actions that you may think up.

You want to do the same thing the compiler does, which is search the copy path. Micro
Focus calls it COBCPY.

>In the case of having open a single file created by a grep, or by
>something similar to ctags, then searching in the open files is what I
>would want. It achieves the purpose of seeing the source and the
>picture of the item.

The grep list cannot be prepared in advance. It sounds like you're shelling to a grep like
this 'find . -name \*.cpy -follow | xargs grep foo >mygrep', then opening and searching
mygrep. My editor does that internally. The file name need not be under the cursor, it can
be anywhere on the line. It tries he word under the cursor first, then quoted words, then
upper case, lastly lower case. It looks in open files first, before going to the file
system. When viewing search results, you can put the cursor on a line and hit one key to
see it in context, a second press of the same key takes you back to the search results.

Here's the best part: the search document is editable, including with group changes. It
doesn't contain copies of the lines, it contains pointers to them. You're actually looking
at lines in the original files. One action can make changes to 100 files.

>

Richard

2007-09-12, 6:55 pm

On Sep 13, 1:21 am, Robert <n...@e.mail> wrote:
> On Wed, 12 Sep 2007 00:13:36 -0700, Richard <rip...@Azonic.co.nz> wrote:
>
>
>
>
>
>
>
> You want to do the same thing the compiler does, which is search the copy path. Micro
> Focus calls it COBCPY.

You are

and arguing the wrong point yet again. Two different
things: "open a file" and "search for a text item". I do not want to
search for a text item in all the files in the path, or directory
tree, I only want to search for a text item in the open files.

When I open a file it knows where to look.

>
> The grep list cannot be prepared in advance.

Of course it can. It can be done before starting the edit or by the
run of the generator program, or anytime in between. Try and work out
what the grep is actually doing.

> It sounds like you're shelling to a grep like
> this 'find . -name \*.cpy -follow | xargs grep foo >mygrep', then opening and searching
> mygrep.

No. Wrong. That is not what it is doing. I gave you the command line.
It is building a complete list of all the definitions regardless of
whether a particular program uses them and winds up with a single file
with the same data in it that your speculative typedef file would
have.

[irrelevant self promotion snipped]

William M. Klein

2007-09-12, 6:55 pm

As MF and the current (and recent) Standards allow nested COPY statements, you
could certainly have a single COPY member with all the COPY statements for the
individual structures (as long as you didn't become recursive, this could go
down multiple levels).

Also, STRONG types in the '02 Standard do provide protection *IF* the programmer
uses them. If they decide to avoid those rules, then (like REDEFINES and a
variety of COBOL features) the results are unpredictable.

Certainly doesn't sound to me as if there are many (if any) reason for a shop
with competent COBOL programmers (even if they do also use other languages) to
change from standard COPY members to the MF non-Standard TYPEDEF extension. (If
a shop DID already use COBOL TYPEDEFs, then I wouldn't see much advantage to
changing to COPY statements either. This is simply a two equivalent styles to
do the same thing.)

--
Bill Klein
wmklein <at> ix.netcom.com
"Robert" <no@e.mail> wrote in message
news:v2ree3lqtjh8nujm8nlghflta2na4dg726@
4ax.com...
> On Tue, 11 Sep 2007 13:11:09 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
>
>
> The advantage is a single copybook describing all types, a opposed to a
> separate copybook
> for each type.
>
> Micro Focus offers strong typing in USAGE OBJECT REFERENCE class-name ONLY.
> Adding strong
> typing to non-OO Cobol is no guarantee of type safety because programmers can
> bypass it
> with pointers, just as C++ programmers do by dropping into C.

William M. Klein

2007-09-12, 6:55 pm

Robert,
You said that the shop was using Micro Focus. Don't you know how to see COPY
source with their IDE? If not, go thru there tutorials to help you to learn the
tools that are already available. (Or as you suggested at the beginning of this
thread, read the manual)

You can also use the REVOLVE feature (of MF) to find where the same field in all
the programs of a project are defined and modified.

--
Bill Klein
wmklein <at> ix.netcom.com
"Robert" <no@e.mail> wrote in message
news:vd2fe3h3g1mpmabpu9lknoetin396hahr2@
4ax.com...
> On Tue, 11 Sep 2007 23:02:46 -0700, Richard <riplin@Azonic.co.nz> wrote:
>
>
>
> Ae you using the editor I wrote?
>
>
> Why limit it to open files, how about all files in the path or in directories
> under the
> current?
>
>
>

Robert

2007-09-12, 6:55 pm

On Wed, 12 Sep 2007 22:11:22 GMT, "William M. Klein" <wmklein@nospam.netcom.com> wrote:

>Robert,
> You said that the shop was using Micro Focus. Don't you know how to see COPY
>source with their IDE? If not, go thru there tutorials to help you to learn the
>tools that are already available. (Or as you suggested at the beginning of this
>thread, read the manual)

There's no IDE for Unix. On Windoes, I do use the workbench, whch I learned from its
former product manager. I believe you know Kramme.

Robert

2007-09-12, 9:55 pm

On Wed, 12 Sep 2007 22:07:41 GMT, "William M. Klein" <wmklein@nospam.netcom.com> wrote:

>As MF and the current (and recent) Standards allow nested COPY statements, you
>could certainly have a single COPY member with all the COPY statements for the
>individual structures (as long as you didn't become recursive, this could go
>down multiple levels).

You can't do that when the copy file contains nothing but the PIC clause.

>Also, STRONG types in the '02 Standard do provide protection *IF* the programmer
>uses them. If they decide to avoid those rules, then (like REDEFINES and a
>variety of COBOL features) the results are unpredictable.

What's that based on? IBM and Micro Focus don't support strong typing. Fujitsu is the only
compiler that does.

>Certainly doesn't sound to me as if there are many (if any) reason for a shop
>with competent COBOL programmers (even if they do also use other languages) to
>change from standard COPY members to the MF non-Standard TYPEDEF extension. (If
>a shop DID already use COBOL TYPEDEFs, then I wouldn't see much advantage to
>changing to COPY statements either. This is simply a two equivalent styles to
>do the same thing.)

As I said, they already have C typedefs. They created Cobol copy files because they
thought it was the only way. Now they have two sets of code to maintain.

Richard

2007-09-12, 9:55 pm

On Sep 13, 12:01 pm, Robert <n...@e.mail> wrote:
> On Wed, 12 Sep 2007 22:07:41 GMT, "William M. Klein" <wmkl...@nospam.netcom.com> wrote:
>
>
> You can't do that when the copy file contains nothing but the PIC clause.
>
>
> What's that based on? IBM and Micro Focus don't support strong typing. Fujitsu is the only
> compiler that does.
>
>
> As I said, they already have C typedefs. They created Cobol copy files because they
> thought it was the only way. Now they have two sets of code to maintain.

Geez, Robert, that is just silly. It is as you are grasping for some,
any, spurious justification for your ideas.

1. They can't use C typedefs in a Cobol program so they have to have
different Cobol files from the C files whether it is COPY or typedef.

2. From what you said the Cobol COPY files were generated, as
presumably was the C typedef. They don't have to 'maintain' these,
they just regenerate.

Another of your claimed 'advantage' was that typedef would allow just
two files to be opened (source plus typedef), that was solved with one
minutes thought by using grep or adding a grep to the generator
script, or code directly into the generator program to output a
reference file.

It seems to me that you don't want people to have _a_ solution to each
problem, you want them to have _your_ solution regardless of its
merits (or lack thereof) or costs.

Robert

2007-09-13, 3:55 am

On Wed, 12 Sep 2007 17:25:44 -0700, Richard <riplin@Azonic.co.nz> wrote:

>On Sep 13, 12:01 pm, Robert <n...@e.mail> wrote:
>
>Geez, Robert, that is just silly. It is as you are grasping for some,
>any, spurious justification for your ideas.
>
>1. They can't use C typedefs in a Cobol program so they have to have
>different Cobol files from the C files whether it is COPY or typedef.
>
>2. From what you said the Cobol COPY files were generated, as
>presumably was the C typedef. They don't have to 'maintain' these,
>they just regenerate.

They don't regenerate for maintenance releases; they change or create the files manually.

>Another of your claimed 'advantage' was that typedef would allow just
>two files to be opened (source plus typedef), that was solved with one
>minutes thought by using grep or adding a grep to the generator
>script, or code directly into the generator program to output a
>reference file.

You are grepping copybooks with whole structures. These copybooks do not have element
names, just pictures (type definitions). There are hundreds to thousands of them.

>It seems to me that you don't want people to have _a_ solution to each
>problem, you want them to have _your_ solution regardless of its
>merits (or lack thereof) or costs.

I don't need to apologize for presenting the problem and my opinion about the best
solution.

Richard

2007-09-13, 3:55 am

On Sep 13, 3:16 pm, Robert <n...@e.mail> wrote:
> On Wed, 12 Sep 2007 17:25:44 -0700, Richard <rip...@Azonic.co.nz> wrote:
>
>
>
>
>
>
>
>
>
>
> They don't regenerate for maintenance releases; they change or create the files manually.

I had thought they would have generated these automatically, it isn't
hard to do so.

But regardless of that the C typedef can't be used by Cobol so they
still need different files for C and Cobol. They could generate from
the C typedef file to either a Cobol typedef or to the Copybooks. I
don't see much difference here between what they appear to be doing
and using typedefs.

But to use typedefs they would have to re-engineer the system, for
what ? to keep you happy ?

>
> You are grepping copybooks with whole structures.

No I'm not.

> These copybooks do not have element
> names, just pictures (type definitions). There are hundreds to thousands of them.

You haven't worked out what the grep does yet, you are too obsessed
with 'how clever your editor is' that you can't see anything
different.

>From what you say the programs have something like:

05 Product-Code COPY Product-Code.cpy.

where Product-Code.cpy is one of hundreds of files and has a content
of something like:

PIC X(16).

Your 'advantage' was that a typedef would have all these types in one
file easily searched. I will have to explain to you what the output of
the grep will be, it will be one file with a line for each copybook
like:

....
Product-Code.cpy: PIC X(16).
Product-Description.cpy: PIC X(40).
Product-Group.cpy: PIC X(4).
....

Thus from the program source file one could hit a keystroke and the
picture would be displayed (in a small window, say) that matches the
copybook name.

So, what 'advantage' does your typedef file have for this ?

>
> I don't need to apologize for presenting the problem and my opinion about the best
> solution.

I am not sure that _they_ think it is a problem.

Yours may well be a solution, but you claim advantages for it that are
easily done in other ways.

William M. Klein

2007-09-13, 3:55 am

Check out the "Chapter 7: Editor" in the Server Express 5.0 Utilities Guide.
Look for the bullet that says,

"Copy library support, which enables you quick access to parts of program source
code held in separate files."

My use of "IDE" might have mislead you - or you (or the site you were talking
about might not LIKE the Micro Focus interface), but it does exist and does
provide the specific facility that I mentioned. (And checking the manual would
have found it - just as it would have found LRM references to TYPEDEFs - as an
extension)

P.S. I can't remember which release of "Unix" products first provided this
functionality, but I believe it has been there for MANY years.

--
Bill Klein
wmklein <at> ix.netcom.com
"Robert" <no@e.mail> wrote in message
news:iitge35rthucrb8h5rv9d32ldhncln16n4@
4ax.com...
> On Wed, 12 Sep 2007 22:11:22 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
>
>
> There's no IDE for Unix. On Windoes, I do use the workbench, whch I learned
> from its
> former product manager. I believe you know Kramme.

Robert

2007-09-13, 3:55 am

On Thu, 13 Sep 2007 04:20:20 GMT, "William M. Klein" <wmklein@nospam.netcom.com> wrote:

>Check out the "Chapter 7: Editor" in the Server Express 5.0 Utilities Guide.
>Look for the bullet that says,
>
>"Copy library support, which enables you quick access to parts of program source
>code held in separate files."
>
>My use of "IDE" might have mislead you - or you (or the site you were talking
>about might not LIKE the Micro Focus interface), but it does exist and does
>provide the specific facility that I mentioned. (And checking the manual would
>have found it - just as it would have found LRM references to TYPEDEFs - as an
>extension)
>
>P.S. I can't remember which release of "Unix" products first provided this
>functionality, but I believe it has been there for MANY years.

Oh yes. That's the same text mode editor they shipped with MS-DOS in the '80s. It's a weak
editor.

I usually use Ultra-Edit, which runs on Windows and accesses the Unix file system via FTP.
If the shop is running Samba or NFS, there are many more Windows editors available.

William M. Klein

2007-09-13, 3:55 am

"Robert" <no@e.mail> wrote in message
news:l8hhe3ljuiqb5un8bnr3s4manuos4ji84i@
4ax.com...
> On Thu, 13 Sep 2007 04:20:20 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
>
>
> Oh yes. That's the same text mode editor they shipped with MS-DOS in the '80s.
> It's a weak
> editor.
>
> I usually use Ultra-Edit, which runs on Windows and accesses the Unix file
> system via FTP.
> If the shop is running Samba or NFS, there are many more Windows editors
> available.

If you have windows, then I would expect to use either the Windows IDE or the
VisualStudio IDE. I thought you were looking for a "Unix only" solution - which
as I say DOES exist and does provide the facility (no matter HOW old it is) that
you want (for handling COPY statements).

If you are doing your editing on Windows and your compiling and debugging on
Unix, that seems counter-productive to me - but I have never had to do it that
way, so I won't swear to it.

The bottom-line is simply that IF the only issue were (and I am not claiming
that you said it was) that your editor would allow you to see TYPEDEFs and "main
source" at the same time while it wouldn't for COPY and main source, then that
does mean that a better selection of available editors would solve this problem
for you (and would have any time in the last decade-plus)

2007-09-13, 7:55 am

In article <ieahe3dprferli0c4svqcemckkcqk6uftm@4ax.com>,
Robert <no@e.mail> wrote:
>On Wed, 12 Sep 2007 17:25:44 -0700, Richard <riplin@Azonic.co.nz> wrote:

[snip]

>
>I don't need to apologize for presenting the problem and my opinion
>about the best
>solution.

Mr Wagner, I do not believe that anyone has asked you to do either... and
I think you might do very, very well to recall what Drill Sergeants teach
about opinions.

DD

Howard Brazee

2007-09-13, 6:55 pm

On Thu, 13 Sep 2007 00:11:07 -0500, Robert <no@e.mail> wrote:

>I usually use Ultra-Edit, which runs on Windows and accesses the Unix file system via FTP.
>If the shop is running Samba or NFS, there are many more Windows editors available.

While my shop has Ultra-Edit, I also bought it at home (with the
forever updates option). Trouble is, I'm saving up my allowance for
a Mac, which will mean I will have to switch editors. (I used to use
Multi-Edit, but stopped upgrading after it went GUI).

Howard Brazee

2007-09-13, 6:55 pm

On Wed, 12 Sep 2007 21:10:41 -0700, Richard <riplin@Azonic.co.nz>
wrote:

>But regardless of that the C typedef can't be used by Cobol so they
>still need different files for C and Cobol. They could generate from
>the C typedef file to either a Cobol typedef or to the Copybooks. I
>don't see much difference here between what they appear to be doing
>and using typedefs.

I wonder how this would change using a data dictionary. I believe
IDMS COPY does translations depending on what compiler is asking for
the file structure.

Robert

2007-09-14, 3:55 am

On Thu, 13 Sep 2007 05:20:38 GMT, "William M. Klein" <wmklein@nospam.netcom.com> wrote:

>
>"Robert" <no@e.mail> wrote in message
> news:l8hhe3ljuiqb5un8bnr3s4manuos4ji84i@
4ax.com...
>
>If you have windows,

EVERYone has Windows.

> then I would expect to use either the Windows IDE or the
>VisualStudio IDE.

It's bundled with Net Express, which costs thousands of dollars per seat.

>I thought you were looking for a "Unix only" solution - which
>as I say DOES exist and does provide the facility (no matter HOW old it is) that
>you want (for handling COPY statements).

Thank you.

>If you are doing your editing on Windows and your compiling and debugging on
>Unix, that seems counter-productive to me - but I have never had to do it that
>way, so I won't swear to it.

It's the norm. Samba and NFS mount the Unix file system on a Windows driver letter. It
looks like another drive on the Windows file system. We can edit with Windows editors,
drag and drop directories to and from other drives, etc.

The link is bidirectional -- the Windows file system looks like another mountpoint
(directory) to Unix. A program running on Unix can read and write files to a Windows disk.
Techniques like FTP have been replaced by a copy command.

Some (rare) enlightened shops do all development and TESTING on Windows, even though the
target platform is Unix. When it's time to deploy, they do a final compilation on Unix but
never test it there. So long as the program doesn't issue OS commands nor make API calls,
the programs always work the same. Java people are comfortable with the concept of
cross-platform compatibility, most Cobolers aren't.

>The bottom-line is simply that IF the only issue were (and I am not claiming
>that you said it was) that your editor would allow you to see TYPEDEFs and "main
>source" at the same time while it wouldn't for COPY and main source, then that
>does mean that a better selection of available editors would solve this problem
>for you (and would have any time in the last decade-plus)

All modern editors can open multiple files at once. They balk at opening hundreds to
thousands of files, even containing one line. The task bar fills up and navigation is
difficult.

Robert

2007-09-14, 3:55 am

On Wed, 12 Sep 2007 21:10:41 -0700, Richard <riplin@Azonic.co.nz> wrote:

>On Sep 13, 3:16 pm, Robert <n...@e.mail> wrote:
>
>I had thought they would have generated these automatically, it isn't
>hard to do so.
>
>But regardless of that the C typedef can't be used by Cobol so they
>still need different files for C and Cobol. They could generate from
>the C typedef file to either a Cobol typedef or to the Copybooks. I
>don't see much difference here between what they appear to be doing
>and using typedefs.
>
>But to use typedefs they would have to re-engineer the system, for
>what ? to keep you happy ?
>
>
>
>No I'm not.
>
>
>You haven't worked out what the grep does yet, you are too obsessed
>with 'how clever your editor is' that you can't see anything
>different.
>
>
> 05 Product-Code COPY Product-Code.cpy.
>
>where Product-Code.cpy is one of hundreds of files and has a content
>of something like:
>
> PIC X(16).
>
>Your 'advantage' was that a typedef would have all these types in one
>file easily searched. I will have to explain to you what the output of
>the grep will be, it will be one file with a line for each copybook
>like:
>
>...
>Product-Code.cpy: PIC X(16).
>Product-Description.cpy: PIC X(40).
>Product-Group.cpy: PIC X(4).

You acknowledge the benefit of having all types in a single file. Why not use typedef?
Then you'd be editing primary code rather than a derivative copy.

Another way is to edit the listing from your previous compilation.

>Thus from the program source file one could hit a keystroke and the
>picture would be displayed (in a small window, say) that matches the
>copybook name.
>
>So, what 'advantage' does your typedef file have for this ?

A single file. What is the advantage of hundreds of copybooks?

William M. Klein

2007-09-14, 3:55 am

"Robert" <no@e.mail> wrote in message
news:nj3ke3hmht7k5gimrpi54k70lqqtt8terv@
4ax.com...
> On Wed, 12 Sep 2007 21:10:41 -0700, Richard <riplin@Azonic.co.nz> wrote:
<snip>
>
> A single file. What is the advantage of hundreds of copybooks?
>

Unless I have missed something in the story of how the shop actually works
today, the advantage(S) of COPY are:

1) The current system CAN generate the COPY statements without any modification

2) The COPY approach is in use for existing applications (and "understood by
existing programmers

3) Possibly (probably) works with any COBOL sensitive editors. (I don't know if
there are editors already that "expand" TYPE - or MF USAGE - statements "in
place" - rather than looking at/for another file.

P.S. I would certainly try to discourage manually creating/modifying COPY files
rather than using their automated system. However, not knowing how/when they do
this, I might be mistaken on this.
Furthermore, when/if they actually reach the stage that the majority of those
maintaining and working with the COBOL source code actually ARE C/C++/C#
programmers, then I would question why COBOL was still being used at all; rather
than why a traditional COBOL technique was still being used for this one - to me
MINOR - part of the application code.

--
Bill Klein
wmklein <at> ix.netcom.com

Richard

2007-09-14, 3:55 am

On Sep 14, 4:39 pm, Robert <n...@e.mail> wrote:
> On Wed, 12 Sep 2007 21:10:41 -0700, Richard <rip...@Azonic.co.nz> wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> You acknowledge the benefit of having all types in a single file.

No, I acknowledged that _you_ claimed it as an advantage** for using
typedefs, and then I showed that there was no di

vantage to
copybooks in that respect for this particular purpose.

** note that I put 'advantage' in apostrophes to indicate, as you had
earlier explained, that it wasn't being used in its normal meaning.

> Why not use typedef?

For the particular software the use of typedefs would involve the cost
of re-engineering the complete source code. For the claimed
'advantage' that can be obtained at no cost at all.

If the system were to be re-implemented from scratch today then
perhaps it could be used, or perhaps OO could be.

Typedef is a 1970s solution for another language that was implemented
in Cobol to allow it to access Windows API in Windows 3.0 (and later).

> Then you'd be editing primary code rather than a derivative copy.

They would be better off generating these from the primary source, the
SQL database itself when they change that, rather than letting
programmers apply arbitrary edits. In fact using a derivitive copy is
safer.

In any case if they want to edit the picture the file is just a single
keystroke away for any reasonable editor.

> Another way is to edit the listing from your previous compilation.
>
>
>
> A single file. What is the advantage of hundreds of copybooks?

There isn't any, but it is what they have. It works, changing will
cost time and money and lead to risk, and so far you haven't found any
'advantage' that isn't easily and cheaply done another way.

You haven't even identified that what they are doing is actually a
problem for them, only that you don't like it and want to show how
clever you are in knowing about typedef (which I actually used in mid
1991 with an early release MF version 2.5 for Windows 3.0).

I probably wouldn't do this either way, but I wouldn't re-engineer the
whole system for no _actual_ advantage as you seem to want to.

Robert

2007-09-14, 9:55 pm

On Fri, 14 Sep 2007 04:46:35 GMT, "William M. Klein" <wmklein@nospam.netcom.com> wrote:

>"Robert" <no@e.mail> wrote in message
> news:nj3ke3hmht7k5gimrpi54k70lqqtt8terv@
4ax.com...
><snip>
>
>Unless I have missed something in the story of how the shop actually works
>today, the advantage(S) of COPY are:
>
>1) The current system CAN generate the COPY statements without any modification
>
>2) The COPY approach is in use for existing applications (and "understood by
>existing programmers
>
>3) Possibly (probably) works with any COBOL sensitive editors. (I don't know if
>there are editors already that "expand" TYPE - or MF USAGE - statements "in
>place" - rather than looking at/for another file.
>
>P.S. I would certainly try to discourage manually creating/modifying COPY files
>rather than using their automated system. However, not knowing how/when they do
>this, I might be mistaken on this.
> Furthermore, when/if they actually reach the stage that the majority of those
>maintaining and working with the COBOL source code actually ARE C/C++/C#
>programmers,

They are.

>then I would question why COBOL was still being used at all; rather
>than why a traditional COBOL technique was still being used for this one - to me
>MINOR - part of the application code.

They have a low opinion of Cobol. When they need a major chunk of code, say bigger than
one Cobol paragraph, they write it in C and call it from Cobol.

All embedded SQL is in called C programs. So are mundane OS calls such as getting the
command line and reading time of day.

William M. Klein

2007-09-14, 9:55 pm

"Robert" <no@e.mail> wrote in message
news:p1ame3113av28q7ac6uf8nb9r0id58tdtr@
4ax.com...
> On Fri, 14 Sep 2007 04:46:35 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
<snip>
>
> They are.
>
>
> They have a low opinion of Cobol. When they need a major chunk of code, say
> bigger than
> one Cobol paragraph, they write it in C and call it from Cobol.
>
> All embedded SQL is in called C programs. So are mundane OS calls such as
> getting the
> command line and reading time of day.

So why is COBOL used at all? (You may have mentioned this earlier, but I don't
remember any more).

--
Bill Klein
wmklein <at> ix.netcom.com

Robert

2007-09-15, 3:55 am

On Sat, 15 Sep 2007 00:56:50 GMT, "William M. Klein" <wmklein@nospam.netcom.com> wrote:

>
>"Robert" <no@e.mail> wrote in message
> news:p1ame3113av28q7ac6uf8nb9r0id58tdtr@
4ax.com...
><snip>
>
>So why is COBOL used at all? (You may have mentioned this earlier, but I don't
>remember any more).

I don't know why it was originally written in Cobol. The earliest program comments are
dated late '90s. I've heard conflicting stories about the system's origin. It was written
outside the US, not by the company now using it. If they wrote it from scratch today,
they wouldn't use Cobol.

Sponsored Links