Bayshore Advisor, Autumn 2005

1

Bayshore Advisor, Autumn 2005

2

Bayshore Advisor, Autumn 2005

3

Critical Recent IBM APARs for zOS, DB2 and CICS

z/OS OA09993 (DFSMS for z/OS 1.5 and 1.6) Increasing SMS Space Usage in Subpool 230. SMS message buffers containing message IGD17239I are not freed after the SSSA11 EOV synchonization function has completed. The SMS space usage in subpool 230 gradually increases until the address space runs out of space. This is due to SMS not freeing the message cell pools created for the message. FUCNTIONLOSS. OA10351 (z/OS 1.4 and higher) WAIT0A2 RSN09C Due to Improper Recovery in IXCL1RS After VSM Error. A WAIT0A2 RSN9C error may occur following a VSM abend while building a channel program for a read request for a couple data set. An unexpected error during the GETMAIN of a CCW buffer by IXCL1IOP results in an abend S00C-124 and then a wait WAIT0A2-9C.

The recovery routine within module IXCL1RS did not properly handle the error. This affects any data center using any type of couple data set.

he GETMAIN of a CCW buffer by IXCL1IOP results in an abend S00C-124 and then a wait WAIT0A2-9C.

The recovery routine within module IXCL1RS did not properly handle the error. This affects any data center using any type of couple data set. 0A10761 (z/OS 1.4 and higher) 0A10761 (z/OS 1.4 and higher) PAV Alias Movement does not occur on some devices if the system has been IPLed for at least 50 days.

PAV Alias Movement does not occur on some devices if the system has been IPLed for at least 50 days. On systems with WLM Dynamic Alias management enabled, some devices may not be receiving additional PAV alias even though there is significant queue delay. This problem can occur anytime after the RRPATOD field wraps, which is approximately 50 days and 21 hours after an IPL. SMP type 99 trace records 996 or 988 will show the device is a candidate for additional aliases, but the move is stopped because SRM believes the one minute time limit between alias moves has not yet expired. A local fix for the device is to vary it online and then offline. This will reset the time of the last alias move and allow SRM to add aliases for the device. FUNCTIONLOSS.

On systems with WLM Dynamic Alias management enabled, some devices may not be receiving additional PAV alias even though there is significant queue delay. This problem can occur anytime after the RRPATOD field wraps, which is approximately 50 days and 21 hours after an IPL. SMP type 99 trace records 996 or 988 will show the device is a candidate for additional aliases, but the move is stopped because SRM believes the one minute time limit between alias moves has not yet expired. A local fix for the device is to vary it online and then offline. This will reset the time of the last alias move and allow SRM to add aliases for the device. FUNCTIONLOSS.

M

OA10881 (z/OS 1.4 and higher)

essage IXL008I on D/T 2084 attempting to gain connectivity after a CF Model Number change. The z990 and z890 processors have the ability to upgrade their CPU models concurrently. This causes the model number in the hardware node descriptor to change. A coupling facility running on one of these processors where the model number changed due to a capacity upgrade will not be able to re-connect due to a node desciptor comparison failure. This will cause z/OS to issue

Bayshore Advisor, Autumn 2005

4

MSGIXL008I indicating that the coupling facility links have been invalidated. This problem will affect users who are running in a Parallel Sysplex configuration with one or more coupling facilities residing on z990 (2084) or z890 (2064) processors. Flagged as IPL, FUNCTIONLOSS, PERVASIVE SYSPLXDS. OA11161 (z/OS 1.4 - 1.6) When Multiple ROUTE *ALLs are issued the Responses are Delayed. When issuing multiple multi-system ROUTE commands, the second and subsequent commands are delayed. Message IEE421I may be received to indicate that no response was received from some systems. When the command response of the routed command is issued there is a POST to indicate to the ROUTE processor that at least one message has been issued by this system for the command. The POST only occurs on the system where the ROUTE command was issued. The other systems are waiting for the ROUTTIME to expire before continuing. The other systems are waiting for the ROUTTIME to expire before continuing. A local fix is to issue ROUTE commands with a T=0 parameter. This affects all users running in a sysplex that issue multiple multi-system ROUTE commands at the same time. FUNCTIONLOSS SYSPLXDS.

