Re: ENF Listener usage
There are many easy ways to serialize the entry and exiting of an ENF exit or any other kind of hook so that you can know when it is safe to free up the CSA it uses and remove the code. One way I have used in the past is to increment an exit-in-use counter with CS logic upon entry and decrement it with similar CS logic upon exit. If the counter is zero, you can free up the CSA control block. Of course, you must first ensure that the routine is never entered again before you start the removal process. I disagree completely. There is no way, easy or otherwise, to serialize this unless you control the issuance of the event (which for ENF you do not). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: User written checks for IBM health checker
Please do not write a check pretending to be someone else. IBM owns the IBMRACF checks. If you want to write a check that does something to meet your needs, then by all means do so, but name it accordingly. As to what you check, or what interfaces you use to accomplish that, that is up to you. You can use any facilities made available through system REXX. I will not comment on how RACF accomplishes the check in question (in part because I don't know, but just as important because I have no idea if there are programming interfaces available to do what it does). If you think the check should behave differently, please consider sharing your thoughts with the RACF team so that they can consider a change or an enhancement. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Exclusive ENQ on dataset owned (SHR) by Started Task?
It is not necessary have a data set ENQ'd exclusive to delete a member, as evidenced by such functions as ISPF 3.1 There is a protocol for deleting members that applications such as ISPF use. I'm not positive just what that protocol is, but it does not involve getting the data set ENQ exclusive. On the other hand, FWIW, anyone who compresses using IEBCOPY with the data set allocated DISP=SHR (not an exclusive ENQ) as opposed to DISP=OLD is asking for trouble (and in many cases will indeed find trouble). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Cell pool questions
The intent is the CPOOL is not used with the term "cell pool services", and the CSRCPxxx be the only use of that term. Have we screwed that up? Wouldn't surprise me. Counts related to "in-use" are not maintained because that would compromise the performance of the service. And yes, the total count of "free+in-use" can be gotten via CPOOL LIST and doing whatever additions you choose to do. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Snap dump question
>I am experiencing the dreaded S0C4-11 I didn't see an answer to the question of just where the S0C4-11 occurred. I somewhat doubt that SNAP would end with an S0C4-11 if your data was incorrect. It would catch the program interrupt, and either retry to give you back a return code or change the completion code. That leads me to suspect that you never made it to the SVC 33 that is part of SNAP. Look in your program for whatever bug is indicated by the error location. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: CSVDYNEX ?'s
Q1A,Q1B) At what point does the dynamic exit processing determine that an abend has occurred? If I were to provide an ESTAE or similar recovery routine in my exit, what that be sufficient to prevent the exit from becoming disabled? (Assuming it recovered correctly.) A1A: Quibble: it is your exit *routine*, not your exit to which the answer applies: when CSVDYNEX service's recovery gets control. A1B: yes. FWIW, an abendnum of x'7FFF' in practice (admittedly not in theory) will also result in not disabling your exit routine. Q2A,Q2B) Is any notification made available? Specifically an ENF? A2: No Q3) If a recovery routine in the exit itself (as in (1) above) is not the answer, then what is the correct way to provide recovery? The CSVDYNEX RECOVER option seems to be only for callers of the exit; I am essentially only doing a CSVDYNEX ADD,STATE=ACTIVE. A3: CSVDYNEX REQUEST=RECOVER is for uses of CSVDYNEX REQUEST=CALL,FASTPATH=YES You can set any type of recovery that works for the environment(s) in which your exit routine gets control. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: D SMF,O -- what do DEFAULT, PARMLIB and SYS mean?
I agree that you ought to submit an RCF, although we can take action without it. The result should be that the publication describes what the individual options mean (since they are not all intuitive) and adds in anything that is not currently shown (specifically, "SYS") Loosely, it is something like this: CHANGED -- conflicting options, SMF changed what was asked for DEFAULT -- as you would likely expect PARMLIB -- as you would likely expect REPLY -- as you would likely expect SYSIN -- applies to an option that came in via SMF Dump utility processing SMF OVERRIDE -- SMF overrode the option, perhaps because the user specification was no longer valid or perhaps the user specification could not be accomplished. NOT IN USE -- as you would likely expect SYS -- Copied from SYS specification to SUBSYS (seems to relate to EXITS, TYPE, INTERVAL, DETAIL) Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Any way to programmatically detect diagnostic trap IGVCPOOLFREEQ active
Why is this an issue? No one should be running with that DIAG trap (or almost any DIAG trap) on in a production environment, and if not in a production environment, who cares? The whole point of these traps is to be used in environments where you can afford to sacrifice performance. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IEW4005I FETCH FOR MODULE Failed
RC = X'0D' means that the load module is not valid. It is corrupted in some way. Load modules consist of "records". At least one of the records is "bad". If this module loads successfully on other LPARs, is it truly the same load module (i.e., fetched from the same data set) or is that a copy? I suggest that you explore re-creating this load module. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
>Please avoid an absurdity such as "AMODE(ANY)", where >"ANY" no longer means "any", but instead "any except 64". Tongue in cheek: sorry for not being prescient enough in (approximately) 1977 to think that someone might ever need 64-bits worth of addressability. It seems obvious now. No, really: I agree. And that is why those options are available in other forms now which I recommend that you use -- such as '31' instead of ANY in AMODE, or in the LOC parameters of STORAGE OBTAIN. We will never remove support for "ANY". We can only encourage you to use better choices. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: STCBSST bit of STCBFLG1 of STCB DSECT
Since there is no reason anyone should ever be looking at this bit, there is no reason anyone should care "in which task". Nevertheless, FWIW, it is in the propagated-to subtask Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: STCBSST bit of STCBFLG1 of STCB DSECT
A correction, courtesy of Jim: STCBSST is on only when subspace information is being propagated from a mother task to a daughter task. Thus the mother task can be actively using a subspace and not have STCBSST on. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: STCBSST bit of STCBFLG1 of STCB DSECT
Let's start by saying "if you want to know if you are prior to z/OS 1.12 then simply query bit CVTZOS_V1R12". If that bit is off, then you are prior to z/OS 1.12. Maybe that suffices -- if you are prior to z/OS 1.12 then you know that a subspace cannot access storage above 2G (although a non-subspace could).. I don't know if there's a bit that RSM provided indicating that the APAR that was mentioned has been installed. Testing for the release might not be as efficient as you desire, but at least it works. You might find it necessary to have your caller tell you if they are in the state you are interested in. I'm not sure that the terminology used is letting the OP ask the right question. There is no such thing as "subspace mode" architecturally. It's not clear whether the OP is referring to "subspace active" or "reduced authority" both of which are potentially applicable, or even to a "subspace task" (a software term). Neither subspace-active nor reduced-authority state is something that can be in a z/OS control block because a suitably authorized program can change that on its own via the BSG and/or BSA instruction. Architecturally the state is kept in the dispatchable unit control table (DUCT) which is an architected block. I strongly discourage you from writing a program that accesses the DUCT as that is the sort of block that sometimes changes from machine to machine (and the operating system would be responsible for adapting to such changes; applications might have difficulty keeping up). STCBSST is not a programming interface. It means that the task is a subspace task (i.e., has subspace capabilities). It does not have any bearing on whether the task is currently subspace-active or reduced-authority although I would be surprised if you could be in either of those two states without having STCBSST on. For what it's worth, if you abend, bit SDWASSA will be on when the abend occurred while subspace-active. SDWABSA will be on for an ESTAE-type recovery routine (not for an FRR) when the abend occurred while in reduced authority mode. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Is there a way to cause SRB to TCB percolation if an XCF exit fails?
As Mark Brooks basically said, with current functionality, the SRB exit routine must issue CALLRTM TYPE=ABTERM,RETRY=NO (whether from its mainline or its own recovery) if the XCF module that calls the exit routine is not to retry. If the exit routine wants this to be predictable, it would be well served to set up an FRR as just about the first thing it does. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic LPA module use count- who's using the module ?
>Does anyone know if there is a way of finding out which address spaces >are using these previous versions with the non-zero use counts ? Brute force: you could schedule an SRB to every address space and, for every task in that address space, with appropriate serialization, run the TCBLLS queue looking for LLE's that point to LPA CDE's (or LPDE's if that is of interest) with an entry point that matches what you care about. Also, keep in mind that use counts for LPA modules (whether dynamic or not) provide no information about whether the module is actually in use, they only track the number of LOADs vs DELETEs (approximately). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: ISPF abendS138 reas2470003
According to the MVS System Codes book, abend 138 has no reason codes. If ISPF is reporting that there is one, it is perhaps reporting on the register 15 value when the abend was issued which is not the same as a reason code, and has no documented value. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: CICS Maintenance - LPA change
>If it does not work, because the application loads the module once and >uses this version from then on, refreshing the module and restarting the >application should work, correct? It depends how creative the application is. If it tears everything down upon termination and, consequently, builds everything from scratch upon restarting then very likely "yes". I could imagine it leaving a main control block around, and if it stashed the address in there and didn't re-find it after restart, then "no". Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
Some of the integrity examples have been tripping a bit over trying to define system integrity in terms of the behavior of authorized programs, when the statement is in terms of what an unauthorized program must not be allowed to do. For the PC FLIH intercept case, the requirement is that a malicious user must not be able to take advantage of this mechanism in order to get their own code running authorized. For the fetch-protection case, the requirement is that a malicious user must not be able to trick a service into copying arbitrary fetch protected system key storage into non-fetch protected storage viewable by the unauthorized caller. The authorized code must be written to prevent such exposures. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
>this is true, but it is not interesting. (with respect to my pointing out some flaws in the examples) I respectfully disagree. When something is presented as a guideline or even perhaps a "rule of thumb", that is one thing. When something is presented as a rule, that is a different thing. If it is stated that "x is true" when it is not, that ought to be challenged. I believe that that is where the examples fell. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
I apologize in advance to Karl Schmitz if I have a bit of this not quite exact. >Perhaps some Integrity Vulnerability examples will help clarify: > >1)If your authorized program while executing in PSW key 0-7 stores >into an address provided by an unauthorized caller then this is a >violation of the IBM statement of integrity. The use of PSW key is imprecise. It's really "while not using the user's key, whether by that being the PSW key or by using MVCK/MVCDK/MVCSK/etc.". But, more important, the (corrected) statement applies both to stores into and fetches from an address. Not just stores. Still, with the exception that if the address has been validated to be a block that the authorized program owns and that cannot change attributes while mid-stream and that is known not to be fetch-protected, maybe. There are any number of cases where unauthorized "input" identifies a system-key system block (which is verified as being a system block) and that block gets updated as a result of a service call by the system running in system key. >3)If your authorized program while executing in PSW Key 0-7 or >supervisor state returns control to an unauthorized requester in an >authorized state then this is a violation of the IBM statement of >Integrity. By authorized state I mean PSW Key 0-7, Supervisor state, or >now has the ability to MODESET. You really also need to add "unintended" if "unauthorized" refers only to key, state, and APF. This is allowed as long as it is done correctly, which includes limiting it to only the intended requestor(s). Getting that correct is the difficult part. And of course that's at heart of this whole thread. Whether done by a PC FLIH intercept returning via LPSW(E), or an SVC routine manipulating the RB, or a stacking PC manipulating the linkage stack, the concept is the same. >4)If your authorized program while executing in PSW Key 0-7 copies >fetch protected storage to non-fetch protected storage then this is a >violation of the IBM statement of integrity. This is not necessarily a violation of the IBM statement of integrity. It depends on whose data is being copied. I am allowed to put my own non-sensitive data into fetch-protected storage and copy it to non-fetch protected storage if I so choose. The requirement is that I not allow the unauthorized user to access something he should not be given access to. Fetch protection is just one tool in the bag of tricks. The owner of the data is typically the one that decides what the access limitations are to be. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Backlevel IPCS issue at z/OS 1.13
>> Q2) Am I wasting my time here. Should the latest version of IPCS work with all older dumps? >> No, what you are trying to do is necessary. IPCS is not backwards compatible. >Sure it is. Not it isn't, if by "backwards compatible" in this case one means that "z/OS 1.13 IPCS can be relied upon to process successfully dumps from other releases". That cannot be relied upon. Of course on z/OS 1.13, via the MIGLIB approach, you can run a different release's IPCS in order to process that other release's dump. AFAIK, the proper technique remains unchanged. If used on 1.11, it would work on 1.13. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: CICS Maintenance - LPA change
If the owner of the service item did not tell you using dynamic LPA would work, you should have no expectation that it will, and you should not do it. This applies to every piece of service regardless of product. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: LAE instruction
>Yes, set the SAC bits first, otherwise the access register is set with zeros. But if you set the ASC bits to something not 00 and not 01 ("SAC" instruction sets "ASC bits"), the LAE instruction will neither set to 0 nor copy the AR but will do what it is defined to do. >LAE R3,(R4) - loads the value from the location pointed to by R4 in the >home address space into R3 and sets the AR3 register with 0, regardless of >the SAC values at the time. This is not correct (since that's equivalent to LAE R3,4). And even if it did not refer to loading a value (which LAE of course doesn't do) it still wouldn't be correct if the instruction were LAE R3,0(R4) or LAE R3,0(R4,0). The AR is set to 0 only in Primary ASC mode cases. The relevant section of the principles of operation was posted in earlier replies and clearly describes the behavior for each of the 4 ASC modes. I don't know why the OP had difficulty finding that information. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Return code = X'14' from ATTACH JSTCB=YES
>It means that only a JS task with no subtasks can issue a ATTACH >JSTCB=YES. A JS task can have JS subtasks and still issue ATTACH JSTCB=YES. It just cannot have non-JS daughters and do so. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Return code = X'14' from ATTACH JSTCB=YES
Sample scenario: -- Initiator attaches jobstep program task -- jobstep program task attaches non-jobstep task T -- non-jobstep task T attaches T2 specifying JSTCB=YES Return Code = x'14'. A jobstep task may only be attached by a jobstep task. And the subtasks of a given task may not be a mixture of both jobstep and non-jobstep tasks. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Linkage tables
>Does anyone know how to display the linkage tables >from an IPCS dump assuming I dump PCAUTH address space Summary Format will display a lot of information. If you literally want to display the linkage tables (both linkage first and linkage second if the ASN-and-LX-reuse facility is active), then follow the real-pointer chains described in the Principles of Operation, starting from the ASTE (the virtual address of the linkage table / linkage first table is in ASCBLTOV) Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: TCBTQE
> On 2/26/2012 1:08 PM, Micheal Butz wrote: >> Are these created by Z/OS or by the user or both I suspect that Michael was asking whether TQE's themselves are created by zOS or by the user or both, rather than whether STIMER was issued within a system service that a user might invoke. TQEs are created by users for DIE routines (see "Establishing a timer disabled interrupt exit" in the authorized assembler services guide). They are also created by z/OS. One way to get a hint of who does what is that IHATQE has fields that are programming interfaces but TCBTQE is not a programming interface. If a user were supposed to queue a TQE to TCBTQE, then TCBTQE would be a programming interface. That's not to say that the interface information is free from error, but it's a place to start. A scan of the z/OS MVS bookshelf for "TQE" locates the information. I suggest that a simple search is a good place to start before posting some questions unless you feel that the broader list would benefit from seeing the answer. It is particularly when you can't (reasonably easily) find information that the many learned participants (customer, ISV, and IBM) on this forum enjoy helping. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: DU-AL in IPCS dump
For a given task, STCBDUCV has the virtual address of the DUCT. The real address analog of that value is placed into control register 2 at dispatch. The principles of operation describes the format of the DUCT. The DUCT the real address of the access list, specifically, offset x'10' bits 1-24 with seven zeroes appended on the right form the 31-bit real address of the start of the dispatchable unit's access list. The format of the access list is also described in the PoOp. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program entry point on Attached program
>If I do a ATTACH DISP=NO is the attached program LOADED No, until after ATTACH DISP=RESET. In any ATTACH scenario, the attached program is loaded under the (running) new task. The new task does not run at all until ATTACH DISP=RESET. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Can one cause pthread_create / BPXPTATT / BPXINLPA to have SVAREA=YES ?
>It seems that pthread_create under zOS1.11 does not establish an FSA. Is >there some option to force it? I'm just curious: Why is the question being asked? Usually if the target needs to save the system's regs so that it can return properly to the system upon completion, BAKR 14,0 (with PR to return) would work fine. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: STEPLIB problems - was: PDSE
>However LIBDEF for ISPLLIB usually doesn't work because it does not >support the use of LINK, LOAD, ATTACH or XCTL. I was given the following information some time ago by the ISPF team: An ISPF application that needs their LINKs, LOADs, ATTACHes and XCTLs to search the ISPLLIB should be started via SELECT CMD(youprog) rather than SELECT PGM(yourprog). With the CMD approach, the program runs with a TASKLIB of ISPLLIB and any LINKs, LOADs, and XCTLs done under that task will thus search ISPLLIB. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: PDSE
>So the only functionally-equivalent, officially-sanctioned way to >accomplish this goal is still to >(1) create a new dataset with a different name and copy the data to it, >(2) modify PARMLIB LNKLST defs to replace the old library in linklist >with the new at next IPL, >(3) IPL. >And if for some reason you really must have the original dataset name, >repeat the process to get back to the old name. If the data set was in the IPL-time LNKLST set, yes. If the data set was not in the IPL-time LNKLST set, then it depends on whether or not you are able to recycle any spaces that were started after you activated the post-IPL LNKLST set. If push came to shove, most are likely aware of the LNKLST UPDATE function. It's there if you're willing to risk it, and not complain if something bad happens. Regardless, you should expect to have to remove the data set to be compressed from the active LNKLST (by activating a new LNKLST set without the data set), making sure that no one is using that data set within their LNKLST set (by recycling, terminating, or using UPDATE), and making sure that LLA is not managing that data set (by informing LLA not to manage this data set, or terminating LLA). Then you can compress the data set. >techniques whose >success depends on SysProg competence and judgement If it were a question of competence and judgment, we would happily tell you what to do. It is not. >I have seen the compression on the fly for years, no damage no harm. And others have seen harm. The system is yours, you can do what you want. You just shouldn't expect a ton of sympathy. Peter Relson z/OS Core Technology Design> -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: PDSE
>how does IBM suggest doing a compress on a Linklist lib that needs >compressing, inquiring minds would love to know There is no suggestion. This is simply not an operation that is supported or can be supported in general. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: PDSE
>Try running an IEBCopy compress against the data set (option "z" against. >TSO-ISPF display of the PDSE). It might be a little complicated as it's >in the Linklist, and so disp=old wouldn't work (still allocated to LLA), >so you'll have to use disp=shri in a batch job. This is not good advice, in general. Of course it's your system, so shooting yourself in the foot is always an option you are allowed to take. The system allocates LNKLST data sets for a reason -- so that you can't get the data set DISP=OLD which in turn means that if you're doing things right you will not be able to do such damaging operations as compress (where for compress "doing things right" means getting the data set DISP=OLD, and by "damaging" I mean damaging to other processes that might have knowledge of where a member is within the data set, not damaging to the data set itself). Bluntly, if you compress a LNKLST data set without DISP=OLD, then don't complain if something related to that data set no longer works. If you must compress the data set, then get it out of the LNKLST and out of LLA management. And note that there is no fully safe way to do the former unless you have added the data set to the now-activated LNKLST set after IPL and are able to terminate/restart all jobs that started after that LNKLST set was activated. Should compress require DISP=OLD? Maybe. But that's unlikely to change, and definitely won't change as a system default (one could imagine giving the customer a knob to ask that for their system the default be that). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Provide a utility to remove residual systems from the sysplex CDS
>MR1026112735 >Title - Provide a utility to remove residual systems from the sysplex CDS I am told that this request, pointed out by Barbara Nitz, had been answered incorrectly and that the response has been corrected to "recognized". Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: S72A-10 Abend
72A-10: When ATTACH is invoked in AR-ASC mode: Non-zero ALETin AR15. When ATTACH is invoked in primary or AR ASC mode: non-zero ALET in parameter list >I do not see tokens involved with ATTACHX. >Can someone please explain what IBM is talking about? IBM is talking about what the book says: access list entry tokens (ALETs). It might help to show the expansion of the macro, and possibly the assembly listing for that section. If you coded exactly what you showed, your expansion would have included LAE 15,IHB0001 And that in turn would put a value in AR15 that depends on what your ASC mode was and what base reg this resolved to, according to the architecture of the LAE instruction. If you were not intentionally in AR-ASC mode, or if your AR15 would have been 0 when the SVC 42 was issued, then you likely have an overlay of your program such that the assembled parameter list no longer contains 0's in all of the slots reserved for ALETs of parameters. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Date and time of IPL API?
>Looking at the comments in IEESMCA I can see that it became >GUPI in OS/390 R3, but how long has it >actually existed? You're right, Mark. I looked carelessly and incompletely. Those fields existed since whatever release change flag "G74" corresponded to, which was well before MVS/XA SP2.1.0. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Question on adding an SVC routine dynamically to a running system
>I don't understand your comment. Unless by malicious use you mean that >the SVC would be executed over and over, just driving up overhead? By "malicious" use I do mean that the SVC would be executed over and over, but the overhead is irrelevant, as that is limited by the user's priority and job class.. It could conceivably cause the trace table to fill more than it should and potentially wrap with the lost of serviceability data that goes with such occurrence. That is my concern. I also have no idea what data you are tracing. Is it storage area(s) identified by the caller? >Why is that short-sighted? Why would I ever set a slip on a BR R14? If >I need to know where the code is located in a dump, I can get the number >from my own data area, compute the offset into the SVC table, and then go >get it from that table. Your SVC is not a BR R14. And even if it was, you are not the only one who looks at dumps and no one else has any idea what your control structures are. For example, a significant percentage of IBM's service time is spent diagnosing situations that are not related to IBM code and any clue that can help them is always appreciated. And the same is true of customers. Suppose someone (not you) has a dump and the system trace shows the SVC and for some reason they feel this should be investigated, but the SVC routine storage is not in the dump because the dump has (E)SQA but not (E)CSA. It can surely be helpful to be able to answer the question of "what module is this?" which might let them answer the question of "who owns this module?". Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Semiprivileged instructions, part 1
The principles of operation requires very careful reading. As I would guess have most, I have failed to be careful enough many times. >The table, Figure 5-6, titled "Summary of Authorization >Mechanisms" includes semiprivileged instructions _and_ >some others; Looking carefully, I cannot discern which >of these 36 instructions are the 23 semiprivileged >instructions. This table is not intending to show all 23 semiprivileged instructions. And it does not. It is intending to show what it says it shows, a summary of authorization mechanisms. Does it do this correctly or not? (It appears that RP ought to have the Q3 designation but doesn't; if true, we can get that corrected) There are 23 instructions in table 10-1 that are designated as "Q".. (BSA, EPAR, EPAIR, ESAR, ESAIR, IAC, IPK, IVSK, MVPG, MVCP, MVCS, MVCDK, MVCK, MVCOS, MVCSK, PTFF, PC, PT, PTI, RP, SAC, SACF, SPKA,) MVPG, MVCK, PTFF are the instructions in 10-1 that are not in 5-6. (It wouldn't shock me if some day TRAP2/TRAP4 were added to 5-6, with a new column for the TRAP-enabled bit in DUCT byte 47.) Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Question on adding an SVC routine dynamically to a running system
>CSVDYLPA allows you to request dynamic LPA services. Be aware, however, that >changes to LPA itself are not actually done. This set of services truly only >lets you add modules to, and delete modules from, common storage. When >searching by module name, the system will locate the copy of a module added >by dynamic LPA services even if it was present in PLPA, MLPA, or FLPA. >And then noting that the SVCUPDTE had an EP= parameter to allow for >specification by entry point address, it prompted my question. I don't follow why that prompted your question, but perhaps that is not important. This is saying little more than that dynamic LPA modules are not literally in the area built for LPA modules during IPL, but they are in LPA as far as system services are concerned. >The SVC in question has but one purpose. To generate a system trace >table entry. The code within the SVC clears r15, and then branches r14. Having an SVC that is like that is surely a bad idea if used in a customer shop in production where malicious use of that SVC could compromise system serviceability. > I can't see any need to set a slip, or find it using IPCS in a dump. That strikes me as a bit short-sighted unless this will never be used in a customer shop. >By "known" I presume you mean the SVC number has been specified, as >opposed to searching the SVC table for an open slot? yes (or "after" you have searched, although it's not clear exactly what you'd search for, as the value in an unused SVC table slot is not documented and may not stay what it is "today". Peter Relson z/OS Core Technolgogy Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Date and time of IPL API?
While the SMCA (IEESMCA) may have existed "forever", SMCAITME / SMCAIDTE were added in OS/390 R3., one release *after* the introduction of the IPA (IHAIPA). These are in "TIME BIN" format. IPAICTOD was provided in the base IPA. IPAILTOD was added in OS/390 R10. These are in STCK format. The IPA field identifies the end of the IPL/NIP phase. The SMCA fields actually identify when the SMF address space starts, and is set via the "TIME BIN" service. DISPLAY IPLINFO uses IPAILTOD (it originally used IPAICTOD). The closest-to-true-start-of-IPL time is formatted by the IEAVFTED exec "Timed Event Data Report" which shows various IPL statistics. The value used is not in a programming interface field. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Semiprivileged instructions, part 1 (3)
>I have noted a couple of omissions in the PoPs that I will submit >a Readers Comment for I didn't notice that any of the things you mentioned regarding the PoOp are necessarily omissions or things to be corrected (but I might have missed it). You questioned the list of semiprivileged instructions, I believe. That depends on what is meant by semiprivileged. If it means "subject to one of the authorization mechanisms shown in table 5-6" then TRAP2/TRAP are not. RP is not. The wording in the PoOp tends to be extremely precise (not 100% correct, but pretty darn close). I caution against assuming that terms mean what they do not say they mean. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Question on adding an SVC routine dynamically to a running system
If adding by EPNAME then it must be in LPA. If adding by EP it can be anywhere that meets your invokers needs. Having said that, it is worse to have it in ECSA instead of dynamic LPA because ECSA provides no capability for SLIP traps or other diagnostics (including IPCS WHERE) by module name. Regardless, one might always caution that what appears to "work" might mean that you have not tested all possible situations where "working" might be important. I can't think of anything that would apply to this specific case, but that is the risk you always take when you intentionally (or unintentionally for that matter) violate documented requirements. For what it's worth, if the SVC number you want to use is "known" and if it happens to have the right attributes for you (such as SVC type, locks on entry) then you can use dynamic LPA with the SVCNUMDEC function (in the programming interface, a field within DSECT LPMEAX of macro CSVLPRET) if using z/OS 1.12 or later. Peter Relson rel...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Semiprivileged instructions, part 1
<> >BSG - Branch in Subspace Group >EREG- Extract stacked REGisters (32 bits) >EREGG - Extract stacked REGisters Grande (64-bits) >ESTA- Extract stacked STAte >LPTEA - Load Page Table Entry Address >MSTA- Modify stacked STAte >SSAR- Set Secondary ASN >SSAIR - Set Secondary ASN with Instance >STRAG - Store Real Address p >TAR - Test Access p >TPROT - Test PROTection p > ('interesting' in the sense they are not >semiprivileged and the first eight are >not privileged either, but they are >described in the chapter on Control >Instructions: so are they 'general' >instructions? I think not, but it's hard >to say.) >My focus: are these first eight instructions useful >for applications programmers? BAKR, PR, EREG, EREGG are all part of the original linkage standard for AR-mode routines, providing a way to preserve the ARs (and GR high halves) without having to change the caller to provide a large enough save area to hold everything. AR mode is fully available to applications programmers. ESTA and MSTA are of primary use to PC target routines so would not be used by writers of *unauthorized* applications. The statement that "the first eight are not privileged" seems incorrect. LPTEA is a privileged operation. SSAR and SSAIR will not be used by an unauthorized application (they may be issued but would only be in the "current primary" state rather than "space switch"). SSAR/SSAIR for space switch are semiprivileged. You would see these in macro expansions of services entered by non-stacking PC's. Most applications would not care much about using BSG (this was created to help cases such as CICS to isolate its transactions from each other). If you think it important to document which semi-privileged instructions are available to problem state applications, please submit a readers comment form asking that this be done. It seems reasonable. It appears at a glance that all of the semiprivileged instructions in table 5-6 on page 5-28 of PoOp are available, subject to such things as "need a suitable PSW key mask" and "not requesting space switch". z/OS does set, for example, CR0 bit 36 which authorizes various instructions. z/OS itself does not provide support for TRAP2/TRAP4. But some (authorized) program products do this on their own (a bad decision not to have this provided by the operating system). They got burned when the architecture changed incompatibly (incompatible changes in the architecture are almost never done to problem state programs, but such changes are something that "we" in the base control program expect to take care of when they occur). The long and short of it is that you can't use TRAP2/TRAP4 "on your own" if you are not privileged. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
>What PARMLIB member is it that allows >8 characters between periods? > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2c190/8.6.5.1 As Paul Gilmartin posted, this is a reference to: MODIFY CATALOG,DISABLE(DSNCHECK) FWIW, I wouldn't bet that most z/OS componentry pays attention to this. It might be entertaining to try if you can make sure not to pollute your existing catalogs The support says only that it will allow you to create data sets (it does not actually say that you can necessarily use them wherever you'd want to use them). And it even warns you that you may not be able to remove them from the catalog.. I'll admit that I didn't even know that this option existed. I know of many places that validate data set names that have no knowledge of the state of this option. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: register Values TCBGRS vs TCBRB->XRBREGS
>Would anyone know what the differences at a point in time between the >values in TCBGRS and The Values of the registers in XRBREGS of the RB >pointed to by TCBRB As with may things, the answer is "is depends". For example, it depends on what "point in time" and what kind of RB is involved. I think of it this way, for an SVC: -- The front end of the SVC FLIH saves intoTCBGRS. -- If an SVRB is created, then the regs are copied into the RB/XSB. -- If no RB is created (type 1 SVC), then no copying is done. If you are looking while the SVC is in control, you might have a different answer than if you are looking after the SVC has returned. And then of course external and I/O interrupts can come into play. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 1.13 ASCENV incompatible change in Assembler
While it is admittedly unpleasant to have the system start enforcing requirements that it has documented, and I'll grant that we don't often make such runtime enforcement changes, here we are talking about assembly where it should be fairly easy to address, and might well help avoid a problem (as might happen if your ARs or register high halves contained some unexpected value) I'm curious whether the complaint is: -- My SYSSTATE does not represent my actual ASC environment or AMODE (or ARCHLVL or OSREL for that matter, although ARCHLVL and OSREL are not relevant to the macro changes being discussed) yet I expect macros to generate proper code that I can rely on working and continuing to work -- My SYSSTATE does represent my actual environment and I am invoking a service in an environment it is documented not to support but that I expect to work and continue to work -- Something else Aside from the annoyance, would anyone really defend either of those first two practices? FWIW, it was probably already mentioned that this information was conveyed to ISVs and is present in the migration guide. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: WAIT ECB WITH 00 First Byte
For "normal completion", the resetting of the other ECB's wait bits is done, as Jim Mulder points out. For "abnormal completion" (i.e., if you were waiting and woke up in your recovery whether due to cancel or some other asynchronous abend), don't count on it Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: How to easily see the contents of SDUMPX PSWREGS=
I share Binyamin's curiosity about why someone would do this. You can always issue an SVC Dump specifying (for example) the ASIDLST parameter to identify both the current space and other spaces that you want to add. There is no need to worry about PSWREGS in such a case. That parameter is provided primarily for dumps taken out of "mainline" rather than out of recovery, where there is no SDWA and thus there may be need to tell SDUMP which PSW and register values to use in making decisions. To view PSWREGS, I'm not sure that this is the best way or the only way to view them but it works: IPCS STATUS WORKSHEET displays (among other things) the SDUMP(X) parameter list (at the bottom, I believe). PSWRP is the field. You can then use that address and display what you provided as input. There are various IPCS commands to list error PSWs and regs that likely pay attention to the input from PSWREGS. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
S402 ABEND upon cross-memory POST
I share Rob Scott's concern about keys (i.e., system integrity) with the approach that has been mentioned. The change to key 0 may have let the post complete without abend but may well have introduced unacceptable system integrity issues. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ALET=2
>Even if it's page fixed? Yes. (in part because "which private space" is unpredictable, as might be the cross-memory environment). That has been documented "forever" although not in all the places where it could have been. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ALET=2
To add a bit to what Jim Mulder posted, DIE routines are expected not to reference private storage, and therefore (whether they are I/O DIEs or Timer DIEs, whether they "can" or not) should not use ALET=2. Within z/OS, Home ASC mode would "work", although as with any DIE the home space is more or less random. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Hiperspaces
Also, of course, above-2G storage can be used. Both data sapces and high virtual can be set up to be shared across address spaces and persist beyond the end of the creating step. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to enable Storage Protection Override?
>UserKey 9 can write into CICSKey 8? that cannot be correct >as all DFH modules would be up for overwriting. Where >would integrity be? FWIW, "system integrity" is not a factor since in the CICS case the key 9 user has permission to get into key 8 and do whatever a key 8 user can do. Reliability is the reason for this function. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to enable Storage Protection Override?
I believe it has been answered "you do not need to enable it, it is always enabled by z/OS" on all machines that support it (which is all machines on which z/OS runs). As with many queries, it would help to understand what you are trying to accomplish, because perhaps use of key 9 is not something that will be of enough benefit to make it worth your while.. One caveat, if you do not attach your task using the KEY=NINE parameter of ATTACHX, then be aware of the rules governing the subpool in which your module is placed. If it lands in subpool 251 which is fetch-protected TCB key. So if your program is in subpool 251 key=8, you cannot successfully SPKA to key 9 within that program as then you will not be able to access your program's instructions. If your program lands in subpool 252 (key 0, not fetch-protected) that will not be a problem. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re-Linkling a load module with AC(1)
>I am looking to relink a vendor supplied program module which is set up similar to the following: > - Module PCOPY is linked as AC(0) >I would like to relink PCOPY with the following: > - Linked as AC(1) How to get this to work is only one concern. Your main concern should be whether the vendor has verified that it is OK to do this. Otherwise you could be creating a system integrity problem. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Testing g RTM routine
I presume by "RTM routine" you mean "FRR". It is not appreciably different than testing any other recovery routine. You have to do something so that that the "mainline" blows up. If you can run z/OS under VM, that could be ideal. P.S., Follow Chris's advice. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ABEND0F8-20
Due to a screw-up on our part many of the z/OS 1.13 "RMODE 64"-related updates to the books did not make it. This was one. While the books themselves might not get updated for some time, there will likely be an info APAR directing you to some web location where you can find all the missing information. That is not in place yet. I can confirm that ABEND0F8-20 is indeed "you issued an SVC other than SVC X'D' (ABEND) from code that resides >= 2G" Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Looking for clues on a bug in assembler
Despite the harsh opinions expressed, I find it somewhat hard to believe that the owners of this code would not agree to document the behavior that has been cited if indeed it is true that certain things are not restored, unless there is an existing documented protocol that you are expected to follow. I could imagine, for example, that if you made this same sort of observation for some execute form of a macro (you initialized it once using a list form, then used it in the execute form, and then re-used it in the execute form without re-initializing from the list form), you would not get much sympathy. But that is not this situation. Was the conclusion that the SYNAD address had been overlaid at some point and not restored upon CLOSE? Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SRBEPA
>There is not much of a real difference. SQA will even overflow into CSA. It is a matter of "definition". Also the manual says to use SQA. In addition, SQA is >automatically page-fixed. I don't know why you'd want executable code in [E]SQA vice [E]CSA. >http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2a890/6.3.4 The thread is primarily about the SRB routine. The reference is about the SRB itself. The SRB must be in (E)SQA; it must not be in (E)CSA. >So for the SRB control block 241, No, never. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IGVINITFREEMAIN
>Doesn't SVC 99 validate its arguments? The only way to validate an address properly is to use it and see if it works. Most services will use the address, have recovery to field a program check due to the address being "bad" and provide return information to the caller (or percolate the resulting "abend"). No information was provided about where within IEFW21SD the program check occurred so it's hard to guess whether the 0C4 was due to bad user input or some system problem. A symptom dump or abend dump will normally at least let you find out what address was bad. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IGVINITFREEMAIN
>If IBM closes it as BAD then you'll have to restrict IGVINITFREEMAIN to a sandbox. You are expected to use these DIAG traps ONLY in a sandbox regardless of how IBM or anyone else chooses to deal with difficulties that you encounter when using them. That is a reason why they are not documented. You use them in a production environment at your own risk. You typically blow up due to this particular trap not because you failed to initialize storage but because you referenced storage after it had been freed (where perhaps before it was freed the storage had had a pointer field within it on which your code relies). Contrast that with IGVINITGETMAIN due to which you typically blow up because you failed to initialize something. As with most 0C4's the first step is to determine what instruction blew up and what data the instruction was trying to reference. Of course when it blows up in a module you don't own, that might not be overly possible. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TCBFX vs. TCBNOIRB
It is somewhat unlikely that any of you out there has ever created an SIRB. In any case, it is not intended that you do so. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TCBFX vs. TCBNOIRB
TCBFX is not part of the programming interface and as such it should not be used under any circumstance. Discussion of its behavior can be entertaining but you should not expect much in the way of facts on the subject. Basically TCBFX and TCBNOIRB are involved with suppression of IRBs / SIRBs. They have nothing to do with SRBs. TCBFX had some scenarios where it was not preserved (might be turned off and then back on again which in effect negated its use by its original setter of preventing IRBs). For fear of breaking something with a very subtle dependency by changing the behavior of TCBFX, TCBNOIRB was created to have the "desired" behavior. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FORCE ARM
>It might be a good idea to add a NOARM parameter because FORCE,ARM is >less dangerous than FORCE and then have FORCE,NORARM mean what the >current FORCE means. Then if just FORCE is issued, have a prompt for >ARM or NOARM. This is unnecessary. In general, you cannot issue FORCE without having first done CANCEL or FORCE,ARM. That is actually a reason why "ARM" might be a verb, it is preparing (arming) the system (if the FORCE,ARM is not effective) for using "full FORCE". Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FORCE ARM
I don't know anyone who truly knows what ARM stands for. For whatever reason, I hadn't thought of it as an acronym but rather as a verb, as in "arming a device" but since that doesn't really make much sense, I suspect something to do with "allow resource managers" is more likely. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RESMGR Add Return Code 44
>Good coding practice in cases of this type is to do the >MVC (ie: Prime the work area) just before the a MF=E call. Just to point out: macros that support the "COMPLETE" suboption of MF=E do not require use of a list form when you use or default to that option (indeed often those macros do not let you specify anything useful on the list form). But since RESMGR is not one of these macros, yes, do prime the work area. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
zOS 32-bit ? 64-bit?
If bit PSAZARCH is on then z/OS is running in z/Architecture (often referred to as 64-bit). This bit will always be on for z/OS 1.6 or later, might be on for OS/390 R10 through z/OS 1.5, and never on prior to OS/390 R10. IPeter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: subtask recovery
>I have been informed by IBM that sub-tasks are suspended >during an abend and cannot be used. I would guess that you are quoting only part of the information you received. Sub-tasks are not suspended "during an abend". But they are suspended during a "cancel" or a termination of the parent task UNTIL it is their turn to run. Obviously they are not suspended "forever". The thing you have to make sure you are not doing is having the parent task waiting for something that the subtask needs to do in a termination scenario. If the parent task is willing to terminate, then the subtask will get its crack at doing whatever it wanted to do. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CA-1 TMSXITJ
>The point of origin is an SMF exit, presumably hung >as an IRB off of the Initiator so the JOBSTEP TCB is >not directly available; you have to look for it. I rather doubt that any SMF exit like this is run as an IRB. Many SMF exits do run under the initiator TCB. It may well be that the "JOBSTEP TCB" does not exist yet (or any longer, depending on the exit). I suppose the TCB may still exist in some of the termination cases (just not yet freemained) even if the task has terminated. (IEFUTL is an exit that runs as an IRB) Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CA-1 TMSXITJ
... > L R3,ASXBFTCB > > Unfortunately, under z/OS it produces the address of a random TCB. We > tried changing the code to obtain the TCB address directly from PSATOLD > but that doesn't seem to be working either. > This does not produce, and never has produced, "the address of a random TCB". It produces the address of the TCB for the RCT (region control task). User code will typically not run with PSATOLD equal to that task. Regarding making the assumption that "you" can use TCBUSER: not a good assumption. TCBUSER has always been intended for use by the owner of the TCB. But since that has never been made clear, we added STCBUSER in z/OS 1.7 with commentary that attempts to be clear about that. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SYNCH[X] vs LINK[X]
(sorry for being late joining in) IMO, no one would ever use SYNCH(X) unless they had a functional reason to do it. If you have the address of something, you would typically simply BASR to it (or something similar). One functional reason is for authority-decreasing. I believe that it can be correctly stated that SYNCH(X) is the only authority-decreasing mechanism truly supported by z/OS. Note that I intentional wrote "z/OS". Authority-decreasing can be accomplished by PC too (and there is nothing that the operating system can do to stop you from doing it) but I suspect that there could be potential system integrity holes in doing so). RTM uses SYNCH(X) to move from supervisor state to the state needed by an ESTAE-type recovery routine.. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SETLOCK in IEFU85
Assuming that you do need the CMS lock, then it does not matter whether you get the local lock of home (LOCAL lock) or the local lock of your primary or secondary space (CML, if not equal to home). The LOCAL lock is easier, as it does not require you to identify which ASCB. Do note the caveat that the exit routine may be entered locked. If it does, the main thing is that you must not release a lock held by your caller, and also that SETLOCK might not like attempting to obtain a CML if you already hold a local, for example. Thus you would want to use SETLOCK TEST,TYPE=ALOCAL,... to determine if a local lock is held and if so not get a local lock (and not release it later). And SETLOCK TEST,TYPE=CMS to determine if the CMS lock is held and if so not get it (and not release it later). You may invoke SETLOCK in AR ASC mode, provided that (as it true in general for all macros) you have informed the macro of this via SYSSTATE ASCENV=AR. If you look at the expansion, you will see that it issues SAC to primary ASC mode before branching to the service, and SAC back to AR ASC mode after returning. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Cobol - STC design issue
I don't pretend to know what is or is not available via Cobol but -- the system closes files and data sets on your behalf if you terminate. As its options might or might not match exactly what you want, it is probably best to do the closing yourself if there is doubt. -- "intercepting" cancel strikes me as a horrible idea. TERM=YES ESTAE(X) routines will get control on cancel and can do what they want. Task termination RESMGR routines (requiring authorization) will also get control but could be considered overkill if you have proper recovery. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: dynamic STEPLIB
>But does the IBM documentation explicitly say that the parent >TCB cannot do this? "That which is not specifically forbidden, >is allowed." Wrong. 100%. That which is not specifically allowed is not supported and you do at your own (system's) risk.. >DCB parameter Mention is made of the ATTACH DCB parameter. ATTACH has both a DCB parameter and a TASKLIB parameter. The DCB is used to fetch the named entry. TASKLIB is used to set the tasklib. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ESTAE testing question
If the DIAG approach isn't useable by you, it's not all that hard to create this case. And it certainly won't have any adverse affect on the system (just on your job and possibly the initiator in which it ran), assuming that you are running in key 8 problem state. Consider this small testcase, invoked by EXEC PGM= -- Set the ESTAE -- Do a variable-length GETMAIN for as much storage as you can get below the line, subpool 0 (this uses up just about everything, but not everything) -- Do a variable-length GETMAIN for as much of a page as you can get below the line, subpool 0 (this uses up the storage within the page where the system might have gotten savearea storage for your program's entry) -- Blow up. You won't have an SDWA when your ESTAE gets control. As to what happens next, that all depends on what you try to do. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Explanation of EUT/FRR
>Let me see if I understand correctly. >The FRR stack used to be saved only if a local lock, i.e., >a lock without disablement, was held. >The FRR stack is now also saved if the PSANSS bit is on. Add in "or SRB mode" to your conditions, then "yes". Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Lines, Bars and ... mini-bars???
The z/OS 1.13 support (or lack of support if you choose to consider it that) is entirely software-limited. There are no hardware limitations involved here. For example, the hardware does support ETE's with 8-byte entry point addresses. And of course the SVC new PSW is 16 bytes and has appropriate room for the address of an above-2G caller. System services have, in general, not been enhanced to accept 8-byte addresses (be those addresses provided for exits or others). There might be scattered exceptions. Might things "work"? Sure, just as a system service might work in AMODE 64 when not documented. Are they supported? No. A macro might not generate suitable instructions if above the bar (or AMODE 64) prior to issuing. Sometimes the service might rely on something related to the caller's return address and would not find the "mod-2G" value appropriate. The rule is simple: unless a service documents that it can accept callers that reside above 2G, do not use it from code above 2G. By the way: the one exception that I had forgotten to mention is: SVC X'D' (abend). You are free to issue abend from above the bar. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Explanation of EUT/FRR
>My understanding was that the EUT bit in PSA was added because the FRR stack >was not saved. Perhaps it was not saved in EUT mode and the bit caused even >EUT's to have their FRR stack saved? You had mentioned in an earlier append that there was no (potential) CPU switch if locked. Not true for local lock / cms lock. The pre-EUT support would save the FRR stack on undispach (for example, even a locally locked or SRB routine can get a page fault that needs to be resolved). The EUT support adding saving of the FRR stack even for enabled unlocked tasks if bit PSANSS is on. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Explanation of EUT/FRR
>Question What if there is a CPU switch in the routine >being protected by the FRR As Binyamin wrote, FRRs are processor-related. There is a stack. The obvious inference is that if a work unit is undispatched the stack must be saved. It is. When the work unit is redispatched, whether on the same or a different processor, the stack must be restored. It is. >Question I thought PC routines are protected by a ARR PC routines entered in task mode with no locks held and enabled for I/O and external interrupts *may* be protected by an ARR. ARRs protect only PC routines. Those two statements do not imply that PC routines *are* protected by an ARR or that they cannot be protected by some other kind of recovery routine (including ESTAEX or IEAARR, both of which are ESTAE-type).. >if EUT FRR are per TASK how does the Z/OS know they are >the secondary since all FRR's are Created by SETFRR Each work unit has an FRR stack. A work unit runs on one processor at a time. As discussed earlier, upon dispatch the work unit's FRR stack is moved to processor-related storage. Upon undispatch the work unit's FRR stack is copied from that storage to work unit-related storage. >there are TCB flags that indicate their presence. No there are not. But there is a pointer in the TCB to the area that contains the saved FRR stack for the task. Similarly, there is a pointer associated with an SRB to the area that contains the saved FRR stack for the SRB. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Lines, Bars and ... mini-bars???
The z/OS 1.13 support is for a program to be able to survive the things that programs cannot typically avoid -- such as external and I/O interrupts, page faults. If you can get your program up there (whether by yourself or by use of "directed load" (LOAD with ADDR64), and if it calls no system routines of any kind (whether by branch, SVC, or PC), then have at it. You cannot LINK, LOAD (wtihout ADDR64), ATTACH, XCTL, SYNCH or IDENTIFY to something above 2G. This should not be construed to imply that further support will be forthcoming. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: most efficient method to determine "used cpu time" within a particular subtask
If by "within a particular subtask" you mean "not my task, but a subtask of it", then you're mostly on your own. There are no programming interfaces provided to accomplish that. And no control block fields that contain time for a task are programming interfaces. If you're interested in time for "my task", and if you happen to be running on a machine with the ECTG instruction available, then TIMEUSED ECTG=YES,STORADR=x is far and away the best. The output is not in "MIC", it will be in TOD clock units. Alternately, TIMEUSED ECTG=COND,STORADR=x,LINKAGE=SYSTEM can be used. It will get the fast path if ECTG is available, and a slower PC-entered path if ECTG is not available. As Binyamin correctly pointed out, if you look at system control blocks (such as TCBTTIME) you will not pick up the time since the last dispatch. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How many CPU seconds can I consume per 10minutes?
>the slower cp is the measure and not the faster cp. I would have said that "the standard CP is the measure and not the specialty engine" but of course in today's world the two statements end up the same since the standard CP is the slower one when there is a difference.. >IMO, the base configuration would be: >N = # of Physical CPs >N*Y02*SUCONVERSION Perhaps this was taken out of context (it might even have been written before there were zAAPs and zIIPs)t, but to get the SU capacity of a CEC, you need to know also how many there are of each type of CPU and factor in the speed differential. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
>When I learned Assembler, I was taught that registers 0,1,14 and 15 >could NEVER be expected to remain unchanged accross a macro invokation. If I may say so, the lesson was a bit incomplete. To be more correct, change the word "never" to "not" and add "unless the macro documented otherwise". And of course any macro might document non-standard linkage conventions (such as SETLOCK which by default modifies registers 11,12,13) that the user must accommodate. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How many CPU seconds can I consume per 10minutes?
The answer is definitely number of CPUs times 60*10. But another interesting question might be "how many CPU seconds can I see represented in control blocks and/or SMF records". And the answer to that question will rely on whether you are running with full-speed processors and have zAAPs/zIIPs since, depending on the control block you are examining, time running on a zAAP/zIIP might be normalized to the speed of the standard CP (hence multiplied). ASCBEJST is one such field. TCBTTIME is another. If for example you have one zAAP and one standard CP, and the zAAP runs twice as fast as a standard CP, and if both zAAP and CP are fully busy, the total time represented would be up to 3 CPU's worth of seconds even though you only have two CPUs. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Real Storage Occupancy
It's not the possible problem of the real storage occupancy (conceivably in the future driving paging or some other problem) that should be the reason for investigation. Instead, it should be whether there is an application problem (such as a virtual storage leak). If you feel comfortable that the application is doing its job properly and happens to need additional storage each time period, then it is your decision whether or not you accept that need. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVRB for LINK, when freed?
>whether the SVRB for a LINK is freed before the LINK'ed to >program's PRB is placed on the RB chain. After. But before the LINK'ed to program gets control. An SVRB is never freed before the SVC routine is done (and part of the "doing" of the LINK SVC routine is to queue the PRB). >In fact (unless this has been rewritten without my consent) >programs executing as a result of EXEC PGM= are (normally?) invoked >via LINK, and they run under a PRB (or used to). If by "programs executing as a result" was meant the program identified by EXEC PGM=, "not in fact". That program gets control via ATTACH. It does run under a PRB. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Real return address for link and attach
For LINK and ATTACH, the address in register 14 on entry to the target routine is in common storage and is the address of an "SVC 3". As you expect, if your "subtask terminates" then it would not resume anywhere. Therefore one must suspect that it did not terminate, although it might have intended to. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PDSE cache
Simple rule: if you want modules cached, the library needs to be managed by LLA. If LLA deems the module cache-worthy then it will either do the caching using VLF or may notify PDSE processing to do it. If I remember correctly, long ago, long before z/OS 1.11, PDSE processing used to try to cache almost everything. Then all of that caching was removed. And then it was put back for cases where LLA felt it worthwhile. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Chacteristics of HOME ASC mode
>What if you Have a ss pc rtn and want to access data and inst from the >program that issued the ss pc rtn "Home" is not where the issuer of a ss pc came from necessarily. Consider if "home" PC'd to ASID P which then PC's to you. The data from the issuer of your PC is not in home but in P. As has been described, ALET=1 in AR mode works for that case as long as your PC routine is defined properly.. If you need the home space (for example to examine the current TCB), then ALET=2 is appropriate to use. If you were to switch to home ASC mode to look at this, your code would have to be in common storage. Very few documented system services (if any) work in home ASC mode. If they do not say they do, then do not use them in that way Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Chacteristics of HOME ASC mode
The Principles of Operation is very clear on the characteristics of where instructions and data are fetched for all of the ASC modes. Instructions are fetched ffrom home, data from home. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DCBs and DCBEs - Could IBM have done it any worse?
IBM very rarely will change an existing RC=0 to some non-0 value. This is for compatibility reasons. Even rarer (if ever) would be to do this in the service stream. We would not want to break some potentially critical application that had a "correct" program such as OPEN If R15 not-equal 0 then abend When the application had, in effect, wanted the long-standing (somewhat strange) behavior of ignoring the DCBE because of its key (or any of the other reasons why a DCBE might be ignored). Likely? No. Impossible? No. z/OS is full of horrible defaults and behaviors that are legacy behaviors that we don't dare change and instead must make a user overtly request new behavior. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to diagnose memory leak?
>1) IPCS seems to be a great debugging tool. Unfortunately here the ordinary >mortals [like us, the applications programmers] are not allowed to use it. Any >idea what's the possible danger? I don't know why someone would want to restrict IPCS use. What someone would normally want to restrict is the data (such as system SVC dump data sets) that "Joe User" might be allowed to use IPCS on. Your own SYSMDUMPs should be fine. So maybe the restriction is out of laziness -- they don't want to protect their data (the data sets) so they sort of (but not completely) protect it by restricting access to the tool that makes it easiest to view the data. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APF Authorization
The original poster had it correct with respect to aliases, and several subsequent posts incorrect: The APF check is done using the real data set name, not the alias name. Thus what you must have in the APF list is the real name. As stated in the authorized assembler services guide: Defining Aliases in the APF List: Do not define aliases in the APF list because data management services of IBM (for example, OPEN processing) map an alias to its actual library name and query the APF list by the actual library name. An alias in the APF list thus does not actually authorize anything. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: A Curosity Question
Peter Relson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: A Curosity Question
It is surely true that there are programs using CIRB and SCHEDXIT. However, if writing new code, or having the opportunity to change existing code, SCHEDIRB is clearly the preferred thing to use. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problems with TSO TEST
Regarding Skip Robinson's report that TEST *(IEFBR14) does not work: this is intentional and is documented. IKJ57005I has two forms, one of which is: MEMBER member NOT FOUND WITHIN THE STANDARD SEARCH ORDER >From the book: Explanation: The specified member name was not found in the standard search order (TSOLIB (TASKLIB), STEPLIB or JOBLIB, or current LNKLST concatenation). Modules residing in the LPA or in both the LPA and a library in the standard search order are not eligible for the TEST command with the '*' operand. The second sentence of the explanation applies. (It surprised me too, and I asked the module owner without thinking to look it up.) I won't defend the wording of the message. Especially since to my thinking the standard search order includes LPA. And, more, it would have been found in the standard search order shown in the doucmentation if they had chosen to look. So the real problem is that it's found in LPA and that's the whole story. I'm not quite sure why this applies to TASKLIB/STEPLIB/JOBLIB in addition to LNKLST, but the reasoning for LNKLST is that there's no way to tell the system "use the LNKLST copy if it's in LPA too", and TSO TEST cannot use the LPA copy. You can use the form of TEST that specifies the data set from which to fetch the module. Of course none of this has any bearing on the strange behavior cited in the original post of this thread. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problems with TSO TEST
>>-- IEFBR14 was not 'moved' to LPALIB; it was copied. It resides now in >>both libraries. >Just a point of curiousity Skip. Was it done by IBM Maintenance or done locally? Neither. IEFBR14 has been resident in both LINKLIB and LPALIB since SP4.2.0. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYMUPDTE Why is it not fully supported yet
SYMUPDTE has not existed for many years. There is IEASYMUP. If you are using SYMUPDTE, I suggest that you change. "Supported" is an interesting term. I might say that "supported" means documented and that we will take an APAR if there is an error. I might say that IEASYMUP meets both of those qualifications. The documentation is in the Redbook and, as with any sample, we will take APARs if there is an error. But I know that's not what you had in mind, and having to linkedit IEASYMUP yourself is far from ideal. As to "why not yet", it is in part because we had asked for, but until the Share requirement mentioned had not received, a requirement that said that it was OK not to have remote systems update their copies of the symbols from "this system" when "this system" changed symbols (whether added or deleted). That is the expensive thing, and is a logical step, but is not clear when we would choose to spend the resources to implement it. This is the thing that IEASYMUP does not do. Are the return codes really not documented in the Redbook? Sorry about that. (hex) - Success 0008 - No parameter provided nn0C - Symbol name contains ampersand nn10 - Symbol name length, without ampersand, is not 1-8 nn14 - Symbol value length > symbol name length minus 1 0018 - Too many symbols (maximum number of symbols is exceeded) nn1C - Reserved symbol nn20 - Security product denied access nn24 - Symbol value contains ampersand In the info above, "nn" is a 1-origin number identifying which symbol the processing did not like. By the way: If / When updating of symbols is "fully supported", it might not be via an EXEC PGM= program such as IEASYMUP. If IEASYMUP is supplanted by another mechanism, a new IEASYMUP might be provided which does nothing more than return a new return code indicating "do not use me". We would not be able reasonably to do much more than warn / alert you not to use an "old" IEASYMUP as an old IEASYMUP might not build the control structures expected. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Address of a PC routine (9)
IIRC, it is not necessary to dump PC/AUTH to get PC-number information into a dump, at least for information with respect to the address spaces being dumped. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html