ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

CPF3401 error

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • CPF3401 error

    Hi,
    I created a simple CLP process that runs a query and outputs to a file and then sends the file as an email attachment. Works great for some but not others. After researching the error the user receives (CPF3401) I discovered that it's (supposedly) an authority issue to the .CSV object. I tried granting authority from within the CLP but that didn't help. Then I realized that some users go into a system 36 environment and others do not. As it turns out the users that go int the 36 environment are the ones that are getting the error.

    How can I get around this error?

    Mike.
    Everyday's a school day, what grade are you in?

  • #2
    You might want to check the message ID again. The ID doesn't seem to match up with your description of the issue.

    CPF3401 Cannot change COPIES for files in PRT or SND status.
    from https://www.ibm.com/support/knowledg...l/chgsplfa.htm

    Comment


    • #3
      How does your "simple CLP process" work? You say it runs a query, outputs to a file, and sends the file as an email attachment. Which one of these is getting the error? What is the error (Like jtaylor said, i doubt its cpf3401) and what command are you running when the error occurs?

      Comment


      • #4
        I have asked a user to request the report so I will provide you the job log. It is CPF3401 and if you google it you will find it is related to the CPYTOIMPF command. https://as400tips.wordpress.com/2014...r-number-3401/
        Everyday's a school day, what grade are you in?

        Comment


        • jtaylor___
          jtaylor___ commented
          Editing a comment
          I see. 3401 isn't CPF3401, it's CPE3401 (Permission denied).

      • #5
        Ok,
        The message id is CPFA0D4. In the joblog it simply states "File system error occurred... 3401" - my mistake.
        Click image for larger version

Name:	3401.png
Views:	2174
Size:	10.4 KB
ID:	153560
        Everyday's a school day, what grade are you in?

        Comment


        • #6
          If you read that message description it tells you that you can get the file system error with DSPMSGD CPE3401 which says Permission Denied:

          Message ID . . . . . . . . . : CPE3401
          Message file . . . . . . . . : QCPFMSG
          Library . . . . . . . . . : QSYS

          Message . . . . : Permission denied.
          Cause . . . . . : An attempt was made to access an object in a way forbidden
          by its object access permissions.


          Comment


          • #7
            .


            Last edited by Scott M; July 16, 2020, 09:11 AM. Reason: Duplicate

            Comment


            • #8
              1. What file system is this? (e.g. root)
              2. Does the file already exist?
              3. Have you checked the permissions at every dir in the path?
              4. Are you saying it works for a user, but if that same user activates S36 special environment it stops working?

              Comment


              • #9
                Originally posted by jtaylor___ View Post
                1. What file system is this? (e.g. root)
                2. Does the file already exist?
                3. Have you checked the permissions at every dir in the path?
                4. Are you saying it works for a user, but if that same user activates S36 special environment it stops working?
                IFS
                No, it's created initially but then remains and is replaced.
                Yes, all directories have *PUBLIC *RWX for data authority.
                Correct, Users that do not work in the S36 environment are able to run the report and receive the email generated. Others that do work in that environment get the error.
                I checked the file that is created initially and it had *PUBLIC *NONE for data authority so I changed it and asked the user to rerun but haven't heard back yet.

                I believe your checklist pointed out the missing authority on the file but, how do I handle this going forward for new files, for users in the S36 environment?

                Everyday's a school day, what grade are you in?

                Comment


                • #10
                  1.
                  There are seven file systems in the integrated file system:
                  • root (/)
                  • Open Systems (QOpenSys)
                  • Library (QSYS.LIB)
                  • Document Library Services (QDLS)
                  • LAN Server/400 (QLANSrv)
                  • Optical Support (QOPT)
                  • File Server (QFileSvr.400)


                  2. So the file already exists and the error is trying to replace it?

                  4. So for a given user it always works or always fails, correct? If they have *S36 in their user profile it always fails, correct?

                  Comment


                  • #11
                    Originally posted by jtaylor___ View Post
                    1.



                    2. So the file already exists and the error is trying to replace it?

                    4. So for a given user it always works or always fails, correct? If they have *S36 in their user profile it always fails, correct?
                    Yes, I believe that is the issue, trying to replace it.
                    S36 = failure.
                    Everyday's a school day, what grade are you in?

                    Comment


                    • #12
                      There's something we're not seeing. I'd recommend an authority collection.
                      Authority collection is a capability that is provided as part of the base operating system. At a high level, authority collection captures data that is associated with the run-time authority checking that is built into the IBM i system. This data is logged to a repository provided by the system and interfaces are available to display and analyze the data. The intent of this support is to assist the security administrator and application provider in securing the objects in an application with the lowest level of authority that is required to allow the application to run successfully. By using the authority collection capability to remove or avoid excess authority, the overall security of the objects that are used by an application is improved.


                      Comment


                      • #13
                        I wonder if the System 36 environment is restricted to only using QDLS since the root file system didn't exist back then? Or maybe it needs the files to conform to the 8.3 convention? Maybe try creating a test version that writes to file in QDLS and see if that works and try with short file name too.

                        Comment


                        • jtaylor___
                          jtaylor___ commented
                          Editing a comment
                          We have *S36 set at the system level, so every user has that value. We use the root file system without issue (haven't used QDLS in forever).

                        • redvan
                          redvan commented
                          Editing a comment
                          I have been leaning towards some authority issue with the S36 environment since only users that log into that environment have an issue. Anyone else, and I mean anyone, outside of S36 does not have an issue with this process or any other.

                        • jtaylor___
                          jtaylor___ commented
                          Editing a comment
                          Since you've identified the problem being users with *S36, then I agree it's likely something in your environment related to that which is the problem. Hopefully the authority collection will identify the culprit.
                      Working...
                      X