Re: uses for long object names

Steve Richter wrote:

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 extenstion of a core object.

There is a difference between machine-readable and human readable. If you need a human-readable name, use a cross-reference file, or use the description. That's why they have 50-character text fields on objects.

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 what the job does, but how it relates to other
jobs running on the system.

I personally don't want my names in databases and other things to take up tons of space to be "meaningful". Typically, you end up with things like "myfile1" and "myfile2" anyway, unless you have the uber-dweeb who assigns the name "corporate-level-design-specifications-for-current-year-oversight". I find that forcing short names forces people to have reasonable naming conventions.

I dont 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.

The fact that you don't understand what it would break makes it clear that you don't understand just how deeply ingrained the length is everywhere. Every command, every language, every screen would have to change.

I would rather they spent time on other things. Unfortunately, I'm pretty sure they're going to bend to the clamor on this one and we'll probably see long names within a couple of releases.

Joe