Cobol - Prodcuing an output file only on Friday?

Author

Prodcuing an output file only on Friday?

arrbee

2006-04-21, 3:55 am

Hi,

Is it possible to control the output files from a COBOL programs? I've
a requirement where I will have to produce the output file (a report)
only on Fridays in a year.

How to get it done? We are using "IBM Enterprise COBOL for z/OS and
OS/390 3.2.0"

Please help.

Rick Smith

2006-04-21, 3:55 am

"arrbee" <arrbee@gmail.com> wrote in message
news:1145604671.952859.159440@v46g2000cwv.googlegroups.com...
> Hi,
>
> Is it possible to control the output files from a COBOL programs? I've
> a requirement where I will have to produce the output file (a report)
> only on Fridays in a year.
>
> How to get it done? We are using "IBM Enterprise COBOL for z/OS and
> OS/390 3.2.0"

Maybe using something like this.

01 d-o-w pic 9.
88 friday value 5.

accept d-o-w from day-of-w

if friday
perform produce-report
end-if

Unless you are looking for a solution using JCL or
job scheduling. In which case, I will defer to others.

William M. Klein

2006-04-21, 3:55 am

There are also several other "COBOL language" options - depending upon exactly
WHAT you are looking for.

Certainly, if you are looking for a way to "dynamically allocate" the file (only
on Fridays) then you would want to look at the "dynamic file allocation"
information available with Enterprise COBOL.

--
Bill Klein
wmklein <at> ix.netcom.com
"Rick Smith" <ricksmith@mfi.net> wrote in message
news:124h4ca8bpmba9b@corp.supernews.com...
>
> "arrbee" <arrbee@gmail.com> wrote in message
> news:1145604671.952859.159440@v46g2000cwv.googlegroups.com...
>
> Maybe using something like this.
>
> 01 d-o-w pic 9.
> 88 friday value 5.
>
> accept d-o-w from day-of-w

> if friday
> perform produce-report
> end-if
>
> Unless you are looking for a solution using JCL or
> job scheduling. In which case, I will defer to others.
>
>
>

arrbee

2006-04-21, 7:55 am

Hi Rick, Thank you very much. I want to achieve it programatically. Of
course, we eventually execute JCL with this program load
module........:-)

HeyBub

2006-04-21, 7:55 am

arrbee wrote:
> Hi,
>
> Is it possible to control the output files from a COBOL programs? I've
> a requirement where I will have to produce the output file (a report)
> only on Fridays in a year.
>
> How to get it done? We are using "IBM Enterprise COBOL for z/OS and
> OS/390 3.2.0"
>
> Please help.

Produce the file every day and tell the end-user to access the file only on
Fridays.

This technique transfers ownership of the problem to someone else.

Donald Tees

2006-04-21, 6:55 pm

arrbee wrote:
> Hi,
>
> Is it possible to control the output files from a COBOL programs? I've
> a requirement where I will have to produce the output file (a report)
> only on Fridays in a year.
>
> How to get it done? We are using "IBM Enterprise COBOL for z/OS and
> OS/390 3.2.0"
>
> Please help.
>

All output from Cobol is controled by Cobol programs, yes. If you only
want to get the report on Fridays, I'd suggest that you only run it on
fridays. Few programs will do anything if you do not run them. Failing
that, have the program check the date to see if it is Friday, and bypass
the report if it is not.

Donald

SkippyPB

2006-04-21, 6:55 pm

On 21 Apr 2006 00:31:12 -0700, "arrbee" <arrbee@gmail.com> enlightened
us:

>Hi,
>
>Is it possible to control the output files from a COBOL programs? I've
>a requirement where I will have to produce the output file (a report)
>only on Fridays in a year.
>
>How to get it done? We are using "IBM Enterprise COBOL for z/OS and
>OS/390 3.2.0"
>
>Please help.

Use a date routine to determine what "today" is. If Friday, produce
report, otherwise end.

Regards,
////
(o o)
-oOO--(_)--OOo-

"Do stars clean themselves with meteor showers?"
-- George Carlin
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Remove nospam to email me.

Steve

SkippyPB

2006-04-21, 6:55 pm

On Fri, 21 Apr 2006 08:46:26 -0500, "HeyBub" <heybubNOSPAM@gmail.com>
enlightened us:

>arrbee wrote:
>
>Produce the file every day and tell the end-user to access the file only on
>Fridays.
>
>This technique transfers ownership of the problem to someone else.
>

And this solution will not gain you any friends within your user
organization.

Regards,
////
(o o)
-oOO--(_)--OOo-

"Do stars clean themselves with meteor showers?"
-- George Carlin
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Remove nospam to email me.

Steve

2006-04-21, 6:55 pm

In article <124h4ca8bpmba9b@corp.supernews.com>,
Rick Smith <ricksmith@mfi.net> wrote:
>
>"arrbee" <arrbee@gmail.com> wrote in message
>news:1145604671.952859.159440@v46g2000cwv.googlegroups.com...
>
>Maybe using something like this.
>
> 01 d-o-w pic 9.
> 88 friday value 5.
>
> accept d-o-w from day-of-w

> if friday
> perform produce-report
> end-if

The advantage of this solution is that it allows for a tendency for report
results to be demanded with increasing frequency... annuals become
quarterlies, quarterlies become w

lies, w

lies become dailies and
dailies become ad-hocs. To modify the abovegiven example for future use
one might use something along the lines of:

01 d-o-w pic 9.
88 monday value 1.
88 tuesday value 2.
88 wednesday value 3.
88 thursday value 4.
88 friday value 5.
88 saturday value 6.
88 sunday value 7.
88 report-needed-today
values 5.
....
accept d-o-w from day-of-w

.
evaluate true
when report-needed-today
perform produce-report-ritual
thru prr-ex
end-evaluate.
....
produce-report-ritual.
evaluate true
when friday
perform produce-friday-report
thru pfr-ex
when other
perform report-error-ritual
thru rer-ex
go to blow-up-program
end-evaluate

.... et and cetera. This way when - *not* 'if' - a user says 'Well, on
Thursday we'll want Tuesday's report... but broken down by division, not
department, and including the miscellaneous graft and corruption figures
and sorted on descending barometric pressure'... or something like that...
the values clause for report-needed-today gets changed, the evaluate in
produce-report-ritual gets expanded and, as BritSpeakers sometimes say,
your mother's brother's name is Robert.

(note that perform thru and go to constructs are used because they are,
inarguably, the best possible styles available... and I, of course, am the
King of England)

DD

Richard

2006-04-21, 6:55 pm

> I will have to produce the output file (a report)
> only on Fridays in a year.

Except on Easter w

when it is to be done on Thurday ?

And, if Christamas day is Friday, then do it Wednesday ?

And, for ThanksGiving ...

Peter Lacey

2006-04-21, 6:55 pm

Richard wrote:
>
>
> Except on Easter w

when it is to be done on Thurday ?
>
> And, if Christamas day is Friday, then do it Wednesday ?
>
> And, for ThanksGiving ...

Ye gods. If it's going to be that complicated, set up an external
calendar file (say something that can be edited through a WP or text
editor) that has every date in the year along with a simple Y or N.
Otherwise looking up the d-o-w is sufficient.

PL

LX-i

2006-04-21, 6:55 pm

Peter Lacey wrote:
> Richard wrote:
>
> Ye gods. If it's going to be that complicated, set up an external
> calendar file (say something that can be edited through a WP or text
> editor)

I think that was what Richard was getting at... :)

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

"Who is more irrational? A man who believes in a God he doesn't see, or
a man who's offended by a God he doesn't believe in?" - Brad Stine

Arnold Trembley

2006-04-22, 3:55 am

arrbee wrote:
> Hi Rick, Thank you very much. I want to achieve it programatically. Of
> course, we eventually execute JCL with this program load
> module........:-)
>

But why would you prefer doing it programmatically rather than in the
job scheduler? I really am curious.

In my experience, generating a report only on Fridays is always done
by having the job schedule run the program on Fridays.

And what would you do if the requirement was to create three monthly
reports on the first Saturday of every month? That's exactly what I
had to do earlier this year. The job scheduler was Tivoli Workload
scheduler, but could just as easily have been CA-7 or Control-M or
some other scheduler I'm not familiar with.

If you make the program decide when to generate the report, the
program must run every day. If you let the job scheduler do it, the
program only runs on the day it needs to run.

--
http://arnold.trembley.home.att.net/

2006-04-22, 6:55 pm

In article <VVh2g.61857$1q4.6933@bgtnsc05-news.ops.worldnet.att.net>,
Arnold Trembley <arnold.trembley@worldnet.att.net> wrote:
>
>
>arrbee wrote:
>
>But why would you prefer doing it programmatically rather than in the
>job scheduler? I really am curious.

My guess is that it is a program that updates files and some Complete
Genius decided to make it a program that updates files *and* generates a
report.

DD

arrbee

2006-04-25, 6:55 pm

Hi Arnold, Thank you very much for the query. I work in a enhancement
project and all I need to do is as per the request given by client. We
could not negotiate the other ways of doing it.........:-(

Program will definitely run on all days. But, reports will be produced
only on Fridays.

arrbee

2006-04-25, 6:55 pm

Wow.........this is cute Rick. Thank you very much. I am able to
achieve what I wanted to do.

Thanks a lot.
Rick Smith wrote:
> "arrbee" <arrbee@gmail.com> wrote in message
> news:1145604671.952859.159440@v46g2000cwv.googlegroups.com...
>
> Maybe using something like this.
>
> 01 d-o-w pic 9.
> 88 friday value 5.
>
> accept d-o-w from day-of-w

> if friday
> perform produce-report
> end-if
>
> Unless you are looking for a solution using JCL or
> job scheduling. In which case, I will defer to others.

Peter Lacey

2006-04-25, 6:55 pm

Rick Smith wrote:

> Maybe using something like this.
>
> 01 d-o-w pic 9.
> 88 friday value 5.
>
> accept d-o-w from day-of-w

> if friday
> perform produce-report
> end-if
>

What are the usual arguments and tradeoffs for using an 88 vs. a 77?

I.e., if one codes

77 d-o-w pic 9.
77 friday pic 9 value 5.

accept d-o-w from day-of-w

if d-o-w = friday
perform produce-report
end-if

instead of Rick's suggestion.

This is a very trivial example so might not be the best illustration; in
both cases the field and the particular desired value are together so
there's no trouble finding out what "friday" is, in either case (unless
this happens to be a Robinson Crusoe program); but I've seen programs
with multiple variables defined with multiple 88's following, and unless
all the references are together in the procedural code it can get hairy
to follow it. I saw one that went something like this -
if flush
if credit
if overdraft
.... and there were a couple of others in the statement. The names could
have been better chosen, to be sure, but it took quite a bit of
untangling even so: having to find and understand the parent variables.

