MCP-CMS

mcpcms  

  conversational monitoring system  
DCP Shell  

    minimalist clustering paradigm  

  launch   — an MCP cell ¹ provisioned by the Domain Control Program per your current context. ²

Dual 6700, c. '72, binding says MK 0.0, so 2.0.0 vs. 21 in 2023.

This page has an audio track, mouseover for title/credit.

Semantic Roadmap

• 0.9.0  075-12-11  Freeze 1.x Era Timeline. 1^st stable tl;dr.^†
• 0.9.1  07y-mm-dd  BaselineOfBOOTKEE, doorbell migrated to JSX/HSX cells.
• 1.0.0  07y-mm-dd  DCP provisions FRED, C-六/SB, CLFE, and DCMS cells.
• 1.1.0  07y-mm-dd  DSAP appgen baseline.
• 1.1.2  07y-mm-dd  FRED fully automated.
• 1.2.0  07y-mm-dd  BaselineOfDCP (DGUI/SPO).
• 1.2.1  07y-mm-dd  Transparent Ledger (Books IX), DCP agency live at perimeter.
• 2.0.0  07y-mm-dd  BaselineOfWFL.
• 2.1.0  07y-mm-dd  ∫ x 𝔻 ∂ DS, BaselineOfKEE (sans boot) .
• 2.2.0  07y-mm-dd  1^st WFL Workframe.
• 3.0.0  07y-mm-dd  ∫ VM (CMS, MVS) / DCP ∂ DS mainframe redux.
• 3.1.0  07y-mm-dd  Mature DDD/KEE product.

DCP/MCP — an OS platform with an aesthetic in homage to mainframes.

¹ Resource quotas are entitlement based.
² Use a supported cloud provider by supplying credentials in control blocks in your profile or system inventory.

† For security and flexibility reasons and to the extent feasible, DCP internals aren't divulged, MCP however is source accessible by DevOps users. This page and About DCP, which is within the core perimeter, are top level specifying stories.

tl;dr

DCP/MCP presents the MCPCMS shell and the "CANDE" MCS³ to whitelisted stations upon connect.
AKPERSONs (see Entitlements) can connect with the link above or in a running SPO image.

³ MCS: a message control subsystem of a MCP. MCP 15 System Commands
MCP 3.3 CANDE Reference Card
MCP 14 CANDE Reference

ODT MCS

MCP-CMS connects via a MCS which is usually the CANDE MCS although more generally any MCS with the ODT property can connect for an Operator Display Terminal session with MCP/DCP. Upon mcpcms connect, like the lang specific subshells in the next §, an additional command cande can be used which will process the MCP-CMS system commands analogous to those in the MCP 15 document above.

In Burroughs MCP, the CANDE MCS was used ubiquitously. The ODTs had a full screen editor which just fed lines to CANDE. Commands are implemented per need and some such as the text edit functions likely never will be in mcpcms cande. CANDE is used in current Unisys MCP but neither it nor the MCS have their former prominence especially when the OS runs as a Windows service.

In DCP/MCP, an ODT is simply a linux PTY which operates in MCP/MCS context.

mcpcms

The CMS^* in MCP-CMS is inspired by VM/CMS and the MCP system command level of the CANDE MCS and the ODT session corresponds to the VM CMS command level. A modified zsh serves as the analog of Burroughs CANDE as one of several shells invocable in an ODT. Upon successful connect, the launch link above results in an ODT session with this shell in the browser having supplied the default cande for the parameter 'mcpcms command' to the connect above. Aside from adaptations for the MCP machine model, it is just zsh however and the following alternates can be specified or run as a subshell with cande <subshell>. You can also leave the field blank in which case you will be at the ODT level with bash.

• shcl
• hsh
• upsh

for lisp, haskell, and prolog respectively. DCP/MCP embeds sbcl, ghc, and swi prolog as libs and code in these shells can interact with those parts of DCP/MCP directly. In the BootKEE epoch, before DCP WFL is generally available, DCP is programmed as jobs via these shells . mcpcms can be accessed from various connect points such as the launch link above in an AKPERSONs session. mcpcms scope may vary from a single MCP cell or node to a whole DCP/DS context. Cloud compute resources are dynamically provisioned using either system inventory or user supplied provisioning credentials with supported cloud vendors. Later MCP for Mac and Windows will allow cells there and the last free version of VM/CMS under Hercules will ultimately run as an autonomous DCP subject, with other possible mainframe emulations, particularly Unisys should their licensing permit.
*   Not to be confused with DCMS, the domains content management system.

