COBOL、JCL、PL1、アセンブラたちをC#に移行したい

https://news.mynavi.jp/techplus/article/20211203-2211817/
そういやAWS自体がCOBOL、PL1、JCLに対応するようになったので
機械生成の読めるかどうかも怪しいC#コードを錬成するぐらいならそのままAWSに移せないか検討したほうがいい気しますね...
内部でJavaに変換しているみたいですが

assemblyはCPUアーキテクチャもわからない以上回答できる人はいらっしゃらない気がします。

今後の保守を考えるとやはりC#で探したいのです。
ちなみにスクラッチで作り直すのは予算が降りないのでできません。（頭バグってる上位層が認めてくれない…）

作り直し出来ないなら、わざわざ開発言語切り替える意味は無いと思いますけどね…
元々保守困難なCOBOLのコードだった場合、仮にツールで機械的にC#に変換した所で、保守出来るようになるかは疑問です。結局は、元のコードの機能を理解する必要はあるんじゃないでしょうか。
変換ツールが存在するVB6からVB.NETのレガシーシステムの移行ですら、変換後にそれなりに手直しは必要でしたし、複雑怪奇なコードのプログラムのいくつかは、作り直しを行いました。

"COBOL C#"でググるとそれっぽい有償のソリューションはいくつか出てくるようですが、それらをとりあえず比較検討してみて、どうするか決めたらいいんじゃないでしょうか。

IBM が　z/VM　を発表し、２０年の歳月が過ぎ、クラウド移行が本格的に行われる時代なんだなと感じています。今はz/Linuxでしょうか？

C#ですか？これは他の方に期待しましょう。

私ならメインフレームの周辺機器をunix対応機器に切り替えすると共にアセンブラを撲滅することから始めるでしょう。
　又、AWSではなく、北海道、関東、沖縄の３地点のプライベートクラウドで実装します。（メインフレームの保守費と比べて回線費は安いとおもいます。AWSの方が安いか！）

1. ＪＣＬ　　　： Ansible（rubyでCOBOL, PL/1をinclude実行)
2. COBOL　　　：rubyでCOBOLにメタプログラミング（無修正実行）
3. PL1　　　　: rubyでPL/1にメタプログラミング（無修正実行）
4. アセンブラ　：Cで周辺機器メーカへ依頼

でしょうか？

ＪＣＬだけでもスクラッチで作り直すことをお勧めします。異なるデバイスの割り当てが問題になるかも？

尚、メインフレームはJCL単位で順次処理が基本で、オンライン処理であっても、JCLで資源を割り当てしVMに常駐するものです。
自立型の分散並列運用システムの時代に
メインフレーム運用管理、運用監視は大変でしょう！

　
素直に　MSPか？NCOSか？知りませんが
メーカのVMを採用しながら段階的に移行して下さい。