Page 1 of 1

Loading images/docs into a VSAM file

PostPosted: Mon Mar 26, 2012 1:05 pm
by Srinivasamurthy
What is the process to load images / documents (like PDF files..) into a VSAM file. Also how to copy it to another VSAM file?

Re: Loading images/docs into a VSAM file

PostPosted: Mon Mar 26, 2012 1:50 pm
by enrico-sorichetti
the question as posed makes little sense, too generic...

You can load/insert things according to the VSAM logic

build a record containing whatever You want and WRITE/INSERT/UPDATE the <thing>

and do not complain, please, You got what You asked for

Re: Loading images/docs into a VSAM file

PostPosted: Mon Mar 26, 2012 2:20 pm
by BillyBoyo
Any type of file is just data, 256 combinations per byte.

As long as the data fits within mainframe constraints, they can be put into a VSAM file.

If they don't currently fit, you can always make it so...

Don't expect to be able to double-click and read it from a batch program :-)

Re: Loading images/docs into a VSAM file

PostPosted: Mon Mar 26, 2012 4:36 pm
by Srinivasamurthy
To elaborate the question further, is it possible to load the images / pdf files to a VSAM file thru a COBOL program, just like loading regular data (text and hexadecimal values) to a VSAM file. If YES, how to read images, pdf files thru the COBOL program. Any sample files and sample programs to read / write images / pdf files into VSAM files are available to view?

Re: Loading images/docs into a VSAM file

PostPosted: Mon Mar 26, 2012 4:44 pm
by Robert Sample
To elaborate the question further, is it possible to load the images / pdf files to a VSAM file thru a COBOL program
Yes, of course -- data is data is data is data. Note, however, that PDF files are frequently larger (much larger) than the typical 32760-byte record length limit of the mainframe, so your program will have to work out a way to split the PDF file into some number of records.
how to read images, pdf files thru the COBOL program
With a READ statement in COBOL -- just like any other data. PDF file data is nothing but data to COBOL.
read / write images / pdf files into VSAM files are available to view?
THAT's not going to happen -- a PDF file can be handled as an image on the mainframe through Unix System Services (I use them on my internal HTML pages at my site), but as far as I know there is no PDF viewer available for COBOL on z/OS. And since you would need a graphics device -- not the 3270 emulator software usually used to connect to the mainframe -- to even view the PDF file, there would be many, many, MANY issues in even attempting to view a PDF with a mainframe program.

Re: Loading images/docs into a VSAM file

PostPosted: Mon Mar 26, 2012 6:16 pm
by Srinivasamurthy
Ok. I understand that it may not be possible to view the VSAM file (containing images / pdf file) in mainframe Z/OS. But is it possible to transmit / extract that VSAM file to UNIX or a different system thru FTP/NDM and view the file in the destination system. If yes, is there any sample code to transmit /extract this VsAM file to a different system?

Re: Loading images/docs into a VSAM file

PostPosted: Mon Mar 26, 2012 6:59 pm
by Robert Sample
Write a program to chop up the PDF into record-sized blocks of data and place in the VSAM file.

Write another program to read the VSAM file and rebuild the original PDF in a Unix System Services file. Your PC browser can then view the image on Unix System Services (assuming the HTTP server, or any equivalent from another software vendor, is running and has a specification for a PDF file).

Neither of these programs would be particularly hard to write in C (for example). I sincerely doubt you would find any examples since you're asking about a VERY hgihly specialized need -- but on the other hand, I've been surprised by what is available in the past.

Re: Loading images/docs into a VSAM file

PostPosted: Tue Mar 27, 2012 1:35 am
by enrico-sorichetti
what is that is not clear?

vsam DOES not care about the content of the record, they are just sequences of bits.
the same for FTP/NDM they are just truckers who carry boxes without caring for the content.
it' s somebody' s else task to interpret those bits according to some <whatever> logic. AMEN