MCP: Difference between revisions
| Line 28: | Line 28: | ||
Having hands on MCP 18 and seeing that it is fully available as a development target opens a role for the legacy MCP in the DCP, where "Unisys MCP" will be used wherever the distinction needs to be made clear. Also usages like ODT, DMS II or MARC are unambiguously referring to the Unisys product as we never intended take more than inspiration from it and it is great to see that apparently most of the mainframe stuff is available in the Windows based product including TCP/IP and DNS interfaces, though obviously it's a limited version of the actual priced product that runs on their hardware. "WFL" and "MCP" are the actual only conflicts, "SPO" isn't really used in the modern Unisys culture, it's been lost from the mainframe days, so the smalltalk thing I'm doing doesn't map to anything specific, although functionally MARC and the ODT would be the analogs. The original SPO was just an ODT with supervisor permissions. | Having hands on MCP 18 and seeing that it is fully available as a development target opens a role for the legacy MCP in the DCP, where "Unisys MCP" will be used wherever the distinction needs to be made clear. Also usages like ODT, DMS II or MARC are unambiguously referring to the Unisys product as we never intended take more than inspiration from it and it is great to see that apparently most of the mainframe stuff is available in the Windows based product including TCP/IP and DNS interfaces, though obviously it's a limited version of the actual priced product that runs on their hardware. "WFL" and "MCP" are the actual only conflicts, "SPO" isn't really used in the modern Unisys culture, it's been lost from the mainframe days, so the smalltalk thing I'm doing doesn't map to anything specific, although functionally MARC and the ODT would be the analogs. The original SPO was just an ODT with supervisor permissions. | ||
<br><br> | <br><br> | ||
The most natural form of integration of Unisys MCP is to allow it as an alternate to linux MCP in a DCP. Physically, this would require at least a DCP aware WFL and DCALGOL and for everything impacted to be recompiled and tested with these. While doable in principle, it's just a bad idea for a number of reasons, among | The most natural form of integration of Unisys MCP is to allow it as an alternate to linux MCP in a DCP. Physically, this would require at least a DCP aware WFL and DCALGOL and for everything impacted to be recompiled and tested with these. While doable in principle, it's just a bad idea for a number of reasons, among them that this isn't a dead arch. So, at least in any foreseeable near term, some fallback is needed.<br><br> | ||
The design principle embodying that fallback is that Unisys MCP shall only have integration with the DCP cognitive architecture and not the physical one, each Unisys MCP in a DCP will be an island (Unisys inter MCP linkages notwithstanding) unlike the linux hosts which form a single system image. That being the case, no Unisys MCP components need to be altered. Rather the integration will be in software built with the standard Unisys dev kit targeting the DCP cog arch. Seems like a good enough place to say I have no interest in the Unisys Univac stuff. There appear to be only a couple hundred MCP sites still running and a good number of them are software houses serving the remainder, a mix of banks, govt units, etc. | The design principle embodying that fallback is that Unisys MCP shall only have integration with the DCP cognitive architecture and not the physical one, each Unisys MCP in a DCP will be an island (Unisys inter MCP linkages notwithstanding) unlike the linux hosts which form a single system image. That being the case, no Unisys MCP components need to be altered. Rather the integration will be in software built with the standard Unisys dev kit targeting the DCP cog arch. Seems like a good enough place to say I have no interest in the Unisys Univac stuff. There appear to be only a couple hundred MCP sites still running and a good number of them are software houses serving the remainder, a mix of banks, govt units, etc. | ||
<br><br> | <br><br> | ||
Revision as of 04:26, 18 March 2020
A timeline of "MCP" in my life course.
MCP 4 Era
The first referent of the acronym is the operating system of the same name, which was at release 19 in 2019.
I was the systems programmer at Daytona Beach Community, now Daytona State College which was then a Burroughs shop as my second multi-year job out of college ('83-'85). [1]
4715 Story
In a my domain space concept, it is the designation for nodes of a Domain Control Program (DCP).
«MCP» is the operating system abstraction on a single node of a cluster, or cloud of computers with fast interconnectivity, miniminally 1 gigabit per second. The MCPs operate as the nodes of the larger OS construct, the DCP. MCP itself has these components/layers:
- The top level which is a lisp image running a generic blackboard model of realtime operations control and knowledge base management.
- The workflow level which is implemented by the Work Flow Language, another Burroughs inspiration, reimagined as a context for literate programming and revival of the job control concept based on an adaptation of WFL to the DCP context.
- A base layer close to machine level using the c++ actor framework and optionally a custom debian kernel.
Elliott AI ™
About this time Unisys made MCP available to run from Windows 7 or 10 64 bit as "MCP Express" although I didn learn of this until 2019Q3 and didn bring it up till end of Q1 '20 (version 5). It is the full OS, sufficient to develop programs for current MCP (18). A main issue is that the license has to be renewed every August 1, but unclear how much disruption that is, working assumption is that worst case is that the backup restore utility would have to be used and the MCP rebuilt from reinstall. Will update this § when I know.
Having hands on MCP 18 and seeing that it is fully available as a development target opens a role for the legacy MCP in the DCP, where "Unisys MCP" will be used wherever the distinction needs to be made clear. Also usages like ODT, DMS II or MARC are unambiguously referring to the Unisys product as we never intended take more than inspiration from it and it is great to see that apparently most of the mainframe stuff is available in the Windows based product including TCP/IP and DNS interfaces, though obviously it's a limited version of the actual priced product that runs on their hardware. "WFL" and "MCP" are the actual only conflicts, "SPO" isn't really used in the modern Unisys culture, it's been lost from the mainframe days, so the smalltalk thing I'm doing doesn't map to anything specific, although functionally MARC and the ODT would be the analogs. The original SPO was just an ODT with supervisor permissions.
The most natural form of integration of Unisys MCP is to allow it as an alternate to linux MCP in a DCP. Physically, this would require at least a DCP aware WFL and DCALGOL and for everything impacted to be recompiled and tested with these. While doable in principle, it's just a bad idea for a number of reasons, among them that this isn't a dead arch. So, at least in any foreseeable near term, some fallback is needed.
The design principle embodying that fallback is that Unisys MCP shall only have integration with the DCP cognitive architecture and not the physical one, each Unisys MCP in a DCP will be an island (Unisys inter MCP linkages notwithstanding) unlike the linux hosts which form a single system image. That being the case, no Unisys MCP components need to be altered. Rather the integration will be in software built with the standard Unisys dev kit targeting the DCP cog arch. Seems like a good enough place to say I have no interest in the Unisys Univac stuff. There appear to be only a couple hundred MCP sites still running and a good number of them are software houses serving the remainder, a mix of banks, govt units, etc.
4718-20
α/β period:
In this period the elements of the DCP are prototyped, marshalled, deployed then productized:
- Get working build of all packages in same form they will ultimately be used in the product.
- Get working build of newly created elements such as the DGUI/SPO and WFL.
- Apply the above to the proto domains.
- Workout in service of the proto domains.
- Do productization/packaging for mass deployment
CP 4721 roughly corresponds to what is produced by 1 and 2 and the AKDOMHST/SVC SKUs to 5.
Sometime between milestone 2 and 4, a MCP shell/remote SPO service will be made available to authenticated users.
CP 4721
Blank for formatting purpose.
See also
Footnote
