Re: Regarding retrieving source from modules

Hans,

For certain, retrieving source from objects requires "planning ahead" in
the sense that you must be sure to compile objects with DBGVIEW(*LIST).
That's a pretty simple and short plan, though.

I agree with you that proper backup and recovery procedures are
essential for data, source, and program objects, however there are other
considerations that I think are more applicable to the notion of
retrieving source from objects.

The "need" to retrieve the source from objects arises primarily because
the appropriate source is not available. The key phrase here is
"appropriate source is not available". For some scenarios, a simple
restore of the source might be the answer. However, in other scenarios,
backup/recovery really has no bearing.

Consider the need to ensure synchronization between source and object.
Though the argument could be made that better controls would prevent any
sort of synchronization problem, the fact is the problem occurs. And,
given the number of circumstances that can lead up to synchronization
problems, it would be difficult to put in place controls that would
truly ensure there are no problems. As you know, these synchronization
problems can be difficult to track down because of many things:

1) Changes are made to source, but no successful compilation occurs
2) Source member names don't correspond to object names (though object
information can take care of this, sometimes).
3) Source is moved from one location to another
4) CRTBND* commands are creating things, pointing to members in QTEMP
and confusing folks
5) The problems are magnified when multiple candidate source members for
an object exist on the system

I could probably list more, but I think you see the point. My personal
opinion is that there is only one acceptable reason, for all practical
purposes, to not have DBGVIEW(*LIST) on an object. That is when you are
distributing software and don't want it "visible" to the outside world.
And, I'm of the opinion that it might be a good idea to have a change
management system that actually retrieves the source from the object any
time it is being worked on.

Gary Guthrie


 
> >Gary wrote:
> >The September 1997 issue of NEWS/400 has article "Retrieve Source from
> >ILE Modules" which discusses the topic of retrieving ILE source from
> >modules with DBGVIEW(*LIST).
> >
> >You can download the utility from the article by visiting the NEWS/400
> >web site at http://www.news400.com where you select the Resources tab
> >and from there Code, followed by NEWS/400 code.



> boldt@ca.ibm.com wrote: 
> This does nothing for those who don't plan ahead.  This is still
> not a substitute for proper backup and recovery procedures.
> 
> Personally, I find this discussion amusing. You never see anyone
> ask:  "How do I recover my A/R files?"  Most companies certainly
> have backup procedures for their vital data files.  Are your RPG
> source code files not just as vital to your business?
> 
> Cheers!  Hans
> 
> Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com
> 
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator: david@midrange.com
> +---
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---