Thus my question. Any experience out there to do with upper levels of
compelxity etc.? I have used 88's as shop standards required but never
very complicated ones.

PL

Donald Tees

2006-04-25, 6:55 pm

Peter Lacey wrote:
> Rick Smith wrote:
>
>
>
>
>
> What are the usual arguments and tradeoffs for using an 88 vs. a 77?
>
> I.e., if one codes
>
> 77 d-o-w pic 9.
> 77 friday pic 9 value 5.
>
> accept d-o-w from day-of-w

> if d-o-w = friday
> perform produce-report
> end-if
>
> instead of Rick's suggestion.
>
> This is a very trivial example so might not be the best illustration; in
> both cases the field and the particular desired value are together so
> there's no trouble finding out what "friday" is, in either case (unless
> this happens to be a Robinson Crusoe program); but I've seen programs
> with multiple variables defined with multiple 88's following, and unless
> all the references are together in the procedural code it can get hairy
> to follow it. I saw one that went something like this -
> if flush
> if credit
> if overdraft
> ... and there were a couple of others in the statement. The names could
> have been better chosen, to be sure, but it took quite a bit of
> untangling even so: having to find and understand the parent variables.
>
> Thus my question. Any experience out there to do with upper levels of
> compelxity etc.? I have used 88's as shop standards required but never
> very complicated ones.
>
> PL

The really weak point of 88 levels (IMO) is that when there are multiple
choices, it becomes much more difficult to trace the code, at least in
NET EXPRESS. If the choice is between several 88 levels, you have to
refer back to the data division source code to see if the branch is
going to work. With constants, variables, you can either see it in the
code, or you can look at the variable in the procedure division source
code. You do not need to go back to the data division source to see what
will happen.

The old arguement that 88 levels centralize possible changes is invalid,
aslo IMO. With proper use of the constants section, or working storage
section value statements chnages can be just as centralized.

Donald

Pete Dashwood

2006-04-25, 6:55 pm

"Peter Lacey" <lacey@mts.net> wrote in message
news:444D518F.EA52E1D4@mts.net...
> Rick Smith wrote:
>
>
>
> What are the usual arguments and tradeoffs for using an 88 vs. a 77?
>

There are none. 88 and 77 have nothing to do with each other. It is like
saying: "What are the usual arguments and tradeoffs for using an orange
instead of a can opener?

The 88 is a condition name. That is to say it represents a condition. It
does not exist in storage and is used only by the compiler.

The 77 is an independent area of storage which certainly DOES exist and is
useful on certain platforms where memory synchronization and slack bytes
might be important. I have never found a case for using a 77 that couldn't
be covered by using 01, the only difference being the alignment in memory.

> I.e., if one codes
>
> 77 d-o-w pic 9.
> 77 friday pic 9 value 5.
>
> accept d-o-w from day-of-w

> if d-o-w = friday
> perform produce-report
> end-if
>
> instead of Rick's suggestion.
>

It uses twice the storage that Rick's suggestion does. OK, in this instance
it is a single byte, but it might not have been. Furthermore, if you wanted
to test for ANY day of the w

you would need another 6 bytes. The 88
solution would only ever require the original byte to be allocated in
storage.

The use of condition names has been argued here on a number of occasions. I
know that Richard has reservations about them and his reasons seem quite
valid to me. Nevertheless, I use them all the time and find them very useful
for the purpose for which they are intended.

The whole point about 88 levels is that you should not be concerned about
the storage location they are attached to; it is the CONDITION that is
important.

e.g. You could think of the condition logically as...

01 (or 77) filler pic x.
88 whale-is-a-fish value '0'.

This would be fine if COBOL allowed you to set these conditions to TRUE or
FALSE, but, apart from a few implementations that extend the language to do
this, 'standard' (whatever the Hell that is...) COBOL doesn't allow 'SET
condition TO FALSE'. So programmers have to move a space or a zero or
somesuch (actually, it can be anything other than the TRUE value...) to the
underlying storage when they want the condition to be false, and that kind
of defeats the object... Even this shortcoming can be overcome...

01 (or 77) filler pic x.
88 whale-is-a-fish value '0'.
88 whale-is-NOT-a-fish value '1'.

(it is important to remember that whales can now be in an indeterminate
state; neither fish nor not-fish, but that is only pertinent when
debugging.)

then...

if we-are-being-silly
set whale-is-a-fish to TRUE
else
set whale-is-NOT-a-fish to TRUE
end-if

Some compilers may not allow use of filler in this way but the point is that
you should NOT even consider the storage to which the condition is attached.
(For me, 'filler' simply means 'I can't be bothered thinking of a name for
this and I have no intention of ever referencing it anyway...') Having to
search through source code to find the places where storage for an 88 level
got referenced, defeats the whole object of 88 levels. They are intended to
abstract the states that the storage they are representing can be in. The
storage is tangible; the condition is abstract. The logic should deal with
the abstraction.

Setting up dichotomies in this way is advisable if you cannot
SET...condition TO FALSE.

Yes, you can always say:

if NOT whale-is-a-fish...
but you can only make it true by referencing the storage or initializing
it to that value.

So, what if the storage is part of an input record and the conditions are
used to document it? Don't you then HAVE to reference the storage? Have a
look...

01 customer-record.
12 cust-type pic x.
88 retail-customer value 'R'.
88 wholesale-customer value 'W'.
88 internet-special value 'I'.

Obviously, the storage now IS important and there may now be a need to
reference it directly....

evaluate cust-type *> references storage for 88 levels...
when retail-customer
....retail customer process
when wholesale-customer
... wholesale customer process
when internet-special
... internet special process
when other
... invalid input process
end-evaluate

The above is probably preferable to...

if NOT retail-customer
if NOT wholesale-customer
if NOT internet-special
...invalid input process
else
... internet special process
else
... wholesale customer process
else
... retail customer process
end-if

.... where the storage is NOT referenced. In both cases the results are
identical. So, NO, you don't HAVE to reference the storage, but you may find
it stylistically more acceptable if you do.

> This is a very trivial example so might not be the best illustration; in
> both cases the field and the particular desired value are together so
> there's no trouble finding out what "friday" is, in either case (unless
> this happens to be a Robinson Crusoe program); but I've seen programs
> with multiple variables defined with multiple 88's following, and unless
> all the references are together in the procedural code it can get hairy
> to follow it. I saw one that went something like this -
> if flush
> if credit
> if overdraft
> ... and there were a couple of others in the statement. The names could
> have been better chosen, to be sure, but it took quite a bit of
> untangling even so: having to find and understand the parent variables.

My argument is that it should not have been necessary to find and understand
the parent variables, IF the 88 levels were set up thoughtfully. If you put
an 88 on something you are, in effect, abstracting it so that it should not
require reference (see above).
>
> Thus my question. Any experience out there to do with upper levels of
> compelxity etc.? I have used 88's as shop standards required but never
> very complicated ones.
>
88s get my vote for the reasons outlined above. I haven't ever had to search
source code in order to understand them in my own or anyone else's code...

If they are only referenced by 'SET' and 'IF' there is no problem. Trouble
can arise when MOVE is used to set the parent variable, or any other type of
reference is made to it. Best avoided...

Pete.

> PL
>

2006-04-25, 6:55 pm

In article <4b58o5Fv56roU1@individual.net>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:

[snip]

>01 (or 77) filler pic x.
> 88 whale-is-a-fish value '0'.
>
>This would be fine if COBOL allowed you to set these conditions to TRUE or
>FALSE, but, apart from a few implementations that extend the language to do
>this, 'standard' (whatever the Hell that is...) COBOL doesn't allow 'SET
>condition TO FALSE'. So programmers have to move a space or a zero or
>somesuch (actually, it can be anything other than the TRUE value...) to the
>underlying storage when they want the condition to be false, and that kind
>of defeats the object... Even this shortcoming can be overcome...

With all due respect, Mr Dashwood, I disagree. First and foremost: unless
the abovegiven 01/77 is in an FD, SD, RD or Linkage field then All Good
Programmers will know that it *must* be initialised by a value clause.

(All Good Programmers know this because their instructors POUNDED IT INTO
THEIR HEADS THAT WORKING-STORAGE FIELDS WILL ALWAYS BE INITIALISED TO SOME
SORT OF VALUE. FAILURE TO DO SO WILL RESULT IN POINTS OFF ON YOUR
EXAMS... AND YOUR CODE IS GOING TO BE MISERABLE ENOUGH SO THAT YOU DON'T
WANT EXTRA POINTS TAKEN OFF BECAUSE YOU FORGOT A STINKING VALUE CLAUSE,
RIGHT? NOW, REPEAT AFTER ME: EVERY WORKING-STORAGE FIELD IS TO BE
INITIALISED WITH A VALUE CLAUSE... oh... sorry about that, sometimes the
Olde Learninge just sort of... oozes out of me.)

Anyhow... given that a Working-Storage field is initialised to a value
then it is trivial to extend to the program the simple logical condition
which can be found in many other places: Non-Existence is the Default
Value, or, Unless Demonstrated Otherwise, A Given Condition Does Not
Exist.