OA11307 (z/OS 1.4 and higher) Allocation Slowdown Due to loop in IEFAB482. Slow performance may occur during tape allocation processing when a job allocates a large number of tape devices combined with a large volume count request on one or more of those devices. This happens because the allocation routines generate an excessive number of CTRACE records in some allocation situations. A local fix is to reduce the volume count specified. PERFORMANCE, PERVASIVE. OA11432 (DFSMS for z/OS 1.3 and higher) Master Catalog Volume left reserved after Import of User Catalog. After an IMPORT of a user catalog is performed, an ENQ for the SYSIGGV2 resource may be left outstanding. This can affect subsequent operations because it is the resource name used for the Master Catalog. During the process of moving a catalog from one volume to another via the EXPORT TEMPORARY and IMPORT, the volume containing the master catalog of the host system was left reserved after the IMPORT completed. The volume also contained master catalogs for other systems in the data center and the outstanding reserve on the volume prevented access from the other systems resulting in errors IOS071I START PENDING and IOS431I DEVICE RESERVED on those systems.

FUNCTIONLOSS, PERFORMANCE. OA09649 (z/OS 1.4 and higher) An installation may find fewer CPUs online after system initialization than in the prior IPL. During system initialization, module IEEVCPUT configures processors as needed to achieve the initial number of configured CPUs as defined for the logical partition. A mechanism is needed to bypass this processing. This APAR adds a new PRESCPU parameter for the IEASYSx member of SYS1.PARMLIB. Support is also provided to recognized this parameter and to cause IEEVCPUT to bring logically online all CPUs (and only those CPUs) that appear as physically online, when PRESCPU is coded. ATTENTION, NEW FUNCTION.

The following RedAlert was issued on 26 July. (RedAlerts point you to especially important APARs and are kept to a minimum - the last one was in February.) You can sign up for RedAlert emails at https://techsupport.services.ibm.com/server/redAlerts.

Bayshore Advisor, Autumn 2005

5

Users of Hierarchical File System (HFS) on z/OS 1.4 through 1.7 "Users of Hierarchical File System (HFS) on z/OS 1.4 through 1.7 may experience a hang with HFS holding the MOUNT latch and/or a VFS latch after a Cancel of a HFS Directory Search operation. Please see OA11041 for details. The only possible recovery action is to IPL. Please install the applicable PTF for DFSMS releases 1G0, 1H0, or 1J0 to prevent the problem."

DB2 OA03194 can cause DB2 to hang or have severe performance degradation. OA03194 changes the limit for the number of SRBs that XES schedules for an exploiter address space. The new limit is one less than the number of processors active in MVS. This change can negatively impact

DB2 IRLM notify and contention exits, which can cause DB2 to hang. Review OA12848 for a more detailed explanation and a workaround.

CICS hangs. From an MVS perspective, the QR TCB is in an 0A01 wait out of DFHDSDS3. CICS 2.3

APAR II10817 This is an information APAR that documents problems in storage leaks in DB2. It lists the DB2 R610 R710 R810 and IRLM R101 and R220 storage usage errors. These problems can cause DB2 outages and should be checked on a regular basis.

PQ90873: DB2 REQUEST UNDER THE L8 TCB, AND SUBSEQUENT ABEND CAUSE THE L8 TCB TO BE USED INSTEAD OF QR, THIS LEADS TO A SET LOGON HOLD CICS hangs. From an MVS perspective, the QR TCB is in an 0A01 wait out of DFHDSDS3.

CICS PQ88234: DFHSM0133 CICS SHORT ON STORAGE ABOVE 16M LINE. ECDSA SUBPOOL USXDPOOL

USA_XMTRAN_SPTOKEN

DFHUSXM USXM DFHICP START

CICS 2.2 PQ90873: DB2 REQUEST UNDER THE L8 TCB, AND SUBSEQUENT ABEND CAUSE THE L8 TCB TO BE USED INSTEAD OF QR, THIS LEADS TO A SET LOGON HOLD

Storage creep in ECDSA, ophaned storage left by DFHICP.

Bayshore Advisor, Autumn 2005

6

IBM Recent Statements of Direction

These are the published IBM statements of

direction for z/OS 1.7.

• The zSeries File System(zFS) will become the strategic file system for z/OS UNIX files. Although HFS(Hierarchical File System) data sets will still be supported, those functions have been stabilized. This means that future enhancements and features will be added for zFS data sets, but probably not for HFS datasets.

