Re: [EXTERNAL] FedEx to move entirely to the cloud
My last three clients. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Gentlemen, when the enemy is committed to a mistake we must not interrupt him too soon. -Admiral Horatio Nelson */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Ed Jaffe Sent: Friday, July 8, 2022 18:38 Can't tell you how many folks I've met in the 11th year of their company's 3-year conversion off the mainframe... --- On 7/8/2022 2:53 PM, Dave Barry wrote: > No surprise. FedEx announce years ago that they were getting off the > mainframe "next year." -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Converting assembler to COBOL help
Apologies, you are probably correct. Bad habits acquired dealing with management who don’t like that method. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Saturday, July 9, 2022 2:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Converting assembler to COBOL help On Sat, 9 Jul 2022 18:10:54 +, Farley, Peter x23353 wrote: >Answers in the order of your questions: > Wouldn't it be more legible to interleave your answers rather than "in the order of ..."? -- 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: Converting assembler to COBOL help
That's a reasonable suggestion. Many pitfalls to watch out for (like the branch gates example I gave earlier), but like you said, possibly 75% coverage for the code portion. System macro conversion could be a big headache too, but at least feasible to try. Trickier could be conversion of the DSECT and non-reentrant variable storage area definitions. I would expect much of that to need careful human review and manual adjustment. Unlike HLL's, assembler allows many hardware-specific "tricks" that make automated analysis, like classical compiler construction to generate "parse trees" and "directed graphs" and such, much more difficult. It may be possible to do, but the work involved to create and validate such a beast would be massive. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of W Mainframe Sent: Saturday, July 9, 2022 10:23 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Converting assembler to COBOL help Hi,A suggestion... I did similar thing some years ago using z390 Macro Language. In summary you can create macros and replace used macros by Cobol statements.The macros just punch Cobol statements to an output.I converted about 250 critical Cobol code.Main question... Is it 100%, of course not... But I would say 75%. RegardsDan Sent from Yahoo Mail for iPhone On Friday, July 8, 2022, 8:53 PM, Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote: On Fri, 8 Jul 2022 22:51:38 +, Farley, Peter x23353 wrote: > > ... The business logic was totally scrambled, sometimes by "old-timer" >tricks like non-reentrant branch gates and other such no-no's under current >maintainability and pipeline-flush avoidance rules, other times just by >flagrantly awful spaghetti code even a human would struggle to understand. > Was that merely faithfully replicating deficiencies in the input? What architecture level? What might it do with such as RISBG? -- 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: Converting assembler to COBOL help
On Sat, 9 Jul 2022 18:10:54 +, Farley, Peter x23353 wrote: >Answers in the order of your questions: > Wouldn't it be more legible to interleave your answers rather than "in the order of ..."? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Converting assembler to COBOL help
Answers in the order of your questions: In most cases, yes, but the COBOL implementation chosen was MUCH worse than the original, far less readable or maintainable, and in many cases unnecessarily more complicated. The converted assembler code was decades old, all pre-2000, so ESA at best, and most probably at XA level or earlier. Nothing of the "newer" instruction sets (FSVO "new") was present in any of the converted assembler source that I was asked to review. In all the cases that I reviewed, the code being converted could have run on the earliest 370 hardware and in some cases on 360 hardware. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Friday, July 8, 2022 7:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Converting assembler to COBOL help On Fri, 8 Jul 2022 22:51:38 +, Farley, Peter x23353 wrote: > >... The business logic was totally scrambled, sometimes by "old-timer" > tricks like non-reentrant branch gates and other such no-no's under current > maintainability and pipeline-flush avoidance rules, other times just by > flagrantly awful spaghetti code even a human would struggle to understand. > Was that merely faithfully replicating deficiencies in the input? What architecture level? What might it do with such as RISBG? -- 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: Converting assembler to COBOL help
Hi,A suggestion... I did similar thing some years ago using z390 Macro Language. In summary you can create macros and replace used macros by Cobol statements.The macros just punch Cobol statements to an output.I converted about 250 critical Cobol code.Main question... Is it 100%, of course not... But I would say 75%. RegardsDan Sent from Yahoo Mail for iPhone On Friday, July 8, 2022, 8:53 PM, Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote: On Fri, 8 Jul 2022 22:51:38 +, Farley, Peter x23353 wrote: > > ... The business logic was totally scrambled, sometimes by "old-timer" >tricks like non-reentrant branch gates and other such no-no's under current >maintainability and pipeline-flush avoidance rules, other times just by >flagrantly awful spaghetti code even a human would struggle to understand. > Was that merely faithfully replicating deficiencies in the input? What architecture level? What might it do with such as RISBG? -- 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: How do I issue a command with a blank in it
The modify command with quotes gives it as typed on the console ( including the quotes) Without quotes it is upper cased Colin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] FedEx to move entirely to the cloud
AND, wait for the first time there's an Asure outage, or a breech (remember "the cloud" does not take responsibility for this). You basically do it at your own risk. Which data-center manager is Fedex going to blame then? Good luck to them. Seem it numerous times! On Sat, Jul 9, 2022, 07:19 Bobbie Justice < 0013e2d84072-dmarc-requ...@listserv.ua.edu> wrote: > Year 15 of the 3 year plan to move off the mainframe. > > Seems like I've heard that before. > > Oh yes, it will save us "x" amount of dollars. > > Of course we're going to spend 45 times the projected savings to get > there, but that comes out of a different budget item so it's okay. > > -- > 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: [EXTERNAL] FedEx to move entirely to the cloud
Year 15 of the 3 year plan to move off the mainframe. Seems like I've heard that before. Oh yes, it will save us "x" amount of dollars. Of course we're going to spend 45 times the projected savings to get there, but that comes out of a different budget item so it's okay. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How do I issue a command with a blank in it?
On Sat, 9 Jul 2022 12:58:35 +, Peter Relson wrote: > >... If you want my guess (without trying to figure out if true or not), >support for single quotation marks came later, was done by someone who didn't >know about the 4th positional parameter who didn't notice in the doc update >that there were two cases that this doc update applies to (even though the >code update covered only one). > "didn't know ... though the code update covered only one" sounds like a case for an RFE to fix the omission of the 4th parameter. A responsible design would have employed a reusable lexical analyzer so a code update would have applied to all parameters alike. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How do I issue a command with a blank in it?
Charles M wrote As does MODIFY, which I think of as very analogous to START, since the data ends up in more or less the same place. In implementation, MODIFY is nothing like START (because of what parsing is done by the system of the command itself). Each individual modify "owner" parses according to whatever rules they have chosen (and, one hopes, documented). The system's parsing responsibility largely ends after determining the "name". The system passes whatever you typed (possibly morphed to upper-case). I'm not sure just when the upper-casing is done (it might even be done before anything even attempts to analyze what the command is). Charles M wrote parameters Program parameters passed to the started program. This might be a list in parentheses or a string in single quotation marks. That is the part I'm referring to (it is under "Starting a system task from a console"). It is incorrect for the 4th positional parameter. It is correct for PARM= . We will update to make that clear. If you want my guess (without trying to figure out if true or not), support for single quotation marks came later, was done by someone who didn't know about the 4th positional parameter who didn't notice in the doc update that there were two cases that this doc update applies to (even though the code update covered only one). Bill G wrote On this page of the z/OS MVS System Commands manual, under "operands" it says "no embedded blanks". It refers to commands in general, not just the "start" command. This shows the danger of an incomplete reference without necessary context. This is within a section "Typical format" and that section starts with "Most system commands". Yes, this is indeed the typical format. It is not the only format. It might be close to correct to think of this as the default format, or to think of it as "this, unless the specific command documents otherwise". There are commands which happily accept embedded blanks (typically, those do not require separation of parameters by a comma) and for which comments are delimited by /*...*/. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