(This is a variation of 'the burden of proof is on the assertor' or 'I'm
sorry, 'Because I say so, now prove me wrong' does not constitute any sort
of an argument. Chartreuse leprechauns live on the dark side of the moon
because I say so... prove me wrong? Nonexistence is the default.')

These two metaphysics (in the sense that they lie beyond the nature of
data) - everything is given an initial value and everything is assumed to
be NOT until proven IS - might make dealing with conditions a bit more
readily-apprehended.

DD

Pete Dashwood

2006-04-25, 6:55 pm

<docdwarf@panix.com> wrote in message news:e2jrgj$c8l$1@reader1.panix.com...
> In article <4b58o5Fv56roU1@individual.net>,
> Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
> [snip]
>
>
> With all due respect, Mr Dashwood, I disagree.

Thanks for the respect, Doc. Rare these days...:-) (And reciprocated... :-))

> First and foremost: unless
> the abovegiven 01/77 is in an FD, SD, RD or Linkage field then All Good
> Programmers will know that it *must* be initialised by a value clause.

I don't disagree that initializing variables is a Good Thing. However, it is
only really important in batch processing. Only in batch is there an
implicit 'first time through this code'. Online, it has to be explicit.

Online processes where code is rentrant/reusable cannot and must not make
any assumption about the state of storage. Typically they will have an
initialization process that will check/set the fields in which they are
interested.

If I were using the switch given above, my code would decide what it was
doing, then either SET whale-is-a-fish TO TRUE or SET whale-is-NOT-a-fish TO
TRUE; it would not expect the state of whales (aside: are you King of that
too...?) to be determined by default.

>
> (All Good Programmers know this because their instructors POUNDED IT INTO
> THEIR HEADS THAT WORKING-STORAGE FIELDS WILL ALWAYS BE INITIALISED TO SOME
> SORT OF VALUE. FAILURE TO DO SO WILL RESULT IN POINTS OFF ON YOUR
> EXAMS... AND YOUR CODE IS GOING TO BE MISERABLE ENOUGH SO THAT YOU DON'T
> WANT EXTRA POINTS TAKEN OFF BECAUSE YOU FORGOT A STINKING VALUE CLAUSE,
> RIGHT? NOW, REPEAT AFTER ME: EVERY WORKING-STORAGE FIELD IS TO BE
> INITIALISED WITH A VALUE CLAUSE... oh... sorry about that, sometimes the
> Olde Learninge just sort of... oozes out of me.)
>
Something certainly oozes out of you... :-)

> Anyhow... given that a Working-Storage field is initialised to a value
> then it is trivial to extend to the program the simple logical condition
> which can be found in many other places: Non-Existence is the Default
> Value, or, Unless Demonstrated Otherwise, A Given Condition Does Not
> Exist.

That is certainly one approach.

>
> (This is a variation of 'the burden of proof is on the assertor' or 'I'm
> sorry, 'Because I say so, now prove me wrong' does not constitute any sort
> of an argument. Chartreuse leprechauns live on the dark side of the moon
> because I say so... prove me wrong? Nonexistence is the default.')
>
> These two metaphysics (in the sense that they lie beyond the nature of
> data) - everything is given an initial value and everything is assumed to
> be NOT until proven IS - might make dealing with conditions a bit more
> readily-apprehended.
>

Yes, I have no issue with that. In COBOL (which is primarily batch oriented)
it represents a good way of working.

Please feel free to amend my example as follows:

01 (or 77) filler pic x VALUE '1'.
88 whale-is-a-fish value '0'.
88 whale-is-NOT-a-fish value '1'.

Pete.

LX-i

2006-04-25, 6:55 pm

Peter Lacey wrote:

[snip example of 88-levels vs. item comparison]

> Thus my question. Any experience out there to do with upper levels of
> compelxity etc.? I have used 88's as shop standards required but never
> very complicated ones.

That's a great question. I remember being surprised that a "sign test"
("is positive", "is negative", and "is zero") were more efficient than a
direct comparison.

I've got some training this w

that takes me out of my office. When I
get back to work, I'll write a simple program and see what the
difference is (at least on the Unisys 2200 mainframe).

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

"Who is more irrational? A man who believes in a God he doesn't see, or
a man who's offended by a God he doesn't believe in?" - Brad Stine

Arnold Trembley

2006-04-25, 6:55 pm

Pete Dashwood wrote:
> (snip)
> I don't disagree that initializing variables is a Good Thing. However, it is
> only really important in batch processing. Only in batch is there an
> implicit 'first time through this code'. Online, it has to be explicit.
>
> Online processes where code is rentrant/reusable cannot and must not make
> any assumption about the state of storage. Typically they will have an
> initialization process that will check/set the fields in which they are
> interested.

When my shop was converting from OS/VS COBOL to COBOL II, a lot of
programmers were surprised to find "unexpected results" in CICS online
programs precisely because OS/VS COBOL always initialized working
storage to zeros or blanks if no VALUE clause was coded. VS COBOL II
did not. It was a big enough problem that IBM supplied a setup option
to initialize working-storage. A similar workaround was also supplied
with Language Environment COBOL compilers when they replaced VS COBOL II.

And it was only with COBOL II and higher that CICS COBOL programs
became truly re-entrant.

IBM COBOL programmers are still being surprised by core dumps in which
the entire working-storage section is no longer a single contiguous
area of memory. If your 01 record is not VALUE'ed at all, it's not in
the load module. It will be allocated at runtime someplace else. The
sins of OS/VS COBOL will live forever.

Many old-timers still code an eye-catcher at the beginning of
working-storage like this:

01 000-CORE-IMAGE-ID PIC X(48) VALUE
'*** SI950010 BEGINNING OF WORKING-STORAGE ***.

This is completely useless for reading a core dump, because the
optimizer in IBM Enterprise COBOL for z/OS detects that this data item
is never referenced, and deletes it from the object code/load module.

So, I agree with DocDwarf that working-storage variables should always
be VALUE'ed - and I always initialize switch/flag fields in the
procedure division before using them.

>
> Please feel free to amend my example as follows:
>
> 01 (or 77) filler pic x VALUE '1'.
> 88 whale-is-a-fish value '0'.
> 88 whale-is-NOT-a-fish value '1'.

This example works fine in IBM VS COBOL II and higher, so I suspect it
is fully ANSI-85 compliant. I thought it looked a little funny the
first time I saw it over ten years ago, but I use it now.

With kindest regards,

--
http://arnold.trembley.home.att.net/

Arnold Trembley

2006-04-25, 6:55 pm

arrbee wrote:

> Hi Arnold, Thank you very much for the query. I work in a enhancement
> project and all I need to do is as per the request given by client. We
> could not negotiate the other ways of doing it.........:-(
>
> Program will definitely run on all days. But, reports will be produced
> only on Fridays.
>

Well, it can certainly be made to work this way, and if that's what
the client wants then that's what the client gets.

The only potential di

vantage I see is that if sometime in the
future the report needs to appear daily, or on a different day of the
w

, then someone would have to modify the program, test it, and
reinstall it. Some shops have audit controls that make it
considerably more difficult to install an application program than a
simple JCL change or a job schedule change. That's certainly true in
my shop.

With kindest regards,

--
http://arnold.trembley.home.att.net/

Pete Dashwood

2006-04-25, 6:55 pm

Good points and an interesting post, Arnold.

Thanks.

Pete.

TOP POST only good stuff below :-)
"Arnold Trembley" <arnold.trembley@worldnet.att.net> wrote in message
news:Arg3g.39681$az4.16157@bgtnsc04-news.ops.worldnet.att.net...
>
>
> Pete Dashwood wrote:
>
> When my shop was converting from OS/VS COBOL to COBOL II, a lot of
> programmers were surprised to find "unexpected results" in CICS online
> programs precisely because OS/VS COBOL always initialized working storage
> to zeros or blanks if no VALUE clause was coded. VS COBOL II did not. It
> was a big enough problem that IBM supplied a setup option to initialize
> working-storage. A similar workaround was also supplied with Language
> Environment COBOL compilers when they replaced VS COBOL II.
>
> And it was only with COBOL II and higher that CICS COBOL programs became
> truly re-entrant.
>
> IBM COBOL programmers are still being surprised by core dumps in which the
> entire working-storage section is no longer a single contiguous area of
> memory. If your 01 record is not VALUE'ed at all, it's not in the load
> module. It will be allocated at runtime someplace else. The sins of
> OS/VS COBOL will live forever.
>
> Many old-timers still code an eye-catcher at the beginning of
> working-storage like this:
>
> 01 000-CORE-IMAGE-ID PIC X(48) VALUE
> '*** SI950010 BEGINNING OF WORKING-STORAGE ***.
>
> This is completely useless for reading a core dump, because the optimizer
> in IBM Enterprise COBOL for z/OS detects that this data item is never
> referenced, and deletes it from the object code/load module.
>
> So, I agree with DocDwarf that working-storage variables should always be
> VALUE'ed - and I always initialize switch/flag fields in the procedure
> division before using them.
>
>
> This example works fine in IBM VS COBOL II and higher, so I suspect it is
> fully ANSI-85 compliant. I thought it looked a little funny the first
> time I saw it over ten years ago, but I use it now.
>
> With kindest regards,
>
> --
> http://arnold.trembley.home.att.net/
>
>

arrbee

2006-04-25, 6:55 pm

Yes. You are correct. Here, they don't mind to create a ticket to get
it done if required. So, no issues. Thanks for all your inputs. They
are very useful to me.

2006-04-25, 6:55 pm

In article <4b5dd1F107fl8U1@individual.net>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
><docdwarf@panix.com> wrote in message news:e2jrgj$c8l$1@reader1.panix.com...
>
>Thanks for the respect, Doc. Rare these days...:-) (And reciprocated... :-))

Not a problem, Mr Dashwood... fresh pot of tea's just steeped, a
jasmine/pouchong mix... the pouchong cuts what, to my palate, is an
overly-floral tendency on the jasmine's part, care for a cup?

>
>
>I don't disagree that initializing variables is a Good Thing. However, it is
>only really important in batch processing. Only in batch is there an
>implicit 'first time through this code'. Online, it has to be explicit.

