Re: Need to create a view over a physical file - but I don't want to - but I have to

Thats true, if the file is embedded in other areas in its
current design, it may be more time consuming than appears...
I also have some "parse out" sqls as part of a few applications,
especially if the flat data periodically comes in sized differently,
at least I can simply mod the front end sql each time the data
shifts, and from that point on, my "home grown" dds file remains
constant for the application.

What Ive found is that once I prove I can manipulate the flat
data into real data, then the users tend to find more "uses" for
the data and I end up propagating my parsing code across even
more reports... fine for me, not so good for whoever has to
sub in for me if I am out of the office....LOL..

oh.. 1 last thought.... since you seem to be dealing with
"conditional" actions based on data values.. true field definitions
would lend themselves more readily to "case" stmt processing.

Good Luck with your parsing approach.
Aaron.

Alan Shore <AlanShore@xxxxxxxx> 5/7/2010 2:03 PM >>>

Thanks for your reply Aaron
At the moment I am using the article to "parse" out the data so that I can
build a view - mainly because now that I have this knowledge from the
article I am somewhat transfixed by this project and the file itself.
However, I do agree that the data held in this file DEFINITELY should be
redesigned. What I am doing should help me understand the scope of the
data.
What DOES bother me is that I may find something that is going to make me
start crying UNCLE
Knowing where this file is used, I also believe that it is going to take me
a LOT more than a couple of days in its redesign and implementation into
where it is presently used


Alan Shore
Programmer/Analyst, Direct Response
E:AShore@xxxxxxxx
P:(631) 200-5019
C:(631) 880-8640
"If you're going through Hell, keep going" - Winston Churchill


midrange-l-bounces@xxxxxxxxxxxx wrote on 05/07/2010 02:41:36 PM:

Consider the future use of the data,
do you want to be locked into decimal subtr options
for the life of this data...
If you may need to access this data easily from
crystal, excel, iseries nav, or other reporting services...
I VOTE for redesign in this case.. A couple of days
rebuilding a database could save you days and headaches
down the road...
can't say much on the RPG solution, been too many years now,
but I do use the sql substr/decimal options a lot for data imported
from outside organizations, and it does work just fine.
ALA

Alan Shore <AlanShore@xxxxxxxx> 5/7/2010 12:02 PM >>>

Sorry about the subject description - but I couldn't think of what to put
in there that would convey the predicament that I face

I need to create a view over a physical that contains the following

fields

(believe me - NOT my design)

NameTypeLength
FIELD01 A 63
FIELD02 A 63
FIELD03 A 63
FIELD04 A 63
FIELD05 A 63

Now - within the programs, each of these fields are moved to a separate
datastructure that is defined like this

D FIELDNBR DS OCCURS(5)
D CFREE 1 63
D LLMT 1 3P 2
D LLMTX 1 3
D WFR 4 63
D DIM(5)
D QTY1 4 5P 0
D ITM#1 6 15
D CPNAMT 16 20 2
D PCTAMT 16 17 0
D QTY2 16 17P 0
D ITM#2 18 27
D QTY3 28 29P 0
D ITM#3 30 39
D QTY4 40 41P 0
D ITM#4 42 51
D QTY5 52 53P 0
D ITM#5 54 63
D TYPE 63 63

If TYPE is a 'C' then CPNAMT is the field to use
If TYPE is a 'P' then PCTAMT is the field to use

I also need to figure out how, when and where QTY2 is used
I also need to analyze if there is anything else

At the moment all I am doing is staring at my screen, thinking whether or
not to re-design this whole file to be more meaningful, BUT what is
required is a view
As always any and all responses GRATEFULLY accepted

Thanks in advance



Alan Shore
Programmer/Analyst, Direct Response
E:AShore@xxxxxxxx
P:(631) 200-5019
C:(631) 880-8640
"If you're going through Hell, keep going" - Winston Churchill
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.






The information contained in this message may be privileged and
confidential and protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient,
you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately
by replying to the message and deleting it from your computer. Under
Florida law, e-mail addresses are public records. If you do not want
your e-mail address released in response to a public-records
request, do not send electronic mail to this entity. Instead,
contact this office by phone or in writing.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.