In this issue:

• At SUGI

• What is Object-Oriented Programming?

• NOTE: Goes on Tour

• SAS(r) With Style

• SAS Certification Survey

• Diary

• Miscellany - Joining, leaving, back-issues, and legal bits

Wow, I really enjoyed that! This year's SUGI was one of the most enjoyable SAS conferences I've had the pleasure to attend. Plenty of interesting papers (including some advance information about V9), a terrific location and weather, and a lot of people to chat to. I'm writing this on my Palm Pilot whilst on the plane home, an ideal time to reflect on what was good about this year's event.

I try to attend each SUGI in order to keep up-to-speed on all the latest technical developments. This year's event was made extra interesting for me by all the people I had a chance to chat with - many of them NOTE: subscribers. And that makes me look forward all the more to the remaining conferences I'll be attending this year. User groups should be about users and what they have to share with each other. Sharing can take the form of a paper or poster, or just an idle chat at an evening mixer. Most SAS practitioners are employed to work at a single location and their opportunities to talk to their peers are limited. User group meetings are essential for sowing new seeds of ideas, and spreading information and knowledge from site to site.

I am particularly looking forward to my return visit to the States later this year. I will be presenting papers in both Chicago and New Orleans. See NOTE: Goes On Tour for details, but safe to say I'm expecting a pleasant and informative trip. The next issue will be published soon after I return from SEUGI. If you see me around Florence , please say "hi". If you get a chance to go along to a local user group near you, make the most of the opportunity; go along, listen to the papers, and talk to your fellow delegates, there's a world of things to learn.

-Andrew
note.editor@ratcliffe.co.uk

This year's SUGI was held in a Long Beach, California. The 4,000+ delegates found Long Beach to have plenty of attractions outside of the Convention Centre; evening mixers at the Queen Mary and the Aquarium of the Pacific were both very popular.

Interestingly, the first paper that I attended on Monday morning was entitled Integrating SAS in Corporate IT. In my opinion, one of SAS's biggest challenges. I have long held the opinion that SAS is an island in the IT world where IT practitioners are unfamiliar with SAS Institute and SAS Software, and SAS practitioners pay little heed to developments in the IT world. The speaker (John LaBore) advocated greater communication and integration between SAS and non-SAS parties.

A number of papers by SAS Institute staff revealed developments planned for the V9 release of SAS - codenamed Mercury. One of the key technical enhancements is the introduction of SSA (SAS Scalable Architecture). SSA will help V9 achieve its goal of being faster.

The aim of SSA is to minimise the real-time taken to run your task. It will achieve this by using SMPs (Symmetrical Multi-Processors) effectively, by using block I/O instead of record I/O, and by using partitioned data for parallel access. Thus, a given task may use more processor time and may make the I/O channels busier, but your task will complete quicker.

SSA will first be seen in parts of V9 and will be added to more parts of SAS in an evolutionary fashion in subsequent releases. It will be available on all platforms supported by SAS Software (contrast this with SPDS which is only available on a limited number of platforms).

The first procedures to feature usage of SSA will be SORT, SUMMARY, REG, and DMREG. Those procedures will be in V9. SAS are treating this as a learning process and will roll-out more SSA-ed procedures in future releases. PROC SUMMARY will use a pipeline model to internally pass data from one stage to another without waiting for the first internal processing stage to finish. PROC SORT will use a peer model so that it will internally split the input data into a number of smaller files, sort the smaller files in parallel, and then merge the results back together.

To achieve the benefits of partitioned data, you will need to use the new SPDS data engine or one of the SAS/ACCESS engines that have been upgraded to support data partitioning (not all of the SAS/ACCESS engines will be upgraded for the initial release). The base engine will not support data partitioning, however it will make use of block I/O. Note that no performance gain via parallel data access will be seen for BY processing when using the base or SPDS engines, i.e. parallel data access is not used for BY group processing except with the new SAS/ACCESS engines.

Whilst the SSA features offer the promise of a faster SAS, remember that they may require a greater amount of tuning by the user to achieve the maximum benefit.

Other technical snippets that I picked-up include the fact that V9 will include the results of SAS's push towards centralised metadata. V9 will include an open, central metadata repository. And, I was advised by more than one source at SAS that SAS/AF Frames are best replaced with Java, a.k.a. AppDev Studio. SAS/AF, Frames, and SCL will continue to be a part of SAS Software for a long time to come, but do not expect significant developments in that area in the future. So, if you have an investment in SAS/AF technology at your site, fear not; but be aware that you should be investigating what AppDev Studio offers you in terms of client development.