I do not understand how you are differentiating between 'implicit' and
'explicit' FIRST-TIME-IN routines, Mr Dashwood. Granted the days of ON 1
are gone but in the environment with which I am most familiar (IBM
mainframe) the functions of:

PROCEDURE DIVISION.
IF EIBCALEN = 0
PERFORM FIRST-TIME-IN THRU FTI-EX

.... and ...

PROCEDURE DIVISION USING PARM.
PERFORM 0000-HOUSEKEEPING.

.... would appear to be identical. The first statement after the PROCEDURE
DIVISION declaration is, explicitly, the first one executed.

[snip]

>
>That is certainly one approach.

It is the approach taken by All Good Programmers, or so I was taught...
just as arithmetic operations are always preceded by a NUMERIC check and
all READs and WRITEs are INTO/FROM.

DD

2006-04-25, 6:55 pm

In article <3c41c$444d82e7$45491de7$15244@KNOLOGY.NET>,
LX-i <lxi0007@netscape.net> wrote:
>Peter Lacey wrote:
>
>[snip example of 88-levels vs. item comparison]
>
>
>That's a great question. I remember being surprised that a "sign test"
>("is positive", "is negative", and "is zero") were more efficient than a
>direct comparison.

I'm not sure what you are calling 'a direct comparison' here, Mr Summers.
Is it:

IF NUMERIC-FIELD01 = value

.... or ...

IF NUMERIC-FIELD01 = NUMERIC-FIELD02

.... where both fields are identically defined?

>
>I've got some training this w

that takes me out of my office.

I'll wait, patiently, then... and I hope the training will be both
intellectually stimulating and of functional value.

DD

Howard Brazee

2006-04-25, 6:55 pm

On Mon, 24 Apr 2006 17:30:39 -0500, Peter Lacey <lacey@mts.net> wrote:

>What are the usual arguments and tradeoffs for using an 88 vs. a 77?

88 levels are easy to read.

But 88 levels make it harder to find where a field is referenced.

I think the following is worth while:

01 PARM-FILE-STATUS PIC X(02) VALUE '00'.
88 PARM-FILE-STATUS-OK VALUE '00' '10' '97'.
*** '97' IS OPENING AN ALREADY OPENED FILE
88 PARM-FILE-AT-END VALUE '10'.

Howard Brazee

2006-04-25, 6:55 pm

On Tue, 25 Apr 2006 03:11:28 GMT, Arnold Trembley
<arnold.trembley@worldnet.att.net> wrote:

>01 000-CORE-IMAGE-ID PIC X(48) VALUE
> '*** SI950010 BEGINNING OF WORKING-STORAGE ***.
>
>This is completely useless for reading a core dump, because the
>optimizer in IBM Enterprise COBOL for z/OS detects that this data item
>is never referenced, and deletes it from the object code/load module.

Depending on what the optimizer does, I've seen people explicitly move
that string to fool it.

Peter Lacey

2006-04-25, 6:55 pm

Pete Dashwood wrote:
>
> "Peter Lacey" <lacey@mts.net> wrote in message

>
> There are none. 88 and 77 have nothing to do with each other. It is like
> saying: "What are the usual arguments and tradeoffs for using an orange
> instead of a can opener?
>

Come now. As I've set the case up, they are two methods of doing the
same thing, and that's what I wanted to explore.

> The 88 is a condition name. That is to say it represents a condition. It
> does not exist in storage and is used only by the compiler.
>
> The 77 is an independent area of storage which certainly DOES exist and is
> useful on certain platforms where memory synchronization and slack bytes
> might be important. I have never found a case for using a 77 that couldn't
> be covered by using 01, the only difference being the alignment in memory.
>

Nor have I. But storage is not an issue these days. Nor does it matter
if the value exists in storage - which on logical grounds I don't think
you can say categorically is true or not. I should imagine it depends
on the implementation: for instance, in IBM-style assembler, it may well
be implemented in a CLI, but is there a similar instruction in
Intel-style assembler? I'm talking about the USE of the value.

> The use of condition names has been argued here on a number of occasions. I
> know that Richard has reservations about them and his reasons seem quite
> valid to me. Nevertheless, I use them all the time and find them very useful
> for the purpose for which they are intended.

No doubt; but I usually use 77's for the same purpose and I "find them
very useful
for the purpose for which they are intended".

>
> The whole point about 88 levels is that you should not be concerned about
> the storage location they are attached to; it is the CONDITION that is
> important.

I'm not. I expressed myself very poorly in the original post: what I
meant to say was that the setting of the parent variable and the test
(using an 88) were on two consecutive lines of the program, something
which obviously can't be counted on.

>
> e.g. You could think of the condition logically as...
>
> 01 (or 77) filler pic x.
> 88 whale-is-a-fish value '0'.
>
> This would be fine if COBOL allowed you to set these conditions to TRUE or
> FALSE, but,

Not the issue.

>
> So, what if the storage is part of an input record and the conditions are
> used to document it? Don't you then HAVE to reference the storage? Have a
> look...
>
> 01 customer-record.
> 12 cust-type pic x.
> 88 retail-customer value 'R'.
> 88 wholesale-customer value 'W'.
> 88 internet-special value 'I'.
>
> Obviously, the storage now IS important and there may now be a need to
> reference it directly....
>
> evaluate cust-type *> references storage for 88 levels...
> when retail-customer
> ....retail customer process
> when wholesale-customer
> ... wholesale customer process
> when internet-special
> ... internet special process
> when other
> ... invalid input process
> end-evaluate
>
> The above is probably preferable to...
>
> if NOT retail-customer
> if NOT wholesale-customer
> if NOT internet-special
> ...invalid input process
> else
> ... internet special process
> else
> ... wholesale customer process
> else
> ... retail customer process
> end-if
>
> ... where the storage is NOT referenced. In both cases the results are
> identical. So, NO, you don't HAVE to reference the storage, but you may find
> it stylistically more acceptable if you do.

I'd say that the first set, using the EVALUATE, illustrates my point -
you know instantly what the parent variable is. Far better
stylistically and maintenance-wise. But if you set up 77-level
condition values, as I suggested, then the code would be equally
explicit and understandable. Possibly even better: suppose there were
four values that satisfied one condition, but several combinations of
three that satisfied another? In the second instance, you'd need
several OR's in the statement regardless of your preferred style.

>
> My argument is that it should not have been necessary to find and understand
> the parent variables, IF the 88 levels were set up thoughtfully. If you put
> an 88 on something you are, in effect, abstracting it so that it should not
> require reference (see above).

I would suggest that in self-defense you'd better be damn sure you know
what the parent variable is! Very similar condition names may well
refer to wildly different variables!

I was castigated once in this group for using a prefix of WK- for
"work-" instead of "w

-". Setting the names of the conditions up may
or may not be a thoughtful process.

