Cobol - TYPEDEF and RENAMES

Author

TYPEDEF and RENAMES

Pete Dashwood

2007-01-10, 6:55 pm

[Sorry, my Usenet server would not allow this to be posted in the existing
thread because the address lines were getting too long. I therefore had to
start another thread... Pete.]

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:12qago1f0bjiqb5@corp.supernews.com...
>
> "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
> news:50ki2hF1g4q80U1@mid.individual.net...
>
> I do not understand!
>
> TYPEDEF saves several hundred (maybe a few thousand)
> characters. OF (or IN) adds a few hundred to several hundred
> characters. Judicious use of RENAMES adds a few hundred;
> but saves a few hundred to several hundred characters by
> avoiding OF (or IN). [Depending on the program.]
>
> The key, it seems, is that, where the judicious use of RENAMES
> adds fewer characters than are saved by using TYPEDEF, the
> result will be less typing. Therefore, I do not understand how
> less typing would be "Even more typing!".
>
> Perhaps you could explain your comment.
>
>
It's a funny thing, in forty years of writing COBOL all around the world I
have never seen a 66 RENAMES used in a production program.

When I first became aware of it about 30 years ago I decided to find a way
to use it... :-)

However, I was unable to come up with any use for it that couldn't be
equally well served by the much more familiar REDEFINES.

Since then, I have realised that it can be used to "regroup" items in a way
that REDEFINES can't be, but the actual need to do this has eluded me...

While I have nothing but respect for your knowledge on things COBOL and your
often imaginative solutions, Rick, I can understand (and share...) Frank's
reluctance. It seems like more writing to me too.

I think the TYPEDEF solution is a good one and I think your posted solution
is fine, but I still wouldn't do it.:-)

1. I'm not so crazy about TYPEDEFs in COBOL.
2. The solution LOOKS ugly even though it is actually quite an elegant
approach.
3. This is a solution to a non-existent problem. Frank was postulating how
things COULD be, not how they are; in reality a simple approach using
smaller datanames would obviate the onerous typing. The hankering after
TYPEDEFs is a result of exposure to other languages and has no place in a
proper COBOL world... :-)

Addressing the comments in your penultimate paragraph, above...

Do you really think that COBOL programmers should be assessing how many
characters they will type with various approaches, and that this should be a
serious consideration when developing application code?

It's fine for ivory tower theorising; on the shop floor all that matters is
getting a solution to the problem as quickly as possible.

My experience has been that ANYTHING which requires me to change my focus
from the specific problem at hand, is counter productive. That's why the
point about COBOL being verbose and requiring more typing was raised in the
first place...

Thirty years ago, when the Priests of COBOL ruled the World and the Holy
Source Code was the one true religion, how those sacred documents were
maintained was a matter of grave concern, and "verbosity" was a good thing
because it provided more information which would hopefully be of use to
subsequent generations of neophytes, entrusted with the awesome
responsibility of keeping the system running.

People who are still using COBOL need to stay focused on problem solution,
not assessing how many key depressions they must make in order to cut a
solution.

Pete.

Rick Smith

2007-01-10, 6:55 pm

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:50l73jF1gnqnuU1@mid.individual.net...
> [Sorry, my Usenet server would not allow this to be posted in the existing
> thread because the address lines were getting too long. I therefore had to
> start another thread... Pete.]
>
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:12qago1f0bjiqb5@corp.supernews.com...
TYPEDEFs[color=darkred]
[snip][color=darkred]
[snip][color=darkred]
> I think the TYPEDEF solution is a good one and I think your posted
solution
> is fine, but I still wouldn't do it.:-)

It was offered only as a possible means for overcoming
a too frequent use of OF (or IN).

> 1. I'm not so crazy about TYPEDEFs in COBOL.
> 2. The solution LOOKS ugly even though it is actually quite an elegant
> approach.
> 3. This is a solution to a non-existent problem. Frank was postulating how
> things COULD be, not how they are; in reality a simple approach using
> smaller datanames would obviate the onerous typing. The hankering after
> TYPEDEFs is a result of exposure to other languages and has no place in a
> proper COBOL world... :-)

Would you say the same about the SAME AS clause,
which is similar to using a TYPEDEF? At least some in
the COBOL world proper, find reason for both. <g>

> Addressing the comments in your penultimate paragraph, above...
>
> Do you really think that COBOL programmers should be assessing how many
> characters they will type with various approaches, and that this should be
a
> serious consideration when developing application code?

I did not raise the issues, I merely responded to what I
understood the issues to be. First, "it would require me
to use the 'OF' clause way too often"; and, second,
"Even more typing!".

> It's fine for ivory tower theorising; on the shop floor all that matters
is
> getting a solution to the problem as quickly as possible.

