MCP-CMS

mcpcms  

  conversational monitoring system  
DCP Shell  

    minimalist clustering paradigm  

  launch   — an MCP cell ¹ provisioned by DCP per your current context. ²

Dual 6700, c. 1971/2, binding says MK 0.0, so 2.0.0

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

Semantic Roadmap

• 0.3.0 4721-04-17  1^st written tl;dr story.†
• 0.9.0 47yy-00-00  MCP BaselineOfDomainSpace.
• 1.0.0 47yy-00-00  LAN and cloud vendor provisioning; production geonode flows.
• 1.1.0 47yy-00-00  DCP BaselineOfKEE.
• 1.2.0  07y-00-00  DCP in the wild, Transparent Ledger in Books, Shopify Integration.
• 2.0.0  07y-00-00  ∫ VM (CMS, MVS) / DCP ∂ DS. The MF-One story.
• 3.0.0  07y-00-00  Done 2^nd tl;dr story, 1^st working WFL, DGUI for job edit and debug with visual execution.
• 4.0.0  07y-00-00  Mature DDD/KEE product.

MCP-CMS — a platform for the Domain Control Program, with an aesthetic in homage to the Burroughs and IBM OSes.

¹ Resource limits are dynamically set except for F class which always gets the system limit if there is one which for billable accounts is the set spend limit.
² Set parameters for your cloud provider in the DS Dashboard control blocks in your DCMS account or use system inventory.

† This page and About DCP are top level specifying stories, cog arch internals aren't divulged as I mean them to be adaptable without notice, everything else is source accessible by devops users.

tl;dr

MCPCMS presents the "CANDE" MCS³ for DS users.

AKPERSONs (see Entitlements), and whitelisted stations can connect with the link above or in a running SPO to a MCP running it.

The attempt, if it reaches the MCP, results in completion codes reported in DS control block displays in your DCMS profile.
Only ssh access from the wild, but this page will attempt, using your SAR credentials if the session role is greater than 1.
MCP operator messages will go to your ODT message queue.

---

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

CANDE MCS

MCP-CMS connects via an MCS which is often referred to as the CANDE MCS although it is more general than that being the default ubiquitous DCP/MCP MCS. 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. The system command processor is also available as a pane in the SPO.

In Burroughs MCP, the CANDE MCS was used ubiquitously. I recall using a full screen editor which i think fed CANDE. The text edit functions are obsolete and not part of the mcpcms cande. CANDE is used in current Unisys MCP but neither it nor the MCS have their former prominence when the OS runs under Windows.

mcpcms

A modified zsh for MCP serves as analog of the CMS from VM/CMS. Upon successful connect, the launch link above results in a terminal session with this shell in the browser. Aside from the modification for the MCP machine model, it is otherwise just zsh however the following (mode) commands are available to establish different shell behaviour in support of the KEE:

• shcl (common lisp nature)
• shhs (HsShellScript, haskell nature)
• upsh (prolog nature)

Lisp and prolog implementations are variable, and multiple can be combined but shcl and upsh themselves use sbcl and swipl, respectively. mcpcms can be accessed with ssh using the following script. Using the FQDSAgentName syntax is equivalent to what the launch link does in an AKPERSONs session.

#!/usr/bin/bash
# save as <fileName> and invoke with <fileName>  <connect-spec> where            
#         
#  <connect-spec> ::= <mcpCommand> <FQDSAgentName> | <connect-spec>
#  <connect-spec> ::= <ipV6Address>:<port> | <ipV4Address>:<port>
#  FQDSAgentName  ::= <agentId>@<domain>[:<port>]
#
#  and the values manually supplied from control blocks in the DCMS account profile where connect attempt results will also be available.  
#  The <mcpCommand>.  indicates the station where the script runs is trusted and the responsible AKPERSON is the operator.
#
if [ -z $2 ] then
  ssh  $1
  exit
fi
#
# Try a connect based on just the FQDSA assuming an eligible station. A port on submitted second parm is ignored with a warning.
# The no <mcpCommand> specified, a DCP determined default shell type is connected.
#
FQDSA=mcp.meansofproduction.biz/?FQDSA=$2&$1
PARMS=$(curl -L $FQDSA)
ssh $PARMS

mcpcms is implemented first for Linux natively running or containerized in docker on Mac and Windows then for the Hercules version where VM/CMS replaces the modified zsh for that special path. Cloud compute resources are dynamically provisioned using either system inventory or user supplied provisioning credentials with supported cloud vendors.

WFL

is eponymous from the original WFL and retains some superficial aesthetics but is radically different in that"

• The Job is not the top level construct. Jobs are the closest elements to heritage WFL in my WFL but with ops on my MCP rather than the Burroughs/Unisys one.
• In my WFL, Namepace, Domain, and then Job is the top level. Namespace and Domain are elements of a domain space and may span multiple MCP instances but Jobs are limited to a single MCP.

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 without WFL to terminals as a special db stack. Our WFL is the central driver and basis of our MCP/DCP architecture

1. is built for the MCP machine model
2. which is a prime driver for the development of that model
3. with code blocks containing text of other supported langs

As far as the elaboration of JCL statements and so forth WFL is developed in a bottom up prototyping style without any spec other than the mainframe reference and the DCP/MCP concept, so there will be no documentation for some time other than the text of actual jobs. № 3 above is implemented by variants for the SUBROUTINE statement, with the same attachment of BEGIN and END bounded blocks:

MCP Block Types

Block Declarator	Language	Intrinsic	Purpose/Role
User Facing
CL	Common Lisp	No	Lateral R
HS	Haskell	No	Applications
APP¹,DB,NS	WFL	Yes	Database, Job, Namespace control
LP	LogTalk	No	Lateral L
PL	Prolog	No	Plain Prolog
ST	Smalltalk²	No	SPO Context
Auteur Facing
MINT	MINT 3	Yes	WFL interpreter
SUBROUTINE	A60	Yes	JCL
UNIT	A68	Yes	Library Context

¹or JOB, they are synonyms  ²headless squeak

Intrinsic means the lang is native to MCP/WFL and doesn't require COMPILE or BIND to produce a RUN eligible object title. User facing means users of the system, Auteur facing means me, for my motivation, satisfaction and design intent of ultimate independence of the initial kernel OS. 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 consuption 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.

A Smalltalk code set is part of the system concept and a "WFL workframe" is intended as an IDE and GUI for DCP/MCP (DGUI/SPO) but it is not required for ops and will be developed based on the experience of the first working clusters.

The namestyles are a homage to MCP and VM/CMS mainframe OSes, both still in use and Unisys WFL (Work Flow Language). The machine thus defined will be ported to other cloud vendors (Google, Azure, et. al.) after workout in Akamai (linode) and AWS.

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

---