Re[2]: SAVOBJ to previous release

>I am pretty sure that once an object is on V4r1 it should be able to be
>saved once again for release V3r7 , though What cannot be done is going
>from Release V4r1 back to V3r2. 

Actually, SAVOBJ TGTRLS(V3R2M0) works great for database objects.
Program objects are a bit tricky, especially if you have to cross from
RISC to CISC.

Certain CL programs will not save to V3R2 even if you don't have any 
V4 function in them.  The very same source will compile and execute 
properly at V4 and V3R2. You just can't ship the object from V4R1 to V3R2.

Here's an example:
PGM                
                   
DCL &USER *CHAR 10 
RTVJOBA USER(&USER)
                   
ENDPGM             

Now, this code will compile and run on a System/38 at version 1.  There's
no V4 code here, yet you can't compile it TGTRLS(*CURRENT) and then
SAVOBJ TGTRLS(V3R2M0).  You can compile it TGTRLS(V3R2M0) just fine.
In fact, after reading the Fine Manual, I see that IBM has indeed documented the
need to compile all your programs destined for an earlier release specifically
as TGTRLS(VxRyMz).  My most humble apologies for pestering the list.
Our situation was made a bit more complex by having code from multiple
releases in the same library, i.e.

PGM1 *CLP V3R1
PGM2 *CLP V4R1
PGM3 *CLP V3R0M5

All 3 programs have vanilla code, but when I SAVOBJ TGTRLS(V3R2M0), 
PGM2 gives me an error, telling me that I have run-time code that can't
be saved to V3R2.  That was getting on the developer's nerves, since
they could not see any difference between the source code.  I can see 
that we need to do a bit of educating...  Sigh.

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
+---