The problem is where the references to the condition names are, in the
source code. If I find a name such as retail-customer ("if
retail-customer") at line 1000, and a name such as internet-customer at
line 2000 (for whatever reason) then I may well have to pause and remind
myself what they refer to, whereas if I see "If cust-type =
retail-customer" then most of the possible questions are explicitly
answered. (I would say "all" questions but somebody for sure could
catch me out!)

> 88s get my vote for the reasons outlined above. I haven't ever had to search
> source code in order to understand them in my own or anyone else's code...
>

One man's experience is illustrative, not definitive. I HAVE had to
search souce code.

> Pete.
>

PL

Donald Tees

2006-04-25, 6:55 pm

Peter Lacey wrote:[color=darkred]
> Pete Dashwood wrote:
>
>
>
>
>
> Come now. As I've set the case up, they are two methods of doing the
> same thing, and that's what I wanted to explore.
>
>
>
>
>
> Nor have I. But storage is not an issue these days. Nor does it matter
> if the value exists in storage - which on logical grounds I don't think
> you can say categorically is true or not. I should imagine it depends
> on the implementation: for instance, in IBM-style assembler, it may well
> be implemented in a CLI, but is there a similar instruction in
> Intel-style assembler? I'm talking about the USE of the value.
>
>
>
>
> No doubt; but I usually use 77's for the same purpose and I "find them
> very useful
> for the purpose for which they are intended".
>
>
>
>
> I'm not. I expressed myself very poorly in the original post: what I
> meant to say was that the setting of the parent variable and the test
> (using an 88) were on two consecutive lines of the program, something
> which obviously can't be counted on.
>
>
>
>
> Not the issue.
>
>
>
>
>
> I'd say that the first set, using the EVALUATE, illustrates my point -
> you know instantly what the parent variable is. Far better
> stylistically and maintenance-wise. But if you set up 77-level
> condition values, as I suggested, then the code would be equally
> explicit and understandable. Possibly even better: suppose there were
> four values that satisfied one condition, but several combinations of
> three that satisfied another? In the second instance, you'd need
> several OR's in the statement regardless of your preferred style.
>
>
>
>
> I would suggest that in self-defense you'd better be damn sure you know
> what the parent variable is! Very similar condition names may well
> refer to wildly different variables!
>
> I was castigated once in this group for using a prefix of WK- for
> "work-" instead of "w

-". Setting the names of the conditions up may
> or may not be a thoughtful process.
>
> The problem is where the references to the condition names are, in the
> source code. If I find a name such as retail-customer ("if
> retail-customer") at line 1000, and a name such as internet-customer at
> line 2000 (for whatever reason) then I may well have to pause and remind
> myself what they refer to, whereas if I see "If cust-type =
> retail-customer" then most of the possible questions are explicitly
> answered. (I would say "all" questions but somebody for sure could
> catch me out!)
>
>
>
>
>
>
> One man's experience is illustrative, not definitive. I HAVE had to
> search souce code.
>
>
>
So have I, on many an occassion. Knowing the parent variable at the
source code level is a *large* problem of 88's IMO.

Donald

Rick Smith

2006-04-25, 6:55 pm

"Peter Lacey" <lacey@mts.net> wrote in message
news:444E3CC6.6252500@mts.net...
> Pete Dashwood wrote:
[snip]
understand[color=darkred]
put[color=darkred]
not[color=darkred]
>
> I would suggest that in self-defense you'd better be damn sure you know
> what the parent variable is! Very similar condition names may well
> refer to wildly different variables!
[snip]
> The problem is where the references to the condition names are, in the
> source code. If I find a name such as retail-customer ("if
> retail-customer") at line 1000, and a name such as internet-customer at
> line 2000 (for whatever reason) then I may well have to pause and remind
> myself what they refer to, whereas if I see "If cust-type =
> retail-customer" then most of the possible questions are explicitly
> answered. (I would say "all" questions but somebody for sure could
> catch me out!)

Some time ago, Mr Stevens suggested qualification of
condition-names, such as;

if retail-customer of cust-type

as a means to associate a condition with its variable.
Is that not sufficient to answer "most of the possible
questions", explicitly.

Richard

2006-04-25, 6:55 pm

Howard Brazee wrote:

> I think the following is worth while:
>
> 01 PARM-FILE-STATUS PIC X(02) VALUE '00'.
> 88 PARM-FILE-STATUS-OK VALUE '00' '10' '97'.

When checking a file-status for success you should only check the first
byte for being zero as there are several success codes that are not
'00'.

Howard Brazee

2006-04-25, 6:55 pm

On 25 Apr 2006 11:59:17 -0700, "Richard" <riplin@Azonic.co.nz> wrote:

>
>When checking a file-status for success you should only check the first
>byte for being zero as there are several success codes that are not
>'00'.

If I check the first byte for being zero, then a '97' will be
incorrectly flagged as unsuccessful.

Richard

2006-04-25, 6:55 pm

Howard Brazee wrote:
> On 25 Apr 2006 11:59:17 -0700, "Richard" <riplin@Azonic.co.nz> wrote:
>
>
> If I check the first byte for being zero, then a '97' will be
> incorrectly flagged as unsuccessful.

'97' is not a 'success' return, nor is '10', though they may be treated
in the same way for some purposes.

01 PARM-FILE-STATUS PIC X(02) VALUE '00'.
88 PARM-FILE-STATUS-OK VALUE '0' & x'00' THRU
'0' & x'FF' '10' '97'.

hcmason@sbcglobal.net

2006-04-25, 6:55 pm

Back in the bad old days, we had SYSIN date cards:

//SYSIN DD*
$DATE 04252006 5

In the cobol program we would accept the date card:
ACCEPT DATE-AREA.
* DEFAULTS TO SYSIN ON IBM...
Eventually we had a procedure that produced a "date card" for each date
for a 10 year period. Then we had someone write a date routine called
standate that would return
todays date card....
The advantage of using a card like this was that during a rerun you
could put whatever
date you wanted on the control card...One of the fields was day of w

on the card...
Cheers...
Chris.

William M. Klein

2006-04-25, 9:55 pm

I think Daniel was distinguishing between:

If Num-Field = Zero
versus
If Num-Field Zero

The latter is a (COBOL-defined) "sign-test" - while the former is a relational
test. I will admit that which is "more efficient" is up to the compiler maker.

--
Bill Klein
wmklein <at> ix.netcom.com
<docdwarf@panix.com> wrote in message news:e2l4du$27f$1@reader1.panix.com...
> In article <3c41c$444d82e7$45491de7$15244@KNOLOGY.NET>,
> LX-i <lxi0007@netscape.net> wrote:
>
> I'm not sure what you are calling 'a direct comparison' here, Mr Summers.
> Is it:
>
> IF NUMERIC-FIELD01 = value
>
> ... or ...
>
> IF NUMERIC-FIELD01 = NUMERIC-FIELD02
>
> ... where both fields are identically defined?
>
>
> I'll wait, patiently, then... and I hope the training will be both
> intellectually stimulating and of functional value.
>
> DD
>

2006-04-26, 7:55 am

In article <aiB3g.115690$zy2.106167@fe08.news.easynews.com>,
William M. Klein <wmklein@nospam.netcom.com> wrote:
>I think Daniel was distinguishing between:
>
> If Num-Field = Zero
> versus
> If Num-Field Zero
>
>The latter is a (COBOL-defined) "sign-test" - while the former is a relational
>test. I will admit that which is "more efficient" is up to the compiler maker.

Ahhhhh... in the words of Engineer Scott, then... 'Let's go see!' Given
the code:

WORKING-STORAGE SECTION.
01 DISPLAY-NUMERIC PIC 9(15)V9(2) VALUE 12.34.
01 ZONED-DECIMAL PIC S9(15)V9(2) VALUE +12.34.
01 BINARY-FIELD PIC S9(15)V9(2) COMP VALUE +12.34.
01 PACKED-DEC PIC S9(15)V9(2) COMP-3 VALUE +12.34.

LINKAGE SECTION.
01 PARMS.
05 PARMLEN PIC S9(4) COMP.
05 PARMNO PIC S9(15)V9(2).
PROCEDURE DIVISION USING PARMS.
MOVE PARMNO TO DISPLAY-NUMERIC ZONED-DECIMAL BINARY-FIELD
PACKED-DEC.
IF DISPLAY-NUMERIC = 0 PERFORM A-PARA THRU A-EX.
IF DISPLAY-NUMERIC ZERO PERFORM A-PARA THRU A-EX.
IF ZONED-DECIMAL = 0 PERFORM A-PARA THRU A-EX.
IF ZONED-DECIMAL ZERO PERFORM A-PARA THRU A-EX.
IF BINARY-FIELD = ZERO PERFORM A-PARA THRU A-EX.
IF BINARY-FIELD ZERO PERFORM A-PARA THRU A-EX.
IF PACKED-DEC = 0 PERFORM A-PARA THRU A-EX.
IF PACKED-DEC ZERO PERFORM A-PARA THRU A-EX.
GOBACK.
A-PARA.
DISPLAY 'HOKEY SHMOKES!'.
A-EX.
EXIT.

.... and the compiler (IBM Enterprise COBOL for z/OS and OS/390 3.2.0)
options of SIZE(MAX),LIB,MAP,DYNAM,LIST,XREF,OPT,FL
AG(I,I),NUMPROC(PFD)
(because that's what I had already) the results, one by one, are:

IF DISPLAY-NUMERIC = 0:

CLC 0(17,2),25(12)
BC 7,280(0,11)

IF DISPLAY-NUMERIC ZERO:

L 2,300(0,9)
CLC 0(17,2),25(12)
L 11,56(0,12)
BC 7,310(0,11)

.... which is less efficient.

IF ZONED-DECIMAL = 0:

L 2,300(0,9)
CLC 24(17,2),8(12)
L 11,56(0,12)
BC 7,340(0,11)

IF ZONED-DECIMAL ZERO:

L 2,300(0,9)
CLC 24(17,2),8(12)
L 11,56(0,12)
BC 7,370(0,11)

.... which is equally efficient.

IF BINARY-FIELD = ZERO:

L 2,300(0,9)
CLC 48(8,2),168(10)
L 11,56(0,12)
BC 7,400(0,11)

IF BINARY-FIELD ZERO:

L 2,300(0,9)
CLC 48(8,2),168(10)
L 11,56(0,12)
BC 7,430(0,11)

.... which is equally efficient.

IF PACKED-DEC = 0:

L 2,300(0,9)
CLC 56(9,2),42(12)
L 11,56(0,12)
BC 7,460(0,11)

IF PACKED-DEC ZERO:

L 2,300(0,9)
CLC 56(9,2),42(12)
L 11,56(0,12)
BC 7,518(0,11)

.... which is equally efficient. Under these conditions, then, the
assertion 'a "sign test" ("is positive", "is negative", and "is zero")
were more efficient than a direct comparison' appears to be demonstrably
false.

DD

Howard Brazee

2006-04-26, 6:55 pm

On 25 Apr 2006 14:01:23 -0700, "Richard" <riplin@Azonic.co.nz> wrote:

>
>'97' is not a 'success' return, nor is '10', though they may be treated
>in the same way for some purposes.

Only "some" purposes? When should we treat it as unsuccessful?

>
> 01 PARM-FILE-STATUS PIC X(02) VALUE '00'.
> 88 PARM-FILE-STATUS-OK VALUE '0' & x'00' THRU
>'0' & x'FF' '10' '97'.

Why do you have the high-values as OK? I haven't come across that.

Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com

Howard Brazee

2006-04-26, 6:55 pm

On Wed, 26 Apr 2006 13:16:24 +0000 (UTC), docdwarf@panix.com () wrote:

>... which is equally efficient. Under these conditions, then, the
>assertion 'a "sign test" ("is positive", "is negative", and "is zero")
>were more efficient than a direct comparison' appears to be demonstrably
>false.

At least, on computer and compiler you used for the test.

Even if we find a compiler where there was a difference, I would
suspect the difference would be pretty small.

Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com

William M. Klein

2006-04-26, 6:55 pm

Just out of (my usual) curiosity, what happens with NUMPROC(NOPFD)? Also, what
about changing whatever setting you have for ZWB/NOZWB? You don't need to post
the full code, but I am curious if this changes your results (as to which is and
isn't most efficient).

--
Bill Klein
wmklein <at> ix.netcom.com
<docdwarf@panix.com> wrote in message news:e2nrr8$eer$1@reader1.panix.com...
> In article <aiB3g.115690$zy2.106167@fe08.news.easynews.com>,
> William M. Klein <wmklein@nospam.netcom.com> wrote:
>
> Ahhhhh... in the words of Engineer Scott, then... 'Let's go see!' Given
> the code:
>
> WORKING-STORAGE SECTION.
> 01 DISPLAY-NUMERIC PIC 9(15)V9(2) VALUE 12.34.
> 01 ZONED-DECIMAL PIC S9(15)V9(2) VALUE +12.34.
> 01 BINARY-FIELD PIC S9(15)V9(2) COMP VALUE +12.34.
> 01 PACKED-DEC PIC S9(15)V9(2) COMP-3 VALUE +12.34.
>
> LINKAGE SECTION.
> 01 PARMS.
> 05 PARMLEN PIC S9(4) COMP.
> 05 PARMNO PIC S9(15)V9(2).
> PROCEDURE DIVISION USING PARMS.
> MOVE PARMNO TO DISPLAY-NUMERIC ZONED-DECIMAL BINARY-FIELD
> PACKED-DEC.
> IF DISPLAY-NUMERIC = 0 PERFORM A-PARA THRU A-EX.
> IF DISPLAY-NUMERIC ZERO PERFORM A-PARA THRU A-EX.
> IF ZONED-DECIMAL = 0 PERFORM A-PARA THRU A-EX.
> IF ZONED-DECIMAL ZERO PERFORM A-PARA THRU A-EX.
> IF BINARY-FIELD = ZERO PERFORM A-PARA THRU A-EX.
> IF BINARY-FIELD ZERO PERFORM A-PARA THRU A-EX.
> IF PACKED-DEC = 0 PERFORM A-PARA THRU A-EX.
> IF PACKED-DEC ZERO PERFORM A-PARA THRU A-EX.
> GOBACK.
> A-PARA.
> DISPLAY 'HOKEY SHMOKES!'.
> A-EX.
> EXIT.
>
> ... and the compiler (IBM Enterprise COBOL for z/OS and OS/390 3.2.0)
> options of SIZE(MAX),LIB,MAP,DYNAM,LIST,XREF,OPT,FL
AG(I,I),NUMPROC(PFD)
> (because that's what I had already) the results, one by one, are:
>
> IF DISPLAY-NUMERIC = 0:
>
> CLC 0(17,2),25(12)
> BC 7,280(0,11)
>
> IF DISPLAY-NUMERIC ZERO:
>
> L 2,300(0,9)
> CLC 0(17,2),25(12)
> L 11,56(0,12)
> BC 7,310(0,11)
>
> ... which is less efficient.
>
> IF ZONED-DECIMAL = 0:
>
> L 2,300(0,9)
> CLC 24(17,2),8(12)
> L 11,56(0,12)
> BC 7,340(0,11)
>
> IF ZONED-DECIMAL ZERO:
>
> L 2,300(0,9)
> CLC 24(17,2),8(12)
> L 11,56(0,12)
> BC 7,370(0,11)
>
> ... which is equally efficient.
>
> IF BINARY-FIELD = ZERO:
>
> L 2,300(0,9)
> CLC 48(8,2),168(10)
> L 11,56(0,12)
> BC 7,400(0,11)
>
> IF BINARY-FIELD ZERO:
>
> L 2,300(0,9)
> CLC 48(8,2),168(10)
> L 11,56(0,12)
> BC 7,430(0,11)
>
> ... which is equally efficient.
>
> IF PACKED-DEC = 0:
>
> L 2,300(0,9)
> CLC 56(9,2),42(12)
> L 11,56(0,12)
> BC 7,460(0,11)
>
> IF PACKED-DEC ZERO:
>
> L 2,300(0,9)
> CLC 56(9,2),42(12)
> L 11,56(0,12)
> BC 7,518(0,11)
>
> ... which is equally efficient. Under these conditions, then, the
> assertion 'a "sign test" ("is positive", "is negative", and "is zero")
> were more efficient than a direct comparison' appears to be demonstrably
> false.
>
> DD

2006-04-26, 6:55 pm

In article <5b1v425g593pj4ub1tefdnqgb5j0p00ubo@4ax.com>,
Howard Brazee <howard@brazee.net> wrote:
>On Wed, 26 Apr 2006 13:16:24 +0000 (UTC), docdwarf@panix.com () wrote:
>
>
>At least, on computer and compiler you used for the test.

Mr Brazee, that might just possibly, perhaps, be one of the reason why I
stated above, clearly and unambiguously, '(u)nder these conditions'.

DD

2006-04-26, 6:55 pm

In article <dNM3g.143655$7i1.102732@fe06.news.easynews.com>,
William M. Klein <wmklein@nospam.netcom.com> wrote:
>Just out of (my usual) curiosity, what happens with NUMPROC(NOPFD)? Also, what
>about changing whatever setting you have for ZWB/NOZWB?

Hmmmm... let's see... the code postes was generated by NUMPROC(PFD) and
the (default) of ZWB; what's asked for here is... carry the one,
double-cipher the nought, check for valid numeric before the divide...
three more compiles:

NUMPROC(PFD),NOZWB
NUMPROC(NOPFD),ZWB
NUMPROC(NOPFD),NOZWB

>You don't need to post
>the full code, but I am curious if this changes your results (as to
>which is and
>isn't most efficient).

All righty... a quick zip through some results:

NUMPROC(PFD),NOZWB:

DISPLAY-NUMERIC - = 0 faster than (IS) ZERO
ZONED-DECIMAL - equal results
BINARY-FIELD - e.r.
PACKED-DECIMAL - e.r.

NUMPROC(NOPFD),NOZWB:

DN - = 0 faster than (IS) ZERO
ZD - e.r.
BF - e.r.
PD - e.r.

NUMPROC(NOPFD),ZWB:

DN - = 0 faster than (IS) ZERO
ZD - e.r.
BF - e.r.
PD - e.r.

.... with some difference in the ASM mnemonics for the generated code...
but I've been told I don't have post the full code...

.... yet.

DD

William M. Klein

2006-04-26, 6:55 pm

Thanks. Certainly seems to answer the (my) question - for this compiler with
these options (at this release/maintenance level) <G>.

--
Bill Klein
wmklein <at> ix.netcom.com
<docdwarf@panix.com> wrote in message news:e2o6rh$ij2$1@reader1.panix.com...
> In article <dNM3g.143655$7i1.102732@fe06.news.easynews.com>,
> William M. Klein <wmklein@nospam.netcom.com> wrote:
>
> Hmmmm... let's see... the code postes was generated by NUMPROC(PFD) and
> the (default) of ZWB; what's asked for here is... carry the one,
> double-cipher the nought, check for valid numeric before the divide...
> three more compiles:
>
> NUMPROC(PFD),NOZWB
> NUMPROC(NOPFD),ZWB
> NUMPROC(NOPFD),NOZWB
>
>
> All righty... a quick zip through some results:
>
> NUMPROC(PFD),NOZWB:
>
> DISPLAY-NUMERIC - = 0 faster than (IS) ZERO
> ZONED-DECIMAL - equal results
> BINARY-FIELD - e.r.
> PACKED-DECIMAL - e.r.
>
> NUMPROC(NOPFD),NOZWB:
>
> DN - = 0 faster than (IS) ZERO
> ZD - e.r.
> BF - e.r.
> PD - e.r.
>
> NUMPROC(NOPFD),ZWB:
>
> DN - = 0 faster than (IS) ZERO
> ZD - e.r.
> BF - e.r.
> PD - e.r.
>
> ... with some difference in the ASM mnemonics for the generated code...
> but I've been told I don't have post the full code...
>
> ... yet.
>
> DD

Richard

2006-04-26, 6:55 pm

>>'97' is not a 'success' return, nor is '10', though they may be treated
[color=darkred]
> Only "some" purposes? When should we treat it as unsuccessful?

Whenever you want to.

'10' is 'unsuccessful' in obtaining a record, but is 'OK' in that it is
an expected result that should not cause a diagnostic.

[color=darkred]
> Why do you have the high-values as OK? I haven't come across that.

It is the full range of all codes that could possibly be used as
'success', ie all values in 8-bit bytes that start with a '0' (zero).

Some vendors do use binary codes for for the second byte, though this
is only for the '9' series at present. It has been requested that the
success codes '0x' be available for vendor extension which may mean
that in the future there be additional codes that indicate success,
such as a vendor's replacement code for '97'.

The point is that code should be written so that it doesn't have to be
debugged and recoded just because a new runtime version or changes in
the files.

Testing for '00' will fail if an indexed file allows duplicate keys, or
an optional file is created, or in the future some other codes are
added.

William M. Klein

2006-04-26, 6:55 pm

You know Richard, if you are going to be "fussy" about "97" not being successful
(even though one vendor makes it so), you need to be consistent (if you want to
be <G> ) about the 2nd digit of "0x" and "9x" file status codes. Through the '85
Standard, it *MUST* (in a Standard conforming implementation) be a DIGIT (0-9).
The '02 Standard also allows it to be an alphanumeric character (I think - but
not certain - this is "a-z" and "A-Z").

A "Standard conforming" ('85 - not '02) program can "successfully" code
PIC 99
for a file status field.

P.S. I am well aware of binary 2nd characters - but those are "just as
non-conforming" as making "97" successful.

--
Bill Klein
wmklein <at> ix.netcom.com
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1146078333.855729.59670@i39g2000cwa.googlegroups.com...
>
>
> Whenever you want to.
>
> '10' is 'unsuccessful' in obtaining a record, but is 'OK' in that it is
> an expected result that should not cause a diagnostic.
>
>
>
>
> It is the full range of all codes that could possibly be used as
> 'success', ie all values in 8-bit bytes that start with a '0' (zero).
>
> Some vendors do use binary codes for for the second byte, though this
> is only for the '9' series at present. It has been requested that the
> success codes '0x' be available for vendor extension which may mean
> that in the future there be additional codes that indicate success,
> such as a vendor's replacement code for '97'.
>
> The point is that code should be written so that it doesn't have to be
> debugged and recoded just because a new runtime version or changes in
> the files.
>
> Testing for '00' will fail if an indexed file allows duplicate keys, or
> an optional file is created, or in the future some other codes are
> added.
>

Richard

2006-04-26, 6:55 pm

William M. Klein wrote:

> You know Richard, if you are going to be "fussy" about "97" not being successful
> (even though one vendor makes it so),

It is not me that does not list it as a 'successful completion' code,
it is the standard that defines that. A '9x' code is a 'Extended file
Staus Code' and should be dealt with exactly as defined by the specific
vendor.

As you may note I include '97' alongside the '0x' codes in the test,
treating it as if it were a 'successful completion' code.

> you need to be consistent (if you want to
> be <G> ) about the 2nd digit of "0x" and "9x" file status codes. Through the '85
> Standard, it *MUST* (in a Standard conforming implementation) be a DIGIT (0-9).
> The '02 Standard also allows it to be an alphanumeric character (I think - but
> not certain - this is "a-z" and "A-Z").

It is you that isn't being consistent. I quite happily cater for all
non-standard codes with all '0x' plus '97' and you want to include some
non-standard but be anal about only allowing standard '0x' codes.

> A "Standard conforming" ('85 - not '02) program can "successfully" code
> PIC 99
> for a file status field.

Which may be interesting but not particulay useful. The aim is to
ensure that in future the programs will continue to work in an expected
manner, not to punish the company for introducing a new Cobol version,
or the next programmer for adding a feature (such as duplicate
alternate keys), or even for using a different vendor's Cobol system.

> P.S. I am well aware of binary 2nd characters - but those are "just as
> non-conforming" as making "97" successful.

The aim isn't to punish non-conformity by making the program fail at
2am, but to ensure that the programs continue to work as expected. You
will note that my code will work correctly whether the vendor uses
non-conforming file status returns or not whereas a PIC 99 or a test
for '00' may not. In particular these may fail and/or will require
recoding for some future, or even current, versions.

Peter Lacey

2006-04-26, 6:55 pm

Richard wrote:
>
>
>
> Whenever you want to.
>
> '10' is 'unsuccessful' in obtaining a record, but is 'OK' in that it is
> an expected result that should not cause a diagnostic.
>
>
>
> It is the full range of all codes that could possibly be used as
> 'success', ie all values in 8-bit bytes that start with a '0' (zero).
>

Presumably programs will still work using the AT END and INVALID KEY
clauses, and letting the USE procedures catch everything else?

PL

Richard

2006-04-26, 6:55 pm

> Presumably programs will still work using the AT END and INVALID KEY
> clauses, and letting the USE procedures catch everything else?

I don't know what happens on an OPEN when only a USE procedure is
specified and a '97' would otherwise be set in the file-status.

Last Boy Scout

2006-04-26, 9:55 pm

Binyamin Dissen

2006-04-27, 3:55 am

On Wed, 26 Apr 2006 13:16:24 +0000 (UTC) docdwarf@panix.com () wrote:

:>IF DISPLAY-NUMERIC = 0:

:>CLC 0(17,2),25(12)
:>BC 7,280(0,11)

:>IF DISPLAY-NUMERIC ZERO:

:>L 2,300(0,9)
:>CLC 0(17,2),25(12)
:>L 11,56(0,12)
:>BC 7,310(0,11)

:>... which is less efficient.

Try the instructions in the opposite order.

I think that this is a coincidence.

--
Binyamin Dissen <bdissen@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

Pete Dashwood

2006-04-27, 3:55 am

<docdwarf@panix.com> wrote in message news:e2l32v$n5q$1@reader1.panix.com...
> In article <4b5dd1F107fl8U1@individual.net>,
> Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
> Not a problem, Mr Dashwood... fresh pot of tea's just steeped, a
> jasmine/pouchong mix... the pouchong cuts what, to my palate, is an
> overly-floral tendency on the jasmine's part, care for a cup?
>
Could I take a raincheck? It sounds delightful... perhaps next time I'm in
New York? :-)
>
> I do not understand how you are differentiating between 'implicit' and
> 'explicit' FIRST-TIME-IN routines, Mr Dashwood. Granted the days of ON 1
I seem to recall that set UPSI bytes in 1400 compatibility mode... Ah, happy
times.... :-)

> are gone but in the environment with which I am most familiar (IBM
> mainframe) the functions of:
>
> PROCEDURE DIVISION.
> IF EIBCALEN = 0
> PERFORM FIRST-TIME-IN THRU FTI-EX
>
> ... and ...
>
> PROCEDURE DIVISION USING PARM.
> PERFORM 0000-HOUSEKEEPING.
>
> ... would appear to be identical. The first statement after the PROCEDURE
> DIVISION declaration is, explicitly, the first one executed.

What about serial reusability (in IMS and CICS) where a 'progress indicator'
can be used to decide at which point in the 'conversation' you decide to
resume? The first statement following the Procedure division is not
necessarily the first statement executed EVERY time the program is entered.
Whether a SPA is used or the length of EIBCALEN (and that is not a way in
which I would use that field), or some other field in some other terminal
dependant buffer in some other system, a good online programmer will make no
assumptions about the values of storage. Initial settings are useful for
batch programs; they are not so useful for rentrant, reusable, or serial
reusable code.

I already conceded that I do not disagree with initializing storage. I have
reservations about its usefulness in online environments, that's all...

>
> [snip]
>
>
> It is the approach taken by All Good Programmers, or so I was taught...
> just as arithmetic operations are always preceded by a NUMERIC check and
> all READs and WRITEs are INTO/FROM.

And you are the King of England... :-)

Pete.

Pete Dashwood

2006-04-27, 3:55 am

"Howard Brazee" <howard@brazee.net> wrote in message
news:kpbs42d515bpefg7aq3870n3s4kbn6oruc@
4ax.com...
> On Mon, 24 Apr 2006 17:30:39 -0500, Peter Lacey <lacey@mts.net> wrote:
>
>
> 88 levels are easy to read.
>
> But 88 levels make it harder to find where a field is referenced.
>

Why would ANY field be hard to find with a modern editor... or even SPF?

I don't understand this at all.

Pete.

Pete Dashwood

2006-04-27, 7:55 am

"Peter Lacey" <lacey@mts.net> wrote in message
news:444E3CC6.6252500@mts.net...
> Pete Dashwood wrote:
>
>
> Come now. As I've set the case up, they are two methods of doing the
> same thing, and that's what I wanted to explore.
>
Sorry. I see no connection between something that represents a condition
(and doesn't physically exist) and something that represents storage, and
does. I'm not being difficult Peter, I honestly don't see it.
>
>
> Nor have I. But storage is not an issue these days. Nor does it matter
> if the value exists in storage - which on logical grounds I don't think
> you can say categorically is true or not. I should imagine it depends
> on the implementation: for instance, in IBM-style assembler, it may well
> be implemented in a CLI, but is there a similar instruction in
> Intel-style assembler? I'm talking about the USE of the value.
Then you are not talking about an 88 level. Neither BAL nor 8086 assembler
(I have facility with both of them) implements a COBOL 88. They DO implement
a similar function, at Assembly time... providing you use the macro
facility.

>
>
> No doubt; but I usually use 77's for the same purpose and I "find them
> very useful
> for the purpose for which they are intended".
The purpose for which a 77 is intended is to allocate a non-synchronized
elementary item in COBOL. It has nothing to do with evaluating a condition.
>
>
> I'm not. I expressed myself very poorly in the original post: what I
> meant to say was that the setting of the parent variable and the test
> (using an 88) were on two consecutive lines of the program, something
> which obviously can't be counted on.
OK, now I understand your objection. Again it really shouldn't matter
whether they are on consecutive lines or not. The STORAGE used by an 88 is
irrelevant. The condition that the name represents is what matters.

Confusion only arises because sometimes the 88 is used to 'Document' the
contents of a piece of storage, and sometimes it is used 'independently' to
describe a condition that needs to be 'remembered' for processing purposes.
I tried to demonstrate both of these in my original post. In doing so, I
pointed out that even if the condition is applied in a 'documentary' way,
you don't HAVE to reference the storage. It really comes down to style and
preference.
>
>
> Not the issue.
>
>
>
> I'd say that the first set, using the EVALUATE, illustrates my point -
> you know instantly what the parent variable is.

Why does it matter? The logic is the same either way. What matters are the
described conditions.

> Far better
> stylistically and maintenance-wise. But if you set up 77-level
> condition values, as I suggested, then the code would be equally
> explicit and understandable.

But there is no need to, and they take extra storage. The language provides
a facility to do exactly what you are doing with 77 levels, but you seem to
prefer not to use it...

>Possibly even better: suppose there were
> four values that satisfied one condition, but several combinations of
> three that satisfied another? In the second instance, you'd need
> several OR's in the statement regardless of your preferred style.
>
Sure, that's why an 88 level is better. It removes the need for explicit
ORing and testing storage.
>
> I would suggest that in self-defense you'd better be damn sure you know
> what the parent variable is! Very similar condition names may well
> refer to wildly different variables!

That is hardly 'thoughtful' use of condition-names is it? Besides,
programmers are used to looking carefully at datanames aren't they :-)?
>
> I was castigated once in this group for using a prefix of WK- for
> "work-" instead of "w

-". Setting the names of the conditions up may
> or may not be a thoughtful process.

Programming should be a thoughtful process. When it isn't, problems arise...
Ah, that's why we're having this discussion... :-)

>
> The problem is where the references to the condition names are, in the
> source code. If I find a name such as retail-customer ("if
> retail-customer") at line 1000, and a name such as internet-customer at
> line 2000 (for whatever reason) then I may well have to pause and remind
> myself what they refer to, whereas if I see "If cust-type =
> retail-customer" then most of the possible questions are explicitly
> answered. (I would say "all" questions but somebody for sure could
> catch me out!)

That's a good example, Peter and I take your point.

Some people will definitely prefer to have an explicit statement of what the
customer type is. I would suggest that they should not use 88 levels. Others
will have no problem realising that the type is implicit in the condition
name. They can use them (thoughtfully.... :-)) without problem.

The discussion gets extended further when we come to OO. If we name an
attribute of an object to be cust-type and the object recognises that this
attribute can have certain values, it might indeed make sense to use 77
levels when GETing and SETing the attribute. But then there is no need for
an 88 level at all.

77 retail-customer pic x value 'R'.
77 wholesale-customer pic x value 'W'.
77 internet-customer pic x value 'I'.

....
invoke customerObj 'SET-cust-type'
using retail-customer
end-invoke

The only difference here is that the actual storage (attribute) is not
available in the calling program and if it did have 88 levels on it, they
would not be available outside the object.

I think my argument is predicated on the fact that if the storage is
accessible to you, and you set condition names on it, then comparing the
storage to some value is simply redundant. That's what the condition names
do.
>
>
>
> One man's experience is illustrative, not definitive. I HAVE had to
> search souce code.
>

Yes, I accept that a number of people here have done that. I'd simply
asuggest that you think about it again in the light of this discussion.

(I did, and I think the availability of the storage is pivotal... If it's
available, an 88 is all that's needed. If it isn't, a 77 with a meaningful
name is all that's needed.)

Having said all of that, all of us will do whatever we are comfortable with.

Pete.

2006-04-27, 7:55 am

In article <4bbg17F10p6iiU1@individual.net>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
><docdwarf@panix.com> wrote in message news:e2l32v$n5q$1@reader1.panix.com...

[snip]
[color=darkred]
>Could I take a raincheck? It sounds delightful... perhaps next time I'm in
>New York? :-)

Well... the tea might be a bit cold by then... but I'm sure something
might be arranged.

[snip]

>I seem to recall that set UPSI bytes in 1400 compatibility mode... Ah, happy
>times.... :-)
>
>
>
>
>What about serial reusability (in IMS and CICS) where a 'progress indicator'
>can be used to decide at which point in the 'conversation' you decide to
>resume?

This is something which I have not seen implemented with any kind of
frequency in the environments with which I have experience, Mr Dashwood.

>The first statement following the Procedure division is not
>necessarily the first statement executed EVERY time the program is entered.
>Whether a SPA is used or the length of EIBCALEN (and that is not a way in
>which I would use that field), or some other field in some other terminal
>dependant buffer in some other system, a good online programmer will make no
>assumptions about the values of storage.

This is dicey. On the one hand we agree, 'until demonstrated otherwise
nonexistence is the default condition'... on the other hand the value
greater than zero for EIBCALEN is considered to be 'a demonstration
otherwise'.

>Initial settings are useful for
>batch programs; they are not so useful for rentrant, reusable, or serial
>reusable code.

To have 'less usefulness' is to have, still (to some degree), usefulness.

>
>I already conceded that I do not disagree with initializing storage. I have
>reservations about its usefulness in online environments, that's all...

Once again, to fall back on my own meagre experience, I have never
encountered a situation where an initialised field had 'negative
usefulness'.

[snip]

>
>And you are the King of England... :-)

