|
There are a couple of things you can do to work around the problem with FTP of packed fields. One is a logical that redefines the numerics as signed. The other is doing a CPYTOIMPF to an IFS work file and sending that by FTP. If the PC system is on the same network as the 400 there's also the possibility of using CPYTOIMPF to a QNTC share on the PC. When it's configured properly it's even easier than scripting an FTP transfer. I'm guessing that FTP to PC or 'NIX is in the future even if it seems unlikely now. One argument on the coding side is that RPG programs internally represent signed fields in files as packed. Future programs could need a lot of data structures to redefine the fields when they have to be zoned. Sounds like some of these folks need to be put on a committee to draft a new mission statement or investigate the optimum color for post it notes. <g> > -----Original Message----- > From: William A.(Tony) Corbett [mailto:corbett@xxxxxxxxxxxxxxx] > Sent: Friday, May 16, 2003 8:52 AM > To: rpg400-l@xxxxxxxxxxxx > Subject: Packed vs. Signed db fields > > > Hi, > I'm currently involved in creation of coding "standards" for a shop > consisting of a few FT programmers and several contract programmers. > > 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'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. > > 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". > > Does anyone have a convincing argument for this "small" > issue, or any kind > of stats on the performance just thrown out the window? > > TIA > > AS/Resources, Inc. > William A.(Tony) Corbett > IBM Certified Specialist - AS/400 Developer > http://www.asresources.com > corbett@xxxxxxxxxxxxxxx > 770-587-4812 (office) > 678-935-5006 (mobile) > fax: 404-663-4737 > > > NOTICE: All e-mail sent to or from this e-mail address will be received or otherwise recorded by The Sharper Image corporate e-mail system and is subject to archival, monitoring, review by and/or disclosure to Sharper Image security and other management. This message is intended only for the use of the addressee and may contain information that is privileged and confidential. The contents of this message may contain personal views which are not the views of The Sharper Image. If you are not the intended recipient, dissemination of this communication is prohibited.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.