Re: BXLE usage assistance
Mark, There are several excellent examples in the z/Architecture Principles of Operation in Appendix A. Tom Harper Phoenix Software International Sent from my iPhone > On May 29, 2024, at 3:03 PM, Mark > <176dcd91c5b1-dmarc-requ...@listserv.uga.edu> wrote: > > Hello, > > I'm writing an exit where I have to scan through an array of variable length > entries in a table where the format is as below (all the entires are readable > characters) > > First 2 bytes = total length of array in hex > then > 2 bytes for length of first entry in hex > First Entry in table > 2 bytes for length of 2nd entry in hex > 2nd entry in table > 2 bytes for length of 3rd entry in hex > 3rd entry in table. > repeats until end of array. > > I'm thinking a BXLE will work, but getting stuck on exactly how to code it. > any help is greatly appriciated. > > Thanks, > Mark. > . 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 attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Complex immediate fields
Seymour, How about this: LLILH R15,X’4000’ Tom Harper Phoenix Software International Sent from my iPhone > On Mar 29, 2024, at 12:56 PM, Seymour J Metz wrote: > > Back in he Assembler XF era I would code something like > > LAR0,L'DEST > LAR1,DEST > XRR15,R15 > ICM R15,8,=C' ' > MVCL R0,R14 > > On current hardware there is an IILF (LFI) instruction, and I would like to > use it instead of the XR/ICM sequence. I consider > > LFI R15,X'4000' > > to be ugly, and would like to be able to either use an immediate field > combing CL1 and XL3 pieces or to refer to an EQU defining that combination. > Is there any way to do that in HLASM? > > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר 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 attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: RES: RES: Reseting RMODE
I think it does solve your problem. What doesn’t it solve? Sent from my iPhone > On Dec 4, 2023, at 10:01 AM, João Reginato wrote: > > Yes, I know that but it doesn't solve my problem > > -Mensagem original----- > De: Tom Harper > Enviada em: segunda-feira, 4 de dezembro de 2023 11:49 > Para: jb.regin...@gmail.com > Cc: ASSEMBLER-LIST@listserv.uga.edu > Assunto: Re: RES: Reseting RMODE > > João, > > What has been hinted at here is that all you need to do is to have two > CSECTs, one which is RMODE(ANY) and a second one which is RMODE(24). > > You can have as many CSECTs in a single assembly as you wish. > > Then, just call the RMODE(24) CSECT when you need it. > > Tom Harper > Phoenix Software International > > Sent from my iPhone > >> On Dec 4, 2023, at 9:29 AM, João Reginato wrote: >> >> As I've said before, I wasn't clear enough here. >> My intent is to change the RMODE during the compilation phase only. >> I have all CSECTS with RMODE ANY so, one of them, need to be RMODE 24, and I >> cannot change it because the HLASM doesn't allow that. despite it hasn't >> finished the compilation of all my csects, issuing the message reported >> before. >> >> João >> >> -Mensagem original- >> De: IBM Mainframe Assembler List Em nome >> de Peter Relson >> Enviada em: domingo, 3 de dezembro de 2023 14:39 >> Para: ASSEMBLER-LIST@LISTSERV.UGA.EDU >> Assunto: 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 > > > > 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 attachments or appended messages are believed to be > free of any virus or other defect that might affect any computer system into > which it is received and opened, it is the responsibility of the recipient > to ensure that it is virus free and no responsibility is accepted by the > sender for any loss or damage arising in any way from its opening or use. > 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
Re: RES: Reseting RMODE
João, What has been hinted at here is that all you need to do is to have two CSECTs, one which is RMODE(ANY) and a second one which is RMODE(24). You can have as many CSECTs in a single assembly as you wish. Then, just call the RMODE(24) CSECT when you need it. Tom Harper Phoenix Software International Sent from my iPhone > On Dec 4, 2023, at 9:29 AM, João Reginato wrote: > > As I've said before, I wasn't clear enough here. > My intent is to change the RMODE during the compilation phase only. > I have all CSECTS with RMODE ANY so, one of them, need to be RMODE 24, and I > cannot change it because the HLASM doesn't allow that. despite it hasn't > finished the compilation of all my csects, issuing the message reported > before. > > João > > -Mensagem original- > De: IBM Mainframe Assembler List Em nome > de Peter Relson > Enviada em: domingo, 3 de dezembro de 2023 14:39 > Para: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Assunto: 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 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 attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Variable-Length Parameter List Attributes
I’m betting you would not see any difference in performance. Modern z machines will likely execute most of those instructions in parallel since there are no dependencies after the first LA. However, if you’re still concerned, I would code it this way: > L R15,ARXEXCOM > CALL (15),(SHVPARM1,SHVPARM2,SHVPARM2,SHVBLOCK,SHVPARM5),X > MF=(E,SHVPARMB) > DS0H > LA1,SHVPARMB > LA0,SHVPARM1 > ST0,0(0,1) > LA0,SHVPARM2 > ST0,4(0,1) > LA0,SHVPARM2 > ST0,8(0,1) > LA0,SHVBLOCK > ST0,12(0,1) > LA0,SHVPARM5 > ST0,16(0,1) > OI16(1),X'80 > BALR 14,15 ORG-2 Back up over the BALR For building your CALL list, and then use > LAR1,SHVPARMB > L R15,ARXEXCOM > BALR R14,R15 For subsequent invocations. Tom Harper Phoenix Software International Sent from my iPhone > On Oct 18, 2023, at 12:48 PM, Dave Clark wrote: > > "IBM Mainframe Assembler List" wrote on > 10/18/2023 12:15:12 PM: >> Execute version of the CALL macro with MF=(E,parm_area_name) can fix > that. > > >Well, the other issue is performance. I potentially call this > program hundreds of times. So, I can build the parameter list just once > and call it as follows: > > LAR1,SHVPARMB > L R15,ARXEXCOM > BALR R14,R15 > >Or I can call it as follows -- much less desireable. Note that > the program address is not supplied by a V-con but by an external program > vector list from REXX. That is why I have to preload R15 rather than > puting it in the CALL statement. But, I still wouldn't want a V-con > inserted into the middle of my instructions by the CALL with a branch > around it. > > L R15,ARXEXCOM > CALL (15),(SHVPARM1,SHVPARM2,SHVPARM2,SHVBLOCK,SHVPARM5),X > MF=(E,SHVPARMB) > DS0H > LA1,SHVPARMB > LA0,SHVPARM1 > ST0,0(0,1) > LA0,SHVPARM2 > ST0,4(0,1) > LA0,SHVPARM2 > ST0,8(0,1) > LA0,SHVBLOCK > ST0,12(0,1) > LA0,SHVPARM5 > ST0,16(0,1) > OI16(1),X'80 > BALR 14,15 > > > Sincerely, > > Dave Clark > -- > int.ext: 91078 > direct: (937) 531-6378 > home: (937) 751-3300 > > Winsupply Group Services > 3110 Kettering Boulevard > Dayton, Ohio 45439 USA > (937) 294-5331 > > > > > > * > This email message and any attachments is for use only by the named > addressee(s) and may contain confidential, privileged and/or proprietary > information. If you have received this message in error, please > immediately notify the sender and delete and destroy the message and all > copies. All unauthorized direct or indirect use or disclosure of this > message is strictly prohibited. No right to confidentiality or privilege > is waived or lost by any error in transmission. > * 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 attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Variable-Length Parameter List Attributes
Dave, Why not use the CALL macro with the VL parameter to mark the end of the list? Sincerely, Tom Harper Phoenix Software International Sent from my iPhone > On Oct 18, 2023, at 11:53 AM, Dave Clark wrote: > > I have a definition such as the following. > > SHVPARMB DS5F > >However, the program I am calling will actually accept 4, 5, or 6 > parameters in this list. So, I believe that T' will return F and L' will > return 4, but is there any attribute that will return the 5 in the above > definition? I ask, because I would rather not hardcode the following to > set the end flag for the list. > > OISHVPARMB+(5*4-4),X'80' > > > Sincerely, > > Dave Clark > -- > int.ext: 91078 > direct: (937) 531-6378 > home: (937) 751-3300 > > Winsupply Group Services > 3110 Kettering Boulevard > Dayton, Ohio 45439 USA > (937) 294-5331 > > > > * > This email message and any attachments is for use only by the named > addressee(s) and may contain confidential, privileged and/or proprietary > information. If you have received this message in error, please > immediately notify the sender and delete and destroy the message and all > copies. All unauthorized direct or indirect use or disclosure of this > message is strictly prohibited. No right to confidentiality or privilege > is waived or lost by any error in transmission. > * 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 attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: [EXTERNAL] Re: Automatic Variable Insertion
Why not use ASASYMBF? https://www.ibm.com/docs/en/zos/2.2.0?topic=hsp-asasymbm-asasymbf-substitute-text-symbols Shared via the Google app Sent from my iPhone Sent from my iPhone > On Apr 18, 2023, at 4:02 PM, Swarbrick, Frank > <12f6dfd67d6a-dmarc-requ...@listserv.uga.edu> wrote: > > Here's a simple call to printf from LE-enabled assembler. > > ceedsa , > ceecaa , > prntit ceeentry main=YES > call PRINTF,(fmtstr,3) > ceeterm > ppa ceeppa , > fmtstr dcc'Test %d!',x'0' > end prntit > > Output is: > Test 3! > > -Original Message- > From: IBM Mainframe Assembler List On > Behalf Of Charles Mills > Sent: Tuesday, April 18, 2023 12:59 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: [EXTERNAL] Re: Automatic Variable Insertion > > I know I have seen an example somewhere of calling printf() from assembler. > Printf() does not really do a WTO, but the form of it named sprint() returns > a string that you could WTO. > > The printf() family is super powerful -- more than you could hope to achieve > in a reasonable amount of macro coding. > > Charles > > > -Original Message- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] > On Behalf Of Gary Weinhold > Sent: Tuesday, April 18, 2023 9:33 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Automatic Variable Insertion > > We resolved this by creating using the TEXT= option with a register which > allowed us to use a single WTO MF=L and a single WTO MF=E for all WTOs. The > messages themselves are generated by a macro which has a LITERAL type (to > generate the constants), a DSECT form (to name where the variables are), and > a SPACE type, to reserve space in working storage for reentrant programs. > We don't use a macro to fill in the variables though. > > It seems like what you want is similar to an assembler version of the C > language printf library function. > > The information contained in this electronic communication and any document > attached hereto or transmitted herewith is confidential and intended for the > exclusive use of the individual or entity named above. If the reader of this > message is not the intended recipient or the employee or agent responsible > for delivering it to the intended recipient, you are hereby notified that any > examination, use, dissemination, distribution or copying of this > communication or any part thereof is strictly prohibited. If you have > received this communication in error, please immediately notify the sender by > reply e-mail and destroy this communication. Thank you. 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 attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Next instruction needed
I think that is unnecessary because the proposal is only for one to 256 bytes so no need to make it interruptible. If you want to use for longer areas, use a move long. Many instructions have been added over the years for small items. This would find significant use as soon as the instruction would become available without dual pathing. The cost to implement should be minimal. Sent from my iPhone > On Apr 15, 2022, at 1:51 PM, Paul Gilmartin > <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > > On Apr 15, 2022, at 11:34:40, Tom Harper wrote: >> >> If it was interrupted, where would the hardware restart? The instruction >> itself cannot be changed. >> > Make it an RFE. Support it with a business case, that it would provide added > value to end users inducing them to spend more on IBM equipment than the > engineering cost of developing the new hardware. > > -- > gil 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 attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Next instruction needed
If it was interrupted, where would the hardware restart? The instruction itself cannot be changed. Sent from my iPhone > On Apr 15, 2022, at 1:19 PM, Dave Clark wrote: > > "IBM Mainframe Assembler List" wrote on > 04/15/2022 01:10:36 PM: >> For a fixed length move, none. For a variable length move, one. > > >Why not zero registers required for a variable length initialize? > For an extended displacement instruction such as what follows, the second > full-word parameter can be a 24-bit length where the high-order byte is > the fill character. But, this would be an uninterruptible instruction. > > > FILL BUFFER,FILLN > > > Sincerely, > > Dave Clark > -- > int.ext: 91078 > direct: (937) 531-6378 > home: (937) 751-3300 > > Winsupply Group Services > 3110 Kettering Boulevard > Dayton, Ohio 45439 USA > (937) 294-5331 > > > > > * > This email message and any attachments is for use only by the named > addressee(s) and may contain confidential, privileged and/or proprietary > information. If you have received this message in error, please > immediately notify the sender and delete and destroy the message and all > copies. All unauthorized direct or indirect use or disclosure of this > message is strictly prohibited. No right to confidentiality or privilege > is waived or lost by any error in transmission. > * 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 attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Next instruction needed
For a fixed length move, none. For a variable length move, one. Sent from my iPhone > On Apr 15, 2022, at 12:27 PM, Robin Vowels wrote: > > On 2022-04-16 02:23, Tom Harper wrote: >>>> On Apr 15, 2022, at 12:20 PM, Robin Vowels wrote: >>> On 2022-04-16 00:25, Tom Harper wrote: >>>> Well known. But the instruction I’m proposing has no registers >>>> involved >>> Oh? How do you propose that such an instruction move >>> N bytes (where N is variable) without the value of N >>> being in a register? >> As mentioned, R0. > > Make up your mind! You just said that no registers were involved. > >>>> (other than base displacement) and thus there is no way to >>>> restart the instruction to complete the process. >>>> So to avoid that, limiting it to 256 bytes removed that as an issue. >>>>>> On Apr 15, 2022, at 9:45 AM, Seymour J Metz wrote: >>>>> You can have interruptability without an arbitrary length restriction; >>>>> CLCL and MVCL work just fine. All that you need is that the instruction >>>>> be resumeable and for the hardware/microcode/millicode to periodically >>>>> check for pending interrupts and update the registers as needed 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 attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Next instruction needed
Sent from my iPhone > On Apr 15, 2022, at 12:20 PM, Robin Vowels wrote: > > On 2022-04-16 00:25, Tom Harper wrote: >> Well known. But the instruction I’m proposing has no registers >> involved > > Oh? How do you propose that such an instruction move > N bytes (where N is variable) without the value of N > being in a register? As mentioned, R0. > >> (other than base displacement) and thus there is no way to >> restart the instruction to complete the process. >> So to avoid that, limiting it to 256 bytes removed that as an issue. >>>> On Apr 15, 2022, at 9:45 AM, Seymour J Metz wrote: >>> You can have interruptability without an arbitrary length restriction; >>> CLCL and MVCL work just fine. All that you need is that the instruction be >>> resumeable and for the hardware/microcode/millicode to periodically check >>> for pending interrupts and update the registers as needed > >>> >>> From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on >>> behalf of Robin Vowels [robi...@dodo.com.au] >>> Sent: Friday, April 15, 2022 5:08 AM >>> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU >>> Subject: Re: Next instruction needed >>> - Original Message - >>> From: "Tom Harper" >>> To: >>> Sent: Friday, April 15, 2022 3:06 AM >>>> IMHO, the next instruction to add to z/Architecture would be an >>>> instruction to clear storage to >>>> zeros. >>>> Right now a number of methods are in widespread use, none of which are >>>> clean and simple. I mean, >>>> it’s been almost sixty years. >>>> MVCL takes three registers to set up beforehand; >>> So? Write yourself a macro. >>>> XC sets the condition code and is not variable length, and the overlapping >>>> MVC is a kluge >>> But it does the job well. >>>> and not variable length either. >>> Use Ex. >>>> An EX instruction is also a kluge. >>>> All you need is the address and length to accomplish this, preferably in >>>> two versions, >>>> one with an immediate operand for the length >>> Really?! A few lines ago, you were decrying XC and MVC because they have a >>> "fixed length". >>>> and another which uses, for example, a register, perhaps register zero. A >>>> long displacement would >>>> be a plus. >>> To avoid issues with interruptibility, the length would need to be limited >>> to 256 bytes. >>> What? Back to a limit of 256? what's the point of that? >>> MVCL will do as long as you want. >>>> I don’t think the length restriction would be an issue in most cases. >>> There's no point in having an instruction with a length restrictionof 256. >>>> Such an instruction might look like this: >>>> CLEAR FieldA >>>> Or >>>> LLGF R0,Varlen >>>> CLEARR >>> A macro reference would require one line. >>>> Similar instructions for compare logical and move would be nice as well. 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 attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Next instruction needed
Robin, See embedded remarks. Tom Sent from my iPhone > On Apr 15, 2022, at 5:08 AM, Robin Vowels wrote: > > - Original Message - From: "Tom Harper" > > To: > Sent: Friday, April 15, 2022 3:06 AM > > >> IMHO, the next instruction to add to z/Architecture would be an instruction >> to clear storage to zeros. > >> Right now a number of methods are in widespread use, none of which are clean >> and simple. I mean, it’s been almost sixty years. > >> MVCL takes three registers to set up beforehand; > > So? Write yourself a macro. Of course a macro can be written. But that’s not the point. Three registers will have to be loaded and that takes time and the registers are not always easily available. > >> XC sets the condition code and is not variable length, and the overlapping >> MVC is a kluge > > But it does the job well. Except that it can only handle fixed length without an execute instruction which is a poor performer. Also needlessly sets the condition code which slows down the processor. > >> and not variable length either. > > Use Ex. A poor performer. > >> An EX instruction is also a kluge. > >> All you need is the address and length to accomplish this, preferably in two >> versions, >> one with an immediate operand for the length > > Really?! A few lines ago, you were decrying XC and MVC because they have a > "fixed length". They are fixed length unless you use an execute instruction. > >> and another which uses, for example, a register, perhaps register zero. A >> long displacement would be a plus. > > To avoid issues with interruptibility, the length would need to be limited to > 256 bytes. > > What? Back to a limit of 256? what's the point of that? > MVCL will do as long as you want. Yes it will. But a common need is for shorter lengths. > >> I don’t think the length restriction would be an issue in most cases. > > There's no point in having an instruction with a length restrictionof 256. I’ve been doing this for a very long time and I will respectfully disagree with you. There are frequent cases to clear fields of 256 bytes or less. > >> Such an instruction might look like this: > >> CLEAR FieldA > >> Or > >> LLGF R0,Varlen >> CLEARR > > A macro reference would require one require one line. True, but not relevant. The purpose of this instruction is to have a simple instruction that performs a frequently used function that the processor can execute quickly. > >> Similar instructions for compare logical and move would be nice as well. > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus 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 attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Next instruction needed
Well known. But the instruction I’m proposing has no registers involved (other than base displacement) and thus there is no way to restart the instruction to complete the process. So to avoid that, limiting it to 256 bytes removed that as an issue. Sent from my iPhone > On Apr 15, 2022, at 9:45 AM, Seymour J Metz wrote: > > You can have interruptability without an arbitrary length restriction; CLCL > and MVCL work just fine. All that you need is that the instruction be > resumeable and for the hardware/microcode/millicode to periodically check for > pending interrupts and update the registers as needed > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on > behalf of Robin Vowels [robi...@dodo.com.au] > Sent: Friday, April 15, 2022 5:08 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Next instruction needed > > - Original Message - > From: "Tom Harper" > To: > Sent: Friday, April 15, 2022 3:06 AM > > >> IMHO, the next instruction to add to z/Architecture would be an instruction >> to clear storage to >> zeros. > >> Right now a number of methods are in widespread use, none of which are clean >> and simple. I mean, >> it’s been almost sixty years. > >> MVCL takes three registers to set up beforehand; > > So? Write yourself a macro. > >> XC sets the condition code and is not variable length, and the overlapping >> MVC is a kluge > > But it does the job well. > >> and not variable length either. > > Use Ex. > >> An EX instruction is also a kluge. > >> All you need is the address and length to accomplish this, preferably in two >> versions, >> one with an immediate operand for the length > > Really?! A few lines ago, you were decrying XC and MVC because they have a > "fixed length". > >> and another which uses, for example, a register, perhaps register zero. A >> long displacement would >> be a plus. > > To avoid issues with interruptibility, the length would need to be limited to > 256 bytes. > > What? Back to a limit of 256? what's the point of that? > MVCL will do as long as you want. > >> I don’t think the length restriction would be an issue in most cases. > > There's no point in having an instruction with a length restrictionof 256. > >> Such an instruction might look like this: > >> CLEAR FieldA > >> Or > >> LLGF R0,Varlen >> CLEARR > > A macro reference would require one line. > >> Similar instructions for compare logical and move would be nice as well. > > > --- > This email has been checked for viruses by Avast antivirus software. > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.avast.com%2Fantivirus&data=05%7C01%7Csmetz3%40gmu.edu%7C321a88f8873f489ae2aa08da1ebf8695%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637856105217726958%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1YlHbddJyGWkzKpajlykSLpgYc4F%2B%2BF26AYQ%2FgecQ78%3D&reserved=0 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 attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Next instruction needed
I did not propose any such instruction. Sent from my iPhone > On Apr 14, 2022, at 4:42 PM, Seymour J Metz wrote: > > You asked for an instruction to clear a page to zeros. I proposed an > instruction to clear a page to zeros without causing an extraneous page-in if > the page was previously paged out and without causing an unnecessary page out > if the page was stolen after being cleared but before you wrote something new > into it. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on > behalf of Tom Harper [tomhar...@phoenixsoftware.com] > Sent: Thursday, April 14, 2022 3:46 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Next instruction needed > > I don’t see what this has to do with what I’m proposing. > > Sent from my iPhone > >> On Apr 14, 2022, at 3:39 PM, Seymour J Metz wrote: >> >> Not directly, but it also wouldn't prevent unnecessary page outs after page >> steals. A better new instruction would be an unpriviled instruction similar >> to IPTE; mark the page as invalid only if write is permitted, otherwise >> protection exception. Maybe even a version that also clears the page and >> sets a PTE that cause the next write to set it back to valid. The intent is >> to cause the OS to treat the page as valid but unmodified since allocation, >> and to avoid extraneous interrupts. >> >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> >> >> From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on >> behalf of Paul Gilmartin [0014e0e4a59b-dmarc-requ...@listserv.uga.edu] >> Sent: Thursday, April 14, 2022 1:26 PM >> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU >> Subject: Re: Next instruction needed >> >>>> On Apr 14, 2022, at 11:06:09, Tom Harper wrote: >>> >>> IMHO, the next instruction to add to z/Architecture would be an instruction >>> to clear storage to zeros. >>> >> Would that cause a Lot of paging I/O? Would it be better to mark all pages >> as >> invalid, to be cleared automatically when referenced, if ever? >> >> That would be an O/S function, not hardware. >> >> -- >> gil > > > > 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 attachments or appended messages are believed to be > free of any virus or other defect that might affect any computer system into > which it is received and opened, it is the responsibility of the recipient > to ensure that it is virus free and no responsibility is accepted by the > sender for any loss or damage arising in any way from its opening or use. 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 attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Next instruction needed
I like that: A significant improvement. Sent from my iPhone > On Apr 14, 2022, at 3:59 PM, Schmitt, Michael wrote: > > Fill Immediate: > > FILLI field,x'FF' set field to high-values > > Where machine sets field to the immediate value: space, zeros, whatever > > > -Original Message- > From: IBM Mainframe Assembler List On > Behalf Of Tom Harper > Sent: Thursday, April 14, 2022 12:06 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Next instruction needed > > IMHO, the next instruction to add to z/Architecture would be an instruction > to clear storage to zeros. > > Right now a number of methods are in widespread use, none of which are clean > and simple. I mean, it’s been almost sixty years. > > MVCL takes three registers to set up beforehand; XC sets the condition code > and is not variable length, and the overlapping MVC is a kluge and not > variable length either. An EX instruction is also a kluge. > > All you need is the address and length to accomplish this, preferably in two > versions, one with an immediate operand for the length and another which > uses, for example, a register, perhaps register zero. A long displacement > would be a plus. > > To avoid issues with interruptibility, the length would need to be limited to > 256 bytes. I don’t think the length restriction would be an issue in most > cases. > > Such an instruction might look like this: > >CLEAR FieldA > > Or > >LLGF R0,Varlen >CLEARR > > Similar instructions for compare logical and move would be nice as well. > > Tom Harper > Phoenix Software International > > Sent from my iPhone > > > 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 attachments or appended messa 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 attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Next instruction needed
I don’t see what this has to do with what I’m proposing. Sent from my iPhone > On Apr 14, 2022, at 3:39 PM, Seymour J Metz wrote: > > Not directly, but it also wouldn't prevent unnecessary page outs after page > steals. A better new instruction would be an unpriviled instruction similar > to IPTE; mark the page as invalid only if write is permitted, otherwise > protection exception. Maybe even a version that also clears the page and sets > a PTE that cause the next write to set it back to valid. The intent is to > cause the OS to treat the page as valid but unmodified since allocation, and > to avoid extraneous interrupts. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on > behalf of Paul Gilmartin [0014e0e4a59b-dmarc-requ...@listserv.uga.edu] > Sent: Thursday, April 14, 2022 1:26 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Next instruction needed > >> On Apr 14, 2022, at 11:06:09, Tom Harper wrote: >> >> IMHO, the next instruction to add to z/Architecture would be an instruction >> to clear storage to zeros. >> > Would that cause a Lot of paging I/O? Would it be better to mark all pages as > invalid, to be cleared automatically when referenced, if ever? > > That would be an O/S function, not hardware. > > -- > gil 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 attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Next instruction needed
I don’t believe the paging implications would be any different from an XC. Sent from my iPhone > On Apr 14, 2022, at 1:26 PM, Paul Gilmartin > <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > > On Apr 14, 2022, at 11:06:09, Tom Harper wrote: >> >> IMHO, the next instruction to add to z/Architecture would be an instruction >> to clear storage to zeros. >> > Would that cause a Lot of paging I/O? Would it be better to mark all pages as > invalid, to be cleared automatically when referenced, if ever? > > That would be an O/S function, not hardware. > > -- > gil 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 attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Next instruction needed
IMHO, the next instruction to add to z/Architecture would be an instruction to clear storage to zeros. Right now a number of methods are in widespread use, none of which are clean and simple. I mean, it’s been almost sixty years. MVCL takes three registers to set up beforehand; XC sets the condition code and is not variable length, and the overlapping MVC is a kluge and not variable length either. An EX instruction is also a kluge. All you need is the address and length to accomplish this, preferably in two versions, one with an immediate operand for the length and another which uses, for example, a register, perhaps register zero. A long displacement would be a plus. To avoid issues with interruptibility, the length would need to be limited to 256 bytes. I don’t think the length restriction would be an issue in most cases. Such an instruction might look like this: CLEAR FieldA Or LLGF R0,Varlen CLEARR Similar instructions for compare logical and move would be nice as well. Tom Harper Phoenix Software International Sent from my iPhone 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 attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Modifying the VSAM Request Parameter List (RPL)
It helps to look at this from a historical perspective. When VSAM was introduced in the early 1970s, the DCB equivalents to the ACB and RPL we’re hopelessly convoluted, and the theory was to provide an API to mask the complexity. As it turns out, the cure of MODCB and SHOWCB was worse than the problem, as the ACB and RPL (and EXLST) were just not that complicated. The IBM code I saw for VTAM never used MODCB either. And these control blocks have been static for decades with a few minor extensions. Happy coding! Tom Harper Phoenix Software International Sent from my iPhone > On Feb 24, 2022, at 12:49 PM, Dave Clark wrote: > > "IBM Mainframe Assembler List" wrote on > 02/24/2022 12:35:27 PM: >> You may use whichever DSECT you want. I just use IFGRPL but that’s >> just my preference. > > >Thanks. I have confirmed that both of the following generate the > same mapping for a VSAM RPL. The second one just also overlays the > mapping for a VTAM RPL. > > > IKQRPL DSECT=YES > > IFGRPL DSECT=YES,AM=VSAM > > > Sincerely, > > Dave Clark > -- > int.ext: 91078 > direct: (937) 531-6378 > home: (937) 751-3300 > > Winsupply Group Services > 3110 Kettering Boulevard > Dayton, Ohio 45439 USA > (937) 294-5331 > > > > > * > This email message and any attachments is for use only by the named > addressee(s) and may contain confidential, privileged and/or proprietary > information. If you have received this message in error, please > immediately notify the sender and delete and destroy the message and all > copies. All unauthorized direct or indirect use or disclosure of this > message is strictly prohibited. No right to confidentiality or privilege > is waived or lost by any error in transmission. > * 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 attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Modifying the VSAM Request Parameter List (RPL)
You may use whichever DSECT you want. I just use IFGRPL but that’s just my preference. Sent from my iPhone > On Feb 24, 2022, at 12:16 PM, Dave Clark wrote: > > "IBM Mainframe Assembler List" wrote on > 02/24/2022 11:49:34 AM: >> Why not dispense with MODCB and just modify the RPL yourself using >> IFGRPL DSECT? > > >And let me ask the question this way... I already have the IKQRPL > DSECT in my program. Are you saying that if I want to directly modify the > VSAM RPL that I should NOT do it through the IKQRPL DSECT only but should > use the IFGRPL DSECT, instead? I did look at the IFGRPL macro (which > looks like VTAM, not VSAM) and it invokes the ISTRPL macro (definitely > VTAM) under the covers. So, then I looked at the ISTRPL macro and I see > that among other things it also invokes the IKQRPL macro under the covers. > That is what prompted me to ask this question. > > > Sincerely, > > Dave Clark > -- > int.ext: 91078 > direct: (937) 531-6378 > home: (937) 751-3300 > > Winsupply Group Services > 3110 Kettering Boulevard > Dayton, Ohio 45439 USA > (937) 294-5331 > > > > > * > This email message and any attachments is for use only by the named > addressee(s) and may contain confidential, privileged and/or proprietary > information. If you have received this message in error, please > immediately notify the sender and delete and destroy the message and all > copies. All unauthorized direct or indirect use or disclosure of this > message is strictly prohibited. No right to confidentiality or privilege > is waived or lost by any error in transmission. > * 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 attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Modifying the VSAM Request Parameter List (RPL)
The result is the same. Sent from my iPhone > On Feb 24, 2022, at 11:55 AM, Dave Clark wrote: > > "IBM Mainframe Assembler List" wrote on > 02/24/2022 11:49:34 AM: >> Why not dispense with MODCB and just modify the RPL yourself using >> IFGRPL DSECT? > > >That sounds like an intriguing idea. What are the negative > ramifications of doing it that way? ...and is there anything "special" > that has to be done after making such direct modifications? > > > Sincerely, > > Dave Clark > -- > int.ext: 91078 > direct: (937) 531-6378 > home: (937) 751-3300 > > Winsupply Group Services > 3110 Kettering Boulevard > Dayton, Ohio 45439 USA > (937) 294-5331 > > > > > * > This email message and any attachments is for use only by the named > addressee(s) and may contain confidential, privileged and/or proprietary > information. If you have received this message in error, please > immediately notify the sender and delete and destroy the message and all > copies. All unauthorized direct or indirect use or disclosure of this > message is strictly prohibited. No right to confidentiality or privilege > is waived or lost by any error in transmission. > * 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 attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Modifying the VSAM Request Parameter List (RPL)
Dave, Why not dispense with MODCB and just modify the RPL yourself using IFGRPL DSECT? Tom Harper Phoenix Software International Sent from my iPhone > On Feb 24, 2022, at 11:33 AM, Dave Clark wrote: > >This isn't strictly an Assembler question -- more of a "How to > Modify a VSAM RPL Efficiently in Assembler" type of question. But... > >The reason I say "efficiently" is because of the dynamic nature of > this external assembler REXX function I am working on. Unlike a high-level > compiler that knows what is needed before a particular READ request and > can create a single MODCB RPL request at that point, I have a nested IF > situation before my GET request that is a bit of a nightmare to say the > least and is a program size hog to say the most. > >In particular, I have 18 MODCB RPL requests just before my GET > request. This is because the caller may have requested an OPEN and then a > READ request that has the following different option combinations. > > Call RXVSAMIO ddname, 'OPEN' > <, 'INPUT'|'UPDATE'|'OUTPUT'|'APPEND'|'RESET' > <, 'SEQUENCE'|'RANDOM'|'DYNAMIC' > >; > > Call RXVSAMIO ddname, 'READ' > <, 'NEXT'|'PREV' >|'RBA'|'KEY' <, 'EQUAL'|'GTEQ' > >; > >I asked this question on the VSE listserve and got the hint to use > the MF=(L,...) and MF=(E,...) macro parameters to separate configuration > of the parameter list from the execution of that parameter list. That > helped a bit to reduce the program size. However, each MODCB MF=(L,...) > request still generates its own in-line parameter list template (ACES) > that "wastes" 20 to 22 bytes before using another 10 bytes to copy the > 16-byte ACES to the dynamic storage parameter list area I have provided. > And that's just the 18 combinations that I have before the GET request -- > not to mention a similar (though smaller) nested IF before the POINT > request. > >So, finally, here is the question... Is there some assembler > technique to further reduce the storage requirements of the following > sequence of instructions? For example... Is there some way to build the > OPTCD value in a separate string and then pass it to a single iteration of > the MODCB MF=(L,...) invocation? > > IF RQARG2,EQ,C'N' GET NEXT > IF FILEOPT,(ON,TM),FILEUPDT IF OPENED FOR UPDATE > MODCB MF=(L,PARMLIST),RPL=(*,FILERPL),OPTCD=(SEQ,FWD,UPD) > ELSE > IF FILEOPT,(ON,TM),FILESEQU IF ACCESS IS SEQUENTIAL > MODCB MF=(L,PARMLIST),RPL=(*,FILERPL),OPTCD=(SEQ,FWD,NUP) > ELSE ACCESS IS DIRECT > MODCB MF=(L,PARMLIST),RPL=(*,FILERPL),OPTCD=(SEQ,FWD,NSP) > ENDIF > ENDIF > ELSE > IF RQARG2,EQ,C'K' GET BY KEY > IF RQARG3,EQ,C'G'GTEQ > IF FILEOPT,(ON,TM),FILESEQU IF ACCESS IS SEQUENTIAL >IF FILEOPT,(ON,TM),FILEUPDT IF OPENED FOR UPDATE > MODCB MF=(L,PARMLIST),RPL=(*,FILERPL), > OPTCD=(KEY,KGE,SEQ,FWD,UPD) >ELSE > MODCB MF=(L,PARMLIST),RPL=(*,FILERPL), > OPTCD=(KEY,KGE,SEQ,FWD,NUP) >ENDIF > ELSE ACCESS IS DIRECT >IF FILEOPT,(ON,TM),FILEUPDT IF OPENED FOR UPDATE > MODCB MF=(L,PARMLIST),RPL=(*,FILERPL), > OPTCD=(KEY,KGE,DIR,FWD,UPD) >ELSE > MODCB MF=(L,PARMLIST),RPL=(*,FILERPL), > OPTCD=(KEY,KGE,DIR,FWD,NSP) >ENDIF > ENDIF > ELSE EQUAL > IF FILEOPT,(ON,TM),FILESEQU IF ACCESS IS SEQUENTIAL >IF FILEOPT,(ON,TM),FILEUPDT IF OPENED FOR UPDATE > MODCB MF=(L,PARMLIST),RPL=(*,FILERPL), > OPTCD=(KEY,KEQ,SEQ,FWD,UPD) >ELSE > MODCB MF=(L,PARMLIST),RPL=(*,FILERPL), > OPTCD=(KEY,KEQ,SEQ,FWD,NUP) >ENDIF > ELSE ACCESS IS DIRECT >IF FILEOPT,(ON,TM),FILEUPDT IF OPENED FOR UPDATE > MODCB MF=(L,PARMLIST),RPL=(*,FILERPL), > OPTCD=(KEY,KEQ,DIR,FWD,UPD) >ELSE > MODCB MF=(L,PARMLIST),RPL=(*,FILERPL), > OPTCD=(KEY,KEQ,DIR,FWD,NSP) >ENDIF > ENDIF > ENDIF > ELSE > IF RQARG2,EQ,C'P' GET PREV > IF FILEOPT,(ON,TM),FILEUPDT IF OPENED FOR UPDATE >MODCB MF=(L,PARMLIST),RPL=(*,FILERPL),OPTCD=(SEQ,BWD,UPD) > ELSE >IF FILEOPT,(ON,TM),FILESEQU IF ACCESS IS SEQUENTIAL >MODCB MF=(L,PARMLIST),RPL=(*,FILERPL),OPTCD=(SEQ,BWD,NUP) >ELSE A
Re: SRST vs. SRSTU
Gil, Apologies as I missed the point of your question. Any prime will generally give a good distribution. But a Mersenne Prime allows you to avoid a divide. Tom Sent from my iPhone > On Feb 23, 2022, at 4:37 PM, Paul Gilmartin > <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > >> On Feb 23, 2022, at 14:00:21, Tom Harper wrote: >> >> Your best bet is a dynamic hash table of size of an appropriate Mersenne >> Prime. The fastest effective way to hash your key is using the CKSM >> instruction. Although fast, it does produce more synonyms than other hash >> techniques. >> > Why a Mersenne Prime? The first thing I find is: > <https://www.quora.com/How-are-Mersenne-primes-used> >The key is that you can compute x mod p really fast if p is a Mersenne > prime. > > Is this a significant advantage on z hardware? > > Are name/token services, IEANTCR/IEANTRT useful here? > > -- > gil 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 attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: SRST vs. SRSTU
Gil, it has nothing to do with hardware speed it just gives a better distribution of hash values. Sent from my iPhone > On Feb 23, 2022, at 4:37 PM, Paul Gilmartin > <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > >> On Feb 23, 2022, at 14:00:21, Tom Harper wrote: >> >> Your best bet is a dynamic hash table of size of an appropriate Mersenne >> Prime. The fastest effective way to hash your key is using the CKSM >> instruction. Although fast, it does produce more synonyms than other hash >> techniques. >> > Why a Mersenne Prime? The first thing I find is: > <https://www.quora.com/How-are-Mersenne-primes-used> >The key is that you can compute x mod p really fast if p is a Mersenne > prime. > > Is this a significant advantage on z hardware? > > Are name/token services, IEANTCR/IEANTRT useful here? > > -- > gil 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 attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: SRST vs. SRSTU
Gary, Now that we know that you are implementing a key/data structure, we can provide more help. Vector instructions are impressive for searching for strings but that’s not really what you’re doing here. B-trees can be used, but are non-trivial to implement. Your best bet is a dynamic hash table of size of an appropriate Mersenne Prime. The fastest effective way to hash your key is using the CKSM instruction. Although fast, it does produce more synonyms than other hash techniques. If the size of your structures are unknown ahead of time, you might consider starting out with a small hash table and then if the ratio of keys to entries exceeds a threshold, rehash entries to the next higher Mersenne Prime. If you know you will never have more than a certain number of entries, you can just make a structure that size and skip the dynamic option. In any case, if you are multi-threading, you will need to serialize. Inserting and deleting keys is not difficult and neither is the basic lookup. If you have the option of writing in C, GLib already has this function implemented. Either way, it can be a fun exercise. Tom Harper Phoenix Software International Sent from my iPhone > On Feb 22, 2022, at 7:24 PM, Gary Weinhold wrote: > > Thanks to all. From the responses so far and my experience I'm inclined to > believe SRST is hardware and probably SRSTU is millicode (perhaps based on > SRST for the first byte) and we must look for another technique. > > My original thought was that we would use a serial search until the number of > keys exceeded some threshold and then build and maintain the 2-byte hash > table and switch to SRSTU, based on naively expecting its performance to be > comparable to SRST up to some number of keys and significantly better than > SRST when the number of entries exceeded some multiple of 256. > > We are experimenting with other techniques, but we can't change that the keys > are added and deleted dynamically, are continually accessed, and the total > number of entries varies significantly in different applications. I guess > it's time to look at vector instructions and possibly B-trees. > > Gary > > Gary Weinhold > Senior Application Architect > DATAKINETICS | Data Performance & Optimization > Phone:+1.613.523.5500 x216 > Email: weinh...@dkl.com > Visit us online at www.DKL.com > E-mail Notification: The information contained in this email and any > attachments is confidential and may be subject to copyright or other > intellectual property protection. If you are not the intended recipient, you > are not authorized to use or disclose this information, and we request that > you notify us by reply mail or telephone and delete the original message from > your mail system. 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 attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: SRST vs. SRSTU
Gary, The first thought that comes to mind is why not sort the table and use a binary search? If in fact the table is being updated and that is not practical, then your options are a serial search (which you have ruled out) or a hash. As you may have guessed, SRST and SRSTU are almost certainly milli-coded instructions and probably not very fast. Secondly, hash performance is highly dependent on the number of synonyms you have. Considering how many entries in your table, this is a distinct possibility. A full word makes for a large number of entries. The best hash tables are of a size of a Mersenne Prime. Right now you are not using one. Lastly, obtain storage for your table in a one Mb page frame to minimize TLB misses. Summary: 1 - If table is static, sort and use a binary search. 2 - Otherwise, create a hash table of a Mersenne Prime of size large enough to avoid most synonyms. Tom Harper Phoenix Software International Sent from my iPhone > On Feb 22, 2022, at 5:09 PM, Gary Weinhold wrote: > > We are trying to optimize a search routine for keys in fixed length rows in > an unordered array. As the number of rows in the array grows, a serial > search becomes relatively inefficient, so we looked for another technique. > We tried a SEARCH STRING (SRST) against a one byte hash of the key to see if > it could give us better performance. The relative positive of the matching > byte in the SRST array was used to determine the location of the key in the > original array; if the keys match, the row is found; if they don't match, we > redrive the SRST. At about 50 rows, SRST is more efficient than a serial > search so it justifies maintaining the hash array. > On the average, we assume the SRST would have to be redriven about (n/256)/2 > times, where n is the number of rows in the array. This would not be a big > factor for several thousand rows, but as the number of rows went into the > tens of thousands, we tried Search String Unicode (SRSTU). It appears to be > identical to SRST, except it compares 2-byte values (at 2-byte boundaries). > So we created a 2-byte hash and, using the same technique based on relative > position, tested for performance improvements compared to SRST when the > number of rows exceeded 1. We thought that the reduction in the number > of redrives due to non-matching keys (on average, (n/65536)/2) would more > than offset the hash array doubling in size. > > Our preliminary results show SRSTU about taking about 50-60% more time for > 15000 and 25000 rows. That came as a surprise to us. We will do more > testing. > > Is there a possibility we are encountering a hardware vs. microcode > implementation of the instuctions? Has anyone else tested the performance of > these instructions? > > Regards, Gary > > Gary Weinhold > Senior Application Architect > We are trying to optimize a search routine for keys in fixed length rows in > an unordered array. As the number of rows in the array grows, a serial > search becomes relatively inefficient, so we looked for another technique. > We tried a SEARCH STRING (SRST) against a one byte hash of the key to see if > it could give us better performance. The relative positive of the matching > byte in the SRST array was used to determine the location of the key in the > original array; if the keys match, the row is found; if they don't match, we > redrive the SRST. At about 50 rows, SRST is more efficient than a serial > search so it justifies maintaining the hash array. > On the average, we assume the SRST would have to be redriven about (n/256)/2 > times, where n is the number of rows in the array. This would not be a big > factor for several thousand rows, but as the number of rows went into the > tens of thousands, we tried Search String Unicode (SRSTU). It appears to be > identical to SRST, except it compares 2-byte values (at 2-byte boundaries). > So we created a 2-byte hash and, using the same technique based on relative > position, tested for performance improvements compared to SRST when the > number of rows exceeded 1. We thought that the reduction in the number > of redrives due to non-matching keys (on average, (n/65536)/2) would more > than offset the hash array doubling in size. > > Our preliminary results show SRSTU about taking about 50-60% more time for > 15000 and 25000 rows. That came as a surprise to us. We will do more > testing. > > Is there a possibility we are encountering a hardware vs. microcode > implementation of the instuctions? Has anyone else tested the performance of > these instructions? > > Regards, Gary > > Gary Weinhold > Senior Application Architect > DATAKINETICS | Data Performance & Optimizat
Re: Is it possible to update CSA from an unauthorized user-key program?
Not sure what you’re trying to accomplish but would EXEC CICS named counter help you? Tom Harper Phoenix Software International Sent from my iPhone > On Dec 6, 2021, at 7:13 PM, Wendell Lovewell > <09624390d784-dmarc-requ...@listserv.uga.edu> wrote: > > Hello Listers, > > I'd like to be able to update a common storage area across all CICS and batch > regions. I've looked at IARV64 REQUEST=GETCOMMON, but it seems that it > requires supervisor state and/or key 0-7. > > It seems that something like issuing a STORAGE macro similar to: > > STORAGE OBTAIN LENGTH=32768,SP=241,KEY=x,LOC=31,OWNER=SYSTEM > > ...from an authorized program would allocate the storage needed. But I > don't know the rules for accessing it from "user-mode" (unauthorized, key 8) > programs like a CICS application. > > a) Given the address of the storage obtained like that, can any user-mode > program read that storage? > b) Could a user-mode program update that storage? > c) Should the KEY parameter be specified, and if so, what value should I use. > Afaik it has to be 0-7 since User-key CSA was outlawed. > d) Am I correct that there isn't an IRAV64 option that will allow a user-mode > program to update the storage? > > Thanks for your help! > > Wendell > > (Cross-posted to the CICS list.) 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 attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: extracting value of an esoteric
I believe EDTINFO with RTNDEVN will return what you need. Sent from my iPhone > On Sep 6, 2021, at 10:12 AM, Tony Thigpen wrote: > > I want to programmatically determine what tape drives are assigned to a > specific esoteric, in this case 'VTL3590'. Can someone point me to the > relevant macro or documentation that can get me started? > > > Tony Thigpen 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 attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Ensuring LRL 2nd operand alignment
Here is how I code a similar instruction: CNOP 2,4 LLILF R14,0 ORG *-4 DC A(symbol+X’8000’) BASSM R14,R15 So that the second operand can be an ADCON or VCON. You could do the same with LRL. Sent from my iPhone > On May 4, 2021, at 9:18 AM, Peter Relson wrote: > > 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 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 attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: security with storage allocation under z.OS
And curiously the facility is present for STORAGE OBTAIN and ISRV64 but not for IARCP64. Sent from my iPhone > On Nov 16, 2020, at 12:39 PM, Steve Smith wrote: > > There is a new operand on STORAGE, EXECUTABLE=YES|NO. The default is YES, > and for earlier releases there was no execute-prevention capability afaik. > > I don't know what to tell you about the "security model". It's a big > subject. > > sas > > On Mon, Nov 16, 2020 at 12:24 PM Ze'ev Atlas < > 01774d97d104-dmarc-requ...@listserv.uga.edu> wrote: > >> Hi allIn the 1970's I probably could have done some getmain, write some >> code into that obtained memory and jump to that code. I assume that >> nowadays, this would be impossible and there is some security model to >> prevent such a security breach.Do you know where can I find information on >> the mainframe security model under z/OS. >> Ze'ev Atlas >> 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 attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: security with storage allocation under z.OS
That is not impossible and used in many products for performance reasons, such as sorting. Sent from my iPhone > On Nov 16, 2020, at 12:24 PM, Ze'ev Atlas > <01774d97d104-dmarc-requ...@listserv.uga.edu> wrote: > > Hi allIn the 1970's I probably could have done some getmain, write some code > into that obtained memory and jump to that code. I assume that nowadays, > this would be impossible and there is some security model to prevent such a > security breach.Do you know where can I find information on the mainframe > security model under z/OS. > Ze'ev Atlas 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 attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: SDUMPs
Dump Analysis and Elimination, a z/OS facility to aid in eliminating duplicate dumps. Sent from my iPhone > On Oct 30, 2020, at 8:53 AM, Tony Thigpen wrote: > > I am using: > //SYSMDUMP DD SYSOUT=* > > What is "DAE"? > > FYI, this is assembler code that I am porting from z/VSE. Adding a DC x'' > to force a SOC1 is not a problem. > > Tony Thigpen > > Seymour J Metz wrote on 10/30/20 4:54 AM: >> Did you have a SYSMDUMP DD? What's in DAE? >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> >> From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on >> behalf of Tony Thigpen [t...@vse2pdf.com] >> Sent: Thursday, October 29, 2020 9:47 PM >> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU >> Subject: Re: SDUMPs >> When I add a DC X'' and I force a SOC1, I don't see any dump added >> to IPCS. >> The guy that set up this system is gone. I don't know if he did >> 'something' to prevent dumps. >> Tony Thigpen >> Gary Weinhold wrote on 10/29/20 9:10 PM: >>> What I normally due in this type of situation is add a SYSUDUMP DD and >>> zap the instruction location where I want the dump to X'00' to force an >>> abend. If you are running in LE (COBOL or some other HLL is in the >>> environment), add a CEEOPTS DD* with TRAP(OFF) to prevent LE from >>> reimaging the abend. On 2020-10-29 7:56 p.m., Tony Thigpen wrote: Once I added SYSMDUMP DD SYSOUT=*, I now see the dumps in IPCS. I just can't seem to find any command in IPCS that just lets me see the GRs and browse storage. Tony Thigpen Seymour J Metz wrote on 10/29/20 6:37 PM: > 1. What is the authorization of your program? > If unauthorized, consider IEATDUMP instead. > > 2. Do you have a SYSMDUMP DD allocated? > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > >>> Gary Weinhold >>> Senior Application Architect >>> DATAKINETICS | Data Performance & Optimization >>> Phone:+1.613.523.5500 x216 >>> Email: weinh...@dkl.com >>> Visit us online at >>> http://secure-web.cisco.com/1THEYXYv7FFtOaUczXr8ApOqmq7ub_yqgp87kwzNSe-ooLJ7Uw9WPjR2rbllUd3YxOHr0HJAjk7A3MO3GGZ5SUxLI6UZ9JGQRGjF_eSesgHxUlE3ZAZ-1HXsZ_la3Au0ezVWDa13iaYg4XPb99FGIySu83c5W2NZTqB1wyV5hPXpUcwKKRmoiQFTI70jS5VkLGMMDhAKUSQLVjSosqDCj8kxpvdmHnyyCOzqEq1PthsCrB-kREClk06HUzp9fOBir_CEUgSy3NIe0PuvO__PmOj6v4xOzpNGqsKUwWhZZ_RvQlXilWgU6473awuKXwJVEE3eG1s0RgYky3ikIskD4MWUELrDh7Kt_-N4_fEDfJ89SzNO5-IOgVGJ6ss_XxK3y2ZVn0LIDzQ3OTz6KOeY1p88B5SCSZfF5SePKiqTfEazlWXll7P1ijGgBotd_QDyX/http%3A%2F%2Fwww.DKL.com >>> E-mail Notification: The information contained in this email and any >>> attachments is confidential and may be subject to copyright or other >>> intellectual property protection. If you are not the intended recipient, >>> you are not authorized to use or disclose this information, and we >>> request that you notify us by reply mail or telephone and delete the >>> original message from your mail system. >>> >>> From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] > on behalf of Tony Thigpen [t...@vse2pdf.com] > Sent: Thursday, October 29, 2020 6:13 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: SDUMPs > > I am very open to using IPCS (although I still have to learn use it.) > > When I use SDUMP, I get the following message on the console: > *74 IEA793A NO DUMP DATA SETS AVAILABLE FOR DUMPID=011 BY JOB > (FLASHME4). USE THE DUMPDS COMMAND OR REPLY D TO DELETE THE DUMP > > I tried: > DD ADD VOL=HKYSY4 > > 18.05.26 HKYP dd add,vol=HKYSY4 > 18.05.26 HKYP IGD100I 1213 ALLOCATED TO DDNAME SYS00051 >DATACLAS () > 18.05.26 HKYP IEE855I DUMPDS COMMAND RESPONSE > DUMPDS COMMAND SYS1.DUMP DATA SET STATUS > DASD VOLUMES ADDED: HKYSY4 > > Then: > dd alloc=active > > Then: > DD ADD DSN=01 > > 18.07.01 HKYP dd add,dsn=01 > 18.07.01 HKYP IEE855I DUMPDS COMMAND RESPONSE > DUMPDS COMMAND SYS1.DUMP DATA SET STATUS > SYS1.DUMP DASD DATA SETS NOT ADDED: > LOCATE FAILED: (01,08) > > > Suggestion? > > Tony Thigpen > > Seymour J Metz wrote on 10/29/20 5:35 PM: >> SDUMP in MVS is for creating an unformatted dump to be viewed online >> with IPCS. For a short formated storage dump use SNAPX. However, >> once you get used to it you may find SDUMP and IPCS more convenient. >> >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> >> >> From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] >> on behalf of Tony Thigpen [t...@vse2pdf.com] >> Sent: Thursday, October 29, 2020 4:47 PM >> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU >>
Re: Another Macro question
ould take to differentiate an eye catching >> string in program storage from an instance of it in in use to nominate a >> control block, I have to wonder if this is a solution looking for a problem >> to solve. >> Keven >> >> >> >> >> >> >> >> >> >> >> On Tue, Oct 20, 2020 at 4:22 PM -0500, "Steve Smith" >> wrote: >> >> >> >> >> >> >> >> >> >> >> It's not complicated if you know how to manipulate strings in Conditional >> Assembly. There's no much way around the fact it's vanity programming >> though. >> >> Besides, the technique is defeated by palindromes :-). >> >> sas >> >> >> On Tue, Oct 20, 2020 at 4:16 PM Tom Harper >> wrote: >> >>> I already have such a macro. I’ll post it later. >>> >>> 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 attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Another Macro question
I already have such a macro. I’ll post it later.
Sent from my iPhone
> On Oct 20, 2020, at 4:06 PM, Tony Thigpen wrote:
>
> While we are talking about macros, a while back, someone posted they liked to
> fill eye-catchers using MVCIN so that scans of the dump for a tag only found
> the real eye-catcher, not the literal used to fill the eye-catcher.
>
> So, instead of:
> MVC EYE1,=C'(BTABLE>'
> use:
> MVCIN EYE1+L'EYE1-1(l'EYE1),=C'>ELBATB('
>
> This would seem to be a good place for a macro:
> MVCEYE EYE1,'(BTABLE>'
> that would generate the correct MVCIN.
>
> Anyone want to try their hand at writing this macro?
>
>
> Tony Thigpen
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 attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.
Re: Strange code snippet
Pieter, This code works fine. The code below was used to get the current TCB address before PSATOLD was introduced with the advent of SRBs. I doubt if changing the code will make any difference one way or the other as it will all be in cache anyway. Tom Sent from my iPhone > On Sep 2, 2020, at 9:59 AM, pw...@mweb.co.za wrote: > > HI all > I found the following code on 2 different client systems (one of them in an > IMS sample user exit). > > L R8,CVTPTR > L R8,CVTTCBP-CVT(,R8) > L R8,4(,R8) > > Can anybody think of a reason why I should not rather use L R8,PSATOLD-PSA ? > > Pieter 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 attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: PC-SS vs PC-CP Curiosity
No task switching takes place. However, if certain SLIPs are in effect, there may be a space switch interruption which will negatively affect performance. Tom - Original Message - From: esst...@juno.com [mailto:esst...@juno.com] Sent: Saturday, January 28, 2012 09:08 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: PC-SS vs PC-CP Curiosity Peter Relson Wrote "using common storage when it is not needed can be detrimental to customers". This point is well taken and very much umderstood. What guidelines would one impose if Common storage is needed. 1K 4K .. 2nd Regarding performance, I would be my understanding that there would be some overhead when A Space Switching PC is issued, due to task switching. Do I understand this correctly ? Paul D'Angelo -- Original Message -- From: Peter Relson To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: PC-SS vs PC-CP Curiosity Date: Mon, 23 Jan 2012 08:58:47 -0500 I suggest that performance not be the consideration you should care about here (even if there is a small difference; I do not happen to know if there is). The main consideration should be your being considerate with respect to customer needs -- using common storage when it is not needed can be detrimental to customers. If you already have the need for your own address space, and already have the need for space-switch PC's, then the question should likely be whether your routine must be in common storage or need not be. If it does not need to be, then usually it should not be. Peter Relson z/OS Core Technology Design
Re: Sample code for PC-ss with SRB back to user space?
Peter, I gave a presentation at SHARE sometime back titled "How to Write a Commercial Software Program" where I covered a lot of these issues. There have been many other presentations at SHARE which covered STARTIO, zHPF, sorting, and other topics. Tom Harper Neon Enterprise Software Sugar Land, TX -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Farley, Peter x23353 Sent: Monday, February 14, 2011 7:47 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Sample code for PC-ss with SRB back to user space? The recent discussion of the commanality of vendor code that sets up an STC which runs in privileged mode and also supplies a subroutine or API for a user address space TCB program to use PC-ss to "call" that STC, which then may schedule an SRB to run back in the calling address space to accomplish the vendor's purpose brought back a question I have had for some time: Why isn't there any good sample code available showing how to do this? Or have I just not looked hard enough to find it? Such code is certainly expert-level stuff, but as a soi-disant assembler expert I would love to have the option of using that tool where it would be appropriate. Figuring out all the nuances and pitfalls of this technique from scratch seems to me to be a counter-productive use of scarce time. Peter -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
Re: Is this a commonly used technique ?
Common technique. - Original Message - From: esst...@juno.com [mailto:esst...@juno.com] Sent: Saturday, February 12, 2011 05:37 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Is this a commonly used technique ? This week I attended a vendors presentation of a proposed product. I rather not disclsoe the Vendor nor the product due to any confidentialy agreements. The Speaker for this presentation did not provide any specific details. However from the presentation I was able to deduce the following (I think). Address Space "A" runs in problem state - key 8. Address Space "A" Issues a Program Call instruction which inturn invokes a Cross Memory Space Switching Routine (in the Vendors Server Space "B"). The PC-ss routine executes in supervisor state, and its only responsibility is to schedule an SRB into the requesting Address Space "A". Now Address Space "A" has an SRB Routing executing in its address space in Supervisor State. Has anyone seen the above Architecture/Technique used ? Is this a commonly used technique ? Paul D'Angelo .
Re: CFC and UPT
Steve, Sent. Tom Tom Harper IMS Utilities Development Team Neon Enterprise Software Sugar Land, TX -Original Message- From: IBM Mainframe Assembler List [mailto:assembler-l...@listserv.uga.edu] On Behalf Of Steve Comstock Sent: Wednesday, December 22, 2010 8:58 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: CFC and UPT On 12/8/2010 8:07 AM, Tom Harper wrote: > Sent attachment privately to Fred, since attachments are not allowed on this > listserv. > > Tom > > Tom Harper > Neon Enterprise Software > Sugar Land, TX So what's happened with SHARE? I thought previous proceedings were available online to members, but all I can see are the proceedings for the SHARE in Boston. Are previous conference proceedings no longer available online to members? So, Tom, could you send me a copy of the referenced talk, too? Thanks. > > -Original Message- > From: IBM Mainframe Assembler List [mailto:assembler-l...@listserv.uga.edu] > On Behalf Of Fred van der Windt > Sent: Wednesday, December 08, 2010 3:27 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: CFC and UPT > > On Mon, 9 Nov 2009 16:44:12 -0600, Michael Stack wrote: > >> This may help: http://www.kcats.org/share/sort/slides/SortAst.pdf . At > the same SHARE meeting, Tom Harper gave a complementary session on how to > implement the instructions. >> >> Mike > > Can somebody point me to that second presentation by Tom Harper? I vaguely > remember looking at it but can't find a link to the presentation anymore. > > Thanks, > > Fred! > -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our new tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html
Re: CFC and UPT
Sent attachment privately to Fred, since attachments are not allowed on this listserv. Tom Tom Harper Neon Enterprise Software Sugar Land, TX -Original Message- From: IBM Mainframe Assembler List [mailto:assembler-l...@listserv.uga.edu] On Behalf Of Fred van der Windt Sent: Wednesday, December 08, 2010 3:27 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: CFC and UPT On Mon, 9 Nov 2009 16:44:12 -0600, Michael Stack wrote: >This may help: http://www.kcats.org/share/sort/slides/SortAst.pdf . At the same SHARE meeting, Tom Harper gave a complementary session on how to implement the instructions. > >Mike Can somebody point me to that second presentation by Tom Harper? I vaguely remember looking at it but can't find a link to the presentation anymore. Thanks, Fred!
Re: Any ideas on how to know if a DDNAME is input or output?
Scott, I think this would be more appropriately posted on IBM-MAIN, since this really has nothing to do with the assembler. However, a DDNAME does not have an attribute of input or output. It has a DISP attribute of NEW, SHR, OLD, or MOD, but except for NEW (which initially must be output), there is no way to tell. This is because it is the DCB or ACB which determines the potential for input or output processing, not the DD statement. In addition, over the lifetime of the DDNAME (which represents an allocation), it could be input for a while, then output, or both concurrently. Maybe it would help us to understand your intent better if you let us know what you are trying to accomplish? Tom Harper IMS Utilities Development Team Neon Enterprise Software Sugar Land, TX -Original Message- From: IBM Mainframe Assembler List [mailto:assembler-l...@listserv.uga.edu] On Behalf Of Scott Bennett Sent: Wednesday, September 01, 2010 3:54 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Any ideas on how to know if a DDNAME is input or output? I need to know if a DDNAME is input or output to a job step, I know some can be both but will handle that manually. I was planning to use informatino found in TIOT and/or JFCB to determine if a DDNAME looks like somthing that is input or looks like output. Has anyone had to perform this task? If so how did you make a best guess on a DDNAME being input or output? Thanks, Scott
