Home > Archive > Cobol > April 2007 > BLOB (binary large object) file in Cobol .DAT file
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
BLOB (binary large object) file in Cobol .DAT file
|
|
| Rene_Surop 2007-04-03, 3:55 am |
| Hi,
Can Cobol possibly store a BLOB object into an Indexed File?? Say a
jpeg/gif/png file stored in a single field. I'm using MF NetExpress.
A workaround of this nature would be to store the "filename (including
the \directory)" of the jpeg/gif/png in a PIC X(255) data
identifier.... then during viewing it by retrieving the file from the
READ statement.
This time I wanted to physically (if you might call it) load the jpeg/
gif/png file into the .DAT file.
Any solution to this problem?
| |
| HeyBub 2007-04-03, 7:55 am |
| Rene_Surop wrote:
> Hi,
>
> Can Cobol possibly store a BLOB object into an Indexed File?? Say a
> jpeg/gif/png file stored in a single field. I'm using MF NetExpress.
>
> A workaround of this nature would be to store the "filename (including
> the \directory)" of the jpeg/gif/png in a PIC X(255) data
> identifier.... then during viewing it by retrieving the file from the
> READ statement.
>
> This time I wanted to physically (if you might call it) load the jpeg/
> gif/png file into the .DAT file.
>
> Any solution to this problem?
You've found a solution. Any particular reason why storing a link to the
data is inappropriate?
| |
| Clark F Morris 2007-04-03, 6:55 pm |
| On 2 Apr 2007 20:05:31 -0700, "Rene_Surop" <infodynamics_ph@yahoo.com>
wrote:
>Hi,
>
>Can Cobol possibly store a BLOB object into an Indexed File?? Say a
>jpeg/gif/png file stored in a single field. I'm using MF NetExpress.
>
>A workaround of this nature would be to store the "filename (including
>the \directory)" of the jpeg/gif/png in a PIC X(255) data
>identifier.... then during viewing it by retrieving the file from the
>READ statement.
>
>This time I wanted to physically (if you might call it) load the jpeg/
>gif/png file into the .DAT file.
>
>Any solution to this problem?
Some of the PC COBOL's might be able to. It may depend on the size
limitation for PIC X(n) fields and 01 levels. Check the manual and
the Microfocus web site. Note that you will probably need Flash
unless the %^$&s have gotten smart.
| |
|
| In article <1314gqqooinhc3c@news.supernews.com>,
HeyBub <heybubNOSPAM@gmail.com> wrote:
>Rene_Surop wrote:
[snip]
>
>You've found a solution. Any particular reason why storing a link to the
>data is inappropriate?
Off the top of my pointy little head... it might make transmitting data a
bit easier.
DD
| |
| Kellie Fitton 2007-04-03, 6:55 pm |
| On Apr 2, 8:05 pm, "Rene_Surop" <infodynamics...@yahoo.com> wrote:
> Hi,
>
> Can Cobol possibly store a BLOB object into an Indexed File?? Say a
> jpeg/gif/png file stored in a single field. I'm using MF NetExpress.
>
> A workaround of this nature would be to store the "filename (including
> the \directory)" of the jpeg/gif/png in a PIC X(255) data
> identifier.... then during viewing it by retrieving the file from the
> READ statement.
>
> This time I wanted to physically (if you might call it) load the jpeg/
> gif/png file into the .DAT file.
>
> Any solution to this problem?
Hi,
You can use the following APIs to combine several resource files into
a single executable object program, one advantage this has over a
separate
data/configuration file is that it'll never get lost.
// Include the files...
CreateFile() using GENERIC_READ,
0,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL);
GetFileSize(hFile, NULL);
ReadFile()
CloseHandle()
// Update the resource data...
BeginUpdateResource()
UpdateResource()
EndUpdateResource()
// Extract the data...
LoadLibraryEx()
FindResource()
LoadResource()
LockResource()
FreeLibrary()
// Save the data into a file...
SizeofResource()
CreateFile() using GENERIC_WRITE,
0,
NULL,
CREATE_ALWAYS,
FILE_ATTRIBUTE_NORMAL,
NULL);
WriteFile()
CloseHandle()
http://msdn2.microsoft.com/en-us/library/aa363858.aspx
http://msdn2.microsoft.com/en-us/library/aa364955.aspx
http://msdn2.microsoft.com/en-us/library/aa365467.aspx
http://msdn.microsoft.com/library/d...ateresource.asp
http://msdn.microsoft.com/library/d...ateresource.asp
http://msdn.microsoft.com/library/d...ateresource.asp
http://msdn.microsoft.com/library/d...adlibraryex.asp
http://msdn.microsoft.com/library/d...indresource.asp
http://msdn.microsoft.com/library/d...oadresource.asp
http://msdn.microsoft.com/library/d...ockresource.asp
http://msdn.microsoft.com/library/d...freelibrary.asp
http://msdn.microsoft.com/library/d...eofresource.asp
http://msdn.microsoft.com/library/d...s/writefile.asp
http://msdn.microsoft.com/library/d...closehandle.asp
Kellie.
| |
| Rick Smith 2007-04-03, 6:55 pm |
|
"Rene_Surop" <infodynamics_ph@yahoo.com> wrote in message
news:1175569531.501497.113700@y66g2000hsf.googlegroups.com...
> Hi,
>
> Can Cobol possibly store a BLOB object into an Indexed File?? Say a
> jpeg/gif/png file stored in a single field. I'm using MF NetExpress.
>
> A workaround of this nature would be to store the "filename (including
> the \directory)" of the jpeg/gif/png in a PIC X(255) data
> identifier.... then during viewing it by retrieving the file from the
> READ statement.
>
> This time I wanted to physically (if you might call it) load the jpeg/
> gif/png file into the .DAT file.
>
> Any solution to this problem?
Yes, but it depends on the maximum size of the image.
I did some testing and found that I could store about
60K in one record. If the image is larger than that, it
may still be stored, but requires multiple segments.
This program used Micro Focus COBOL 3.2.24.
It is able to store images of up to 6MB (change
max-image-size). I used a ".jpg" from Golf Magazine
for testing. Feel free to use what you can.
----- output is:
segments written: 04
image size: 00233612
-----
$set constant max-image-segment-size(61440)
$set constant max-image-size(1048576)
identification division.
program-id. A27B05.
environment division.
input-output section.
file-control.
select optional image-master
assign to "image.dat"
organization indexed
access dynamic
record key image-key.
select in-file
assign to "golfma~1.jpg"
organization sequential.
select out-file
assign to "golfma~2.jpg"
organization sequential.
data division.
file section.
fd image-master
record varying.
1 image-record.
2 image-key.
3 image-name pic x(20).
3 image-segment-number pic 99.
2 filler.
3 image-segment-size pic 9(8) binary.
3 image-segment-data pic x
occurs 0 to max-image-segment-size
depending on image-segment-size.
fd in-file.
1 in-record pic x.
fd out-file.
1 out-record pic x.
working-storage section.
1 work-key.
2 work-name pic x(20) value "golfma".
2 work-segment-number pic 99 value 0.
1 segment-start pic 9(8) binary value 0.
1 bytes-read pic 9(8) binary value 0.
1 bytes-written pic 9(8) binary value 0.
1 filler.
2 image-size pic 9(8) binary value 0.
2 image-data pic x value space
occurs 0 to max-image-size
depending on image-size.
procedure division.
begin.
if ((max-image-size + max-image-segment-size - 1)
/ max-image-segment-size) > 99
display "requires more than 99 segments "
& "for largest image"
stop run
end-if
* delete file image-master *> uncomment when changing
*> max-segment-image-size
*> for testing
perform file-to-image
perform image-to-master
perform master-to-image
perform image-to-file
if bytes-read = bytes-written
perform verify-file
end-if
display "segments written: " work-segment-number
display "image size: " bytes-read
stop run
| |
| Paul Robinson 2007-04-04, 6:55 pm |
| HeyBub wrote:
> Rene_Surop wrote:
>
> You've found a solution. Any particular reason why storing a link to the
> data is inappropriate?
Yeah, the data isn't in the database. This means that the program can't
access data to which a link is stored without validating the link.
This does create a problem where the database can conceivably have bad
data in it because it contains file links that may or may not be valid.
In search engines, we call that "link rot."
I think one of the prime considerations of a database is that it
shouldn't contain bad data if there is a way to avoid doing so.
| |
| Rene_Surop 2007-04-09, 9:55 pm |
| HeyBub>>> Need the file to be transported (somehow) as what "docdw"
mentioned and backup it quite easy.
Killie/Rick>>> Thanks for the info, I will definitely start from your
side. Thanks a lot.
| |
|
|
|
|
|