|
|
|
|
|
|
|
|
VM/COM, October 1985
1
-
OO OO OOO OOO // OOOOOOO OOOOOOO OOO OOO
OO OO OO OOO OO // OO OO OO OO OO OOO OO
OO OO OO O OO // OO OO OO OO O OO
oo oo oo oo // oo oo oo oo oo
oooo oo oo // oo oo oo oo oo oo
oo oo oo // ooooooo ooooooo oo oo
0 ------------------------------------------------------------
October 1985 edition Volume 2 Number 5
- CsNews Network Newsletter
-
-
Staff:
0 Michele Robinson CSMICH at MAINE Editor
Andrew T. Robinson ANDY at MAINE CsNews Director
David Eckhardt DAE at PSUVAX1 Assistant Editor
Prof. G. Markowsky MARKOV at MAINE Faculty Advisor
-
0 Ôçççççççççççççççççççççççççççççççççççççççççççççççççççççççä
³ Newsletter article contribution Userid: CSNEWS@MAINE ³
³ ³
³ Contributions from readers welcomed and encouraged! ³
¨ççççççççççççççççççççççççççççççççççççççççççççççççççççççç]
1
0 Vm-Com Issue 2.5
-
0 Table of Contents
+ _____ __ ________
- Introduction to Vm/Com 2.5 . . . . . . . . . . . . . . . 1
CSNEWS Notes . . . . . . . . . . . . . . . . . . . . . . 2
The GNU Manifesto (part 2) . . . . . . . . . . . . . . . 4
Write FIFO But Read LIFO! . . . . . . . . . . . . . . . . 8
Programming at the Machine Level (part 3) . . . . . . . . 10
Summary of CMS Release 4 Enhancements . . . . . . . . . . 16
Fog . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
OpCodes . . . . . . . . . . . . . . . . . . . . . . . . . 19
-
-
-
-
-
-
-
-
-
-
-
-
-
- 2
1
0 Vm-Com Issue 2.5
0 Introduction to Vm/Com 2.5
+ Introduction to Vm/Com 2.5
-
Hi again! Good to have you all reading another issue of
Vm/Com... I'd really like to get some comments back from
you the reader, telling us anything you might have on your
mind. My letters to the editor column is very empty...
0 In this issue is the second part of the GNU article, the
third article in the 370 machine programming series, an
article on structured programming and a summary of the new
CMS release 4 updates, and the humor section consists of the
usual OpCodes and a unique creation called Fog.
0 Untill next issue, keep reading and enjoying and Happy
Halloween! See ya in 2-5.
0 Michele Robinson,
Editor
-
-
-
-
-
-
-
-
-
-
-
- 1
1
0 Vm-Com Issue 2.5
0 CSNEWS Notes
+ CSNEWS Notes
0 Andrew T. Robinson, (ANDY@MAINE)
-
Hello, CSNEWS fans! I'm back again with some more
penetrating insight into the world of BITNET and CSNEWS.
This month there are all sorts of interesting things I can
talk about. The question is, whether I can remember any of
them.
0 First of all, one of our operators, Sean Colbath
(CPE07401@MAINE), has left us for the University of
Rochester. We were sorry to see him go, but he may be
resuming some of his CSNEWS activity when he gets an ID at
UOR. We'll be sure to tell you what that ID is, so you can
all bug him to death.
0 In addition, the other member of the CSNEWS founding
team, Barry Gates, has returned to Massachusetts. Barry was
in charge of the COMDISK, and has presented some ideas for
the BITNAUTS LIST which may be implemented in the near
future.
0 Speaking of the COMDISK, our new COMDISK managers for
this year are David Liscomb (NMCS025@MAINE) and David
Gridley (ICC020G@MAINE). David Gridley is also a regular
CSNEWS operator.
0 Preparatory to transfer of CSNEWS to an Assembler-based
system, some of the CSNEWS software is undergoing a face
lift. You may start to notice some changes in the command
outputs soon. Also, as things get more advanced, some of
the programs may end up dying outright. If this happens,
just inform a CSNEWS operator.
0 I realize that this is the October issue, but I am
writing this in September. As such, school is just starting
here and at many other BITNET schools. There will lots of
new BITNAUTS on the NET soon, and with them, new friends...
*and* new problems.
0 The problem of student access to BITNET has been a
subject of debate for a long time now. Naturally, we of the
CSNEWS staff encourage constructive use of the BITNET. We
also recognize that there are many problems that occur every
day because of non-constructive use. I encourage all
BITNAUTS to take an interest in seeing what they can do to
HELP the BITNET, and not hinder it. If more students
display a higher level of maturity when using their
respective systems, they may find their administrators less
eager to restrict their access to the computer and BITNET.
- 2
1
0 Vm-Com Issue 2.5
0 There is a CSBB forum on CSNEWS, BITNET CSNOTICE, which
contains current discussions on BITNET access and use. I
encourage all of our readers to look at BITNET CSNOTICE, and
add their comments to the discussion. PLEASE put all BITNET
discussions in BITNET CSNOTICE, and NOT FLAME.
0 Well I guess th-that's all for now folks. I'll be back
with more fun and exciting comments next issue. See ya
later!
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
0 3
1
0 Vm-Com Issue 2.5
0 The GNU Manifesto, (Continued from Issue 2-4)
+ The GNU Manifesto, (Continued from Issue 2-4)
0 Written by Richard M. Stallman
Submitted by Jim Lewis (JWL@UCBKIM.ARPA)
- Why All Computer Users Will Benefit
0 Once GNU is written, everyone will be able to obtain good
system software free, just like air.
0 This means much more than just saving everyone the price
of a Unix license. It means that much wasteful duplication
of system programming effort will be avoided. This effort
can go instead into advancing the state of the art.
0 Complete system sources will be available to everyone.
As a result, a user who needs changes in the system will
always be free to make them himself, or hire any available
programmer or company to make them for him. Users will no
longer be at the mercy of one programmer or company which
owns the sources and is in sole position to make changes.
0 Schools will be able to provide a much more educational
environment by encouraging all students to study and improve
the system code. Harvard's computer lab used to have the
policy that no program could be installed on the system if
its sources were not on public display, and upheld it by
actually refusing to install certain programs. I was very
much inspired by this.
0 Finally, the overhead of considering who owns the system
software and what one is or is not entitled to do with it
will be lifted.
0 Arrangements to make people pay for using a program,
including licensing of copies, always incur a tremendous
cost to society through the cumbersome mechanisms necessary
to figure out how much (that is, which programs) a person
must pay for. And only a police state can force everyone to
obey them. Consider a space station where air must be
manufactured at great cost: charging each breather per liter
of air may be fair, but wearing the metered gas mask all day
and all night is intolerable even if everyone can afford to
pay the air bill. And the TV cameras everywhere to see if
you ever take the mask off are outrageous. It's better to
support the air plant with a head tax and chuck the masks.
0 Copying all or parts of a program is as natural to a
programmer as breathing, and as productive. It ought to be
as free.
-
0 4
1
0 Vm-Com Issue 2.5
0 Some Easily Rebutted Objections to GNU's Goals
0 "Nobody will use it if it is free, because that
means they can't rely on any support."
"You have to charge for the program to pay for
providing the support."
0 If people would rather pay for GNU plus service than get GNU
free without service, a company to provide just service to
people who have obtained GNU free ought to be profitable.
0 We must distinguish between support in the form of real
programming work and mere handholding. The former is
something one cannot rely on from a software vendor. If
your problem is not shared by enough people, the vendor will
tell you to get lost.
0 If your business needs to be able to rely on support, the
only way is to have all the necessary sources and tools.
Then you can hire any available person to fix your problem;
you are not at the mercy of any individual. With Unix, the
price of sources puts this out of consideration for most
businesses. With GNU this will be easy. It is still possible
for there to be no available competent person, but this
problem cannot be blamed on distribution arrangements. GNU
does not eliminate all the world's problems, only some of
them.
0 Meanwhile, the users who know nothing about computers
need handholding: doing things for them which they could
easily do themselves but don't know how.
0 Such services could be provided by companies that sell
just hand-holding and repair service. If it is true that
users would rather spend money and get a product with
service, they will also be willing to buy the service having
got the product free. The service companies will compete in
quality and price; users will not be tied to any particular
one. Meanwhile, those of us who don't need the service
should be able to use the program without paying for the
service.
0 "You cannot reach many people without advertising, and
you must charge for the program to support that."
"It's no use advertising a program people can get free."
0 There are various forms of free or very cheap publicity that
can be used to inform numbers of computer users about
something like GNU. But it may be true that one can reach
more microcomputer users with advertising. If this is
really so, a business which advertises the service of
copying and mailing GNU for a fee ought to be successful
enough to pay for its advertising and more. This way, only
the users who benefit from the advertising pay for it.
0 5
1
0 Vm-Com Issue 2.5
0 On the other hand, if many people get GNU from their
friends, and such companies don't succeed, this will show
that advertising was not really necessary to spread GNU.
Why is it that free market advocates don't want to let the
free market decide this?
0 "My company needs a proprietary operating
system to get a competitive edge."
0 GNU will remove operating system software from the realm of
competition. You will not be able to get an edge in this
area, but neither will your competitors be able to get an
edge over you. You and they will compete in other areas,
while benefitting mutually in this one. If your business is
selling an operating system, you will not like GNU, but
that's tough on you. If your business is something else,
GNU can save you from being pushed into the expensive
business of selling operating systems.
0 I would like to see GNU development supported by gifts
from many manufacturers and users, reducing the cost to
each.
0 "Don't programmers deserve a reward for their creativity?"
0 If anything deserves a reward, it is social contribution.
Creativity can be a social contribution, but only in so far
as society is free to use the results. If programmers
deserve to be rewarded for creating innovative programs, by
the same token they deserve to be punished if they restrict
the use of these programs.
0 "Shouldn't a programmer be able to ask
for a reward for his creativity?"
0 There is nothing wrong with wanting pay for work, or seeking
to maximize one's income, as long as one does not use means
that are destructive. But the means customary in the field
of software today are based on destruction.
0 Extracting money from users of a program by restricting
their use of it is destructive because the restrictions
reduce the amount and the ways that the program can be used.
This reduces the amount of wealth that humanity derives from
the program. When there is a deliberate choice to restrict,
the harmful consequences are deliberate destruction.
0 The reason a good citizen does not use such destructive
means to become wealthier is that, if everyone did so, we
would all become poorer from the mutual destructiveness.
This is Kantian ethics; or, the Golden Rule. Since I do not
like the consequences that result if everyone hoards
information, I am required to consider it wrong for one to
do so. Specifically, the desire to be rewarded for one's
0 6
1
0 Vm-Com Issue 2.5
0 creativity does not justify depriving the world in general
of all or part of that creativity.
0 "Won't programmers starve?"
0 I could answer that nobody is forced to be a programmer.
Most of us cannot manage to get any money for standing on
the street and making faces. But we are not, as a result,
condemned to spend our lives standing on the street making
faces, and starving. We do something else.
0 But that is the wrong answer because it accepts the
questioner's implicit assumption: that without ownership of
software, programmers cannot possibly be paid a cent.
Supposedly it is all or nothing.
0 The real reason programmers will not starve is that it
will still be possible for them to get paid for programming;
just not paid as much as now.
0 Restricting copying is not the only basis for business in
software. It is the most common basis because it brings in
the most money. If it were prohibited, or rejected by the
customer, software business would move to other bases of
organization which are now used less often. There are always
numerous ways to organize any kind of business.
0 Probably programming will not be as lucrative on the new
basis as it is now. But that is not an argument against the
change. It is not considered an injustice that sales clerks
make the salaries that they now do. If programmers made the
same, that would not be an injustice either. (In practice
they would still make considerably more than that.)
- Copyright (c) 1985 Richard M. Stallman
0 Permission is granted to anyone to make or
distribute verbatim copies of this document as
received, in any medium, provided that the
copyright notice and permission notice are
preserved, and that the distributor grants the
recipient permission for further redistribution as
permitted by this notice.
0 Modified versions may not be distributed.
- ÕThis is the second part of the GNU story. Part one
of this article can be found in issue 2-4. -Edþ
-
- 7
1
0 Vm-Com Issue 2.5
0 Write FIFO But Read LIFO!
+ Write FIFO But Read LIFO!
0 Billy E. Taylor, Jr. (TAYLORB@UMDB)
-
Those of you who are familiar with programming in a well
structured language, like Pascal or especially C, know how
easy it is to create highly convoluted, "write only" code,
i.e. code that even you cannot decipher after six months.
In an attempt to eliminate this effect, for the past several
years structured, "black box" style programming has been
heavily emphasized.
0 Here's a description for those of you who are not very
familiar with the idea. A large programming task is first
divided into a half dozen to a dozen or so smaller subtasks.
The programmer divides the main task such that each subtask
is designed to handle related tasks and accomplish a
specific portion of the main task. The main routine for the
program can then be written making each subtask a
procedure/subroutine call which you assume will achieve the
task set for it.
0 This process is then performed on each of the just
created routines for the subtasks. In this manner, each
routine/subtask is further divided until the resultant
subtasks/routines are so conceptually simple and their
objectives so straight forward that the coding practically
suggests itself. In most cases this style produces a large
number of relatively small simplistic routines.
0 This is called "black box" style because as each routine
is written, each subtask is treated like the famous black
box where the inputs are known, the produced outputs are
known, but at this point the programmer does not care HOW
the black box/routine works, only that it DOES work. The
how is considered only later, when this task is further
subdivided. This style, also, imitates a FIFO stack in that
each routine is written (roughly) in the order in which it
will execute, i.e. main routine first, then large
subroutines, then medium subroutines of the large
subroutines, etc.
0 This style of programming works extremely well for the
vast majority of large programming tasks. This procedure
also tends to produce and reinforce an unfortunate habit
among programmers. FIFO style programming leads more than a
few programmers to FIFO style reading of others programs.
And for many, this is exactly the most difficult way to read
a program!
-
0 8
1
0 Vm-Com Issue 2.5
0 If you attempt to read a program that you have never
seen before, written by another programmer, you will find
that reading FIFO is quite difficult. You wind up either
reading the main routine and knowing only vaguely what all
of the procedure calls there are doing and then reading
those procedures. Or you mimic execution and read the main
routine until the first procedure call and then trace
through the program to that procedure and start to read it.
Then you trace the procedure calls in that procedure and so
on. By the time you return from those calls, you will have
lost the context of the routine you were trying to
understand in the first place.
0 Reading in this manner will give, at best, a poor
understanding of the exact operations behind or the concepts
involved in the program. It will often inhibit any real
understanding of the program at all.
0 However, try reading a program you've never seen before
in what I'll call a LIFO manner. With a C or Pascal-like
program it's usually very much like reading through a
program listing as it's printed. You start at the top, where
the smallest, often used, conceptually obvious routines are
located. As you read each of those, you make the connection
between the routine name and it's actions. Now, when you
see a call to this routine later, you already KNOW what the
routine is doing so no routine tracing of any kind is
needed.
0 As you work your way through the program listing, the
routines will become more conceptually intricate, perhaps
even cleverly bizarre, but since you will have already made
the mental link between the calls to the smaller routines
and the actions of these routines, you can concentrate
solely on the tricks of logic employed in the ONE routine
you're currently reading.
0 With fewer things to concentrate on at one time, you
will be able to more clearly understand that upon which you
are concentrating. By working this process all the way down
to the program's main routine, you will easily gain an
understanding of what the entire program does and more
importantly, HOW the program accomplishes what it does.
- ÕMany thanks to Dr. Randy Barth of Computer Science
Corp. for demonstrating that this is a sufficiently
important idea to merit explanation. -B.T.þ
-
-
0 9
1
0 Vm-Com Issue 2.5
0 Programming at the Machine Level
+ Programming at the Machine Level
Part III: S/370 Interrupt Structure
+ Part III: S/370 Interrupt Structure
0 Andrew T. Robinson (ANDY@MAINE)
-
In the last article of this series, we discussed some of
the essential concepts of the IBM 370-architecture interrupt
system. In this article, I will review some of the
programming considerations that are important when writing
an interrupt handler. We will also see a sample interrupt
trapping program that can be used to do a 'waited' read to
the console.
0 There are several considerations when writing a program
that is interrupt driven, or simply traps interrupts. One
of the most important is telling the CPU that your handler
is to get control whenever an interrupt of the type you are
trapping occurs. Do this by replacing the NEW-PSW for that
type of interrupt (in our example we will be trapping I/O
interrupts) with a PSW you have constructed in your program.
0 The first four bytes of this replacement PSW are usually
zeroes, especially the system mask byte (bits 0-7). With all
the system mask bits set to zero, your interrupt handler
will be entered with all I/O and EXTERNAL interrupts
disabled. This is important, because many interrupt
handlers (including the example below) are not reentrant,
and would crash if an interrupt of the type being trapped
occurred while the handler was already active.
0 The second four bytes of the replacement PSW (the program
mask, condition code, and instruction address) contain the
address of the start of your interrupt handler. This is the
address that will receive control when the interrupt occurs.
0 CMS provides default NEW-PSWs for each type of interrupt
when it is IPLed, and when CMS has control of the machine
(i.e., when you are in interactive command mode), it expects
that these NEW PSWs are the ones it put there originally.
If they are not, you may find yourself blown into CP or, in
more insidious cases, your terminal may simply lock and you
will have no recourse but to shut off the terminal and wait
15 minutes.
0 This type of problem can occur quite easily when a
program which traps a certain type of interrupt replaces the
default NEW-PSW with its own, and then exits, leaving *its*
PSW in place. Then an interrupt of the type that was being
trapped occurs, and the CPU attempts to branch to the user
interrupt handler, when lo and behold it is no longer in
storage... HANG!
- 10
1
0 Vm-Com Issue 2.5
0 The solution is quite simple. Before you move your
replacement PSWs into whatever NEW-PSW fields you are going
to use, simply save the current contents of those NEW-PSWs
in a special area set aside in your program.
0 Once you have SAVED any PSWs you plan to replace, the
next step is swapping in *your* NEW-PSWs. There is a
possibility of a problem here. If your program was entered
under normal circumstances, your program will run ENABLED
until you explicitly tell it not to ('ENABLED' simply means
that the system mask bits are set to allow interrupts to
occur while your program is executing). Some interrupt
handlers require intialization before they can effectively
process the interrupts they are intended to trap. If you
have swapped in your NEW-PSWs, and an interrupt occurs
before your handler's initialization is complete, your
program (and perhaps CMS) could crash.
0 The solution to this problem (if and when it is
applicable), is to DISABLE any interrupts you don't want to
occur using the IBM/370 SSM instruction. You can see an
example of this in the sample program below.
0 Now that your interrupt handler is initialized, the next
step is to place your program in a WAIT STATE using the LPSW
instruction (see programming example). Once this has been
done, your program will simply wait for an interrupt to
occur before it executes any more instructions.
0 Now let's cover a few points about the actual function of
the interrupt handler. First, When an interrupt occurs and
your handler is activated, it is important that it establish
addressability and perform any special initialization
required before another interrupt causes it to be suspended.
If the system mask of your replacement NEW-PSW is set to
zeroes as recommended above, you can be sure that another
interrupt will not grab control away from your handler. If
you want to enabled some interrupts after your handler is
initialized, simply use the SSM instruction.
0 Second, user handlers are usually set up to handle a
small subset of the possible interrupts that could occur for
a specific interrupt class (For instance, in the programming
example, the handler is intended to process interrupts on
device 009 only). If the interrupt code does not match one
of those you are attempting to process, you should transfer
control to to the default CMS handler. You do this by
executing a LPSW instruction which points to the area where
you saved the CMS NEW-PSW for the specific interrupt class.
-
-
11
1
0 Vm-Com Issue 2.5
0 Third, when your handler is DONE processing the
interrupt, you should allow the original program to resume
where it was interrupted. This is done by executing a LPSW
instruction which points to the OLD-PSW for the type of
interrupt you were handling.
0 Finally, when your interrupt-driven program has completed
its work, and is ready to return to CMS (or whatever program
called it), you should restore the CMS Default NEW-PSWs that
you saved earlier. Always do this *before* you return to
your program's caller. This way, you can be sure that if an
interrupt occurs in the future, it will directed to the
correct CMS interrupt handler, and not yours, which might
not be in storage.
0 In general, the series of steps that is involved in
setting up and using an interrupt handler is as follows:
- SETTING UP --
+ SETTING UP --
0 1. Disable interrupts by setting system mask to zeroes
0 2. Save CMS default NEW-PSWs for each type of interrupt
you plan to trap.
0 3. Move in your replacement NEW-PSWs pointing to your
interrupt handler(s).
0 4. Do any other handler initialization (if any) that is
required.
0 5. Place program in wait state
0 6. (after interrupt handler has been activated and has
finished processing) Restore the CMS default NEW
PSWs that you saved earlier.
0 7. Return to calling program (usually CMS)
- HANDLER ACTIVATION --
+ HANDLER ACTIVATION --
0 1. Save registers in a safe place and get addressability
to your handler.
0 2. Perform whatever functions you want
0 3. Clear the wait bit in the OLD-PSW for the type of
interrupt you are processing.
0 4. Load the OLD-PSW for that type of interrupt, and
resume execution in the main program where the
interrupt originally occurred.
0 12
1
0 Vm-Com Issue 2.5
0 Now that you've read through all of the preceding
verbiage, we can show you a (working) program and some
instructions on how to run it.
-
0 *
* This program places the user VM into a wait-state, and
* upon receipt of an interrupt on the console (device 009),
* will issue a standard WAITRD (RDTERM) call to read a line
* from the terminal. The input text is then stacked in the
* console buffer with ATTN, where it may be read by an EXEC
*
* This program will allow an EXEC/EXEC2/REXX program to
* issue a console-read to a full-screen terminal without
* putting up the 'VM READ' status at the bottom of the
* screen. So it actually has practical applications!
*
RDWAIT CSECT
STM R14,R12,12(R13) save CMS' registers
LR R12,R15 get a better base register
USING RDWAIT,R12 ... and tell assembler
*
* The first step is to save the CMS NEW PSW which we are
* going to replace with our own..
*
MVC CMSSAVE,X'78' save I/O NEW PSW
*
* Once the I/O NEW PSW has been saved, disable interrupts
* and move in *our* I/O NEW PSW.
*
SSM =X'00' this disables interrupts
MVC X'78'(8),OURPSW move in our PSW
*
* The basic setup of our I/O handler is complete. All that
* is left to do is put the machine into a WAIT STATE
*
LPSW WAITPSW place in enabled wait
* (all interrupts allowed)
*
* This next label is where control is passed AFTER our
* handler has finished it's work. Just drop back to CMS or
* the EXEC this program was invoked from.
*
EXIT LM R14,R12,12(R13) restore CMS' registers
SR R15,R15 make return code = 0
BR R14 return to caller
-
-
0 13
1
0 Vm-Com Issue 2.5
0 *
* This is the beginning of the handler itself. When it is
* activated (for instance when the user presses 'ENTER'),
* our I/O NEW PSW is loaded, which points to this routine.
* at that time, all interrupts are disabled, so nothing bad
* will happen to us.
*
HANDLER CLC X'38'+2(2),=X'0009' was this an interrupt
* from the console device?
*
BE CONSINT yes, it belongs to us
*
* The interrupt was on another device, so pass it back to
* CMS and let him handle it.
*
LPSW CMSSAVE give to CMS
*
* This is a console interrupt, it belongs to this handler.
* Restore the CMS I/O NEW PSW and issue the RDTERM call to
* get a line of text from the terminal. Also note that in
* this program, the I/O OLD PSW must be saved because it
* will be altered by RDTERM.
*
CONSINT MVC X'78'(8),CMSSAVE restore I/O NEW PSW
MVC OURSAVE,X'38' save I/O OLD PSW
* so we can resume later
*
SSM =X'81' enable console interrupts
RDTERM AREA1 read a line from the
* terminal
*
* RDTERM returns the number of bytes actually read in
* register 0. So we store this length into the ATTN plist
* which will allow us to stack only those characters that
* are actually significant in the line
*
STACKIT STCM R0,B'0001',ATTNLIST+12 save # of chars read
LA R1,ATTNLIST point to stacking command
SVC 202 push line into stack
DC AL4(1) ...fun constant (required)
*
* The interrupt handler is done, so return to where the main
* program was interrupted by restoring the I/O OLD PSW. NOTE
* that in this program, we must zap the second byte of the
* OLD I/O PSW save area, since the OLD PSW has the WAIT bit
* set. If this is not done, the program will go into another
* WAIT STATE again when we issue the LPSW
*
MVI OURSAVE+1,X'00' zap wait-bit to zero
LPSW OURSAVE load the I/O OLD PSW
-
- 14
1
0 Vm-Com Issue 2.5
0 *
* Following are the data areas for the program. First, the
* save area for the CMS I/O NEW PSW, then *our* I/O NEW PSW,
* then the WAIT PSW, and finally, the stacking PLIST
*
CMSSAVE DS D save area for CMS PSW
OURSAVE DS D save area for I/O OLD PSW
OURPSW DC X'00000000',AL4(HANDLER) our I/O NEW PSW
WAITPSW DC X'FF060000',AL4(EXIT) our WAIT PSW
AREA1 DC CL136' '
ATTNLIST DC CL8'ATTN' stacking command
DC CL4'LIFO' ... same as REXX PUSH
DC AL4(AREA1) area to stack
*
* Required MACRO definition
*
REGEQU
END RDWAIT
-
-
To assemble and run this program, issue the following
commands:
0 GLOBAL MACLIB CMSLIB DMSSP
ASSEMBLE RDWAIT
LOAD RDWAIT ( ORIGIN TRANS
GENMOD (SYSTEM
- The '(SYSTEM' option on GENMOD allows the program to
store in the nucleus (the OLD and NEW PSWs) without
generating a storage protection exception (which is a type
of PROGRAM interrupt!).
0 This is by no means an exhaustive tutorial on the
interrupt structure of the system/370. However, it should
give the reader with a reasonable amount of programming
experience an idea of how the interrupt system actually
works.
-
ÕThis is part three of the 370 programming series
started in issue number 2-2. -Ed.þ
-
-
0 15
1
0 Vm-Com Issue 2.5
0 Summary of CMS Release 4 Enhancements
+ Summary of CMS Release 4 Enhancements
0 Wayne Smith, U.Maine, 7/9/85
- The following information has been excerpted from various
presentations by IBM and IBM users at SHARE 64, March 1985.
- HELP Enhancements
+ HELP Enhancements
0 - TASK oriented menus have been added.
- HELP files are pre-formatted (no longer have embedded
SCRIPT commands) for faster display.
- Abbreviation/synonym resolution is available for all HELP.
- Other minor improvements have been made.
- XEDIT Enhancements
+ XEDIT Enhancements
0 - Messages are in mixed case.
- BRKKEY may be turned on and off.
- Programmed symbol sets may be used (but must be loaded
outside of XEDIT).
- A new facility exists for inputting to a file: SI, the
Structured Input macro.
- XEDIT calculates if a file is too large to edit more
quickly.
- MACLIB Enhancements
+ MACLIB Enhancements
0 - XEDIT supports the MEMBER option to edit a member of a
MACLIB.
- A new MACLIST command (analogous to RDRLIST and FILELIST)
to work with members of a MACLIB.
- EXECs in Storage
+ EXECs in Storage
0 - EXEC and XEDIT files may be loaded into storage by the user
(for example, the PROFILE XEDIT could be loaded by the
PROFILE EXEC). Functions that rely on large EXEC and/or
XEDIT files may run much faster when the EXECs are left
in storage. Examples include FILELIST and U.Maine MAIL.
-
-
-
0 16
1
0 Vm-Com Issue 2.5
0 EXECIO Enhancements
+ EXECIO Enhancements
0 - Results may be returned directly to EXEC variables. Examples:
0 EXECIO 1 CP ( VAR RESULT STRING QUERY FILES
0 Returns the result of "CP QUERY FILES" in variable "RESULT"
0 EXECIO * DISKR MY MEMO A 1 ( FINIS STEM RESULT
0 Returns the number of lines in RESULT.0 and the nth line of
the file in array element RESULT.n
- NUCXLOAD Enhancements
+ NUCXLOAD Enhancements
0 - The LOAD & INCLUDE commands allow the RLDSAVE option.
MODULEs to be NUCXLOADed do not have to be ADCON-free if
they were created using this RLDSAVE option.
- Command Search Enhancements
+ Command Search Enhancements
0 - A program now can call CMS for complete command resolution.
REXX, XEDIT, and EXEC2 use instead of each mimicing CMS
command resolution for CMS subcommands.
- TAPE Processing Enhancements
+ TAPE Processing Enhancements
0 - Support has been added for the new IBM 3480 magnetic tape
subsystem. (New options have been added for TAPE, FILEDEF,
and RDTAPE, WRTAPE, TAPECTL, and TAPESL macros).
- Standard label tape support has been improved. Information
in the header and trailer labels is written and used when
read.
- Multi-volume tape files are supported through BSAM and
QSAM (FILEDEFed files). How this support will be
integrated with the U.Maine MOUNT support is not known
at this time.
- File System Performance Enhancements
+ File System Performance Enhancements
0 Performance of CP & CMS has been enhanced when minidisks
with large numbers of files are ACCESSed.
0 - On read-only minidisks, the sorted order of files is taken
advantage of by an "index".
- On read-write minidisks, a hash table is built and used to
look up files more quickly.
- The "preferred" list of filetypes has been change to speed
looking for files of filetype: EXEC, MODULE, CMSUT1,
AUTOSAVE, XEDTEMP, XEDIT, SYSUT1, and TEXT.
0 17
1
0 Vm-Com Issue 2.5
0 Fog
+ Fog
0 Jeff Smith (RPS385@MAINE)
- ÕThis is the output from a rather unusual exec. Sounds
like real, doesn't it? You'd almost never know this is
nothing but a bunch of big words put together to make
nonsense.þ
0 As a resultant implication, any associated supporting
element adds explicit performance limits to the total system
rationale. Of course, the characterization of specific
criteria maximizes the probability of project success, yet
minimizes cost and time required for the subsystem
compatibility testing. To further describe and annotate,
initiation of critical subsystem development affects a
significant implementation of the total system rationale.
It is assumed that the characterization of specific criteria
is further compounded when taking into account the subsystem
compatibility testing. Of course, a large portion of
interface coordination communication is functionally
equivalent and parallel to the total system rationale. Thus,
the product assurance architecture mandates staff-meeting-
level attention to the sophisticated hardware.
-
-
-
-
-
-
-
-
-
-
18
1
0 Vm-Com Issue 2.5
0 OpCodes
+ OpCodes
0 Various and Assorted Creative Minds...
-
AFVC Add Finagle's Variable Constant
AT Accumulate Trivia
AWTT Assemble With Tinker Toys
BAF Blow All Fuses
BCB Burp and Clear Bytes
CDR Complement Disk Randomly
CMD CPU Melt Down
CPR Compliment PRogrammer("Aren't you cute!")
DDS Delaminate Disk Surface
DES Disk Eject Swapped
DEM Disk Eject Memory
DEI Disk Eject Immediate
DEB Disk Eject Both
DRAF DRAw Flowchart
EXX ÕA real instruction on the Zilog Z-80 --
Zilog is owned by EXXonþ
GORS GO Real Slow
HCF Halt and Catch Fire
HCRS Hang in Critical Section
HDO Halt and Disable Operator
HDRW Halt and Display Random Word
HIS Halt in Impossible State
JAA Jump Almost Always
JFM Jump on Full Moon
JMAT JuMp on Alternate Thursdays
LAGW Load And Go Wrong
LCC Load and Clear Core
LCD Load and Clear Disk
LMYB Logical MaYBe
MAZ Multiply Answer by Zero
MDB Move and Drop Bits
MLP Multiply and Lose Precision
PAZ Pack Alpha Zone
PPL Perform Perpetual Loop
RA Randomize Answer
RAU Ridicule All Users
RBT Read Blank Tape
RCCP Randomly Corrupt Current Process
RCRV Randomly Convert to Reverse Video
RDF Randomize Directory Filenames
RET Read and Erase Tape
RMI Randomize Memory Immediate
-
-
0 19
1
0 Vm-Com Issue 2.5
0 SAD Seek And Destroy
SAI Skip All Instructions
SC Scramble Channels
SCRRC SCRamble Register Contents
SD Scramble Directory
SLP Sharpen Light Pen
SMC Scramble memory contents
SOB Õa real PDP-11 instructionþ
SPSW Scramble Processor Status Word
SSB Scramble Status Byte
TLINF Teach me a Lesson I'll Never Forget
TOO Turn On/Off operator
UCB Uncouple CPU and Branch
UCPUB Uncouple CPU's and Branch
WI Why Immediate
WSWW Work in Strange and Wondrous Ways
XMB Exclusive MayBe
ZAP Zero and Add Packed
ZPI ZaP Immediate
-
-
-
-
-
-
-
-
-
-
-
-
20
|