Steve Richter wrote:
On 3/13/08, Joe Pluta wrote:
<<SNIP>> Oh please, not the 10-character object thing again. Get
over it. There isn't a single business issue that can't be solved
by a 10-character object name. Yes, it's a limit, but I really
don't want IBM "fixing" it anytime soon. If you want long names,
use the IFS and stay the heck out of the QSYS library system.
Recently I had to lock various message queues in a way that did not
interfere with the operation of the message queue. I used data areas
for this purpose. What name to assign to these DTAARAs? Ideally, the
name would have been the name of the message queue with the word
"lock" concatenated to the end. Could not do that because of the 10
char name limit. This sort of scenario comes up quite frequently,
where you want the object name to be a readable extension of a core
object.
The _ideal_ solution is to create another object TheLib/ObjName.lock
to correlate directly to the existing object TheLib/ObjName *?*
Seems to me that such an /ideal/ solution was derived from a
creativity void. Or at least that the information given was a trifle,
from which no reason could logically be inferred for having been so
limiting, of probably more than hundreds of reasonable creative
solutions. Presented in detail as its own topic, I am sure many people
would be willing to offer some varied views unencumbered by tendency or
predisposition.
Another example is the job scheduler. long readable names would be
great there. All the billing end of day jobs could have meaningful
names that describe not only what the job does, but how it
relates to other jobs running on the system.
A /text field/ or a /documentation field/ designed for that purpose
would not be more appropriate... Why? IMO trying to use names to
generally document is fatuous. Descriptive names are good, but using
names to replace appropriate methods of documenting is not good.
ADDJOBENTRY NAME('Run end of every [week]day to produce billing
information. This job depends on ...')
- or -
ADDJOBENTRY NAME(EODBILLING) LONGDESC(*URL)
URL('file://d.s.d.n/docs/jobentry/EODBilling.txt')
I don't see why long object names would have to break any existing
apps. do what windows95 did. have two names for an object. a short,
legacy name, and a long readable one. When a long name is given, the
system automatically assigns a unique short name.
Functionally impact? Probably not, for command-based or API access
anyhow. Any feature using short names could continue to do so, given a
good implementation. But what features *must* be able to assign and to
display the long name? At a minimum the messaging. Would assigning the
longer name have to be part of a create, or can that action be limited
only to a rename feature?
As I see it, the real issue is the usability and ubiquitousness of
the capability. If CRTDTAARA gets long name support externalized in all
*DTAARA commands but not in RPG data area support, is that acceptable?
And if WRKDTAARA panel continues to support only the short name? Which
panels and what APIs would be absolutely required to enable? Given a
partially complete solution because some functions would surely remain
unchanged, will that make the issue with short names even more
frustrating; like trying to work in DOS? If most would be satisfied
with an increase to only 20-byte names, is that sufficient? If the
limit were 100-byte names, how many would then complain they need 128,
256, or ??? Would default folding to upper be acceptable, or would that
also have to change to be acceptable; keep the quoted name style? What
impacts to support for which recovery dollars are required, and in what
manner to collect? I am not trying to defend doing nothing, but IMO the
most appropriate way to get there is to make a new operating system much
like in the S/36&S/38->AS/400 transition where exists a completely new
UI and ability to fully convert into entirely different functionally
[but more] capable features and completely dropping some features [like
S/xx environments, old languages, old utilities, etc.]
I do not see making longer names available in /QSYS.LIB effecting
more sales of i5/OS, and without i5/OS moving from niche to mainstream,
I do not see the resources to make longer names happen in /QSYS.LIB, so
I think it is the proverbial catch-22.
Of course, after that, be sure to also read my signature line.
Regards, Chuck
midrange.com
