Thank you, yes, very helpful! I think I've found what I was looking for in this ABCs Redbook. https://www.redbooks.ibm.com/redbooks/pdfs/sg246988.pdf
I needed to do about 3 things together in the correct order to get what I wanted, which was really a trace and dump together. * Turn on TRACE CT for SYSTCPIP and SYSTCPDA * V TCIPIP,TCPIP,PKT,ON * TRACE CT for SYSOMVS * Start DUMP COMM=() * Recreate problem * Reply to DUMP R xx,END * Dump should happen * Turn everything off I suppose replacing DUMP with a SLIP would do about the same thing, just SLIP seems to be quite a bit more precise. //lindy ________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Peter Relson <[email protected]> Sent: Friday, August 23, 2024 5:31 AM To: [email protected] <[email protected]> Subject: Re: Debugging syscall / SLIP for reason code EXTERNAL If entered exactly as shown in the original post (the SLIP command and then the response to the WTOR), that response would have failed and not set a SLIP trap. As eagle eye Adam spotted, the blank after the address in DATA ends the input data, requiring the WTOR response to start with the (missing) close-paren. But the WTOR response shown did not. This is not my area at all, but this reason code is produced in module BPXVSSOC. Nominally it has something to do with not finding a suitable Socket GFS and suitable VFS for that GFS (matching the input domain). I don't happen to know anything about either of those. Once it did not find a suitable VFS, you could get 112B0000. This was not just "reason" 112B0000, it was errno 45A and errnojr 112B0000, for what that's worth. You can find some info about that case on IBM Docs within the diagnosis reference (search for 45A and/or 112B0000) which gets you here: https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect.checkpoint.com%2Fv2%2F___https%3A%2F%2Fwww.ibm.com%2Fdocs%2Fen%2Fzos%2F3.1.0%3Ftopic%3Dlocation-ipv6-format-address-issues-errno45a-errnojr112b0000___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86ZGU1ZmMzZjRhOTMwM2RkYmMyY2YyYzZkMmViYTk5MTY6Njo5ZDFlOjdlYjI0MTc0NmZlMTVhYWM2YTdhYjFkMzY3MDcyNjExZmEwYmExZTQ3ODA1ODFlOTFhZGE0YzYzZmFmOGY0Y2I6cDpUOk4&data=05%7C02%7Clindy.mayfield%40SSF.SAS.COM%7Cb1673c1c9fb142a75d5508dcc31bc887%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C638599771308623999%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2Bc1giq5waVfs9ikHYV6tRfvCm0pym%2BjGy6RwYuse5zg%3D&reserved=0<https://protect.checkpoint.com/v2/___https://www.ibm.com/docs/en/zos/3.1.0?topic=location-ipv6-format-address-issues-errno45a-errnojr112b0000___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86ZGU1ZmMzZjRhOTMwM2RkYmMyY2YyYzZkMmViYTk5MTY6Njo5ZDFlOjdlYjI0MTc0NmZlMTVhYWM2YTdhYjFkMzY3MDcyNjExZmEwYmExZTQ3ODA1ODFlOTFhZGE0YzYzZmFmOGY0Y2I6cDpUOk4> It might not apply to your case. Was there no documentation for this syscall about this reason code to give you a clue what might have gone wrong? Getting an SVC Dump at that point within OMVS processing seems unlikely to shed much light to a user unless you can find your code and data. But if you do, this module might run in cross-memory mode, such that the caller's data is not in the current primary address space. You might need to make sure to include secondary and/or home address spaces in the dump. I don't know if that helps you or not. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- 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
