Ah, but I prefer to have a WRITE at the bottom of the routine to show what was assigned every time the routine is executed, and EXIT statements prevent you from having that.
On Thu, Aug 4, 2011 at 3:27 PM, Darth Keller <darth.kel...@assurant.com>wrote: > >>I would like to add the following observation: > >>Why use a SELECT structure, and then use > >> DO > >> SET &STORGRP = 'xxxxxxxx' > >> EXIT > >> END > > >>When you could code it more like this: > >>SELECT > >> WHEN (&HLQ = &HSM_HLQ) /* MANAGE MULTI VOLUME HFS DATA SETS */ > >> SET &STORGRP = 'HFSCLASS' > >> WHEN (&HLQ = &ZFS_HLQ) /* MANAGE MULTI VOLUME ZFS DATA SETS */ > >> SET &STORGRP = 'ZFSCLASS' > >> WHEN (&HLQ = &HS1_HLQ) /* MANAGE HFS DATA SETS*/ > >> SET &STORGRP = 'DBCLASS > >> END > >>END /* END OF STORAGE GROUP ROUTINE PROC */ > > >>I find the second case much more readable. > > I would NEVER recommend that. My recommendation would be to use DO-END > Pairs and WRITE statements (ALWAYS) > and EXIT's (Almost Always). The above code maybe be shorter, but gives > you absolutely no help when > it comes time to debug a problem in the future. I don't care how pretty > the code is, I want to know how > much it's going to help me at o-dark in the morning when I trying to > figure out some issue. > > Readability is in the eye of the beholder - I much rather provide as much > assistance to myself and co-workers as > possible.. > > SELECT > WHEN (stmt) > DO > SET stmt > WRITE "identifying information" > EXIT > END > - etc - > END > > WRITE statements provide identifiable exit points in the code. You know > immediately where the dataset assignment > fell out of the code. I almost always code an EXIT statement to prevent > re-assignments later in the code. When I chose not to > code an EXIT, it's because I've specifically chosen not to & understand > exactly what it means. > > It's all personal preference in the end, but why not take the opportunity > to help yourself right from the beginning? > > dd keller > > > This e-mail message and all attachments transmitted with it may > contain legally privileged and/or confidential information intended > solely for the use of the addressee(s). If the reader of this > message is not the intended recipient, you are hereby notified that > any reading, dissemination, distribution, copying, forwarding or > other use of this message or its attachments is strictly > prohibited. If you have received this message in error, please > notify the sender immediately and delete this message and all > copies and backups thereof. Thank you. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
