|
Hi Steve,
Why did this just start happening? Perhaps the profile under which this job runs didn't have a current directory and picked up '/'
Exactly right. The "current working directory" (CWD) is the IFS equivalent of the more traditional "current library". Since you've worked with the AS/400 for awhile now, I'm sure you're familiar with using paths like *CURLIB/MYFILE to reference a file in the current library.
The IFS "current directory" works the same way. If I referece an IFS pathname of "myfile.csv" it looks for myfile.csv in the CWD. If I reference "mydir/myfile.csv" then it ooks for "mydir" in the CWD, and looks for myfile.csv.
For example, if your current directory is /home/steve and you use the pathname "mydir/myfile.csv" then the system will actually look for a file named /home/steve/mydir/myfile.csv
If you DON'T want to look in your CWD, then you need to start the IFS pathname with a slash. For example /mydir/myfile.csv would NOT look in your current directory, it'd look for "mydir" in the root of the IFS.
or perhaps the profile was changed or perhaps the job stream changed to issue a CD somewhere?We cant understand why it just (we say just it actually started about 2-3 weeks ago but the users have only just informed us) started happening. As I say the only thing we have done recently is load WDSC.
It makes perfect sense why WDSC would cause this problem.Each user profile has a "home directory." When the user signs on, this is what their CWD starts as -- it starts as the home directory. By default, that home directory will be /home/usrprf. For example, if your user profile name is STEVE, then your home directory would be /home/STEVE. When you first sign on, that's what your CWD will be. You can change your CWD with the 'CD' or 'CHGCURDIR' command at any time. This is analogous to changing your change your *CURLIB with the CHGCURLIB or CHGLIBL commands.
If you sign on and your home directory doesn't exist (because nobody has created it) then the system changes your CWD to / automatically because many commands operate on the CWD, so having it set to a directory that doesn't exist can cause things to fail. So the system "fixes" the problem by switching you to the / directory. (By the way, the / directory is called "the root directory".)
Now... here's the thing... The Remote Systems Explorer (RSE) in WDSC needs a place (for each user, separate from the others) to store logs and settings related to WDSC. It stores this information in your HOME Directory.
If your home directory is /home/STEVE, for example, it'll create a directory named /home/STEVE/.eclipse/RSE and it'll store logs and various settings in that directory.
In order to create that directory, /home/STEVE has to exist. So WDSC will create it.
Since WDSC has created it, this also means that when you sign on, your CWD will default to /home/STEVE, even though it was previously the root directory. This SHOULDN'T cause any problems, in theory, because programs shoudl never just assume that they'll always be run with the CWD set to a particular directory!
In your sample code, the programmer OBVIOUSLY intended to reference the QSYS.LIB filesystem, which is always listed immediately off of the root directory. It makes NO SENSE to code it as 'QSYS.LIB/mylib.lib' It should ALWAYS be coded as '/QSYS.LIB/mylib.lib' because you never want to reference QSYS.LIB as starting from "whatever the current directory happens to be", instead you always want to reference QSYS.LIB as being right off of the root directory.
From my perspective, the problem is that the CL program you posted herewas written improperly. When it worked before, it was largely due to coincidence. The user JUST HAPPENED to be in the right place at the right time for it to work.
Unfortunately, this is a common mistake with iSeries people. Because we're used to referencing 'library/object' they just assume that the IFS is 'directory/object'. But, that's not how the IFS works. It's also not how Windows or Unix work -- Windows and Unix work like the IFS does.
IMHO, the correct fix for your CL programs is to insert a leading slash into the path name. You COULD fix it by changing the CWD using the CHGCURDIR or CD commands before running the rest of the CL program, but IMHO that's the wrong way to fix it. Inserting the leading slash is the right way, because the intent of the programmer is to reference a specific location in the IFS, not a location that's relative to the CWD. Therefore, you shouled be using absolute paths, not relative ones.
Furthermore, if your users/operators/programmers understand the IFS, they may actually use the CWD in the same way that they use library lists and the curlib today. Do you really want to change their CWD and not tell them? This would be like changing their library list in a CL program, and then just leaving them with a different library list after it completes. Unless they were expecting it, it'd probably cause them grief.
Anyway... hope this helps you understand.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
