I tried something similar in PL/1, many years ago. If I remember right, I had to have two pointers, one based(addr(other_pointer)). All this to achieve R1 -> ptr -> list of TUPs for SVC 99. One of them was a pointer to a function.
It looked dirty to me, but... I showed the guy running the team, who wanted to avoid ASM, and he just said "OK you win. Do it in ASM. Try to make it reusable" :-) Roops On Fri., Mar. 19, 2021, 15:18 Farley, Peter x23353, < [email protected]> wrote: > 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 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
