Re: sftp config file
In this case the private key is in RACF, but thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: sftp config file
Wow. That was it. Thank you very much! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
sftp config file
Using JCL for sftp connection to external server. Debug shows Reading configuration data /etc/ssh/ssh_config Reading configuration data /etc/ssh/zos_ssh_config I need it to read ~/.ssh/config and ~/.ssh/zos_user_config but it's not. Searching through the manuals and archives, but need guidance.According to the manual, it's supposed to look in ~/.ssh before /etc/ssh. Joel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
zOS GENCERT
In zOS, is it possible to extract a private key, making it viewable by a human, generated by the RACF RACDCERT GENCERT command? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
I actually might share that with this vendor! They still have not realized/acknowledged their error. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
Thanks all for the response. I'm glad I wasn't missing something. I will discuss further with the vendor, hoping they will recognize the risks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
vendor distributes their private key
A vendor has an ftps server for us to connect to from a batch job on zos. Similar setups with vendors have required the vendor to provide their server's public cert chain for import into RACF. This vendor insists on providing not just their server public cert chain but also their private key. First, they provided a password-protected p12 file, describing it as containing the "root, intermediate, and private certs". I requested their public certificate chain only, they sent me a DER file -- with both the server cert and its private key. I have asked them to elaborate on their need to distribute their private key to me, their response has essentially been, that's the way we do it. I'm not comfortable accepting anyone's private key. There has been no mention of "client authentication", and I'm still not sure I'd be comfortable with that config, either. Help me understand two things: 1) what I'm missing as to why any vendor would require me to install their private key on my side when installing the public cert on my side should suffice as in many other instances, and 2) arguments for/against client authentication (not password authentication, but client) in case that is why they're sending me their private key. Joel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for mainframe shops Lexington/Cincinnati
Thank you to all. Several good leads for me. I appreciate it. I'm looking hard at the Fort Knox opp, but also hoping to find something there in the Lexington area. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Looking for mainframe shops Lexington/Cincinnati
Would appreciate info on zos shops in Lexington KY and Cincinnati OH, for possible relo. What mainframe shops are there??? Thanks, Joel Columbia SC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 0C4, 071, 822 abends in IEFACTRT after zOS 2.2
I mis-spoke. At the time of my first post we had NOT moved the fresh copy of IEFACTRT from cbt109 into production. We did this past weekend and S071 abends were resolved. (You were correct, the USING R15 was absent in the old IEFACTRT.) However, the 0C4 abends stlil occur within certain address spaces with high utilization. Also on these address spaces the output gets garbled: (Also notice the comma in front of EXCP TOTAL.) * EXCP STATISTICS * * DDNAME CC# UNIT EXCP COUNT DDNAME CC# UNIT EXCP COUNT DDNAME CC# UNIT EXCP COUNT * STEPLIB 240 0 STEPLIB + 1 202 11 STEPLIB + 2 21A 0 * CDMSLIB 240 59 CDMSLIB + 1 202901 CDMSLIB + 2 21A236 * CDMSLIB + 4 803511 SYSTCPD A56 0 SYSCTL 21C 3 * PRODDD1 201 0 PRODDD2 201 0 PRODDD3 201 0 ... * TXRCD23D + 1 B4C 10,596 TXRCD11J + 1 B48 9,713 TXRCD02C + 1 B4E264 * TXGMD01B + 1 25B 1,920 TXACDS24 + 1 265 1,365 TXACDS66 + 1 247 95 * TXACDS65 + 1 7D2268 TXACDS55 + 1 249 19 TXIID27B + 1 234 32 * * EXCP TOTAL ,037,794 VIO PAGE INS 0 VIO PAGE OUTS 0 PA * * *B 3CF779,263003 0 + 5 3FF 0 *B + 1 3CF779,263 + 5 3FF 0 B T+ 1 BEB ,897,600 * + 5 3FF 0 B T+ 1 BEB ,897,600B + 1 3CF779,263 * B T+ 1 BEB ,897,600B + 1 3CF779,263 + 5 3FF 0 *B + 1 3CF779,263 + 5 3FF 0 B T+ 1 BEB ,897,600 The IBM copy of IEEACTRT gives a different output and we were trying to not impose that changed output on the customer so as not to disturb their routine. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
0C4, 071, 822 abends in IEFACTRT after zOS 2.2
After migrating to zOS 2.2, a vendor-customized IEFACTRT routine started getting 0c4, 071, and 822 abends in certain highly-used initiators. We discovered that the vendor portion was supposed to have been removed prior to 2.2 so we removed their custom module. Abends still occurred. We downloaded the latest source of IEFACTRT from CBT109, compared it to what we already had and there were very few differences. We assembled the latest source and moved it into production. Same thing. An excerpt from IBM support, in reference to the latest CBT109 IEFACTRT: "This 0C4 abend led to IEFACTRT's recovery routine being invoked. According the the SCB control block, the recovery routine is located at +x'972': +972 4140 0004 +976 1904 +978 4770 C986 <- +97C 5802 +980 41F0 0004 +984 07FE "On entry to this routine, regs R3-R12 are zeroes - so the instruction at +x'978' triggers a branch to address 0986. This address is in the PSA, and is used as a savearea by disabled routines. As a result, the contents at this address may vary - leading to unpredictable abends - including 0c1 abends and spin loops." Any other shops have issues on zOS 2.2 with CBT109 IEFACTRT? Thanks, Joel M Ivey -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
