[fpc-devel] Re: EBCDIC (was On a port of Free Pascal to the IBM 370)

[steve smithers]

> rvmartin2 at ntlworld.com wrote on Thu, 2 Feb 2012 16:28:29 +0000 (GMT)
> I had nearly 40 years of mainframe development (OS/360 through MVS and
> VM/SP) and it is not a comfortable environment for developing code.
>
> My productivity went up about 200% when I got a PC as a host terminal.
> I coded using my favourite PC editor then uploaded the source to the
> mainframe using MYTE or similar then ran it through the appropriate compiler.
>
> For pascal programs I wrote portable code, compiling and debugging with
> Virtual Pascal, then uploaded and ran it through the VSPascal compiler.

Same here, but things got better.  But to some extent, that's looking back
through rose-tinted spectacles.  We managed with the resources we had at
the time.  However, I am not suggesting we go back to overnight compilations
on punched card.

> If I was still developing pascal code for 370 etc I would like to write
> and test it on the PC - Free Pascal would be great - then change a
> parameter for FP to generate 370 assembler source to upload and compile.
> It wouldn't matter whether that output was ascii or ebcdic as it could be
> converted on the upload, but I would probably prefer ascii so that I could
> check and possibly tweak it before upload.

"Write once, compile anywhere" isn't that the motto?  I'm not trying to suggest
anything to break this model, but when I compile my code on the mainframe, I
would expect stuff like if ch in['A'..'Z'] to be EBCDIC based.

> Mark Morgan Lloyd <markMLl.fpc-devel at telemetry.co.uk wrote on Thu, 02 Feb 2012 17:27:51 +0000
>
> I'd only expect the version control system to contain textfiles. Or are 
> you saying that some IBM operating systems support files which contain 
> both text and data (I'm aware of the Mac's OS and obviously OS/2 doing 
> this, both of which FPC supports).

I wasn't really talking about source files.  I was talking about I/O in
general.  Translating a text file on the fly is possible, assuming you 
can identify it as such.  But what about a structured file that contains 
mixed binary and string info.  Integers need to converted from little to 
big endian, strings from ASCII to EBCDIC, floating point from PC to mainframe 
formats, files may contain internal pointers to other info, again it needs
to be converted.  Doing all this automagically in the RTL isn't an exercise
in coding it's clairvoyance.  And yes, MVS supports mixed binary and string
data in a file, doesn't every operating system?  A file is just data, stuff, 
the operating system has no business telling me what I can put in my files!

> Just trust me then. PC doctrine has it that anybody can write a 
> compiler, but we're aware of the fact that other architectures might do 
> things differently.

Anyone can write whatever they want on the mainframe too.  All the tools
required are provided.  What you do with it has nothing to do with architecture,
it's to do with security.  If you were a user on a Linux system, one amongst
50 others, one without root access, you would find yourself constrained about
what you and your compiler could do.  At least I hope you would.  It's the same
on OS.  If you are running hercules and MVS, just for yourself on your desktop,
you can do what you want.  If you work for NatWest, you would find you wouldn't
have the same freedoms.

> No, but having an accessible operating system for testing is, and it 
> would end up being extremely inconvenient if that operating system 
> didn't support standard networking so that- at the very least- test code 
> code could be got onto it and copies of error messages got off. I don't 
> think the other developers would be happy if told they had to use 
> (something equivalent to) Kermit :-)

Hercules provides terminal access to a TCP/IP client, both in 3270 terminal
mode and for file transfer.  As far as I know Kermit is not available