Re: Where to find old manuals
Yes, that is the variant which is Java based and which is available at the URL I included in my post. That variant was constructed as a native 32-bit Microsoft Windows application which does not require any additional JRE components. Here is a snippet of prose from the related "install.txt" file: | This release has been repackaged using a special tool to link the | Java Runtime functions along with the Softcopy Reader application | code, building it into a Windows executable instead of a jar | file. In addition to eliminating the prerequisite for the Java | Runtime Environment on the client machine, this change has | significantly improved runtime performance. The 16:16 virtual addressing scheme issue applies to the old "IBM BookManager Library Reader for Windows" product that was once shipped with the CD Collections. Bob On 2024-03-26 12:47 PM, Charles Mills wrote: FWIW, I use Softcopy Reader on Windows 10 Pro 64 bit with no issues. The About says IBM Softcopy Reader 4.0 Service Level S021412 Driver Level SCRV3_011412. Charles
Re: Where to find old manuals
Adding to what Jonathan said, if you use the string shown below for your search argument you'll get a list of about 215 pubs: z/OS V1R9 MVS Most, but not all, of the pubs are available as PDFs. Some are only in Bookmanger format (these are .BOO files). The IBM softcopy reader for Microsoft Windows or the Java based softcopy reader (for Microsoft Windows and Linux) would be needed to read the various BOO files. If I remember correctly, the softcopy reader for Microsoft Windows was produced in executable format (the 16:16 virtual addressing scheme) which hasn't been supported in Microsoft Windows for quite some time (I think the last version which supported this was the 32-bit version of Windows 7). None of the 64-bit variants of Microsoft Windows have ever supported the 16:16 virtual addressing scheme. The URL shown below provides a very brief description of the Java based softcopy reader: https://www.ibm.com/support/pages/ibm-softcopy-reader The URL shown below gets you to a site from which the Java based softcopy reader for Microsoft Windows can be downloaded: https://www.ibm.com/support/pages/ibm-softcopy-reader-windows-v40-0 The URL shown below has a description of the process for installing the Java based softcopy reader on Linux: https://www.ibm.com/docs/en/zos/2.3.0?topic=isrrhlp-installing-from-online-library-collection-kit-cd-rom-linux I do not know from which IBM site the Linux version (ilrjaval.tgz) can be fetched. If you would like, I can place the content of the ilrjava directory as found on the z/OS V1R8 "Tools" CD (from the IBM SK3T-4269-17 Collection) on a site such as Dropbox for you; let me know. Bob Raicer On 2024-03-26 2:35 AM, Jonathan Scott wrote: where can I find the assembler macros manuals from the old z/OS V1R9? Go to the IBM Publications Center https://www.ibm.com/resources/publications and enter this in the search box: z/OS V1R9 MVS Programming Assembler Jonathan Scott, HLASM IBM Hursley, UK
Re: OPCODE tables
What David Cole said is sad and true. After the dissolution of marriage and Kay Bond taking over the business, David and Kay asked me if I would be interested in helping Kay with technical support and maintenance of the Tachyon software suite. I said Yes, and, for a brief time, I did what I could for zero charge (I was a friend and I didn't want any sort of compensation). Unfortunately, Kay lost interest in the products and running a small company, and the rest of the story is the obvious. It really is too bad. The Tachyon software is very good. I started using the assembler when David and I worked together, some time before he and Kay launched the company. I suppose it might be possible to resurrect the products, but Kay would need to be willing to let someone take over the company (probably for some $$$) and that someone would need to help me with the code. I think it's all unlikely. Bob On 2024-03-21 10:41 AM, David Cole wrote: Dave Bond and his wife got divorced. The wife got the business, Dave got his freedom. Tachyon has been orphaned.
Re: Hiding COPY text
I do not believe the suggestion about putting the COPY statement within a macro definition will work as desired. Here is an extraction of the description of the COPY statement as it relates to macros (Chapter 7. How to specify macro definitions, page 227 of SC26-4940-09 High Level Assembler for z/OS & z/VM & z/VSE Language Reference): | COPY instruction | | The COPY instruction, inside macro definitions, lets you copy | into the macro definition any sequence of statements allowed in | the body of a macro definition. These statements become part of | the body of the macro before macro processing takes place. You | can also use the COPY instruction to copy complete macro | definitions into a source module. You might consider doing something like this: PUSH PRINT * COPY IEABRC PRINT OFF Suppress listing of IEABRC text COPY IEABRC POP PRINT You could create a macro that uses AINSERT if you find that more convenient; something like this: MACRO XXXBRC AINSERT ' PUSH PRINT',BACK AINSERT '* COPY IEABRC',BACK AINSERT ' PRINT OFF Suppress listing of IEABRC text',BACK AINSERT ' COPY IEABRC',BACK AINSERT ' POP PRINT',BACK MEXIT , MEND , This would work without having to be concerned about the dependencies of the text of IEABRC needing to be in the open source, and would comply with the documented statement that IEABRC should be COPYed into the source stream.
Re: How to create a pdf file from Mainframe
Are you intending to perform the entire document creation process on z/OS, editing the content by perhaps using some GUI based product, or perhaps using some form of a "batch" type of a product that uses markup tags (something similar to the old IBM BookManager product)? Whatever the tool, if that tool can output AFPDS, but cannot output PDF, you could use IBM Infoprint to "transform" the AFPDS to PDF. It also might be the case that one of the many Virtual Printer programs has been ported to the z/OS Unix environment. Such a program could use the JES SAPI subsystem interface to gain access to SPOOL resident datasets and perform the transformation from a variety of data stream formats to PDF. I haven't looked for such a program, but my guess is that this has been done. Bob
Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?
There have been a few posts in this thread that more or less stated that only complete physical blocks could be read into storage from a device. This is not strictly true. There is the obvious case of truncation, where the number of bytes the device has been requested to transfer is less than the actual physical size of the block. For CCW types of I/O operations (as opposed to TCW types) there is also the possibility of exploiting the "Skip" feature of the channel. Bit 35 (format-0 CCWs) or bit 11 (format-1 CCWs) of the CCW is referred to as the Skip Flag Bit. When this bit is one, the channel suppresses the transfer of data into storage. This flag bit is valid ONLY for read, read-backward, sense ID, or sense operations. Note that the storage device still engages with the data transfer to the channel and all of the data error checking functions (such as ECC) still occur. It is the channel that suppresses the storage of data into memory. When combined with Data Chaining this can be used to store subsets of a data block into potentially discontiguous areas of memory. I do not believe that any of the access methods exploit this, however. OPEN/CLOSE/EOV at one time used this feature when processing Standard User Label tapes. The interesting portion of the channel program was a Read with the Skip Bit on, command chained to a Transfer In Channel back to the Read. When no errors occurred, the channel program ended with Unit Exception status when the Tape Mark at the end of the label set was encountered. Bob
Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?
A PDSE is essentially a form of VSAM Linear, where the physical data set is a collection of 4K-byte blocks. It does not have the notion of CA's and CI's like other VSAM data sets. The notion of BLKSIZE is synthesized and mapped onto the internal PDSE structures; the BLKSIZE value is not the physical unit of transfer size as is the typical case for a traditional Physical Sequential data set. Here is a URL for a SHARE presentation that provides a nice explanation of how a PDSE is put together: https://share.confex.com/share/124/webprogram/Handout/Session16956/PDSE%20Nuts%20and%20Bolts.pdf Bob On 2023-11-13 7:48 AM, Seymour J Metz wrote: Does anybody know whether CI size = block size for PDSE and zFS (linear) data sets? VSAM used to use multiple blocks for a CI.
Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?
I agree with Paul regarding the absurdity he mentioned. Here's another scheme you might want to consider. Let's call the set of logical records currently at the beginning of the data set the Restricted Access Set. Presumably, the remaining records comprise the Unrestricted Access Set. You could create two files: File One contains the Restricted Access Set records. File Two contains the Unrestricted Access Set records. All file I/O can be done with QSAM without needing to perform any type of record location calculations and the corresponding positioning operations. You can make the Block Size anything that makes you happy; let Data Management do all of the blocking and unblocking and deal with all of the device idiosyncrasies. The two files could even reside on very different types of devices and possibly different file systems. Both sets could be read as a logical single entity by concatenating the two files. The Unrestricted Set could be read (and written if so desired) by simply OPENing that file. The same thing goes for the Restricted Set. The concatenation could be done in JCL and/or Dynamic Allocation. If you do not intend to Extend either set, the two files could be members of a PDS, and you can access the members using QSAM. If you DO intend to extend either set (where the containing file is a PDS), then DISP=MOD (or OPEN EXTEND) against a PDS member is disallowed by Data Management. In this case you would need to create a "new" member by copying the "old" member data to the "new" member, and then (without having CLOSEd the "new" member) add the new logical records. After CLOSEing the "new" member you would need to delete the "old" member and rename the "new" member, giving it the "old" member name. In this kind of scenario a PDSE would be better since it never needs to be compressed. Clearly, the two separate files approach is the simplest. Bob
Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?
More than a decade ago when I was working as a developer on the implementation and support of Extended Address Volumes, the plan of record was to "functionally stabilize" BDAM. At that time there was zero work planned or being done on BDAM for EAV support. To be honest, I haven't paid any attention to BDAM since, so I cannot say for certain what BDAM improvements may have occurred. That said, I would avoid using BDAM unless you have absolutely no other choice. As others have advised, you can likely achieve your goal using BSAM, subject to the constraints and caveats they've stated. I agree with the sentiment stated by Binyamin Dissen: "However this is the wrong organization for the file if that is your need. No matter how hard you try, a hammer is a poor tool to put in a screw." Bob
Storage-Key-Removal Facility
While browsing the SA22-7832-13 version of Principles of Operation I saw this text on Page 1-28: |Storage-Key-Removal Facility | |The storage-key-removal facility may be available on a model |implementing z/Architecture. A configuration with the |storage-key-removal facility installed does not have the ability to |use any key protection mechanisms. Setting or reading of a storage |key is prohibited and the PSW key and any specified key must be zero |otherwise an exception condition is recognized. Can any of you provide some insight regarding the motivation for the introduction of this facility, and perhaps what operating system might exploit it? Thanks. Bob
Re: Unsigned 64-bit numbers
- begin snippet (from Paul Gilmartin) I believe what it intends to say is that the two's complement of the maximum negative number is not its algebraic negation. - end snippet I agree with you, Paul, about the "algebraic negation" part of your reply. However, as perceived by the programmer, the LCR instruction does not ignore the carry out of the sign position. I also agree with your point about "knowledge of the hardware implementation". What matters is the behavior of the implementation as it relates to the outcome of the operation as stated in Principles of Operation. In general, there are many variations of machine implementations (think of out of order execution as an example) but which ultimately conform to the model as described in Principles of Operation. Bottom line: I agree with you.
Re: Unsigned 64-bit numbers
- begin snippet (from Dave Clark) That's all well and good, but not germain to the issues being discussed in this thread. - end snippet No worries, Dave. My post was not intended to be a direct response to you. I'm also guessing you meant to use the word "germane" (but that's not particularly relevant to "the issues being discussed in this thread" either).
Re: Unsigned 64-bit numbers
There has been a lot of discussion about the representation of signed binary integers and the common operations of signed addition and subtraction on these items. Since the introduction of the S/360 and continuing on through all of its largely compatible successors, the representation of signed binary integers has remained the same. For the sake of clarity I am going to paraphrase some of the text found in the original S/360 Principles of Operation and the z/Architecture Principles of Operation. A negative number is represented by the two's complement of the positive number of the same absolute value. The two's complement of a number is obtained by forming the one's complement of the number (i.e., inverting all of the bits), adding a value of one in the rightmost bit position, allowing a carry into the sign position, and ignoring any carry out of the sign position. The notation for signed binary integers has a number range in which, for a given length (number of bits), the set of negative nonzero numbers is one larger than the set of positive nonzero numbers. The number "zero" is represented by all zero bits. The two's complement of zero is zero; there is no "negative zero". The maximum positive number consists of a sign bit of zero followed by all ones; the maximum negative number (the negative number with the greatest absolute value) consists of a sign bit of one followed by all zeros. The two's complement of the maximum negative number cannot be represented in the same number of bits. When an operation, such as Load Complement, attempts to produce the two's complement of the maximum negative number, the result is the maximum negative number, and a fixed-point overflow exception is recognized. An overflow does not result, however, when the maximum negative number is complemented as an intermediate result but the final result is within the representable range. An example of this case is a subtraction of the maximum negative number from -1. A fixed-point overflow condition exists for signed binary addition or subtraction when the carry out of the sign-bit position and the carry out of the leftmost numeric bit position disagree. Detection of an overflow does not affect the result produced by the operation. In other words, signed addition and subtraction produce a fixed-point overflow when the result is outside the range of representation for signed binary integers. Considering the various Add and Subtract instructions which operate on 32-bit signed binary integers, there is an overflow when the proper result would be greater than or equal to +2**31 or less than -2**31. The actual result stored after an overflow differs from the proper result by 2**32. The various Add and Subtract instructions which operate on Unsigned binary integers of the same length (for example Add Logical) produce the same results as the corresponding Signed instructions. The instructions differ only in the interpretation of the result. Add interprets the result as a signed binary integer and inspects it for sign, magnitude, and overflow to set the condition code accordingly and, for an overflow condition, potentially cause a Fixed-Point Overflow Program Check interruption. Add Logical interprets the result as an unsigned binary integer and sets the condition code according to whether the result is zero and whether there was a carry out of the high order bit. Such a carry is not considered an overflow, and no program check interruption for overflow can occur. To illustrate the behavior of two's complement operations let's use 8-bit values (the operations behave exactly the same way for fixed point binary integers with a larger number of bits). The maximum positive number is: B'0111 ' = x'7F' = 127 decimal The maximum negative number is: B'1000 ' = x'80' = -128 decimal The two's complement of the maximum negative number: Step 1. Invert all of the bits: B'1 000 ' becomes B'0 111 ' Step 2. Add 1 to the result obtained in Step 1. B'0 111 ' + B'0 000 0001' B'1 000 ' An overflow condition is recognized because a carry out of the leftmost numeric bit (the carry out of bit 1 into the sign bit is a 1) and the carry out of the sign bit (this carry out is a zero) are different. In other words, the overflow condition is recognized because the proper result would be greater than or equal to +2**7 (decimal 128). The resultant number remains unchanged. The resultant number differs from the proper result by 2**8 (2**8 = decimal 256; 256-128=128).
Re: Unexpected C code
The behavior of LCR, LNR and LPR have not changed since the introduction of the S/360. Here are some quotes from GA22-6821 "IBM System/360 Principles of Operation:" For LCR: "An overflow condition occurs when the maximum negative number is complemented; the number remains unchanged." For LNR: "The operation complements positive numbers; negative numbers remain unchanged. The number zero remains unchanged." For LPR: "An overflow condition occurs when the maximum negative number is complemented; the number remains unchanged." The description of the behavior of these instructions as found in SA22-7832 "z/Architecture Principles of Operation" when the operands are both the same size (both are 32-bits or both are 64-bits) matches the S/360 behavior. For LCGFR and LPGFR the first operand is 64-bits and the second operand is 32-bits. These instructions process the maximum 32-bit negative number without recognizing an overflow, i.e., the maximum negative 32-bit number can be complemented and represented correctly as a 64-bit result.
Re: Quadword constant
- begin snippet (from Steve Smith) That's the old-fashioned way. This is the new way: ORG *,16 - end snippet The assembler still cares about SECTALGN. The "old fashioned way" works fine, independent of SECTALGN. Also, note that I explicitly stated mapping quad word aligned storage areas, which, as you and others have noted, can be easily obtained using STORAGE OBTAIN,STARTBDY=4 (and other methods, such as the various Cell Pool services). With respect to ensuring "the alignment matches", it pretty much is always important (I'm sure that you could come up with some use case where you intentionally want a mismatch of the alignment).
Re: Quadword constant
Ed; Of course, what you said about the LQ type of DC is true, and I too have used LQ data types in some of my code too. However, the SECTALGN requirement is a bit of an issue when assembling code with 2**3 (double word) section alignment and which also contains DSECTs which map quad word aligned storage areas. I've had to resort to schemes like what is shown below (I hope the list server doesn't mangle the sample listing too badly). The reason(s) for still having double word aligned sections is (are) a bit lost in antiquity -- inertia is a powerful thing :) : D-Loc Object Code Stmt Source Statement : 1 SAMPLE DSECT , : 2 PRINT ON,DATA : 0010 3 REF DC A(QUADITEM) :0004 00 4 BYTE DC AL1(0) : 5 * - :0005 6 DC (*-SAMPLE)+15)/16)*16)-(*-SAMPLE))AL1(0) :000D 00 : 7 * Round up to a Quad Word : 8 * boundary. : 9 * :0010 10 QUADITEM DC XL16'00' :0018 : 11 END ,
Re: Quadword constant
A couple of more general instructions which require quadword aligned storage operands and 128-bit values in even-odd pairs of 64-bit GPRs: Compare Double and Swap (CDSG) Compare and Swap and Store (CSST) Having the ability to assemble quadword aligned 128-bit items for use with these instructions would be helpful.
Fun Youtube video about the z16
A former colleague sent me this Youtube video link about the IBM Z16. If you haven't seen the video I think you're in for a treat -- it is pretty cool and funny too. https://www.youtube.com/watch?v=ZDtaanCENbc Bob
Relative Addressing
I'd like to attempt to clear up some common misconceptions about the Relative Addressing instructions. The "relative immediate" operand of the relative addressing instructions is a signed value representing a number of halfwords. The immediate operand value is effectively doubled and algebraically added to the address of the instruction (not the address contained in the PSW) to form a 64-bit intermediate address. A carry out of the most significant address bit is ignored. The intermediate address value is then modified according to the current addressing mode: - for 64-bit mode, all 64-bits are retained. - for 31-bit mode, bits 0 through 32 of the intermediate value are effectively set to zero. - for 24-bit mode, bits 0 through 39 of the intermediate value are effectively set to zero. For branch-type instructions when the branch is to be taken, this modified address value replaces the instruction address portion of the current PSW. There are other relative addressing instructions (for example, Load Relative Long) where the relative address calculation is used to obtain the address of an operand in storage. Similarly, for the Execute Relative Long instruction, the relative address calculation is used to obtain the address of a "target" instruction. When the target instruction itself uses relative addressing, the relative address calculations for the target instruction operands are performed as previously described, i.e., they are relative to the address of the target instruction, not the address of the Execute Relative Long instruction. This is all explained in detail in the z/Architecture Principles of Operation. Bob
Re: Test Decimal Instruction
You might want to consider using this (or a similar) code sequence. It eliminates the use of EXECUTE instructions and verifies that the length of the source data is acceptable, i.e., the length is positive and does not exceed the length of the "work area" (field PWORK16). And, of course, it validates the data as being in the Packed Decimal format. [Note: I shifted the code right a couple of columns and put a non-blank in column one to avoid strange text flowing problems with the list server system.] : ZAP PWORK16,KP0 Initialize the area to : * receive the Packed Decimal : * item. : * : CLFI R2,L'PWORK16 * Br if the length of the : JHNOTGOOD * source item is greater : * * than the length of the : * * work area. : * : LNR R15,R2 * Negate the source item : JZNOTGOOD * length and branch if : * * zero. : * : LAR14,PWORK16+L'PWORK16(R15) : * Set the MVCL 'To' adrs. : LRR15,R2 Set the MVCL 'To' length. : LRR0,R1Set the MVCL 'From' adrs. : LRR1,R2Set the MVCL 'From' length. : * : MVCL R14,R0 Copy the source item to : * the work area (right aligned). : * : TPPWORK16 * Verify the copy of the : JNZ NOTGOOD * source item is valid : * * Packed Decimal format. : * : * - do something with the validated data. : * : * : NOTGOOD DC0H'0' : MVC MACRO,=CL8'CONVERT' : LR R5,R7 : LHI R15,-7 : B RETERR : * : KP0 DCPL1'0'
Re: Fun with RXSBG
Hi Dan. I believe you have run into a couple of glitches in the z390 assembler. There is another issue with your WIF macro. The line: LAY ,-1(,) references variable symbol "" which is not defined. The HLASM Language Reference states: : Use the MEND statement to indicate the end of a macro : definition. It also provides an exit when it is processed : during macro expansion. It can appear only once within a macro : definition and must be the last statement in every macro : definition. That last sentence in the IBM doc snippet isn't strictly precise. To try to avoid too many complicating factors, I am intentionally avoiding the discussion of nested macro definitions. Historically, the IBM mainframe assemblers ignore everything following the MEND statement when processing a macro contained in a macro library. IBM has taken advantage of this when producing bilingual (assembler and, for example, PL/X) macros. A simple example of this is macro BPXYENFO. A part of making this work is having a method of telling the alternative language processor (the PL/X compiler in my example) to effectively ignore column one of all lines in the source stream. For PL/I this is the "MARGINS" compiler option: "The MARGINS option specifies which part of each compiler input record contains PL/I statements". When a macro definition is "in-line" with the source stream, the lines following the MEND statement are part of the "open code". Having worked on the development and support of several IBM mainframe assemblers, I can testify that processing source code compatibly is quite challenging; the language rules are not exactly "crisp" nor are they consistent :) But, it is what it is, and the history is long.
Re: Fun with RXSBG
I have used similar logic to "round up" a length or address value with the same architecturally integral constraints. In this old code fragment GPR 15 contains the initial value to be adjusted. Yes, the code needs to be tweaked for 64-bit values. I guess if I hurt my head a bit I could use the ROTATE THEN * SELECTED BITS instructions too ! Nifty (perhaps?)! : DBLRND EQU B'111'A double-word length or : *boundary rounding value. : * : LAR14,DBLRND(,0)Load a double-word rounding : *value. : * : ALR R15,R14 Round up the initial value. : * : XRR14,R15 Obtain the rounded sum with : *the rounding bits inverted. : * : NRR15,R14 Obtain the rounded value. Just out of curiosity, are the various Rotate instructions all implemented in hardware on all of the machine models where they exist?
Re: Interpreting Explicit Decimal Numbers
Thank you, Dave, for your explanation of your use of Rexx stem variables, and your definition of terms. Bob
Re: Interpreting Explicit Decimal Numbers
. Just to be clear, the original implementation of ReXX was for VM . in about 1980, well before OS/2. Oh yes, I totally agree. What I was attempting to say was that the original implementation published by RexxLA was based upon the implementation I cited in the IBM announcement letter. I still have my (mostly hand written) notes from around 1990 related to the IBM OS/2 1.3 implementation of Rexx. To the best of my knowledge (from looking at Mike Cowlishaw's notes which he donated to RexxLA and which once upon a time resided on IBM Hursley Labs systems), Rexx was initially developed from 1979 through 1982 as an internal IBM tool, and was first released as part of the IBM VM/SP operating system around 1983. I remember working on VM in that timeframe and I was thrilled (really!) that I could use Rexx instead of EXEC and EXEC2. As an IBM employee I had the opportunity to chat with Mike Cowlishaw on several occasions. Not surprisingly, I found him to be a delightful individual and extremely helpful. Bob
Re: Interpreting Explicit Decimal Numbers
. Which is he using? Do they differ? Is GAAP a requirement? Does . either Rexx support GAAP? Does COBOL? Does DFP? Let me start off by stating: - I don't know what "GAAP" means. - I am fully aware that Dave Clark is implementing code for z/VSE. I didn't have any of the IBM z/VSE publications on my system, so I used citations from the z/OS publication and the corresponding publication regarding the Rexx implementation for Microsoft Windows and Linux. The latter two are produced by the Rexx Language Association and the original implementation was based upon the IBM implementation for IBM OS/2, Microsoft Windows, and IBM AIX. In October 2004 IBM issued announcement ENUS904-207 which stated: . As part of IBM's continued support of the Open Source community, . Object REXX has been provided by IBM to the REXX Language . Association (RexxLA). The code is now available under an open . source project from RexxLA under Common Public License (CPL) V1. . . For more information, refer to the following Web sites . http://www.RexxLA.org . http://www.ibm.com/software/awdtools/obj-rexx Since that time RexxLA has continued to enhance its implementation and support of Open Object Rexx. There is also an ANSI standard for Rexx (X3J18-199X). The RexxLA implementation is highly conformant to this standard. The IBM implementation on z/OS is somewhat less so (which is kind of ironic, since Rexx is an IBM invention). Today I fetched the VSE/REXX Reference (SC33-6642) from the IBM web site. Its language regarding "Precision" and the "NUMERIC DIGITS" instruction is virtually identical to the citations I used in my post. With respect to the response to my post by Tony Thigpen, advising me to "go back and read all of Dave's posts and and the responses": I have read each and every post since the beginning of the topic started by Dave Clark. I have even contributed some coding examples to try to help him. With respect to clarity, even Dave Clark acknowledged confusion: "But possibly what is confusing is that this thread of questioning is about zoned input which is only indirectly related to the zoned output of the routine I just mentioned." Similarly, Tom Marchant noted his confusion: "I'm confused. Are you passing zoned data in a register? Or the address of zoned data? Or perhaps a binary number?" From my perspective, it is totally reasonable to ask for clarifications from Dave Clark as well as from other contributors to the discussion. Bob
Re: Interpreting Explicit Decimal Numbers
Dave -- I'm not clear on what you mean by "precision" and "scale" when you say: "transform a zoned-decimal number with up to 31 digits of precision and up to 15 digits for scale with an external sign and an explicit decimal point into a packed number that is properly aligned." Do you mean "precision" in the same sense as the definition contained in the Rexx documentation included below? Does "scale" mean a scaling factor in the sense of how COBOL defines it with the "P" character in a PICTURE string? That is, each "P" character in the PICTURE string represents a power of 10 (negative or positive, depending upon where the "P" characters appears in the PICTURE string relative to the "9"s in the string) which is to be used as a multiplier on the actual value. For example, PICTURE 999ppp means the actual area in storage for this data item is only large enough to store three decimal digits, but the value is to be interpreted as being multiplied by 10**3. So a value of "123" is to be interpreted as "123000" when used in, for example, arithmetic operations. Perhaps you intend to mean "scale" as the number of decimal digits to the right of an explicitly specified decimal point, where you intend to support up to 15 such digits. I also don't understand where (or how) implied decimal points are specified in your conversion and representation scheme. For what it's worth, why don't you do all (or the majority) of your decimal string validation and manipulation stuff in Rexx? You're already writing Rexx code and doing this in Rexx itself is way easier and, overall, more robust. ::: . Open Object Rexx Reference . V4.2 (2014-01-10) . . 10.1. Precision . . Precision is the maximum number of significant digits that can . result from an operation. This is controlled by the instruction: . . >>-NUMERIC DIGITS--++--;--->< . +-expression-+ . . The expression is evaluated and must result in a positive whole . number. This defines the precision (number of significant digits) . of a calculation. Results are rounded to that precision, if . necessary. . . If you do not specify expression in this instruction, or if no . NUMERIC DIGITS instruction has been processed since the start of a . program, the default precision is used. The Rexx standard for the . default precision is 9. . . NUMERIC DIGITS can set values smaller than nine. However, use . small values with care because the loss of precision and rounding . affects all Rexx computations, including, for example, the . computation of new values for the control variable in DO loops. . . . NUMERIC DIGITS . . Controls the precision to which arithmetic operations and built-in . functions are evaluated. If you omit expression1, the precision . defaults to 9 digits. . . There is no limit to the value for DIGITS (except the amount of . storage available), but high precisions are likely to require a . great amount of processing time. It is recommended that you use . the default value whenever possible . ::: . . z/OS Version 2 Release 4 TSO/E REXX Reference (SA32-0972-40) . . Precision . . Precision is the maximum number of significant digits that can . result from an operation. This is controlled by the instruction: . . . >>-NUMERIC DIGITS--++--;--->< . +-expression-+ . . The expression is evaluated and must result in a positive whole . number. This defines the precision (number of significant digits) . to which calculations are carried out. Results are rounded to . that precision, if necessary. . . If you do not specify expression in this instruction, or if no . NUMERIC DIGITS instruction has been processed since the start of a . program, the default precision is used. The REXX standard for the . default precision is 9. . . Note that NUMERIC DIGITS can set values below the default of nine. . However, use small values with care - the loss of precision and . rounding thus requested affects all REXX computations, including, . for example, the computation of new values for the control . variable in DO loops. . . . NUMERIC DIGITS . . Controls the precision to which arithmetic operations and . arithmetic built-in functions are evaluated. If you omit . expression1, the precision defaults to 9 digits. . . There is no limit to the value for DIGITS (except the amount of . storage available), but note that high precisions are likely to . require a good deal of processing time. It is suggested that you . use the default value wherever possible . :::
Re: Rules for Zoned Overpunch
Here is another table based scheme which combines sign validation, sign classification (i.e., the sign is negative or positive) and recognition of the preferred sign values. LLC R14,BYTE Fetch the rightmost byte * of the Zoned Decimal field. * SRL R14,4(0) Convert the Zone bits * to a table index. * LAR14,ZDSTBL(R14) * Fetch the corresponding ICM R14,B'0001',0(R14) * table value. * JZINVALID Br if the Zone is not a * valid Sign value. * JMNEGATIVE Br if the Zone indicates * a Negative value. * * Fall through when the Sign is considered Positive. * POSITIVE DC0H'0' TML R14,ZDSTPREF Test for the Preferred * Sign indicator if so * desired. * ... Deal with Positive values ... * J FINISH All done NEGATIVE DC0H'0' TML R14,ZDSTPREF Test for the Preferred * Sign indicator if so * desired. * ... Deal with Negative values ... * J FINISH All done * -- * * The following table is used to validate the 4-bit Zone field of * the rightmost byte of a Zoned Decimal value when interpreting * the Zone value as a Sign value. * * When a table entry is all binary zeros the corresponding Zone * value is not a valid Sign value. * * Preferred Sign values are also indicated. * * The leftmost bit of a table entry is used to indicate the Sign * (Negative or Positive) such that its value (one or zero, * respectively) can be used to set a corresponding Condition Code * when the entry is fetched using the Insert Characters Under Mask * instruction. * * -- ZDSTNEG EQU X'80'When one, the sign is * regarded as Negative. * Else, the sign is regarded * as Positive. * ZDSTPREF EQU X'40'When one, the sign is * regarded as the Preferred * sign. * *EQU X'20'*** Reserved *EQU X'10'*** Reserved *EQU X'08'*** Reserved *EQU X'04'*** Reserved *EQU X'02 *** Reserved * ZDSTVAL EQU X'01'When one, the sign is valid. * DC0D'0' ZDSTBL EQU *,16 DC10AL1(0) Zone values of x'0' * through x'9' are * invalid. * DCAL1(ZDSTVAL) A: Positive, Valid DCAL1(ZDSTNEG+ZDSTVAL) B: Negative, Valid * DCAL1(ZDSTPREF+ZDSTVAL)C: Positive, Preferred, * Valid. * DCAL1(ZDSTNEG+ZDSTPREF+ZDSTVAL) * D: Negative, Preferred, * Valid. * DCAL1(ZDSTVAL) E: Positive, Valid DCAL1(ZDSTVAL) F: Positive, Valid *
Re: Branch-and-Link nomenclature question
The notion of whether some of these linkage instructions could be thought of as "save" and "then branch" is interesting and hasn't changed since the introduction of the S/360. The fundamental concept is that as a part of normal instruction sequencing, the addressing information found in the PSW is updated as part of the instruction fetch and decode process (the instruction length code is used to adjust the instruction address portion of the PSW). For the RR format of these instructions when the "R2" operand is non-zero, the information contained in the "R2" operand is used to compute updated addressing information to be placed into the PSW. The addressing information currently contained in the PSW (this is the "link" information) is placed into the GPR designated by the "R1" operand prior to conditionally (when the "R2" operand is non-zero) replacing the addressing information in the PSW with the computed addressing information (this is the "branch" information). At the completion of the instruction the newly formed PSW is used. Specifying the same non-zero values for the "R1" and "R2" operands on BALR or BASR takes advantage of this concept. I have seen linkage assist services which work in this manner (frequently with the aid of a macro): - GPR 15 is loaded with the address of a function to be called. - GPR 14 is loaded with the address of the linkage assist service. - The linkage assist service is invoked via BASR R14,R14. - The linkage assist service deals with maintaining a "stack" of Save Areas (used to save/restore caller registers and other useful information), loads GPR 14 with the address of the service which unwinds the stack (to effect the "return" to the original caller), and transfers control to the target function whose address was contained in GPR 15 at entry to the linkage assist service. - Upon its completion, the called function "returns" to the address contained in GPR 14 at its entry (which transfers control to the stack unwinding service which, in turn, ultimately transfers control to the original caller). I have no idea if CICS does this kind of stuff. Quoting from the description of the BAL and BALR instructions as found in the September 1968 edition of the S/360 Principles of Operation: "The branch address is determined before the link information is stored." The z/Architecture Principles of Operation essentially states the same thing about BAL, BALR, BAS, BASR: "The branch address is computed before general register R1 is changed." And this is in the description of BASSM: "The new value for the PSW is computed before general register R1 is changed."
Re: Making Encoded Bits Human Readable
Just for fun, here is yet one more variation on Peter's scheme, using only S/360 instructions. In the comments, YY and ZZ represent the two bit pairs of interest, lower case x represents bits or bytes of unknown value. Bit strings are enclosed in square brackets. Bytes are separated by underscore characters. XR R14,R14 R14 = 00_00_00_00 IC R14,BYTE R14 = 00_00_00_[YYZZ] SRDL R14,6(0) R14 = 00_00_00_[00YY] * R15 = [ZZxx]_xx_xx_xx SRL R15,30(0) R15 = 00_00_00_[00ZZ] LA R14,X'F1'(,R14) * Scale x'00' through x'03' LA R15,X'F1'(,R15) * to x'F1' through x'F4'
Re: Making Encoded Bits Human Readable
Making Peter's approach even more old school, use R14 and R15 instead of R0 and R1, and do the character conversion stuff with Load Address instead of Add Halfword Immediate. ICM R14,B'1000',BYTE Put the byte into bits 0-7 SRDL R14,30 Move BYTE.0-1 to reg 14.30-31, * zeroing reg 14.0-29 * BYTE.2-3 to reg 15.0-1 SRL R15,30 Move BYTE.2-3 to reg 15.30-31, * zeroing reg 15.0-29 LA R14,X'F1'(,R14) 0-3 => C'1'-C'4' LA R15,X'F1'(,R15) STC R14,TARGET0 STC R15,TARGET1 BYTE DS X
Re: Making Encoded Bits Human Readable
OK. Let's go through the code one instruction at a time. I1 LLGC R0,BYTE Low order byte of R0 * contains byte of interest. * * Bits 56-59 contain the two * adjacent bit pairs of * interest. * * Bits 60-63 are of no * interest. * * Bits 0-55 are zero. * I2 SRL R0,4(0) Bits 60-63 of R0 contain * the pair of two bits of * interest. Bits 0-59 are * zero. * I3 SRLG R1,R0,2(0) R1 contains the first pair * of bits of interest in bits * 62-63. Bits 0-61 are zero. * I4 NILL R0,B'11' R0 contains the second pair * of bits of interest in bits * 62-63. Bits 0-61 are zero. * I5 AHI R0,C'1' * Convert the bit pairs to I6 AHI R1,C'1' * Zoned Decimal format, * * origined at 1. In the commentary below I will show the bytes of a register as two hex digits per byte, with bytes separated by underscore characters. When showing the bits of a byte, all eight bits will be shown. The bits of the BYTE data item are laid out as follows: JKYZ Where the leftmost two bits (JK) are the first bit pair of interest, and the next two bits (YZ) are the next pair of bits of interest. The remaining four bits () are of no interest. Instruction I1 At the completion of this instruction the 64-bit GPR 0 contains: 00_00_00_00_00_00_00_JKYZ Instruction I2 This shifts the low order 32-bits of the 64-bit GPR 0 right by four bits. The High order 32-bits of the 64-bit GPR 0 are unchanged. At the completion of this instruction the 64-bit GPR 0 contains: 00_00_00_00_00_00_00_JKYZ Instruction I3 This shifts the CONTENT of the 64-bit GPR 0 (not the register itself) right by two bits and places the 64-bit result of the shift into the 64-bit GPR 1. GPR 0 is UNCHANGED by this operation. At the completion of this instruction, the 64-bit GPRs of interest contain: GPR 0: 00_00_00_00_00_00_00_JKYZ GPR 1: 00_00_00_00_00_00_00_00JK Instruction I4 This performs a bitwise AND of the rightmost 16-bits of the 64-bit GPR 0 with the immediate operand of B'0011'. The leftmost 48-bits of the 64-bit GPR 0 are unchanged by this operation. At the completion of this instruction, the 64-bit GPRs of interest contain: GPR 0: 00_00_00_00_00_00_00_00YZ GPR 1: 00_00_00_00_00_00_00_00JK Instruction I5 This performs a Signed Add of the Signed immediate operand value of x'00F1' to the low order 32-bits of the 64-bit GPR 0. Note that a Fixed-Point Overflow cannot occur. The maximum value which can result from the Addition is 00_00_00_F4. The low order 32-bits of the 64-bit GPR 0 are replaced by the resultant sum. The high order 32-bits of the 64-bit GPR 0 are unchanged by this operation. Instruction I6 This performs the identical operation as instruction I5, except the 64-bit GPR being operated upon is Register 1 instead of Register 0.
Re: Making Encoded Bits Human Readable
Here is another possibility that uses instructions which have been available since the publication of the original z/Architecture Principles of Operation in December 2000. It is only one instruction longer (and four instruction bytes longer) than the scheme offered by Dan Greiner, although not as nifty! Bob LLGC R0,BYTE Low order byte of R0 * contains byte of interest. * * Bits 56-59 contain the two * adjacent bit pairs of * interest. * * Bits 60-63 are of no * interest. * * Bits 0-55 are zero. * SRL R0,4(0) Bits 60-63 of R0 contain * the pair of two bits of * interest. Bits 0-59 are * zero. * SRLG R1,R0,2(0) R1 contains the first pair * of bits of interest in bits * 62-63. Bits 0-61 are zero. * NILL R0,B'11' R0 contains the second pair * of bits of interest in bits * 62-63. Bits 0-61 are zero. * AHI R0,C'1' * Convert the bit pairs to AHI R1,C'1' * Zoned Decimal format, * * origined at 1.
Re: Determining a group item
I'm not clear on what you (Joseph Reichman) are attempting to accomplish. If you are going to produce a Rexx program that does something with symbols which appear in some form of an assembler data structure, then you could do something like the example shown below and (as others have suggested) subsequently process the SYSADATA file with the Rexx program. D-Loc Object Code Addr1 Addr2 Stmt Source Statement 0046 1 TEST DSECT , 4040404040404040 2 X1 DC 7CL10' ' 0046 3 X2 DC 0CL20' ' 0046 4 GROUP1 EQU X1,*-X1,C'C' 5 End , Symbol Cross Reference Symbol Length Value Id Type Asm Program Defn References GROUP1 70 C 4 TEST 1 J 1 X1 10 C C 2 4 X2 20 0046 C C 3 Dsect Cross Reference Dsect Length Id Defn Con Member TEST 0046 1 PRIMARY INPUT Here is an extraction from the High Level Assembler Language Reference (V1.6) regarding length attributes of symbols when the "Duplication Factor" is zero: * A duplication factor of zero is permitted, except for literals, * with the following results: * * - No value is assembled. * * - Alignment is forced according to the type of constant * specified, if no length attribute is present. * * - The length attribute of the symbol naming the constant is * established according to the implicitly or explicitly specified * length. For reasons lost in antiquity, an explicitly specified Length value must be positive, e.g., CL0' ' is invalid. Note that: - The Length Attribute of symbol X1 is 10 (decimal) even though it occupies 70 bytes. - The Length Attribute of symbol X2 is 20 (decimal) even though it occupies zero bytes. - The GROUP1 equate gets you the origin location and proper length of a collection of items. There are all kinds of quirks and inconsistencies in how the assembler treats the length attributes of symbols. For example, the length attribute of a DSECT (e.g., L'TEST in this coding example) is always 1 even though the proper length is reflected in the DSECT Cross Reference.
Re: Vector Ops
Very Cool, Dan! Thanks for putting together an excellent and very interest provoking presentation! Bob
Re: Is it possible to update CSA from an unauthorized user-key program?
Using XCF Note Pad might very well be a good choice. I *think* the service was introduced in z/OS 1.13, and enhanced in z/OS 2.2 Here are some links to a SHARE presentation from 2013 which describes the facility a bit and offers an example of how SAP has exploited it. https://share.confex.com/share/120/webprogram/Handout/Session13083/XCF%20Note%20Pad%20Slides%202013%20Feb.pdf https://share.confex.com/share/120/webprogram/Handout/Session13083/XCF%20Note%20Pad%20Handout%20%202013%20Feb.pdf The facility is described in the following IBM pubs for z/OS 2.2 SA23-1399-03 z/OS MVS Setting Up a Sysplex Chapter 6. Planning XCF Note Pad Services in a sysplex SA38-0658-02 z/OS MVS Programming: Sysplex Services Reference Chapter 17. IXCNOTE — XCF Note Pad Interface SA23-1400-03 z/OS MVS Programming: Sysplex Services Guide Chapter 12. Using Note Pad Services (IXCNOTE) I was in the process of composing a note about using the IARVSERV facility which permits shared access to Private Area and Data Space storage among cooperating address spaces, and which does not require elevated privileges (for example: Supervisor State; System Key; APF Authorization) for its use. One of the issues with IARVSERV is that the default amount of storage that can be shared is rather small (sixteen 4K pages); system exit IEFUSI can be used to increase this amount up to 2**31. And, of course, the storage is shared on a given z/OS system -- it is not cross system. Bob
Re: z/Architecture Principles of Operation pdf
I somewhat agree that z/Architecture is not "a feature of z/OS", however, access to Principles of Operation is mandatory in order to to write (or even study) assembler code. Numerous other z/OS pubs make many references to Principles of Operation. For example, the statements shown below extracted from page 65 within "z/OS Version 2 Release 4 MVS Programming: Extended Addressability Guide" (SA23-1394-40): "The purpose of this section is to help you use the 64-bit GPR and the 64-bit instructions as you want to save registers, perform arithmetic operations, access data. It is not a tutorial about how to use the new instruction set. Principles of Operation is the definitive reference book for these instructions." It appears that IBM is a bit inconsistent about how to obtain the z/Architecture Principles of Operation. I thought I would take peek at the z/VM library at: https://www.vm.ibm.com/library/index.html Down on the left hand side of the page is an item labeled "z/VM Related PDFs" which gets you to: https://www.vm.ibm.com/library/other.html If you type "Principles" in the "Filter" box on the resultant page you'll see the download links for SA22-7832-12 (z/Architecture Principles of Operation) and SA22-7201-08 (Enterprise Systems Architecture/390 Principles of Operation). The links work and no IBM user ID is required. Also, on the z/VM Indexed PDF page (https://www.vm.ibm.com/library/pdfzip.html) there is this statement: "Note: Starting with the 2019 April Refresh Collection the z/VM Related PDFs will no longer be included. Please see earlier collections or see the Related PDFs page." Hopefully the "Related PDFs page" will continue to be available. To the IBMers: Any chance on having a similar Related PDFs link on the z/OS home page? Bob
z/Architecture Principles of Operation pdf
I am curious to know why z/Architecture Principles of Operation (SA22-7832) is not included in the z/OS 2.5 documentation collection (ZOSV2R5-PDFKIT_GA2021.zip), nor is it in the z/OS 2.4 documentation collection (zOSV2R4Library.zip), nor is it in the z/OS 2.3 documentation collection (zOSV2R3Library.zip). SA22-7832-10 WAS included in the z/OS 2.2 collection (C27843006.zip) and a current-at-the-time version was included in all prior collections (as best as I can tell). 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"). Is there some (sensible) reason for this? Thanks. Bob Raicer
Re: Base-less macros
I've been using (for a shockingly large number of years!) the approach that Keith Moe and Charles Mills described. It has worked very well and caused no trouble for my product development and support teams. All of the products on which I've been a designer and developer have been nearly 100 percent OCO, so, in the main, we don't have to be concerned with code written by customers. When we ship assembler macros for customer use we have the tendency to use BRAS to branch around in-line constants when absolutely necessary (but we try very hard to avoid this). We also have a lot more usage of the machine instructions which have appropriate immediate operands (things like Load Logical Immediate). Bob
Re: Table processing question
Hi Fred; I sent an e-mail directly to you with an example attached. I've found that trying to post code samples to the list server often gets messed up -- formatting gets lost. I don't know if "attachments" are preserved when e-mailing to the list server and what happens when some folks use the "list digest". Bob Raicer
Selective upper casing of assembler source code
Also, long ago and far away, I wrote a Rexx program to read the assembler source file, perform selective upper casing and write a new file. Comments (both free standing and line end) were left as is; labels, operation codes and most operands were upper cased. My Rexx code did its best to parse the source lines, recognizing quoted strings, continuation lines and so on. I also recognized "special" free standing begin/end comments to tell the Rexx code to simply leave the intervening lines alone. The code certainly wasn't perfect, but it worked well for my style of coding. I chose Rexx because it was easy to "port" to VM/CMS, MVS and the PC. Having a separate program did away with editor dependencies, as well as specific assembler dependencies (such as exits). Yes, it was an extra step in my overall development process and it added a little bit of overhead, but for me this was an acceptable solution. Bob
Re: Conditional MVCL macro?
On Tue, 20 Oct 2020 16:58:52 -0400 Steve Smith said: And for something completely different... sometimes I use MVCK for a variable-length move instead of EX/MVC or MVCL. I haven't done any performance tests, because I haven't used it in performance-critical code (and it does have a warning that it is slow). But for programming convenience, getting & setting the key is (at least slightly) less of an annoyance than setting up EX. I vaguely recall a rumor that there is an MVCX milli-code instruction that works the same without the key specification. Sure would be nice if that appeared in PoOp. Perhaps you are thinking of the MVCOS (Move with Optional Specifications) instruction? The instruction has been around for quite a while. To the best of my knowledge, the instruction was first documented in SA22-7832-06 (z/Architecture Principles of Operation, 7th edition, February 2008) and was patented by IBM in Europe on 29 November 2007 (International Publication Number WO 2007/134646 A1). And as you noted, all of these "storage access key" type of data copying instructions (MVCK, MVCSK, MVCDK, etc.) are going to have poorer performance than instructions like MVC, MVCL and MVCLE, but they can be convenient/appropriate to use in certain situations. Quoting from Principles of Operation: "The performance of MOVE WITH KEY on most models may be significantly slower than that of the MOVE (MVC) and MOVE LONG instructions." Bob
Re: Deep Cuts
On Sun, 6 Sep 2020 16:48:18 -0700 Charles Mills wrote: > I'm familiar with the use of NULL as a "special" value. I think > the C standard says that 0 may never be a valid address. The ISO/IEC 9899:20xx "C" standard cites no restriction on the value zero being an invalid address. An extraction from the standard: Topic 6.3.2.3 Pointers An integer may be converted to any pointer type. Except as previously specified, the result is implementation-defined, might not be correctly aligned, might not point to an entity of the referenced type, and might be a trap representation. An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant. If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function. In other words, the standard requires that the simple assignment of the integer value zero to a pointer causes that pointer to be assigned the implementation defined value of NULL. For example: char *somepointer = 0; A conforming compiler treats the above assignment as: char *somepointer = NULL; While on most implementations this assigns the value zero to "somepointer", it is not necessarily so; the value of NULL may be any bit pattern which satisfies the constraints stated in the standard. Most implementations define NULL (for example, in stdlib.h or stddef.h) as: #define NULL ((void *)0) An example of an implementation dependent way to get the value zero assigned to a pointer is shown below. The "trick" here is that the value being assigned is not a constant expression. volatile int intzero = 0; char *somepointer = (char *)intzero; C does not prohibit dereferencing the NULL pointer; rather it makes it undefined (and implementation dependent) behavior. Certainly, on an IBM mainframe beginning with the S/360 and continuing to the present, it would be awkward (and obnoxious) to be unable to reference the PSA via a pointer variable. Bob
Re: z390 RLD Entries ... Bug or Feature?
Here are a few more tidbits of information regarding relocatable address constants (summarized from the disjoint information contained in SC26-4940-06, High Level Assembler for z/OS & z/VM & z/VSE Language Reference): 1-byte relocatable constants have never been allowed. 2-byte relocatable constants are allowed and the assembler will produce message "ASMA066W 2-byte relocatable address constant" unless assembler option RA2 is specified. Quoting from "High Level Assembler for z/OS & z/VM & z/VSE Programmer's Guide Version 1 Release 6" (SC26-4941-08): "RA2 Instructs the assembler to suppress error diagnostic message ASMA066W when 2-byte relocatable address constants, such as AL2(*) and Y(*), are defined in the source program." Only AD type address constants may have lengths (in bytes) over the range 5-8 inclusive. VD type address constants may have lengths (in bytes) of 3, 4 or 8. The Tachyon z/Assembler correctly assembles (and produces the correct Relocation Dictionary items) for this slightly modified version of Dan's test program (I specified RA2 and XOBJ assembler options): RLDNFG CSECT , A DC AD(H) B DC ADL2(G) C DC ADL3(F) D DC ADL4(E) E DC ADL5(D) F DC ADL6(C) G DC ADL7(B) H DC ADL8(A) END , I do not have local access to another fairly popular cross-assembler produced by Dignus (see http://www.dignus.com/dasm/). However, Dignus permits the assembly of small source files on their web site (http://www.dignus.com/dasm/asmit.html). The assembler version is DASM V1.95.11. Unfortunately, their web site doesn't permit specifying any assembler options and the object code format is the old OBJ rather than XOBJ/GOFF, so the RLD entries for statements 7 through 10 are incorrect. Also, the *PROCESS statement does not permit specifying XOBJ or GOFF, so I cannot correspondingly instruct the assembler using that method. Here is the Dignus assembly listing (I edited the listing a bit to hopefully avoid line wrapping problems when posting this message to the list server): Loc Object Code Addr1 Addr2 Stmt Source Statement 1 *PROCESS RA2 002B 2 RLDNFG CSECT , 0023 3 A DC AD(H) 0008 001C 4 B DC ADL2(G) 000A 16 5 C DC ADL3(F) 000D 0011 6 D DC ADL4(E) 0011 0D 7 E DC ADL5(D) 0016 000A 8 F DC ADL6(C) 001C 08 9 G DC ADL7(B) 0023 10 H DC ADL8(A) 11 END , Relocation Dictionary Pos.Id Rel.Id Address Type Action 0001 0001 A 4 + 0001 0001 0008 A 2 + 0001 0001 000A A 3 + 0001 0001 000D A 4 + 0001 0001 0011 A 1 + 0001 0001 0016 A 2 + 0001 0001 001C A 3 + 0001 0001 0023 A 4 + Bob Raicer
The Condition Code as a return value from a called function and LEAVE in Rexx
I am no doubt joining in on the conversation regarding using the
Condition Code as a return value from a called function/sub-routine,
as well as the conversation regarding the LEAVE construct in Rexx.
I am certainly not a fan of using the Condition Code as a return
value from a called function. It is rather limited (only a two bit
integer) and does not work for functions invoked by other
programming languages (for example, "C").
The SPM (Set Program Mask) instruction has been around since the
introduction of the S/360 (announced in 1964, 56 years ago). The
S/370 was announced in 1970 (50 years ago). MVS/XA was announced
in 1983 (37 years ago) and that's when the IPM (Insert Program Mask)
instruction appeared.
Unfortunately, IBM Rexx for z/OS is way behind the times. ooRexx has
supported the "Label" keyword on the "Do" instruction (and several
other instructions, for example, "Select") for quite some time (the
support was present in Version 4.0 in August 2009).
The syntax is roughly this, where optional components are shown
within braces:
DO {LABEL name} {repetitor} {conditional} ...
Here is an excerpt from the documentation of the "Do" instruction
regarding the "LABEL" component/phrase:
"The LABEL phrase, if used, must precede any repetitor or
conditional."
Here is an excerpt from the documentation of the "Leave" instruction
which describes how the "Label" on a "Do" is used:
"The name is a symbol, taken as a constant. If name is not
specified, LEAVE ends the innermost active repetitive loop. If name
is specified, it must be the name of the control variable or LABEL
name of a currently active LOOP, DO, or SELECT, which can be the
innermost, and that block, and any active block inside it, are then
ended. Control then passes to the clause following the END that
matches the instruction of the selected block."
The ANSI Standard for Rexx (X3J18) has not been updated since
1998 and consequently does not reflect the notion of the "Label"
keyword on "Do", etc.
Bob Raicer
Re: Questionable Instructions in Obtaining EAX documentation
Well, the statement from Peter Relson (and others) which is essentially: -- LA R1,1 is exactly equivalent to LA R1,1(0). Just look at the generated object code. -- is not totally true. It all depends upon which USINGs are in effect. Take a peek at the following example (admittedly a bit unusual, but perfectly legitimate). Loc Object Code Addr1 Addr2 Stmt Source Statement 0008 1 EXAMPLE CSECT , R:9 2 USING 0,9 4120 9100 0100 3 LA 2,256 0004 4120 0100 0100 4 LA 2,256(,0) 5 END , If the intent is to place a truly non-relocatable value (e.g., a constant) into a GPR (which IS the intent of this example), then I believe the coding style of statement 4 is the preferred way to go; it is explicit and unambiguous. This applies to many other instructions which use base+displacement operands (examples: SLL, SRL, SLDL) which are not interpreted as address values. Bob
Re: Getting the Last Condition Code
Speaking as someone who has worked on OS and I/O subsystem development for more than 45 years, I wholeheartedly agree with the comments and observations posted by Brent Longborough. I've always found the style of invoking some function and depending upon the Condition Code upon return to be worse than just smelly. If, during the course of a code review, the more seasoned folks on my development team encountered that style, the code was rejected and it was required to be reworked. I'm also not a big fan of the "vectored returns" (e.g., B 0(,R14) for one condition, B 4(,R14) for another, etc.). Among other things, this introduces an undesirable dependency upon the size of the instruction(s) following the linkage instruction in the caller's code. Return Codes and Reason Codes (typically in R15 and R0, respectively) work quite nicely and are much more maintainable. Of course, nothing is perfect and developers need to be very much aware of what they are doing and what kind of a mess (or hopefully, lack thereof) they are leaving for the next individual who has to work on the code. Bob
Re: Modify ECB COMECBPT Intermittent response
The scenario you describe creates, at the minimum, race conditions and you can (and likely will) get a S301 ABEND. (Attempting to WAIT on an ECB which already has its WAIT bit set to one).
Re: SVC99 DEALLOC Failure
How about posting a hex dump of your complete DYNALLOC interface data structures upon return from your Unallocation request: S99RB: the DYNALLOC Request Block S99RBX: the DYNALLOC Request Block Extension S99TUNIT: the complete set of DYNALLOC Text Units IGDMCSMG: the set of SMS/DYNALLOC Message Elements There are a lot of possibilities about why your request isn't working as you would like (or expect). FYI, the DUNUNALC text unit specifies that the resource is to be deallocated even if it has the permanently allocated attribute. This most often applies to resources allocated via JCL. Bob
Re: Curosity Question About ESTA and MSTA
The short answer to your question is No. I think you have a fundamental misunderstanding of the operation of the Linkage Stack mechanism. You should carefully read "Chapter 2. Linkage stack" within IBM publication SA23-1394-00 "z/OS MVS Programming: Extended Addressability Guide" (this is the z/OS 2.1 version, but nothing of great significance has changed in this area for quite some time). The Modifiable Area of a Linkage Stack frame is typically intended to be used in association with ARR's. For some relevant discussion, look at "Chapter 18. Providing recovery" within IBM publication SA23-1371-02 "z/OS MVS Programming: Authorized Assembler Services Guide Version 2 Release 1" With respect to the z/Architecture perspective on the Modifiable Area of a Linkage Stack frame, read subtopic "Adding and Retrieving Information" within major topic "Linkage-Stack Introduction" within IBM publication SA22-7832-11 "z/Architecture Principles of Operation". Here is the text extracted from that subtopic: + Adding and Retrieving Information + + The instruction MODIFY STACKED STATE can be used by a program to + place two words of information, contained in a designated + general-register pair, in an area, called the modifiable area, of + the current linkage-stack state entry (a branch state entry or a + program-call state entry). This is intended to allow a called + program to establish a recovery routine that will be given control + by the control program, if necessary. Bob
HLASM treatment of RMODE for an ENTRY point label
I've noticed that the IBM CELQPRLG macro emits the following statements unconditionally (the numbers in parens at the start of each line below are for reference; they are not an actual portion of the emitted statement). (1) ENTRY CEEEPNM (2) CEEEPNM DS 0H (3) CEEEPNM AMODE 64 (4) CEEEPNM RMODE ANY I'm trying to understand why the High Level Assembler doesn't flag statement 4 as being in error, since specifying RMODE for a symbol defined as an ENTRY point (which was done on statement 1) is not supposedly valid. Here is what the HLASM Language Reference (SC26-4940-06) states about the RMODE statement: RMODE instruction The RMODE instruction specifies the residence mode to be associated with control sections in the object deck. name RMODE 24 31 64 ANY name Is the name field that associates the residence mode with a control section. If there is a symbol in the name field, it must also appear in the name field of a START, CSECT, RSECT, or COM instruction in this assembly. If the name field is space-filled, there must be an unnamed control section in this assembly. If the name field contains a sequence symbol (see “Symbols” on page 25 for details), it is treated as a blank name field.
Re: ADRDSSU VTOC -- also IEBCOPY
On Fri, 6 Jun 2014 10:43:57 -0600, Paul Gilmartin
paulgboul...@aim.com wrote:
I suspect the restriction (we have it at 1.13) spans many
releases. How silly to go to trouble to avoid doing nothing.
DISP={OLD|NEW} seems to make no difference. I suspect that DISP
is among many DD options that are simply ignored in connection
with DUMMY.
Here are few extractions from the DUMMY Parameter topic contained
within z/OS 1.11 MVS JCL Reference (SA22-7597-13):
Because no I/O is performed to the dummy data set, the system
checks the SPACE and DISP parameters, if coded, for syntax,
then ignores them. If you code UNIT with DUMMY, the system
will ignore it if the specified unit name is syntactically
correct and defined to the system. Otherwise the system
terminates the job.
:
:
:
Use one of the following access methods with the DUMMY
parameter:
. Basic sequential access method (BSAM)
. Virtual storage access method (VSAM)
. Queued sequential access method (QSAM)
. BDAM load mode (BSAM with MACRF=WL in the data control
block)
You'll notice that BPAM (and many other access method types) is
(are) not supported. Nothing has changed here in decades.
I certainly cannot look at the source code for IEBCOPY, but I
suspect that IEBCOPY simply checks the device type associated with
the DD to be operated upon and if it's not something it likes (i.e.
DASD, TAPE) you get the results you're seeing. Actually supporting
DUMMY allocations would require more work, not less as your
assertion implies.
Bob
Re: ADRDSSU VTOC -- also IEBCOPY
I don't think there is anything particularly wrong with what you propose, however, it is both more code/work than what currently exists and looking inside the data set referenced by the DD being operated upon can only happen after it is OPENed (and the BPAM OPEN will fail when referencing a DUMMY allocation). Bob On 2014-06-07 9:30 AM, Robert A. Rosenberg wrote: At 08:30 -0600 on 06/07/2014, Bob Raicer wrote about Re: ADRDSSU VTOC -- also IEBCOPY: I certainly cannot look at the source code for IEBCOPY, but I suspect that IEBCOPY simply checks the device type associated with the DD to be operated upon and if it's not something it likes (i.e. DASD, TAPE) you get the results you're seeing. Actually supporting DUMMY allocations would require more work, not less as your assertion implies. I disagree. Here is my reasoning. Support of output to SYSUT2 requires that for each file that is being selected to be potentially copied to SYSUT2, there is a check to see if it already is in the PDS(E) UNLESS Replace (SYSUT2,R) is coded in the Copy command before the copy is attempted. If SYSUT2 is DUMMY/NULLFILE, then the check is bypassed and the copy acts as if the file does not exist in SYSUT2. All that is needed is to error at open time if you have a DUMMY as input. For output, set a flag that says the dataset is dummy, and as each file is selected, just issue the copied to message bypassing any reading of the member itself. Note, I am assuming that you do not want to be warned of duplicate files from input (ie: No Replaced or Not Copied messages). If I am missing something in this analysis, please point it out.
Re: Rexx substr not retiring string
John (Walker); I believe you are confusing the notion of a null terminated string and a line whose length is zero. A null character (in both ASCII and EBCDIC) is a byte whose value is 0x00, i.e., all bits are zero. In the C programming language (and many other programming languages), the end of a character string is defined as the first occurrence of a null byte when viewing the string from left to right. For example, the character string ABC consists of the single characters A, B and C, followed by a 0x00 byte. The logical length of this string is three. A C string consisting solely of a 0x00 byte is a null string and the logical length of this string is zero. Rexx, unlike C, does not have the notion of null terminated strings. In fact, a string in Rexx may contain any combination of character values. A null string in Rexx is one whose length is zero. The following simple Rexx program (and its corresponding output) illustrates these Rexx string concepts. The Program - /* REXX */ Parse version RexxVers say RexxVers say String_1 = ABC say String_1: sayLength: Length(String_1) sayValue: 0xC2X(String_1) say String_2 = X2C(00) say String_2: sayLength: Length(String_2) sayValue: 0xC2X(String_2) say String_3 = say String_3: sayLength: Length(String_3) say Return (0) - The Output - REXX-ooRexx_4.1.3(MT) 6.03 4 Jul 2013 String_1: Length: 3 Value: 0x414243 String_2: Length: 1 Value: 0x00 String_3: Length: 0 -- You'll notice that I executed this Rexx program on a platform other than z/OS (the actual system is the 64-bit version of Microsoft Windows 7 Ultimate). I did this deliberately in an attempt to illustrate that even on a platform which is biased towards null terminated strings, Rexx strings are not null terminated. You can run this yourself on z/OS. Unfortunately, IBM's EXECIO documentation is written rather poorly. In particular, this statement taken from the TSO/E REXX Reference is misleading and imprecise: When EXECIO writes an arbitrary number of lines from a list of compound variables, it stops when it reaches a null value or an uninitialized variable (one that displays its own name). A null value in this context really means a variable whose value LENGTH is zero, not whose actual value is a single null byte. The second part of that same sentence (talking about an uninitialized variable) is also imprecise and somewhat incorrect. Rexx absolutely distinguishes the initialized versus uninitialized states of a variable. While it is true that the implicit value of an uninitialized variable is the name of that variable, the explicitly assigned value of a variable may certainly be its own name. For example: X = X Bob
Re: Rexx substr not retiring string
Take a look at the EXECIO topic within Chapter 10. TSO/E REXX commands in IBM pub z/OS TSO/E REXX Reference Version 2 Release 1 (SA32-0972-00). Among other things you'll see that specifying * as the first EXECIO operand (this is the lines parameter) when DISKW is specified as the second operand does not mean that all of the stem set elements will be processed nor does it mean that the value contained in the zero'th (stem.0) element is used to determine the number of lines to be written. Rather, the behavior is documented as: lines the number of lines to be written. This operand can be a specific decimal number or an arbitrary number indicated by *. : : : When EXECIO writes an arbitrary number of lines from a list of compound variables, it stops when it reaches a null value or an uninitialized variable (one that displays its own name). The 0th variable has no effect on controlling the number of lines written from variables. Also, look at example 12 on page 239 of this same publication. This example illustrates how to read all of the records from a file and populate a stem variable set, and subsequently, write the populated stem variable set to another file. It also illustrates the trouble you can get into when specifying * as the lines operand in concert with DISKW. Bob
Re: REXX interface
I'm not really sure what the original question was all about: === On Wed, Mar 19, 2014 at 9:04 AM, John Walker jwalker...@yahoo.com wrote: Rexx execs are EASY. But, Rexx interface, is that something different? === The IBM publication to which Steve Smith was referring is: z/OS TSO/E REXX Reference Version 2 Release 1 (SA32-0972-00) There are other versions of this pub for various versions of z/OS. You are most likely interested in the information contained in these chapters: Chapter 8. Using REXX in different address spaces Chapter 12. TSO/E REXX programming services Chapter 13. TSO/E REXX customizing services Chapter 14. Language Processor Environments Chapter 15. Initialization and termination routines A similar publication exists fo z/VM: z/VM REXX/VM Reference Version 6 Release 1 (SC24-6221-00) In the United States, these publications are available free of charge at: http://www-05.ibm.com/e-business/linkweb/publications/servlet/pbi.wss?CTY=US For other countries, omit the ?CTY=US at the end of the URL and navigate through web interface to select the desired country/region/language. Bob
Re: The Future of the ITSO
IBM is thrashing about, trying to find ways to reduce the erosion of profit margins. Producing high quality product documentation is time consuming and necessarily involves the resources of many people. Internally, this is regarded as essentially pure overhead. When this is coupled with the belief that customers don't read the pubs much (yes, my management has told me this numerous times while not too harshly chastising me for spending too much time on producing documentation for product components which I've developed or modified), it's pretty easy to see and understand what's happening. The BookManager (.BOO) files are gone and it won't be long before the PDFs are gone too. The InfoCenter flavor of the documentation is also headed for the graveyard. This is a very disheartening trend. IBM mainframe customers (and competitors and non-customers) have long benefited from the availability of essentially free IBM product documentation, the great majority of which was accurate and complete. Those days are coming to a close. We all vote with our wallets and, as the old saying goes, you get what you pay for (but you usually get less). Bob
Re: Relative Branches / IBM macros
Here is an example of what I was trying to describe: ABLE CSECT , EXTRN IEFBR14 USING ABLE,R7 LARL R15,IEFBR14 BRC 0,IEFBR14 LHI R15,(IEFBR14-ABLE) LHI R15,(SECOND-FIRST) OFFSET DCA(IEFBR14-ABLE) FIRSTDCF'1' SECOND DCF'3' And here are some snippets from the assembly listing: C0F0 22 LARL R15,IEFBR14 0006 A704 23 BRC 0,IEFBR14 000A 24 LHI R15,(IEFBR14-ABLE) ** ASMA032E Relocatable value or unresolved symbol found when absolute value required - (IEFBR14-ABLE) ** ASMA435I Record 24 in RAICER.TEMP.SOURCE(SIMPLE) on volume: DV2D19 000E A7F8 0004 0004 25 LHI R15,(SECOND-FIRST) 0024 30 OFFSET DC A(IEFBR14-ABLE) 0028 0001 31 FIRSTDC F'1' 002C 0003 32 SECOND DC F'3' Relocation Dictionary Pos.Id Rel.Id Address Type Action 0004 0006 0002 RI 4 + 0004 0006 0008 RI 2 + 0004 0004 0024 A 4 - 0004 0006 0024 A 4 + Statements 22 and 23 cause entries to be placed in the Relocation Dictionary which indicate the Relocation Type is Relative Immediate and the size (in bytes) of the corresponding item to be adjusted by the relocation processing is four and two, respectively. For statement 24, entries in the Relocation Dictionary would be required in order to compute the Absolute Value of the expression during relocation processing, much like the RLD entries necessary to resolve the same expression for statement 30. And, yes, binder support is required for this, much like the binder support needed to handle the RLD items for statements 22 and 23. Bob
Re: Relative Branches / IBM macros
It seems to me that the real problem is that the assembler is inconsistent with respect to the evaluation of expressions and using the result of such an evaluation in various contexts. The HLASM Language Reference clearly states the requirement of Immediate Data operands for machine instructions: Immediate data In addition to registers, numeric values, relative addresses, and lengths, some machine instruction operands require immediate data. Such data is assembled directly into the object code of the machine instructions. Use immediate data to specify the bit patterns for masks or other absolute values you need. Specify immediate data only where it is required. Do not confuse it with address references to constants and areas, or with any literals you specify as the operands of machine instructions. Immediate data must be specified as absolute expressions whose range of values depends on the machine instruction for which the data is required. The immediate data is assembled into its binary representation. The HLASM Language Reference defines an Absolute Expression as shown below: Absolute expression: An absolute expression is one whose value remains the same after program relocation. The value of an absolute expression is called an absolute value. An expression is absolute, and is reduced to a single absolute value if the expression: 1. Comprises a symbol with an absolute value, a self-defining term, or a symbol length attribute reference, or any arithmetic combination of absolute terms. The absolute terms can include Integer and Scale attributes, but not Type attributes. 2. Contains relocatable terms alone or in combination with absolute terms, and if all these relocatable terms are paired. Paired relocatable terms: An expression can be absolute even though it contains relocatable terms, if all the relocatable terms are paired. The pairing of relocatable terms cancels the effect of relocation. The assembler reduces paired terms to single absolute terms in the intermediate stages of evaluation. The assembler considers relocatable terms as paired under the following conditions: . The paired terms must have the same relocatability attribute. . The paired terms must have opposite signs after all unary operators are resolved. In an expression, the paired terms do not have to be contiguous (that is, other terms can come between the paired terms). The assembler permits relocatable expressions in the operands of Relative Immediate instructions (such as Load Address Relative Long [LARL], Branch Relative on Condition [BRC], etc.). For instructions in which one or more operands must be Immediate Absolute values (such as Compare Logical Immediate [CLI], Load Halfword Immediate [LHI], etc.), the assembler disallows the use of paired relocatable terms in an Absolute Expression when any of those terms require creating an entry in the Relocation Dictionary. In my opinion, this is an unnecessary restriction, but it is what it is. Bob
Re: how to: document usage of bit(s) of a register.
If what you're really trying to do is to copy the low order 32 bits of GPR 13 into the high order 32 bits of GPR 0, while leaving the low order 32 bits of GPR 0 unchanged, then the following I-stream will do the job. RLLG R0,R0,32(0) Exchange the high order and * low order 32 bits of GPR 0. * LRR0,R13 Copy the low order 32 bits * of GPR 13 into the low * order 32 bits of GPR 0. * RLLG R0,R0,32(0) Exchange the high order and * low order 32 bits of GPR 0. * * The high order 32 bits of * GPR 0 now contain a copy of * the low order 32 bits of * GPR 13. * * The low order 32 bits of * GPR 0 are what they were * prior to the first RLLG. Bob
Re: the fine manuals
First, the mandatory disclaimer: The content of this message is my personal view only and does not in any way reflect the opinion or position of my employer. I couldn't agree more with the overall sentiment about Infocenter -- it's miserable. As a developer, I find it very challenging to get the technical content for the product I work on to be reflected in the pubs as I would like. We (the developers) do not have access to the tools the Information Development folks (a.k.a, the technical writers) use to actually produce the pubs. Consequently, we get sent XML and sometimes PDF for document sections to review. The cycle of attempting to edit these things to provide feedback to the ID folks followed by the next iteration to review is awkward (I use third party software to get the job done as best as I can, as do many of my teammates). We also have another HTML based internal tool to use for the review process, but it's even worse. Often, it's very difficult to know where in Infocenter (or even in which pub) the documentation being reviewed will ultimately reside. At least with a PDF or the BookManager format file one can see and navigate through the various topics in context. I still use the old V2.0.3 IBM Library Reader for Windows (READIBM.EXE), product number 5799-PXY. It runs fine in Windows 2000 and mostly OK in Windows XP (on XP it sometimes crashes with a GPF). It will not run at all natively on the 64-bit versions of Windows 7. Running a Windows 2000 virtual machine (Virtual Box or VMware) on the 64-bit flavor of Windows 7 is quite easy to setup and use. For PDF reading and editing I use Foxit PhantomPDF. Unfortunately, none of the PDF reading software has great document searching capabilities. The IBM Library Reader and the Softcopy Reader both do a dramatically better job against the BookManager format files. To me it's sad that the BookManager format is essentially dead. We haven't produced BookManager format documentation for the program products I work on for quite a few years. I fear the PDFs are going to be gone in the not too distant future. Bob
