|
> > They are about to implement "standards" which say to make ALL numeric fields > in the db zoned fields. The argument being for the "chance" that they MAY > at some time in the future have to interface with a PC package which MAY use > FTP to download AS400 files. > I sure hope they're making the same concessions on the PC. i.e. storing everything in a format, such as XML, that can be FTPed and read by iSeries programs. If they're using software like Word, Excel, etc, other than the absolute newest versions of these, the data is unreadable by the iSeries, and therefore violates their rules. Granted, these things can be exported to other formats -- but likewise, your DB2 databases with packed numbers could be exported to other formats (CPYTOIMPF is there explictly for this purpose) Unless the iSeries is being treated as a 2nd-class machine, this rule should be enforced both ways. Not only THAT, but zoned decimal is not directly exportable to the PC unless it contains a positive number. Negative numbers will STILL be a problem. > I'm arguing that signed numeric is not really "native" to the AS400 > architecure, wastes disk space, and is a performance issue. This one small > issue is a problem for me, since it is "just not right" and I have problems > with doing things that I feel are just wrong. Expressing a (hopefully) > educated opinion is part of being a consultant, I feel. > It's called "zoned" not "signed numeric". Packed, Zoned, Integer all support being signed. > The slight cumulative performance gain is enough for me, having worked on > over-taxed AS400s before where a nanosecond gained was a nanosecond gained. > They are saying that "disk is cheap" and that we have plenty of disk and > performance now. I'd like to win this argument, since it just ain't right, > particularly for a "standard". I agree that this "just doensn't seem right". But, I don't think you'll ever notice the performance difference, or disk space... we're not talking about much here. Even on a billion records, a nanosecond per record difference isn't going to affect the bottom line. And disk space... Wow. Using packed instead of zoned isn't going to make much difference here. If disk space is truly an issue, you'd be better off using some sort of zipping/compression software for uncommonly used objects. I can almost guarantee that there are 10 things wasting more space than the packed vs. zoned issues. > > Does anyone have a convincing argument for this "small" issue, or any kind > of stats on the performance just thrown out the window? > Decide on what's important to the company. If interoperability between PC/OS400 is of top importance, then you need to make sure that all of the PCs follow suit as well. I'd also store all numerics in alphanumeric fields, using edit codes so that the negative numbers are represented in a PC-friendly manner. Yes, this will hurt performance, but if interoperability takes priority, then that's what you do... if you don't mind exporting things before having the interoperability, then you can concentrate on performance. Packed performs slightly better than zoned. (and much better than parsing a character string!!) In this case, you can export the files when you need them. Likewise, you can export them on the PC. Problem solved.
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.