• Support for the ISAM access method will be removed. Attempts to open an ISAM data set will cause an open failure.

• JES2 will no longer support compatibility mode which allowed JES2 to operate using a z/OS 1.2 format checkpoint data set. This was designed so that users could start JES2 with an older format of the checkpoint data set and then enter the JES2 activate command to dynamically convert it to the newer format. If you have not already done this, then you will need to issue the $ACTIVATE command before migrating to z/OS 1.7 or you will need to use the spool offload/reload functions to transfer jobs and output to the new JES2 system.

• Support will be dropped for the JOBCAT and STEPCAT JCL DD statements. Any job that attempts to use these statements to access private catalogs will be failed. A feature is available in z/OS 1.5 and z/OS 1.6 that will allow you to detect the use of these statements, and to even cause these jobs to fail if you choose.

• The OS/390 V2.10 C/C++ compiler will no longer be supported. Starting with z/OS 1.2 both this compiler and the ISO C/C++ compiler has been provided. But the OS/390 V2.10 C/C++ compiler was only intended as a migration aid to the ISO C/C++ compiler, and so it will not be supported after z/OS 1.6

• Support for 1 byte Console IDs and external interfaces supporting migration console IDs will be dropped. This will cause errors if you try to use a 1 byte Console ID in an operation command or with the WTO, WTOR, and MCSOPER macros. Programs that were compiled with the older versions of these macros will continue to work, although errors will occur the next time you try to compile them without changing the macro format.

The following Statements of

Direction apply to releases

beyond z/OS 1.7.

• Support will be dropped for VSAM attributes IMBED, REPLICATE, and KEYRANGE. These attributes currently provide worse performance and waste space and they should be removed as soon as possible.

• After z/OS 1.7 the Integrated Security Services element will no longer include the Firewall Technology component. The following functions will be dropped: ♦ FTP Proxy services ♦ Socks V4 services ♦ Network Address Translation ♦ RealAudio support.

Some of these functions are being replaced by improved functions in the Communications Server component.

• After z/OS 1.7 support will be dropped from the z/OS communications server for ♦ ASSORTEDPARMS statement in the

configuration profile block definition ♦ KEEPALIVEOPTIONS statement in the

configuration profile block definition. ♦ PAGTSNMP subagent. ♦ Defining Enterprise Extender

Tranmission Groups (TG) will multiple service Access Point (SAP) addresses.

♦ AnyNet definitions. • After z/OS 1.7, all support will be dropped for

console messages with 1 byte console IDs.

The entire list of the IBM Statement of Direction is available at www.ibm.com/servers/eserver/zseries/zos/zos_sods.html

Bayshore Advisor, Autumn 2005

7

Featured Article

SYSDA and the use of ESOTERIC names and EDT By Martha Hall, Bayshore Senior Consultant This article will discuss the use of Esoteric names for device allocation and how to generate them using the EDT (Eligible Device Table). The UNIT parameter in the JCL identifies the device or type of device on which a dataset will be allocated. You can use an Esoteric name or a Generic name or a device number in order to map the allocation to a volume or a pool of volumes. Historically, in the west, before SMS we have used Esoteric names to specify pools of DASD for allocation. We should first define several terms. A Generic name is a name generated by MVS when it finds devices that have similar characteristics. An example is 3390. In your JCL you would code UNIT=3390. An Esoteric name is a logical name given to a group of devices that can include devices of different Generic device types. This means that I could have an Esoteric name that contained 3380 and 3390 devices. All of the devices specified to an Esoteric name must however be of the same device class, with one exception. You can, in fact, have an Esoteric group that contains both DASD and TAPE classes. So we can see that Esoteric

names are installation defined grouping of IO devices. Devices belong to one of the following classes:

CTC adapters DASD devices Display devices Tape devices Unit record devices like

printers Communication devices

Since it is sometimes desirable to segregate groups of devices or pools as they are commonly called, Western data centers will usually use an Esoteric name rather than a unit name or a generic name for allocation. As an example I could have a pool or Esoteric called IMSTST which is an Esoteric group name for three 3390 devices (device numbers 284, 394, 494). I could have another pool called IMSDEV that contains five 3390 devices (device numbers 183, 283, 383, 583, and 583). In my JCL, I can then specify UNIT=IMSDEV or UNIT=IMSTST as my job requires. This will separate the data allocations for IMSTST and IMSDEV. I could also have JES2 exits to enforce these

