Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED)
Am 09.04.2014 16:53, schrieb Gerhard Postpischil: I'd add 4) - many modern control units have diagnostic capability that allows unrestricted hardware access to the drives. If yours do, you'll need physical access controls. I first ran into this when we got our first string of Hitachi 3380s. The C.E. wanted a telephone line so he could service the units remotely; I had to educate management that that would allow uncontrolled access to customer data. True but not only related to the ERASE function. It applies to deleted as well as non-deleted data. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF START command remains on the command line
Am 09.04.2014 20:12, schrieb Duffy Nightingale, SS: I always split the screen by putting the cursor where I want the split, then press PF2. No command needed. Well actually PF2 usually has the command SPLIT assigned. So there is a command as well. SPLIT NEW would be similar to START in that it starts another (up to 8, that will increase with z/OS 21., right) split screen session. However, SPLIT NEW does not allow another parameter to directly jump to some place in the new session (IIRC). And, I don't want to bother changing numerous KEYLISTS on numerous systems from SPLIT to SPLIT NEW. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF START command remains on the command line
Am 09.04.2014 20:18, schrieb Tom Marchant: That only lets you have two splits. Not if you change SPLIT to SPLIT NEW. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 abend on old assembler program when upgrading to z/OS 1.13
Am 09.04.2014 20:59, schrieb Pommier, Rex: _9750 -8 4710 C04ABC74(,R12)BO _9754 -4 5830 0208L R3,520 _97580 D503 3000 C172 CLC 0(4,R3),370(R12) The program loads R3 from address 520 (208x) which is in the PSA. That field is documented as 520 (208) ADDRESS 4 PSAPCCAV - VIRTUAL ADDRESS OF PCCA It loosk as if the PCCA had been moved to 31bit storage in z/OS V1.13. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 abend on old assembler program when upgrading to z/OS 1.13
Just found this in the V1.13 Migration manual: *Description:* In parmlib member DIAGxx, you can specify the virtual location of the LCCA control block (mapped by the IHALCCA macro) or the location of the */_PCCA_/* control block (mapped by the IHAPCCA macro) to be used when a CPU is brought online. Before z/OS V1R12, if the IHALCCA or IHAPCCA structures specified on the CBLOC VIRTUAL24 or VIRTUAL31 keyword of DIAGxx did not specify either the 24-bit (VIRTUAL24) or 31-bit (VIRTUAL31) location, the default location for the LCCA or */_PCCA_/* was in 24-bit virtual storage. Beginning with z/OS V1R12, the default location for the LCCA and */_PCCA_/* is now in 31-bit virtual storage if you do not specify VIRTUAL24 or VIRTUAL31 for the structures IHALCCA and IHAPCCA. If only one standard processor is online during the IPL, the LCCA and */_PCCA_/* of the IPL CPU will be in 24-bit storage regardless of the specification. If there is more than one processor, and DIAGxx permits it, you'll have the LCCA and */_PCCA_/* in 31-bit storage. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: S0C4 abend on old assembler program when upgrading to z/OS 1.13
Who'd have thought that the number of CPUs online would affect the default virtual location of LCCA and PCCA? Sometime there are reall funny costructs. However there sure must be a good reason for this since code had to be written to handle it. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: need pub to help me with a REXX exec
Something I find very useful which is not widely know: you can activate interactive trace (equivalent to trace ?i) with TSO command EXECUTIL TS. Useful when you need to start debugging so where within an ISPF/REXX application. You just proceed through the panels until you are at the point your want to start tracing. There you enter TSO EXECUTIL TS and continue with the application in REXX trace mode. Enter TSO EXECUTIL TE to stop tracing again. -- Peter Hunkeler Von: Lizette Koehler stars...@mindspring.com An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: need pub to help me with a REXX exec Datum: 04.04.14 03:40 John, You may wish to join the TSO REXX list. It is full of people that just love REXX coding. Go to the bottom of this webpage to join http://vm.marist.edu/htbin/wlvindex?TSO-REXX You may also wish to check out RExx-LA http://www.rexxla.org/ Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Norgauer Sent: Thursday, April 03, 2014 3:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: need pub to help me with a REXX exec Can someone point me to a pub that explains how to debug and/or trace a REXX exec? Thanks. John Norgauer Senior Systems Programmer Mainframe Technical Support Services University of California Davis Medical Center 1651 Alhambra Blvd Suite 200 Sacramento, Ca 95816 916-734-0536 -- 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: Which fonts are being actually used?
I don't have access to VPS documentation, so I don't know if VPS offers a suitable exit. With PSF, I'd try with a Ressource Management exit (exit 7) which can ask to receive control when fonts are loaded. The exit would then write information about fonts being used to a data set which can be analyzed later. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Which fonts are being actually used?
On 03/24/2014 07:16 PM, retired mainframer wrote: I don't know VPS but on my system (AFP and PPFA) all the used fonts were specified in the various PAGEDEFs we used. That might be a place to start. You don't have documents generated by AFP renderers such as ISIS Papyrus, HP Elixier, etc? With those the fonts used are specified on the indivicual page. No PAGEDEFs are used. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
OT: How to open a new list at UA.EDU?
Does anyone know how to create a new list here at UA.EDU's listserver? I'm searching a place to host an AFP (Advanced Function Presentation) related list. There was one on Topia but it seems to be dead. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Tasks ENQ'ing exclusive on resource not getting control in FIFO order
It was my understanding that tasks enqueueing on a resource are getting control in FIFO order, if contention existed. Today, we had a situation where this was not true. Environment is as follows: - 4 system parallel sysplex, z/OS V1.13, GRS STAR mode. - a dozen or so jobs running the same program are active across all 4 systems at a time. More job being submitted as jobs end (more or less). - the programs are serializing using EXCLUSIVE ENQ on a resource, scope systems As expected, one job is running, all others are waiting to get the resource assigned. But suddenly, we the recognized that jobs on two systems never got running. They have been waiting for the resource for hours, while newer jobs got control one after the other. So resource assignment is clearly not FIFO. We then saw (in EJES) that once a job ended, all waiting jobs are active for a very short time, then one job continues to run while all other are waiting again. I have RTFM, and still think ENQ is FIFO. I have not found anything related to GRS STAR mode that contradicts. I have not followed GRS new lately. What am I missing? -- 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)
Happy New Year to everybody. Barbara, I'm sorry for the delayed response. I've been too busy with the year end porocessing. 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. A simple 'tso ishell' will start two BPXASs: BPXP024I BPXAS INITIATOR STARTED ON BEHALF OF JOB BARBARA RUNNING IN ASID 0030 BPXP024I BPXAS INITIATOR STARTED ON BEHALF OF JOB BARBARA1 RUNNING IN ASID 001E x'30' is my TSO userid, and asid x'1E' is so short-lived that it is gone (without a trace, no BPXAS, no nothing) at the time I look at the log. According to what you wrote, I *should* see at least one BPXAS being idle (in asid x'1E'). There is no asid x'1E'. No, the BPXP024I message documents the ASID that caused this BPXAS to be startet. That ASID may or may not be another BPXAS. Since you mention X'1E' I'd say this is a system address space started during IPL. One of these that are starting UNIX work, and thus are initiating BPXAS starts, is BPXOINIT. The SDSF ps display shows two processes in asid x'30' - in my TSO asid, one for EXEC and the other for /bin/fomfuish. Yes, the first process is the ISHELL REXX and the second one is started to be able to display time/date values in your timezone, provided there is one configured in your UNIX shell environment. (The BPXAS that has been used for a short time is part of this processing.) Once I leave ishell, the two processes are gone. No message in syslog. No idle BPXAS anywhere. I must be missing something. No, you're not missing anything. The two processes are *local* processes, i.e. they run in your TSO address space. You confimed this when you saw two processes in your ASID X'30' in SDSF's PS display. No address space terminated just because you quit ishell. Therefore no end of AS messages are logged. Is there a magic command that I am unaware of that would show me idle BPXASs, provided they exist?!? Have you tried DA ALL in SDSF or D A,BPXAS on the console. SDSF does not show idle initiators in the DA unless you proivde the ALL parm. But then, OMVS/Unix never really made sense to me. It's not a question of whether it makes sense or not. It is an integral part of z/OS and even system tasks (TCP/IP, DB2, IMS, etc., etc.) make use of it. There is no way around it anymore. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
FW: I broke it - programcontrolled programs
RDz.Which insisted on a program-controlled environment despite BPX.DAEMON not being defined. According to the books and your explanation, the need for a program-controlled environment should not have been there. This was true for ftp, but not for RDz. BPX.DAEMON is for processes changing the security environment of the AS (setuid()). There is a second, similar profile called BPX.SERVER which aims to enable a higher security level for processes changing the security environment on a UNIX thread (similar to MVS subtasks) level using the pthread_security_np() service. From what you describe, I guess that RDz might be using this call, and that BPX.SERVER is defined on your system. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFSMRCL0 usermod - was: I broke it
ADCD is used by ISVs - typically the smaller ones. This list is full of people who have experience with it (including me), so this may be the best user group for ADCD. Is anyone of you using an ADCD system still having a V1.10 system? If so, would someone please see, if the DFSMRCL0 module is in any of the LPA libraries in addition to the ADCD...LINKLIB. Just curios, because it still isn't clear why Barbara had no problem with FTP on her V1.10 system. -- 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)
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: I broke it - program controlled programs
Sorry for the late and somewhat lengthy reply. It was back in the second half of the 90s when I was in IBM education that we tried to understand daemon procesing. I thought I understand how daemon processing, BPX.DAEMON and prorgram controlled interact. However, Barbara's post about her problems with FTP showed me, I was missing something, or, that something has changed since then. I've been working through my old material and the elder an newer manuals. The net result being, that I seem to have understood daemon processing correctly: A program changing the userid uid of the current process *without* knowing the target user's password needs to run with (e)uid=0, must have READ access to BPX.DAEMON and all load modules in the address space must have been loaded from program controlled libraries (or have the program controlled extended attribute set, if loaded from the file system. For brevity, I'll only talk about controlled libraries hereafter). What I didn't realize, and never stumbled across, was the exact requirement when a program changes the userid uid of the current process while *knowing* the target user's password. I knew from experience that no access to BPX.DAEMON is required (this knowledge lead to my, a bit unluckily formulated, initial response). What I didn't know was that still all load module must come from program controlled libraries. It seems I just never stumbled across this case. The documentation on BPX.DAEMON in the z/OS UNIX Planning Guide is a bit unclear in this respect (the OS/390 V1.2 book was much fuzzier than the description as of OS/390 V2.10). I interpreted it to say that neither BPX.DAEMON authority nor program controlled is required when the password is known. This is seemed to match with my experience, however, it is not correct. The description of the __passwd() library call (as of OS/390 V1.2) clearly states: If the BPX.DAEMON facility class profile is defined, then all modules within the address space must be loaded from a controlled library. This includes all modules in the application and run-time libraries. So, to be able to change identity with the password at hand when BPX.DAEMON *is* defined, you don't need access to BPX.DAEMON, but still all load modules must have been loaded from a program controlled library. During this research, I also found the reason why so often a requirement for access to BPX.DAEMON is described when it is not actually needed: In an elder C/C++ Runtime Library Reference (MVS/ESA V5), is says: The caller of this service must be a member of the BPX.DAEMON facility class profile. I can't say whether the above statement was wrong or whether the program controlled requirement was not yet in place at that time. But it clearly lead to the statement on BPX.DAEMON access required. I guess for a long time, the statement should have read all load modules must reside in program controlled libraries. Please accept my apologies for the confusion my posts in ignorance may have caused. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