Papers presented by SAS staff at previous SUGIs have been available on the web for some time, but I heard this year that the full Proceedings would be on the SAS web site, i.e. non-SAS presenters in addition to SAS staff. However, when I looked, I couldn't yet find anything. I'll keep you posted.

If you feel you missed-out by not attending this year's conference, you should know that next year's will take place between the 14th and 17th April at the Walt Disney World Swan and Dolphin resorts in Orlando, Florida.

And finally, the International team (comprising John Day, Kevin Elliot, Steve Morton and yours truly) lost the final of the SUGI quiz bowl to the SUGI Section Chairs team. Congratulations guys, but we'll be back next year! You can see a photo of the winners in the SUGI slideshow, but note the incorrect caption that suggests the International team did indeed emerge victorious!

Return to top...

In a nutshell?  An object-oriented application is based upon a model of the real world. The entities that make up the application represent real world objects or concepts. And they interact with each other in a manner analogous to the real world too. By decomposing the requirements down to small enough real world components, we can produce a system with granular objects that are flexible and easily understood by the business community as well as the IT community.

One typically expects objects to possess "state" and "behaviour". They encompass data and process for a given real world object.

Objects are SAS/AF widgets, right?  Only partly true! SAS/AF widgets are examples of visual objects, developed by SAS staff. But not all objects are widgets. If you produce an OO application it will contain a mixture of visual and non-visual (model) objects. And you will have written many of those objects yourself, it's not simply a case of using objects pre-supplied by SAS.

Is OO applicable to base SAS and macros?  Theoretically yes, but in practical terms I personally say "no". It is certainly not the case that you need an OO language to write an OO application, so there's nothing to stop you writing an OO application in base or macro. But it's a heck of a lot easier to write an OO application if your language does support OO concepts.

So what are the OO concepts that a language should support?  Well, some of the key attributes are inheritance, encapsulation, and polymorphism.

