Enhanced iProject

Now that we have completely free format starting in column 1 with unlimited columns, the next step is for the tools to support source in the IFS. I would like an enhanced iProject that resides in the IFS, and does not necessarily tie back to source physical files. I want to be able to segregate portions of my application by folder, and name programs with long file names.

The only exception to this would be device files. These could still be stored in a folder that is tied back to a specific source physical file, but that would have to be a property of the folder in the project. In the project metadata, you could tie a folder to either a library and source physical file, or to an IFS directory. The IFS directory could exist in both cases. But, if the project folder was a "surrogate" for a source physical file, the folder in the IFS would just contain metadata.

The ultimate goal of this would be to get to a point where we could use a tool like GIT to manage our source. The hybrid source physical file folder would not really work directly, but either a work around could be developed, or something to replace the DDS for device files. In fact, device files are the only thing left to address outside the RDi tooling since the database can be developed using SQL DDL, which can be run directly from the IFS using RUNSQLSTM.

Create and enhanced iProject in the IFS.

app
|-> customer
| |-> Protorypes.rpgle
| |-> ListCustomers.rpgle
| |-> ChangeCustomer.rpgle
| |-> AddCustomer.rpgle
| |-> DeleteCustomer.rpgle
| |-> customer_service_program
| | |-> Prototypes.rpgle
| | |-> GetCustomerName.sqlrpgle
| | |-> GetCustomerAddress.sqlrpgle
| | |-> IsValidCustomer.sqlrpgle

You get the point, would still have to provide a way to bind service programs, maybe an XML tool to describe the modules to be bound together, and which procedures to be exposed in the binding source. Program and module object names can be defined in the H specs of the respective source files. Each folder should have a bit of metadata to indicate where to generate objects, this would make binding service programs easier. Or a specific make tool like ant, or extensions to ant could be developed to make the build easier.