Rocket DevOps (formerly Aldon)

 View Only
  • 1.  DBGVIEW(*SOURCE) on 15 options

    Posted 08-19-2022 08:44
    I am mostly certain that I used option 15 to set my programs to allow debug. I have verified this in *DEV and ITG. Now the program in QUA is not showing the debug source.  What am I missing? Yes, I can recompile for QUA into a temporary object, but I guess this means I would not be able to debug on the PROD system if that came about.   

    Is there a better solution to know I will always have the debug option?

    David Taylor
    Senior Developer
    Range Resources Corporation
    Fort Worth TX US

  • 2.  RE: DBGVIEW(*SOURCE) on 15 options
    Best Answer

    Posted 08-19-2022 09:26
    Hi David,

    Thank you for your enquiry.

    As you correctly identified, you should not have to recompile an object at a Target destination to get the Debug view.

    The Debug view option to use would depend on whether the source is deployed. Some policies would not allow the source to be deployed to QUA or Production.

    1. Change the create option to DBGVIEW(*SOURCE) and deploy the source
    2. Change the create option to DBGVIEW(*LIST) or DBGVIEW(*ALL) if deployment of source is not allowed.

    Additional information for other watchers:
    The "Create options" could be applied at any of the below levels:

    STRLMI > 11. Setup menu > 5. Edit defaults for object creation

    Application, (Overrides Global)
    STRLMI > 12. Work with applications > 2=Change > 6. Edit defaults for object creation

    Release (Overrides Application)
    STRLMI > 13. Work with releases > 2=Change > 6. Edit defaults for object creation

    Object level. (Overrides Release)
    STRLMI > 1. Work with objects by release (or WWOD or similar) > 15=Change create options

    Best regards

    Jay Mikaiel
    Senior Technical Support Engineer
    Rocket Software

  • 3.  RE: DBGVIEW(*SOURCE) on 15 options

    Posted 08-23-2022 11:55
    I have successfully used LMi to deploy (using my home-grown deployment tools, not LMi Deploy) program objects with visibility enabled.  That is, after using option 15 in DVP to set the visibility option, I have promoted them through QUA to PDN, and then when the compiled program objects are installed at a client site, I am able to use, for example, green screen STRDBG to view program source while the program is being executed at a client site.

    When the STRDBG display first shows the source lines for an SQLRPGLE program, I see a warning message on line 24 that says the QRPGLESRC file is not found (on the client's machine).  However, I am seeing some form of the source lines of the program in the debug view at the client site.

    My understanding about program visibility is that when a program is complied with one of the DBGVIEW options, some representational source code is carried along with the program object.  Otherwise, how would any source view of the program be available at my client site where they do not have the original source file?  This same principle applies when using DBGVIEW(*LIST), in that the debug view is the report output from the original program compile operation.

    So, the solutions proposed by Jay Mikaiel do not seem to take this characteristic into account, that is, if I'm understanding his reply correctly.  I'm suggesting that, unless some more elaborate view of source code is required, that must be based on the existence of the original source file and source member, it is not necessary to deploy source code separately.

    I have always felt that the complexity of managing the debug view for RPG programs that include embedded SQL makes debugging program problems difficult (in the past?).  But I'm not discussing options for managing the debug views for this type of program in my reply to this thread.  I just wanted to clarify that according to my experience, it may not be necessary to deploy actual source files with source members in order to achieve a helpful form of program debug view at a client's site.


    I believe that Jay has not answered one of the implied questions from David, which is:  How would the debug view of a program be lost as the program object is promoted to QUA and /or to PDN?

    Perhaps we need some details about settings within LMi administration that would override the program-level compile options which can only be changed while a program is checked out to DVP.  I don't know where compile options would be changed in the case where LMi is instructed to recompile programs as they are promoted from one level to the next, specifically, promoted to QUA and/or to PDN.  (I have probably been ignoring some LMi admin options all these years, since I started using ACMS in the 1990s.)

    I have never had a problem promoting program objects through QUA to PDN, and then delivering those program objects with visibility retained as they are deployed to client sites.  So I'm sorry I can't offer advice on this aspect of the discussion, and I would ask Jay for further clarification.

    George Loose
    Technical Product Manager - IBM i
    SMA Technologies
    Houston TX US