Question on HLASM - B to a DROP statement!?!
Yes the subject is correct. I just ran into this situation. Program is in production. Multiple points in this program do the following: B DROPR11 Now, a few screens away we have this: DROPR11 DROP R11 LA R1,x (or something similar) The DROPR11 above gets flagged with an invalid label The various B DROPR11 statements resolve to the LA R1 Anyone see a problem with this? When did this kind of thing get accepted? I would have figured that invalid label would have gotten at least an RC=8 And every one of those "Branch" instructions would have been flagged for an undefined label or some such. An inquiring mind would like to know. Regards, Steve Thompson
Re: Q: Finalist
Forgot to mention I have this cross-posted with IBM Main. The issue is, the program(s) invoking Finalist are written in ALC. We are getting to modernize all the ALC code (yes, we are keeping much of it). On 7/26/2024 3:23 PM, Paul Gilmartin wrote: On 7/26/24 12:49, Steve Thompson wrote: Hi all: I am looking for someone that is using Finalist (zipcode USPS addressing tool). I'd like to ask some dumb questions about it. I know it doesn't work with Java under z/OS... Yeah, a modernization thing. Do you mean that Java under z/OS is outdated? Should it be upgraded? (Is this question assembler-specific would it better be asked on IBM-Main?)
Q: Finalist
Hi all: I am looking for someone that is using Finalist (zipcode USPS addressing tool). I'd like to ask some dumb questions about it. I know it doesn't work with Java under z/OS... Yeah, a modernization thing. -- Regards, Steve Thompson
Re: Subpool 0 Usage
Here is what the article says:
"Got sensitive data? Then use fetch protection!" And then talks
about fetch protection, etc.
Then on the other side of the page:
"TIP : Do NOT use subpool 0 for anything
if possible – even in unauthorized code.
Don’t be in the bucket with the world and its wife
Hard to locate storage leaks"
A little knowledge can be dangerous with someone that does not
understand the knowledge.
Regards,
Steve Thompson
On 7/11/2024 9:10 PM, Michael Watkins wrote:
I think the actual document cautions against using key 0, not subpool 0.
But maybe I'm looking at the wrong GSE document from 2019 ('Secure Engineering:
How to develop authorized code without compromising z/OS system integrity' by
Rob Scott, Rocket Software).
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Seymour J Metz
Sent: Thursday, July 11, 2024 7:48 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Subpool 0 Usage
CAUTION: This email originated from outside of the Texas Comptroller's email
system.
DO NOT click links or open attachments unless you expect them from the sender
and know the content is safe.
Well, SP0 is shared by default. Then there's that whole business of converting
SP0 to SP252.
Of course, it depends on the context. Authorized? Subtasks? Multi-user?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
From: IBM Mainframe Assembler List on behalf of
Janko Kalinic
Sent: Thursday, July 11, 2024 3:14 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Subpool 0 Usage
I just read that you should NOT use Subpool 0 for anything if possible.
Thoughts?
Regards,
John K
Re: Does the GET macro indicate EOF?
zXDC? It allows one to step through code Just say 'n'. Steve Thompson On 5/8/2024 10:17 PM, David Eisenberg wrote: Peter, Yes... I'm using ASMIDF. I can definitely set a manual breakpoint on the EOF label, and the breakpoint will be honored... but that's not my problem. The issue pertains to single-stepping; in my case, using IDF's STMTSTEP command. The code doing the GET resides in an external subroutine that is called by multiple applications. Suppose the developer is using ASMIDF, and is single-stepping through his/her application program, and reaches a call to that subroutine. The developer issues a STMTSTEP command, and quite reasonably should expect to get control back immediately after the call, but that doesn't happen. That's because the developer has no idea that he/she needs to set a breakpoint on an EODAD address inside the external subroutine being called. ASMIDF itself doesn't set the breakpoint on the EODAD address during single-stepping. So when the EODAD is reached, ASMIDF simply plows through execution with no breakpoint set, and the developer never gets control back until the program terminates. Hence my original question. The whole problem goes away if the EODAD address immediately follows the GET (as in my original code snippet) because ASMIDF does set an automatic temporary breakpoint on that address when single-stepping. But that solution requires my being able to determine whether I reached the EODAD address because I *fell into it* (after a successful GET), or because it was *branched to* as a result of reaching the EOF. That's why I'm hoping that the GET macro sets something I can test, or perhaps there's something in the DCB I can examine. I just need to know whether the GET read a record, or whether it hit the EOF. That would solve the ASMIDF single-stepping problem entirely. I hope this makes sense! David
Re: ASMA043E Previously defined symbol
One place I worked long ago used BAD: Broken as Designed. Steve Thompson On 5/1/2024 1:25 PM, Steve Smith wrote: Ease of bizarre inscrutable errors is not the same as ease of use. Just sayin' ;-) WAD just means it was a bad design. sas On Wed, May 1, 2024 at 7:00 PM Phil Smith III wrote: Paul Gilmartin wrote, re Rexx being fine with duplicate labels: That's bad. That's WAD. Remember, the goal of Rexx was ease of use. Just sayin'.
Re: ASMA043E Previously defined symbol
I suggest you show us a snippet of code so we can see how you are re-defining a variable/symbol. Steve Thompson On 4/30/2024 5:55 PM, João Reginato wrote: Hi The message “ASMA043E Previously defined Symbol” is always issued when an already defined field is redefined, even if it is not referenced, making the compiler end with error (return code 8). I see this situation as it was just a warning issue (with return code 4). Is there a reason for this behavior? TIA João
TEST of updated Email server security Config
This is a test of email after changing "security" settings of my email domain. Just ignore this please. -- Regards, Steve Thompson
Re: Don Higgins has retired from z390 development again
Amen!! Enjoy your retirement. Steve Thompson On 3/5/2024 4:47 PM, David Kreuter wrote: All the best and two beautiful words: “clear scan” David From: IBM Mainframe Assembler List on behalf of Ecbyahoo <086a7e5ec0f7-dmarc-requ...@listserv.uga.edu> Sent: Tuesday, March 5, 2024 4:16:29 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Don Higgins has retired from z390 development again Don, That is great news about the clear scans and I hope you have a wonderful and relaxing retirement with your wife! E.Clay "The best of all is, God is with us." John Wesley On Mar 5, 2024, at 12:45 PM, Don Higgins wrote: All I have retired again from z390 development after having survived esophageal cancer, kidney cancer, and thyroid cancer over the past 2 years. All my scans are now clear of cancer, and I feel well again. So at 79 I'm planning to spend more time with my wife Charlotte traveling and relaxing. I will miss working with the current z390 core development team: Abe Kornelis, John Ganci, and Anthony Delosa, and hope they will continue on. I also miss working with Melvyn Maltz and John Ehrman who supported z390. Melvyn developed the z390 CICS emulation, and John invited me to present z390 at several SHARE sessions. For those interested in learning more about z390, the current development site is here: https://github.com/z390development/z390 The original website I maintained from 2004 until 2012 when I turned it over to Abe is here: https://z390.org/ All z390 code is written in J2SE Java and is open source. The purpose of z390 is to help those interested in learning, developing, and executing mainframe assembler programs on Windows and Linux. Don Higgins d...@higgins.net <mailto:d...@higgins.net> www.donhiggins.org<http://www.donhiggins.org> <http://www.donhiggins.org> -- Regards, Steve Thompson
Re: Linkage Editor Include Order
Thanks for this thread. I knew there was a way to do this, but not having touched VSE since 2005 or so... Does VSE still use a CIL (Core Image Library)? Or is everything relocatable now? Steve Thompson On 12/4/2023 3:05 PM, Dave Clark wrote: "IBM Mainframe Assembler List" wrote on 12/04/2023 02:16:08 PM: Is it possible to influence the order the linkage editor includes objects? I found an answer that works for z/VSE. After cataloging the main object for my load module, I use the following linkage editor statements to specify the order I want for my included objects and the linkage editor honors this specified order. // LIBDEF PHASE,CATALOG=DAP.PROD,TEMP // OPTION CATAL PHASE RXVSAMIO,* INCLUDE RXVSAMIO INCLUDE RXVSAMBK INCLUDE RXVSAMBR INCLUDE RXVSAMXA INCLUDE RXVSAMXR INCLUDE DTEMAN INCLUDE IEANTCR INCLUDE IEANTRT // EXEC PGM=LNKEDT,SIZE=128K /* EOD CSECT/LOADED RELOC. PARTIT. PHASE TAKEN AMODE/RMODE ENTRY AT FACTOR OFFSET OFFSET FROM - RXVSAMIO 500078 500078 507D05 24 24 - RXVSAMIO 500078 500078 00 00 RXVSAMIO 24 24 RXVSAMBK 502E78 502E78 002E00 002E00 RXVSAMBK 24 24 RXVSAMBR 504078 504078 004000 004000 RXVSAMBR 24 24 RXVSAMXA 505378 505378 005300 005300 RXVSAMXA 24 24 RXVSAMXR 506778 506778 006700 006700 RXVSAMXR 24 24 DTEMAN507678 507678 007600 007600 DTEMAN31 ANY IEANTCR 507C78 507C78 007C00 007C00 IEANTCR 31 ANY IEANTRT 507CC0 507CC0 007C48 007C48 IEANTRT 31 ANY Sincerely, Dave Clark
Re: SV: ASMA057E Undefined operation code SR 15,15
I think I see your problem. You have to identify a label variable so that the programmer can put a label on the statement. Then you have to put that label variable as the label for &REST. Thusly: 1 MACRO 2 &LBL ZERO &N 3 &RESTSETC 'SR&N,&N' 4 &LBL &REST 5 MEND Steve Thompson On 11/14/2023 5:22 PM, Willy Jensen wrote: The way I read the error message is that the entire statement 'SR15,15' is read as the op-code. -Oprindelig meddelelse- Fra: IBM Mainframe Assembler List På vegne af Michael Oujesky Sendt: 14. november 2023 23:18 Til: ASSEMBLER-LIST@LISTSERV.UGA.EDU Emne: Re: ASMA057E Undefined operation code SR 15,15 Looks like it is taking 'SR' as a label and '1,15' as an op ode. Michael At 02:28 PM 11/14/2023, João Reginato wrote: hi I can't see the error on this simple code. Can anyone help me pls? TIA João Reginato (+55 61) 9911-55500 Active Usings: None Loc Object CodeAddr1 Addr2 Stmt Source Statement HLASM R6.0 2023/11/14 16.58 1 MACRO 2 ZERO &N 3 &RESTSETC 'SR&N,&N' 4 &REST 5 MEND 6 ZERO 15 7+ SR15,15 01-4 ** ASMA057E Undefined operation code - 4/SR15,15 ** ASMA435I Record 4 in JOAO.QWASM.JOB09574.D101.? on volume: 8 END
Re: Based vs. Relative
To get to relative operations, there is an IBM supplied macro that one can include right at the top of your source and it can be turned on/off as needed. As I recall, it does OPSYN to get rid of based branch (jump) and uses the relative version. I'm sorry, I'm not doing ALC right at this time, so I'd actually have to go look for that macro, but it does exist and I can't remember where it was that I found that and read up on the ramifications. Steve Thompson On 11/9/2023 12:33 PM, Charles Mills wrote: Principles is your friend! I found the transition from based to relative to be relatively (ha ha) painless. You don't have to do it all at once. Just start coding relative jumps now. The existence of base register does not preclude using relative jumps. Then when you get comfortable, comment out the USING and see what happens. I know I can do a relative jump up to 4K, correct The programmer answer is Yes. But in addition to up to 4K, you can actually do up to +/- 65K. There are also even longer ones that will jump anywhere. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Dave Clark Sent: Thursday, November 9, 2023 9:17 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Based vs. Relative (was: Internal Exit Routine Handling) "IBM Mainframe Assembler List" wrote on 11/09/2023 11:27:20 AM: IMHO, relative branch use is a "best practice" in all situations. I *never* use a based branch if an equivalent relative branch will suffice... I've been coding based-branches since 1980 and never moved on to the new stuff. But I recognize that it would be beneficial if I did. So, let me ask a couple of simple questions... Is it, relatively speaking (hehe), "a lot" of effort (or even possible/practical) to do away with a code base register altogether? The first place that I would like to switch to relative jumps is in my structured programming macro sets. But do relative jumps come in more than one flavor? ...like long jumps and "how far"? I know I can do a relative jump up to 4K, correct? Is there a long jump beyond that? And since there can be as much code between the macros in my macro sets as the user determines to put in there, should I use long jumps as opposed to "short" jumps, just-in-case? For example... I have these 4 macros in one of my sets. Internally, I generate labels for THEN, ELSE, and ENDF. These also arbitrarily allow nesting up to 8 levels. IF condition,AND/OR,condition AND condition,AND,condition ... as much code as the user desires between here ... ELSE ... as much code as the user desires between here ... ENDIF Sincerely, Dave Clark
Re: Variable-Length Parameter List Attributes
The "DS" defines storage, but does not init the content. Steve Thompson On 10/18/2023 2:27 PM, Farley, Peter wrote: That’s even more clever than my suggestion! But I would use DS instead of DC. All you really want is the alignment after all, not any actual storage. Peter From: IBM Mainframe Assembler List On Behalf Of Steve Smith Sent: Wednesday, October 18, 2023 2:22 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Variable-Length Parameter List Attributes You can actually set LINKINST=DC,LINKOP=0H if you really like clever. sas On Wed, Oct 18, 2023 at 1:37 PM Ed Jaffe mailto:edja...@phoenixsoftware.com>> wrote: On 10/18/2023 10:14 AM, Farley, Peter wrote: Build the parameter list once using this form: CALL (15),(PARM1,PARM2,PARM2,BLOCK,PARM5),VL,MF=(E,PARMB), X LINKINST=NOPR,LINKOP='0' Nice! I remember when LINKINST was added (and have used it for both BASR and BASSM). Never thought to set it to a NOPR... -- 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: Channel Appendage Routines
Oh yes. Just like with a console typewriter as I recall. It has to send the interrupt to tell you it is ready for you to read. I'm not sure how T-MON does this, but it can write back to the device and keep it updating as I recall. Some of the other monitor products can do the same. I don't think that is what you would want. Steve Thompson On 9/18/2023 5:29 PM, Dave Clark wrote: "IBM Mainframe Assembler List" wrote on 09/18/2023 05:10:51 PM: Forgive me, but I can't remember what a channel appendage is or is for. Could you just give me a quick answer/idea. I used to do CCW stuff but since ECKD, I've only done CCWs for tape (which is now not supported). In my case, I am using a channel appendage routine to synchronize native 3270 I/O. Basically, after writing to the 3270 device, I can't read immediately and must wait for an attention interrupt to tell me when the 3270 device has data to be received. 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. *
Re: Channel Appendage Routines
Yes, it is coming back to me. Back in the day with Wylbur... I had to deal with all of that. And then with Connect:Direct I was doing testing with the cartridge tapes and when the Tape libraries came out, they went scsi and IBM dropped EXCP support for them, so that code is now deprecated since the Cart drives are all EOL/OOS. Steve Thompson On 9/18/2023 5:24 PM, Tony Thigpen wrote: Some of us on VSE-L are working on a program for which the original programmer as passed away. The program runs under VSE and does direct IO to a 3270 device to allow for repairing 'things' that have been messed up, such as the IPL procedures. It includes a small editor. The channel appendage routine is for handling errors from the 3270 which is really a TN3270 session on an OSA-C. Tony Thigpen Seymour J Metz wrote on 9/18/23 5:14 PM: A CE appendage gets control after the channel program and any associated error recovery have completed. In OS/360 it ran disabled, but in MVS it runs as an extension of the EXCP Supervisor; I don't recall what locks are held. From: IBM Mainframe Assembler List on behalf of Steve Thompson Sent: Monday, September 18, 2023 5:10 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Channel Appendage Routines Forgive me, but I can't remember what a channel appendage is or is for. Could you just give me a quick answer/idea. I used to do CCW stuff but since ECKD, I've only done CCWs for tape (which is now not supported). Regards, Steve Thompson On 9/18/2023 4:54 PM, Tony Thigpen wrote: In VSE, yes. Tony Thigpen Dave Clark wrote on 9/18/23 4:36 PM: "IBM Mainframe Assembler List" wrote on 09/18/2023 04:27:49 PM: On the program we are both working on, the use of format-1 CCWs is not needed. In the end, it's one linked together program that is loaded by a // EXEC card, thus it is always loaded in 24bit. So, the only reason for using a format-1 CCW is so that the I/O buffer can reside in 31-bit space? 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. *
Re: Channel Appendage Routines
Thanks. Now I kind of remember what they can do. Steve Thompson On 9/18/2023 5:14 PM, Seymour J Metz wrote: A CE appendage gets control after the channel program and any associated error recovery have completed. In OS/360 it ran disabled, but in MVS it runs as an extension of the EXCP Supervisor; I don't recall what locks are held. From: IBM Mainframe Assembler List on behalf of Steve Thompson Sent: Monday, September 18, 2023 5:10 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Channel Appendage Routines Forgive me, but I can't remember what a channel appendage is or is for. Could you just give me a quick answer/idea. I used to do CCW stuff but since ECKD, I've only done CCWs for tape (which is now not supported). Regards, Steve Thompson On 9/18/2023 4:54 PM, Tony Thigpen wrote: In VSE, yes. Tony Thigpen Dave Clark wrote on 9/18/23 4:36 PM: "IBM Mainframe Assembler List" wrote on 09/18/2023 04:27:49 PM: On the program we are both working on, the use of format-1 CCWs is not needed. In the end, it's one linked together program that is loaded by a // EXEC card, thus it is always loaded in 24bit. So, the only reason for using a format-1 CCW is so that the I/O buffer can reside in 31-bit space? 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. *
Re: Channel Appendage Routines
Forgive me, but I can't remember what a channel appendage is or is for. Could you just give me a quick answer/idea. I used to do CCW stuff but since ECKD, I've only done CCWs for tape (which is now not supported). Regards, Steve Thompson On 9/18/2023 4:54 PM, Tony Thigpen wrote: In VSE, yes. Tony Thigpen Dave Clark wrote on 9/18/23 4:36 PM: "IBM Mainframe Assembler List" wrote on 09/18/2023 04:27:49 PM: On the program we are both working on, the use of format-1 CCWs is not needed. In the end, it's one linked together program that is loaded by a // EXEC card, thus it is always loaded in 24bit. So, the only reason for using a format-1 CCW is so that the I/O buffer can reside in 31-bit space? 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. *
Re: Will z/OS be obsolete in 5 years?
My experience with Linux (RHEL) under zVM is that Linux tries to cache as much of the file system(s) as it can. To me this is a waste of RAM. So here is an interesting situation: Linux has its file systems and then MOUNTS a read only system via IP that is on another platform (NFS?). So this is being cached -- but it is read only, so if any data gets updated, it was updated by the platform that owns that file structure. I tried to get the Linux people to do an experiment: turn off file caching in Linux. See if the z/Arch caching would be just as fast or nearly so. Why was I pushing for this? Because ACE (replacement for IIB) is a CORE HOG as we used to say. In migrating to it, it immediately needed 1 GB more of RAM at a minimum. So in running production we had those servers using 16-32GB of RAM (eventually some were out at 64GB!!), with us also specifying VDISK for swap space (VDisk is actually c-Store or RAM being used as disk as far as Linux could tell, so that it was effectively E-Store for paging). Just getting Linux to stop caching file systems could possibly get us back 20% of the RAM in an LPAR running Linux for z. (Long story to explain this but yes, we could reduce the RAM in those servers by 1-2 GB each if we could prove no impact to production response). Oh, and you do not page Linux -- You have it do all its own paging. Why? Paging paging is like going back to shadow tables and the like for running MVS under VM/370 prior to IEF/SIE. (this being Assembler and not specifically a VM group, IEF is the Interpretive Execution Facility, which has a single instruction, SIE (Start Interpretive Execution)). With that instruction, any time the guest does something that would affect all users, SIE takes an interrupt, drops out to CP, CP then figures out what really needs to be done, does it, and then returns back to the guest via SIE so that the O/S thinks it did whatever. This is the short explanation. Since I never had access to IEF at Amdahl I only know this much of SIE and since those days we are several versions of IEF beyond what we did back then. -- Any one know of anyone that has done this experiment to see if z/Arch caching worked as well as Linux caching a file system? Steve Thompson On 8/8/2023 4:30 AM, dave.g4...@gmail.com wrote: -Original Message- From: IBM Mainframe Assembler List On Behalf Of Jon Perryman Sent: Monday, August 7, 2023 11:05 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Will z/OS be obsolete in 5 years? On Thu, 20 Jul 2023 at 09:01, Rob van der Heij wrote: It would be interesting to see your evidence of IBM Z not performing well with Linux. Linux on z performs better than Linux on most other hardware. My point is that Linux wastes much of z hardware. Since I haven't seen Linux on z, I have to make some assumptions. It's probably fair to say the Linux filesystem still uses block allocation. Let's say it's a 10 disk filesystem and 100 people are writing 1 block repeatedly at the same time. After each writes 10 blocks, where are the 10 blocks for a specific user. In z/OS you know exactly where those blocks would be in the file. If you read that file are these blocks located sequentially. While the filesystem can make a few decisions, it's nothing close to the planning provided by SMS, HSM, SRM and other z/OS tools. Yes but do you really? If you allocate a fixed file size you are wasting the un-used space at the end of the file, or if you run out of space its going elsewhere. I would argue that Linux is better at using disk capacity as you only ever waste half a block. Yes they might be scattered but how much data is on spinning disk and how much on SSD? Like MS Windows disks, Linux filesystems can benefit from defrag. Also consider when Linux needs more CPUs than available. Clustering must be implemented on Linux to increase the number of CPU which does not share the filesystem. In z/OS, a second box has full access to all files because of Sysplex. If the data is in a SAN multiple systems can access them without a SYSPLEX... I'm sure IBM has made improvements but some design limitations will be difficult to resolve without the correct tools. For instance, can DB2 for Linux on z share a database across multiple z frames. It's been a while since I last looked but DB2 for z/OS was used because it outperformed DB2 for Linux on z. Why use DB2? Dave
Re: Macros: sublists question
I haven't been dealing with HLASM for a few years, and I know that the new kids wanted certain new features But look at this from the Macro Processor's viewpoint: AAA m=(1,2,,3),=(a,b,c) Which one is a "macro" name (or mnemonic) and then which is a keyword and which one is positional? The second one "=(a,b,c)" is missing the keyword. So that statement should be flagged with an error. At least, I would expect that. Steve Thompson On 8/1/2023 4:39 PM, David Eisenberg wrote: I hope someone can help me; I have a macro assembler question. Suppose I write a macro MYMAC receiving two positional parameters: &TAG MYMAC &DATE1,&DATE2 The macro will do some date arithmetic. If I invoke the macro this way: MYMAC (2023,7,31),(2024,1,15)two dates (year,month,day) then IIUC, &DATE1 and &DATE2 are both sublists. I therefore have no trouble coding SETA statements so that I can reference the year, month, and day values individually. Now suppose I wish to modify the macro parameter syntax by requiring an equals sign in front of one of the dates (because I need to handle certain dates differently). E.g.: MYMAC (2023,7,31),(=,2024,1,15) Again, this is simple: I can check for the equals sign and extract the numeric values from the appropriate positions in each sublist. However... suppose I want to allow this syntax: MYMAC (2023,7,31),=(2024,1,15) in which the equals sign precedes a date, but is *outside* of the parentheses. Now IIUC, &DATE2 is no longer a sublist. This instruction: &YMD2SETC '&DATE2'(2,*) sets &YMD2 to the string (2024,1,15) which *looks* like a sublist, but of course it’s not. Maybe I'm on the wrong track. Bottom line: in my last example, I can’t figure out how to extract the year, month, and day values from &DATE2 so that I can reference them separately. I apologize if this is basic stuff... I would really appreciate the help! Thanks, David
Re: Hyper Scale? [Was Will z/OS be obsolete in 5 years?]
Linux in VM is a non-starter for hyperscale Linux computing. You might as well by PC servers. What is hyperscale Linux? I've been involved in LPARs of z/VM running multiple Linux servers in SSI pairs for hot fail over. So I am curious what you mean by this. Looking this up, I read a lot of word salad, and salespeople/marketeers that don't understand (or flatly ignore that Cloud is someone else's data center), so their definitions are, really, word salad. Steve Thompson
Test of Access
This is a test. This is only a Test. Had this been a real message, it would have contained some intelligence. Alas, this is only a TEST.
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
Re: Questionable Instructions in Obtaining EAX documentation
From memories of 30-ish years ago... I worked on MDF (Multiple Domain Facility -- What IBM came to call PR/SM and domains got called LPARs) at Amdahl. So let me elaborate on what Seymour said just based on the Amdahl MVS Structure and Flow class I had (2 weeks of in depth teaching). When you hit the blue LOAD button (as I recall that was the color), the system went into IPL mode/state (I've forgotten which is the formal name) and fetched from a specific volume the IPL TEXT. Now we summarize all the fun from that. Page Frame 0 for that DOMAIN/LPAR is *the INITIAL* PSA (PSA 0) while in IPL mode/state. This is all done in REAL mode. So you get all of the IRIM and RIMs done (Initial Resource Initialization Module, and Resource INIT module -- I didn't come up with those names, IBM did) and you are now preparing for MP INIT (or DP if you only have a Dyadic machine), so, you point some register (not 0) at this PSA you are about to build, doing a copy from the PSA 0 to this PSA being built and now you load your prefix reg with this address. Now R0 is pointing to this new PSA and no longer to PSA 0. Why did we do this? Because PSA 0 now has all of the NEW/PSWs set to point to the xxx Interrupt FLIHs (First Level Interrupt Handlers). And it has all the other stuff that has to be anchored in the PSA stored at the specified positions. I have forgotten when RSM (Real Storage Manager) has been done, and VSM, etc. are init-ed, but DAT should now be active. We can now do "MP" INIT. For each CPU we have to get the storage for its PSA and copy PSA 0 to it to init it -- You may need to make a change in that PSA, so you have to address it with something other than R0. Once that is done, a SIGP RESTART is done for that CPU. Now that CPU goes through all the stuff it must to get to a dispatchable state for the dispatcher to control it. And that may be a very short # of items. Rinse repeat for each CPU defined for this domain/LPAR. That's one use of addressing a PSA where you can't use R0. ACR -- Alternate CPU recovery may be another. MCK -- Machine check handler. It may have to look at a dead CPU (MCK PD comes to mind, and PI loop is another -- but that may be done in ACR) and so it has to use something other than R0 to look at that processor's PSA. Now you know some of the reasons for using other than R0 to address a PSA. Again, it has been 30 years now since I worked at that level and MVS has changed a lot since then. Regards, Steve Thompson On 11/12/19 2:01 PM, Seymour J Metz wrote: No, it's not a waste of resources. There is a valid use case regardless of whether you can conceive of it. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of John McKown Sent: Tuesday, November 12, 2019 8:13 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Questionable Instructions in Obtaining EAX documentation On Tue, Nov 12, 2019 at 6:56 AM Peter Relson wrote: What if R9 is not supposed to be zero? Maybe the code is looking at the PSA of another processor. The normal way to accomplish that is USING PSA,R9 rather than leaving a time-bomb for those who come after by using "0". I cannot fathom the reason to use _any_ base for the PSA other than GPR0. It is simply wasteful of a scarce resource. Peter Relson z/OS Core Technology Design -- People in sleeping bags are the soft tacos of the bear world. Maranatha! <>< John McKown
Re: Questionable Instructions in Obtaining EAX documentation
Yes, and I am, by your definition, one of the .01%. But my point was, the contents of R0 may be relevant. Implying it never matters is not quite right. However I must agree with you that most people working on/with z/OS will never need to work at this level. But depending on what they are doing with VM and/or a z Linux distro BTW, I went and looked it up (I have quite a few copies of the PoOP from different points in time). This knowledge was once quite important to me because a long time ago I worked on MDF at AMDAHL. And I was once working on an emulator for S/370-XA but I think it was Don Higgins (regardless he lived across the bay from me when I was in Tampa before Amdahl) beat me to it. And I think that is where Hercules came from (hazy memory these days). If you get into the depths of MVS (as in MVS 3.8J or 3.8O I think it was), you might need that info, so maybe it is more than 0.01% that will be exposed to this during their lives. Regards, Steve Thompson On 11/6/19 1:44 PM, Steve Smith wrote: Prefixing is absolutely* irrelevant to this discussion, and to 99.99% of assembler programmers for their entire lives. It's well-documented if you're interested, but you probably aren't. Any discussion here is very likely to be spurious, specious, and superficial. *I guess it's "really" irrelevant too. :-) sas On Wed, Nov 6, 2019 at 1:30 PM Seymour J Metz wrote: The contents of R0 is irrelevant to forming the effective address of an RS or RX instruction. the contents of the prefix register are only relevant for real addresses. Now,, if you're running DAT off and you use an instruction that takes an address from a register, e.g., MVCL, then it is subject to prefixing. But even there it's in terms of the storage assigned to the LPAR.
Re: Questionable Instructions in Obtaining EAX documentation
So what happens when R0 happens to contain the same value as the prefix Reg of the CPU that handles this code? Would that be how one gets to "relative" 0 in this particular LPAR? (Absolute address 0 is owned by the Hypervisor if I understand how IBM implemented PR/SM). Regards, Steve Thompson On 11/6/19 1:01 PM, Steve Smith wrote: Register 0 cannot be used as a base or index register. This is because 0 in the base or index register field or an instruction means "no register". The assembler has always allowed the specification of 0 for either to satisfy the people who just like to code default stuff. Clearing a register before LH strongly implies the coder doesn't know what LH does. The L R4,AXVAL should be LH. sas
Re: Writing the Definitive Systems Programmer Resume
Sigh. I can tell it is going to be a good day when I get up an hour before the alarm I thought I had used his private address, but instead replied to the list. Sigh. Regards, Steve Thompson On 8/2/19 6:43 AM, Steve Thompson wrote: Joe: I'm interested. I won't be able to be at Share. Regards, Steve Thompson On 8/1/19 6:51 PM, Joe Gallaher wrote: Ever feel like your resume goes into a black hole? I would like to invite anyone attending next week's SHARE conference in Pittsburgh to come to my session entitled "Writing the Definitive Systems Programmer Resume" (session 25087, Tuesday, August 6, 2019 at 3:30 PM). This will be the 13th time I have given this presentation at SHARE and it contains a lot of useful information and samples for the aspiring resume writer. Over the last 37 years I have written thousands and thousands of mainframe systems resumes. Here is a link to my session: https://events.share.org/Summer2019/Public/SessionDetails.aspx?FromPage=Sessions.aspx&SessionID=8678 If you cannot attend, feel free to send me an email (or LinkedIn message) and I will send you a link to my PowerPoint slides. Joe Gallaher j...@spci.net 323-822-1569 work 323-363-7259 cell http://www.SPCI.net http://www.linkedin.com/in/joegallaher "You wouldn't hire a COBOL programmer to install your operating system. Why use an applications recruiter for your systems management needs?"
Re: Writing the Definitive Systems Programmer Resume
Joe: I'm interested. I won't be able to be at Share. Regards, Steve Thompson On 8/1/19 6:51 PM, Joe Gallaher wrote: Ever feel like your resume goes into a black hole? I would like to invite anyone attending next week's SHARE conference in Pittsburgh to come to my session entitled "Writing the Definitive Systems Programmer Resume" (session 25087, Tuesday, August 6, 2019 at 3:30 PM). This will be the 13th time I have given this presentation at SHARE and it contains a lot of useful information and samples for the aspiring resume writer. Over the last 37 years I have written thousands and thousands of mainframe systems resumes. Here is a link to my session: https://events.share.org/Summer2019/Public/SessionDetails.aspx?FromPage=Sessions.aspx&SessionID=8678 If you cannot attend, feel free to send me an email (or LinkedIn message) and I will send you a link to my PowerPoint slides. Joe Gallaher j...@spci.net 323-822-1569 work 323-363-7259 cell http://www.SPCI.net http://www.linkedin.com/in/joegallaher "You wouldn't hire a COBOL programmer to install your operating system. Why use an applications recruiter for your systems management needs?"
Re: Fwd: Assembler III at Latham, NY 12110, USA
Yeah. Been there, done that, told LinkedIn that they could keep their "membership". Just because some keyword matches doesn't mean you are a pipe fitter. It only means you know how to do pipes with Linux or maybe VM & REXX. Regards, Steve Thompson On 3/18/19 7:17 PM, Donald Blake wrote: And from one of Sneha's co-workers ... -- Forwarded message - From: Sai Kalyani Kaluri Date: Mon, Mar 18, 2019 at 5:21 PM Subject: Assembler III at Latham, NY 12110, USA To: *Hi ,* This is Kalyani from Nextgen Technologies Inc. We have an immediate opportunity with one of our clients. Please find the job description below and if you are interested, please forward your resume to kaly...@nextgentechinc.com *JD:* *Job ID: PHHJP00011876* *Position : Assembler III* *Location: Latham, NY 12110, USA* *Timings: 2nd shift (3:20 p.m.-11:30 p.m.)* *Duration : 3 Months of Contract* *Job Description:* - Experience: 2-5 years of experience in position or specialization. - Education: High-school/Associates or equivalent experience if applicable. - Certification if applicable. - Position, align, fasten and install piping, fixtures, or wiring and electrical components to form assemblies or subassemblies, using hand tools, rivet guns, and welding equipment. - Construct or assemble an entire product or component of a product. - Be safety conscious and have a safety and quality first mentality, must be positive, focused, work well with others, demonstrate strong attention to detail, maintain high sense of urgency and consistency in work performance. - Must have steel toed shoes prior to beginning assignment. Thanks & Regards, *Kalyani Kaluri *|R*ecruiter* *[image: Description: http://www.nextgentechinc.com/images/logo.png]* Nextgen Technologies Inc | *1735 N 1St ST., Suite-308 <https://maps.google.com/?q=1735+N+1St+ST.,+Suite-308%C2%A0+%7CSan+Jose,+CA+95112&entry=gmail&source=g>** |San Jose, CA 95112 <https://maps.google.com/?q=1735+N+1St+ST.,+Suite-308%C2%A0+%7CSan+Jose,+CA+95112&entry=gmail&source=g>* Email :-- kaly...@nextgentechinc.com Website:-- www.nextgentechinc.com
Re: Snap Macro Assembler error ? Here it is thanks
Late answer to this:
I had also tried this, got fed up with it, and used IEATDUMP instead.
Regards,
Steve Thompson
On 11/4/18 10:32 PM, Paul Gilmartin wrote:
On 2018-11-04, at 18:51:14, Keven Hall wrote:
I noticed this benign cyst of codein the SNAPX macro. Obviously this
has no effect on code generation but executing it a few million times
per day could really chew up some cycles. YMMV
.CKLFORM ANOP
AIF ('&MF' NE 'L').ARND
AIF ('&STORAGE' EQ '').ARND
.ARND ANOP
IOW, you're worried about the consequence if you assemble
the source a few million times?
-- gil
Re: SVC99 DEALLOC Failure
On 10/31/18 8:16 AM, Peter Relson wrote: So y'all will know how things worked out -- I found the issues and fixed them. Please share the details of "the issues", whether they were coding error(s) or were thing(s) that you figured out. Both could be helpful to others, to avoid whatever pitfalls you ran into. Peter Relson z/OS Core Technology Design Quickly, there was confusion with a label being used in the COBOL code. The COBOL area and the ALC DSECT matched, but the wrong label was used so the wrong value was in the "right place" and the TEXT unit logic was using the wrong info. It was Scott (of IBM) over in IBM-main who pointed out something about what SVC99 was doing and it suddenly occurred to me that I may have finger-checked in the COBOL driver. This little incident uncovered another problem: The original TIOT validation routine, based on how things were done with MVS/SP1 (looks up the DDName to see if it is already allocated) was failing. It was telling us that a DDNAME was not in the table when we know it had to be, because it was defined in the JCL. Regards, Steve Thompson
Re: SVC99 DEALLOC Failure
So y'all will know how things worked out -- I found the issues and fixed them. Now it will deallocate the DD if the DD had been specified by JCL or SVC99. Thanx, Steve Thompson
Re: SVC99 DEALLOC Failure
I’ll give that a try. I had thought about that but was puzzled because it is not listed as being needed. I’ll be back at this in the morning. Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct mistaks > On Oct 29, 2018, at 5:10 PM, Janko Kalinic wrote: > > Try adding the DUNUNALC text unit (x'0007'). The PDS command uses that > in all of it's deallocations. > > Regards, > John K > >> On Mon, Oct 29, 2018 at 3:29 PM Steve Thompson wrote: >> >> Dunno. I’ve never used it. I’ll go look it up and see. >> >> Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. >> Expct mistaks >> >> >>> On Oct 29, 2018, at 4:16 PM, Paul Gilmartin < >> 00000014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: >>> >>>> On 2018-10-29, at 14:02:30, Steve Thompson wrote: >>>> >>>> I'm testing a special in-house developed utility. So it is designed to >> be invoked by a COBOL program. >>>> >>>> Now, I come back and test the DEALLOC function, and I get a failure >> from SVC99, ... >>>> >>> Can you compare the result with BPXWDYN( ... MSG(WTP) ) which >>> gives pretty good diagnostic text? >>> >>> -- gil >>
Re: SVC99 DEALLOC Failure
Dunno. I’ve never used it. I’ll go look it up and see. Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct mistaks > On Oct 29, 2018, at 4:16 PM, Paul Gilmartin > <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > >> On 2018-10-29, at 14:02:30, Steve Thompson wrote: >> >> I'm testing a special in-house developed utility. So it is designed to be >> invoked by a COBOL program. >> >> Now, I come back and test the DEALLOC function, and I get a failure from >> SVC99, ... >> > Can you compare the result with BPXWDYN( ... MSG(WTP) ) which > gives pretty good diagnostic text? > > -- gil
SVC99 DEALLOC Failure
I'm testing a special in-house developed utility. So it is designed to be invoked by a COBOL program. I'm going to tell you how I got here and all the stuff I've been doing, and then the effects of the SIS (IBMLink search), etc. before I ask my question. So a test of the code, once fixed to run AMODE=31, works when I do an allocation of one of my own data sets using the DD of SYSUT1. When I do this allocate, I do not specify anything special for the text units. I only use the DDNAME, DSNAME and disposition of SHR. Now, I come back and test the DEALLOC function, and I get a failure from SVC99, and in the RBX I get ERROR CODE 0388 - ALL REQUESTS EXCEPT DSNAME ALLOCATIONS REQUIRED KEY NOT SPECIFIED (I know this because the program has SNAP logic built in so I can SNAP the Text units & pointers before and after the SVC99 execution). This is also associated with IKJ56878I and that message makes no sense. But the doc for that message says go read the text messages in the manual, and basically, pay attention to the text keys that are required. Uh, it appears that only the DDNAME is required, but it doesn't say you can't also specify the DSNAME. It makes no difference, I can't get this to work. So, the message manual also says something about DAIRFAIL. Well I haven't played with DAIR directly for so long that I can't remember what manual(s) even hold that info, if they are even published these days. Ok, so I did a bunch of duckduckgo.com searches, and google, and I can't find anything that matches. So then I went to IBMLink and finally got the web pages to display formatted (Chrome) and searched and got no hits for the message, for dairfail, etc. And I was not just looking for APARs and PTFs, I was including other libraries for info as well. [KC comes into this now, and it locked up IE.] So back to Chrome and I can't find the info I need. Does anyone know if there is something special about SYSUTn as a DD for SVC99? I use these all the time via REXX, and I don't have these problems there. So it would seem that it should be simple as I did not turn on any special flags for doing the allocation (e.g., in-use, or similar). Regards, Steve Thompson
Re: Macro Behavior
Thank you. You answered my real question. And so with that knowledge I can say that the RFE is like screaming in space. No one will hear. Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct mistaks > On Oct 19, 2018, at 1:03 PM, Peter Relson wrote: > > There is no "should" in this sort of situation. There is a "could". There > is a "wouldn't it be nice if". > > Could it be done? Sure. Would having done so have helped this case? Sure. > Would doing so be a better use of limited resources than doing something > else? > > There is no requirement that a macro do any more than what it is > documented to do, which is to provide the correct expansion when you have > provided valid syntax. Most macros do far more than that. > > Will ESPIE be changed? Probably not. Whether you ask here or via RFE. > ESPIE (and SPIE) have had no such check for over 40 years. There are many > macros that make no attempt to look at (or for) positional parameters. > > Peter Relson > z/OS Core Technology Design
Re: Macro Behavior
In the case of positionals: it is the writer’s problem to determine how many
positional entries they need to handle.
I have forgotten the macro, but it was back in the old F Asm days (IIRC) that
used &SYSLST(n) to handle all of its positionals. That is, it did not define
them individually on or with the model statement. This makes it impossible for
the assembler to know there is a problem.
So, in that case, the writer had to detect and report the excess. And as I
recall, they did. I can’t remember if it was an “O/S” macro or product (back in
those days there was not the siloing that there is today, based on component).
But, when a system macro is user indifferent, that leads to problems. And ESPIE
is a system|RTM macro. Indifference here can cause problems.
In fact it did. RENT and self modifying do not go together well.
Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct
mistaks
> On Oct 18, 2018, at 7:22 PM, Charles Mills wrote:
>
> +1
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
> On Behalf Of Steve Smith
> Sent: Thursday, October 18, 2018 3:27 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: Macro Behavior
>
> I think in this case, ESPIE, it should check for extraneous operands. It
> evidently has a maximum of 3 positional operands, and it would certainly
> complain if MF(E(1)) was one of them.
>
> Re allowing a trailing comma: I wouldn't, and I think Jonathan's
> justification is off the mark. The check for too many positionals would
> include optional operands. Regular processing should normally treat an
> optional operand as unspecified if null anyway. So
> AIF (n'&SYSLIST GT max).error
> is sufficient. But if you insist, then
> AIF (n'&SYSLIST EQ max+1 AND '&SYSLIST(max+1)' EQ '').ok
> first.
>
> I've seen too many macros that are overzealous in checking things that
> don't matter, and things the assembler could catch just as well. This
> example is sort of a gray area (albeit dark gray) where the macro could
> process with what it got, but on the other hand could likely save some
> trouble by doing this extra check.
>
> A logical case could be made the macro processor could/should catch this
> itself. Undeclared positionals could be an automatic warning, like
> undeclared keywords are. But you'd need some way for macros to specify
> they will accept an arbitrary number of undeclared positional operands
> (because many do so). However, this is pretty much hypothetical, as I
> can't see it's worth the effort or incompatibility.
>
> sas
>
> On Thu, Oct 18, 2018 at 11:49 AM Jonathan Scott
> wrote:
>
>> Ref: Your note of Thu, 18 Oct 2018 11:30:09 -0400
>>
>> Steve Thompson writes:
>>> I have a question. If one passes too many positional arguments to
>>> a macro, should one not issue an MNOTE about this?
>>>
>>> Please try the following, and let me know what you think about this:
>>>
>>> ESPIE SET,MYRTN,(1,3,7),PARAM=(3),MF(E,(1))
>>
>> It is obviously possible for a macro to check for too many positional
>> arguments. There are also many other ways in which macros could
>> typically perform intelligent extra validation on operands.
>>
>> However, on the other side, it is not normally the responsibility of the
>> macro writer to check for incorrect usage. Such checks could be
>> considered some "extra value" which the macro writer could add, if it is
>> considered worth while and does not add too much complexity.
>>
>> The usual principle in most product macros is only to check for errors
>> which mean that the macro is unable to continue, for example because a
>> required operand is missing or a keyword has an unsupported value.
>>
>> Personally, I include the "too many positional parameters" check in
>> most of the macros which I create.
>>
>> I check for ('&SYSLIST(n)' EQ '') where n is one more than the valid
>> number of positional parameters. I do this rather than checking
>> N'&SYSLIST so that it will tolerate a trailing comma, for example when
>> a macro has one positional parameter which is optional, so the user has
>> coded a dummy comma operand, which causes N'&SYSLIST to be set to 2 even
>> though only one positional operand is allowed.
>>
>> Of course, my check will not pick up a case where a spurious extra
>> positional parameter is preceded by two or more consecutive commas,
>> but it doesn't seem worth coding multiple checks to cover even more
>> obscure possibilities.
>>
>> Jonathan Scott, HLASM
>> IBM Hursley, UK
>>
>
>
> --
> sas
Macro Behavior
I have a question. If one passes too many positional arguments to a macro, should one not issue an MNOTE about this? Please try the following, and let me know what you think about this: ESPIE SET,MYRTN,(1,3,7),PARAM=(3),MF(E,(1)) --- Yes, the above should have "=" making it a keyword. But somehow that "=" got removed. Which is what brought my attention to this. This macro does not generate an MNOTE, it ignores the extra positional parm. Support wants an RFE for this. Shades of CA's thinking. Regards, Steve Thompson
Re: IEATDUMP MF=L Can someone explain this?
Well, after looking at the code that is generated, I really do think that this was done this way for PLAX (or whatever it is today) users and NOT HLASM programmers. And the manual needs to explain this better. This is the label prefix for all the labels that will be generated by this expansion. I say this because Whatever it is you put in the second parm, becomes the label prefix. And then each field has its own label with that prefix. And the label on the MACRO call is put into the source like this: IEATDUMP_L IEATDUMP PLISTVER=MAX,MF=(L,IEATDUMP_S) +IEATDUMP_L EQU IEATDUMP_S +IEATDUMP_S DS OD +IEATDUMP_S_... One would have expected that a DSECT macro would be be required to be generated... You know, like IHAPSA, or IKJTCB, or IEFZB4d0, or ... Regards, Steve Thompson On 08/24/2018 02:23 PM, Mike Shaw wrote: We have the list form coded like this: IEATDUMP PLISTVER=MAX,MF=(L,IEATDUMPL) and the execute form coded like this: IEATDUMP DSN=DUMPDSNL,HDR=DUMPTITL, PLISTVER=MAX, MF=(E,IEATDUMPL) Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
IEATDUMP MF=L Can someone explain this?
I have a program that I am fixing to be 31bit addressing. I'm looking at an MNOTE out of IEATDUMP coded as follows: IEATDUMP_L IEATDUMP PLISTVER=MAX,MF=L The MNOTE,8 says: For the "MF" key, positional ARG 2 is required. So, here I am trying to define the List area, but the list area needs to be given an address to use. But I need this generated so that it KNOWS what the size of the PLIST is. The very fine manual just doesn't make sense in this case. What is MF=L for? Hasn't it been to build the PLIST area with a label? And then, if I need to know the length of the list, I put a label or EQU after... I am just baffled with this. It is as if they expect me to know what the PLIST size is to start with (if I give it an area in storage, I better know how much it is going to ultimately clobber, doncha think?). We don't have to do this with other macros. What is so special about this one? Regards, Steve Thompson
WYLBUR [was Re: EX]
On 08/07/2018 04:37 PM, Dan Greiner wrote: Steve Thompson wrote: BTW, there are a few instructions on IBM systems that are not documented. One of those is, SIGH (ok, SIE :) ). You can't SIE an SIE either (this is part of the Interpretive Execution Facility). Actually, the original SIE was documented in "IBM System/370 Extended Architecture — Interpretive Execution" (SA22-7095-00). You can find it at http://bitsavers.org/pdf/ibm/370/princOps/SA22-7095-0_370-XA_Interpretive_Execution_Jan84.pdf. The storage operand of the SIE instruction is the state-description block (SDB), the original format of which (described in SA22-7095) is no longer supported. Alas, the documentation of current versions of the SDB are not publicly available. However, various customers made use of the original-recipe SIE. As I recall, Stanford Linear Accelerator Center (SLAC) made use of SIE to dispatch a Wylbur guest (thus isolating the rest of the OS from Wylbur's proclivity to wildly branch while in supervisor state). Since the operand of the SIE instruction is not another instruction, I'm not sure what you mean by "You can't SIE an SIE either ..." The SIE firmware certainly allows multiple levels of interpretive execution: PR/SM issues SIE to dispatch a logical partition (a 1st-level guest), and zVM running in a partition issues SIE to dispatch a virtual-machine guest (a 2nd-level guest). Conceivably — given a really smart VM guest, and access to the current SIE doc — you could dispatch additional levels of guest configurations. Yeah, I knew most of that at one time. But I also knew that SIE stopped being documented, I think with XA. I know the version of it prior to ESA was not documented, because of TIDA at AMDAHL. The persons that handled SIE for AMDAHL told me that SIE can't be used to dispatch a second level VM machine. The "EXCEPTION" to that appeared to be with PR/SM which originally was VM under the covers -- as it was explained to us by customers -- OK, we could read the console and we recognized the message prefixes as well. So I have understood that SIE can't dispatch SIE. But hey, I haven't had the opportunity to work at that level since the AMDAHL bean counter layoff of 1989. And the wild branch in Wylbur (well some wild branch) I finally fixed when I took ACS/OBS WYLBUR to source maintenance and SMP/E install. To get all this to work, I had to overhaul the JES2 SRB mode code so that the users would assemble a module that WYLBUR would load and then have all the displacements that matched the JES2 they were running. So we ran that level of WYLBUR in house for two years as I hammered out various things in getting the components correctly defined in SMPE so that, IIRC, you could chose JES2 SRB, or JES2 SSI or JES3 SSI for spool access -- they were mutually exclusive. Then ACF2, or RACF, or Top Secret, or WACF (Wylbur Access Control Feature IIRC that name) were all mutually exclusive. And there were a few other components but I can't remember them. At any rate, George Coldren and I chased that wild branch through the code and we just couldn't pin it down to *the* cause. Even with XDC, we couldn't recreate it at will, so we could never find it. Once the SMPE version of ACS/WYLBUR shipped (9.5, I've forgotten the FUNCTION ID), the number of outstanding problems we had dropped from 400+ to less than 25. Wish I could find someone with the source for that. I don't think it would take me much more than a year to have it running in z/OS -- Assuming I could work on it full time :) Regards, Steve Thompson
Re: EX
On 08/05/2018 09:30 PM, Robin Vowels wrote: - Original Message - From: "Steve Thompson" To: Sent: Monday, August 06, 2018 4:21 AM Subject: Re: EX On 08/05/2018 08:13 AM, Robin Vowels wrote: From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Friday, August 03, 2018 3:09 AM EX can "modify" everything, but it does not modify the subject instruction. Exception, EX. Of course. In the context, EX can modify everything. And anyway, why would you want to EX an EX? How easy is it to get a S0C1 (PIC 1) in a program? Now look at the next several program interrupts and ask, how could I get such an interrupt? Well, there is the wild branch into code or data. Then there is the storage overlay of data (also known as storage corruption). In all my years of programming, I have never seen an accidental S0C3. But I have seen plenty of PIC 1s, a few PIC 2s, PIC 5-7. And most of those have been as a result of a bad branch. But you can get them trying to "run" data as if they were instructions. So, because of its usefulness, I code it in a macro typically called SUICIDE. There is no question about what is going to happen when this instruction is pulled into the processor. S0C3. And because of comments I put with it, you will know why this is going to happen. BTW, there are a few instructions on IBM systems that are not documented. One of those is, SIGH (ok, SIE :) ). You can't SIE an SIE either (this is part of the Interpretive Execution Facility). Regards, Steve Thompson
Re: EX
On 08/05/2018 08:13 AM, Robin Vowels wrote: From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Friday, August 03, 2018 3:09 AM A principal use of EX is to be able to use a register mask to modify the target. CDC 3800 had a clever alternative to this, a modify-next-instruction instruction (I forget what it was called). The target was always the following instruction; execution continued after that instruction -- no need to branch around. Its principal use was to enable CDC 3800 extended addressing in old CDC 3600 short-address instructions. Addressing was not otherwise modal. IBM might have done well to provide a modify-next rather than a long-address, pipeline breaking, dreadfully expensive, EX. (They probably had the discussion and had good reasons not to do it.) (Can EX modify the CC mask in a target branch instruction? A sure branch prediction breaker.) EX can "modify" everything, but it does not modify the subject instruction. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus Exception, EX. That results in S0C3 on MVS or PIC 3 in any other O/S environment (DOS, TOS, VM, CMS, etc.).
Re: EQU * considered harmful
On 08/02/2018 04:09 PM, Paul Gilmartin wrote: On 2018-08-02, at 14:00:37, Steve Thompson wrote: I haven't touched a Univac since 1979. So I forgot a few things. But still, the 36 bit words made it a pain for communicating with a DEC. I was asked how to get them to talk to each other... It was interesting -- thankfully I kept doing FORTRAN-77 and someone else built the interface box. "If you don't have 36-bit words, you're not playing with a full DEC!" PDP-6, decsystem-10 and decsystem-20 had 36 bits. Vax broke the mold. -- gil It was NASA. They were using old equipment. I don't remember which DEC boxes they had, I was told that the I/O interface was 16bits wide. But, the Space Shuttle flew in spite of the fun we had writing the ground support software. -- Goddard Space Flight, Beltsville MD Regards, Steve Thompson
Re: EQU * considered harmful
Shmuel: I haven't touched a Univac since 1979. So I forgot a few things. But still, the 36 bit words made it a pain for communicating with a DEC. I was asked how to get them to talk to each other... It was interesting -- thankfully I kept doing FORTRAN-77 and someone else built the interface box. I do not know about the IBM z machines today. I worked on ECL/TTL at Amdahl in Macrocode/MDF. I've read stuff about the chip sets and sometimes at SHARE I get to talk with some people about the advances since the days I worked at Amdahl. BAL -- Actually, I worked on an ASCII based machine that had NO Conditional assembly -- It was a Basic Assembly Language assembler. That was for and with Digital Systems Corp (not DEC) in Walkersville MD -- Galaxy 5 machines. 20 bit addressing/word, no priv ops and no storage protection using. Competed favorably to/with IBM's S/3 15D machines. Used "Maytag" disk drives (2311 type). Regards, Steve Thompson On 08/02/2018 12:34 PM, Seymour J Metz wrote: Be glad we aren't doing Univac I wish that you had imitated the good parts as I recall the U1100/x machines were word machines. Each instruction was 36bits long and there were 3 types of registers. General, FP, and Index IIRC. Close; the same pool of accumulators was used for fixed and floating point. For many instructions it was possible to specify a 6-bit, 12-bit or 18-bit byte within the word. The advantage of separating the accumulators from the index registers is that you get more of them. That doesn't matter for a machine like STAR-100 with an 8-bit register number, but with a 4-bit number it's too easy to run out. BAL/ALC since about 1976 ALC I believe. I seriously doubt that you were still running BPS in 1976. BTW, what is the effect on the pipeline of an extraneous branch around the inline executed instruction, as compared to putting it out of line? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Steve Thompson Sent: Wednesday, August 1, 2018 8:24 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: EQU * considered harmful IBM is committed to this (instructions take an even number of bytes) because the machine is architected that way (long story that is anchored back in the S/360 architecture). Be glad we aren't doing Univac -- as I recall the U1100/x machines were word machines. Each instruction was 36bits long and there were 3 types of registers. General, FP, and Index IIRC. Answering another post here: The instruction and data being close together such that they are in the same cache line causes what I think is called a processor pipeline stall. With the G3 CMOS chip-set that implemented I/D Bank cache, if an instruction were to modify data within that cache line, the pipe would stall, the system control code would have to force that cache line back into C-Store, it would have to be fetched into the D-Bank cache, the data fetch/update/write (whatever the instruction was) would be done, the cache line would be flushed back to C-store and then re-fetched back into the I Bank cache That was the G3 level. I'm told that this was uncovered by SAS because they were "generating" their code as they ran (I'm thinking they were modifying their code) and so SAS programs ran much more slowly than they had on the prior machine. One observation I have as someone who has been programming in BAL/ALC since about 1976. You guys wouldn't be able to program on a S/360 with that level of assembler. Particularly if it were the DOS Assembler. The idea of EQU * in instructions made sense, and as others have pointed out, didn't cause excessive TXT cards to be punched (really had to pay attention to this on a S/360-20 -- oh the inhumanity of it all with a SYSRES on tape -- My apologies to Bones of Star Trek fame). And structured ALC macros generate scads of unintelligible labels (well, until you get used to the way it works). Be glad that we can now use more than 8 characters for a label. There are reasons for labels that one does not "branch" to, whether by LA Rn,=(sss); BR Rn, or BALR, etc. And that is, if one is using an interactive trace tool (such as TSO TEST -- I have forgotten how to use it, XDC is so much better) one can specify the PARM of TEST to the assembler and was it also LINKEDIT? Anyway, you now have labeled points (on SYM cards) to set breakpoints instead of offsets in the program. Ya just gotta be old enough to have had to work that way back in the day. And Charles, sorry, this go around I will be in the office. I just can't get free to go to SHARE. Maybe, possibly in spring 2019. Regards, Steve Thompson On 08/01/2018 06:49 PM, Charles Mills wrote: - IBM is pretty much committed to even-halfword instructions because Jump only jumps even halfwords. - You want a confessi
Re: EQU * considered harmful
IBM is committed to this (instructions take an even number of bytes) because the machine is architected that way (long story that is anchored back in the S/360 architecture). Be glad we aren't doing Univac -- as I recall the U1100/x machines were word machines. Each instruction was 36bits long and there were 3 types of registers. General, FP, and Index IIRC. Answering another post here: The instruction and data being close together such that they are in the same cache line causes what I think is called a processor pipeline stall. With the G3 CMOS chip-set that implemented I/D Bank cache, if an instruction were to modify data within that cache line, the pipe would stall, the system control code would have to force that cache line back into C-Store, it would have to be fetched into the D-Bank cache, the data fetch/update/write (whatever the instruction was) would be done, the cache line would be flushed back to C-store and then re-fetched back into the I Bank cache That was the G3 level. I'm told that this was uncovered by SAS because they were "generating" their code as they ran (I'm thinking they were modifying their code) and so SAS programs ran much more slowly than they had on the prior machine. One observation I have as someone who has been programming in BAL/ALC since about 1976. You guys wouldn't be able to program on a S/360 with that level of assembler. Particularly if it were the DOS Assembler. The idea of EQU * in instructions made sense, and as others have pointed out, didn't cause excessive TXT cards to be punched (really had to pay attention to this on a S/360-20 -- oh the inhumanity of it all with a SYSRES on tape -- My apologies to Bones of Star Trek fame). And structured ALC macros generate scads of unintelligible labels (well, until you get used to the way it works). Be glad that we can now use more than 8 characters for a label. There are reasons for labels that one does not "branch" to, whether by LA Rn,=(sss); BR Rn, or BALR, etc. And that is, if one is using an interactive trace tool (such as TSO TEST -- I have forgotten how to use it, XDC is so much better) one can specify the PARM of TEST to the assembler and was it also LINKEDIT? Anyway, you now have labeled points (on SYM cards) to set breakpoints instead of offsets in the program. Ya just gotta be old enough to have had to work that way back in the day. And Charles, sorry, this go around I will be in the office. I just can't get free to go to SHARE. Maybe, possibly in spring 2019. Regards, Steve Thompson On 08/01/2018 06:49 PM, Charles Mills wrote: - IBM is pretty much committed to even-halfword instructions because Jump only jumps even halfwords. - You want a confession? You know one reason why I got in the habit of not using DS 0H in code? Because when I started out with punched card decks, 24MB hard drives and Assembler D, every transition from assembled data to DS and back forced a new TXT card and wasted cards and/or DASD space. You may laugh now. FWIW, DC 0H'0' avoided the problem but is trickier 029-jockeying than EQU *, and every typo cost you your daily shot back in those days. - I have a house rule to use J (not B!) *+n only to jump over a single instruction, never more than one. Yeah, it may be a problem waiting to happen, especially now with machine instruction length a little less intuitive (change A to AG and there goes your J *+8). What I like about it is that labels invite the question "who jumps here?"* so if I can avoid a label I do. It's a tradeoff. No one ever said assembler coding was for the faint-hearted. *A better solution probably is the structured assembler macros but by the time they came along I was not writing much assembler, so this old dog never learned that new trick. See you in STL? Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Gord Tomlin Sent: Wednesday, August 1, 2018 3:23 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: EQU * considered harmful On 2018-08-01 16:41, Charles Mills wrote: "Avoid instructions (executable code) and operand data (working storage or stack storage) in the same cache lines; which can be costly due to moving cache lines between the separated (split) local caches (instruction/data L1/L2)" -- C. Kevin Shum, Distinguished Engineer, IBM z Systems Microprocessor Development (March 2016) Charles Exactly. "Mixing executable code and operand data considered harmful" And if you always avoid mixing instructions and operand data, using EQU * for labels in code is no longer potentially harmful. We're on pretty safe ground if we assume IBM will always only create instructions that are an even number of bytes in size. I prefer, and always use, DS 0H for labels in code, but if EQU * causes problems in your code
Re: Instruction/Data Cache Usage (was EQU *)
I would suggest that the reason for the moving of "IBM's" data is because of the I-Bank D-Bank cache issue (I think it is actually a processor-pipeline stall -- but I have not done this level of work since 1990 -- Yes, long before the CMOS G3 chips were announce in 1997). What I have been doing to programs that do not have to be RENT but must become AMODE 31 is use the MF=L and MF=(E,???) formats where the List version of the macro is in "working storage" of the program (not GETMAINed, but right after the Register Save area). This allows short instruction lengths and the PLIST is in a data area that can't be part of any instruction cache lines. Regards, Steve Thompson On 08/01/2018 06:57 PM, Keith Moe wrote: "(working storage or stack storage)" I interpret this is mean storage that is being ALTERED, not CONSTANTS. I would think that duplicate unchanged cache lines in the instruction and data caches would not have the same SERIOUS penalty as altering data would. But I am not a hardware engineer nor do I know if this is true or not. I've noticed that IBM has been changing many of their macros to generate fewer inline constants with branches around them and use more literals (which can sometime surprise you with unexpected addressability problems when the data suddenly move from being very local) presumably to reduce the double cache usage (with or without the move/copy penalty), but one of the most glaring mixture of instructions and data that is (potentially) updated are the CVTEXIT and CVTBRET instructions. Programs invoked via system linkage have Register 14 pointing to CVTEXIT. The CVT is in the read/write nucleus and is not even cache line aligned! Keith Moe BMC Software, Inc. On Wed, 8/1/18, Charles Mills wrote: Subject: Re: EQU * considered harmful To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Date: Wednesday, August 1, 2018, 1:41 PM "Avoid instructions (executable code) and operand data (working storage or stack storage) in the same cache lines; which can be costly due to moving cache lines between the separated (split) local caches (instruction/data L1/L2)" -- C. Kevin Shum, Distinguished Engineer, IBM z Systems Microprocessor Development (March 2016) Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Keith Moe Sent: Wednesday, August 1, 2018 1:27 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: EQU * considered harmful Inline data is only a killer if it is updated. It is merely less efficient if it is read only (same cache line in instruction and data caches). My example was merely to show that the "INSTRUCT" statement would force half word alignment. Aside from macros that expand inline CONSTANTS (not updatable areas), I generally avoid mixing instructions and data. Even in non-reentrant code (unfortunately there's a lot here that I have to maintain and it's not worth it to make it reentrant), I try to isolate code blocks and data blocks. Keith Moe BMC Software, Inc. On Wed, 8/1/18, Charles Mills wrote: Subject: Re: EQU * considered harmful To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Date: Wednesday, August 1, 2018, 1:05 PM Well, one could argue that "DS" implies a variable, not instructions, and is therefore inappropriate as something on which to hang an instruction label. I like the idea of some kind of "instruction" attribute for EQU, with an error if you branched to a non-instruction symbol. I think I might argue for an EQU operand rather than a new opcode, but that is a quibble. J NEXTL DC CL(oddnumber)' ' NEXTL INSTRUCT You know that data mixed with instructions is just a performance KILLER on modern CPUs? They have separate i- and data caches, and mingling the two makes a mess that must be straightened out, at a cost of CPU cycles. Charles
Re: New Metal C standalone product for z/OS
* TYPEing &LABEL DC 0F,A(BUFF_LEN+7) Get The Charles Constant... The type of the LABEL is "F" not "A" and you got what you needed. yes? This is typically done for certain "ASSIST" type macros that I've used in the past where they check what the label is (IF, DO, DOWHILE, SELECT, etc.). Meanwhile, I'm thinking a bit about c and learning it. I still remember that c's pointers are about as obtuse as they get... But I'm told once you get past that, c becomes easy :) Regards, Steve Thompson On 07/18/2018 01:42 PM, Charles Mills wrote: It *does* get alignment right. CDSECT's output does not depend on "inherent" C alignment. Char[8] and uint64_t both end up in the same place. It constructs the struct using the SYSADATA offsets. It inserts its own padding where necessary. It emits #pragma pack(packed). Going from structs to DSECTs would make a lot of sense except that there is no C equivalent of SYSADATA, so the utility would have to have its own built-in (partial) C compiler. Going from PL/X to DSECTs (or C headers!) makes a lot of (technical) sense. I fail to see how &ptr32 is any clearer than A, unless you happen to be coming from a C-only background. Neither one is clear if you don't know what it means. A means "32-bit pointer." Generally. Of course HLASM is all but untyped. A might mean an integer constant, especially since A supports expressions while F somewhat inexplicably does not. You can code A(BUFF_LEN+7) but not F'BUFF_LEN+7'. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, July 18, 2018 10:10 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: New Metal C standalone product for z/OS On 2018-07-17, at 18:04:14, Charles Mills wrote: One annoying thing also is that it is non-trivial to use a text editor to find and convert all char foo[8]; to uint64_t foo; It would be easier if the c syntax were char[8] foo; then getting to uint64_t foo; would be trivial. It seems the designers were fixated on making declarators look like member references. -Original Message- From: Charles Mills Sent: Tuesday, July 17, 2018 4:57 PM Well, the problem of course is that assembler is not strongly typed. You can code BUFFADDR DS CL4 (or even 4C) and it works just fine for assembler, but what is poor CDSECT supposed to do. Last I knew, it did all FD and AD as char[8] which IMHO is pretty d@mned stupid. But it is syntactically valid and the storage layout is correct. Subject to bouldary alignment. A more useful design would code the data area descriptions initially as C structs and supply an ASTRUCT utility to convert to DSECTS. I believe I'd name it DESTRUCT. Or, an assembler programmer with foresight could have employed SETC symbols such as: &__ptr32 SETC A POINTER DC &__ptr32(symbol) ... Providing some guidance for a CDSECT utility and clarity for the reader of the source. (IMO, "&__ptr32" conveys better information than "A". I'm not advocating Hungarian Notation.) (This solves nothing for legacy source code.) -- gil
Re: Dr. John Ehrman
I am all for this. But I am not the one who can do it. For posterity's sake: I really enjoyed my exposure to Dr. John. What many may not know is, John was one of the developers of WYLBUR. And by stroke of luck (?) I was the last of the OBS/ACS WYLBUR developers. We made heavy use of HLASM and its conditional assembly in those days. I had a problem with some interface code for WYLBUR with JES2. And the JES2 support and development were claiming that they owned SYSPARM. This got escalated to HLASM. After both of us presented our sides of our respective arguments, Dr. John said, "I happen to own SYSPARM as part of HLASM. Mr. Thompson is correct that JES2 must parse the SYSPARM string for their information. So, I believe that JES2 has an opportunity for an APAR." That was my first time to ever talk with him. - I am just not as good with words as others. I shall miss him. -- Steve Thompson On 02/21/2018 04:32 PM, Richard Kuebbing wrote: Might I suggest the life of John Ehrman rises to a level that calls for a page on Wikipedia. Since Wikipedia wants to be only a secondary source, these messages could be considered the primary source. I would build the page but I am not a writer of anything but code. richard -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Don Higgins Sent: Wednesday, February 21, 2018 3:47 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Dr. John Ehrman All I was so sorry to hear about the passing of John Ehrman. Back on 11/20/17 I received this private email from John, “Hi, Don…. I retired from IBM in June 2016; at the same time, we discovered two types of cancer, so with treating that plus a couple of back surgeries has slowed me down a bit. I hope all is well with you and yours, and that the recent hurricanes didn't do any lasting damage. Regards ... John” I replied but never heard back from him again. I consider John Ehrman a friend, a true gentleman, and a technical hero. He was leader of the IBM High Level Assembler Group and leader of the Assembler Group at SHARE. I met John at SHARE many times and he introduced me several times when I made presentations at SHARE about the z390 Portable Mainframe Assembler and Emulator. Don Higgins d...@higgins.net - 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: OOP in HLASM
My understanding of US Copyright law is a bit different that yours. But, I'm not an attorney and I certainly haven't stayed at a H/I Express. If M/F in acquiring Borland also by that purchase obtained the copyrights and other IP, then I seriously doubt that this is in the public domain. Which is why I asked them and am waiting for a response. However, if Len Dorfman wrote this and was paid royalties by Borland, then Len still owns this (as opposed to Borland buying the "copyright"). Be careful in asserting that something has gone into the public domain in the area of copyright. You could get burned. I have some interest in copyrights because of IP owned by my family. And to my knowledge the renewal of copyright was changed in the '60s to no longer needing to formally renew it. This is how certain music passed into the public domain because it expired before anyone realized that they still had to do a renewal to pass into the no renewals "zone", and copyright became the life of the author plus some number of years depending on how famous the author was (hence the nick-name for this law as the Mickey-Mouse law -- this was pursued by "Disney" to protect, you got it, Mickey Mouse and the rest). Regards, Steve Thompson On 02/08/2018 06:09 PM, Paul Raulerson wrote: Hi Steve - Borland, 1990, USA, and as far as I can tell, the copyright was not renewed after the product was abandoned. Copyright law in 1990 was still somewhat sane... I am not a copyright lawyer though, so caveat emptor! Typos courtesy of my iPhone and my fat fingers! On Feb 8, 2018, at 16:56, Steve Thompson wrote: I must challenge your statement about the copyright's expiration, or did the author put it in the public domain? In what country was it originally copyrighted? Has the author been dead more than 20 years? [and that death date may be different for the item to pass into the public domain as in the USofA the Mickey Mouse law keeps getting the date shoved further and further into the future.] Regards, Steve Thompson On 02/08/2018 05:24 PM, Paul Raulerson wrote: On Feb 8, 2018, at 4:22 PM, Paul Raulerson wrote: How about the? Object Oriented ASSEMBLER LANGUAGE - from 1990. (grin) Not HLASM, but a fun read for language historians, amateur or otherwise! The manual is out of copyright, and the entire book is available over at Bitsavers, if anyone would like to read it. I reproduced a few pages here to whet your appetites. :) Chapter 4 is the most interesting part to me, and provides an interesting take on the subject I think. Caveat, I never used the OO parts of this assembler, mostly because it just looked like “too much trouble.” I wish I had taken more time to study it back then. In any event… enjoy! http://bitsavers.informatik.uni-stuttgart.de/pdf/borland/turbo_assembler/Turbo_Assembler_Version_5_Users_Guide.pdf <http://bitsavers.informatik.uni-stuttgart.de/pdf/borland/turbo_assembler/Turbo_Assembler_Version_5_Users_Guide.pdf> -Paul On Feb 8, 2018, at 1:36 PM, Seymour J Metz mailto:sme...@gmu.edu>> wrote: I can get down and dirty with machine code, but my standard coding practice is to use lots of macros to automate repetitive tasks, sometimes with different code paths depending on the target processor. As to library overhead, I've certainly written code design to fir well in a PL/I environment and never found the overhead to be unreasonable. And, yes, there is other code where I sweat every cycle, but that's the exception. I can't see using the full OO paradigm in HLASM, but I've certainly seen implementation of parts of it in assembler code. That "definition" isn't a definition, it's simply a list of purport6ed benefits. There are theological arguments about the one true definition, but there is a broad consensus that it includes classes, methods, objects, messages and inheritance. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 <http://mason.gmu.edu/~smetz3>
Re: OOP in HLASM
I must challenge your statement about the copyright's expiration, or did the author put it in the public domain? In what country was it originally copyrighted? Has the author been dead more than 20 years? [and that death date may be different for the item to pass into the public domain as in the USofA the Mickey Mouse law keeps getting the date shoved further and further into the future.] Regards, Steve Thompson On 02/08/2018 05:24 PM, Paul Raulerson wrote: On Feb 8, 2018, at 4:22 PM, Paul Raulerson wrote: How about the? Object Oriented ASSEMBLER LANGUAGE - from 1990. (grin) Not HLASM, but a fun read for language historians, amateur or otherwise! The manual is out of copyright, and the entire book is available over at Bitsavers, if anyone would like to read it. I reproduced a few pages here to whet your appetites. :) Chapter 4 is the most interesting part to me, and provides an interesting take on the subject I think. Caveat, I never used the OO parts of this assembler, mostly because it just looked like “too much trouble.” I wish I had taken more time to study it back then. In any event… enjoy! http://bitsavers.informatik.uni-stuttgart.de/pdf/borland/turbo_assembler/Turbo_Assembler_Version_5_Users_Guide.pdf <http://bitsavers.informatik.uni-stuttgart.de/pdf/borland/turbo_assembler/Turbo_Assembler_Version_5_Users_Guide.pdf> -Paul On Feb 8, 2018, at 1:36 PM, Seymour J Metz mailto:sme...@gmu.edu>> wrote: I can get down and dirty with machine code, but my standard coding practice is to use lots of macros to automate repetitive tasks, sometimes with different code paths depending on the target processor. As to library overhead, I've certainly written code design to fir well in a PL/I environment and never found the overhead to be unreasonable. And, yes, there is other code where I sweat every cycle, but that's the exception. I can't see using the full OO paradigm in HLASM, but I've certainly seen implementation of parts of it in assembler code. That "definition" isn't a definition, it's simply a list of purport6ed benefits. There are theological arguments about the one true definition, but there is a broad consensus that it includes classes, methods, objects, messages and inheritance. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 <http://mason.gmu.edu/~smetz3>
Re: Pu
On 01/31/2018 03:19 PM, Seymour J Metz wrote: I sometimes add references to Wikipedia articles and would like to know whether there is a URL for a current z Principles of Operations manual that does not require an IBM userid. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 I have been having that problem this past week. Web pages that did not need a userid/password, now do. What gives with IBM? The z/OS Tech Library was supposed to be accessible for download by anyone. Anyone a member of SHARE here? Time to make noise at the next SHARE? Regards, Steve Thompson
Re: Fair comparison C vs HLASM
On 01/31/2018 11:39 AM, Robin Vowels wrote: On 31/01/2018 2:53 PM, Paul Gilmartin wrote: On 2018-01-30, at 21:21:49, Robin Vowels wrote: The MVC and CLC instructions of the IBM /360 came years before Unix and C. ... and were available on all but the most primitive S/360 models. The 360 model 30 had MVC and CLC. I believe that nowadays the z has strlen() and strcpy() in microcode. And I understand that RISC processors came long after C. Me, too. Also on the 360-20. Regards, Steve Thompson
Re: Device Independence
On 01/30/2018 03:43 PM, Paul Gilmartin wrote: On 2018-01-30, at 13:33:24, Jon Perryman wrote: Jon wrote: If you specified the attributes needed, then you would not need concatenated datasets. > Paul wrote: No, I have tried TRSMAIN UNPACK with a single UNIX file as archive. FILEDATA, RECFM, LRECL, BLKSIZE all specified. It fails without the prefixed empty data set. If you absolutely hate the concatenated dataset, then try the DCB= where it references a dataset or DDN. Even that may not work if the attribute can not be specified in the JCL. It may even be an attribute outside the JCL DCB. DCB is mutually exclusive with path. IBM answered my SR on SYSEXEC saying the problem was with DSORG. DSORG is mutually exclusive with PATH. I believe that some utilities fail because of device type. It causes me to wonder, why DSORG causes a problem with a path or a file. After all, unless you know something special about the file, aren't all files DSORG=PS -- Physical Sequential in EXT, EXT2, btrfs, hfs, zfs, etc.? Ok, in hfs and zfs they are emulating an FBA device, but still... That's just interesting to me. Regards, Steve Thompson
Re: Fair comparison C vs HLASM
On 01/28/2018 09:47 PM, Paul Gilmartin wrote: On 2018-01-28, at 18:55:32, Steve Thompson wrote: On 01/26/2018 10:05 PM, Paul Gilmartin wrote: On 2018-01-26, at 19:20:02, Jon Perryman wrote: Paul Gilmartin Wrote: Isn't a PL/X flavor of DCB provided? There may be DCB in PL/X. The DCB has many fields to be filled in. Does PL/X require you simply fill in the fields or does it allow abstraction where the programmer specifies a few parameters and the appropriate fields are filled in to fulfill the requirements the programmer specified. How would a mere mortal know any of that? One would be by reading a manual or two of the MVS world. Please provide a link to a PL/X reference manual that I, a mere mortal may read. -- gil My apologies, I read the question relative to MVS I/O, not PL/X which is NOT available outside of IBM (as I was given to understand as a contractor working on AI Languages in the early 1990s). I was only allowed to read the output from PL/?, not the source, except for when reading macros where the PL/? source is embedded in the macro. I am just another person who would be very interested in a PL/? compiler for ISVs and other customers of IBM. Regards, Steve Thompson
Re: Fair comparison C vs HLASM
On 01/26/2018 10:05 PM, Paul Gilmartin wrote:
On 2018-01-26, at 19:20:02, Jon Perryman wrote:
Paul Gilmartin wrote:
Is "full functionality of DCB" useful for any OS other than for z/OS? For z/OS,
allocate with BPXWDYN or JCL DD statement and open by fopen("//DDN:..." ).
BPXWDYN is dynamic allocation and does not provide every feature in DCB. FOPEN
allows some DCB parms to be specified as runtime text that is parsed to fill in
a DCB. Neither actually provides all functionality provided by DCB.
Does DCB provide functionality not available via DYNALLOC?
BPXWDYN has a poorly documented side door allowing specification of SVC 99
text units by code.
Paul Gilmartin Wrote: Isn't a PL/X flavor of DCB provided?
There may be DCB in PL/X. The DCB has many fields to be filled in. Does PL/X
require you simply fill in the fields or does it allow abstraction where the
programmer specifies a few parameters and the appropriate fields are filled in
to fulfill the requirements the programmer specified.
How would a mere mortal know any of that?
One would be by reading a manual or two of the MVS world.
And if one wrote in PL/?, there are commands to drop directly
into ALC and come back (so I'm told, was never allowed access to
PL/S, PL/AS, or PL/X).
A DCB, going back to a prior post (don't remember by whom), does
not have to have every field "defined". That is, one can do a
GETMAIN or whatever in "C" and init it to nulls and then fill in
those fields that one needs. Then issue OPEN against that DCB and
the system will fill in everything else. It will even put in the
address of the read or write routine (GET/PUT, etc.).
Now, if you did it one way, you got QSAM, if another, you got
BSAM, or BDAM, or ISAM (which is no longer supported by IBM),
etc. But NOT VSAM. That requires an ACB as does VTAM.
One does not need HLASM to this. We used to do this with the old
"F" assembler.
And then with DCB, why not DTFxx from DOS/VS? systems. A bit
lower level in what it does, but there are manuals for this too.
Here is the difference between the DOS and MVS worlds: DOS was
device dependent (DTFxx for Cards, Printer, Sequential DASD,
TAPE, ISAM, etc.) and also had to know the format of the data
(Undefined, Fixed, Fixed Block, Variable, Variable Block, etc.).
Let's talk High Level Languages: COBOL does a lot of stuff that
the programmer just doesn't have to know. Comparing that to "c"
is a mistake!
The problem with "c" is that it does not have a defined set of
I/O verbs in the language def that then gets handled by some
predefined routine for that architecture wherein it is being
compiled.
But, we do have "verbs" defined for ALC in the form of Macros
that generates the code to get to the system provided routines.
And as I recall, the system wherein "c" was developed was a
system for handling "telemetry" from C/O Switches (Phone Company
Central Office switches) for doing switch control and billing. So
a sequential string oriented system was the way things were done.
It turned out that MVS/ESA was *so* needed by PACBELL one would
think it had almost been written for them. Back in those days
(1990ish) it was taking them more than 30 days to do billing for
a set of Central Offices (CO) (problem of the Telco's own design
because of ZUM vs. how things were done around Washington DC ---
Long story on that)
So with being able to load a data space, multiple simultaneous
C/O Billing runs could be done and share the big CO-CO billing
table Sorry, this was so long ago I'm forgetting many of the
details on this. But they presented it at a NaSPA local chapter
in the Silicon Valley Area (SPANC, SysProgrammers Association of
Northern California IIRC) at the Boole & Babbage offices right
down the street from Amdahl.
I think you are trying to compare a base ball bat to a mechanical
pencil.
Just my observation. And I do not consider myself to be a c
programmer. Frankly, I can't get past its obtuse pointer handling.
Regards,
Steve Thompson
Re: Fair comparison C vs HLASM
I find it interesting that different report languages that I've dealt with have a very interesting operational methodology that reminds me very much of the fixed logic cycle of RPG/RPGII. Regards, Steve Thompson On 01/22/2018 01:43 PM, Tony Thigpen wrote: I did not say we should use RPGII for a parser. I just think it's still a good choice for 'some' situations, like plain report writing. (Read the statement I quoted.) FYI, I provide support for a large zOS customer that still runs a lot of RPGII. Some interesting facts on RPGII. 1) The product is owned by the same people in Germany that own VSE and zLinux. It is not owned by the language group in Perth. 2) The latest real APAR was back in the 80's. There was a paper-only APAR in the 90's for Y2K describing how to call the date window routine from RPGII, but that is not a 'real' APAR. Personally, I would consider RPGII to be one of the first real 4GL languages. It seems to meet the definition of a 4GL better than the definition of a compiler. Tony Thigpen Charles Mills wrote on 01/22/2018 12:20 PM: I'd like to see an XML parser written in RPG II. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Tony Thigpen Sent: Monday, January 22, 2018 9:18 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Fair comparison C vs HLASM > Both languages have their places, and there are also many > situations where neither one is the best choice. Long Live RPGII. :-) Tony Thigpen Gord Tomlin wrote on 01/22/2018 11:59 AM: On 2018-01-22 10:44, Jon Perryman wrote: I also commented that C is a weak language compared to HLASM and gave some examples that force bad coding techniques (e.g. XML parser). A C programmer took offence because he had written an efficient XML parser in C. Most programmers (whether C or Assembler) would not write their own XML parser. They would call a pre-existing parser. FWIW, in the past, I've done RYO parsing in both languages, and it was less work for me when I did it in C. I'm not here to defend C. It certainly has its warts. But just as it's not good for C programmers to proclaim C to be better than Assembler in each and every case, it's not good for Assembler programmers to do the reverse. Both languages have their places, and there are also many situations where neither one is the best choice. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/
Re: Fair comparison C vs HLASM
You provide the compiler and the specs and I'll give it a whirl. Mind you, I'm rusty with RPGII, but I sure did enough of it in my DOS -> DOS/VSE days. And, come to think of it, a customer had it on MVS in SOCAL during their migration from DOS to MVS (not OS/MFT, but MVS). Also, I have used the conditional assembly feature of F and H level assemblers to do some interesting things, such as generating other languages, JCL, commands for SORT, etc. Been a l-l-l-long time since I did things like that. Regards, Steve Thompson On 01/22/2018 12:20 PM, Charles Mills wrote: I'd like to see an XML parser written in RPG II. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Tony Thigpen Sent: Monday, January 22, 2018 9:18 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Fair comparison C vs HLASM > Both languages have their places, and there are also many > situations where neither one is the best choice. Long Live RPGII. :-) Tony Thigpen Gord Tomlin wrote on 01/22/2018 11:59 AM: On 2018-01-22 10:44, Jon Perryman wrote: I also commented that C is a weak language compared to HLASM and gave some examples that force bad coding techniques (e.g. XML parser). A C programmer took offence because he had written an efficient XML parser in C. Most programmers (whether C or Assembler) would not write their own XML parser. They would call a pre-existing parser. FWIW, in the past, I've done RYO parsing in both languages, and it was less work for me when I did it in C. I'm not here to defend C. It certainly has its warts. But just as it's not good for C programmers to proclaim C to be better than Assembler in each and every case, it's not good for Assembler programmers to do the reverse. Both languages have their places, and there are also many situations where neither one is the best choice. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/
Re: Who'da Thunk about COBOL here? [was Re: Macro processor]
On 12/20/2017 08:15 AM, John McKown wrote: On Wed, Dec 20, 2017 at 6:59 AM, Steve Thompson wrote: Now, I might be able to solve a problem with an ALC module that was written and last touched about 1988 under MVS/SP1. Making this particular module LE friendly, RENT, AMODE(31), and G3 friendly has been painful so far. And who will be able to work on it after those of us who know HLASM and conditional assembly are gone? So I have been tasked to find a solution, and here it was hiding in the COBOL Lang REF. !?!?! Regards, Steve Thompson ps. Sure hope it allows one to build concatenations... Gonna be a lot of experimenting with this. Glad to be of service. I have never tried to allocate a concatenation using the ASSIGN. But it is simple with BPXWDYN. I will have to look that up and see if I can make it work. Regards, Steve Thompson
Who'da Thunk about COBOL here? [was Re: Macro processor]
On 12/20/2017 06:13 AM, John McKown wrote: Which "production" languages would that be? Enterprise COBOL and PL/I _both_ support dynamic allocation of files. COBOL ref: https://www.ibm.com/support/knowledgecenter/en/SS6SG3_6.2.0/com.ibm.cobol62.ent.doc/PGandLR/ref/rliosass.html Thank you for this. We have scanned the various COBOL References trying to find dynamic allocation (files). But what we found was that "dynamic allocation" is for STORAGE OBTAIN. Never gave it a thought to look at ASSIGN for this. Now, I might be able to solve a problem with an ALC module that was written and last touched about 1988 under MVS/SP1. Making this particular module LE friendly, RENT, AMODE(31), and G3 friendly has been painful so far. And who will be able to work on it after those of us who know HLASM and conditional assembly are gone? So I have been tasked to find a solution, and here it was hiding in the COBOL Lang REF. !?!?! Regards, Steve Thompson ps. Sure hope it allows one to build concatenations... Gonna be a lot of experimenting with this.
Re: edmk instruction
On 11/01/2017 08:33 PM, retired mainframer wrote: Where did the $ come from? "Does the customer really want something like 0$10245670 ?" EDMK is for "floating" in a character, typically in the US, a "$". So I used that example result to attempt to demonstrate what the results might look like using EDMK with the edit pattern being given. Now we know s/he really doesn't want an edit pattern, so I do not understand why the EDMK or ED instruction. But s/he may have other things going on with this program that they may not be at liberty to discuss. Regards, Steve Thompson -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER- l...@listserv.uga.edu] On Behalf Of Steve Thompson Sent: Wednesday, November 01, 2017 2:44 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: edmk instruction Does the customer really want something like 0$10245670 ? Because with EDMK and the mask you have specified that is pretty much how this is going to work (as least the first three looks I took at this trying to figure out why the edit mask was written the way it is). Regards, Steve Thompson On 11/01/2017 03:29 PM, Sokolsky, Hayim Z. wrote: Just a try of the top of my head ... MVC OUTPUT(15),=X'F0202020202020202020202020202120' EDMK OUTPUT(15),NUMBER
Re: edmk instruction
On 11/01/2017 06:00 PM, Charles Mills wrote: Charles, forgive me but not only do I agree with you, I think your two points are worth drawing a lot of attention to. Pay attention to that fill character and "significance." ^^ -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Steve Thompson Sent: Wednesday, November 1, 2017 2:44 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: edmk instruction Does the customer really want something like 0$10245670 ? Because with EDMK and the mask you have specified that is pretty much how this is going to work (as least the first three looks I took at this trying to figure out why the edit mask was written the way it is). Regards, Steve Thompson On 11/01/2017 03:29 PM, Sokolsky, Hayim Z. wrote: Just a try of the top of my head ... MVC OUTPUT(15),=X'F0202020202020202020202020202120' EDMK OUTPUT(15),NUMBER The first character in the output field is the "fill" character. In this case it's a C'0'. So even though all the x'20' characters prior to the x'21' get replaced by fill, it's zero anyhow. The only difference between ED and EDMK is pointing R1 to the first significant digit. Hayim Sokolsky Director, Senior Mainframe Security Architect Security Architecture and Technology Technology Risk Management DTCC Tampa Direct: +1 813 470-2177 | hsokol...@dtcc.com Visit us at www.dtcc.com or follow us on Twitter @The_DTCC and on LinkedIn. To learn about career opportunities at DTCC, please visit dtcc.com/careers. Classification: DTCC Public (WHITE) The views I have expressed in this email are my own personal views, and are not endorsed or supported by, and do not necessarily express or reflect, the views, positions or strategies of my employer. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Greg Gray Sent: Wednesday, November 01, 2017 15:07 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: edmk instruction I have a field PL7 that contains a number (dollar amount) and I have to output that amount into a CL15 output field. The customer would like for the remaining characters other than the digits for the amount to be zeros, i.e., 0012391. I am trying to code a EDMK pattern with no success, has anyone ever completed such a task? DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
Re: edmk instruction
Does the customer really want something like 0$10245670 ? Because with EDMK and the mask you have specified that is pretty much how this is going to work (as least the first three looks I took at this trying to figure out why the edit mask was written the way it is). Regards, Steve Thompson On 11/01/2017 03:29 PM, Sokolsky, Hayim Z. wrote: Just a try of the top of my head ... MVC OUTPUT(15),=X'F0202020202020202020202020202120' EDMK OUTPUT(15),NUMBER The first character in the output field is the "fill" character. In this case it's a C'0'. So even though all the x'20' characters prior to the x'21' get replaced by fill, it's zero anyhow. The only difference between ED and EDMK is pointing R1 to the first significant digit. Hayim Sokolsky Director, Senior Mainframe Security Architect Security Architecture and Technology Technology Risk Management DTCC Tampa Direct: +1 813 470-2177 | hsokol...@dtcc.com Visit us at www.dtcc.com or follow us on Twitter @The_DTCC and on LinkedIn. To learn about career opportunities at DTCC, please visit dtcc.com/careers. Classification: DTCC Public (WHITE) The views I have expressed in this email are my own personal views, and are not endorsed or supported by, and do not necessarily express or reflect, the views, positions or strategies of my employer. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Greg Gray Sent: Wednesday, November 01, 2017 15:07 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: edmk instruction I have a field PL7 that contains a number (dollar amount) and I have to output that amount into a CL15 output field. The customer would like for the remaining characters other than the digits for the amount to be zeros, i.e., 0012391. I am trying to code a EDMK pattern with no success, has anyone ever completed such a task? DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
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: ASSEMBLER-LIST Digest - 18 Mar 2017 to 19 Mar 2017 (#2017-31)
On 03/20/2017 07:45 PM, 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. I have worked on a One's complement machine. As I recall (it has been more than 35 years since I was programming a Univac 1100 machine) Two's complement prevents a "math/logic" error. And I just can't remember for sure what it was. It may have been that -0 could be a "valid" result when doing one's complement. So, don't be so hasty to shoot down two's complement. And in many places were I have worked on IBM and Wang VS systems, the standards required packed decimal except for Indexes, so that numbers could be read in a dump. Me being an ALC programmer, didn't care because I had a trusty TI Programmer, or the equivalent from Casio, so I could decode Fixed point binary as well as Float. Now, I'm going to sit back and eat some more pop-corn while you guys argue this thing out. But I still think the way we have been doing things is the right way to handle it. However, you could, if you really wanted to, ORG back over the instruction and stick whatever it is you want in the Immediate Byte(s). But don't forget to also code " ORG , " after you do this just to keep from screwing the instruction counter... Regards, Steve Thompson
Return of Dr. John
On 02/26/2017 12:21 AM, John Ehrman wrote:
Well, maybe not. I was laid off ("retired") by IBM last June, and managed to
get back to this list only a few days ago. I'll try to keep active if I haven't forgotten
too much.
John Ehrman
Glad to have you back.
And I figured you were "offered" early retirement given how
things are going at IBM these days.
Regards,
Steve Thompson
Re: HLASM anomaly
On 02/23/2017 01:16 PM, Paul Gilmartin wrote: On 2017-02-23, at 10:31, Steve Thompson wrote: Informative? Or Warning? Do you then disagree with warnings on multiple base-displacement resolutions? I sometimes run into this, and can't figure out why the assembler even issued the message. But when it happens I do verify that it is using the correct base. This is actually a problem going back to the "F" Assembler. It was a source of errors, difficult to analyze. Nowadays, the best way to suppress this is with the "end" operand of the USING instruction. In other cases, it may be necessary to: PUSH USING DROP USING ... ... POP USING And the warning assumes 12-bit displacement. I believe it is not issued for longer displacements. And with the advent of negative displacements there is a need for a "begin" qualifier as well as "end" on USING. I use it all the time and still get warning of multiple base-displacement resolutions. My gripe is, I removed a "," from the end of a line on purpose, and because it is marked as continuing, I get a warning. That didn't use to happen. This was done to test certain expansions of Macros, or not pick up a debugging keyword (on the last line of the continuation). Grrr. This shows that Assembler syntax was descriptive, not prescriptive. Programmers used unspecified constructs that generated no error messages or only warnings, and came to depend on them, and they had to become part of the documented syntax. There was no a priori decision on whether a continuation needed be indicated by a comma, or a mark in column 72, or both. Way back when, this was documented. If you needed to continue the line, you had to have a non-blank character in 72. What you may be continuing is a comment, but never-the-less, it required a non-blank in cc72. And as I recall, a non-macro statement for DOS could only be continued for 3 lines. OS had a different limit. As each "generation" of assembler came out, more limits were lifted, more stuff supported. Finally we have HLASM. On Wed, 22 Feb 2017 16:18:38 -0500, Melvyn Maltz wrote: Immediate operands won't accept a duplication factor...why not ? Can't find a reason in the HLASM manual Try these... AHI R1,2X'FF' AHI R1,X'' AHI R1,-1 How do you (and HLASM) feel about?: AHI R1,X'00' Earlier, I said self-defining term. I think that should have been non-relocatable expression (and I don't think a constant with a duplication factor is an expression). What are the limits on the operand of AHI? What of: AEQU -32768 DC Y(A) AHI R1,AOK, I believe. BEQU 32767 DC Y(B) AHI R1,BOK, I believe. cEQU 65535 DC Y(C) AHI R1,COK ??? Is the operand of AHI treated modulo 2^16, or ? -- gil
Re: HLASM anomaly
On 02/23/2017 10:09 AM, Paul Gilmartin wrote: On 2017-02-23, at 07:57, Steve Thompson wrote: Ah, I see why you all are having a problem with this. And me, being an old ALC programmer, this is intuitively obvious. In fact, there are several changes to HLASM that I disagreed with, because they then caused programs I had written earlier to start getting informative messages, where they didn't get them before. Informative? Or Warning? Do you then disagree with warnings on multiple base-displacement resolutions? I sometimes run into this, and can't figure out why the assembler even issued the message. But when it happens I do verify that it is using the correct base. This is actually a problem going back to the "F" Assembler. My gripe is, I removed a "," from the end of a line on purpose, and because it is marked as continuing, I get a warning. That didn't use to happen. This was done to test certain expansions of Macros, or not pick up a debugging keyword (on the last line of the continuation). Yeah, I'm that old. And somewhere I still have the manuals for that level of ASM so I can figure out certain things about conditional assembly when I run into confusion because the HLASM's manuals don't describe things as well as it used to be done (and Dr. Ehrmann and I had discussed this at one point). So, you want the immediate area to be filled with a replication. But that means that the assembler now must pay attention to the replication value -- which it may not know until after the instruction has to be generated, and ensure that it does not exceed the immediate are of the instruction. Any self-defining term ought to be acceptable as an immediate operand. But can a self-defining term contain a replication factor? On Wed, 22 Feb 2017 16:18:38 -0500, Melvyn Maltz wrote: Immediate operands won't accept a duplication factor...why not ? Can't find a reason in the HLASM manual Try these... AHI R1,2X'FF' AHI R1,X'' AHI R1,-1 How do you (and HLASM) feel about?: AHI R1,X'00' -- gil
Re: HLASM anomaly
Yeah, I just answered another post on this. It explains my error -- I was reading fast and thinking 1 byte immediates, not the multi-byte of the newer instructions. Still stuck in pre-z/Arch instructions. But, I am slowly using the newer ones. Regards, Steve Thompson On 02/23/2017 09:28 AM, Charles Mills wrote: Replication would then expand outside of the instruction and into the instruction stream Not necessarily. AHI R1,2X'FF', were it valid, would presumably generate exactly the same machine code as the valid AHI R1,X''. One could, for example, write a series of macros (with names for example like AHI@) that would accept immediate operands with replication factors exactly as the OP wished, and assemble them into valid machine code. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Steve Thompson Sent: Thursday, February 23, 2017 4:56 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: HLASM anomaly What does "immediate" mean to you? In this case, it means immediately available within the instruction itself. Replication would then expand outside of the instruction and into the instruction stream. That would then cause the next byte, beyond the instruction, to be an OPCODE by instruction fetch (IF) using the PSW's Instruction counter (IC). When an instruction is fetched, the IC is advanced by the length of the instruction -- which is based on the OP code (it defines the length of the instruction). Accordingly, there is nothing in the instruction to tell IF that this instruction has a different length for updating the IC. It would help to read the Principles of Operations manual for more than just the instructions that you want to use. Understanding how the machine actually works can keep you out of trouble and make use of nuances at the same time. Regards, Steve Thompson On 02/22/2017 04:18 PM, Melvyn Maltz wrote: 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: HLASM anomaly
Ah, I see why you all are having a problem with this. And me, being an old ALC programmer, this is intuitively obvious. In fact, there are several changes to HLASM that I disagreed with, because they then caused programs I had written earlier to start getting informative messages, where they didn't get them before. And when I first scanned the instructions, I was going quite fast, and didn't catch the need for more than 1 byte of immediate data. So, you want the immediate area to be filled with a replication. But that means that the assembler now must pay attention to the replication value -- which it may not know until after the instruction has to be generated, and ensure that it does not exceed the immediate are of the instruction. And the more such logic that is added to HLASM, the slower it gets (my problem with this stuff). I wish that IBM had made PLX or PL/AS a product for you High-level Language programmers to work with... Regards, Steve Thompson On 02/23/2017 08:41 AM, Robin Vowels wrote: From: "Steve Thompson" Sent: Thursday, February 23, 2017 11:55 PM What does "immediate" mean to you? In this case, it means immediately available within the instruction itself. Replication would then expand outside of the instruction Why? It is an Immediate instruction. and into the instruction stream. That would then cause the next byte, beyond the instruction, to be an OPCODE by instruction fetch (IF) using the PSW's Instruction counter (IC). When an instruction is fetched, the IC is advanced by the length of the instruction -- which is based on the OP code (it defines the length of the instruction). Accordingly, there is nothing in the instruction to tell IF that this instruction has a different length for updating the IC. It would help to read the Principles of Operations manual for more than just the instructions that you want to use. Understanding how the machine actually works can keep you out of trouble and make use of nuances at the same time. Regards, Steve Thompson --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: HLASM anomaly
What does "immediate" mean to you? In this case, it means immediately available within the instruction itself. Replication would then expand outside of the instruction and into the instruction stream. That would then cause the next byte, beyond the instruction, to be an OPCODE by instruction fetch (IF) using the PSW's Instruction counter (IC). When an instruction is fetched, the IC is advanced by the length of the instruction -- which is based on the OP code (it defines the length of the instruction). Accordingly, there is nothing in the instruction to tell IF that this instruction has a different length for updating the IC. It would help to read the Principles of Operations manual for more than just the instructions that you want to use. Understanding how the machine actually works can keep you out of trouble and make use of nuances at the same time. Regards, Steve Thompson On 02/22/2017 04:18 PM, Melvyn Maltz wrote: 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: ASMA435I
Yes, that did not exist when I was doing all that. And I have not looked at the exit doc for HLASM for several years now. So I can't speak to the Unix I/O control block interface. Sent from my iPhone > On Nov 27, 2016, at 11:49 AM, Paul Gilmartin > <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > >> On 2016-11-27, at 08:58, Steve Thompson wrote: >> ... >> As a result, it knows from where the macros come from that you specify in >> your assembly because that is a very static situation, unless you decide to >> use HLASM exits in a "strange" way to inject code into the stream. >> > IIRC, using those exits the interface allowed setting in a > control block the values to appear in ASMA435I, though with an > uncomfortable 44-character limit. > > And it remains a myestery what the DEB contains for a UNIX > directory. > > Thanks, > gil
Re: ASMA435I
A bit more to Binyamin's explanation. Back in the '90s when I was working on ACS/WYLBUR, I needed to change the SYSLIB concatenation during "assembly time", and so I created the ASYSLIB "directive". Just so you know and understand, "ASYSLIB" allowed one to change the SYSLIB concatenation as often as needed. This way you could have the SYSLIB DD point to the current SCP level, and SYSLIB2 DD (or whatever name you wanted as long as it did not conflict with any other HLASM was using) could point to a different SCP or even ISV list where the macro names could be in conflict with IBM's macro names. And then ASYSLIB with no operand would take you back to the default SYSLIB DD. So I wrote all the code for it (and the doc), but then noticed that I was being told that the "yyy" macros were coming from SYS1.AMODGEN (in those days, we had various levels of code for SCPs, JES2, JES3, ISVs, etc.), when SYS1.* wasn't in that concatenation. I can't remember if I published ASYSLIB or not. I know I didn't send it off to CBT, and I wish I had. But since ACS owned all of it (since I was an employee of theirs at the time), the full ASYSLIB system I wrote (including PUSH/POP ASYSLIB) never made it outside of our development lab. Meanwhile, I had thought that HLASM was doing things one way, when it was doing it another. Dr. Erhman and I talked, and he realized that upon changing the concatenation (by changing DD names), he had the code still using what it had been using -- the list for SYSLIB that he had already obtained. I never tried having a secondary SYSLIB (e.g. SYSLIB2) having more DSNs in it than the SYSLIB to see what kind of error would have happened...). And so, it was agreed that this was a "FIN" issue, and the next release of the HLASM had the fix for this. And to put it as simply as possible (since Dr. John didn't share what he did exactly) HLASM today knows to check the DDname being used to make sure it matches the one it had been using. As a result, it knows from where the macros come from that you specify in your assembly because that is a very static situation, unless you decide to use HLASM exits in a "strange" way to inject code into the stream. HTH, Steve Thompson On 11/27/2016 02:07 AM, Binyamin Dissen wrote: RDJFCB + BLDL - look at the "C" value. On Sat, 26 Nov 2016 19:15:34 -0700 Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: :>A couple recent threads on IBM-MAIN asked, "How can I tell where :>my load module came from?" and "How can a Rexx EXEC know where :>it came from?" :> :>The consensus (I call it a consensus because I joined it) is :>that it's damned hard. Once a library is OPENed there's little :>information but the DEB which contains only UCBs and TTRs (well, :>lotsa other stuff, but it's no help). :> :>Yet, HLASM effortlessly produces: :> ASMA435I Record 1 in user.ASM(FROMPDS) on volume: 00
Re: Rif: Re: EXECUTE Instruction and location of its target instruction
You can make a macro that will do this. At Amdahl we had such at one time. Where I currently work, we have a macro called ALIGN. It was developed long before the G3 chipset (where 256byte cache lines came about IIRC). If you make use of &SYSPARM you could control how your expansion works, by passing in the cache line info in some fashion. For now, I use it to make static storage start on a new cache line -- by making the CSECT start on a page boundary. Note, HLASM can't align to something unless you have a known starting point. So by making your CSECTs be page aligned, you can know what will be 32byte, 256byte, etc aligned. Should alignment of cache not be evenly placed in pages, there goes that methodology. Sent from my iPhone > On Nov 23, 2016, at 7:50 PM, Paul Gilmartin > <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > > Does HLASM have an instruction to cause cache line alignment? Such an > instruction would need to be model-sensitive, perhaps governed by OPTABLE. > > -- gil
Re: EXECUTE Instruction and location of its target instruction
BTW -- I understand your situation. I have ALC code that I have to bring forward from a 1980ish coding style to RENT and G3 chipset compliant. And while it is high priority to get done, I get hit with higher priority work. So I get limited time to actually make things happen. I make large use of IBM macros to generate relative branch from old style, so I don't have to physically touch the instructions. That gives me time to solve I/D bank collisions among other RENT problems. Sent from my iPhone > On Nov 23, 2016, at 9:32 AM, Philippe Cloarec > wrote: > > Hi Steve, > Thx for your input, yes this is my understanding of the process. > Philippe
Re: EXECUTE Instruction and location of its target instruction
As long as the target of the execute is not in a D-bank cache line, you shouldn't see a big "hit" in processing cycles. If it is, then it has to be flushed out, refetched to I-bank, pulled into the pipe, processed, flushed back out, and then back to D-bank (if still needed). This is based on my memory of the process when we first went to 256 byte cache lines w/ I/D bank caching. Sent from my iPhone > On Nov 23, 2016, at 4:57 AM, Philippe Cloarec > wrote: > > Hi Rob, > > ref:It's in the same cache line or it's not. > > Actually this was exactly my point and I was confused about seen various > coding approaches to reach that purpose to optimize > as much as possible CPU use. > > later > > Philippe
Re: Question on using DYNALLOC
I like this, particularly because of the explanation that goes with it as to why you want to do things this way. But, might I suggest that you do the member name in lower case? That way, you can see it, and I think ISPF will allow you to view/edit it if you need to while fixing a problem if your JOB fails for any reason. Regards, Steve Thompson On 11/11/2016 07:58 AM, John McKown wrote: On Fri, Nov 11, 2016 at 6:33 AM, Ward Able, Grant wrote: Ah rats! Looks like I am going to have to use a new member name every time. Thanks Paul. Now to code up a member name lookup piece of code.. I think the following will work. Allocate the DSN(MEMBER) with a DISP=OLD (for integrity) or SHR (if it's a PDSE or you're a gambler). Now, do an OPEN on _two_ different DCBs for the DD. First OPEN a DCB for _input_. Then OPEN a second DCB for _output_. When you OPEN a member of a PDS for _output_, the access method always positions to write at the end of the PDS, into "unused" space. You can now read records from the INPUT DCB and write them immediately to the OUTPUT DCB. At EOF on the input DCB, close the input DCB. Continue writing the new information to the output DCB. Finally, close the output DCB. This will do a STOW to actually update the PDS directory so that the member name now points to the new version of the member. Until the output DCB is closed, the PDS directory continues to point to the old member. But remember that an ABEND will do a close and _will_ update the directory so you _could_ loose the original member contents. What I'd suggest doing is similar to what you indicated, use a new member name. Being a weird-o. Remember that all member names are exactly 8 characters in length! The ones that look shorter are actually padded on the right with blanks. Also, remember that all byte combinations, with the exception of 8X'FF' are valid as a member name, though the non-printables can't be used in JCL or TSO ALLOCATE or BPXWDYN. So, weird person that I am, I would use SVC 99 (which I am fairly sure will accept non-printables as a member name) as you do above but make the member name be equal to the original member name, with the last character being X'00'. Now copy the original contents to the new member. Eventually you will close both the input & output DCBs successfully. Now, allocate the same DSN, but without a member name. Open a BPAM DCB on this, rather than the "normal" QSAM / BSAM you would for a member. Use a STOW delete function to delete the original member name. Lastly use a STOW rename to change the "weird" member name to the original member name. I, personally, feels that this is the safest way to "update" a member of a PDS without coming up with a "new" name all of the time. Of course, my method is a bit on the paranoid side. But, remember, just because you're paranoid doesn't mean that they aren't out to get you. Bugs, that is. And, it was just a weird idea (from a grand master). Regards – Grant. 201496 (Internal phone) +44 (0)2076501496 (External phone)
Got it working....
Sorry folks, too many interruptions, battling with FF on SUSE Linux and Chrome. I finally got logged in, and got me re-established. And thank you Jean Snow. You caused me to realize that I have to get my logon recovered with the list server so I could fix things. Regards, Steve Thompson
Test of List
The last email I've gotten from the list was 10JUN2010. Is this list still working? Regards, Steve Thompson
COBOL CALLing ALC ...
I am trying to determine how I am supposed to know if a COBOL program is AMODE=31/ANY when they call an ALC subroutine. The routine getting control has just been through an upgrade from 1979 style of NOREUS and data mixed in with instructions. Also, this routine is not LE conforming. It has never been. I'm used to doing a BSM to return as a subroutine to have addressing modes match. I had assumed that the caller did BSSM not just BASR or BALR So when the program ends and returns to the caller via BSM R14, wow, you would not believe all the ESTAEs that get driven (including this programs ESTAEX). LE throws a fit and thankfully, having set up SYSMDUMP with DISP=MOD, I get the dump I need and IPCS ignores the second dump. ;-) So, R14 does not have the hi-order bit on when I am called. COBOL being used is Enterprise COBOL 4.2 (which is currently supported). The environment, just so we are all on the same page is JES2, z/OS 2.2, z13EC. Regards, Steve Thompson PS. I have been scanning various manuals (including the LE one) and nothing is said about this. And I don't have any MVS/XA or MVS/ESA manuals around anymore.
