I have a client that has many old apps running in the S/36 Execution Environment. I had converted one of the inquiry programs into an ILE RPG program, keeping the program-described workstation definition, so that I could easily call this program from other programs. After some time, it was decided that we needed to display some information in a subfile-like format from this program. Not wanting to go through all the hassle of defining all the input and output specifications, I tried something, and to my surprise, it worked.

I created a second workstation file containing just the subfile record

I had struggled with using the debugger in WDSc for a long time when I asked a friend that I knew to be an expert on the subject to help me understand how to use it. She told me that I only needed to know three little words–Service Entry Points–to make my debugging life easier. She was right!

If you have not yet learned the joys of debugging with Service Entry Points, try it today. In the Remote Systems view (RSE), choose a program object. Right click on the object and select Debug (Service Entry) –> Set Service Entry Point.

Last week, I demonstrated how to create new i5/OS job queues for increased subsystem throughput, segmented workloads, and to run jobs in sequence. But the best subsystem architecture won’t provide any benefits if no one uses it. So in this column, I’ll show you how to configure user profiles, scheduled job entries, and batch jobs to take advantage of the new job queues that I created last time.

Why Create and Assign Your Own Job Queues

All system i5 partitions use job queues to stage work for processing, and job queues are assigned to a subsystem through the use