: Re: Subpool 0 Usage
The reason for "not" that comes to my mind is: * if you are authorized and could run in "someone else's" (unauthorized) address space, your usage of subpool 0 is almost always going to be a system integrity error. And not limited to subpool 0. It would apply also of ANY low private subpool: 0-127 (and 131-132 depending on the key) There is nothing wrong with an unauthorized application using any of the low privae subpools. After all, they can't use anything else. Peter Relson z/OS Core Technology Design
Re: Getting to CVT with FLAG(PAGE0)
John K wrote: I had to turn off FLAG(PAGE0) for SWAREQ and TRKCALC. SWAREQ addressed this almost 15 years ago. TRKCALC was changed over 15 years ago. Please avoid using ancient versions of macros. Shmuel wrote: The obvious example is CVTPTR, which currently is an absolute EQU. Changing that to a DS A would break compatibility. Any ideas on how to resolve the PAGE0 issue while remaing compatible? Does it require an HLASM enhancement? This was in response to my post that told what to do. So I don't know why the question is being asked. Jonathan's post (and any number of macros) show what to do. Michael S wrote Does this mean: A. Yeah, it is going to give that warning. You have to consider each case to determine if the warning is valid or not. B. I'm coding it wrong. C. I'm coding it right but there's a better way to code it that won't trigger the error. I like my compiles and assembles to be clean: no warnings. So I'm not a fan of option A. I suppose I could put in a compile option to set FLAG(NOPAGE0) in programs that are getting to the CVT. I'd have chosen choice D: "You're coding it in a syntactically correct way that you have asked to be flagged in case you have some other case that was not intended". And I'd choose the action that would logically go with your choice C. Now that you have found 2 errors and 2 cases of CVTPTR, you'll fix the errors and I'd think (least work, and most effective) change your uses of CVTPTR to specify a base reg of 0. . Peter
Re: Getting to CVT with FLAG(PAGE0)
Turning off FLAG(PAGE0) is never necessary within your own code. Adding explicit base reg of 0 (not an index reg of 0) is the technique to indicate you know what you are doing and thus override the flag. You will see that within many macro expansions the need to reference the CVT without requiring the invoker to include the CVT. Maybe there are some macros that don't do that. If you find any in z/OS, let me know and maybe we can get that improved. Peter Relson z/OS Core Technology Design
Re: The best way to check any virtual address
My summary: the best way to check any virtual address is not to check it. You use the address as the interface intend it to be used, with suitable recovery (be that FRR, ESTAE/ESTAEX, ESPIE) and handle blowing up when it turns out that it is not valid. Sure, there are cases where you could find that the address is not valid and avoid a "recovery path", but you'd usually still need to have the recovery path/protection to avoid a time of check to time of use exposure. And why would you care about a long path if your caller gave you improper data (if anything, such "punishment" might be "incentive" for them to get it right). LRA was mentioned, but it's got the same situation as TPROT. If the data is properly paged out, LRA and TPROT will not give a result that is helpful (unless you require/expect that the data is page-fixed). For example, I could use TPROT on a purported ASCB address and if I didn't get success, I'd know it wasn't an ASCB address (because an ASCB cannot be paged out). Peter Relson z/OS Core Technology Design
Re: Instructions by Machine
Mike Shaw wrote This _gold_ for ISVs writing code that must execute on many different z models. Thanks to Dan and Yves for all the work. For Dan's, I'd suggest (somehow) adding a "key" to the 2-character facility names (I know most of them, but many might not, so it could be helpful to have the "long name"). I couldn't see "which facility" in Yves' table (and I think that's really important because even if it's on a machine that doesn't mean you can use it on a given OS or even a given environment for a given OS) I'm curious in exactly what way this information on a machine basis is a lot of help. I certainly agree that it's nice to know what instructions you are "free to use". And for that, having the information by facility is (to me) most helpful. With or without the opcode table, you still likely need to pay attention to architecture level set (which is not by machine, but rather by facility). For z/OS, that is documented here: https://www.ibm.com/docs/en/zos/3.1.0?topic=system-identifying-server-requirements within Table 1. Minimum server levels and machine facilities that are required for z/OS Most cases I would think would choose to limit their instructions to those available in facilities known (by architecture level set) to be available on all the releases you are choosing to support. And something done "if available" would be checking the facility bit at run-time. Is anyone really looking at "machine model" to determine availability of an instruction? That would not ordinarily be a good idea. If I were creating this for z/OS, I'd like a table of "show me all the instructions I know that I can use for each z/OS release" (with an indicator, perhaps, of which were added since the previous release). That gives you the direct way to see what you can rely upon being available, for whichever you choose as your oldest release. Maybe that's just me. Peter Relson z/OS Core Technology Design
Re: IEABRC anomaly
I don't recall having thought about this when providing IEABRC. But the conclusion that it's not going to get added is likely a correct one. Without a complex macro (which definitely is not going to happen), changing NOP to JNOP for the cases Jonathan Scott mentioned will reject operands that are fully valid (avoiding RC=4 if you suppress ASMA212W Branch address alignment for unfavorable). I believe his case is a very common one of using the operand of NOP for diagnostic purposes. While NOP perhaps isn't a branch (because it never goes anywhere), it is the conditional branch opcode so could have been a candidate for conversion. But functionally it is not necessary. Anyone who truly wants conversion of the operand for some reason could avoid using NOP and code a conditional branch with mask 0. That will get converted. Peter Relson z/OS Core Technology Design
Re: Complex immediate fields
Gil asked Are instruction pages REFReshable? z/OS does not refresh anything (be that instruction or data), whether the module is identified as refreshable or not. The only thing z/OS now pays attention to with respect to the refreshable option relates to the REFRPROT option, for which the whole pages within a module are page-protected. When made page-protected (outside of a store using a real address) you cannot modify them (whether key 0 or not) - you indicated that, whether the OS supports refreshable or not, that the module can handle it, and a module that can handle being refreshed is treated as one that better not modify itself because at any point it might be refreshed back to a previous state. Peter Relson z/OS Core Technology Design
Re: OPCODE tables
Dan Greiner wrote At execution time, the only safe way to ensure that an instruction is present in the configuration (other than taking a punch on the chin if it's not) is to query whether the respective facility is installed by means of the STFLE instruction. If on z/OS you might be able to take advantage of the architecture level set (ALS) for each release. The list of facilities upon which you may rely for each z/OS release are listed. I look here: https://www.ibm.com/docs/en/zos/3.1.0?topic=system-identifying-server-requirements If POp indicates that an instruction will get an operation exception if such and such a facility is not available, and you are allowing your product to run on a z/OS release that does not include that facility in its list, you could/would be putting your customer at risk. As Dan points out, some things are available on a machine but not surfaced to the user, depending on release and on environment (such as whether running as a guest under z/VM). I'd imagine that very few instructions are worth determining at runtime to see if they are available and dual-pathing your code Note of caution: IBM has issued a statement of direction about withdrawal of the transactional execution facility, even though it is part of the z/OS 2.4 ALS. Peter Relson z/OS Core Technology Design
Re: Decimal Floating Point Numbers
I am imagining (and could easily be wrong) that the hex data is identical across the views (and thus the instruction implementation does not care about the view), and it's only a question of which bits you choose to look at (or what arithmetic logical manipulation you use) if formatting the value for human consumption. For example, the exponent differs, as does the significand (a term I had not known of until seeing it in the POp). I don't know what kind of dump was being looked at, but perhaps there's a formatting option within the dump viewing program that might say "show me this as a Right-Unit View DFP value". Peter Relson z/OS Core Technology Design
Re: Reseting RMODE
I cannot imagine anyone being willing to implement an "RMODE MIN" whose only purpose is to allow you to specify an RMODE statement multiple times in one CSECT with different values. Functionally, at the cost of 8 bytes (and it conceivably can be accomplished with 0, but I have not tried), state the problem clearly and do not assume a solution: Apparently, you want, at the end of the "module source", to indicate that, despite what someone might have coded earlier in the source, that you really want RMODE 24. Then perhaps just add DUMMYCSECT DUMMYRMODE 24 NOPR 0 immediately before the END The assembly will work fine. And when you bind it, the "minimum" across the CSECTs is what will by default be used. Peter Relson z/OS Core Technology Design
Re: Reseting RMODE
The starting point regarding using a DCB (that does need to be below 16M) is that use of non-reentrant code is discouraged (if for potential performance issues if nothing else, if you have not well-separated the instruction and static data from dynamic data). Any reentrant module will naturally be getmaining its dynamic storage and may choose to have that storage be LOC=24 if that is what it needs. Or the DCB can be acquired separately, while having the module be RMODE 31. RMODE for a module, as have been stated very clearly by multiple folks, cannot be "switched" mid-stream because that is not how the module was loaded into storage. You can have multiple CSECTs in a load module or program object, but unless it is a program object with RMODE=SPLIT the overall RMODE will generally be the least common denominator (i.e., RMODE 24 if there is an RMODE 24 CSECT even if everything else is RMODE 31). As to why we do not support tri-modal RMODE=SPLIT: $$ and performance and avoiding undesired increase of common storage. I've lost track of what z/OS-oriented cases require AMODE 24 (and provide no way to get appropriate functionality if AMODE 31). RMODE 24 for data such as a DCB, affects only non-reentrant modules. So try to avoid that. Peter Relson z/OS Core Technology Design
Re: comment continuation macro invocation
I just thought it was odd that the continued comments column is different for an instruction vs a macro. Perhaps the difference is that the data in column 16 of the continuation line of the macro invocation is actually part of the macro invocation, not a comment. Consider: MACRO M &A=2,&B=3 LHI &A,&B MEND With M A=1, this is <* in col 72> B=1 a comment Which is the same as M A=1,B=1 M A=1 this is a comment which gets ASMA432W Continuation statement may be in error - comma omitted from continued statement. and M A=1 this is a comment which is fine. The definition appears to let the assembler help with a common trivial error (at the cost of minor annoyance if you really wanted a comment), While letting you provide a nicely commented macro invocation (perhaps putting a comment on each line with keyword=value) such as M A=1,Set the A parameter to ...<* in col 72> B=2,Set the B parameter to ...<* in col 72> ... Peter Relson z/OS Core Technology Design
Reseting RMODE
It sounds like the OP might not fully understand RMODE. RMODE is a directive to the binder and loader of where in storage to place a module. As was mentioned, the granularity is on a section basis, and the directive is applied at module fetch time when store is acquired into which to place the module. The module is where the module is. If you need to be in AMODE 24 "at some point" then that part of the module must be RMODE 24. The RMODE of a load module or program object is generally the minimum of the RMODEs of the sections that comprise that executable. An exception is, as Ed Jaffe mentioned, when something like RMODE=SPLIT is used on the bind of a program object. In the RMODE=SPLIT case you can end up with one part of the executable in one RMODE and the other part in another RMODE and V-Con's between the two parts are resolved at module fetch time. Peter Relson z/OS Core Technology Design
Re: BAKR/PR and Linkage Convenction
The rule for just about anything is "the fewer cache lines you can use, the better". How you accomplish that (if you even choose to try) is a matter of programming (not necessarily a simple matter of programming). As Jonathan Scott mentioned, if you're going to try to "align" you at least need to make sure that your module is on a strong enough boundary. If you want to do cache-alignment stuff (i.e., 256-byte boundary) within a module, you'll need your module loaded on a page boundary. z/OS does not support loading modules on boundaries other than doubleword and page (and maybe, going forward, 1M-boundary for RMODE 64). Most relative-branch modules find the need to have a static area (whether for literals or other things) and find it convenient to locate such an area with a register (a base reg for static data, in this case). Various z/OS macros require addressability to wherever a literal generated by the macro might get placed. Obviously you could set that up temporarily with LARL, wherever needed, if you choose not to devote a reg for that purpose. Peter Relson z/OS Core Technology Design
Re: The interaction between LSEs and ESTAE-cancel (was Re: BAKR/PR and Linkage Convenction)
Jon Perryman 3. Abend recovery can be more difficult. It's been a long time but if I > remember correctly, ESTAE creates a linkage stack entry and an abend causes > linkage stack entries to be flushed up to the ESTAE entry thus limiting > recovery to the CSECT which requires setting up recovery environment for > each point that requires recovery. That's not quite correct. What happens is this: * ESTAE-create does not create LSEs (Linkage Stack Entries). What it does do is mark the LSE that is current at the time of ESTAE-create. * Then ESTAE cancel will purge all LSEs that are newer that what existed at ESTAE-create time. That can be quite a rude surprise if you're using BAKR/PRs without regard to ESTAE-create points. That's not quite correct either. ESTAE(X) cancel does not do that. The sequence of ESTAE(X) create, BAKR, ESTAE(X) cancel is rejected with return code x'24' because you are not canceling from the right linkage stack entry. It is retry from any recovery routine (ESTAE-type or FRR-type) that by default resets the linkage stack to the time-of-set entry. You can consider that a "purge" if you want. It doesn't typically have to do anything to "purge", just reset the "current pointer". This default can be overridden by setting SDWALSLV within your recovery routine. For example, set to 2 if you want the retry to be two entries past the time-of-set linkage stack level. There are authorization restrictions with respect to how far you can go. Perhaps you were thinking about PR canceling an ESTAE-type recovery routine that is associated with the former linkage stack level. That does happen. That is analogous to what happens if you end an RB with which an ESTAE-type recovery routine. ESTAE-x recovery is removed by the system automatically when the RB with which it is associated terminates or when the linkage stack entry with which it is associated is removed. BAKR is simply not a great approach for saving registers from module to module. Recovery complications are one of the downsides. Performance is another. Limitation on the size of the linkage stack (unless you expand it) is another. Most find that BAKR is nice for initial entry, but intra-component linkage is better handled with save areas. You're not going to want to set up new recovery for every module that gets control (both for complexity and performance). Many z/OS components have the concept of a "recovery mainline" with individual modules each providing a "module recovery exit". The recovery mainline calls each appropriate module recovery exit, so that the module recovery exit can take care of logic specific to that module, with the recovery mainline doing the routing and taking care of logic that is general to the flow. We find that that makes it more natural to keep recovery in synch with module changes. Peter Relson z/OS Core Technology Design
Re: BAKR/PR and Linkage Convenction
Tom M wrote: > This is documented in chapter 2 of the Assembler Services Reference. Tom meant the Assembler Services Guide. And he probably feels bad about that mis-reference because he helped write that section. This is the Linkage Conventions section. If you're saving only the low halves of the GRs, an 18-word save area provided by the caller is recommended. If you're saving only the 64-bit GRs, a 36-word save area is recommended. If you're also saving access registers, the standard convention is to use the linkage stack (there are mapped approaches that use a larger save area that can hold both GRs and ARs). Do note that there are limits to the number of entries you get by default on the linkage stack. And keep in mind that ESTAE-type recovery routine retry is sensitive to the linkage stack level when the routine is established. Peter Relson z/OS Core Technology Design
Re: ASMA057E Undefined operation code SR 15,15
Everyone came up with the right alternatives. Among XR, SLR, and SR, XR is thought best (not necessarily measurable better). If you don't need a condition code (and certainly if you need to preserve a condition code), LHI is thought best. I'm not sure to what extent the fact that the first three are 2-byte instructions and LHI is a 4-byte instruction comes into play. It is apparent that LHI creates a bigger instruction-space footprint. That in turn can lead to increased cache line usage. Peter Relson z/OS Core Technology Design
Re: ASMA057E Undefined operation code SR 15,15
This was a very lengthy thread in which the OP multiple times ignored those who correctly provided what was needed. I don't know why the OP would not simply take the advice and proceed. The error has nothing to do with "label", although the lack of allowing "label" is not typically good. The operand was not specified in column 1. As was mentioned, the single macro variable was treated as "the opcode". There is no "opcode" of "SR 15,15". That is the way assembler macro substitution works. Should it? Maybe not, but history and compatibility demand that it not be changed. All of the approaches demonstrated in the macro below work: MACRO ZERO &N SR&N,&N &OPCODE SETC 'SR' &OPERAND SETC '&N' SR&OPERAND,&OPERAND &OPCODE &OPERAND,&OPERAND &OPERANDS SETC '&N,&N' &OPCODE &OPERANDS MEND And then add support for a label for better usability. (I think older releases of the assembler used to require &LCLC for each SETC symbol, but apparently that is no longer required.) I saw no mention that "SR" is at best the 4th best choice for zeroing a register. I'll leave the other 3 (and perhaps more) as an exercise for the reader, for a while. Peter Relson z/OS Core Technology Design
Re: Variable-Length Parameter List Attributes
Regarding "object modules", I'd have said that a lot of (almost all?) IBM-supplied products ship that way. These "object modules" are in what we think of as a "distlib" or "distribution library". You will find them on your installing system. SMP/E (or something) parses the ++MODs in a PTF into object decks that are generally individually bound as "object modules" into the distlib. Later the bind of distlib object modules (sometimes coupled with existing load modules / program objects, but often solely done with object modules) produces the requisite load module / program object. Peter Relson z/OS Core Technology Design
Re: IARV64 REQUEST=DISCARDDATA Question
As this function can never return partial pages, it will always be zero upon first use. To be picky, the "As" phrase of this is not quite true. IARV64 does not, but could return a partial page, such as a partial 2G page for a smaller request when the conditions were right (but the implementation does not do that). The conclusion is, similarly, not quite true. It does happen always to be zero. A different (likely felt to be insecure) implementation that did not clear pages upon new usage when those pages had been used, but are no longer in use, would not guarantee "always be zero". In any case, that's why we agree that it would be nice to document. Peter Relson z/OS Core Technology Design
Re: IARV64 REQUEST=DISCARDDATA Question
Mike Shaw wrote The doc does not say what that memory object's pages contain just after IARV64 REQUEST=GETSTOR is issued. The "doc" actually does say so. But it's not surprising you didn't notice it, because it's in the "guide" (and not in a section specifically for IARV64) rather than in the "reference" for IARV64. The macro has "The initial value of storage within a memory object is binary zero." The assembler services guide has "IARV64 GETSTOR service creates memory objects; storage is cleared to zeros". We will look into updating the reference's GETSTOR function to have the same information. Peter Relson z/OS Core Technology Design
Re: Self-documenting Bit Settings
Dave Clark asked > Where do you draw the line? You really don't have to draw a line. You give the macro user a way to say "don't do this checking". You're not trying to "prevent", you're trying to "help". So if there's a need to do something other than you've accommodated, let it happen. Some z/OS system commands have an "OK" option which can be used to indicate (for example) "normally, you would prompt to confirm that I know what I'm doing, but since I do know what I'm doing, I'm telling you not to bother asking" because it can be easier not having to deal with a WTOR to respond to. Here, some "CHECK=NO" option would indicate similarly "I do know what I'm doing". Peter Relson z/OS Core Technology Design
Re: Self-documenting Bit Settings
I'd think that many would find it strange to have the equates precede the field definition. If you must use "*" for the equate, that is appropriate. Or, you might choose an approach such as one of the following: F1 DSB F1B0 EQU F1,X'80' F1B1 EQU *-1,X'40' F1B2 EQU *-L'F1,X'20' Peter Relson z/OS Core Technology Design
Re: Automation in C++ vs HLAsm WAS: looking for limbo languages - how low can you go?
Jon Perryman wrote #CALC (R4)=@PSAaddr of PSA #CALC WRKPSA=@PSASave PSA addr I'd guess that this is not a good way of doing this, if it means that this address will be used as a base register, since that is both unnecessary and (worse) results in a zero address detection event which will complicate your finding "real" ZAD problems (and it is highly encouraged to run with ZAD active in testing to look for unexpected ZAD events within your code since you would generally know which are expected and which not). But I don't specifically know what "@PSA" is, so my guess could be wrong. The two CALC statements are likely too simplistic if you are trying to reference the PSA's of all processors (such as within a loop), due to the concepts of prefixing and reverse prefixing. Peter Relson z/OS Core Technology Design
Re: IEFU86 WorkArea use ?
The linked-to post is not about the work area being "shared" per se. The work area is for use by the called exit routine for the duration of that exit routine's being in control. There can be no assumptions about contents on entry. Basic debugging is necessary for any error. If you're going to ask for help, then provide the information that those who might help would need. The OP did not post the complete exit routine. For all I know, the use of the "execute form" of WTO is incorrect and is not properly initialized and incorrectly assumes some storage is zeroes but might not be. The OP did not post anything about just where the 0C4-11 occurred. Making the readers guess is not the right approach. Binyamin wrote: Is the 0C4 in your code or did you possibly mess up other storage? Look at the PSW and registers. Look at the work areas. Exactly. "Is WTO even legal from IEFU86?" WTO is just used to test my exit. That does not answer to the question. But the odds are that a BRANCH=YES WTO will work according to specifications if it is done correctly, whether or not you should use it within an exit such as IEFU86. STORAGE OBTAIN,LENGTH=WORKLEN,ADDR=(R1),SP=245 LTR R15,R15 Storage Obtain OK ? JNZ FIN Non, on sort sans RELEASE STORAGE OBTAIN defaults to COND=NO. This invocation would abend (not return) if the storage could not be obtained. Thus there is no reason to check R15 afterwards. Only if you also specify CHECKZERO=YES for a COND=NO STORAGE OBTAIN could you successfully obtain the storage and get a non-zero return code. Charles M wrote STORAGE OBTAIN: I think under the covers it is the same service as GETMAIN. That would depend on how far under the covers you go, and whether you specify LINKAGE= on the STORAGE invocation. STORAGE OBTAIN with LINKAGE=SVC or LINKAGE=BRANCH is exactly the same service as GETMAIN. STORAGE OBTAIN with the default LINKAGE=SYSTEM has different initial and final processing than GETMAIN. The "middle" is common to both. Not sure if it is possible in that environment to get back to user key but if you can it might be worthwhile. Switching to user key would likely be a very wrong thing to do. And a reminder: questions about how z/OS works (such as whether a work area provided on a z/OS interface has certain characteristics) do not belong on assembler-list. IBM-Main is a much better choice, getting to a wider audience of folks who might help. Peter Relson z/OS Core Technology Design
Re: How to properly integrate HLASM SECTALGN with ALIGNT in z/OS binder?
Jonathan S wrote: By default, alignment stronger than quadword is rounded up to 4K, for compatibility with the limitations of the load module format. I suspect that, even if this is true, the actual statement is that any alignment stronger than doubleword (rather than quadword) results in the module being loaded on a page boundary. That is a statement for the entire module, not for each individual section. This is simply because the "desired" alignment is not known in the directory entry; there is only a bit for page-aligned vs not page-aligned (which will be doubleword-aligned). So if you need a section ordered on a boundary stronger than doubleword, the module must be on a page boundary. It is not the case that this necessarily causes the module to be rounded to a 4K multiple. Peter Relson z/OS Core Technology Design
Re: Assembler theology question
Dave Cole wrote Also, I probably wouldn't bother with a USING. My favorite instruction for this is: L R10,PSATOLD-PSA(0) Note, providing the "0" for the index register prevents that rather annoying ASMA306W message. ASMA306W is for overlapping usings. So I don't think it would apply to this "L" which is unaffected by USINGs. And if you're referring to ASMA309W, I'd say that it's not right -- You need 0 as a base register to prevent ASMA306W. And of course you can not use FLAG(PAGE0) if you don't like that message. Here are the examples that come to mind (I removed the ASMA435I messages), using FLAG(PAGE0,NOUSING0): 5880 021C 021C 4 L R8,PSATOLD-PSA ** ASMA309W Operand PSATOLD-PSA resolved to a displacement with no base register 0004 5880 021C 021C 5 L R8,PSATOLD-PSA(0) ** ASMA309W Operand PSATOLD-PSA(0) resolved to a displacement with no base register 0008 5880 021C 021C 6 L R8,PSATOLD-PSA(,0) 000C 5880 021C 0000021C 7 L R8,PSATOLD-PSA(0,0) Peter Relson z/OS Core Technology Design
Re: SECTALGN(256)
Page alignment is what you'd expect. If you need any section aligned at greater than an 8-byte boundary (and you do), then the entire module needs to be obtained on greater than an 8-byte boundary, and the only choices made available for obtaining storage for modules are 8-byte boundary and page boundary. Since 8-byte boundary won't cut it, page alignment is used. That is for the entire module, not for individual sections within the module. You have a simple linkedit. But that doesn't mean you have a simple assembly. And I suspect that you have some installation overrides to the default defaults (I noticed only that you have RMODEX=64TRUE which makes sense but is not the default default). Peter Relson z/OS Core Technology Design -Original Message- From: Ed Jaffe Sent: Thursday, May 4, 2023 8:08 PM To: Peter Relson ; assembler-list@listserv.uga.edu Cc: Jonathan Scott Subject: [EXTERNAL] Re: SECTALGN(256) On 5/4/2023 1:19 PM, Peter Relson wrote: > > Ed, > > What you really want is not to dive so deeply into the weeds. > > Bind with COMPAT=ZOSV2R1. > It does not work. Here is a trivial example. I'm compiling with SECTALGN(256) and specifying no binder input other than a NAME statement: //LKED.SYSIN DD * NAME EJESAL3(R) My binder options passed in through JCL are: IEW2278I B352 INVOCATION PARAMETERS - NCAL,MAP,XREF,LIST=SUMMARY,COMPAT=ZOSV2R1,FETCHOPT=(PACK,PRIME),RMODEX=64TRUE,AC=0,REFR,RENT,REUS IEW2278I B352 IEWPARMS PARAMETERS - LISTPRIV=YES The binder output is shown below. Note the "PAGE ALIGN YES" in the SAVE MODULE ATTRIBUTES section. I would like to understand where that is coming from. I'm not specifying it, at least not intentionally. 1PROCESSING OPTIONS: ALIASES NO ALIGN2 NO AMODE UNSPECIFIED CALL NO CASE UPPER COMPAT ZOSV2R1 COMPRESS AUTO DCBS NO DYNAM NO EXTATTR UNSPECIFIED EXITS: NONE FILL NONE GID UNSPECIFIED HOBSET NO INFO NO LET 04 LINECT 060 LIST SUMMARY LISTPRIV YES LONGPARM NO MAP YES MAXBLK 032760 MODMAP NO MSGLEVEL 00 OVLY NO PRINT YES RES NO REUSABILITY REFRESHABLE RMODE UNSPECIFIED RMODEX 64TRUE SIGN NO STORENX NOREPLACE STRIPCL NO STRIPSEC NO SYMTRACE TERM NO TRAP ON UID UNSPECIFIED UPCASE NO WKSPACE 00K,00K XCAL NO XREF YES ***END OF OPTIONS*** 1SAVE OPERATION SUMMARY: MEMBER NAME EJESAL3 LOAD LIBRARY PHOENIX.TEST.LOADLIB PROGRAM TYPE PROGRAM OBJECT(FORMAT 5 OS COMPAT LEVEL z/OS V2R1 ) VOLUME SERIAL MVSPV3 DISPOSITION ADDED NEW TIME OF SAVE 15.33.19 MAY 4, 2023 1SAVE MODULE ATTRIBUTES: AC 000 AMODE 64 COMPRESSION NONE DC NO EDITABLE YES EXCEEDS 16MB NO EXECUTABLE YES LONGPARM NO MIGRATABLE YES OL NO OVLY NO PACK,PRIME YES,YES PAGE ALIGN YES REFR YES RENT YES REUS YES RMODE ANY SCTR NO SIGN NO SSI SYM GENERATED NO TEST NO XPLINK NO MODULE SIZE (HEX) 4F00 DASD SIZE (HEX) 7000 -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any
SECTALGN(256)
Ed, What you really want is not to dive so deeply into the weeds. Bind with COMPAT=ZOSV2R1. >From the doc: COMPAT=ZOSV2R1 is the minimum level that supports preserving all boundary alignments specifications coming from ESD records. ALIGNT can be used to specify boundary alignments for both load modules and program objects without requiring the use of COMPAT(ZOSV2R1). In a simple experiment, this seemed to do the right thing. I don't have any idea about ALIGNT. Peter Relson z/OS Core Technology Design
Re: Automatic Variable Insertion
I suggest, by the way, that you use the TEXT keyword of WTO. It can make things much more flexible for you, since the message line is then not part of the WTO expansion, rather just the address of it. Peter Relson z/OS Core Technology Design
Re: Blocking Low core access from Assembler programs
PrimePSA (EXEC PGM=IGVDGNPP) is not documented and is not supported. And that is not likely to change. It certainly won't change without a formal request for the functionality it provides. You can do what you want, and I don't recall it ever not doing what it intends to do, but do not expect assistance from IBM Service with respect to anything within your system that goes awry due to that (be it IBM code or otherwise). Running it usually exposes problems but can, actually, hide a problem depending on the instructions that are unintentionally referencing the first page. Shmuel wrote >Would there be utility in accepting a MODIFY command to reprime with a >different value? The V= parameter (in the example V='50404143,,,FF7F') identifies a group of values that are cycled through. Martin Ward's example of erroneous reference to page 0 that a scan can find (I removed the "" and "m") CLC 0(R1),field fieldDCC'9' is also flagged by *PROCESS FLAG(PAGE0) which had been mentioned. Many would think that it best to have such problems exposed by the assembly itself. Peter Relson z/OS Core Technology Design
Re: Blocking Low core access from Assembler programs
Sayama P wrote: It looks like there is no practical way to detect unintentional run-time access to page zero. Since the original post did not ask about "detecting" but rather about producing an access error (and you cannot do the latter), I disagree with this assertion. You cannot "detected unintentional" by scanning source and you often cannot know "unintentional" without mind-reading. But you can detect at run-time a class of errors - the most common class of errors - namely where a program picks up a field that contains an address, not realizing that sometimes that address is 0, and then uses that. ZAD (Zero Address Detection) detected that case. Yes, it's about "testing" (or simply normal running of work) because it can only detect what actually happens in running code. Sure, it's true that it does not detect the case where the address is not 0 but still within the first page. The case of 0 is orders of magnitude more likely. Peter Relson z/OS Core Technology Design
Blocking Low core access from Assembler programs
The assembler's FLAG(PAGE0) is provided to catch at assembly-time errors such as AHRx,2 when you might have intended AHI Rx,2 Peter Relson z/OS Core Technology Design
Re: Blocking Low core access from Assembler programs
Is it possible to force an Assembler program to hit an access error if it tries to load data from the low core (page starting from address zero)? If you're talking about z/OS, in a word, "no". Such behavior would not be in accordance with z/OS requirements. Location 0 is a valid address in z/OS and locations 0-x'7FF' are set by z/OS not to be fetch-protected. Therefore they are accessible to any program, without "access error". Programming interfaces such as FLCCVT, PSATOLD and PSAAOLD are within this range. DO NOT change control register bits. Peter Relson z/OS Core Technology Design
Re: Entry Point in load module
This is not a question for assembler-list as it has nothing to do with the assembler itself. The binder is a z/OS function and questions about it would be better suited for ibm-main. Since you did not show either your program (or a snippet thereof) or your binder JCL it is impossible to answer your question. The "design" is not "set the entry point to the start of the 2nd CSECT if there are two CSECTs". The design includes various things including ENTRY binder control statements, a name on an END statement, the order in which OBJs and/or loadmods are included. But in its simplest form, the default is to set the entry point to the start of the first section. For example, IEW2322I 1220 1 INCLUDE SYSOBJS(TEST1) -- where CSECT is TEST1 IEW2322I 1220 2 INCLUDE SYSOBJS(TEST2) -- where CSECT is TEST2 IEW2322I 1220 3 NAME TEST(R) IEW2650I 5102 MODULE ENTRY NOT PROVIDED. ENTRY DEFAULTS TO SECTION TEST1. And if you reversed the includes, entry would default to TEST2. In the absence of a name on an END statement, I'd think it unwise to rely on whatever rule might exist, when you have multiple CSECTs. Peter Relson z/OS Core Technology Design
Re: External symbol record for CATTR
Joe, Please post a small assembler program that, when you assemble it, has the anomaly you cite. I'd think you could take the Metal C assembler, and strip out most of it. The following program, based on the tiny amount of data that you chose to share in your post, when assembled on z/OS shows references to M_WSA in the listing and browsing the ADATA you can also see references to it (types x'20', x'30', x'42', x'44' -- I'm assuming that the 3rd byte of the record is the "type"): GETMAC#C CSECT M_WSACATTR RMODE(ANY),PART(INDEX) DS0D @1indexPTR DC (4)X'00' M_WSACATTR RMODE(ANY),PART(HEAD) @2INDEXPTR DC (4)X'00' END Perhaps try this one yourself and see if it shows the anomaly on your zPDT setup. I would not bet that a zPDT personal license provides access to z/OS service. But I don't know for sure. Peter
Re: RSECT vs CSECT
>RMODE(SPLIT)? The only case in z/OS module fetch processing that pays attention to RSECT is building the nucleus. The read-only part of the nucleus consists of RSECTs. The read-write part of the nucleus consists of CSECTs. RSECT does not factor into RMODE(SPLIT) processing. Peter
Re: Subject: RSECT vs CSECT
> Is there any advantage to using RSECT over CSECT with PARM=RENT? One might say that there is advantage in having the definition within the source rather than relying on a build parameter to ask for the sort of checking you'd get. And, of course, RSECT vs CSECT is passed as information to the binder, and in some cases has meaning to the operating system. It does have meaning for modules built into the z/OS nucleus, for example. Peter Relson z/OS Core Technology Design
Re: Subject: ASMA500 message question
You ignore the message at your own risk. Unless your module is page-aligned and this is a page-aligned CSECT within that module, you have no idea if the CSECT will land on a quadword (or stronger) boundary. And if you truly need quadword boundary and don't have it, things won't end well. Mike S wrote CATTR use requires GOFF object format, which I don't want to use. Why would you not want to use GOFF? I can think of only one module in all of z/OS that cannot use GOFF. I'll let guesses occur before providing the answer in a day or two. Peter Relson z/OS Core Technology Design
Re: Assembler courses
Willy J wrote: > I did eventually write a macro to handle DCBs from a 31-bit program I don't follow why this is a challenge. For the normal access method interfaces (such as those that were listed), AMODE 31 is supported. The only thing that is important is the RMODE of the DCB. LOC=(24,64) on GETMAIN or STORAGE OBTAIN is easy to code. Or RMODE 24 on your module if the module is not reentrant and you don't mind the whole loadmod below 16M. Or RMODE=SPLIT in a program object with suitable RMODE 24 CSECT(s). Peter Relson z/OS Core Technology Design
Re: Assembler courses
For me, the biggest problem in making something reentrant is if I need to use a DCB. There is no way, that I know of, to generate a DCB in a GETMAIN'd area. I'm not sure why "DCB" is pointed out specially. In a large number of cases reentrant programming relies on dynamic storage that has been initialized by copying from static storage. DCB is not intrinsically different then the list form of many macros -- you create one initialized in static storage, you allot space in dynamic storage, you copy from static to dynamic, and away you go. Many "execute forms" provide a "complete form" which fully initializes and therefore does not require an initialized static list form. The older the service the less likely it is to support "complete". ESTAE is one such. And if you don't do it right, even thinking that you can just set the area to zeroes, you get what many would not want as the desired value for at least one parameter. I chose not to identify the parameter because you should just do it right and then you won't care. Regarding code below 16M, almost all (maybe all) of the access methods support the invoker being above the 16M line and can identify exit routines that are above 16M. The data might need to be below 16M but that is easy to accomplish (at least in assembler). If you have a need for a mixture of code above 16M and below 16M, see if you have access to using PDSE's and program objects. RMODE=SPLIT is very well suited for exactly this situation. You can't just copy executable code from a CSECT to getmained storage without making sure that the "from" can get to the "to" and vice versa. That can be a pain. V-Cons don't apply between a loaded module and getmained storage. But they do apply across CSECTs in a loadmod or a program object (include the RMODE=24 and RMODE=31 CSECTs in an RMODE=SPLIT program object). Peter Relson z/OS Core Technology Design
Re: Assembler courses
I view "baseless" as a poor choice to teach. Many macros require static data and assume that there is addressability to same. Many programs require static data and it can be challenging (or at least inconvenient) to establish addressability on demand. This all plays into why over time assembler programs that see continued development typically perform worse (difficult choices to make in register optimization) while HLL programs typically perform better (availing of better register optimization that comes into existence). I think that you should teach use of "no codereg". But, with that, you should start with "addressability to static data". You then add in that, if conditions are right, you can do away with that if you have no need to address static data or if you are willing to establish it only when needed. This is a tiny delta. Yes, it's of course true that if you can achieve "baseless" you have an extra register to play with. You have to decide if the nuisance of establishing static data addressability only in the places where it happens to be needed is worth it. This approach is little different then teaching "coding" and then teaching the differences between reentrant and non-reentrant (which is a small thing). For both of these cases, you are giving the students the knowledge they need to make informed choices. Peter Relson z/OS Core Technology Design
Re: YA MGCRE RCF?
Definitely the lack of an equate for R12 should be corrected (such as by adding an equate and a BASR R12,0). I'll get that taken care of. Almost all macros expect some amount of addressability to static data for certain invocations. That will not be stated for individual macros. That is why "baseless" coding is usually not a valid approach if using z/OS macros. You tend at least to need addressability to static data. The MGCRE example isn't even for that case; it needs addressability to get to the static data that is used (the text and consname). Macros, in general, have no way of knowing if they could use "LARL" so don't even try. An entertaining thought for an assembler enhancement would be a pseudo-op that generated "LA" or "LARL" depending on whether the target was in a CSECT or a DSECT (maybe allowing for LAY too). Peter Relson z/OS Core Technology Design
Re: Documentation on the new 64 bit instructions
For the case where you get control in the same AMODE as the caller (e.g., BALR, BASR, BRASL, etc), and you want to use BAKR/PR to save/restore registers, and your return address is in reg 14, then it is true that BSM 14,0 BAKR 14,0 is the easiest way to set things up so that PR returns in the AMODE of the caller. There are other, long-winded, ways to accomplish this (that quite possibly no one uses). The principles of operation is not, for the most part, a user's guide. It is a user's manual. Peter Relson z/OS Core Technology Design
Re: Documentation on the new 64 bit instructions
Not that BAKR is a "new 64 bit instruction" (neither "new" nor "64 bit"), but POp does tell you what you need to do to use the instruction by describing exactly how the instruction behaves. How you do what you need to do is your choice. You made an unfounded assumption related to how PR works. You don't "have" to do a BSM prior to the BAKR. And, in fact, in some cases it would be wrong to do so (the typical example is if your interface is invoked via BASSM). If you want the PR paired with a BAKR to return in AMODE 31 then the address saved must indicate AMODE 31. How you accomplish that is up to you. Peter Relson z/OS Core Technology Design
Re: Subject: MVCRL
Why isn't there a Move Relative Long instruction The answer is likely because there is insufficient reason to have one, to justify the cost. Instructions are typically created when they solve a problem and, often, when they can be done faster if implemented in the machine than if done piece by piece in a program (which, surprising to some, is not necessarily the case if the instruction is implemented in millicode). Why can't you simply use MVCL (or MVCLE), having set up the address operands using LARL if they are relatively addressable (as long as a halfword boundary is OK as a limitation)? Any instruction that needs two fully defined addresses (think of an SS-type instruction such as MVC) has limited space for additional information (such as a length). The instruction length is limited to 6 bytes. You need at least 2 bytes for base+displacement or for the offset if relatively addressing, for each of the two operands. You need at least 1 byte for the opcode. That leaves you one byte for everything else. MVCL has a lot of "everything else". That is why MVCL has its operands in double-reg pairs. So would any other MVCL-like thing. So the approach for using a hypothetical move-long-relative would be the same as using MVCL, just using LARL where needed. And once the setup has been done, there is no need for a new instruction. Peter Relson z/OS Core Technology Design
Re: Unexpected C code
Gil wrote: Somewhat later in this thread, Thomas David Rivers averred that LPR Of 0x8000 results in 0x8000. The puzzling sequence of instructions was LPR; LCR; SLR 31 to set a char variable on a nonzero operand. This works correctly (and I'll trust the C compliers) only if both LPR and LCR result in 0x8000, or at least some nonzero result. It is true that LPR of 0x8000 does result in 0x8000. As does LCR of 0x8000. If I have this right: Overflow processing for these instructions depends on the "fixed point overflow" bit in the PSW program mask. The "only if" is true only when the program mask does not have that bit on.. It is false if the program mask does have the bit on because the overflow results in a program interrupt. If a program interrupt were to occur, only if there were appropriate recovery in place that accepted this and retried silently to the next instruction could we consider that the program continues as expected. Peter Relson z/OS Core Technology Design
Re: the BEAR (was: New z16 Instructions)
Both LBEAR and STBEAR are created for OS's other than z/OS. Could z/OS use them constructively? Possibly. If by "constructive" we positively balance functional benefit over performance cost. Could an application use STBEAR constructively? Possibly. Probably more likely to be of constructive use if the OS itself uses LBEAR and STBEAR. Peter Relson z/OS Core Technology Design
Re: Unexpected C code
Apologies if this was mentioned, since I am only now getting around to reading some of this thread: Bernd wrote (and others had similar) LPR: if the register contains 0x8000, IMO the result will be zero (and overflow), so you're right ... this will lead to a zero result. IMO, the overflow will be ignored. The question is about "will be ignored". Do you know that it will truly be ignored? Can you be certain that the program mask bit is not on which, if on, would cause the overflow to program-check? If running under LE with ESPIE protection, might that program mask be on? z/OS itself cannot make such an assumption in many paths (in an SVC path, it might be able to because the SVC new PSW has 0's for the program mask; in a PC path, it cannot because the PC instruction does not change the program mask so the routine would have to do so). Thus this nice trick to avoid compares and branches is not, in general, usable within the OS. Peter Relson z/OS Core Technology Design
Re: Inlining routines
Three approaches that would normally be used are macro, a copy file, and LOCTR. Many would avoid a copy file if the source has to be placed in a separate part because it can be harder to maintain. But if multiple modules want to be able to include this same code, macro and copy file are the way to go. Here's a simple example with LOCTR TEST CSECT MAIN1LOCTR M1 DSF SUBR LOCTR MAIN2LOCTR M2A DSF SUBR LOCTR S1 DSF MAIN2LOCTR M2B DSF END The order of instructions in the OBJ will be M1, S1, M2A M2B Peter Relson z/OS Core Technology Design
Re: Testing Address validity
I have an ordinary problem state program that attempts to access storage that it does not have access to. Obviously a S0C4 is the result. Let's say the address is a valid virtual address (but the storage key is wrong) and the page representing that virtual address is paged out. What is the sequence of events that leads to the S0C4? Does the OS have to page in the page so the hardware can generate a S0C4? That seems inefficient. And in any event, whatever the mechanism, why could not that mechanism generate a condition code for this hypothetical new instruction rather than a program interrupt? There has to be a program interrupt. Because that is the hardware's way of telling the software "I do not know". The hardware does not know anything beyond that the DAT structure indicates that the page is not valid. Is it "truly not valid" or is it "not valid because the OS has paged out the page"? The software could choose to provide a way to field that program interrupt and convert it into something that continues the user program. That is, after all, exactly what happens on a page fault. z/OS would not do that because it would not be a useful expenditure of resource. Taking a long time to field a user error is hardly a problem in any realistic situation. After all, the same user could have simply blown up themselves if they wanted to do so, without involving your service. So the net effect to the system is the same. As to the question about the flow, it's something like this: * Program/instruction references storage via a virtual address * Hardware determines that the virtual address is not backed by a real page and presents a program interrupt (there are quite a few possible such interrupts * OS program interrupt handler sees that program interrupt and queries its own data to determine if the reason that the virtual address is not backed by a real page is because the page has been paged out to some form of auxiliary storage * OS would generally let the fault continue to some recovery process if the page is not available on aux * If the page is available on aux, OS would generally suspend the program, bring in the page from aux by some asynchronous process (it can be synchronous for such cases as DREF or SCM in which case suspend/resume would not be needed), then resume the program to "try again". The desire to "try again" is why these program interrupts occur without a PSW address update, allowing for easy "try again". So, sure, in the middle of the above the OS could have said "the page is on aux, but I'm not going to bring it in, and if I can tell that the instruction being issued was some new "test only" instruction then set up to continue the interrupted program with an indicator such as a condition code (or anything else it chose to make the interface, even a "return code"). This is not instruction architecture. This is software programming interface. z/OS would not mplement such a thing. There is no guarantee even that the operating system can determine the instruction. That information is not part of program interrupt information, and it is theoretically possible for the page(s) with the instruction to be paged out by an asynchronous process before the program interrupt handler could look. Just about the only productive use of TPROT is when you are supervisor state and have reason to know that the storage being accessed is supposed to be page-fixed. In that case a CC=3 from TPROT can be known to indicate "bad". z/OS itself uses this sometimes. Peter Relson z/OS Core Technology Design
Re: Long Displacement Facility (was: Fun with RXSBG)
The long-displacement facility has been part of the z/OS architecture level set since z/OS 2.1 (including the "high performance" variant). Mark B wrote: If you need to test a facility bit in the range of 0-31 then use the list of bits stored by the STORE FACILITY LIST instruction, which should have been placed in some common location by the OS you're running on, typically at location x'C8'. If you need to test a facility bit >=32 *and* you might possibly be running on a pre-z9 machine(!) then first test bit 7 of the result stored by STORE FACILITY LIST to see if STFLE is available, and if it is then issue the STFLE instruction (if the output isn't already available somewhere) and test the bit from the list of bits stored. For z/OS, the IPL-time output is "already available somewhere". If you are interested in the IPL-time state of facility bits (which in almost all cases is what you would care about), as opposed to the state "now": * For any bit in the first 256, you can look at the area located by x'C8' (FLCFACL/FLCFACLE in IHAPSA, or FlceFactilitiesList/FlceFacilitiesList1 in IHAPSAE). * For any bit at all you can look at the area mapped by IHAFACL and pointed to by ECVTFACL (you can also use IHAFACL to look at the PSA area, with a little manipulation to account for the header of the area pointed to by ECVTFACL) Peter Relson z/OS Core Technology Design
Re: Question about RACROUTE REQUEST=AUTH|FASTAUTH processing
I am able to issue both of the above RAROUTE macros against a facility profile with individual users. However when a individual is part of a Group must I issue a second RACROUTE REQUEST=AUTH|FASTAUTH ? This is not the kind of question best asked here. It has nothing to do with the assembler itself. Authorization requests should almost always be based on a user ID. RACF does the authorization check based on the user ID and all of the groups to which the user has a valid connection. With some of the interfaces, the user ID is determined implicitly; with others it is provided explicitly. The issuer of RACROUTE does not generally need to care how the customer set up their profiles and access lists, so does not care whether access is granted to an individual user ID or to a group to which the individual user ID is connected. Peter Relson z/OS Core Technology Design
Re: Modifying the VSAM Request Parameter List (RPL)
The desired interface would be if MODCB provide a "modify form" (MF=M). Your use case is exactly what the modify form is for. However, MODCB (at least the z/OS MODCB) doesn't. So your choices are between an extended if-then-else for every combination you want (obviously very unpleasant) and building the parameter list yourself. You asked about the downside of doing so? Basically, that you have to get it 100% right or all bets are off. If you go that route, you should check byte for byte and register for register that what you build is what the macro would have built The other downside is that you are in unsupported territory (at least would be for z/OS). The interface is the executable macro. But at least if you got it 100% right you could reproduce any problem using a real macro invocation such that it would become reportable. Peter Relson z/OS Core Technology Design
Re: Interpreting Explicit Decimal Numbers
I can't use vector instructions as I don't have access to the vector facility. Do you mean you're not on a machine that has the vector facility? Or might not be? Otherwise you do have "access". z/OS 2.5 is the first z/OS release that has the vector extension facility as part of its architecture level set. Peter Relson z/OS Core Technology Design
Re: Making Encoded Bits Human Readable
The lowest-tech approach using only two regs (no 64-bit regs, no z/Arch instructions, no 6-byte instructions even) that came to mind was this: ICM 0,B'1000',BYTE Put the byte into bits 0-7 SRDL 0,30 Move BYTE.0-1 to reg 0.30-31, * zeroing reg 0.0-29 * BYTE.2-3 to reg 1.0-1 SRL 1,30 Move BYTE.2-3 to reg 1.30-31, * zeroing reg 1.0-29 AHI 0,C'1' 0-3 => C'1'-C'4' AHI 1,C'1' STC 0,target0 STC 1,target1 BYTE DSX I.e., taking advantage of needing to do a shift anyway to avoid having to clear anything. That doesn't make it the fastest (for example, LLC might be faster than ICM) but is a 6-byte instruction. The fastest is going to be some sort of table look-up (as has been discussed, whether TROT or something else) but that takes more storage. I don't remember why the OP wanted to make a value range of 0-3 human-readable as 1-4. If you could settle for displaying as human-readable 0-3, then instead of the AHI one could do an OI xxx,C'0' after the STC. It would quite likely perform worse (an extra storage reference instead of a register update), but then you'd be using nothing even as new as relative-immediate if that were a consideration. Shmuel wrote: >Wouldn't RISBGZ R0,R1,62,63,2 be clearer than XR and SLDL? Not to many of us. I'm impressed that it is to you. It's a great instruction (which is presumably why it was made available to us mere mortals from those previously available only to the millicode folks). But "clearer"? That wouldn't be an adjective I'd use. Peter Relson z/OS Core Technology Design
Re: Saving Caller's 64-bit Registers
Peter F wrote: . . . each save area indicates how the BACKCHAIN POINTER WAS (not "registers were") stored by the program that created that area. No, it indicates BOTH how the backchain pointer was stored *and* also how the caller's registers were stored. When you create a save area, it is for your callees to use to save. All you can tell them is where YOU stored the backchain, not necessarily where nor how many registers they can save in it. This is pretty much true except for the word "All". The created save area is also for you to use to save the address of your caller's save area. You can also tell the callee (but they should not have interest) where/how you saved your caller's registers. And the callee should not need to know where you saved the backchain. The conventions are such that whether you saved at +4 or +x'80' that value will not be overwritten by the callee. The general purpose of the FxSA designation is not for either the caller or the callee. It is for diagnosticians and programs they might use, in particular to be able to ascertain the caller's registers from some kind of dump (such as in following backwards the savearea chain from time of error and formatting the registers that had been saved). Can the designation be used for additional things such as Tony T seems to want to do? I suppose so. Peter Relson z/OS Core Technology Design
Re: Saving Caller's 64-bit Regsiters
Michael Schmitt wrote: Also the linkage stack is not supported by Language Environment, so you should not be using it in any code that can be called in an LE run-unit. The doc is likely "imprecise". It is surely untrue in general. z/OS does not need any "support" by LE in order for an individual program to use the linkage stack. But it might be true that if you are called from LE and then you need to call back out to LE, you cannot use the linkage stack. But if you are a leaf routine, I'd bet that you can. It's typically a question of recovery routine processing -- if they need to retry and then return to you, and if the recovery routine was established before your code updated the linkage stack. That's the sort of situation that might well exist. For that, your use of the linkage stack would cause things not to work. Peter Relson z/OS Core Technology Design
Re: Saving Caller's 64-bit Registers
It might be worth noting that the normal official linkage when ARs need to be saved is to use the linkage stack. We internally do use some 144-byte save areas for GR low-half plus ARs. That never made it into the linkage conventions. Tony T wrote: First a basic question on F8SA. The AR-regs at offset x'90', are they AR-regs stored by B or by C? C. Only the saving of caller high halves in the target routine's save area is a defined convention. If B received a 72-byte area and needs to save either 64bit or aregs, it will need to create either a F5SA and F8SA area. Under these conditions, B *must* put 'F5SA' and 'F8SA' in the new save area as B has utilized the tail end of the new save area for the high-halfs. So, when C is called, it follows that C knows 'for sure' that when it sees the 'F5SA' and 'F8SA' literals, then it can safely store all it's regs as double-words starting at offset 8. Is that not true? What if the caller does not do this? "Must" is different than "it is highly recommended to follow the linkage conventions". In fact, if 'C' sees any of the know literals at offset 4, it knows that the caller placed a back-pointer at offset x'80', therefore it knows that the length of the save area is at least long enough to store all the regs as double-words starting at offset 8. Is that not also true? Not true for F1SA And, if 'C' sees a positive and even fullword at offset 4, then the only safe option is to only save the low-half of the regs at offset 8 because, most likely, it is just an old save are? You should not rely on "positive". But if you just went for "even", that would be true. But if you're already going to have to deal with 72-byte, then isn't that enough to know? If not using the linkage stack, always save the low halves in the provided 72-byte area, and "high halves" in the area you obtain. Why do it two different ways? If supporting AMODE 31 and AMODE 64 at the same point, you might well have required that the AMODE 64 caller provide a 144-byte area. Peter Relson z/OS Core Technology Design
Re: Saving Caller's 64-bit Registers
Gil wrote: When did the rules change? In days of yore I was led to believe that any program that could be invoked with /STEP EXEC PGM=... could instead be invoked by LINK With a 72-byte save area. In fact, ini Assembler Services Guide V2R5, I read: • Caller-provided save area A calling program provides its target program with a 72-byte register save area unless the target program's interface requirements are otherwise specified.. In days of yore there were no 64-bit GRs or AMODE 64. And your belief was always incorrect. Many programs could be so invoked. Some required ATTACH not LINK. And if they show use only of ATTACH, assuming that you can use LINK is an incorrect assumption. Your reference from the Assembler Services Guide is fully true. The default default is that the target needs only 72 bytes. The default default is that the target routine is AMODE 24/31 and does not change high halves or use ARs. Compatibility demands that. But 72 bytes is not appropriate for AMODE 64 entry (it might border on impossible unless you include the possibility of using and then getting rid of a linkage stack entry). LINK can prevent an AMODE 64 target (to allow it, you need to specify the non-default AMODE64OK=YES). ATTACH cannot (because the ATTACH front-end cannot know the intended AMODE; that is found only later). Thus it is up to the system to help with ATTACH and it is up to the issuer of LINK to get it right. ATTACH has provided a 144-byte savearea for a long time. And, yes, whether the target needs it or not (which is in general unknowable). But what about compatibility with existing customer code? Rather, IBM should have modified BPXBATCH to save low halves; obtain 144 bytes; then save the entire registers. Quite possibly true. You're certainly right that changing to require 144 can properly be done only if you have control over all your callers (and can get them to change to accommodate). And it appears that the owners of BPXBATCH did not have such control, but changed anyway. When BPXBATCH (module BPXMBATC) was implemented, it used a 72-byte savearea (and even then the module had a comment that it was OK to invoke via Attach, LINK, Load/Call, "TSO call" and "Batch/Exec" (maybe that's EXEC PGM= which is an attach). The change appears to have been made in z/OS 2.1. Peter Relson z/OS Core Technology Design
Re: Saving Caller's 64-bit Registers
Shmuel wrote >For running forward, it's a bit stickier. Is a program providing a >144 byte save area expected to format it as FxSA? As I wrote previously, you cannot in general "run forward". You could if you know exactly what the target programs are doing (which is unlikely unless you own them). There is no expectation. There is no concept of the provider "formatting it". The provider "provides it". The target "uses it". It is not in general knowable how the target chose to "use it". The target could be a routine that expects 72 bytes and uses the first 72 bytes only (including putting the next address at +8). It could be a routine that expects 144 bytes in which case it would likely use it according to the conventions (incuding putting the next address at +x'88').. Shmuel wrote > A program that saves its caller's registers in standard 72-byte format > is expected to set offset 4 of the save area that it obtains to the address > of the previous save area, regardless of the size of save area that it provides. That's not what the manual says. A program that saves the callers registers in a 72-byte save area and alters ARs or the top halve of GRs is expected to save them in a new F5SA or F8SA There is no conflict. The manual section referred to is not what Tom was referring to. A program that "saves its caller's registers in standard 72-byte format" is not one that (also) saves ARs and/or high halves. That would be a program that "saves its caller's low halves in standard 72-byte format and also saves ARs and/or high halves". And, yes, such a program would (if following the conventions) be using F5SA/F8SA. The main important thing, as has been mentioned so many times, is that the provider of the save area provides space. The provider does not dictate how that space is to be used. The conventions are such that the uses do not conflict with respect to being able to locate the previous pointer. A general routine to format save areas does so. It looks at the value at +4 to decide if that is the previous pointer or if the previous pointer is at +x'88'. Peter Relson z/OS Core Technology Design
Re: Debugging Assembler Rexx programs
Shmuel wrote >Assume that any system macro expanding to a PC or an SVC will clobber R15-R1. Or any linkage at all (such as branch linkage by BALR, BASR, BASSM, BRASL, etc). Unless the documentation says otherwise. The default of non-preserving of regs 14-1 (and high halves 15-1 and ARs 15-1) is part of the linkage conventions. Peter Relson z/OS Core Technology Design
Re: Saving Caller's 64-bit Registers
Tony wrote: 1) What is "B's save area"?...or is it the save area allocated by B and used by C when C receives control? It is the "or" -- B's save area is the save area allocated by B. B provides that to what it calls (such as C). It will (as filled in by C) contain B's registers at the time of the call. Tony wrote 2) It reads as if a newly acquired save area is partially propagated by the program that acquired the save area and partially by the program that is called with R13 pointing to this newly acquired area. And that the allocater/caller is actually setting the word 1 literal, the back pointer, and maybe filling the end of the area with the high-halfs of the registers from when it received control. Yet, the front registers are left un-used and will be filled in by the next program to be called. If this is the case, then the next program being called will actually see the word 1 literal when it receives control. Am I understanding this correctly? The allocater of the savearea (the call target) is defining at +4 within this savearea how the allocater (the call target) saved its caller's registers (either by putting the prev ptr there or by setting to the appropriate 4-char string). The only other thing(s) set in this savearea by the allocater are the prev pointer at +80 (if this is a 144-byte or larger save area) and, if using that approach, the high halves and/or ARs at parts of the savearea beyond 144. IHASAVER has mappings of all these things (F4SA, F5SA, F7SA, F8SA). F1SA indicates regs "saved on linkage stack" and (I think) "F6SA" indicates saved on z-Architecture linkage stack but I suspect no one uses F6SA. The allocated area can be passed to an "old" target routine that knows only about 72-byte save areas. The allocated area can be passed to a "new" target routine that expects a 144-byte save area. So "yes", the next program can see the word 1 literal. Just as it can see the word 1 prev pointer. It can usually also "see" the entire savearea chain if it chose to look. But that information is not relevant to that next program. Peter z/OS Core Technology Design
Saving Caller's 64-bit Registers
Some more info from the REXX folks: The savearea passed to programs invoked via ADDRESS LINK, LINKMVS, or LINKPGM was extended to pass a 144-byte savearea to the caller by APAR OA44581 (whenever that became available). Programs invoked as REXX functions or subroutines are still passed a 72-byte savearea (I don't know why they didn't similarly change that). This makes REXX LINK more compatible with REXX ATTACH -- the target routine in both cases gets a 144-byte savearea. Peter Relson z/OS Core Technology Design
Re: Saving Caller's 64-bit Registers
The REXX team indicates that the current savearea size for a called routine is 72 bytes. This will get documented. Thanks Shmuel for submitting the update request. Maybe the size will change in a release, such that you can eventually get to the point of relying on a larger size if you know you are running on a supported release. Peter Relson z/OS Core Technology Design
Re: Saving Caller's 64-bit Registers (was "...Regsiters")
Shmuel wrote ...I don't understand the issue for running the forward chain, assuming that all called routines have set the forward pointer, other than detecting the end of the chain. If +4 (word 2) is on a word boundary then the save area is either unused or is 72 bytes. If word 2 is FxSA (C6FxE2C1) then it is a 144-byte save area; anything else and it is invalid. We have been through this so many times. I don't understand why. The value in the 2nd word has only a peripheral relationship to the size of the save area. It states how the CALLED program saved the CALLER's registers. For example: if the called program saves the caller's register low halves only, in the caller-provided 72-byte savearea, then the 2nd word of the area pointed to by the called program's reg 13 will have an even value. But it is unknowable whether the called program is itself using a 72-byte savearea, a 144-byte savearea, or something larger. And thus it is unknowable whether, looking forward, you need to use the word at +8 or the doubleword at +136 to locate the "next" savearea to understand how that savearea's owner saved its caller's registers. And the answer to Dave Clark's continued asking of the same question remains the same: the called program cannot "tell" how much storage the caller provided unless the interface provides a way for the caller to do so. And there really is no need to do so. Just as you, as an interface provider, might choose to provide a separate entry point for a caller in AMODE 64 than for one in AMODE 31 to avoid complications, you might provide a separate entry point for a caller passing a 72-byte savearea than one passing a 144-byte savearea. Or you might just always assume that the caller provides a 72-byte saverea, save the low halves there, and (if needed) save the high halves in an area that you obtain upon entry and identify that you have done so in the 2nd word. Peter Relson z/OS Core Technology Design
Re: Saving Caller's 64-bit Regsiters
Tony Thigpen wrote "stuff". The opinions in that post do not reflect the requirements of an interface provider. It is irrelevant what your routine is called from. The caller is responsible for meeting the interface, whether that be save area or parameter list or other data or environment. And if they don't, the problem is on them. And if they are not able to meet the interface, and you feel it important that they be able to do so, then you have not provided a suitable interface. And just about everything else in that post is similarly off key. The post does not show understanding of the intent of the information at offset 4. And that is surprising since this has been discussed so many times. No approach requiring the caller to identify something could have been done compatibly. And compatibility matters. A lot. Dave Clark wrote "Because how is the callee supposed to know how to treat the caller's savearea unless the callee knows how long the caller's savearea is?" Because they have no need to do so. How many times do we have to go through this? . It's a fully proper question to inquire how long is the R13 area provided by Rexx on a call. That should be clearly documented. Dave Clark wrote "OK, so what you're saying is that I should do the standard updates to the caller's 72-byte save area and then do the BAKR instruction to save everything. Finally, I only have to do RP to return to program based on the saved stack values. Correct?" No, not correct. Unless you like to waste cycles. And you do not use "RP". I could not tell if you mean "PR" or truly "RP". You can use BAKR and not do the STM/LM at all. Part of the z/OS linkage conventions explains what you can do if your caller is not known to be providing a 144-byte save area yet you want/need to save high halves too. That situation/approach surely applies to zVSE too. Peter Relson z/OS Core Technology Design
Re: Saving Caller's 64-bit Regsiters
Dave Clark wrote is there some other means of knowing whether or not to save the high halves in the caller's save area? This has been covered many times. It's your interface. If you documented that they should provide a save area suitable for saving high halves in that area then you assume that they have met the interface requirements. If they didn't (especially with respect to save area), bad things will happen. It's no different than if you required a 72-byte save area and they gave you a shorter one. Dave Clark wrote I found that a "standard register save area" is now defined by IBM as 128 bytes long. For z/OS, no it is not. I have no idea about z/VSE. Michael Schmitt wrote The problem is that the new save area formats are not compatible with the 72-byte save area format, so you can't use them in amode 31 unless you control both the calling and called programs. And they're not supported by Language Environment. Yes they are compatible (to the extent that is important) and you can use them in any AMODE. You can chain backwards, interpreting the information saved at offset 4. You cannot forward-chain. Peter Relson z/OS Core Technology Design
Re: 64-bit registers (was: Unsigned Binary Formats)
Shmuel wrote: CLCL pair+pair (32) CLCLE pair+pair (32 or 64) CLCL should be "(32 or 64)" in this nomenclature. Basically just about any instruction operand that is located by a register (it could be via a register pair such as for CLCL, or just a base-displacement with or without index) can be considered to be modal with respect to AMODE. If AMODE 64, then all 64 bits of the register are used. If AMODE 31, then 31 bits. And if AMODE 24, then 24 bits (conceivably some newer instructions could choose to use 31-bits even if AMODE 24, I don't recall if that happens or not). Peter Relson z/OS Core Technology Design
Re: Determining a group item
Joe, I can all but guarantee that trying to derive the offsets and lengths from the source will miss edge cases that the assembler deals with. ORG is a simple example of something that can be not overly straightforward. That is why looking at ADATA (or a listing) has a big advantage -- you are utilizing information produced by the program responsible for dealing with the subtleties. Peter Relson z/OS Core Technology Design
Re: Is it possible to update CSA from an unauthorized user-key program?
Jeffrey Celander wrote: Coupling Facility XCFNOTE services is a callable service can be used to create/read/modify data across applications or the entire Sysplex. Access to the data notes can be controlled and locked down by your SAF. The services can be called in problem state without the need to create special authorized services and managing CSA block anchors. This is true. But don't make light of the SAF requirement. A problem state user does need to be authorized to a FACILITY class resource for the notepad. It is up to the customer to control whether such access is appropriate. Peter Relson z/OS Core Technology Design
Re: Vector register 23?
Robert Ngan wrote: Vector registers (VRs) 8 - 15, bytes 0 - 7, and the entirety of VRs 16 - 23 are unchanged. 16-23 only! Not 16-31. Is this correct? Yes it is correct (and you didn't even ask about VRs 0-7). As with the FPRs, some of the vector regs are considered "volatile" and need not be preserved if used. A program might be able to take advantage of that, if using the regs when not calling anything. Only the part about regs 8-15 bytes 0-7 is related to the fact that the VR storage overlaps the FPR storage. Peter Relson z/OS Core Technology Design
Re: Is it possible to update CSA from an unauthorized user-key program?
It is possibly to update only if the CSA is in user-key. And having user-key CSA is a bad idea. That is why it had been soundly discouraged for well over a decade, capability to create it had been made not the default, and indeed the capability to create it was withdrawn, although subsequently the RUCSA feature was added -- although doing that adding had little if anything to do with user-key CSA being anything other than a bad idea. It has never been possible for an unauthorized program to acquire common storage. Peter Relson z/OS Core Technology Design
Re: Base-less macros
Shmuel wrote: Assuming that the caller has initialized the save area and subsequently used it in accordance with IBM linkage conventions, offset 4-7 will contain 4 EBCDIC characters ending iin SA only if it is 144 bytes long; Not true. An example is the longest-existing. That's where the creator of the save area (the target module) identifies that it saved the caller's regs on the linkage stack so placed 'F1SA' at +4. If the linkage conventions are followed, under what circumstances would you be unable to follow the forward chain with a little bit of work? Within your application, maybe, as long as it doesn't use F1SA. If it uses F1SA there is no way of knowing if the forward chain is 4 bytes at +8 or 8 bytes at +136.. Once you get into the system, linkage conventions are not necessarily followed (and additional ones are used), for performance and integrity reasons. Peter Relson z/OS Core Technology Design
Re: Base-less macros
Charles wrote: Ah! I have not been clear on the convention. As I read it now, the called program puts one of the FnSA strings in its *new* save area to indicate how *it* previously stored the registers in its entry save area. This point has been made multiple times in this forum and in IBM-Main. And it's a reason why you can only predictably walk a save area chain backwards. You cannot walk it forwards (unless you know what conventions all the parties have employed). Shmuel wrote CHSI 6(r13),C'SA' Should be adequate to test whether the caller has a long save area. Not true. +4 in the R13 passed to a routine does not indicate how long the save area is. No comparison can tell that. It is up to the caller to satisfy the linkage requirements, whatever they may be (parameters, save area, environment, etc). A called program may not function properly (may not even be able to detect it is not functioning properly) if that does not happen. Charles wrote > the caller must provide a large enough area to allow for the 144 byte Does that not make the problem go away? Simply automatically always save the low order halves of the registers, and if the subroutine will be altering the high halves, save those also. Done. The *caller* has no say in the save area format. Yes, I think that it does make the problem go away. If you know that the caller will always provide 144 bytes, performance-aside, why not just use the 144-byte save area protocol and not worry about it? It's perfectly fine to save high halves in AMODE 31. It's perfectly fine to use high halves in AMODE 31. In many cases, a module that accepts entry in both AMODE 31 and AMODE 64 will choose to run in AMODE 64 (we might call that "CAP64") and thus need to save high halves regardless of the AMODE of the caller. But if you are stuck, for compatibility, with the "old (AMODE 31)" callers passing a 72-byte save area, things are more complicated. Having a unique entry point for each AMODE can be a good approach for such a case. Peter Relson z/OS Core Technology Design
Re: Base-less macros
Steve Smith wrote: >And there are other bizarre ways to return without >restoring R14, which is not actually required by documented conventions. Only restoring of AR14 and the high half of R14 are required (for non-AMODE 64 cases), in general. (Although I would guess that there are many violations of preserving the high half of R14). Some interfaces might define that they preserve R14 completely. Most do not. Mark Hammack wrote >I have a macro that switches between a regular (24/31 bit style) >save area and an extended (64 bit "F4SA") save area. What do you mean by "switches between"? It is fine to use a different style than the style your caller was using (as long as the savearea provided is big enough to accommodate your needs), without having any care about what was being used by your caller. The string at +4 identifies how you saved your caller's registers. Peter Relson z/OS Core Technology Design
Re: FPR usage question
I wrote For z/OS, this question relates to each work unit and the question is "does the work unit use FPRs 8-15 or VRs?". If the answer is no, then that work unit does not save/restore those regs upon undispatch/redispatch and thus saves some cycles. "FPRs 8-15" is incomplete/inaccurate within that. It should be "FPRs 1,3,5,7-15 or the floating point control register (FPCR)". Historically, only FPRs 0,2,4,6 existed and were saved/restored upon undispatch/redispatch. Maybe Shmuel would know even the "pre-history" as to whether FPRs 1,3,5,7 ever existed. The addition of the "additional floating point registers" (1,3,5,7-15 and the FPCR) came with enablement by control register bit, with a program interrupt upon usage without that control register bit (upon which program interrupt, in many cases, the system would automatically activate saving/restoring of the additional FPRs). Peter Relson z/OS Core Technology Design
Re: FPR usage question
Gil wrote Do you save and restore them? The information pertinent to the question is here: https://www.ibm.com/docs/en/zos/2.5.0?topic=registers-linkage-convention-floating-point There is no need to save/restore FPRs 0-7 (as opposed to 8-15). Further info is here: https://www.ibm.com/docs/en/zos/2.5.0?topic=conventions-saving-calling-programs-registers such as: Saving the calling program's registers Unless otherwise defined by the individual interface, the calling program expects upon return: ... FPRs 8 - 15 are unchanged; The Floating Point Control (FPC) Register is unchanged except for two fields: the IEEE exception flags and the data exception code (DXC). Vector registers (VRs) 8 - 15, bytes 0 - 7, and the entirety of VRs 16 - 23 are unchanged. Anything that is expected to be unchanged across a call according to the linkage conventions must be preserved by a user (whether by not using or by save/restore). Gil wrote I remember being asked, "Do you use FPRs? If not, we can bypass saving/restoring them for performance when we gen your dedicated VSE system." For z/OS, this question relates to each work unit and the question is "does the work unit use FPRs 8-15 or VRs?". If the answer is no, then that work unit does not save/restore those regs upon undispatch/redispatch and thus saves some cycles. Peter Relson z/OS Core Technology Design
Re: Curious compiler optimization
Dave Rivers wrote about the "clobber list". I'd say that IBM's C does have a "clobber list" for __ASM. My question would be whether GCC would have the same result for the example that was posed, where the function return was unconditional and there were no outputs identified in the "clobber list" so that, at least as far as the "clobber list" is concerned, the __asm had no identified effect. What would GCC ask their users to identify as "clobbered" if they (for example) just wanted the __ASM to issue linkage instructions to a routine that did some sort of "print"? It could indicate that regs 0,1,14,15 are clobbered (which this did), but that would not be relevant to the function return. And does GCC, as IBM C, feel free to remove the __ASM (or whatever the GCC analog is) in the specific case being discussed? If not, why not? Peter Relson z/OS Core Technology Design
Re: Curious compiler optimization
>At a minimum, there should be an option to say "Leave the asm alone" As I had written previously, there is a standards proposal to do just that. Peter Relson z/OS Core Technology Design
Re: Curious compiler optimization
> In general the rule is if the compiler can see that > there is no dependency on any code, > the compiler is allowed to prune it. Which is a different rule from "if the compiler can not see that there is a dependency on any code , the compiler is allowed to prune it." The second applies to the code, but not the first. True. But one might say that the treating of the __asm text as a black box does mean that the compiler can "tell" -- basing its "knowledge" on the user input. Peter Relson z/OS Core Technology Design
Re: Curious compiler optimization
I discussed this with the C compiler team. As was suggested, the reason for removal in Mario's case was that the compiler had no knowledge that the __asm would do anything that would effect the result. Side effects that could happen under the covers and unknown to the compiler(that could be updates to variables, printf, whatever) are simply not relevant to the discussion. To paraphrase what I was told: In general the rule is if the compiler can see that there is no dependency on any code, the compiler is allowed to prune it. The __asm assembler text is a black box. All that the compiler sees is the C variables in the constraints. In this case, there are no identified side effects or writes to anything relevant and hence cannot affect what the compiler believes is the function's behavior (which as coded was to return "0"). I asked about how to get the __asm expanded anyway. There is already a standards proposal to do just that. So that's something to look forward to (possibly to be implemented by extending the "nodiscard" attribute). But for now, you could -- put that function in it's own translation unit (file) and compile that with no optimization. Then any call should not optimize out the asm statement. -- have a #pragma option_override(asmFunct, "OPT(LEVEL,0)") in the same source file with the function to avoid optimizing the code out Peter Relson z/OS Core Technology Design
Re: z/Architecture Principles of Operation pdf
I don't know if this was responded to or not, but the following is likely true, but not overly important, because it's not the "expected" way It can be obtained by going through https://www-01.ibm.com/servers/resourcelink, however, this requires an IBM Resourcelink user ID and the pub seems to be in a machine model specific library (for example, the "z15 Model T01 library"). : The PoP can be found here: http://publibfp.dhe.ibm.com/epubs/pdf/a227832c.pdf It is within the hardware doc which is where it belongs. It does not require a ResourceLink ID to access. But, yes, it would be nice if there were a link to it from the z/OS doc. And when a new version is posted, they append to assembler-list, providing the link. Peter Relson z/OS Core Technology Design
Re: Curious compiler optimization
Mario, Did you ever try yours but returning the value in functRC (an output from the __asm) rather than 0, just to bound the problem? How much does the compiler attempt to figure out what the __asm is trying to do (besides just manipulating the instructions based on the "symbols"? And what is the "default" with respect to getting the compiler to honor what was coded (and how do you override that default if that default is not right for the case in hand)? Peter Relson z/OS Core Technology Design
Re: Curious compiler optimization
I disagree Mario. Your set of assembled instructions definitely produced some result, but you ended the C program with " return 0; " The __ASM indicated that the only outputs are an internal variable (functRC) and registers (that won't be preserved to the caller). I don't remember if there is some way to indicate that the __ASM sets "anything". Does the C language accept the notion of "side effects" produced by a call (such as changing some global data structure)? Maybe that's not best programming practice but if that is allowed, then the __ASM has to be produced (unless the default for __ASM is that only things identified as changed are changed, including global data structures). Maybe you'd get the same effect with this program if the __asm was instead a "call" to an external routine. Peter Relson z/OS Core Technology Design
Re: Curious compiler optimization
> When it needs zero, it merely copies it into anther > register that it has allocated? Yes, but why not just store the register that they know already contains zero? Because they do not necessarily "know" that when the code is generated. It might well be that the removal of the extra instructions and the "knowledge" itself is an optimization, and the OP asked for no optimization. So this is not a curious "optimization". It is a natural non-optimization. Unless the OP's curiosity was about use of MVHI which, as was pointed out, is fully correct. I'd think that if you want decent code, you don't ask for no optimization. If you do ask for no optimization, you get what you get. Maybe that helps you learn how these compilers generate code. For example, the "initial" pass of the code-gen for z system does not necessarily assume knowledge of there being only 16 GRs available. Regarding "ST r0,var(,r13,160)" I have no idea, but this is not assembler, it is pseudo-assembler. If they don't document otherwise, it can be as "pseudo" as they choose. Maybe the leading comma is to indicate that there is no index register. That's how you'd code it in assembler (of course you'd have the "160" where "var" is). Peter Relson z/OS Core Technology Design
Re: Base-less macros
In a huge number of cases, programs using relative branch are not base-less. They have no "code base register" but that does not mean they are base-less. For the most part, z/OS has simply decided that we will not worry about "no base register at all" cases when customers use our macros. We expect addressability to a static area where literals go. So no "code base register" but a "static data base register". I didn't follow how LOCTR would help unless accompanied by LARL. Without the LARL, you still need addressability to the area built from the data within the LOCTR section. And if you have such addressability then you could have your LTORG within that LOCTR-defined area too so that anyone's macros could use literals. Peter Relson z/OS Core Technology Design
Re: Base-less macros
In general, z/OS macros that accommodate relative branching assume that the user has addressability to a static data area and that they will have a suitable LTORG. And that means that we feel free to use literals in such cases. Of course there are now a lot of "immediate" instructions that can avoid the need for reference to storage containing static data. Peter Relson z/OS Core Technology Design
Re: A question about an Authorizing PC Service Routine
IBM-Main would have been a better home for the post. I discovered this program Curious: did you discover this program's loadmod installed on your system, or did you just discover the source for the program? If the former, you should alert your support staff (and likely upper management) immediately. To be completely fair, without seeing the ETDEF for this PC it is probably not knowable if this is or is not a "magic PC". If the PC were defined to give control in problem state, this might not be an exposure, depending on the PKM that was established. If entered in problem state, the SPKA would blow up unless the key of the SPKA was represented within the PKM. And if that PKM represented the caller's PKM, the caller already had the authority to do that SPKA. Now, the odds of that being why someone created this are close to 0 Once this PC routine Branches back to the users code (BSM 0,1), the user code is running in supervisor state and would issue a PR instruction to remove the entry from the linkage stack. I find this code very messy. How would the user code return to an instruction following the BSM so the PC Service Routine would issue the PR instruction ? We should not care that it's messy; it is unacceptable code regardless. As mentioned above, it is not true that the user code is necessarily running in supervisor state (although likely). The user code's PR would do what PR does when it corresponds to a PC - removing the entry from the linkage stack and giving control to the instruction after the PC, in the PC issuer's state and key (assuming that the key 0 routine did not change the linkage stack entry itself). Peter Relson z/OS Core Technology Design
Re: extracting value of an esoteric
Reminder: this listserv is for questions relating to the assembler itself (e.g., its behavior and the assembler language), not to operating system services that you might invoke in assembler. You will get a much broader set of eyes on your question (and thus often get more help) if you post to IBM-Main. Peter Relson z/OS Core Technology Design
Re: What's wrong with me?
Are you able to get a dump that would have the SDWA in it (or record the error in logrec so you can view it)? RTM presents two sets of registers. One is from "time of error". One is from the RB / linkage stack. I have no idea what an "LE Dump" provides. But I'd be skeptical that anything provides the RB / linkage stack regs as the only set of regs, as that is close to useless for debugging. And of course the SDWA has information about the type of event. Peter Relson z/OS Core Technology Design
Re: Macro to set a bit string
Can there be concurrent updates? OI works fine if on any modern machine, given the interlocked access facilities. If there are no worries about concurrent updates and you don't like executed instructions, Something like this (assumes AMODE 31, bit number < 4G): Larea_address_reg,area_address Leven_reg,bit_num SRDL even_reg,3 * even_reg has the byte offset SRL even_reg+1,29 * odd reg has which bit-within-byte IC some_reg,0(even_reg,area_address_reg) LHI OR_Reg,X'80' SRL OR_Reg,0(even_reg+1) OR some_reg,OR_reg STC some_reg,0(even_reg+1,address_reg) can be used. If there could be concurrent updates, the above approach will not work. Peter Relson z/OS Core Technology Design
Re: Interlocked Acess Facility 2
You haven't had to bifurcate your code like this since z/OS 2.2 which has the z11 as it's minimum requirement. Actually, there was no z/OS release that had z196 as its minimum requirement. z/OS 2.2's minimum is z10. z/OS 2.3's minimum is zEC12 (so includes z196). Regardless, it remains true that as of z/OS 2.3 (and thus for all in-full-support z/OS releases) you can rely on the availability of IAF2. Peter Relson z/OS Core Technology Design
Re: Ensuring LRL 2nd operand alignment
Tony H asked about a use case for LRL: one obvious one is a non-reentrant module. Or, as Shmuel mentioned, it might have been needed for cases where there is no binder support for fullword immediate relocatable expressions. As to the OP's actual question, there are limited choices that come to mind -- the code was not actually running on a z10 or later machine; the OP says "not the case". -- If this is VM perhaps they have done something to ask that VM treat the execution environment as an older machine. There is the concept of the "virtual architecture level". -- the data shown does not represent what happened -- either it was not a PIC 1 or it was not a PIC 1 at that address. If this is repeatable then it could have been helpful to show some preceding data and have the trace that was shown cover the instruction before as well. Regardless, alignment of the operand is not relevant to the discussion. As pointed out, a misaligned operand would have resulted in a specification exception. Peter Relson z/OS Core Technology Design
Re: Add 1, Subtract 1
To add to what Charles M posted, Don't forget that LA in AMODE 31 always zeroes bit 32, and LA in AMODE 24 zeroes bits 32-39 of the 64-bit GR. That's another way that they are not functionally equivalent, if that difference matters to you. A good rule of thumb is that when you have equivalent alternatives, choose the one that has the smallest instruction byte footprint. BCTR is a 2 byte instruction. But don't sacrifice the readability of your code. Peter Relson z/OS Core Technology Design
Re: Determining AR or Primary Mode
It is uncommon to want to do this. If you are SVC-entered or PC-entered, you should know (because at some point you set up the definition). If you are branch-entered when it might be either primary or AR, you would usually save status via BAKR, then switch unconditionally to whichever mode you want to run in and then when you want to determine what mode your caller was in you would use ESTA with the option to extract the PSW from the linkage stack and look at the result (doing the same sort of test that was mentioned if you had done EPSW). It is typically much far more convenient to run in a known state and then, if you need to do something based on your called state, switch conditionally to that, and then switch back to the known state. Peter Relson z/OS Core Technology Design
Re: TBEGINC question
It appears that the editorial rules for Principles of Operation are stricter than those for Services. They certainly are. A lot stricter. Related to the fact that the machine has to enforce restrictions. Software does not "have to" (but of course it can be nice if it does). Peter Relson z/OS Core Technology Design
TBEGINC question
As Keven Hall mentioned, If it were required that there be no crossing of page boundary from TBEGINC through TEND, the principles of operation would have said so. There is no such requirement. Peter Relson z/OS Core Technology Design
Re: Help with EZASMI assembly
An instruction with a zero base does not use the AR associated with the index, so why won't it refer to the wrong AS when in AR mode? I suggested it was a valuable technique, not that it was a valuable technique for accessing data spaces or other address spaces. It is a valuable technique for accessing data that you know is in the primary address space, saving you from having to set an access register. Peter Relson z/OS Core Technology Design
Re: Help with EZASMI assembly
Is there code that has a zero base and non-zero index for something that might not be in common storage or in the primary AS? Wouldn't that cause problems in AR mode? To the first question: aside from the cases that apply to secondary and home ASC modes, I would hope not. To the second question: yes. It is a very valuable technique for AR mode. Peter Relson z/OS Core Technology Design
