Re: QRPLOBJ

It doesn't keep the real program name when it goes into QRPLOBJ, so there is no
way you could have "over-written" one with a duplicate name.  The reason its 
easy
to delete them at IPL, is that you know that no job can exist across an IPL
(therefore it cant be in the call stack).  If your users are signing off at the
end of each day, then you can delete these objects in QRPLOBJ that are over 1 
day
old without any problems (99.8% of the time).

    Pete

watern@cbs.fiserv.com wrote:

> Hi,
>
> I missed the earlier posts on this so hope I am not repeating or missing
> anything.
>
> I can see a situation similar to what you are describing occurring if the
> program being moved into the production environment already exists in
> QRPLOBJ.
>
> This would happen if QRPLOBJ has not been cleared since the program was
> previously moved into production:
>
> 1. Version 1 of pgm is moved to production
> 2. Version 2 of pgm is developed and moved to production
>    - existing version 1 is in use so version 1 is moved to QRPLOBJ and
> replaced with version 2
> 3. Version 3 of pgm is developed and moved to production
>   - existing version 2 is in use so version 2 is moved to QRPLOBJ
>   - but, version 1 already exists in QRPLOBJ so this move fails
>   - therefore version 2 remains in production
>   - therefore version 3 is not moved from staging to production.
>
> In this scenario, looking at the call stack after the move-to-production,
> the production program shows as being in use, but this is not the new
> version.
>
> Have you checked that the job that moved the object to production completed
> normally ?
>
> If the call stack shows the production object is in use, I would do a
> dsppgm on the production object to see if the source details show the
> source for the new version.
>
> The reason that this never happens when compiling programs in use with
> REPLACE(*YES), is that when the compilation process moves a program to
> QRPLOBJ it is also renames it, so it can happen many times over with the
> same program.
>
> If a user process moves a program to QRPLOBJ, it would need to do something
> similar, or make sure that the object doesnt aleady exist in QRPLOBJ.
>
> An advantage of a user process moving objects to QRPLOBJ would be that they
> are removed automatically when they are no longer being used. I think this
> happens at the next IPL.
>
> Rgds,
> Nigel Waters
>
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@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
> +---

--
Pete Massiello
OS Solutions International
Phone: (203)-744-7854  Ext 11.
http://www.os-solutions.com
mailto:pmassiello@os-solutions.com


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@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
+---