FTP GET creates a file in the IFS. Basic users can work w/that file, ROBOT cannot.

Frosty the Coder

Legendary Poster
I created a job that does an FTP GET from a windows folder into the IFS.
The IFS file is created as /MYFOLDER/MYFILE

Immediately after the FTP, I issue a CPY (copy object) command to correct the CCSID.

After the CPY, the job works with MYFILE.

The CLP works when run from my userid.
It works when run using a basic userid.

It FAILS, throwing CPFA0A9, but only when running under userid ROBOT.

This works/fails in the same fashion on the production machine as well as the test machine.

My userid, the generic userid, and ROBOT all have QGPL/QDFTJOBD set for job description.

My "special authorities" are *ALLOBJ; *JOBCTL; *SAVSYS; *SECADM; and *SPLCTL
The generic userid only has *JOBCTL.

The supplemental group is *NONE for the generic user.
My id and Robot have differing values.
As the generic user has *NONE, I don't think this setting is the issue.

I am convinced that something in the ROBOT userid is set differently than my ID or the generic user.
I've pored over the user profiles, but don't see a setting that would (seem to) make a difference.

/MYFOLDER/MYFILE has *PUBLIC authority of *RWX, (Objopr, read, add, update, delete execute).
Nothing that I've seen explicitly prevents ROBOT.

Where else can I look to find why ROBOT userid fails?



Well Known Member
CPFA0A9 = Object not found. Object is &1.

Are you sure it's authority related?

My first thought is that the job either (1) can't find the file in the IFS or (2) the library list is incorrect and it can't locate MYFILE.

Frosty the Coder

Legendary Poster

Thanks for the reply.

The MYFILE is being created.
I can see it in the IFS at the same time that ROBOT is in MSGW for the CPFA0A9.

The CPY command is being passed the full IFS pathname.
*LIBL shouldn't matter.

I had read, during one of the google searches, that CPFA0A9 can be false positive due to authority.
That's what this feels like.

I haven't NOTICED anything that would exclude ROBOT.

Still digging...


Frosty the Coder

Legendary Poster
FOUND IT, and what a "learning experience" it was.

When using the IFS, the "home directory" setting of the user profile comes into play.

I changed the CPY, which was to correct the CCSID, to a CHGATR changing the CCSID.
ROBOT still failed, BUT it threw another message into the joblog stating "/home/ROBOT/myfolder/myfile" was not found.
This was accurate as it was in "/myfolder/myfile".

I added a "CHGCURDIR /", which sets the current directory to "root".
This caused the CLP to look for JUST "/myfolder/myfile".
This is working, at least on our test system.

I am both IGNORANT and APATHETIC as to why other profiles work.
That's right, "I don't know and I don't care".

(Still supporting A7.3 while moving to Oracle EBS)


Well Known Member
Frosty -

Permissions in the IFS are much different from traditional IBM i object authorities. The Integrated File System uses Unix-style permissions.

Please read this document:

One solution is to create a "group" profile (perhaps call it IFSOWN) and make IFSOWN the Primary Group on the folder MYFOLDER, then add IFSOWN as a supplemental group to the ROBOT user profile or any other profiles which need to use the files in MYFOLDER.

The objects created in MYFOLDER will inherit the Primary Group from MYFOLDER, thus ROBOT should then be authorized:

Also review how the STMFAUT(*INDIR) parameter on CPYTOIMPF works...