ISeries System Debug Manager

205 pts.
Tags:
AS/400 debugging
IBM iSeries
RPG
RPG debugging
RPG ILE
I have recently started using the ISeries System Debug Manager (I know, finally making the move to RPGLE). I have having trouble setting up the library list for it. We do not use the SYSVAL library lists normally for our users. We have a menu system that controls the users library list outside of the SYSVAL or User Profile. Does anyone have a suggestion on a good way to give the debugger the library list I need it to have?

Answer Wiki

Thanks. We'll let you know when a new response is added.

I’m not quite sure which debugger the iSeries System Debug Manager is – is it the one through the emulation screens (STRDBG command), or the WDSC debugger, RDi, or something completely different?

Your menu system is probably storing the library list in a file or data area, and reading it when a user goes into the menu system in order to set their session with that library list.

So you should be able to trace down the location where it stores that library list. You could read that file or data area in a CL program and then change the library list accordingly. Depending on how the library names are stored, whether they’re in separate records or one long field, you may need to build a string of all those names and then use that for the LIBL keyword of the CHGLIBL command. I recommend creating a command for that CL program, so that you could then just run the command to set your library list. The advantage of that is that if your library list ever has to be adjusted, you wouldn’t have to change your CL program, since it would get the library list from the same location as your menu system.

You would then just run your new command before starting your program(s) you wish to debug, or have your debugging tool run that command automatically when you start a debug session.

CWC
——————-

