ASNA Visual RPG makes a great partner with Microsoft’s ASP.NET to create superb IBM i websites. For the best performance, these apps should always use DataGate connection pooling and you should always take great care to disconnect every active database connection before a page goes out of scope. If you don’t disconnect a database, the IBM i job is orphaned and doesn’t end right away. The connection pooling article previously mentioned covers orphaned jobs in detail.
This article offers a few tips on finding the cause of orphaned IBM i jobs associated with your AVR ASP.NET web app.
Although this article focuses on the IBM i, the concepts all apply to Web sites driven by ASNA DataGate for SQL Server. The biggest difference there is that you don’t have the WRKACTJOB command to see active connections. However, this Stack Overflow article explains what the SQL Server equalivalent is to WRKACTJOB.
How to tell if you have orphaned jobs
It’s sometimes hard to know if you have an issue with orphaned IBM i jobs. If an AVR ASP.NET website is created without much regard for watching for orphaned jobs during development–then in production they just start sneaking up on you. If you’re using DataGate connection pooling correctly, expect one IBM i job for each block of 20-50 users (as reported by WRKACTJOB). Even with 100 users, you shouldn’t see very many IBM i jobs for your ASP.NET web app. If you have less than 100 users and see more than 10 or 15 jobs or so, you should look deeper into the cause of that many jobs. These numbers may vary widely depending on the type of web app you have and how quickly your users move from page to page. Knowing the exact number of jobs to expect isn’t an exact science–it is not just the number of users but also how heavily users are pounding on the keyboard and showing more pages. It might also help to keep track of the number of jobs at different times of the day for a couple of weeks. This may reveal an issue. Orphan jobs are an insidious problem–that only gets worse as time goes by. For example, consider a Web app with five users. Spurious jobs produced with only five users are annnoying, but with this few users there may not be enough orphan jobs to cause any issues. However, as the number of users grows, so grows the chance that more and more orphan jobs are created. There is a scalability tipping point where this issue goes from annoying to “wow-we need to do something about this.”
What causes orphaned jobs?
Orphaned IBM i jobs are caused by failure to disconnect from a DataGate IBM i connection before a page goes out of scope. Generally, the pattern to ensure a web page doesn’t cause an orphan IBM i job is:- Connect to database
- Open files
- Do work
- Close files
- Disconnect from database
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
DclDB DGDB DBName("IBMI") DclDiskFile FileA... DclDiskFile FileB... BegSr Page_Load Access(*Private) Event(*This.Load) DclSrParm sender Tipo(*Object) DclSrParm e Tipo(System.EventArgs) Connect DGDB Open FileA Open FileB If (NOT Page.IsPostBack) // Do NOT Page.IsPostBack work Else // Do Page.IsPostBack work EndIf EndSr BegSr Page_Unload Access(*Private) Event(*This.Unload) DclSrParm sender Tipo(*Object) DclSrParm e Tipo(System.EventArgs) Close *All Disconnect DGDB EndSr |
Using the page-at-a-time test to determine what page is causing orphaned jobs
A good way to determine what page is causing orphaned IBM i jobs is to:- Restart the website to ensure you’re starting the test from a cold website.
- Ensure you are the only user of the web. This test only works with one user using the site. With more than one user, you’ll get spurious test results. Testing the site with only one user is often quite challenging on a production website. It’s best to do this test on a test server, but that isn’t always possible and the next section shows a way to help ensure that there is only one user of the web app during this test–even on a production site.
- Start a green-screen 5250 session and use WRKUSRJOB to watch for website DataGate jobs. (watch for the same username used in the DataGate database name)
- Start using the site. As you are using it, press refresh the WRKUSRJOB display after every page. If you are the only user, there should always be one job displayed. If more than one appears for a page, you’ve located the page where the database leak is.
Ensure only one user using a production application
The previous page-at-a-time test works only when the tester is the only website user during testing. This is a challenging task for a web app deployed to production. Despite your best efforts to get everyone out of the app, there are occasional stragglers that will come along. However, how do you know someone else is using the app? If no one comes along, you can perform the page-at-a-time test on a production site. To ensure the tester is the only user of the website, you can use ASP.NET’s performance counters to display the number of currently active sessions. As long as that number stays at 1, you know the tester is the only website user and the test will be meaningful. If you must do the test on a production server, following these steps to ensure there is only one user of the website. Step 1. On the web server, start the Windows Performance Monitor (Start->Run-Perfmon). Click the “Performance Monitor” entry under the “Monitoring Tools” entry and then click the green plus sign (outlined in red).




Using DataGate’s special database logging
Another way to help determine what page is causing orphaned jobs is to use DataGate’s special database logging. This causes some special entries in the IBM i job. To use this logging facility: Step 1. Start Visual Studio as an administrator (locate Visual Studio in the Windows Start Menu, right click it and click the “Start as administrator”). Use View->DataGate Explorer and right-click the Database Name for which you want to use logging to display the dialog shown below:




1. Copy an IBM i job description (using CRTDUPOBJ)
2. Change that copied job description so that all of its messages are logged (as shown below in the red box)
