CCD Central Computing Division FORUM Computing Division Newsletter

Jump To Main Content

Jump Over Banner

Home

Jump Over Left Menu

November/December 1988

Editorial

What is Father Christmas bringing you this year? We very much hope that he will bring us a variety of enhancements to the IBM and CRAY systems. Talks aimed at purchasing an automatic cartridge store are already well advanced. This would be a device containing 6,000 3480 cartridge tapes - the square tapes mentioned in an earlier issue - and a number of tape drives with a robot to select and mount the tape. Such a device will be very necessary if we are successfully to handle the large amount of data involved with both LEP and some of the major astronomy projects. We are currently hoping that such a device will be installed in February.

As we go to press there are rumours that some of the extra money for science recently announced by the Secretary of State will be used to enhance computing facilities. We are beginning to think seriously about extra memory and SSD for the CRAY computer. In addition to this, with next year's money we are likely to be able to purchase a major enhancement of the CRAY VAX front-end facility. I hope Father Christmas is as good to you as he appears to be to us.

So after Christmas what are we planning for the New Year? Two schemes currently under investigation are likely to have an impact on our users. The first affects our two newsletters. This is likely to be the last issue of FORUM in its present form. For a variety of reasons we feel that the time has come to combine FORUM and ARCLIGHT into one bigger and better newsletter reflecting the wide range of computing activities based at the Atlas Centre.

The other area we are reviewing is that of communication with our users. Newsletters are all very well for telling you what is happening but they do not help to get your views to us so that we can take them in to account when making plans for the future of our services. We have tried a number of ways of getting your input but none have been terribly fruitful. Letters to FORUM are few and far between and user meetings have had their day - travel costs and the time involved have seen to that. So we are planning something new. We are investigating various forms of online conferencing and user meetings and I hope to be able to say more in the next issue. We really do need your views if we are to provide the sort of services which meet your needs.

So the next few months look like an exciting time for us. I hope they are for you too. May I on behalf of the staff of the Atlas Centre wish you a happy Christmas and a fruitful new year.

Paul Thompson, Head of User Support and Marketing, Central Computing Department

New Vectorising Tools

The latest release of IBM's Interactive Debug (IAD) which comes as part of the VS Fortran package contains a lot of new features. A number of these can be used to tune the vector performance of your programs.

Use of IAD to find the hotspots in your program has already been described in a user note (see FIND HOTSPOT WRITEUP). This article describes the new features available.

IAD can help you analyse the behaviour of vectorised programs by:

  • gathering vector length and stride information at run time;
  • summarising the sampling information by DO loop rather than by statement;
  • timing DO Loops;
  • displaying the compilers Vector Report in IAD's source window instead of the normal source listing;
  • displaying. using HELP. more information on Vector Report messages issued by the compiler.

Before IAD can gather information on vector length etc. the program must be compiled using the IV A suboption of the VECTOR option.

