Re: J4 - presentation/discussion on "Future of the COBOL Standard"

On Mar 19, 7:31 am, Robert <n...@xxxxxx> wrote:
On Tue, 18 Mar 2008 09:02:56 -0600, Howard Brazee <how...@xxxxxxxxxx> wrote:
On Tue, 18 Mar 2008 08:15:40 -0600, Robert <n...@xxxxxx> wrote:

I already addressed it by pointing out that Cobol lets you use picture V in binary
integers, thus eliminating the imagined need for comp-3.

Was there ever a "need" to use packed-decimal? In my experience it
has always been a matter of knowing what is most efficient to use with
the system I'm using.

On which mainframe was binary slower than packed decimal?

IBM 1401

You are limiting yourself by only being able to consider simple
arithmetic operations. It may well be that on most machines adding,
multiplying and such on 32bit binary are faster. However for
commercial work data input, print output and display is just as
important.

Converting between display and packed for large numbers with scaling
was likely to be faster than the conversion for binary.

Another issue is that hardware support for binary was only 32 bit (or
24 on ICL 1900, I still remember 8,388,607) and this was inadequate.
Larger binary required code routines to deal with these numbers which
was considerably slower. Hardware support for packed may have been
slower for small numbers but it overtook the software support where
accounting sized numbers were used, and trounced it on converting to
display for printing.

It was possible to have unaligned or part word binary but this added
the overhead of unpacking and repacking the data for each operation.

The language provided me options - I was supposed to pick the option
that fit the system I was working with that best fit the requirements
of my employer.

The requirement was correct answers. How did packed fit the requirement better than
binary?

Packed also could be written to tape using byte size increments to
better utilise capacity. Binary 32 bit or 64 bit (software supported)
would actually waste space.

Having done tests back in the late 70s comparing Cobol packed, binary
and display calculations and _including_ formatting for input,
printing and display for typical applications (eg invoicing) the
packed was actually just ahead of binary. Obviously as more complex
calculations were required then the binary may have won.

Today there is hardware support for 64 bit and that makes a
significant difference, one that 30 or 40 years ago was not available.

.

Relevant Pages

  • Re: Displaying MAC graphics in IE6
    ... Even tried converting them to GIF files and uploading those - same ... But other pix will. ... >> provide a link to each pix, they will display BUT if I embed them in the ...
    (comp.sys.mac.graphics)
  • Re: 6502 screen too big
    ... >> In short i cannot fit in the screen display for most games on!6502em ... > First of all what MDF are you using? ... one for a Samsung 172v it was the nearest to my monitor type. ...
    (comp.sys.acorn.misc)
  • Re: Image Size
    ... Is there not a way to tell the browser to ... it fit to the active window) ... to decide how images are displayed when they are too large to fit the ...
    (microsoft.public.frontpage.programming)
  • Re: 6502 screen too big
    ... > In short i cannot fit in the screen display for most games on!6502em ... First of all what MDF are you using? ... One designed for the monitor is better ...
    (comp.sys.acorn.misc)
  • Re: Results of trend line in Excel
    ... The most likely cause is that you are working with two few digits. ... format the trendline equation to display more digits I am sure you will find ... Best to use LINEST to get the coefficients into cells; ... I created data in the range of the fit so there is no error ...
    (microsoft.public.excel.charting)