Re: Converting assembler to COBOL help

2022-07-10 Thread Mitch Mccluhan
 Hello,
There is a vendor BP that does this sort of thing with an automated tool.
Mitch

  
 
 
 
-Original Message-
From: W Mainframe <01304632a58d-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Sat, Jul 9, 2022 9:23 am
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?

-- 
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: Converting assembler to COBOL help

2022-07-10 Thread Seymour J Metz
Run some hairy test cases and evaluate the outputs for, e.g., completeness, 
effort for manual recodeing of anything not automatically converted, 
efficiency, readability, maintainability. It's a lot harder to do it well than 
to just do it. Using a program that only translates 75% of a module might 
require more manpower than translating the whole thing manually.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tom 
Ross [tmr...@stlvm20.vnet.ibm.com]
Sent: Friday, July 8, 2022 6:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Converting assembler to COBOL help

Greetings mainframers!

This has porobbaly been asked and answered, but are there tools or companies
that can convert or help to rewrite assembler applications or just programs
into COBOL?  Any suggestions?


Cheers,
TomR  >> COBOL is the Language of the Future! <<
AKA:  Captain COBOL, Tom Ross

--
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: Converting assembler to COBOL help

2022-07-10 Thread Seymour J Metz
Automatic conversion of assembler code has been around for decades. And, yes, 
it is a bear for complicated architectures and a lot of work even for simple 
machines. BTDT,GTA.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Farley, Peter x23353 [031df298a9da-dmarc-requ...@listserv.ua.edu]
Sent: Saturday, July 9, 2022 2:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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

--
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

2022-07-09 Thread Farley, Peter x23353
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

2022-07-09 Thread Farley, Peter x23353
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

2022-07-09 Thread Paul Gilmartin
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

2022-07-09 Thread Farley, Peter x23353
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

2022-07-09 Thread W Mainframe
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: Converting assembler to COBOL help

2022-07-08 Thread Paul Gilmartin
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


Re: Converting assembler to COBOL help

2022-07-08 Thread Farley, Peter x23353
Tom,

I don't know who the vendor actually was (it wasn't done in my application 
area), but a few years ago we tried one of them who had an automated tool of 
some kind to do that conversion, and the resulting COBOL code that I was asked 
to peer-review was unreadable and unmaintainable.  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.

That project was canceled, and now we do it (when actually needed) in the 
old-fashioned way - by hand, by a senior programmer experienced in both 
languages.   Usually only when something breaks and management needs the 
business logic preserved in a more "supportable" form.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Ross
Sent: Friday, July 8, 2022 6:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Converting assembler to COBOL help

Greetings mainframers!

This has porobbaly been asked and answered, but are there tools or companies 
that can convert or help to rewrite assembler applications or just programs 
into COBOL?  Any suggestions?


Cheers,
TomR  >> COBOL is the Language of the Future! <<
AKA:  Captain COBOL, Tom Ross
--

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

2022-07-08 Thread Joe Monk
Why in the heck would you want to do that?

Joe

On Fri, Jul 8, 2022 at 5:32 PM Tom Ross  wrote:

> Greetings mainframers!
>
> This has porobbaly been asked and answered, but are there tools or
> companies
> that can convert or help to rewrite assembler applications or just programs
> into COBOL?  Any suggestions?
>
>
> Cheers,
> TomR  >> COBOL is the Language of the Future! <<
> AKA:  Captain COBOL, Tom Ross
>
> --
> 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


Converting assembler to COBOL help

2022-07-08 Thread Tom Ross
Greetings mainframers!

This has porobbaly been asked and answered, but are there tools or companies
that can convert or help to rewrite assembler applications or just programs
into COBOL?  Any suggestions?


Cheers,
TomR  >> COBOL is the Language of the Future! <<
AKA:  Captain COBOL, Tom Ross

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN