This page has been proofread, but needs to be validated.
Vol. 4/No. 7
19 June 74

Note that this change does not affect users of other terminals, such as the IBM 2741. Users with questions should contact Jack DiGiuseppe at 764-2121.

✓ PL/I Subroutines PLCALL and RAND Changed: Effective at 8:45 p.m., 31 May 1974, the file *PL1LIB acquired two changed subroutines. PLCALL subroutines have now been updated to reflect changes which were not implemented when the write-up describing PLCALL subroutine changes first appeared in the Newsletter (24 August 1973). This update makes the parameter list passed by PLCALL subprograms closer in form to those used in MTS FORTRAN. Specifically, the last word in the parameter list pointed to by general register 1 has the high-order bit set to 1. This feature can be used by subprograms that accept a variable number of parameters to determine when the last parameter has been reached.

In addition, the subroutine RAND has been extended to allow a zero argument, which is capable of automatically generating a random number based on the time of day.

✓ FREAD Available in *LIBRARY: A new free format input subroutine called FREAD is now available in the file *LIBRARY. This subroutine was written for MTS at the University of British Columbia and is specifically designed to be called for FORTRAN programs. Documentation of this subroutine will appear shortly as CCMemo 276.

✓ NEW:IEHMOVE to Replace 'IEHMOVE: A new version of *IEHM0VE has been written and is now in the file NEW:IEHMOVE, where it will remain until 1 July 1974. At that time the contents of NEW:IEHMOVE will be moved to *IEHMOVE, and the previous contents of *IEHM0VE will be moved to OLD:IEHMOVE. On 1 August 1974, the contents of OLD:IEHMOVE will be destroyed. The new version will be described soon in CCMemo 275.

The Newsletter is published every two weeks from September through April and every three weeks from May through August. Copies are freely available at the Computing Center (North Campus) and at NUBS, the North University Building remote batch station (Main Campus); they will also be sent upon request to individuals in University academic, administrative, and research units. We regret that we are unable to send copies to local users via U.S. mail, or to individual users in University residence halls. Persons not affiliated with The University of Michigan or who are not authorized users of the Computing Center may receive the Newsletter upon payment of a $10.00 yearly subscription. Checks should be made out to The University of Michigan. We will gladly exchange newsletters with other university, government, or nonprofit computing installations.

The Newsletter welcomes readers' contributions. To be considered for publication, they should bear the author's name, address, and phone number. We will withhold the author's name upon request. Communications may be sent to the editor or dropped into the suggestion boxes.

Portions of the Newsletter may be reprinted without permission so long as the source is clearly acknowledged. To avoid misunderstandings, any abridgments of reprinted material should be indicated by ellipsis marks (...) and editorial interpolations should be enclosed in brackets.

Editor: Mrs. Mary Ann Wilkes Subscriptions: Mrs. Grace Preston Computing Center 1075 Beal Avenue Ann Arbor, Michigan 48105

313-764-2121

Paging

[Editor's Note: At the request of many users as well as our own staff members, the following article is reprinted from the University of British Columbia Computing Center Newsletter. It was written by J. Berryman, and appeared most recently in its entirety in Vol. 6, Number 2, February 1974. Minor changes have been made in keeping with the minor differences that exist between UBC's Computing Center and our own.]

PART I

Certain computer systems (MTS, for one) use a process called paging to increase the effective memory capacities of their machines. To help explain this process we have invented a game that is played by the same rules as those that control the paging process. Understanding the game is easier than understanding the actual paging process, because computers usually are surrounded by an air of confusion and mystery whereas games usually aren't. Part I gives the game rules, Part II gives the corresponding rules for the actual process, and Part III discusses the object of the game and how you can make the paging mechanism work best for your programs.

The Crating Game

Rules

  1. You can have up to eight million things. So can everybody else.
  2. Things are kept in crates that hold 4096 things each. Things in the same crate are called cratemates.
  3. Crates are stored either in the workshop or the warehouse. The workshop is almost always too small to hold all the crates.
  4. There is only one workshop and two warehouses. Everybody shares them.
  5. Each thing has its own thing number.
  6. What you do with a thing is to zark it. Everybody takes turns zarking.
  7. You can zark only your things, not anybody else's.
  8. Things can be zarked only when they're in the workshop.
  9. Only the Thing King knows whether a thing is in the workshop or in one of the warehouses.
  10. The longer a thing goes without being zarked, the grubbier it is said to become.
  11. The way you get your things is to ask the Thing King. The Thing King gives out things only in bunches of eight. This is to keep the royal overhead down.
  12. The way you zark one of your things is to give its thing number. If you give the number of a thing that happens to be in the workshop, it is zarked immediately. If not, the Thing King finds the grubbiest thing in the workshop, whether it is yours or somebody else's. He packs it off—in its crate, with all its cratemates—to the warehouse. In its place, he puts the crate containing your thing. Your thing then gets zarked, even though the Thing King had to go to some trouble for you. You never know that your thing wasn't in the shop all along.
2