Reader Input: /QOpenSys Redux, PC5250 Popup Keypads, and Even Farther Beyond Replication

June 24, 2009 Hey, Joe

It looks like the links that you detailed in the Matryoshka Doll article on nested QOpenSys links probably occur after installing PASE on the iSeries. Check out this IBM document that very briefly discusses recursive /QOpenSys links in the AS/400 IFS. IBM doesn’t say why this happens, but at least it points the finger at what causes the problem.

–Bill Speicher

Earlier this year I wrote this article and a tip on one of the great mysteries of the AS/400 Integrated File System (AS/400 IFS). The purpose of the article was to explain why there are multiple /QOpenSys symbolic links (symlinks) nested one inside another in the AS/400 Integrated File System (AS/400 IFS), resembling some kind of bizarre i5/OS Matryoshka doll. You may be able to see this effect for yourself on an i5/OS system by opening the /QOpenSys folder off the root of the IFS (/), only to find another /QOpenSys folder inside that folder. Open the /QOpenSys/QOpenSys folder and you’ll see a third /QOpenSys entry, and then another, and another. This will continue indefinitely until you breach the upper limit on the POSIX_SYMLOOP value in the LIMITS member of the SYS file in the QSYSINC library, where the process will simply error out with a “Path name resolution causes looping” error.

I won’t get into all the grimy details of how this happens here, but you can see the earlier results of my (and my readerships’) research in that April 15th article titled And /QOpenSys and /QOpenSys and /QOpenSys and…. We fleshed out a lot of reasons for how the issue happens, but I wasn’t able to answer the question of why those nested (or recursive) /QOpenSys entries are in the AS/400 IFS in the first place.

In the IBM document referenced by Bill, confusingly titled, QOpenSys Link off of Root Recursive, Big Blue answers the question with this startling simple sentence:

“The /QOpenSys link under /QOpenSys is a symlink required by PASE. A symlink is like a pointer and takes up no DASD on the system.”

That settles it. IBM done it. So between my article and this candid admission from IBM, we can probably consider the case closed. Or can we? Reader Tim M. added this addendum about the possible importance of the /QOpenSys/QOpenSys link for programmers:

Although I haven’t confirmed this, I suspect it [the /QOpenSys symlink] is there to make PASE commands continue to work properly if chroot is performed to the /QOpenSys. –Tim M.

[Joe’s Note: chroot is used to change the disk root directory for the current running process.]

Tim presents a good reason for keeping the /QOpenSys/QOpenSys symlink, instead of deleting it, as I implied you could do in my earlier article. You could mess up any programming that relies on chroot, possibly even inside PASE, if you delete the recursive /QOpenSys/QOpenSys/… link.

So I’m starting to get it. Multiple /QOpenSys links are probably caused by PASE installation on the i5/OS operating system, and it may hurt some applications if you delete the /QOpenSys symlink. Game over. Problem solved. Or it was until reader Charles Wilt wrote in with the following possible explanation for why the /QOpenSys/QOpenSys symlink exists in the first place:

My understanding is that it’s due to the fact that most PASE software runs in /QOpenSys. PASE software is compiled for AIX, and in AIX, software expects to have certain standard directories like /usr, /usr/local, /usr/bin, etc. However, in PASE instead of (for example) /usr/bin, those directories actually reside in /QOpenSys/usr/bin.

So PASE plays a trick on the program where it adds a /QOpenSys to the start of the path name. The program specifies /usr/bin, and PASE actually directs it to /QOpenSys/usr/bin.

The problem is, what happens when a program (perhaps from user input) actually does specify /QOpenSys/usr/bin? Because PASE adds /QOpenSys to the beginning of the path name, you’d have /QOpenSys/QOpenSys/usr/bin which would be a problem–and that’s where the symlink comes in. If you specify /QOpenSys/QOpenSys/usr/bin, it’s the same directory as /QOpenSys/usr/bin, thanks to the symlink. –Charles Wilt

Putting it all together, here’s what we get:

IBM requires the /QOpenSys/QOpenSys symlink in order to run the PASE software on i5/OS. So don’t delete it.
The PASE software was originally compiled for the AIX operating system, which expects certain standard folder names, such as /usr, /usr/bin, etc. The symlink allows those standards to be used for AIX applications without rewriting the application and it may also protect the integrity of /QOpenSys/ sub-directory names from programmers who specify directory paths such as /QOpenSys/usr/bin.
The symlink is also needed in case any software uses the chroot command to change the apparent disk root directory for the current running process and its children.

And I think I’ll leave it at that before I wind up having to change the name of my column to “Admin /QOpenSys/QOpenSys Alert.” However, if you’re into even more /QOpenSys² talk, email me and I’ll send you reader Jeff Gardner’s test results, where he elaborates, corrects, and fleshes out my discussion about how i5/OS resolves references made to objects in the /QOpenSys/QOpenSys symlink. It’s illuminating, but too long to fit into this tip. Thanks for the info, Jeff!

And thanks to everyone who sent me information on the /QOpenSys symlink. Now it’s time to break up this party and move on to another topic.

Reader Input on PC5250 Popup Keypad Moves

To cleanse the palette and change the subject, here’s a bonus tip from reader Trevor Briggs that expands on my June 10th tip about copying PC5250 pop-up keypads from one machine to another. In that tip, I explained to a reader named Beth how to duplicate the pop-up keypad from one PC5250 setup to several other setups. Trevor pointed out one simple but critical item to check when porting keypads between machines:

There’s one other thing that Beth may need to do when copying keypads between machines. If any of the new keypad keys invoke keyboard macros or a script, she will need to copy those from the old PCs, too. Otherwise that function will not work on the new PC. –Trevor Briggs

If you’re in this situation, pay heed and listen. This tip may someday save your popup keypad functionality.

More Farther Beyond Replication Items To Check

Finally, in response to my article on going beyond replication in an i5/OS high-availability environment, reader Dave Flint wrote in to remind me to add these items to my list of things that may not necessarily be replicated to a Capacity BackUp System (CBU) by your high-availability software.

Job Schedule Entries for automatically running jobs from the i5/OS Job Scheduler, which can be updated on the green screen from the Work with Job Schedule Entries (WRKJOBSCDE)command
System Reply List (SRL) entries for automatically answering i5/OS inquiry messages, which turned out to be strangely complex after I called IBM about replicating my SRL to another machine. I’ll report on that process in a future column
Device descriptions and remote output queues, which actually can be replicated when using certain high availability software
Your Work with Relational Database Entries (WRKRDBDIRE) setup

So be sure to consider these objects when examining your replication process to find any other items that may need to be duplicated from a production machine to a CBU.

–Joe

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search