Talk:OS/360 Object File Format

This article is rated Start-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Software: Computing Low‑importance This article is within the scope of WikiProject Software, a collaborative effort to improve the coverage of software on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.SoftwareWikipedia:WikiProject SoftwareTemplate:WikiProject Softwaresoftware Low This article has been rated as Low-importance on the project's importance scale. This article is supported by WikiProject Computing (assessed as Low-importance).

How is this EVEN a stub!?, it should be Somewhere higher than that. --StaleGuy22 (talk) 21:05, 1 July 2020 (UTC)Reply

While the common use of the format is for relocatable object programs meant for the linker or loader, assemblers also have the ability to generate absolute addresses. An origin can be given, and addresses will start there. One place where this is used is in the IPL code. Another is for stand-alone programs run without any OS help. Gah4 (talk) 22:10, 1 July 2020 (UTC)Reply

Here are my thoughts on the “weaknesses” mentioned in the article. Many of them seem to be strawmen, given that this is an object language and not an HLL.

• alignment cannot be specified.

What does this mean? CSECTs are always aligned. Stuff within CSECTs can be aligned if desired.

• a reentrant module (as opposed to one merely read-only) cannot be specified.

True, but the link editor allows RENT

• cannot distinguish between a subroutine (a routine that handles data only through arguments) vs. a function (a routine that returns data through a return value).

This seems outside the scope of an object language.

• address constants can't be identified as pointers (such as for access to a data structure) as opposed to, say, access to a table (that is not changed) or to a virtual method in a dynamic record.

I’ll leave this to others to comment, but I can’t see that anyone cares about this.

OK, VAX allows modules to be marked read-only and loaded into pages write protected. (Helped by the 512 byte page size.) Gah4 (talk) 08:00, 27 October 2022 (UTC)Reply

• no means to allow procedures or functions to check or validate argument types or validate external structures.

This seems to be outside the scope of an object language. There are conventions that can do this if needed.

• no means to declare an object, where part of the structure is data and part is code (methods that operates upon the data of the object).

This can easily be done. Any module consisting of code and data might be an object.

OK, external symbols can't distinguish between code and data. There are fun examples where Fortran programs call data in a COMMON block. Gah4 (talk) 08:00, 27 October 2022 (UTC)Reply

I think that if we’re talking about weaknesses we need to compare apples and apples. I’m familiar with a bunch of object languages and it seems (from my limited knowledge) that, except tor long names, IBM object code does just about everything that the others do. Peter Flass (talk) 03:31, 27 October 2022 (UTC)Reply

Even more, functions and subroutines look exactly like initialized data (named COMMON) at the object program level. There are some fun tricks in Fortran based on that. Gah4 (talk) 21:41, 12 May 2025 (UTC)Reply

Note that the VM/CMS filetype for object programs and object libraries are TEXT and TXTLIB. Also, note that Filename uses TEXT as an example, but not what most people call a text file. And object program lines have the TXT code in columns 2-4. Gah4 (talk) 21:44, 12 May 2025 (UTC)Reply