until greater than
Ross Klatte
...
108210 01 WS-ACCT-SS PIC 9(02).
108230 01 WS-DEPT-SS PIC 9(02).
...
108300 01 WS-ROW-COLUMN-TABLE.
108500 05 WS-ROW-ACCT OCCURS 1 TO 99 TIMES
108520 DEPENDING ON
108550 WS-MAX-ACCTS.
108700 10 WS-ROW-DEPT OCCURS 5 TIMES.
108900 15 WS-ACCT-DEPT-AMOUNT PIC 9(07).
...
316300 PERFORM 100-INITIALIZE-AMOUNT-TABLE
316500 THRU 100-INITIALIZE-AMOUNT-TABLE-EXIT
316700 VARYING WS-ACCT-SS FROM 1 BY 1
316900 UNTIL WS-ACCT-SS > WS-MAX-ACCTS
317100 AFTER WS-DEPT-SS FROM 1 BY 1
317300 UNTIL WS-DEPT-SS > 4.
...
344400 100-INITIALIZE-AMOUNT-TABLE.
344500 MOVE ZERO TO
344700 WS-ACCT-DEPT-AMOUNT (WS-ACCT-SS WS-DEPT-SS).
344800 100-INITIALIZE-AMOUNT-TABLE-EXIT.
-------------------------------------------------------------
This code was used without incident until WS-MAX-ACCTS
eventually reached 99, at which point it promptly blew up with
ASSERTION FAILURE ON RANGE TEST @ (Expression out of range 6600).
It was salvaged by changing WS-MAX-ACCTS to a 3-digit number.
But I found this philosophically unpleasant. I thought that
it should remain as a 2-digit number, especially as there
are only two bytes in the output file's field.
I can't say "until WS-ACCT-SS = WS-MAX-ACCTS" because then
I lose the last iteration.
This is quite simple using GO TO, but I would like to use
structured 85 code.
Any elegant suggestions?
Ross
http://community.webshots.com/user/ross_klatte
stringer
If so, try:
>316300 PERFORM 100-INITIALIZE-AMOUNT-TABLE
>316500 THRU 100-INITIALIZE-AMOUNT-TABLE-EXIT
>
>316700 VARYING WS-ACCT-SS FROM 1 BY 1 WITH TEST AFTER
>316900 UNTIL WS-ACCT-SS IS GREATER THAN OR EQUAL TO WS-MAX-ACCTS
Strictly speaking, you don't need the greater than test, but it might save your
backside in the event of an unforseen bug!
In article <20020522201039...@mb-ck.aol.com>, klatt...@aol.commmm
says...
William M. Klein
Given
"Ross Klatte" <klatt...@aol.commmm> wrote in message
news:20020522201039...@mb-ck.aol.com...
> 108202 01 WS-MAX-ACCTS PIC 9(02) VALUE 99.
> ...
> 108210 01 WS-ACCT-SS PIC 9(02).
> ...
<snip>
> ...
> 316300 PERFORM 100-INITIALIZE-AMOUNT-TABLE
...
> 316700 VARYING WS-ACCT-SS FROM 1 BY 1
> 316900 UNTIL WS-ACCT-SS > WS-MAX-ACCTS
Please tell me what "valid" value of WS-ACCT-SS (defined as PIC
9(02)
will EVER be greater than the value of WS-MAX-ACCTS (defined as PIC 9(02) -
with a value of "99")
Bottom-Line:
*only* 3-digit numbers can ever be greater than the two digit number "99"
Richard Plinston
>...
>108210 01 WS-ACCT-SS PIC 9(02).
>316300 PERFORM 100-INITIALIZE-AMOUNT-TABLE
>316500 THRU 100-INITIALIZE-AMOUNT-TABLE-EXIT
>316700 VARYING WS-ACCT-SS FROM 1 BY 1
>316900 UNTIL WS-ACCT-SS > WS-MAX-ACCTS
>344500 MOVE ZERO TO
>
>344700 WS-ACCT-DEPT-AMOUNT (WS-ACCT-SS WS-DEPT-SS).
> I thought that
> it should remain as a 2-digit number, especially as there
> are only two bytes in the output file's field.
> >Any elegant suggestions?
MOVE ZERO TO WS-Acct-SS
PERFORM ..
UNTIL WS-Acct-SS = WS-Max-Accts
...
ADD 1 TO WS-Acct-SS
MOVE ... TO WS-Acct-Dept-Amount(WS-Acct-SS ..)
This can be made to work but 'elegent' ?
Just get over it and make all these counters and limits as PIC S9(8).
It is better to make it work rather than piss around with a few bytes.
Otherwise you will spend half your life chasing down avoidable bugs
while trying to save a byte or two.
If it is 'elegence' you want then dump the THRU and the ~EXIT and think
about how to make it work without the crutch of having a GO TO available
if it all gets 'too hard'.
Willem Clements
>108202 01 WS-MAX-ACCTS PIC 9(02) VALUE 99.
>....
>108210 01 WS-ACCT-SS PIC 9(02).
>108230 01 WS-DEPT-SS PIC 9(02).
>....
>108300 01 WS-ROW-COLUMN-TABLE.
>108500 05 WS-ROW-ACCT OCCURS 1 TO 99 TIMES
>108520 DEPENDING ON
>
>108550 WS-MAX-ACCTS.
>108700 10 WS-ROW-DEPT OCCURS 5 TIMES.
>108900 15 WS-ACCT-DEPT-AMOUNT PIC 9(07).
>....
>316300 PERFORM 100-INITIALIZE-AMOUNT-TABLE
>316500 THRU 100-INITIALIZE-AMOUNT-TABLE-EXIT
>
>316700 VARYING WS-ACCT-SS FROM 1 BY 1
>316900 UNTIL WS-ACCT-SS > WS-MAX-ACCTS
>317100 AFTER WS-DEPT-SS FROM 1 BY 1
>317300 UNTIL WS-DEPT-SS > 4.
>....
>344400 100-INITIALIZE-AMOUNT-TABLE.
>
>344500 MOVE ZERO TO
>344700 WS-ACCT-DEPT-AMOUNT (WS-ACCT-SS WS-DEPT-SS).
>344800 100-INITIALIZE-AMOUNT-TABLE-EXIT.
>-------------------------------------------------------------
>This code was used without incident until WS-MAX-ACCTS
>eventually reached 99, at which point it promptly blew up with
>ASSERTION FAILURE ON RANGE TEST @ (Expression out of range 6600).
>
>It was salvaged by changing WS-MAX-ACCTS to a 3-digit number.
>But I found this philosophically unpleasant. I thought that
>it should remain as a 2-digit number, especially as there
>are only two bytes in the output file's field.
>I can't say "until WS-ACCT-SS = WS-MAX-ACCTS" because then
>I lose the last iteration.
>This is quite simple using GO TO, but I would like to use
>structured 85 code.
>
>Any elegant suggestions?
>
Why not simply
MOVE ALL '0' TO WS-ROW-COLUMN-TABLE.
Willem Clements
Brainbench MVP for COBOL II
http://www.brainbench.com
-----------== Posted via Newsfeed.Com - Uncensored Usenet News ==----------
http://www.newsfeed.com The #1 Newsgroup Service in the World!
-----= Over 100,000 Newsgroups - Unlimited Fast Downloads - 19 Servers =-----
Sff5ky
>This code was used without incident until WS-MAX-ACCTS
>eventually reached 99, at which point it promptly blew up with
>ASSERTION FAILURE ON RANGE TEST @ (Expression out of range 6600).
>
How is your WS-ACCT-SS ever supposed to be greater than WS-MAX-ACCTS
if both counters are 2-digit numbers and MAX gets set to 99?
Your reasoning for 2-digits on WS-MAX-ACCTS would also require that
WS-DEPT-SS be a 1-digit field as the ROW occurs only 5 times within each
of the ACCT rows.
Terry Heinze
"Ross Klatte" <klatt...@aol.commmm> wrote in message
news:20020522201039...@mb-ck.aol.com...
Howard Brazee
On 22-May-2002, stri...@es.co.nz (stringer) wrote:
> >316900 UNTIL WS-ACCT-SS IS GREATER THAN OR EQUAL TO WS-MAX-ACCTS
> >
>
> Strictly speaking, you don't need the greater than test, but it might save
> your
> backside in the event of an unforseen bug!
>
> In article <20020522201039...@mb-ck.aol.com>,
> klatt...@aol.commmm
> says...
> >
> >108202 01 WS-MAX-ACCTS PIC 9(02) VALUE 99.
> >...
> >108210 01 WS-ACCT-SS PIC 9(02).
> >
> >108230 01 WS-DEPT-SS PIC 9(02).
> >
> >...
> >108300 01 WS-ROW-COLUMN-TABLE.
> >
> >108500 05 WS-ROW-ACCT OCCURS 1 TO 99 TIMES
> >108520 DEPENDING ON
> >
>
> >
> >108550 WS-MAX-ACCTS.
I always loop "UNTIL GREATER THAN", as you say it might save your backside.
But in this case it could be a contributor to a bug! What happens when
WS-MAX-ACCTS = 99 and you increment WS-ACCT-SS from 99 to 00?
Howard Brazee
On 23-May-2002, Richard Plinston <rip...@Azonic.co.nz> wrote:
> Just get over it and make all these counters and limits as PIC S9(8).
> It is better to make it work rather than piss around with a few bytes.
> Otherwise you will spend half your life chasing down avoidable bugs
> while trying to save a byte or two.
If he wants to be efficient, he doesn't want a subscript to be DISPLAY
anyway. The only reason to use USAGE IS DISPLAY is to make the subscript
easier to read in a dump or DISPLAY command.
James J. Gavan
Following this thread - I'll go with Richard's, "don't piss around"
versus your *efficiency*. Had he gone Richard's route you wouldn't have
needed to comment in previous message, "What happens when WS-MAX-ACCTS =
99 and you increment WS-ACCT-SS from 99 to 00?" Same goes for Bill's
comment - KISS.
Jimmy, Calgary AB
Alain.Feler
(MS-Cobol V4.5, in fact an old Microfocus Cobol for Dos sold by Microsoft).
I once got an execution time divided by 4 only replacing an initialize by
move spaces to the same array ( pic x occurs 9000)...
Speaking of 85 style, I would prefer:
77 MAX-ACCTS PIC 9(4) binary VALUE 99.
77 ACCT-SS PIC 9(4) binary value 0.
77 DEPT-SS PIC 9(4) binary value 0.
01 ROW-COLUMN-TABLE.
05 ROW-ACCT OCCURS 1 TO 99 TIMES
DEPENDING ON MAX-ACCTS.
10 ROW-DEPT OCCURS 5 TIMES.
15 ACCT-DEPT-AMOUNT PIC 9(07).
...
perform 100-INITIALIZE-AMOUNT-TABLE
...
100-INITIALIZE-AMOUNT-TABLE.
perform varying acct-ss from 1 by 1 until acct-ss > ws-max-accts
perform varying dept-ss from 1 by 1 until dept-ss > 4
move 0 to acct-dept-amount(acct-ss dept-ss)
end-perform
end-perform
.
Terry Heinze <terry...@prodigy.net> a écrit dans le message :
fD4H8.1336$F_4.73...@newssvr16.news.prodigy.com...
Ross Klatte
just what the doctor ordered. It worked perfectly, and has a cryptic
quality fully in the spirit of modern COBOL.
Shop standards rule out some of the good ideas, such as making
subscripts binary. Also ruled out was making the 4-row table have
a one-digit subscript; all subscripts have to be at least 2 digits.
INITIALIZE ROW-COLUMN-TABLE gives me a syntax error.
I think "MOVE ALL ZERO" would be acceptable, but it doesn't
look very cool.
Most annoying of all, the standards rule out leaving out the
table initialization code all together; it is a batch program running
on a Unisys box. But leaving out the manual initialization frightens
all the IBM-trained programmers, and there are a lot of those.
Along the same lines, I don't really approve of the part about
"OCCURS ... DEPENDING" either. I don't know what IBM does,
but Unisys goes ahead and allocates 99 in memory; so I don't
see where anything is gained (other than coolness).
>From: "Alain.Feler" Alain...@wanadoo.fr
>Date: 5/23/2002 4:10 PM Eastern Daylight Time
>Message-id: <acjieo$2ek$1...@wanadoo.fr>
>
>Initialize is very convenient, but very slow, at least with my compiler
>(MS-Cobol V4.5, in fact an old Microfocus Cobol for Dos sold by Microsoft).
>I once got an execution time divided by 4 only replacing an initialize by
>move spaces to the same array ( pic x occurs 9000)...
Personally, I like INITIALIZE for a record, where everything is all
higgledy-piggledy. But I don't like it for a table of all zeroes, or a
table of all spaces. I intend to use it, but I don't like it.
Ross
http://community.webshots.com/user/ross_klatte
stringer
the original code.
I agree with other posters that it would be better if he used
Pic 999 (or greater), or put in code to ensure the counter would not increment
beyond 99 and a flag to pick up any such attempt and allow a break
from the perform.
In article <acitqc$a7$1...@peabody.colorado.edu>, howard...@cusys.edu says...
Jnjsle
"cryptic quality"...."doesn't look very cool"...., Jesus. The most elegant
solutions are the simplest, not to mention in this case, the most efficient.
But why am I talking efficiency and elegance to a man who uses display integers
for subscripts?
Ross Klatte
>Date: 5/23/2002 10:54 PM Eastern Daylight Time
>Message-id: <20020523225452...@mb-ft.aol.com>
In this thread you have not breathed a word either about efficiency
or about elegance. Your only contribution is apparently some sort
of religious invocation.
Ross
http://community.webshots.com/user/ross_klatte
Michael Mattias
> Shop standards rule out some of the good ideas, such as making
> subscripts binary. Also ruled out was making the 4-row table have
> a one-digit subscript; all subscripts have to be at least 2 digits.
Subscripts must not be binary is a shop standard? All subscripts must be at
least TWO digits is a shop standard (or is that subscript PICTURE clause)?
Whomever sets the standards needs to move forward a tad; oh, say, about
twenty-five years or so....
MCM
Russell Styles
seem to exist with OBJ/GNT programs. (Microfocus 3.1).
Alain.Feler" <Alain...@wanadoo.fr> wrote in message
news:acjieo$2ek$1...@wanadoo.fr...
JerryMouse
"Jnjsle" <jnj...@aol.com> wrote in message
news:20020523225452...@mb-ft.aol.com...
Why not? As has been proven here many times, the efficiency difference
between display, binary, subscripts, and indexes makes no observable
difference in execution speed (but sometimes a great deal of difference in
program maintenance and the prevalence of bugs).
Anonymous
"JerryMouse" <nos...@invalid.com> wrote in message
news:gRrH8.5476$%o.46...@bin3.nnrp.aus1.giganews.com...
If that is true, then the combined observation powers of the group is
suspect.
Donald Tees
"JerryMouse" <nos...@invalid.com> wrote in message
news:gRrH8.5476$%o.46...@bin3.nnrp.aus1.giganews.com...
>
My feelings exactly. I use nothing but display usage, sign leading
separate, and have for years. I am a lot more concerened about ME being
efficient that my computer, my time is more valuable than my computers'.
Donald
Donald Tees
>
> "JerryMouse" <nos...@invalid.com> wrote in message
> news:gRrH8.5476$%o.46...@bin3.nnrp.aus1.giganews.com...
> >
> > "Jnjsle" <jnj...@aol.com> wrote in message
> > news:20020523225452...@mb-ft.aol.com...
> > >
> > > "cryptic quality"...."doesn't look very cool"...., Jesus. The most
> elegant
> > > solutions are the simplest, not to mention in this case, the most
> > efficient.
> > > But why am I talking efficiency and elegance to a man who uses display
> > integers
> > > for subscripts?
> >
> > Why not? As has been proven here many times, the efficiency difference
> > between display, binary, subscripts, and indexes makes no observable
> > difference in execution speed (but sometimes a great deal of difference
in
> > program maintenance and the prevalence of bugs).
> >
> >
>
> If that is true, then the combined observation powers of the group is
> suspect.
>
Or that you have very little experience beyond large scale batch processing.
I will bet you cannot find a single transaction at a time program where it
makes a tinker's damn worth of difference.
Donald
Howard Brazee
On 24-May-2002, "Donald Tees" <donal...@sympatico.ca> wrote:
> My feelings exactly. I use nothing but display usage, sign leading
> separate, and have for years. I am a lot more concerened about ME being
> efficient that my computer, my time is more valuable than my computers'.
Also, there is another thread with someone having an ASCII file with COMP-3
data that does not look familiar to me. He's not a CoBOL programmer. If
that file had been created as you suggest, a character FTP would have
worked, and he wouldn't need to be asking us how to translate.
This is costly.
Howard Brazee
On 24-May-2002, "Donald Tees" <donal...@sympatico.ca> wrote:
> > If that is true, then the combined observation powers of the group is
> > suspect.
> >
>
> Or that you have very little experience beyond large scale batch
> processing.
Not necessarily - as long as we have experience within large scale batch
processing, we should have tested & observed the difference.
> I will bet you cannot find a single transaction at a time program where it
> makes a tinker's damn worth of difference.
True - but we're allowed to observe other kinds of programming.
JerryMouse
"Anonymous" <Nobody> wrote in message news:3ceda6f0_3@anonymous...
>
> news:gRrH8.5476$%o.46...@bin3.nnrp.aus1.giganews.com...
> >
> > "Jnjsle" <jnj...@aol.com> wrote in message
> > news:20020523225452...@mb-ft.aol.com...
> > >
> > > "cryptic quality"...."doesn't look very cool"...., Jesus. The most
> elegant
> > > solutions are the simplest, not to mention in this case, the most
> > efficient.
> > > But why am I talking efficiency and elegance to a man who uses display
> > integers
> > > for subscripts?
> >
> > Why not? As has been proven here many times, the efficiency difference
> > between display, binary, subscripts, and indexes makes no observable
> > difference in execution speed (but sometimes a great deal of difference
in
> > program maintenance and the prevalence of bugs).
> >
> >
>
> If that is true, then the combined observation powers of the group is
> suspect.
There's no need to rely on the wisdom of the sages or the ages: test it
yourself.
Couple of perform loops, couple of calls to the clock - Bingo! the answer
appears.
Anonymous
> There's no need to rely on the wisdom of the sages or the ages: test it
> yourself.
>
> Couple of perform loops, couple of calls to the clock - Bingo! the answer
> appears.
>
Microseconds saved per online transaction times millions of transactions
results in runtime cost savings that eventually will pay for your next
raise, assuming of course you can convince someone you deserve one, which is
getting harder and harder to do.
I wouldn't be surprised if I have more years of online transaction
experience than the bulk of the visitors to this newsgroup have had
birthdays. Yet rarely does a day pass but what I don't learn even more
efficient ways to do things. I refuse to be a dinosauer stuck in the days
of punched cards and paper tape ... I require it of myself to stay on the
leading edge of technology.
It has been my observation over the years that, with each new generation of
coder knowing less and less about what is "under the hood" when their code
is compiled, and with computers getting faster and faster, the coders tend
to get sloppier and sloppier. Eventually you get to the point where coders
produce bloated code like ... well, Microsoft products are a good example of
needlessly bloated code. And I attribute that to the new breed of coder who
does not see the need to code for runtime efficiency. After all, the
computers keep getting faster and faster ...
I also have discovered over the years that coding for runtime efficiency,
and coding for efficiency in maintenance, ARE NOT mutually exclusive goals,
but in fact the two go hand and hand quite well to produce a superior
product.
Liam Devlin
What's philosophically unpleasant about 3 bytes?
> I thought that
> it should remain as a 2-digit number, especially as there
> are only two bytes in the output file's field.
Poor file sizing, right? :-)
> I can't say "until WS-ACCT-SS = WS-MAX-ACCTS" because then
> I lose the last iteration.
> This is quite simple using GO TO, but I would like to use
> structured 85 code.
I'm surprised no one's suggested:
PERFORM WITH TEST AFTER
VARYING WS-ACCT-SS FROM 1 BY 1
UNTIL WS-ACCT-SS = WS-MAX-ACCTS
AFTER WS-DEPT-SS FROM 1 BY 1
UNTIL WS-DEPT-SS > 4
MOVE ZERO TO
WS-ACCT-DEPT-AMOUNT (WS-ACCT-SS WS-DEPT-SS)
END-PERFORM
You can decide how elegant it is. If you've grown to 99 accounts,
what happens when you get one more? As someone else pointed out,
DISPLAY subscripts are inefficient, so you could make them
Pic S9999 Binary and keep them 2 bytes.
Or, how about:
Initialize WS-ROW-COLUMN-TABLE
Liam Devlin
Or out the door, as described in Docdwarf's previous post.
Donald Tees
> >
> > There's no need to rely on the wisdom of the sages or the ages: test it
> > yourself.
> >
> > Couple of perform loops, couple of calls to the clock - Bingo! the
answer
> > appears.
> >
>
> Microseconds saved per online transaction times millions of transactions
> results in runtime cost savings that eventually will pay for your next
> raise, assuming of course you can convince someone you deserve one, which
is
> getting harder and harder to do.
yawn. pay for "your" next machine? You know me and my boss? Or you are
just one of those people that expects everybody to be just like you, every
computer to be just like yours, every application to fit your program?
Peculiar mindset for a programmer.
>
> I wouldn't be surprised if I have more years of online transaction
> experience than the bulk of the visitors to this newsgroup have had
> birthdays. Yet rarely does a day pass but what I don't learn even more
> efficient ways to do things. I refuse to be a dinosauer stuck in the days
> of punched cards and paper tape ... I require it of myself to stay on the
> leading edge of technology.
I would. I'm at my 35 year mark. I am one of the beginners. As a
programmer that is. If you are claiming to be leading edge in every data
processing technical area, you are a liar. BTW, I got rid of my paper tape
home machine in 1975 or so. It was a PDP-8.
what is "under the hood" when their code
> is compiled, and with computers getting faster and faster, the coders tend
> to get sloppier and sloppier. Eventually you get to the point where
coders
> produce bloated code like ... well, Microsoft products are a good example
of
> needlessly bloated code. And I attribute that to the new breed of coder
who
> does not see the need to code for runtime efficiency. After all, the
> computers keep getting faster and faster ...
>
There area dozens of people in here that have coded in dozens of assemblers.
You are the one that does not know that, as you are the newcomer. Sounds
like you are a beginner too. Decided to read one of the technical
newsgroups finally. How state of the art. You are even learning to blame
MS for everything. Pretty soon, you will be up to 1990.
> I also have discovered over the years that coding for runtime efficiency,
> and coding for efficiency in maintenance, ARE NOT mutually exclusive
goals,
> but in fact the two go hand and hand quite well to produce a superior
> product.
>
If you think efficiency means changing PIC 99 to PIC 99 USAGE COMP, then you
have a lot to learn still.
Donald
docd...@panix.com
Here I must pause, Mr Devlin, and say...
... hmmmmmm... I dunno.
A case of ossified shop standards can be seen more than one way. Compare:
'If it ain't broke, don't fix it'
... with ...
'If you don't change your habits of diet and exercise you're going to get
a heart attack'
Obviously one can never be certain when another person is going to suffer
a cardiac episode - after all, anyone can, at any time, get hit by a bus -
but the studies which link diet, exercise and increased life expectancy
are there for all to read.
Likewise... is it possible to say 'This company failed because the COBOL
coding standards in their DP/IS/IT/whatever the acronym is now shop hadn't
been changed in a quarter-century'? I doubt that it is possible to say so
with precision.
In an organisation there are those who have the authority and privlege to
establish direction... in large organisations such folks are called
Executives. In, say, Mr Dilworth's company he is the final authority on
coding standards; if he wants something that will compile under the rules
for COBOL '68 then so be it... it is *his* shop. If he is able to
maintain a running business that meets his needs and desires while
remaining within his restrictions, well and good and more power to him...
it does not, of course, change the fact that he has apparently been doing
the same thing for the past few decades and seems... resistant to any
alternative methods.
(Consider the dispenser of gasoline/petrol... except for minor changes in
equipment the essence of the job hasn't changed in a goodly while, one
finds a location, sets up a shack, tank and pump and waits for motorists.
Certainly one can earn more money by adding features, such as a mechanic
or a shop selling packages of excessively-salted carbohydrates... but the
guts of it, the shack, tank and pump are the same.)
On the other hand... things in a business rarely exist in vacuo and the
Russian proveb has it 'a fish rots from the head' (which isn't really
true... I would imagine that putrefaction would begin in the lower
intestines, where things are turning to excrement anyhow... but I
digress). As was noticed by, among others, Sir Thomas Gresham: when there
exists in circulation two kinds of money, one bad and one good, then bad
money will drive good money out of the marketplace. This is still debated
to this day by financiers, economists and Other Worthy Folks but I have
noticed a slight variation applicable to the workplace, a sort of
Gresham's Law of Management: when there exists in a workplace two kinds of
management, one bad and one good, then bad management will drive good
management out of the workplace.
Given, then, the fact that there is a workplace with COBOL-coding
standards which neglect a quarter-century of change... and that these
standards have the support of management... and that things in a business
rarely exist in vacuo... and that Gresham's Law of Management is a
phenomenon which has been observed...
... then it might be, perhaps, a Good Conclusion that someone should move
out the door, as Mr Devlin suggested.
The question then becomes, however... who?
DD
Anonymous
> If you think efficiency means changing PIC 99 to PIC 99 USAGE COMP, then
you
> have a lot to learn still.
>
> Donald
>
I'm sure I do, and as I previously said, I probably learn something new
every day. One tends to do that, unless one is standing still, stagnating.
However, if you are going to do a lot of computations on the PIC 99, and you
think it is efficient to have to generate and execute extra instructions to
put it into a form that the computer can do the computation on, then perhaps
you haven't learned as much in 35 years as you think. I have met a lot of
people with 1 year of experience, repeated 35 times.
Perhaps the reason clients pay so highly for my services is because I "still
have a lot to learn." That's also probably what qualifies me for the
performance tuning contract I'm currently on.
And yes, I do think that changing PIC 99 to a suitable computational form
plays a small role in runtime efficiency. Not only do I think it, I also
know it.
James J. Gavan
Anonymous wrote:
> >
> > If you think efficiency means changing PIC 99 to PIC 99 USAGE COMP, then
> you
> > have a lot to learn still.
> >
> > Donald
> >
>
> I'm sure I do, and as I previously said, I probably learn something new
> every day. One tends to do that, unless one is standing still, stagnating.
>
> However, if you are going to do a lot of computations on the PIC 99, and you
> think it is efficient to have to generate and execute extra instructions to
> put it into a form that the computer can do the computation on, then perhaps
> you haven't learned as much in 35 years as you think. I have met a lot of
> people with 1 year of experience, repeated 35 times.
>
> Perhaps the reason clients pay so highly for my services is because I "still
> have a lot to learn." That's also probably what qualifies me for the
> performance tuning contract I'm currently on.
>
> And yes, I do think that changing PIC 99 to a suitable computational form
> plays a small role in runtime efficiency. Not only do I think it, I also
> know it.
Ahhh. So now the above plays a SMALL ROLE in runtime efficiency, plus "I also
know it". Others have illustrated in here with timings. If you are truly
concerned about the youngsters in here using the efficiencies you deem,
illustrate with some PERFORM cycle code, plus the timings.
I would also take one step backwards. The systems design, (programming is the
second phase), has a major impact on the machine usage. An application is
perceived, then spec'ed and you finish up with a neat rectangular box containing
your design. The speed at which current systems become obsolete/inefficient is
impacted by the increasing pace of business needs/technology. Now bits start to
get added on to that rectangular box and you finish up with a octagonal shape -
still does the job, but messy. The last recourse is a completely fresh design,
meeting today's needs, plus hopefully, allowing a let-out for some of tomorrow's
needs.
Contractually you are into fine tuning, (and I'm assuming this is just 'fine
tuning', not re-design); I would suggest the installation, regardless of size, is
being a bit backward having to call in an outside resource on this one. Given
they have a Maintenance Department (team) fine tuning should be an element they
should be covering.
My own reasoning on that - EDP staff are EXPENSIVE. A project is designed, and
programmed and there is always a planned finish date. This means work allocated
to programmers is given a target date for completion. The Chief Programmer
(whatever fancy title is currently used), will delegate tasks, having evaluated
how many man-weeks, months it should take to do. The individual may produce a
very workable program, but would *really* have liked, perhaps one or two more
weeks to make it zing by looking for efficiencies. The budget/timescale just
doesn't allow for this.
Having proven the application and got it up and running, then my contention, it
is Maintenance Department which should view source to see where they can re-group
procedures and do the fine tuning that they are obviously paying you big bucks to
do <G>
In passing, you took a swipe at Microsoft and others for bloat. I don't disagree,
but pic 9(02) versus pic 9(02) comp-3 has nothing to do with bloat. Ironically,
I speculate the type of bloat we see in Windoze products is because of OO. Huh ?
The bright eyed and bushy-tailed, including the geeks at the U. of Bellingham,
Wa., are using OO - I have no proof - but they are probably breaking the cardinal
rule of OO - REUSABILITY. I'll wager there is a lot of 'copy and paste', rather
than, with some forethought, getting into an OO design hierarchy that makes
polymorphism sing like a sweet bird.
Jimmy, Calgary AB
Richard Plinston
>
> However, if you are going to do a lot of computations on the PIC 99, and you
> think it is efficient to have to generate and execute extra instructions to
> put it into a form that the computer can do the computation on, then perhaps
> you haven't learned as much in 35 years as you think.
Actually it was 35 years ago that this sort of thing was absolutely
vital. When I was doing Cobol customer support for a mainframe company
around that time I would spend hours showing customers how to meet their
run-time needs on processors slower than my watch is now.
In very many cases on modern machinery, however, this sort of detailing
is quite irrelevant. The types of applications have changed, the ratio
of processor speed to programmer cost has inverted, mult-tasking,
interrupt driven multi-threading, disk caching, have all been invented.
There are now more important aspects to consider.
> And yes, I do think that changing PIC 99 to a suitable computational form
> plays a small role in runtime efficiency. Not only do I think it, I also
> know it.
I am sure that you can contrive suitable tests to demonstrate this, but
in real modern systems the cpu time and the disk access time are no
longer additive as they were 30 years ago and most systems spend most of
their time waiting for disk transfers to complete.
So while you claim to be 'up to date' and 'learning', you are merely
regurgitating 'wisdom' that was important several decades ago and is no
longer particularly relevant.
Yes, there are constructs that will generate slightly faster code.
These may be INDEX or COMP or BINARY or some other depending on the
actual machine the code will run on.
Will PIC 99 COMP be the 'best' code ? - not on my machine.
Will it make any improvement to my systems ? - no. The system
(multi-user) spends most of its time waiting for disk and has plenty of
spare CPU (around 40-80%). I would be much better spending my time on
reducing disk transfers, such as by using extra alternate keys where
this may save searches and sorts.
JerryMouse
"Anonymous" <Nobody> wrote in message news:3cee1f11_1@anonymous...
> >
> > There's no need to rely on the wisdom of the sages or the ages: test it
> > yourself.
> >
> > Couple of perform loops, couple of calls to the clock - Bingo! the
answer
> > appears.
> >
>
> Microseconds saved per online transaction times millions of transactions
> results in runtime cost savings that eventually will pay for your next
> raise, assuming of course you can convince someone you deserve one, which
is
> getting harder and harder to do.
5 microseconds saved per transaction x 5 million transactions / day = 25
seconds/day saved
Or at $100/hour for an engineer, about the cost of a donut. I guess it all
comes down to how important donuts are to you.
>
> I wouldn't be surprised if I have more years of online transaction
> experience than the bulk of the visitors to this newsgroup have had
> birthdays. Yet rarely does a day pass but what I don't learn even more
> efficient ways to do things. I refuse to be a dinosauer stuck in the days
> of punched cards and paper tape ... I require it of myself to stay on the
> leading edge of technology.
I'm glad you learn more efficient ways of doing things. What was the result
of the ten-line program I urged you to try for evaluating the actual time
difference between display and binary subscripts?
>
> It has been my observation over the years that, with each new generation
of
> coder knowing less and less about what is "under the hood" when their code
> is compiled, and with computers getting faster and faster, the coders tend
> to get sloppier and sloppier. Eventually you get to the point where
coders
> produce bloated code like ... well, Microsoft products are a good example
of
> needlessly bloated code. And I attribute that to the new breed of coder
who
> does not see the need to code for runtime efficiency. After all, the
> computers keep getting faster and faster ...
There IS less and less need to code for runtime efficiency because compilers
are MUCH smarter and operating systems are more efficient than before. In
fact, I wouldn't be surprised if prior techniques for operational efficiency
don't actually interfer with the compiler's optimization techniques!
For example, my compiler does something magical with ISAM files in that
loading an ISAM file from a text file generates a file considerably SMALLER
than the original text file.
(TEXT + INDEXES + OVERFLOW < TEXT?)
The ISAM routines are obviously compacting the data. Now I COULD have spent
man-months figuring out a hand-crafted compaction routine myself....
>
> I also have discovered over the years that coding for runtime efficiency,
> and coding for efficiency in maintenance, ARE NOT mutually exclusive
goals,
> but in fact the two go hand and hand quite well to produce a superior
> product.
You're right. Execution and maintenance efficiency are not - necessarily -
mutually exclusive. But which had you rather work on? Which has more bugs?
And which requires more maintenance?
Tim Scrivens
>
> "Anonymous" <Nobody> wrote in message news:3cee1f11_1@anonymous...
> > >
> > > There's no need to rely on the wisdom of the sages or the ages: test
it
> > > yourself.
> > >
> > > Couple of perform loops, couple of calls to the clock - Bingo! the
> answer
> > > appears.
> > >
> >
> > Microseconds saved per online transaction times millions of transactions
> > results in runtime cost savings that eventually will pay for your next
> > raise, assuming of course you can convince someone you deserve one,
which
> is
> > getting harder and harder to do.
>
> 5 microseconds saved per transaction x 5 million transactions / day = 25
> seconds/day saved
>
> Or at $100/hour for an engineer, about the cost of a donut. I guess it all
> comes down to how important donuts are to you.
And then, 5 microseconds per transaction, 5 million transactions. 25
seconds. 15 different batch programs, all with this - translates to an
extra 6 minutes a day.
Not important in terms of money, but if your batch window runs long - every
bit helps.
Jack Sleight
standing in the center of the room and nobody notices.
Why would anyone choose a perform varying routine with 2 levels in
preference to a move '0' or an initialize. From both perspectives
discussed here: programmer productivity and system efficiency, it
makes no sense.
Also, remember I said "efficiency" not "performance". In a mainframe
environment, where hundreds of jobs are running concurrently, choices
like the one made by Mr. Klatte, in aggregate, can have a significant
effect on CPU utilization, and by implication the cost of doing
business.
I've heard the line about per MIP and MEG costs plunging. But I
haven't heard many DP mgrs bragging about their H/W budgets plunging.
Because efficiency still makes sense, training yourself to code
efficiently makes sense too.
Granted in a "single transaction at a time" environment, these
efficiencies have little effect. I'd guess if you decided to perform
the process manually, it makes even less sense.
My apologies to Mr. Klatte, but that New Age B.S. just sets my teeth
on edge. "Cool", Jesus.
"Howard Brazee" <howard...@cusys.edu> wrote in message news:<acln84$l49$1...@peabody.colorado.edu>...
docd...@panix.com
Helps *what*, though... stave off the long-overdue re-analysis and rewrite
which might make the system more efficient? If your batch window is that
tight then maybe things need to be handled a little differently.
DD
William M. Klein
<docd...@panix.com> wrote in message news:acs25u$9k9$1...@panix1.panix.com... <snip>
> >
> >And then, 5 microseconds per transaction, 5 million transactions. 25
> >seconds. 15 different batch programs, all with this - translates to an
> >extra 6 minutes a day.
> >
> >Not important in terms of money, but if your batch window runs long -
every
> >bit helps.
>
> Helps *what*, though... stave off the long-overdue re-analysis and rewrite
> which might make the system more efficient? If your batch window is that
> tight then maybe things need to be handled a little differently.
>
> DD
>
Reminds me of a story from the days of "long ago and far away".
I had just been hired as a "medium-experienced" COBOL, CICS, IMS, ADF (don't
ask - if you never heard of this) programmer at the phone company. (To give
you an idea of how long ago this was, it was *THE* phone company).
My new manager meet me at the elevator and while walking me to my desk - and
before introducing me to my collogues, she informed me that they had just
finished a review of the new process/application that I was hired to work
on. The initial estimate was that the nightly batch run would take 26 hours
to run !!!
Needless to say, we did NOT get "right down" to coding that application and
did a little "re-design".
Post-Script to the humorous story.
I stayed working for that company (thru phone company divestiture and
various other "interesting" times) and went on to many other exciting jobs
(both involving COBOL and not) - from teaching "redundant" phone-operator
mangers to be entry level programmers to being a systems programmer.
However, about 3 years after I left the company (about 7 years after that
initial walk from the elevator), I heard that the company FINALLY cancelled
the entire (still not in production) project ... and went with an entirely
different solution to the problem. <G>
--
Bill Klein
wmklein <at> ix.netcom.com
Ross Klatte
>Date: 2002-05-26 21:05 Eastern Daylight Time
>Why would anyone choose a perform varying routine with 2 levels in
>preference to a move '0' or an initialize.
>choices
>like the one made by Mr. Klatte, in aggregate, can have a significant
>effect on CPU utilization
>My apologies to Mr. Klatte, but that New Age B.S. just sets my teeth
>on edge. "Cool", Jesus.
>
On the program in question, I am a maintenance programmer,
not a designer. Furthermore, I am a contractor, not an FTE.
Typically, a Unisys shop will have a number of programmers
who learned either on IBM or on C. These people make a
lot of mistakes on the COMP and COMP-n usages. The
"no binary, no packed" rule is there to better utilize these
people.
As I said earlier, my own choice would have been to eliminate
the manual initialization altogether; it is not necessary.
As I said earlier, I cannot INITIALIZE a table.
As I implied earlier, I would prefer MOVE ZEROES to the
table. In looking at other programs, I observed that this
code is not used. In every case, there is a routine
to move the zero one element at a time. I suspect, but
do not know, that this technique was settled upon in order
to eliminate arguments and errors resulting from the
exact behavior of MOVE ZEROES or MOVE 0 or MOVE
LOW-VALUES. My only legitimate interest in the code
is the fact that it undeniably blew up. It would be
politically and programmatically unwise to start
changing code that has proven itself in production, just
because I think that I know a better way.
This is the first time in my life that I have ever been
accused of being "new age." As a point of reference,
I voted for Barry Goldwater. I take the intended insult
as a great compliment. This dinosaur is evolving in place.
Today, the "WITH TEST AFTER." Tomorrow, the "ALSO.
Ross
http://community.webshots.com/user/ross_klatte
SkippyPB
While I understand what you are saying there Doc, there are instances
where the batch window is tight due to outside influences and not
because a process or a system is inefficient. Take a large bank that
is doing central processing and has branches in many states. If
you're central processor is based on the east coast, you've a 4 hour
delay to get all information from the west coast, hence you may not be
able to start your batch processing until 7-8 pm eastern standard. It
may be latter than that even based on when the ACH information is
transmitted from the Federal Reserve. And you need to have the
online files refreshed and ready for tellers on the east coast by
approximately 7-8 am eastern. Twelve hours may seem like a lot, but
it's not. A twitch in the process or program here or there and you're
in trouble.
Regards,
////
(o o)
-oOO--(_)--OOo-
Blessed are the flexible for they shall not be bent out of shape.~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Remove nospam to email me.
Steve
docd...@panix.com
A perfectly reasonable scenario... and one which might be resolved by,
say, decentralised processing or the kind of work done by any of the major
credit card companies.
Mr Trembley might want to step in here but as I understand it the
transaction volumes at Visa and MasterCard are a bit... healthier than
they are at most banking institutions *and* there is the added...
'challenge' of being *up* - and by *up* I intend 'responding really,
*really* fast so a news-stand in Kuala Lampur doesn't start to complain
that the cards take too long to validate' - twenty-four hours a day, seven
days a week and across *all* time-zones...
... so maybe they are using techniques which might be applicable to a bank
which spans, say, a mere five time-zones (Manhattan to Honolulu) and has
the whole weekend to straighten things out.
DD
Arnold Trembley
> (snip)
> A perfectly reasonable scenario... and one which might be resolved by,
> say, decentralised processing or the kind of work done by any of the major
> credit card companies.
>
> Mr Trembley might want to step in here but as I understand it the
> transaction volumes at Visa and MasterCard are a bit... healthier than
> they are at most banking institutions *and* there is the added...
> 'challenge' of being *up* - and by *up* I intend 'responding really,
> *really* fast so a news-stand in Kuala Lampur doesn't start to complain
> that the cards take too long to validate' - twenty-four hours a day, seven
> days a week and across *all* time-zones...
>
> ... so maybe they are using techniques which might be applicable to a bank
> which spans, say, a mere five time-zones (Manhattan to Honolulu) and has
> the whole weekend to straighten things out.
>
> DD
Actually, I'd prefer NOT to step in here, but yes, there are certain
challenges to running 24/7/365 and processing transactions in all
time-zones.
If you go to google and search for "ZDnet Visa settlement system new
replacement", you might find an interesting article. Unfortunately
there's no COBOL, since Visa replaced their IBM mainframe batch
settlement system, written in S/370 assembler, with a new IBM
mainframe batch system written in C and using DB2. I believe they
processed about 109 million batch transactions in two days during a
parallel conversion.
I am aware of COBOL applications, both batch and online, that process
very high volumes of transactions, so I would argue that sometimes
every microsecond is very important.
Hope that helps!
docd...@panix.com
From
http://www.eweek.com/article/0,3658,apn=3&s=703&a=19360&app=1&ap=2,00.asp
--begin quoted text:
With officials looking on anxiously, the new system processed 109 million
transactions valued at $3.5 billion in its first two days. During the
deployment, both the old and the new systems ran concurrently.
--end quoted text
Most enjoyable, Mr Trembley... but note that it was not argued that there
was never a time when 'every microsecond is very important', as opposed to
'sometimes'; what is to be remembered is that if one lives as though
'sometimes' is 'always' then one is usually... wrong. The ability to
squeeze the last few ticks out of a system which is too small for its
dataflow is a valiant one... but it is like the tailor who can let out the
trousers of a teenager *one* last time, eventually one will have to either
spring for a new pair of pants or be rather embarassed.
DD
Tim Scrivens
<docd...@panix.com> wrote in message news:acttpe$i41$1...@panix1.panix.com...
> In article
<1D585A2BC416C81D.04647176...@lp.airnews.net>,
> SkippyPB <swie...@neo.rr.com> wrote:
> >On 26 May 2002 21:29:34 -0400, docd...@panix.com enlightened us:
> >
> transaction volumes at Visa and MasterCard are a bit... healthier than
> they are at most banking institutions *and* there is the added...
> 'challenge' of being *up* - and by *up* I intend 'responding really,
> *really* fast so a news-stand in Kuala Lampur doesn't start to complain
> that the cards take too long to validate' - twenty-four hours a day, seven
> days a week and across *all* time-zones...
>
> ... so maybe they are using techniques which might be applicable to a bank
> which spans, say, a mere five time-zones (Manhattan to Honolulu) and has
> the whole weekend to straighten things out.
And if I worked in banking, this would be REALLY germane.
I don't. Our batch window is a maximum of 9 hours, weekdays (10PM to 7
AM) - and you better not go much past 6.
Tim Scrivens
<docd...@panix.com> wrote in message news:acs25u$9k9$1...@panix1.panix.com...
Unfortunately, Doc, the limits of efficiency are reached quickly when one is
working through a software product that writes the COBOL for you. A sort of
3.5 GL.
We have all sorts of fun tricks to try to get more time out of the process,
though.
docd...@panix.com
Mr Scrivens, you might not work in banking but the techniques might be
applicable... or other techniques that might arise from a review of the
Way Things Are Done, that is all I am pointing out.
For example: I spent time at a brokerage, long ago, and every night was a
race to beat the window. I took a look at some of the jobstreams and
noticed that a goodly many of them started with an IDCAMS REPRO of the
Customer Master File KSDS to a &&TEMP flatfile, a SORT of this flatfile in
the same sequence and then program processing of this sorted flatfile.
(note to non-IBM mainframe folks - an indexed file was copied to a
temporary file and this temp file was sorted for further processing)
I suggested that if this was necessary then it might save a bit of their
precious time to consolidate jobs so that this sorting was done fewer
times... and did folks know that SyncSort could deal with a KSDS
directly, no REPRO needed?...
... and I was taken aside and told, in no uncertain terms:
1) I was on a contract to do online work (CICS) and was *not* to pay
attention to what was happening on the batch side
2) The recently-arrived new CIO wanted some new hardware so these - and
other - inefficiencies were not to be touched.
Now this second one might seem 'merely political'... until one notices
'recently-arrived new'; these problems had been there for a while.
Now I am but a COBOL-codin' fool; there are folks who are *much* more
skilled at the arcana of systems tuning, buffer-diddling (anyone remember
how to RESERVE 32 ALTERNATE AREAS?) and other such things... and what I
suggest is that they, too, get involved in jobs that run too long, if only
to provide a fresh set of eyes.
DD
docd...@panix.com
Tim Scrivens <tim.sc...@nz.eds.com> wrote:
>
><docd...@panix.com> wrote in message news:acs25u$9k9$1...@panix1.panix.com...
>> In article <acritk$ln9$1...@hermes.nz.eds.com>,
>> Tim Scrivens <tim.sc...@nz.eds.com> wrote:
>> >
>> >And then, 5 microseconds per transaction, 5 million transactions. 25
>> >seconds. 15 different batch programs, all with this - translates to an
>> >extra 6 minutes a day.
>> >
>> >Not important in terms of money, but if your batch window runs long - every
>> >bit helps.
>>
>> Helps *what*, though... stave off the long-overdue re-analysis and rewrite
>> which might make the system more efficient? If your batch window is that
>> tight then maybe things need to be handled a little differently.
>
>Unfortunately, Doc, the limits of efficiency are reached quickly when one is
>working through a software product that writes the COBOL for you. A sort of
>3.5 GL.
>
>We have all sorts of fun tricks to try to get more time out of the process,
>though.
Understood, Mr Scrivens... but it might be time to recall unto Management
the words of Thomas Jefferson:
http://odur.let.rug.nl/~usa/P/tj3/writings/brf/jefl246.htm
--begin quoted text:
But I know also, that laws and institutions must go hand in hand with the
progress of the human mind. As that becomes more developed, more
enlightened, as new discoveries are made, new truths disclosed, and
manners and opinions changewith the change of circumstances, institutions
must advance also, and keep pace with the times. We might as require a
man to wear still the coat which fitted him as a boy, as civilized society
to remain ever under the regimen of their barbarous ancestors.
--end quoted text
... and likewise with systems. Since your organisation has bound it'sself
to a coat of a particular size - by the tool that has been chosen, in this
case - then it must be determined when the limits of this garment have
been reached and the firm starts turning away new business with a
sorrowful 'We must apologise but our DP/IT/MIS/IS systems cannot handle
more business.'
*That*, of course, is anathema... just as it would be anathema for a
mechanic to turn down jobs because he doesn't have a large-enough hammer.
DD
SkippyPB
Indeed there are ways of maintaining up time (24 hours for most ATM
systems) and processing coast-to-coast banks that allow for a batch
window time that is able to be met. I was just, obviously not too
well, trying to point out that there are other causes for short batch
windows other than poor programming or processes.
Liam Devlin
> docd...@panix.com wrote:
>
>>(snip)
>>A perfectly reasonable scenario... and one which might be resolved by,
>>say, decentralised processing or the kind of work done by any of the major
>>credit card companies.
>>
>>Mr Trembley might want to step in here but as I understand it the
>>transaction volumes at Visa and MasterCard are a bit... healthier than
>>they are at most banking institutions *and* there is the added...
>>'challenge' of being *up* - and by *up* I intend 'responding really,
>>*really* fast so a news-stand in Kuala Lampur doesn't start to complain
>>that the cards take too long to validate' - twenty-four hours a day, seven
>>days a week and across *all* time-zones...
>>
>>... so maybe they are using techniques which might be applicable to a bank
>>which spans, say, a mere five time-zones (Manhattan to Honolulu) and has
>>the whole weekend to straighten things out.
>>
>>DD
>>
>
> Actually, I'd prefer NOT to step in here, but yes, there are certain
> challenges to running 24/7/365 and processing transactions in all
> time-zones.
>
> If you go to google and search for "ZDnet Visa settlement system new
> replacement", you might find an interesting article.
Not any more:-(
> Unfortunately
> there's no COBOL, since Visa replaced their IBM mainframe batch
> settlement system, written in S/370 assembler, with a new IBM
> mainframe batch system written in C and using DB2. I believe they
> processed about 109 million batch transactions in two days during a
> parallel conversion.
>
> I am aware of COBOL applications, both batch and online, that process
> very high volumes of transactions, so I would argue that sometimes
> every microsecond is very important.
Sometimes they are make or break issues, mostly they aren't, in my
experience, anyway (in what might considered "commercial data processing").
Liam Devlin
> <docd...@panix.com> wrote in message news:acttpe$i41$1...@panix1.panix.com...
>
>>In article
>>
> <1D585A2BC416C81D.04647176...@lp.airnews.net>,
>
>>SkippyPB <swie...@neo.rr.com> wrote:
>>
>>>On 26 May 2002 21:29:34 -0400, docd...@panix.com enlightened us:
>>>
>>>
>>Mr Trembley might want to step in here but as I understand it the
>>transaction volumes at Visa and MasterCard are a bit... healthier than
>>they are at most banking institutions *and* there is the added...
>>'challenge' of being *up* - and by *up* I intend 'responding really,
>>*really* fast so a news-stand in Kuala Lampur doesn't start to complain
>>that the cards take too long to validate' - twenty-four hours a day, seven
>>days a week and across *all* time-zones...
>>
>>... so maybe they are using techniques which might be applicable to a bank
>>which spans, say, a mere five time-zones (Manhattan to Honolulu) and has
>>the whole weekend to straighten things out.
>>
>
> And if I worked in banking, this would be REALLY germane.
Wouldn't it also be germane if your business, whatever it does, spanned
multiple times zones, including not only the US, but Brussels, London,
Tokyo & Singapore, as well?
> I don't. Our batch window is a maximum of 9 hours, weekdays (10PM to 7
> AM) - and you better not go much past 6.
You didn't specify Eastern/Central/Mountain/Pacific, etc., time zone.
Liam Devlin
Didn't he write "Mandy" & a bunch of other hits?
Terry Heinze
changes/enhancements, it becomes a combination of packed decimal, numeric
display, and alphanumeric? The advantage of using INITIALIZE now will cause
NO PROCEDURE DIVISION statement to change then.
--
....Terry
"Ross Klatte" <klatt...@aol.commmm> wrote in message
news:20020523175809...@mb-bk.aol.com...
> Stringer's suggestion of "WITH TEST AFTER" and "UNTIL >= MAX" was
> just what the doctor ordered. It worked perfectly, and has a cryptic
> quality fully in the spirit of modern COBOL.
>
> Shop standards rule out some of the good ideas, such as making
> subscripts binary. Also ruled out was making the 4-row table have
> a one-digit subscript; all subscripts have to be at least 2 digits.
> INITIALIZE ROW-COLUMN-TABLE gives me a syntax error.
> I think "MOVE ALL ZERO" would be acceptable, but it doesn't
> look very cool.
> Most annoying of all, the standards rule out leaving out the
> table initialization code all together; it is a batch program running
> on a Unisys box. But leaving out the manual initialization frightens
> all the IBM-trained programmers, and there are a lot of those.
> Along the same lines, I don't really approve of the part about
> "OCCURS ... DEPENDING" either. I don't know what IBM does,
> but Unisys goes ahead and allocates 99 in memory; so I don't
> see where anything is gained (other than coolness).
>
> >From: "Alain.Feler" Alain...@wanadoo.fr
> >Date: 5/23/2002 4:10 PM Eastern Daylight Time
> >Message-id: <acjieo$2ek$1...@wanadoo.fr>
> >
> >Initialize is very convenient, but very slow, at least with my compiler
> >(MS-Cobol V4.5, in fact an old Microfocus Cobol for Dos sold by
Microsoft).
> >I once got an execution time divided by 4 only replacing an initialize by
> >move spaces to the same array ( pic x occurs 9000)...
>
> Personally, I like INITIALIZE for a record, where everything is all
> higgledy-piggledy. But I don't like it for a table of all zeroes, or a
> table of all spaces. I intend to use it, but I don't like it.
>
>
>
> Ross
> http://community.webshots.com/user/ross_klatte
>
>
Ross Klatte
>Date: 2002-06-02 12:02 Eastern Daylight Time
I cautiously broached the idea of using WITH TEST AFTER to
solve the problem created by PERFORM UNTIL loop-counter > nn,
at the point where the loop-counter reaches but does not surpass
its physical limits.
The vehement abuse and scorn heaped upon the idea made me
hasten to insist that the idea was all Stringer's and none of my
own.
If there are any present who happen to hate WITH TEST AFTER,
why do you hate it? It looks pretty cool to me.
Ross
http://community.webshots.com/user/ross_klatte
William M. Klein
non-COBOL environments) is:
A) It is a useful tool - but one that isn't needed particularly often
B) It should be used "knowledgeably" i.e. ONLY when you require that you
"perform" your loop at least once - whether OR NOT the "control" condition
is true before the loop
C) (follow-on to B) if you end up "required" to put the same test inside
your loop and on your PERFORM statement when using WITH TEST AFTER, the
chances are that you have used it when you shouldn't have.
***
As far (as I recall) the original "question" - it will NOT solve problems of
trying to compare a 2 digit variable with a 3 digit literal.
--
Bill Klein
wmklein <at> ix.netcom.com
"Ross Klatte" <klatt...@aol.commmm> wrote in message
news:20020612210449...@mb-ma.aol.com...
Rufio
"William M. Klein" <wmk...@nospam.ix.netcom.com> wrote in message
news:ae9v68$5ut$1...@slb4.atl.mindspring.net...
| My view of "With Test After" (commonly referred to as "DO Until" in
| non-COBOL environments) is:
|
| A) It is a useful tool - but one that isn't needed particularly often
|
| B) It should be used "knowledgeably" i.e. ONLY when you require that
you
| "perform" your loop at least once - whether OR NOT the "control"
condition
| is true before the loop
|
| C) (follow-on to B) if you end up "required" to put the same test
inside
| your loop and on your PERFORM statement when using WITH TEST AFTER, the
| chances are that you have used it when you shouldn't have.
Not sure how often I'd use WITH TEST AFTER - but it's bloody obvious what
it does - unike some of those "smart" pieces of code that are a bitch to
fix at 3am.
stringer
with Mr Klein (dare I call him Bill?)
But (Please excuse the English!) it did seem an elegant solution to a problem
faced by Mr Klatte who seems hamstrung by an IT boss who would rather save
$0.02 worth of memory than have logical bullet-proof code.
Correct me if I'm wrong, but "with test after" was added to the language at
some time. Perhaps this explains the reluctance of some to take up its use. I
have noticed in this newsgroup that htere are some who still use CoBOL 74, and
some who simply prefer to use its constructs despite more modern ones being
available.
I won't get into the argument about spaghetti-code vs procedural vs object
oriented, save to naote that a) almost everyone agrees that first is plain bad
and to be avoided and b) that htere are horses for courses. While OO may be
best for many things, such a database backed programmes, there are still some
things better coded in procedural. And no, I won't respond to any replies about
this, as not being a full time paid programer I haven't the time or experience
to get into such a debate in detail!
To Bill Jimmy, Thane and others too numerous to mention, I enjoy your posts.
Keep up the good work. I have learnt much just from reading this newsgroup, and
now feel confident enough to occasionally contribute. I now have thousands of
lines of code behind me in an ever expanding suite of programmes. Perhaps some
day I will be in a position to make some money out of it!!
D J H Stringer
In article <ae9v68$5ut$1...@slb4.atl.mindspring.net>, wmk...@nospam.ix.netcom.com
says...
Peter E. C. Dashwood
emotional about computer code...) I don't use it and probably never will.
Why not?
Because during more than three decades of writing COBOL, I have become used
to the fact that WITH TEST BEFORE is the way Perform works and I don't have
to think about it. (This does NOT mean I am stuck in COBOL 74 or COBOL 59 or
any other version. Quite the contrary. I have been coding Object Oriented
COBOL for over 3 years now and DO use additions to the language which add
value to it... This one simply doesn't.
I have never encountered a case where it would be necessary to use it. That
doesn't mean there aren't any, just that I personally never came across any.
I probably organise my code so as to obviate the need for it, without even
thinking about it.
I would have no problem maintaining code that DID use it, but my own view is
that it is inelegant and unnecessary. (Inelegant because it means writing
three more words; unnecessary because it is possible to organise things so
it isn't needed.)
It DOESN'T look "pretty cool" to me; it simply looks ugly...<G>
Pete.
Ross Klatte <klatt...@aol.commmm> wrote in message
news:20020612210449...@mb-ma.aol.com...
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
James J. Gavan
stringer wrote:
> As the poster of the original solution, perhaps i should comment that i agree
> with Mr Klein (dare I call him Bill?)
>
Why not ? Having met the man he is a very nice person with no pomp or circumstance
<G>. "My boy Bill........", from Carousel .
> But (Please excuse the English!) it did seem an elegant solution to a problem
> faced by Mr Klatte who seems hamstrung by an IT boss who would rather save
> $0.02 worth of memory than have logical bullet-proof code.
>
> Correct me if I'm wrong, but "with test after" was added to the language at
> some time. Perhaps this explains the reluctance of some to take up its use. I
> have noticed in this newsgroup that htere are some who still use CoBOL 74, and
> some who simply prefer to use its constructs despite more modern ones being
> available.
>
> I won't get into the argument about spaghetti-code vs procedural vs object
> oriented, save to naote that a) almost everyone agrees that first is plain bad
> and to be avoided and b) that htere are horses for courses. While OO may be
> best for many things, such a database backed programmes, there are still some
> things better coded in procedural. And no, I won't respond to any replies about
> this, as not being a full time paid programer I haven't the time or experience
> to get into such a debate in detail!
>
> To Bill Jimmy, Thane and others too numerous to mention, I enjoy your posts.
> Keep up the good work. I have learnt much just from reading this newsgroup, and
> now feel confident enough to occasionally contribute. I now have thousands of
> lines of code behind me in an ever expanding suite of programmes. Perhaps some
> day I will be in a position to make some money out of it!!
Not slavishly following Pete, I don't use the PERFORM TEST AFTER - and like him
haven't as yet found a need to. Given the right occasion, I would use it.
Perhaps COBOL is too flexible to a fault - it just provides so many options to do
the same thing, and each individual settles into a particular style. I'd be curious
to know how many people use DECLARATIVES. I find it just as easy to do the
following :-
open input Data-file
if file-status <> "00"
set FileError to true
end-if
where the last three lines would be covered automatically by DECLARATIVES.
The plethora of coding options gets worse when you look at Exception Handling in
the draft for COBOL 2002. Declaratives, EC (Exception Conditions), a list of 50
plus, and EXIT RAISING etc.. The mind boggles as to how much of this will be put to
good use, along with Report Writer and Screen Section which wont be supported by
IBM.
The COBOL Standard is a bit like a set of City bylaws; once introduced, you have
one hell of a job getting rid of superfluous syntax. Announce you are going to
remove feature X and a bunch of people will come on like screaming dervishes saying
"BUT I *always* use that....!".
Jimmy, Calgary AB
stringer
Like you, I code without declaratives.
I also tend to code without the 'test after' alternative, although there are
several places where I could have used it, and may just rewrite my code that
way where appropriate.
And finally, I thought dervishes whirled, not screamed? Perhaps a better
reference might have been to Syrians coming down like the wolf from the
fold..(I won't guarantee the accuracy of the quote).
David Stringer
In article <3D0D5EFD...@shaw.ca>, jjg...@shaw.ca says...
James J. Gavan
stringer wrote:
> Jimmy,
>
> Like you, I code without declaratives.
>
> I also tend to code without the 'test after' alternative, although there are
> several places where I could have used it, and may just rewrite my code that
> way where appropriate.
>
> And finally, I thought dervishes whirled, not screamed? Perhaps a better
> reference might have been to Syrians coming down like the wolf from the
> fold..(I won't guarantee the accuracy of the quote).
>
Yes I was a bit off with my imagery. Dervishes do 'whirl'. I was thinking more of
the screaming Fuzzy Wuzzies in the 1939 'Four Feathers' which starred Ralph
Richardson. These guys, (from Sudan.?) had Afro haircuts way back in 1898 at the
Battle of Omdurman. That's me Oirish grandfather you can see kneeling in the front
row pointing his rifle at the Mahdi's onslaught. Winnie Churchill was also in on
the last British cavalry charge.
I learned that poem at school too. Tried to check, no success, but think it is,
"Assyrians coming down like a wolf from the fold". (Possibly one of the English
Victorian poets ?)
Jimmy, Calgary AB
Peter E. C. Dashwood
stringer <stri...@es.co.nz> wrote in message
news:aejou4$b7f$1...@lust.ihug.co.nz...
> Jimmy,
>
> Like you, I code without declaratives.
>
mainframe environments where there may be quite complex cleanup requirements
if hardware fails.
> I also tend to code without the 'test after' alternative, although there
are
> several places where I could have used it, and may just rewrite my code
that
> way where appropriate.
>
Why would you rewrite working code, just so you can use a previously unused
construct?
> And finally, I thought dervishes whirled, not screamed? Perhaps a better
> reference might have been to Syrians coming down like the wolf from the
> fold..(I won't guarantee the accuracy of the quote).
>
Dervishes whirl. The Assyrian came down like a wolf ON the fold (the fold
being the place where sheep were kept). I believe the quote is from the
Bible, but I haven't checked for Chapter and Verse. Having said that, it has
a ring of Byron or Tennyson (might be Ozymandias) to it, so it might be that
Jimmy is right about his Victorian romantics. The thing that screams
is an Irish lost spirit called a Banshee. Jimmy, having Irish blood, should
have known that; Stringer, being a Kiwi, should demonstrate a better
standard of education...<G>
Pete. (This NG always guarantees a smile...<G>)
Posted Via Usenet.com Premium Usenet Newsgroup Services
Richard Plinston
>
> Although I don't "hate" WITH TEST AFTER
> It DOESN'T look "pretty cool" to me; it simply looks ugly...<G>
In general what looks 'nice' is what one recognises and what looks
'ugly' is what one doesn't recognise.
If a particular feature hasn't been used then one's reaction to it is
'confusion and frustration' at having to work out what it is doing (even
if this is only momentary), whereas the intent of code in one's usual
style can be recognised at a glance.
stringer
>
>
; Stringer, being a Kiwi, should demonstrate a better
>standard of education...<G>
>
I consider my hand smacked!!
I actually read the poem many years ago at secondary school where it was
incororated in a history book on the Charge of the Light Brigade, and went
with:
"Canon to the left of them,
"Canon to the right of them,
"Into the valley of death rode the five hundred
stringer
Pete Dashwood wrote:Why would you rewrite working code, just so you can use a
previously unused construct?
He too missed thep point. I wasn't wanting to use a (new?) construct just for
the sake of it, but because it was easier to read. I have several places where
a portion of code in a perform loop is repeated just before the perform loop.
The reason is so that that code is run at least once before the test. This I
consider inelegant compared to the extra three words contained in the test.
I suspect that the compiled machine code may well be more efficient too, though
I'll not waste my time checking that out. Any students here with the time to
waste on a test programme??
In article <3D0E3B52...@Azonic.co.nz>, rip...@Azonic.co.nz says...
James J. Gavan
stringer wrote:
> In article <3d0d9...@Usenet.com>, dash...@nospam.enternet.co.nz says...
> >
> >
> ; Stringer, being a Kiwi, should demonstrate a better
> >standard of education...<G>
> >
>
> I consider my hand smacked!!
Consider your head smacked ! Do they have a refresher for English 101 in NZ
<G>
Got it :-
Destruction of SENNACHERIB - Lord Byron (1788-1824)
1 The Assyrian came down like the wolf on the fold,
2 And his cohorts were gleaming in purple and gold;
3 And the sheen of their spears was like stars on the sea,
4 When the blue wave rolls nightly on deep Galilee.
5 Like the leaves of the forest when Summer is green,
6 That host with their banners at sunset were seen:
7 Like the leaves of the forest when Autumn hath blown,
8 That host on the morrow lay withered and strown.
9 For the Angel of Death spread his wings on the blast,
10 And breathed in the face of the foe as he passed;
11 And the eyes of the sleepers waxed deadly and chill,
12 And their hearts but once heaved, and for ever grew still!
13 And there lay the steed with his nostril all wide,
14 But through it there rolled not the breath of his pride;
15 And the foam of his gasping lay white on the turf,
16 And cold as the spray of the rock-beating surf.
17 And there lay the rider distorted and pale,
18 With the dew on his brow, and the rust on his mail:
19 And the tents were all silent, the banners alone,
20 The lances unlifted, the trumpet unblown.
21 And the widows of Ashur are loud in their wail,
22 And the idols are broke in the temple of Baal;
23 And the might of the Gentile, unsmote by the sword,
24 Hath melted like snow in the glance of the Lord!
Pete was right about it's Israelite connotation, but not the Bible. Don't ask
me why, but in the back of my head the word "SENNACHERIB" was ticking away,
with no meaning.
>
>
> I actually read the poem many years ago at secondary school where it was
> incororated in a history book on the Charge of the Light Brigade, and went
> with:
> "Canon to the left of them,
> "Canon to the right of them,
> "Into the valley of death rode the five hundred
Your math is wrong ! What sort of "funny" history book were you reading,
there's only some 3,000 years between the two events, the latter being the
Crimean War :-
ALFRED LORD TENNYSON (1809-1883)
CHARGE OF THE LIGHT BRIGADE
I.
1 Half a league, half a league,
2 Half a league onward,
3 All in the valley of Death
4 Rode the six hundred.
5 `Forward, the Light Brigade!
6 Charge for the guns!' he said:
7 Into the valley of Death
8 Rode the six hundred.
II.
9 `Forward, the Light Brigade!'
10 Was there a man dismay'd?
11 Not tho' the soldier knew
12 Some one had blunder'd:
13 Their's not to make reply,
14 Their's not to reason why,
15 Their's but to do and die:
16 Into the valley of Death
17 Rode the six hundred.
III
18 Cannon to right of them,
19 Cannon to left of them,
20 Cannon in front of them
21 Volley'd and thunder'd;
22 Storm'd at with shot and shell,
23 Boldly they rode and well,
24 Into the jaws of Death,
25 Into the mouth of Hell
26 Rode the six hundred.
IV
27 Flash'd all their sabres bare,
28 Flash'd as they turn'd in air
29 Sabring the gunners there,
30 Charging an army, while
31 All the world wonder'd:
32 Plunged in the battery-smoke
33 Right thro' the line they broke;
34 Cossack and Russian
35 Reel'd from the sabre-stroke
36 Shatter'd and sunder'd.
37 Then they rode back, but not
38 Not the six hundred.
V
39 Cannon to right of them,
40 Cannon to left of them,
41 Cannon behind them
42 Volley'd and thunder'd;
43 Storm'd at with shot and shell,
44 While horse and hero fell,
45 They that had fought so well
46 Came thro' the jaws of Death,
47 Back from the mouth of Hell,
48 All that was left of them,
49 Left of six hundred.
VI
50 When can their glory fade?
51 O the wild charge they made!
52 All the world wonder'd.
53 Honour the charge they made!
54 Honour the Light Brigade,
55 Noble six hundred!
PS: There's a site where you can listen to Tennyson reciting the first lines
of the poem, recorded on one of those oldie cylinders.
Try this link, if you want to follow up - it's free and would save you paying
for English 101 <G>
http://www.library.utoronto.ca/utel/rp/index1stlines.html
Jimmy, Calgary AB
Peter E. C. Dashwood
influenced by Tennyson's famous "Charge of the Light Brigade" except that
the Light Brigade had CANNON to the left, right, and in front of them, and
there were around 630 of them...<G>
Pete.
Peter E. C. Dashwood
Pete.
Richard Plinston <rip...@Azonic.co.nz> wrote in message
news:3D0E3B52...@Azonic.co.nz...
Posted Via Usenet.com Premium Usenet Newsgroup Services
Peter E. C. Dashwood
> Quite right. Coding styles all differ.
>
> Pete Dashwood wrote:Why would you rewrite working code, just so you can
use a
> previously unused construct?
>
> He too missed thep point. I wasn't wanting to use a (new?) construct just
for
> the sake of it, but because it was easier to read. I have several places
where
> a portion of code in a perform loop is repeated just before the perform
loop.
>
> The reason is so that that code is run at least once before the test. This
I
> consider inelegant compared to the extra three words contained in the
test.
>
BEFORE, fine. It's your code and I truly believe people should use whatever
they are comfortable with.
> I suspect that the compiled machine code may well be more efficient too,
though
> I'll not waste my time checking that out. Any students here with the time
to
> waste on a test programme??
>
>
Would it matter to you if it was ?
Or is that simply another argument to justify doing it?
Whatever you do is OK. But it is important you should know the real reasons
you code things a certain way and not what you think are the reasons <G>.
Pete.
>
> In article <3D0E3B52...@Azonic.co.nz>, rip...@Azonic.co.nz says...
> >
> >Peter E. C. Dashwood wrote:
> >>
> >> Although I don't "hate" WITH TEST AFTER
> >> ...
> >> It DOESN'T look "pretty cool" to me; it simply looks ugly...<G>
> >
> >In general what looks 'nice' is what one recognises and what looks
> >'ugly' is what one doesn't recognise.
> >
> >If a particular feature hasn't been used then one's reaction to it is
> >'confusion and frustration' at having to work out what it is doing (even
> >if this is only momentary), whereas the intent of code in one's usual
> >style can be recognised at a glance.
>
Posted Via Usenet.com Premium Usenet Newsgroup Services
Peter E. C. Dashwood
It was a pleasure to read them again after all these years.
Pete.
James J. Gavan <jjg...@shaw.ca> wrote in message
news:3D0E67CA...@shaw.ca...
Posted Via Usenet.com Premium Usenet Newsgroup Services