|
Based on other responses, I knew that the AS/400 could do Integer much faster but I had always thought the AS/400 had built in support for packed decimal arithmetic that was inherent in the hardware or MI. My response was based on using zoned Vs packed, not on whether integer was faster than packed. Hans response was that this was done for accuracy purposes only. So question still seems open. Are you better off using packed decimal for parameters or zoned? My understanding is packed. Zoned is something left over from the System 36. Obviously if this was counter or some other kind of zero precision number you would want to use integer but creates a problem because CL does not support binary types. If you are using a command interface, you can pass values to a RPG ILE that are binary, i.e. integer but not to CL. I started using integers for my service program functions but quickly got burned on that one when I try to call one of the functions with an integer parameter and, of course, it blows up. There are ways to get around it. (Create a wrapper function for CL to accept packed and covert to integer and call function or call a function to create a binary value in a string and pass that(ugly!)) but what seems safer is using packed decimal for parameters on service program functions. Anybody got any opinion on that. Thanks. -----Original Message----- From: Shaw, David [mailto:dshaw@spartan.com] Sent: Friday, January 21, 2000 6:44 AM To: 'RPG400-L@midrange.com' Subject: RE: Entry Parameters -----Original Message----- From: Alan Campin [mailto:Alan.Campin@CaseLogic.com] Not to argue here. Maybe Hans could give use the true run down but all my understanding in 20 years of technical journals and performance tips says that the AS/400 is a packed decimal machine, the only one in the world. I believe that this has been extended to allow efficient other types (Like integer) but the native format of an AS/400 is packed decimal to the point where the math is done in a base 10 format(for absolute precision), not base 2(Binary). In other words, the AS/400 is business data processing machine, not a scientific machine. If you have ever had to work on a machine that uses floating point number to represent decimal values and all the problems inherent in that, you know what I mean. We are really spoiled on the AS/400 because we never have these kind of problems. Everything I have read says the AS/400 takes a zoned value, converts it to packed decimal, does the arithmetic in Base 10 and then converts the result back to zoned. ---------------------------- My understanding is that the AS/400 directly supports packed decimal, zoned decimal, integer, and floating point arithmetic. Many of the major business computers support decimal arithmetic without resorting to floating point - you don't think that S/360, S/370, and S/390 machines only do floating point and integer, do you? Or that business machines from Burroughs or Sperry Univac had that kind of disadvantage relative to IBM? After all, the COBOL standards specify support for decimal arithmetic in COBOL programs. My experience is that the decimal arithmetic issue mainly applies to the scientific machines, things like VAXes and Unix boxes. As for the implicit conversion to packed, I have read a number of times that it's the RPG III compiler that does that, not OS/400 and not the hardware. Dave Shaw +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +--- +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.