allocations, which is also commonly done in the west. SYSDA is a commonly used Esoteric name and is frequently used in JCL delivered by both IBM and third-party vendors. It is therefore recommended that you define your complete DASD pool as SYSDA. This will avoid potential JCL or dynamic allocation errors when using vendor supplied routines. The following chart clarifies the definitions:

The eligible device table (EDT) is an installation-defined and named list of the I/O devices that are eligible for allocation. The Esoteric names and the associated pools or ranges of

Bayshore Advisor, Autumn 2005

8

DASD are defined in this table. The EDT specification is contained with the Operating System Configuration in the HCD or Hardware Configuration Definition. The EDT is a list of devices and the associated Esoteric name for each range of devices. In order to view the EDT for a particular Operating System Configuration in the HCD, you select the Operating System and then you will see the “Actions on Selected Operating Systems” panel. The panel ID is CBDPOSFX. Select Option “5” to work with EDTs. From this panel you can add a new EDT by using the PF11 key to “add a new EDT” (CBDPED10). After creating the EDT identifier and specifying the MVS Configuration ID, press enter to display the EDT list panel (CBDPEDF0). From the EDT list panel, select the ID of the new EDT you have created and you will see the “Actions on selected EDTs” panel. (CBDPEDFX). From this panel, select Item 4 “Work with Esoterics” and press the “enter” key. You should see the Esoteric list panel (CBDPESF0). Use PF11 to add a new Esoteric. Next you will see the ADD Esoteric panel. Enter the Esoteric name that you wish to add. In our example we will use IMSTST as our Esoteric name. Specify “NO” for VIO eligible, and null/blank for Token name and hit enter.

At this point the Esoteric name has been defined, and now you can associate a specific volume or volumes with that Esoteric name. Under the Operating System you are working on, select the device you wish to include in the group. From the device definition panel (CBDPDVOS) , hit enter and you should see the “Define device parameters and features panel (CBDPDV13).

Hit enter and you should be taken to the “Assign/Unassign Device to Esoteric” panel (CBDPDV16). In this panel, add the EDT ID.ESOTERIC name for example 0M.IMSTST assigned YES. If you do not want to assign a group of devices, you can limit the range by specifying a starting number and the number of devices. If you omit the number of devices, then 1 is assumed. Using HCD, you define EDT information in an IODF. At IPL or dynamic configuration, information in the IODF and UIMs is used to build the EDT. When you create the LOADxx member, you specify an IODF

statement to identify the I/O configuration definition for IPL. The IODF statement contains the name of the production IODF and identifier of the EDT and operating system configuration that is used to IPL the system. The IODF identified becomes the active IODF for the system. An example of this statement in the LOADxx member follows:

IODF xx hiqualif configid 0M y In this example the new EDT member we created is suffix 0M. We put the new EDT member suffix in columns 31 and 32. If you do not specify an EDT member, the default is 00. Some additional notes are needed to clarify what value is being used as your default unit. For installations using SMS, use ISMF. First chose option 8 and then chose

option 1 “Display the Base Configuration”. You can see a default unit. This can easily be changed if you chose a new value by using Option 3 “Alter”. Then perform a Validate and then an Activate and you have a new default value. An SMS value will take precedence over some of the values coded in the ALLOCxx member of Parmlib. So obviously, the other place where the default unit might be specified is the ALLOCxx member of Parmlib. You may see a UNIT value here. The default value for UNIT in the ALLOCxx member of Parmlib is SYSALLDA.

Bayshore Advisor, Autumn 2005

9

Featured Article

Are Your MVS & JES2 Commands Safe? By James Smith, Bayshore senior consultant z/OS and JES commands (console commands is a common term) are used to control system operations in a z/OS environment. When these commands are not secure and are wrongly used then disaster can strike. System operators are normally responsible for entering system commands. This is their primary responsibility. However, often other members of the system support staff need access to monitoring commands. Who has access to these commands in your installation? Many of these commands are sensitive and potentially disruptive: Some of the sensitive operations functions that can be performed include: • halt the system • place processor, real

storage, and channel paths offline

• cancel jobs, mount requests and TSO sessions

• terminate critical network connections

Some of the sensitive functions that can be performed which impact security include: • Using an unauthorized