Discuss This Question: 12  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Willhud69
    The System I Debug Manager is a Java GUI interface for STRDBG that comes with the Iseries starting I think in V5R1 (Like I said, I just started using it). WE don't have all the pieces installed to use WDSC or RSE and the Green Screen STRDBG seems very limiting, so I was trying this. I thought of the CL idea after I posted my thing, and was actually trying that now. I created a CL where I just use ADDLIBLE to add all the libraries I need Then I call the RPGLE program I am trying to test. Then in theory, I should call the CL program with the GUI Debugger, add the ILE program to the debugger, and be fine. I however get an error about having to have OPMSRC(*YES) on OPM programs, and I am not sure where to specify that when calling the CL.
    205 pointsBadges:
    report
  • Teandy
    This is from the help under the Start Debug window. "Initialization command (Optional): Type a single OS/400 control language command that you want to run before calling the program you want to debug. For example, you can use this command to set environment variables, library lists, and so on." So, according to this, you should be able to use the CHGLIBL command to set the *LIBL. I have not worked with this software very much, but from what I’ve seen, it seems far more limited than using STRDBG on an RPGLE or CLLE program. If you are trying to debug an OPM program, I would suggest you copy the program source to another name and run that source through the CVTRPGSRC command and then compile it. Then you can use the STRDBG command and get pretty much the same screens as you get with STRISDB. I would also suggest that when you compile the program, you set DBGVIEW to either *all or *list. This will increase the size of your object, but if someone deletes the source, you can still see it in debug.
    5,860 pointsBadges:
    report
  • LBurkett99
    You can create an OPM program with OPTION(*SRCDBG), then use the OPMSRC(*YES) parameter in the STRDBG command. There are two library lists; QSYSLIBL and QUSRLIBL are the system value names. The system library list can only be changed by the CHGSYSVAL command, and its default value is something like QSYS and QGPL. If you want every user to always have access to one or more user libraries, add them to QSYSLIBL.
    830 pointsBadges:
    report
  • Willhud69
    Thanks everyone, its very refreshing having help. I got past the OPMSRC(*YES) problem by reading about what to change when I compile the CL. But when it called the RPGLE program, it blew up with an error on the screen. Cause . . . . . : RPG procedure WPR519 in program WILL/WPR519 received the message CPF4380 while performing an implicit OPEN operation on file WPR519D. The actual file is WPR519D. Recovery . . . : Check the job log for a complete description of message CPF4380, and contact the person responsible for program maintenance. If the file has a device type of SPECIAL, there may be no message in the job log. I have not had a chance to look at that yet. I would have expected it to display the screen from the RPGLE program. I do need to make sure the library list isn't getting the DDS object from the production library instead of the test library. Just haven't had a chance yet. I don't like the STRDBG program because you can't watch variables as you go through the code as you can with the STRISDB debugger. You have to page up and down and all through the code to place your cursor on the variable and hit F11 or you have to type in a string on the command line to see the variable. If there is a way to just watch the variables like with STRISDB I would be a happy camper, but there either isn't a way, or I haven't found it. I don't understand why you have an amazing feature like that in STRISDB and they go and create STRDBG and leave that off???? That just doesn't make any sense to me. The thing about the GUI, is you can see whatever variables you want changing as you step through the code like you could with STRISDB As far as using the system values for the library lists, it would take me forever to see what all that would effect, since each users is controlled by their sign on and certain batch jobs just add them within the CL. It probably shouldn't be that way, but lots of stuff in the IT world you inherit and it works, so you don't mess with it too much if you can help it <grin>
    205 pointsBadges:
    report
  • Willhud69
    here is the description of the error from the job log. I can only guess, that maybe you can't use the Java GUI to debug screen files? WPR519D is a DSPF object with multiple record formats. 3 screens and a couple of subfiles within it. Statement . . . . . . . . . : 1000001 Message . . . . : Open attributes not valid in a multithreaded job. Cause . . . . . : The open of file WPR519D in library WILL device *N failed because this job is multithreaded and one of the following attributes has been specified. - The file being opened is a type of file which is not supported in multithreaded jobs. - SPOOL(*NO) was specified on an Override with Printer File (OVRPRTF) command, in the program, or on the file. - A save file was opened when more than one thread exists. Recovery . . . : Correct the attributes which caused the failure and try the request again. Technical description . . . . . . . . : In a multithreaded job only database files, printer files, save files and Distributed Data Management (DDM) files of type *IP may be opened. Printer files must be opened SPOOL(*YES). Save files must be opened when only one thread exists. I had just read several articles about how much better the GUI version was then just using the STRDBG, but it is either only good for batch processes, or I am still doing something wrong. Which leads me back to just using STRDBG and having to either keep track of the variables in my head, or writing them all down each time they change /headdesk/.
    205 pointsBadges:
    report
  • Teandy
    In this case, the error means that you are trying to open an interactive screen in a batch process. If you want the use the GUI, you need to start the program on the i5 THEN lauch the GUI and select "Debug existing job on system".
    5,860 pointsBadges:
    report
  • Willhud69
    Thanks, I definately never would have thought about starting the program first in a 5250 session. I will try that this weekend. I really appreciate all the help.
    205 pointsBadges:
    report
  • Yorkshireman
    If you want to watch variables in the program you can use the 'Watch' command. It's not like ISDB where the screen is taken over with watch items. F18 is used to see the list of stuff you're watcjing. The program will break when a change to the watched variable happens. You should therefoer explore the syntax for conditional breakpoints, something like Break at 12345 when ABCDEF = 12345 this allows, say, a batch process to execute up to a given record, then breaks, and you can step / set more break points. The potential for ILE to use multiple modules and become multi threaded means that the debug environment is perforce more complex. For debug purposes, you could consider compiling as single threaded, and make a command ( or something) which allows you to call the function from the command line and cary out interactive debug (not always possible I know, but well worth it if you can do so. Finally, of course - design for failure, and have plenty of joblog messages and output of values / program structured to decision points etc etc , blah blah.. I used to be able to throw a pgm in ISDB, and now I have to think about the debug process - so ideally it needs to be designed in.
    5,580 pointsBadges:
    report
  • Willhud69
    I tried th F18 option in STRDBG, but this is what I get. System: Type options, press enter. 4=Clear 5=Display Opt Num Variable Address Length 1 CSEFDT E6E058929A085A5C 4 Putting a 5 beside one of them variables Display Watch Watch Number . . . : 1 Address . . . . . : E6E058929A085A5C Length . . . . . . : 4 Number of Hits . . : 0 Scope when watch was set: Program/Library/Type: WPR519 WILL *PGM Module . : WPR519 Procedure: WPR519 Variable : CSEFDT I don't see the value anyplace?
    205 pointsBadges:
    report
  • Cwc
    You need to use F17 to set a watch of a particular variable (place the cursor on the variable and press F17), or just type Watch at the bottom, followed by the name of the variable. That will monitor its memory location, and when the storage changes, the program will pause. You can then use F11 to display the variable being watched (or any of the other ones), or enter EVAL followed by the name of the variable to see its value. F18 lets you see all the active watches and work with them accordingly.
    4,290 pointsBadges:
    report
  • Willhud69
    The EVAL command will help some. It's a heck of a lot of typing just to see what is in each variable, but it might beat paging up and down through 100 screens to find the variable I am looking for to see what it's value is. If I was still young and didn't have the beginings for old timers, I would just keep them all in my head. My short term memory just isn't what it used to be 20 years ago though. Perhaps the programming we do is just way to simple for what they had in mind for this debug tool. Never in a million years would I care what the memory address of the variable is. That's supposed to be the beauty of RPG and the AS/400. I write simple business applications! I am not writing an OS. To me, the F18 screen is totally useless from what I can tell. I simply want to see a list of all the variables I care about and what their current value is when I hit a break point. Has the world of AS/400 programming changed so much, that I am alone in thinking this is? I feel like I am stuck with a couple of very BAD tools (at least for what I need them for), with no way around using them either because that's all there is. STRDBG - Won't show you all your variables on a single screen or window that you want to see the values of, and the stopping each time the variable changes is a pain, especially if your watching 4 or 5 variables from the same physical file and it does a READE. I feel like I am hitting the F11 key 100 times for it to simply step to the next line of code because it hits the file so many times. That pretty much forces me to put a break after each read and hitting F12 instead. The System I Debugger (GUI over STRDBG) will show me a screen with the variables, but again stops on file reads like STRDBG. Setting a break point right after the file read and hitting F12 seems easier, but then I have to make sure I set a break point after each read. I was able to get it to debug the screen by starting the program first, and then starting debug in the GUI. It's a bit cumbersome swapping back and forth between the green screen and the GUI, but it works. RSE/WDSC - Is simply overkill and won't run well on our AS/400 as it is now. Perhaps after our next upgrade I will make sure all the pieces to that are installed and try it. To Yorkshireman - 'The potential for ILE to use multiple modules and become multi threaded means that the debug environment is perforce more complex. For debug purposes, you could consider compiling as single threaded, and make a command ( or something) which allows you to call the function from the command line and cary out interactive debug (not always possible I know, but well worth it if you can do so. ' I really didn't follow this part at all. I confess I don't know much about the whole multiple modules/multi-threaded thing. We write data entery screens, reports, etc. We have a couple web sites that one of the programmers here basically hacked their way through copying and changing examples, but I doubt any of us really understand it. It's just not the kind of programming we do on a normal basis. I like a lot of the things they added in ILE that I have found so far, but feel as if they really dropped the ball with the debug tool. I think I need a quiet moment to shed a tear into a beer for the interactive debugger that served me well for the last 10 - 15 years. I am sure I am not the only AS/400 guy or gal to put off going to ILE for these reasons and others. Unfortunately, Lawson has now forced our hand, so we don't have a choice. Somewhere between 1/3 and 1/2 of all our code had to be changed to ILE to satisfy their new file formats. What's done though is done. I am sure in time of using it, we will get better at it. Right now though, it seems awefully limiting. I do appreciate all the help though you guys and gals have been great in trying to get my backward ways up to speed.
    205 pointsBadges:
    report
  • Cwc
    I never got into STRISDB much, but as far as I know, the STRDBG command pretty much does what STRISDB does, except STRDBG will work on both OPM and ILE programs, where STRISDB works only on OPM. To avoid having to to step through each field on a file operation, you can add the Option(*NoDebugIO) keyword on an H specification in the source. As far as tools go, hasn't IBM provided many more tools? And many people don't even use because they're used to the way they've always done it, with SEU and PDM. I think SEU is a workhorse and still use from time to time, for quick edits. But WDSC/RSE is a much better option overall. It is a client based application so shouldn't need many resources on the AS/400. Here is a good writeup on how to debug with it: http://www.ibmsystemsmag.com/ibmi/enewsletterexclusive/18995p1.aspx . One of the things that's really cool about this is that you can just roll over a variable with the mouse and its value will automatically be displayed. In our world, it's important to keep up with technological advancements, and many of the System i's (the system formerly known as AS/400) biggest advocates have not kept up. In order for the system to continue to be seen as viable in the modern IT world, its application programmers cannot afford to get left behind. To do so enforces the misperception that the i is a "legacy system". It is not -- only the applications that were written years ago are. OPM programming (such as RPG III/400) is obsolete, while ILE has much, much more functionality and power. It will save you a lot of programming time once you start using it, and the learning curve really isn't that steep if you get a good book on it, or if you take a class. The bottom line, in my opinion, is that we are paid to understand and use technology that help our business customers. If we don't keep up with new developments, we are not providing value to our business and risk seeing our favorite system getting shown the door and replaced with a bunch of PC based servers that, although they have their role and many strengths, also don't have the robustness that the System i does. How many of us will be able to adapt to different programming paradigms like object oriented programming and web programming if we don't at least get familiar with the concepts as we go along? If we cannot adapt, we will be gone. This has already been happening.
    4,290 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following