Re: The Day the Music Dies (was: RE: backup spool file)

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.