Re: Cycleing - Multiple Input Files

If you have files conditioned by a switch, you still have to use different file names in the program ... I use different logicals, the RENAME function so throughout the program file access unique to which file name, and I don't remember technical name for it, but I substitute input field names to avoid ALIAS (same field name different places in program that really should be kept separate). After the data comes input, we can use MOVE to field name to be used in the calculations, like COBOL mentality.

You can cut down on maintenance headaches with
/COPY same code from a library of same code chunks.
Give some thought to good naming, ability to navigate "What name did I give the program chunk to do X?" and "where-used ... if I muck with this logic, that is copied into this program, what other programs are also using it?"

The most popular program, where I work, is "the schedule."
This is a green bar report that looks like an Excel except not all columns in registration.
It lists customer end item orders with buckets what due this week, next, etc. months out.

It could be potentially a programming maintenance nightmare because there are like 50 versions ...
page break on customer vs. continuous
only list this or that facility vs. combined facilities
only list parts that have a particular item class, such as samples, go through particular processes
only list customers that are managed by certain people, so they see their stuff & not all data
instead of quantities, multiply each quantity by price = dollarized version
instead of price, go after costing = profit picture
same logic as dollarized, except multiplier is unit time to make = capacity load drain
same except multiplier is # cartons, skids, so shipping knows in advance how much trucker space to reserve
combinations

So on top of having 50 different versions,
there is a constant parade of enhancement needs to go into those 50 different versions

there are subroutines essentially same in all versions
they can be invoked via /COPY
so when they need to be enhanced, to add a new condition
change one place
recompile one version & test with the new condition
if working fine, recompile other 50 versions
maybe have one CL "recompile all schedule programs"

I call this SOA.

Ideally the only stuff in a program other than /COPY
is that which needs to be unique to that program.

I have two RPG IV programs that are, for the most part, identical. While there are a few additional bits of logic in the second one, the primary difference is that the primary input file has a different record length.

What I would like to do is use the EXTIND(*INUx) keyword to condition the two files; one as IPE the other as ISE. The CL that drives this would set the appropriate switch. What I am not sure about is whether or not this is permissible; can't recall ever doing this in even RPG II, and the manual didn't answer the question. I can simply make the changes and see what happens, but I thought if anyone knew that this won't fly it was save me some time.

Changing the files to IF and USROPN, while perhaps possible, would not be the best option if the former idea would work.

I really would like to merge these into a single program to cut down on the maintenance headaches.

Thanks.

Jerry C. Adams
IBM System i Programmer/Analyst
B&W Wholesale
office: 615-995-7024
email: jerry@xxxxxxxxxxxxxxx

--
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.