God save the Me!

DD

2006-04-27, 7:55 am

In article <khu0525jlduj036q56lj671fsmcmi45mnv@4ax.com>,
Binyamin Dissen <postingid@dissensoftware.com> wrote:
>On Wed, 26 Apr 2006 13:16:24 +0000 (UTC) docdwarf@panix.com () wrote:
>
>:>IF DISPLAY-NUMERIC = 0:
>
>:>CLC 0(17,2),25(12)
>:>BC 7,280(0,11)
>
>:>IF DISPLAY-NUMERIC ZERO:
>
>:>L 2,300(0,9)
>:>CLC 0(17,2),25(12)
>:>L 11,56(0,12)
>:>BC 7,310(0,11)
>
>:>... which is less efficient.
>
>Try the instructions in the opposite order.
>
>I think that this is a coincidence.

The compiler appears to bear out your thinking, Mr Dissen... when coded
as:

001800 IF DISPLAY-NUMERIC ZERO PERFORM A-PARA THRU A-EX.
001900 IF DISPLAY-NUMERIC = 0 PERFORM A-PARA THRU A-EX.

.... the PMAP... errrrr, LIST shows:

000018 IF
0003A2 D510 2000 C019 CLC 0(17,2),25(12)
0003A8 4770 B118 BC 7,280(0,11)

