Thanks to all who wrote about this problem. The simplest solution - that of simply copying the JPG files to one type 19 directory - is working, to my amazement. There are 171,000 mugshots in one directory and they are being handled correctly. As far as a solution goes, that's good enough.
However, Craig's technical example regarding conversion was worth pursuing. I forgot to mention that there are two steps: storing the JPG record into the file, then copying it back out to a directory. Once it's out I can use it. Simply, the record has to go in and out of the Universe dynamic file intact. I mimicked the code Craig supplied then wrote a corresponding program to copy the record out. Since the code used OCONV before storing, I guessed ICONV would be the choice when reading form the universe dynamic file: ASSIGN 1 TO SYSTEM(1017) OPEN 'TARGETFILE' TO TFT ELSE STOP ;* open the uv dyn file of jpg recs OPEN 'MYDIR' TO MYDIR ELSE STOP ;* open a type 19 file READ JPGREC FROM TFT,'1234.JPG' ELSE STOP OUTREC = ICONV(JPGREC,"MX0C") WRITE OUTREC TO MYDIR,'1234.JPG' END This works! So either solution will work. Harold Oaks Sr. Analyst/Programmer Clark County, WA -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig Bennett Sent: Tuesday, August 21, 2007 5:22 PM To: [email protected] Subject: Re: [U2] Binary data corruption on copy Hi Harold, if I were doing this on UV I would do the following (inelegant error handling but its just an example :): If 1234.jpg is in a UV type 19 file: OPEN "SOURCEFILE" TO SFT ELSE STOP ASSIGN 1 TO SYSTEM(1017) ;* UV Specific - disables conversion of CRLF to @AM on reading which damages your binary data READ JPG FROM SFT, "1234.jpg" ELSE STOP OPEN "TARGETFILE" TO TFT ELSE STOP * Choose one of the following options to encode your data before storing * 1: Hex Conversion - exactly doubles the size of the file TDAT = OCONV(JPG, "MX0C") * 2: Base64 conversion - slower but more space (33% size increase). ERRCDE = ENCODE("Base64", 1, JPG, 1, TDAT, 1) WRITE TDAT ON TFT ELSE STOP hth, Craig Oaks, Harold wrote: > Dave- > > Of course, unidata may be different than universe in its file structure. > However, I would like to try what you do. > How do you do that hex conversion? What is the next step? For > example, I have 1234.jpg at unix level. What specifically do you do > to get that into your unidata file? > > Harold > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Dave Davis > Sent: Tuesday, August 21, 2007 10:59 AM > To: [email protected] > Subject: RE: [U2] Binary data corruption on copy > > That "$" trick is probably specific to pi/open. > > I normally convert this kind of file to hex before storing in unidata. > > If there's a better way, I would like to know about it. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Oaks, Harold > Sent: Tuesday, August 21, 2007 1:10 PM > To: [email protected] > Subject: [U2] Binary data corruption on copy > > A question for the group: > > I have JPG format records which I wish to copy from unix level into a > Universe file but am having trouble with it getting 'corrupted' during > the copy. We are converting from pi/open to universe. > > I can do this business in pi/open by changing the name of the source > file, prepending it with a $, then copying at TCL level into the > pi/open file. For example, if the record at unix level is named > 1234.jpg and is in the directory SOURCE I run this command at unix level: > mv 1234.jpg \$1234.jpg > which changes the name. Now at TCL level in pi/open I can issue the > command COPY FROM SOURCE TO IMAGE_FILE $1234.jpg After that, I can > change the name back within the pi/open file: > CNAME IMAGE_FILE $1234.jpg 1234.jpg > and the copy is complete. > > Pi/open knows that if the record name starts with a dollar sign that > it is binary and should not be changed. Once the copy from a unix > directory into the pi/open dynamic file is done I can use it > successfully. > > In Universe I attempt to do the same thing. The 1234.jpg name is > changed to $1234.jpg and then copied into the Universe file > UNIV_IMAGE_FILE, a dynamic (type 30) file. > But it doesn't work very well - the image is corrupted, the binary > file was messed with during the copy. > > I know the jpg record is intact before I start the copying. I > wouldn't need to bother with a copy to a Universe file, in fact, > except that we have over 130,000 images now and I can't believe a unix > directory could successfully handle that many records. > > Any suggestions on copying so that the binary remains intact? > > Thanks- > Harold > > > Harold D. Oaks > Sr. Analyst/Programmer > Office of the Budget and Information Systems Clark County, Washington > ph: (360) 397-6121 x4132 > fax: (360) 397-2342 > ------- > u2-users mailing list > [email protected] > To unsubscribe please visit http://listserver.u2ug.org/ > ------- > u2-users mailing list > [email protected] > To unsubscribe please visit http://listserver.u2ug.org/ > ------- > u2-users mailing list > [email protected] > To unsubscribe please visit http://listserver.u2ug.org/ > > -- Craig Bennett Director Amajuba Pty Ltd Phone: 02 9987 0161 Mobile: 0412448781 Fax: 02 8456 5943 ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
