Suggest to him (or her), that if there is an error in the compression and/or decompression code, it's their posterior that is in the frying pan. If there's an error in the vendor's code, their posterior is not in harm's way. (hopefully said error does not render your compressed data irretrievable)
Convince the programmer to put the responsibility for support and maintenance of the compression/decompression tools on the vendor and not themselves. Charles (Chuck) Hardee Senior Systems Engineer/Database Administration EAS Information Technology Thermo Fisher Scientific 300 Industry Drive | Pittsburgh, PA 15275 Phone +1 (724) 517-2633 | Mobile +1 (412) 877-2809 | FAX: +1 (412) 490-9230 [email protected] | www.thermofisher.com WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of this e-mail or the information herein by anyone other than the intended recipient, or an employee or agent of a system responsible for delivering the message to the intended recipient, is prohibited. If you are not the intended recipient, please inform the sender and delete all copies. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of John McKown Sent: Thursday, December 15, 2016 10:25 AM To: [email protected] Subject: how to: convince programmer something else is better. I'm having a bit of a problem convincing a COBOL programmer to "not do" something because, IMO, there is a better way. However, it almost seems like he is not hearing me. Some background. We have an in-house written RLE blank compression routine which we use for some selected data sets. These data sets are known to have large sequences of blanks in the records. We have used this program for over 25 years (it was here when I came here). So this predates SMS compression by a couple of decades. It was also used because, back in that day, VSAM KSDS data sets were limited to 2 GiB. Oh, the program is written in HLASM. Well, we are getting off of z/OS to Wintel. Regardless of cost and time. "So let it be written. So let it be done!" As part of this, we will need to uncompress the data and transfer it to Windows. There are no problems with that (other than screams from the SAN people about the size of the resultant files). Part of this is using MicroFocus COBOL to do some of the work (i..e port the COBOL programs to Windows). The aforementioned programmer wants a COBOL version of the HLASM compression and decompression routines. In fact, he has written the decompression routine. He wants me to write a COBOL version of the compression routine. Which I am working on. This is being done "just in case" they are needed (i.e. the SAN people scream long & hard enough about space issues). However, MicroFocus supplies 3 different compression routines which can be called from COBOL. What I'm trying to convince the programmer to do is write the Wintel COBOL versions of the compression routines to take the same parameters as they have historically, but to call the MIcroFocus routines within them to do the actual compression and decompression. But, again, it is like he is just not hearing me. Do any of the COBOL programmers out there have any idea how I can phrase this information so that it makes better sense to him? I.e. convince him that using the vendor compression routines, via a compatible interface routine, is the way to go? -- Heisenberg may have been here. http://xkcd.com/1770/ Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
