I'm creating an invoice file on the mainframe that the user wants to receive as a PDF via e-mail. I need to come up with a way to do this in an automated fashion.
My Product Information:
Acrobat Standard 8.1.2, Windows
I am going to assume an IBM MVS (e.g. z/OS) environment. I do know there are other mainframes out there (or were), but this seems to be the last one standing.
Two major areas to investigate are: 1) How the file is being stored on the MF - not just file disposition and organization, but also how the data is internally handled. 2) How to get the file out of MVS land and into an area you can actually send it out.
File Types...
Binary - You need to make sure that the PDF being created, when downloaded, is still a PDF. In other words, it can be saved to a SEQ data set, but don't run any jobs on it (other than maybe an IEBGENER copy job) that will treat it as a record oriented data. Be wary of your file dispostion (FB, FBA, VB, VBA, etc.) and your LRECL. Both sides must always match. Do not use VSAM or ISAM to store them. On the MF you are only ever to do a linear read. Anything else will just cause headaches.
ASCII - While there are a couple of individuals that will insist that PDF is only a binary format, that wasn't alwasy the case. There is an ASCII varient from way back when. A number of MF libraries still output in this manner. The main drawback is that none of the contents can be compressed and it cannot support (or is difficult to support) encryption. Handle this the same as binary.
I hope this isn't the case... EBCDIC - Kind of like ASCII, other than the data is saved using native EBCDIC character encoding. Be sure to use the correct EBCDIC <<-->> ASCII code page to do the translation when getting it off the mainframe. Be wary of the translation. The standard a-Z, A-Z, 0-9 characters won't cause a problem. It will be weird ones like {} and [].Take a good, hard, look at the PDFs being created by your system? Is any post creation manipulation needed? Is it one PDF per statement or one PDF per job? If the latter, how is that PDF constructed? Is it truly a single PDF of all the statements (you will need a page extraction tool) or are they really individual PDFs concatenated into a single file (PDF splitting tool)? You may need to get/write some tools to take care of these issues.
Hopefully you are not writing a single file per statement or initiating a single job per statement. In the case of the former, you have a scalability issue that you will run into. Only so many members you can write to in a library. In the case of the latter, you are burning MIPS needlessly and all your other users will come after you with torches and pitchforks as you flood all the JES initiators. I speak from experience on this (the burns and puncture wounds are starting to heal).
Getting it from here to there... Directly from JES there is sendmail that can be called from your JCL. Try it, if it works fine for you. There may be some file translation flags you need to specify (see file types above).
Copy it to another LPAR that can easily handle sending it out. For example USSHFS (Unix System Services Heirarchical File System). By copying the PDF to a USSHFS partition you can also mount that partition as an NFS from another UNIX/Linux environment and have that system send the file out. Again, you do have to worry about translation.
Use a transaction handler such as an MQSeries pipe. Very nice!
FTP - Send it directly from your environment to your customers. It does require that a VPN or some other tigh-coupling of the network be put in place. This also works to get it to another environment, just in case the USSHFS option isn't available.
Other than using sendmail directly off the MF, all the other options will also require that you write out a control file that indicates which file to send and where to send it to. This can also be handled by using XML wrapper around the PDF. Really nice in the case of MQSeries. You will also need some sort of scheduled service on the target environment that can pick up the control file, parse it and use that info to find the PDF and send it out.
Be wary of ASA carriage control (skip perf on channel 1) being generated in the outouput. The PDF spec doesn't like this all that much.
Testing - A good test is once you have the PDF off the MF and onto your desktop, open it. Then close it (do nothing else in between). If Acrobat (not Reader) asks you to save it, something is wrong with how the file was brought down. This must be corrected. The save indicates that Acrobat performed a automatic repair on the file when it was opened. This will bite you in production. Correct now before your customers find out.
Take a look at what is being created. Do a full inventory of what tools you have available to get you from here to there. The minimal number of hops, while desireable, may not be the best. You want this handled through the most solid, reliable, channel you have. Not just the fastest.
While I don't subscribe to eveything Stephen Covey says, in this case 'Begin with the end in mind.' should shine a light on the solution.
Lastly, I have seen some truly Rube Goldberg processing systems built in JCL that, when investigated deeper, were actually elegant works of art.
Keep up the good fight! A lot of Millenials poo poo the mainframe. I've yet to see one of them come up with something better at what it does. The MF was never designed for fancy, schmancy graphics, web or other such items. It was designed to make money. And it does that very, very well.
I hope this helps - While not a lot of specifics, I don't have many on your environment. This info should get you started. I am available for follow-up questions.
Thanks.
Douglas Hanna is a member of the Production Print Technology team at Aon.
www.aonhewitt.com
I am going to assume an IBM MVS (e.g. z/OS) environment. I do know there are other mainframes out there (or were), but this seems to be the last one standing.
Two major areas to investigate are:
1) How the file is being stored on the MF - not just file disposition and organization, but also how the data is internally handled.
2) How to get the file out of MVS land and into an area you can actually send it out.
File Types...
Binary - You need to make sure that the PDF being created, when downloaded, is still a PDF. In other words, it can be saved to a SEQ data set, but don't run any jobs on it (other than maybe an IEBGENER copy job) that will treat it as a record oriented data. Be wary of your file dispostion (FB, FBA, VB, VBA, etc.) and your LRECL. Both sides must always match. Do not use VSAM or ISAM to store them. On the MF you are only ever to do a linear read. Anything else will just cause headaches.
ASCII - While there are a couple of individuals that will insist that PDF is only a binary format, that wasn't alwasy the case. There is an ASCII varient from way back when. A number of MF libraries still output in this manner. The main drawback is that none of the contents can be compressed and it cannot support (or is difficult to support) encryption. Handle this the same as binary.
I hope this isn't the case...
EBCDIC - Kind of like ASCII, other than the data is saved using native EBCDIC character encoding. Be sure to use the correct EBCDIC <<-->> ASCII code page to do the translation when getting it off the mainframe. Be wary of the translation. The standard a-Z, A-Z, 0-9 characters won't cause a problem. It will be weird ones like {} and [].Take a good, hard, look at the PDFs being created by your system? Is any post creation manipulation needed? Is it one PDF per statement or one PDF per job? If the latter, how is that PDF constructed? Is it truly a single PDF of all the statements (you will need a page extraction tool) or are they really individual PDFs concatenated into a single file (PDF splitting tool)? You may need to get/write some tools to take care of these issues.
Hopefully you are not writing a single file per statement or initiating a single job per statement. In the case of the former, you have a scalability issue that you will run into. Only so many members you can write to in a library. In the case of the latter, you are burning MIPS needlessly and all your other users will come after you with torches and pitchforks as you flood all the JES initiators. I speak from experience on this (the burns and puncture wounds are starting to heal).
Getting it from here to there...
Directly from JES there is sendmail that can be called from your JCL. Try it, if it works fine for you. There may be some file translation flags you need to specify (see file types above).
Copy it to another LPAR that can easily handle sending it out. For example USSHFS (Unix System Services Heirarchical File System). By copying the PDF to a USSHFS partition you can also mount that partition as an NFS from another UNIX/Linux environment and have that system send the file out. Again, you do have to worry about translation.
Use a transaction handler such as an MQSeries pipe. Very nice!
FTP - Send it directly from your environment to your customers. It does require that a VPN or some other tigh-coupling of the network be put in place. This also works to get it to another environment, just in case the USSHFS option isn't available.
Other than using sendmail directly off the MF, all the other options will also require that you write out a control file that indicates which file to send and where to send it to. This can also be handled by using XML wrapper around the PDF. Really nice in the case of MQSeries. You will also need some sort of scheduled service on the target environment that can pick up the control file, parse it and use that info to find the PDF and send it out.
Be wary of ASA carriage control (skip perf on channel 1) being generated in the outouput. The PDF spec doesn't like this all that much.
Testing - A good test is once you have the PDF off the MF and onto your desktop, open it. Then close it (do nothing else in between). If Acrobat (not Reader) asks you to save it, something is wrong with how the file was brought down. This must be corrected. The save indicates that Acrobat performed a automatic repair on the file when it was opened. This will bite you in production. Correct now before your customers find out.
Take a look at what is being created. Do a full inventory of what tools you have available to get you from here to there. The minimal number of hops, while desireable, may not be the best. You want this handled through the most solid, reliable, channel you have. Not just the fastest.
While I don't subscribe to eveything Stephen Covey says, in this case 'Begin with the end in mind.' should shine a light on the solution.
Lastly, I have seen some truly Rube Goldberg processing systems built in JCL that, when investigated deeper, were actually elegant works of art.
Keep up the good fight! A lot of Millenials poo poo the mainframe. I've yet to see one of them come up with something better at what it does. The MF was never designed for fancy, schmancy graphics, web or other such items. It was designed to make money. And it does that very, very well.
I hope this helps - While not a lot of specifics, I don't have many on your environment. This info should get you started. I am available for follow-up questions.
Thanks.
Douglas Hanna is a member of the Production Print Technology team at Aon.
www.aonhewitt.com