Re: RACF permission to INETD OTELNET port?
Check the PROFILE.TCPIP data set. PORT statements in there reserve ports
to specific job names. Anything else trying to use that port will be
rejected.
On 6/17/24 1:30 PM, Tom Brennan wrote:
Well that destroys my theory that the problem was caused by a non-root
id :) Like you say, there must be something else involved. Sounds
like you're making progress though.
Just curious, what made you choose port 323?
On 6/17/2024 9:26 AM, Binyamin Dissen wrote:
Changed it to 323 and it works.
I cannot figure out which BPX* resource would control this (23) and how.
On Mon, 17 Jun 2024 06:01:03 -0700 Tom Brennan
wrote:
:>I'm not sure if Attila was saying to try this, but if you can
change the
:>port to something higher than 1024 and the bind works, that would
:>indicate you're not really root at the time of the bind. Then if the
:>userid starting the task is root, maybe somebody is doing a
setuid() or
:>similar before the bind.
:>
:>On 6/17/2024 1:26 AM, Attila Fogarasi wrote:
:>> Is INETD configured correctly? Your config is in
etc/inetd/conf*. *TELNET
:>> is delivered specifying an ID of OMVSKERN and must be defined
with both
:>> superuser and daemon authority. Guessing you are using OMVSKERN
based on
:>> uid(0). Your port 722 is presumably defined in the /etc/services
file
:>>
:>> On Mon, Jun 17, 2024 at 6:10?PM Attila Fogarasi
wrote:
:>>
:>>> Brave man running uid(0) for other than the OMVS kernel ...
usually uid(0)
:>>> does give superuser authority, but you may need to be in
group(SYS1) and
:>>> have a GID. Another possibility is having root as HOME('/').
good luck,
:>>> its frustrating that simply things like getting a reason code for
:>>> "permission denied" is not so easy.
:>>>
:>>> On Mon, Jun 17, 2024 at 5:19?PM Binyamin Dissen <
:>>> 0662573e2c3a-dmarc-requ...@listserv.ua.edu> wrote:
:>>>
: Took a dump of the address space, and the associated userid has
UID(0)
:
: What else would be required for root access?
:
: On Mon, 17 Jun 2024 06:29:01 +1000 Attila Fogarasi
: <05b6fee9abb7-dmarc-requ...@listserv.ua.edu> wrote:
:
: :>port 722 is a privileged port, usually means your program
needs root
: :>access, all of that is configured outside of RACF.
: :>
: :>On Mon, Jun 17, 2024 at 6:16?AM Binyamin Dissen <
: :>0662573e2c3a-dmarc-requ...@listserv.ua.edu> wrote:
: :>
: :>> On Sun, 16 Jun 2024 09:47:20 -0500 Walt Farrell
: :>> <05bd6dbb44aa-dmarc-requ...@listserv.ua.edu> wrote:
: :>>
: :>> :>On Sun, 16 Jun 2024 17:20:34 +0300, Binyamin Dissen <
: :>> bdis...@dissensoftware.com> wrote:
: :>>
: :>> :>>Getting
: :>>
: :>> :>>BPXF024I (TCPIP) Jun 16 06:38:15 inetd 65583 : FOMN0091
: *:otelnet/tcp:
: :>> :>>722 bind: EDC5111I Permission denied., rsn=744C7246
: :>>
: :>> :>>Not sure where it got 722 - looked in all the /etc places.
: :>>
: :>> :>>Also, what permission would be required to all;ow access
to 722?
: Don't
: :>> seer
: :>> :>>anything obvious.
: :>>
: :>> :>What evidence do you have that it's a RACF issue?
: :>>
: :>> I am guessing from "permission denied"
:
: --
: Binyamin Dissen
: http://www.dissensoftware.com
:
: Director, Dissen Software, Bar & Grill - Israel
:
:
--
: For IBM-MAIN subscribe / signoff / archive access instructions,
: send email to lists...@listserv.ua.edu with the message: INFO
IBM-MAIN
:
:>>>
:>>
:>>
--
:>> For IBM-MAIN subscribe / signoff / archive access instructions,
:>> send email to lists...@listserv.ua.edu with the message: INFO
IBM-MAIN
:>>
:>>
:>
:>--
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
Binyamin Dissen
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Kinda fun
Products from UCC (at least, UCC7 and UCC11) came in source form with line numbers. Fixes came in IEBUPDTE form to insert lines by line number. When a new release came out, they would tell you which programs were renumbered so you would know which local mods you had to rework. In 1984, we were in the MVS/XA Early Support Program. I worked with the lead UCC7 programmer on changes that were needed. He then took what he learned back to the UCC11 developers and they sent someone out one weekend to implement the changes they had developed. We were going to make the changes and do the test on a Sunday afternoon when we had test time for XA. The person brought punch cards with the updates. By that time, we did not have card readers. Also, the cards only had the punches - no text across the top. We spent a couple hours finding something we could use to dial into the UCC system and get access to the code, which we could then type into our system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: The Story of Mainframe Passwords
I was into social engineering before it was cool . As I remember it, it let you enter 20 commands (and executed them) before it did this. On 5/12/2022 2:18 PM, Tom Brennan wrote: Wow, clear text. But all that doesn't matter if a fellow sysprog modifies my logon clist to put up messages something like this: ACF01234 ID HAS BEEN OFFLINE FOR TOO LONG PLEASE LOGON AGAIN ACF01235 ACF2, ENTER USERID: ACF01236 ACF2, ENTER PASSWORD: ... and then SEND the password to the fellow sysprog. Yes, that happened to me as a joke for the new guy. When entering the password I did notice the text appeared on the screen, which was odd. But I stupidly hit Enter anyway :) This did open my eyes to how easy it is to obtain someone's logon information. On 5/12/2022 6:00 AM, Lennie Dymoke-Bradshaw wrote: Maybe include how the TSO password used to be stored (in clear of course) in the TSB control block in days past. Lennie Dymoke-Bradshaw https://rsclweb.com 'Dance like no one is watching. Encrypt like everyone is.' -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: 11 May 2022 23:02 To: IBM-MAIN@LISTSERV.UA.EDU Subject: The Story of Mainframe Passwords Reg Harbeck (a name many of you should recognize) and I are putting together a presentation on the above subject. We would appreciate any material that anyone thought could be included. (I guess I should get all lawyerly here and say if you send it to us you grant us permission to use it.) Note that we specifically avoided calling it the HISTORY of mainframe passwords. We are aiming at casting a much wider net than a bunch of "and then mixed case came along in 20__." The presentation is intended to be fun, not a password tutorial. If you wanted to write me off this list it's charlesm at mcn dot org. Thanks! Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CBU HMC activation - switching back
That happened to us once (person replied that it was a real DR instead of a test). We contacted IBM right away and they fixed the CBU settings and didn't charge us. On 12/4/2021 6:41 AM, Jake Anderson wrote: Hello Is it possible to swtich back to temporary CBU activation incase it someone has activated the CBU permanently by mistake ? Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I tend to skip over the subject of emails
I found that not only is the subject often ignored, I can't ask for more than one piece of information in an email. I will only get the answer to the first question. And if I respond to a question with additional information in anticipation of the next question, I will always get asked what I just answered anyway. On 11/4/2021 3:53 PM, Tom Brennan wrote: I tend to skip over the subject of emails. I don't know why. I do the same when reading section headings in manuals - some kind of psycho thing I guess. So for others who might have the same problem, I sometimes put the same text as the subject in the first part of the email body. On 11/4/2021 10:33 AM, Carmen Vitullo wrote: I already apologized,literally, yeah, sorry Ed, that's your subject of the post :( thanks Bob ! nevermind : working 2 PC's at home back and forth, I neglected to comprehend fully the need. again - SORRY Carmen On 11/4/2021 10:07 AM, Ed Jaffe wrote: On 11/4/2021 8:01 AM, Richards, Robert B. (CTR) wrote: Ed wants a programmatic way of doing it, not logging on to a system and issuing ISMF commands from within the dialog. I literally put that fundamental requirement in the subject line of my post. For some reason, my query has been totally misunderstood by the majority of respondents. I'm baffled by it... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: even an old mainframer can do it
Back then, we had a 2-processor machine. It had to support multiple CICS test regions along with the TSO users and batch. Online compiles were not allowed because TSO was for short-running transactions with plenty of think time. Tieing up your (possibly shared) terminal (and not doing anything else while it ran) was a huge waste of precious resources (machine and human). It was more cost-effective to do good desk checking and compile in batch. With much cheaper (relatively) machines, letting the computer do the debugging is the better choice now. On 8/18/2021 12:17 PM, Tom Brennan wrote: Me too, but in the early 1980's. I'd run the assembler from TSO READY so I wouldn't have to wait for an initiator. My way of programming was always like starting with a ball of clay generally like what I wanted, then adding the details as I went along. That method means lots and lots of compiles. Then one day my supervisor dropped by my desk with a blue-bar listing titled, "Top 10 TSO CPU Users" and I think I was on the top. Oops. On 8/17/2021 11:35 PM, Mike Schwab wrote: Well, in the early 1990s, my system had 1-2 hour delays on compiles. So while waiting, I wrote a clist to do the same thing. Allocate, error handling, and deallocate of a single file took about 30 lines, and a few iterations of debugging. So, once I had one file allocate, I went through all the files, executed the program, and deallocated, and proceeded with the next two steps. Got it working and would go get a new cup of coffee while it ran instead of having to wait. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XMITIP and ANTI SPOOF message
This discussion started out talking about XMITIP, which means running on z/OS and using CSSMTP (or the older SMTP server). There is no user authentication with the server. If you know how to create the headers and how to get output to CSSMTP, you can create a sequential file and use IEBGENER to write it to spool. You can put any mail-from ID you want in it. One of our systems programmers sent a note to all of I.T. showing people how to do this. Fortunately, this was very early and no one was wanting to do it yet, so it was mostly ignored. On 2/18/2021 4:45 PM, Tom Brennan wrote: On 2/18/2021 2:20 PM, Jeremy Nicoll wrote: It depends surely on the mail host? If I've done an authenticated login to a reputable mail provider, surely they'll make sure that what they send out will accurately reflect who I am, not who my email client claims? I think that's correct - it depends. I switched ISP's 2 weeks ago (bad Spectrum cable to great Frontier fiber service *finally* in my neighborhood) and had to rework that relay processing a bit. The old ISP required specific FROM addresses. The new outgoing email server (Godaddy) does not seem to check or change those addresses. It does require a paid account with userid and password, and with that I assume they can trace mail back to me if I decide to change careers and get into the spam business :) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: setting up CSSMTP to use TLS-SSL
I think the most common approach is to have CSSMTP send the mail to an enterprise (internal) mail server and let it take care of security going out to the internet. On 8/31/20 11:33 PM, Brian Westerman wrote: So does this all mean that (currently) no one on the list uses TLS-SSL to forward their mail from CSSMTP to the target mail server? Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Allocating GDG(+1) using SVC 99
The same happened when CA bought Uccel. All of the UCCnn messages became CA-nn. On 6/21/20 12:41 PM, Tom Brennan wrote: Side note: I had to chuckle when I first saw "NDM" replaced in all the messages and screens with "C:D". Hey, a 3 character replace and we're done without having to worry about strings getting longer or shorter :) On 6/21/2020 10:24 AM, Steve Thompson wrote: Managed File Transfer. NDM, is one (aka Connect:Direct). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Quote style
Tom would sometimes send long notes, and occasionally put something in the middle to see if anyone actually read it. I would usually be the first (or only) person to respond to whatever he stuck there. So Tom: the recent "Where's Waldo?" pictures I have seen have him standing pretty much by himself, with anyone else socially distanced from him. And quit looking at ibm-main on weekends. On 6/13/20 1:05 PM, Tom Brennan wrote: On 6/13/2020 10:57 AM, Pew, Curtis G wrote: On Jun 13, 2020, at 12:46 PM, Bob Bridges wrote: Wait - is bottom-posting a thing? I've always assumed that bottom-posters are just careless; they read down to a certain point, and then type in their responses without thinking about where. Are you saying that some people post at the bottom ON PURPOSE?! But it gets to be a mess after just a few posts, unless people take the time to do some weeding, like you did with the bottom section. Most people don't take that time. Yes! Why, for heaven's sake? You quote just the part you’re responding to, and then give your response. That way it’s unambiguous just what your response refers to. There’s no need to try scrolling through a long thread to figure out what set off the email. I'll just type something here and see if anyone can find it. Where's Waldo? Isn't it Saturday? Why am I looking at ibm-main? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MQ question
The messages will be in an XMIT queue (which is a local queue). The name will probably be the name of the remote server. If not, check the remote queue definition. It will have the name of the XMIT queue. That is what you want to clear. On 4/14/20 4:20 PM, Pommier, Rex wrote: Hi all, First apologies if this isn't the right forum to ask this question. MQ is not my native language (or second or third for that matter). Here's my situation. We have a CICS region writing messages to a remote queue. Unfortunately sometime in the past, the server that was handling this queue vanished from our landscape. Now I have a full pageset dataset. Is there a way using CSQUTIL or some other MQ utility to delete the records sitting on this queue without deleting and redefining the pageset? I've been meandering through the MQ reference but since this thing weighs in at well over 5000 pages, I haven't found success. I thought I had it with the EMPTY command, but that only works on local queues. TIA, Rex The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Console access to an LPAR
Skip, check the internal documentation web site. I left complete instructions on configuring the ICCs. If you edit a session, be sure to check all of the fields. The dialog resets some to their defaults instead of retaining their values. On 02/14/2015 02:43 PM, J O Skip Robinson wrote: I need to emphasize that this is not an online/offline issue. Response to D M=CHP() indicates that only certain OSAC devices--online or offline--can be accessed by certain LPARs. Turns out that this association is not defined in the IODF at all but in the OSA 'Advanced Facilities' app on the HMC. Support here used to be provided by a couple of colleagues who left the company amid the shock waves from the outsourcing offensive recently celebrated in the media. We don't need any changes for now, but at least I know where to find the sweet spot. Kudos once again to IBM Main! . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Clifford McNeill Sent: Friday, February 13, 2015 5:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Console access to an LPAR Skip, It could be part of the OS definitions in HCD panels CBDPDVOS (Define Device to Operating System Configuration) and CBDPDV13 (Define Device Parameters / Features)? There you can define the device as initially offline. Or it could be part of the ICC/OSC definition that is accessed from OSA Advanced Facilities at the HMC. Assignments can be made by LPAR/MIFID and other criteria there. I use the latter, combined with IODF definitions that put all online and use CUA assignments that are the same on all LPARs. But they could easily be different. Good luck! Cliff McNeill Date: Fri, 13 Feb 2015 23:52:09 + From: jo.skip.robin...@sce.com Subject: Console access to an LPAR To: IBM-MAIN@LISTSERV.UA.EDU We have a perfectly serviceable IODF created by a long departed colleague. Consoles are hung off an OSA Console CHP. Each LPAR has access to four devices such that D M=CHP(xx) looks like this: 0 1 2 3 4 5 6 7 8 9 A B C D E F 00yy $@ $@ $@ $@ $@ $@ $@ $@ $@ $@ $@ $@ $@ $@ $@ $@ 00zz $@ $@ $@ $@ + + + + $@ $@ $@ $@ $@ $@ $@ $@ ... Every LPAR has a unique set four devices (shown with + signs) so that one OSA and one set of devices can service all LPARs unambiguously. I have combed through the IODF, probing top down, bottom up, and side to side, but I cannot find where this unique association is defined. Everything is working, but it bothers me that I don't understand because that means I can't change anything. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