It seems to me that the COBOL file system may be
useful for "getting a solution to the problem as quickly
as possible". As I understand your prior comments
concerning the COBOL file system, "all that matters"
does not always include the notion "as quickly as
possible". Of course, it really depends on the problem,
does it not? <g>

> My experience has been that ANYTHING which requires me to change my focus
> from the specific problem at hand, is counter productive. That's why the
> point about COBOL being verbose and requiring more typing was raised in
the
> first place...
>
> Thirty years ago, when the Priests of COBOL ruled the World and the Holy
> Source Code was the one true religion, how those sacred documents were
> maintained was a matter of grave concern, and "verbosity" was a good thing
> because it provided more information which would hopefully be of use to
> subsequent generations of neophytes, entrusted with the awesome
> responsibility of keeping the system running.
>
> People who are still using COBOL need to stay focused on problem solution,
> not assessing how many key depressions they must make in order to cut a
> solution.

As I said before, I did not raise the issues; but, if I find
too many OFs affecting my focus, I know of a means
to maintain that focus--one that may take fewer
keystrokes. <g>

Pete Dashwood

2007-01-11, 3:55 am

Good responses :-)

Very brief comment below...

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:12qb0agopntgic9@corp.supernews.com...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:50l73jF1gnqnuU1@mid.individual.net...
> TYPEDEFs
> [snip]
> [snip]
> solution
>
> It was offered only as a possible means for overcoming
> a too frequent use of OF (or IN).
>
>
> Would you say the same about the SAME AS clause,
> which is similar to using a TYPEDEF? At least some in
> the COBOL world proper, find reason for both. <g>
>

Never heard of it... so, obviously, "No..." :-)

(I just looked it up...interesting :-)).

> a
>
> I did not raise the issues, I merely responded to what I
> understood the issues to be. First, "it would require me
> to use the 'OF' clause way too often"; and, second,
> "Even more typing!".
>
> is
>
> It seems to me that the COBOL file system may be
> useful for "getting a solution to the problem as quickly
> as possible". As I understand your prior comments
> concerning the COBOL file system, "all that matters"
> does not always include the notion "as quickly as
> possible". Of course, it really depends on the problem,
> does it not? <g>
>

Ah, I touched a nerve... :-)

There is no development speed gain in using the COBOL file system over using
RDBMS, FOR SOMEONE WHO IS FACILE WITH BOTH. (For someone who is NOT facile
with both, all solutions look like a nail... :-))

On some sites there are political considerations as to why you wouldn't use
RDBMS (going through the DBAs can be very counter-productive and leads to
appalling solutions that are developed just to avoid doing this... Smart
sites streamline this process and ensure that DBAs and Architects have
better things to do than worry about temporary DB creation.) Given that you
can create what you like and get approval to make it permanent later, then
the political considerations should not be allowed to affect solution design
and implementation.

The main downside to the COBOL file system is that you need to write a COBOL
program to access it.

In terms of development time I contend there is little or no difference, and
the RDBMS solution has many advantages over the COBOL file system.
(Openness, flexibility, and ubiquity are three that spring immediately to
mind...)

> the
>
> As I said before, I did not raise the issues; but, if I find
> too many OFs affecting my focus, I know of a means
> to maintain that focus--one that may take fewer
> keystrokes. <g>
>
Fair enough :-).

Pete.
>
>

2007-01-11, 7:55 am

In article <50l73jF1gnqnuU1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:

[snip]

>It's a funny thing, in forty years of writing COBOL all around the world I
>have never seen a 66 RENAMES used in a production program.

I mentioned, in another posting, an aesthetic opposition to the 66... I
saw it in Prod once, implemented by a fellow who was combining
job-security via idiosyncratic knowledge with 'Gee, Mom, I'm a
Programmer!' coding.

[snip]

>Do you really think that COBOL programmers should be assessing how many
>characters they will type with various approaches, and that this should be a
>serious consideration when developing application code?
>
>It's fine for ivory tower theorising; on the shop floor all that matters is
>getting a solution to the problem as quickly as possible.

My clients pay me for doing the latter, Mr Dashwood, and it is a matter of
duty and honor for me to do my best to supply them with what they are
paying me for... and, at times, *just* a little bit more. My mentioning
this, in another posting, caused... someone to compare me with a
practioner of what is considered, in many times and places, a
less-than-honorable profession.

The money, as mentioned there, is green and has pictures of dead
Presidents on it.
>
>My experience has been that ANYTHING which requires me to change my focus
>from the specific problem at hand, is counter productive.

How interesting... I've found more than once that stepping back from a
situation, looking at it from another angle or 'changing my focus' on it
allows me to come up with a solution which others have called
'superior'... I may have mentioned that, somewhere, a while back...
ahhhhh, there it is, from
<http://groups.google.com/group/comp...b7?dmode=source>

--begin quoted text:

