Talk:OS/360 Object File Format

Computing Stub‑class

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology 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.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
Stub	This article has been rated as Stub-class on Wikipedia's content assessment scale.
???	This article has not yet received a rating on the project's importance scale.

Excuse Me?

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

relocation

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]

List of weaknesses

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.

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.

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]