Where did the QSYSOPR messages go?
Who answered that inquiry message?

Often we see users answering messages on the QSYSOPR message queue. Sometimes they respond correctly, sometimes they don't. Remember displaying the QSYSOPR message queue to see what has been happening on your system only to see an empty QSYSOPR message queue.

All of us need to secure the QSYSOPR message queue correctly. It is the message console for the entire system.

Users need to be able to send messages to QSYSOPR, but not answer messages. For that they need Data *ADD and *OBJOPR rights to the queue...

There are times when we need to allow a user to perform a function that is beyond their authority level. For example, I have a menu option that displays certain selected information from a customer credit file. It shows the Customer name and address, but it does not display any of the sensitive data in the credit file.

In this example, the user should have no authority to access the file. But, when executing this particular menu option to view the Customer Name and Address, I need to elevate the user's authority to allow the user to access the file. The typical method used to elevate the user's authority would be to use Adopted Authority.

When a program is executed that adopts authority, that adopted authority will be propagated to all programs that are subsequently called, until the original program that adopted authority is ended.

Another way to look at this is that Adopted authority is passed down the program call stack to all called programs and subprograms. Each of these programs will ultimately RETURN to the CALLing program. When the program that adopted authority RETURNs, the adopted authority is removed.

It is a common misconception that there is only one way to stop the propagation of authority to a called program. That method is implemented by using the USEADPAUT(*NO) program attribute in a called program.

If a program in the Call Stack has adopted authority, and a program is then called that specifies USEADPAUT(*NO), that program, and any programs that it CALLs will not use the adopted authority established earlier in the Call stack. It is a great way to stop the propagation of adopted authority. In this case, the adopted authority established in one program is propagated to a CALLed program, but the CALLed program says 'I don't want to use any adopted authority'.

There is another way to stop the propagation of adopted authority, but using this method, a program that adopts authority can say to a CALLed program, "I've got adopted authority, but you can't have it".

In essence, if a program is running under adopted authority, that program can change its own runtime attributes to either propagate or NOT propagate the adopted authority that is present at its call level.

The i/OS Host File Server and Netserver facilities present severe vulnerabilities to your production database and applications. When your system ships from IBM, the File server is configured to be easy to use, but, vulnerable. So, it is up to you to learn how to protect the system and then to make the required changes.

There are several file sharing methods that can be implemented on i/OS. You can use iSeries Access file sharing to navigate through the IFS(Integrated File System) to locate a stream file, directory, or other object. This is typically done using the iSeries Navigator "File Systems" option. Using this type of file sharing, you can even navigate through the QSYS.LIB file system, which makes 'Drag and Drop" access available to your production libraries, files, programs, etc.

Another popular method of file serving is to use the built in support for Netserver, where you can use MS/Widows Explorer to "Map a Drive" to a shared directory in the System i IFS.

IBM has tried to make things easy by shipping the system to us with a pre-configured Netserver "Share" directed at the system's /root file system. This is very dangerous.