On Tue, 14 Dec 2004 rob@xxxxxxxxx wrote:

That's called a "variable length field" on the i5.  People don't use them
because they weren't available on the S/38 and they refuse to change.
Some might say the extra 2 byte overhead for a variable length field might
waste $2.73 in disk space and they can't afford that on a measly 6-9 byte
field.

That's only if it is a database field. Are people really writing the VRM into the database? (This is a serious question) What for?


I don't think a database field is necessary. In fact, it seems like a waste. A simple pointer to memory that stores the string would suffice. Or it could be stored in a flat file like /etc/version. Or you could do both like linux does and have a flat file /proc/version which is really just a simple pointer to memory.

Then if you need the version do something like:

VERSION=`cat /etc/version`

where VERSION is a variable that needs no further declaration. Granted CL doesn't have such handy things but that is CL's fault. Or you could (should) add support for pointers to CL (since it is an ILE language) and construct something like:

DCL  VAR(&VERSION) TYPE(*POINTER) VALUE(ptr_version)

In this case ptr_version would be a system API that returns a pointer to the string in memory that contains the VRM.

Neither case requires knowing the length of the string and could support a string of any length. The first case can be achieved today if you use the shell instead of CL.

The fun part would be now adding an offset field to any api data
structures to support changing this field to variable length.

This is the part I'm interested in. What system APIs require passing the VRM?


James Rich wrote:

Why use fixed lengths at all?  Make the VRM be a "string" that can be any
length.  Heck, in linux you can even add your own custom tag to the "VRM"
(i.e. something like 2.6.9-we_did_this) and all the tools handle it just
fine.  Why couldn't the iSeries do something similar?

James Rich

It's not the software that's free; it's you.
        - billyskank on Groklaw

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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

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.