Re: Users of CSP and its successor migrating to COBOL 5.1

2014-02-13 Thread John Gilmore
Clarke Morris wrote: begin extract The problem is not the compiler options used for the COBOL generation of CSP programs, the problem is the compiler options of the programs that use the output from CSP programs. /end extract and I disagree. The problem here is one of incoherence. All of the

Re: Users of CSP and its successor migrating to COBOL 5.1

2014-02-13 Thread Ed Gould
On Feb 13, 2014, at 9:24 AM, John Gilmore wrote: Clarke Morris wrote: SNIP-- John Gilmore replied: More generally, the traditional COBOL-shop aversion to recompiling is one that urgently needs to be discarded. It was never sensible, and it is no

Re: Users of CSP and its successor migrating to COBOL 5.1

2014-02-13 Thread Paul Gilmartin
On Thu, 13 Feb 2014 10:24:44 -0500, John Gilmore wrote: Clarke Morris wrote: begin extract The problem is not the compiler options used for the COBOL generation of CSP programs, the problem is the compiler options of the programs that use the output from CSP programs. /end extract and I

Re: Users of CSP and its successor migrating to COBOL 5.1

2014-02-13 Thread Tom Ross
If other programs that handle files created by CSP (and maybe its successors) were using NUMPROC(MIG) because it was more efficient than NUMPROC(NOPFD), then those programs may have to be recompiled with NUMPROC(NOPFD) because there can be problems. I ran into that with a program that for

Re: Users of CSP and its successor migrating to COBOL 5.1

2014-02-13 Thread Clark Morris
On 13 Feb 2014 09:35:50 -0800, tmr...@stlvm20.vnet.ibm.com (Tom Ross) wrote: If other programs that handle files created by CSP (and maybe its successors) were using NUMPROC(MIG) because it was more efficient than NUMPROC(NOPFD), then those programs may have to be recompiled with NUMPROC(NOPFD)

Re: Users of CSP and its successor migrating to COBOL 5.1

2014-02-12 Thread Paul Gilmartin
On Tue, 11 Feb 2014 22:47:42 -0400, Clark F Morris wrote: ... CSP and possibly its successor forced an F zone on all signed fields with positive values leaving the D zone for negative fields. The elimination of NUMPROC(MIG) means this behavior if still existing can cause problems. ...

Re: Users of CSP and its successor migrating to COBOL 5.1

2014-02-12 Thread John Gilmore
Paul Gilmartin's point has merit; but, as usual, the details matter. Mike Cowlishaw's design of the [now IEEE-standard] z/Architecture decimal floating-point (DFP) format 1) distinguishes -0.0e+000 from +0.0e+000, and 2) ensures that they compare equal architecturally. The distinction is useful

Users of CSP and its successor migrating to COBOL 5.1

2014-02-12 Thread Tom Ross
If your shop uses an IBM z series computer and it is looking to upgrade to version 5.1 of Enterprise COBOL and it is using Cross System Product (CSP) or its Visual Gen successor, migration may be a problem. CSP and possibly its successor forced an F zone on all signed fields with positive values

Re: Users of CSP and its successor migrating to COBOL 5.1

2014-02-12 Thread Clark Morris
On 12 Feb 2014 13:59:28 -0800, in bit.listserv.ibm-main you wrote: If your shop uses an IBM z series computer and it is looking to upgrade to version 5.1 of Enterprise COBOL and it is using Cross System Product (CSP) or its Visual Gen successor, migration may be a problem. CSP and possibly its

Users of CSP and its successor migrating to COBOL 5.1

2014-02-11 Thread Clark F Morris
If your shop uses an IBM z series computer and it is looking to upgrade to version 5.1 of Enterprise COBOL and it is using Cross System Product (CSP) or its Visual Gen successor, migration may be a problem. CSP and possibly its successor forced an F zone on all signed fields with positive values