ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

DDS AFPRSC grafic field error CPD6F8C

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

  • DDS AFPRSC grafic field error CPD6F8C

    I got a strange issue. If I submit an AFPRSC grafic file name by a fieldname, the system reports a CPD6F8C error and nothing was printed. But if I indicate the same value as a constant all works fine and the grafic was printed.
    Do somebody know something about this? I appreciate any help.
    Thanks.

    DDS:
    A R LOGOIMAGE AFPRSC(&LOG_FILE *JFIF + ....
    A LOG_FILE 125A P
    (V7.3/CCSID 65535)

  • #2
    First the obvious thing:
    How long is the filename?
    The field has a limit of 125 bytes. Is the filename including directory etc longer than that?

    Comment


    • #3
      Second:
      In the manual there is a comment about the resource.

      Note: When you provide the resource-name, path-to-use, external-name, or secondary-resource-path as a literal value, the operating system assumes that it is specified in the coded character set identifier (CCSID) of the DDS source physical file. When you provide the resource-name, path-to-use, external-name, or secondary-resource-path as a program-to-system field, the operating system assumes that it is specified in the default job CCSID.

      The resource-name is the name of the file in the integrated file system, including the file extension, if there is one. If the complete name is not specified, the resource will not be found. The maximum size of the quoted string is 250 bytes. The name cannot contain characters that can be interpreted as path name delimiters. To ensure portability across all AFP platforms, see the MOCA™ Reference (SC31-6802) book for a list of characters that are allowed in an external resource name.


      There is a comment about CCSIDs among other things. Might be your problem there.

      Comment


      • #4
        Thanks Peder for the reply.
        The lenght of the file name is about 20 chars. It might a CCSID problem perhaps, but I'm not sure.
        I made a test drive with a new DDS like the old one, only with the grafic defs and that run well. It's only that printer-file.
        As mentioned, the filename as constant is ok, as content of a file it fails. Strange

        btw. the file name must not contain the path.

        Comment


        • #5
          Just got curious what CPD6F8C meant:

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

          Meddelelse . . : The requested resource name syntax is not valid.
          Ã…rsag . . . . . : A resource name with syntax that is not valid was
          specified for DDS keyword AFPRSC on record format &6 for file &2 in library
          &3. The AFPRSC DDS keyword is ignored.
          Handling . . . : Specify a resource name that does not contain characters
          that can be interpreted as path name delimiters and whose length is valid.

          Comment


          • #6
            In a very old manual for DDS printer files ( V6R1 ) there is something about paths for AFPRSC on page 16.

            Use the optional path-to-use parameter to further qualify the AFP resource. You should specify this
            parameter as an expression of the form (*PATH path-to-use). If you do not specify the path-to-use
            parameter, the environment variable QIBM_AFP_RESOURCES_PATH and the explicit path
            /QIBM/UserData/OS400/AFPresources are used to search for the file. You can specify these values for the
            path-to-use parameter:
            - *NONE. A path is not specified. *NONE has the same effect as if the path-to-use parameter is not
            supplied at all.
            - *CWD. The current working directory for the job is specified.
            - path-to-use. An absolute path name is specified. This must be a single directory. The value is a quoted
            string whose maximum length when the path name is provided in the DDS is 2000.
            Note: When you reference a resource, if you specify (*PATH *NONE) or if you do not specify *PATH at
            all, the resource must be available through directories specified with the environment variable
            QIBM_AFP_RESOURCES_PATH or the explicit path /QIBM/UserData/OS400/AFPresources.

            See “How the operating system searches for resources on the path-to-use or the secondary-resource-path
            parameter” on page 20 for more information.


            On page 20 there is a description and examples how it searches for the resources ( default paths etc ).
            This might give you a clue what is going on.


            If you find out what the problem is then please put a post in here describing the cause.
            Might help other programmers in the future.


            Comment


            • #7
              Peder,
              I know how to indicate correctly the parameters for printing an afp resource. Yes, the path issue too.

              Latest news of this problem:
              The same printerfile (wihtout changes) was printed by one cobol program (only test and output operations) and by the other (production) not. Isn't that strange?

              And obviously I can't find somebody who could help me with that problem.
              Yes, of course, if I find out the solution, I'll publish it here.

              Comment


              • #8
                Just one final remark:
                Is AFP installed on the production system?

                From the manual:
                Beginning with OS/400® V3R1, the Advanced Function Printing (AFP) subsystem was a separately
                orderable feature of the IBM i operating system, called Print Services Facility™ (PSF).

                There are two separate subsystems in the IBM i operating system. The original IBM i printing subsystem
                continues to support line printers and a subset of IBM Intelligent Printer Data Stream (IPDS) printers and
                print functions. Full support for all IPDS printers is provided by the integrated AFP printing subsystem.
                The printing subsystem used to process application output is determined by the device description of the
                target printer. Only printers defined as DEVTYPE(*IPDS) and AFP(*YES) (both specified in the printer
                device description) are controlled by the AFP printing subsystem.

                In order to print based on the values specified for certain keywords, PSF is required. For example,
                spooled files generated with DEVTYPE(*AFPDS) can only be printed by PSF.

                Comment


                • #9
                  Peder,
                  It's the same system.

                  Comment


                  • #10
                    OK. Same system but perhaps different users?

                    Does the user in the production system have the same credentials as the user in your test system?

                    With that I am thinking about if the user in the production system have rights to access the referenced directory or file?

                    Could it be something to do with the "Home directory" on the user profile.
                    Many years ago I experienced some very funny things with the Home directory…. and old programs expecting to start
                    referring to the root ( / ).

                    Comment


                    • #11
                      No, it's always the same user. A credentials right problem I don't think so. If the grafics file name is a constant in the DDS the picture will be found, the same value in a variable not. I assume there is something going wrong while the spooler prints the printerfile. This is so tricky, i have the same printer DDS, the same user, the same jpg, a simple cobol program that prints all and the other (productive, with filled fields for the document) not.

                      Comment


                      • #12
                        Trailing blanks?

                        Cheers,

                        Emmanuel

                        Comment


                        • #13
                          Emmanuel,
                          'mypicture.jpg' defined in the DDS works, MYPIC = 'mypicture.jpg' doesn't work. The field value is correct.

                          Comment


                          • #14
                            You are referring to programs in the test environment and production environment.
                            Is it the same programs or two different programs?
                            If different programs then you must see what the difference is.


                            Regarding the name of the jpg file on the IFS.
                            Are the cases of the letters the same?
                            Remember names are case sensitive.
                            mypicture.jpg is not equal to MyPicture.jpg

                            I assume that the file name only has the characters a-z, A-Z or 0-9 in it.
                            Otherwise you might experience funny problems with different CCSIDs etc.

                            Comment


                            • #15
                              Peder,
                              different programs in the same environment with the same user.

                              Program1 origin program: If I indicate like this 'PIC999888.jpg' as a constant in the DDS it runs ok, if I do that: PICFIELD = 'PIC999888.jpg' than not.
                              Program2 simple test program: I do exactly the same as in program 1, both versions run ok. Note, with the same printerfile of program1.
                              And yes your right, I have only simple chars and nums in the file name.

                              The problem ist not finding the file in the ifs, the problem is that the system asumes that there is a path separating char in the file name parameter.
                              But we never move a char like that. It's so strange.

                              btw.
                              if you indicate a fully qualified filename in the file parameter field, you get this error too. But we don't this this way - ergo, it doesn't matter.

                              ... and thanks for taking attention!

                              Comment

                              Working...
                              X