Inheritance is simply the concept that the definition of one object (class) extends another. That is to say, for example class B is the same as class A except that it has two extra methods, or maybe has the same methods but one or two of them are implemented to do different things (of a similar nature to class A's). So B inherits some or all of A's behaviour. The existence of inheritance leads to a hierarchy of classes, percolating up to a root class (the Object class in SAS/AF).

Encapsulation is a combination of modularity and de-coupling, concepts familiar to most programmers. In essence, an object's own methods are the only means of modifying an object's state (its attributes): its internal state is shielded - encapsulated - preventing direct modification by other objects.

Finally, polymorphism is the ability to handle different kinds of objects as if they are the same type; or alternatively expressed, the ability to use a single consistent technique to handle different types of objects whilst being ignorant of their differences.

For example, you might have separate classes for cars, vans, lorries, and buses. They will all share common attributes and operations, and these will be defined in the parent class (perhaps called vehicle), but the operations will be implemented differently. All these classes might have a speed attribute and they might have an accelerate operation, but the accelerate operation would be coded differently for each type of vehicle. Any other object, such as driver, can interact with a vehicle type of object without needing to know what type of vehicle they are dealing with.

In the next issue of NOTE: I will take these definitions further and put them into the context of SCL. And I will begin a short step-by-step guide to building a test harness that will be designed and built in an OO fashion. In so doing, you will see some of the theoretical aspects explained in practical terms.

Return to top...

I feel honoured to have been invited to speak at a couple of user group meetings in the States this summer. Covering the length of the country, I'll be speaking at SUCHI (Chicago) and SSU (New Orleans) in August. These are both respected events and I am hoping to learn plenty from my fellow speakers and delegates.

If you are in Chicago on Monday 20th, or in New Orleans around 19th - 22nd, come along and join the party. I'll be speaking in Chicago on Monday, and in New Orleans on Tuesday and Wednesday. I'm not looking forward to all the flying, but I know I'll get a warm welcome when I arrive.

I'll provide you with more details when I have the completed agendas.

Return to top...

This month's coding guidelines concern the clarity of the interfaces between sections of your programs. But remember, as I always say,  the most important aspect of coding standards is to have them and use them - it is not important that your coding standards match those of RTSL.

Avoid global macro variables if at all possible. Try to specifically pass information from one section of your program to another. When I see a program using a global macro variable I have no idea who created the value in that variable and who is maintaining that variable's value. On the other hand, if I see a value being passed on a parameter list, I know that the calling routine is responsible for providing the correct value.

Specific to SCL: avoid placing items in the local and global lists if you can. The issue is the same as that with global macro variables, there is no clear placement of responsibility for creating and maintaining the values.

I much prefer to see long parameter lists than macros or methods that apparently take no parameters but after investigation are revealed to use global macro variables or items from the local or global list. It seems clumsy to be coding long parameter lists, and therefore easier to just put "popular" values into widely-accessible locations so that they can be used by anybody at any time, but I usually find that a long parameter list is a sign of a macro or method that is trying to do too much. Prune the parameter list by refactoring your macros or methods.

For every entity in your application, be sure you know who is creating it, reading it, updating it, and deleting it (CRUD). An easy to remember acronym! Those four things define the life-cycle of an entity. For entities such as variables that are local to macros or methods, it is probably very clear who does what, but for more widely available entities (such as the aforementioned global macro variables and items on the local or global list), it is not so clear, and that is when having a clear CRUD definition is important.

Data sets are another good example of entities for which you should have a very clear CRUD definition. It is very easy to be writing a part of an application that needs some information, to spot that the required information is already in a data set in the WORK library, and to decide to use that. Beware, be sure you know who created that data set, who updates it, and who deletes it. And also when those events occur.

Document CRUD for all major entities in your application. I find a matrix to be a convenient way of doing this. List all components of your application down the side of your matrix, and list all major entities across the top. Place C, R, U, or D at the appropriate intersections.

Return to top...

SAS are offering a survey to get our feedback on certification. They are encouraging all SAS practitioners to participate, regardless of whether you are currently certified. If you want to influence the direction of the SAS Certification program, complete the survey at www.sas.com/service/edu/certify/survey.

Details on the SAS Certification program are at www.sas.com/service/edu/certify.

Return to top...

If I were not constrained by the need to earn money by working(!), this diary provides a guide to some of the world-wide events I might like to attend. Those marked with an asterisk are those that I will be attending. If you plan to go to any of the listed events, please let me know - I'd be very grateful for any comments after the event. And it would be nice to meet if I am going too.

May
21st - 23rd, XP2001 (eXtreme Programming), Sardinia, Italy. Premier European conference on eXtreme Programming and flexible processes in software engineering.

29th - 1st June, SEUGI (SAS European Users Group International), Florence, Italy. Premier SAS conference in Europe.*

July
23rd - 25th, XP Universe (eXtreme Programming), Raleigh, North Carolina, USA. Notable by its location!

August
19th - 22nd, SSU 2001 (Southern SAS Users), New Orleans, USA.*

20th, SUCHI (SAS Users Chicago International), Chicago, USA.*

September
18th-19th, SUGA (SAS User Group Australia), Melbourne, Australia. Premier SAS conference in Asia/Pacific.

25th - 26th, VIEWS, London, England. Premier SAS conference in UK. Dates are provisional.*

October
14th - 18th, OOPSLA, Florida, USA. Premier object technology conference world-wide.

April 2002
14th - 17th, SUGI (SAS User Group International), Florida, USA. Premier SAS conference world-wide.*

Return to top...

You can subscribe and unsubscribe by visiting our web site at www.ratcliffe.co.uk. Or, to subscribe just click here and hit the Send button in your email client; and to unsubscribe, just click here and hit the Send button in your email client. Please do not include a message in the body of the email, it will not be seen by a human!

Back issues are available on our web site at www.ratcliffe.co.uk.

Please send comments to note.editor@ratcliffe.co.uk.

NOTE: (c) 2001 Ratcliffe Technical Services Limited. All rights reserved.
5 Willow Close, Bexley, Kent, GB-DA5 1QY, England.

Republication by permission only. You may forward copies only if no fee is involved. Please encourage the recipients of the forwarded copy to subscribe and get their own free copy of NOTE:.

Andrew Ratcliffe is a registered partner of SAS UK. NOTE: is a production solely of RTSL and has no affiliation with SAS UK. Andrew is chairman of VIEWS (the UK's independent SAS user group). NOTE: is a production solely of RTSL and has no affiliation with VIEWS.

This edition of NOTE: was sent free to 348 subscribers worldwide.

This is a valid HTML 4.01 Transitional document

Return to top...