DCP WFL

is eponymous upon the Burroughs WFL with some preserved semantics and aesthetics but the following essential differences —

• The Job is not the top level construct. The Job or App is the closest construct to heritage WFL in my WFL but with ops on my MCP rather than the Burroughs/Unisys one and expansion beyond batch ops.
• In my WFL, Namespace, Database, and then App/Job is the scope hierarchy. Namespace and Database are elements of a domain space and may span multiple MCP instances but Jobs are limited to the nodes and cells of a single MCP. Essentially there is a single whole space level job which the DCP implements.

In Burroughs systems, WFL didn have as high a profile as IBM JCL, the main punch of the overall system, in an industry installation, would be its system of transactions and these ran from a database which the Burroughs architecture delivered seamlessly with little or no WFL to ODTs from a MCS running db stack or programmers using CANDE while WFL was used for operations. DCP WFL has these design goals

1. provide an clear/auditable text for DCP operations as a complement to
2. the MCP which provides the real machine model and
3. with code blocks containing text of other supported langs

DCP WFL is developed in a bottom up manner from this statement of design intent without any spec other than the heritage systems and the DCP/MCP concept. In the initial releases there will be no documentation outside of story text, and the top level pamphlets. Code cannot move into WFL blocks from its free form before the 1.2.0 milestone. In standard Algol convention № 3 above is implemented by these block variants with the same delimitation by BEGIN and END bounded blocks:

MCP Block Types

WFL Declarator	Language	Intrinsic¹	Purpose/Role
Machine Facing
None²	MINT 3	Yes	MTRANS WFL Compiler
N/A	Smalltalk²	No	GUI and Object Model
SUBROUTINE	A60	Yes	JCL Procedures
UNIT	A68	Yes	MCP Libraries
Enterprise Facing
CL	Common Lisp	Yes (sbcl-librarian)	Lateral R
HS	Haskell	Yes (ghc-pkg)	Enterprise Applications
JOB	WFL	Yes	JCL
LP	LogTalk	No	Lateral L
PL	Prolog	Yes (MQI/pengine)	Plain Prolog

¹Intrinsic means directly compiled/interpreted by MCP and doesn't require COMPILE or BIND to produce a RUN eligible object title.
²Mint code is monolithic with security by obscurity for some application, database, and namespace elements.  ³headless squeak using my cog build for Sista and multi-threading .

Enterprise facing means oriented to programming users of the system, Machine facing means me, for my motivation, satisfaction and design intent of real machine independence of the core super-OS as much as in the nominal sense. Users can create their own semantic spaces by using WFL and the standard modern high level lang blocks while the MINT and Algol elements are my private programming of DCP/MCP not meant for user consumption but visible to satisfy transparency requirements.

Procedural WFL is translated from source text to A60/C, then compiled and linked to the Barton machine, or directly interpreted by genie or MINT. Non-WFL blocks are compiled and bound and used in the concrete context of the DS which they form as extensions of the WFL/B machine.

'JCL' means things defined by an M-TRAN phrase grammar which can contain pure MINT blocks but general end use procedures are meant to be in Algol dialects. I dont mean it to be an acronym being both more general than job control and serving as the macro assembler of MCP. MCP thus maintains a distinction between what it and the host machine directly interpret.

DCP/MCP are embodied in a central simulacrum containing an object model for them. SPO a system supervisor GUI, and LibraryBrowser which maps code trees to MCP object files and maintains MCP file system attributes, run as a Smalltalk vm/image in the regular MCP job mix. LibraryBrowser/SPO are the things an end user works with to perform dev/ops with the former constituting a "WFL workframe", the pair functioning as the IDE and GUI of DCP/MCP (DGUI). Much of it can run headless, the form which the actual DCP can dynamically change by altering its methods, and the one used by non-KEE users. Separately, an available FOSS visual programming pkg is being adapted for what I am calling DS G based on my experience with LabView/G, and which will be developed before WFL but with intent of later being a façade for it in concert with LibraryBrowser.

The namestyles are in homage to MCP and VM/CMS mainframe OSes, both still in use and Unisys and VM/CMS are trademarks of the IBM and Unisys corporations, respectively. DS MCP as an actually delivered OS is composed of cells (containers) and OS images (nodes) running system services and jobs with original code in the KEE langs supported by lower level apps runnable on a nodes kernel OS.

The Abydos Kings List   c. -400   to   1400   公元,   Menes — Seti I

---