RE: Source now allowed in the IFS -- MIDRANGE-L

My thoughts are:  EXACTLY...!  That's why I have included the post in it's
entirety, on purpose.

(The size of the diskspace source takes up is a FASCINATING discussion, but
a red herring imho.  If the hardware compression feature card is installed,
it's less than a moot point.)


I would even go even further, and would hope that IBM would (instead of
trying to mangle OS/400 to look Windoze or *nix-like) extend the features
that are built into CPF over TO the IFS even MORE...  For example, object
usage info (and PGM object info, as recently mentioned).  Then it might be
even more worth the resources to consider leveraging that, by added
additional object info on usage frequency, etc.


To REALLY go further out there, I would think that IBM might consider trying
to sell more disks...!!!

I don't know, of course, but would take a wild-hair guess that it wouldn't
be exceedingly difficult to leverage the technology of disk mirroring (at
software AND hardware level), to allow mirroring of file/member objects
between IFS and Native file system...  Not just source.

Wonder why couldn't this be done?  Cycles are becoming cheap, and level of
mirroring could possibly be at object/library/and/or/system-wide.

Could even develop hooks into OS and a Public Interface that existing ISVs
could tap into to replicate to other formats besides text (perhaps like
Excel, SQL Server, or Oracle??)...  Formats that change too often to put
into firmware could then benefit.

Anyhoo...  I see the benefits.



| -----Original Message-----
| [mailto:midrange-l-admin@midrange.com]On Behalf Of Mark Waterbury
| Sent: Wednesday, October 16, 2002 8:33 AM
|
| Hello, all:
|
| I think what is missing from this thread is the fact that, if you store
| your source exclusively in the IFS, and then compile the objects
| directly from there, you lose the "link" between the object and the
| source, because there is no way to store the long IFS path name
| in the limited space provided in the OIR for the source file, library
| and member name, plus the date/time stamp, within *MODULEs
| and *PGMs.
|
| Now, consider this carefully. Most, if not all change management
| vendor products must try to "match" compiled objects with their
| corresponding sources, when you are first placing everything under
| control of your CMS.
|
| Without this feature, of which System/38 CPF and OS/400 were
| the first, and perhaps only operating system ever to provide this
| capability "built-in", there is NO WAY that any vendor tool can
| now "guarantee" the integrity of your objects and source code,
| because there is effectively no way to ensure that you have in fact
| "archived" the correct source for any given object.
|
| So, this means that it is even more important to use a change
| management and version control tool, but it will be even more
| difficult to ensure that it has been properly implemented initially,
| IMHO.
|
| Thoughts, anyone? (Someone from IBM, please correct me if
| I am mistaken...)