I was once asked to put together some routines to calculate valid
Business Days... across different countries. I said 'Hmmmm, how
interesting... I think I'll head out for a smoke' and out I went. I sat
next to George Washington's statue (this was on Wall St) and I had *two*
smokes... I then went back, pounded on my keyboard, printed out some...
stuff and walked into the project leader's office for the following
interchange:

Me: 'Here's the print-outs, the source is in (libname)... give it to
Jimmy and see if he can break my code in testing it.'

PL: "oh... we gave that to Bob to do because you didn't get Right To
It."

Me: "Hmmmm, of *course* I did not get Right To It, I had to *think*...
so I went out for a smoke. Tell me... is Bob ready for testing yet?"

PL: "Ummmm.... no."

Me: "Maybe he should have stepped out for a smoke, too."

--end quoted text

[snip]

>People who are still using COBOL need to stay focused on problem solution,
>not assessing how many key depressions they must make in order to cut a
>solution.

In my experience, Mr Dashwood, people who are doing things which require
what many call 'thinking' find problem solutions in unexpected places...
I've been surprised what useful things have come to my mind while I take
my morning shower.

DD

Howard Brazee

2007-01-11, 6:55 pm

On Thu, 11 Jan 2007 13:15:54 +0000 (UTC), docdwarf@panix.com () wrote:

>The money, as mentioned there, is green and has pictures of dead
>Presidents on it.

I remember when money was like that - it was actual paper, not just
some numbers in a computer.

Not that paper is worth any more than numbers in a computer.

2007-01-11, 6:55 pm

In article <7hncq25h0l4olotm135ne2inu4qggpop24@4ax.com>,
Howard Brazee <howard@brazee.net> wrote:
>On Thu, 11 Jan 2007 13:15:54 +0000 (UTC), docdwarf@panix.com () wrote:
>
>
>I remember when money was like that - it was actual paper, not just
>some numbers in a computer.

Curious that you should mention that... decades on back, when I started
working with Large Financial Organisations, it came to me that dealing
with money needed a particular set of skills, such as the ability to
differentiate between coins and notes of various denominations, the
ability to shift these items around, count them, make change...

.... but that the farther one got from dealing with these artifacts the
higher one's pay was. A cashier deals with money and such folks don't, in
my experience, earn large sums... even the folks who work in the Mint or
the Bureau of Printing and Engraving, stamping out coins or sheets of
bills, weren't what I would call all-that-highly-paid...

.... but the people who worked with the 'concept' of money, folks like
programmers - for whom a firm's money is numbers on a computer - or
stock-traders, or those who broker Large Deals between organisations,
where no pictures of dead Presidents are involved... just numbers
scribbled on a sheet of paper, or entered into a computer, or shouted at
each other over the telephone...

.... these folks earned more. The more distance there was between you and
the physical artifacts, the more you earned.

I'm sure there is a Very Good Reason for this.

>Not that paper is worth any more than numbers in a computer.

I'm not sure how you are using the word 'worth' here. I've been in
situations where greenbacks are necessary and establishments where a sign
over the cash-register reads 'Cash Only - No Credit Cards'; at such times
and in such places one needs pictures of dead Presidents in order to
effect a transaction.

DD

Howard Brazee

2007-01-11, 6:55 pm

On Thu, 11 Jan 2007 18:53:30 +0000 (UTC), docdwarf@panix.com () wrote:

>... but that the farther one got from dealing with these artifacts the
>higher one's pay was. A cashier deals with money and such folks don't, in
>my experience, earn large sums... even the folks who work in the Mint or
>the Bureau of Printing and Engraving, stamping out coins or sheets of
>bills, weren't what I would call all-that-highly-paid...

Bank cashiers quickly come to think of what they are working with as
dirty paper.

>I'm not sure how you are using the word 'worth' here. I've been in
>situations where greenbacks are necessary and establishments where a sign
>over the cash-register reads 'Cash Only - No Credit Cards'; at such times
>and in such places one needs pictures of dead Presidents in order to
>effect a transaction.

I don't remember the last time I was in such a situation. Pretty
much paper cash serves the same function as loose change: Useful
for small transactions only.

2007-01-11, 6:55 pm

In article <lp2dq2db60121vv625bm4ta3nvjdad80f3@4ax.com>,
Howard Brazee <howard@brazee.net> wrote:
>On Thu, 11 Jan 2007 18:53:30 +0000 (UTC), docdwarf@panix.com () wrote:

[snip]

>
>I don't remember the last time I was in such a situation.

I don't, either, but my memory is, admittedly, porous... and I have a
tendency to pay in cash so the situation isn't one that I pay much
attention to.

>Pretty
>much paper cash serves the same function as loose change: Useful
>for small transactions only.

Once again, I do not know how you are using the word 'small' here... a
puff of dust can be said to be 'small' but when it gets in one's eyes
while driving the effects can be life-changing.

DD

Sponsored Links