On 11/05/2010, at 7:37 AM, Mark S. Waterbury wrote:
A far bigger issue is, if you place your source in the IFS and use any
of the CRTxxx commands that support it, you lose one of the most
important features of OS/400 or i5/OS, that is, the automatic
"stamping"
of the created object with the source file name, library name, member
name, and date-time stamp of the source member.
That stuff's obviously not important because it's not present on any
other platform. If **THEY** can do without it then so can we. Why
should we have all this extra guff (as one PC dweeb said to me) stored
with an object? It just clutter's up the system and provides no value
whatsoever. Since few people purchase our beloved system just because
it is better than the others why spend development dollars making and
maintaining such differences when that money could be spent making our
system look just like **THEIR** systems. While we're at it why not get
rid of all the object/module/service program junk in a program object.
Who bothers to look at that stuff? Oh, there's so much that could be
cleaned up. Just store everything as stream files. Get rid of command
objects--what value does prompting and help text add to them? Doing
something like this would remove the need to argue why our system is
better, there'd be no need for additional education--it would be just
like everything else--and then the merge of i and p can be complete.
**To those reading this out of context, perhaps years after it was
written, it should be obvious that it is sarcasm (regardless of what
Oscar Wilde says). so don't take it literally.
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists
http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.