....

000019 IF
0003B8 5820 912C L 2,300(0,9)
0003BC D510 2000 C019 CLC 0(17,2),25(12)
0003C2 58B0 C038 L 11,56(0,12)
0003C6 4770 B136 BC 7,310(0,11)

DD

Howard Brazee

2006-04-27, 6:55 pm

On Thu, 27 Apr 2006 21:11:18 +1200, "Pete Dashwood"
<dashwood@enternet.co.nz> wrote:

>
>Why would ANY field be hard to find with a modern editor... or even SPF?
>
>I don't understand this at all.

Because there can be multiple names for the same field - which can
happen with a redefines as well.

Searching through my source-library for all programs that updates a
field from a copy member, I have to look for every possible way to
update that field.

Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com

Clark Morris

2006-04-27, 6:55 pm

On Thu, 27 Apr 2006 22:35:04 +1200, "Pete Dashwood"
<dashwood@enternet.co.nz> wrote:

>
>"Peter Lacey" <lacey@mts.net> wrote in message
>news:444E3CC6.6252500@mts.net...
>Sorry. I see no connection between something that represents a condition
>(and doesn't physically exist) and something that represents storage, and
>does. I'm not being difficult Peter, I honestly don't see it.

The fun with 88 levels is that the name(s) on the 88 condition
statements don't have to have any relationship with each other or the
field to which they apply (which may be named FILLER). I have used 88
levels in conjunction with fillers so that all manipulation is by "SET
condition-name" TO TRUE. I have come to like the idea of named
constants so that I can write the statement "IF file-a-status =
record-not-found-value". Some optimizing compilers might even
optimize the compares that use 1 byte values. The reasons that I am
now leaning toward the latter construct (which I have appropriated
from an otherwise sloppy application vendor) is the ability to see
everywhere a field is used or changed as well as the values used. I
think that it makes it easier to find why a given condition isn't true
when debugging.
>Then you are not talking about an 88 level. Neither BAL nor 8086 assembler
>(I have facility with both of them) implements a COBOL 88. They DO implement
>a similar function, at Assembly time... providing you use the macro
>facility.
>
>The purpose for which a 77 is intended is to allocate a non-synchronized
>elementary item in COBOL. It has nothing to do with evaluating a condition.
>OK, now I understand your objection. Again it really shouldn't matter
>whether they are on consecutive lines or not. The STORAGE used by an 88 is
>irrelevant. The condition that the name represents is what matters.
>
>Confusion only arises because sometimes the 88 is used to 'Document' the
>contents of a piece of storage, and sometimes it is used 'independently' to
>describe a condition that needs to be 'remembered' for processing purposes.
>I tried to demonstrate both of these in my original post. In doing so, I
>pointed out that even if the condition is applied in a 'documentary' way,
>you don't HAVE to reference the storage. It really comes down to style and
>preference.
>
>Why does it matter? The logic is the same either way. What matters are the
>described conditions.
>
>
>But there is no need to, and they take extra storage. The language provides
>a facility to do exactly what you are doing with 77 levels, but you seem to
>prefer not to use it...
>
>
>Sure, that's why an 88 level is better. It removes the need for explicit
>ORing and testing storage.
>
>That is hardly 'thoughtful' use of condition-names is it? Besides,
>programmers are used to looking carefully at datanames aren't they :-)?
>
>Programming should be a thoughtful process. When it isn't, problems arise...
>Ah, that's why we're having this discussion... :-)
>
>
>That's a good example, Peter and I take your point.
>
>Some people will definitely prefer to have an explicit statement of what the
>customer type is. I would suggest that they should not use 88 levels. Others
>will have no problem realising that the type is implicit in the condition
>name. They can use them (thoughtfully.... :-)) without problem.
>
>The discussion gets extended further when we come to OO. If we name an
>attribute of an object to be cust-type and the object recognises that this
>attribute can have certain values, it might indeed make sense to use 77
>levels when GETing and SETing the attribute. But then there is no need for
>an 88 level at all.
>
>77 retail-customer pic x value 'R'.
>77 wholesale-customer pic x value 'W'.
>77 internet-customer pic x value 'I'.
>
>...
> invoke customerObj 'SET-cust-type'
> using retail-customer
> end-invoke
>
>The only difference here is that the actual storage (attribute) is not
>available in the calling program and if it did have 88 levels on it, they
>would not be available outside the object.
>
>I think my argument is predicated on the fact that if the storage is
>accessible to you, and you set condition names on it, then comparing the
>storage to some value is simply redundant. That's what the condition names
>do.
>
>Yes, I accept that a number of people here have done that. I'd simply
>asuggest that you think about it again in the light of this discussion.
>
>(I did, and I think the availability of the storage is pivotal... If it's
>available, an 88 is all that's needed. If it isn't, a 77 with a meaningful
>name is all that's needed.)
>
>Having said all of that, all of us will do whatever we are comfortable with.
>
>Pete.
>
>

Richard

2006-04-27, 6:55 pm

> Why would ANY field be hard to find with a modern editor... or even SPF?

Some of us use tools rather than just an editor.

For example if I wanted to find every program that referenced a
particular field in a file then I can use `grep -i fieldname *.cbl
*.pd`. If the refernces are via 88 levels then this will not find
those.

Even with an editor I would have to search for each condition name.

Binyamin Dissen

2006-04-27, 6:55 pm

On Thu, 27 Apr 2006 12:17:13 +0000 (UTC) docdwarf@panix.com () wrote:

:>In article <khu0525jlduj036q56lj671fsmcmi45mnv@4ax.com>,
:>Binyamin Dissen <postingid@dissensoftware.com> wrote:
:>>On Wed, 26 Apr 2006 13:16:24 +0000 (UTC) docdwarf@panix.com () wrote:

:>>:>IF DISPLAY-NUMERIC = 0:

:>>:>CLC 0(17,2),25(12)
:>>:>BC 7,280(0,11)

:>>:>IF DISPLAY-NUMERIC ZERO:

:>>:>L 2,300(0,9)
:>>:>CLC 0(17,2),25(12)
:>>:>L 11,56(0,12)
:>>:>BC 7,310(0,11)

:>>:>... which is less efficient.

:>>Try the instructions in the opposite order.

:>>I think that this is a coincidence.

:>The compiler appears to bear out your thinking, Mr Dissen... when coded
:>as:

:>001800 IF DISPLAY-NUMERIC ZERO PERFORM A-PARA THRU A-EX.
:>001900 IF DISPLAY-NUMERIC = 0 PERFORM A-PARA THRU A-EX.

:>... the PMAP... errrrr, LIST shows:

:>000018 IF
:> 0003A2 D510 2000 C019 CLC 0(17,2),25(12)
:> 0003A8 4770 B118 BC 7,280(0,11)

:>...

:>000019 IF
:> 0003B8 5820 912C L 2,300(0