Thanks for the analysis.
as a TSO command processor (single user). This makes it easier.
I've already thrown out the EXCP stuff(as much as I like it). I use BDAM
IO with relative record access. I've written a macro to do all the
DIR & WS access with the new support module.
.* storage area defined by WS3. WS3 should start PAGE
.* boundary and be large enough to hold NUM#@ x WSSIZE bytes.
I'm starting the work on The APLUTIL module. I'm making the code 31 bit
and re-entrant. I've
BDAM(DCBs, DECBs,CDCPARS,JFCB, etc). I removed the necessity for the
SWAP file(Since this is going to be a TSO command processor).
I chose BDAM because it allows me multiple IOs(like chained scheduling).
I have the APLINIT module almost complete.
360 model 50 and a 145 .
Post by ThomasAfter the many postings regarding running the APL\360 code under MVT I
decided to look at the code in the context of moving the code to MVS
as I have had some experience in refurbishing old code.
Firstly, looking at the online component of APL\360.
The online code makes minimal use of OS/360 and where it does use
OS/360 services all of the expected integrity associated with OS/360
is circumvented by the code. The only exception being the workspace
interpreter.
All OS APL/360 code runs in Key 0 Supervisor state except when the
interpreter is dispatched with the region user key to interpret the
users workspace code which is resident in storage set to the region
user key. System/360 storage protection is used to prevent errors in
APL\360 user programs that would corrupt APL\360 code or other
resident workspaces. The storage keys and PSW key are set without the
use of any system services.
DASD I/O
APL\360 uses EXCP for all DASD processing however the dataset
integrity of EXCP processing is circumvented. The DEB file mask for
each dataset is set to zero allowing embedded cylinder SEEKs in CCW
strings. The CCW strings used by the code do have embedded SEEKs with
the CCHH DASD address calculated by the code. Therefore any error in
calculating the provided CCHH may result in I/O outside of the extents
of a SWAP or LIBRARY dataset. This will not be prevented by the MVT
I/O Supervisor and could result in corruption of other datasets on the
volume (including the VTOC).
APL\360 uses PCI, CE and Abnormal End (XE) Appendages for control of
the I/O to the SWAP and LIBRARY datasets. The provided Appendage exits
are not discreetly coded routines isolated for ease of understanding
and maintenance but are in fact dummy routines which pass control
directly into the complex APL\360 control code running disabled in Key
0 Supervisor state.
SWAP and LIBRARY dataset device characteristics are obtained from the
DEVTYPE macro. They may be allocated on 2311, 2314, 3330 or any DASD
device supported by MVT however not to any device with a track size
exceeding 14000 as that is the size of the DASD I/O area allocated in
the IM CSECT in APLSSINI. RPS Support is included in the DASD driving
code and not identified in the source as a retro fit/enhancement. An
interesting aside is that the APL\360 source code as distributed has a
date 05/11/70 whereas IBM announced 3330s in Jun 1970 so 3330s must
have been generally available inside the IBM Labs for some time before
Customer Announcement.
Terminal I/O
APL\360 does not use OS/360 for I/O to the terminal devices. Therefore
no OS/360 UCBs are required or used to drive the terminals. No OS/360
Access Method code is used. I/O to the terminals is driven directly by
SIO instructions initiating CCWs strings built and updated by AP\360.
Extensive use is made of PCI interrupts to update running channel
programs to manage the buffer pool. To implement this method of I/O,
on startup, the I/O New PSW is replaced with a PSW passing control
directly to APL\360. All I/O interrupts are received by APL\360 where
the interrupting device address is inspected and non APL\360 terminal
interrupts are passed to the MVT I/O Supervisor for processing. All
terminal I/O error processing is implemented in the APL\360 terminal
control routines. Due to the characteristics of start/stop terminal
hardware and unique characteristics of each terminal type the terminal
I/O driving code and CCW manipulation code is closely integrated with
the applications parsing and processing code.
The code is designed to run a significant number of terminals to
support a large user population in competition for computer resources
executing the APL\360 interpreter so it has been implemented using an
interrupt driven structure. Running disabled during terminal I/O would
not be possible due to the PCI driven code managing the buffer pool.
Timer Processing
Branch entry points are used to enter internal MVT Timer code for
finer granular control of timer services.
PSW Formats
The code manipulates BC Mode PSWs to dispatch various code routines.
This code would not function correctly with EC Mode PSWs
24 Bit Addressing Violation
The excellent diagnostic work by Juergen has identified the problem
with APL\360 failing when it is running above the 8MB line due to use
of hi-order flag bits in a 24 bit address field. This will make a
migration to MVS very difficult.
Batch Utility Component
The APL\360 batch utility code is compliant with standard OS/360 APIs
except that the DEB file mask is set to zero to allow cylinder SEEKs
in CCW chains. The I/O Appendages used in the online component are not
loaded for use during batch processing. Tape I/O uses EXCP to a DOS
interface which is then mapped to OS control blocks to be compliant
with MVT EXCP processing. The code has been written for unlabelled
tapes only, with specific APL\360 formatted tapes with its own
internal processing to identify tape contents. QSAM is used for
SYSIN/SYSOUT processing. The batch utilities should be able to run in
the MVS environment but only testing will reveal any hidden problems
when processing APL\360 workspaces for backup or restoration.
Recommendations
Allocate each APL\360 SWAP and LIBRARY dataset to a unique volume not
used for any other purpose due to the possible risk of data corruption
on the volume. The same device type must be used for all datasets.
RE-IPL MVT immediately after each APL\360 shutdown or abnormal
termination to avoid the possibility of the I/O New PSW not being
correctly restored. A Program Interrupt in the APL\360 control
routines will not restore the I/O New PSW to the previous setting.
Without the I/O New PSW being restored to pass control to the MVT I/O
Supervisor then every I/O interrupt from any device will end up at the
location of the APL\360 interception code whether it is there or been
overwritten.
We own a great deal of thanks to Juergen for his major effort working
to refurbish APL\360 in such a difficult and complex environment
without the benefit of complete documentation or a complete
distribution tape. It is truly work with a high degree of complexity
and difficulty to understand the interaction between the various
components of APL\360. We must also give thanks to Max for his work in
developing 2703 Control Unit emulation. Without taking anything away
from the brilliant work done by the many Hercules developers in
building Hercules and its device emulation I would consider the 2703
CU to be the most difficult to emulate. The major issue is one of
timing where CCWs may not be processed at Hercules speed but must
respect the timing delays of the real world environment to provide a
workable emulation for start-stop devices with all their quirky features.
My apologies for the long post however the APL\360 project has
attracted a lot of attention and comments so I hope this post level
sets everyone to the scope of this project and its ongoing issues.
Regards
Tom