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

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

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by 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].