Re: PC - SVC restriction ?
PC routines are not supposed to issue SVCs as I understand it. However, WTO and WAIT work (for me, in my single user environment). Has the PC - no SVC restriction been relaxed, or opened up to particular SVC types? The "supposed to" is not correct. No restriction has ever existed. What has always existed is that you can only (successfully) issue an SVC if in an environment where an SVC is allowed: task mode, enabled for interrupts, no locks held, no EUT FRRs, primary = home = secondary. If your PC target (or any routine for that matter) is in that environment, you can issue an SVC and it will make its way to the SVC target routine, otherwise you can't (the abend SVC can be considered an exception). The environments for issuing any service should be clearly documented as part of the documentation for that service. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMODE 64
There is nothing in z/OS Next that will be related to Joe's problem. I don't know what "not recognized in my recovery routine" means. Show the data. Perhaps not your case, but recovery routines (e.g., ESTAE-type, FRRs) cannot be in 64-bit storage. This is unlikely ever to change. But you wrote I load that address into R15 Do BASR R14,R15 and get a S0C1 That makes no sense at all. Unless you didn't load the 64-bit address into 64-bit R15 or were not AMO. Once again you have failed to show the relevant data. How did you "load that address into R15". What is the value in R15 at time of error? And what does that "load...BASR" have to do with "recognized in my recovery routine"? I can believe that if you did something wrong and it blew up you'd land in a recovery routine. Now, if you loaded the LOAD output entry point address that you showed into 64-bit register 15 and issued BASR 14,15, you would not get a S0C1 you would get a S0C6 because of a non-even address. That returned entry point address in ALL cases is suitable for use with BASSM, not necessarily with BASR. You could have done LGR 15,0 BASSM 14,15 Or you could have done something like LGR 15,0 NILL 15,x'FFFE' SAM64 BASR 14,15 Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: POSTing a WAIT in another Address Space; POST ASCB= parameter; S602 Abend
Binyamin wrote: The code attempting the CS needs addressability. Common is not required. Quite often server PC code has its post to the server via the CS technique with the ECB available via an ALET.. You're right of course that addressability is the requirement, not common storage. Regarding the client's having an ALET to access storage in the server address space: that is certainly possible. I don't know how "common" that is. You could be right that it is "quite often". Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: POSTing a WAIT in another Address Space; POST ASCB= parameter; S602 Abend
Use of CS for what we call "quick post" works only if the ECB is in common storage and if the ECB is not yet waiting. You still have to be fully prepared for it to be waiting and code to use IEAMSXMP (or cross memory POST) when you encounter that. It is generally not all that common to find that the ECB is not waiting, but it certainly does happen. We rarely find it worth the extra code and usually waste the cycles trying the CS. The documentation for macros such as IEAMSXMP is intended to be clear about the level of indirection for your parameter. I'd hope any programmer would be able to get the ECB specification right with documentation such as: ECB=xecb is the name (RS-type), or address in register (2)-(12), of a required fullword input which is the ECB to post. So if you specify a "name", it is the field name of the ECB (it's up to you to have provided addressability). You'll see that the expansion takes the address of what you specify. If you specify "address in register", then you have provided the address of the ECB. You'll see that the expansion takes the contents of the register. The documentation for older macros such as POST is weak in that regard. Contrast the ECB=xecb documentation above with the doc for the ECB positional parameter of POST: ecb addr ecb addr: RX-type address, or register (2)-(12), except (10). -and- ecb addr Specifies the address of the fullword event control block representing the event. Do you specify the ECB itself? Do you specify a word containing the ECB address? What do you put into the register if using register form? This problem is pervasive. Since it's unlikely that this pervasive problem will be fixed in the broad sense (an individual case will be addressed if complained about, I'd think), you should be in the habit of looking at the expansion and giving a modicum of thought to what is going on. Clearly a service that is going to update an ECB needs, on input, the address of the ECB, not its contents. If the register form is going to have the address of the ECB, then the expansion for non-register will take the address of what you specify and pass that. So if you specify the ECB itself, such as ECB=MYECB, you'll get the address of MYECB passed, and you'll be good. If you specify something that contains the address, such as ECB=ADDRESS_OF_MYECB, you'll get the address of ADDRESS_OF_MYECB. Things won't go well. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How do I choose a subpool?
FWIW, subpool one isn't all of LE's storage, but it is the part that your C modules need. It's certainly true that if you want to be able to do a subpool freemain, then you wouldn't want to use a subpool that "something else" obtained storage from. So that's where "not subpool 0" comes from and also "subpool 1". I have no idea why they chose subpool 1 for writeable static instantiation. But they did. Of course, if you're authorized you almost always want to avoid "any subpool that is part of the user region" unless you want to be bound by region size limits. 105 FREEMAIN RU,A=(1),LV=(0) *** ,SP=(R2) 107+DS0H @P2A ... Hmmm. Where did line 106 go? Line 106 is from "SYSSTATE TEST" issued within FREEMAIN. It's a macro invocation within a macro so in the absence of PRINT MCALL doesn't get shown in the listing. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Subpool FREEMAIN
FREEMAIN A=(1),LV=(0) 12,*** IHB001 MODE OPERAND REQ'D-NOT SPECIFIED So it would seem that you actually most have done something like FREEMAIN RU,A=(1),LV=(0) If Jim is right, then the invocation asked to free location 0 for length of x'0100' and that properly got 378-1C. That input matches the explanation for 378-1C. I hope there is no use of LE and C writeable static in this address space. That uses subpool 1 and it would be unlikely to be a good idea to free the whole subpool in such a case. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Use of, e.g., LAE in IBM macros
> I was thinking of macros that allow cross-memory RX parameters. I would say that there is no such thing as a cross-memory parameter. But there is AR-qualified data (which might be within a data space or an address space). LAE is already used. Services that support AR-qualified parameters, when appropriate, will use the AR of an identified GR and will use LAE for an RS-type or RX-type specification when the ALET is needed. Here's a non-working (the regs and fields are not initialized) but syntactically correct example TEST CSECT SYSSTATE ASCENV=AR,ARCHLVL=OSREL,OSREL=SYSSTATE USING @DATA,12 CSVAPF REQUEST=LIST,ANSAREA=(2),ANSLEN=(3) CSVAPF REQUEST=LIST,ANSAREA=AA,ANSLEN=AL @DATADS0D AA DSD AL DSF END Assemble this and look through the expansions for things like LAE and STAM. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Use of, e.g., LAE in IBM macros
>How many IBM macros have documentation like "For both primary ASC mode callers >and AR ASC mode callers, >control parameters must be in the primary address space."? Almost all that go so far as to document this (for many others, they should but don't). Of course there are a fair number that allow their data to be ALET-qualified. >Are there any IM macros where requesting use of LAE would be reasonable? With what goal? Saving one instruction (such as doing "LAE" instead of "LR" and "CPYA")? Such a request would not be reasonable. But maybe you have a better goal in mind. For almost all services the rule is that an input AR (or input ALET) is ignored if the caller is not AR mode. There are exceptions. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEASYM filtering on HWNAME not working
The obvious first thought is "the hardware name is not DR" on the system where the definition is not working. Look at ECVTHDNM and see what it says (among many choices, you could write a tiny program, use REXX, use TSO TEST, use IPCS ACTIVE, use IPCS upon an SVC Dump) Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Relative Instructions not generated by some IBM macros, e.g. STORAGE and
You are always welcome and encouraged to submit requirements, whether individually or through Share. But please do not submit a requirement that asks for changing "all". That will likely be declined out of hand. Targeted requirements (both to an area and for specific things within that area) are much more likely to be viewed with favor. That includes prioritizing which macros are of most importance to you. Since this function cannot compatibly be provided by default, you are going to have to change to ask for that new function, which could conceivably be via some global macro variable that you set once for the whole module (perhaps via SYSSTATE), as opposed to via a macro keyword specified on each individual macro. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Relative Instructions not generated by some IBM macros, e.g. STORAGE and ATTACHX
You are expected to make use of IEABRC/IEABRCX if you encounter a macro that uses base displacement branches. But I know that the post was not about branches. It is always to be expected that you need a reg to locate your static data (not your code). You might like the thought of "baseless" coding. But there is no expectation that you can accomplish that with our macros. You should be prepared to provide such addressability. As to when this would be changed? The likely answer is "never". A 6-byte instruction will generally not be used to replace a 4-byte instruction. Conditionally? Conceivably. As to when you would not have to worry about AMODE switching? With LE, that is already conceivable. If simply using z/OS services, the likely answer is "never" in general. Will the macros ever be "changed" from using "LA" or "LAE" to some long-displacement form unconditionally? Surely "no". That's the same 6-byte vs 4-byte consideration. Conditionally? Maybe. But only if a formal request is submitted. And it's more likely to happen for those macros that are tool-generated (as many of the macros created since the mid 80's are). Regarding LARL, it's the case that only the standard form can ever use it. Nothing else has any idea whether your expression is locatable relatively or by resolution of base-displacement. Could some alternate syntax be defined that lets you select between the two? Sure. Will it? Not likely. I have to believe that the use of list/execute forms is dominant. Regarding LRL, that's a good idea (again, conditionally). When these macros were created (or even when enhanced to accommodate not needing a base reg for your code), that was not an instruction that existed. And until z/OS 2.2 that was not an instruction that could be relied upon to be available according to some architecture level set (LRL was introduced on the z10 machine). The general expectation is that you can re-assemble using the new release's macros and still run that expansion on older releases (perhaps limited to those older releases that are still supported). Now that only z/OS 2.4 and up are supported (other than extended support), there are opportunities to use some instructions that were not previously OK to use. Peter Relson z/OS Core Technology Design. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Non-reentrant program not allowed (where?); Advantages of reentrant programs?
It is fair to contrast a program that does not have to acquire storage with one that does. Any extra getmain/freemain (or storage analog) is more cycles of execution. But if you are loading the program more than once because it is not reentrant then the extra cycles needed to do that dwarf the cycles of an extra getmain/freemain (or storage analog). But a stack (such as "C" might rely upon) does not come for free either. Something, at some point, acquired that storage. That took cycles. If your program is so small that it cares about one getmain/freemain, then it probably is overall uninteresting (think how much had to happen to get the job to run that program running and terminated); and if it is not uninteresting, then it should probably be in LPA to avoid the overhead of fetching in the first place. Shmuel wrote Is there a table showing fetch protect, key, page protect and subpool for every combination of library authorization, REFR, REFRPROT, RENT, REUS, TCB key? No there is no "table" nor would it be a productive use of time to create one. The characteristics of where a module is loaded are well described. Page Protect would be outside the bounds of a table; simply, it applies to everything that is marked refreshable. Modules are placed in a particular subpool according to the rules, and for subpools such as 251 and 252 the definition of the subpool tells things such as "key" and "fetch protection". "Reus" is uninteresting without Rent since it is just another case of "not reentrant". And Reus with Rent is the same as Rent to z/OS. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Debugging syscall / SLIP for reason code
Turn on TRACE CT for SYSTCPIP and SYSTCPDA V TCIPIP,TCPIP,PKT,ON TRACE CT for SYSOMVS Start DUMP COMM=() Recreate problem Reply to DUMP R xx,END If everything you need is in those component traces and if you are sure that your DUMP parameter will capture those component traces, then sure this is fine. If you need access to storage containing the parameter/data that was passed to the syscall, that data won't be in this dump unless the program happens to wait after the call. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Non-reentrant program not allowed (where?); Advantages of reentrant programs?
It is not the case that the default has changed for when a reentrant module is placed into key 0 storage (which many equate with protecting it from stores, but of course it only protects it from non-key-0 stores). The default will never change, due to compatibility concerns. But there are options available such as REFRPROT to do some things differently than the default. And, if you care, for a key 9 task (a task attached with ATTACHX specifying KEY=NINE) a reentrant module is placed into key 0 storage whether or not the source library is authorized. Regarding REFRPROT/NOREFRPROT: The "no" version had to be provided and had to be the default, for compatibility reasons. The refreshable attribute had always been ignored by MVS / OS/390 / z/OS so there were plenty of cases where modules had been marked refreshable that weren't. In most cases, compatibility concerns win over modernizing. PLPA, pretty much by definition, is refreshable (because it actually is refreshed when backing real pages have been stolen). That's why the PLPA page data set exists. It is true that you won't successfully IPL if you try to put something into PLPA that is not marked reentrant. Surprising to me, no one has mentioned performance. Avoiding fetching a copy of the module from DASD (as can happen for a second or subsequent fetch of the same reentrant module if a loaded copy still is in play) can be a huge gain if you "load" it many times (such as once per task in a multi-tasking application). Also, be sure in a non-reentrant module to separate your "data" from your "code" (separate cache lines) to avoid significant degradation due to "store into instruction stream" effects. Is user key CSA still available? Only in a restricted way. This is RUCSA. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Debugging syscall / SLIP for reason code
If entered exactly as shown in the original post (the SLIP command and then the response to the WTOR), that response would have failed and not set a SLIP trap. As eagle eye Adam spotted, the blank after the address in DATA ends the input data, requiring the WTOR response to start with the (missing) close-paren. But the WTOR response shown did not. This is not my area at all, but this reason code is produced in module BPXVSSOC. Nominally it has something to do with not finding a suitable Socket GFS and suitable VFS for that GFS (matching the input domain). I don't happen to know anything about either of those. Once it did not find a suitable VFS, you could get 112B. This was not just "reason" 112B, it was errno 45A and errnojr 112B, for what that's worth. You can find some info about that case on IBM Docs within the diagnosis reference (search for 45A and/or 112B) which gets you here: https://www.ibm.com/docs/en/zos/3.1.0?topic=location-ipv6-format-address-issues-errno45a-errnojr112b It might not apply to your case. Was there no documentation for this syscall about this reason code to give you a clue what might have gone wrong? Getting an SVC Dump at that point within OMVS processing seems unlikely to shed much light to a user unless you can find your code and data. But if you do, this module might run in cross-memory mode, such that the caller's data is not in the current primary address space. You might need to make sure to include secondary and/or home address spaces in the dump. I don't know if that helps you or not. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Debugging syscall / SLIP for reason code
SLIP set,if,a=SYNCSVCD,RANGE=(10?+8C?+F0?+1F4?),DATA=(13R??+b0,EQ,112B
),DSPNAME=('OMVS'.*)
If the instruction located by OCVTERRA gets control for this situation (that's
what your RANGE keyword gets you) and if your DATA expression is correct, then
the trap will match.
As suggested you might want to add jobname or ASID, but that will just limit
the trap to matching for your case (where otherwise it will also match for some
other job).
If the trap isn't matching at all, then jobname/ASID won't help make it match.
You might temporarily try removing the DATA expression in case the problem is
that that expression is not correct (you'll definitely want to apply
JOBNAME/ASID if you do that).
Then you'd at least see if the instruction does get control (although it might
not be for the case of interest).
If the trap matches without the DATA expression, but not with it, then you'll
need to figure out what's wrong with that expression.
Peter Relson
z/OS Core Technology Design
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sic transit PDF?
Gil wrote The PDF was in two-up format and I failed to read the second column. Just curious: which book was that? I know that PoP is, but I didn't realize there were others. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sic transit PDF?
Gil wrote I was in an off-list discussion with a Developer where I mentioned where an M&C PDF Programmer response contained insufficient information to resolve a problem. Developer supplied URL of the web page, which contains the necessary information. Catch-22: RCF process is gone. Doc problems can be reported by Feedback via a web page which, in this case, does not exhibit the problem. The official word is: Use "was this topic helpful?" for the corresponding web page, and describe the problem and that the problem is with the PDF. You can make your own choice of whether to go with "thumbs up" or "thumbs down" but I suspect I know what most will choose. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Comments on ASAXWC?
ASAXWC has not been tested in P<>H environment, but it seems likely it would work, both for the normal path that obtains a works area (since it uses STORAGE OBTAIN) and also for paths where you provide a workarea. Those paths do not issue any SVC's (which is the normal inhibitor to accommodating cross-memory invocation). In all cases all the data must be accessible in the primary address space. I trust you're aware that the "default" exactly-one-char symbol is "?" rather than "%". There are definitely existing uses of "%" for that case, though, which is why ASAXWC allows you to specify which such symbol you want used. As to performance, it's brute-force. It's not quick. Those areas that need "quick" might well choose not to accommodate full flexibility (for example supporting only a trailing asterisk so that all they have to check are the "n" characters preceding the asterisk in the pattern). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Couple of questions about job id
For a given ASID, look at OUCB +B0. JES2, STC or TSO should appear. That is field OUCBSUBN which is not a programming interface. Its commentary leads me to think that there are additional possible values. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Couple of questions about job id
Colin P wrote char *pJBNI; char *pJBNS; pJBNI = (char*)*(long*)(plASCB+ASCBJBNI);// for jobs pJBNS = (char*)*(long*)(plASCB+ASCBJBNS); // for started tasks #define ASCBJBNI 172L #define ASCBJBNS 176L One or the other will be zero The last line is not true as written. For example, within an initiator when a job is running, neither is zero. If you're writing product code be aware that as an address space terminates the storage pointed to by ASCBJBNS / ASCBJBNI (which is within a CSCB mapped by IEECHAIN, hence the references to CHTRKID in other posts) gets freemained so that you might have to be prepared to blow up if using the pointer to look (if it's "your" ASCB, no problem). You might instead consider ASSBJBNS / ASSBJBNI which are not pointers, rather are the 8-byte values themselves (or x'00' in the first byte indicating not available), since you can serialize against that storage being freed by having the CPU lock, then verifying that the ASCB is valid via LOCASCSB, and checking that ASCBFAIL is not on. If all is fine, then the ASCB/ASSB cannot be freed until you release the CPU lock. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: parmlib IRRPRM00 and ICHRDSNT
FWIW, This wording "The IRRPRMxx PARMLIB member is specified via the "RACF=xx" system initialization option." Which is here: https://www.ibm.com/docs/en/zos/3.1.0?topic=configuration-specifying-racf-database-options implies that IRRPRMxx is only processed during IPL. (I would have liked this in the next section of the book that is specifically for IRRPRMxx, in addition to, or instead of, this other place.) I'd suggest changing "initialization option" to "parameter". I'm not sure why you thought that stopping and re-starting RACF would pay attention to IRRPRMxx. Started tasks that pay attention to a parmlib generally have a parameter by which you identify the parmlib member to pay attention to upon the start. Peter Relson z/OS Core Technology Desig -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LISTDSI Bad return value z/OS 3.1
Perhaps the "0" from "3390" was too far to the right and ignored? An unnumbered file with the "0" in column 73 would certainly ignore the "0". Parmlib members often have the rule that anything past column 71 is silently ignored. Reading of a parmlib member by IEFPRMLB, for example, will let you ask to blank out column 72 to avoid confusing subsequent parsing. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Does MVCDK move 'per byte' like MVC?
An alternative (no comment on relative performance) for this case since you know the intended data is: SPKA user-key MVI first-byte MVC overlapping SPKA your-key Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CSVDYLPA=ADD LPMEAMODLEN not being updated
For BYADDR=NO the entry point is being updated but not the length it returns a constant not reflective of the true module length consequently for a number of modules only part of it is being copied to LPA Nonsense. Prove it. CSVDYLPA never returns a "constant" for module length. If it returned a length, then that IS the true module length and that IS the amount "copied to LPA". SHOW THE DATA. That includes the directory information returned for an item that doesn't work. That includes the values for ALL of the things that your macro invocation references. For all I know, the DD you used for DESERV doesn't match the DSN you supplied to CSVDYLPA. At least, consider going for consistency by using DDNAME= rather than DSNAME= for CSVDYLPA. Did you bother trying SETPROG LPA,ADD to add any single one of the modules from your data set and then look at the result such as by DISPLAY PROG,LPA,MOD=xxx? At least with that you can get an idea of what your expectations should be. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: message IEA793AJUsr wonderinfJ
The OP first tried to clear a dump data set. That would have worked if there was such a data set. But apparently there wasn't. SYS1.DUMPxx data sets are not magically created, they are created by "you" and managed by "you" (and the system might attempt to find an available one) Then there is dynamic dump allocation which, apparently, is not active. This relates to DUMPDS (DD) command options such as DD ALLOC and DD ADD. And you can define the naming pattern for the dump data set. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What's at a comma?
Phil S wrote: IPL PSW: The first eight bytes read during a CCW-type initial-program-loading (IPL) initial read operation are stored at locations 0-7. ... That's what I was talking about re the IPL PSW. That is, of course, true. My point was that that information is not in the "PSA" that is available to programs. It was at absolute locations 0-7 (not subject to prefixing because that is not active at the IPL itself). The IPL root program ends up after that in the same page (and what follows). But that is gone by the time the IPL proceeds much further. Prior to z-Architecture, locations 0-7 were the restart old PSW, generally 0's until a restart had been done (if ever). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What's at a comma?
The code is checking 7 bytes at location x'6B' through x'71'. As of z/OS 2.5 that area is all zeroes. Prior to z/OS 2.5 for any z/Architecture IPL it is not. The same is true for location 0 and others. Since none of them are programming interfaces (such that changing the value is not something we would feel a need to disclose), I doubt that anyone at IBM would try to list them for you. But if you have access to both a release before 2.5 and a release 2.5 or later, you could probably figure it out with not much difficulty. Someone asked about "IPL PSW". These 7 bytes have nothing to do with any IPL PSW. And the PSW's used for IPL are not preserved in low storage for later viewing. Assembly option FLAG(PAGE0) would have alerted you to the error: ** ASMA309W Operand 0(R7) resolved to a displacement with no base register ** ASMA309W Operand COMMA resolved to a displacement with no base register Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF 194
The references to TS7700 Statistical Data Format appear to be to SMF 94. The query was SMF 194 which, I believe, is not owned by IBM. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
TSO PARMLIB command - Abend S047
Did this ever get resolved? I was away and could not respond at the time. I would have started by saying that the APF authorization of SYS1.CMDLIB is pretty much irrelevant. It might be necessary but it is not relevant to the abend. Simply put, the abend indicates that the issuer of an SVC that requires APF authorization (usually the MODESET SVC, but could be any SVC that requires APF authorization and there are a dozen or so) was not APF-authorized. So we need to backtrack to how that user was supposed to be APF-authorized. And the general answer for a TSO command is that TSO needs to have been "informed" that the PARMLIB command is to be processed in the authorized size of TSO. If it wasn't informed, then the command would run in the unauthorized side and you'd expect MODESET to get SVC 047. I would have suggested to look within the definition of what TSO is to consider as an authorized command. PARMLIB is documented as an authorized command (but I don't know if that is "built-in" or needs to be specified). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Epoch Index
Attila F wrote STP provides that non-z/OS persistent data store that can cross IPLs. Nothing was coming to mind that matches a statement like that. It is true that certain STP attributes can be set by the OS and remain in effect upon the next IPL of the partition, but that's not a "data store". Can you clarify? Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Exits (was RMDS error DBNV016)
Mike Schwab wrote Most exits are assembler, right? Most system exits, surely. Metal C (or anything that does not need an environment such as C and REXX do) is another choice typically. Bob Bridges wrote: Although I gather z/OS now allows them to be in REXX. Certainly not in general. Most system exits do not get control when REXX is available. Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Epoch Index
Gil wrote Eerily reminiscent of a Red Alert IBM issued a couple years ago. A macro, customer facing therefore hard to change, was doing a STCK to a wild address. When a certain bit in the TOD changed, IPL cod which tests that bit with no effect other than to crash when it had the wrong value would make the next IPL impossible. That seems unlikely, and almost inconceivable unless you IPL without "clear" (aside from if the corrupted storage got written to a data set that was read upon re-IPL). Might you have any details? I certainly understand relatively unpredictable side effects within the current IPL, Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ZAD SLIP trap
The PER SLIP matches only a non-zero register with zeros in it like this: L Rx,PSAAOLD(0,4) <-- SLIP will match if R4 contains zeros And, also, will match for this if R4 contains zeros: L Rx,PSAAOLD(4,0) Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Epoch Index
Am I correct in understanding that on current hardware an overflow from the TOD will be carried into the Epoch Index, but only once? No, that is not correct. The Epoch Index gets incremented upon the wrap/overflow, for as many epochs as happen. Am I correct in understanding that the Clock Comparator remains in 64-bit TOD format? How will intervals spanning that time in 2042 be handled? Yes, it is true. The short answer to the second question is "correctly". As a hint, try doing 64-bit arithmetic that subtracts a before-wrap 8-byte TOD value from an after-wrap 8-byte TOD value and see what you get. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DSNTEP2 problem
RUN PROGRAM(DSNTEP2) PLAN(DSNTEP1) LIB('DB2.DBV.SDSNSAMP')
IKJ56712I INVALID KEYWORD, PLAN(DSNTEP1)
I'm surprised that TSO parsing (and given that we see an IKJ message, it seems
that TSO parsing is being used, not necessarily by TSO itself) would consider a
"bad value" (especially when the possible values are not knowable to a parser)
to be an "INVALID KEYWORD" (as opposed to if the user had coded PLANN(DSNTEP1)
it might have complained that PLANN was an invalid keyword.
Peter Relson
z/OS Core Technology Design
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Syntax error using Unix cp command with "-W" parameters
Gil wrote: It's careless documentation to introduce syntax rules only on examples. I've submitted a feedback to: <https://www.ibm.com/docs/en/zos/3.1.0?topic=descriptions-cp-copy-file> I agree completely (I'd have gone with "incorrect", being stronger than "careless"). Thank you for submitting feedback to get that corrected. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Fault Analyzer output for executed instructions?
Mike Schwab wrote Length is a nibble, x0 is one byte, one digit, one sign, xF is 16 bytes, 31 digits, 1 sign. On Tue, May 14, 2024 at 6:48 PM Seymour J Metz mailto:sme...@gmu.edu>> wrote: > > I have a program that is getting an S0C7 on an EX instruction. The output > from Fault Analyzer contains the target instruction as is, with a zero length > field, and only displays one byte of the operand. Could you explain further? It is certainly not true that “in general”, length is a nybble. And I doubt it is true that it is true for every instruction that can get a PIC 7 (Seymour’s post did not identify the instruction itself that was the target of the execute). I believe that there was a way to have the processing take the instruction text, OR with the value from the low byte of register (which indicates whatever it indicates), and use that updated instruction text as the basis for a display. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 0C4 pic 11 in stimer exit on retry
Was your recovery routine set within the IRB or by the mainline? The reg 13 within the IRB is for the IRB and storage associated with an RB is freed when the RB terminates. If you "retry" you are retrying to the RB that set the recovery. Thus any regs for retry should be ones associated with that RB. Of at least as much importance: Show the data. Including the 8-byte translation exception address. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Testdriving svc in key 9 (was: finding callers key in svc)
I managed to show now that the code in the svc is correct, it indicated that the caller was in key 9. Perhaps share, to help others not make the system mistake, what had led you to believe that the code was not doing what you wanted. I've solved the testdriver issue now by marking that routine as REFReshable and put it in SYS1.LINKLIB. This behavior, when marking the module as refreshable, applies only when the REFRPROT option of PROGxx is active. That applies system-wide. As long as that is OK, and you have control of setting REFRPROT, have at it. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: finding callers key in svc
Please try to have different threads with suitable subjects for each. The 0C4 is unrelated to the subject. Since the code shown for the SVC routine is correct for type 2/3/4 yet you say that you do not find the right data, then prove it: Show the definition of the SVC, show extracts from IPCS looking at the dump storage. If you are blowing up at the instruction right after the SPKA to a different key, regardless of what that instruction was, then your program is in key 8 fetch-protected storage so unless your new key is 0, you will not be able to access the instruction. Requirements for placing a reentrant program into key 0 non-fetch-protected storage depend on authorization and various system-wide options, along with the possibility of doing an ATTACHX with the KEY=NINE parameter (which will place into key 0 storage without relying on authorization). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: finding callers key in svc
USING RBBASIC,R5 POINT TO REQUEST BLOCK LR7,RBLINK LOAD CALLER RB IN REG 7 DROP R5 DROP SVC RB MAPPING USING RBBASIC,R7 AND NOW MAP CALLER RB LR1,RBOPSW GET CALLER PSW AND PUT IN REG 1 NR1,=X'00F0'ONLY PSW KEY SRL R1,16 SHIFT TO 00K0 *STR1,KEY STORE CALLER KEY DCH'0'FORCE ABEND If your SVC is a type 2/3/4 SVC, the code works. I can't speak to how you are debugging or what you are seeing in a dump because you have not shared any of that information. You could even try this without needing your own SVC by having your code in a LINK target, at least to verify that you are seeing the PSW of the SVC issuer (SVC 6 in the simplest LINK case). You wouldn't have R5 set on input but can easily pick that up via (IHAPSA) PSATOLD -> (IKJTCB) TCBRBP. It is in general poor form to use RBLINK rather than RBLINKB unless AMODE 24, but in your case you would know that the caller's RB is not waiting so the high byte will have a 0 wait count so can get away with using the 4-byte name. These days, the L/N/SRL has many better alternatives, such as LLC (of the 2nd byte of RBOPSW) / NILL (to clear the low 4 bits if for some reason you need to do so). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Weird error with class DATASET
However that does not explain why RACF interferes at the second volume mount. To be picky, RACF never "interferes". RACF only answers a question asked of it. A fair question might be "why is there a RACF query in class dataset in your case?" Presumably that is because a dataset is being opened. And as you showed you have TAPEAUTHDSN=YES. I have no idea if temporary data sets "count" when OPEN is processing, but it wouldn't shock me. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: finding callers key in svc
is there any logic behind why MVC uses the actual byte count and MVCSK uses the 'number of bytes to the right'? As Wayne D pointed out, for MVC the user codes "n" and the instruction text uses "n-1". This is almost certainly for effectiveness. Having 8 bits of instruction text lets you cover a range of 1-256 bytes instead of 0-255 bytes. You would have been very unhappy if you could only move 255 bytes with a single MVC if moving a long string (particularly in the days before MVCL). FWIW, this is why if you EXecute an MVC, the value you put into the register is "n-1". For MVCSK/MVCDK, the user does not code a length, and the length is not in the instruction text. The length is in a register. So the user puts the value there by a separate instruction. So both actually use "number of bytes to the right" (or, as I think of it, "length minus one"). You could ask "for MVCSK/MVCDK, since the length is in a register, why did you go with n-1 in the register instead of n?". I don't recall exactly but it was likely for either (or both) of consistency with MVC (such as the execute case) or for cost savings (perhaps being able to share part of the implementation). As to the initial question, as pointed out, it depends on the type of the SVC. The SVC owner knows what type it is (because they defined it) and can look in the right place for that type of SVC, just as they look in the right place for the caller's regs (for which the answer is different than the psw/key, but similarly depends on the type of the SVC. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0c4 creation
Bernd O wrote I'd suggest to be very careful with such codings; a co-worker some years ago did this and - by accident - the code ran privileged, which caused the whole LPAR to hang. Same goes for ST at address zero, which was suggested by another poster. I challenge both of those. The first will never happen unless something changed to key 0 (being privileged is relevant only to the extent that you could then change to key 0). And that doesn't happen without intent. The second will never happen outside of the OS itself in the absence of an APARable z/OS error (related to what we refer to as low-core protect). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Value in SDWAEC1
if I don't find a RB in the RB chain I do a CSVQUERY in the asid of SDWAPRIM if not I do NUCKLKUP Please be more complete in describing what you are truly doing (and trying to accomplish). For example, suppose you do find an RB for which RBOPSW matches SDWAEC1. In what way does that help you? The name in the RB's CDE (if there is one, not even all PRBs have one) would identify the program for which the RB started but might have next to nothing to do with the problem. And what if there are two RB's with such a PSW? SDWANAME might already have in it a name from that CDE. You can't do a "CSVQUERY in the ASID of SDWAPRIM" unless you are running with your current primary ASID equal to SDWAPRIM. I.e., CSVQUERY searches the information for the current primary address space (even if primary is not home). Thus, at a minimum, for an ESTAEX, you'd have to check for SDWAPRIM = current primary ASID (such as by using EPAR to extract the current primary ASN). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ALESERV rc 15 = 0 and alet = 0
The assertion of the subject is surely not correct. I do not choose to guess in just what way. Perhaps more important, the ALESERV is likely creating a system integrity violation in specifying access=public. Please take to heart the comment on ASSBSTKN: As with other ASCB/ASSB fields, serialization may be required when accessing something other than your address space's data. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Value in SDWAEC1
I think the comment in SDWAEC1 is quite clear: Extended control PSW at time of error(abend). When the error was a program interrupt within transactional execution, this is the PSW at the time of the program interrupt within the transaction. It means what it says. When you mention an RB, it is important to identify to which RB you refer. Peter Relson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What is IEANTRTR in Authorized Assembler Services Reference?
IEANTRTR, exactly like IEANTRT, has authorization-related "limitations" and authorization-related opportunities. If you look closely, the non-authorized IEANTRT shows that the level parameter has 4 choices. The authorized IEANTRT shows that the level parameter has 7 choices. The same is true for IEANTRTR (or would be if both authorized and non-authorized were documented). But neither is really true. It's just that an unauthorized IEANTRT would (in practice, not theory) not use one of the other 3 choices. Those other three options are all "match only if the name/token was created by a supervisor state or system key creator". Could an unauthorized user go down that route? I suppose. They wouldn't be retrieving information that they set. The authorized IEANTRT allows SRB-mode and allows locks to be held; the unauthorized does not allow SRB-mode. It incorrectly talks about locks that could be held. It should not. But realize that these are not enforced requirements/restrictions. Unauthorized code cannot be in SRB mode and cannot have system locks; authorized code is expected to follow the rules, whether they are enforced or not. Unlike IEANTRT for reasons that I do not recall (but should because I wrote it and it was only 10 years ago) but for which I'd hope you'd consider submitting "negative feedback" (such as via thumbs down within "was this topic helpful?" after which you get to enter your comment), IEANTRTR is documented only in the authorized assembler services reference. It should be documented in both, appropriately. It's hard to submit feedback for "this book doesn't have this chapter", with the current scheme available, so I'd suggest doing it from the authorized book's chapter. Peter Relsonz/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STIMER
You can cancel an STIMER via TTIMER CANCEL. Peter Relsonz/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Recovery routine for IRB
It is perfectly valid to "have" an ESTAE-type recovery routine while you hold a lock or are disabled. You might not be able to set it in that environment (the OP's code set the ESTAEX while not in either of those states), but if you set it before, it will participate. Branch-entry ESTAE has some limited use cases where you can set an ESTAE even though locked; ESTAEX does not support that. An ESTAE-type recovery routine will get control if any/all FRRs have percolated for an error that happened while locked or disabled, but any locks will have been released and enablement will have been re-established so the routine gets control enabled and unlocked (much recovery might need to get control still holding the locks in order not to lose serialization; those cases need an FRR). The lock release(s) and enablement happen at the "transition" from "RTM1" (FRR processing) to "RTM2" (ESTAE-type processing). RTM1 issues an SVC D to get to RTM2 (enabled, unlocked, not XM mode); this is not an "abend" in the normal sense of the term. Regarding the response about "why CIRB", it was not really on point. You likely do not need to build/touch IQE/IRB. The parameters on SCHEDIRB (such as EPPTR, MODE, KEY et al) generally cover all the pieces of data that you would set in the IRB. They do cover all that you showed in your code example. It is documented that SCHEDIRB is suggested rather than CIRB. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Recovery routine for IRB
If an ESTAE-type recovery routine (whether ESTAE or ESTAEX or ARR or IEAARR) is established when the IRB blows up, it will get control. Therefore we conclude that that is not the case. What you have shown is not a "recovery routine for IRB" but rather a recovery routine for the mainline that would cover an IRB if that IRB happened to run before you terminated and if that IRB blew up so that the mainline's recovery was the most recent recovery routine. That would not be intrinsically different than if you LINK'd to a routine and that routine blew up without recovery. You have made an assumption that just because you issued SCHEDIRB that the IRB will run before the mainline continues. That is not a valid assumption. It might run as soon as you release the LOCAL lock, it might not. If you are trying to test what happens when an IRB pops on top of your RB and that IRB blows up and your RB's recovery gets control, consider doing something like WAIT on an ECB that is initialized to 0 and that is never posted. In your testcase that would be right after you release the LOCAL lock. That would make sure that your mainline did not proceed too far. I don't know why you want to go the route of CIRB to accomplish your test (and if you must use SCHEDIRB, why not use the form that has the system initialize the IRB for you and not need you to use CIRB?). Why not use STIMER or STIMERM to wait for, say, 0.01 seconds, with an exit? The exit routine runs as an IRB. You have not initialized your ESTAEX execute form from a static list form. Whether that's relevant to your problem or not, I have no idea. But it is easily demonstrated that your scenario is not as you describe, otherwise the ESTAEX routine would get control. If, for debugging, you want to see if the recovery is in effect (not in control) when your IRB gets control, see if the +x'A0' word in the TCB pointed to by PSATOLD is non-0. It will be 0 if there is no ESTAE/ESTAEX/FESTAE. In the simple case you describe you would expect to see a non-0 address there (which locates the STAE Control Block, SCB). When you are providing a code example and there is any possibility that someone will want to assemble it (perhaps even to try it), please make sure it assembles or provide guidance on what to do to get it to assemble. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SDWAEC1
If for instance the user was running amode 64 I don't think SDWASRSV has 64 bit area but if I have the correlating RB I can get the 64 bit regs from XSB SDWASRSV doesn't have them because it is 4-bytes per register. Have you looked at SDWAG64 and/or SDWAG64H? For purposes of first level diagnosis it is rarely needed to have the regs from the RB/linkage stack except when they give you easy access to the registers that were input to the target routine when the error is due to bad input (so, for example, if you are in a PC target, sure; if you are in a type 2/3/4 SVC routine, sure), but very rarely would your recovery routine care about that. What you generally want are the time of error registers, and the ability to track back to where the register values came from. modifying file 192 general recovery. As far as I recall, you have yet to share with the group the design points of the modifications you are trying to make. Several folks have previously questioned some of the approaches that it appears you might be trying to implement. SDWANAME, SDWAMODN, SDWACSCT might be of interest to a diagnostician but rarely to a recovery routine itself. Some of these are sometimes provided by RTM; SDWAMODN and SDWACSCT are often set by the recovery routine itself. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SDWAEC1
Since it is apparent that Mr. Reichman does not respect the time of the followers of IBM-Main, I choose not to continue rewarding bad behavior. This will be my last response to any post he makes that demonstrates that lack of respect, whether he has not seemed to pay attention to a post upon which his post is based or has not provided sufficient information either upon initial post of a thread or (especially) when asked for such information by a responder. I'm trying to leave the door open for a change to what we might call good behavior. Regarding SDWAEC1 (you should instead be using SDWAPSW16 to handle any RMODE 64 cases that might surface for the time of error PSW) * If the address is in common storage, you could use CSVQUERY with SEARCH=LPA and, if that does not succeed and the address is below 2G, use NUCLKUP. * If the error occurred in your current-primary address space, you could use CSVQUERY with SEARCH=JPA with INADDR64=YES and maybe ANCESTORJPQ=YES and maybe DIRLOAD=YES. (if the error address is in private, and you are not running with the failing address space as your current primary, it would be wrong to try to search the current-primary address space for a given address) If you want to handle modules loaded with GLOBAL=YES, then tweak the above also to search JPA (with or without LPA) in the case of common storage. Most would not bother. LOAD with GLOBAL=YES is possible to get right, but in almost all cases is not gotten right and results in a system integrity exposure. Thus it is discouraged, with dynamic LPA and load with ADDR/ADDR64 being the alternatives (most diagnosticians would prefer that you use dynamic LPA in order to more easily learn what module name is associated with a given address). Some day nucleus storage above 2G might be supported. If that happens there would be something akin to NUCLKUP that accommodates an 8-byte input/output address. I think that SDWAPRIM would be a good indicator of where the error occurred, by ASID. There could be some tricky cases if the PSW indicated Home ASC mode. In practice, all home ASC code is in common storage (it theoretically need not be). If you have a private-area address and the PSW is in home ASC mode, then it's the home address space that needs to be searched. The address space that is available to you to search depends on the type of recovery (and options) that you are using. SDWAFMID is set in only a few circumstances, it seems (such as DAT error), so you won't find that helpful generally. Note that none of this discussion mentioned (or had a reason to mention) an RB/XSB pair. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SDWAEC1
The value is the time of error PSW from wherever it came. It could have come from a task or SRB in this address space. It could have come from an SRB in another address space. It need not be in "RBOPSW" (or XSBOPSW16) of any RB. Most of your recent questions ought to be preceded by a description of what it is that you are trying to do. It is not helpful, either to you or to those whom you are asking, to keep asking questions that you (and a program) should not have to care about. I'm guessing that this is another thing you are trying to do to help name the program that blew up. Fine. But how does being in RBOPSW of some task's RB help other than to give a name to the most recent PRB that had a CDE? Even if that's the jobstep program's PRB, is that what you want to surface? The odds are that there is no intended programming interface that will do what you want (whatever that is) in all cases. And no one is going to try to figure out the exceptions. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SDWARTYA in different address space
wonder if SETRP can retry in different address space the doc says you can run it in AR mode Whether you can issue SETRP in AR mode has nothing to do with "retry in different address space". The space from which data is fetched by SETRP (which in your example is "nothing" because you specified register form) is not related to the address space in which you retry (which itself is an inaccurate-enough term to be not useful). The cross memory environment for any recovery routine's retry is well-defined and depends on what you have chosen to identify. One additional tidbit is bit SDWARFXM (which applies to FRRs only). Its comment is correct. So if RETADDR=(RX) and access RX has an ALET ? Whether or not you can invoke a macro in AR mode is not sufficient to know if the data can be in a data space. These questions can often be answered simply by looking at the expansion. What do you get for the retaddr processing of SETRP RC=4,RETADDR=(RX)? You get "LR15,RX" then "ST15,SDWARTYA-SDWA(,1)". And you get that whether or not you have SYSSTATE ASCENV=AR. Thus it is irrelevant what is the ALET in Access register RX. You can see that the WKAREA default, to register 1, requires that you have set up AR1 appropriately (to 0 would be most appropriate) Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Nanosecond resolution timestamps for HLL's?
It might be said that the notion of monotonicity with respect to clock values is not "valid" unless you are a single-threaded application or all your references are serialized across all the threads (such as by a step- or system- or systems-level ENQ depending on the characteristics). Otherwise you cannot possibly tell what is what because thread one might have captured clock value "n" and then gotten interrupted, and then thread two captured clock value "n+1" and then continued to completion, after which thread one was re-dispatched (with what is now an older time stamp than the one already captured). If these two threads were serialized by an ENQ against each other the above scenario would not happen because thread two would not have been able to get to the point of capturing its clock value. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XTL64E_EXTENTADDR
It should be apparent that if you're using a 4-byte address from an 8-byte PSW, you cannot possibly handle information from an extent list that might have addresses above 2G. 16-byte PSW with its 8-byte address (and similarly GR high halves) is provided only for time of error. That's not either SDWAEC1/SDWAEC2 of course. If using 8-byte PSW, XTL64 is not needed, the "normal" extent list will do. Further, I don't recall how you are actually thinking to locate the XTL64. If you're using CSVQUERY (such as based on the address that you seem to be interested in), I can say only that that is a bad thing to do in a "general recovery routine" for all the reasons I laid out long ago to one of your earlier posts, including making sure that your recovery routine actually gets the opportunity to do the things that recovery routines must do (and not get short-circuited by calling an unnecessary routine that (just because of the nature of things) might unexpectedly fail). You might survive if you have established nested recovery to catch such a failure (which would surely be the minimum you have to do). But if you do provide CSVQUERY with an address and it finds it (based on such things as your search criteria - JPALPA or just JPA, for example), then you have a change to get an XTL64. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XTL64E_EXTENTADDR
In contents supervisor speak, an extent list contains header information and then information about the length and address of each (module) extent (whether mapped by IHAXTLST or IHAXTL64. As the name implies, XTL64E_EXTENTADDR contains the address of the extent for this entry. And, not surprising, there is a similar field, also appropriately named, that contains the length of the extent. Applying both to XTLST and XTL64, it is relatively uncommon to need to know the information about the extents unless dumping the module. The entry point address is more common to use. Since you didn't provide any information about what you were intending to do with the information, I have no idea which would be better for you. Peter Relsonz/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Difference between STSI instruction and SYSEVENT QVS?
AFAIK (which admittedly might not be "far" enough), TFP prior to z16 had no information relevant to STSI. There are now TFP hardware records that apply variable capacity for which STSI surfaces information. Possibly QVS should surface that too and might be enhanced to do so. Peter Relsonz/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Registers in the RB
The fact that registers are saved (or at least land) in the "new RB" and the PSW in the "old RB" was described many posts earlier. That applies in all cases where a new (not "first") RB is created. Note that just when that saving happens can be kind of funky for a case such as XCTL(X). The problem that keeps cropping up in the posts is that the OP keeps making judgments and assumptions that are not true (sometimes because they are wrong, sometimes because they are incomplete). And these are under the guise of enhancing a general recovery routine that never was a general recovery routine, and based on the questions being asked will not be (because it won't be suitable for an FRR). Now if it's a general ESTAE-type recovery routine, perhaps that would be a reasonable goal. If we want to be picky, System 0C1 is not an abend code. System 0C4 is not an abend code. These are completion codes which might or might not result from ABEND. For purposes of example the hardware gives control to the program check FLIH for interrupt code 4 the program check FLIH issues ABEND abend code 0C4 reason 4 Well, not exactly. Let's try to be accurate. The program check FLIH issues SOMETHING that results in recovery seeing a system completion code of 0C4 reason 4. That SOMETHING happens to be CALLRTM TYPE=PROGCK, about which I will not provide any additional information. There is no ABEND at this point. By the way there are more reason codes for 0C4 than 4,10,11 as of z/Architecture. We keep saying that not everything that disrupts a running work unit creates an RB. It is therefore obviously the case that the registers are saved somewhere; they are not in a "new RB" when there is no new RB. Consider the case where there was a program check when there is an FRR. RTM understands how to convert a program interrupt code to a system completion code. It does so, so that it can place that in the proper areas (such as the SDWA and TCBCMPC and STCBCMPC), and it got the time of error regs from where the PC FLIH put them. If the FRR retries, no new RB was ever involved. But let's say that all FRRs percolate, now this is where my hint comes in. RTM issues an SVC D. This is unlike an application-issued (or other system-issued) SVC D. But it is still an SVC D which is a type 2 SVC and thus creates a new RB. Within this RB, the system places the time of error regs that had been stashed earlier.If you want to find the time of error regs and you can find RTM's SVRB, they are in there. As to the question about high halves (and ARs for that matter), they are saved in the XSB that corresponds to the RB that has the low halves. There was mention about SVC D as being an SVC that can be issued in any environment, such as being disabled (where normal SVCs cannot). That is not accurate either (although it's not unreasonable to think of it that way). When any SVC (x'D' is included) is issued in an improper-for-SVC environment, the same thing happens - the SVC FLIH issues CALLRTM TYPE=SVCERR. You don't get an RB for CALLRTM for a type 2 SVC (x'D' is included) issued in an improper-for-SVC environment. Flow then proceeds similar to the program interrupt case through FRR processing. If an FRR retries (ignoring a nested FRR), that's that, no "abend" SVC was successfully processed. If we need to get to RTM 2 for ESTAE (or even task termination) processing, then the special SVC D is issued. Peter Relsonz/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Registers in the RB
It was my understanding probably erroneously that when a RB I guess I am talking about a PRB gets interrupted and that can happen in one of two instances 1) An SVC 2) A Program check e.g. S0C1,4 It is true that the understanding is erroneous. There are many more cases where any RB can be interrupted, and it is not true that interrupt by SVC necessarily creates a new RB. I'm not going to answer beyond that since "asked and answered" would apply. That answer has been provided previously in the same general thread. But as a hint: SVC D is an SVC that creates an SVRB. Peter Relsonz/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Difference between STSI instruction and SYSEVENT QVS?
How about: STSI returns a lot of data that is not returned by SYSEVENT QVS? (or so I assume) How about: SYSEVENT QVS returns a lot of data that is not provided by STSI? (or so I assume) Now, if you were to ask about specific fields in SYSEVENT QVS, I think for certain ones the answer is "none", that SYSEVENT QVS obtains them from STSI. Reference was made to CSRSI. Do note that not all of STSI information is accessible via the CSRSI service; the data not provided was not thought to be of general enough use to make it worth providing (and using up the cycles and common storage to make it happen). Peter Relsonz/OS Core Technology Design I -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Data space dump with SDUMPX
The DSPLIST indicated * One entry (based on the length) * Jobname of "*" * Dataspace name of 1EDB The SDUMP requested only the current ASID. I'd guess that the system will only try to dump data spaces owned by ASID's that are being dumped (or a data space that is SCOPE=COMMON, AKA "a CADS"), applying the DSPLIST data to each such ASID looking for a match. If you are referring to multiple data spaces within the same ASID, they would not have the same name so it's not surprising you'd only get one. If GENNAME=YES was specified, they could have the same trailing characters, but the first (numeric) characters would differ. If you are referring to data spaces owned by different ASIDs, you might need to use an ASIDLST and identify the proper set of ASIDs. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How can I determine the User Name associated with the current Batch JOB RACF ID?
I had written At least in the past (I don't know if still true), there are cases where the ACEE might be what, very loosely, is referred to as encrypted in which case it would not be readable as-is. It's not truly encrypted such that you need some cryptography to decrypt it, but the intent is that the security product know what to do to provide you the "decrypted" info Charles M helped me realize that I was mis-thinking. It's the utoken that can be "encrypted", not the ACEE. Thanks, Charles. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How can I determine the User Name associated with the current Batch JOB RACF ID?
You can get it from ACEEUNAM. The intended interface is likely one of the RACROUTE variants (EXTRACT?). At least in the past (I don't know if still true), there are cases where the ACEE might be what, very loosely, is referred to as encrypted in which case it would not be readable as-is. It's not truly encrypted such that you need some cryptography to decrypt it, but the intent is that the security product know what to do to provide you the "decrypted" info Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Regarding RBINTCOD
Are you implying that an ESTAE(X) routine with SDWALOC=31 is guaranteed an SDWA and there is no reason to check R0 for 12 and alternate code paths? Jon P did write what I meant. Answer: no, it just makes it a lot more likely that the storage obtain for the SDWA will succeed. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Has there always been STIMER TASK?
This thread led me to wonder if there was a change from STIMER REAL (meaning a time interval, which is the default) to STIMER TASK (meaning a CPU time limit), or vice versa. Note that STIMERM does not support the "TASK" option (it was felt to be too complex, and not necessary, to have to deal with multiple such STIMER's associated with a task). A single exploiter can use STIMER TASK within the same task that has multiple exploiters using STIMERM REAL Using STIMER REAL to monitor task CPU time is not a good fit. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Has there always been STIMER TASK?
I looked at the APAR text and I would consider it inaccurate (and/or incorrect). >From the APAR text: It should be noted: IMS establishes a time limit using the STIMER macro and the TASK parameter to indicate that the time interval is only decreased when the associated task is running. Any ESS that WAITs or SUSPENDs the IMS dependent region will therefore not decrease the time interval during these events and will not drive STIMER exit routines to issue abends. Use of "time limit" and "time interval" surely is an unclear usage of terms. STIMER TASK provides a "CPU Time limit" (most would not think of it that way if they see only "time limit"). And there is no "time interval". The STIMER remains in effect as long as it takes to use that much CPU time. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Regarding RBINTCOD
Is there any way to know whether this is an SVC or abend I mean I know for SVC the length must be 2 but that doesn't mean it cannot be a abend Abend is an SVC. So you could conceivably look at RBINTCOD for x'000D'. A different question would be whether you can tell that the error was not initiated by the abend SVC but by CALLRTM TYPE=ABTERM or was a program check or an SVC error. In general the answer might be "no" because there is auxiliary information passed by RTM1 (think of an FRR environment, whether or not there are FRRs) to RTM2 via SVC x'D'. That auxiliary information is not part of the programming interface. But none of this is appropriate to do within a recovery routine. That is why there is an SDWA. And if the system was unable to provide the ESTAE-type recovery routine with an SDWA, then too bad (and encourage the creator to use SDWALOC31=YES (as is the case always for such recovery as ESTAEX and ARR). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: trying to identify different type of RB's
For a SYNCH(X) PRB, would RBCDSYNC be on to identify that RB? That bit is not part of the programming interface. It should not be important whether RBCDSYNC is or is not on.. If you're running within an ESTAE-type recovery routine, you can rely on that routine's having gotten control via SYNCH(X) and thus begins running in a PRB created by SYNCH processing. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking to invoke abend in IBM PC call Service
Pick your favorite service, look what abends it issues and code the parameters so that they match the thing that is complained about. How about STORAGE OBTAIN,COND=NO,LOC=24,LINKAGE=SYSTEM,SP=0 with a LENGTH amount of 16M, which will get the abend indicating "could not get the storage you asked for". Or pick any valid PC where the target routine takes a parameter area pointed to by a particular register, issue the PC, and set that input reg to x'_7000'. Some PC routines will field the error and retry with a bad return code. But many will percolate that error to user recovery. If you're asking about a space-switch PC, that restricts the choices, but the approach applies. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: sdwagrsv not equal rbgrsave
I chain backward as its the only way to do it wrapping around tcbrbp and next rb had the registers in the prefix it had SVC 12 maybe SVC 42 issued that "Wrapping around tcbrbp" is a strange way to do much of anything. More natural would be to start with TCBRBP to locate the newest RB and chain using RBLINKB to go as far as you choose to go. When you get to the relevant RB, you could/would/should have saved the address of the previous RB (the next newer RB). One of those RBs has the PSW; one of those RBs has the registers. SVC 12 is the SYNCH SVC which is how RTM gives control to an ESTAE. And that's why the PRB for your ESTAE is separated from the PRB for your mainline by an SVRB for the SVC D that got you into RTM. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HEALTH CHECKER (USS_FILESYS_CONFIG)
The fix was a RACF change to permit the id that Health Checker is running under access to BPX.SUPERUSER in the FACILITY class. I would have expected (earlier) message(s) to accompany that. The check itself would be in that state but I think HZS0109E would have been issued (along with possibly a message such as HZS0025I that mentions BPX1QDB or BPX1ENV) HZS0109E IBM HEALTH CHECKER FOR Z/OS ADDRESS SPACE USER IDENTITY DOES NOT HAVE ACCESS TO z/OS UNIX SYSTEM SERVICES Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: sdwagrsv not equal rbgrsave
sdawgrsv wasn’t in either TCB regs or rb regs If you had done what I written, you would have looked at all the relevant RBs, not only at a single RB.You apparently looked at the oldest RB. That sounds like it was the RB associated with the "mainline". Did you look at the next-oldest RB? TCBRBP points to the newest RB. RBLINKB navigates to the next older RB.RBLINKB of the last RB points to the TCB. I'm sure you know that. If you're looking within an ESTAE than look at the RB's I suggested. Peter Relsonz/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: sdwagrsv not equal rbgrsave
Simple experimentation will show what you need to know about what is saved where. For example, suppose your mainline links to another routine.You mainline's RB and the LINK target's RB can be examined. Or suppose your mainline has an ESTAE and abends.You can examine the mainline's RB, then the (next newer) RTM SVRB, then the (next newer) ESTAE routine's PRB. If you were trying to think about why it does what you will figure out that it does, you'd realize that the regs that the SVC interrupt handler processing wants to use have to be saved really quickly but the PSW is already captured (in SVC Old PSW). Peter Relsonz/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Direct branch entry to ICSF routines
>Could you share why it matters to you if there is a linkage stack entry (whether before or after getting to the "true routine", even if my guess is right about what you think of as the "true routines")? Performance. That doesn't provide much insight. What the callable services stub and the service do is generally the business of the stub and the service. For all I know, there is a BAKR on the front end and the target routine relies on being able to extract caller information from the linkage stack. It remains up to a caller to meet the interface requirements. Peter Relsonz/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Traversing The Linkage Stack
Joe R wrote I got to a X'89' is a header the doc say that decrementing that would bring to a new linkage frame I specifically remember looking - 32 bytes from there and it was all zeros. Not having ready access to that document, but knowing who wrote it, I'll bet that it does not say that. It certainly isn't true architecturally. You might look again at the architectural definition of the header stack entry (which I expect that that presentation shows correctly). Is it actually the case that you had only the one BAKR entry on the linkage stack and that is why the preceding entry descriptor was for the header? If so, of course there is nothing preceding that, which the rest of the information in that entry descriptor would have indicated. I don't recall that you ever posted what the linkage stack looked like (you showed only the entry descriptor and data that actually was irrelevant because it was part of the next entry). If true, despite being asked about doing so, why not? You misinterpreted data that you did not let the readers see, made incorrect conclusions and started with that. Really? What can we do to get you to post in a meaningful and useful way so that the kind readers of IBM-Main can help (without wasting unnecessary time)? Peter Relsonz/OS Core Technology Design Peter Relsonz/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: sdwagrsv not equal rbgrsave
Here is the SDWA as you can see the PSW matches how come the registers don't? Because the registers are not saved in the same RB that the scrunched-to-8-bytes PSW is saved in. Peter Relsonz/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?
The technical reason "why" is because it would be very difficult to do, would have adverse performance effects for the system, and there is not at this point a business case for providing it. So you're not going to get it just because you think it sounds nice (and even because it sounds "logical" to have it be part of the whole encryption ballgame). It would need to provide real business value. Please keep in mind that encryption is not about verification. It is about hiding. Program signing is about verification. Program signing is available for PDSE load libraries (not file system directories) and some level of program signing is now available for PDS load libraries to accommodate the needs of Validated Boot for z/OS). FWIW, the validation of a program signature has an unavoidable adverse performance cost too. For some situations, that cost is worthwhile (ICSF has a hard requirement in this area). If you have a business need for program signature of file system directories (more than a "it would be very nice if"), then by all means make your needs known. It might well not happen without your input. Peter Relsonz/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Direct branch entry to ICSF routines
Binyamin wrote does that means that the CSFDLL functions do not create a linkage stack entry before calling the true routines/ Could you share why it matters to you if there is a linkage stack entry (whether before or after getting to the "true routine", even if my guess is right about what you think of as the "true routines")? Peter Relsonz/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HEALTH CHECKER (USS_FILESYS_CONFIG)
You originally asked about the syntax error message. The syntax of the command used was incorrect, and I think the syntax error message was pretty reasonable. F HZSPROC,ADDREPLACE,CHECK=(IBMUSS,USS_HFS_DETECTED),USS=YES ASA101I SYNTAX ERROR: WAS SEEN, WHERE ONE OF 826 (CHECKROUTINE DATE EXEC INTERVAL REASON SEVERITY) WOULD BE CORRECT. DETECTING MODULE IS HZSIPMX It is telling you that it reached the end of the command, and you had omitted something required, which depending on what you were doing would be one of the keywords mentioned. But you should not be trying to "add" the check, because you have no idea how to do so. And you cannot "enable" a check by a command; you have to address the problem by fixing the environmental problem. As you show the problem is that the system does not think that you have USS enabled (or at least that was the case when the check ran). You will have to determine why that is the case. If USS is enabled, you might have to ask that the check be run again (its default interval is 24 hours; I don't recall if checks disabled waiting for USS get run automatically if USS becomes enabled). Those who suggested "E" or "Enable" might have been thinking of activate (rather than enable). Peter Relsonz/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Traversing The Linkage Stack
>From one of the posts, it wasn't clear if the OP realized that the entry >descriptor is at the end of the entry, not at the beginning. If you're not traversing stack sections, complications related to header and trailer don't tend to come into play. Consider posting the entire linkage stack from start through time of error, along with the data from the SDWA which the OP indicates is not in the linkage stack. Unlike AI, RTM does not make stuff up. If there is a PSW, RTM found it somewhere, either in an RB/XSB or the linkage stack. If there is a problem marking the PSW as "from a linkage stack entry", that would be good to know. And for that, the information I mentioned above (plus all the data from the RBs/XSBs) would be needed for diagnosis. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Help Trying to determine where abend occurred
>the doc says I can issue CSVQUERY in AR mode I might try to put SDWAPRIM on my >DU-AL Allowing a service to be issued/called/invoked in AR mode does not imply "the service will pay attention to any access list entry". CSVQUERY processing does not pay attention to any access list entry. CSVQUERY processing looks at data within only the current-primary address space. You might consider "If I am now running with my primary ASID matching the value in SDWAPRIM then use CSVQUERY to try to associate a module name with the time-of-error address". That has no bearing on the address from SDWAEC2 because the logic above would be wrong if the address from SDWAEC2 is prior to a space-switch PC and your recovery is ESTAEX, ARR, or IEAARR or some forms of SETFRR (namely, the recovery routine cases for which the recovery routine's primary address space is the primary address space when the recovery was established) Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Help Trying to determine where abend occurred
Joe R wrote Seems that sdwaec2 points to the code in the pc routine while sdwaec1 points the home address space right after the pc instruction wondering if I can always make this assumption As Walt F pointed out, there is documentation about these fields in the assembler services guide. I think that makes it clear what is in SDWAEC1 and SDWAEC2 under which circumstances. As to the assumption about "the home address space", that would be a valid assumption only if you know that the primary address space equaled the home address space at the time of the instruction (PC in this case), which is not in general the case. The PC would have been an instruction in the pre-PC primary address space. Do note that instructions are fetched from the home address space (not the primary address space if the two differ) for home ASC mode. But since you cannot issue a PC in home ASC mode, that does not apply to your case. And in practice, all code that uses Home ASC mode is in common storage. My question is there any field in the SDWA or extensions that would tell me in what ASID the abend occurred I'd look at SDWAXM, specifically SDWAPRIM, unless the error was in home ASC mode in which case you don't need to look at the SDWA but can use PSAAOLD -> ASCBASID. SDWAPRIM is the primary ASID at the time of error. Is that what you mean by "in what ASID the abend occurred"? If the error was a storage access using an ALET, the erroneous reference could have been to any number of (address or data) spaces. You seem to be pursuing something that might not be overly useful for a recovery routine. The recovery routine of the PC issuer would typically rely on footprints set by the PC issuer's mainline to understand what the mainline was last doing (and thus how the recovery routine needed to react). The recovery routine of the PC target would typically not care about where the PC was issued from. A diagnostician, of course, might well care about both, but they would typically be looking at a dump. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question about IEAMSCHD
>Binyamin wrote :> :>What is a "non-authorized" address space? :> :>Everyone I know would consider that to be an address space for which the jobstep program is not both linkedited AC=1 and gotten from an APF-authorized concatenation, and is not a system key address space (as could be defined in such places as the program properties table). In the context of SRB? I'd say "yes" (or "not applicable" since this is about an address space, not about whether a work unit is or is not currently running in a system state - which I would characterize as supervisor state or PSW key 0-7). SRBs (key 0 supervisor state typically) can run in unauthorized address spaces. The authorization of the address space is not related to the authorization of an SRB running within that address space. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PLIST8=NO?
,PLIST8=YES ,PLIST8=NO Then: PLIST4 and PLIST8 cannot be specified together. But can PLIST8=YES and PLIST8=NO be specified together? That's not explicitly prohibited. According to the syntax-description conventions used in this book (and other similar books), it is explicitly prohibited. According to that convention, these two options are mutually exclusive. Further, the assembler complains if you specify both. That is the case with any keyword on any macro. ** ASMA018E Duplicate keyword in macro call; last value is used - CALL /PLIST8 Register Contents 1 Address of the parameter list, if present Are the contents unpredictable if the parameter list is absent? More precisely, "not defined". As always, it is up to the caller to comply to the requirements posed by the callee. If // EXEC PGM= refers to an AMODE 64 program, does the initiator provide an AMODE 64 plist? The answer is "no". That is documented. It cannot in practice be otherwise; the AMODE attribute of the program is not known by the system at the time that the parameter list/area is built. running Accurate wording would have been "if SYSSTATE AMODE64=YES is in effect" rather than "if running AMODE 64" and similarly "if SYSSTATE AMODE64=YES is not in effect" rather than "if running AMODE 24 or AMODE 31". I don't understand why often these cases of someone pointing out ways that documentation could be improved (and there are innumerable cases in which documentation can be approved) are solely voiced here as a complaint and are never submitted as a suggested update (such as via feedback on the page), with suggestion for how exactly to improve it. I am curious: did this wording cause you grief? If it did, then please help others too by making sure that the flaw is pointed out to those in charge of changing it (and pointing out on IBM-Main is generally not as helpful as getting the publication itself updated). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question about IEAMSCHD
Paul D wrote "To run an SRB routine in a different address space from the scheduling code, the SRB routine must be either in a different program that is accessible from the target address space, or in the common storage together with the scheduling code." This is nothing more than a statement that you cannot have the SRB routine be in the private storage of the address space of the scheduler in such a case. The SRB routine has to be addressable in the target address space and thus can be in the private storage of the target address space or can be in common storage. If you want it in private storage, it is up to you go get it loaded there. Steve B wrote I have the code to turn on the JSCBAUTH however it is a SVC I sure hope no one lets you install that SVC on a system that anyone cares much about. Except in a vanishingly small percentage of cases, this is an extreme system integrity violation. Binyamin wrote What is a "non-authorized" address space? Everyone I know would consider that to be an address space for which the jobstep program is not both linkedited AC=1 and gotten from an APF-authorized concatenation, and is not a system key address space (as could be defined in such places as the program properties table). Starting (and even running) in problem state and user key is not enough for the characterization. The user program in a non-authorized address space cannot switch itself to an authorized state. Of course within a non-authorized address space at various points code runs authorized (such as after an SVC or a non-space-switching PC that is defined to execute in supervisor state and/or a system key). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CDE Extension for RMODE 64
R15 has bit 63 on I would assume Yes, reg 15 would be set up to be suitable for use by BSM 0,15 (AKA "pointer-defined") hence having bit 63 on when you want the target to be AMODE 64 (as you would need for an address above 2G). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CDE Extension for RMODE 64
when you say not every CDE is built by z/os are you referring to the IDENTIFY Macro...? No I am not. IDENTIFY is part of z/OS. I am referring to non-z/OS programs that obtain storage for CDE's and chain them into the z/OS control structures such as the job pack queue TCBJPQ. Also I noticed that the retry address is only 4 bytes. I guess then to you would have to retry to a label in the program that has RP instruction And have your recovery set it up before returning to RTM You noticed correctly. Neither retry addresses nor (more broadly) recovery routines can be above 2G. However, your guess is not what anyone is likely to do. The CVTBSM0F field was provided for this purpose. You set up 64-bit retry reg 15 to the address of your above-the-bar retry address. You make sure that that reg 15 will be used for retry (SETRP with RETRY15=YES, if an FRR; RETRY15 does not apply for ESTAE-type retry so that case is fine without RETRY15=YES). You set up the retry address to the address of CVTBSM0F (not the contents of CVTBSM0F, that would not work). You make sure retry is AMODE 64. Retry goes to CVTBSM0F, the instruction there which is BSM 0,X'F' takes you to the target located by reg 15. The system trace entry for that retry contains the value from reg 15, not the address of CVTBSM0F. Aside from the trace entry manipulation, you could accomplish this by yourself with some other register if you had a need. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CDE Extension for RMODE 64
If bit CDCEX in the CDE meaning there is an CDE extension would that imply the module is RMODE 64 since CDXEntpt64 is a double word A simple glance at a CDE in storage for a module that is not RMODE 64 would show you that this is not the case. Every CDE built by z/OS has a CDX, as does every LPDE. The CDCDEX / LPDECDEX bit is on in each.. Not every CDE is necessarily built by z/OS (to our regret). A module is RMODE 64 (or has an RMODE 64 extent) if it has an extent that is above 2G. Extents are normally in the area pointed to by CDXLMJP of a major (non-alias) CDE. Since those extents have only 4 bytes for the extent address, that won't cut it for RMODE 64. A CDX (when it exists) might have an "XTL64". The interface parts of a CDX are mapped by IHACDX. The extent list 64 (mapped by IHAXTL64) has an 8-byte address for an extent. There is also the fine point of whether you are talking about "is the module defined as RMODE 64" or "is the module in 64-bit storage" or "is some extent of the module in 64-bit storage". The answer to the first question is within the directory entry. AMBLIST is one way to display that information (or doing a BLDL or a DESERV GET). The answer to the second and third questions lies with looking at the XTL64. If CDXXTLST64Addr is not 0 and if every extent is above 64 then you'd consider the answer to the second question to be "yes". If CDXXTLST64Addr is not 0 and if some extent is above 64 then you'd consider the answer to the third question to be "yes". If CDXXTLST64Addr is 0 then the answers to the 2nd and 3rd questions are "no". It does happen to be the case that if you look at the extent list pointed to by CDXLMJP, if one of the extents has an address >= x'7000', that correlates to "the extent is actually above 2G" and in that same entry the length is "1" (these being indicators that the real extent definition is in the XTL64 because it does not fit in the XTLST. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RETRY - was ARR and CSVQUERY
Tom B wrote I was referring to my experience with a JES2 exit which setup its own recovery routine. In that code you could see it free any getmain'd memory, etc. like you mentioned. But also in that code was an error that caused an 0C4. So when the x'00' I added for temporary debugging ran that user-coded recovery routine, I was surprised to get an 0C4 instead and had to fix the recovery routine. So of course JES2 had its own recovery routine in place that handled the 0C4 and we got a dump and JES2 went on its merry way, perhaps after disabling that exit (I can't remember). I took a weird view of what I suspect you really meant by "0C4 instead". I'm now thinking you just meant that you were surprised that the recovery routine did not complete successfully. But in case you were thinking of what happened to come to my mind, here's some info: When the x'00' "instruction" was executed, it would have gotten an operation exception and the most recently established recovery routine (see "special-case" below) would have gotten control for the 0C1. Its SDWA would have shown that. And TCBCMPC would be x'0C1000'. If that recovery routine then took some exception that resulted in an 0C4, a newer recovery routine (established by this recovery routine) or, in the absence of such, the next-oldest recovery routine would have gotten control for the 0C4. Its SDWA would have shown that . TCBCMPC would now be x'0C4000'. Special-Case: if you have established SPIE/ESPIE for a program interrupt, that exit will get control even if there is a newer-established ESTAE-type recovery routine. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RETRY - was ARR and CSVQUERY
Tom B wrote >So are you implying that in z/OS there are environments where I can run >a program without any built-in basic recovery? To be a bit snide, you "can" run a program without any recovery, of course. Whether you should or not is an entirely different question. I view their being two main reasons for recovery (and not necessarily in the order I show): First, to deal with resources that might otherwise be left in an undesired state if you don't have recovery. Maybe that's storage you obtained or an ENQ or lock that you hold or any number of other things (perhaps even that you prefer to return to your caller with a return/reason code in that case rather than an abend). But if you know that the system will release the resource in question in a timely fashion, maybe you don't care. For example, suppose you know that you are the jobstep program and you obtain private storage in a jobstep or task-related subpool and blow up, Maybe you don't bother freeing it because you know that the task will terminate and the system will free the storage (in your mainline you would probably free the storage for cleanliness reasons, but maybe you take the cheap way out in an abend case). But if you might be called by something else, that's a different ballgame. In that case, you do not know that the task will terminate - the caller might have recovery that retries. Second, to capture serviceability data such as what was running and what was going on in order to help diagnosticians. That might be information in the SDWA and your use of recording to logrec; it could be a message written to the job log (but calling almost any service out of recovery might mention having recovery to protect something bad happening within that flow). It could be a dump of some type. In the "freeing storage" case, maybe the recovery isn't so much about freeing the storage but more about capturing data to help someone figure out what went wrong Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RETRY - was ARR and CSVQUERY
Jon P wrote The SDWA can be referenced by alet 0 or alet 2. Perhaps this was referring to the specific example. But in general, if this was meant to indicate that you could choose either, that wouldn't be true for an ESTAEX or ARR or IEAARR established for primary <> home. The SDWA is in the primary address space of the recovery routine given control (for an FRR, it's in common storage, so the ALET is not important). Peter Relson z/OS Core Technology -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RETRY - was ARR and CSVQUERY
If you haven't changed the data or conceivably the environment, retrying the instruction will get the same result. That shouldn't be a surprise. If you were to try, you'd likely have to decipher the instruction so that you could figure out what data and/or regs it was using and make sure to change something for "the next time". I believe long ago it used to be the case that the PL/I compiler (this was before "C" was anything more than the 3rd letter of the alphabet), would get control for a page fault or segment fault on data that it knew about, set up the data so that a retry of the instruction would work, and do so. Thinking about this now, we have no idea how it could do that in a predictable way (since it would get control for "normal" page faults too). Of course, the architecture accommodates and allows retrying the instruction. That is used by the system when (for example) a page fault occurs. The system stops the work unit, asynchronously pages in the page (when the page actually was valid but paged out) and resets the work unit to re-execute the instruction. And the program old PSW's instruction address for a page fault doesn't even need to be backed up to get to the right place to re-execute. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CSVQUERY in ARR routine return code 8 didn't have PLISTVER=MAX On CSVQUERY
Ed J wrote Always code PLISTVER=MAX on the list form but (based on recent experience) *never* code it on the execute form of a macro unless you want to risk things not working as expected on back-level systems. I'd make it "almost always". The case that comes up occasionally, and is a reason that the default is not PLISTVER=MAX, is when someone has embedded the list form in a structure (not at the end) so that if the size changed, fields beyond this structure would have changed offsets and if you didn't recompile everything appropriate things would break. That potential incompatibility drives the default. And, yes, the default has the downside that if your list form "gets it wrong", things don't work. Compatibility wins in this case. The documentation for PLISTVER (at least within the macro itself) includes: If your program can tolerate this, IBM recommends that you always specify MAX when creating the list form parameter list as that will ensure that the list form parameter list is always long enough to hold whatever parameters might be specified on the execute form. The part to be careful about is "If your program can tolerate this". Maybe you have embedded within a structure; maybe your program has a highly limited amount of dynamic storage available. Those could be cases where you cannot "tolerate this". Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CSVQUERY in ARR routine return code 8 didn't have PLISTVER=MAX On CSVQUERY
Once again, the lack of providing sufficient information about what was actually done has wasted the time of the good folks on this listserv. I suppose it might be said that we enable this bad behavior by responding. I intend to stop responding for this sort of case from repeat "offenders". "Sufficient information" may include the source but should include the data passed to the service (and in this case information from a dump showing the job pack queue CDE's). Of course before posting, you ought to look at that data and see that it matches your expectation. I.e. do your due diligence and "prove it". Lack of PLISTVER=MAX on the list form can result in the area for the parameter list being too small, with the result that the execute form expansion overlays something following it which perhaps something relies upon. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Assembler optimization OPTION
The starting point to almost all of these discussions tends to be to write reentrant programs (as high level languages naturally produce). If you must stick with a non-reentrant program, consider the LOCTR directive. If you don't feel like truly moving the data-defining statements within your program, you can use the LOCTR directive to help to "move" data to a separate area. You might have an area for your "code" and an area for your "static data" and an area for your "dynamic data" Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Parameters to ARR routine
Tom H wrote
There is another difference between running under an ESTAEX and an IEAARR, and
that is you cannot use IEALSQRY to determine the linkage stack depth if you
need it for retry. You must keep track of it yourself.
That's a good observation. And you're right. But it is not intentional. That
was an oversight from when I created IEAARRs 25 years ago. Those PC numbers are
treated specially by RTM and do not have a "true" ARR (which is why IEALSQRY
does not play well with that situation), rather the linkage stack entry itself
has the information needed to give control to your recovery routine. No one had
ever brought that to my attention.
"You must keep track of it yourself" ("+1" after BAKR, "-1" before PR) is often
just as easy as, and is always orders of magnitude more efficient than, using
IEALSQRY. Of course that does require that all the routines have access to the
field where the current level has been saved (so they can increment/decrement
as appropriate), unless (for example) each routine has a recovery block that
keeps track "for it" and some over-arching code can run these blocks and
determine the appropriate value needed.
Peter Relson
z/OS Core Technology Design.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
I have to pass the token from ETCON returned in register 0 some how to the client
Joe R wrote (applying his minor correction) I have to pass the token from ETCRE returned in register 0 some how to the client Many have chosen to accomplish this by use of a global control block that their clients can access or by a system-level name/token pair. Note that ETCON is restricted to authorized callers. If you need unauthorized callers to connect, you will have to provide a way for their task to get authorized in order to issue the ETCON. In many cases, that might be by your providing a PC definition that uses a system LX to avoid the chicken-and-egg situation, since the system LX does not require use of ETCON (aside from by the creator). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