FORTVS2 TEST (VECTOR(IVA)

This creates a file called TEST PIF which will be used by IAD.

The following examples all assume the use of IAD. For example. if the file TEST FORTRAN compiled above contains a main program, then IAD is entered by issuing the command

IAD TEST

Vector Length and Stride

IAD can record the average length and stride of vectors in a program at run-time, and display the averages as well as compiler estimates for length and stride. Averages are calculated over all executions of the loop where vector length and stride recording is active.

The length of a vector is equivalent to the iteration count of the DO loop. Thus, the lengths of all vectors in one DO loop are equal. The stride of a vector is the distance between successive elements of a vector. in units of the array element size.

Length and stride statistics can be gathered for all DO loops that were analysable by the compiler. Refer to the VS FORTRAN Version 2 Programming Guide for a list of conditions that cause an unanalysable loop.

Run-time vector length and stride information can be used in several ways.

  • The average iteration count can be used in the ASSUME directive for DO loops whose iteration count could not be accurately determined at compile-time.
  • Average stride information can be used to restructure a DO loop to decrease vector strides. This improves data cache usage and thus the performance of the loop.
  • Length and stride information can be used to determine if a DO loop should or should not be vectorised. If the average iteration count of the loop is small, or the average stride of vectors in the loop is large. it may not be profitable to vectorise the loop. A PREFER directive can then be used to force or inhibit vectorisation of the DO loop.
  • Length and stride information can be compared to compiler estimates to verify that the compiler is using reasonable estimates for vector cost analysis.

The VECSTAT command is used to activate. deactivate, or reset vector length and stride recording. The LISTVEC command is used to display average length and stride for vectors. recorded during execution. as well as compiler estimates for length and stride.

To activate vector length and stride recording for a1l loops in a program use

VECSTAT *.* ON

To list the information when the program has completed use

LISTVEC *.*

To list the information just for routine ABC use

LISTVEC ABC.*

DO Loop Sampling

IAD previously allowed sampling by individual instructions. When looking for potential to vectorise it is often more useful to summarise this information in terms of DO loops.

To initiate sampling. use the ENDDEBUG command as before.

ENDDEBUG SAMPLE

Now the DOLOOP option of the LlSTSAMP command can be used.

LlSTSAMP *.* DOLOOP

to list the whole program. The list can be restricted to a particular routine by

LlSTSAMP SUB123.* DOLOOP

Timing DO Loops

The TIMER and LISTTIME subcommands can be used to obtain timing information for individual DO Loops in a program. The following prescription should be followed.

  1. Create an AFFON file to tell IAD only to use DEBUG hooks for timing DO loops. This file (called for example TEST AFFON) need only contain one line

    (ALL) * DOLOOP
    

    and should be defined to IAD before invocation by

    FILEDEF AFFON DISK TEST AFFON
    
  2. Compile the program.
  3. Invoke IAD.
  4. Issue the following commands

    TIMER * DOLOOP 
    GO 
    LISTTIME *.* DOLOOP PRINT
    

This will run the program, time the DO Loops and write the information to the print file.

By compiling with the VECTOR(IV A) option and by using the PREFER VECTOR and PREFER SCALAR directives to control vectorisation, the effect of vectorisation of the execution time of DO loops can be observed.

Displaying the Vector Report and error messages

If the program to be debugged was compiled with the VECTOR sub-option REPORT(SLIST), eg

FORTVS2 TEST (VECTOR(REPORT(SLIST))
NOSOURCE

when the program is run under IAD, the vector report will be used to display the source. This vector report shows which loops were vectorised and displays the messages explaining why vectorisation was inhibited. A fuller explanation of these messages can be obtained by placing the cursor on the line containing the message number and pressing the HELP function key (PF1).

References

Further information on the IAD subcommands mentioned here can be found by typing FIND IAD in CMS or in the Interactive Debug Guide and Reference Manual (SC26-4223-2).

John Gordon, User Support and Marketing Group, Central Computing Department

RIP MUGWUMP et al

We have now decided that support of the MUGWUMP, GINO-F and SMOG graphics systems (and libraries based on them) on the IBM Central Computer will be ended on April 1 1989. We have given a course on conversion from these packages to the new systems (GKS, NAG, UNIRAS) and are happy to give the course again, in January or February if more users want it. Please contact Garry Williams if you would like to attend and David Greenaway if you require any assistance with converting programs.

Chris Osland, Head or Graphics Group, Central Computing Department

National Information on Software and Services Bulletin Board

An online information service: the NISS Bulletin Board (NISSBB), may be used from any terminal/workstation which can be connected to the Joint Academic Network (JANET). In most cases you will connect to any JANET host computer (including your "local" computer systems) through a PAD unit. If you are not familiar with what is involved your computer service will be able to advise you.

The JANET address of NISSBB is 000062200000. Needless to say this is not terribly memorable ... but hopefully you will find NISSBB of sufficient interest that the address will become etched on your brain in due course! However, it is possible for PADs to be made to recognise the names of certain "popular" services, and we hope that many computer services will add the name NISS to their PAD units; this would allow you to call up NISSBB by simply typing:

CALL NISS

So, why should you be interested in NISSBB? No matter what your involvement in computing it is likely that you will face problems which others have already faced, or you may be working in a fairly specialised area in which there is little local expertise. Some people who are "in the know" already use JANET to participate in special interest groups, mailing lists, bulletin boards etc which already proliferate. However, many are not so well-informed and for some time there has been a need for a national online information service: a focal point for the numerous information sources which already exist. Needless to say this is an ambitious undertaking, and one which can only be realised if you participate and share the knowledge that you have.

NISSBB is so easy-to-use that I daren't waste your reading time by describing it here. There are no registration formalities to complete. so when you call 000062200000 you are led directly into the top-level menu:

MAIN MENU

A  Introduction to NISSBB 
B  The NISS Catalogue 
C  Academic Computer Services 
D  National Computing Initiatives (CHEST. CTISS, NISS) 
E  Library Services 
F  Online Information Sources 
G  Computer-Related Job Vacancies 
H  Computing Groups and Committees 
I  Machine-Range User Groups 
J  Software User Groups 
K  Conferences and Courses 
L  Joint Academic NETwork
M  Main Menu
N  Sciences 
O  Social Sciences 
P  Medicine 
Q  Engineering 
R  Arts and Humanities

Y  Comments
Z  Table of Contents

Each of these sections lead onto other menus and other sections. You can display the contents of any one of these sections by simply typing in the appropriate key.

Because NISSBB is designed to be easy-to-use over a computer network, from anyone of a vast array of terminals/workstations, and by a potential audience boasting varying degrees of computer-literacy the facilities offered are few in number and deliberately simple. The most glaring limitation at present is the absence of a sophisticated and comprehensive index/search facility: (this is something planned for NISSBB Mark II). There is however a useful, if rather simple. basic section search facility.

Section A (together with the HELP, HINTS and SEARCH commands) tells you all you need to know about how NISSBB is structured and what facilities it offers. For example Section A4 describes how to download information from NISSBB onto your local computer system, should you want to print it out.

Section D covers national computing initiatives such as NISS, CHEST and CTISS. Under Section D3, on CHEST, you will find details of the current educational discounts available on all kinds of computer software, the "CHEST Directory of MicroSoftware Prices". and the current list of public-domain software held by the Lancaster Micro Service. with instructions on how to download the software to your preferred system.

Under Section D4. on CTISS. you will find details of the majority of the 139 "Computers in Teaching Initiative" projects. Many of the projects have come to fruition, having produced CBT software which may help you in your teaching. Why re-invent the wheel when a quick check will put you in touch with colleagues who may have something which you can use or easily adapt?

Under Section D2, on NISS. you can read about the NISS "Software and Datasets Catalogue" which is the other main service under development within the NISS project. Work on the Software Catalogue is progressing well, and details are given on how to register to look at the current "pilot" service.

Section F holds details of other sources of information which are available to you either over JANET or further afield. There are hundreds (if not thousands) of special interest groups who use electronic mail or Bulletin Boards to correspond; we have details of a few.

Section G has been set aside to advertise computer-related job vacancies. Advertisements can be placed free of charge for the remainder of 1988 - after that there will be a charge; mail NISS@SWURCC for more information. At the time of writing there are at least four vacancies in the UK computing industry: one of them being for a "Bulletin Board Administrator" within the NISS Team!

Section H is given over to publicise the work of the many computer groups/committees which are run by the IUCC and PCCC. (Also of interest in some quarters will be Section C2 which has entries for each PCCC/IUCC computer service.)

Finally you are directed to Sections N-R, which are devoted to publicising information which is academic discipline-specific. Although there is not a lot of information here at the moment, these sections are set for healthy expansion. Geography. for instance, will have a substantial amount of information online within the next month.

You should be aware that the "team" looking after the Bulletin Board information consists of about half of one person (bits of three people in reality), so you can help us out by supplying information which is currently lacking. and please be patient. Our aim is to establish NISS as a worthwhile service by November 1990!

The Bulletin Board is gathering contributors as it rolls along. but I would particularly like to thank Peter Abbott (Aston University) for his help with sections C and D. Janet Wheeler (University of Newcastle) who is looking after section F, and Jim Morris (University of Leicester) who is the author of the underlying software.

Please try out NISSBB (JANET 000062200000) and pass on the word if you find it useful. If you feel that there is a section of information not represented on NISSBB and you think that you are well placed to manage such a section. please get in contact with us.

Rob Armstrong, Information Services Manager, National Information on Software and Services

VAX (VMS) User Group Meeting

The nineteenth meeting of the SERC VAX/VMS User Group was held in London at the Institute of Mechanical Engineers on Wednesday, 26 October, 1988, with twenty three members attending. The morning session was quite "political", involving discussion of member's relationships with RAL, the Computer Board, CHEST, JNT, WNUG, UWIST and DEC, though we still found a little time to exchange some technical tidbits politics spilled over too into the special afternoon session where the focus was provided by the presence of representatives from DEC.

In the last edition of FORUM it was reported that a letter would be sent to Paul Thompson (as Head of User Support and Marketing) summarizing the VUG members' priorities for requested RAL support. This has now been done and Paul was able to make his reply at the VUG meeting. (The letter itself is reproduced after this report.) Essentially Paul replied positively to all seven recommendations, though he pointed out that provision of extra personnel and/or funding was inevitably a long-term process and success could not be guaranteed. He also explained that any broadening of the scope of R.AL VMS support beyond networking topics would involve modifying the terms of reference for CCD "infrastructure". Nonetheless Paul promised to make his best endeavours to meet the VUG recommendations, and indeed thanked the group for its input.

Paul Thompson also presented his revised proposal for the terms of reference of the VAX/VMS User Group, which now includes explicit provision for access to both the Head of User Support and Marketing and the Head of RAL Central Computing Department. The meeting was happy to accept this proposal in its new form.

On then to networking. Peter Chiu's status report pointed out that the current version of PSI is 4.2, but that until version 5 of the Coloured Books Software is available. JANET sites would have to stay with version 4.1 of PSI (and version 4.7 of VMS). RAL support will distribute PSI 4.2 to sites on the central contract as soon as it is to hand, but the CBS-5 distribution depends on DEC. Bob Cranfield reported that he had been told by people within DEC that users would be lucky to see CBS-5 by Christmas. This news is of course highly regrettable, since it mean that most academic sites will not yet be able to move to VMS-5 (DEC's major new operating system release), despite having received their upgrade kits some two months ago. The VUG has been exerting considerable pressure on DEC via the Chairman and the RAL Support Team, as well as at the individual member level, to accelerate the distribution of CBS-5 and to ensure that this kind of problem does not occur again. During the afternoon session Tony Cleaver from DEC assured the meeting that he was doing his best to ease the current problem, but it was still not clear how DEC intend to cope with future upgrades.

Another networking issue that clearly caused alarm among the VUG membership was the reported breakdown of communications between the VAX/VMS Networking Group (WNUG) and DEC. Members believe it is crucial that a good working relationship be maintained with DEC throughout the delicate transition to OSI standards. The meeting accordingly asked the Chairman to write to both the Chairman of WNUG and the Head of the Joint Network Team to request that strong efforts are made to re-establish proper interaction with DEC without delay.

Yet more alarm was caused by the report that CHEST are currently negotiating with DEC over software licensing terms. The alarm was due to the fact that most members had been unaware of the imminent possibility of a licensing arrangement that may well become their only discount option and yet is being negotiated without their representation. The group stressed later in the day to Tony Cleaver from DEC's educational account team that there are a large number of academic and research installations which are very interested in special arrangements for purchasing and or maintenance of hardware and software and yet are not represented by the Computer Board or its offshoots.

Before breaking for lunch the group just had time to hear from Nick Hill, the new representative from the RAL CCD graphics group, of the release of RAL GK.S 1.11, which now supports the workstation independent segment store. There was also interest expressed in interfacing Exabyte cartridge tape systems and a warning that some non-DEC equipment may not operate correctly with QBUS on the 3000 series MicroVAX's.

We were joined in the afternoon by our guests from DEC. Tony Cleaver introduced himself and described the new educational account team to which he now belongs, together with James King (the account sales manager). Terry Hookwav and a field service representative. Being new to the account Tony warned us that he would have to largely sit and listen. In the event I think he found there was plenty to listen to and hopefully he will have taken back some useful input for the account team's planning.

In the second half of the afternoon one of DEC's technical experts, Andy Williams, gave an overview of the delights awaiting us in version 5 of VMS, being closely questioned in particular about the intriguing new licence management facility. Having whetted our appetites for many goodies such as symmetric multiprocessing, mixed interconnect clusters, system management facilities, cluster management, and RMS enhancement, we can only hope that CBS kits arrive soon so that we can start to sample the wares.

Copy of letter from the VUG chairman to the Head of User Support and Marketing

Dear Paul,

I am writing to you on behalf of the SERC-funded VAX/VMS User Group to express our concern over the current level of central VAX/VMS support. As you will know the VUG has devoted a considerable proportion of the discussion time during its last few meetings to the question of central support. Throughout these discussions members have been essentially unanimous on the desirability of extending the role and capacity of the RAL VMS support team(s).

VUG members have varied interests however, and it has been difficult to establish a clear consensus on priorities. In view of this members were asked to rate their priorities in some detail prior to our recent meeting in London. The responses were summarised at the meeting and there followed a discussion in which it we attempted to examine both the justification of members' support requests and the feasibility of meeting them. I was subsequently commissioned by the meeting to send you a summary of this summary, which I have done below.

Having been circulated with this summary the VUG membership would now like to append the following series of recommendations:

RECOMMENDATIONS:

  1. THE VAX VMS SUPPORT TEAM SHOULD BE RETURNED TO COMPLEMENT WITHOUT DELAY.
  2. THE SUPPORT TEAM SHOULD BE GIVEN A MANDATE TO TRACK DEC'S OSI TRANSITION PLANS AND PROVIDE CONSEQUENT ADVICE TO VMS USERS.
  3. IT SHOULD BE A RECOGNISED ROLE FOR THE SUPPORT TEAM TO PROVIDE ADVICE ON GENERAL (NON-NETWORK) VMS ISSUES.
  4. THE VMS SECTION OF THE RAL GRAPHICS TEAM SHOULD LIAISE WITH USERS OVER PRIORITY DETAILS.
  5. RAL VMS SUPPORT TEAMS SHOULD CONTINUE TO LIAISE WITH RAL DATA HANDLING DIVISION ON AREAS OF MUTUAL INTEREST.
  6. PROVISION SHOULD BE MADE FOR THE POSSIBLE ACQUISITION OF FURTHER HARDWARE AND SOFTWARE TO ENABLE THE RAL TEAM TO CONTINUE TO PROVIDE RELEVANT SUPPORT. Since the above recommendations imply a significant increase in the area of responsibility covered by the RAL support team, VUG members would like to add the further important recommendation that:
  7. RAL SHOULD MAKE PROVISION TO INCREASE THE SIZE OF THE VAX VMS SUPPORT TEAM IN ORDER TO PROVIDE THE REQUESTED EXTRA USER SUPPORT

Yours sincerely,
Bob Cranfield - Chairman, SERC VAX/VMS User Group

SUMMARY OF SURVEY AND DISCUSSION ON CENTRAL VMS SUPPORT:

I believe that several points were clear from the survey results. These are itemised below, together with comments arising from the ensuing discussion.

  1. WIDE-AREA-NETWORK (WAN) SUPPORT OF THE KIND CURRENTLY PROVIDED WAS RATED 10 (OUT OF 10) BY ALMOST ALL RESPONDENTS.

    It is most important to point this out, not only because it confirms earlier perceptions of priorities, but also because the recent departure of Sue Weston from the team inevitably triggers some apprehension as to whether support can be maintained at existing levels.

  2. THERE IS A GROWING INTEREST IN ISSUES THAT ARISE FROM LOCAL NETWORKING ARRANGEMENTS, SUCH AS DECNET, PSI-ACCESS, PINK-BOOK AND LAVC.

    Such topics, together with DEC's own plans for OSI transition, form a potential support area that will become increasingly hard to distinguish from the "mainstream" WAN issues.

  3. THE REQUEST FOR GRAPHICS SUPPORT WAS REASONABLY STRONG. BUT SPLIT BETWEEN DIFFERENT FACILITIES.

    The situation with respect to graphics has changed significantly from when members initiated the lobby for support on VMS systems. This is mainly because the VUG membership is now split according to which flavour of GKS is relevant to them. Members from the HEP world now have little interest in the RAL implementation since most HEP collaborations are committed to the GTS-GRAL product. Nevertheless graphics support in some form is clearly a fairly high priority for most members. The recent decision to provide a VMS support person in the RAL graphics team seems therefore quite justified, particularly in view of the joint arrangements with the Data Handling Division which should provide a mechanism for covering both RAL and GTS-GRAL implementations of GKS. It should be noted, though, that members were concerned that the graphics support team should not try to cover too broad an area and that close attention should be paid to the real priorities of VMS users.

  4. SUPPORT FOR GENERAL (NON-NETWORK) VMS TOPICS IS A HIGH PRIORITY FOR MANY MEMBERS.

    There was a strong feeling among many members that the RAL team could usefully provide general VMS advice as well as acting as a clearing house for problems and tips. This is in fact a role that they already play, but it was felt to be important to put this service on a more formal footing, particularly in view of the increased demands that networking is likely to put on people's time.

  5. CERN LIAISON AND COMMUNICATION WITH IBM SYSTEMS ARE BOTH HIGH PRIORITIES FOR HEP SITES.

    The liaison aspect (in the sense of coordinating use and distribution of CERN software) is arguably more appropriately covered by RAL Data Handling Division, but communication between CMS and VMS systems is surely an area in which RAL should take some responsibility.

    At the meeting there was also discussion of the possibilities of the support team organising central purchases and/or providing a "test-bed" for new hardware and software products. It was felt that such possibilities should not be ruled out (indeed both have occurred in the past), but it was likely that the RAL support setup may not be the most appropriate vehicle in many cases.

SUMMARY OF REPLIES TO VUG "RAL SUPPORT QUESTIONNAIRE"

SUPPORT AREA SITE PRIORITIES
U
C
L
R
L
V
J
L
E
V
A
O
X
P
H
L
B
I
O
K
C
L
Q
M
C
S
U
S
S
B
R
U
N
M
S
S
L
R
L
V
I
S
T
A
R
R
G
O
R
L
V
2
M
A
N
WIDE AREA NETWORK ACCESS 10 10 10 10 10 10 10 10 10 10 10 10 8 10 10
SECURITY 10 10 10 8 10 10 10 10 10 10 10 10 10 10 10
RJE TO RAL/CERN IBMS 9 2 1 10 0 0 9 0 4 0 0 0 0 7 9
CMS FULL-SCREEN ACCESS 9 4 2 10 2 0 8 0 6 0 0 7 0 9 9
MAILSHARE INTERFACE 8 8 8 10 8 8 5 0 8 8 5 10 4 9 9
GIFT - - - - - - - - - - - - - - 9
CERN LIAISON 6 0 1 9 0 1 6 0 7 0 0 0 4 2 8
DESY LIAISON - - - - - - - - - - - - - - 8
DECNET 8 8 7 - 8 8 6 5 8 8 10 7 10 2 8
PSI-ACCESS 4 1 2 10 1 8 0 0 4 5 0 7 9 0 6
PINK-BOOK 2 1 8 - 8 8 8 0 2 4 10 7 - 7 6
RAL GKS 0 8 0 0 0 0 0 0 0 6 10 10? 10 5 0
GTS-GRAL GKS 6 0 1 5 1 6 7 0 8 4 0 0? 0 3 8
UNIRAS 3 1 5 - 1 3 0 0 - 3 5 - - 0 0
NAG GRAPHICS 2 6 2 - 0 2 2 0 2 2 5 0 - 1 1
OTHER GRAPHICS? - - - - - - 0 - 8 0 0 - - - -
LAVC MANAGEMENT 8 0 7 - 8 8 6 0 8 8 0 3 8 2 8
LARGE CLUSTER MANAGEMENT 0 0 1 - 0 - 0 0 0 0 0 3 0 0 0
VMS: UPDTS, RELS, FLD TESTS 9 9 9 - 9 9 6 3 9 9 3 3 10 5 9
OTHER VMS 6 6 6 - 5 6 5 3 6 4 2 3 9 3 6
OTHER NON-NETWORK TOPICS - - - - - - 0 - - 0 0 - - - -
VAXSET - 6 - - - - - - - - - - - - -
SIMPLE MAILING LIST - 2 - - - - - - - - - - - - -
ORGANISING VMS COURSES - - - - - - - - - - - - - 8 -
ORACLE DATABASE 4 0 1 0 2 0 6 0 4 0 1 - 0 3 4
BULK SOFTWARE DEALS - - - 6 - - - - - - - - - - -
HARDWARE SOFTWARE TRIALS - - - 6 - 7 - - - - - - - - -

- means no comment
? means my own interpretation of written comments
0 means low interest
10 means high interest

Bob Cranfield, UCL, HEP VAX User Group Chairman