- Original Message -
From: Timothy Sipples sipp...@sg.ibm.com
To: IBM-MAIN@LISTSERV.UA.EDU
Cc:
Sent: Tuesday, April 21, 2015 4:13 AM
Subject: Re: COBOL's NUMPROC compiler option
OK, but what are we talking about here, in performance terms? NUMPROC(MIG)
versus NUMPROC(NOPFD) offered some
In 8918505894176310.wa.m42tomibmmainyahoo@listserv.ua.edu, on
04/20/2015
at 03:11 PM, Tom Marchant
000a2a8c2020-dmarc-requ...@listserv.ua.edu said:
It is easy for us to fault the designers of System/360 and OS/360
for not considering the future requirement for more than 16 MB.
In 7935647633061500.wa.paulgboulderaim@listserv.ua.edu, on
04/20/2015
at 09:39 AM, Paul Gilmartin
000433f07816-dmarc-requ...@listserv.ua.edu said:
I'm a skeptic about Postel's Principle.
Google for MBZ. Your point on F zones is well taken, but given the
card heritage IBM may
OK, but what are we talking about here, in performance terms? NUMPROC(MIG)
versus NUMPROC(NOPFD) offered some performance benefit in the past, but
Enterprise COBOL 5.x offers a performance benefit, too.
Basically, is this 2 steps forward 1 step back, or is it 1 step forward 2
steps back? The
@LISTSERV.UA.EDU
Cc:
Sent: Tuesday, April 21, 2015 4:13 AM
Subject: Re: COBOL's NUMPROC compiler option
OK, but what are we talking about here, in performance terms? NUMPROC(MIG)
versus NUMPROC(NOPFD) offered some performance benefit in the past, but
Enterprise COBOL 5.x offers a performance benefit, too
On Mon, 20 Apr 2015 11:46:57 -0500, Paul Gilmartin wrote:
Had bit 0 not been
pervasively exploited as a flag, 32-bit addressing could have been
accomplished easily.
If there had been no reason to run old code in AMODE 24, 32-bit
addressing could have been accomplished easily.
That was the hope
On Mon, 20 Apr 2015 13:09:14 +0800, Timothy Sipples wrote:
Clark Morris wrote:
Given that IBM CSP and its descendants (IBM VisualAge generator)
generate F signs for positive fields
My understanding is that the currently supported descendants, i.e. EGL,
don't behave this way.
I'm a skeptic
On 19 Apr 2015 22:10:22 -0700, in bit.listserv.ibm-main you wrote:
Clark Morris wrote:
Given that IBM CSP and its descendants (IBM VisualAge generator)
generate F signs for positive fields
My understanding is that the currently supported descendants, i.e. EGL,
don't behave this way.
Let me
On Mon, 20 Apr 2015 11:24:51 -0400, John Gilmore wrote:
The transition was from 24- to 31-bit addressing. Apart from this quibble,
Paul is right here. Unused fields should be initialized innocuously
and, usually, marked as reserved. (From time to time there is of course a
case for making user
The transition was from 24- to 31-bit addressing. Apart from this quibble,
Paul is right here. Unused fields should be initialized innocuously
and, usually, marked as reserved. (From time to time there is of course a
case for making user fields available in control blocks.)
--John Gilmore,
Clark Morris wrote:
Given that IBM CSP and its descendants (IBM VisualAge generator)
generate F signs for positive fields
My understanding is that the currently supported descendants, i.e. EGL,
don't behave this way.
Let me see if I can re-thread the use case needle here, Clark, and please
On 18 Apr 2015 16:24:30 -0700, in bit.listserv.ibm-main you wrote:
Mr. Ross,
Is there going to be a corresponding PACKCHECK compiler option? It is=20
We have no plans for one, but we are very open to suggestions. I have
wondered for years how a customer could actually migrate from
Mr. Ross,
Is there going to be a corresponding PACKCHECK compiler option? It is=20
We have no plans for one, but we are very open to suggestions. I have
wondered for years how a customer could actually migrate from NUMPROC(NOPFD)
to NUMPROC(PFD), and something like that would help. Please
Clark Morris wrote:
I read the APAR and Tom Ross's SHARE presentation and have the following
question.
I must have missed that SHARE presentation, but will search again later for
this.
For now, for what version of COBOL is this applicable?
For installations that have CSP or its descendants,
Mr. Ross,
Is there going to be a corresponding PACKCHECK compiler option? It is
very difficult to locate all of the assembler code that took liberty in
fixing positive pack decimal fields with a sign of F instead of
determining if the result field was signed or not. After all everybody
On 13 Apr 2015 14:52:00 -0700, in bit.listserv.ibm-main you wrote:
I read the APAR and Tom Ross's SHARE presentation and have the
following question.
05 FIELD-CSP PIC S999 PACKED-DECIMAL.
If FIELD-CSP contains x'123f', for NUMPROC(PFD),ZD(MIG) will FIELD-CSP
be NUMERIC in an IF NUMERIC test?
- What is on input as described under NOPFD?
That is on input to a statement, before a statement starts operating on
the data.
- Which allowed behavior of COBOL 5.2 is closer to MIG: NOPFD or PFD?
It depends on what behavior you mean, but for preferred sign correction
you need
I read the APAR and Tom Ross's SHARE presentation and have the
following question.
05 FIELD-CSP PIC S999 PACKED-DECIMAL.
If FIELD-CSP contains x'123f', for NUMPROC(PFD),ZD(MIG) will FIELD-CSP
be NUMERIC in an IF NUMERIC test? So far as I can tell CSP and its
descendants will generate this
Take a look at ZONEDATA(MIG) to see if it's relevant. ZONEDATA(MIG),
introduced this past January (2015), addresses at least some of the use
cases involving NUMPROC(MIG). Refer to APAR PI31403.
On 11 Apr 2015 04:30:06 -0700, in bit.listserv.ibm-main you wrote:
Take a look at ZONEDATA(MIG) to see if it's relevant. ZONEDATA(MIG),
introduced this past January (2015), addresses at least some of the use
cases involving NUMPROC(MIG). Refer to APAR PI31403.
I read the APAR and Tom Ropss's
Whilst pondering our migration to Enterprise COBOL 5.2 I've come upon the
situation that our current compiler option for NUMPROC, the MIG option, is no
longer available. Now we have to decide if we wish to use the more compatible
option NOPFD or the better performing but possibly less
21 matches
Mail list logo
