Thanks Charles. As I indicated in one of my earlier responses, I agree with you and am taking that route. Too many chances for failure in the future.
Peter -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Charles Mills Sent: Friday, March 19, 2021 10:27 AM To: [email protected] Subject: Re: This Call-Assembler-inside-COBOL technique works, but is it risky to use? @Peter, I have given this some serious thought. Thanks for the interesting problem! I believe you should eschew the clever "assembler in working storage" approach. If the UUID4 approach works for you, then of course, by all means use it. If not, then you should go with a conventional external callable assembler routine. Here is my logic. I hear you on the assembler maintenance issues. I think the external assembler is very unlikely to fail or require maintenance, but if it does, the task is straightforward. If there is no talent at your shop that can do it, then certainly they can find a contractor to do it. There is no complex business logic embedded in the assembler. It will be a simple problem. OTOH if you go with the working storage approach, I think there is a decent likelihood of failure sometime in the future. Perhaps they change the COBOL compiler, as I suggested. Perhaps IBM changes the "executability" of working storage, as @Peter suggested. If that happens then your organization has a complex and difficult problem. If it is an exception on non-executable storage LE is likely to be totally boggled by the error. Your shop will have a complex problem that someone with knowledge of the hardware, knowledge of COBOL, and then ultimately decent assembler skills, is going to have to sort out. That is going to be tricky. Some future programmer may be cursing your memory. That is why I think you should eschew your working storage technique, as clever and as fascinating as it is, and go with either UUID4 or a conventional call to assembler. Charles -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
