Re: R/W access to HMC
Yes, I can import IOCP txt from memory stick, but I want to UPLOAD the file TO memory stick from my workstation. Reason: the HMC and CPC reside in remote location. I can power-up the machine remotely, IPL, deactivate, change reset profiles, configure OSA-ICC, everything remotely EXCEPT new IOCP upload. I don't want to interconnect HMC-SE private network with my corpo-network, as it is not recommended. (Yes, I know I can upload IOCDS directly from z/OS image, but this is not the same) -- Radoslaw Skorupka Lodz, Poland W dniu 2012-12-28 20:23, retired mainframer pisze: On the HMC that came with our z10, you could import IOCP text files from a USB memory stick. It had a CD/DVD reader/writer but I don't remember if you could import from that. You could also export screen shots for inclusion in procedure or training documentation. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of R.S. :: Sent: Friday, December 28, 2012 6:15 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: R/W access to HMC :: :: Is there any supported method to access HMC media (USB stick, maybe :: other) in R/W mode? :: :: My goal is to update IOCP.txt files on the stick then read them from SE :: to build IOCDS. :: :: I mean HMC version 2.x (Linux based). :: :: In the old good OS/2 it was feasible. -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2012 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.410.984 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BPXP024I BPXAS INITIATOR STARTED ON BEHALF OF... ( was: JVMDUMP032I message)
On Sat, 29 Dec 2012 07:42:34 +0100, ibmmain nitz-...@gmx.net wrote: I have also seen this happen with IBMUSER, and the colleague doing the ftp swears that he didn't use IBMUSER for his ftp. If this was for an inbound FTP session, do you have the FTP server configured to run as IBMUSER? -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BPXP024I BPXAS INITIATOR STARTED ON BEHALF OF... ( was: JVMDUMP032I message)
It seems I have not been clear enough. Like a JESx initiator, which, in its lifetime, may serve as a container (address space) for many batch jobs, BPXAS initiators may, in their lifetime, serve as a container (i.e.address space) for many, many processes one after the other. The message BPXP042I documents only which (parent) process initiated *the creation of this very instance of a BPXAS address space* because it (the parent process) started a new (child) process (via spawn() of fork()). Thereafter, the very same instance of the BPXAS address space may be used again and again and again. Each time a process does a (non-local) spawn() of a fork(), one such BPXAS is needed. If a BPXAS is sitting around doing nothing, i.e. it is idle, this means it has been hosting one or more processes before. But currently, it is waiting for another process it can host, or, for the 30 minute idle period to expire. You will see message BPXP024I only for the *very first* process is was hosting in its lifetime. In SDSF, when you see a line saying BPXAS, this is a line showing an *idle* UNIX process initiator. This is equivalent to JESx initiators. When you see a line saying INIT, this is an idle batch job initiator. The JESx initiator changes its displayed jobname when it is serving a batch job. Equally, a BPXAS changes its displayed jobname when it is serving a UNIX process. I have seen that message citing my own (TSO) userid as jobname. And I had certainly NOT done anything at that time. I had done something in OMVS before, though (like 5 minutes earlier). Is it possible that the jobname/userid somehow somewhere gets stored and reused despite *this* parent process being someone else? I have also seen this happen with IBMUSER, and the colleague doing the ftp swears that he didn't use IBMUSER for his ftp. Let's assume you start your TSO session (your ID is BARBARA), then do something with Z/OS UNIX that starts a new UNIX *non-local* process. (There are processes that may run in the current address space, called local processes. There are processes that may *not* run in the current address space, called non-local processes.) Since this new non-local process needs an address space to run in, the system looks if it can find an *idle* BPXAS. We assume now, there was none, so a new one was started especially for you, well for your process. The system then writes message BPXP024I to document that your TSO session was the reason this BPXAS was started. (To be exact: The message documents that there is a process running in address space BARBARA that initiated this BPXAS creation. It does not say this is a TSO session.) At this time (and before the process ends), you can see 2 lines in SDSF: One called BARBARA, a TSU line, representing your TSO session, and a second one called BARBARA1, an STC line, representing your UNIX process. You won't see a line called BPXAS. Sometime later, your non-local process ends; the BPXAS becomes idle. You can again see it as BPXAS in SDSF and you can read message BPXP024I saying it was started for parent BARBARA. Let's now assume nothing else happened on the system until 5 minutes later, when your colleage FOO performs the very same steps described above. The BPXAS is still idle and the system will select it to host Foo's UNIX process. Since the BPXAS was already running, *no* BPXP024I message is written. At this time (before the process ends), you can see 2 lines in SDSF: One called FOO, a TSU line, representing Foo's TSO session, and a second one called FOO1, an STC line, representing Foo's UNIX process. You won't see a line called BPXAS. Sometime later, Foo's non-local process ends; the BPXAS becomes idle again. You can again see it as BPXAS in SDSF and you can still read message BPXP024I saying it was started for parent BARBARA. You won't see Foo's process mentioned. Why? Imagine, say, ten UNIX guys are logged into Z/OS UNIX working hardly in their shell environments for 8 hours. You can imagine that thousands and thousands of processes have been started and ended during that working day. Say, a couple of BPXAS address spaces could cope with the work but never got idle long enough (the 30 minutes period) to end. If BPXP024I was written for each and every process, there were thousands and thousands of BPCXP024I messages in those BPXASs filling your spool. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BPXP024I BPXAS INITIATOR STARTED ON BEHALF OF... ( was: JVMDUMP032I message)
I have also seen this happen with IBMUSER, and the colleague doing the ftp swears that he didn't use IBMUSER for his ftp. If this was for an inbound FTP session, do you have the FTP server configured to run as IBMUSER? The message documents the *jobname*, not the uid/userid of the parent process. If the message says IBMUSER, then there must have been some address space named IBMUSER initiating the creation of this BPXAS. Isn't IBMUSER a userid defined on precustomized z/OS systems like the ADCD systems? I bet someone was logged into TSO as IBMUSER, then did some UNIX work. Later that other colleague did an ftp and his process was hosted by the BPXAS that previously has been started on bevalf of IBMUSER. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I broke it - programcontrolled programs
Thanks for that list. Problem is, BPX.DAEMON was defined with UACC(READ) and some userids had ALTER, so explicit READ access doesn't do much. Or does it? I just stumbled over this one when reading the whole thread once more trying to find answers for Barbara. The profile should be defined with UACC(NONE), then ACC(READ) should be given to only those userids that need it, i.e. servers, not people. When access is needed, the distinction is between NONE and READ. ALTER imples READ, so it is the same. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: R/W access to HMC
I'm confused. If you want to transfer text data (in either direction) between the HMC and a memory stick, you need to mount the stick in the HMC. I never used remote access to the HMC so I don't know if the import/export functions will support a text transfer between the HMC (server) and your workstation (client). But if it does support such a transfer, why would you bother with the memory stick? A file on a memory stick on the workstation is just Q:\x.txt which is no different to the transfer protocol than one on your hard drive (C:\x.txt). I wonder if the HMC backup functions will support any destination other than the local (to the HMC) CD/DVD drive. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of R.S. :: Sent: Saturday, December 29, 2012 1:55 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: R/W access to HMC :: :: Yes, I can import IOCP txt from memory stick, but I want to UPLOAD the :: file TO memory stick from my workstation. Reason: the HMC and CPC reside :: in remote location. I can power-up the machine remotely, IPL, :: deactivate, change reset profiles, configure OSA-ICC, everything :: remotely EXCEPT new IOCP upload. I don't want to interconnect HMC-SE :: private network with my corpo-network, as it is not recommended. :: :: (Yes, I know I can upload IOCDS directly from z/OS image, but this is :: not the same) :: :: W dniu 2012-12-28 20:23, retired mainframer pisze: :: On the HMC that came with our z10, you could import IOCP text files :: from a :: USB memory stick. It had a CD/DVD reader/writer but I don't remember :: if you :: could import from that. :: :: You could also export screen shots for inclusion in procedure or :: training :: documentation. :: :: :: -Original Message- :: :: From: IBM Mainframe Discussion List [mailto:IBM- :: m...@listserv.ua.edu] On :: :: Behalf Of R.S. :: :: Sent: Friday, December 28, 2012 6:15 AM :: :: To: IBM-MAIN@LISTSERV.UA.EDU :: :: Subject: R/W access to HMC :: :: :: :: Is there any supported method to access HMC media (USB stick, :: maybe :: :: other) in R/W mode? :: :: :: :: My goal is to update IOCP.txt files on the stick then read them :: from SE :: :: to build IOCDS. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
