RE: Packed vs. Signed db fields

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.