Submit to Batch, or Run Interactively?
From: Eric Lehti To: All
Do you have a rule of thumb you use in deciding whether to run a job interactively or on a job queue?
I read somewhere that a job that ties up your terminal for three to five minutes (with a priority 20 in QINTER), is equivalent to the cost of submitting it to run from a job queue at priority 50. The explanation was that job initiation sucks up some system resources, so you may as well run it interactively. Another source said 40 seconds is a good rule.
How many seconds or minutes do you feel is a reasonable length of time to tie up a workstation running a job before you think you (and all other users on your system) would be better off submitting it to a job queue?
I find that the majority of users accepts that their report will process in the order received on the job queue. And I am converting more of our jobs to submit to the job queue. But now the job queue is getting stacked up with 20 to 30 jobs, at times.
The other day a user said, "I liked it better when the job ran attached to my workstation. I could always get my report in two minutes. Now I don't know how long I will have to wait for it." What suggestions do you have?
From: Paul Yust To: Eric Lehti
What we do is group our users by location. For each location, we have a different job description (i.e., LOCAJOBD, LOCBJOBD, ACCTJOBD, etc.) that is specified in the user profile. Each job description has a corresponding job queue (i.e., LOCAJOBQ, LOCBJOBQ, etc.). Finally, each of these job queues is added to the QBATCH subsystem. Each job queue entry for the subsystem is set up to allow one active job. The whole QBATCH subsystem is limited to four active jobs. This way, we can have up to four batch jobs active at a time.
You probably won't want to create more job queues than the maximum number of active jobs you allow to run from the QBATCH subsystem, since it would mean that when all job queues have jobs in them, some of them would not get immediate service.
From: John Brown To: Eric Lehti
I was told by IBM many years ago that if a job has no user intervention required (i.e., reports, batch file processing, etc.), then it should run in batch regardless of the time it takes to run. Now, in real life, I take each job on an individual basis, contingent on the resources required to complete it.
From: Michael Catalani To: Eric Lehti
It sounds as though you have migrated from a S/36, because you said your users liked having their reports run on the display station. I ran into the same problem all the time when I migrated S/36 shops. They were used to having their reports run on screen so they knew when the report finished.
There are some major performance reasons why you should not do this, but one reason most people do not know about is how the system actually handles interactive batch jobs. The system has some "performance algorithms" that will actually raise an interactive batch job's priority (numerically lower it) because it is I/O intensive. This will give that report program more priority than your true interactive users.
The best way to handle them is to submit them to batch. These reports may run slower until you get all of your "batch" work submitted. The best way to handle this depends on the size of your processor and the amount of memory you have. You can set up multiple job queues, but the number of batch jobs you should have active at a time depends on your processor speed and memory size.
If your processor is not running near 100 percent, then you have some processor time not being used. Therefore, you may be able to run more batch jobs. If it makes good business sense to run your report programs from the display station, then do it. In this case, use the Change Job (CHGJOB) command before and after running the program and lower the job's priority to 30 or 50. This will help keep it from competing with the interactive jobs.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online