What I was saying was simply that integer values, those in the sequence . . . -5, -4, -3, -2, -1, 0, +1, +2, +3, +4, +5, . . .
should always be binary. Bean counters, perform indices, and the like obviously fall in this category. If you are counting something, beans, iterations, days, jam jars, whatever, use binary. In particular, never use packed-decimal indices or subscripts. The question how to use floating-point in COBOL is a vexed one. It is/would be possible to use both IBM hexadecimal floating point (HFP) and ANSI binary floating point (BFP) in a COBOL routine, but it is fair to admit that one needs to know both too much and kinds of things that COBOL programmers seldom know to do so successfully. Some years ago this situation changed dramatically. Mike Cowlishaw---he who designed REXX---devised what is now ANSI decimal floating point (DFP). DFP behaves consistently in ways that do not surprise accountants. (All three floating-point formats are supported by zArchitecture hardware.) Although there has been ample tIme to do so, IBM COBOL does not yet support DFP. It should. When IBM COBOL does support DFP, it will be possible to eliminate packed-decimal (except as a transitional data type in certain conversion operations) from COBOL routines; and doing so will confer large performance advantages. John Gilmore, Ashland, MA 01721 - USA > Scott ford > www.identityforge.com > > On Jul 14, 2012, at 12:34 PM, Chris Mason <chrisma...@belgacom.net> wrote: > >> John >> >>> Integer arithmetic should never be done with anything but binary >>> integers. >> >> "What never?" >> >> One excuse might be when the only arithmetic to be performed is to add up >> "a column" of numbers and present the result. Converting to packed >> decimal, adding using the packed decimal instruction and then converting >> the total to the printable form might be an example of where staying with >> packed decimal is the more efficient. >> >> "Well, hardly ever!" >> >> - >> >> To all following this topic >> >> Even before John Gilmore's assertion, I had in mind to tell a story >> concerning the relative efficiency of packed decimal. >> >> Forty years ago in the north-west of England, an IBM salesman was faced >> with losing one of his customers. Competition had muscled in and proposed >> a machine potentially more suited to the demands made on the customer's >> business - and their pocket. The salesman's response was to propose >> replacing the 360/30 with a 360/25 which I believe had only recently - at >> the time - been added to the 360 range, extending it "downwards" - >> ignoring - *obviously* - the 360/20! >> >> The customer - or perhaps the competition - proposed running a benchmark >> and the customer supplied both contenders with the source of an assembler >> program key to their operation. >> >> It's important to know that the 360/30 the customer already had was >> literally "basic" in that disks were not a feature of the configuration >> with all storage on tape. Thus the operating system was Basic Programming >> System (BPS) Tape. There was a BPS-Tape assembler compiler of course but >> there was no COBOL compiler. It may have been a bit of a disappointment - >> maybe even a surprise - for the competition that they were not provided >> with COBOL source. >> >> The customer was an organisation which set and evaluated examination >> papers for secondary schools. The "benchmark" program had the >> responsibility of sorting the sheep from the goats. It did so on the basis >> of assuming the results formed a "bell curve" and then fenced the anxious >> teenagers based on the standard deviation.[1] >> >> Obviously - or I wouldn't be telling this story! - all the arithmetic was >> performed using packed decimal and the "heavy lifting" was in determining >> the variance: the mean, the differences from the mean and the squares of >> the latter.[2] >> >> I was one of a team of three assigned to win this benchmark to replace a >> bigger machine with a smaller machine! The team leader initiated the >> effort by simply writing the tape records as blocks. This reduced the >> execution time by half from about 30 minutes to 15 minutes - and would >> probably have been sufficient to win the contest. However I had my eye on >> those unsavoury packed decimal instructions! >> >> Essentially I rewrote the whole program using binary arithmetic >> instructions to replace the packed decimal instructions. I happened to >> mention what I was doing - more strictly, had done - to one of my >> colleagues - of an academic bent comparable to our own John Gilmore! He >> responded by reminding me - or in case I didn't know - that use of base >> registers was faster than using index registers. Of course, either I had >> forgotten or just didn't know before.[3] Back to the 129 in order to rekey >> a significant percentage of the source program cards with commas in front >> of the register numbers where a storage reference was required - or >> implied. >> >> Mistake! The BPS-Tape assembler can't handle "(,R)" like its more >> sophisticated cousins can. The BPS-Tape assembler requires "(0,R)". Back >> to the 129 again. >> >> Did the fundamental change to the type of instruction performing the >> arithmetic do any good? I seem to remember that a number of seconds were >> "knocked" off the total time, trivial in comparison with the benefits of >> improving the tape I/O. >> >> Again by means of a massive rewrite, I introduced another improvement. I >> can't recall why it was necessary to read the tape with the results >> records multiple times, but this was the way the original program worked >> and so, until this point, I had kept that basic logic. Taking into account >> the proposed storage, I reduced the number of tape passes from - IMMSMC - >> 10 to 2. Again an improvement to be measured in seconds since I had >> managed to extinguish the "wait light" and the tape now limped along where >> previously it had sprinted.[4] >> >> - >> >> [1] There's a lot of discussion these days in the British news media of a >> creep to larger percentages of the higher grades in exam results, >> particularly the exams leading to university entrance. This would not be >> possible if the exam boards continued to use the methodology embedded in >> the analysis of results used by this exam board 40 years ago. >> >> [2] The calculation of the standard deviation was rather clever. In a way >> this also promised to be "heavy lifting" since the determination of the >> square root of the variance depended on iteration. However it must have >> been considered that two iterations were always sufficient.[2.1] The >> refining logic was framed by an initial BALR R,0 and a final BALR R,R. >> >> [2.1] I forget at how the initial guess was arrived but I suppose it may >> have been a constant corresponding to a typical historical value. >> >> [3] The time for compilation of the program was also to taken into >> account. Fortunately I had already been told - or perhaps noticed - that >> the tape operations during compilation worked faster when all macros were >> kept near the beginning of the program source. >> >> [4] I won't even mention that over a drink in the hotel bar before the >> "trysting day", I realised that there was one more possible improvement. >> This would have involved overlaying initialisation logic storage with >> working space! There wasn't time now and it wasn't needed since the 360/30 >> was duly replaced by a 360/25. >> >> - >> >> Chris Mason >> >> >> On Sat, 14 Jul 2012 08:08:03 -0400, John Gilmore <jwgli...@gmail.com> >> wrote: >> >>> Doing integer--as opposed to real fixed-point--arithmetic with >>> packed-decimal values is the real culprit here. >>> >>> Integer arithmetic should never be done with anything but binary >>> integers. Operations on them are register operations, which are much >>> faster than storage-to-storage ones; and zero is always positive. >>> Moreover, it is now possible to make them behave in COBOL exactly as >>> they do in assembly language. >>> >>> John Gilmore, Ashland, MA 01721 - USA >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
