export fixed length file

[Dennis Malen]

Ken,

Thanks for your response. I failed to inform the list with my post that this 
is not a report format. The requirement of this processing was that I needed 
to append information to a file many times during the day. I therefore was 
not able to use the -x.

The approach I used with the "&" and the chr("10") was a trick I learned 
from you on a prior post. It had been working well ever since. The current 
post was the first time that the dummy fields exceeded a processing line. 
That is why I initially used met(1) and met(2) not realizing that the last 
dummy field in met(1) and the first dummy field in Met(2) would not maintain 
the character length.

That is why I used xx & yy which solved the problem. I then only had to use 
met(1). The following is the beginning of my export statement:

then: pn="/tmp/metro"{dt{".txt"
  -   -   -   -   -   -

then: export ascii met=(pn) -a

Thanks to your suggestion I am always able to append to a fixed length file.

Dennis Malen
516.479.5912


----- Original Message ----- 
From: "Kenneth Brody" <kenbrody at bestweb.net>
To: "Dennis Malen" <dmalen at malen.com>; <filepro-list at lists.celestial.com>
Sent: Thursday, November 10, 2005 12:49 PM
Subject: Fwd: Re: export fixed length file


> Sending this again...
>
> ----- Forwarded message from kenbrody at bestweb.net -----
>    Date: Wed,  9 Nov 2005 17:46:11 -0500
>    From: Kenneth Brody <kenbrody at bestweb.net>
> Reply-To: Kenneth Brody <kenbrody at bestweb.net>
> Subject: Re: export fixed length file
>      To: Dennis Malen <dmalen at malen.com>
>
> Quoting Dennis Malen (Wed, 9 Nov 2005 17:09:01 -0500):
>
>> When doing an export on a fixed length ascii file I found that when
>> using two export identifiers (not sure of the terminology) that the use
>> of a second export identifier caused the values to be pushed left even
>> though the respective fields were defined as certain lengths.
>
> Leading and trailing blanks from the fields are stripped unless you
> use the "-x" flag.
>
>> The following should give you an idea of what I mean:
>>
>>  met(1)=a&b&c&d&e&f&g&h&i&j&k&l&m&na&o&p&q&r&s&t&u&v&w&x&ya&z     ~
> [...]
>>  met(2)=aa&bb&cc&dd&ee&ff&gg&hh&ii&jj&kk&ll&ma&nn&oo&chr("10");write met
> [...]
>> Above, I had to use met(1) and met(2). This caused only z(30) and
>> aa(27) to be corrupted concerning the lack of its ability to maintain
>> the defined length of the respective fields.
>
> Leading and trailing blanks were stripped from each of the two export
> fields.  If "a" or "aa" have leading blanks, they will be stripped, and
> if "z" has trailing blanks, they will be stripped.
>
>> In order to fix the problem I had to do the following which was to
>> create two dummy fields that held the value of each line and then
>> send it out as met(1) only. I have not included the processing
>> showing the dummy fields defined as that was not causing the problem.
> [...]
>>  xx=a&b&c&d&e&f&g&h&i&j&k&l&m&na&o&p&q&r&s&t&u&v&w&x&ya&z          ~
> [...]
>>  yy=aa&bb&cc&dd&ee&ff&gg&hh&ii&jj&kk&ll&ma&nn&oo&chr("10")
> [...]
>>  met(1)=xx&yy;write met                                            ~
>
> Leading and trailing blanks will still be stripped.  If field "a" has
> leading blanks, they will still be stripped.
>
>> The above fixed the problem.
>>
>> Some of you may not be aware that this approach causes a problem and
>> some of you may have a better fix.
>
> No problem here.  If leading and trailing blanks are important, use
> the "-x" flag.
>
> ----- End forwarded message -----
> --
> KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
> http://www.hvcomputer.com
> http://www.fileProPlus.com
>
>
>