ADATA
I should also say: Ed make a useful suggestion - make some of these items Share requests. Also, John and I will be in San Francisco at the spring Share conference. We (am taking a liberty here - I've not asked John, but I'm sure the answer is yes) can sort out a conference room to discuss ADATA or other topics. Sharuff Sharuff Morsa - IBM Hursley Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Use of sequence numbering in current HLASM source?
I know where our love of putting sequence numbers in columns 73-80 comes from. But the only thing that I know of that continues to really use them is IEBUPDTE. So I'm wondering if it is really worth the bother to have them anymore. Now, most here would likely say what bother? ISPF makes it easy. True. *If* you are using the ISPF editor and keep your HLASM source code in a RECFM=FB,LRECL=80 data set. It may not be as well known here as in other fora, but I have a real liking for UNIX (and Linux). I mainly keep my source in z/OS UNIX files in specific subdirectories instead of as members in a PDS. I have also fallen in love with FLOWASM's free format input for HLASM. And, recently, I have gotten to liking using git on Linux for change control (it is a version control system such as CVS, Subversion, ...). So I am now often keeping a copy of my source in Linux as well. Since I can't use git in z/OS UNIX because I cannot find a port of it. So, other than being non main stream and even obsessively weird, is there any *technical* reason to maintain sequence numbers? -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
Re: Use of sequence numbering in current HLASM source?
On Nov 7, 2012, at 08:21, McKown, John wrote: I know where our love of putting sequence numbers in columns 73-80 comes from. But the only thing that I know of that continues to really use them is IEBUPDTE. ... So, other than being non main stream and even obsessively weird, is there any *technical* reason to maintain sequence numbers? Some of our anti-obsessively weird developers have insisted that it makes it easier to cite passages in code reviews. Their numbers are dwindling as we too use a UNIX-based source control system. But get Shmuel's opinion. -- gil
Re: Use of sequence numbering in current HLASM source?
I stopped using sequence numbers years ago, even though for 99% of my editing I use ISPF. As long as your source code maintenance software doesn't require it (most don't these days) I see no reason at all to use it. IMHO it clutters the translator/compiler listing with useless information. Whichever language I am working in (HLASM, COBOL Rexx, JCL/PROC, whatever), I mark the lines that I need to change with an identifying string or comment to leave the bread crumbs other maintainers will need to identify what I changed. No need for sequence numbers that I can see. I also haven't used IEBUPDTE in so long I would have to go back to the manual to figure out how to use it again. When I had the privilege of working in a VM environment decades ago, I used to make extensive use of the VMUPDATE facility to maintain software. IIRC even that excellent facility doesn't use sequence numbers but relative line number, but I could be mis-remembering that. Peter -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of McKown, John Sent: Wednesday, November 07, 2012 10:21 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Use of sequence numbering in current HLASM source? I know where our love of putting sequence numbers in columns 73-80 comes from. But the only thing that I know of that continues to really use them is IEBUPDTE. So I'm wondering if it is really worth the bother to have them anymore. Now, most here would likely say what bother? ISPF makes it easy. True. *If* you are using the ISPF editor and keep your HLASM source code in a RECFM=FB,LRECL=80 data set. It may not be as well known here as in other fora, but I have a real liking for UNIX (and Linux). I mainly keep my source in z/OS UNIX files in specific subdirectories instead of as members in a PDS. I have also fallen in love with FLOWASM's free format input for HLASM. And, recently, I have gotten to liking using git on Linux for change control (it is a version control system such as CVS, Subversion, ...). So I am now often keeping a copy of my source in Linux as well. Since I can't use git in z/OS UNIX because I cannot find a port of it. So, other than being non main stream and even obsessively weird, is there any *technical* reason to maintain sequence numbers? -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
Re: 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: Use of sequence numbering in current HLASM source?
I have not used sequence numbers, CAPS ON, and the like for many years. Those who have sentimental attachments to things of this sort---old habits die hard in some bailiwicks---are and should be free to use them. Specious arguments for their continued use are, of course, easy to construct; but even if I had a source-program deck to drop, I should be hard put to find the piece of unit-record equipment---What was it called?---required to put it back in sequence. --jg
Re: Use of sequence numbering in current HLASM source?
On Wed, Nov 7, 2012 at 10:21 AM, McKown, John john.mck...@healthmarkets.com wrote: ...snip... So, other than being non main stream and even obsessively weird, is there any *technical* reason to maintain sequence numbers? -- John McKown Systems Engineer IV IT John, We use sequence numbers to extract change lines from edited source modules. The developer making the change maintains the sequence numbers on new or on changed lines he adds/changes. When the change is finished, he then uses SUPERC with process option UPDMVS8 and compares the new changed source module to the prior release of that same source module. SUPERC then emits a change file in IEBUPDTE format. Those change files (we call them 'delta' files) identify which lines were changed and how. Multiple such delta files can then be saved and applied later, or backed out if need be. This lets more than one developer work on the same source module at the same time. It ain't CVS, but it works -- Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: Use of sequence numbering in current HLASM source?
For all types that I retrieve from Endevor (cobol asm macro copybook jcl proc parm ...) 73-80 is worse than useless. The first thing I do when the element is in my library is to do REN;UNNUM to eliminate them. If they exist and if you use ISPF edit and if you have no bnds (and in some cases if you do) they come into the useable area when the ( line command is used. At one time there was an attempt here to use 73-80 for change control. Since they are not on the normal ISPF edit screen on a 80 character wide green screen, they were too easy to lose. For cobol 1-6 tends to be used for change control. For asm, there is less discipline. I tend to use 68-71. One of the great features of asm is that comments can be on a line of code. That is one of the greatest annoyances of cobol. A construct like /*...*/ is very desirable. IBM Mainframe Assembler List ASSEMBLER-LIST@LISTSERV.UGA.EDU wrote on 11/07/2012 10:21:28 AM: From: McKown, John john.mck...@healthmarkets.com I know where our love of putting sequence numbers in columns 73-80 comes from. But the only thing that I know of that continues to really use them is IEBUPDTE. So I'm wondering if it is really worth the bother to have them anymore. Now, most here would likely say what bother? ISPF makes it easy. True. *If* you are using the ISPF editor and keep your HLASM source code in a RECFM=FB,LRECL=80 data set. It may not be as well known here as in other fora, but I have a real liking for UNIX (and Linux). I mainly keep my source in z/OS UNIX files in specific subdirectories instead of as members in a PDS. I have also fallen in love with FLOWASM's free format input for HLASM. And, recently, I have gotten to liking using git on Linux for change control (it is a version control system such as CVS, Subversion, ...). So I am now often keeping a copy of my source in Linux as well. Since I can't use git in z/OS UNIX because I cannot find a port of it. So, other than being non main stream and even obsessively weird, is there any *technical* reason to maintain sequence numbers? John McKown - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you
Re: Use of sequence numbering in current HLASM source?
What! You don't have an IBM 088 collator handy? How do you do daily processing? grin/ -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER- l...@listserv.uga.edu] On Behalf Of John Gilmore Sent: Wednesday, November 07, 2012 10:09 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Use of sequence numbering in current HLASM source? I have not used sequence numbers, CAPS ON, and the like for many years. Those who have sentimental attachments to things of this sort---old habits die hard in some bailiwicks---are and should be free to use them. Specious arguments for their continued use are, of course, easy to construct; but even if I had a source-program deck to drop, I should be hard put to find the piece of unit-record equipment---What was it called?---required to put it back in sequence. --jg
Re: ADATA
Hello Sharuff, I think the main problem people have with ADATA is that it's so extraordinarily verbose. That, I suppose, is why you wrote ASMLANGX for IDF. I suppose if IBM would create user settable (and resettable) controls in HLASM over which particular ADATA record types did and did not get generated, that would be a help. Also, many programs are constructed from numerous separately assembled elements. Generally, in such cases, there will be a control blocks definition section that is similar across all of the assemblies. It would be useful to provide a way to turn off (and later turn back on) the generation of all ADATA for selected ranges of source statements. Further, this mechanism should be nestable so that it can be safely invoked in broadly used macros. In my own case, z/XDC is built from nearly 200 separate assemblies. Each has a cblocks section that provides to its particular assembly selected cblock maps from a much larger product-wide set. Then I have one DOC assembly (similar in concept to JES2's HASPDOC) that does nothing but generate assemblies of the entire set of mapping macros used by z/XDC. If I could turn off ADATA generation across just the cblocks sections of all of my assemblies (except the DOC assembly), that would save tens of thousands of tracks of DASD space. Finally, since a lot of ADATA consists of nulls and particularly blank strings, even something so simple minded as a run length encoding compression would save significant space (PARM controlled, of course). WRT SHARE, I am not generally involved in SHARE, and in particular, I will not be attending the SFO SHARE. So I will leave it to others who (hopefully) think these are good ideas to create suitable SHARE requirements. Absent that, I will develop my own custom solutions. Thank you for your consideration of these ideas. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 At 11/7/2012 02:44 AM, Sharuff Morsa3 wrote: So, tell me what the ADATA issues are, what you'd like to see change and HLASM improve. Asking for ASMLANX may not be the answer. I (believe) RFE entries can be marked private. RFEs allow us to review requirements understand what required by users. You can vote on RFE items. Go create them. Go read http://www-01.ibm.com/support/docview.wss?uid=swg21577670 (and the usual caveats - no promises - but I do need RFEs in order to pursue user requested enhancements) Sharuff Sharuff Morsa - IBM Hursley Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU At 11/7/2012 04:47 AM, Sharuff Morsa3 wrote: I should also say: Ed make a useful suggestion - make some of these items Share requests. Also, John and I will be in San Francisco at the spring Share conference. We (am taking a liberty here - I've not asked John, but I'm sure the answer is yes) can sort out a conference room to discuss ADATA or other topics. Sharuff Sharuff Morsa - IBM Hursley Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: Use of sequence numbering in current HLASM source?
On 11/7/2012 10: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? I think this is another religious issue not worth fighting over. Some programs are maintained with strict sequence numbers, and a utility such as IEBUPDTE or IEBUPDTX is used to maintain changes. (Does anyone still use IEBUPDAT?). There are some reasons for this use, such as maintenance of commercial software, but even that is declining. Some programs maintain sequence numbers, but with frequent alteration (RENUM, etc.). These I rely upon heavily. For one, they make it easier to disambiguate roughly similar code sequences (more prevalent in assembler?). More importantly, they make it trivially simple to edit code after reading a virtual or physical program listing (Locating by line number rather than search). Gerhard Postpischil Bradford, Vermont
Re: Use of sequence numbering in current HLASM source?
So, in summary, use them or not as the individual or company dictates. I don't really lose any capability by keeping my source as I do, without sequence numbers. Thanks to all. It was interesting to read that some still do have a use for these. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
Re: Use of sequence numbering in current HLASM source?
There are some reasons, albeit llittle known, to keep line numbers: 1. With STATS and NUM on, ISPF edit stores the edit session number in 79-80. It's the same as the MM of VV.MM column in the ISPF member list. This information is useful in edit, browse, and compiler/assembly listings. 2. With the default increment, listings (whether printed or on DASD) are still useful even after modest changes. Anything that preserves information and/or promotes productivity is a good thing. On the down-side, the ISPF edit locate (L) command can't be used with the line numbers in messages. So I use an edit macro that I call LL. This is a bare-bones version: /* REXX */ address isredit macro (LinCount) up max down LinCount return 0 Also on the down-side, you loose some potential source code real estate. Unless you are using a 3278-5 (132x27emulation configuration), and have the right ISPF terminal settings, this is no big loss. Most people choose not to scroll left and right to use that area on 80 column emulation. On Wed, Nov 7, 2012 at 2:15 PM, McKown, John john.mck...@healthmarkets.comwrote: So, in summary, use them or not as the individual or company dictates. I don't really lose any capability by keeping my source as I do, without sequence numbers. Thanks to all. It was interesting to read that some still do have a use for these. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.comhttp://www.healthmarkets.com/ Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- OREXXMan
Re: Use of sequence numbering in current HLASM source?
I would prefer the 083 sorter. Nothing made me appreciate computers and mag tape so much as sorting 6 million cards on 12 columns, the first of which was alphanumeric. 18 machines, 5 people, days and yes I would like to be buried face down 9 edge first. :-) IBM Mainframe Assembler List ASSEMBLER-LIST@LISTSERV.UGA.EDU wrote on 11/07/2012 12:06:13 PM: From: McKown, John john.mck...@healthmarkets.com To: ASSEMBLER-LIST@LISTSERV.UGA.EDU, Date: 11/07/2012 12:19 PM Subject: Re: Use of sequence numbering in current HLASM source? Sent by: IBM Mainframe Assembler List ASSEMBLER-LIST@LISTSERV.UGA.EDU What! You don't have an IBM 088 collator handy? How do you do daily processing? grin/ -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid- West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER- l...@listserv.uga.edu] On Behalf Of John Gilmore Sent: Wednesday, November 07, 2012 10:09 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Use of sequence numbering in current HLASM source? I have not used sequence numbers, CAPS ON, and the like for many years. Those who have sentimental attachments to things of this sort---old habits die hard in some bailiwicks---are and should be free to use them. Specious arguments for their continued use are, of course, easy to construct; but even if I had a source-program deck to drop, I should be hard put to find the piece of unit-record equipment---What was it called?---required to put it back in sequence. --jg - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you
ISPF EDIT hi-liting of packed literals?
I recently noticed that some assembler comments were being hi-lited strangely within the ISPF editor. I finally realized that this was only on packed decimal literals, the high-lighter is treating the closing quote of the packed value (without an explicit length) as if it were the opening quote of a character literal. This seems to have started when we upgraded to z/OS 1.13. Example (non-assembling) code: TEST2TITLE 'Test assembler' TEST2CSECT CLC CHAR,=C'AA' Character CLC PACK,=P'10' Packed ---WRONG! CLC PACK,=PL3'11' Packed CLC BIN,=F'20'Fullword CLC BIN,=H'20'Halfword END The list server won't accept images, so copy the above into an ISPF edit session, and switch hi-liting on. Can someone verify that hi-liting works properly in ISPF edit prior to z/OS 1.13 for me. Robert Ngan CSC Financial Services Group
