Talk:Transaction Processing Facility

Core?

The reference to "core" as a synonym for "main memory" is very (thirty years?) out-of-date. Should not all references to "core" or "core memory" be changed to "main memory" (or perhaps some other more modern term)?

Charlesm20 (talk) 19:14, 5 March 2009 (UTC)[reply]

Done. 73.127.147.187 (talk) 07:52, 8 February 2021 (UTC)[reply]

NPOV?

This page could probably do with a little minor NPOV editing. Seconded, reads like an IBM press release —Preceding unsigned comment added by 77.103.163.11 (talk) 17:51, 16 June 2009 (UTC)[reply]

—The preceding unsigned comment was added by 80.111.233.163 (talk • contribs) .

go ahead and edit to improve the article. that's what wikipedia is about. --stmrlbs|talk 17:53, 16 June 2009 (UTC)[reply]

Compare and contrast with other OSes

It would be helpful if someone could compare and contrast this to other operating systems. In particular, does TPF have the concept of processes/threads, file system, security, etc.

—The preceding unsigned comment was added by Tkrotchko (talk • contribs) .

I'm very far from a TPF expert, but it's my understanding that TPF is (was?) not really thought of as a complete operating system but more as a very fast collection of subroutines (dare we say 'system services?) that a few very-carefuly specialised, extremely high throughput programs could use. If my understanding is correct, I think you'll find TPF is missing a lot of the very things you'd want to compare.

Hopefully, someone who really knows will come by and correct me where I'm wrong.

Atlant 20:18, 1 March 2006 (UTC)[reply]

I think you're right, however, with IBM's introduction of zTPF and their push towards posix compliance, there must be some correlation. I think I probably need to do more research myself at IBM. This page looks promising: IBM TPF V4R1 General Information

--Tkrotchko 21:53, 2 March 2006 (UTC)[reply]

What do you think of as a complete operating system? TPF, to achieve the all-important goal of speed, controls all it's own hardware and interfaces and provides the environment for the TPF application to run on. As there are specialised functions to perform a lot of these (all?) of these operations, it has not possible to port any other code to TPF systems. This is changing with ISO C and the move to posix compliance, but even then I doubt it will be worth porting any other software to TPF without making major changes to it to fit in with the way TPF 'does things'.

- :HTH. - :--Jacquesmesmer 21:05, 22 May 2006 (UTC)[reply]

What do you think of as a complete operating system?

If you were asking me, I'd say that some of the things that TPF didn't have that most modern OS's do have would probably be:

Support for a very wide range of mass storage (more than just DASD)
Support for a wide range of terminals, protocols, and UI paradigms (not just 3270s and CICS)
Support for a wide range of networking protocols, both proprietary and industry-standard, not just SNA
Support for a wide range of program types, not just TP-oriented stuff
Flexible, fully automatic memory, processor, and disk storage allocation

(And again, I'm no TPF expert, so if I got wrong any exclusions above, please correct me! I may be wildly wrong here, but I thought that at least at some point in time, TPF couldn't even back-up its databases; you shut down TPF and brought up another OS to do that work.)

Atlant 22:42, 22 May 2006 (UTC)[reply]

Well, it is a limited operating system, in that it only supports what's required for its users. I'm no systems expert either, but to clarify/correct some of your assumptions:

Support for DASD is based on S/390 based DASD and offload to tape. TPF shops use DASD for speed and reliability. If they wanted to use something else they would write interfaces to it or get IBM to do the same. There is no demand to use anything else.
TCP/IP and MATIP terminal handling has been supported for a number of years, although I believe it's still just 3270 emulation over them. Again there is no requirement from the users of the systems to move to anything more specialised. At best raw data is offloaded to a GUI, otherwise line input is the standard usage. It may be specialised, but it's quite quick when you have a queue of people waiting to check in.
TCP/IP (offload and native stack), MATIP, AX25, X25, SLC, ALC are commonly supported.
TPF systems are only used as transaction processing systems, so there is no requirement to do batch work on them. As a result, a TPF system must have an MVS system working with it to perform batch activities.
It's probably ignorance, but I don't understand what you mean by fully automatic memory, processor and disk storage allocation. Every operating system (or the BIOS that underlies it) has to be told what hardware components are available to it. As I understand it, some use software to achieve this (PnP). TPF does not.

(I've worked in TPF for 16 years now. Long before my time there was backup and restore. In fact, long before the existence of the PC there was backup and restore, so this is just scurrilous!). (One caution I would make about assessing TPF - it is a niche product. It only does what its users want it to do. At the moment what they want is speed and reliability for transaction processing).

--Jacquesmesmer 10:05, 31 July 2006 (UTC)[reply]

Locking

you should consider adding VFA locking in this section. Paul Austin 17:32, 5 April 2006 (UTC)[reply]

Move to "Transaction Processing Facility"?

TPF is already ambiguous. I've studied policy and I'm not sure on this, but I believe that the "spirit of the law" would be for this page to be moved to Transaction Processing Facility, as the abbreviation is common, but not so common that people are forgetting its roots (like "radar"). Thoughts? toresbe 03:44, 15 July 2006 (UTC)[reply]

Speaking just for myself, I wouldn't argue if this article got moved to Transaction Processing Facility and the TPF (disambiguation) page were placed at TPF.

Atlant 13:03, 17 July 2006 (UTC)[reply]

Done. —Cliffb 02:39, 25 August 2006 (UTC)[reply]

C

"However, C language programming is much easier to obtain skilled people in, so most if not all new development is done in C"

I'm not sure this is really true. Many shops are Assembler only or Assembler-principally.

At present. But how long do the people working there have to go until retirement?

I'm not being facetious. I'm currently on a week's course in mainframe fundamentals because I'm 25 and IBM is concerned at the possibility of, to be blunt, everyone who knows about mainframes dying off. I'm finding it fascinating, but I'm not reasonably about to start hacking away in zSeries assembler. With C and some practice and guidance, I might be able to start poking around the edges of things.

Of course, I'm not going to, since "agile" and Java is really where I want to go :-) But I never turn down the opportunity to learn about something outside my experience. 62.56.52.163 20:57, 7 June 2007 (UTC)[reply]

Also the implication that a generic C-language programmer can be put on a TPF project and be quicky productive is not correct.

That I certainly agree with. 62.56.52.163 20:57, 7 June 2007 (UTC)[reply]

As a commentary note, COBOL vs. C vs. Assembler coders being easy to find is perceptive (not a neutral statement). Some installations that use C will find it harder to find C language developers since the academic world has moved onward to Java and Objective-C. Many places, including venerable IBM, are training a new generation of coders for legacy tools on mainframe tech. —Preceding unsigned comment added by 68.242.7.200 (talk) 09:12, 23 February 2008 (UTC)[reply]

Restructure of articles about IBM mainframe operating systems

After a big edit of MVS I concluded that the whole set of articles about IBM mainframe operating systems from System/360 onwards needed to be re-structured to minimise overlap and to make clearer the evolutionary relationships between these operating systems (notably in memory management, which is historically a major distinguishing feature). There is already some support for this proposal. Please add comments at Talk: MVS. Philcha 23:56, 20 October 2007 (UTC)[reply]

Rewrite of Job Control Language in progress

As part of the proposed restructure of articles on IBM mainframe operating systems (above), I've rewritten Job Control Language to: cover IBM's DOS/360 and its descendants as well as OS/360 and its descendants; focus more on the facilities and flavour of the 2 JCLs rather than on details of some statement types and some of their options. Please comment in Talk: Job Control Language. I'd be particulary grateful for more info on DOS/360 and its descendants, especially after 1980 - I only used DOS JCL a handful of times, and only in the late 1970s. Anything about the pre-DOS System/360 operating systems would also be appreciated.

The rewrite does not currently take account of Truthanado's point in Talk: Job Control Language about use of "JCL" by computer suppliers other than IBM, which may entail further restructuring of articles about JCLs. Philcha 00:59, 21 October 2007 (UTC)[reply]