Re: Load and Add
On 2/19/2013 7:09 AM, Steve Conway wrote: Paul Gilmartin wrote, in response to Ed Jaffe: I perceive a bit of expert's elitism, even narcissism in that rhetoric: "If you don't already know that, you're beneath my attention!" (I've tripped over the convention myself, at times.) You obviously don't know Ed Jaffe. You read a whole lot more into his post than he put there. Classic projection. ;) I have a personal and professional interest in identifying and working with folks who are new to our platform. I am actively involved, especially in conjunction with the MVS Program and zNextGen at SHARE, in helping to identify real and/or perceived problems/barriers through which new folks must work once they suddenly find themselves immersed in a mainframe environment (especially z/OS). I assumed that HLASM "old timers" would be so familiar with the conventions used in PoOp that the "second operand" discussion would not have originated with them--thus my inquiry as to the experience level of the OP along with an attempt to explain my rationale for asking. This is an area of great general interest to the mainframe community at large. The topic of shortages of mainframe skills and so-called "vitality hires" dominated the "Ask the Experts Panel and MVS Program Closing" at SHARE in San Francisco -- a session over which I preside as MC. The discussion involved so many different people and points of view that not one single technical question was asked! (First time ever for such a discussion, I think...) In case you were wondering, there most definitely ARE new, young, highly-skilled and motivated HLASM programmers entering the workforce. Most of them work for IBM and ISVs. Vit Gottwald (from CA Technologies), co-Project Manager of the zNextGen Project at SHARE, is one such person. Vit took a few minutes during the above-referenced SHARE session, to explain what excites him about our platform. The audience applauded when he told them that being able to program in HLASM was the primary reason he took his current job! The other zNextGen co-Project Manager is Linda Mooney who is a great example of how a person can be new to the platform without also being fresh out of school. [Aside: If you're interested in getting involved with zNextGen, search for and join their groups on Facebook and/or Linked-In. I believe there are currently about 700 members. More are always welcome...] Modernization efforts are underway to try to make configuring, managing, and even programming a mainframe more "user friendly" to folks that are new to the platform. (Some examples from IBM are z/OSMF and RDz. ISV's are doing some great things in this realm as well. I reviewed some of Phoenix Software International's mainframe modernization strategy during my Valentine's Day webinar, hosted last week by IBM Systems Magazine.) The efficacy of these efforts has yet to be fully measured and realized. In any case, a change to the conventions used in PoOp is unlikely to be a candidate for any such effort. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/
Re: Load and Add
On 2/18/2013 2:19 PM, Bodoh John Robert [Contractor] wrote: I couldn't disagree more. The document was written in English. I presume that, being written in English, it was meant for people that speak English. In every context that I can remember, "second operand" always referred to the operand that was in the second position. I have never heard of the phrase "second operand" to refer to a subscript. I don't necessarily disagree with your logic, but I must ask: How long have you been reading Principles of Operation? Are you new to the platform? Many of us on this list have been using the "bible" since the 1980s, 1970s or even (in some cases) the 1960s and we are well acquainted with the conventions used throughout the book. Even if they might seem arcane to some, my point was that they are what they are and have always been. Changing them now would require tremendous effort--arguably wasting precious IBM hardware development resources. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/
Re: Load and Add
On 2/18/2013 12:37 PM, Bodoh John Robert [Contractor] wrote: That's right, the operands are listed after the mnemonic. However, my presumption was the "second operand" is referring to the operand that is in the second position. It is very confusing to say "second" refers to the subscript. It has always been thus. The reason for the subscript is to denote which operand is being discussed--since storage operands are routinely broken up into pieces e.g., B2 and D2. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/
Re: DSPSERV with SCOPE=?
On 2/11/2013 7:59 AM, Paul Gilmartin wrote: On Feb 11, 2013, at 08:37, Bill Fairchild wrote: In order to make a simple trick like this easy to maintain by someone else in the future, or even myself (since my intricately detailed memory is rather short-lived), I would want to write so much documentation into the code that I would rather spend much less time and write three copies of the macro to make the code triple-pathed. Dismayingly, when there are multiple options, the multiplicity grows exponentially. The MF=M form of RACROUTE is sooo nice for situations like this. I wish all macros had that! We once had a situation where we coded two GETMAIN macros in a service (one for MVS/SP and one for MVS/XA. Yes, this was a long time ago...) Then we needed boundary=page as an option; suddenly it was four macros. Before too long we had 32 GETMAINs coded! From experience I can tell you it's NOT easier to read and NOT easier to maintain 32 macros (and the logic to get to them) than it is to maintain ONE stream of conditional IF/ENDIF with modification of a single parameter list--preferably via the MF=M form macro. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/
Re: SVC 34
On 2/7/2013 5:24 PM, retired mainframer wrote: I didn't think water cooled machines were still supported. zEC12 can be water cooled for those that wish to save energy in their data center. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/
Re: Debugger and Structured Programming Macros
On 1/22/2013 7:06 AM, Bodoh John Robert wrote: We use the IBM debugger program to unit test assembler programs. We also use the structured programming macros. When viewing the source code in the debugger, all of the internal macros used by the structured macros also are displayed. This results in cluttering the screen with these macros. This makes following the flow of the program difficult. Is there an option either in the assembler or the debugger that will eliminate these internal macros from the display? Many years ago there was a similar problem with z/XDC. I reported it to Dave Cole and he fixed it. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/
APAR OA41232 Opened Today
I thought some of you on this list might be interested... WARNING: you cannot AMASPZAP a module compiled with SECTALGN(16). Only lower and higher SECTALGN values are supported. This has caused us some grief in the field. The ability to ZAP a module to provide temporary relief for a customer problem is fairly important... :\ APAR Identifier .. OA41232 Last Changed 13/01/17 AMASPZAP CANNOT PROCESS A MODULE COMPILED WITH SECTALGN(16) Symptom .. IN INCORROUT Status ... INTRAN Severity ... 3 Date Closed . Component .. 5752SC112 Duplicate of Reported Release . 780 Fixed Release Component Name SVA UTILITIESSpecial Notice Current Target Date .. Flags SCP ... Platform Status Detail: Not Available PE PTF List: PTF List: Parent APAR: Child APAR list: ERROR DESCRIPTION: AMASPZAP can't process modules that are compiled with SECTALGN(16). Only lower and higher values can be zapped. LOCAL FIX: none -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/
Re: SVC 34
On 1/16/2013 2:26 PM, Ward, Mike S wrote: Can anyone please tell me where the description on how to use SVC's in z/OS is. I remember back when there was a book devoted to MVS svc's and the parameters required to call them. I can't seem to find one for z/OS. MGCR/MGCRE is described in Authorized Assembler Services Guide and Reference. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/
Re: 64Bit Addressing and CALL
On 12/20/2012 12:36 PM, esst...@juno.com wrote: I have a program that loads CSRSI, It obtains Storage for the response area, and invokes CSRSI via a Call I wanted to replace the STORAGE MACRO with IAVR64 So I believe the program could be re-wriiten as follows: * LOAD EP=CSRSI Load CSRSI Function STR0,CSRSI@ Save Address Of CSRSI Function * IARV64 REQUEST=GETSTOR,SEGMENT==AD(MAXSIZE), ORIGIN=ORIGIN,MF=E,IARV64,COMPLETE) * LGR0,ORIGIN Get Starting Address Of Memory Object STG R0,CSRSI_INFO@ Store Mem-Obj Address for CSRSI SYSSTATE AMODE64=YES,ARCHLVL=2 L R15,CSRSI@ Load R15 with CSRSI Address CALL (R15),(CSRSI_TYPE,CSRSI_INFOLEN,CSRSI_INFO@,CSRSI_RC) LTR R15,R15 Examine Return code BNZ BAD_CSRSI No, Exit Multiple issues here. If this service *could* be called in 64-bit mode, then you would probably need to use LGF with LINKINST=BASSM to invoke it and probably using PLIST8 for the parm list. But, that is all moot because the service supports 24- and 31-bit addresses only. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/
Re: Use of "sequence numbering" in current HLASM source?
On 11/7/2012 7:21 AM, McKown, John wrote: So, other than being "non main stream" and even "obsessively weird", is there any *technical* reason to maintain sequence numbers? We got rid of sequence numbers in the majority of our HLASM source code long ago. Only source code that is distributed to customers (for exits and such) has them. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: ASMLANGX files
On 11/6/2012 7:01 AM, Chuck Arney wrote: I'm sure there are a number of tool providers that would like to take advantage of smaller formats of ADATA. Each provider could roll their own, but a standard published format would of course be more desirable for the good of both provider and user. The ADATA format is published exactly for this reason. Why not the ASMLANGX format? I think this is a very sensible suggestion. How about making it a SHARE requirement? -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: ASMLANGX files
On 11/5/2012 7:48 AM, David Cole wrote: Does anyone know if the internal format of ASMLANGX files has been published? Some of our ADATA libraries are larger than an entire 3390 mod3! XDC use of the more compact ASMLANGX format would be most welcome... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Curosity Question
On 11/2/2012 7:40 AM, Bill Fairchild wrote: Rather than belabor this issue any further, if you could post a link to some explanation of the mathematical proof why clustering occurs around prime factors of a composite modulo, I would love to read it and try to understand what is going on. ISTR that Knuth provides this proof in his SaS book. Unfortunately, it's in my other office so I can't check for myself until Monday... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Weird Metal C problem
On 10/28/2012 9:46 PM, Edward Jaffe wrote:
On 10/27/2012 10:01 AM, Johnny Luo wrote:
#include
#include
void main()
{
_asm(" here we are " );
}
Shouldn't it be __asm instead of _asm?
A test conducted under z/OS 1.13 shows that _asm is an external function whereas
__asm inserts the supplied text directly into the METALC assembler language
output:
*_asm(" here we are ");
LR14,11
OILH 14,X'8000'
L 15,=V(@ASM)
LA1,76(,13) #MX_TEMP1
ST14,76(,13) #MX_TEMP1
MVC 8(4,13),#NAB_1
BASR 14,15
here we are
*__asm(" here we are ");
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/
Re: Weird Metal C problem
On 10/27/2012 10:01 AM, Johnny Luo wrote:
#include
#include
void main()
{
_asm(" here we are " );
}
Shouldn't it be __asm instead of _asm?
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/
Re: Conditional Sequential RLDs
On 9/26/2012 11:36 AM, Duffy Nightingale wrote: I just used this and I run on an old system (something that is very desireable for a software company). I thought it was cool because I have a table full of the V() and the addresses are all automatically filled in. We used to use V-cons but when we started writing 64-bit code in 2002 we changed them all to A-cons. We use pointer-defined linkage *everywhere*! The problem is that the HOBSET binder option, which sets the high-order bit in a 32-bit word for AMODE(31) EPAs, does not set the equivalent low-order bit for 64-bit EPAs in a doubleword. And, there is no LOBSET option. :( -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: The Transaction state (was Model 2827 New Instructions)
On 9/22/2012 12:55 PM, Binyamin Dissen wrote: On Fri, 21 Sep 2012 08:20:38 -0700 Edward Jaffe wrote: :>There are existing search/update models in which the "runner" performs its :>search using only block-concurrent instructions (such as L) without :>serialization and then checks later whether a retry is needed. A good example is :>IEANTRT. That code is FAST because the "retrieve" function never serializes :>against the "update" function. Wonder how the delete works. Perhaps it leaves the storage orphaned? Otherwise the scan, if interrupted, could be left with a link pointer to nowhere. A delete does not leave storage "orphaned", but it doesn't release it either. The entry is simply made available for reuse by another create. The total amount of storage required gradually increases until it reaches a high water mark. We use similar techniques in some of our queue managers. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: The Transaction state (was Model 2827 New Instructions)
On 9/21/2012 5:01 AM, Peter Relson wrote: Of course Binyamin is right. Since the "runner" can get interrupted, then the runner needs to run within a transaction too. (Getting interrupted includes the z/OS LPAR getting interrupted by LPAR processing, which covers even the disabled PSW case) There are existing search/update models in which the "runner" performs its search using only block-concurrent instructions (such as L) without serialization and then checks later whether a retry is needed. A good example is IEANTRT. That code is FAST because the "retrieve" function never serializes against the "update" function. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Model 2827 New Instructions
On 9/18/2012 2:09 PM, John Gilmore wrote: Tony H: I have already marked the typos I h ave found in SA22-7871-07. I plan to send them to John Ehrman, who will see to their annihilation; and I urge you to send yours to him too. Better yet, send them to Dan Greiner. Ed Jaffe
Re: which instructions should I use?
On 8/29/2012 11:07 AM, John Ehrman wrote: But be careful: I've seen many examples of poor coding practices that -- simply because they were familar -- were propagated from one program to another, to the detriment of all. When I worked for a large bank in the 1980s, and saw how "new" JCL was constructed there, I conjectured that all batch JCL is descended from the same singular job stream. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: which instructions should I use?
On 8/29/2012 6:33 AM, John Gilmore wrote: Second, and more important, while Mr Dissen's notion that stereotyped, 'easy to understand' code sequences are to be prized "in the real world" is his to cherish, I find it unattractive. Such sequences, often copied unreflectively from elsewhere, are too often the foci of error. Failure to take thought is but seldom a virtue, even in "the real world" that Mr Dissen inhabits.. Keep in mind that some 'stereotyped' code sequences are so common that the hardware contains optimizations for them. For example, the use of LA to increment a pointer, followed closely by a use of the target register as an address, is so common that special 'bypass' circuitry exists in the hardware to make this sequence run fast. MVI/MVC to clear a field by propagation is similarly optimized. There are numerous other examples as well. Replacing such code sequences with well-intentioned alternatives will tend to make the code run slower. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: which instructions should I use?
On 8/28/2012 5:45 AM, David Bond wrote: TMLL was included with the first set of Relative and Immediate instructions way back on the 9672-G2. If you are willing to use AHI and BRC, then there is not reason not to use TMLL. I didn't see your response before I wrote mine. I said 'G3' but I'm sure you are correct with 'G2'. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: which instructions should I use?
On 8/28/2012 5:27 AM, McKown, John wrote: Value to be tested is in a register, not storage. On the newer machines, the TMLL instruction can do this. But I run on a z9BC. TMLL has been supported since 9672-G3 as TML. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Strange PC entry
On 8/25/2012 7:26 AM, Chuck@arneycomputer wrote: If you use a zPDT or Hercules, I guess you could use a PC (Private code) section running on your PC (Personal Computer) to execute a PC (Program Call) instruction. Just for fun of course. But, doing so would not be politically correct! -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Strange PC entry
On 8/23/2012 3:40 PM, John Gilmore wrote: PC is now an overloaded term, one that needs to be used carefully. I'll say! I only read this thread because I thought it was talking about some anomalous entry into a PC routine! -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
SHARE MVS Program Survey - Your Participation Requested
The SHARE MVS Program has created a survey to help determine which topics to include in upcoming conferences. The survey contains a list of z/OS enhancements that we think should be implemented in most installations. Many of these aren't implemented and we'd like your input to understand why. Our Projects will use the survey results to help adapt session focus in these areas. The list itself is very interesting and you'll be able to compare your installation to others after the survey concludes. Already a SHARE member? Go to http://www.share.org/MVS and use your existing SHARE login and password, or click the link at the bottom of the page for reset options. From http://www.share.org, you can also select 'Our Community', and then select the 'MVS Program' as the Area of Interest. Not a SHARE member? It’s easy to create a web user profile! * Visit http://www.share.org/membership * Check to see if your company is already a SHARE member – there’s no cost to you or your company to be added to the membership, and you’ll receive full member benefits! * If your company is not a member, select “Non-Member Account”. You’ll be asked to provide your contact information and optional demographic information. This should take less than 5 minutes to complete. * Your request to access SHARE.org will be approved within one business day. If you need to expedite this process, please call (888-574-2735) or email SHARE HQ (shar...@share.org) and request immediate access. * Follow the instructions above to access the survey. [Shameless Plug: If you haven't seen the new SHARE website, you'll be impressed by the many new features such as a z/OS blog, user forums, access to prior years' proceedings, free webcasts, and additional publications.]
Re: Subject: AW: ** ASMA030E Invalid literal usage - =CL8'MARTINWH'
On 7/12/2012 9:56 AM, McKown, John wrote: Which is totally simplistic these days. You bought your cell phone, right? Do you really think that you can do anything to it that you want to? And that it is totally documented? In today's "IP is __mine__" world, more and more things are becoming "black boxes". "No user serviceable parts in side." I am not afraid to 'root' my Android phone. If I had an iPhone, I would 'jail-break' it for sure! -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Detecting RMODE at assembly time
On 7/1/2012 7:03 PM, Alex Kodat wrote: As far as requiring "smarts" to see out eligible GETMAINs, my point was that it shouldn't require any. Heck, even I was able to change all our storage allocations years ago to use 64-bit backing and haven't ever had a problem resulting from that. I can assure you that I don't have the smarts to look for eligible GETMAINs as I wouldn't even know what to look for. What would I look for? As part of our RSCR effort many years ago, we changed all of our GETMAIN and STORAGE OBTAIN requests to back everything in 64-bit real. Everything seemed to work fine at first, but eventually failed when some of the code was executed in an LPAR with >2G of real. We found numerous occurrences of code that needed to be enhanced to use LRAG instead of LRA. (IIRC, some were real-mode channel programs, some were PR/SM DIAGNOSE, some were VM DIAGNOSE. There may have been others.) This had to be done conditionally, since at the time we still supported ESA/390 architecture. This is why I mentioned 'eligible' GETMAINs. Naturally, I highly recommend LOC=(xx,64) be specified whenever possible. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Detecting RMODE at assembly time
On 7/1/2012 7:03 PM, Alex Kodat wrote: Sorry but I don't understand what re-entrancy has to do with how storage is backed. Care to explain? I was referring to the practice of using GETMAIN to acquire working storage areas. This technique is most often employed by RENT programs. Also, I assume by "have no control over the backing of storage" you meant that most older programs don't specify the required backing for their GETMAIN? No. I meant that programs don't have control over where the storage, into which they are loaded by the contents supervisor, is backed. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Detecting RMODE at assembly time
On 6/30/2012 10:04 AM, Alex Kodat wrote: Storage for all data areas and control blocks can be backed above the 2 GB bar even if your program is running in 24-bit mode. This means that you can code either of the following: * LOC=(BELOW,ANY) * LOC=(BELOW,64) on the GETMAIN or STORAGE macro. Recommendation: Code the second value as 64. Note: Code LOC=(BELOW,ANY) or LOC=(BELOW,24) when using tape devices that do not support 64-bit IDAWs. This recommendation assumes the AMODE(24)/RMODE(24) program is coded using re-entrant programming techniques and is actively being maintained by someone with enough "smarts" to seek out all eligible GETMAINs, specify a backing location other than the default, and test to be sure everything works as expected. Note that many older programs are not re-entrant and have no control over the backing of the storage into which they are loaded. (The system has no choice but to use 24-bit backing.) IMO, anyone doing active development in the 21st century should be writing interface macros and services that support RMODE 31 calling programs. Enhancing existing 24-bit-only services to support 31-bit-resident callers seems to me to be a much better use of programmer resources than spending time 'enhancing' those 24-bit interfaces to detect RMODE 31 callers at assembly time only to issue an error MNOTE. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Detecting RMODE at assembly time
On 6/30/2012 9:32 AM, Paul Gilmartin wrote: Does the z hardware support 64-bit I/O? Of course! CCW-based channel programs support 64-bit IDAWs (and MIDAWs). zHPF channel programs, with or without TIDAWs, are natively 64-bit. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Detecting RMODE at assembly time
On 6/30/2012 7:57 AM, Edward Jaffe wrote: For example, if a z/OS system is now capable of running 1000 more address spaces than it could twenty years ago, that means 384,000 additional bytes of fixed, common storage below 16MB is required just to hold the ASCBs (address space control blocks -- 384 bytes each)! There are other fixed, common storage control blocks needed as well. And 24-bit common storage, whether fixed or not, reduces the amount of 24-bit virtual private area available. Lol! In reading back my post as it was echoed to me, I see I failed to directly state the most important point. :-[ While there is one shrinking virtual 24-bit area per address space, there is ONLY ONE 24-bit real storage area shared by the ENTIRE SYSTEM! So, not only does growth of fixed, common 24-bit storage 'eat' into the total that is available, but private 24-bit addresses when they are fixed (such as during an I/O) are competing for an ever-shrinking pool of 4K frames in that singular system-wide area. 24-bit I/O. Don't do it! -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Detecting RMODE at assembly time
On 6/28/2012 2:12 PM, Binyamin Dissen wrote: In what way? RMODE ANY/31 does NOT guarantee that the module will be loaded above the line. It is a preference. Lol! If your address space is so 31-bit storage constrained that your RMODE(31) program must be loaded into 24-bit memory, the just-loaded program probably won't run worth a damn. IJS... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Detecting RMODE at assembly time
On 6/28/2012 7:02 AM, Jay Toran wrote: If the module is above the line, my code that the macro calls doesn't run. I want to give the programmer a warning if that could happen by letting them know at assemble time. If it isn't possible, any ideas? When presented with a similar challenge many years ago, we decided to invest the development resources necessary to make ALL programs RMODE(31). Surprisingly, 24-bit VSCR is as important today as when MVS/XA first arrived on the scene. It's not a problem that was 'solved' decades ago and can now be ignored. The number of logical processors per LPAR is growing as is the number of concurrent address spaces supported by z/OS and other operating systems. This 'horizontal' growth is putting new pressure on virtual and (precious real) memory below 16MB. For example, if a z/OS system is now capable of running 1000 more address spaces than it could twenty years ago, that means 384,000 additional bytes of fixed, common storage below 16MB is required just to hold the ASCBs (address space control blocks -- 384 bytes each)! There are other fixed, common storage control blocks needed as well. And 24-bit common storage, whether fixed or not, reduces the amount of 24-bit virtual private area available. IMHO, any programs that still do I/O to buffers below the line should be modified to do I/O to buffers above the line as soon as possible. (Even if you think your RMODE(24) program does no I/O, consider that below-the-line I/O occurs in CSV FETCH processing just to load your RMODE(24) program into memory!) Of course, the goal should be RMODE(31) for all programs if practical to do so. That should get you positioned just in time for entry into the world of RMODE(64) programming when/if such a thing comes to be reality. :-) -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: HLASM - 20 years old
On 6/21/2012 7:36 AM, Sharuff Morsa3 wrote: John took the initiative for creating High Level Assembler as a follow up product to the older Assembler F and Assembler H; and he is widely regarded as the "father of HLASM". [snip] Many thanks to John and the developers in Perth (many of them called John - at one point I'm sure you couldn't work on HLASM unless your name was John or possibly Craig). Without all of their hard work and dedication; the product, the language, its many facilities, HLASM would not be what it is today. Happy Birthday HLASM. Happy Birthday, indeed and a hearty congratulations! Hard to believe it's been 20 years already! For those interested in such things, see http://2012atlanta.share.org/WrapUpArticle.aspx "In Atlanta, SHARE recognized a long-time SHARE volunteer, gentleman and scholar, Dr. John R. Ehrman with the Distinguished Service Award. John has been a SHARE volunteer for over 40 years. His first SHARE event was in February 1964, and he has only missed two meetings since then in August 1965 and February 1966. John is the longest continuing attendee that SHARE has had! He served on the SHARE Board of Directors in 1972-73 and sketched out the initial design of the previous SHARE logo of the red 'S'. Most recently John has been serving as the Project Manager for the Assembler Project. He has won multiple best session awards, including for the Assembler Boot Camp, and has also been awarded the Distinguished Speaker Award. John is the 'father' and champion of the High Level Assembler and his work led to approval for its development in 1992. Congratulations John!" -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: To Gen or Not To Gen
n 6/17/2012 8:18 AM, Hardee, Chuck wrote:
Hello Listers!
I am in the process of writing a macro and would like to control whether or not
some MNOTEs are generated.
What I am looking for is whether or not I can check the current status of GEN
versus NOGEN.
If the macro is assembled and PRINT GEN is specified, I don't want to issue my
MNOTEs but if the assembly is performed with PRINT NOGEN, then I want to
execute the MNOTEs.
Has anyone ever done anything like this?
If so, how does one test for the GEN/NOGEN status?
You might choose to define your own PUSH, POP and PRINT macros and use OPSYN to
make them active. Those three macros would then internally manage the binary
on/off value for producing the MNOTEs as needed. Here is a quick 'proof of
concept' PRINT macro:
Stmt Source Statement
1 MACRO ,
2 XPMAC &A,&B
3 GBLB &Mnotes
4 AIF ('&A' EQ 'GEN').L1
5 AIF ('&A' EQ 'NOGEN').L2
6 AGO .L3
7 .L1 ANOP ,
8 &Mnotes SETB 0
9 MNOTE 'Debugging: Mnotes will be suppressed'
10 AGO .L3
11 .L2 ANOP ,
12 &Mnotes SETB 1
13 MNOTE 'Debugging: Mnotes will be produced'
14 .L3 ANOP ,
15 XPRINT &A,&B
16 MEND ,
17 XPRINT OPSYN PRINT
18 PRINTOPSYN XPMAC
19 TEST RSECT ,
20 PRINT GEN
21+Debugging: Mnotes will be suppressed
22+ XPRINT GEN,
23 PRINT NOGEN
24+Debugging: Mnotes will be produced
25+ XPRINT NOGEN,
26 PRINT ON
27+ XPRINT ON,
28 PRINT OFF
29+ XPRINT OFF,
38 PRINT OFF,NOPRINT
This last statement illustrates a drawback to this approach. The 'NOPRINT'
keyword is not honored for your OPSYNed PRINT statement.
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/
Re: Jumpify Your Code (Was: Base registers)
On 6/17/2012 9:13 AM, Martin Truebner wrote: Ed, can I link to yours from mine? http://pi-sysprog.de/free/makerel.html or (in another language) http://pi-sysprog.de/free/makereld.html on the very end Of course! 8-) Your bilingual perspective (I mean VSE/MVS, not English/German ;-) ) is always highly appreciated! -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Jumpify Your Code (Was: Base registers)
On 6/16/2012 2:54 PM, Scott Ford wrote: I saw your 2007 presentation and have a copy. I am always looking for good examples to aid my education and understanding. For those having trouble finding the February 2011 version of this presentation on SHARE's new web site, here is a link to it on the Phoenix Software site: ftp://ftp.phoenixsoftware.com/pub/demo/Jumpify_Your_Code_2011.pdf -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Base registers
On 6/5/2012 2:19 PM, Tom Marchant wrote: On Tue, 5 Jun 2012 15:59:36 -0400, Scott Ford wrote: where can you find a good sample of baseless assembler code ? Look for Ed Jaffe's SHARE presentation "Jumpify your code". The original "jumpify your code" presentation was from 2007. When I updated it in 2011 for zEnterprise, I retitled it "jumpify your programs". I *knew* I should have kept the original title! >:o -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Base registers
On 6/2/2012 5:38 PM, Tony Thigpen wrote: > but there is none to be made for doing so in > writing even a new single RSECT. How about this reason. We have several customers running our software that are on pre-MP3000 machines that don't even support relative instructions. They still pay us for support and that includes software upgrades. Other vendors may not care about existing customers, but we do. Almost all of these customers also can't upgrade their VSE. They fell into the ESL trap with IBM many years ago and now can't get their budget dollars back to get current because of the IBM monthly charges. As faithful customers for many years, we do not want to kick them while they are down just so we can do 'fancier' code. There are two sides to this. You need to care about all of your customers, not just those with no money. Dragging premier customers, with the latest hardware and software, down to the level of the laggards is not fair to them. Customers that continue to invest heavily in the platform must be rewarded for doing so. IBM and ISV software should exploit the latest hardware and software features in ways that provide these leading edge customers with the very best performance and feature set possible lest they find an alternative (seemingly cheaper) way to host their applications. It's not just 'fancier' code. The productivity gains accrued by allowing programmers to leverage new facilities are immense; new features can be implemented in far less time giving customers more of they want for their maintenance dollars; tremendous run-time performance savings can be realized by leveraging new hardware and software features; today's memory rich (especially) 64-bit environments allow programs to do things only dreamed of twenty years ago; and, so on... The ESL problem is a unique problem for VSE that does not exist for MVS customers. Nevertheless, the reality is that very, Very, VERY few customers running severely back-level operating system releases are interested in installing the latest and greatest release of 'Product X' -- even on VSE. Often, such systems exist because the customer is in their 15th year of their 3-year plan to migrate off the mainframe. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: DS 0H
On 6/14/2012 9:52 AM, McKown, John wrote: If that is the definition: label: is functionally identical to: label DS 0H It would be __simple__ to implement for users of FLOWASM. Just modify the source input routine to change the statement to remove the tailing : and insert DS 0H. Change this: IF CLI,0(R3),GT,C' ' If label present JAS R14,FLOW_SrcParse Advance past Label ENDIF , EndIf to this: IF CLI,0(R3),GT,C' ' If label present JAS R14,FLOW_SrcParse Advance past label IF LTR,R4,R4,NP If nothing after label LRR14,R3 Point to last character AHI R14,-1 (same) IF CLI,0(R14),EQ,C':' If trailing colon L R0,FLOWSAV2+4 Old stmt pointer L R1,FLOWSAV2 Old stmt length AHI R1,-1 Adjust for colon LAR3,FLOWSTMW New stmt pointer STR3,FLOWSAV2+4 (same) LAR4,L'FLOWSTMW New stmt length STR4,FLOWSAV2 (same) LRR14,R3 Target pointer LRR15,R4 Target length DO UNTIL=NO Do for MVCLE MVCLE R14,R0,C' ' Copy with blank pad ENDDO , EndDo JAS R14,FLOW_SrcParse Advance past label MVC 1(5,R3),=C'DC 0H' Set 'DC 0H' ENDIF , EndIf trailing colon ENDIF , EndIf nothing after label ENDIF , EndIf label present -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: DS 0H
On 6/13/2012 11:32 AM, Rob van der Heij wrote: What's this talk about labels in assembler programs? Don't we all do structured assembler now? ;-) Of course! But, subroutines still need labels. *** * Subroutine to Accumulate FOOs * *** AccumulateFoos DC 0H STKPUSH , Save the registers . . (FOOs get accumulated here) . STKPOP , Restore the registers BRR14 Return -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: anti 4095 base guys
On 6/4/2012 12:48 PM, Binyamin Dissen wrote: On Mon, 4 Jun 2012 14:20:09 -0500 "McKown, John" wrote: :>No such thing as a negative displacement. A displacement is more like an unsigned immediate operand. From 0..4095 (0x000 to 0xFFF for a 12 bit displacement) or 0..1048575 (0x0 to 0xF for a 20 bit long displacement). You may wish to look up the **Y instructions. The corresponding 'grande' instructions, introduced with z/Architecture, also use 20-bit *signed* displacements. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: DS 0H
On 6/5/2012 4:51 AM, McKown, John wrote: My rule for most instructions is "place any required label on a separate DS 0H as the preceding statement." I use DC 0H rather than DS 0H, but that is a minor difference. Naturally, the label is always on its own line. Otherwise the instruction would not line up with the others below and that would look ugly. For example: *** * Subroutine to Accumulate FOOs * *** AccumulateFoos DC 0H STKPUSH , Save the registers . . (FOOs get accumulated here) . STKPOP , Restore the registers BRR14 Return -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: MVC with 2nd operand length
On 5/23/2012 11:43 AM, Ray Mullins wrote: Try using the HLASMTK SPM SELECT on a CLC where a variable-length literal is the first operand. A CLC:2 or CLC2 macro or whatever would use the length of the second operand would simplify a lot of code that I have inherited. Excellent use case, Ray. We use both CLC2 and MVC2 macros in exactly that way. Slick! -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Messages - Was MVC with 2nd operand length
On 5/22/2012 1:56 PM, Mike Shaw wrote: On Tue, May 22, 2012 at 2:29 PM, McKown, John wrote: <...snip...>IMO. I.e. a BASH UNIX prompt beats the crap out of line mode TSO.<...snip...> Jeepers John, I gotta disagree with you on that one. How is '#' as a prompt any better than 'READY'? He's talking about the capabilities available at the prompt. TSO/E READY is very, very weak. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: MVC with 2nd operand length
On 5/22/2012 6:56 AM, Art Celestini wrote: Personally, I have not encountered many circumstances where I needed to MVC using the length of the source. I find that surprising. I just scanned the assembler source code for one of our more popular products and found 27,930 MVCs and 927 MVC2s. That means our programmers found MVC2 preferable to MVC in at least 3.2% of cases. These results are heavily skewed by the fact that many MVCs are found in code authored before we came up with MVC2 some years ago. I then randomly chose one recently-coded program and found 70 MVCs and 4 MVC2s. MVC2 was used in 5.4% of cases or approximately one in every eighteen moves. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: MVC with 2nd operand length
On 5/16/2012 9:48 AM, John Ehrman wrote:
Macro
&LabMVC2&Target,&Source
&LabCLC 0(0,0),&SourceX'D500 ',S(&Source)
Org *-6 Back up to first byte of instruction
LA0,&Target.(0) X'4100',S(&Target),S(&Source)
Org *-4 Back up to first byte of instruction
DCAL1(X'D2',L'&Source-1) First 2 bytes of instruction
Org *+4 Step to next instruction
MEnd
This is very similar to the macro we have of the same name. Only ours has an AIF
that tests the first character of &Target for '(' and takes a second path that
supports the following coding format:
MVC2 displacement(,reg),source_field
For example:
MVC2 0(,R14),_1.DSTDEST Set Character DEST data
Without that second path through the macro, the above code will fail with:
** ASMA173S Delimiter error, expected blank - (0)
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/
Re: Where to find out about "PER zero-address detection"?
On 4/25/2012 8:31 AM, Mike Shaw wrote: One could always try a SLIP SET,... command with ACTION=IGNORE to see if the syntax one has a hunch about is correct. And, if you try it on a z10 or earlier processor you will get: IEE745I THE ZAD FACILITY IS NOT AVAILABLE Looking up that message yields: IEE745I THE facility FACILITY IS NOT AVAILABLE Explanation: The named facility is not available. In the message text: facility ZAD, which indicates that the zero-address-detection facility, as requested by the SLIP SET,ZAD command, is not installed on the machine. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Where to find out about "PER zero-address detection"?
On 4/25/2012 6:53 AM, McKown, John wrote: I've tried finding about this using the -08 version of the Principles of Operation. I got a few hits, but nothing which described what it actually __does__. I can guess from the phrase, but I'd like something documented. The description for z/OS msgIEE735I (output of D SLIP= command) contains: | PER-ZAD | PER zero address detection trap. This suggests strongly that you can issue a SLIP SET,ZAD,... command to capture/track ZAD events on a z/OS system. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: CALL macro "enhancement" thought
On 4/11/2012 2:27 AM, Martin Packer wrote: Trashing the I Cache is still very much a concern. However, in the case posed to the group (branching around a constant to be loaded into a register), the "data" is not being modified. Though not ideal, it's perfectly OK to have instructions and constants in the same cache line. Multiple copies of the line can be loaded simultaneously "read-only" into both I-cache and D-cache on multiple processors and perform well. However, if you UPDATE the line, two things will happen as I understand things: a) all copies of that line will be purged from D-cache on all 'other' processors so that the 'current' processor can exclusively lock/update the line and b) the line will be purged from I-cache on all processors forcing the processor pipeline to go back to an earlier point in instruction fetch processing to re-fetch the line -- bad news. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: curiosity: In AR mode, why doesn't BALR/BASR/BRAS/BRASL set the value of the corresponding AR register ?
On 4/10/2012 11:31 AM, McKown, John wrote: But that made me wonder why the z/Architecture does not specify that the contents of the AR register associated with the link register in any of the "branch and link" type instructions: BALR, BASR, BRAS, BRASL, and BASSM will be set to 0? Anybody have any idea why these type of instructions don't set the AR? Unnecessary. Instruction fetch is always from the primary address space. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: DataSpace & LOAD
On 3/5/2012 3:18 PM, Kevin Lynch wrote: A Common Area Dataspace is automatically shared between all existing and future Address Spaces, whereas 64 bit shared storage is not automatically addressable by all Address Spaces. For that requirement one can acquire 64-bit common storage instead. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: DataSpace & LOAD
On 3/5/2012 12:32 PM, Gainsford, Allen wrote: I take it that you're referring to using a guard area, and using CHANGEGUARD to convert guard space to usable space as needed. We do exactly that in numerous places; it's a useful technique. The only "trick" is choosing the upper bound. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: DataSpace & LOAD
On 3/4/2012 4:34 PM, esst...@juno.com wrote: Ed Jaffe wrote What we do is invoke the binder (via the IEWBIND macro) to read in the RLDs for the load module. Then we can relocate the module anywhere we want, including to a data space. I have been using offsets in the past and would like to see if I can use addresses. Now having stated that, can You elaborate on using IWEBIND. It is not a macro I use regularly. The binder API (IEWBIND) is described here: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2b2b0/3.0 -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: DataSpace & LOAD
On 3/4/2012 1:21 PM, esst...@juno.com wrote: Has anyone ever tried to issue a LOAD macro and have the program (i.e Table) placed directly into a data space. I have issued MVS LOADS (which is a load for a table) and then use MVCL in AR mode to copy the Table into a Dataspace. Now if the Table contained Address/pointers to sub list what techniques do others use to resolve Address Tranlation ? What we do is invoke the binder (via the IEWBIND macro) to read in the RLDs for the load module. Then we can relocate the module anywhere we want, including to a data space. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Program FLIH backdoor - This is a criminal breach of security!
On 3/2/2012 9:09 AM, David Cole wrote: Certainly, the "hearsay" could be wrong. And I do hope that it is wrong. But it is a better course to assume that the charge is right and raise awareness to the point where it will be investigated and PROVEN to be right or wrong... ... than it is to assume that the charge is wrong and just sit back and *hope* that nothing bad happens. In other words, I think that being noisy about this issue will have a more constructive result than being silent will. The subject line of this thread started off as "Program FLIH". Then, you renamed it to, "Program FLIH backdoor - This is a criminal breach of security!" Making noise is one thing; making speculative accusations of criminal wrongdoing is quite another. That's the stuff of lawsuits. Innocent until proven guilty is the American way; not the other way 'round. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Program FLIH backdoor - This is a criminal breach of security!
On 3/2/2012 1:29 AM, David Cole wrote: If the PFLIH hook is (as it has been described earlier in these threads) a mechanism by which a non-authorized process can become authorized, then its very existence is a "substantive offense" in and of itself. It is not just "a template", it doesn't just show the way. It *is* the way. I keep coming back to IGX00011. It's presence on z/OS systems PROVES that the very existence of a "magic" SVC service, while arguably not a 21st-century best practice, is NOT considered an exposure or "substantive offense" when done correctly. (Those last three words are very important!) A "magic" PFLIH technique is not substantially different, from an integrity standpoint, than a "magic" SVC except that the code gets control for EVERY interrupt and so has the potential to slow things down if not implemented efficiently. The real question is whether an unintended third party can use the code to become authorized. Unlike the "magic" SVCs of the past, I'm confident that IGX00011 cannot be exploited by unintended third parties. The same might very well be true of the PFLIH approach being discussed here, despite any third-party hearsay from Bill Fairchild's colleague claiming otherwise. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Program FLIH backdoor - This is a criminal breach of security!
On 3/1/2012 9:23 AM, Binyamin Dissen wrote: I would suggest by the fact that they do it in a tricky way and not in a forthright way that there is an exposure. Otherwise why not simply use a PC? There is no need to do this (at least since DAS) in the FLIH. I suspect the code was written long before the existence of PC routines. The approach is clever for sure, but that in itself does not guarantee there is an exposure. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Program FLIH backdoor - This is a criminal breach of security!
On 3/1/2012 6:52 AM, David Cole wrote: This is not just despicable, under today's law, it is actually criminal! Any vendor who does this could be (and should be) jailed in criminal courts and sued out of existence in civil courts. I do not know who is doing this, but I believe utmost pressure must be brought to bear upon that vendor so that it will commit every resource to removing the breach from its products. Just to clear: intercepting the FLIH does not itself constitute an exposure and, as far as state changes go, the checking and requirements could be complete enough to avoid any integrity problem. For example, the methodology could be similar to that employed by IBM's IGX00011 "magic" SVC and its intended caller. Unless someone can prove there really is an exposure, which to my knowledge has not been done, I suggest that passing such judgment is premature. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Requiring FLOWASM for CBT donations
On 2/27/2012 1:44 PM, Gary DiPillo wrote: Well, Ed, you must have already done that, since I just found it in CBT724. The FILE724.XMI has a 12/26/2011 date, and the files in the .XMI have dates from 2005. Forgot about that. I think Sam Golob did that for me... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Requiring FLOWASM for CBT donations
On 2/27/2012 1:02 PM, McKown, John wrote: OK, I'm considering donating some code to the CBTtape so that others can use it, if they want. The code, such as it is, is all for UNIX commands. I use FLOWASM because it makes it easier for me to use vi to edit HLASM code if I don't need to conform to the normal HLASM syntax requirements. I especially like not needing the continuation indicator in column 72. Does anybody know if the CBT will accept HLASM which requires FLOWASM to assemble? Or should I reformat the code, just to be nice? Maybe FLOWASM should be donated to the CBT as well? -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Program FLIH
On 2/24/2012 9:54 AM, Gibney, Dave wrote: What I don't understand, pardon my "naifness" (split the thread John:), is the need for such today. I suspect new code authored from-scratch today, by the "offending" vendor, would never intentionally use a hook like the one that has been described here. But an existing infrastructure might depend on it heavily. And, many different products from a single ISV can share the same robust infrastructure. The exploit (if it exists) might not be any harder to crack than it was for NEON's zPrime to turn on a bit to make TCB work eligible for zIIP execution. Or it might now be a maze of checks that cannot be exploited by others. It is a complete myth that IBM doesn't sanction SVCs that turn off the problem state bit in the PSW. If that were true, the mere existence of IGX00011 would invalidate IBM's integrity statement for z/OS. That extended SVC routine (ESR) can be invoked by an unauthorized problem program with the right name and other attributes and it will return in supervisor state. Guaranteed! When any of the vendors I named instruct me so, I dutifully APF their libraries and they often reside in the linklist which we at least do set AFP via IEASYSxx. You can't be expected to catch subtle MVS integrity exposures at install time. You must assume that no legitimate software vendor--including IBM--would knowingly violate its own integrity statement. Furthermore, I hope you didn't hesitate when our installation instructions asked you to covertly deploy our sabotage backbone along with the rest of our authorized components. To activate, press ATTN three-times and in the secret prompt area type in the name 'JOSHUA". Enjoy! . . . . . . . . . . . . LOL! This is a JOKE! We have no back doors of any kind. We take MVS integrity VERY seriously! :-D -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Program FLIH
On 2/24/2012 9:51 AM, Mike Shaw wrote: On Fri, Feb 24, 2012 at 8:43 AM, John Gilmorewrote: I believe, however, that this name should be made public. This information should not be confined to the priesthood John, The name of the offending ISV can be inferred if you read the text of each post in this thread carefully... I think John meant PUBLIC--as opposed to known among a small minority, including those involved in this discussion. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Program FLIH
On 2/24/2012 5:43 AM, John Gilmore wrote: There had been a tacit assumption that notionally respectable ISVs do not do such things. That assumption has been undermined, and even responsible ISVs will now have to spend time and energy reassuring their customers that they are not guilty too. They are all now in the position of a locksmith suspected of burglary. I had a similar thought, so yesterday I reviewed our integrity statement... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Program FLIH
On 2/23/2012 1:08 PM, Hall, Keven wrote: If you're at all curious to see if it's in your system/s you can use IPCS (as of z/OS v1.9) to browse real storage when source is specified as ACTIVE. You need to have read access to BLSACTV.SYSTEM in class FACILITY and then use the command: IP L pointer_at_location_1DC ABS INST If the address at location 1DC points to a page boundary it's most likely that the 3rd party code is installed. Interesting. It's not on ANY of our systems. HOWEVER, I looked at a dump recently sent in from a large customer and there it was! -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: FLOWASM observation
On 2/22/2012 7:01 AM, McKown, John wrote: ... but still send each record read by the assembler to the PROCESS subfunction in order to "do its magic". It works wonderfully. Yay! Another happy customer! :-) I've also changed the PROCESS subfunction to translate all x'05' (EBCDIC tabs) to x'40' (a single space). That's because I sometimes use vi to edit my assembler. I forget myself and use the ! tab key. If there are changes you think should be permanently incorporated into FLOWASM, please send them to me. Thanks! -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: FLOWASM observation
On 2/22/2012 6:47 AM, Paul Gilmartin wrote: Why is a RDJFCB required at all? I'm primarily not an assembler programmer, but I've coded a few OPENs successfully, but never a RDJFCB. I would suggest that if RDJFCB fails, let FLOWASM, not assembler, proceed with its OPEN and I/O processing. If RDJFCB fails, so will OPEN. The reason it failed in John's case is simply because he didn't provide a SYSIN DD statement. RDJFCB is used to provide the "Source Information" requested by the assembler on its AXPROPN call to the exit: AXPMEMN Member Name AXPMEMT Member Type (VSE only) AXPDSN Data Set Name AXPVOL Volume Serial Number You could get this information by chasing control blocks, but it's far better to use supported services whenever you can. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: FLOWASM observation
On 2/21/2012 8:52 AM, McKown, John wrote: I keep my HLASM source in z/OS UNIX files. "Just because I want to.". This works well for me. The only problem that I've run into is when I edit with "vi" (yes, I get what I deserve). ISPF edit "knows" that if I replace "ABCD" with "EF", it should only move the non-blank characters immediately to the right of the "ABCD" left. vi doesn't do this. This is really disruptive of continuation characters in column 72. So, looked at FLOWASM. Wonderfully, one thing it allows is continuation of a statement without the continuation character in column 72! So I thought it would be wonder to use and remove all the characters from column 72. Unfortunately, FLOWASM uses RDJFCB on the DCB which describe the input dataset. This RDJFCB gets an RC of 4 when the input is a UNIX file.. It appears that the RDJFCB is really only used to pass back the DSN and volume of the input dataset to the assembler. John, In studying the FLOWASM code, I see the only reason there is an OPEN at all in routine FLOW_SrcOpen is to handle long, variable-length records. If your records are all <= 80 characters in length (which I assume they must be since you're not currently a FLOWASM user), then it should be OK to let the assembler perform the OPEN and READs for us. I would change the following code from this: DO , Do for OPEN processing LAR2,FLOWDCB Point to the DCB MVC FLOWMACW(FLOWRDFML),FLOWRDFM Copy model RDJFCB macro RDJFCB ((2)), Read the JFCB MF=(E,FLOWMACW) (same) IF LTR,R15,R15,NZ If non-zero return code LAR15,AXPCBAD Indicate OPEN failed XRR0,R0 Set reason code = 0 ASMLEAVE ,Leave the structure ENDIF , EndIf to this (only one line changed. See '<== HERE' comment): DO , Do for OPEN processing LAR2,FLOWDCB Point to the DCB MVC FLOWMACW(FLOWRDFML),FLOWRDFM Copy model RDJFCB macro RDJFCB ((2)), Read the JFCB MF=(E,FLOWMACW) (same) IF LTR,R15,R15,NZ If non-zero return code XRR15,R15 Set return code = 0 <== HERE! XRR0,R0 Set reason code = 0 ASMLEAVE ,Leave the structure ENDIF , EndIf I believe this change will instruct the assembler to fall back to its own internal OPEN and READ processing for SYSIN (or whatever DD you're using) which, as you know, contains support for z/OS UNIX files. Regards, -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: FLOWASM observation
On 2/21/2012 8:52 AM, McKown, John wrote: I keep my HLASM source in z/OS UNIX files. "Just because I want to.". This works well for me. The only problem that I've run into is when I edit with "vi" (yes, I get what I deserve). ISPF edit "knows" that if I replace "ABCD" with "EF", it should only move the non-blank characters immediately to the right of the "ABCD" left. vi doesn't do this. This is really disruptive of continuation characters in column 72. So, looked at FLOWASM. Wonderfully, one thing it allows is continuation of a statement without the continuation character in column 72! So I thought it would be wonder to use and remove all the characters from column 72. Unfortunately, FLOWASM uses RDJFCB on the DCB which describe the input dataset. This RDJFCB gets an RC of 4 when the input is a UNIX file.. It appears that the RDJFCB is really only used to pass back the DSN and volume of the input dataset to the assembler. I'm wondering if I have an old version and a newer version supports input from a UNIX file. Did I mention that I keep my macros in UNIX as well? Yes, I'm weird. I will take a look at this... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Printing out LCLC values
On 1/19/2012 3:38 PM, Micheal Butz wrote: Is there anyway to print character variables to debug macros LCLC GBLC or for that matter arithmetic values GBLA LBLA binary values LBLB GBLB MHELP -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: How bad is the EX instruction?
On 1/17/2012 8:06 AM, Farley, Peter x23353 wrote: Others have said here that performance is a strong reason for _not_ coding in assembler: o Compiler developers have done the research on instruction timings and know better than most end users what sequences fit the pipelines optimally. Notoriously NOT for the IBM COBOL compilers. The PL/X compiler also generates 'poor' code. (It's one reason it's been difficult to convince the 'powers that be' to establish a new Architectural Level Set for z/OS.) IBM has hinted that they plan to address these compiler deficiencies--when is anybody's guess. But, at least they admit there's a problem. That's the first step... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: How good is the EX instruction?
On 1/17/2012 6:40 AM, Paul Gilmartin wrote: I forget; is the target of EX treated as a data access or as an instruction access for cacne management? The 256-byte cache line containing the target instruction is loaded into I-cache. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: How bad is the EX instruction?
On 1/12/2012 7:32 AM, McKown, John wrote: I ask about the CPU cost of an EX because that same program that I'm working on uses the EX a fair amount to move "variable length" strings into a blank-initialized area for reporting purposes. Instead of EX of an MVC, I could use MVCL or MVCLE. But many have said that EX of an MVC is less overhead than MVCL in many cases. Especially since I know that my length is always no more than 255 characters. I check and report an error if the length is 256 or more. Relative instruction performance is a moving target. We run benchmarks whenever we get a new processor so we can understand the trends. Most new hardware generations build on the microprocessor design of the prior generation, so the changes tend to be incremental. Now and then, the microprocessor gets completely redesigned. One such redesign occurred with the introduction of the z10. I mentioned our observations re: EXecute and MVCL performance in my "z10 User Experience" at SHARE in Denver. Check out slide 13 for this information. Thanks again to David Bond for helping us make sense of our measurements. http://proceedings.share.org/client_files/SHARE_in_Denver/S2215EJ161728.pdf -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Interesting(?) observation
On 1/11/2012 6:42 AM, McKown, John wrote: What is the big deal? Well, I remember how everybody complains when IBM "steps on" their macro name. But, if you name your internal macro with a _ in it, which is valid in an HLASM symbol, but which cannot be easily used in a PDS member name, the probability of IBM "stepping on" it is greatly reduced. And you should be able to use the subdirectory name in your batch compiles simply by including it in the SYSLIB for the assembler. From looking, _ is the only such character. Clever! You can also define exotically-named macros within a member that you COPY into your program, e.g. member MYMACS can define macros _A, _B, _C etc. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Enhanced CALL macro?
On 1/11/2012 6:27 AM, McKown, John wrote: Is the ROI for the conversion less than a single year? If not, forget it. That's all that is keeping the z alive here. The "break even" on the up front cost to convert from z/OS to Windows is currently estimated to be 2 to 3 years. That is "far too long" according to our management. And so we stay on z/OS for the time being. I've spoken with many IBM customers that are on their (for example) 11th year of a 2-3 year conversion effort. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Enhanced CALL macro?
On 1/10/2012 4:04 PM, John P. Baker wrote:
LAEY instruction if the operand is specified as '(SL,{"symbol" |
"expression"})' and SYSSTATE ASCENV=ASC is in effect ;
LAEY. I wish! We can't use the general-instructions-extension facility. :-(
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/
Re: Enhanced CALL macro?
On 1/10/2012 1:41 PM, Gord Tomlin wrote: What we do for this is use multiple location counters and code in our prolog/epilog macros to automatically set up a base register for the part of the CSECT containing the constants. The using range of the base register is automatically defined to cover only the constants so that no code inadvertently uses base/displacement branching. The code referring to constants "just works". Same here. Only a very small 'nit' program could get away without needing a base register to 'cover' its constants. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: 128-bit arithmetic
On 1/9/2012 10:38 PM, Paul Gilmartin wrote: I have an Immodest Proposal. (I'll not leave that platform to John M., exclusively.) Define the future extension of the TOD clock as a signed binary 112-bit (111+sign) value. Rationale: given that some contracts and treaties entered in the 19th century are likely still in effect, there would be more utility in supporting a STCKE-compatible representation of dates in the 19th century or somewhat before than of dates in the 204th century and later. I like that idea! :-) Unfortunately, STCKE is old (it pre-dates z/Architecture). An awful lot of code has been authored that treats the STCKE result as unsigned based upon the description you quoted from PoOp. So, some might judge it to already be too late for this sort of change. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: 128-bit arithmetic
On 1/9/2012 1:40 PM, Steve Comstock wrote: Here's what I'm thinking: LMG R2,R4,datetimen - put datetime into R2/R3 (use 64 bits in each reg) and put datetimes into R4/R5 (use 64 bits in each reg) SLBGR R3,R5 SLBGR R2,R4 You're not supposed to use a logical subtract 'with borrow' on the low-order part. You use it only on the high-order part--AFTER doing a logical subtract 'without borrow' on the low-order part. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: z/Arch design question.
On 1/7/2012 9:03 AM, John P. Baker wrote: Benchmark tests have indicated that MVCL is less efficient than an MVC loop designed to perform the same function. I suggest that the inherent inefficiencies of interruptive instruction design could well be the cause. Based on our own internal benchmarks of various instructions, I don't think MVCL runs any slower because it's interruptible. (In fact, it runs faster than looping MVC for larger moves. The slowness for shorter moves seems attributable to millicode instruction overhead. MVCLE performs similarly.) However, your point is well taken in the larger context of instruction complexity, so I think we are saying essentially the same thing. Supporting interruptible instructions is complex and expensive. Whether the goal is to minimize hardware engineering time, chip "real estate," or possible sub-standard performance, it's clear that the additional development costs required to make an instruction interruptible are simply not worth the end result: eliminating one software branch. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: z/Arch design question.
On 1/6/2012 8:24 AM, McKown, John wrote: My curiosity is why MVCLE sets the CC, thus forcing user code to branch back. Why not just not update the PSW instruction address until all the data is processed? Still allow the interrupt like MVCL does, of course. I understand why the interrupt is necessary, especially in a single CP environment. Does anybody know? Is it a "millicode" thing? It is a chip "real estate" thing. The amount of extra silicon used to make an instruction interruptible is extreme. It is a complex undertaking. Using standard, non-interruptible instructions is simpler and allows many more new and useful instructions to be added to the instruction set. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Calculate elapsed time from MM/DD/YY HH:MM:SS formats
On 1/5/2012 12:54 PM, Paul Gilmartin wrote: On 1/4/2012 8:32 PM, James P Connelley wrote: CONVTOD is the ticket. Does that yield correct results even when a Daylight Saving change occurs within the interval? For time stamp math, you simply convert your date/time to STCK form using an offset of zero, do your addition/subtraction, and convert back also using an offset of zero. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Mixed Case in Assembler
On 1/1/2012 7:42 PM, Tony Harminc wrote: On 30 December 2011 10:29, Edward Jaffe wrote: The current behavior is fine for those who like it. I would like an option to enforce case matching. For example, if I create a field called EZDrmStringsUpper and some developer codes it as EZDrmStringSupper I would like to have the assembler generate a diagnostic. Our products support uppercase strings; but we don't feed them supper! ;-) That sounds like something to be enforced by either the global xref program that every development shop has, or perhaps by some stage of the SCCS check-in process. We don't have that global XREF program! Lol! Consider the following: EZDrm DSECT , EZDrmEyeCatch DSCL4 . . (other fields for EZDrm) The most obvious solution is a SYMCASE(ANY|ASIS) assembler option that, like most options, would affect the entire assembly. There would be ACONTROL support to handle exceptions--for example references made from inside IBM or other providers' macros you cannot change. With the default of SYMCASE(ANY), the assembler would work as it does today i.e., allow any case when referencing EZDrmEyeCatch such as EzDRMEYeCaTCh. But, with SYMCASE(ASIS), symbols would need to be specified exactly as they are defined or an informational or warning diagnostic would be produced. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: mixed case in assembler
On 12/31/2011 8:08 AM, Paul Gilmartin wrote: We did well enough for 40 years with case-sensitive assemblers. The misguided attempt to add case-insensitivity causes chaos and instability. AFAICT, these options have been around since the very first release of HLASM. They provide enforcement of the stricter rules used by older assemblers. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: mixed case in assembler
On 12/30/2011 9:47 AM, John Gilmore wrote: NOCOMPAT(NOCASE,NOMACROCASE) [snip] With NOCOMPAT(NOCASE) in effect the HLASM thus distinguishes among MyLabel, MYLABEL, etc. I does not treat them as synonyms. This does not appear to be true in the assembler I'm using (HLASM 6.0). Please post an example. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: mixed case in assembler
On 12/30/2011 7:33 AM, Edward Jaffe wrote: On 12/30/2011 6:43 AM, John Gilmore wrote: Case control is a more complicated issue. In situations like the one EJ describes I have found the two options that the HLASM already supports, viz., o CASE | NOCASE, and o MACROCASE|NOMACROCASE entirely adequate; but this is because I work in a very small group of usually two and never more than three people in which my taste is, if not controlling, very influential. Honestly, I forgot about these options. Thanks for reminding me. I will see if they meet my needs. OK. I reviewed these options. They do NOT do what I need. (This is probably why I forgot about them.) 1. COMPAT(CASE) enforces a requirement for uppercase opcodes and symbols. Almost exactly the opposite of what I want. 2. COMPAT(MACROCASE) converts macro operands to uppercase. I'm not interested in a COMPAT() option to remain compatible with older assemblers. I want a new option, as described previously, to generate a diagnostic when a programmer references MyField as (for example) MyfiEld. For ease of transition, it might be nice if the option could be limited to certain symbols or sections. For example, a new operand on the DSECT statement that says the fields defined herein must be referenced using the correct case. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: mixed case in assembler
On 12/30/2011 6:43 AM, John Gilmore wrote: Case control is a more complicated issue. In situations like the one EJ describes I have found the two options that the HLASM already supports, viz., o CASE | NOCASE, and o MACROCASE|NOMACROCASE entirely adequate; but this is because I work in a very small group of usually two and never more than three people in which my taste is, if not controlling, very influential. Honestly, I forgot about these options. Thanks for reminding me. I will see if they meet my needs. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Mixed Case in Assembler [Was: ASSEMBLER-LIST Digest - 20 Dec 2011 to 21 Dec 2011 (#2011-208)]
On 12/30/2011 5:23 AM, Steve Comstock wrote: On 12/30/2011 12:34 AM, Edward Jaffe wrote: I also like camel case. It looks much better than using underscores to separate uppercase words. However, I don't consider the assembler's current behavior to be 'nice'. For example, I will painstakingly plan and create camel case fields in a control block and then later see code referencing those fields using the wrong case (due to typos, dyslexia, or what have you). Sometimes those 'misspelled' references get propagated to other code and things really start to get ugly. I wish there was a way to tell the assembler to be case sensitive. But words with the same string of letters but different case are _not_ misspellings. They are the same word, so they reference the same variables. Using the 'wrong case' just means using the case preferred by the coder: they are still the same variables. I consider it 'nice' because each coder can use the case pattern they prefer and yet everyone is referencing the same variable: these are not typos. When I have pointed these issues out, the programmers have acknowledged that they ARE typos! The current behavior is fine for those who like it. I would like an option to enforce case matching. For example, if I create a field called EZDrmStringsUpper and some developer codes it as EZDrmStringSupper I would like to have the assembler generate a diagnostic. Our products support uppercase strings; but we don't feed them supper! ;-) But, to each his own. This is anarchy--exactly what I want to avoid. For our environment, I want the designer of the control block field to choose the name by which it will be referenced by other programmers. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Mixed Case in Assembler [Was: ASSEMBLER-LIST Digest - 20 Dec 2011 to 21 Dec 2011 (#2011-208)]
On 12/23/2011 8:42 AM, Steve Comstock wrote: Sure, camel case. And the nice thing is the Assembler will recognize variable names if you happen to forget and not capitalize the first letter, since it is case-insensitive. I also like camel case. It looks much better than using underscores to separate uppercase words. However, I don't consider the assembler's current behavior to be 'nice'. For example, I will painstakingly plan and create camel case fields in a control block and then later see code referencing those fields using the wrong case (due to typos, dyslexia, or what have you). Sometimes those 'misspelled' references get propagated to other code and things really start to get ugly. I wish there was a way to tell the assembler to be case sensitive. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: ASM Program to copy a file
On 12/10/2011 11:41 AM, Steve Comstock wrote: Wow! I didn't know I wielded such power. :-) You da Man! :-D -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: ASM Program to copy a file
On 12/10/2011 6:22 AM, Steve Comstock wrote: Hmmm. Are you advocating use of semiprivileged instructions in application code then? Or only some of them? Which ones are 'safe' or 'OK' to use in standard application programs? Where does one draw the line? Once your minimum supported operating system enables use of a particular semi-privileged instruction, then you can use it just the same as you would any new macro-based system service provided by that same level of the OS. If you write code for multiple operating systems, you need to take extra care. For example, very old z/VSE systems (pre-VSE/ESA 2.5?) used to not enable 'extraction-authority control' so often-used instructions like IPK would not work in problem state. Thankfully, that is ancient history now. I haven't seen a similar mismatch between z/OS and z/VSE in quite a while. Nevertheless, if your code might run under multiple operating systems, this is a consideration. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: ASM Program to copy a file
On 12/10/2011 4:08 AM, Bernd Oppolzer wrote: To solve this problem, I ended up with a GET routine for every QSAM dataset, where the EODAD address is part of the routine. The GET routine looked like this (from memory, I don't have the sources at hand): GET1 PSTART (R10,R14)start macro for local procedure GET DATASET1 get record from dataset XRR15,R15 set eof rc to zero LRR5,R1 move record address to reg 5 LEAVE , success, leave proc (comma VERY important!!) EOF1 DS0H= EODAD address of DATASET1 LAR15,8 end of file, set eof rc to 8 GET1ZPSTOP (R10,R14) end macro for local procedure so the EODAD branch is hidden in the GET-ROUTINE. We have done similar things. Typically the caller places the DCB address in R1 and does a JAS[L] to the 'GetNextRec' subroutine. It expects back R1 (record pointer for MACRF=L) and R15 (return code: 0=OK, 4=EOF). In addition to setting return codes, the subroutine ensures R1 contains an invalid address in the EOF case. | L R1,InputDCB1 Point to input DCB 1 | JAS R14,GetNextRecGet next record | DOEXIT LTR,R15,R15,NZ Exit if nothing left | . | . |GetNextRec DC 0H | STKPUSH (R14) Save link register | DO ,Do for GET | GET (1) Get next record | XRR15,R15 Set retcode = 0 | LEAVE , Exit |GetNextEof DC 0H <--- EOF branches here | L R1,=A(X'7000) Set invalid address | LHI R15,4 Set retcode = 4 (EOF) | ENDDO , EndDo for GET | STKPOP (R14)Restore link register | BRR14 Return I didn't mention this technique because I knew Steve would not approve. If he thinks one TM/BNZ is too much overhead, imagine how he feels about adding a JAS[L]/STKPUSH/STKPOP for every GET! :D In our shop, we tell the developer to write ASSEMBLER modules without B or J instructions. All control flow is done using SP macros, which have been developed or at least improved inhouse in the past 35 years (I don't know the beginning of the history, because I'm with this company since 1988 "only"). A very sensible development strategy. It sounds you you guys were (and still are) way ahead of your time. Thanks for sharing... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: ASM Program to copy a file
On 12/9/2011 11:33 AM, Steve Comstock wrote: For application programming (granted: there are precious few applications written in Assembler these days, except by software product developers), I actually disdain using the linkage stack, for these reasons: Actually, I wasn't talking about the linkage stack at all. I was referring to software-only stacking. In the early days, people rarely coded hierarchically. Everything was a flat programming model, one routine following another with (one or more) branches to the label of the next routine. These days, people understand the value of nested logic. A software register stack is practically a necessity for such coding. I have made a simple stacking macro available publicly to help those who might be challenged to 'roll' their own. More sophisticated stack services (such as the one we use internally) handle so-called 'automatic' variables as well. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: ASM Program to copy a file
On 12/9/2011 9:07 AM, Steve Comstock wrote: Right, so I would argue that the GET approach is more 'traditional' than the 'traditional approach' you describe: it's been around longer. I should have said 'typical'. The flaws introduced by older 1960s-era designs have been corrected in modern implementations. It's practically impossible to find a modern-era service that handles a simple 'end-of-data' condition using an out-of-line branch, and with good reason. You set up a deliberate disonance when you use the word 'arbitrary'; there need be nothing arbitrary about the routine jumped to for an EODAD occurrence: it should be well planned and naturally take the control flow to the next part of the logic. When DCBEODAD was designed, stacks were not used. In modern code, an out-of-line branch risks a situation where one or more stack frames do not get unwound. This is exactly the sort of thing that would be flagged by tools that look for problematic programming that violates good architectural and coding practices, such as those from 'Cast Software' that are getting so much press lately--having found Java to be the most problematic language and COBOL the least in a study involving 745 applications from 160 companies in nearly a dozen industries which totaled 365 million lines of code. http://www.computerworlduk.com/news/applications/3323819/java-apps-have-most-flaws-cobol-apps-least-study-finds/ Actually, the EODAD (and other DCB exit routines) might be more closely compared to exception routines in languages such as Java: event-driven routines that get control specifically when some event occurs. Event handlers, if you will. Which is more 'modern'? Which is 'better'? As you know, the answer is always 'it depends'. Such 'event handlers' are usually designed to deal with the stack frame issue I mentioned above, just as ESTAE is aware of the System z hardware linkage stack. DCBEODAD does no such thing. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: ASM Program to copy a file
On 12/9/2011 7:53 AM, Steve Comstock wrote: I disagree. Why test a flag after every GET? QSAM essentially does that for you and branches you to EODAD automatically; if you find yourself in your EODAD routine you know you're ready for the next phase of your processing, which might be just shutting down (CLOSE and RETURN), but it might be more complex, such as taking subtotals, CLOSE-ing one file and OPEN-ing another, etc. But to add the overhead of test-and-branch after every GET is totally unnecessary. QSAM GET is but one example of a whole class of similar operations provided by many IBM and ISV systems services. The notion of an "open," followed by one or many "gets," followed by a "close" is just how programming works for hundreds of different resources--from REXX/CLIST variables, to ENQs, to logger, to BCPii, and more. The traditional approach is for the return code to be set non-zero (e.g., 4) when end of data is reached. For example: DO INF Do for all objects SOMESERV REQUEST=GETObtain next object DOEXIT LTR,R15,R15,NZ Exit if no more objects . . process the returned data . . . ENDDO , EndDo for all objects QSAM GET was invented before there were structured disciplines. Having the system branch to an arbitrary 'EODAD' label outside the GET loop increases the program's complexity and makes GET's behavior 'arcane' when compared to the processing methodology used by nearly every other service that has been invented since. An approach that sets a flag that can be tested in the loop solves this problem nicely, making GET's processing more mainstream. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: ASM Program to copy a file
On 12/8/2011 9:57 AM, Steve Comstock wrote: BAKR R14,0 Save caller's ARs and GPRs Why do you care about the caller's ARs? First, you are a main program so the caller is z/OS. Overkill. Why not use standard save area chaining? BAKR R14,0 is a standard entry linkage approach. (At least, it has been since the advent of ESA/390.) R13 should then be set to point to an F1SA. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: ASM Program to copy a file
On 12/8/2011 8:14 AM, Martin Truebner wrote: Much better solution is what (ITIR) Ed J. uses ... a MACRO called MVCSL (or so) which means MVC in sender length. I'm surprised you remember this! It was something I accidentally left in a sample code fragment in a SHARE presentation years ago. We call the macro MVC2: MVC using the length of the second operand. We also have MVCX: generate as many MVCs as needed to copy variables of any length without using MVCL. (Yes, I realize MVCX is the name of a millicode mnemonic, but I think the chances of that instruction being exposed to 'normal' code is unlikely.) We also have XCX, OCX, and others. I just realized we are missing MVC2X! Lol! -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Conditional assembly test for current AMODE
On 10/21/2011 5:40 AM, Tom Marchant wrote: On Thu, 20 Oct 2011 14:03:55 -0700, Edward Jaffe wrote: It's inconvenient to have to keep SYSSTATE manually synchronized. You could issue SYSSTATE first and then code a macro that tests SYSSTATE and uses it to specify the corresponding AMODE. Nice idea! -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Conditional assembly test for current AMODE
On 10/20/2011 12:23 PM, John Ehrman wrote: There is no system variable symbol that captures this information. Too bad. It would be useful to be able to code SYSSTATE operands based upon the value of a variable like &SYSAMODE--the AMODE of the CSECT at an entry point. The AMODE value in the ESD, propagated by the binder, is what drives the pointer-defined linkage that will ultimately give the module control in the right AMODE. It's inconvenient to have to keep SYSSTATE manually synchronized. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
