|
James, Some people may be writing the VRM to a database field. Let's say you have multiple iSeries. And you have to distribute objects to them. It might be helpful to know the target release. Therefore you might be storing the VRM in the file that lists your remote systems. I like the potential of storing the vrm in some standard place. Often this lists gets a request like that. And the replies vary like "Do a DSPPTF and look at that." or "Do a RTVOBJD on some known IBM object and use that." I've given up waiting on enhancements to CL (although V5R3 looks pretty nice). I've gotten to the point of doing most of that via a HLL like RPG. There's nothing I HAVE to use CL for. Granted, I may still do a backup program in CL. There are numerous api's that return the VRM. For example QUSLOBJ which is the api version of DSPOBJD. (However it already uses VxxRxxMxx). It is often necessary to know which version of the OS an object was created under. One example that bit us was our QBATCH *SBSD was created under V02R03M00. Now, IBM does not convert any subsystem to the new format when it is that old. We had to delete and recreate it. Rob Berendt -- Group Dekko Services, LLC Dept 01.073 PO Box 2000 Dock 108 6928N 400E Kendallville, IN 46755 http://www.dekko.com James Rich <james@xxxxxxxxxxx> Sent by: midrange-l-bounces@xxxxxxxxxxxx 12/14/2004 04:35 PM Please respond to Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx> To Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx> cc Subject Re: The Day the Music Dies (was: RE: backup spool file) 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 -- This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
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.