MCP-CMS: Difference between revisions

From Cibernética Americana
Jump to navigationJump to search
No edit summary
No edit summary
Line 48: Line 48:
           </span>
           </span>
</div>
</div>
<div style="position:relative;top:-90px;right:60px;"><img align=right width=400px src="https://meansofproduction.biz/images/b6700nMCP2.png">
<div style="position:relative;top:-90px;right:60px;"><img align=right width=300px src="https://meansofproduction.biz/images/b6700nMCP2.png">
<span style="float:right;position:relative;top:360px;left:300px;font-size:10px;">Dual 6700, c. 1971/2, binding says MK 0.0, so 2.0.0</span>
<span style="float:right;position:relative;top:360px;left:300px;font-size:10px;">Dual 6700, c. 1971/2, binding says MK 0.0, so 2.0.0</span>
</div>
</div>

Revision as of 17:13, 18 February 2024

mcpcms  

  conversational monitoring system  
DCP Shell  
    minimalist clustering paradigm  

  launch   — a shell on a MCP node, ¹ provisioned per your current context. ²
Dual 6700, c. 1971/2, binding says MK 0.0, so 2.0.0

Semantic Roadmap

  • 0.3.0 c. 4721-04-17  1st written tl;dr story.†
  • 0.9.0 c. 47yy-00-00  Container,LAN,Akamai, BaselineOfDomainSpace.
  • 1.0.0 c. 47yy-00-00  All core space migrated to MCP, BaselineOfKEE.
  • 1.1.0 c. 47yy-00-00  Mac, AWS, Azure, GCP, production geonode flows.
  • 1.2.0 c. 47yy-00-00  ∫ VM (CMS, MVS) / DCP ∂ DS. The MF-One story.
  • 2.0.0 c. 47yy-00-00  DCP live in the wild, Transparent Ledger, Shopify SKUs live.
  • 3.0.0 c. 47yy-00-00  Done 2nd tl;dr story, 1st working WFL, DGUI for job edit and debug with visual execution.
  • 4.0.0 c. 47yy-00-00  Mature DDD/KEE product.

MCPCMS presents the operator display terminal for MCP DevOps and the default or "CANDE" MCS³.

Restricted to AKPERSONs (see Entitlements), and whitelisted stations .
A running SPO counts against launch limits.
ABORTED, ACTIVE, COMPLETEDOK, or STOPPED are completion codes for launch job but in the wild it's not run.

Launch code ABORTED implies additional info in your DCMS account message queue.


¹ Resource limits are dynamically set except for F class which always gets the system limit if there is one which for billable accounts there isn.
² Set parameters for your MCP nodes cloud provider in the DS Dashboard control blocks in your DCMS account.
³ MCS: a message control subsystem of a MCP.

† 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.

CANDE MCS

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 MCS. Some other commands do map to the new system context though and they are developed in a similar fashion to WFL with an additional shell mode command cande like the lang specific subshells in the next §, which invokes the MCS command processor at a mcpcms prompt.

The command processor is also available as a pane in the WebKEE legacy SPA and the CANDE MCS is the default ubiquitous DCP/MCP MCS. CANDE is used in current Unisys MCP but neither it nor the MCS have their former prominence when the OS runs under Windows.

mcpcms

is derived from zsh for MCP and the shell variant set for it in /etc/shells. In an authenticated session, the launch link normally results in a WebSSH session with this shell. 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> ::= 'skip' <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 skip literal 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.
#
FQDSA=getmcpcms.ai-integration.biz/?FQDSA=$2
PARMS=$(curl -L $FQDSA)
ssh $PARMS

mcpcms is implemented for Linux first then MacOS. The intent is to support mainframe OSes after that, specifically the Hercules version of IBM and the Windows based version of Unisys MCP. Core Domain Space uses either AWS or Linode to dynamically provision whole hosts as MCP nodes and nodes may also be created as composed containers on an existing host.

WFL

has eponymous origin in the MCP 12 WFL job control model and supports the DCP with a line of demarcation between the minimalist MCP and its extension specific to DCP which is meant to protect properties of its internals. A way to think about it and my design intent is that MCP is a basic unix cluster machine to host any common mix, while the WFL machine is a private specialization.

Unisys WFL is just a point of departure to our WFL. 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 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:

Subroutine DeclaratorLanguageIntrinsic
CLCommon LispNo
HSHaskell No
LPLogTalkNo
PLPrologNo
SUBROUTINEWFL (JCL) Yes
System Internal
MINTMINT 3Yes
PROCA60Yes
UNITA68Yes
MCP Block Types

Intrinsic means the lang is native to MCP/WFL and doesn't require COMPILE or BIND to produce a RUN eligible object title.
MAKE binds job titles to files executable by the cande MCS with the START or SCHEDULE commands.

WFL(JCL) job streams are translated from source text to A60/C, A68, and MINT then compiled and linked to the Barton machine, or interpreted by genie or MINT, respectively. WFL(JCL) is A60 translated to C, compiled and bound, interspersed with the JCL statements interpreted by the B machine. Non-intrinsic code forms unified code trees in the DGUI and is maintained there under the control of the governing build statements and commands. Thus, a general WFL job orchestrates an application divided into system part executed by the B machine and application parts executed in the OS image extended from the base OS by the B machine.

'WFL' used without the JCL qualifier or 'WFL workframe' refers to general source processing framework of the high level part of the DCP. Build statements and commands refers to COMPILE/BIND/MAKE.



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
This page has a music track, mouseover for title.