RE: SAVOBJ to previous release

Buck,

We already distribute an application (FaxServer/401) down to 
V2R3 that is being developed on a V3R7 machine.  When you 
compile the program, it must specify the target release.  Eg: 
TGTRLS(V2R3M0).

Then on the SAVxxx command, you should also specify the TGTRLS 
parm.

We have changed the command defaults for all of the CRTxxx 
commands to default this way.  For most things, nobody even 
notices this.  When something does blow up because of the prior 
release compile, the message usually says so.  This causes the 
programer to stop and say "Do I really need this?" and find a 
more compatible way.  If nothing else, it alerts you to 
potential problems prior to your stuff getting to the customer.

For those very few things that MUST be done to V3R1 (or 
whatever), we have to decide.  Do we disable the function for 
lower releases and handle it in the install process?  Or do we 
raise the bar and say the customers must be at a new release 
level.  This is one of those decisions that generally causes a 
fight between Marketing & Development, but it must happen.

And FYI, we are getting ready to raise the bar on FaxServer/401 
to V3R1.  This is not a decision to be made lightly.  You have 
to ask yourself questions like "How many customers will I lose 
because of new OS required?  How many will I gain because of the 
new function?  Can I even generate stuff to the old release?".

Regards,
Bob Crothers
Cornerstone Communications


-----Original Message-----
From:   Buck Calabro [SMTP:mcalabro@commsoft.net]
Sent:   Tuesday, December 09, 1997 9:27 AM
To:     MIDRANGE-L@midrange.com
Subject:        Re: SAVOBJ to previous release

>> Sending the source is not a good option for us.  We're 
looking to package
>> an entire library for the end-user to RSTOBJ to their system: 
load 'n go.
>> If they have to compile all the CL source, that'd be a bit 
messy.
>
>> We *could* compile to the earliest release we support, but 
the
>> developers won't be happy having to override all their CL 
compiles
>> for the sake of the few that don't SAVOBJ properly.
>
>Have you considered building a 'make' CL program and compiling 
that for a
>very early release? The program could then do all the object 
restoration,
>constructing libraries, compiling of the source members 
restored, etc. The
>customer spends a few CPU cycles, but ends up with a package 
built for their
>particular installation.

We have considered that; even started a prototype.  One problem 
is that
we do not want to ship source to the target machine. 
 Proprietary reasons
aside, the sheer bulk of the source makes this unappealing.  The 
source for
this application is about 872,235,008 bytes.  Restoring all that 
source,
re-compiling it and then deleting it can be a significant chore, 
especially
since OS/400 can handle it via RSTOBJ...

Buck Calabro
Commsoft

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to 
"MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to 
MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: 
david@midrange.com
+---

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---