Hacker News new | comments | show | ask | jobs | submit login

If you run into anyone still doing scaping, you might suggest Microfocus COBOL. It's a lot less painful to recompile for x86 and .NET than it is to deal with terminal scraping.



But that only solves the COBOL aspect. There's are many cases in which assembly, FORTRAN and who-knows-what-else is involved.

Terminal scraping is "universal" (it is language agnostic; it's much easier to get a system emulator working perfectly than multiple compilers/language environments).


FORTRAN isn't scary. C was designed to be compatible with FORTRAN so it just works in most situations. Most people don't realize that if you declare variables non-extern without a value in different compilation units, they actually have "common" linkage to be compatible with FORTRAN "common" memory.

  a.c: int a;
  $ cc -c -o a.o a.c; nm a.o
  0000000000000004 C _a <-- "common"

  a.c: int a = 1;
  $ cc -c -o a.o a.c; nm a.o
  0000000100001040 D _a
  
FORTRAN functions can be called from and call into C or C++ (extern "C"'d) without any issue. Simplified example:

  foo.f:SUBROUTINE FOO
  foo.f:CHARACTER*80 LINE
  foo.f:INTEGER*4 NUM
  foo.f:CALL BAR(LINE, NUM)
  foo.f:END
  bar.c:void bar_(const char *line, int *num, int len) {
  bar.c:    /* implicit length for string arguments, values as pointers */
  bar.c:}

  foo.f:SUBROUTINE FOO
  foo.f:END
  bar.c:extern void foo_(void);
  bar.c:void bar(void) { foo_(); }


Fortran isn't scary, but porting a system from one architecture to another, when that system includes Fortran, Assembly, Cobol and other parts IS scary, which makes emulation (and terminal scraping) a robust solution, and recompilation/porting an expensive one.

[And Fortran does have scary aspects: from the 25 year old hacker's test: "Did you ever change the value of 4? In a language other than Fortran?" - numeric literals in fortran aren't constant!]


I haven't seen many cross-platform issues with FORTRAN. (If you redefine 4 on any platform, it will be bad.) IMO, C is much more time consuming to port to a different platform due to system headers and inevitably different system APIs. POSIX helps, but certain parts of the system aren't covered by POSIX and so you wind up with #ifdef platform support where new support needs to be added.


> I haven't seen many cross-platform issues with FORTRAN.

Most fortran floating around is cross-platform fortran, and that is quite easy to port. However, legacy systems are usually very much platform dependent. I was once hired to port something in Fortran from a System 3090 (or was it 390? That would be more than 20 years ago now) to an SGI workstation, and it took several weeks of full time work.

And you're ignoring the subject under discussion: Porting a working system comprised of multiple parts in multiple languages (COBOL, Fortran, ASM, REXX, ....) is a much harder than the sum of porting individual programs - which is why emulation + terminal scraping is the cheaper, more robust solution.


One problem is that cobol is not that standard many uses proprietary extensions for cics and xml and all sorts of stuff that may not be available on the microfocus platform.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: