Greetings -

I have an issue when holding PDF files to our USS (Unix) box. The problem is when I FTP them off the box they cannot be opened. I get an "A file I/O error has occured" error. After looking at the contents of the file via a text editor I noticed visible carriage return characters (squares) at the end of every row. The same report working using PC hold does not have these characters. When the characters are removed the file opens fine. What is giving me this added bonus? I am stumped.

Thanks

Check to see if the same issue occurs when you FTP the file with binary mode set versus ascii mode.

This might help.

I have tried both to no avail.
I have even successfully FTP'd a working copy to UNIX from windows and back to eliminate the FTP process as a culprit.
I can defer a PDF on UNIX and retrieve it successfully from the MR defer window, but I don't think a saved defered report is stored the same way a filedef'd file is.

Shawn,

I do not have a Unix environment but I vaguely remember seeing this issue discussed or mentioned somehwere. Try doing a search on Focal Point to find other threads regarding this issue. I'm sure there is a solution on here somehwere.

You may also want to search IB's tech support.

Last but not least, please update your signature with paltform/version/environment information.

Well, Mickey, I do and I just did a test and didn't have any problems.

First I did an APP HOLD and held (ON TABLE HOLD AS XXXXX FORMAT PDF) my pdf document in a directory in ibi/apps. To make sure that it was ok, I went to a browser and typed in a link to open the document in browser. Worked great. Then I ran ftp from my desktop and transferred it from my AIX system to my PC. I opened the file just fine.

Shawn, could you please update your profile signature with your product suite, release, and platform so that we can better help you.

Also, indicate how your process is different than mine.

(profile updated)
I have been searching the forum without any luck.

here is my code:

FILEDEF HOLD1PDF DISK /u/iadmin/wfsadhoc/temp_files/temp01.txt
TABLE FILE CAR
PRINT COUNTRY
ON TABLE HOLD AS HOLD1PDF FORMAT PDF
END

When viewing the file via view editor in unix each line ends with a ^M.
Running the same fex with PCHOLD and viewing the file these ^M characters do not exist. If I remove the ^M s manually, then the file opens in adobe perfectly.

quote:

FILEDEF HOLD1PDF DISK /u/iadmin/wfsadhoc/temp_files/temp01.txt

Change .txt to .pdf and I am convinced that your problems will go away. If you download the file as txt, Windows will try to use Notepad to open the file as opposed to Adobe. If the suffix is pdf, it will know what program to use to open the file.

Here are a couple things - you should get in the habit of having a -RUN after your FILEDEF works in your case without but will save you headaches in the future.

What happens if you filedef the file to temp01.pdf instead of temp01.txt?

We also run in USS, but in my test, the file that is created (either with .txt or .pdf) has no ^M on the lines when I view it with the oedit line editor. I have used your code exactly as is. There must be a character translation setting or something that is not correct.

oops.. my fault. It was .PDF, but I was trying everything to "trick" it.

I heard back from IBI who said its a known issue and has since been fixed in 7.3.6.. I'm assuming he meant 7.6.3.

Thanks all for your time.

I ran across something in my travel through documentation today that reminded me of this post. I didn't test anything so I don't know if this might help, but there is a setting called PDFLINETERM. From the Docs:

Description:
Determines if an extra space is appended to each record of a PDF output file to facilitate proper file transfer between Windows and UNIX.

In Windows systems, the end of each PDF file has a table containing the byte offset, including two line termination characters, a carriage return and a line feed. In UNIX, files are terminated by only one character, a line feed. Transferring files between Windows and UNIX systems requires the proper use of the PDFLINETERM parameter.

Syntax:
SET PDFLINETERM = {STANDARD|SPACE}where:

STANDARD

Creates a PDF file without any extra characters. This file will be a valid PDF file if transferred in text mode to a Windows machine, but not to a UNIX machine. If subsequently transferred from a UNIX machine to a Windows machine in text mode, it will be a valid PDF file on the Windows machine.


SPACE

Creates a PDF file with an extra space character appended to each record. This file will be a valid PDF file if transferred in text mode to a UNIX machine, but not to a Windows machine. If subsequently transferred from an ASCII UNIX machine to a Windows machine in binary mode, it will be a valid PDF file on the Windows machine.