version of the PROGxx parameter member which allow different APF libraries to be defined to

the system. You can now ‘sneak’ modules into an authorized state. It’s like letting a known virus loose on your PC.

• Dynamically change SMF parameters – delete potential system audit records.

• set a SLIP which can be used to disclose a password

• stop the system log All of the above functions expose the integrity of your system. In the early years of MVS, console commands could only be issued through one of the MVS consoles, which were directly connected to the system. The MVS console allows MVS and JES commands to be executed without requiring a user to logon to the system. Starting with MVS release 3.1.3, console operators can be required to logon to the MVS consoles by specifying the LOGON(REQUIRED) parameter within the CONSOLxx PARMLIB member. This is a common practice in the west, but not in China. Should you reconsider your position on this matter? Be warned however that the system console does not timeout after a specified period of inactivity. Therefore, unless each operator logs off the MVS console after each time they

issue a console command, operators will share the same ID. This would not provide any accountability for each operator's individual actions. Also the identity of the user issuing the command is not tagged in the SYSLOG when the message is written. However, enabling the logon security for MVS console would at least allow an installation to restrict those console commands which are not the function of a system operator. Other MVS facilities and system software products which provide for the issuance of console commands include: • Batch Submission

JES2 allows jobs to issue MVS and JES commands through the various submission facilities, which include internal reader, card readers, STC readers, and TSO readers. Each of these facilities is assigned parameters which either allow or not allow JES and MVS commands (i.e., system commands) to be defined for execution within specific jobs being submitted. Do you need to have MVS commands imbedded in JCL? If not then you should set COMMAND= IGNORE in the JES2 JOBCLASS definition to prevent unauthorized use. • System Display and

Search Facility (SDSF)

Bayshore Advisor, Autumn 2005

10

SDSF is an IBM product which interfaces with the MVS spool and provides a tool for analyzing and controlling JES2. SDSF, which is executed from a TSO session allows users (i.e., besides operators) to control the manner in which jobs are executed and printed and alleviates the tasks required to be performed by the operator. SDSF has the ability to issue any MVS command except for those commands that are restricted to the master MVS console, such as CONFIG, CONTROL, DUMP, FORCE, TRACE, and VARY. It is critical to implement RACF security within SDSF, but this is not yet a common practice in China. Traditionally SDSF is customized to restrict who can issue commands, which can control JES2 resources, and who can look at sensitive output. There is a wealth of security functions available in SDSF and we feel they should be used to protect the availability of your system. Protecting your MVS and JES2 commands now may save you from a disaster in the future. Security Access Facility (SAF) Use the SAF interface to restrict access to MVS and JES commands. This is achieved via the OPERCMDS Resource Class to define the individual MVS and JES commands which are to be protected. Console commands can be protected and individuals permitted access at the

commands first operand using masking characters. Also, security can be administered at the complete command level with all of its operands. Controlling Operator Commands To control the use of operator commands, create profiles in the appropriate RACF classes that enable RACF command authorization. The specific RACF classes that you must activate depend on the input source that you want to protect. The following table lists the RACF classes that must be activated for each input source.

Example of Controlling Who Can Issue MVS Commands The following example shows how to use the OPERCMDS class to control who can display and cancel jobs in your installation.

Suppose you want to let anyone display jobs but you want to restrict the task of cancelling jobs to a group of MVS operators. All of the MVS operators you want to authorize

have RACF-defined user IDs connected to a group called OPERGRP.

According to z/OS MVS Planning: Operations, to authorize a user to issue the MVS DISPLAY JOBS command, you must give the user READ access to a resource named MVS.DISPLAY.JOB in the OPERCMDS class. To authorize a user to issue the MVS CANCEL command for all jobs, you must give the user UPDATE access to a resource named MVS.CANCEL.JOB. ** In the OPERCMDS class.

To grant these authorizations, enter:

SETROPTS GENERIC(OPERCMDS) REFRESH

RDEFINE OPERCMDS MVS.DISPLAY.JOB UACC(READ) RDEFINE OPERCMDS MVS.CANCEL.JOB.** UACC(NONE) PERMIT MVS.CANCEL.JOB.** CLASS(OPERCMDS) ID(OPERGRP) ACCESS(UPDATE) SETROPTS CLASSACT(OPERCMDS) SETROPTS RACLIST(OPERCMDS) REFRESH SETROPTS GENERIC(OPERCMDS) REFRESH Now, anyone can display a job, but only the operators in OPERGRP can cancel a job We would like to see that data centers use the functions your system provides to protect YOUR resources.

