Re: Cobol question
Rex, at this link you'll find an interesting thread: https://groups.google.com/g/bit.listserv.ibm-main/c/B04G-HasOd4 As somebody (who is at least 30K light years beyond me) probably the right way is to use TIMEUSED macro. It depends on how much you need to rely the info. I recently wrote an assembler interface to do the needed using the new instructions (without too many checks to be honest). It seems the new way (ECT=YES) invocation costs very less than before. Best regards. Max Il giorno mar 11 lug 2023 alle ore 23:44 Joe Monk ha scritto: > You can always map the TCB and reference field TCBTTIME to get the > accumulated CPU time for the task - I think its offset 316 decimal. > > Joe > > On Tue, Jul 11, 2023 at 4:22 PM Pommier, Rex > wrote: > > > Hey all, > > > > I just got this tossed at me by an application developer. Cobol 6.3. Is > > there some built-in function or something that they can put into a > program > > to report out the amount of CPU (TCB) time the program has consumed thus > > far in execution of the program? We have a program that processes > > accounts, and at the beginning of every account it prints the account > > number and wall clock timestamp. The developers would like to also > report > > out how much CPU the program has consumed at the same time as the wall > > clock. I don't know of any but if somebody has an idea off the top of > > their head, I'll listen. > > > > TIA, > > > > Rex > > > > -- > > The information contained in this message is confidential, protected from > > disclosure and may be legally privileged. If the reader of this message > is > > not the intended recipient or an employee or agent responsible for > > delivering this message to the intended recipient, you are hereby > notified > > that any disclosure, distribution, copying, or any action taken or action > > omitted in reliance on it, is strictly prohibited and may be unlawful. If > > you have received this communication in error, please notify us > immediately > > by replying to this message and destroy the material in its entirety, > > whether in electronic or hard copy format. Thank you. > > > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol question
You can always map the TCB and reference field TCBTTIME to get the accumulated CPU time for the task - I think its offset 316 decimal. Joe On Tue, Jul 11, 2023 at 4:22 PM Pommier, Rex wrote: > Hey all, > > I just got this tossed at me by an application developer. Cobol 6.3. Is > there some built-in function or something that they can put into a program > to report out the amount of CPU (TCB) time the program has consumed thus > far in execution of the program? We have a program that processes > accounts, and at the beginning of every account it prints the account > number and wall clock timestamp. The developers would like to also report > out how much CPU the program has consumed at the same time as the wall > clock. I don't know of any but if somebody has an idea off the top of > their head, I'll listen. > > TIA, > > Rex > > -- > The information contained in this message is confidential, protected from > disclosure and may be legally privileged. If the reader of this message is > not the intended recipient or an employee or agent responsible for > delivering this message to the intended recipient, you are hereby notified > that any disclosure, distribution, copying, or any action taken or action > omitted in reliance on it, is strictly prohibited and may be unlawful. If > you have received this communication in error, please notify us immediately > by replying to this message and destroy the material in its entirety, > whether in electronic or hard copy format. Thank you. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Cobol question
Hey all, I just got this tossed at me by an application developer. Cobol 6.3. Is there some built-in function or something that they can put into a program to report out the amount of CPU (TCB) time the program has consumed thus far in execution of the program? We have a program that processes accounts, and at the beginning of every account it prints the account number and wall clock timestamp. The developers would like to also report out how much CPU the program has consumed at the same time as the wall clock. I don't know of any but if somebody has an idea off the top of their head, I'll listen. TIA, Rex -- The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL question: How to dynamically get the name of the routine that called you
Thanks Michael, I tried your routine here and it did exactly what I needed, so thank you. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Schmitt, Michael Sent: Tuesday, May 2, 2023 3:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL question: How to dynamically get the name of the routine that called you I am attempting to post the assembler program here for reference, we'll see if the listserv accepts it without mangling. To use, call it passing the area you want it to return the calling program name in. The call_level_e equate controls how many levels up it goes. 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL question: How to dynamically get the name of the routine that called you
Is this z/OS? I hope so ... You say: I need this for determining from where a high-usage subroutine is being called unnecessarily in a large main program (many called modules with multiple levels of CALL, but no recursion). are these modules separate load modules which are dynamically called and is the name of the load module (which may be identical to the program-ID) sufficient? If so, there is no need to rely on the program name which is stored somewhere in the EPA signature (PPA1 block). It is then possible to simply retrieve the EPA from the save area chain and check, to which load module this entry point belongs, using the OS control blocks CDE and XTLST, which is IMO a well-known method (and has no dependency on compiler releases or even programming languages). I wrote some dump analysis tools for customers, and they always do both methods, just in case that some "free style" ASSEMBLER programs in the chain don't mark the entry points in some of the known ways. Then we still have the name of the load module (and maybe the offset of the entry point, if it is non-zero). HTH, kind regards Bernd Am 02.05.2023 um 19:08 schrieb Schmitt, Michael: I wrote an assembler subprogram that gets the name of the caller of the caller, i.e. if A > B > asm, it returns A. Or any number of levels up that you want. It works for static and dynamic calls, for both Language Environment compatible and non-LE programs.* The logic to get the program name is non-trivial. For example, in an LE compatible program it depends on if the Program Prolog Area is in FASTLINK format or not. I don't think this is possible to do in straight COBOL, because how would you get access to the registers for the save area chain? But maybe there's an LE service that could help. Let me know if you're interested in the assembler program. * assuming the program follows standard conventions for the program id signature string. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter Sent: Tuesday, May 2, 2023 11:23 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: COBOL question: How to dynamically get the name of the routine that called you This is an Enterprise COBOL V5/6 question. No earlier compiler versions are involved. Is it possible for a called COBOL program to dynamically determine the name of the calling COBOL program (i.e., the PROGRAM-ID value)? I have been reading the LE Vendor Interfaces manual but I have yet to figure out now to use any of the documented services or control blocks to get the name of the caller. I need this for determining from where a high-usage subroutine is being called unnecessarily in a large main program (many called modules with multiple levels of CALL, but no recursion). The subroutine unfortunately is NOT passed the name of the caller in the LINKAGE parameters (that would have been too easy . . . ). Any RTFM pointers or process to follow to get the caller's name would be appreciated. I am willing to set up an assembler stub routine to capture the data if it cannot be done directly from the COBOL called subroutine. Peter -- 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL question: How to dynamically get the name of the routine that called you
I am attempting to post the assembler program here for reference, we'll see if the listserv accepts it without mangling. To use, call it passing the area you want it to return the calling program name in. The call_level_e equate controls how many levels up it goes. -- setc 'CALLERID' title ' - Return name of program caller' csect amode 31 rmode any using *,r15 sysstate archlvl=OSREL, generate z/Architecture code+ osrel=SYSSTATE macro , sysdatc can't be in open code get_asmtime gblc setc '' date as MMDD aread clockd time as HHMMSSTH setc ''(1,4).'-'.''(5,2).'-'.''(7,2) formatted date setc ''(1,2).':'.''(3,2).':'.''(5,2) formatted time setc ' ' mend gblc get assembly date & time get_asmtime j start skip over program id dcal1(l'prog_id) count byte for program id prog_id dcc' ' savearea dc18f'0' save area and my base address startbsm r14,r0 put caller's AMODE in r14 stm r14,r12,12(r13) save caller's registers lrr2,r13 r2 -> caller's save area lar13,savearear13 -> my save area & base str13,8(,r2) set forward chain from caller str2,4(,r13) set backward chain to caller drop r15 using savearea,r13r13 is my base register srr15,r15 clear return code l r14,=a(mainline+x'8000') set 31 bit mode bsm r0,r14 branch to mainline eojgood srr15,r15 good return: rc = 0 eoj l r13,4(,r13) point back to caller's save area str15,16(,r13)set return code lmr14,r12,12(r13) restore caller's registers oi15(r13),x'01' set return indication bsm r0,r14 return to caller & caller's mode call_level_e equ 2 How many programs up do we go? * Return codes: * 0 - CALL LEVEL caller found, name returned * 4 - Requested CALL LEVEL not found. Highest caller returned. * 8 - Incorrect usage: CALLERID directly called by MVS or no * parm provided. No caller returned. * * Registers: * R0 - Standard system use, work register * R1 - Standard system use, work register * R2 - Standard system use * R3 - Caller name parm * R4 - Loop counter * R5 - Save area chain pointer * R6 - Entry point of caller * R7 - Language Environment Program Prolog Area 1 (PPA1) * R8 - Name of caller * R9 - * R10 - * R11 - * R12 - * R13 - Base register, save area pointer * R14 - * R15 - Standard system use mainline ds 0h ltr r1,r1 if called with no parm jnz main_l000 lar15,8 rc=8: usage error j eojreturn main_l000 ds 0hend if l r3,0(,r1) save caller name parm address using caller_name_dsect,r3 lar4,call_level_e r4 = number of callers to find srr6,r6 init r6 to no entry point srr8,r8 init r8 to no callers found l r5,savprev-saver(,r13) r5 -> my caller's save area using saver,r5 main_l100 ds 0hdo CALL LEVEL times l r5,savprev climb chain ltr r5,r5 if end of chain jnz main_l120 ltr r8,r8 if no callers found jnz main_l110 lar15,8rc=8: usage error j eoj return main_l110 ds 0h else lar15,4rc=4: Not enough calls j main_l190 found, leave *end if main_l120 ds 0h end if l r1,savgrs15r1 = candidate entry point lar1,0(,r1) clear mode bit crr6,r1 if same as last entry point jemain_l100 iterate lrr6,r1 r6 -> entry point clc le_signature_c,5(r6) if not Lang Environment prog jemain_l130 lar8,5(,r6) use program id for caller j main_l150 main_l130 ds 0h else lrr7,r6 r7 -> Program Prolog Area
Re: COBOL question: How to dynamically get the name of the routine that called you
You use the LE service CEETBCK. This is the traceback utility and can be used to walk the call chain backwards from Enteprise COBOL. Joe On Tue, May 2, 2023 at 12:08 PM Schmitt, Michael wrote: > I wrote an assembler subprogram that gets the name of the caller of the > caller, i.e. if A > B > asm, it returns A. Or any number of levels up that > you want. It works for static and dynamic calls, for both Language > Environment compatible and non-LE programs.* > > The logic to get the program name is non-trivial. For example, in an LE > compatible program it depends on if the Program Prolog Area is in FASTLINK > format or not. > > I don't think this is possible to do in straight COBOL, because how would > you get access to the registers for the save area chain? But maybe there's > an LE service that could help. > > > Let me know if you're interested in the assembler program. > > > * assuming the program follows standard conventions for the program id > signature string. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Farley, Peter > Sent: Tuesday, May 2, 2023 11:23 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: COBOL question: How to dynamically get the name of the routine > that called you > > This is an Enterprise COBOL V5/6 question. No earlier compiler versions > are involved. > > Is it possible for a called COBOL program to dynamically determine the > name of the calling COBOL program (i.e., the PROGRAM-ID value)? I have > been reading the LE Vendor Interfaces manual but I have yet to figure out > now to use any of the documented services or control blocks to get the name > of the caller. > > I need this for determining from where a high-usage subroutine is being > called unnecessarily in a large main program (many called modules with > multiple levels of CALL, but no recursion). The subroutine unfortunately > is NOT passed the name of the caller in the LINKAGE parameters (that would > have been too easy . . . ). > > Any RTFM pointers or process to follow to get the caller's name would be > appreciated. I am willing to set up an assembler stub routine to capture > the data if it cannot be done directly from the COBOL called subroutine. > > Peter > -- > > > 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. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL question: How to dynamically get the name of the routine that called you
I wrote an assembler subprogram that gets the name of the caller of the caller, i.e. if A > B > asm, it returns A. Or any number of levels up that you want. It works for static and dynamic calls, for both Language Environment compatible and non-LE programs.* The logic to get the program name is non-trivial. For example, in an LE compatible program it depends on if the Program Prolog Area is in FASTLINK format or not. I don't think this is possible to do in straight COBOL, because how would you get access to the registers for the save area chain? But maybe there's an LE service that could help. Let me know if you're interested in the assembler program. * assuming the program follows standard conventions for the program id signature string. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter Sent: Tuesday, May 2, 2023 11:23 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: COBOL question: How to dynamically get the name of the routine that called you This is an Enterprise COBOL V5/6 question. No earlier compiler versions are involved. Is it possible for a called COBOL program to dynamically determine the name of the calling COBOL program (i.e., the PROGRAM-ID value)? I have been reading the LE Vendor Interfaces manual but I have yet to figure out now to use any of the documented services or control blocks to get the name of the caller. I need this for determining from where a high-usage subroutine is being called unnecessarily in a large main program (many called modules with multiple levels of CALL, but no recursion). The subroutine unfortunately is NOT passed the name of the caller in the LINKAGE parameters (that would have been too easy . . . ). Any RTFM pointers or process to follow to get the caller's name would be appreciated. I am willing to set up an assembler stub routine to capture the data if it cannot be done directly from the COBOL called subroutine. Peter -- 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
COBOL question: How to dynamically get the name of the routine that called you
This is an Enterprise COBOL V5/6 question. No earlier compiler versions are involved. Is it possible for a called COBOL program to dynamically determine the name of the calling COBOL program (i.e., the PROGRAM-ID value)? I have been reading the LE Vendor Interfaces manual but I have yet to figure out now to use any of the documented services or control blocks to get the name of the caller. I need this for determining from where a high-usage subroutine is being called unnecessarily in a large main program (many called modules with multiple levels of CALL, but no recursion). The subroutine unfortunately is NOT passed the name of the caller in the LINKAGE parameters (that would have been too easy . . . ). Any RTFM pointers or process to follow to get the caller's name would be appreciated. I am willing to set up an assembler stub routine to capture the data if it cannot be done directly from the COBOL called subroutine. Peter -- 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL question
Thanks. Just to be clear. I am running under EXPEDITER. The program runs almost to completion. The last two things I do: 1. If the Address is not NULL -> FREE 2. GOBACK. Thanks …….Cameron From: IBM Mainframe Discussion List On Behalf Of Joe Monk Sent: Monday, April 10, 2023 9:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: COBOL question A lot of times, U4038 is not enough region... Joe On Mon, Apr 10, 2023 at 6:15 AM Cameron Conacher < 03cfc59146bb-dmarc-requ...@listserv.ua.edu<mailto:03cfc59146bb-dmarc-requ...@listserv.ua.edu>> wrote: > Good call > > I ALLOCATE once. > And just before GOBACK, I issue the FREE. Just one time. > I am thinking it might be related to EXPEDITER. > > That is my current WAG. > > > Thanks > > …….Cameron > > -Original Message- > From: IBM Mainframe Discussion List > mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf > Of Charles Mills > Sent: Sunday, April 9, 2023 8:07 PM > To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU> > Subject: [External] Re: COBOL question > > I can't see your code of course but my WAG is a programmer logic error. > (Sorry!) I am going to guess your logic is such that you try to free the > same area twice or, less likely, corrupt your pointer. > > You say you check to see if it is null before freeing. Do you set it to > NULL after freeing? > > Charles > > On Sun, 9 Apr 2023 23:01:05 +, Cameron Conacher < > cameron.conac...@aexp.com<mailto:cameron.conac...@aexp.com>> wrote: > > >Thanks Bob, > >No I initialize the Pointer to NULL, and then allocate. Successfully. > >And then later I check to see it the pointer = NULL. If it is not NULL, > then I do the FREE. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with the > message: INFO IBM-MAIN > > American Express made the following annotations > > This e-mail was sent to you by a representative of Amex Bank of Canada, > P.O. Box 3204, Station "F", Toronto, ON, M1W 3W7, > www.americanexpress.ca<https://isolate.menlosecurity.com/1/3735928037/http:/www.americanexpress.ca>. > If you no longer wish to receive these e-mails, please notify the sender by > reply e-mail. > > This e-mail is solely for the intended recipient and may contain > confidential or privileged information. If you are not the intended > recipient, any disclosure, copying, use, or distribution of the information > included in this e-mail is prohibited. If you have received this e-mail in > error, please notify the sender by reply e-mail and immediately and > permanently delete this e-mail and any attachments. Thank you. > > American Express a fait les remarques suivantes > Ce courriel vous a été envoyé par un représentant de la Banque Amex du > Canada, C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, > www.americanexpress.ca<https://isolate.menlosecurity.com/1/3735928037/http:/www.americanexpress.ca>. > Si, par la suite, vous ne souhaitez plus recevoir > ces courriels, veuillez en aviser les expéditeurs par courriel. > > Ce courriel est réservé au seul destinataire indiqué et peut renfermer des > renseignements confidentiels et privilégiés. Si vous n’êtes pas le > destinataire prévu, toute divulgation, duplication, utilisation ou > distribution du courriel est interdite. Si vous avez reçu ce courriel par > erreur, veuillez en aviser l’expéditeur par courriel et détruire > immédiatement le courriel et toute pièce jointe. Merci. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with > the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with the message: INFO IBM-MAIN American Express made the following annotations This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no longer wish to receive these e-mails, please notify the sender by reply e-mail. This e-mail is solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any disclosure, copying, use,
Re: COBOL question
A lot of times, U4038 is not enough region... Joe On Mon, Apr 10, 2023 at 6:15 AM Cameron Conacher < 03cfc59146bb-dmarc-requ...@listserv.ua.edu> wrote: > Good call > > I ALLOCATE once. > And just before GOBACK, I issue the FREE. Just one time. > I am thinking it might be related to EXPEDITER. > > That is my current WAG. > > > Thanks > > …….Cameron > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Charles Mills > Sent: Sunday, April 9, 2023 8:07 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [External] Re: COBOL question > > I can't see your code of course but my WAG is a programmer logic error. > (Sorry!) I am going to guess your logic is such that you try to free the > same area twice or, less likely, corrupt your pointer. > > You say you check to see if it is null before freeing. Do you set it to > NULL after freeing? > > Charles > > On Sun, 9 Apr 2023 23:01:05 +, Cameron Conacher < > cameron.conac...@aexp.com> wrote: > > >Thanks Bob, > >No I initialize the Pointer to NULL, and then allocate. Successfully. > >And then later I check to see it the pointer = NULL. If it is not NULL, > then I do the FREE. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > American Express made the following annotations > > This e-mail was sent to you by a representative of Amex Bank of Canada, > P.O. Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. > If you no longer wish to receive these e-mails, please notify the sender by > reply e-mail. > > This e-mail is solely for the intended recipient and may contain > confidential or privileged information. If you are not the intended > recipient, any disclosure, copying, use, or distribution of the information > included in this e-mail is prohibited. If you have received this e-mail in > error, please notify the sender by reply e-mail and immediately and > permanently delete this e-mail and any attachments. Thank you. > > American Express a fait les remarques suivantes > Ce courriel vous a été envoyé par un représentant de la Banque Amex du > Canada, C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, > www.americanexpress.ca. Si, par la suite, vous ne souhaitez plus recevoir > ces courriels, veuillez en aviser les expéditeurs par courriel. > > Ce courriel est réservé au seul destinataire indiqué et peut renfermer des > renseignements confidentiels et privilégiés. Si vous n’êtes pas le > destinataire prévu, toute divulgation, duplication, utilisation ou > distribution du courriel est interdite. Si vous avez reçu ce courriel par > erreur, veuillez en aviser l’expéditeur par courriel et détruire > immédiatement le courriel et toute pièce jointe. Merci. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL question
Good call I ALLOCATE once. And just before GOBACK, I issue the FREE. Just one time. I am thinking it might be related to EXPEDITER. That is my current WAG. Thanks …….Cameron -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Sunday, April 9, 2023 8:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: COBOL question I can't see your code of course but my WAG is a programmer logic error. (Sorry!) I am going to guess your logic is such that you try to free the same area twice or, less likely, corrupt your pointer. You say you check to see if it is null before freeing. Do you set it to NULL after freeing? Charles On Sun, 9 Apr 2023 23:01:05 +, Cameron Conacher wrote: >Thanks Bob, >No I initialize the Pointer to NULL, and then allocate. Successfully. >And then later I check to see it the pointer = NULL. If it is not NULL, then I >do the FREE. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN American Express made the following annotations This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no longer wish to receive these e-mails, please notify the sender by reply e-mail. This e-mail is solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by reply e-mail and immediately and permanently delete this e-mail and any attachments. Thank you. American Express a fait les remarques suivantes Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser les expéditeurs par courriel. Ce courriel est réservé au seul destinataire indiqué et peut renfermer des renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire prévu, toute divulgation, duplication, utilisation ou distribution du courriel est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce jointe. Merci. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL question
I can't see your code of course but my WAG is a programmer logic error. (Sorry!) I am going to guess your logic is such that you try to free the same area twice or, less likely, corrupt your pointer. You say you check to see if it is null before freeing. Do you set it to NULL after freeing? Charles On Sun, 9 Apr 2023 23:01:05 +, Cameron Conacher wrote: >Thanks Bob, >No I initialize the Pointer to NULL, and then allocate. Successfully. >And then later I check to see it the pointer = NULL. If it is not NULL, then I >do the FREE. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL question
Thanks Bob, No I initialize the Pointer to NULL, and then allocate. Successfully. And then later I check to see it the pointer = NULL. If it is not NULL, then I do the FREE. Thanks …….Cameron -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bob T Roller Sent: Saturday, April 8, 2023 8:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: COBOL question Region card big enough? I’ve seen that abend via not enough memory. Bob Sent from Proton Mail for iOS On Sat, Apr 8, 2023 at 8:17 PM, Charles Hardee wrote: > I have not seen this exactly like what you describe, but I do have > some thoughts. > The pointer you are using for the ALLOCATE, does it have a value > clause, specifically VALUE NULL. > If not, the pointer could have an unknown value that does not compare > equal to NULL so you would attempt to FREE it. > > On Sat, Apr 8, 2023 at 6:05 PM Cameron Conacher wrote: > >> Hello folks >> I have written an IMS COBOL program. I have included a couple of >> ALLOCATE statements. >> At the end of processing I check my pointers and if they are not NULL >> I try to FREE. This results in a U4038 abend. At least inside Expediter. >> I have not used ALLOCATE/FREE before. >> I am thinking it may be related to Expediter somehow. >> I mean FREE is pretty darned straight forward. >> At the moment I have commented out the statements. Memory should be >> freed at the end of processing anyway, but good housekeeping is well good. >> Has anyone seen this before? >> >> Thanks >> >> Sent from my iPhone >> - >> - For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO >> IBM-MAIN >> > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN American Express made the following annotations This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no longer wish to receive these e-mails, please notify the sender by reply e-mail. This e-mail is solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by reply e-mail and immediately and permanently delete this e-mail and any attachments. Thank you. American Express a fait les remarques suivantes Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser les expéditeurs par courriel. Ce courriel est réservé au seul destinataire indiqué et peut renfermer des renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire prévu, toute divulgation, duplication, utilisation ou distribution du courriel est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce jointe. Merci. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL question
Region card big enough? I’ve seen that abend via not enough memory. Bob Sent from Proton Mail for iOS On Sat, Apr 8, 2023 at 8:17 PM, Charles Hardee wrote: > I have not seen this exactly like what you describe, but I do have some > thoughts. > The pointer you are using for the ALLOCATE, does it have a value clause, > specifically VALUE NULL. > If not, the pointer could have an unknown value that does not compare equal > to NULL so you would attempt to FREE it. > > On Sat, Apr 8, 2023 at 6:05 PM Cameron Conacher wrote: > >> Hello folks >> I have written an IMS COBOL program. I have included a couple of ALLOCATE >> statements. >> At the end of processing I check my pointers and if they are not NULL I >> try to FREE. This results in a U4038 abend. At least inside Expediter. >> I have not used ALLOCATE/FREE before. >> I am thinking it may be related to Expediter somehow. >> I mean FREE is pretty darned straight forward. >> At the moment I have commented out the statements. Memory should be freed >> at the end of processing anyway, but good housekeeping is well good. >> Has anyone seen this before? >> >> Thanks >> >> Sent from my iPhone >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL question
I have not seen this exactly like what you describe, but I do have some thoughts. The pointer you are using for the ALLOCATE, does it have a value clause, specifically VALUE NULL. If not, the pointer could have an unknown value that does not compare equal to NULL so you would attempt to FREE it. On Sat, Apr 8, 2023 at 6:05 PM Cameron Conacher wrote: > Hello folks > I have written an IMS COBOL program. I have included a couple of ALLOCATE > statements. > At the end of processing I check my pointers and if they are not NULL I > try to FREE. This results in a U4038 abend. At least inside Expediter. > I have not used ALLOCATE/FREE before. > I am thinking it may be related to Expediter somehow. > I mean FREE is pretty darned straight forward. > At the moment I have commented out the statements. Memory should be freed > at the end of processing anyway, but good housekeeping is well good. > Has anyone seen this before? > > Thanks > > Sent from my iPhone > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
COBOL question
Hello folks I have written an IMS COBOL program. I have included a couple of ALLOCATE statements. At the end of processing I check my pointers and if they are not NULL I try to FREE. This results in a U4038 abend. At least inside Expediter. I have not used ALLOCATE/FREE before. I am thinking it may be related to Expediter somehow. I mean FREE is pretty darned straight forward. At the moment I have commented out the statements. Memory should be freed at the end of processing anyway, but good housekeeping is well good. Has anyone seen this before? Thanks Sent from my iPhone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
I liked Panvalet. Sent from my iPhone I promise you I can’t type or Spell on any smartphone > On Jun 9, 2020, at 15:53, David Spiegel wrote: > > +1 sleazy-freaking-trieve. > (I used to support it, Panvalet and Librarian) > >> On 2020-06-09 16:27, Joe Monk wrote: >> "Easytrieve plus" >> >> You mean sleazytrieve plus? :) >> >> There was also DYL280 and QUIKJOB. >> >> Joe >> >>> On Tue, Jun 9, 2020 at 12:55 PM Mike Schwab wrote: >>> >>> 4GL - I've used Telon which takes a screen layout and database layout >>> and generates the cobol code and editing rules. ADR-Datacom had Ideal >>> which was similar, later CA. Easytrieve plus I really liked, >>> especially the report generation part. >>> >>> -- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >>> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> . > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
+1 sleazy-freaking-trieve. (I used to support it, Panvalet and Librarian) On 2020-06-09 16:27, Joe Monk wrote: "Easytrieve plus" You mean sleazytrieve plus? :) There was also DYL280 and QUIKJOB. Joe On Tue, Jun 9, 2020 at 12:55 PM Mike Schwab wrote: 4GL - I've used Telon which takes a screen layout and database layout and generates the cobol code and editing rules. ADR-Datacom had Ideal which was similar, later CA. Easytrieve plus I really liked, especially the report generation part. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
Sleazytrieve is the bane of existence, as much as java is. We actually dumped all CA products, so we have IMU now. I'm not sure it's any better. You want to see some ugly COBOL? First Horizon Bank Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of John McKown Sent: Tuesday, June 9, 2020 4:43 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL Question [External Email. Exercise caution when clicking links or opening attachments.] On Tue, Jun 9, 2020 at 3:28 PM Joe Monk wrote: > "Easytrieve plus" > > You mean sleazytrieve plus? :) > We still use SleavyTrieve+ in production. Crap, we have some RACF reports, written over 28 years ago (before my time) which use EZTP to parse the output of an "LU *". I really should replace them all with something using IRRDBU00 output and ICETOOL along the path of RACFICE. But "we're going away" (perhaps finally, given UnitedHealthCare has enough money to just force it) and so "why bother?". > > There was also DYL280 and QUIKJOB. > > Joe > > On Tue, Jun 9, 2020 at 12:55 PM Mike Schwab > wrote: > > > 4GL - I've used Telon which takes a screen layout and database > > layout and generates the cobol code and editing rules. ADR-Datacom > > had Ideal which was similar, later CA. Easytrieve plus I really > > liked, especially the report generation part. > > > > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO > > IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- People in sleeping bags are the soft tacos of the bear world. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
On Tue, Jun 9, 2020 at 3:28 PM Joe Monk wrote: > "Easytrieve plus" > > You mean sleazytrieve plus? :) > We still use SleavyTrieve+ in production. Crap, we have some RACF reports, written over 28 years ago (before my time) which use EZTP to parse the output of an "LU *". I really should replace them all with something using IRRDBU00 output and ICETOOL along the path of RACFICE. But "we're going away" (perhaps finally, given UnitedHealthCare has enough money to just force it) and so "why bother?". > > There was also DYL280 and QUIKJOB. > > Joe > > On Tue, Jun 9, 2020 at 12:55 PM Mike Schwab > wrote: > > > 4GL - I've used Telon which takes a screen layout and database layout > > and generates the cobol code and editing rules. ADR-Datacom had Ideal > > which was similar, later CA. Easytrieve plus I really liked, > > especially the report generation part. > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- People in sleeping bags are the soft tacos of the bear world. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
I used quikjob for nearly 20 years as a systems pgmr. It was a very simple yet powerful product. It also had several other quikxxx modules to handle vsam easily and a report module to make very neat reports from bland data. I think the company got bought out and the products renamed at some point in the early 2000's. I think I fixed over 200 small issues conveyed by programmers at 2 or 3 in the morning just to get the batch back up and working again. Miss those days John Clifford (had to retire) On Tue, Jun 9, 2020 at 4:28 PM Joe Monk wrote: > "Easytrieve plus" > > You mean sleazytrieve plus? :) > > There was also DYL280 and QUIKJOB. > > Joe > > On Tue, Jun 9, 2020 at 12:55 PM Mike Schwab > wrote: > > > 4GL - I've used Telon which takes a screen layout and database layout > > and generates the cobol code and editing rules. ADR-Datacom had Ideal > > which was similar, later CA. Easytrieve plus I really liked, > > especially the report generation part. > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
I have not see sleazytrieve on 20 years Sent from my iPhone > On Jun 9, 2020, at 15:27, Joe Monk wrote: > > "Easytrieve plus" > > You mean sleazytrieve plus? :) > > There was also DYL280 and QUIKJOB. > > Joe > >> On Tue, Jun 9, 2020 at 12:55 PM Mike Schwab wrote: >> >> 4GL - I've used Telon which takes a screen layout and database layout >> and generates the cobol code and editing rules. ADR-Datacom had Ideal >> which was similar, later CA. Easytrieve plus I really liked, >> especially the report generation part. >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
"Easytrieve plus" You mean sleazytrieve plus? :) There was also DYL280 and QUIKJOB. Joe On Tue, Jun 9, 2020 at 12:55 PM Mike Schwab wrote: > 4GL - I've used Telon which takes a screen layout and database layout > and generates the cobol code and editing rules. ADR-Datacom had Ideal > which was similar, later CA. Easytrieve plus I really liked, > especially the report generation part. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
4GL - I've used Telon which takes a screen layout and database layout and generates the cobol code and editing rules. ADR-Datacom had Ideal which was similar, later CA. Easytrieve plus I really liked, especially the report generation part. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
The inner product of two vectors is a sum of products. The inner product of two
square matrices has a sum of products for each element:
a=0;
do i=lbound(a) to hbound(a);
do k=lbound(a,2) to hbound(a,2);
a(i,k) = sum(b(i,*)*c(*,k));
end;
end;
The trace of a square matrix is the sum of the diagonal elements:
trace = 0;
do i=lbound(a) to hbound(a);
trace = trace + a(i,i);
end;
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Frank Swarbrick [frank.swarbr...@outlook.com]
Sent: Tuesday, June 9, 2020 12:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question
I don't know what any of those terms even mean, so I'll not attempt to answer.
My interest in learning Fortran is more for it syntax than for its scientific
and mathematical capabilities.
From: IBM Mainframe Discussion List on behalf of
Seymour J Metz
Sent: Tuesday, June 9, 2020 9:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question
Partially. Does Fortran now have reduction operators, e.g., inner product,
trace?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Frank Swarbrick [frank.swarbr...@outlook.com]
Sent: Tuesday, June 9, 2020 10:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question
Do you mean like this?
integer, dimension(10) :: a, b, c
a = [1,2,3,4,5,6,7,8,9,10]
b = [2,3,4,5,6,7,8,9,10,11]
c = a + b
print *, "a = ", a
print *, "b = ", b
print *, "c = ", c
a =1 2 3 4 5 6
7 8 9 10
b =2 3 4 5 6 7
8 9 10 11
c =3 5 7 9 11 13
15 17 19 21
Apparently added as part of the Fortran 90 standard.
From: IBM Mainframe Discussion List on behalf of
Seymour J Metz
Sent: Tuesday, June 9, 2020 8:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question
Have they added array operations to Fortran?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob
Bridges [robhbrid...@gmail.com]
Sent: Tuesday, June 9, 2020 12:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question
I haven't written anything in FORTRAN since some time in the late '70s. But
even much more recently I heard it's regarded by number crunchers, engineers
say, as the best language for sheer speed. Not so great for report writing
and formatting.
---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
/* If a problem has a single neck, it has a simple solution. */
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Frank Swarbrick
Sent: Monday, June 8, 2020 21:22
I've been teaching myself (modern) Fortran the last few weeks. Just
because. It has an interesting behavior that I kind of like.
Normal IF statement:
if (something) then
end if
But it also has a "one line IF" (not sure offhand of the Fortran "name" for
this):
if (something)
must be on the same line as the if and the condition
(unless you specify the "line continuation character"), and of course only
one statement is allowed. Kind of like the C/Java if statement with out a
statement block, but less dangerous because of the "on the same line"
requirement. Here is one way I've used it in practice.
call get_command_argument(1, host)
if (inet_addr(host) .lt. 0) call error_stop("Host must be in dotted decimal
format.")
call get_command_argument(2, port_str)
read (port_str, '(i5)', iostat = iostat) port ! convert string 'port_str' to
integer 'port'
if (iostat .ne. 0 .or. port .le. 0) call error_stop("Port must be positive
numeric (0-32767).")
Using "if/then" instead of just "if" I'd have had this:
call get_command_argument(1, host)
if (inet_addr(host) .lt. 0) then
call error_stop("Host must be in dotted decimal format.")
end if
call get_command_argument(2, port_str)
read (port_str, '(i5)', iostat = iostat) port ! convert string 'port_str' to
integer 'port'
if (iostat .ne. 0 .or. port .le. 0) then
call error_stop("Port must be positive numeric (0-32767).")
end if
Given by absolute druthers I would have the then clause part of the single
line if instead of the if/end if, but its still pretty nice regardless, as
it doesn't cause as much "clutter"
Re: COBOL Question
I don't know what any of those terms even mean, so I'll not attempt to answer.
My interest in learning Fortran is more for it syntax than for its scientific
and mathematical capabilities.
From: IBM Mainframe Discussion List on behalf of
Seymour J Metz
Sent: Tuesday, June 9, 2020 9:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question
Partially. Does Fortran now have reduction operators, e.g., inner product,
trace?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Frank Swarbrick [frank.swarbr...@outlook.com]
Sent: Tuesday, June 9, 2020 10:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question
Do you mean like this?
integer, dimension(10) :: a, b, c
a = [1,2,3,4,5,6,7,8,9,10]
b = [2,3,4,5,6,7,8,9,10,11]
c = a + b
print *, "a = ", a
print *, "b = ", b
print *, "c = ", c
a =1 2 3 4 5 6
7 8 9 10
b =2 3 4 5 6 7
8 9 10 11
c =3 5 7 9 11 13
15 17 19 21
Apparently added as part of the Fortran 90 standard.
From: IBM Mainframe Discussion List on behalf of
Seymour J Metz
Sent: Tuesday, June 9, 2020 8:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question
Have they added array operations to Fortran?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob
Bridges [robhbrid...@gmail.com]
Sent: Tuesday, June 9, 2020 12:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question
I haven't written anything in FORTRAN since some time in the late '70s. But
even much more recently I heard it's regarded by number crunchers, engineers
say, as the best language for sheer speed. Not so great for report writing
and formatting.
---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
/* If a problem has a single neck, it has a simple solution. */
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Frank Swarbrick
Sent: Monday, June 8, 2020 21:22
I've been teaching myself (modern) Fortran the last few weeks. Just
because. It has an interesting behavior that I kind of like.
Normal IF statement:
if (something) then
end if
But it also has a "one line IF" (not sure offhand of the Fortran "name" for
this):
if (something)
must be on the same line as the if and the condition
(unless you specify the "line continuation character"), and of course only
one statement is allowed. Kind of like the C/Java if statement with out a
statement block, but less dangerous because of the "on the same line"
requirement. Here is one way I've used it in practice.
call get_command_argument(1, host)
if (inet_addr(host) .lt. 0) call error_stop("Host must be in dotted decimal
format.")
call get_command_argument(2, port_str)
read (port_str, '(i5)', iostat = iostat) port ! convert string 'port_str' to
integer 'port'
if (iostat .ne. 0 .or. port .le. 0) call error_stop("Port must be positive
numeric (0-32767).")
Using "if/then" instead of just "if" I'd have had this:
call get_command_argument(1, host)
if (inet_addr(host) .lt. 0) then
call error_stop("Host must be in dotted decimal format.")
end if
call get_command_argument(2, port_str)
read (port_str, '(i5)', iostat = iostat) port ! convert string 'port_str' to
integer 'port'
if (iostat .ne. 0 .or. port .le. 0) then
call error_stop("Port must be positive numeric (0-32767).")
end if
Given by absolute druthers I would have the then clause part of the single
line if instead of the if/end if, but its still pretty nice regardless, as
it doesn't cause as much "clutter" as error handling often does.
On a side note, I think Fortran has done a much better job than COBOL of
adding "modern" features (starting with Fortran 90 in 1990). If only the
COBOL "designers" had followed in their footsteps.
And in my mind Fortran had even more to "make up" for in regards to it's
less than ideal beginnings. Which Fortran can even be forgiven for then,
being I believe about five years older than COBOL (Cobol?).
From: IBM Mainframe Discussion List on behalf of
Bob Bridges
Sent: Sunday, June 7, 2020 12:35 PM
The only language I can think of off-hand that doesn't require some sort of
END to close a DO (I'm sure there are others) is ISPF. But, in REXX at
least, I never use singl
Re: COBOL Question
Partially. Does Fortran now have reduction operators, e.g., inner product,
trace?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Frank Swarbrick [frank.swarbr...@outlook.com]
Sent: Tuesday, June 9, 2020 10:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question
Do you mean like this?
integer, dimension(10) :: a, b, c
a = [1,2,3,4,5,6,7,8,9,10]
b = [2,3,4,5,6,7,8,9,10,11]
c = a + b
print *, "a = ", a
print *, "b = ", b
print *, "c = ", c
a =1 2 3 4 5 6
7 8 9 10
b =2 3 4 5 6 7
8 9 10 11
c =3 5 7 9 11 13
15 17 19 21
Apparently added as part of the Fortran 90 standard.
From: IBM Mainframe Discussion List on behalf of
Seymour J Metz
Sent: Tuesday, June 9, 2020 8:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question
Have they added array operations to Fortran?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob
Bridges [robhbrid...@gmail.com]
Sent: Tuesday, June 9, 2020 12:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question
I haven't written anything in FORTRAN since some time in the late '70s. But
even much more recently I heard it's regarded by number crunchers, engineers
say, as the best language for sheer speed. Not so great for report writing
and formatting.
---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
/* If a problem has a single neck, it has a simple solution. */
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Frank Swarbrick
Sent: Monday, June 8, 2020 21:22
I've been teaching myself (modern) Fortran the last few weeks. Just
because. It has an interesting behavior that I kind of like.
Normal IF statement:
if (something) then
end if
But it also has a "one line IF" (not sure offhand of the Fortran "name" for
this):
if (something)
must be on the same line as the if and the condition
(unless you specify the "line continuation character"), and of course only
one statement is allowed. Kind of like the C/Java if statement with out a
statement block, but less dangerous because of the "on the same line"
requirement. Here is one way I've used it in practice.
call get_command_argument(1, host)
if (inet_addr(host) .lt. 0) call error_stop("Host must be in dotted decimal
format.")
call get_command_argument(2, port_str)
read (port_str, '(i5)', iostat = iostat) port ! convert string 'port_str' to
integer 'port'
if (iostat .ne. 0 .or. port .le. 0) call error_stop("Port must be positive
numeric (0-32767).")
Using "if/then" instead of just "if" I'd have had this:
call get_command_argument(1, host)
if (inet_addr(host) .lt. 0) then
call error_stop("Host must be in dotted decimal format.")
end if
call get_command_argument(2, port_str)
read (port_str, '(i5)', iostat = iostat) port ! convert string 'port_str' to
integer 'port'
if (iostat .ne. 0 .or. port .le. 0) then
call error_stop("Port must be positive numeric (0-32767).")
end if
Given by absolute druthers I would have the then clause part of the single
line if instead of the if/end if, but its still pretty nice regardless, as
it doesn't cause as much "clutter" as error handling often does.
On a side note, I think Fortran has done a much better job than COBOL of
adding "modern" features (starting with Fortran 90 in 1990). If only the
COBOL "designers" had followed in their footsteps.
And in my mind Fortran had even more to "make up" for in regards to it's
less than ideal beginnings. Which Fortran can even be forgiven for then,
being I believe about five years older than COBOL (Cobol?).
From: IBM Mainframe Discussion List on behalf of
Bob Bridges
Sent: Sunday, June 7, 2020 12:35 PM
The only language I can think of off-hand that doesn't require some sort of
END to close a DO (I'm sure there are others) is ISPF. But, in REXX at
least, I never use single-statement DOs. I see them all the time, and I
don't get it. Like this:
if x=0 then do
x=x+1
end
Or, more painfully:
select
when idx="T" then
do
countt=countt+1
end
when idx="U" then
do
countu=countu+1
end
when idx="V" then
do
countv=countv+1
end
when i
Re: COBOL Question
I couldn't tell you. But it's what I have been running on Windows recently. I
imagine it might (probably?) run on Linux for Z.
From: IBM Mainframe Discussion List on behalf of
Seymour J Metz
Sent: Tuesday, June 9, 2020 8:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question
What about gcc Fortran? Does that run on OMVS? Linux on Z?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Frank Swarbrick [frank.swarbr...@outlook.com]
Sent: Tuesday, June 9, 2020 10:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question
Here's the question I have about Fortran support. Why does IBM support modern
Fortran on platforms like Linux and AIX, but mainframe Fortran (IBM VS FORTRAN)
is still at FORTRAN 77 level and seems to have had no enhancements other than
Language Environment support since...1993? I know if I were a Fortran
developer this would piss me off greatly.
From: IBM Mainframe Discussion List on behalf of
Evans-Young, Darren
Sent: Monday, June 8, 2020 8:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question
FORTRAN 90 was a significant upgrade over previous standards. Mainly, free-form
input source statements.
Also, increase the length of identifiers from 6 characters to 31 characters,
and upper/lowecase keywords/identifiers.
The latest standard is Fortran 2018.
I still teach Fortran to my Honor students. It's easy to learn for a first
programming language, very forgiving, and
you can do a lot with it. I still get flack from uninformed individuals, you
know, the ones that say no one uses mainframes
anymore, no one uses Fortran anymore, no on uses COBOL anymore. Every year, a
couple of my students email me back
to say how having Fortran experience on their resume helped them land a job or
internship; companies like NASA, NOAA,
Lockheed-Martin, etc. They are usually the only applicants out of hundreds that
list Fortran experience.
Darren
From: IBM Mainframe Discussion List on behalf of
lenru...@gmail.com
Sent: Monday, June 8, 2020 8:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question
On, long ago and on some DOS/VS Cobol compiler, after a compiler upgrade, there
was a problem with a statement something like this:
READ some-fileAT END do somethingMOVE A TO B.
See the problem? The period after the AT END was omitted. The old compiler
only allowed one statement after AT END (maybe a bug) but after it honored the
period.
It was a bear to find. It worked before and for a long time after the compiler
change, until it was complied again.
On Monday, June 8, 2020, 08:22:18 PM CDT, Frank Swarbrick
wrote:
I've been teaching myself (modern) Fortran the last few weeks. Just because.
It has an interesting behavior that I kind of like.
Normal IF statement:
if (something) then
end if
But it also has a "one line IF" (not sure offhand of the Fortran "name" for
this):
if (something)
must be on the same line as the if and the condition (unless
you specify the "line continuation character"), and of course only one
statement is allowed. Kind of like the C/Java if statement with out a
statement block, but less dangerous because of the "on the same line"
requirement. Here is one way I've used it in practice.
call get_command_argument(1, host)
if (inet_addr(host) .lt. 0) call error_stop("Host must be in dotted decimal
format.")
call get_command_argument(2, port_str)
read (port_str, '(i5)', iostat = iostat) port ! convert string 'port_str' to
integer 'port'
if (iostat .ne. 0 .or. port .le. 0) call error_stop("Port must be positive
numeric (0-32767).")
Using "if/then" instead of just "if" I'd have had this:
call get_command_argument(1, host)
if (inet_addr(host) .lt. 0) then
call error_stop("Host must be in dotted decimal format.")
end if
call get_command_argument(2, port_str)
read (port_str, '(i5)', iostat = iostat) port ! convert string 'port_str' to
integer 'port'
if (iostat .ne. 0 .or. port .le. 0) then
call error_stop("Port must be positive numeric (0-32767).")
end if
Given by absolute druthers I would have the then clause part of the single line
if instead of the if/end if, but its still pretty nice regardless, as it
doesn't cause as much "clutter" as error handling often does.
On a side note, I think Fortran has done a much better job than COBOL of adding
"modern" features (starting with Fortran 90 in 1990). If only the COBOL
"designers" had followed in their footsteps.
And in my mind Fortran had even more to "make up" for in regards to it's less
than ideal beginnings. Which Fortran can even be forgiven for then, being I
believe a
Re: COBOL Question
Do you mean like this?
integer, dimension(10) :: a, b, c
a = [1,2,3,4,5,6,7,8,9,10]
b = [2,3,4,5,6,7,8,9,10,11]
c = a + b
print *, "a = ", a
print *, "b = ", b
print *, "c = ", c
a =1 2 3 4 5 6
7 8 9 10
b =2 3 4 5 6 7
8 9 10 11
c =3 5 7 9 11 13
15 17 19 21
Apparently added as part of the Fortran 90 standard.
From: IBM Mainframe Discussion List on behalf of
Seymour J Metz
Sent: Tuesday, June 9, 2020 8:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question
Have they added array operations to Fortran?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob
Bridges [robhbrid...@gmail.com]
Sent: Tuesday, June 9, 2020 12:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question
I haven't written anything in FORTRAN since some time in the late '70s. But
even much more recently I heard it's regarded by number crunchers, engineers
say, as the best language for sheer speed. Not so great for report writing
and formatting.
---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
/* If a problem has a single neck, it has a simple solution. */
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Frank Swarbrick
Sent: Monday, June 8, 2020 21:22
I've been teaching myself (modern) Fortran the last few weeks. Just
because. It has an interesting behavior that I kind of like.
Normal IF statement:
if (something) then
end if
But it also has a "one line IF" (not sure offhand of the Fortran "name" for
this):
if (something)
must be on the same line as the if and the condition
(unless you specify the "line continuation character"), and of course only
one statement is allowed. Kind of like the C/Java if statement with out a
statement block, but less dangerous because of the "on the same line"
requirement. Here is one way I've used it in practice.
call get_command_argument(1, host)
if (inet_addr(host) .lt. 0) call error_stop("Host must be in dotted decimal
format.")
call get_command_argument(2, port_str)
read (port_str, '(i5)', iostat = iostat) port ! convert string 'port_str' to
integer 'port'
if (iostat .ne. 0 .or. port .le. 0) call error_stop("Port must be positive
numeric (0-32767).")
Using "if/then" instead of just "if" I'd have had this:
call get_command_argument(1, host)
if (inet_addr(host) .lt. 0) then
call error_stop("Host must be in dotted decimal format.")
end if
call get_command_argument(2, port_str)
read (port_str, '(i5)', iostat = iostat) port ! convert string 'port_str' to
integer 'port'
if (iostat .ne. 0 .or. port .le. 0) then
call error_stop("Port must be positive numeric (0-32767).")
end if
Given by absolute druthers I would have the then clause part of the single
line if instead of the if/end if, but its still pretty nice regardless, as
it doesn't cause as much "clutter" as error handling often does.
On a side note, I think Fortran has done a much better job than COBOL of
adding "modern" features (starting with Fortran 90 in 1990). If only the
COBOL "designers" had followed in their footsteps.
And in my mind Fortran had even more to "make up" for in regards to it's
less than ideal beginnings. Which Fortran can even be forgiven for then,
being I believe about five years older than COBOL (Cobol?).
From: IBM Mainframe Discussion List on behalf of
Bob Bridges
Sent: Sunday, June 7, 2020 12:35 PM
The only language I can think of off-hand that doesn't require some sort of
END to close a DO (I'm sure there are others) is ISPF. But, in REXX at
least, I never use single-statement DOs. I see them all the time, and I
don't get it. Like this:
if x=0 then do
x=x+1
end
Or, more painfully:
select
when idx="T" then
do
countt=countt+1
end
when idx="U" then
do
countu=countu+1
end
when idx="V" then
do
countv=countv+1
end
when idx="W" then
do
countw=countw+1
end
otherwise
do
countx=countx+1
end
end
Why? If it were easier to read, I might sympathize. But it's harder, not
easier.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-M
Re: COBOL Question
What about gcc Fortran? Does that run on OMVS? Linux on Z?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Frank Swarbrick [frank.swarbr...@outlook.com]
Sent: Tuesday, June 9, 2020 10:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question
Here's the question I have about Fortran support. Why does IBM support modern
Fortran on platforms like Linux and AIX, but mainframe Fortran (IBM VS FORTRAN)
is still at FORTRAN 77 level and seems to have had no enhancements other than
Language Environment support since...1993? I know if I were a Fortran
developer this would piss me off greatly.
From: IBM Mainframe Discussion List on behalf of
Evans-Young, Darren
Sent: Monday, June 8, 2020 8:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question
FORTRAN 90 was a significant upgrade over previous standards. Mainly, free-form
input source statements.
Also, increase the length of identifiers from 6 characters to 31 characters,
and upper/lowecase keywords/identifiers.
The latest standard is Fortran 2018.
I still teach Fortran to my Honor students. It's easy to learn for a first
programming language, very forgiving, and
you can do a lot with it. I still get flack from uninformed individuals, you
know, the ones that say no one uses mainframes
anymore, no one uses Fortran anymore, no on uses COBOL anymore. Every year, a
couple of my students email me back
to say how having Fortran experience on their resume helped them land a job or
internship; companies like NASA, NOAA,
Lockheed-Martin, etc. They are usually the only applicants out of hundreds that
list Fortran experience.
Darren
From: IBM Mainframe Discussion List on behalf of
lenru...@gmail.com
Sent: Monday, June 8, 2020 8:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question
On, long ago and on some DOS/VS Cobol compiler, after a compiler upgrade, there
was a problem with a statement something like this:
READ some-fileAT END do somethingMOVE A TO B.
See the problem? The period after the AT END was omitted. The old compiler
only allowed one statement after AT END (maybe a bug) but after it honored the
period.
It was a bear to find. It worked before and for a long time after the compiler
change, until it was complied again.
On Monday, June 8, 2020, 08:22:18 PM CDT, Frank Swarbrick
wrote:
I've been teaching myself (modern) Fortran the last few weeks. Just because.
It has an interesting behavior that I kind of like.
Normal IF statement:
if (something) then
end if
But it also has a "one line IF" (not sure offhand of the Fortran "name" for
this):
if (something)
must be on the same line as the if and the condition (unless
you specify the "line continuation character"), and of course only one
statement is allowed. Kind of like the C/Java if statement with out a
statement block, but less dangerous because of the "on the same line"
requirement. Here is one way I've used it in practice.
call get_command_argument(1, host)
if (inet_addr(host) .lt. 0) call error_stop("Host must be in dotted decimal
format.")
call get_command_argument(2, port_str)
read (port_str, '(i5)', iostat = iostat) port ! convert string 'port_str' to
integer 'port'
if (iostat .ne. 0 .or. port .le. 0) call error_stop("Port must be positive
numeric (0-32767).")
Using "if/then" instead of just "if" I'd have had this:
call get_command_argument(1, host)
if (inet_addr(host) .lt. 0) then
call error_stop("Host must be in dotted decimal format.")
end if
call get_command_argument(2, port_str)
read (port_str, '(i5)', iostat = iostat) port ! convert string 'port_str' to
integer 'port'
if (iostat .ne. 0 .or. port .le. 0) then
call error_stop("Port must be positive numeric (0-32767).")
end if
Given by absolute druthers I would have the then clause part of the single line
if instead of the if/end if, but its still pretty nice regardless, as it
doesn't cause as much "clutter" as error handling often does.
On a side note, I think Fortran has done a much better job than COBOL of adding
"modern" features (starting with Fortran 90 in 1990). If only the COBOL
"designers" had followed in their footsteps.
And in my mind Fortran had even more to "make up" for in regards to it's less
than ideal beginnings. Which Fortran can even be forgiven for then, being I
believe about five years older than COBOL (Cobol?).
From: IBM Mainframe Discussion List on behalf of Bob
Bridges
Sent: Sunday, June 7, 2020 12:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question
The only language I can think of off-hand that doesn't require some sort of END
to close a
Re: COBOL Question
Here's the question I have about Fortran support. Why does IBM support modern
Fortran on platforms like Linux and AIX, but mainframe Fortran (IBM VS FORTRAN)
is still at FORTRAN 77 level and seems to have had no enhancements other than
Language Environment support since...1993? I know if I were a Fortran
developer this would piss me off greatly.
From: IBM Mainframe Discussion List on behalf of
Evans-Young, Darren
Sent: Monday, June 8, 2020 8:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question
FORTRAN 90 was a significant upgrade over previous standards. Mainly, free-form
input source statements.
Also, increase the length of identifiers from 6 characters to 31 characters,
and upper/lowecase keywords/identifiers.
The latest standard is Fortran 2018.
I still teach Fortran to my Honor students. It's easy to learn for a first
programming language, very forgiving, and
you can do a lot with it. I still get flack from uninformed individuals, you
know, the ones that say no one uses mainframes
anymore, no one uses Fortran anymore, no on uses COBOL anymore. Every year, a
couple of my students email me back
to say how having Fortran experience on their resume helped them land a job or
internship; companies like NASA, NOAA,
Lockheed-Martin, etc. They are usually the only applicants out of hundreds that
list Fortran experience.
Darren
From: IBM Mainframe Discussion List on behalf of
lenru...@gmail.com
Sent: Monday, June 8, 2020 8:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question
On, long ago and on some DOS/VS Cobol compiler, after a compiler upgrade, there
was a problem with a statement something like this:
READ some-fileAT END do somethingMOVE A TO B.
See the problem? The period after the AT END was omitted. The old compiler
only allowed one statement after AT END (maybe a bug) but after it honored the
period.
It was a bear to find. It worked before and for a long time after the compiler
change, until it was complied again.
On Monday, June 8, 2020, 08:22:18 PM CDT, Frank Swarbrick
wrote:
I've been teaching myself (modern) Fortran the last few weeks. Just because.
It has an interesting behavior that I kind of like.
Normal IF statement:
if (something) then
end if
But it also has a "one line IF" (not sure offhand of the Fortran "name" for
this):
if (something)
must be on the same line as the if and the condition (unless
you specify the "line continuation character"), and of course only one
statement is allowed. Kind of like the C/Java if statement with out a
statement block, but less dangerous because of the "on the same line"
requirement. Here is one way I've used it in practice.
call get_command_argument(1, host)
if (inet_addr(host) .lt. 0) call error_stop("Host must be in dotted decimal
format.")
call get_command_argument(2, port_str)
read (port_str, '(i5)', iostat = iostat) port ! convert string 'port_str' to
integer 'port'
if (iostat .ne. 0 .or. port .le. 0) call error_stop("Port must be positive
numeric (0-32767).")
Using "if/then" instead of just "if" I'd have had this:
call get_command_argument(1, host)
if (inet_addr(host) .lt. 0) then
call error_stop("Host must be in dotted decimal format.")
end if
call get_command_argument(2, port_str)
read (port_str, '(i5)', iostat = iostat) port ! convert string 'port_str' to
integer 'port'
if (iostat .ne. 0 .or. port .le. 0) then
call error_stop("Port must be positive numeric (0-32767).")
end if
Given by absolute druthers I would have the then clause part of the single line
if instead of the if/end if, but its still pretty nice regardless, as it
doesn't cause as much "clutter" as error handling often does.
On a side note, I think Fortran has done a much better job than COBOL of adding
"modern" features (starting with Fortran 90 in 1990). If only the COBOL
"designers" had followed in their footsteps.
And in my mind Fortran had even more to "make up" for in regards to it's less
than ideal beginnings. Which Fortran can even be forgiven for then, being I
believe about five years older than COBOL (Cobol?).
From: IBM Mainframe Discussion List on behalf of Bob
Bridges
Sent: Sunday, June 7, 2020 12:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question
The only language I can think of off-hand that doesn't require some sort of END
to close a DO (I'm sure there are others) is ISPF. But, in REXX at least, I
never use single-statement DOs. I see them all the time, and I don't get it.
Like this:
if x=0 then do
x=x+1
end
Or, more painfully:
select
when idx="T" then
do
countt=countt+1
end
when idx="U" then
do
countu=countu+1
Re: COBOL Question
Have they added array operations to Fortran?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob
Bridges [robhbrid...@gmail.com]
Sent: Tuesday, June 9, 2020 12:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question
I haven't written anything in FORTRAN since some time in the late '70s. But
even much more recently I heard it's regarded by number crunchers, engineers
say, as the best language for sheer speed. Not so great for report writing
and formatting.
---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
/* If a problem has a single neck, it has a simple solution. */
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Frank Swarbrick
Sent: Monday, June 8, 2020 21:22
I've been teaching myself (modern) Fortran the last few weeks. Just
because. It has an interesting behavior that I kind of like.
Normal IF statement:
if (something) then
end if
But it also has a "one line IF" (not sure offhand of the Fortran "name" for
this):
if (something)
must be on the same line as the if and the condition
(unless you specify the "line continuation character"), and of course only
one statement is allowed. Kind of like the C/Java if statement with out a
statement block, but less dangerous because of the "on the same line"
requirement. Here is one way I've used it in practice.
call get_command_argument(1, host)
if (inet_addr(host) .lt. 0) call error_stop("Host must be in dotted decimal
format.")
call get_command_argument(2, port_str)
read (port_str, '(i5)', iostat = iostat) port ! convert string 'port_str' to
integer 'port'
if (iostat .ne. 0 .or. port .le. 0) call error_stop("Port must be positive
numeric (0-32767).")
Using "if/then" instead of just "if" I'd have had this:
call get_command_argument(1, host)
if (inet_addr(host) .lt. 0) then
call error_stop("Host must be in dotted decimal format.")
end if
call get_command_argument(2, port_str)
read (port_str, '(i5)', iostat = iostat) port ! convert string 'port_str' to
integer 'port'
if (iostat .ne. 0 .or. port .le. 0) then
call error_stop("Port must be positive numeric (0-32767).")
end if
Given by absolute druthers I would have the then clause part of the single
line if instead of the if/end if, but its still pretty nice regardless, as
it doesn't cause as much "clutter" as error handling often does.
On a side note, I think Fortran has done a much better job than COBOL of
adding "modern" features (starting with Fortran 90 in 1990). If only the
COBOL "designers" had followed in their footsteps.
And in my mind Fortran had even more to "make up" for in regards to it's
less than ideal beginnings. Which Fortran can even be forgiven for then,
being I believe about five years older than COBOL (Cobol?).
From: IBM Mainframe Discussion List on behalf of
Bob Bridges
Sent: Sunday, June 7, 2020 12:35 PM
The only language I can think of off-hand that doesn't require some sort of
END to close a DO (I'm sure there are others) is ISPF. But, in REXX at
least, I never use single-statement DOs. I see them all the time, and I
don't get it. Like this:
if x=0 then do
x=x+1
end
Or, more painfully:
select
when idx="T" then
do
countt=countt+1
end
when idx="U" then
do
countu=countu+1
end
when idx="V" then
do
countv=countv+1
end
when idx="W" then
do
countw=countw+1
end
otherwise
do
countx=countx+1
end
end
Why? If it were easier to read, I might sympathize. But it's harder, not
easier.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
A noted translator once claimed that every translation is a lie; I am tempted to claim that every computer-related taxonomy is a lie. Octal was the norm long before EUnix; hexadecimal, while occasionally used, was an aberration until S/360. By 1960 macro-assemblers were the norm. How do you classify Prolog? RPG.? Do you really want, e.g., Ada, ALGOL 68, APL, Erlang, FLOW-MATIC, FORMAC, Forth, FORTRAN, Go, Haskell, Icon, LISP, PL/I, Prolog, RPG, Simula, SNOBOL, in the same generation? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob Bridges [robhbrid...@gmail.com] Sent: Tuesday, June 9, 2020 12:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL Question LOL! I'm reminded that DYL-280II was advertised as a 4GL, with English-like syntax. Neither is true, to my mind. I like DYL-280II, and taught classes in it at my employer of the time (Volvo Truck NA) as well as workshops at the DYLAKOR conferences. But it's not a 4GL. Well, not in the sense I usually associate with the term. Actually, let me ask the group what you think about that: 1GL: Machine code; programming in binary and hex. (Also octal, if you think in Unix, I suppose, which I don't.) 2GL: Assemblers of various flavors; each statement in assembler corresponds to a single machine instruction, but using mnemonics that make it easier to remember how to say what you intend. 3GL: Algorithmic languages. Most of us use these: COBOL, FORTRAN, BASIC, VB, Pascal, you get the idea. The feature of algorithmic languages is that they have a certain severe syntax, each token meaning a very particular thing, but arranged in a way that allows a human to clump several machine instructions together into conceptual groups. Calls to a subroutine can be expressed in one line rather than five; assignment statements the same. 4GL: This was supposed to be the point at which we could just talk to a computer and let it would figure out what we mean. I gather there've been some attempts at this that generate surprisingly good results - with surprising gaps in the system's ability to comprehend how we think. Yeah, yeah, I realize what that really means is that ~we~ often fail to notice how we think. But we don't really have a 4GL by this definition...do we? Still a dream, I gather. Not that I'm complaining. It may be a dream that can never be realized, simply because human thoughts are imprecise and cannot be acted upon precisely until the human has organized them better. Using a 3GL is one way to force that organization. Just a thought. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* I never noticed them actually using English words in the finals of the spelling bee. They seem to have reached a point where the spellers can spell all the English words and have moved on to words from around the world that may once have been used in an English sentence. -Dogsbody at Norton's Patrick O'Brian forum */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, June 8, 2020 22:19 It's so nice of COBOL to be written in common language so any English speaker can intuitively grasp it correctly. --- On Mon, 8 Jun 2020 20:50:12 -0500, Joe Monk wrote: >In this case, because we are PERFORMing THRU, then GO TO exit, merely >causes an iterate. > >--- On Mon, Jun 8, 2020 at 7:36 PM Frank Swarbrick wrote: >> GO TO to an "exit" procedure (that is, a procedure that terminates >> unconditionally terminates the program) is, in my mind, acceptable as >> well. In fact, if you try to "perform" a "terminal" exit procedure the >> compiler will give you a warning that your "calling" procedure will never >> reach its exit. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Goto Statements AND COBOL OPTIMIZATION (was: COBOL Question)
[Default] On 8 Jun 2020 01:55:52 -0700, in bit.listserv.ibm-main dcrayf...@gmail.com (David Crayford) wrote: >I learned JSP back in the early 90's. It was popular in the UK (Jackson >was British) and most large mainframe companies adopted it. It was good. >There was even tooling that >could create code from charts. > >Dijkstra's paper is one of the most controversial CS papers ever >written. It was written before structured programming took off and >programming languages >like FORTRAN and COBOL were not well structured at the time. >Unfortunately, people drank the kool-aid and a whole generation of >programmers were brain-washed by dogma >that goto is inherently evil. I see code all the time that eschews goto >for error handling and the alternative is never better. In fact, it's >always crap! It's either deeply nested if-logic or extra status >flag checks. For languages that support try/finally, use groups, RAII >etc the problem doesn't exist but that's certainly not the case from >almost all mainstream languages that run on z/OS >other than Java and C++. > My avoidance of GO TO in COBOL is based on my understanding of IBM COBOL compiler optimization and not a computer theology that says all GO TO is bad. In the case of error clean up and blow up paragraphs, from a clarity point of view I would prefer to GO TO them but I believe this could adversely affect optimization. While I can't speak for other languages, VS COBOL 2.4 and later optimizations Enterprise COBOL 5.2 do PERFORM optimization where Paragraphs that can only be PERFORMed will cause a simplified generation of code for the related PERFORMs. In some cases the Paragraph is moved inline to replace the PERFORM statement which can bee a performance advantage for caching. I don't believe that PERFORM ... THRU statements are eligible for this optimization. I have avoided GO TO statements and even used PERFORM to execute the error abort Paragraphs accepting the warning message to make certain the optimization could take place. This is because in COBOL the same paragraph could be reached by PERFORM x, PERFORM x THRU exit-x1, PERFORM x THRU exit-x2 and GO TO x. The addition of EXIT PARAGRAPH and EXIT SECTION have eliminated most of the reasons for use of GO TO in COBOL. I would be interested in any corrections to my understanding by those responsible for the COBOL compiler. Clark Morris > >On 2020-06-08 4:28 PM, Wayne Bickerdike wrote: >> Dijkstra wrote his missive around 1968. Knuth made a meal of it and after >> reading his paper which was published 5 years later, it was too hard a read. >> >> Around the same time Michael Jackson was distilling this information and >> produced his structured programming book "Principles of Program Design". I >> still have a copy and generally will approach program design using the same >> tried and tested techniques. At IBM in 1978 we had an advocate for the same >> methods, Tony Droar. Unfortunately, a lot of this good work seemed to miss >> a lot of organisations. Some places I worked in the 80's wouldn't allow a >> sort to make a program easier to write. >> >> Jackson explained go to was essential, particularly when performing >> validationposit.admitquit. I've seen a Jackson structure design >> turned into a flowchart and the structure is lost. Flowcharts encouraged >> the use of GO TO. >> >> On Mon, Jun 8, 2020 at 4:45 PM David Crayford wrote: >> >>> On 2020-06-07 10:48 PM, Paul Gilmartin wrote: > I consider the out of line PERFORM to be far more dangerous. I have a >>> similar issue with REXX; it does not have lexical scope, and you can fall >>> into a procedure. A noteworthy 1976 paper (behind a paywall): Software malpractice a distasteful experience https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.4380060303 ... describes the pitfall set by a (too) clever programmer's relying on optimization by falling into procedures. In the day, I read it free in the University library. >>> I'm sure that paper is an interesting read from a historical >>> perspective. It's referenced in Code Complete along with another >>> reference to Frank Rubin's letter to the ACM (March 1987) >>> in which he asserts that goto-less programming has cost business >>> "hundreds of millions of dollars". >>> >>> The original context of the "goto considered harmful" is lost on the >>> younger generation, as at the time there were large swaths of developers >>> who were trained before structured programming took off. >>> There are a handful of use cases where "goto" makes the code simpler, >>> cleaner and more readable. In these cases, you /should/ use goto >>> statements. A good programmer can recognize these cases and use goto >>> appropriately. >>> >>> >>> >>> >>> >>> -- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@listserv.ua.edu
Re: COBOL Question
HOLY CRAP!!! First post from Darren that I've seen in years Maybe I missed a few. Hi Darren! _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Evans-Young, Darren Sent: Monday, June 8, 2020 10:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL Question **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** FORTRAN 90 was a significant upgrade over previous standards. Mainly, free-form input source statements. Also, increase the length of identifiers from 6 characters to 31 characters, and upper/lowecase keywords/identifiers. The latest standard is Fortran 2018. I still teach Fortran to my Honor students. It's easy to learn for a first programming language, very forgiving, and you can do a lot with it. I still get flack from uninformed individuals, you know, the ones that say no one uses mainframes anymore, no one uses Fortran anymore, no on uses COBOL anymore. Every year, a couple of my students email me back to say how having Fortran experience on their resume helped them land a job or internship; companies like NASA, NOAA, Lockheed-Martin, etc. They are usually the only applicants out of hundreds that list Fortran experience. Darren This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
LOL! I'm reminded that DYL-280II was advertised as a 4GL, with English-like syntax. Neither is true, to my mind. I like DYL-280II, and taught classes in it at my employer of the time (Volvo Truck NA) as well as workshops at the DYLAKOR conferences. But it's not a 4GL. Well, not in the sense I usually associate with the term. Actually, let me ask the group what you think about that: 1GL: Machine code; programming in binary and hex. (Also octal, if you think in Unix, I suppose, which I don't.) 2GL: Assemblers of various flavors; each statement in assembler corresponds to a single machine instruction, but using mnemonics that make it easier to remember how to say what you intend. 3GL: Algorithmic languages. Most of us use these: COBOL, FORTRAN, BASIC, VB, Pascal, you get the idea. The feature of algorithmic languages is that they have a certain severe syntax, each token meaning a very particular thing, but arranged in a way that allows a human to clump several machine instructions together into conceptual groups. Calls to a subroutine can be expressed in one line rather than five; assignment statements the same. 4GL: This was supposed to be the point at which we could just talk to a computer and let it would figure out what we mean. I gather there've been some attempts at this that generate surprisingly good results - with surprising gaps in the system's ability to comprehend how we think. Yeah, yeah, I realize what that really means is that ~we~ often fail to notice how we think. But we don't really have a 4GL by this definition...do we? Still a dream, I gather. Not that I'm complaining. It may be a dream that can never be realized, simply because human thoughts are imprecise and cannot be acted upon precisely until the human has organized them better. Using a 3GL is one way to force that organization. Just a thought. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* I never noticed them actually using English words in the finals of the spelling bee. They seem to have reached a point where the spellers can spell all the English words and have moved on to words from around the world that may once have been used in an English sentence. -Dogsbody at Norton's Patrick O'Brian forum */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, June 8, 2020 22:19 It's so nice of COBOL to be written in common language so any English speaker can intuitively grasp it correctly. --- On Mon, 8 Jun 2020 20:50:12 -0500, Joe Monk wrote: >In this case, because we are PERFORMing THRU, then GO TO exit, merely >causes an iterate. > >--- On Mon, Jun 8, 2020 at 7:36 PM Frank Swarbrick wrote: >> GO TO to an "exit" procedure (that is, a procedure that terminates >> unconditionally terminates the program) is, in my mind, acceptable as >> well. In fact, if you try to "perform" a "terminal" exit procedure the >> compiler will give you a warning that your "calling" procedure will never >> reach its exit. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
I haven't written anything in FORTRAN since some time in the late '70s. But
even much more recently I heard it's regarded by number crunchers, engineers
say, as the best language for sheer speed. Not so great for report writing
and formatting.
---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
/* If a problem has a single neck, it has a simple solution. */
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Frank Swarbrick
Sent: Monday, June 8, 2020 21:22
I've been teaching myself (modern) Fortran the last few weeks. Just
because. It has an interesting behavior that I kind of like.
Normal IF statement:
if (something) then
end if
But it also has a "one line IF" (not sure offhand of the Fortran "name" for
this):
if (something)
must be on the same line as the if and the condition
(unless you specify the "line continuation character"), and of course only
one statement is allowed. Kind of like the C/Java if statement with out a
statement block, but less dangerous because of the "on the same line"
requirement. Here is one way I've used it in practice.
call get_command_argument(1, host)
if (inet_addr(host) .lt. 0) call error_stop("Host must be in dotted decimal
format.")
call get_command_argument(2, port_str)
read (port_str, '(i5)', iostat = iostat) port ! convert string 'port_str' to
integer 'port'
if (iostat .ne. 0 .or. port .le. 0) call error_stop("Port must be positive
numeric (0-32767).")
Using "if/then" instead of just "if" I'd have had this:
call get_command_argument(1, host)
if (inet_addr(host) .lt. 0) then
call error_stop("Host must be in dotted decimal format.")
end if
call get_command_argument(2, port_str)
read (port_str, '(i5)', iostat = iostat) port ! convert string 'port_str' to
integer 'port'
if (iostat .ne. 0 .or. port .le. 0) then
call error_stop("Port must be positive numeric (0-32767).")
end if
Given by absolute druthers I would have the then clause part of the single
line if instead of the if/end if, but its still pretty nice regardless, as
it doesn't cause as much "clutter" as error handling often does.
On a side note, I think Fortran has done a much better job than COBOL of
adding "modern" features (starting with Fortran 90 in 1990). If only the
COBOL "designers" had followed in their footsteps.
And in my mind Fortran had even more to "make up" for in regards to it's
less than ideal beginnings. Which Fortran can even be forgiven for then,
being I believe about five years older than COBOL (Cobol?).
From: IBM Mainframe Discussion List on behalf of
Bob Bridges
Sent: Sunday, June 7, 2020 12:35 PM
The only language I can think of off-hand that doesn't require some sort of
END to close a DO (I'm sure there are others) is ISPF. But, in REXX at
least, I never use single-statement DOs. I see them all the time, and I
don't get it. Like this:
if x=0 then do
x=x+1
end
Or, more painfully:
select
when idx="T" then
do
countt=countt+1
end
when idx="U" then
do
countu=countu+1
end
when idx="V" then
do
countv=countv+1
end
when idx="W" then
do
countw=countw+1
end
otherwise
do
countx=countx+1
end
end
Why? If it were easier to read, I might sympathize. But it's harder, not
easier.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
On Mon, 8 Jun 2020 20:50:12 -0500, Joe Monk wrote: >In this case, because we are PERFORMing THRU, then GO TO exit, merely >causes an iterate. > It's so nice of COBOL to be written in common language so any English speaker can intuitively grasp it correctly. >On Mon, Jun 8, 2020 at 7:36 PM Frank Swarbrick wrote: > >> GO TO to an "exit" procedure (that is, a procedure that terminates >> unconditionally terminates the program) is, in my mind, acceptable as >> well. In fact, if you try to "perform" a "terminal" exit procedure the >> compiler will give you a warning that your "calling" procedure will never >> reach its exit. >> >> >> From: Joe Monk >> Sent: Saturday, June 6, 2020 2:49 AM >> >> I think what you mean is this: >> >> PERFORM 1050-LOOP THRU 1059-EXIT VARYING JC FROM 1 BY 1 UNTIL JC = 99 >> END-PERFORM >> >> 1050-LOOP. >> IF FIRST-NAME NOT = "ROBERT" >> GO TO 1059-EXIT >> END-IF >> IF TYPE NOT = 195 >> GO TO 1059-EXIT >> END-IF >> IF NOT SO-ON >> GO TO 1059-EXIT >> END-IF >> IF NOT SO-FORTH >> GO TO 1059-EXIT >> END-IF >> PERFORM 1050-SUCH-AND-SUCH END-PERFORM >> >> 1059-EXIT. >> EXIT. >> >> In structured programming, it is perfectly acceptable to use GO TO within a >> paragraph. It is NOT acceptable to use GO TO outside of a paragraph. >> >> On Sat, Jun 6, 2020 at 12:42 AM Bob Bridges wrote: >> >> > I realize this is a bit of a change in subject (and it's not as if we need >> > yet another one), but I avoid this construction. My phobia is based on an >> > extreme example: In their zeal never to use GOTOs, I've frequently seen >> > programmers write paragraphs like this: >> > >> > PERFORM 1050-LOOP VARYING JC FROM 1 BY 1 TO 99 >> > >> > 1050-LOOP. >> > IF X < 1000 >> > IF FIRST-NAME NOT = "ROBERT" >> > IF TYPE = 195 >> > IF SO-ON >> > IF SO-FORTH >> > EXECUTE 1050-SUCH-AND-SUCH >> > END-IF >> > END-IF >> > END-IF >> > END-IF >> > END-IF >> > >> > Gives me a headache to try to evaluate that. Much better, in my opinion, >> > to introduce ONE LOUSY "GOTO EO-PARAGRAPH" like this: >> > >> > PERFORM 1050-LOOP THRU 1059-LOOP VARYING JC FROM 1 BY 1 TO 99 >> > >> > 1050-LOOP. >> > IF X > 999 GOTO 1059-LOOP. >> > IF FIRST-NAME = "ROBERT" GOTO 1059-LOOP. >> > IF TYPE <> 195 GOTO 1059-LOOP. >> > IF NOT SO-ON GOTO 1059-LOOP. >> > IF NOT SO-FORTH GOTO 1059-LOOP. >> > EXECUTE 1050-SUCH-AND-SUCH >> > 1059-LOOP. >> > >> > Keep in mind I haven't programmed in COBOL since Y2K; I had to look up the >> > syntax, I probably got part of it wrong nonetheless, and I'll bet there are >> > easier ways to do it nowadays. In REXX, for example, they have the ITERATE >> > statement: >> > >> > do jc=1 to 99 >> > if x>99 then iterate >> > if firstname='ROBERT' then iterate >> > if type<>195 then iterate >> > if \soon then iterate >> > if \soforth then iterate >> > call suchandsuch >> > end >> > >> > However you do it, I vastly prefer skip-to-next-item over nested Ifs. But >> > I confess that one single nested IF is not going to give me a headache; I >> > just react when I see one. Not your fault :). >> > >> > -Original Message- >> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> > Behalf Of Gibney, Dave >> > Sent: Friday, June 5, 2020 16:17 >> > >> > Using OP >> > IF TVOLL (IND1) NOT = HIGH-VALUE >> > AND SMOD (IND1) = 'B' OR 'R' >> > >> > I would do >> > IF TVOLL (IND1) NOT = HIGH-VALUE >> > IF SMOD (IND1) = 'B' OR 'R' >> > Do the stuff -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
FORTRAN 90 was a significant upgrade over previous standards. Mainly, free-form
input source statements.
Also, increase the length of identifiers from 6 characters to 31 characters,
and upper/lowecase keywords/identifiers.
The latest standard is Fortran 2018.
I still teach Fortran to my Honor students. It's easy to learn for a first
programming language, very forgiving, and
you can do a lot with it. I still get flack from uninformed individuals, you
know, the ones that say no one uses mainframes
anymore, no one uses Fortran anymore, no on uses COBOL anymore. Every year, a
couple of my students email me back
to say how having Fortran experience on their resume helped them land a job or
internship; companies like NASA, NOAA,
Lockheed-Martin, etc. They are usually the only applicants out of hundreds that
list Fortran experience.
Darren
From: IBM Mainframe Discussion List on behalf of
lenru...@gmail.com
Sent: Monday, June 8, 2020 8:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question
On, long ago and on some DOS/VS Cobol compiler, after a compiler upgrade, there
was a problem with a statement something like this:
READ some-fileAT END do somethingMOVE A TO B.
See the problem? The period after the AT END was omitted. The old compiler
only allowed one statement after AT END (maybe a bug) but after it honored the
period.
It was a bear to find. It worked before and for a long time after the compiler
change, until it was complied again.
On Monday, June 8, 2020, 08:22:18 PM CDT, Frank Swarbrick
wrote:
I've been teaching myself (modern) Fortran the last few weeks. Just because.
It has an interesting behavior that I kind of like.
Normal IF statement:
if (something) then
end if
But it also has a "one line IF" (not sure offhand of the Fortran "name" for
this):
if (something)
must be on the same line as the if and the condition (unless
you specify the "line continuation character"), and of course only one
statement is allowed. Kind of like the C/Java if statement with out a
statement block, but less dangerous because of the "on the same line"
requirement. Here is one way I've used it in practice.
call get_command_argument(1, host)
if (inet_addr(host) .lt. 0) call error_stop("Host must be in dotted decimal
format.")
call get_command_argument(2, port_str)
read (port_str, '(i5)', iostat = iostat) port ! convert string 'port_str' to
integer 'port'
if (iostat .ne. 0 .or. port .le. 0) call error_stop("Port must be positive
numeric (0-32767).")
Using "if/then" instead of just "if" I'd have had this:
call get_command_argument(1, host)
if (inet_addr(host) .lt. 0) then
call error_stop("Host must be in dotted decimal format.")
end if
call get_command_argument(2, port_str)
read (port_str, '(i5)', iostat = iostat) port ! convert string 'port_str' to
integer 'port'
if (iostat .ne. 0 .or. port .le. 0) then
call error_stop("Port must be positive numeric (0-32767).")
end if
Given by absolute druthers I would have the then clause part of the single line
if instead of the if/end if, but its still pretty nice regardless, as it
doesn't cause as much "clutter" as error handling often does.
On a side note, I think Fortran has done a much better job than COBOL of adding
"modern" features (starting with Fortran 90 in 1990). If only the COBOL
"designers" had followed in their footsteps.
And in my mind Fortran had even more to "make up" for in regards to it's less
than ideal beginnings. Which Fortran can even be forgiven for then, being I
believe about five years older than COBOL (Cobol?).
From: IBM Mainframe Discussion List on behalf of Bob
Bridges
Sent: Sunday, June 7, 2020 12:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question
The only language I can think of off-hand that doesn't require some sort of END
to close a DO (I'm sure there are others) is ISPF. But, in REXX at least, I
never use single-statement DOs. I see them all the time, and I don't get it.
Like this:
if x=0 then do
x=x+1
end
Or, more painfully:
select
when idx="T" then
do
countt=countt+1
end
when idx="U" then
do
countu=countu+1
end
when idx="V" then
do
countv=countv+1
end
when idx="W" then
do
countw=countw+1
end
otherwise
do
countx=countx+1
end
end
Why? If it were easier to read, I might sympathize. But it's harder, not
easier.
---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
/* It's a good thing Lincoln wrote the Gettysburg Address the year that he did,
or else that "fourscore and seven years" part would have just been plain wrong.
-Paul Paternoster */
Re: COBOL Question
On, long ago and on some DOS/VS Cobol compiler, after a compiler upgrade,
there was a problem with a statement something like this:
READ some-file AT END do somethingMOVE A TO B.
See the problem? The period after the AT END was omitted. The old compiler
only allowed one statement after AT END (maybe a bug) but after it honored the
period.
It was a bear to find. It worked before and for a long time after the compiler
change, until it was complied again.
On Monday, June 8, 2020, 08:22:18 PM CDT, Frank Swarbrick
wrote:
I've been teaching myself (modern) Fortran the last few weeks. Just because.
It has an interesting behavior that I kind of like.
Normal IF statement:
if (something) then
end if
But it also has a "one line IF" (not sure offhand of the Fortran "name" for
this):
if (something)
must be on the same line as the if and the condition (unless
you specify the "line continuation character"), and of course only one
statement is allowed. Kind of like the C/Java if statement with out a
statement block, but less dangerous because of the "on the same line"
requirement. Here is one way I've used it in practice.
call get_command_argument(1, host)
if (inet_addr(host) .lt. 0) call error_stop("Host must be in dotted decimal
format.")
call get_command_argument(2, port_str)
read (port_str, '(i5)', iostat = iostat) port ! convert string 'port_str' to
integer 'port'
if (iostat .ne. 0 .or. port .le. 0) call error_stop("Port must be positive
numeric (0-32767).")
Using "if/then" instead of just "if" I'd have had this:
call get_command_argument(1, host)
if (inet_addr(host) .lt. 0) then
call error_stop("Host must be in dotted decimal format.")
end if
call get_command_argument(2, port_str)
read (port_str, '(i5)', iostat = iostat) port ! convert string 'port_str' to
integer 'port'
if (iostat .ne. 0 .or. port .le. 0) then
call error_stop("Port must be positive numeric (0-32767).")
end if
Given by absolute druthers I would have the then clause part of the single line
if instead of the if/end if, but its still pretty nice regardless, as it
doesn't cause as much "clutter" as error handling often does.
On a side note, I think Fortran has done a much better job than COBOL of adding
"modern" features (starting with Fortran 90 in 1990). If only the COBOL
"designers" had followed in their footsteps.
And in my mind Fortran had even more to "make up" for in regards to it's less
than ideal beginnings. Which Fortran can even be forgiven for then, being I
believe about five years older than COBOL (Cobol?).
From: IBM Mainframe Discussion List on behalf of Bob
Bridges
Sent: Sunday, June 7, 2020 12:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question
The only language I can think of off-hand that doesn't require some sort of END
to close a DO (I'm sure there are others) is ISPF. But, in REXX at least, I
never use single-statement DOs. I see them all the time, and I don't get it.
Like this:
if x=0 then do
x=x+1
end
Or, more painfully:
select
when idx="T" then
do
countt=countt+1
end
when idx="U" then
do
countu=countu+1
end
when idx="V" then
do
countv=countv+1
end
when idx="W" then
do
countw=countw+1
end
otherwise
do
countx=countx+1
end
end
Why? If it were easier to read, I might sympathize. But it's harder, not
easier.
---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
/* It's a good thing Lincoln wrote the Gettysburg Address the year that he did,
or else that "fourscore and seven years" part would have just been plain wrong.
-Paul Paternoster */
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Saturday, June 6, 2020 14:40
But in Rexx similarly, END is required even for a single-statement DO.
Good for Rexx. I like strong closure.
>--- On 6 Jun 2020 10:53:44 -0700, (Bob Bridges) wrote:
>>Oh, you need an END-IF even for a single-statement IF? I forgot; I've been
>>thinking in REXX too long. In that case you're close; I guess I really meant
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
In this case, because we are PERFORMing THRU, then GO TO exit, merely causes an iterate. Joe On Mon, Jun 8, 2020 at 7:36 PM Frank Swarbrick wrote: > GO TO to an "exit" procedure (that is, a procedure that terminates > unconditionally terminates the program) is, in my mind, acceptable as > well. In fact, if you try to "perform" a "terminal" exit procedure the > compiler will give you a warning that your "calling" procedure will never > reach its exit. > > > From: IBM Mainframe Discussion List on behalf > of Joe Monk > Sent: Saturday, June 6, 2020 2:49 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: COBOL Question > > I think what you mean is this: > > PERFORM 1050-LOOP THRU 1059-EXIT VARYING JC FROM 1 BY 1 UNTIL JC = 99 > END-PERFORM > > 1050-LOOP. > IF FIRST-NAME NOT = "ROBERT" > GO TO 1059-EXIT > END-IF > IF TYPE NOT = 195 > GO TO 1059-EXIT > END-IF > IF NOT SO-ON > GO TO 1059-EXIT > END-IF > IF NOT SO-FORTH > GO TO 1059-EXIT > END-IF > PERFORM 1050-SUCH-AND-SUCH END-PERFORM > > 1059-EXIT. > EXIT. > > In structured programming, it is perfectly acceptable to use GO TO within a > paragraph. It is NOT acceptable to use GO TO outside of a paragraph. > > Joe > > On Sat, Jun 6, 2020 at 12:42 AM Bob Bridges wrote: > > > I realize this is a bit of a change in subject (and it's not as if we > need > > yet another one), but I avoid this construction. My phobia is based on > an > > extreme example: In their zeal never to use GOTOs, I've frequently seen > > programmers write paragraphs like this: > > > > PERFORM 1050-LOOP VARYING JC FROM 1 BY 1 TO 99 > > > > 1050-LOOP. > > IF X < 1000 > > IF FIRST-NAME NOT = "ROBERT" > > IF TYPE = 195 > > IF SO-ON > > IF SO-FORTH > > EXECUTE 1050-SUCH-AND-SUCH > > END-IF > > END-IF > > END-IF > > END-IF > > END-IF > > > > Gives me a headache to try to evaluate that. Much better, in my opinion, > > to introduce ONE LOUSY "GOTO EO-PARAGRAPH" like this: > > > > PERFORM 1050-LOOP THRU 1059-LOOP VARYING JC FROM 1 BY 1 TO 99 > > > > 1050-LOOP. > > IF X > 999 GOTO 1059-LOOP. > > IF FIRST-NAME = "ROBERT" GOTO 1059-LOOP. > > IF TYPE <> 195 GOTO 1059-LOOP. > > IF NOT SO-ON GOTO 1059-LOOP. > > IF NOT SO-FORTH GOTO 1059-LOOP. > > EXECUTE 1050-SUCH-AND-SUCH > > 1059-LOOP. > > > > Keep in mind I haven't programmed in COBOL since Y2K; I had to look up > the > > syntax, I probably got part of it wrong nonetheless, and I'll bet there > are > > easier ways to do it nowadays. In REXX, for example, they have the > ITERATE > > statement: > > > > do jc=1 to 99 > > if x>99 then iterate > > if firstname='ROBERT' then iterate > > if type<>195 then iterate > > if \soon then iterate > > if \soforth then iterate > > call suchandsuch > > end > > > > However you do it, I vastly prefer skip-to-next-item over nested Ifs. > But > > I confess that one single nested IF is not going to give me a headache; I > > just react when I see one. Not your fault :). > > > > --- > > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > > > > /* In an emergency, a drawstring from a parka hood can be used to > strangle > > a snoring tent mate. -"Camping Tips" */ > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of Gibney, Dave > > Sent: Friday, June 5, 2020 16:17 > > > > Using OP > > IF TVOLL (IND1) NOT = HIGH-VALUE > > AND SMOD (IND1) = 'B' OR 'R' > > > > I would do > > IF TVOLL (IND1) NOT = HIGH-VALUE > > IF SMOD (IND1) = 'B' OR 'R' > > Do the stuff > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
I've been teaching myself (modern) Fortran the last few weeks. Just because.
It has an interesting behavior that I kind of like.
Normal IF statement:
if (something) then
end if
But it also has a "one line IF" (not sure offhand of the Fortran "name" for
this):
if (something)
must be on the same line as the if and the condition (unless
you specify the "line continuation character"), and of course only one
statement is allowed. Kind of like the C/Java if statement with out a
statement block, but less dangerous because of the "on the same line"
requirement. Here is one way I've used it in practice.
call get_command_argument(1, host)
if (inet_addr(host) .lt. 0) call error_stop("Host must be in dotted decimal
format.")
call get_command_argument(2, port_str)
read (port_str, '(i5)', iostat = iostat) port ! convert string 'port_str' to
integer 'port'
if (iostat .ne. 0 .or. port .le. 0) call error_stop("Port must be positive
numeric (0-32767).")
Using "if/then" instead of just "if" I'd have had this:
call get_command_argument(1, host)
if (inet_addr(host) .lt. 0) then
call error_stop("Host must be in dotted decimal format.")
end if
call get_command_argument(2, port_str)
read (port_str, '(i5)', iostat = iostat) port ! convert string 'port_str' to
integer 'port'
if (iostat .ne. 0 .or. port .le. 0) then
call error_stop("Port must be positive numeric (0-32767).")
end if
Given by absolute druthers I would have the then clause part of the single line
if instead of the if/end if, but its still pretty nice regardless, as it
doesn't cause as much "clutter" as error handling often does.
On a side note, I think Fortran has done a much better job than COBOL of adding
"modern" features (starting with Fortran 90 in 1990). If only the COBOL
"designers" had followed in their footsteps.
And in my mind Fortran had even more to "make up" for in regards to it's less
than ideal beginnings. Which Fortran can even be forgiven for then, being I
believe about five years older than COBOL (Cobol?).
From: IBM Mainframe Discussion List on behalf of Bob
Bridges
Sent: Sunday, June 7, 2020 12:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question
The only language I can think of off-hand that doesn't require some sort of END
to close a DO (I'm sure there are others) is ISPF. But, in REXX at least, I
never use single-statement DOs. I see them all the time, and I don't get it.
Like this:
if x=0 then do
x=x+1
end
Or, more painfully:
select
when idx="T" then
do
countt=countt+1
end
when idx="U" then
do
countu=countu+1
end
when idx="V" then
do
countv=countv+1
end
when idx="W" then
do
countw=countw+1
end
otherwise
do
countx=countx+1
end
end
Why? If it were easier to read, I might sympathize. But it's harder, not
easier.
---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
/* It's a good thing Lincoln wrote the Gettysburg Address the year that he did,
or else that "fourscore and seven years" part would have just been plain wrong.
-Paul Paternoster */
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Saturday, June 6, 2020 14:40
But in Rexx similarly, END is required even for a single-statement DO.
Good for Rexx. I like strong closure.
>--- On 6 Jun 2020 10:53:44 -0700, (Bob Bridges) wrote:
>>Oh, you need an END-IF even for a single-statement IF? I forgot; I've been
>>thinking in REXX too long. In that case you're close; I guess I really meant
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
Were there really three releases of VS COBOL II that didn't implement COBOL 1985? I thought there was only one. But I didn't live through it. I generally think of COBOL II and COBOL 1985 as being "the same", since that was (essentially) the case by the time I became a COBOL developer (in 1996). I also curse those who still insist on using periods to terminate sentences when it is allowed. The major offender at my shop left a few years ago, so I've mostly (?) gotten over it. From: IBM Mainframe Discussion List on behalf of Clark Morris Sent: Saturday, June 6, 2020 12:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL Question [Default] On 6 Jun 2020 10:53:44 -0700, in bit.listserv.ibm-main robhbrid...@gmail.com (Bob Bridges) wrote: >Oh, you need an END-IF even for a single-statement IF? I forgot; I've been >thinking in REXX too long. In that case you're close; I guess I really meant In your example the END-IF is not needed. However beginning with VS COBOL IIV4 (1985 standard) it became better practice to eliminate all but the last period in a paragraph and terminate all conditional with end statements such as END-IF. With Enterprise COBOL 5.2 and later (2002 Standard) the 1050-EXIT paragraph could be eliminated and the GO TOs replaced with EXIT PARAGRAPH. This allow simpler code generation for the PERFORM and the PERFORMed paragraph be moved inline to in effect replace the PERFORM statement. Also look up inline PERFORMs. In general, because of code optimization starting with VS COBOL II release 4 (1985 standard) GO TO became a bad idea. Clark Morris > > PERFORM 1050-LOOP THRU 1050-EXIT VARYING JC FROM 1 BY 1 TO 99 > > 1050-LOOP. > IF X > 999 GOTO 1050-EXIT END-IF. > IF FIRST-NAME = "ROBERT" GOTO 1050-EXIT END-IF. > IF TYPE <> 195 GOTO 1050-EXIT END-IF. > IF NOT SO-ON GOTO 1050-EXIT END-IF. > IF NOT SO-FORTH GOTO 1050-EXIT END-IF. > [do such and such] > 1050-EXIT. > >I'm happy to hear someone else admit that a GOTO is conceivable under ~any~ >circumstances. In my old shop I argued for GOTOs in three very strictly >limited circumstances, the other two being end-of-section and end-of-program. >Some languages allow for this by including some flavor of "leave" statement; >all I want to do with a GOTO is to simulate that part of structured >programming. But at the particular shop I have in mind, none of that could be >contemplated, because all GOTOs are evil. > >--- >Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > >/* Law #21 of combat operations: The important things are always simple; the >simple things are always hard. */ > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Joe Monk >Sent: Saturday, June 6, 2020 04:49 > >I think what you mean is this: > >PERFORM 1050-LOOP THRU 1059-EXIT VARYING JC FROM 1 BY 1 UNTIL JC = 99 >END-PERFORM > > 1050-LOOP. >IF FIRST-NAME NOT = "ROBERT" >GO TO 1059-EXIT >END-IF >IF TYPE NOT = 195 >GO TO 1059-EXIT >END-IF >IF NOT SO-ON >GO TO 1059-EXIT >END-IF >IF NOT SO-FORTH >GO TO 1059-EXIT >END-IF >PERFORM 1050-SUCH-AND-SUCH END-PERFORM > > 1059-EXIT. > EXIT. > >In structured programming, it is perfectly acceptable to use GO TO within a >paragraph. It is NOT acceptable to use GO TO outside of a paragraph. > >--- On Sat, Jun 6, 2020 at 12:42 AM Bob Bridges wrote: >> I realize this is a bit of a change in subject (and it's not as if we need >> yet another one), but I avoid this construction. My phobia is based on an >> extreme example: In their zeal never to use GOTOs, I've frequently seen >> programmers write paragraphs like this: >> >> PERFORM 1050-LOOP VARYING JC FROM 1 BY 1 TO 99 >> >> 1050-LOOP. >> IF X < 1000 >> IF FIRST-NAME NOT = "ROBERT" >> IF TYPE = 195 >> IF SO-ON >> IF SO-FORTH >> EXECUTE 1050-SUCH-AND-SUCH >> END-IF >> END-IF >> END-IF >> END-IF >> END-IF >> >> Gives me a headache to try to evaluate that. Much better, in my opinion, >> to introduce ONE LOUSY "GOTO EO-PARAGRAPH" like this: >> >> PERFORM 1050-LOOP THRU 1059-LOOP VARYING JC FROM 1 BY 1 TO 99 >> >> 1050-LOOP. >> IF X > 999 GOTO 1059-LOOP. >> IF FIRST-NAME = "ROBERT" GOTO 1059-LOOP. >> IF TYPE <> 195 GOTO 1059-LOOP. >> IF NOT SO-ON GOTO 1059-LOOP. >> IF NOT SO-FORTH GOTO 1059-LOOP.
Re: COBOL Question
Apologies again if this has already been answered. I'm a few days behind. You can use a full stop (period) to terminate an IF statement. The "problem" is (and one of the any reasons I elide all periods that are not absolutely required) it terminates an entire COBOL "sentence" (not just a COBOL statement). Since you used a perform of a separate procedure you could end each IF with a period and its fine. The same would not be true for an "inline" perform, as I showed in my previous reply. If I had used a period instead of an END-IF the period would not only terminate the first IF, but also the PERFORM. Meaning the remainder of the IF statements would end up being "outside of the loop", while the END-PERFORM would have no PERFORM to match to, since the PERFORM was already terminated by the period. Bad news! But at least it wouldn't compile. If I had dropped the END-PERFORM it WOULD compile (with periods replacing END-IFs), but it wouldn't do what you want. Here's, if you are interested, valid COBOL that also likely does not do what one would want it to do. IF SOMETHING NEXT SENTENCE ELSE PERFORM SOMETHING-ELSE END-IF PERFORM MORE PERFORM MORE-AND-MORE EXIT. The "NEXT SENTENCE" phrase of an IF statement is an implicit GO TO *beyond* the next period (i.e., "to the next sentence". In this case if SOMETHING is true not only would SOMETHING-ELSE be bypassed, but so would MORE and MORE-AND-MORE. Two possible fixes are: 1) add three periods (example below), or keep as-is except replace the NEXT SENTENCE phrase (clause?) with a CONTINUE statement. CONTINUE is a true no-op, rather then a GO TO in disguise. Option 1) IF SOMETHING NEXT SENTENCE ELSE PERFORM SOMETHING-ELSE END-IF. PERFORM MORE. PERFORM MORE-AND-MORE. EXIT. Option 2) IF SOMETHING CONTINUE ELSE PERFORM SOMETHING-ELSE END-IF PERFORM MORE PERFORM MORE-AND-MORE EXIT. All of this nonsense is, of course, a result of END- clauses not being part of COBOL before the 1985 standard. You HAD to use a period to terminate an IF. And of course all of that is a result of someone thinking that an "English like" programming language could be unambiguous, or at least a somewhat good idea in practice... A good idea in theory, but not so much in practice. From: IBM Mainframe Discussion List on behalf of Bob Bridges Sent: Saturday, June 6, 2020 11:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL Question Oh, you need an END-IF even for a single-statement IF? I forgot; I've been thinking in REXX too long. In that case you're close; I guess I really meant PERFORM 1050-LOOP THRU 1050-EXIT VARYING JC FROM 1 BY 1 TO 99 1050-LOOP. IF X > 999 GOTO 1050-EXIT END-IF. IF FIRST-NAME = "ROBERT" GOTO 1050-EXIT END-IF. IF TYPE <> 195 GOTO 1050-EXIT END-IF. IF NOT SO-ON GOTO 1050-EXIT END-IF. IF NOT SO-FORTH GOTO 1050-EXIT END-IF. [do such and such] 1050-EXIT. I'm happy to hear someone else admit that a GOTO is conceivable under ~any~ circumstances. In my old shop I argued for GOTOs in three very strictly limited circumstances, the other two being end-of-section and end-of-program. Some languages allow for this by including some flavor of "leave" statement; all I want to do with a GOTO is to simulate that part of structured programming. But at the particular shop I have in mind, none of that could be contemplated, because all GOTOs are evil. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Law #21 of combat operations: The important things are always simple; the simple things are always hard. */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joe Monk Sent: Saturday, June 6, 2020 04:49 I think what you mean is this: PERFORM 1050-LOOP THRU 1059-EXIT VARYING JC FROM 1 BY 1 UNTIL JC = 99 END-PERFORM 1050-LOOP. IF FIRST-NAME NOT = "ROBERT" GO TO 1059-EXIT END-IF IF TYPE NOT = 195 GO TO 1059-EXIT END-IF IF NOT SO-ON GO TO 1059-EXIT END-IF IF NOT SO-FORTH GO TO 1059-EXIT END-IF PERFORM 1050-SUCH-AND-SUCH END-PERFORM 1059-EXIT. EXIT. In structured programming, it is perfectly acceptable to use GO TO within a paragraph. It is NOT acceptable to use GO TO outside of a paragraph. --- On Sat, Jun 6, 2020 at 12:42 AM Bob Bridges wrote: > I realize this is a bit of a change in subject (and it's not as if we need > yet another one), but I avoid this construction. My phobia is based on an > extreme example: In their zeal never to use GOTOs, I've frequently seen > programmers write paragraphs like this: > > PERFORM 1050-LOOP VARYING JC FROM 1 BY 1 TO 99 > > 1050-LOOP. > IF X < 1000 > IF FIRST-NAME NOT = "ROBERT" &g
Re: COBOL Question
GO TO to an "exit" procedure (that is, a procedure that terminates unconditionally terminates the program) is, in my mind, acceptable as well. In fact, if you try to "perform" a "terminal" exit procedure the compiler will give you a warning that your "calling" procedure will never reach its exit. From: IBM Mainframe Discussion List on behalf of Joe Monk Sent: Saturday, June 6, 2020 2:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL Question I think what you mean is this: PERFORM 1050-LOOP THRU 1059-EXIT VARYING JC FROM 1 BY 1 UNTIL JC = 99 END-PERFORM 1050-LOOP. IF FIRST-NAME NOT = "ROBERT" GO TO 1059-EXIT END-IF IF TYPE NOT = 195 GO TO 1059-EXIT END-IF IF NOT SO-ON GO TO 1059-EXIT END-IF IF NOT SO-FORTH GO TO 1059-EXIT END-IF PERFORM 1050-SUCH-AND-SUCH END-PERFORM 1059-EXIT. EXIT. In structured programming, it is perfectly acceptable to use GO TO within a paragraph. It is NOT acceptable to use GO TO outside of a paragraph. Joe On Sat, Jun 6, 2020 at 12:42 AM Bob Bridges wrote: > I realize this is a bit of a change in subject (and it's not as if we need > yet another one), but I avoid this construction. My phobia is based on an > extreme example: In their zeal never to use GOTOs, I've frequently seen > programmers write paragraphs like this: > > PERFORM 1050-LOOP VARYING JC FROM 1 BY 1 TO 99 > > 1050-LOOP. > IF X < 1000 > IF FIRST-NAME NOT = "ROBERT" > IF TYPE = 195 > IF SO-ON > IF SO-FORTH > EXECUTE 1050-SUCH-AND-SUCH > END-IF > END-IF > END-IF > END-IF > END-IF > > Gives me a headache to try to evaluate that. Much better, in my opinion, > to introduce ONE LOUSY "GOTO EO-PARAGRAPH" like this: > > PERFORM 1050-LOOP THRU 1059-LOOP VARYING JC FROM 1 BY 1 TO 99 > > 1050-LOOP. > IF X > 999 GOTO 1059-LOOP. > IF FIRST-NAME = "ROBERT" GOTO 1059-LOOP. > IF TYPE <> 195 GOTO 1059-LOOP. > IF NOT SO-ON GOTO 1059-LOOP. > IF NOT SO-FORTH GOTO 1059-LOOP. > EXECUTE 1050-SUCH-AND-SUCH > 1059-LOOP. > > Keep in mind I haven't programmed in COBOL since Y2K; I had to look up the > syntax, I probably got part of it wrong nonetheless, and I'll bet there are > easier ways to do it nowadays. In REXX, for example, they have the ITERATE > statement: > > do jc=1 to 99 > if x>99 then iterate > if firstname='ROBERT' then iterate > if type<>195 then iterate > if \soon then iterate > if \soforth then iterate > call suchandsuch > end > > However you do it, I vastly prefer skip-to-next-item over nested Ifs. But > I confess that one single nested IF is not going to give me a headache; I > just react when I see one. Not your fault :). > > --- > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > > /* In an emergency, a drawstring from a parka hood can be used to strangle > a snoring tent mate. -"Camping Tips" */ > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Gibney, Dave > Sent: Friday, June 5, 2020 16:17 > > Using OP > IF TVOLL (IND1) NOT = HIGH-VALUE > AND SMOD (IND1) = 'B' OR 'R' > > I would do > IF TVOLL (IND1) NOT = HIGH-VALUE > IF SMOD (IND1) = 'B' OR 'R' > Do the stuff > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
With Enterprise COBOL V5 and up you could do the following: PERFORM VARYING JC FROM 1 BY 1 UNTIL JC > 99 IF X > 999 EXIT PERFORM CYCLE END-IF IF FIRST-NAME = "ROBERT" EXIT PERFORM CYCLE END-IF IF TYPE <> 195 EXIT PERFORM CYCLE END-IF IF NOT SO-ON EXIT PERFORM CYCLE END-IF IF NOT SO-FORTH EXIT PERFORM CYCLE END-IF PERFORM 1050-SUCH-AND-SUCH END-PERFORM EXIT PERFORM CYCLE is COBOL's version of REXX "iterate", C/C++/Java "continue", etc. EXIT PERFORM (w/o CYCLE) is like "leave/break". Only works with an inline perform, but that's true for those other languages as well. Inline performs have been available since COBOL 1985 standard, e.g. IBM VS COBOL II, but EXIT PERFORM [CYCLE] were added only in the COBOL 2002 standard. From: IBM Mainframe Discussion List on behalf of Bob Bridges Sent: Friday, June 5, 2020 11:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL Question I realize this is a bit of a change in subject (and it's not as if we need yet another one), but I avoid this construction. My phobia is based on an extreme example: In their zeal never to use GOTOs, I've frequently seen programmers write paragraphs like this: PERFORM 1050-LOOP VARYING JC FROM 1 BY 1 TO 99 1050-LOOP. IF X < 1000 IF FIRST-NAME NOT = "ROBERT" IF TYPE = 195 IF SO-ON IF SO-FORTH EXECUTE 1050-SUCH-AND-SUCH END-IF END-IF END-IF END-IF END-IF Gives me a headache to try to evaluate that. Much better, in my opinion, to introduce ONE LOUSY "GOTO EO-PARAGRAPH" like this: PERFORM 1050-LOOP THRU 1059-LOOP VARYING JC FROM 1 BY 1 TO 99 1050-LOOP. IF X > 999 GOTO 1059-LOOP. IF FIRST-NAME = "ROBERT" GOTO 1059-LOOP. IF TYPE <> 195 GOTO 1059-LOOP. IF NOT SO-ON GOTO 1059-LOOP. IF NOT SO-FORTH GOTO 1059-LOOP. EXECUTE 1050-SUCH-AND-SUCH 1059-LOOP. Keep in mind I haven't programmed in COBOL since Y2K; I had to look up the syntax, I probably got part of it wrong nonetheless, and I'll bet there are easier ways to do it nowadays. In REXX, for example, they have the ITERATE statement: do jc=1 to 99 if x>99 then iterate if firstname='ROBERT' then iterate if type<>195 then iterate if \soon then iterate if \soforth then iterate call suchandsuch end However you do it, I vastly prefer skip-to-next-item over nested Ifs. But I confess that one single nested IF is not going to give me a headache; I just react when I see one. Not your fault :). --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* In an emergency, a drawstring from a parka hood can be used to strangle a snoring tent mate. -"Camping Tips" */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave Sent: Friday, June 5, 2020 16:17 Using OP IF TVOLL (IND1) NOT = HIGH-VALUE AND SMOD (IND1) = 'B' OR 'R' I would do IF TVOLL (IND1) NOT = HIGH-VALUE IF SMOD (IND1) = 'B' OR 'R' Do the stuff -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
In PL/I, yes, but not in REXX.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Wayne Bickerdike [wayn...@gmail.com]
Sent: Monday, June 8, 2020 12:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question
For brevity, if you don't like DO END.
select
when idx="T" then countt=countt+1
when idx="U" then countu=countu+1
when idx="V" then countv=countv+1
when idx="W" then countw=countw+1
otherwise countx=countx+1; end
Could be :
SELECT( idx)
when ("T") then countt=countt+1
when ("U") then countu=countu+1
when ("V") then countv=countv+1
when ("W") then countw=countw+1
otherwise countx=countx+1; end
On Mon, Jun 8, 2020 at 2:08 PM Bob Bridges wrote:
> No, I wasn't complaining about the SELECT statement, only about using lots
> of DO/statement/ENDs when there's only a single statement. I would code
> the same thing like this:
>
> select
> when idx="T" then countt=countt+1
> when idx="U" then countu=countu+1
> when idx="V" then countv=countv+1
> when idx="W" then countw=countw+1
> otherwise countx=countx+1; end
>
> (Of course if that were a real example I would probably have found a way
> to use a stem variable instead:
>
> count.idx=count.idx+1
>
> But in this case I was just talking about coding style, as Mr Metz said.)
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* If a problem has a single neck, it has a simple solution. */
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lou Losee
> Sent: Sunday, June 7, 2020 14:38
>
> Would you rather code the select as a series of nested if-then-else?
>
> --- On Sun, Jun 7, 2020 at 1:35 PM Bob Bridges
> wrote:
> > The only language I can think of off-hand that doesn't require some sort
> > of END to close a DO (I'm sure there are others) is ISPF. But, in REXX
> at
> > least, I never use single-statement DOs. I see them all the time, and I
> > don't get it. Like this:
> >
> > if x=0 then do
> > x=x+1
> > end
> >
> > Or, more painfully:
> >
> > select
> > when idx="T" then
> > do
> > countt=countt+1
> > end
> > when idx="U" then
> > do
> > countu=countu+1
> > end
> > when idx="V" then
> > do
> > countv=countv+1
> > end
> > when idx="W" then
> > do
> > countw=countw+1
> > end
> > otherwise
> > do
> > countx=countx+1
> > end
> > end
> >
> > Why? If it were easier to read, I might sympathize. But it's harder,
> not
> > easier.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Paul Gilmartin
> > Sent: Saturday, June 6, 2020 14:40
> >
> > But in Rexx similarly, END is required even for a single-statement DO.
> > Good for Rexx. I like strong closure.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
Wayne V. Bickerdike
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Goto Statements (was: COBOL Question)
It didn't help that he contradicted himself as to whether GOTO should be banned. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Wayne Bickerdike [wayn...@gmail.com] Sent: Monday, June 8, 2020 4:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Goto Statements (was: COBOL Question) Dijkstra wrote his missive around 1968. Knuth made a meal of it and after reading his paper which was published 5 years later, it was too hard a read. Around the same time Michael Jackson was distilling this information and produced his structured programming book "Principles of Program Design". I still have a copy and generally will approach program design using the same tried and tested techniques. At IBM in 1978 we had an advocate for the same methods, Tony Droar. Unfortunately, a lot of this good work seemed to miss a lot of organisations. Some places I worked in the 80's wouldn't allow a sort to make a program easier to write. Jackson explained go to was essential, particularly when performing validationposit.admitquit. I've seen a Jackson structure design turned into a flowchart and the structure is lost. Flowcharts encouraged the use of GO TO. On Mon, Jun 8, 2020 at 4:45 PM David Crayford wrote: > On 2020-06-07 10:48 PM, Paul Gilmartin wrote: > >> I consider the out of line PERFORM to be far more dangerous. I have a > similar issue with REXX; it does not have lexical scope, and you can fall > into a procedure. > >> > > A noteworthy 1976 paper (behind a paywall): > > Software malpractice — a distasteful experience† > > https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.4380060303 > > > > ... describes the pitfall set by a (too) clever programmer's relying on > > optimization by falling into procedures. > > > > † In the day, I read it free in the University library. > > I'm sure that paper is an interesting read from a historical > perspective. It's referenced in Code Complete along with another > reference to Frank Rubin's letter to the ACM (March 1987) > in which he asserts that goto-less programming has cost business > "hundreds of millions of dollars". > > The original context of the "goto considered harmful" is lost on the > younger generation, as at the time there were large swaths of developers > who were trained before structured programming took off. > There are a handful of use cases where "goto" makes the code simpler, > cleaner and more readable. In these cases, you /should/ use goto > statements. A good programmer can recognize these cases and use goto > appropriately. > > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Wayne V. Bickerdike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Goto Statements (was: COBOL Question)
I learned JSP back in the early 90's. It was popular in the UK (Jackson was British) and most large mainframe companies adopted it. It was good. There was even tooling that could create code from charts. Dijkstra's paper is one of the most controversial CS papers ever written. It was written before structured programming took off and programming languages like FORTRAN and COBOL were not well structured at the time. Unfortunately, people drank the kool-aid and a whole generation of programmers were brain-washed by dogma that goto is inherently evil. I see code all the time that eschews goto for error handling and the alternative is never better. In fact, it's always crap! It's either deeply nested if-logic or extra status flag checks. For languages that support try/finally, use groups, RAII etc the problem doesn't exist but that's certainly not the case from almost all mainstream languages that run on z/OS other than Java and C++. On 2020-06-08 4:28 PM, Wayne Bickerdike wrote: Dijkstra wrote his missive around 1968. Knuth made a meal of it and after reading his paper which was published 5 years later, it was too hard a read. Around the same time Michael Jackson was distilling this information and produced his structured programming book "Principles of Program Design". I still have a copy and generally will approach program design using the same tried and tested techniques. At IBM in 1978 we had an advocate for the same methods, Tony Droar. Unfortunately, a lot of this good work seemed to miss a lot of organisations. Some places I worked in the 80's wouldn't allow a sort to make a program easier to write. Jackson explained go to was essential, particularly when performing validationposit.admitquit. I've seen a Jackson structure design turned into a flowchart and the structure is lost. Flowcharts encouraged the use of GO TO. On Mon, Jun 8, 2020 at 4:45 PM David Crayford wrote: On 2020-06-07 10:48 PM, Paul Gilmartin wrote: I consider the out of line PERFORM to be far more dangerous. I have a similar issue with REXX; it does not have lexical scope, and you can fall into a procedure. A noteworthy 1976 paper (behind a paywall): Software malpractice — a distasteful experience† https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.4380060303 ... describes the pitfall set by a (too) clever programmer's relying on optimization by falling into procedures. † In the day, I read it free in the University library. I'm sure that paper is an interesting read from a historical perspective. It's referenced in Code Complete along with another reference to Frank Rubin's letter to the ACM (March 1987) in which he asserts that goto-less programming has cost business "hundreds of millions of dollars". The original context of the "goto considered harmful" is lost on the younger generation, as at the time there were large swaths of developers who were trained before structured programming took off. There are a handful of use cases where "goto" makes the code simpler, cleaner and more readable. In these cases, you /should/ use goto statements. A good programmer can recognize these cases and use goto appropriately. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Goto Statements (was: COBOL Question)
Dijkstra wrote his missive around 1968. Knuth made a meal of it and after reading his paper which was published 5 years later, it was too hard a read. Around the same time Michael Jackson was distilling this information and produced his structured programming book "Principles of Program Design". I still have a copy and generally will approach program design using the same tried and tested techniques. At IBM in 1978 we had an advocate for the same methods, Tony Droar. Unfortunately, a lot of this good work seemed to miss a lot of organisations. Some places I worked in the 80's wouldn't allow a sort to make a program easier to write. Jackson explained go to was essential, particularly when performing validationposit.admitquit. I've seen a Jackson structure design turned into a flowchart and the structure is lost. Flowcharts encouraged the use of GO TO. On Mon, Jun 8, 2020 at 4:45 PM David Crayford wrote: > On 2020-06-07 10:48 PM, Paul Gilmartin wrote: > >> I consider the out of line PERFORM to be far more dangerous. I have a > similar issue with REXX; it does not have lexical scope, and you can fall > into a procedure. > >> > > A noteworthy 1976 paper (behind a paywall): > > Software malpractice — a distasteful experience† > > https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.4380060303 > > > > ... describes the pitfall set by a (too) clever programmer's relying on > > optimization by falling into procedures. > > > > † In the day, I read it free in the University library. > > I'm sure that paper is an interesting read from a historical > perspective. It's referenced in Code Complete along with another > reference to Frank Rubin's letter to the ACM (March 1987) > in which he asserts that goto-less programming has cost business > "hundreds of millions of dollars". > > The original context of the "goto considered harmful" is lost on the > younger generation, as at the time there were large swaths of developers > who were trained before structured programming took off. > There are a handful of use cases where "goto" makes the code simpler, > cleaner and more readable. In these cases, you /should/ use goto > statements. A good programmer can recognize these cases and use goto > appropriately. > > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Wayne V. Bickerdike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Goto Statements (was: COBOL Question)
On 2020-06-07 10:48 PM, Paul Gilmartin wrote: I consider the out of line PERFORM to be far more dangerous. I have a similar issue with REXX; it does not have lexical scope, and you can fall into a procedure. A noteworthy 1976 paper (behind a paywall): Software malpractice — a distasteful experience† https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.4380060303 ... describes the pitfall set by a (too) clever programmer's relying on optimization by falling into procedures. † In the day, I read it free in the University library. I'm sure that paper is an interesting read from a historical perspective. It's referenced in Code Complete along with another reference to Frank Rubin's letter to the ACM (March 1987) in which he asserts that goto-less programming has cost business "hundreds of millions of dollars". The original context of the "goto considered harmful" is lost on the younger generation, as at the time there were large swaths of developers who were trained before structured programming took off. There are a handful of use cases where "goto" makes the code simpler, cleaner and more readable. In these cases, you /should/ use goto statements. A good programmer can recognize these cases and use goto appropriately. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
Results:
1
0
0
0
***
On Mon, Jun 8, 2020 at 4:06 PM Wayne Bickerdike wrote:
> /* REXX */
> COUNTT = 0
> COUNTU = 0
> COUNTV = 0
> COUNTW = 0
> TAB.T = "COUNTT=COUNTT+1"
> TAB.U = "COUNTU=COUNTU+1"
> TAB.V = "COUNTV=COUNTV+1"
> TAB.W = "COUNTW=COUNTW+1"
> IDX = 'T'
>
> INTERPRET TAB.IDX
> SAY COUNTT
> SAY COUNTU
> SAY COUNTV
> SAY COUNTW
>
> On Mon, Jun 8, 2020 at 3:10 PM Wayne Bickerdike wrote:
>
>> Forgot the quotes!
>>
>> On Mon, Jun 8, 2020 at 3:07 PM Wayne Bickerdike
>> wrote:
>>
>>> Or to be controversial:
>>>
>>> tab.T = countt=countT+1
>>> tab.U = countU=countU+1
>>> tab.V = countV=countV+1
>>> tab.W = countW=countW+1
>>>
>>> INTERPRET tab.idx
>>>
>>> On Mon, Jun 8, 2020 at 3:01 PM Wayne Bickerdike
>>> wrote:
>>>
CA-IDEAL has SELECT FIRST ACTION AND SELECT EVERY ACTION. That I like.
On Mon, Jun 8, 2020 at 2:59 PM Wayne Bickerdike
wrote:
> For brevity, if you don't like DO END.
>
> select
> when idx="T" then countt=countt+1
> when idx="U" then countu=countu+1
> when idx="V" then countv=countv+1
> when idx="W" then countw=countw+1
> otherwise countx=countx+1; end
>
> Could be :
> SELECT( idx)
> when ("T") then countt=countt+1
> when ("U") then countu=countu+1
> when ("V") then countv=countv+1
> when ("W") then countw=countw+1
> otherwise countx=countx+1; end
>
>
>
> On Mon, Jun 8, 2020 at 2:08 PM Bob Bridges
> wrote:
>
>> No, I wasn't complaining about the SELECT statement, only about using
>> lots of DO/statement/ENDs when there's only a single statement. I would
>> code the same thing like this:
>>
>> select
>> when idx="T" then countt=countt+1
>> when idx="U" then countu=countu+1
>> when idx="V" then countv=countv+1
>> when idx="W" then countw=countw+1
>> otherwise countx=countx+1; end
>>
>> (Of course if that were a real example I would probably have found a
>> way to use a stem variable instead:
>>
>> count.idx=count.idx+1
>>
>> But in this case I was just talking about coding style, as Mr Metz
>> said.)
>>
>> ---
>> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>>
>> /* If a problem has a single neck, it has a simple solution. */
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On Behalf Of Lou Losee
>> Sent: Sunday, June 7, 2020 14:38
>>
>> Would you rather code the select as a series of nested if-then-else?
>>
>> --- On Sun, Jun 7, 2020 at 1:35 PM Bob Bridges
>> wrote:
>> > The only language I can think of off-hand that doesn't require some
>> sort
>> > of END to close a DO (I'm sure there are others) is ISPF. But, in
>> REXX at
>> > least, I never use single-statement DOs. I see them all the time,
>> and I
>> > don't get it. Like this:
>> >
>> > if x=0 then do
>> > x=x+1
>> > end
>> >
>> > Or, more painfully:
>> >
>> > select
>> > when idx="T" then
>> > do
>> > countt=countt+1
>> > end
>> > when idx="U" then
>> > do
>> > countu=countu+1
>> > end
>> > when idx="V" then
>> > do
>> > countv=countv+1
>> > end
>> > when idx="W" then
>> > do
>> > countw=countw+1
>> > end
>> > otherwise
>> > do
>> > countx=countx+1
>> > end
>> > end
>> >
>> > Why? If it were easier to read, I might sympathize. But it's
>> harder, not
>> > easier.
>> >
>> > -Original Message-
>> > From: IBM Mainframe Discussion List [mailto:
>> IBM-MAIN@LISTSERV.UA.EDU] On
>> > Behalf Of Paul Gilmartin
>> > Sent: Saturday, June 6, 2020 14:40
>> >
>> > But in Rexx similarly, END is required even for a single-statement
>> DO.
>> > Good for Rexx. I like strong closure.
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO
>> IBM-MAIN
>>
>
>
> --
> Wayne V. Bickerdike
>
>
--
Wayne V. Bickerdike
>>>
>>> --
>>> Wayne V. Bickerdike
>>>
>>>
>>
>> --
>> Wayne V. Bickerdike
>>
>>
>
> --
> Wayne V. Bickerdike
>
>
--
Wayne V. Bickerdike
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
/* REXX */
COUNTT = 0
COUNTU = 0
COUNTV = 0
COUNTW = 0
TAB.T = "COUNTT=COUNTT+1"
TAB.U = "COUNTU=COUNTU+1"
TAB.V = "COUNTV=COUNTV+1"
TAB.W = "COUNTW=COUNTW+1"
IDX = 'T'
INTERPRET TAB.IDX
SAY COUNTT
SAY COUNTU
SAY COUNTV
SAY COUNTW
On Mon, Jun 8, 2020 at 3:10 PM Wayne Bickerdike wrote:
> Forgot the quotes!
>
> On Mon, Jun 8, 2020 at 3:07 PM Wayne Bickerdike wrote:
>
>> Or to be controversial:
>>
>> tab.T = countt=countT+1
>> tab.U = countU=countU+1
>> tab.V = countV=countV+1
>> tab.W = countW=countW+1
>>
>> INTERPRET tab.idx
>>
>> On Mon, Jun 8, 2020 at 3:01 PM Wayne Bickerdike
>> wrote:
>>
>>> CA-IDEAL has SELECT FIRST ACTION AND SELECT EVERY ACTION. That I like.
>>>
>>> On Mon, Jun 8, 2020 at 2:59 PM Wayne Bickerdike
>>> wrote:
>>>
For brevity, if you don't like DO END.
select
when idx="T" then countt=countt+1
when idx="U" then countu=countu+1
when idx="V" then countv=countv+1
when idx="W" then countw=countw+1
otherwise countx=countx+1; end
Could be :
SELECT( idx)
when ("T") then countt=countt+1
when ("U") then countu=countu+1
when ("V") then countv=countv+1
when ("W") then countw=countw+1
otherwise countx=countx+1; end
On Mon, Jun 8, 2020 at 2:08 PM Bob Bridges
wrote:
> No, I wasn't complaining about the SELECT statement, only about using
> lots of DO/statement/ENDs when there's only a single statement. I would
> code the same thing like this:
>
> select
> when idx="T" then countt=countt+1
> when idx="U" then countu=countu+1
> when idx="V" then countv=countv+1
> when idx="W" then countw=countw+1
> otherwise countx=countx+1; end
>
> (Of course if that were a real example I would probably have found a
> way to use a stem variable instead:
>
> count.idx=count.idx+1
>
> But in this case I was just talking about coding style, as Mr Metz
> said.)
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* If a problem has a single neck, it has a simple solution. */
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Lou Losee
> Sent: Sunday, June 7, 2020 14:38
>
> Would you rather code the select as a series of nested if-then-else?
>
> --- On Sun, Jun 7, 2020 at 1:35 PM Bob Bridges
> wrote:
> > The only language I can think of off-hand that doesn't require some
> sort
> > of END to close a DO (I'm sure there are others) is ISPF. But, in
> REXX at
> > least, I never use single-statement DOs. I see them all the time,
> and I
> > don't get it. Like this:
> >
> > if x=0 then do
> > x=x+1
> > end
> >
> > Or, more painfully:
> >
> > select
> > when idx="T" then
> > do
> > countt=countt+1
> > end
> > when idx="U" then
> > do
> > countu=countu+1
> > end
> > when idx="V" then
> > do
> > countv=countv+1
> > end
> > when idx="W" then
> > do
> > countw=countw+1
> > end
> > otherwise
> > do
> > countx=countx+1
> > end
> > end
> >
> > Why? If it were easier to read, I might sympathize. But it's
> harder, not
> > easier.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> > Behalf Of Paul Gilmartin
> > Sent: Saturday, June 6, 2020 14:40
> >
> > But in Rexx similarly, END is required even for a single-statement
> DO.
> > Good for Rexx. I like strong closure.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
Wayne V. Bickerdike
>>>
>>> --
>>> Wayne V. Bickerdike
>>>
>>>
>>
>> --
>> Wayne V. Bickerdike
>>
>>
>
> --
> Wayne V. Bickerdike
>
>
--
Wayne V. Bickerdike
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
Forgot the quotes!
On Mon, Jun 8, 2020 at 3:07 PM Wayne Bickerdike wrote:
> Or to be controversial:
>
> tab.T = countt=countT+1
> tab.U = countU=countU+1
> tab.V = countV=countV+1
> tab.W = countW=countW+1
>
> INTERPRET tab.idx
>
> On Mon, Jun 8, 2020 at 3:01 PM Wayne Bickerdike wrote:
>
>> CA-IDEAL has SELECT FIRST ACTION AND SELECT EVERY ACTION. That I like.
>>
>> On Mon, Jun 8, 2020 at 2:59 PM Wayne Bickerdike
>> wrote:
>>
>>> For brevity, if you don't like DO END.
>>>
>>> select
>>> when idx="T" then countt=countt+1
>>> when idx="U" then countu=countu+1
>>> when idx="V" then countv=countv+1
>>> when idx="W" then countw=countw+1
>>> otherwise countx=countx+1; end
>>>
>>> Could be :
>>> SELECT( idx)
>>> when ("T") then countt=countt+1
>>> when ("U") then countu=countu+1
>>> when ("V") then countv=countv+1
>>> when ("W") then countw=countw+1
>>> otherwise countx=countx+1; end
>>>
>>>
>>>
>>> On Mon, Jun 8, 2020 at 2:08 PM Bob Bridges
>>> wrote:
>>>
No, I wasn't complaining about the SELECT statement, only about using
lots of DO/statement/ENDs when there's only a single statement. I would
code the same thing like this:
select
when idx="T" then countt=countt+1
when idx="U" then countu=countu+1
when idx="V" then countv=countv+1
when idx="W" then countw=countw+1
otherwise countx=countx+1; end
(Of course if that were a real example I would probably have found a
way to use a stem variable instead:
count.idx=count.idx+1
But in this case I was just talking about coding style, as Mr Metz
said.)
---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
/* If a problem has a single neck, it has a simple solution. */
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Lou Losee
Sent: Sunday, June 7, 2020 14:38
Would you rather code the select as a series of nested if-then-else?
--- On Sun, Jun 7, 2020 at 1:35 PM Bob Bridges
wrote:
> The only language I can think of off-hand that doesn't require some
sort
> of END to close a DO (I'm sure there are others) is ISPF. But, in
REXX at
> least, I never use single-statement DOs. I see them all the time,
and I
> don't get it. Like this:
>
> if x=0 then do
> x=x+1
> end
>
> Or, more painfully:
>
> select
> when idx="T" then
> do
> countt=countt+1
> end
> when idx="U" then
> do
> countu=countu+1
> end
> when idx="V" then
> do
> countv=countv+1
> end
> when idx="W" then
> do
> countw=countw+1
> end
> otherwise
> do
> countx=countx+1
> end
> end
>
> Why? If it were easier to read, I might sympathize. But it's
harder, not
> easier.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On
> Behalf Of Paul Gilmartin
> Sent: Saturday, June 6, 2020 14:40
>
> But in Rexx similarly, END is required even for a single-statement DO.
> Good for Rexx. I like strong closure.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>>
>>>
>>> --
>>> Wayne V. Bickerdike
>>>
>>>
>>
>> --
>> Wayne V. Bickerdike
>>
>>
>
> --
> Wayne V. Bickerdike
>
>
--
Wayne V. Bickerdike
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
Or to be controversial:
tab.T = countt=countT+1
tab.U = countU=countU+1
tab.V = countV=countV+1
tab.W = countW=countW+1
INTERPRET tab.idx
On Mon, Jun 8, 2020 at 3:01 PM Wayne Bickerdike wrote:
> CA-IDEAL has SELECT FIRST ACTION AND SELECT EVERY ACTION. That I like.
>
> On Mon, Jun 8, 2020 at 2:59 PM Wayne Bickerdike wrote:
>
>> For brevity, if you don't like DO END.
>>
>> select
>> when idx="T" then countt=countt+1
>> when idx="U" then countu=countu+1
>> when idx="V" then countv=countv+1
>> when idx="W" then countw=countw+1
>> otherwise countx=countx+1; end
>>
>> Could be :
>> SELECT( idx)
>> when ("T") then countt=countt+1
>> when ("U") then countu=countu+1
>> when ("V") then countv=countv+1
>> when ("W") then countw=countw+1
>> otherwise countx=countx+1; end
>>
>>
>>
>> On Mon, Jun 8, 2020 at 2:08 PM Bob Bridges wrote:
>>
>>> No, I wasn't complaining about the SELECT statement, only about using
>>> lots of DO/statement/ENDs when there's only a single statement. I would
>>> code the same thing like this:
>>>
>>> select
>>> when idx="T" then countt=countt+1
>>> when idx="U" then countu=countu+1
>>> when idx="V" then countv=countv+1
>>> when idx="W" then countw=countw+1
>>> otherwise countx=countx+1; end
>>>
>>> (Of course if that were a real example I would probably have found a way
>>> to use a stem variable instead:
>>>
>>> count.idx=count.idx+1
>>>
>>> But in this case I was just talking about coding style, as Mr Metz said.)
>>>
>>> ---
>>> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>>>
>>> /* If a problem has a single neck, it has a simple solution. */
>>>
>>> -Original Message-
>>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>>> On Behalf Of Lou Losee
>>> Sent: Sunday, June 7, 2020 14:38
>>>
>>> Would you rather code the select as a series of nested if-then-else?
>>>
>>> --- On Sun, Jun 7, 2020 at 1:35 PM Bob Bridges
>>> wrote:
>>> > The only language I can think of off-hand that doesn't require some
>>> sort
>>> > of END to close a DO (I'm sure there are others) is ISPF. But, in
>>> REXX at
>>> > least, I never use single-statement DOs. I see them all the time, and
>>> I
>>> > don't get it. Like this:
>>> >
>>> > if x=0 then do
>>> > x=x+1
>>> > end
>>> >
>>> > Or, more painfully:
>>> >
>>> > select
>>> > when idx="T" then
>>> > do
>>> > countt=countt+1
>>> > end
>>> > when idx="U" then
>>> > do
>>> > countu=countu+1
>>> > end
>>> > when idx="V" then
>>> > do
>>> > countv=countv+1
>>> > end
>>> > when idx="W" then
>>> > do
>>> > countw=countw+1
>>> > end
>>> > otherwise
>>> > do
>>> > countx=countx+1
>>> > end
>>> > end
>>> >
>>> > Why? If it were easier to read, I might sympathize. But it's harder,
>>> not
>>> > easier.
>>> >
>>> > -Original Message-
>>> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>>> On
>>> > Behalf Of Paul Gilmartin
>>> > Sent: Saturday, June 6, 2020 14:40
>>> >
>>> > But in Rexx similarly, END is required even for a single-statement DO.
>>> > Good for Rexx. I like strong closure.
>>>
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>>
>>
>>
>> --
>> Wayne V. Bickerdike
>>
>>
>
> --
> Wayne V. Bickerdike
>
>
--
Wayne V. Bickerdike
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
CA-IDEAL has SELECT FIRST ACTION AND SELECT EVERY ACTION. That I like.
On Mon, Jun 8, 2020 at 2:59 PM Wayne Bickerdike wrote:
> For brevity, if you don't like DO END.
>
> select
> when idx="T" then countt=countt+1
> when idx="U" then countu=countu+1
> when idx="V" then countv=countv+1
> when idx="W" then countw=countw+1
> otherwise countx=countx+1; end
>
> Could be :
> SELECT( idx)
> when ("T") then countt=countt+1
> when ("U") then countu=countu+1
> when ("V") then countv=countv+1
> when ("W") then countw=countw+1
> otherwise countx=countx+1; end
>
>
>
> On Mon, Jun 8, 2020 at 2:08 PM Bob Bridges wrote:
>
>> No, I wasn't complaining about the SELECT statement, only about using
>> lots of DO/statement/ENDs when there's only a single statement. I would
>> code the same thing like this:
>>
>> select
>> when idx="T" then countt=countt+1
>> when idx="U" then countu=countu+1
>> when idx="V" then countv=countv+1
>> when idx="W" then countw=countw+1
>> otherwise countx=countx+1; end
>>
>> (Of course if that were a real example I would probably have found a way
>> to use a stem variable instead:
>>
>> count.idx=count.idx+1
>>
>> But in this case I was just talking about coding style, as Mr Metz said.)
>>
>> ---
>> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>>
>> /* If a problem has a single neck, it has a simple solution. */
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of Lou Losee
>> Sent: Sunday, June 7, 2020 14:38
>>
>> Would you rather code the select as a series of nested if-then-else?
>>
>> --- On Sun, Jun 7, 2020 at 1:35 PM Bob Bridges
>> wrote:
>> > The only language I can think of off-hand that doesn't require some sort
>> > of END to close a DO (I'm sure there are others) is ISPF. But, in REXX
>> at
>> > least, I never use single-statement DOs. I see them all the time, and I
>> > don't get it. Like this:
>> >
>> > if x=0 then do
>> > x=x+1
>> > end
>> >
>> > Or, more painfully:
>> >
>> > select
>> > when idx="T" then
>> > do
>> > countt=countt+1
>> > end
>> > when idx="U" then
>> > do
>> > countu=countu+1
>> > end
>> > when idx="V" then
>> > do
>> > countv=countv+1
>> > end
>> > when idx="W" then
>> > do
>> > countw=countw+1
>> > end
>> > otherwise
>> > do
>> > countx=countx+1
>> > end
>> > end
>> >
>> > Why? If it were easier to read, I might sympathize. But it's harder,
>> not
>> > easier.
>> >
>> > -Original Message-
>> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On
>> > Behalf Of Paul Gilmartin
>> > Sent: Saturday, June 6, 2020 14:40
>> >
>> > But in Rexx similarly, END is required even for a single-statement DO.
>> > Good for Rexx. I like strong closure.
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>
>
> --
> Wayne V. Bickerdike
>
>
--
Wayne V. Bickerdike
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
For brevity, if you don't like DO END.
select
when idx="T" then countt=countt+1
when idx="U" then countu=countu+1
when idx="V" then countv=countv+1
when idx="W" then countw=countw+1
otherwise countx=countx+1; end
Could be :
SELECT( idx)
when ("T") then countt=countt+1
when ("U") then countu=countu+1
when ("V") then countv=countv+1
when ("W") then countw=countw+1
otherwise countx=countx+1; end
On Mon, Jun 8, 2020 at 2:08 PM Bob Bridges wrote:
> No, I wasn't complaining about the SELECT statement, only about using lots
> of DO/statement/ENDs when there's only a single statement. I would code
> the same thing like this:
>
> select
> when idx="T" then countt=countt+1
> when idx="U" then countu=countu+1
> when idx="V" then countv=countv+1
> when idx="W" then countw=countw+1
> otherwise countx=countx+1; end
>
> (Of course if that were a real example I would probably have found a way
> to use a stem variable instead:
>
> count.idx=count.idx+1
>
> But in this case I was just talking about coding style, as Mr Metz said.)
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* If a problem has a single neck, it has a simple solution. */
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lou Losee
> Sent: Sunday, June 7, 2020 14:38
>
> Would you rather code the select as a series of nested if-then-else?
>
> --- On Sun, Jun 7, 2020 at 1:35 PM Bob Bridges
> wrote:
> > The only language I can think of off-hand that doesn't require some sort
> > of END to close a DO (I'm sure there are others) is ISPF. But, in REXX
> at
> > least, I never use single-statement DOs. I see them all the time, and I
> > don't get it. Like this:
> >
> > if x=0 then do
> > x=x+1
> > end
> >
> > Or, more painfully:
> >
> > select
> > when idx="T" then
> > do
> > countt=countt+1
> > end
> > when idx="U" then
> > do
> > countu=countu+1
> > end
> > when idx="V" then
> > do
> > countv=countv+1
> > end
> > when idx="W" then
> > do
> > countw=countw+1
> > end
> > otherwise
> > do
> > countx=countx+1
> > end
> > end
> >
> > Why? If it were easier to read, I might sympathize. But it's harder,
> not
> > easier.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Paul Gilmartin
> > Sent: Saturday, June 6, 2020 14:40
> >
> > But in Rexx similarly, END is required even for a single-statement DO.
> > Good for Rexx. I like strong closure.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
Wayne V. Bickerdike
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
No, I wasn't complaining about the SELECT statement, only about using lots of DO/statement/ENDs when there's only a single statement. I would code the same thing like this: select when idx="T" then countt=countt+1 when idx="U" then countu=countu+1 when idx="V" then countv=countv+1 when idx="W" then countw=countw+1 otherwise countx=countx+1; end (Of course if that were a real example I would probably have found a way to use a stem variable instead: count.idx=count.idx+1 But in this case I was just talking about coding style, as Mr Metz said.) --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* If a problem has a single neck, it has a simple solution. */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lou Losee Sent: Sunday, June 7, 2020 14:38 Would you rather code the select as a series of nested if-then-else? --- On Sun, Jun 7, 2020 at 1:35 PM Bob Bridges wrote: > The only language I can think of off-hand that doesn't require some sort > of END to close a DO (I'm sure there are others) is ISPF. But, in REXX at > least, I never use single-statement DOs. I see them all the time, and I > don't get it. Like this: > > if x=0 then do > x=x+1 > end > > Or, more painfully: > > select > when idx="T" then > do > countt=countt+1 > end > when idx="U" then > do > countu=countu+1 > end > when idx="V" then > do > countv=countv+1 > end > when idx="W" then > do > countw=countw+1 > end > otherwise > do > countx=countx+1 > end > end > > Why? If it were easier to read, I might sympathize. But it's harder, not > easier. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Paul Gilmartin > Sent: Saturday, June 6, 2020 14:40 > > But in Rexx similarly, END is required even for a single-statement DO. > Good for Rexx. I like strong closure. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
Or DTL. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Steve Thompson [ste...@copper.net] Sent: Sunday, June 7, 2020 4:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL Question Don’t forget the SKELETON language. Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct mistaks > On Jun 7, 2020, at 4:30 PM, Seymour J Metz wrote: > > 1. ISPF is not a language.If you are referring to panel definition > statements, > ELSE uses indentation to control scope. Python does the same thing. I > don't like it, but it is what it is. > > 2. SO/END blocks containing only a single statement are useful if you > may be adding code in the future. It's a stylistic issue about which > you will never achieve consensus. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > Bob Bridges [robhbrid...@gmail.com] > Sent: Sunday, June 7, 2020 2:35 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: COBOL Question > > The only language I can think of off-hand that doesn't require some sort of > END to close a DO (I'm sure there are others) is ISPF. But, in REXX at > least, I never use single-statement DOs. I see them all the time, and I > don't get it. Like this: > > if x=0 then do >x=x+1 > end > > Or, more painfully: > > select >when idx="T" then > do >countt=countt+1 > end >when idx="U" then > do >countu=countu+1 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
Don’t forget the SKELETON language. Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct mistaks > On Jun 7, 2020, at 4:30 PM, Seymour J Metz wrote: > > 1. ISPF is not a language.If you are referring to panel definition > statements, > ELSE uses indentation to control scope. Python does the same thing. I > don't like it, but it is what it is. > > 2. SO/END blocks containing only a single statement are useful if you > may be adding code in the future. It's a stylistic issue about which > you will never achieve consensus. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > Bob Bridges [robhbrid...@gmail.com] > Sent: Sunday, June 7, 2020 2:35 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: COBOL Question > > The only language I can think of off-hand that doesn't require some sort of > END to close a DO (I'm sure there are others) is ISPF. But, in REXX at > least, I never use single-statement DOs. I see them all the time, and I > don't get it. Like this: > > if x=0 then do >x=x+1 > end > > Or, more painfully: > > select >when idx="T" then > do >countt=countt+1 > end >when idx="U" then > do >countu=countu+1 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Goto Statements (was: COBOL Question)
Well, if I were writing COBOL today I would eschew PERFORm foo THRU bar in favor of more structured constructs. You have a similar problem with assembler; code optimized for one model may run poorly on another. The NASPA magazine was Technical Support. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Clark Morris [cfmt...@uniserve.com] Sent: Sunday, June 7, 2020 2:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Goto Statements (was: COBOL Question) [Default] On 7 Jun 2020 03:33:44 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: >I generally get by with control structures like case (select/when), >if/elsif/when, iterate and leave, but I unashamedly use GOTO, when it is the >cleanest way to do something; I refuse to avoid a useful construct just >because it is not politically correct. In the case of COBOL, I consider the >out of line PERFORM to be far more dangerous. I have a similar issue with >REXX; it does not have lexical scope, and you can fall into a procedure. With any supported IBM COBOL, it can and should be written such that there are no fall throughs and without PERFORM ... THRU ... statements. By use of only PERFORM statements (without THRU) code movement is possible such that PERFORMED paragraphs can be moved inline which can be important in this era of cache and instruction look ahead. In order to maintain the ability for the compiler to do code optimizing I have coded PERFORMs of catastrophe paragraphs which have terminating STOP RUN, GOBACK or calls to an ABEND routine. Code which was optimal under OS/VS COBOL (1974 standard) became poor under VS COBOL 2.4 and later (1985 standard and later). As someone who coded programs ALTER xxx TO yyy instead of PERFORM to save 16 bytes in order to fit into a 16K DOS 360 background partition or 6K DOS 360 foreground partition, this represents a drastic change in philosophy. In the late 1980s I drastically rewrote a program to substantially reduce both CPU and run time in the late 1980s or early 1990s in the OS/VS COBOL available to me. ALL PERFORM xxx VARYING statements were eliminated and PERFORM xxx THRU xxx-EXIT statements were used where GO TO xxx and GO TO xxx-EXIT statements were used to do the iteration of the loop and the exiting of the loop. I submitted an article to the NAASPA magazine (the name escapes me at the moment) regarding all of the optimizations which was published. I did put in the caveat that the VS COBOL II compiler would make some of those optimizations counter-productive. Indeed to accomplish the same goal the rewrite would have had to have been substantially different for VS COBOL 2.4 and later. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
1. ISPF is not a language.If you are referring to panel definition statements, ELSE uses indentation to control scope. Python does the same thing. I don't like it, but it is what it is. 2. SO/END blocks containing only a single statement are useful if you may be adding code in the future. It's a stylistic issue about which you will never achieve consensus. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob Bridges [robhbrid...@gmail.com] Sent: Sunday, June 7, 2020 2:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL Question The only language I can think of off-hand that doesn't require some sort of END to close a DO (I'm sure there are others) is ISPF. But, in REXX at least, I never use single-statement DOs. I see them all the time, and I don't get it. Like this: if x=0 then do x=x+1 end Or, more painfully: select when idx="T" then do countt=countt+1 end when idx="U" then do countu=countu+1 end when idx="V" then do countv=countv+1 end when idx="W" then do countw=countw+1 end otherwise do countx=countx+1 end end Why? If it were easier to read, I might sympathize. But it's harder, not easier. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* It's a good thing Lincoln wrote the Gettysburg Address the year that he did, or else that "fourscore and seven years" part would have just been plain wrong. -Paul Paternoster */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Saturday, June 6, 2020 14:40 But in Rexx similarly, END is required even for a single-statement DO. Good for Rexx. I like strong closure. >--- On 6 Jun 2020 10:53:44 -0700, (Bob Bridges) wrote: >>Oh, you need an END-IF even for a single-statement IF? I forgot; I've been >>thinking in REXX too long. In that case you're close; I guess I really meant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
There's no XOR mentioned there, confused or otherwise. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Sunday, June 7, 2020 3:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL Question You could not be more correct. You wrote NOT and I translated that in my head to the exclamation point. (My C is showing.) And yes, absolutely, as you say, the problem is the merging of logical not and XOR operations. The link below says "NOT -- Called Logical NOT Operator. Used to reverse the logical state of its operand. If a condition is true, then Logical NOT operator will make false." But as you saw, that is not so. If foo is X'01' then NOT foo is X'FE' and both are true. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bob Bridges Sent: Sunday, June 7, 2020 11:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL Question You must have misread me somehow, Mr Mills; I didn't say there's a '!' operator in VBA. You spoke of a '!' operator in C, but I've never heard of that operator in VBA; all I meant is that maybe I should look in VBA for another Boolean operator that is different from NOT as you say '!' is different from '~' in C. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
You could not be more correct. You wrote NOT and I translated that in my head to the exclamation point. (My C is showing.) And yes, absolutely, as you say, the problem is the merging of logical not and XOR operations. The link below says "NOT -- Called Logical NOT Operator. Used to reverse the logical state of its operand. If a condition is true, then Logical NOT operator will make false." But as you saw, that is not so. If foo is X'01' then NOT foo is X'FE' and both are true. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bob Bridges Sent: Sunday, June 7, 2020 11:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL Question You must have misread me somehow, Mr Mills; I didn't say there's a '!' operator in VBA. You spoke of a '!' operator in C, but I've never heard of that operator in VBA; all I meant is that maybe I should look in VBA for another Boolean operator that is different from NOT as you say '!' is different from '~' in C. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
You must have misread me somehow, Mr Mills; I didn't say there's a '!' operator in VBA. You spoke of a '!' operator in C, but I've never heard of that operator in VBA; all I meant is that maybe I should look in VBA for another Boolean operator that is different from NOT as you say '!' is different from '~' in C. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* That sort of wit which employs itself insolently in criticizing and censuring the words and sentiments of others in conversation is absolute folly; for it answers none of the ends of conversation. He who uses it neither improves others, is improved himself, nor pleases anyone. -Poor Richard’s Almanack, 1756 */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Saturday, June 6, 2020 15:34 https://www.tutorialspoint.com/cprogramming/c_operators.htm for C operators I don't know VBA at all, only some VB. Are you sure about the ! operator being "complement"? https://bytecomb.com/the-bang-exclamation-operator-in-vba/ https://www.tutorialspoint.com/vba/vba_operators.htm -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bob Bridges Sent: Saturday, June 6, 2020 10:57 AM Really, a different operator? I didn't know; I bought a C compiler once, a couple decades ago, but then never used it. Now I'm wondering whether VBA has such a distinction and I simply assumed, and never looked for it. I don't think so, but I should remember to look. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Saturday, June 6, 2020 11:35 The problem would seem to me to stem from having the same operator for Boolean Not and for Bit Complement. Apparently VBA uses ! for both. I believe that in C or C++ if ( ! Result ) would evaluate as you expected: first Result would be evaluated as true or false, then that truth value would be logically inverted, and then that inversion evaluated as true or false. C has a separate operator for complement -- the tilde ~ -- and in C you would have to code if ( ~ Result ) to get the anomalous behavior you describe. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bob Bridges Sent: Friday, June 5, 2020 11:00 PM Reminds me of a situation I had some years ago while writing a VBA program that used a class (for FTP, I think) that had been written in some flavor of C. I was testing a supposedly Boolean return code and getting unexpected results. I tried several ways, and eventually proved to myself that the return code was both True and False. That is: Result = Function(Argument) If Result Then MsgBox "True" If Not Result Then MsgBox "False" ...displayed ~both~ messages. Maybe some of you already know what was happening here, but I had to examine the returned value in hex to catch on. VBA uses -1 ( b) for True and 0 ( b) for False, but evaluates 0 as False and any non-zero number as True. The Not operand uses two's complement to negate. But C, I gather, uses 0 for False and 1 for True. So in this case I was getting a 1 back from the function ( 0001b), which VBA evaluated as True - and when I said "Not Result", it negated 1 into -2 ( 1110b) and evaluated that as True also. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
Bob, Would you rather code the select as a series of nested if-then-else? Lou On Sun, Jun 7, 2020 at 1:35 PM Bob Bridges wrote: > The only language I can think of off-hand that doesn't require some sort > of END to close a DO (I'm sure there are others) is ISPF. But, in REXX at > least, I never use single-statement DOs. I see them all the time, and I > don't get it. Like this: > > if x=0 then do > x=x+1 > end > > Or, more painfully: > > select > when idx="T" then > do > countt=countt+1 > end > when idx="U" then > do > countu=countu+1 > end > when idx="V" then > do > countv=countv+1 > end > when idx="W" then > do > countw=countw+1 > end > otherwise > do > countx=countx+1 > end > end > > Why? If it were easier to read, I might sympathize. But it's harder, not > easier. > > --- > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > > /* It's a good thing Lincoln wrote the Gettysburg Address the year that he > did, or else that "fourscore and seven years" part would have just been > plain wrong. -Paul Paternoster */ > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Paul Gilmartin > Sent: Saturday, June 6, 2020 14:40 > > But in Rexx similarly, END is required even for a single-statement DO. > Good for Rexx. I like strong closure. > > >--- On 6 Jun 2020 10:53:44 -0700, (Bob Bridges) wrote: > >>Oh, you need an END-IF even for a single-statement IF? I forgot; I've > been thinking in REXX too long. In that case you're close; I guess I > really meant > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Please excuse spelling - sent from my mobile. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
The only language I can think of off-hand that doesn't require some sort of END to close a DO (I'm sure there are others) is ISPF. But, in REXX at least, I never use single-statement DOs. I see them all the time, and I don't get it. Like this: if x=0 then do x=x+1 end Or, more painfully: select when idx="T" then do countt=countt+1 end when idx="U" then do countu=countu+1 end when idx="V" then do countv=countv+1 end when idx="W" then do countw=countw+1 end otherwise do countx=countx+1 end end Why? If it were easier to read, I might sympathize. But it's harder, not easier. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* It's a good thing Lincoln wrote the Gettysburg Address the year that he did, or else that "fourscore and seven years" part would have just been plain wrong. -Paul Paternoster */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Saturday, June 6, 2020 14:40 But in Rexx similarly, END is required even for a single-statement DO. Good for Rexx. I like strong closure. >--- On 6 Jun 2020 10:53:44 -0700, (Bob Bridges) wrote: >>Oh, you need an END-IF even for a single-statement IF? I forgot; I've been >>thinking in REXX too long. In that case you're close; I guess I really meant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Goto Statements (was: COBOL Question)
[Default] On 7 Jun 2020 03:33:44 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: >I generally get by with control structures like case (select/when), >if/elsif/when, iterate and leave, but I unashamedly use GOTO, when it is the >cleanest way to do something; I refuse to avoid a useful construct just >because it is not politically correct. In the case of COBOL, I consider the >out of line PERFORM to be far more dangerous. I have a similar issue with >REXX; it does not have lexical scope, and you can fall into a procedure. With any supported IBM COBOL, it can and should be written such that there are no fall throughs and without PERFORM ... THRU ... statements. By use of only PERFORM statements (without THRU) code movement is possible such that PERFORMED paragraphs can be moved inline which can be important in this era of cache and instruction look ahead. In order to maintain the ability for the compiler to do code optimizing I have coded PERFORMs of catastrophe paragraphs which have terminating STOP RUN, GOBACK or calls to an ABEND routine. Code which was optimal under OS/VS COBOL (1974 standard) became poor under VS COBOL 2.4 and later (1985 standard and later). As someone who coded programs ALTER xxx TO yyy instead of PERFORM to save 16 bytes in order to fit into a 16K DOS 360 background partition or 6K DOS 360 foreground partition, this represents a drastic change in philosophy. In the late 1980s I drastically rewrote a program to substantially reduce both CPU and run time in the late 1980s or early 1990s in the OS/VS COBOL available to me. ALL PERFORM xxx VARYING statements were eliminated and PERFORM xxx THRU xxx-EXIT statements were used where GO TO xxx and GO TO xxx-EXIT statements were used to do the iteration of the loop and the exiting of the loop. I submitted an article to the NAASPA magazine (the name escapes me at the moment) regarding all of the optimizations which was published. I did put in the caveat that the VS COBOL II compiler would make some of those optimizations counter-productive. Indeed to accomplish the same goal the rewrite would have had to have been substantially different for VS COBOL 2.4 and later. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Goto Statements (was: COBOL Question)
Ah, but SIGNAL does clean up resources., Not always the appropriate resources, but resources. do i=1 to 100 foo SIGNAL bar baz bar: j=1 end That's part of "it does not have lexical scope," -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] Sent: Sunday, June 7, 2020 10:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Goto Statements (was: COBOL Question) On Sun, 7 Jun 2020 10:33:34 +, Seymour J Metz wrote: >I generally get by with control structures like case (select/when), >if/elsif/when, iterate and leave, but I unashamedly use GOTO, when it is the >cleanest way to do something; I refuse to avoid a useful construct just >because it is not politically correct. In the case of COBOL, > Alas, Rexx lacks GOTO and SIGNAL fails to clean up resources, largely a consequence of lacking lexical scope. >I consider the out of line PERFORM to be far more dangerous. I have a similar >issue with REXX; it does not have lexical scope, and you can fall into a >procedure. > A noteworthy 1976 paper (behind a paywall): Software malpractice — a distasteful experience† https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.4380060303 ... describes the pitfall set by a (too) clever programmer's relying on optimization by falling into procedures. † In the day, I read it free in the University library. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Goto Statements (was: COBOL Question)
On Sun, 7 Jun 2020 10:33:34 +, Seymour J Metz wrote: >I generally get by with control structures like case (select/when), >if/elsif/when, iterate and leave, but I unashamedly use GOTO, when it is the >cleanest way to do something; I refuse to avoid a useful construct just >because it is not politically correct. In the case of COBOL, > Alas, Rexx lacks GOTO and SIGNAL fails to clean up resources, largely a consequence of lacking lexical scope. >I consider the out of line PERFORM to be far more dangerous. I have a similar >issue with REXX; it does not have lexical scope, and you can fall into a >procedure. > A noteworthy 1976 paper (behind a paywall): Software malpractice — a distasteful experience† https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.4380060303 ... describes the pitfall set by a (too) clever programmer's relying on optimization by falling into procedures. † In the day, I read it free in the University library. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
If you really believe this nonsense then you have never programmed systems level code which requires cleanup of system resources such as locks. In 2020 we should not be having this conversation any more - it's bogus! Nobody emulates structured programming constructs such as loops using goto anymore. It's used to exit a routine and cleanup resources and younger programmers don't have the silly bias that seems to stick around here! On 2020-06-07 1:53 AM, Bob Bridges wrote: Oh, you need an END-IF even for a single-statement IF? I forgot; I've been thinking in REXX too long. In that case you're close; I guess I really meant PERFORM 1050-LOOP THRU 1050-EXIT VARYING JC FROM 1 BY 1 TO 99 1050-LOOP. IF X > 999 GOTO 1050-EXIT END-IF. IF FIRST-NAME = "ROBERT" GOTO 1050-EXIT END-IF. IF TYPE <> 195 GOTO 1050-EXIT END-IF. IF NOT SO-ON GOTO 1050-EXIT END-IF. IF NOT SO-FORTH GOTO 1050-EXIT END-IF. [do such and such] 1050-EXIT. I'm happy to hear someone else admit that a GOTO is conceivable under ~any~ circumstances. In my old shop I argued for GOTOs in three very strictly limited circumstances, the other two being end-of-section and end-of-program. Some languages allow for this by including some flavor of "leave" statement; all I want to do with a GOTO is to simulate that part of structured programming. But at the particular shop I have in mind, none of that could be contemplated, because all GOTOs are evil. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Law #21 of combat operations: The important things are always simple; the simple things are always hard. */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joe Monk Sent: Saturday, June 6, 2020 04:49 I think what you mean is this: PERFORM 1050-LOOP THRU 1059-EXIT VARYING JC FROM 1 BY 1 UNTIL JC = 99 END-PERFORM 1050-LOOP. IF FIRST-NAME NOT = "ROBERT" GO TO 1059-EXIT END-IF IF TYPE NOT = 195 GO TO 1059-EXIT END-IF IF NOT SO-ON GO TO 1059-EXIT END-IF IF NOT SO-FORTH GO TO 1059-EXIT END-IF PERFORM 1050-SUCH-AND-SUCH END-PERFORM 1059-EXIT. EXIT. In structured programming, it is perfectly acceptable to use GO TO within a paragraph. It is NOT acceptable to use GO TO outside of a paragraph. --- On Sat, Jun 6, 2020 at 12:42 AM Bob Bridges wrote: I realize this is a bit of a change in subject (and it's not as if we need yet another one), but I avoid this construction. My phobia is based on an extreme example: In their zeal never to use GOTOs, I've frequently seen programmers write paragraphs like this: PERFORM 1050-LOOP VARYING JC FROM 1 BY 1 TO 99 1050-LOOP. IF X < 1000 IF FIRST-NAME NOT = "ROBERT" IF TYPE = 195 IF SO-ON IF SO-FORTH EXECUTE 1050-SUCH-AND-SUCH END-IF END-IF END-IF END-IF END-IF Gives me a headache to try to evaluate that. Much better, in my opinion, to introduce ONE LOUSY "GOTO EO-PARAGRAPH" like this: PERFORM 1050-LOOP THRU 1059-LOOP VARYING JC FROM 1 BY 1 TO 99 1050-LOOP. IF X > 999 GOTO 1059-LOOP. IF FIRST-NAME = "ROBERT" GOTO 1059-LOOP. IF TYPE <> 195 GOTO 1059-LOOP. IF NOT SO-ON GOTO 1059-LOOP. IF NOT SO-FORTH GOTO 1059-LOOP. EXECUTE 1050-SUCH-AND-SUCH 1059-LOOP. Keep in mind I haven't programmed in COBOL since Y2K; I had to look up the syntax, I probably got part of it wrong nonetheless, and I'll bet there are easier ways to do it nowadays. In REXX, for example, they have the ITERATE statement: do jc=1 to 99 if x>99 then iterate if firstname='ROBERT' then iterate if type<>195 then iterate if \soon then iterate if \soforth then iterate call suchandsuch end However you do it, I vastly prefer skip-to-next-item over nested Ifs. But I confess that one single nested IF is not going to give me a headache; I just react when I see one. Not your fault :). -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave Sent: Friday, June 5, 2020 16:17 Using OP IF TVOLL (IND1) NOT = HIGH-VALUE AND SMOD (IND1) = 'B' OR 'R' I would do IF TVOLL (IND1) NOT = HIGH-VALUE IF SMOD (IND1) = 'B' OR 'R' Do the stuff -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
I've posted this before many times before! The conversation has got boring now - yawn! I would challenge anybody to refactor this code without goto's. https://github.com/eclipse/omr/blob/e9b85117d18c369108a9ddb790023103c35b4379/thread/common/omrthread.c#L246 On 2020-06-07 1:53 AM, Bob Bridges wrote: Oh, you need an END-IF even for a single-statement IF? I forgot; I've been thinking in REXX too long. In that case you're close; I guess I really meant PERFORM 1050-LOOP THRU 1050-EXIT VARYING JC FROM 1 BY 1 TO 99 1050-LOOP. IF X > 999 GOTO 1050-EXIT END-IF. IF FIRST-NAME = "ROBERT" GOTO 1050-EXIT END-IF. IF TYPE <> 195 GOTO 1050-EXIT END-IF. IF NOT SO-ON GOTO 1050-EXIT END-IF. IF NOT SO-FORTH GOTO 1050-EXIT END-IF. [do such and such] 1050-EXIT. I'm happy to hear someone else admit that a GOTO is conceivable under ~any~ circumstances. In my old shop I argued for GOTOs in three very strictly limited circumstances, the other two being end-of-section and end-of-program. Some languages allow for this by including some flavor of "leave" statement; all I want to do with a GOTO is to simulate that part of structured programming. But at the particular shop I have in mind, none of that could be contemplated, because all GOTOs are evil. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Law #21 of combat operations: The important things are always simple; the simple things are always hard. */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joe Monk Sent: Saturday, June 6, 2020 04:49 I think what you mean is this: PERFORM 1050-LOOP THRU 1059-EXIT VARYING JC FROM 1 BY 1 UNTIL JC = 99 END-PERFORM 1050-LOOP. IF FIRST-NAME NOT = "ROBERT" GO TO 1059-EXIT END-IF IF TYPE NOT = 195 GO TO 1059-EXIT END-IF IF NOT SO-ON GO TO 1059-EXIT END-IF IF NOT SO-FORTH GO TO 1059-EXIT END-IF PERFORM 1050-SUCH-AND-SUCH END-PERFORM 1059-EXIT. EXIT. In structured programming, it is perfectly acceptable to use GO TO within a paragraph. It is NOT acceptable to use GO TO outside of a paragraph. --- On Sat, Jun 6, 2020 at 12:42 AM Bob Bridges wrote: I realize this is a bit of a change in subject (and it's not as if we need yet another one), but I avoid this construction. My phobia is based on an extreme example: In their zeal never to use GOTOs, I've frequently seen programmers write paragraphs like this: PERFORM 1050-LOOP VARYING JC FROM 1 BY 1 TO 99 1050-LOOP. IF X < 1000 IF FIRST-NAME NOT = "ROBERT" IF TYPE = 195 IF SO-ON IF SO-FORTH EXECUTE 1050-SUCH-AND-SUCH END-IF END-IF END-IF END-IF END-IF Gives me a headache to try to evaluate that. Much better, in my opinion, to introduce ONE LOUSY "GOTO EO-PARAGRAPH" like this: PERFORM 1050-LOOP THRU 1059-LOOP VARYING JC FROM 1 BY 1 TO 99 1050-LOOP. IF X > 999 GOTO 1059-LOOP. IF FIRST-NAME = "ROBERT" GOTO 1059-LOOP. IF TYPE <> 195 GOTO 1059-LOOP. IF NOT SO-ON GOTO 1059-LOOP. IF NOT SO-FORTH GOTO 1059-LOOP. EXECUTE 1050-SUCH-AND-SUCH 1059-LOOP. Keep in mind I haven't programmed in COBOL since Y2K; I had to look up the syntax, I probably got part of it wrong nonetheless, and I'll bet there are easier ways to do it nowadays. In REXX, for example, they have the ITERATE statement: do jc=1 to 99 if x>99 then iterate if firstname='ROBERT' then iterate if type<>195 then iterate if \soon then iterate if \soforth then iterate call suchandsuch end However you do it, I vastly prefer skip-to-next-item over nested Ifs. But I confess that one single nested IF is not going to give me a headache; I just react when I see one. Not your fault :). -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave Sent: Friday, June 5, 2020 16:17 Using OP IF TVOLL (IND1) NOT = HIGH-VALUE AND SMOD (IND1) = 'B' OR 'R' I would do IF TVOLL (IND1) NOT = HIGH-VALUE IF SMOD (IND1) = 'B' OR 'R' Do the stuff -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Goto Statements (was: COBOL Question)
I generally get by with control structures like case (select/when), if/elsif/when, iterate and leave, but I unashamedly use GOTO, when it is the cleanest way to do something; I refuse to avoid a useful construct just because it is not politically correct. In the case of COBOL, I consider the out of line PERFORM to be far more dangerous. I have a similar issue with REXX; it does not have lexical scope, and you can fall into a procedure. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bernd Oppolzer [bernd.oppol...@t-online.de] Sent: Sunday, June 7, 2020 6:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Goto Statements (was: COBOL Question) Thank you very much for the link to that article; I did not know that before. When I started to work on the Stanford Pascal compiler in 2011, it had about 20 to 30 labels and Gotos (6000 lines of source code). http://secure-web.cisco.com/1pX2kW19qrUp9yyoP4cfhRRs2ehNXyOiR8ZzrLZPfjVUIuBM5B0cu5ExeRn-gVhTqtsFmQqRCeX1kWt8GVLJyqBetd-We06QY6gkbVWv3QC1o-NEVdaqRH6t2DH39gZvw0-3Jihs-F5wMJmmJUpgr5TRe-YayUTWUwX8Ei1zyTXm3YUVjbqPmkwLafqSKfBfd7dffvaXZkRLue6QQlmtfeaQ2d1GitnaBXNkNX9uaLzv2H5RvX0D-L61XkawFX-Eek9LsXAx0ycMXFpGNImgy5z9eMSon1P95x3V9wTqj1Pw6li8X2jwgFaZf1K_OkHNP4J_e51OIlCSPmnr61YIXw_-N0KKbOmQDuxiLobG46E7__kPTDeUP6oVHTPSdfvi8bQ6hhgm0MAe1y0jWiSnvezjXncFaNcNhThLUdm5bv1vkXAAvMM89ntcCkUAiNb44/http%3A%2F%2Fbernd-oppolzer.de%2Fjob9.htm In the meantime, I omitted most of them, but this was only possible, after I added CONTINUE and BREAK (for all three types of loops) and RETURN (to do early returns from procedures), which are not present in Standard Pascal. http://secure-web.cisco.com/1Km_bU1ZhlXrKXvTgabvFbHyaYXnzrcmk29Sl8AEjRAtYm4DFVcOJwHT6UIto3Tv4KffE0e3UQGWhHuGzdbAd-m2WCw4XJOZavBvuPWSV9525c1v_HDcAvHJIHIA6np8gqeDNP9bJFESQpyaSyQivd7HdNVnZTzfPKzWC2Bcv82b4oS_eTA6_H7fYXeBcHDP76oBOMOyB-kYDewa6mzanpF2bWJDRsXBYrQsW5qSE7Fk3sggZqGbEAYcJlLHNrF8IZSg3UmLFP_nCC5K9ftu_qXhfj-mM8dDUC52sS0YD1lON2dpIK7GgMzQ9WudkLKf-Z43IOBnRltKuxHzXUiTetyx7siAqIytTDFJ5C-29z1pojvBmeRIHtb0-K74gMS83Q9i2y7Sj7nPydr_ou22wlo62sHVFJ4yS9RU4NANqxMEEbsrJuWL_ZM1qQjZPEuRa/http%3A%2F%2Fbernd-oppolzer.de%2Fjob9i004.htm The compiler now has 22000 lines of code (much more function than the 2011 version), but much less gotos. Back to Cobol: IMO, many of the observations of the 1960s are still valid for today's modern COBOL: if you use (for example) inline PERFORM and all the possibilities to do structured programming in COBOL and try to reduce the use of Gotos to an absolute minimum (for example: leave the program in case of catastrophic errors), then your programs will be easier to read and maintain; at least that's what I am experiencing. BTW: I added so much function to the New Stanford Pascal compiler in the years since 2011 (and I ported it to Windows and Linux etc.), that I recently was able to use it to write a COBOL source code formatter using this compiler, which is very helpful when doing maintenance work on (large old) COBOL programs. I am thinking about enhancing this source code formatter (which does COBOL parsing to some degree) to get meta information out of the COBOL source code, for example file usage or to throw warnings about strange logic constructs - much the same way as my PL/1 tool from 2007 did it (this was written in C). If someone is interested, I will share the Pascal source of the COBOL source code formatter ... contact me offlline. But you will need the New Stanford Compiler to use it (available from GitHub and from the WebSite above). Kind regards Bernd Am 07.06.2020 um 02:26 schrieb Seymour J Metz: > https://secure-web.cisco.com/1Ly5ugowEV6ot4gbUyw07wld8pVo5RD7yYuLNdHEOf-3il63S7RNh5Uhz3z3qoKCTFZWHjCdAd9NWtRND2NeuvtUodK8xswKDI8qCbark0s6SJ5nXm7-R2ftSd_nYVROosKE8L-PHT1wEeBiCnX_EoOBsN2JcXxfXFq_MNEEfAfs5I_hk6jaQfOdPfRC6_TLwm_g1xb0iM3ICYM0c8XPwUqrA4rLqXyfU-rIz4Dp8LJp_b5--XwmHIh5kl8_oQTbAGn4lksD2k0ehk9-HzYrQGjendQbb39rTwPrLGGng14e9Sx46KhwhyhYMz-stXs2kjIore_VyCD4j1FFWmlNBTVSYtOHijv6gCOsLEv9maQADfq2W7D_-_-XYWu4mAPz3Wu3h15kosqbDyPRuDf-xcCtA_dJ3oB55h5QETpelVe2_CuvHD-y2_nREcy5rpp4t/https%3A%2F%2Fwww.cs.sjsu.edu%2F%7Emak%2FCS185C%2FKnuthStructuredProgrammingGoTo.pdf > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Goto Statements (was: COBOL Question)
Thank you very much for the link to that article; I did not know that before. When I started to work on the Stanford Pascal compiler in 2011, it had about 20 to 30 labels and Gotos (6000 lines of source code). http://bernd-oppolzer.de/job9.htm In the meantime, I omitted most of them, but this was only possible, after I added CONTINUE and BREAK (for all three types of loops) and RETURN (to do early returns from procedures), which are not present in Standard Pascal. http://bernd-oppolzer.de/job9i004.htm The compiler now has 22000 lines of code (much more function than the 2011 version), but much less gotos. Back to Cobol: IMO, many of the observations of the 1960s are still valid for today's modern COBOL: if you use (for example) inline PERFORM and all the possibilities to do structured programming in COBOL and try to reduce the use of Gotos to an absolute minimum (for example: leave the program in case of catastrophic errors), then your programs will be easier to read and maintain; at least that's what I am experiencing. BTW: I added so much function to the New Stanford Pascal compiler in the years since 2011 (and I ported it to Windows and Linux etc.), that I recently was able to use it to write a COBOL source code formatter using this compiler, which is very helpful when doing maintenance work on (large old) COBOL programs. I am thinking about enhancing this source code formatter (which does COBOL parsing to some degree) to get meta information out of the COBOL source code, for example file usage or to throw warnings about strange logic constructs - much the same way as my PL/1 tool from 2007 did it (this was written in C). If someone is interested, I will share the Pascal source of the COBOL source code formatter ... contact me offlline. But you will need the New Stanford Compiler to use it (available from GitHub and from the WebSite above). Kind regards Bernd Am 07.06.2020 um 02:26 schrieb Seymour J Metz: https://www.cs.sjsu.edu/~mak/CS185C/KnuthStructuredProgrammingGoTo.pdf -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
BIT(1) and BINARY are two different things in PL/I. The coercion of bit strings into FIXED BINARY looked good at the time, but I believe that it was a bad decision, as your example shows. OTOH, it's even worse to treat numerical or character data as boolean. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bernd Oppolzer [bernd.oppol...@t-online.de] Sent: Friday, June 5, 2020 7:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL Question This triggered me once more, sorry :-) I recall that we once did a larger project, checking all the PL/1 sources at a customer of mine, looking for errors in program logic, using a tool that I wrote (sort of a light weight, yet powerful, PL/1 parser). The parser threw errors (observations) on about ten percent of the source codes. One program had this coding: IF 9 < ZZ < 20 THEN DO; no error from the compiler, no warning :-) the condition turned out to be always true, because (9 < ZZ) < 20 the left part is evaluated and gives a binary result (BIT(1) in PL/1 speech); this is converted to decimal, and no matter what the value of ZZ is, the BIT(1) is always lower than 20 (be it '0'B or '1'B). This was of course not what the author intended; this was at an insurance company where most of the programmers had a math background, so this kind of expression was natural to them. The compiler didn't complain. Kind regards Bernd Am 05.06.2020 um 23:26 schrieb Paul Gilmartin: > On Fri, 5 Jun 2020 20:54:37 +, Seymour J Metz wrote: > >> SMOD (IND1) = 'B' OR 'R' means (SMOD (IND1) = 'B') OR (SMOD (IND1) = 'R'); >> syntax for implied comparands exists in other languages as well. >> > I have dealt with a language (Mainsail) that had a ternary compare: > A <= B < C > I don't know whether it avoided side effects of evaluating B twice. > It probably (I'm not sure) short-circuited to avoid evaluating C > needlessly. > > I like semi-open intervals, especially in loops. > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
https://www.cs.sjsu.edu/~mak/CS185C/KnuthStructuredProgrammingGoTo.pdf -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob Bridges [robhbrid...@gmail.com] Sent: Saturday, June 6, 2020 1:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL Question Oh, you need an END-IF even for a single-statement IF? I forgot; I've been thinking in REXX too long. In that case you're close; I guess I really meant PERFORM 1050-LOOP THRU 1050-EXIT VARYING JC FROM 1 BY 1 TO 99 1050-LOOP. IF X > 999 GOTO 1050-EXIT END-IF. IF FIRST-NAME = "ROBERT" GOTO 1050-EXIT END-IF. IF TYPE <> 195 GOTO 1050-EXIT END-IF. IF NOT SO-ON GOTO 1050-EXIT END-IF. IF NOT SO-FORTH GOTO 1050-EXIT END-IF. [do such and such] 1050-EXIT. I'm happy to hear someone else admit that a GOTO is conceivable under ~any~ circumstances. In my old shop I argued for GOTOs in three very strictly limited circumstances, the other two being end-of-section and end-of-program. Some languages allow for this by including some flavor of "leave" statement; all I want to do with a GOTO is to simulate that part of structured programming. But at the particular shop I have in mind, none of that could be contemplated, because all GOTOs are evil. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Law #21 of combat operations: The important things are always simple; the simple things are always hard. */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joe Monk Sent: Saturday, June 6, 2020 04:49 I think what you mean is this: PERFORM 1050-LOOP THRU 1059-EXIT VARYING JC FROM 1 BY 1 UNTIL JC = 99 END-PERFORM 1050-LOOP. IF FIRST-NAME NOT = "ROBERT" GO TO 1059-EXIT END-IF IF TYPE NOT = 195 GO TO 1059-EXIT END-IF IF NOT SO-ON GO TO 1059-EXIT END-IF IF NOT SO-FORTH GO TO 1059-EXIT END-IF PERFORM 1050-SUCH-AND-SUCH END-PERFORM 1059-EXIT. EXIT. In structured programming, it is perfectly acceptable to use GO TO within a paragraph. It is NOT acceptable to use GO TO outside of a paragraph. --- On Sat, Jun 6, 2020 at 12:42 AM Bob Bridges wrote: > I realize this is a bit of a change in subject (and it's not as if we need > yet another one), but I avoid this construction. My phobia is based on an > extreme example: In their zeal never to use GOTOs, I've frequently seen > programmers write paragraphs like this: > > PERFORM 1050-LOOP VARYING JC FROM 1 BY 1 TO 99 > > 1050-LOOP. > IF X < 1000 > IF FIRST-NAME NOT = "ROBERT" > IF TYPE = 195 > IF SO-ON > IF SO-FORTH > EXECUTE 1050-SUCH-AND-SUCH > END-IF > END-IF > END-IF > END-IF > END-IF > > Gives me a headache to try to evaluate that. Much better, in my opinion, > to introduce ONE LOUSY "GOTO EO-PARAGRAPH" like this: > > PERFORM 1050-LOOP THRU 1059-LOOP VARYING JC FROM 1 BY 1 TO 99 > > 1050-LOOP. > IF X > 999 GOTO 1059-LOOP. > IF FIRST-NAME = "ROBERT" GOTO 1059-LOOP. > IF TYPE <> 195 GOTO 1059-LOOP. > IF NOT SO-ON GOTO 1059-LOOP. > IF NOT SO-FORTH GOTO 1059-LOOP. > EXECUTE 1050-SUCH-AND-SUCH > 1059-LOOP. > > Keep in mind I haven't programmed in COBOL since Y2K; I had to look up the > syntax, I probably got part of it wrong nonetheless, and I'll bet there are > easier ways to do it nowadays. In REXX, for example, they have the ITERATE > statement: > > do jc=1 to 99 > if x>99 then iterate > if firstname='ROBERT' then iterate > if type<>195 then iterate > if \soon then iterate > if \soforth then iterate > call suchandsuch > end > > However you do it, I vastly prefer skip-to-next-item over nested Ifs. But > I confess that one single nested IF is not going to give me a headache; I > just react when I see one. Not your fault :). > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Gibney, Dave > Sent: Friday, June 5, 2020 16:17 > > Using OP > IF TVOLL (IND1) NOT = HIGH-VALUE > AND SMOD (IND1) = 'B' OR 'R' > > I would do > IF TVOLL (IND1) NOT = HIGH-VALUE > IF SMOD (IND1) = 'B' OR 'R' > Do the stuff -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
OTOH, REXX does not have an ENDIF, although SELECT does require an END. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] Sent: Saturday, June 6, 2020 2:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL Question On Sat, 6 Jun 2020 15:28:57 -0300, Clark Morris wrote: >On 6 Jun 2020 10:53:44 -0700, (Bob Bridges) wrote: > >>Oh, you need an END-IF even for a single-statement IF? I forgot; I've been >>thinking in REXX too long. In that case you're close; I guess I really meant > But in Rexx similarly, END is required even for a single-statement DO. Good for Rexx. I like strong closure. >In your example the END-IF is not needed. However beginning with VS >COBOL IIV4 (1985 standard) it became better practice to eliminate all >but the last period in a paragraph and terminate all conditional with >end statements such as END-IF. With Enterprise COBOL 5.2 and later >(2002 Standard) the 1050-EXIT paragraph could be eliminated and the GO >TOs replaced with EXIT PARAGRAPH. This allow simpler code generation >for the PERFORM and the PERFORMed paragraph be moved inline to in >effect replace the PERFORM statement. Also look up inline PERFORMs. >In general, because of code optimization starting with VS COBOL II >release 4 (1985 standard) GO TO became a bad idea. > Always a bad idea, or just usually? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
[Default] On 6 Jun 2020 12:43:09 -0700, in bit.listserv.ibm-main joemon...@gmail.com (Joe Monk) wrote: >Granted its been awhile since ive done application code, but if you >dont end-if they become a nested condition, which I dont think was the >original intent. A conditional statement in COBOL is terminated either by a period or an END-xx statement. The arithmetic statements become conditional if there is an "ON SIZE ERROR" clause so that there are END-ADD, END-SUBTRACT, END-COMPUTE, etc. statements. I-O statements such as READ and WRITE become conditional if there are "AT END", INVALID KEY" or similar statements so there are END-READ and END-WRITE statements. Clark Morris > >Joe > >On Sat, Jun 6, 2020 at 1:40 PM Paul Gilmartin < >000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > >> On Sat, 6 Jun 2020 15:28:57 -0300, Clark Morris wrote: >> >> >On 6 Jun 2020 10:53:44 -0700, (Bob Bridges) wrote: >> > >> >>Oh, you need an END-IF even for a single-statement IF? I forgot; I've >> been thinking in REXX too long. In that case you're close; I guess I >> really meant >> > >> But in Rexx similarly, END is required even for a single-statement DO. >> Good for Rexx. I like strong closure. >> >> >In your example the END-IF is not needed. However beginning with VS >> >COBOL IIV4 (1985 standard) it became better practice to eliminate all >> >but the last period in a paragraph and terminate all conditional with >> >end statements such as END-IF. With Enterprise COBOL 5.2 and later >> >(2002 Standard) the 1050-EXIT paragraph could be eliminated and the GO >> >TOs replaced with EXIT PARAGRAPH. This allow simpler code generation >> >for the PERFORM and the PERFORMed paragraph be moved inline to in >> >effect replace the PERFORM statement. Also look up inline PERFORMs. >> >In general, because of code optimization starting with VS COBOL II >> >release 4 (1985 standard) GO TO became a bad idea. >> > >> Always a bad idea, or just usually? >> >> -- gil >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
Granted its been awhile since ive done application code, but if you dont end-if they become a nested condition, which I dont think was the original intent. Joe On Sat, Jun 6, 2020 at 1:40 PM Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Sat, 6 Jun 2020 15:28:57 -0300, Clark Morris wrote: > > >On 6 Jun 2020 10:53:44 -0700, (Bob Bridges) wrote: > > > >>Oh, you need an END-IF even for a single-statement IF? I forgot; I've > been thinking in REXX too long. In that case you're close; I guess I > really meant > > > But in Rexx similarly, END is required even for a single-statement DO. > Good for Rexx. I like strong closure. > > >In your example the END-IF is not needed. However beginning with VS > >COBOL IIV4 (1985 standard) it became better practice to eliminate all > >but the last period in a paragraph and terminate all conditional with > >end statements such as END-IF. With Enterprise COBOL 5.2 and later > >(2002 Standard) the 1050-EXIT paragraph could be eliminated and the GO > >TOs replaced with EXIT PARAGRAPH. This allow simpler code generation > >for the PERFORM and the PERFORMed paragraph be moved inline to in > >effect replace the PERFORM statement. Also look up inline PERFORMs. > >In general, because of code optimization starting with VS COBOL II > >release 4 (1985 standard) GO TO became a bad idea. > > > Always a bad idea, or just usually? > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
https://www.tutorialspoint.com/cprogramming/c_operators.htm for C operators I don't know VBA at all, only some VB. Are you sure about the ! operator being "complement"? https://bytecomb.com/the-bang-exclamation-operator-in-vba/ https://www.tutorialspoint.com/vba/vba_operators.htm Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bob Bridges Sent: Saturday, June 6, 2020 10:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL Question Really, a different operator? I didn't know; I bought a C compiler once, a couple decades ago, but then never used it. Now I'm wondering whether VBA has such a distinction and I simply assumed, and never looked for it. I don't think so, but I should remember to look. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
On Sat, 6 Jun 2020 15:28:57 -0300, Clark Morris wrote: >On 6 Jun 2020 10:53:44 -0700, (Bob Bridges) wrote: > >>Oh, you need an END-IF even for a single-statement IF? I forgot; I've been >>thinking in REXX too long. In that case you're close; I guess I really meant > But in Rexx similarly, END is required even for a single-statement DO. Good for Rexx. I like strong closure. >In your example the END-IF is not needed. However beginning with VS >COBOL IIV4 (1985 standard) it became better practice to eliminate all >but the last period in a paragraph and terminate all conditional with >end statements such as END-IF. With Enterprise COBOL 5.2 and later >(2002 Standard) the 1050-EXIT paragraph could be eliminated and the GO >TOs replaced with EXIT PARAGRAPH. This allow simpler code generation >for the PERFORM and the PERFORMed paragraph be moved inline to in >effect replace the PERFORM statement. Also look up inline PERFORMs. >In general, because of code optimization starting with VS COBOL II >release 4 (1985 standard) GO TO became a bad idea. > Always a bad idea, or just usually? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
[Default] On 6 Jun 2020 10:53:44 -0700, in bit.listserv.ibm-main robhbrid...@gmail.com (Bob Bridges) wrote: >Oh, you need an END-IF even for a single-statement IF? I forgot; I've been >thinking in REXX too long. In that case you're close; I guess I really meant In your example the END-IF is not needed. However beginning with VS COBOL IIV4 (1985 standard) it became better practice to eliminate all but the last period in a paragraph and terminate all conditional with end statements such as END-IF. With Enterprise COBOL 5.2 and later (2002 Standard) the 1050-EXIT paragraph could be eliminated and the GO TOs replaced with EXIT PARAGRAPH. This allow simpler code generation for the PERFORM and the PERFORMed paragraph be moved inline to in effect replace the PERFORM statement. Also look up inline PERFORMs. In general, because of code optimization starting with VS COBOL II release 4 (1985 standard) GO TO became a bad idea. Clark Morris > > PERFORM 1050-LOOP THRU 1050-EXIT VARYING JC FROM 1 BY 1 TO 99 > > 1050-LOOP. > IF X > 999 GOTO 1050-EXIT END-IF. > IF FIRST-NAME = "ROBERT" GOTO 1050-EXIT END-IF. > IF TYPE <> 195 GOTO 1050-EXIT END-IF. > IF NOT SO-ON GOTO 1050-EXIT END-IF. > IF NOT SO-FORTH GOTO 1050-EXIT END-IF. > [do such and such] > 1050-EXIT. > >I'm happy to hear someone else admit that a GOTO is conceivable under ~any~ >circumstances. In my old shop I argued for GOTOs in three very strictly >limited circumstances, the other two being end-of-section and end-of-program. >Some languages allow for this by including some flavor of "leave" statement; >all I want to do with a GOTO is to simulate that part of structured >programming. But at the particular shop I have in mind, none of that could be >contemplated, because all GOTOs are evil. > >--- >Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > >/* Law #21 of combat operations: The important things are always simple; the >simple things are always hard. */ > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Joe Monk >Sent: Saturday, June 6, 2020 04:49 > >I think what you mean is this: > >PERFORM 1050-LOOP THRU 1059-EXIT VARYING JC FROM 1 BY 1 UNTIL JC = 99 >END-PERFORM > > 1050-LOOP. >IF FIRST-NAME NOT = "ROBERT" >GO TO 1059-EXIT >END-IF >IF TYPE NOT = 195 >GO TO 1059-EXIT >END-IF >IF NOT SO-ON >GO TO 1059-EXIT >END-IF >IF NOT SO-FORTH >GO TO 1059-EXIT >END-IF >PERFORM 1050-SUCH-AND-SUCH END-PERFORM > > 1059-EXIT. > EXIT. > >In structured programming, it is perfectly acceptable to use GO TO within a >paragraph. It is NOT acceptable to use GO TO outside of a paragraph. > >--- On Sat, Jun 6, 2020 at 12:42 AM Bob Bridges wrote: >> I realize this is a bit of a change in subject (and it's not as if we need >> yet another one), but I avoid this construction. My phobia is based on an >> extreme example: In their zeal never to use GOTOs, I've frequently seen >> programmers write paragraphs like this: >> >> PERFORM 1050-LOOP VARYING JC FROM 1 BY 1 TO 99 >> >> 1050-LOOP. >> IF X < 1000 >> IF FIRST-NAME NOT = "ROBERT" >> IF TYPE = 195 >> IF SO-ON >> IF SO-FORTH >> EXECUTE 1050-SUCH-AND-SUCH >> END-IF >> END-IF >> END-IF >> END-IF >> END-IF >> >> Gives me a headache to try to evaluate that. Much better, in my opinion, >> to introduce ONE LOUSY "GOTO EO-PARAGRAPH" like this: >> >> PERFORM 1050-LOOP THRU 1059-LOOP VARYING JC FROM 1 BY 1 TO 99 >> >> 1050-LOOP. >> IF X > 999 GOTO 1059-LOOP. >> IF FIRST-NAME = "ROBERT" GOTO 1059-LOOP. >> IF TYPE <> 195 GOTO 1059-LOOP. >> IF NOT SO-ON GOTO 1059-LOOP. >> IF NOT SO-FORTH GOTO 1059-LOOP. >> EXECUTE 1050-SUCH-AND-SUCH >> 1059-LOOP. >> >> Keep in mind I haven't programmed in COBOL since Y2K; I had to look up the >> syntax, I probably got part of it wrong nonetheless, and I'll bet there are >> easier ways to do it nowadays. In REXX, for example, they have the ITERATE >> statement: >> >> do jc=1 to 99 >> if x>99 then iterate >> if firstname='ROBERT' then iterate >> if type<>195 then iterate >> if \soon then iterate >> if \soforth then iterate >> call suchandsuch >> end >> >> However you do it, I vastly prefer skip-to-next-item over nested Ifs. But >> I confess that one single nested IF is not going to give me a headache; I >> just react when I see one. Not your fault :). >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of Gibney, Dave >> Sent: Friday, June 5, 2020 16:17 >> >> Using OP >> IF TVOLL (IND1) NOT = HIGH-VALUE >> AND SMOD (IND1) = 'B' OR 'R' >> >> I would do >> IF TVOLL (IND1) NOT = HIGH-VALUE >> IF SMOD (IND1) = 'B' OR 'R' >> Do the
Re: COBOL Question
Really, a different operator? I didn't know; I bought a C compiler once, a couple decades ago, but then never used it. Now I'm wondering whether VBA has such a distinction and I simply assumed, and never looked for it. I don't think so, but I should remember to look. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Good teaching is one-fourth preparation and three-fourths good theatre. -Gail Godwin */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Saturday, June 6, 2020 11:35 The problem would seem to me to stem from having the same operator for Boolean Not and for Bit Complement. Apparently VBA uses ! for both. I believe that in C or C++ if ( ! Result ) would evaluate as you expected: first Result would be evaluated as true or false, then that truth value would be logically inverted, and then that inversion evaluated as true or false. C has a separate operator for complement -- the tilde ~ -- and in C you would have to code if ( ~ Result ) to get the anomalous behavior you describe. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bob Bridges Sent: Friday, June 5, 2020 11:00 PM Reminds me of a situation I had some years ago while writing a VBA program that used a class (for FTP, I think) that had been written in some flavor of C. I was testing a supposedly Boolean return code and getting unexpected results. I tried several ways, and eventually proved to myself that the return code was both True and False. That is: Result = Function(Argument) If Result Then MsgBox "True" If Not Result Then MsgBox "False" ...displayed ~both~ messages. Maybe some of you already know what was happening here, but I had to examine the returned value in hex to catch on. VBA uses -1 ( b) for True and 0 ( b) for False, but evaluates 0 as False and any non-zero number as True. The Not operand uses two's complement to negate. But C, I gather, uses 0 for False and 1 for True. So in this case I was getting a 1 back from the function ( 0001b), which VBA evaluated as True - and when I said "Not Result", it negated 1 into -2 ( 1110b) and evaluated that as True also. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
Oh, you need an END-IF even for a single-statement IF? I forgot; I've been thinking in REXX too long. In that case you're close; I guess I really meant PERFORM 1050-LOOP THRU 1050-EXIT VARYING JC FROM 1 BY 1 TO 99 1050-LOOP. IF X > 999 GOTO 1050-EXIT END-IF. IF FIRST-NAME = "ROBERT" GOTO 1050-EXIT END-IF. IF TYPE <> 195 GOTO 1050-EXIT END-IF. IF NOT SO-ON GOTO 1050-EXIT END-IF. IF NOT SO-FORTH GOTO 1050-EXIT END-IF. [do such and such] 1050-EXIT. I'm happy to hear someone else admit that a GOTO is conceivable under ~any~ circumstances. In my old shop I argued for GOTOs in three very strictly limited circumstances, the other two being end-of-section and end-of-program. Some languages allow for this by including some flavor of "leave" statement; all I want to do with a GOTO is to simulate that part of structured programming. But at the particular shop I have in mind, none of that could be contemplated, because all GOTOs are evil. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Law #21 of combat operations: The important things are always simple; the simple things are always hard. */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joe Monk Sent: Saturday, June 6, 2020 04:49 I think what you mean is this: PERFORM 1050-LOOP THRU 1059-EXIT VARYING JC FROM 1 BY 1 UNTIL JC = 99 END-PERFORM 1050-LOOP. IF FIRST-NAME NOT = "ROBERT" GO TO 1059-EXIT END-IF IF TYPE NOT = 195 GO TO 1059-EXIT END-IF IF NOT SO-ON GO TO 1059-EXIT END-IF IF NOT SO-FORTH GO TO 1059-EXIT END-IF PERFORM 1050-SUCH-AND-SUCH END-PERFORM 1059-EXIT. EXIT. In structured programming, it is perfectly acceptable to use GO TO within a paragraph. It is NOT acceptable to use GO TO outside of a paragraph. --- On Sat, Jun 6, 2020 at 12:42 AM Bob Bridges wrote: > I realize this is a bit of a change in subject (and it's not as if we need > yet another one), but I avoid this construction. My phobia is based on an > extreme example: In their zeal never to use GOTOs, I've frequently seen > programmers write paragraphs like this: > > PERFORM 1050-LOOP VARYING JC FROM 1 BY 1 TO 99 > > 1050-LOOP. > IF X < 1000 > IF FIRST-NAME NOT = "ROBERT" > IF TYPE = 195 > IF SO-ON > IF SO-FORTH > EXECUTE 1050-SUCH-AND-SUCH > END-IF > END-IF > END-IF > END-IF > END-IF > > Gives me a headache to try to evaluate that. Much better, in my opinion, > to introduce ONE LOUSY "GOTO EO-PARAGRAPH" like this: > > PERFORM 1050-LOOP THRU 1059-LOOP VARYING JC FROM 1 BY 1 TO 99 > > 1050-LOOP. > IF X > 999 GOTO 1059-LOOP. > IF FIRST-NAME = "ROBERT" GOTO 1059-LOOP. > IF TYPE <> 195 GOTO 1059-LOOP. > IF NOT SO-ON GOTO 1059-LOOP. > IF NOT SO-FORTH GOTO 1059-LOOP. > EXECUTE 1050-SUCH-AND-SUCH > 1059-LOOP. > > Keep in mind I haven't programmed in COBOL since Y2K; I had to look up the > syntax, I probably got part of it wrong nonetheless, and I'll bet there are > easier ways to do it nowadays. In REXX, for example, they have the ITERATE > statement: > > do jc=1 to 99 > if x>99 then iterate > if firstname='ROBERT' then iterate > if type<>195 then iterate > if \soon then iterate > if \soforth then iterate > call suchandsuch > end > > However you do it, I vastly prefer skip-to-next-item over nested Ifs. But > I confess that one single nested IF is not going to give me a headache; I > just react when I see one. Not your fault :). > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Gibney, Dave > Sent: Friday, June 5, 2020 16:17 > > Using OP > IF TVOLL (IND1) NOT = HIGH-VALUE > AND SMOD (IND1) = 'B' OR 'R' > > I would do > IF TVOLL (IND1) NOT = HIGH-VALUE > IF SMOD (IND1) = 'B' OR 'R' > Do the stuff -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
The problem would seem to me to stem from having the same operator for Boolean Not and for Bit Complement. Apparently VBA uses ! for both. I believe that in C or C++ if ( ! Result ) would evaluate as you expected: first Result would be evaluated as true or false, then that truth value would be logically inverted, and then that inversion evaluated as true or false. C has a separate operator for complement -- the tilde ~ -- and in C you would have to code if ( ~ Result ) to get the anomalous behavior you describe. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bob Bridges Sent: Friday, June 5, 2020 11:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL Question Reminds me of a situation I had some years ago while writing a VBA program that used a class (for FTP, I think) that had been written in some flavor of C. I was testing a supposedly Boolean return code and getting unexpected results. I tried several ways, and eventually proved to myself that the return code was both True and False. That is: Result = Function(Argument) If Result Then MsgBox "True" If Not Result Then MsgBox "False" ...displayed ~both~ messages. Maybe some of you already know what was happening here, but I had to examine the returned value in hex to catch on. VBA uses -1 ( b) for True and 0 ( b) for False, but evaluates 0 as False and any non-zero number as True. The Not operand uses two's complement to negate. But C, I gather, uses 0 for False and 1 for True. So in this case I was getting a 1 back from the function ( 0001b), which VBA evaluated as True - and when I said "Not Result", it negated 1 into -2 ( 1110b) and evaluated that as True also. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
I think what you mean is this: PERFORM 1050-LOOP THRU 1059-EXIT VARYING JC FROM 1 BY 1 UNTIL JC = 99 END-PERFORM 1050-LOOP. IF FIRST-NAME NOT = "ROBERT" GO TO 1059-EXIT END-IF IF TYPE NOT = 195 GO TO 1059-EXIT END-IF IF NOT SO-ON GO TO 1059-EXIT END-IF IF NOT SO-FORTH GO TO 1059-EXIT END-IF PERFORM 1050-SUCH-AND-SUCH END-PERFORM 1059-EXIT. EXIT. In structured programming, it is perfectly acceptable to use GO TO within a paragraph. It is NOT acceptable to use GO TO outside of a paragraph. Joe On Sat, Jun 6, 2020 at 12:42 AM Bob Bridges wrote: > I realize this is a bit of a change in subject (and it's not as if we need > yet another one), but I avoid this construction. My phobia is based on an > extreme example: In their zeal never to use GOTOs, I've frequently seen > programmers write paragraphs like this: > > PERFORM 1050-LOOP VARYING JC FROM 1 BY 1 TO 99 > > 1050-LOOP. > IF X < 1000 > IF FIRST-NAME NOT = "ROBERT" > IF TYPE = 195 > IF SO-ON > IF SO-FORTH > EXECUTE 1050-SUCH-AND-SUCH > END-IF > END-IF > END-IF > END-IF > END-IF > > Gives me a headache to try to evaluate that. Much better, in my opinion, > to introduce ONE LOUSY "GOTO EO-PARAGRAPH" like this: > > PERFORM 1050-LOOP THRU 1059-LOOP VARYING JC FROM 1 BY 1 TO 99 > > 1050-LOOP. > IF X > 999 GOTO 1059-LOOP. > IF FIRST-NAME = "ROBERT" GOTO 1059-LOOP. > IF TYPE <> 195 GOTO 1059-LOOP. > IF NOT SO-ON GOTO 1059-LOOP. > IF NOT SO-FORTH GOTO 1059-LOOP. > EXECUTE 1050-SUCH-AND-SUCH > 1059-LOOP. > > Keep in mind I haven't programmed in COBOL since Y2K; I had to look up the > syntax, I probably got part of it wrong nonetheless, and I'll bet there are > easier ways to do it nowadays. In REXX, for example, they have the ITERATE > statement: > > do jc=1 to 99 > if x>99 then iterate > if firstname='ROBERT' then iterate > if type<>195 then iterate > if \soon then iterate > if \soforth then iterate > call suchandsuch > end > > However you do it, I vastly prefer skip-to-next-item over nested Ifs. But > I confess that one single nested IF is not going to give me a headache; I > just react when I see one. Not your fault :). > > --- > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > > /* In an emergency, a drawstring from a parka hood can be used to strangle > a snoring tent mate. -"Camping Tips" */ > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Gibney, Dave > Sent: Friday, June 5, 2020 16:17 > > Using OP > IF TVOLL (IND1) NOT = HIGH-VALUE > AND SMOD (IND1) = 'B' OR 'R' > > I would do > IF TVOLL (IND1) NOT = HIGH-VALUE > IF SMOD (IND1) = 'B' OR 'R' > Do the stuff > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
Reminds me of a situation I had some years ago while writing a VBA program that used a class (for FTP, I think) that had been written in some flavor of C. I was testing a supposedly Boolean return code and getting unexpected results. I tried several ways, and eventually proved to myself that the return code was both True and False. That is: Result = Function(Argument) If Result Then MsgBox "True" If Not Result Then MsgBox "False" ...displayed ~both~ messages. Maybe some of you already know what was happening here, but I had to examine the returned value in hex to catch on. VBA uses -1 ( b) for True and 0 ( b) for False, but evaluates 0 as False and any non-zero number as True. The Not operand uses two's complement to negate. But C, I gather, uses 0 for False and 1 for True. So in this case I was getting a 1 back from the function ( 0001b), which VBA evaluated as True - and when I said "Not Result", it negated 1 into -2 ( 1110b) and evaluated that as True also. Easy to write around once I understood what was going on, but it did confuse me for a while. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Every wise workman takes his tools away from the work from time to time that they may be ground and sharpened; so does the only-wise Jehovah take his ministers oftentimes away into darkness and loneliness and trouble, that he may sharpen and prepare them for harder work in his service. -Robert Murray M'Cheyne (1813-1843) */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bernd Oppolzer Sent: Friday, June 5, 2020 19:35 This triggered me once more, sorry :-) I recall that we once did a larger project, checking all the PL/1 sources at a customer of mine, looking for errors in program logic, using a tool that I wrote (sort of a light weight, yet powerful, PL/1 parser). The parser threw errors (observations) on about ten percent of the source codes. One program had this coding: IF 9 < ZZ < 20 THEN DO; no error from the compiler, no warning :-) the condition turned out to be always true, because (9 < ZZ) < 20 the left part is evaluated and gives a binary result (BIT(1) in PL/1 speech); this is converted to decimal, and no matter what the value of ZZ is, the BIT(1) is always lower than 20 (be it '0'B or '1'B). This was of course not what the author intended; this was at an insurance company where most of the programmers had a math background, so this kind of expression was natural to them. The compiler didn't complain. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
I realize this is a bit of a change in subject (and it's not as if we need yet another one), but I avoid this construction. My phobia is based on an extreme example: In their zeal never to use GOTOs, I've frequently seen programmers write paragraphs like this: PERFORM 1050-LOOP VARYING JC FROM 1 BY 1 TO 99 1050-LOOP. IF X < 1000 IF FIRST-NAME NOT = "ROBERT" IF TYPE = 195 IF SO-ON IF SO-FORTH EXECUTE 1050-SUCH-AND-SUCH END-IF END-IF END-IF END-IF END-IF Gives me a headache to try to evaluate that. Much better, in my opinion, to introduce ONE LOUSY "GOTO EO-PARAGRAPH" like this: PERFORM 1050-LOOP THRU 1059-LOOP VARYING JC FROM 1 BY 1 TO 99 1050-LOOP. IF X > 999 GOTO 1059-LOOP. IF FIRST-NAME = "ROBERT" GOTO 1059-LOOP. IF TYPE <> 195 GOTO 1059-LOOP. IF NOT SO-ON GOTO 1059-LOOP. IF NOT SO-FORTH GOTO 1059-LOOP. EXECUTE 1050-SUCH-AND-SUCH 1059-LOOP. Keep in mind I haven't programmed in COBOL since Y2K; I had to look up the syntax, I probably got part of it wrong nonetheless, and I'll bet there are easier ways to do it nowadays. In REXX, for example, they have the ITERATE statement: do jc=1 to 99 if x>99 then iterate if firstname='ROBERT' then iterate if type<>195 then iterate if \soon then iterate if \soforth then iterate call suchandsuch end However you do it, I vastly prefer skip-to-next-item over nested Ifs. But I confess that one single nested IF is not going to give me a headache; I just react when I see one. Not your fault :). --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* In an emergency, a drawstring from a parka hood can be used to strangle a snoring tent mate. -"Camping Tips" */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave Sent: Friday, June 5, 2020 16:17 Using OP IF TVOLL (IND1) NOT = HIGH-VALUE AND SMOD (IND1) = 'B' OR 'R' I would do IF TVOLL (IND1) NOT = HIGH-VALUE IF SMOD (IND1) = 'B' OR 'R' Do the stuff -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
This triggered me once more, sorry :-) I recall that we once did a larger project, checking all the PL/1 sources at a customer of mine, looking for errors in program logic, using a tool that I wrote (sort of a light weight, yet powerful, PL/1 parser). The parser threw errors (observations) on about ten percent of the source codes. One program had this coding: IF 9 < ZZ < 20 THEN DO; no error from the compiler, no warning :-) the condition turned out to be always true, because (9 < ZZ) < 20 the left part is evaluated and gives a binary result (BIT(1) in PL/1 speech); this is converted to decimal, and no matter what the value of ZZ is, the BIT(1) is always lower than 20 (be it '0'B or '1'B). This was of course not what the author intended; this was at an insurance company where most of the programmers had a math background, so this kind of expression was natural to them. The compiler didn't complain. Kind regards Bernd Am 05.06.2020 um 23:26 schrieb Paul Gilmartin: On Fri, 5 Jun 2020 20:54:37 +, Seymour J Metz wrote: SMOD (IND1) = 'B' OR 'R' means (SMOD (IND1) = 'B') OR (SMOD (IND1) = 'R'); syntax for implied comparands exists in other languages as well. I have dealt with a language (Mainsail) that had a ternary compare: A <= B < C I don't know whether it avoided side effects of evaluating B twice. It probably (I'm not sure) short-circuited to avoid evaluating C needlessly. I like semi-open intervals, especially in loops. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
Perl chained compares reevaluate terms: foo < rand() bar can give unexpected results. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] Sent: Friday, June 5, 2020 5:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL Question On Fri, 5 Jun 2020 20:54:37 +, Seymour J Metz wrote: >SMOD (IND1) = 'B' OR 'R' means (SMOD (IND1) = 'B') OR (SMOD (IND1) = 'R'); >syntax for implied comparands exists in other languages as well. > I have dealt with a language (Mainsail) that had a ternary compare: A <= B < C I don't know whether it avoided side effects of evaluating B twice. It probably (I'm not sure) short-circuited to avoid evaluating C needlessly. I like semi-open intervals, especially in loops. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
FYI, in COBOL: SMOD (IND1) = 'B' OR 'R' Evaluates as: SMOD (IND1) = 'B' OR SMOD (IND1) = 'R' The negative test requires AND instead of OR: SMOD (IND1) NOT = 'B' AND 'R' Evaluates to: SMOD (IND1) NOT = 'B' AND SMOD (IND1) NOT = 'R' Your last example has tripped up more than one novice COBOL coder and is obvious (to us) as a tautology, but not to the novices. I have seen this error multiple times in code reviews for less experienced coders. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Friday, June 5, 2020 4:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL Question EXTERNAL EMAIL On Fri, 5 Jun 2020 20:17:06 +, Gibney, Dave wrote: >Using OP > IF TVOLL (IND1) NOT = HIGH-VALUE > AND SMOD (IND1) = 'B' OR 'R' > >I would do > IF TVOLL (IND1) NOT = HIGH-VALUE > IF SMOD (IND1) = 'B' OR 'R' > Do the stuff > I have (almost) never coded COBOL, so I have trouble wrapping my head around: SMOD (IND1) = 'B' OR 'R' Does it mean: ( SMOD (IND1) = 'B' ) OR 'R' or SMOD (IND1) = ( 'B' OR 'R' ) or (implied Distributive Law): SMOD (IND1) = 'B' OR SMOD (IND1) = 'R' I'd have even more trouble with: SMOD (IND1) NOT = 'B' OR 'R' SMOD (IND1) NOT = 'B' OR SMOD (IND1) NOT = 'R' ... which seems to be a verbose expression for TRUE. I've seen programmers fall into that trap. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
On Fri, 5 Jun 2020 20:54:37 +, Seymour J Metz wrote: >SMOD (IND1) = 'B' OR 'R' means (SMOD (IND1) = 'B') OR (SMOD (IND1) = 'R'); >syntax for implied comparands exists in other languages as well. > I have dealt with a language (Mainsail) that had a ternary compare: A <= B < C I don't know whether it avoided side effects of evaluating B twice. It probably (I'm not sure) short-circuited to avoid evaluating C needlessly. I like semi-open intervals, especially in loops. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
+1 On 2020-06-05 16:47, Gibney, Dave wrote: The entire original confusion had to do with the fact that the 1st question involving HiGH-VALUE was not processed as expected because the AND took precedent over the OR. I don't remember exactly how COBOL does X = 'A' OR 'B', If NATURAL, this would be X = 'A' OR = 'B", The "OR =" is the operator required by the language syntax. Personally, if I was writing this in COBOL, I'd probably use the full, unambiguous SMOD (IND1) = 'B' OR SMOD (IND1) = 'R' -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Friday, June 05, 2020 1:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL Question On Fri, 5 Jun 2020 20:17:06 +, Gibney, Dave wrote: Using OP IF TVOLL (IND1) NOT = HIGH-VALUE AND SMOD (IND1) = 'B' OR 'R' I would do IF TVOLL (IND1) NOT = HIGH-VALUE IF SMOD (IND1) = 'B' OR 'R' Do the stuff I have (almost) never coded COBOL, so I have trouble wrapping my head around: SMOD (IND1) = 'B' OR 'R' Does it mean: ( SMOD (IND1) = 'B' ) OR 'R' or SMOD (IND1) = ( 'B' OR 'R' ) or (implied Distributive Law): SMOD (IND1) = 'B' OR SMOD (IND1) = 'R' I'd have even more trouble with: SMOD (IND1) NOT = 'B' OR 'R' SMOD (IND1) NOT = 'B' OR SMOD (IND1) NOT = 'R' ... which seems to be a verbose expression for TRUE. I've seen programmers fall into that trap. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
I agree with Dave G. avoid negative logic I would do (not cobol syntax but shows the questions better, I think) IF SMOD (IND1) = 'B' OR 'R' THEN DO IF TVOLL (IND1) = HIGH-VALUE then DO xxx ELSE DO yyy On Fri, Jun 5, 2020 at 4:47 PM Gibney, Dave wrote: > The entire original confusion had to do with the fact that the 1st > question involving HiGH-VALUE was not processed as expected because the AND > took precedent over the OR. > > I don't remember exactly how COBOL does X = 'A' OR 'B', If NATURAL, this > would be X = 'A' OR = 'B", The "OR =" is the operator required by the > language syntax. > > Personally, if I was writing this in COBOL, I'd probably use the full, > unambiguous SMOD (IND1) = 'B' OR SMOD (IND1) = 'R' > > >-Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Paul Gilmartin > > Sent: Friday, June 05, 2020 1:33 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: COBOL Question > > > > On Fri, 5 Jun 2020 20:17:06 +, Gibney, Dave wrote: > > > > >Using OP > > > IF TVOLL (IND1) NOT = HIGH-VALUE > > > AND SMOD (IND1) = 'B' OR 'R' > > > > > >I would do > > > IF TVOLL (IND1) NOT = HIGH-VALUE > > > IF SMOD (IND1) = 'B' OR 'R' > > > Do the stuff > > > > > I have (almost) never coded COBOL, so I have trouble wrapping my head > > around: > > SMOD (IND1) = 'B' OR 'R' > > > > Does it mean: > > ( SMOD (IND1) = 'B' ) OR 'R' or > > SMOD (IND1) = ( 'B' OR 'R' ) or (implied Distributive Law): > > SMOD (IND1) = 'B' OR SMOD (IND1) = 'R' > > > > I'd have even more trouble with: > > SMOD (IND1) NOT = 'B' OR 'R' > > SMOD (IND1) NOT = 'B' OR SMOD (IND1) NOT = 'R' > > > > ... which seems to be a verbose expression for TRUE. I've seen > programmers > > fall into that trap. > > > > -- gil > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to > > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
SMOD (IND1) = 'B' OR 'R' means (SMOD (IND1) = 'B') OR (SMOD (IND1) = 'R'); syntax for implied comparands exists in other languages as well. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] Sent: Friday, June 5, 2020 4:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL Question On Fri, 5 Jun 2020 20:17:06 +, Gibney, Dave wrote: >Using OP > IF TVOLL (IND1) NOT = HIGH-VALUE > AND SMOD (IND1) = 'B' OR 'R' > >I would do > IF TVOLL (IND1) NOT = HIGH-VALUE > IF SMOD (IND1) = 'B' OR 'R' > Do the stuff > I have (almost) never coded COBOL, so I have trouble wrapping my head around: SMOD (IND1) = 'B' OR 'R' Does it mean: ( SMOD (IND1) = 'B' ) OR 'R' or SMOD (IND1) = ( 'B' OR 'R' ) or (implied Distributive Law): SMOD (IND1) = 'B' OR SMOD (IND1) = 'R' I'd have even more trouble with: SMOD (IND1) NOT = 'B' OR 'R' SMOD (IND1) NOT = 'B' OR SMOD (IND1) NOT = 'R' ... which seems to be a verbose expression for TRUE. I've seen programmers fall into that trap. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
The entire original confusion had to do with the fact that the 1st question involving HiGH-VALUE was not processed as expected because the AND took precedent over the OR. I don't remember exactly how COBOL does X = 'A' OR 'B', If NATURAL, this would be X = 'A' OR = 'B", The "OR =" is the operator required by the language syntax. Personally, if I was writing this in COBOL, I'd probably use the full, unambiguous SMOD (IND1) = 'B' OR SMOD (IND1) = 'R' >-Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Paul Gilmartin > Sent: Friday, June 05, 2020 1:33 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: COBOL Question > > On Fri, 5 Jun 2020 20:17:06 +, Gibney, Dave wrote: > > >Using OP > > IF TVOLL (IND1) NOT = HIGH-VALUE > > AND SMOD (IND1) = 'B' OR 'R' > > > >I would do > > IF TVOLL (IND1) NOT = HIGH-VALUE > > IF SMOD (IND1) = 'B' OR 'R' > > Do the stuff > > > I have (almost) never coded COBOL, so I have trouble wrapping my head > around: > SMOD (IND1) = 'B' OR 'R' > > Does it mean: > ( SMOD (IND1) = 'B' ) OR 'R' or > SMOD (IND1) = ( 'B' OR 'R' ) or (implied Distributive Law): > SMOD (IND1) = 'B' OR SMOD (IND1) = 'R' > > I'd have even more trouble with: > SMOD (IND1) NOT = 'B' OR 'R' > SMOD (IND1) NOT = 'B' OR SMOD (IND1) NOT = 'R' > > ... which seems to be a verbose expression for TRUE. I've seen programmers > fall into that trap. > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
On Fri, 5 Jun 2020 20:17:06 +, Gibney, Dave wrote: >Using OP > IF TVOLL (IND1) NOT = HIGH-VALUE > AND SMOD (IND1) = 'B' OR 'R' > >I would do > IF TVOLL (IND1) NOT = HIGH-VALUE > IF SMOD (IND1) = 'B' OR 'R' > Do the stuff > I have (almost) never coded COBOL, so I have trouble wrapping my head around: SMOD (IND1) = 'B' OR 'R' Does it mean: ( SMOD (IND1) = 'B' ) OR 'R' or SMOD (IND1) = ( 'B' OR 'R' ) or (implied Distributive Law): SMOD (IND1) = 'B' OR SMOD (IND1) = 'R' I'd have even more trouble with: SMOD (IND1) NOT = 'B' OR 'R' SMOD (IND1) NOT = 'B' OR SMOD (IND1) NOT = 'R' ... which seems to be a verbose expression for TRUE. I've seen programmers fall into that trap. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
Using OP IF TVOLL (IND1) NOT = HIGH-VALUE AND SMOD (IND1) = 'B' OR 'R' I would do IF TVOLL (IND1) NOT = HIGH-VALUE IF SMOD (IND1) = 'B' OR 'R' Do the stuff > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Paul Gilmartin > Sent: Friday, June 05, 2020 1:12 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: COBOL Question > > On Fri, 5 Jun 2020 19:56:06 +, Gibney, Dave wrote: > > >Also, it's often better to nest than to make compound conditions. > > > Do you mean not expanding the Distributive Law? E.g. you prefer: > A and ( B or C ) > to: > A and B or A and C? > > Do we need to talk about short-circuit evaluation? > > >> -Original Message- > >> From: Charles Mills > >> Sent: Friday, June 05, 2020 12:54 PM > >> > >> I long ago decided never to bother looking up or thinking about > >> operator precedence. If I am not immediately certain straight out of > >> the box then I use parentheses. > >> > Me, too. And I've been thwarted by a BASIC interpreter (Data General) and > a Pascal compiler (Lightspeed) which incrementally compiled to internal > pseudo-code (RPN?) and decompiled for listing (Infix) with bare minimum > parentheses. And frustrated my attempts to align decimal points vertically. > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
Many moons ago when I wrote COBOL for a living I used the hell out of 88 Levels. Its makes for really pretty code but it is hell to debug sometimes like compound Condition. 1 or 2 items it an 88 is easy, 40 or 50 is not, same with compound conditions -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave Sent: Friday, June 5, 2020 2:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL Question Also, it's often better to nest than to make compound conditions. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Charles Mills > Sent: Friday, June 05, 2020 12:54 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: COBOL Question > > I long ago decided never to bother looking up or thinking about operator > precedence. If I am not immediately certain straight out of the box then I use > parentheses. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Bernd Oppolzer > Sent: Friday, June 5, 2020 12:23 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: COBOL Question > > I hope you don't mind if I comment once again; > > my original coding was: > > IF TVOLL (IND1) NOT = HIGH-VALUE > AND SMOD (IND1) = 'B' OR 'R' > > and as I learned now from your helpful posts, this is expanded to > > IF TVOLL (IND1) NOT = HIGH-VALUE > AND SMOD (IND1) = 'B' OR SMOD (IND1) = 'R' > > (which would have alarmed me, if I had seen it in this variant, BTW) and then, > because of operator precedence, evaluated as > > IF (TVOLL (IND1) NOT = HIGH-VALUE > AND SMOD (IND1) = 'B') > OR SMOD (IND1) = 'R' > > so that in my case (SMOD ... being 'R') the condition evaluated to true, which > was not what I had expected. > > This is a little bit counter intuitive IMHO, because the abbreviation 'B' OR > 'R' > suggests that the list of values both rely to the right condition (only) and > so I > thought the evaluation would be > > IF TVOLL (IND1) NOT = HIGH-VALUE > AND (SMOD (IND1) = 'B' OR 'R') > > I expected somehow an implicit paranthese because of the abbreviation ... > > What I would take as a conclusion (for me) from this experience: > it is best to use parantheses, especially if there is a combination of AND and > OR ... and when using abbreviations. > > Thanks again, kind regards > have a nice weekend > > Bernd > > > > Am 05.06.2020 um 20:48 schrieb Bob Bridges: > > Seems to me that ~is~ operator precedence: We evaluate AND before OR, > just as we evaluate * before +. But that's closely related to the > distributive > rule, right? > > > > P and Q or R > > R or P and Q > > > > ...both evaluate the same way, to "(P and Q) or R". The distributive > > property says that > > > > P and (Q or R) > > > > ...evaluates to > > > > (P and Q) or (P and R) > > > > I'm just as rusty in COBOL as Mr Oppolzer, so I didn't know you could > > say > > > > IF VAR = 'B' OR 'R' > > > > But if you can, it must mean "IF VAR = 'B' OR VAR = 'R'". > > > > --- > > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > > > > /* No one would talk much in society if he knew how often he > > misunderstands others. -Goethe */ > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
