Re: Source in the IFS

Like Scott said: the IFS is definitely the way out. I foresee the use of
it for even the common source of all programs. The record-length limit
nature of PF-SRC type of files is also a constraint when you need to build
a literal string that surpasses it.

I keep copies of my sources in my /home/me directory/folder in a rather
manual way even with Notepad++ and a good tool to get access to it as a
folder from my laptop. It's also fun.
i.e. I have like a hierarchy like:

/home/me/myIBMi/myProject/myLib/myRPGLESRC/myMember.rpgle or so.

And it's worth it.

JS

El mié, 29 mar 2023 a las 23:35, Vance Stanley via MIDRANGE-L (<
midrange-l@xxxxxxxxxxxxxxxxxx>) escribió:

Agree. I spent an hour making this function to consume a rest API fit and
be somewhat readable in seu to go into turnover. It went from readable to
looking like a code generator did it.
On Wednesday, March 29, 2023, 10:22:44 PM CDT, Scott Klement <
midrange-l@xxxxxxxxxxxxxxxx> wrote:

Source in the IFS is definitely the way to go in the long run.

There are a small handful of tools that still don't support IFS -- but
it's not hard to work around the problem (just a simple utility that
copies source to a temporary member during compile.)

For /copy books, I recommend having a place that's designated as the
location for any needed copybooks. On the Unix system I work on, they
use /usr/include for copybooks included with the system, and
/usr/local/include for copybooks that are specific to your
installation. If you use those locations (or designate your own) for
your copybooks, it's just one location to be sure you include.

Use relative paths for testing in development/test/qa environments (with
a copy of the copybook)

Then use the RPGINCDIR system wide to set up folders like /usr/include
and /usr/local/include and use paths relative to those for anything
available system-wide (i.e. things that aren't currently "checked out"
by the developer for making changes, etc.)


On 3/29/2023 3:46 PM, Sam_L wrote:

I'm experimenting with putting source in the IFS. Would like sone input.

1) Do you miss the text on the source and the created object?

2) What's the best way to handle /COPY of utilities shared between
projects.

I don't want want to hard code the /COPY file, or use an RPGINCDIR
environment variable, or specify an INCDIR on the CRTxxx command.

Using path name relative to the source file directory seemed best.
For testing I created a directory structure like this:
/HOME
MyName
MySourcE
Copy_Mbrs
incText.rpgle
Proj1
TestInc.rpgle

TestInc looks like this:
**free
/include ../Copy_Mbrs/incText.rpgle
dsply theMsg;
*inlr = *on;
return;

incText looks like this:
**free
dcl-s theMsg char(30) inz('Hello included text');

Which compiles quite nicely. But is this the best way?

This is for my personal projects on PUB400, so no source management
packages.

Any suggestions, comments, discussions welcomed.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.