I haven't got that far in my notes yet but...  Cross-compilation - yes. Building a 370 binary on Linux or Windows - Well you can if you want but... Transfer binary to a 370 machine - Whew.  This is problematic.

It's not any problem to move the binary itself, but there is more required than the binary itself in order to produce an executable load module on any OS version.  (I can't comment on VM or DOS cause they are a mystery to me). An OS binary consists of more than the binary and I know of no way to build that information on Linux or Windows.

I would very strongly suggest cross-compile fpc on Linux/Windows using a version that emits, not gas assembler but 370 assembler.  I will be talking about gas vs 370 assembler later.  The assembler output can be in ASCII or EBCDIC as rvmartin said it's just a character encoding.  The advantage is that you only need to upload a text file(s).  Feed it into the OS assembler and link programs and you have a 370 load module.

2) The sources of the compiler and RTL are transferred to the 370.  I assume that after the file transfer, the sources are still in ASCII format ?

It depends on the options you use on your file transfer program, but I would convert to EBCDIC here.

3) At that point the compiler can try to recompile itself on the 370  machine.

Yes.

Once a initial port to 370 has been made and the assembler output generator is implemented (which means that the compiler can basically generate 370 capable assembler files) this is rather easy as FPC can generate "link on target" scripts (and AFAIK also "assemble on target").

Not at the first step. As long as FPC is not able to understand EBCDIC there is no sense in converting the source to EBCDIC.

Regards,
Sven

That's not the case when the target is Linux: as with all distreaux and variants, the program compiles to a single file:

0 1> pascal-xsc hello.p
environment file /usr/local/p-xsc/sys/p88.env found. Compiling hello.p with PASCAL-XSC version T3.62 dated 07.12.05 (C) Copyright University of Karlsruhe 1991-1999
(C) Copyright University of Wuppertal 2000-2005
importing module /usr/local/p-xsc/sys/stdmod.mod
FILE: hello.o
Analysis complete
Code generation complete
0 1> ls -lt
total 108
-rwxr-xr-x 1 markMLl markMLl 100118 Jan 30 18:17 hello -rw-r--r-- 1 markMLl markMLl 68 Jan 30 18:16 hello.p 0 1> ./hello
Hello, World!

That's on a system which describes itself as

0 1> cat /proc/cpuinfo
vendor_id : IBM/S390
# processors : 2
bogomips per cpu: 629.00
features : esan3 stfle msa ldisp eimm dfp
processor 0: version = 00, identification = 000069, machine = 9672 processor 1: version = 00, identification = 100069, machine = 9672

However I am aware that various mainframe OSes- not limited to IBM- insist on "blessing" executables before they can be run.

We look forward to your notes. My understanding is that at least one variant of FPC (the one targeting x86) can use multiple assembler notations, so the exact format of the assembly source might turn out not to be a problem. More of a problem would be is 370 Assembler conventions turned out to be incompatible with FPC code generation.

Assuming that the target operating system has any concept of an executable script. Steve's already told us that you can't generate a binary externally, and it might turn out that the compiler will have to generate a JCL (or comparable) deck which is then processed in some way on the target rather than being executed directly.

The link script does not need to be executable by itself. In the end it would be sufficient to just include the commands in it that are needed to assemble and link the final application and then execute these by hand (in the worst case...).

Regards,
Sven

Yes, I'm just trying to think ahead. In my mainframe days job control was either done with 80 column cards or using a KSR-33 :-)