RE: Using an Expression to control a FOR loop

Hello Scott,

I don't mind being forced to use zoned decimal because the output file
is for my use only. Typically (well, so far just once), I'm going to
write a program to use the file I create here. And I've kind of gotten
away from defining anything but 'S' -type numeric disk fields once I
(wrongly?) decided that format was more compatible with the Windows
world. But this discussion has been very helpful to me (despite the risk
of exposing my stupidity).

Thank you, all, again.

Arthur J. Marino
RockTenn Corporation
(631) 297-2276

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Friday, March 27, 2009 3:00 AM
To: RPG programming on the IBM i / System i
Subject: Re: Using an Expression to control a FOR loop

Hi Arthur,

So the PF you're writing to always uses zoned decimal output fields?
Never packed or integer? Because padding with EBCDIC zeros wouldn't
work well for packed or integer. You'll also need code to deal with
negative numbers...

Personally, I wouldn't try to do all this numeric formatting manually.
I'd load the numeric values into a very large RPG numeric field (say,
63P30 or something like that) using the %DEC() BIF to convert the data.
Then, I'd use _LBCPYNV to copy that 63P30 to the destination number.
_LBCPYNV will happily take parameters for the size/decpos of the output
data that can be changed at run-time. IT can output to and zoned,
packed, integer, with little difficulty.

And since it's build into the MI layer of the OS, it's very fast, and
it's results will always be consistent with the way the rest of the OS
would read/write that type of number.


Arthur Marino wrote:

Thank you, Doug and Scott. The one downside to asking this august

group

a question is the ever present possibility that I'll expose my own
stupidity. But since you asked...

What I'm trying to do here is create a generic delimited file parser.
I've had one too many users tells me they have a s/sheet for me, and I
need to get it into a file on the 400 ('scuse me) so I can do

something

useful with it.

I'm making 2 passes thru the data.

First it determines 'max' field attributes for every column in the

.csv

file and then displays a subfile showing the 'DDS'. The user (me) can
unlock this data in order to make changes to generated field names,
lengths, decimal positions and COLHDGs. Lengths can be left alone or
made larger, decimals can be changed up or down. Then it builds the

DDS

source member and creates the file. Then there's an override/open on

the

program-described 'dummy' output file (reclen=4096) to the file just
created.

The 2nd pass reads the data for the sole purpose of building a string
that exactly mimics the DDS record layout. That's why the alpha fields
have to be padded with blanks, numeric fields have to be prefixed with
zeros, decimal positions have to be aligned, so when I do the

exception

output of the string to the dummy, everything is kosher on disk.

Thanks again to all.

Arthur J. Marino
RockTenn Corporation
(631) 297-2276
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Thursday, March 26, 2009 1:52 AM
To: RPG programming on the IBM i / System i
Subject: Re: Using an Expression to control a FOR loop

Douglas Handy wrote:

Then a second pass standardizes the data in each column to the

maximum

size

and decimals detected for that particular column during the first

pass.

There "coldta" is the contents of a column of data but the size can't

be

determined at compile time as in:

D zeros s like(coldta) inz(*zeros)

I don't agree with you. The code I work will work perfectly well
despite the size being unknown at compile time. Think about it. The

OP

defined a variable called ColDta that he stored the column data in.

How

could he possibly do that if he doesn't know the size of the field?

The

answer is simple: ColDta is defined as the MAXIMUM possible size of a
field. Since it's a VARYING field, he can set the length to be

smaller.

My code, similarly, will work. It doesn't matter that you don't know
the field size at compile time, because I did the following:

coldta = %subst(zeros:1:cwdth(#col)-%len(coldta)) + coldta;

%subst() is a BIF that lets you take PART OF a string. When I do

that,

I can control the length of the data I use in the expression.

So I was *not* assuming that he knew the size of the field at compile
time. Incredibly, I was able to glean that the size wasn't known from
the other 500 times it was stated in this thread.

It is also why the values aren't known at compile time for using some

of the

other techniques proposed.

Yes, I get that. I would not have proposed those techniques. Unlike
certain others, I KNOW that *ZEROS can't be used as the first parm of
%SUBST(), and I KNOW that you can't use a variable for the

length/decpos

of %DEC(). It's not rocket science after all. %DEC() controls the

size

of an intermediate result. Think about it...

Surely you understand that an intermediate result is -- basically -- a
variable generated and used by the compiler. (Under the covers.) in
order to change it's length/decpos, the compiler would -- essentially

--

have to *recompile* the program. Think about it.

What I don't get here is why it is desirable to standardize the

columns into

what in essence is fixed width sizes with leading or trailing zeros,

up to

the maximum length of any data in that "column".

Yes, that was MY question as well. I can fully understand the idea of
loading a variable amount of data -- and I *did* take it into account
when I wrote my code, as I've hopefully clarified above.

What I don't understand is why you'd want to fill the silly thing with
zeros. What good does that do anyone?

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.


This message, including its attachments, constitutes an electronic communication within the meaning of the Electronic Communications Privacy Act, 18 U.S.C. Section 2510. This message is the confidential property of RockTenn, and disclosure is strictly limited to recipients intended by the sender. Unless previously authorized in writing, this message does not constitute an offer, acceptance, or agreement of any kind. This message may contain confidential attorney-client privileged information and attorney work product. If you are not the intended recipient, or responsible for delivering e-mail to the intended recipient, you are advised that use, dissemination, forwarding, printing, or copying of this message is STRICTLY PROHIBITED. If you receive this message in error, please notify the sender immediately by return e-mail and delete the message entirely from your system. Sender is not liable for damage caused by viruses transmitted with this message, or errors or omissions in content caused by transmission.
(c) RockTenn, Norcross, GA.