Bayshore Advisor, Autumn 2005

11

IBM z/os Software Product End of Service Dates Version and

Release Announce Date Availability Date Withdrawn from Marketing

Service Discontinued

1.7.0 2005/07/27 2005/09/30 2006/09* 2008/09* 1.6.0 2004/08/10 2004/09/24 2005/09/30 2007/09* 1.5.0 2004/02/10 2004/03/26 2004/09/09 2007/03/31* 1.4.0 2002/08/13 2002/09/27 2004/09/09 2007/03/31 1.3.0 2002/02/19 2002/03/29 2002/09/12 2005/03/31 1.2.0 2001/09/11 2001/10/26 2002/03/14 2004/10/31 1.1.0 2000/10/30 2001/03/30 2002/06/25 2004/03/31

*Indicates IBM Projected date. Actual end of marketing or end of service date has not been announced yet.

IBM DB2 Software Product End of Service Dates Version and

Release OS/Platform Program ID End of Marketing date

End of Service date

8 z/OS 5625-DB2 * * 7 OS/390, z/OS 5675-DB2 * * 6 OS/390 5645-DB2 2002/06/30 2005/06/05 5 OS/390 5655-DB2 2001/12/31 2002/12/31 4 MVS/ESA 5695-DB2 2000/12/01 2001/12/31 3 MVS 5685-DB2 2000/02/29 2001/01/31

*Indicates IBM Projected date. Actual end of marketing or end of service date has not been announced yet.

IBM CICS Software Product End of Service Dates Product Name Version/Release Availability

Date End of Service

Date CICS Transaction Server for OS/390 V1.3 1.3 1998/09/08 2006/04/30

CICS Transaction Server for z/OS V2.2 2.2 2002/01/25 * CICS Transaction Server for z/OS V2.3 2.3 2003/12/19 * CICS Transaction Server for z/OS V3.1 3.1 2005/03/25 * *Indicates IBM Projected date. Actual end of marketing or end of service date has not been announced yet.

IBM IMS Software Product End of Service Dates Version/ Release

OS/Platform Program

ID

General Availability

Date

End Of Marketing Date

End of Service

Date 6.1 MVS/ESA 5655-158 1997/12/26 2002/09/04 2003/09/307.1 OS/390 5655-B01 2000/09/05 2004/09/08 2005/11/089.1 OS/390, z/OS 5655-J38 2004/10/27 * * 8.1 OS/390, z/OS 5655-C56 2002/09/02 * * *Indicates IBM Projected date. Actual end of marketing or end of service date has not been announced yet.

Bayshore Advisor, Autumn 2005

12

New IBM Redbooks SG24-5983-03 DFSMSrmm Installation and Implementation Primer SG24-6515-00 Technical Introduction IBM eServer zSeries 800 SG24-6645-00 Effective zSeries Performance Monitoring Using Resource

Measurement Facility (RMF) SG24-6669 IBM System z9 109 Technical Introduction SG24-6651 z/OS V1R6 DFSMS Technical Guide

The URL for the redbooks is http://www.redbooks.ibm.com/

Draft Redbooks SG24-6366-00 z/OS Basics (Formal Publication 09/2005)

New IBM Washington System Center Technical Flashes FLASH10369 Setting OSA SNA Parameters for Best Performance; what SNA

parameters should be used when you are configuring the OSA Express and OSA Express2 facilities. This flash gives several recommendations to improve performance.

For the Washington Systems Center flashes, the address is: http://www-03.ibm.com/support/techdocs/atsmastr.nsf/Web/TechDocs

Bayshore Consulting & Services Co., Ltd Bayshore Consulting & Services Co., Ltd Rm 209, Zhongchen Building, No.1, Lize Zhong Er Lu, Rm 209, Zhongchen Building, No.1, Lize Zhong Er Lu,

Chaoyang District, Beijing, China, 100102 Chaoyang District, Beijing, China, 100102 Tel: (010) 6439-1733 Fax: (010) 6439-1582 Tel: (010) 6439-1733 Fax: (010) 6439-1582

http://www.bayss.comhttp://www.bayss.com

Bayshore Advisor, Autumn 2005

13