Re: Branch-and-Link nomenclature question
Hi Guys, Specifically to Dave Cole's query... >>>(FWIW, I find both books to be abysmal documents!) >>>(There. That ought to create a firestorm!) A few years ago and on this forum I dared to say that the PoO was totally inadequate for the 21st century...an opinion I still hold It did get a 'firestorm' reaction, about evenly distributed between, "it's a bible and cannot be modified" to those agreeing with me Among my suggestions, only applying to instruction descriptions is that... These should be in a separate Manual, one 'page' per instruction, hyperlinks to similar instructions, maybe a tracker saying 'people who looked at AHI also looked at LHI :-)' Perhaps there's someone out there who has the time Melvyn Maltz. On 10/02/2022 07:40 pm, David Cole wrote: WRT: "A gentle reminder on terminology: The term "JUMP" appears neither in the PoO nor in the z/Architecture Reference Summary (SA22-7832). What you refer to as "JAS (jump and save)" is simply reflecting the extended mnemonic for BRANCH RELATIVE AND SAVE (BRAS)." The PoOps has some inconsistencies... One that I find rather irritating is the presences of extended mnemonics for a large number of newer instructions, but the omission of same for all of the BC, BRC, BRAS and related instructions. Yes, I am quite aware that I included redundant entries in my list. I didn't care because it was beside the point. Speaking of fake mnemonics... What is the difference between "extended mnemonics" (such as CGIJNE) and "alternative mnemonics" (such as JAS)? Is it that one is documented only in the PoOp and the other only in HLASM Ref? (FWIW, I find both books to be abysmal documents!) (There. That ought to create a firestorm!) Dave At 2/10/2022 01:27 PM, Dan Greiner wrote: Having learned this stuff in the 1970s — before the linkage stack showed up in the late 1980s — I was accustomed to hearing them called simply "linkage instructions." For the common usage of application programmers who need a simple instruction to branch to Oz while leaving a footprint of how to get back to Kansas, that's probably sufficient. . The z/Architecture Principles of Operation (SA22-7832-10) refers to such instruction in a section labelled "Subroutine Linkage without the Linkage Stack" (p. 5-16 onward), with the simple stuff like BAL[R], BAS[R] and friends called "Simple Branch Instructions". This text shows the awkwardness that crept into the architecture when various commonly-used terms get redeployed for other purposes. [A brief aside: During the design of the S/360, the designers deliberately eschewed a stack architecture in favor of the chained save-area approach. With the advent of ESA, they changed their minds (sort of) and implemented a linkage stack.] A gentle reminder on terminology: The term "JUMP" appears neither in the PoO nor in the z/Architecture Reference Summary (SA22-7832). What you refer to as "JAS (jump and save)" is simply reflecting the extended mnemonic for BRANCH RELATIVE AND SAVE (BRAS).
Re: Vector Ops
Hi Ray, No need for a z15, z390 supports them :-) Melvyn. On 14/12/2021 01:06 pm, Ray Mansell wrote: Excellent stuff, as always, Dan. Now, if only I could find a z15 on which to play :-) Ray On 12/14/2021 12:03 AM, Dan Greiner wrote: Back in late September, I posted a series of PowerPoint slides describing the IBM z/Architecture vector facilities on my Google Drive: https://drive.google.com/file/d/13OhBkhgbU7N6a20nVo5uEAnR-s3-Pyz8/view?usp=sharing The most common response I've received is something to the effect of "good stuff ... now what do I do with it?" Last Christmas, I received a really annoying puzzle as a gift ... annoying because solving it involved a lot of repetitive stress on my already inflamed carpals. A simple C program did the trick, but I wanted to see if I could use the vector ops to do better, so I started researching them. This led to a months-long documentation project resulting in the slides mentioned above. I've put together another short presentation — only 11 slides — that describe the puzzle and one solution using vector instructions. There are numerous features of the vector architecture, but this pitch illustrates what I think are a few key points: SIMD, branch avoidance, and a really neat instruction (VPERM). Unlike my previous stuff, there is no animation in these slides; the meat of it is in the presenter notes, so make sure you view the notes page. https://docs.google.com/presentation/d/1gD089nRo8Lch-rkg7T7pbwclBAvsp0bf/edit?usp=sharing&ouid=104012833061983447284&rtpof=true&sd=true Enjoy!
Re: Base-less macros
Hi there, I am sure Jonathan will confirm...but yes, even byte literals will be on an even boundary, they are sorted If you code it and use LARL, you'll get an error if not on an even boundary =CL5 may not align, a frequent source of 'it worked then but not now' syndrome Melvyn Maltz. On 08/11/2021 09:17 pm, Paul Gilmartin wrote: On Nov 8, 2021, at 13:57:10, Melvyn Maltz wrote: ... LARL R3,=C'ABCDE-' Yes, it's a 5-byte literal extended to 6 to keep the LARL happy Does giving a character constant even length guarantee even alignment? I'm thinking of such as: DC. 0H'0' EVEN DC C'?' ODD DC C'ABCDE-' Are the rules special for literals? What if you want a speciic length?: LARL R3,=CL5'ABCDE-' My head hurts, gil
Re: Base-less macros
Hi there, I hate the term base-less it means 'without foundation' ! I'm not sure what the fuss is about, I've been using base-free code with literals for years. eg. LARL R3,=C'ABCDE-' MVC THERE(5),0(R3) Yes, it's a 5-byte literal extended to 6 to keep the LARL happy LARL has a range of +/- 2G which should keep most coders happy, so it doesn't matter where the LTORG is Melvyn Maltz. On 08/11/2021 12:25 am, Tony Thigpen wrote: I finally am to the point where I no longer need to worry about specific customers having hardware that does not support relative instructions, so I am updating some macros I provide to be baseless. What is the 'preferred' approach to macro generated constants? In the past, I have used both inline constants that I branch around, and ltorg literals (=c'x'). In the past, I have been bitten by using ltorg literals and the client did not put a LTORG after my macro causing a 'no active base register' issue. So, I am thinking inline with a BRAS is better. Maybe there is another approach that I missed? Suggestions? Tony Thigpen
Re: A problem with OPEN and CLOSE macros
Hi Guys, Thanks for the responses, here's mine... To Charles... You made my point exactly, as you didn't at first realise what the code was doing, but you did 10 minutes later :-) Mark Nelson is not your guy for this, unless you think there is an integrity issue I believe there is, it certainly got Mark's attention, also a UK RACF expert that I know Your gun, your bullet, your foot What I was trying to demonstrate is how a hacker could subvert code without it being obvious what was happening. My code wasn't subtle, if I had wanted to hide my evil-doing...I could do If I rewrote the code to overlay an I/O buffer then your company's data integrity is at risk ! Subverting z/OS or RACF is a little more difficult To Seymour... Like Charles, you haven't realised what the code does...exactly my point Further, your code would fail I sent Mark the full program, I tested it and it works R5 doesn't contain a DCB address. I know...OPEN wouldn't get that far because the end-of-list bit stays with DCB 1 I'm using R5 to do something nasty to storage beyond the MF=L Melvyn Maltz. - Original Message - From: "Seymour J Metz" To: Sent: Sunday, June 13, 2021 3:29 PM Subject: Re: A problem with OPEN and CLOSE macros Using an operand with the wrong length is a basic error, not limited to OPEN or even to macros. Further, your code would fail even if you corrected HERE24O to OPEN (DCB1,INPUT,*,),MF=L; R5 doesn't contain a DCB address. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of MELVYN MALTZ [072265160664-dmarc-requ...@listserv.uga.edu] Sent: Friday, June 11, 2021 4:36 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: A problem with OPEN and CLOSE macros 1) An OPEN/CLOSE with MF=L,MODE=24 can be overlayed with an MF=E,MODE=31 (and vice-versa). This results in destruction of the list, abends would occur 2) An OPEN/CLOSE with MF=L with (say) 2 entries can be overlayed with an MF=E with 3 entries. The end-of-list bit isn't touched, but a storage violation occurs It is true that the "DFSMS Macro Instructions for Data Sets" does warn against mixed mode and MF=L/E length differences with the usual 'unpredictable results may occur' The first problem doesn't worry me, but the second one does, look at this cut-down code...no apologies for it being contrived...if I wanted to hide it, I could do... LA 2,8-1 EX R2,EXMVC LR5,EXMVC OILF R5,X'00FF' OPEN (DCB2,OUTPUT,(R5)),MF=(E,HERE24O),MODE=24 EX R2,EXMVC ... HEREDC8C'A' THERE DC8C'B' * DCB1 DCB ... DCB2 DCB ... * HERE24O OPEN (DCB1,INPUT),MF=L EXMVC MVC THERE(0),HERE Using OPEN/CLOSE to subvert code sends this into another dimension I've been exchanging Emails with Mark Nelson (RACF Development) about this and have offered a solution, I can quite understand why IBM aren't keen on it 1) The OPEN/CLOSE list structure must change The 'new' structure needs an 8-byte header eg. DC C'OPCL' eyecatcher DC X'mode bit' DC XL3'no. of entries' 2) The OPEN/CLOSE SVC processors must be able to detect the 'old' and 'new' formats in order not to disturb existing code 3) OPEN/CLOSE MF=E will have extra coding for the 'new' format only, to detect both mode and storage violation errors...setting an error code Whether this is worth doing is largely up to the user community, I would be worried if an innocent looking macro could subvert program code Your thoughts ? Melvyn Maltz.
A problem with OPEN and CLOSE macros
1) An OPEN/CLOSE with MF=L,MODE=24 can be overlayed with an MF=E,MODE=31 (and vice-versa). This results in destruction of the list, abends would occur 2) An OPEN/CLOSE with MF=L with (say) 2 entries can be overlayed with an MF=E with 3 entries. The end-of-list bit isn't touched, but a storage violation occurs It is true that the "DFSMS Macro Instructions for Data Sets" does warn against mixed mode and MF=L/E length differences with the usual 'unpredictable results may occur' The first problem doesn't worry me, but the second one does, look at this cut-down code...no apologies for it being contrived...if I wanted to hide it, I could do... LA 2,8-1 EX R2,EXMVC LR5,EXMVC OILF R5,X'00FF' OPEN (DCB2,OUTPUT,(R5)),MF=(E,HERE24O),MODE=24 EX R2,EXMVC ... HEREDC8C'A' THERE DC8C'B' * DCB1 DCB ... DCB2 DCB ... * HERE24O OPEN (DCB1,INPUT),MF=L EXMVC MVC THERE(0),HERE Using OPEN/CLOSE to subvert code sends this into another dimension I've been exchanging Emails with Mark Nelson (RACF Development) about this and have offered a solution, I can quite understand why IBM aren't keen on it 1) The OPEN/CLOSE list structure must change The 'new' structure needs an 8-byte header eg. DC C'OPCL' eyecatcher DC X'mode bit' DC XL3'no. of entries' 2) The OPEN/CLOSE SVC processors must be able to detect the 'old' and 'new' formats in order not to disturb existing code 3) OPEN/CLOSE MF=E will have extra coding for the 'new' format only, to detect both mode and storage violation errors...setting an error code Whether this is worth doing is largely up to the user community, I would be worried if an innocent looking macro could subvert program code Your thoughts ? Melvyn Maltz.
Relocatable immediate values
I have to thank my esteemed colleague Don Higgins for enabling this post IILF R3,MYLABEL ... MYLABEL DC 'HELLO' This is interesting on a number of levels, yes, the immediate value is relocatable I guess this is a 'good thing' for 32-bit immediate instructions...hmmm My concern is though, are these instructions modal ? I haven't tested all variants, but in 31-bit mode is the top bit on ? If so, LGFI would propagate it...if so it doesn't seem like a good thing Not a lot about this in the PoP...nada
Re: Is TESTCB a bad boy ?
Apologies, I misremembered Found a Functional Characteristics for the 360/50 and it's 0.5uS Melvyn Maltz. - Original Message - From: "Seymour J Metz" To: Sent: Wednesday, October 28, 2020 6:51 PM Subject: Re: Is TESTCB a bad boy ? WTF? Yes, on some models index was more expensive than base, but I don't know of any model where it was nearly as large as 50 microseconds. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of MELVYN MALTZ [072265160664-dmarc-requ...@listserv.uga.edu] Sent: Tuesday, October 27, 2020 5:24 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Is TESTCB a bad boy ? To Charles... EX 0, on a dynamically constructed TM...the hard way doing whatever... had to be done I don't want to get off topic, but TESTCB is the worst IBM macro I have ever seen Syntax checking...none, documentation...awful and misdescribed in the VSAM Macro manual...I won't go on And using an index register instead of a base register is frowned upon (440D0014) I doubt if it matters now, but you are right, back in 360/370 days the use of index carried a 50uS overhead I well remember obsessively recoding LA R5,1(R5) as LA R5,1(,R5) back in the days Melvyn Maltz.=
Re: Is TESTCB a bad boy ?
To Charles... EX 0, on a dynamically constructed TM...the hard way doing whatever... had to be done I don't want to get off topic, but TESTCB is the worst IBM macro I have ever seen Syntax checking...none, documentation...awful and misdescribed in the VSAM Macro manual...I won't go on And using an index register instead of a base register is frowned upon (440D0014) I doubt if it matters now, but you are right, back in 360/370 days the use of index carried a 50uS overhead I well remember obsessively recoding LA R5,1(R5) as LA R5,1(,R5) back in the days Melvyn Maltz. - Original Message - From: "Charles Mills" To: Sent: Tuesday, October 27, 2020 8:22 PM Subject: Re: Is TESTCB a bad boy ? Interesting code. I suspect that others are correct: the EX target is far enough away as to not adversely affect the pipeline. Two other comments though: EX 0, on a dynamically constructed TM seems like the hard way of doing whatever it was that had to be done. I would have to understand all the code to be sure, but that sure seems like doing things the hard way. And using an index register instead of a base register is frowned upon (440D0014). Not sure if it is still true today, but once upon a time at least the use of an index register slowed things down by a cycle. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of MELVYN MALTZ Sent: Monday, October 26, 2020 7:22 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Is TESTCB a bad boy ? Thanks for all the responses, very useful Perhaps I'd better state what environment I'm working in I'm using the MVS 3.8 version of VSAM macros which are in the Public Domain IDA019C1 is the xCB processor and I have the source code from that era All of this has been adapted in z390 so that I have a emulated IBM VSAM environment as far as xCB operations go To respond to most of you To Charles... Rather than send you the unfathomable code from IDA019C1 here is an extract from a z390 trace which shows a typical situation, code followed by source 800FDCCA 0 9291D014 MVI S2(000FF98C)=96 I2=91='j' IDA019C1 00105A MVI TSTOP(REG13),X'91' 800FDCCE 0 440D0014 EXR0=800FD42E S2(000FF98C)=91804001 IDA019C1 00105E EX REG0,BITSTINS(REG13) To Gary... TESTCB has list, execute, and generate forms; they generate reentrant code Mostly they don't, some like MF=G have the potential but as always it's up to the skill of the programmer to ensure re-entrancy To Christopher... As you can see from the above code the instruction doing the mod is about 7K from the instruction being modified, so only that cache would be refreshed, a minor overhead provided is wasn't being done a lot I'm still a little concerned that TESTCB might be used internally by COBOL etc and be taking a performance hit unknown to the users Melvyn Maltz. - Original Message - From: "Christopher Y. Blaicher" To: Sent: Monday, October 26, 2020 7:21 PM Subject: Re: Is TESTCB a bad boy ? A cache line is 256 bytes. If the code that modifies an instruction is in the same cache line as the instruction, then multiple cache line refreshes have to happen. The cache line for the modified instruction has to be brought into the data cache and modified. This causes the cache line in the instruction cache to be invalidated. The cache line then has to be refreshed into the instruction cache and then the next instruction re-fetched. Doing an EX causes no cache line refreshes and does not interfere with the pipeline. As I said, EX has its own set of overheads, but are a very small fraction of modifying an instruction. Chris Blaicher Technical Architect Precisely.com -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Farley, Peter x23353 Sent: Monday, October 26, 2020 2:33 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Is TESTCB a bad boy ? This message originated Externally. Use proper judgement and caution with attachments, links, or responses. Isn't that true only if the dynamically built instruction isn't in the same cache line as the code that performs the build and EX? I've seen examples where the "built" instruction was a non-reentrant location in the same CSECT and very near to the "build" instructions. Not my code, but I have seen it. Peter -Original Message- From: IBM Mainframe Assembler List On Behalf Of Christopher Y. Blaicher Sent: Monday, October 26, 2020 2:07 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Is TESTCB a bad boy ? This will not have the same performance hit. The problem with the MVI was the CPU had to 1) bring the cache line into the data cache; 2) apply the MVI data; 3) refresh the cache line in the instruction cache; and finally 4) execute the ins
Re: Is TESTCB a bad boy ?
Thanks for all the responses, very useful Perhaps I'd better state what environment I'm working in I'm using the MVS 3.8 version of VSAM macros which are in the Public Domain IDA019C1 is the xCB processor and I have the source code from that era All of this has been adapted in z390 so that I have a emulated IBM VSAM environment as far as xCB operations go To respond to most of you To Charles... Rather than send you the unfathomable code from IDA019C1 here is an extract from a z390 trace which shows a typical situation, code followed by source 800FDCCA 0 9291D014 MVI S2(000FF98C)=96 I2=91='j' IDA019C1 00105A MVI TSTOP(REG13),X'91' 800FDCCE 0 440D0014 EXR0=800FD42E S2(000FF98C)=91804001 IDA019C1 00105E EX REG0,BITSTINS(REG13) To Gary... TESTCB has list, execute, and generate forms; they generate reentrant code Mostly they don't, some like MF=G have the potential but as always it's up to the skill of the programmer to ensure re-entrancy To Christopher... As you can see from the above code the instruction doing the mod is about 7K from the instruction being modified, so only that cache would be refreshed, a minor overhead provided is wasn't being done a lot I'm still a little concerned that TESTCB might be used internally by COBOL etc and be taking a performance hit unknown to the users Melvyn Maltz. - Original Message - From: "Christopher Y. Blaicher" To: Sent: Monday, October 26, 2020 7:21 PM Subject: Re: Is TESTCB a bad boy ? A cache line is 256 bytes. If the code that modifies an instruction is in the same cache line as the instruction, then multiple cache line refreshes have to happen. The cache line for the modified instruction has to be brought into the data cache and modified. This causes the cache line in the instruction cache to be invalidated. The cache line then has to be refreshed into the instruction cache and then the next instruction re-fetched. Doing an EX causes no cache line refreshes and does not interfere with the pipeline. As I said, EX has its own set of overheads, but are a very small fraction of modifying an instruction. Chris Blaicher Technical Architect Precisely.com -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Farley, Peter x23353 Sent: Monday, October 26, 2020 2:33 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Is TESTCB a bad boy ? This message originated Externally. Use proper judgement and caution with attachments, links, or responses. Isn't that true only if the dynamically built instruction isn't in the same cache line as the code that performs the build and EX? I've seen examples where the "built" instruction was a non-reentrant location in the same CSECT and very near to the "build" instructions. Not my code, but I have seen it. Peter -Original Message- From: IBM Mainframe Assembler List On Behalf Of Christopher Y. Blaicher Sent: Monday, October 26, 2020 2:07 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Is TESTCB a bad boy ? This will not have the same performance hit. The problem with the MVI was the CPU had to 1) bring the cache line into the data cache; 2) apply the MVI data; 3) refresh the cache line in the instruction cache; and finally 4) execute the instruction. Doing an EX skips steps 1, 2 and 3. EX has its own set of overheads, but nowhere near what all the cache hits have. Chris Blaicher Technical Architect Precisely.com -Original Message----- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Melvyn Maltz Sent: Monday, October 26, 2020 11:16 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Is TESTCB a bad boy ? This message originated Externally. Use proper judgement and caution with attachments, links, or responses. In ancient times it was common practice to do this sort of thing... SWITCH NOP GO MVI SWITCH+1,X'F0' I believe this clears the cache and causes severe performance hits In my research into TESTCB for the z390 Project I found that it dynamically builds the subject instruction for an EX Would this have the same performance hit ? Melvyn Maltz. 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.
Is TESTCB a bad boy ?
In ancient times it was common practice to do this sort of thing... SWITCH NOP GO MVI SWITCH+1,X'F0' I believe this clears the cache and causes severe performance hits In my research into TESTCB for the z390 Project I found that it dynamically builds the subject instruction for an EX Would this have the same performance hit ? Melvyn Maltz.
Re: z390 Macros for Newer Instructions
Hi John, Please contact me directly using the zarf... address, I'll then give you an alternate I've just logged in to the Yahoo z390 site via http://groups.yahoo.com/group/z390/ You are right that z390.org hasn't been updated for ages, there is another z390.info but 'm not sure what the differences are I could certainly use some help with zVSAM V2 development Regards, Melvyn. - Original Message - From: "John" <0da23edbcde9-dmarc-requ...@listserv.uga.edu> To: Sent: Tuesday, July 14, 2020 10:12 PM Subject: Re: z390 Macros for Newer Instructions Melvyn, I worked on z390 starting circa 2014, stopping in April 2017. I might be interested in helping Don bring z390 up-to-date. The last version of z390 I downloaded from the old z390 Yahoo group was beta 12, roughly in September 2018. The Yahoo group no longer exists. Is there a central location that contains the current z390? The z390.org web site looks like it hasn't been updated in quite some time. Can we discuss this off-list? Regards, John Ganci On Tue, 2020-07-14 at 20:07 +0100, MELVYN MALTZ wrote: Hi Dan, I know Don Higgins is working on bringing z390 up-to-date regarding the current P-o-Ops There are now only Don and I trying to keep z390 development going, you would be most welcome to join us Although Java skills are needed most, I could use a buddy to oversee and test my Assembler development work for zVSAM V2 Melvyn Maltz. - Original Message - From: "Dan Greiner" To: Sent: Tuesday, July 14, 2020 6:51 PM Subject: z390 Macros for Newer Instructions I continue to noodle around with z390 and regularly find myself missing support for newer instructions (z390.org indicates that the latest instructions supported are for the z10, circa 2008). Being a Java moron, updating the source to support newer ops was beyond my ken. I finally got tired of coding various macros in support of newer instructions, so I gleaned a list of newer mnemonics from the "IBM z/Architecture Reference Summary" (SA22-7871-10) and extended mnemonics from the PoO (SA22-7832-12), and with a little calisthenics, converted them into 889 macros (there are a lot of extended vector mnemonics). You are welcome to examine the results at: https://drive.google.com/file/d/19lJfprlE0ZqIMYo1WXrEiW75Kri2lW7X/view?usp=sharing CAVEAT EMPTOR! Absolutely no warranty is implied or expressed! Got it? None! Zippo!! Zilch!!! The macros are simple minded, with no operand validation; so, if you code a general register higher than 15 or a vector register higher than 31, or if you omit an operand, bad things may happen. If you so happen to trip over an inaccurate result, a response posted to this message may (or may not) result in an update.
Re: z390 Macros for Newer Instructions
Hi Dan, I know Don Higgins is working on bringing z390 up-to-date regarding the current P-o-Ops There are now only Don and I trying to keep z390 development going, you would be most welcome to join us Although Java skills are needed most, I could use a buddy to oversee and test my Assembler development work for zVSAM V2 Melvyn Maltz. - Original Message - From: "Dan Greiner" To: Sent: Tuesday, July 14, 2020 6:51 PM Subject: z390 Macros for Newer Instructions I continue to noodle around with z390 and regularly find myself missing support for newer instructions (z390.org indicates that the latest instructions supported are for the z10, circa 2008). Being a Java moron, updating the source to support newer ops was beyond my ken. I finally got tired of coding various macros in support of newer instructions, so I gleaned a list of newer mnemonics from the "IBM z/Architecture Reference Summary" (SA22-7871-10) and extended mnemonics from the PoO (SA22-7832-12), and with a little calisthenics, converted them into 889 macros (there are a lot of extended vector mnemonics). You are welcome to examine the results at: https://drive.google.com/file/d/19lJfprlE0ZqIMYo1WXrEiW75Kri2lW7X/view?usp=sharing CAVEAT EMPTOR! Absolutely no warranty is implied or expressed! Got it? None! Zippo!! Zilch!!! The macros are simple minded, with no operand validation; so, if you code a general register higher than 15 or a vector register higher than 31, or if you omit an operand, bad things may happen. If you so happen to trip over an inaccurate result, a response posted to this message may (or may not) result in an update.
Re: Convert *signed* EBCDIC to packed decimal
Hi Doug, By s/370 I hope you mean z15...there are a few new instructions :-) I would recommend getting z390, a free Assembler emulator, go here www.z390.org You get me for free as a mentor as well :-) Contact me directly, not through this forum To your problem... Yes, you do need to scan for a sign, If you find a plus just set it to X'F0' If you find a minus, set it to X'F0' and use NI to set the last byte to X'nD' Then use CDZT or CXZT to convert to DFP Using DFP is better than the old packed instructions I expect there will be dissenters Melvyn Maltz. - Original Message - From: "Doug Wegscheid" To: Sent: Wednesday, June 03, 2020 9:26 PM Subject: Convert *signed* EBCDIC to packed decimal I'm getting reacquanted with s/370 assembler after a 40 years hiatus. I'm working through some examples from my Kacmar book, and need to convert from a character string to a packed decimal. PACK almost works, except it does not handle a leading (or any) plus or minus signed. Is there a *simple* way to do, or am I going to have to scan for the sign characters myself, remove them, pack the result, and flip the sign if it was negative? Alternatively, is there some accessible prior art out there?
Re: z/OS HLASM: EQU for statement labels
Hi Guys, I thought I would put my 2 cents worth in I know that 55 years of Assembler coding doesn't count for much these days :-) Labels... Even back in the 60's I was taught never to put a label on an instruction I only break that rule now for the subject of an EX (and its variants) In the old days of real storage I used to code label EQU * and this was fine Then paging came along and the recommendation was to keep in-line data close to the instructions using it (locality of reference). As people have mentioned this sometimes resulted in odd addresses and S0C1 abends (before unalignment was detected) So I switched to label DS 0H in coding Have to state the obvious...DS 0H might not be appropriate for some data as there are now many instructions that rely on specific alignments I consider... DS 0H label EQU * to be overkill and I would deduct 2 points With changes in architecture, we now move in-line data to avoid cache problems And did you know that this code...popular in ancient times is a performance disaster now ONETIME NOP THERE MVI ONETIME+1,X'F0' Returning CC from a subroutine... Have to point out that IBM do this in the VSAM TESTCB macro Melvyn Maltz. - Original Message - From: "David Woolbright" To: Sent: Tuesday, June 02, 2020 5:58 PM Subject: Re: z/OS HLASM: EQU for statement labels I’’m just a humble academic so I hesitate to weigh in. I trained assembler programmers for one large credit card processing company for many years and their standard was to use EQU * as the target of all branches, mainly so new lines could be added easily. I’ve never had an odd address created accidentally using this technique, but it’s also the case that the assembler will warn you in cases where you do have an unfavorable address. I’m in the process of revising many years of teaching material into book format, so your opinions on this matter to me. Using EQU for targets would seem to be a stylistic point on which reasonable people could disagree, but perhaps I’m wrong. On Jun 2, 2020, at 11:49 AM, Seymour J Metz wrote: Is this useful? Only if you're a sadist. -- 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: Tuesday, June 2, 2020 11:40 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels On 2020-06-02, at 09:33:48, Charles Mills wrote: I don't claim any benefit to the technique, it's just my habit. Actually I think the cleanest is a DS 0H followed by label EQU *. That clearly shows what is going on: re-establishing halfword alignment followed by mapping a label to an address. I found it ironic that: LABELCNOP ... assigns the address of the beginning of the padding rather than the end to LABEL. Is this useful? Fortunately, LABELDS0H does the opposite so your 2-instruction construct is otiose. -- gil
Re: Sample code to practice assembler
Hi JD, Download the z390 product (it's free) from www.z390.org It's an Assembler emulator for a PC under Windows or Linux I teach and mentor students of Assembler and would be happy to help you in any way z390 has it's own forums as well Contact me here zarf77...@blueyonder.co.uk Regards, Melvyn (z390 Developer) - Original Message - From: "johnnydeep san" To: Sent: Thursday, May 14, 2020 6:40 AM Subject: Sample code to practice assembler Hi all, I'm new bee and learning assembler by own. i'm glad to join this group. If you guys having any link or doc for practice basic Z/os assembler code. ,please let me know. Regards, JD
Re: Z390 Assembler Emulator
Hi Frank, I'm one of the few z390 developers left Contact me directly here zarf77...@blueyonder.co.uk z390 fully supports macro language, no special requirements It could be that your SYSMAC concat isn't correct Send me your BAT (renamed) and sample code and I'll sort out your problem I don't know Linux, but I know someone who does Melvyn Maltz. - Original Message - From: "Frank Myers" To: Sent: Monday, May 11, 2020 11:05 PM Subject: Z390 Assembler Emulator Hi, I installed the z390 emulator and assembler on Linux. I tried to assemble some of my code, but found that It was not recognizing my Macros. I copied them into the z390/mac directory, but still it does not find my Macros. * Is there a required step to preprocess or register macros before they can be used? Or do the macros need to adhere to a fixed record length? Or perhaps only a subset of IBM Assembler Macro language is supported? Or perhaps some other magic?* Thanks, in advance for any help or advise you can share. Frank
Re: Does S0C5 still exist ?
Hi Steve, You're the only person to actually meet my request...thankyou I would much appreciate the code used, I tried B and MVI to your address in A/RMODE 31 but I get S0C4 Melvyn. - Original Message - From: "Steve Smith" To: Sent: Thursday, January 30, 2020 12:39 AM Subject: Re: Does S0C5 still exist ? I proved it. IEA995I SYMPTOM DUMP OUTPUT 909 SYSTEM COMPLETION CODE=0C5 REASON CODE=0005 TIME=19.17.34 SEQ=01808 CPU= ASID=0038 PSW AT TIME OF ERROR 030C1001 FE8E8EA8 ILC 4 INTC 05 NO ACTIVE MODULE FOUND NAME=UNKNOWN DATA AT PSW IS UNAVAILABLE AT THIS TIME GR 0: _17E00FFE 1: _003C 2: DEAD_ 3: _0001 4: BEEF_ 5: _004F81A0 6: _004CCFC8 7: _00F97480 8: _004FE838 9: _004F83E8 A: _01D7B600 B: _0001 C: _07D4BC98 D: _6F60 E: _1E1E F: _7E8E8E88 END OF SYMPTOM DUMP It's about six lines of code that assumes you have less than a few petabytes of real storage, and that I'll leave as an exercise. Don't try this at home. It's rather dangerous code if you load the registers pointing to memory that actually does exist. I've seen many (far too many) dumps in my time, and that is definitely a unique PSW. sas
Re: Does S0C5 still exist ?
Hi Keven, You might be the 5th, but the response is respected I didn't know the LURA and STURA instructions but these require privops access From other responses I conclude that S0C5 is not possible with DAT on, but I still feel that it's more to do with storage key protection than DAT Again, turning DAT off requires rather special RACF access Melvyn. - Original Message - From: "Keven" To: Sent: Wednesday, January 29, 2020 11:36 PM Subject: Re: Does S0C5 still exist ? I’ve developed code that executed LURA and STURA instructions and I saw a few S0C5s along the way. I remember thinking at the time that I had finally filled in my S0Cx card (I.e., I had at that point written code that had non-deliberately ABENDed with a S0C1 through S0C9. I might even have cracked a beer that evening to mark the event.I think S0C5 only results from an attempt to access real storage addresses outside the available range I’m probably by now the 5th or so person to respond with this answer... On Wed, Jan 29, 2020 at 5:01 PM -0600, "Steve Smith" wrote: I think that's the winner! Much easier than stepping into DAT-off on one's own (unless you happen to actually still have a V=R region). John McKown's suggestion is nice for runner-up. sas On Wed, Jan 29, 2020 at 5:12 PM Keith Moe wrote: Yes. It is still possible to generate a REAL 0C5 (Addressing Exception) abend. To do so, you must be in DAT OFF mode. z/OS has DAT OFF Services and until you have a full 64-bit addressable real storage, an 0C5 can occur. Back in 2005, I accidentally generated one in a DAT OFF service call. Keith Moe BMC Software, Inc.
Re: Does S0C5 still exist ?
Well, yes, it may be possible I have a feeling that this is storage key related which is newer than DAT Melvyn - Original Message - From: "John McKown" To: Sent: Wednesday, January 29, 2020 9:47 PM Subject: Re: Does S0C5 still exist ? Cheat -- use the ABEND macro. Yes, you can use it to generate system anend codes. PIC 5 is basically that a physical address doesn't exist, so I doubt you can generate it DAT on. On Wed, Jan 29, 2020, 15:11 Melvyn Maltz < 072265160664-dmarc-requ...@listserv.uga.edu> wrote: As part of a training exercise I was challenged to write code that abended S0C5 While I'm very skilled at writing Assembler code that abends, I failed in this case :-( With the advent of much more secure storage allocation (if someone mentions CICS Storage Violations the men in white coats will have to sedate me) is it possible to create a S0C5 ? Some simple code that does it please Melvyn
Re: Does S0C5 still exist ?
No, that's a S0C6 - Original Message - From: "John Melcher" <0a33cad2fca2-dmarc-requ...@listserv.uga.edu> To: Sent: Wednesday, January 29, 2020 9:33 PM Subject: Re: Does S0C5 still exist ? Jdoesn't do it? -Original Message- From: IBM Mainframe Assembler List On Behalf Of Joe Dolcini Sent: Wednesday, January 29, 2020 3:32 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Does S0C5 still exist ? *** External email: Verify sender before opening attachments or links *** I thought it was leftover from MVT (non-virtual) days. I found the following S0C5 – Addressing Exception Description An address developed and used by the ABENDing program lies outside of the available virtual storage on the processor. Possible Causes Indexing, Subcripting outside the program’s assigned limits. Un-initialized index Attempt to read an unopened input file A missing or misspelled DD statement. An attempt to close a dataset second time An input/output instruction is terminated because an open is unable to complete Regarding the listed reasons that reference datasets, I didn’t think those would get an 0c5. On Jan 29, 2020, at 3:23 PM, Steve Thompson wrote: Get the PoOP and look at Program Interrupt Code (PIC) 5. I can't remember off the top of my head if this is addressing or specification exception. Regards, Steve Thompson On 1/29/20 4:11 PM, Melvyn Maltz wrote: As part of a training exercise I was challenged to write code that abended S0C5 While I'm very skilled at writing Assembler code that abends, I failed in this case :-( With the advent of much more secure storage allocation (if someone mentions CICS Storage Violations the men in white coats will have to sedate me) is it possible to create a S0C5 ? Some simple code that does it please Melvyn
Re: Does S0C5 still exist ?
Thanks Steve, Yes, it's in the Manual, but does it exist is my question ? And yes, Addressing Melvyn - Original Message - From: "Steve Thompson" To: Sent: Wednesday, January 29, 2020 9:23 PM Subject: Re: Does S0C5 still exist ? Get the PoOP and look at Program Interrupt Code (PIC) 5. I can't remember off the top of my head if this is addressing or specification exception. Regards, Steve Thompson On 1/29/20 4:11 PM, Melvyn Maltz wrote: As part of a training exercise I was challenged to write code that abended S0C5 While I'm very skilled at writing Assembler code that abends, I failed in this case :-( With the advent of much more secure storage allocation (if someone mentions CICS Storage Violations the men in white coats will have to sedate me) is it possible to create a S0C5 ? Some simple code that does it please Melvyn
Does S0C5 still exist ?
As part of a training exercise I was challenged to write code that abended S0C5 While I'm very skilled at writing Assembler code that abends, I failed in this case :-( With the advent of much more secure storage allocation (if someone mentions CICS Storage Violations the men in white coats will have to sedate me) is it possible to create a S0C5 ? Some simple code that does it please Melvyn
Re: Where do I find more info about new z15 instruction SORTL listed in Sept. APAR but not in POP
Hi there, APAR PH00902 has this neat get-out clause... The presence of a mnemonic in the above lists does not necessarily mean that the corresponding instruction is available to use. The list may include mnemonics reserved for possible future use, so that if the corresponding instructions are made available before the next major hardware level this will not result in any new potential clashes with library macros. Melvyn Maltz. - Original Message - From: "Charles Mills" To: Sent: Sunday, December 01, 2019 9:03 PM Subject: Re: Where do I find more info about new z15 instruction SORTL listed in Sept. APAR but not in POP There were not yet any exploiters and they aim to keep it that way! Geez, you would think the several-year lead time on hardware design would have given the DFSORT team a decent head start. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Ed Jaffe Sent: Sunday, December 1, 2019 9:56 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Where do I find more info about new z15 instruction SORTL listed in Sept. APAR but not in POP On 12/1/2019 5:59 AM, Don Higgins wrote: All Where do I find more info about new z15 instruction SORTL listed in Sept. APAR but not in POP I asked IBM about this pre-GA and was told that the doc was *deliberately* left out of PoOp because there were not yet any exploiters! WTF? How can anyone exploit something that isn't documented? My "push back" on that was left unanswered... :-\
Re: C DLL Code from Assembler
Hi Tony, I'm in the process of rewriting GENCB for the z390 Emulator It's in use by CICS and many other things GENCB BLK=RPL,ACB=(R5),... It would be a serious bug if it didn't work I tried it and it works with MF=omitted, E and G An ST places the content of R5 into the ACE block Register notation is invalid with MF=L Melvyn Maltz. - Original Message - From: "Tony Harminc" To: Sent: Tuesday, July 02, 2019 8:54 PM Subject: Re: C DLL Code from Assembler On Tue, 2 Jul 2019 at 12:50, John McKown wrote: Wouldn't it be nice if IBM were to extend the GENCB macro to include BLK=DCB in addition to BLK=ACB, BLK=RPL, BLK=EXLST, and BLK=NIB? OTOH, does anyone actually use GENCB? My impression is that GENCB and friends were effectively deprecated long ago. We have them in some of our legacy VTAM code, and there are all kinds of annoyances and things that they don't do correctly and completely. (For example, a GENCB BLK=RPL,ACB=(Rn),OPTCD=... fails to store the supplied ACB address in the created RPL field RPLDACB.) It's a nice idea but a poor implementation. To say nothing about the need to bracket GENCB with ACONTROL FLAG(NOPAGE0) POP ACONTROL to avoid the HLASM complaint about no base register (because GENCB references the CVT with a L 15,16). That they haven't made that trivial fix in these many years says plenty. Tony H.
Re: Best practice using Conditional Assembly
Hi Paul, Others will give you code Define an LCLC array Keep a count of entries Before inserting a new entry, scan the array to see if &XCODE is already there If it is...it's a duplicate If not, add it and increment the count Melvyn Maltz - Original Message - From: "esst...@juno.com" To: Sent: Sunday, March 03, 2019 10:26 PM Subject: Best practice using Conditional Assembly Hi,.I construct a table using a set of Macros. The macro supports four different TYPE fuctions. I can have a TYPE=INITIAL, TYPE=ENTRY, TYPE=FINAL, and TYPE=DSECT. . TYPE=INITIAL basically sets up pointers to the first entry, last entry, and a count of the number of entries. . TYPE=ENTRY describes the individual elements in the table, each ENTRY is identified by a four character Transaction Code. . I want to know how best to identify a duplicate Transaction Code during Assembly of the Table. . For Example SV5000XX TYPE=INITIAL SV5000XX TYPE=ENTRY,XCODE=ABCD,P1=JOB001,P=JOB002,P3=JOB003 SV5000XX TYPE=ENTRY,XCODE=IJKL,P1=JOB021,P=JOB032,P3=JOB043 SV5000XX TYPE=ENTRY,XCODE=ABCD,P1=JOB0AA,P=JOB0BB,P3=JOB0CC SV5000XX TYPE=FINAL . In the above scenario, I would want to flag entry three as a duplicate XCODE of ABCD during assembly. . I want to know how best to identify a duplicate Transaction Code during Assembly of the Table. . Any suggestions - sample conditional assembly code would be best . Paul D'Angelo * * *
Re: Two string instruction questions
Hi Peter, Partially right In a VSAM file (KSDS only I think) you can request the Index to have compressed keys Only worth while if the keys were large (max length is 127 bytes) The Index entry would be compared to the previous and both the beginning and ending key bytes would be compared and whatever was the same got a length instead of the bytes, the final index entry looks horrible, but it saved valuable disk space back in the time when dinosaurs (like me) ruled the Earth :-) The RBA would not have been there for a KSDS Have I got the very last "VSAM Logic" Manual on the planet ? Melvyn Maltz - Original Message - From: "Farley, Peter x23353" To: Sent: Wednesday, March 14, 2018 10:18 PM Subject: Re: Two string instruction questions I think I read somewhere that is what keyed VSAM Index records are, aren't they? A count of equal key bytes and then the remaining non-equal bytes, followed by the RBA in the data component? Or is that a fib I was told? Peter -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Charles Mills Sent: Wednesday, March 14, 2018 5:49 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Two string instruction questions That's interesting. Thanks! I did think of what CUSE would be perfect for: what I know as "vertical compression" but Google does not seem to know the term. Think of standard run length compression as "horizontal." Picture something like that, but where a code indicates "the next 'n' bytes of this record are identical to the bytes in the same position in the previous record." Only works for sequential files, because you need the previous record to decode this records. But works well where there are a lot of repeating fields. -- 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: Posting
Thanks to Ed and Dave But did you get the original posting...you didn't say If you thought it too trivial/irrelevant to respond to...that's fine But if you didn't get it, that's not fine Melvyn. - Original Message - From: "Ed Jaffe" To: Sent: Thursday, December 14, 2017 8:05 PM Subject: Re: Posting On 12/14/2017 12:03 PM, MELVYN MALTZ wrote: Did you receive the original post ? If not...why ? Irrelevant. Every spam filter is unique. Your experience with your particular spam filter is unique to you on no one else... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/
Re: Posting
Hi Tom, Thanks for the response Yes, whatever I have set, I get everyone's posting including my own When I posted the original "HLASM RFE revisited" I was surprised when I didn't receive the posting sent back to me and also that no-one had responded I found that my Email client had rejected it as Spam and refused to send it on to me However, the post "Posting" you picked up on did come back to me Did you receive the original post ? If not...why ? Melvyn. - Original Message - From: "Tom Marchant" <00a69b48f3bb-dmarc-requ...@listserv.uga.edu> To: Sent: Thursday, December 14, 2017 5:23 PM Subject: Re: Posting On Wed, 13 Dec 2017 17:26:51 -0500, Melvyn Maltz wrote: For some reason my recent posting is going into Spam or (in my case) being rejected as Spam before I get it If I understand correctly, you are saying that you have REPRO set, so that you receive your own postings, and that when your post was sent to you it went to your spam folder. Is that correct? If so, the problem would seem to be in your email client. -- Tom Marchant
Posting
For some reason my recent posting is going into Spam or (in my case) being rejected as Spam before I get it It isn't Spam and is a topic for further discussion The Posting is called: HLASM RFE revisited Posted on: 11th Dec @ 09:36 It can be found on the listserv website Perhaps the moderator would like to comment
Re: Macro Processors
Title: HLASM RFE Revisited Posted on 11th Dec 09:36 - Original Message - From: "Charles Mills" To: Sent: Tuesday, December 12, 2017 12:51 AM Subject: Re: Macro Processors You want to give us a hint? Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of MELVYN MALTZ Sent: Monday, December 11, 2017 4:00 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Macro Processors Sorry Charles, I wasn't precise The post is there, but the return of my post went into my Spam folder, which it hasn't done before For those (I think most) who receive all posts and replies it may not have hit your Inbox
Re: Macro Processors
Sorry Charles, I wasn't precise The post is there, but the return of my post went into my Spam folder, which it hasn't done before For those (I think most) who receive all posts and replies it may not have hit your Inbox Something odd happened Melvyn. - Original Message - From: "Charles Mills" To: Sent: Monday, December 11, 2017 11:50 PM Subject: Re: Macro Processors Who is us guys and if it bounced, how would we respond? Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of MELVYN MALTZ Sent: Monday, December 11, 2017 2:50 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Macro Processors I might point out that zcobol (part of z390) was a translation of COBOL syntax which was then converted to Assembler by a large set of macros...thankyou Don Higgins
Re: Macro Processors
I might point out that zcobol (part of z390) was a translation of COBOL syntax which was then converted to Assembler by a large set of macros...thankyou Don Higgins And while I'm here, I posted "HLASM RFE revisited", but the bounce back went into my Spam folder...it isn't and I would appreciate you guys finding it and responding Melvyn Maltz. - Original Message - From: "Charles Mills" To: Sent: Monday, December 11, 2017 10:16 PM Subject: Re: Macro Processors I get your point. The assembler macro facility is more like a facility for writing extensions to the assembler than it is like the C macro preprocessor. That ability to write a macro that is integrated in its processing with the main passes of the assembler -- yes, that is very cool. In C I can write a macro FOO(bar) that expands out into C code -- shorthand, in other words. But an assembler macro has the ability to be more like an extension of the assembler itself, not simply a shorthand for some more wordy assembler instructions. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of John Ehrman Sent: Monday, December 11, 2017 12:19 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Macro Processors Charles Mills noted... Date: Sat, 9 Dec 2017 17:58:15 -0800 From: Charles Mills PL/I has a very powerful "macro" (preprocessor, I think they call it) facility. I don't know it well at all, but in my impression it is more powerful than either assembler or C macros. I agree that PL/I's macro preprocessor is indeed powerful; but it and all other macro facilities I know of lack a key feature of HLASM's conditional assembly and macro facility: an intimate interaction between the base language and the macro language. While the
HLASM RFE revisited
To remind folks what I was proposing... 1) More flexibility in defining 2 and 4-byte immediate values 2) Arithmetic values reported as out-of-range, but seemed ok 3) HLASM output shows some immediates but not others Since my last posting which got favourable support I have been exchanging Emails with Jonathan Scott This has proved useful as I now have a better understanding of how HLASM actually works I don't entirely agree that it should work that way, but I would like to throw both opinions back to the community to see what the general view is Jonathan has allowed me to quote from our private Emails provided I don't misrepresent his views, and I will be vigilant not to do so The symbols >>JS<< and >>MM<< are used to differentiate opinions >>JS<< Every assembler expression is evaluated in a way which is completely unrelated to its context, currently as a 31-bit signed expression For an immediate operand, the expression value is then assigned to the instruction field, preserving the numerical interpretation of that value according to whether the field is signed or unsigned >>MM<< This does explain the curiosity of LH 1,=X'' being valid and LHI 1,X'' being invalid. The LHI immediate will generate a binary value of 65535 which is outside the range for the operand. If the immediate were valid it would still comply with the PoOP "The second operand is sign extended..." Similarly, LHI 1,2X'FF isn't valid because strictly speaking the immediate operand is not a single binary value >>JS<< And 2X'FF' would still be an invalid value for LHI regardless of notation There might be a partial solution... >>JS<< All I can say for now is that we are hoping to make checking more consistent in the future by introducing a truncation check option while at the same time providing an option to tolerate use of unsigned values in signed fields and vice versa >>MM<< I guess we aren't going to get a true DC-type expression for 2 or 4-byte immediates unless the feeling is strong enough One last point, as I don't work for an IBM customer I have no access to the formal method of submitting an RFE. If the general feeling here is that one should be submitted may I ask for someone to do this on my behalf Melvyn Maltz.
Re: z14 PoO Available - VFLL instruction
And wouldn't it be great if it was called z390 and available on a website called www.z390.org and if just a few Java programmers could be bothered to spend a few hours achieving just that as Don, Melvyn, Abe and several others tried to do over the past years...doh. And while I'm on the subject, does anyone remember that a few months ago I wanted the PoOPS ripped apart and reconstructed so that every single instruction had a page to itself with links ? My suggestion got trashed...I still can't believe that the guys and gals here have so little imagination. 53 years of assembler coding and still no-one listens to me. And just to annoy people even more, enhancing the IBM360 architecture is like redesigning the T-Rex...it's already extinct guys...time to move on. Melvyn Maltz. - Original Message - From: "Gary Weinhold" To: Sent: Sunday, September 24, 2017 11:59 PM Subject: Re: z14 PoO Available - VFLL instruction But wouldn't be great if the PoO could just be fed into a software emulator creator (in machine-readable format, of course) and out would come a software emulator. And the another process could create all the chips and microcode. That way the PoO would always exactly match the processor. Gary Weinhold From: a...@bixoft.nl Sent: September 24, 2017 3:01 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Reply to: a...@bixoft.nl Subject: Re: z14 PoO Available - VFLL instruction All, In the new PoO, on page 24-26, Programming Note for VFLL instruction, there is what seems to be another copy-paste error. I quote: *Programming Note*: If a trapping IEEE exception is encountered during execution of VECTOR LOAD LENGTHENED it is model dependent if the VIX in the VXC field is the index of the source or target element unless the IBM z/Architecture Principles of Operation is installed in which case it is always the index of the source element. Beats me how the PoO could be installed in the processor, but maybe I'm taking things too literally? Can it be it should have referred to the vector-enhancement facility 1 ? Kind regards, Abe Kornelis == Op 15-9-2017 om 8:07 schreef Dan Greiner: The IBM z14 processor is generally available today (14 September 2017). The z/Architecture Principles of Operation corresponding to the new z14 processor is available at http://publibfp.dhe.ibm.com/epubs/pdf/dz9zr011.pdf The z/Architecture Reference Summary corresponding to the new z14 processor is available at http://publibfp.dhe.ibm.com/epubs/pdf/dz9zs009.pdf Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone: +1.613.523.5500 x216 Email: weinh...@dkl.com<mailto:weinh...@dkl.com> [http://www.dkl.com/wp-content/uploads/2015/07/dkl_logo.png]<http://www.dkl.com/> Visit us online at www.DKL.com<http://www.dkl.com/> [http://www.dkl.com/wp-content/uploads/2015/08/banner.png]<http://www.dkl.com/mailsig> 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.
Re: random quest
Hi Richard, Paul is right, we came up with the same solution There are several statistical tests for randomness, perhaps the easiest to calculate is MSSD (mean squared successive differences) and you are on the right track You can attach my name Melvyn. - Original Message - From: "Richard Kuebbing" To: Sent: Tuesday, May 16, 2017 11:46 PM Subject: Re: random quest Fantastic. This looks to be the level of brilliance I was looking for - simplicity plus 100% solution. So follow-up question. I have a lot of advanced math in grad school, all inapplicable to this. Is there any kind of measure of how "random" a set of numbers is? Someone internal is bound to ask. I am thinking of graphing the difference [=n(i+1)-n(i)] and looking at distribution. The client(s) are business persons and are unlikely to ask. Question 2: I have a passion for documenting things. Do you wish to have your name attached to this idea? Tomorrow when I have time I will peruse all the answers. Profound thanks Peace be w/y'all -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Farley, Peter x23353 Sent: Tuesday, May 16, 2017 4:51 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: random quest 1. Use either CEERAN0 or FUNCTION RANDOM to generate a column of 99,999 random numbers. It's OK if there are duplicates. 2. Add a second column using SORT with sequential numbers from 1 to 9 (use the SEQNUM option). 3. SORT by the first column only and DO NOT specify the EQUALS option. 4. Use the numbers in column 2 after sorting as your 99,999 randomly ordered numbers You can combine steps 2, 3, and 4 in one SORT execution. INREC to add the SEQNUM's as a second column, SORT by first column, OUTREC to select only the second column for output. HTH Peter -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Richard Kuebbing Sent: Tuesday, May 16, 2017 4:28 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: random quest So I need a set of 99,999 random numbers which are 5 digits and unique, i.e. no duplicates. CEERAN0 and Cobol FUNCTION RANDOM both give sets w/30+% duplicates. I have seen website random.org. Anyone have to ever done this thing? Anyone have suggestions? -- 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. - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you
Re: random quest
Hi Richard, I'll assume you'll want the five digit numbers in a random order 1) Have a look at the PPNO instruction 2) This technique will work, it might depend on whether you want to do this multiple times or just once I'll assume you have a random number generator (rng), someone will have one if you don't a) Build a table of numbers 1-9 b) Use the rng to select a number from 1-9, mark that entry as used and collect it c) Use the rng again with range 1-8, select the nth unused and collect it d) Repeat c and d dropping the range by one each time until you have none left Regards, Melvyn Maltz. - Original Message - From: "Richard Kuebbing" To: Sent: Tuesday, May 16, 2017 9:28 PM Subject: random quest So I need a set of 99,999 random numbers which are 5 digits and unique, i.e. no duplicates. CEERAN0 and Cobol FUNCTION RANDOM both give sets w/30+% duplicates. I have seen website random.org. Anyone have to ever done this thing? Anyone have suggestions? Richard Kuebbing Efforts and courage are not enough without purpose and direction. - John F. Kennedy Fasten your seat belts, it's going to be a bumpy ride. - Bette Davis (as character Margo Channing) _All About Eve_1950 Furious activity is no substitute for understanding. - H. H. Williams Our greatest danger in life is in permitting the urgent things to crowd out the important. - Charles E. Hummel Quidquid latine dictum sit, altum videtur. - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you
Re: Quick error termination of an assembler routine (Was: Performance of Decimal Floating Point Instruction)
>>> I've never seen one, that I can remember, occur when executing data Way back when, I discovered this code in an IGZ (COBOL module) BALR 14,15 DC CL6'PATCH' etc. According to IBM a return wasn't possible (it did), the DC is a nasty XC This was done inside CICS and did sufficent damage to cause the CICS region to crash I raised an APAR Melvyn Maltz. - Original Message - From: "Steve Thompson" To: Sent: Friday, May 12, 2017 3:07 AM Subject: Re: Quick error termination of an assembler routine (Was: Performance of Decimal Floating Point Instruction) > Has anyone ever seen S0C3 (PIC 3) as an accident? > > I use EX 0,* to trigger a failure. I've never seen one, that I > can remember, occur when executing data (such as happens when one > takes a wild branch). > > Just thought I'd ask while you all are kind of on the subject. > > Regards, > Steve.T
Re: HLASM "Anomaly"
To: Peter Relson If you were a brickie building a wall would you NOT want to be told that you were using inferior mortar ? Much the same with our building blocks...these items are inferior and I would not want them in any build of mine...if the programmer doesn't know about them, one day the wall will come tumbling down. If these were coded intentionally, I would suggest a better way LHI 1,X'' DC Y(X'') and this is in error DC Y(65535) No, I don't want a different rule set, I want the current one to serve the Assembler community better than it does at present Melvyn Maltz. - Original Message - From: "Peter Relson" To: Sent: Saturday, March 25, 2017 8:30 PM Subject: Re: HLASM "Anomaly" Regarding the lengthy discussion of immediate operands and whether there should be warnings or errors, I will point out that there is next to zero chance that the assembler will unconditionally change its rules in this regard, as that could cause currently working JCL to fail (I'm with Charles Mills in thinking that a warning in many cases is wishy-washy as there are very few cases where a warning on an assembly should be accepted by a build process, unless you like looking manually at the listing every time to make sure that your expected warning is the only one that you're getting). If you want a different rule set, then you need to ask for an option by which you can request a new rule set (and of course to have that new rule set implemented, and that new option will not be the default). We often choose to live with the poor decisions that we might have made on initial implementation because compatibility is a huge strength of our platform. A "good" example is the default of STORAGE OBTAIN to be "obtain the storage in key 0" for a subpool that has multiple keys. That is an awful default. The implementers did not realize that a "PC" in this case was closer to the "SVC" GETMAIN than to the key-zero-required branch-entry GETMAIN. Once it was "out there" it was too late to change. A discussion about what would be a good alternate rule set is welcome. Do so. And submit a requirement for it. But griping about the existing rules just for the sake of griping is not productive. Peter Relson z/OS Core Technology Design
Re: HLASM "Anomaly"
Hi Steves, and Paul, Ok, I don't want this argument to get circular Why not just specify -1 As in: CLI HERE,-1 CLFI 1,-1 Ok, much easier to code CLFI 1,4X'FF' Yes...I know why or why not I have enough support for an RFE to be created, this will probably go to a vote in the UK and then be submitted to IBM. It will be up to IBM to judge the cost/benefit factors Let me restate, whatever form the final RFE takes it will not affect current code, though it may produce warning messages not previous produced, eg. for LHI 1,X'' which has aleady been discussed to death Melvyn Maltz. - Original Message - From: "Steve Smith" To: Sent: Tuesday, March 21, 2017 2:18 AM Subject: Re: HLASM "Anomaly" On 3/20/2017 20:58, Paul Gilmartin wrote: Please don't reply with "Subject:...Digest..." Sorry... I wish I remembered to do that, but I usually don't. On 2017-03-20, at 17:45, Steve Smith wrote: Two's-complement is an amazingly great way for binary computers to store negative numbers. It is not so great for humans to read or write. First of all, you have to know where the sign bit is, and X expressions are ambiguous. If you watch carefully, you'll see that HLASM (almost) always left-fills to 32 bits (with 0s), so if you intend to specify -1, then you must write X''. Why not just write -1? I would. You could. This was for those who really, really, want to pound the square peg into the round hole. It would have been nice if different conventions were chosen back in the dark ages, instead of conflating X strings with hex numbers. But it isn't nice, and you might as well learn how it works, and learn to live with it. The consequences of that have pervaded this thread. Sure, and there's value in discussing them. But for generating RFEs and requirements, it's appropriate (it's necessary) to consider the costs as well as the benefits. My take (and implication) is that the costs vastly outweigh the benefits. -- gil sas
Re: HLASM "Anomaly"
To: Abe and Paul, Abe is quite right, when I started this thread I didn't realise just how many "anomalies" would pop out of the woodwork LHI 1,X'' LHI 1,X'12345678' Yes, you get a warning about the 2nd but not the 1st As Abe said, I would also be drawn to the Programmer's intent, did they mean to code LGFI ? Melvyn. - Original Message - From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> To: Sent: Saturday, March 18, 2017 10:21 PM Subject: Re: HLASM "Anomaly" On 2017-03-18, at 15:41, MELVYN MALTZ wrote: A fine example is LHI 1,H2 and the next Both of these assemble without error or warning (that's a big disagree) Don't you believe -1 is a valid expression to LHI? Or don't you believe X'' is -1? Remember, expressions are typeless. Would you change that? How? That requires a lot of wise design. What types should exist? What types should be allowed to be combined with what operators? Too much of HLASM came about because someone thought some construct worked the way he expected and twisted an account rep's arm to make it so, and didn't care about the chaos this added to the specification. Compare this with LHI 1,H5 and the next which generate a warning (do we need the warning ?) Yes, since X'' is 65535, and not in the halfword range, -32768 to +32767. - Original Message - From: "Paul Gilmartin" Sent: Saturday, March 18, 2017 2:10 PM Subject: Re: HLASM "Anomaly" For which of these intructions do you agree/disagree with HLASM's behavior: ... H2 EQU X'' LHI 1,H2 LHI 1,X'' DCY(H2) DCY(X'') ... H5 EQU X'' LHI 1,H5 LHI 1,0+X'' DCY(H5) DCY(X'') -- gil
Re: HLASM "Anomaly"
Hi Paul, For which of these instructions do you agree/disagree with HLASM's behavior: It's a good set, even better than mine :-) The most important thing is "does the coding method make it more readable or understandable within the context of the surrounding code ?" If yes, all valid things must be allowed Also remember that some of these parameters may be generated from macro variables To get specific: I can only use the DeZhi mainframe which uses HLASM V5...apologies if V6 differs A fine example is LHI 1,H2 and the next Both of these assemble without error or warning (that's a big disagree) Compare this with LHI 1,H5 and the next which generate a warning (do we need the warning ?) I used to present students with DC X'5C'. What is it ? Is it binary 92, or +5 in decimal, or an asterisk ? Interesting that all of your code, despite E and W messages assemble correctly, except the last LHI which has the invalid 2AL1...doh Melvyn Maltz. - Original Message - From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> To: Sent: Saturday, March 18, 2017 2:10 PM Subject: Re: HLASM "Anomaly" On 2017-03-17, at 17:40, MELVYN MALTZ wrote: A pity our Emails crossed, with regards to the 2X'FF issue please read my latest post As for the Scon...I agree with you, you must submit a bug report for that one For which of these intructions do you agree/disagree with HLASM's behavior: START H1 EQU -1 LHI 1,H1 LHI 1,-1 DCY(H1) DCY(-1) H2 EQU X'' LHI 1,H2 LHI 1,X'' DCY(H2) DCY(X'') H3 EQU X'' LHI 1,H3 LHI 1,0+X'' DCY(H3) DCY(X'') H4 EQU 65535 LHI 1,H4 LHI 1,65535 DCY(H4) DCY(65535) DCH'65535' H5 EQU X'' LHI 1,H5 LHI 1,0+X'' DCY(H5) DCY(X'') TABLEDC2AL1(*-TABLE) LHI 1,2AL1(*-TABLE) END As I said earlier, I place considerable value on simplicity and uniformity of syntax rules. I believe HLASM meets my expectations well here. As I also said, I'd welcome additional operators for forming expressions: AND, OR, XOR, SLL, SLA, SRL, SRA, LT, LE, EQ, NE, GE, and GT. And 64-bit arithmetic. I'd not like to see distinct 32-bit and 64-bit exprssion types, Rather, all expressions should have 64-bit values. But a switch to allow compatibility with existing ASMADATA format. -- gil
Re: HLASM "Anomaly"
Hi Paul, A pity our Emails crossed, with regards to the 2X'FF issue please read my latest post As for the Scon...I agree with you, you must submit a bug report for that one Regards, Melvyn. - Original Message - From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> To: Sent: Friday, March 17, 2017 11:15 PM Subject: Re: HLASM "Anomaly" On 2017-03-17, at 04:44, Martin Ward wrote: Given that 2X'FF' generates the same two bytes as X'', there is no reason why we should not be allowed to replace the latter by the former. I tend more to be value-oriented. The operand of MVHHI is an expression, and it is prudently restricted to the range, [-32768,32767], even as a Y-constant is. Expressions can be EQUated. What should be the meaning of: XEQU 2X'FF' If the value is 65535, that's outside the halfword range and MVHHI A,X should fail, as should DCY(X) Don't make too many exceptions to too many rules. One exception I'd like to see removed is, given addressability, LAR1,=D'3.14' works OK, while DCS(=D'3.14') fails. Why should a base-displacement be resolvable in an instruction, but not in an S-constant? The same code should be used and work for both. -- gil
Re: HLASM Anomaly
Hi Martin and Tom, and all others who have contributed My thanks to Martin for his support To Tom...this thread originated when I tried to code LLIHF R5,4C'I' and then later CIH R5,4C'I' When it failed to assemble in z390 I turned to DeZhi and it failed there too Is that code good, bad or ugly ? >>>I work as an assembler programmer...can't remember a time...needed to code >>>an immediate operand >>>that could have been specified that way if it were >>>possible Welcome to the world of logical 32-bit immediates I used to sniff at labelled USINGs, there was always another way...I wouldn't do without them now After 52 years of IBM Assembler programming I still have things to learn :-) And now... I was inspired by John Ehrman's comment... >>>constructs like BALR 2FL.41'7',3BL.4'101' -- I guess we never thought of >>>documenting that restriction because we >>>never thought someone would try >>>it! Until now ! Also John Dravnieks expertise... >>>internally the assembler has an expression processor for instruction >>>operands, and it has another one for DC operands - >>>why it is this way I >>>do not know >>>expecting the DC type processing to be done for the instruction operands, >>>and getting confused/annoyed/bewildered >>>that it does not work that way Actually, although my initial remit just concerned immediates, I think there might be a justification for a single expression processor for both DC and instruction operands. This may make HLASM a little more efficient and easier to maintain than at present. John can have his bit-length operands and I can have my 4C'I' immediate and no-one will ever be confused/annoyed/bewildered ever again :-) None of the rules below would affect the assembly of any existing program Rule 1...All current DC expressions remain the same...of course Rule 2...All DC-type expressions can be used in instruction operands as well as arithmetic expressions Only the rightmost bits of the result will be used according to the operand length If the result is larger than required for the operand (in value), a warning is issued If the result is smaller than required, it is padded left with zero-bits Rule 3...I would prefer that warnings about arithmetic values being out-of-range were removed Which of these are not readable ? a) CFI 1,4X'FF' b) CLFI 1,-1 Neither are currently valid Rule 4...Yeh, John D's comment about J 10, well we still do B *+10 It's 10 halfwords I've also noticed that the HLASM output listing is very inconsistent about immediate operands, when I've done further research I'll include it in my RFE Melvyn Maltz. - Original Message - From: "Tom Marchant" <00a69b48f3bb-dmarc-requ...@listserv.uga.edu> To: Sent: Friday, March 17, 2017 9:08 PM Subject: Re: HLASM "Anomaly" On Fri, 17 Mar 2017 10:44:41 +, Martin Ward wrote: >Given that 2X'FF' generates the same two bytes as X'', >there is no reason why we should not be allowed to replace >the latter by the former [in an immediate expression]. Maybe so, but I don't see it as a significant limitation. Certainly not one that is worth the effort of making HLASM behave the way you think it "should". I work as an assembler programmer and I can't remember a time when I needed to code an immediate operand that could have been specified that way if it were possible. -- Tom Marchant
HLASM anomaly
To restate what I'm asking for... Now that we have 2 and 4-byte immediate values it would make sense to allow both duplication factor and explicit length for these Currently the instructions below would fail AHI 1,2X'FF' CFI 1,XL4'FF' Rather more contentious, I agree, is to imply an explicit length of 1, 2, or 4 bytes to any immediate if there were no dup/explicit already present So, CFI 1,C'9' generates X'00F9' (yuk) But if it were forced to have an explicit length it would be interpreted as CL4'9'=X'F9404040' which is what you might expect ??? Ok, I'll be shot down on that one, but I'll still submit it Steve Thomas---What does "immediate" mean to you ? It means a DC-type constant of any form that is only constrained by the length of the immediate according to the instruction Paul Gilmartin---How do you feel about AHI 1,X'00' It exceeds the 2 byte limit and therefore invalid If the explicit length were to be implemented, then it would operate as XL2'00'=X'' Yes, AHI 1,65535 is valid In z390, AHI 1,X'00' is valid In DeZhi, it generates but gives a warning Yes, it's an HLASM problem, some immediates are logical, some are algebraic, it doesn't really matter how the immediate is generated provided you get the result you intended John Ehrman---Immediates are not absolute Sorry to disagree, 2X'FF' is just as absolute as X'' I've always considered the result as definitive, not how we got there >>>consider AHI 0,(N)X'F' By that stage in the Assembly, it would be known (I hope) that AHI takes a 2-byte immediate, if the parsing of the DC-type immediate exceeded that, it's an error...no acrobatics needed Chris Smith---Limits ot 16-bit signed...why examples of unsigned Immediates can be logical or algebraic, compare CFI with CLFI CLFI 1,-1 is a contradiction, but works ! John Dravnieks--- Read above stuff, AHI 1,X'' does assemble with a warning Charles Mills--- Sorry, but an immediate operand is a unit of storage, the fact that it's embedded into an instruction is irrelevant I'm sure they'll be more flak flying, but I'll wait a few days for the smoke to clear before I annoy Sharuff :-) Mel.
HLASM anomaly
Immediate operands won't accept a duplication factor...why not ? Can't find a reason in the HLASM manual Try these... CFI R1,4X'FF' CFI R1,X'' CFI R1,-1 AHI R1,2X'FF' AHI R1,X'' AHI R1,-1 Melvyn Maltz
Re: 360/20 instructions
You might also like to know of an undocumented instruction specific to the 360/20. This was a form of the Diagnose (opcode X'83') which allowed me to read the hex dials on the console into storage. This was extremely useful as I had the job of converting 1401 Autocoder into 360/20 Assembler and this instruction enabled me to replace the sense switches. On later machines under DOS I used the UPSI card. Forgive me, but it's 50 years since I coded one of those and I can't remember the operand, but I'm sure someone will.
Re: Redesigning the Principles of Operation Manual
Hi Joey, I think you miss the point. Conciseness is essential. What I am suggesting is that each instruction is concisely defined. Start with ADD in Chapter 7, where 15 instructions are concisely compressed into a meaningless hotchpotch of description. Do you think that a student after reading that section would know what ASI actually did ? Mel. - Original Message - From: "Capps, Joey" To: Sent: Wednesday, November 12, 2014 10:15 PM Subject: Re: Redesigning the Principles of Operation Manual Personally I don't think it's design was to save paper. I think it was to 'be concise'. And that is what I think it needs to be. As for reorganizing it into different chapters, that might be useful. But we cannot afford to have it lose its concise nature. Joey -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Melvyn Maltz Sent: Wednesday, November 12, 2014 4:04 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Redesigning the Principles of Operation Manual One can see why the Principles of Operation manual (PoP) was designed in its present format...to save paper. There is now no need to design this manual in a form that was suitable 30 years ago. Now that I've restarted teaching Assembler I realise that the PoP neither serves the professional learning new instructions or techniques nor the student learning for the first time. The suggestions below have been compiled by myself and contacts and are not in any priority order. I offer these in order to stimulate discussion. I know IBM monitor this forum as I see names that I know. IBM can join in as well. 1) Instruction descriptions Every instruction must be individually described. No more bunching. 2) Two Manuals ---PoP1 describes formats and techniques ---PoP2 describes instructions and examples Hyperlinks to similar instructions and examples. 3) Classification The current classification is inadequate, ie. CVD isn't a decimal instruction...there are many others. If you have to classify, then here is a suggestion... 1) Boolean...AND/OR/XOR 2) BranchBRANCH and PROGRAM 3) Compare...COMPARE and TEST a) Binary b) Floating point c) Decimal 4) Conversion...CONVERT/TRANSLATE/UNPACK/EDIT/PACK a) Character/Binary/Decimal b) Floating point 5) Cryptography...COMPRESSION/CIPHER/PERFORM 6) I/O...CHANNEL 7) Maths a) Binary b) Floating point c) Decimal 8) Move...PAGE/MOVE/LOAD/STORE/INSERT 9) Trace..TRACE 10) Transaction..TRANSACTION 11) Trap...TRAP 12) Others 4) An iPoP app that can display an individual instruction with multiple cross-references for local use. 5) A Web app to do the same, but has the advantage of being international and collective. "People who looked up LG also looked up LLGF" Let the discourse begin.
Redesigning the Principles of Operation Manual
One can see why the Principles of Operation manual (PoP) was designed in its present format...to save paper. There is now no need to design this manual in a form that was suitable 30 years ago. Now that I've restarted teaching Assembler I realise that the PoP neither serves the professional learning new instructions or techniques nor the student learning for the first time. The suggestions below have been compiled by myself and contacts and are not in any priority order. I offer these in order to stimulate discussion. I know IBM monitor this forum as I see names that I know. IBM can join in as well. 1) Instruction descriptions Every instruction must be individually described. No more bunching. 2) Two Manuals ---PoP1 describes formats and techniques ---PoP2 describes instructions and examples Hyperlinks to similar instructions and examples. 3) Classification The current classification is inadequate, ie. CVD isn't a decimal instruction...there are many others. If you have to classify, then here is a suggestion... 1) Boolean...AND/OR/XOR 2) BranchBRANCH and PROGRAM 3) Compare...COMPARE and TEST a) Binary b) Floating point c) Decimal 4) Conversion...CONVERT/TRANSLATE/UNPACK/EDIT/PACK a) Character/Binary/Decimal b) Floating point 5) Cryptography...COMPRESSION/CIPHER/PERFORM 6) I/O...CHANNEL 7) Maths a) Binary b) Floating point c) Decimal 8) Move...PAGE/MOVE/LOAD/STORE/INSERT 9) Trace..TRACE 10) Transaction..TRANSACTION 11) Trap...TRAP 12) Others 4) An iPoP app that can display an individual instruction with multiple cross-references for local use. 5) A Web app to do the same, but has the advantage of being international and collective. "People who looked up LG also looked up LLGF" Let the discourse begin.
