Jump Over Left Menu
PNX User Forum, 24 June 1986
16 July 1986
Common Base Programme: PERQ User Note 8
The fourth PNX User Forum took place at Rutherford Appleton Laboratory. A mixture of progress reports, users experiences and looking to the future were combined with informal demonstrations. A question and answer session rounded off the day. The users could then take away their copies of PNX5 and PNX SR. About forty Perq users attended the meeting. These were mainly SERC grant holders and users supported by the Computer Board.
Chairman's Introduction and Welcome.
Professor R Morrison, Dept of Computer Science, University of St Andrews.
Prof. Morrison took the chair on behalf of Prof. Atkinson, who is Chairman of the Single User System Interim Panel which recently took over from SUSSG. He welcomed fellow users of the Perq. The aim of the day was to give people plenty of opportunity to talk about problems and share experiences.
Progress Report and Forward Look.
Julian Gallop, Common Base Programme Manager, RAL.
Julian began by advertising the European Perq User Group meeting on 28th-29th July, 1986. He went on to describe the present and future of the Common Base Programme (CBP) and of Perqs in particular.
There had been several changes to the staff and support arrangements since Christmas. Some people were new to Single User Systems (SUS). Ken Robinson is now in charge of the Man Machine Interaction (MMI) section of Informatics Division. CBP is in the Distributed Interactive Computing Group led by Ken Hartley. The group is split into Interactive Computing Facility (ICF) Support led by Mike Jane (grant assessments are dealt with here by Peter Hemmings), Systems and Communications led by Eric Thomas and SUS/ Applications led by Julian Gallop. Julian is in charge of CBP support and development, and graphics and text processing on Multi User Minis also. Members of the CB team are:
- Peter Kent
- Kevin Lewis
- Fran Childs L
- ynton Jones-Ng
- Software Development
- Jan Malone
- Martin Prime
- Janet Haswell
- Trudy Watson
Since January 1986 the CB Support arrangements have been to ring RAL Service Line (x6389) during working hours with problems. This has given users a chance to report problems earlier in the day and shortened the time taken to report any hardware faults to ICL. Any software problems are passed on the Common Base Support Desk which is open for 3 hours each working day. Better support for both machines in the Common Base, Perq and Sun, has been achieved this way.
Connections to Wide Area Networks (WANS) have been a problem for a long time. Three solutions are possible:
- direct to a LAN which connects to JANET is the most favoured solution.
- RS232 connection to an ICF or Unix machine which is on JANET.
- A WAN connection on the SUS itself. This is the least favoured as it is expensive and uses up resources on the machine.
So what is happening in LANs? CBP now supports Ethernet based LANs. The Cambridge Ring is no longer supported. There are many ways to provide communications over Ethernet. The problem is to choose the right one. There are some hurdles to overcome: coexistence of different manufacturers machines on the same Ethernet is one. If anyone has this problem we would like to hear about it The ISO protocols will be used so that the coloured book services can be provided on top of them. It has the advantage of being a standard and having the backing of a large company (TP4/LLCl is used by the MAPP project funded by General Motors). On top of this there will be a distributed file system. The options are NFS (already on Suns and others), Newcastle Connection over UDP or LLC1 (a problem of two low level protocols that should communicate, but do not do so) and possibly RFS (it is still on the horizon). There is the question whether to have remote paging?
At present we have NFS on the Sun and Newcastle Connection over LLC1 on the Perq. In the next six months (to be taken with a pinch of salt) the plan is to implement the Coloured Books with ISO class 4 over LLC1 on Perq, Sun and Vax 4.2BSD. Also to have NFS on the Vax as well as the Sun and to put Newcastle Connection on several machines over UDP and LLC1.
Software for Common Base Machines is classified in four groups:
- Common Base (and software using Common Base). Software that is portable across all the machines ie. GKS, F77, Pascal, 'NAG Mk 11', 'NAGGRAF Mk 2' (the first one to use GKS) and some of the Kent Tools.
- Discipline specific software. For example LISP for the IKBS community, Modula-2 for the Software Engineers and software for other engineering disciplines. This software may become generally available later.
- Experimental software. This may become generally available later. For example C++ and some of the Kent Tools.
- Non-Common Base Software which is available but has no commitment for provision on other systems. For example, ICL's TECDOC.
At present there are 130 Perq 1 (of which 100 are now maintained), 70 Perq 2, 60 Sun2 (funded mainly by Alvey) and 80 Sun3 (funded by Alvey and SERC). Only Sun3s are being purchased at the moment. All these machines will be supported for their grant lifetime. The Perq1s will not be maintained by us when their grants expire but they will get copies of PNX SR.
Looking to the future for CB Hardware, assessments of servers, low cost workstations (LCWs) and high performance workstations are being made. The goal for servers and LCWs is to maximize the facilities for the user on the money available. Sharing of facilities will take place where possible. For example discs (for paging, dumping and storage), WAN connections, and printers can be shared. Paging servers (like the Sun) will be looked at, not compute servers. We are investigating servers of this type, but actual purchase this financial year depends on funding.
SUS machines are too expensive (perq2 Â£25k, Sun3 Â£30k with sufficient disc, Â£10k discless). We have to decide what we are willing to compromise on when looking at LCWs. Software and communications interfaces are vital, especially validated software. Resolution of the screen, size and speed, and capacity all need bearable thresholds defined. We will also look at the ergonomics of the machines. They will be Unix based, either System V or 4.2BSD.
Finally Julian proposed that as there are more than one machine range in the Common Base the meeting should decide whether to have a User meeting for each machine range or to have one user meeting for all Common Base users with some machine specific talks in parallel but having joint talks on overall strategy and applications. This was discussed at the question and answer session.
Questions that followed:
- If MAPP is a major factor in LANs, when will we get involved in it and support it? We need to be compatible with Industry who are moving towards MAPP.
- The Coloured books solution is a temporary one. The immediate value of the MAPP initiative is the boost that it gives to the ISO protocols underlying it. The higher levels of the MAPP product specification are 'discipline specific', so we have no policy on MAPP at present; the appropriate Engineering Committees should push for it if they want it.
Software Tools for the Perq - Update on Kent Software Tools.
Mark Russell, University of Kent at Canterbury.
The tools described were created under a grant whereby the University of Kent acts as a software tools centre for the SERC Common Base Program. Some of the tools replace existing non graphical UNIX tools, others put a graphical interface on an existing tool. The aim is to exploit the graphics of a workstation. There are general purpose tools, for example minit, vdiff, fs and view. Also tools for software developers like ups and the menu package. Fortran tools have been ported to the Perq (various numerical libraries), TOOLPACK has been mounted with graphical interfaces to some of its tools.
The tools were then described in detail. Examples of the tools appearance on the screen are in an appendix of this report
minit is a window manager with a history mechanism. It takes a different approach to command submission, all text-entered commands are entered in the window manager window and saved in a history list. A command in the history list can be resubmitted (perhaps in a different window) simply by pointing at it with the puck. minit also provides command line editing with the puck, thus changes can be make anywhere in the command line. The history list can be saved for use in a later session. minit also provides all the window management functions of winit.
vdiff is a graphical front end for diff. It is an example of how to add a graphical front end to an existing UNIX tool. Diff is useful for comparing files, but its output is hard to read. vdiff reads this output and produces a display of the files side by side, with the differences highlighted. The user can scroll the displayed files up or down. They can also scroll left and right to see all of the longer lines on an A4 screen.
view is an intelligent file browser. It has the speed of cat with some of the facilities of spy. View tries to determine a file's type (text, font, cursor, object etc) and to display the contents of the file intelligently. A window on the flies is displayed which can scrolled horizontally or vertically with the puck. View can be used to watch growing (or shrinking!) files. It can be used in conjunction with fs.
fs is a screen editor for the file system. Files are displayed as editable objects. On the screen indentations is used to show the directory structure. Directories can be expanded to show their contents, and collapsed to hide them. Thus you can wander around the directory hierarchy. All of the commands in fs operate in the same way:
- The user selects an arbitrary group of flies and directories by pressing and dragging the puck.
- She then selects a command form the menu, which operates on the selected files. In the example given, (a copy is in the appendix) the inverted files are the selection. A command is picked from the top. View can be called on the selection. Even ownerships and permissions can be changed by editing the fields. Undo works on everything, even deleting flies.
ups is a graphical run time and postmortem debugger for C and FORTRAN programs. No typed commands are used, interaction is by selecting commands from the menu or editing displayed fields. The program being debugged (the target) runs in its own window, so program and debugger output do not interfere. When the target stops, ups displays a stack trace (a list of functions defining where the target has stopped). The users can then select any of the displayed functions and expand it to show the values of its arguments and local variables. The source of the program can be viewed in a spy-like window separately as well. An example of a C program and Fortran program were given. C structures, linked lists and F77 2 dimensional arrays can be displayed. Sadly FORT object files do not have enough information to give array dimensions and other details.
Why was the menu package written?
Menus are the standard method of user interaction for applications on graphical workstations. The design of the menu is an important factor in the user interface of a program, and in the appearance of the display. The best way to design effective menus is by experiment. So it is useful to change menus easily. Menus are not trivial to implement, especially if they are hierarchical or use popup submenus. So a need for the menu editor and the menu library was seen.
The menu package consists of the menu editor med, and a set of library routines to use the menus created with the editor. Library routines are provided to read in menus created with med, to display them and to make selections from them. The menu package provides static and popup menus, various forms of highlighting, dynamically alterable captions and multiple fonts. All the Kent software tools use the menu package for their menus. An example of med was given showing how to add a box to a menu and make a sub menu like search on spy. Different fonts can be used. The return values for the menu selection can also be defined. The menu description is written to a file. This can be read by a program if you are still experimenting (saving compilation time) and when you are happy with it, it can be included in the program to save execution time.
Finally Mark described the FORTRAN tools.
Several linear algebra libraries were ported to the Perq including BLAS, UNPACK, SPARSPAK, LANCZOS and YALE. TOOLPACK was ported to the Perq. A graphical post processor for the TOOLPACK profiler and a graphical version of the TOOLPACK formatter options tool are also available. Examples of these are in the first appendix.
- How often are the tools released?
- Some, like view, have not changed in the last six months so have had one release. Others are still under development They will eventually stabilize.
- Is the profiler for FORTRAN only?
- Is a FORT version of ups available?
- The ERCC Fortran compiler does not give enough information for ups.
- Will the profiler run with ERCC Fortran?
- Yes. It manipulates the Fortran source code.
- Are they available for Pascal?
- There has been no demand so they are not available.
- Does ups display values in an array of structures?
- Yes. Use the indirection to dereference the pointer then expand the structure.
LUNCH and informal demonstrations.
The demonstrations were:
- apple, Finite Element Analysis, B Colyer.
- Automatic Mesh Generation for Finite Element Analysis, J Tierney, Univ. of Liverpool.
- cfelap, Finite Element Analysis, G Ellis, Univ. of Aberdeen.
- Kent Tools, M Russell, University of Kent.
- pimms, Interactive Molecule Modelling, D Ricketts, Univ. of Oxford.
- satres, Electronic Circuit Design, C Downes, Salford University.
The PERQ as an Applications Development Machine.
B Colyer, Technology Division, Rutherford Appleton Laboratory.
Bryan uses Single User Systems as tools to do applications programming for research and development into Finite Element Analysis. He uses the Perq to develop programs specifically for SUSs and to develop programs that will eventually run on other machines as the development environment is good on the Perq. Most of the Finite Element work has been in processing data for 2D structures. 3D structure representation would be better so they are working towards that.
One of his projects on the Perq is a program which solves potential Finite Element problems. The program is called "apple". This is useful in electromagnetics, electrostatics, structural analysis and many other areas. He is experimenting with man machine interfaces and graphics as aids to the user who is trying to solve problems. The first work was about 4 years ago on POS using Pascal. When PNX came he used sed to help translate the programs to F77 and wrote a C interface to access the graphics primitives from F77. Algorithms for automatic meshing were incorporated and the boundary algorithms were improved. Recently the code has been extensively rewritten to improve the speed of execution of the code and the readability of the source. Better graphical display of data was incorporated. They have also written a 2D stress analysis program.
Software development was easier on the Perq than on a mainframe as the results of the program were graphical so debugging is more obvious. Spy was a useful tool.
Apple is free to academics. Commercial users have to pay for it. Contact Bryan direct for more details.
Bryan explained how they would extend the 2D meshing to 3D in apple. This is very complicated. He uses Delaunay's Lemma to calculate the mesh in 3D. Part of the mesh can be written out to a file at any time so it can be displayed separately and a few points examined.
SUS graphics enabled the models to be drawn faster and easier. A wire frame model program written about 2 years ago was adapted for present needs on the Perq. It did zoom, rotate and shift on the model. The biggest improvement to Perq is the FORT compiler as its compilation time is a lot faster. There are a few bugs in the optimising option. Bryan has a HP Laserjet printer attached to the Perq to produce high quality output and screendumps.
Why yet another Window Manager?
Dr A S Williams, Informatics Division, Rutherford Appleton Laboratory.
Tony addressed this question by talking about the Window Manager (WM) project in MMI section; its history, goals, the work and its current state.
The current work has developed from the original workstations and CBP systems development work with ICL. The aim was to have GKS input types implementable on the window manager software interface without significant degradation of response time. The WM user interface was also looked at later to see how it could be improved. The Spy editor was developed as a testbed for ideas on interaction techniques which were then included in the WW graphics library. The use of WW with spy led to WW becoming the toolkit for spy-like programs. Examples of programs exploiting WW are a clock on which the time and date can be modified using the puck, a continuous graphical ps, and a control panel for puftp.
The proposal for a Window Management project was first written in 1982 and accepted in 1983 but there was no money available from SERC at the time. It was then submitted to Alvey with no response until the MMI directorate was prompted by other Alvey directorates to produce some guidelines on Window Managers as it was essential to their work. So in April 1985 a Window Management Workshop was convened. The proceedings are published in Methodology of Window Management: Hopgood et al. eds. Published by Springer Verlag, 1986, in the Eurographics Seminar Series. Then funding was made available for work to begin on specifying interfaces to Window Management functions.
The context of the work is that applications need supportive toolkits and they need to be portable. Also new workstations need applications to be available quickly. All WMs are very different and toolkits are tied to the WM and often are proprietary. At present graphics standards are inadequate (at least current implementations are; they are slow on workstations in current active user and do not provide sufficiently responsive interaction). In short there is no single toolkit, User Interface (VI) Management System or graphics package that is suitable for all applications.
There are some standards in preparation for Window Management. ANSI is not expected to report before 1989, but MIT has the Athena project (the X window manager), IBM has Topview and PC/RT, the MAC has windows, and GEM is offered by Digital Research. ANSI may be optimistic; GKS took seven years to become a standard. MIT is public domain, free, portable and network transparent if you have the correct protocols. But the latency of I/O is not fast enough. IBMs Topview is text only. PC/RT's manager allows multiple windows but you can only see one at a time. GEM is tied to MS/DOS. The MAC and GEM are geared to a single process environment not a multi-process one. So the future is not too bright.
A solution to the problem is to design an interface that separates the toolkit from the window system. This is called the Client Server Interface (CSI). This means the toolkit may have to be ported with the application. This method is used by MIT.
The project in MMI section is simply to specify the CSI. The goals are flexibility of having different toolkits, performance (otherwise the WM won't be used), high throughput and low latency, display independence/adaptability. All user interface choices should be left open so the VI or Layout Manager can determine them as client's of the WM. It is more difficult for the program to specify what to do if we need to know the properties of menus etc. Tiling vs. overlapping, window properties, control objects, access rights and protection should all be left open to the clients decision.
The CSI does not provide windows. It does provide the building blocks for windows: a hierarchy of viewports mapped to images which are mapped to the display. Input events are passed via viewports onto queues. The hierarchy provides inheritance of position, rank, colour, depth and input properties (event masks, cursor shape) between viewports. The Layout Manager is a client of the CSI. It can take events from the background and the title bars. Typing goes to the tty or application processes. Clients may associate viewports with queues at will. The whole idea is founded on the premise that viewports and low level (pixel oriented) I/O are cheap.
The state of the project is that the CSI is having a final review with manufacturers. Next it will be circulated to the user community for comment. Emulations on the Perq and Sun are starting to be designed to test portability. Porting WW to the CSI will be done later as we need it to port our code. Discussions about the CSI on other UK machines are being encouraged by Alvey. We are looking for major applications to port to it so more people can get involved and so the concepts will be exercised in real situations.
- Does the CSI provide tiling as well as overlapping viewports?
- Yes, it provides both. The Layout manager takes the decision on which to do. We will supply a layout manager with overlapping viewport support and a terminal emulator with the CSI.
- Is this work published?
- Not in detail. The specification will be published.
- Will the restriction of not being able to select windows in software go away?
- Yes, but input cannot be stolen by other processes.
- When will we be able to port applications to it?
- Autumn 1986.
- What toolkits win be available?
- We aim to have WW ready by the end of 1986. But we can give no commitment. The GKS toolkit has no timescale.
Question and Answer Session with Panel.
ICL and RAL Support Staff.
The panel were
- J Gallop, RAL
- K Lewis, RAL Support Section
- J Steel, QMC, Computer Board Support
- B Brough, ICL Perq Business Centre
- R Verden, ICL Feltham Customer Services
- W Rowles, ICL Feltham Customer Services
Initials of the panel have been attached to replies to questions.
- Q: When will ICL deliver the new Perq?
- A: (BB) I am not authorized to answer that question.
- Q: Are you aware of price competition?
- A: (BB) Yes.
- Q: How many people will buy file servers?
- A: 6-10 possible hands up.
- Q: Is Newcastle Connection (NC) sufficient for people or do you want NFS as well?
- A: Many Perqs are isolated from other Unix machines so would not benefit from either NC or NFS. Robert Stroud said that Perqs could talk to VAXes at present but this is not available in PNX 5.2. ICL said there would be a maintenance release with fixes to some of the NC problems.
- Q: Why is PNX 5 and SR so late?
- A: (KML) This was because the firm we used to copy the floppies took 3 months to do it.
- Q: Are there any facilities to dump flies from the Perq?
- A: (BB) You could use the tape streamer and tar.
- Q: But tar is not very good!
- A: (BB) There are no plans to enhance PNX 5 for dumping files. There are no plans to make it run faster.
- Q: The Perq ethemet hardware seems to generate byte swapped packets.
Broadcast packets from 4.2 machines jam up the Perq. Perqs can send out bad
packets. Have you any comments?
- A: (BB) The PERQ2 hardware has various modification states one or more of which may help to resolve this problem. The latest hardware modification state plus the latest maintenance release of PNX5 should improve the situation but we would like to know what the effect is on the Newcastle Connection development network.
- Q: (JRG) Can we do a beta test of the hardware and maintenance release?
- A: (BB) ICL will investigate and respond in due course.
- Q: We still do not seem to have access to a known error log as agreed.
- A: (BB) No you don't We are trying to get a newsletter out instead.
- Q: If something is a known restriction is it no longer thought of as a bug?
- A: (BB) It means that ICL reserves the right to do nothing more about known restrictions, however in practice we attempt to reduce the restrictions list in each maintenance release. There are no plans to enhance PNX5 but ICL will continue to provide bug fixed maintenance releases.
- Q: Where will people with Perq1s whose grants have run out get help and support?
- A: (JRG) All the machines will get PNX SR. It is up to your department to finance the maintenance. (ICL) ICL want to pick up the maintenance of Perq1s in this situation. A discount can be given. Â£1800 a year is the price. Depending on your configuration that figure can be brought down by discounts. It depends on the number of Perq1s. This could apply to Computer Board Perqs as well. ICL will approach people with Perq1s to discuss this.
- Q: Will Perq 1 users get software such as NAG and GKS?
- A: (JRG) You will get NAG Mk 11 from SERC but nothing new after that.
- Q: The new support arrangements are working very well. Will Perq1 users stay on
the mailing list after their grant is over?
- A: (JRG) Yes.
- Q: Will ICL fix bugs that have been reported?
- A: (BB) ICL will continue to fix bugs via the maintenance release system. Which bugs are fixed in which maintenance release depends on the bugs we have fixes for at the time the maintenance release is "frozen". There is scheduled to be a maintenance release version of the PNXS FORT compiler as part of the general PNX5 maintenance release.
- Q: ICL once announced there would be intertask communication.
Is this still going ahead? We do need inter process communication.
- A: (BB) I don't know. There are no development plans for the Perq 2. (ASW) RAL will supply the PTY driver with the CSI. Everyone on the mailing list will hear about it.
- Q: I have written several letters to the Perq Business Centre and have not
received a reply. I wish to discuss applications we have developed that would be
useful to other Perq users.
- A: (BB) I cannot comment Can you send me copies of the letters?
- Q: Does the Perq Business Centre get involved with applications?
- A: (BB) In general no, but there are a few exceptions that help make Perq an effective tool. For example Kent Tools.
- Q: Can Perqs communicate with other ICL machines?
- A: (BB) Yes, use C03. It is available from Common Base Support
- Q: Is there a maintenance release of PNX SR?
- A: (BB) ICL just plan to do a PNX 5 maintenance release and SERC can do a PNX SR one based on that if they wish, with the Perq Business Centre's help.
- Q: The hardware engineers have very few spares with them and no good
diagnostic tools so they have to cannibalize users working machines. Why?
- A: (ICL) There are a lack of repaired spares. If the problem is not well defined they may bring the wrong parts anyway. There is an underfunding of the Perq repair hardware loop. The nature of the boards means we get a large number of rejects when they are repaired. We are trying to solve the problems. They still need good software tools to fmd the problem in the first place.
- Q: (JRG) Would you like a joint CBP Users meeting or carry on with
- A: About 20 hands voted yes and 1 hand voted no.
Examples of Kent Tools
- med with 2 windows and the manager driver in the bottom right.
- vdiff with diff on the same files above it.
- View on text, font and cursor files.
- Fs with the current level expanded and some files selected.
- Fs after expanding selected directories.
- Fs with view running on the selected file (an object file).
- ups on fs. Stopped at a breakpoint. A function is selected.
- Ups in window 1 with the function expanded and variables displayed. In window 2 a structure is expanded.
- Ups. Stopped on a breakpoint with the source in window 2 and the target process in another window.
- as 9 but with the function expanded.
- Values of the array TREE displayed in a separate window.
- med: menu editor. Window 2 adding a 5th option
- Window 0: giving it a string and return value.
- Window 3: equalising the boxes of the menu.
- Window 3: making a sub-menu.
- Window 0: subdividing and adding titles.
- Window 2: changing the font.
- Toolpack profiler.
- Toolpack profiler option modifier.
Figure 1: med with 2 windows and the manager driver in the bottom right
Figure 2: vdiff with diff on the same files above it
Figure 3: View on text, font and cursor files
Figure 4: Fs with the current level expanded and some files selected
Figure 5: Fs after expanding selected directories
Figure 6: Fs with view running on the selected file (an object file)
Figure 7: ups on fs. Stopped at a breakpoint. A function is selected
Figure 8: Ups in window 1 with the function expanded and variables displayed. In window 2 a structure is expanded
Figure 9: Ups. Stopped on a breakpoint with the source in window 2 and the target process in another window
Figure 10: as Figure 9 but with the function expanded
Figure 11: Values of the array TREE displayed in a separate window
Figure 12: med: menu editor. Window 2 adding a 5th option
- Window 0: giving it a string and return value.
- Window 3: equalising the boxes of the menu.
Figure 13: Continued
- Window 3: making a sub-menu.
- Window 0: subdividing and adding titles.
- Window 2: changing the font.
Figure 14: Toolpack profiler
Figure 15: Toolpack profiler option modifier
List of Attendees
Name Institution J Bovey Kent B Brough ICL Mrs M Bullen QMC Mr Cardew Sheffield D Chiu QMC B Colyer R24 5 - RAL T Conway R1 -RAL R Cooper Glasgow Mr Datardina NAG A Dearle St Andrews C Downes Salford G Ellis Aberdeen J Gallop R1 - RAL D Gibson R1 - RAL S Guest Loughborough Mr Hadjicostas QMC K Hartley R1 - RAL P Hemmings R1 - RAL B Kay UCL P Kent R1 - RAL Mr Lai QMC K M Lewis R32 - RAL J Malone R1 - RAL Prof McGreavy Leeds University R Morrison St Andrews M Prime R1 - RAL B Read R27 - RAL G Reynolds East Anglia D Rickets Oxford Univ K Robinson R1 - RAL M Russell Kent A Sherwood North Staffs Poly J Steel QMC J Stewart Southampton R Stroud Newcastle J Tierney Liverpool Dr Visvalingam Hull Univ Dr Wait Liverpool T Watson R1 - RAL