2

I am preparing a program in RPGLE that will use Java function returning fancy PDF file. I want to take that PDF in RPGLE and create a PDF file on IFS.

For now the Java program returns the PDF in byte[] format. Than I take the byte [] as char in RPG and I try to create stream file out of it. But the PDF is damaged and I can't open it via Adobe Reader...

Below is the prototype of Java procedure and code creating stream file:

D GetPDF    PR    A ExtProc(*Java:'PDF':'get') Len(16773100) CCSID(*HEX)

   Dcl-S wkPDFTxt Char(16773100) CCSID(*HEX);

   wkPDFTxt = GetPDF();
   
   fd = open(filePath
            :O_CREAT + O_EXCL + O_WRONLY + O_CCSID + O_INHERITMODE
            :S_IRUSR
            :65535);
   write(fd: %addr(wkPDFTxt): %Len(%Trim(wkPDFTxt));
   close(fd)

Anyone is familiar with PDF creation and could help me how can I achieve this? I thought that taking byte [] as char() and writing it to stream file in UTF8 would work but it doesn't.

user2775380
  • 77
  • 8
  • Sounds possible, any idea what can I do to achieve what I need? – user2775380 Oct 17 '22 at 11:33
  • 1
    I'm not familiar with a Java class named PDF. Is that one of your own making? Can you show us that class? or if it is too big, tell us what package you are using to read PDFs? Maybe the problem is in that class? What is it actually returning in the byte[]? do you want it written directly or converted to something else? – jmarkmurphy Oct 18 '22 at 17:55

3 Answers3

2

I found the open/write/close functions. They are UNIX-type integrated file system APIs.

The CCSID when the file already exists is the file CCSID. The CCSID specified in the parameters is simply the CCSID that the file is created with. It should be either 1208 (UTF-8) or 819 (ASCII), even though PDF is a binary format. Maybe you should use 819 because that appears to be what you are getting from the Java method.

NO CONVERSION IS PERFORMED. according to the documentation

If O_TEXTDATA is not specified, the data is processed as binary. The data is read from the file and written to the file without any conversion. The application is responsible for handling the data.

You must make sure the data is in the required format. The docs are a bit confusing because that fourth parameter is called conversion ID and the docs say

The specified or derived CCSID is assumed to be the CCSID of the data in the file, when a new file is created. This CCSID is associated with the file during file creation.

The punctuation could be wrong. To line up with the rest of the document, it should be

The specified or derived CCSID is assumed to be the CCSID of the data in the file. When a new file is created, this CCSID is associated with the file during file creation.

In any case, you do not have O_TEXTDATA (and you shouldn't) so since the source CCSID looks like it is 819 (this is normal for a windows file in the US) you should make the CCSID 819 and just write the data the way you got it.

jmarkmurphy
  • 11,030
  • 31
  • 59
0

Probably an encoding problem... wkPDFTxt is char() so EBCDIC. If you are >= V7R2 you can force UTF8 for this variable , by adding to the declaration:

Dcl-S wkPDFTxt Char(16773100) CCSID(*UTF8);

Would it be possible to write the stream on the java side , and compare in hexadecimal with the RPG file ?

Dam
  • 986
  • 1
  • 14
  • 20
  • Thanks for answer! It helped to create a PDF that can be opened in Adobe. But its content is empty... Would you have any idea why it happens? I am sure the content of byte [] is not empty – user2775380 Oct 17 '22 at 10:53
  • Thanks K J, but what does it mean to me than? What should I do to recreate it correctly? In the PDF all bytes should be in UTF8. This is the agreement between me and Java developer who prepares the PDF in byte [] UTF8 – user2775380 Oct 17 '22 at 11:21
  • if the java code is executed on the ibm i , why not directly write it in the java part ? can you try with a varchar ? VarChar(16773100) – Dam Oct 17 '22 at 11:40
0

If you're dealing with binary objects like PDF, CCSID(65535) aka CCSID(*HEX) would seem to be more appropriate.

I'd add that to the PR and to the declaration of wkPDFTxt though wkPDFbuffer would be a more appropriate name.

Also, when you open the stream file, you'll want to use 65535 instead of 1208.

Lastly, your PR for the Java method looks a little suspect, it'd might be helpful to see the signature of the Java method you're calling to ensure it's been done correctly.

Charles
  • 21,637
  • 1
  • 20
  • 44
  • It sounds very promising. I did the change as you suggested but now I Get message „conversion between ccsid(65535) and ccsid(819) is not supported” while calling the Java method that returnes just byte[]… have No idea why it has 819 somewhere. I submitted the job with ccsid *hex – user2775380 Oct 18 '22 at 06:54
  • did you add CCSID(65535) to the PR? Update your post to include the latest code and the Java method – Charles Oct 18 '22 at 15:20
  • I've updated the code. CCSID(*HEX) was added to PR – user2775380 Oct 18 '22 at 17:40
  • @Charles, do you recognize those Java and stream IO functions? – jmarkmurphy Oct 18 '22 at 18:07
  • The IFS stream ones, yes...the Java no. – Charles Oct 18 '22 at 22:03