Peter Farley writes:
And unfortunately [Enterprise COBOL V5.1] does NOT allow the same range
of values that the C/C++ compiler's ARCH option allows.
Enterprise COBOL V5.1 supports compilation for ARCH(6) and above, i.e.
z990/z890 processors and above. Enterprise COBOL V4.2 is still available if
In 4983992839630034.wa.paulgboulderaim@listserv.ua.edu, on
07/19/2013
at 09:15 AM, Paul Gilmartin paulgboul...@aim.com said:
Mathematical/scientific notation tends to use single-character
identifiers, to be case-sensitive, and to admit characters from
Greek, Hebrew, ...
Also. face and
Some all but random responses.
First,
begin extract
That's all well and good for two character values but obviously
doesn't scale beyond a half-word.
/end extract
The problem I was addressing was a two-character/halfword one, and I
raised it originally to illustrate one egregious way in which
On Fri, 19 Jul 2013 08:19:19 -0400, John Gilmore wrote:
The C language switch statement is defined very specifically and
carefully as an SBCS single-character facility. Not at all
incidentally, this definition ensures that branch tables can always be
used to implement a C switch statement.
FSVO
Let me make a distinction between values known a fortiori, like those
of the keywords or reserved words of a statement-level language and
classes of values defined by initial letter, length in characters, or
the like.
It is correct that IBM REXX treats single-letter identifiers
differently from
On Fri, 19 Jul 2013 09:34:41 -0400, John Gilmore wrote:
Organizing a symbol table/dictionary by identifier length is an old
idea. For example, the Lowry-Medlock FORTRAN H compiler, to which I
have referred here before, kept one-, two-, three-, four-, five- and
six-character identifiers is
[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Norbert Friemel
Sent: Thursday, July 18, 2013 7:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Parser
On Thu, 18 Jul 2013 18:12:42 -0500, Norbert Friemel wrote:
There's an ARCH option in COBOL 5.1:
http://pic.dhe.ibm.com/infocenter/pdthelp/v1r1
I 'favor' the mathematical tradition, but it is still infeasible, in
full, for programming. It is likely that in that long run in which I
shall be dead it will be feasible.
For certain kinds of programming a close, very close, approximation to
mathematical notation is already feasible; and it is
Norbert Friemel wrote:
On Thu, 18 Jul 2013 15:24:46 -0700, Tom Ross wrote:
hardware requirements as the z/OS level we required. In particular,
if you have z/OS V1R13 running on 9672, there is no way to compile
with COBOL V5 to get a program that will run on that system.
z/OS V1R13 running
In
CAE1XxDHYkdf=hpg9srqnkk3xddbnweg5z-hk+ozszg02t9o...@mail.gmail.com,
on 07/18/2013
at 11:01 AM, John Gilmore jwgli...@gmail.com said:
I am not quite sure what you mean by the Vienna telephone
Directory,
It would appear that you did know what I meant, if not the exact
edition.
but if you
In
CAE1XxDHQXLXdSU=uf=ica2nfkudeytf+rj4shxp3uy_m2rp...@mail.gmail.com,
on 07/18/2013
at 04:13 PM, John Gilmore jwgli...@gmail.com said:
Of course alphabetic is very inefficient. In the Unioted States more
thsan half of the business in many insurance lines is in CA', 'NY',
and 'TX'.
In
cae1xxdgyyohtcvjaskqu_tjjcw6s8imk8gc5uwdx+mohaea...@mail.gmail.com,
on 07/18/2013
at 03:24 PM, John Gilmore jwgli...@gmail.com said:
I avoided discussion of VDL, lazily perhaps; but it is not really
accessible without a great deal of work unless one knows recursive
function theory well.
I
On 19 July 2013 08:19, John Gilmore jwgli...@gmail.com wrote:
Some all but random responses.
[...]
The C language switch statement is defined very specifically and
carefully as an SBCS single-character facility. Not at all
incidentally, this definition ensures that branch tables can always be
That there are such languages is of course correct,
In them one writes not
r = a | b| c| . . . ;
but
r = a ;
if r then ;
else r = b ;
if r then ;
else r = c ;
if r then ;
else . . . ;
If a language definition requires such ugliness, one must of course
live with it; but it is a PITA.
The
COBOL optimization has always been problematic for two reasons.
The less important of them is that, until now at least, some
syntactically interesting features of the language have been
implemented very poorly. Some COBOL EVALUATEs are, for example,
functionally very like a C switch or a PL/I
On Thu, 18 Jul 2013 08:13:02 -0400, John Gilmore wrote:
COBOL optimization has always been problematic for two reasons.
The less important of them is that, until now at least, some
syntactically interesting features of the language have been
implemented very poorly. Some COBOL EVALUATEs are,
On 7/18/2013 6:46 AM, Paul Gilmartin wrote:
On Thu, 18 Jul 2013 08:13:02 -0400, John Gilmore wrote:
COBOL optimization has always been problematic for two reasons.
The less important of them is that, until now at least, some
syntactically interesting features of the language have been
In
cae1xxdecfrb55hrg7mw+n0epsnozlxpratgefxi9a2k63na...@mail.gmail.com,
on 07/17/2013
at 12:19 PM, John Gilmore jwgli...@gmail.com said:
In PL/I evaluation is always broken off. The standard requires it.
What standard? Certainly not X3-74-1987, and I don't recall any such
requirement in
I am not quite sure what you mean by the Vienna telephone Directory,
but if you mean the Vienna Parkrink VDL formalization of PL/I, you
will find a full treatment of breakoff in it.
John Gilmore, Ashland, MA 01721 - USA
--
For
On 7/18/2013 11:01 AM, John Gilmore wrote:
I am not quite sure what you mean by the Vienna telephone Directory,
but if you mean the Vienna Parkrink VDL formalization of PL/I, you
will find a full treatment of breakoff in it.
Parkrink? Did you mean Parkring, the street dividing the first and
Paul Gilmartin wrote:
begin extract
Which might be the proper implementation if the cases are sparse.
Best to start with the median case value and bisect recursively.
Storage is cheap nowadays, particularly if it's not accessed. But a
large and sparse branch table is an invitation to page
I should have written 'Parkring'. It was written 'Parkrink' on a
document I had in front of me, but that is not really a sufficient
excuse.
I avoided discussion of VDL, lazily perhaps; but it is not really
accessible without a great deal of work unless one knows recursive
function theory well.
Alphabetic would almost certainly be very inefficient. A minimal
optimization would be a binary search of a table or states, or order
the states in most to least order for the (1. number of transactions,
2. number of policies, 3. number of agents, 4, population).Setting a
subscript once and
Why not a different algorithm, based on the number of possible
alternatives? For instance, if only 2 or 3, then a cascading IF/THEN/ELSE.
If over a thousand, maybe a hash table. Just a thought, I'm sure there are
many possibilities.
On Thu, Jul 18, 2013 at 3:02 PM, Mike Schwab
Of course alphabetic is very inefficient. In the Unioted States more
thsan half of the business in many insurance lines is in CA', 'NY',
and 'TX'. Programmers keep such sets of if-then-elses in
lexicographic sequence to simplify their maintenance. Moreover, they
often continue to do so even
On Thu, 18 Jul 2013 15:09:22 -0400, John Gilmore wrote:
Paul Gilmartin wrote:
begin extract
Which might be the proper implementation if the cases are sparse.
Best to start with the median case value and bisect recursively.
Storage is cheap nowadays, particularly if it's not accessed. But a
I am beginning to have a suspicion that some readers at least do not
know how branch tables. C switch statements, and the like work. Here,
given a state-code of, say, 'NY', its two-byte code point, in EBCDIC
x' d5e8', is used as an offset to address a unique byte in that
table, one of bytes 0,1,
Since you are working on performance, have you tried compiling with the
Enterprise COBOL V4.2 compiler? New compilers will generate code that
uses instruction sets on new CPUs. You may get some benefit that way.
Enterprise COBOL V4.2 code can run on old hardware such as the 9672,
we did not
Tom Ross wrote:
begin extract
In particular, if you have z/OS V1R13 running on 9672, there is no way
to compile with COBOL V5 to get a program that will run on that
system.
/end extract
Other statement-level languages deal with this problem by permitting
the specification of an ARCH level, and
On Thu, 18 Jul 2013 15:24:46 -0700, Tom Ross wrote:
On the topic of evaluation of conditions, in z/OS COBOL our generated
code will leave a condition evaluation as soon as we know it is true or
false. We do not keep evaluating other operands if the final result is
clear from earlier ones.
Has
On Thu, 18 Jul 2013 18:59:40 -0400, John Gilmore wrote:
Tom Ross wrote:
begin extract
In particular, if you have z/OS V1R13 running on 9672, there is no way
to compile with COBOL V5 to get a program that will run on that
system.
/end extract
Other statement-level languages deal with this
On Thu, 18 Jul 2013 18:12:42 -0500, Norbert Friemel wrote:
There's an ARCH option in COBOL 5.1:
http://pic.dhe.ibm.com/infocenter/pdthelp/v1r1/index.jsp?topic=%2Fcom.ibm.entcobol.doc_5.1%2FPGandLR%2Frlpre.html
On Thu, 18 Jul 2013 15:24:46 -0700, Tom Ross wrote:
hardware requirements as the z/OS level we required. In particular,
if you have z/OS V1R13 running on 9672, there is no way to compile
with COBOL V5 to get a program that will run on that system.
z/OS V1R13 running on 9672? I think z/OS can
That's all well and good for two character values but obviously doesn't
scale beyond a half-word. If all the keys are already known then a
perfect hash optimized switch statement is one of the most efficient
methods I've seen.
Especially popular with compiler writers for the symbol table.
On
Dear all
I would like to tune some IF THEN ELSE statements by changing operands
positions of OR AND statements in some of my COBOL II v3.4 programs.
Can we say that if always VAR1 assigned to VALUE1 the following statement
(VAR1 EQUAL 'VALUE1') OR (VAR2 EQUAL 'VALUE2)
has better performance
What I suggest you do is compile the program with the assembly option and
look at the code generated.
In the case that something will ALWAYS be equal or not equal, why bother to
test?
But going with your conditions. If you put the know condition first, then
one that satisfies the test, then yes
My response got away from me before I had completed it.
It should have been
You need to keep two things in mind. Even very simple optimizers 1)
break off evaluation with the outcome FALSE as soon as an AND
component is found to be false, and 2) break off evaluation with the
outcome true as
You need to keep two things in mind. Even very simple optimizers 1)
break off evaluation with the outcome FALSE as soon as an AND
component is found to be false, and 2) break off evaluation with the
outcome true as soon as an OR component is found to be true.
Thus trhe components bi of
a = b1
On Wed, 17 Jul 2013 10:56:06 -0400, John Gilmore wrote:
You need to keep two things in mind. Even very simple optimizers 1)
break off evaluation with the outcome FALSE as soon as an AND
component is found to be false, and 2) break off evaluation with the
outcome true as soon as an OR component
Subject:Re: COBOL Parser
Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu
What I suggest you do is compile the program with the assembly option and
look at the code generated.
In the case that something will ALWAYS be equal or not equal, why bother
to
test?
But going
In PL/I evaluation is always broken off. The standard requires it.
One must break up a single expression into several, using temporaries
and some low cunning, to avoid break off.
Side effects can be beneficent or malign. Reflexive hostility to
them, common among academic computer scientists, is
Here IBM have been pushing the 5.1 barrow - even naming numbers.
From the announcement:
With modern advanced optimization and improved exploitation of z hardware,
many well-structured, CPU-intensive batch applications have shown performance
increases greater than 10%
Hmmm - it's that
In
CAE1XxDFnJFuhoXVTBF5X0qmpLPBDE=yJcbUZDQrhSKb83=w...@mail.gmail.com,
on 07/17/2013
at 10:45 AM, John Gilmore jwgli...@gmail.com said:
You need to keep two things in mind. Even very simple optimizers 1)
break off evaluation with the outcome FALSE as soon as an AND
component is found to be
I wouldn't take well structured too literally here. Or, at least, I think
it's best to consider the compiler developer's definition of well
structured which is at least somewhat different than the application
developer's.
Again, this is fairly easy stuff to measure -- in the statistical sense
44 matches
Mail list logo
