Re: possible RFEs (was Re: Making ILMA=YES a default option)
If anyone has a "possible RFE" I would suggest submitting it as ... an RFE. Information on how to do this is at the following URL, which is also shown as the "Requirements" link at the end of the HLASM listing report generated by the INFO option. http://www.ibm.com/support/docview.wss?uid=swg21577670 But don't get your hopes up too much; HLASM already has a huge list of suggested enhancements (mostly collected by the late and greatly missed Dr John Ehrman) but most of the low-hanging fruit has been picked long ago. Jonathan Scott, HLASM IBM Hursley, UK
Re: Making ILMA=YES a default option
Ref: Your note of Wed, 16 May 2018 10:30:18 -0400 Steve Smith writes: > I certainly agree, and although I suppose it's virtually impossible, I'd > get rid of the option altogether. As you state, it's practically > inconceivable anyone would exploit that hole. I realize that protecting > compatibility is important, but let's be reasonable. Thanks for the feedback. We definitely have to continue to accept the ILMA/NOILMA option in order to avoid causing errors in existing assembly jobs or source files that specify it. It's probably not so important that NOILMA actually does anything, but as the option has been implemented all we need to do is to change the default. It should really also apply to SYSLIB macros. When a SYSLIB macro is found, it is read into storage and an entry is added to the current OPTABLE referring to that copy of the macro, so if the same macro is used after changing OPTABLE, it is not found in the OPTABLE and a new copy is loaded, which is generally harmless apart from being inefficient. This code is used for inline macros too, but when the ILMA option was added the programmer decided for some reason to add a specific check to make it apply only to inline macros. My guess is that the culture of "if it ain't broke, don't fix it" led to an excess of caution in this case. So if we do ship an APAR to change the default, I might well suggest that we also apply the same logic to SYSLIB macros (which would merely involve deleting the check for an inline macro). Jonathan Scott, HLASM IBM Hursley, UK
Re: Making ILMA=YES a default option
I certainly agree, and although I suppose it's virtually impossible, I'd get rid of the option altogether. As you state, it's practically inconceivable anyone would exploit that hole. I realize that protecting compatibility is important, but let's be reasonable. sas
Re: possible RFEs (was Re: Making ILMA=YES a default option)
I sent a private note to John with more details... But - Systems/ASM originally expanded characters and we found that broke some things; so we reverted to the HLASM behavior (expanding characters in comment fields caused lines to grow past column 72.) We do have a "-tc" option (tab column). If you set it, we will expand characters to the given column multiple. Regarding looking for macros/copy decks. We originally did specify a ".mac" extension... but users desired more flexibility. So, now we have options that specify search templates (the macro/copy name is expanded in the template to produce a file name to attemp to open.) This lets you have a lot of flexibility in the search, to use whatever extension you'd like, whatever path names you'd like, etc... it's very flexible across multiple environments. Consider too, the problem of "caseness". The user can have: copy mybook Should you look for a file named "mybook" - or a file named "MYBOOK". Our templates allow you to indicate how that search should proceed. (This matters less on case-insensitive file systems like Windows and Mac, but on z/Linux or USS it's important.) We also allow the name of the macro to be larger than 8; but that's incompatible with HLASM. Our users tend to move between the two products and thus live with the HLASM restriction. I kinda like the idea of using " to extend how copy might work, to be more like how #include works in C. Not sure what the implications on macro names might be (you would need to allow for a quoted opcode, I suppose.) - Dave Rivers - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
possible RFEs (was Re: Making ILMA=YES a default option)
On Wed, May 16, 2018 at 2:57 AM, Jonathan Scott wrote: > > > > As the current HLASM team leader, > As an aside, since you are the team leader, I would like to ask a question. I know that you cannot speak officially here, but I'm hoping you can give your personal opinion. I like to maintain my source code in z/OS UNIX files instead of PDS members. There are two things which I would really love to have in HLASM. The first is to treat tab characters as special as in "insert blanks here up to the next significant column as defined in the ICTL". E.g. opcodeoperandsX (where the X is in the continuation column). In addition to this, I would love a "free format" input which is not FB/80 dependant. This is basically what the FLOWASM exit does for us. The problem with FLOWASM is that I cannot guarantee that it can be installed by everyone who might want some of my code ( it could happen!) . Some companies are very strict about installing "free" software. I am not sure, but this might make HLASM more palatable to people who use HLASM on z/Linux. Going further afield, and like being too pushy, I really which that I could easily keep my HLASM macros in UNIX files. Yes, I can do so now, but they must be like the historical PDS member names: no more that 8 characters and limited to upper case English characters, digits, and the three national characters. I would love to be able to put an extension on my macros (perhaps .mac) and be able to tell HLASM that any COPY members or when searching for a macro to first use the given name, and if not found, then try again after appending the default extension. Going even further, it would be nice if I could use _any_ UNIX file name as a COPY or MACRO name, perhaps by enclosing it in " marks. E.g. COPY "/some/directory/FileName.mac" copy "../../AnotherFile.copycode" "unix-macro.mac" operands "UNIX-macro.mac" operands Note that the last two are different macro names and would be treated as such by HLASM. I.e. they would be case significant because they are in " marks. I know that the above is most likely going to be rejected because it would be a significant amount of work for something that the majority of HLASM customers don't need. But, it can't hurt to ask, can it? > > > Jonathan Scott, HLASM > IBM Hursley, UK > -- We all have skeletons in our closet. Mine are so old, they have osteoporosis. Maranatha! <>< John McKown
Making ILMA=YES a default option
We've just shipped the PTFs for HLASM APAR PI97142, which fixes up quite a few loose ends in options processing, especially some oversights in OPTABLE processing. When support for dynamically changing the OPTABLE with *PROCESS and ACONTROL was added, several implications of this change were not spotted at the time, and there have been several fixes to this area over the years as people have started to exploit this function. For example, only a few weeks ago APAR PI95384 fixed OPSYN to ensure that it applied to all OPTABLEs in which the relevant instruction instance was defined, not just the current optable, ensuring that IEABRCX was still able to convert branches within code which used ACONTROL to switch to a different OPTABLE. As part of APAR PI97142, the ASMAOPT macro which is used to generate the installation default options module ASMADOPT now supports the option ILMA=YES, which ensures that in-line macros are automatically assumed to apply to all OPTABLE instruction sets. However, for "compatibility" with the situation before this option was provided, the default is currently ILMA=NO. I personally do not understand why it was previously considered a good idea to provide the ILMA/NOILMA option to preserve the original undocumented and unhelpful behaviour, as I cannot think of any good reason to support the capability to define different macros of the same name for different OPTABLE values. I'd agree that it's possible to invent a way to use this function, for example to generate different instructions within macros for different OPTABLEs, but it is already possible to do that with the existing capabilities for a macro to test the OPTABLE value (or to achieve a similar effect by testing the operation code attribute of an opcode to determine whether it is supported for the current OPTABLE). As the current HLASM team leader, I am considering changing the default in the supplied defaults module to ILMA=YES, which although technically incompatible is far more useful, and might help reduce the frequency with which we have to tell users that specifying the ILMA option will fix their problems. I would like to know if anyone on this list has any opinions on this change, especially if they are aware of any possible negative impact of this change. (If an installation has its own default options module and does not reassemble it after this change, they would not pick up the new default of ILMA=YES until they reassembled it or dropped back to the supplied default options module). Jonathan Scott, HLASM IBM Hursley, UK
