The IBM i operating system is highly dependent on environmental variables, which can have a significant impact on its performance. In this article, we will dive into the various environmental variables and their effects on the IBM i.
What are environment variables?
Let me start at the beginning, what are environment variables?
Environment variables allow you to set variables to a value prior to executing a program or script. For example you can set an environment variable to allow you to run debug on a green screen in wide screen mode. I cannot be the only one that uses a quick STRDBG from a green screen, can I?
This can be seen in the figure below.
An environment variable is made up of a named pair, for example API_KEY=”mySecretKey”
On the IBM i, environmental variables can either be set at a system, or job level. By default, as in the ADDENVVAR command shown in the figure above, this variable would be set at job level.
As I’m sure you can gather, variables set at a system level, affect all jobs.
Please note that a user must have *JOBCTL special authority to use these commands for system environment variables, but any user can use them for their job environment variables.
Environment Variables Commands
This section details all the green screen commands we can use with environment variables.
The Work with Environment Variables (WRKENVVAR) is shown in the figure below.
How can I check environment variables?
As part of the excellent, and very useful, DB2 for i services, IBM has provided a SQL service that will list all your environment variables.
FROM QSYS2.ENVIRONMENT_VARIABLE_INFO ;
The information provided by this SQL statement returns similar information to the WRKENVVAR command.
You can also find all your environment variables by taking option 22 off the DSPJOB (Display Job) command.
The output from this command is shown in the figure below.
As well as the SQL statement and CL commands listed above, there are also a number of system APIs that can be used to check your environment variables. These are listed under the IBM informational centre API finder.
As well as the ILE_DEBUGGER_1 I mentioned earlier in this article, an environmental variable worth a mention is the QIBM_MULTI_THREADED variable, which is used to enable or disable multithreading support in IBM i applications.
This variable needs to be set to Y if you are having issues with submitting, or using QSHELL.
This variable can have the following values:
- “Y” to enable multi-threading support
- “N” to disable multi-threading support
By setting this variable to Y, it normally stops any errors encountered with a job ending with a PASE signal 5 error.
There is another environmental variable that I have had to set on a users box, this one allows the maximum number of spool files for a job on the system to be changed. This one is called QIBM_SP_MAXSPLF and allows a maximum of 999,999 spool file for a job.
Please note, that if this environment variable is set, it overrides the QMAXSPLF system value.
Knowing about environmental variables can save you time and trouble. I certainly wasted a lot of time with the PASE signal 5 error!
Be sure to take a look at them!
All the examples I have written for this article, and previous ones, can be found on my companies open-source repository on GitHub, which can be found at https://github.com/formaserve/f_Learning
If you have any questions, either on this article, or anything else on the IBM i, please use the comments below, or send me a message on twitter @AndyYouens
Andy Youens is an IBM i consultant/instructor at Milton Keynes, UK-based FormaServe Systems with over 40 years IBM midrange experience.