Re: SPF in 1978

[Anne & Lynn Wheeler]

re:
http://www.garlic.com/~lynn/2011p.html#106 SPF in 1978
http://www.garlic.com/~lynn/2011p.html#107 SPF in 1978

I had originally done extended sharing on cp67 along with paged-mapped
CMS filesystem ... which I then converted to vm370 ... some old email
http://www.garlic.com/~lynn/2006v.html#email731212
http://www.garlic.com/~lynn/2006w.html#email750102
http://www.garlic.com/~lynn/2006w.html#email750430

with respect to "csc/vm" in the above ... one of my hobbies was making
enhanced operating systems available to internal datacenter ... first
with cp67 and then later with vm370.

during the "future system" period ... some old posts
http://www.garlic.com/~lynn/submain.html#futuresys

I continued to do 360/370 stuff (even when future system was killing off 370 
efforts) ... and periodically would ridicule future system activities.

after the demise of future system, there was mad rush to get stuff
back into 370 product pipelines ... which motivated decision to
release various bits & pieces of stuff that I had been doing. A small
subset of the sharing stuff (w/o the paged mapped filesystem support)
was including in vm370 release 3 as DCSS.

the following is exchange with the SPF group about trying to map SPF
into a "shared module" (as opposed to DCSS sharing).

Date: 11/07/79 14:53:27
From: wheeler
To: somebody in GBURG SPF group

The SPF module starts (begins) at location x'2' and end somewhere
close to x'7' (actually around x'6a000'). If I load and genmod
SPF it ordinarily creates a MODULE which starts at location x'2'
and ends around x'6a000', i.e. those core locations are written to disk.
When I invoke SPF the SPF MODULE file is read into locations starting
at the start of the module (x'2') and ending at the end of the
module (x'6a000').
--
Shared module support is an enhancement to VM and CMS which allows
specification at GENMOD time which segments (16 page groups) are to
be shared. The segments to be shared must be occupied by the module
being genmod'ed (i.e segment 2: x'2' thru x'3'; segment 3:
x'3' thru x'4', etc.).
--
Ordinarily I would LOAD SPF
   GENMOD SPF
--
for shared modules I
   LOAD SPF
   reset module ending address to x'7'
   GENMOD SPF (share 2 3 4 5 6
--
Now at loadmod time, in addition to reading the SPF MODULE file into
the specified core locations (i.e. x'2' thru x'7') it
also identifies to CP that segments 2, 3, 4, 5, and 6 are SPF shared
segments. For all other programs that I have been involved with,
that works satisfactory (i.e. the same code runs in discontiguous
shared segments, runs in modules, runs in shared modules) and modules
which did not change internal code locations while a discontiguous
shared module also do not change internal code locations while a
module and/or a shared module. As I read your reply, SPF is
altering 8 bytes of core at absolute location x'2' independently
of whether or not that location is contained within the module.
If I were to:
   LOAD SPF (origin 3
   reset module ending address to x'8'
   GENMOD SPF (share 3 4 5 6 7
there would not be any problems?  since SPF is not storing into a
relative module core location (i.e. start of the 1st SPF module + x'0' bytes)
but into absolute location x'2'.

... snip ...

and the response about why there were still problems: as an aside ...
1979 GBURG SPF group appeared to still be using all upper case

Date: 11/07/79
To: wheeler
From: somebody in GBURG SPF group

LYNN,
THANKS FOR SENDING THE DESCRIPTION OF SHARED MODULES.  I HAVEN'T
STUDIED IT IN DETAIL, BUT DID READ THROUGH IT.  VERY INTERESTING.

YOUR IDEA OF STARTING SPF AT 3 INSTEAD OF 2 WOULD AVOID 
THE "SHARED" VIOLATION AS WE STORE INTO LOCATION 2.  HOWEVER, 
THAT WILL NOT SOLVE ALL THE PROBLEMS.  IN SPF, THE WAY WE DETERMINE 
WHETHER WE ARE RUNNING IN THE USER AREA (TEST MODE) OR IN
DCSS, IS TO COMPARE THE ADDRESS OF THE FIRST PROGRAM (HAPPENS TO BE
NAMED SPF) TO THE VALUE '2'.  IF IT IS NOT THERE, IT IS ASSUMED
THAT WE ARE IN DCSS.  THE IMPLICATION IS THAT SPF WILL NOT RELOAD
ITSELF FOLLOWING A FOREGROUND COMPILE, OR CMS COMMAND THAT USES
THE USER AREA.  IF MY UNDERSTANDING OF "SHARED MODULES" IS CORRECT,
I AM AFRAID THAT, AT LEAST IN THE NEAR TERM, THERE IS NOTHING I
CAN DO THAT WILL PERMIT SPF TO OPERATE CORRECTLY IN YOUR SPECIAL
ENVIRONMENT.  FEEL FREE TO WRITE OR CALL.
   REGARDS,
   XXX

... snip ...

later exchange about SPF being a real "pig" of an application:

Date: 02/21/80 12:59:12
To: wheeler

Hi, Lynn,
Do you have SPF/CMS installed, or know anybody that does 

... snip ...

Date: 02/21/80 14:42:09
From: wheeler

SPF/CMS installed and running, but it is a pig tho.

... snip ...

In this time-frame there were a number of internally developed CMS
full-screen editors ... early one that had been released to c

Re: Eight-character TSO Userid Support

[Paul Gilmartin]

On Sat, 24 Dec 2011 19:19:34 -0500, zMan wrote:

>Yeah, I see the case for 8-character consistency since TSO seems to be
>the weirdo here, but I'm hard-pressed (much as I'd like to see it) to
>find a case for changing the other areas. It ain't broke...
> 
Hmmm.  How many upper-case alphanumeric characters would be needed
to provide unique identifiers for all the files an enterprise would ever need?
By that metric, 44(8) is more than sufficient.

But users will complain that they can readily move their data among
Linux, Windows, Solaris, OS X; for z/OS they must perform
excruciating name transformations.  Such complaints will rise
at least to audibility in the airline magazines which, like it or
not, are a consideration in management decisions.

But z/OS Unix System Services provides an escape from the name
constraints.  IBM should devote effort to elevating z/OS USS to
enterprise strength and not let it remain a marketing gimmick.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Eight-character TSO Userid Support

[zMan]

Yeah, I see the case for 8-character consistency since TSO seems to be
the weirdo here, but I'm hard-pressed (much as I'd like to see it) to
find a case for changing the other areas. It ain't broke...

On Sat, Dec 24, 2011 at 7:11 PM, Clark Morris  wrote:
> While I agree that the control block (and SMF record) limitations on
> Jobname, proc step name and step name will be expensive to overcome,
> we need to come up with a case for it being worth doing.  The name
> limitations don't seem to be present in the Unix/Linux and Windows
> environments and both may use Unicode for at least some of the names.
> File names also may need to be reviewed.  The fun will be the
> transition.
-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Eight-character TSO Userid Support

[Clark Morris]

On 24 Dec 2011 14:44:22 -0800, in bit.listserv.ibm-main you wrote:

>In <4ef583a2.1080...@phoenixsoftware.com>, on 12/23/2011
>   at 11:47 PM, Edward Jaffe  said:
>
>>I am curious: is TSO the only hold-out?
>
>For 7 character userids, probably. However, there are two related
>issues that are global:
>
> 1. The current limit of userids to 8 characters is equally
>obsolescent.
>
> 2. The limitation of DSN components no longer makes sense, now
> that IBM has put a stake through the heart of CVOL's.
>
>I agree with Paul that the TSO PROFILE PREFIX should be expanded to 42
>characters. Due to control block layouts, expand it or the userid to 8
>characters would be as much work as expanding them to a larger size.
> 
While I agree that the control block (and SMF record) limitations on
Jobname, proc step name and step name will be expensive to overcome,
we need to come up with a case for it being worth doing.  The name
limitations don't seem to be present in the Unix/Linux and Windows
environments and both may use Unicode for at least some of the names.
File names also may need to be reviewed.  The fun will be the
transition.  

Clark Morris

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Eight-character TSO Userid Support

[Paul Gilmartin]

On Sat, 24 Dec 2011 17:25:29 -0500, Shmuel Metz (Seymour J.) wrote:
>
> 1. The current limit of userids to 8 characters is equally
>obsolescent.
>
> 2. The limitation of DSN components no longer makes sense, now
> that IBM has put a stake through the heart of CVOL's.
> 
I understand from discussions in these fora that when CVOLs were
supplanted, the limit was consequentially removed.

Some people can't tolerate liberty.

Customers demanded the limit be reinstated.  IBM made it a configuration
option, with the default being the less restrictive.

Customers demanded that the default be restrictive.  IBM acceded.

Even worse, it was done in such a manner that if the customer
reinstated the restriction, it was not possible to uncatalog or rename
data sets created in the interim with names exploiting the
less restrictive convention.

Go figger.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Eight-character TSO Userid Support

[Shmuel Metz (Seymour J.)]

In <4ef583a2.1080...@phoenixsoftware.com>, on 12/23/2011
   at 11:47 PM, Edward Jaffe  said:

>I am curious: is TSO the only hold-out?

For 7 character userids, probably. However, there are two related
issues that are global:

 1. The current limit of userids to 8 characters is equally
obsolescent.

 2. The limitation of DSN components no longer makes sense, now
 that IBM has put a stake through the heart of CVOL's.

I agree with Paul that the TSO PROFILE PREFIX should be expanded to 42
characters. Due to control block layouts, expand it or the userid to 8
characters would be as much work as expanding them to a larger size.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: SPF timeline?

[Ed Gould]

Benyamin:
It was later explained to me that SPF was written at a woman's  
undergarment (Bra?) place in Chicago by I think an IBM person (or  
group). My mind is complete blank as to its name. Whoever came up  
with structured program facility was short sighted IMO. The immediate  
use might have been that but it was just plain misleading and a lot  
of people looked elsewhere quickly when they heard the name. At the  
time we were using TCAM and the fullscreen was at best clumsy IMO.  
VTAM fixed that of course but until ISPF came along (it, Fullscreen)  
was well supported, IIRC.


Ed



On Dec 24, 2011, at 12:58 PM, Binyamin Dissen wrote:

On Thu, 22 Dec 2011 18:00:22 -0600 Ed Gould  
 wrote:


:>I think you are about right on the time line. I do remember the two
:>separate products. We had look at ISPF (we had gone FSE instead).
:>Our IBMers at the time went AWOL and I could never get a good
:>explanation between the two products.
:>We decided to keep FSE as it was a lot less $$$ . We also did not
:>like the proliferation of ISPF datasets (at the time DASD was
:>expensive).

I remember when SPF was being tested at Western Electric and I much  
preferred

Session Manager + FSE.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: SPF timeline?

[Binyamin Dissen]

On Thu, 22 Dec 2011 18:00:22 -0600 Ed Gould  wrote:

:>I think you are about right on the time line. I do remember the two  
:>separate products. We had look at ISPF (we had gone FSE instead).
:>Our IBMers at the time went AWOL and I could never get a good  
:>explanation between the two products.
:>We decided to keep FSE as it was a lot less $$$ . We also did not  
:>like the proliferation of ISPF datasets (at the time DASD was  
:>expensive).

I remember when SPF was being tested at Western Electric and I much preferred
Session Manager + FSE.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Eight-character TSO Userid Support:

[Paul Gilmartin]

On Sat, 24 Dec 2011 09:45:12 -0500, John Gilmore wrote:

>Edward Jaffe wrote
>
>
>Recently, the need for eight-character TSO userids made it into the
>list of the highest ranked MVS SHARE requirements. Many installations,
>driven by their business units, are attempting to standardize on a
>single, eight-character, cross-platform userid. These attempts are
>being hampered by the arcane seven-character TSO userid restriction
>introduced in the 1970s.
>
>
>Examples of this sort could be multiplied ad infinitum et nauseam.  I
>have concluded that the only way around such infelicities is to make
>external-name size limitations much larger than life, to chose, say,
>the value  2^15 - 1 = 32767 characters for them and to make this value
>a design point even though it is not yet globally usable.
> 
>Considerable work will have to be done to eliminate the
>seven-character TSO userid maximum, and it would be a work wasted if
>an already obsolescent eight-character maximum replaced it.
>
Yes.  Particularly, TSO userids should be coded so the length is limited
only by the underlying OS, so that if MVS ever adopts more than 8,
TSO will immediately support that greater number with no recoding.
(or at most the minimal code change of redefining a single EQU used
globally).

Likewise, the TSO DSN prefix should be made larger than life so it
could immediately support up to 42 characters for legacy data sets,
and more if the underlying OS restriction is ever relaxed, and
immediately  UNIX directory path.

Unix System Services already supports the USERIDALIASTABLE:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/bpxzb2b0/3.7.4.3

Would extending this facility to support TSO logins, and adding a
reverse lookup function provide short term relief of the SHARE
requirement.  (One of the examplesin the cited section contains
an alias longer than 8 characters.)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Tapeless Solutions

[Russell Witt]

Not true at all. CA-Vtape can optionally use "open system" storage, but it is 
not required. If you want to go directly from MF DASD/CACHE to tape - that is 
an option.

Actually, there was a presentation (panel-type) at the SHARE in Orlando where 
we had a short 7-minute presentation from each of 6 vendors. All of their 
presentations have also been uploaded to the SHARE web-site. So, if you are 
interested in a short over-view of half-a-dozen different Vtape offerings (with 
remote replication), you can go to the SHARE web-site.

Russell Witt
CA-1 L2 Support Manager

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
R.S.
Sent: Saturday, December 24, 2011 5:06 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Tapeless Solutions

W dniu 2011-12-24 10:50, Tommy Tsui pisze:
> It seems the only choice for enterprise tapeless solution is only vsm 
> or 7720, anyone will consider bustech or ca-tape software solution 
> what is pros and cons
Well, I never said that. BusTech MDL is also a choice, as well as Luminex 
product or Interkom one.
Actually all of mentioned products are a PART of the solution, all of them need 
some "open system" (FBA) storage to store the data.
Pros and cons - well, at least Luminex is not tied to given storage 
manufacturer (BusTech is part of EMC), so in this case you have wider choice of 
devices. Another issue is performance, scalability, remote copy, etc.

Regards
--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

ISO updates C standard - The H Open Source: News and Features

[John McKown]

A Christmas gift from ISO:

http://www.h-online.com/open/news/item/ISO-updates-C-standard-1400814.html

Article has a link to a PDF with the draft standard. 

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=57853

for the real standard. Which costs money to buy.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Eight-character TSO Userid Support:

[John Gilmore]

Edward Jaffe wrote


Recently, the need for eight-character TSO userids made it into the
list of the highest ranked MVS SHARE requirements. Many installations,
driven by their business units, are attempting to standardize on a
single, eight-character, cross-platform userid. These attempts are
being hampered by the arcane seven-character TSO userid restriction
introduced in the 1970s.


This is clearly desirable, but I am not sure that it is enough.

Historically, such limitations are almost always traceable to the use
of suffixing schemes.

Old-style IBM PL/I, for example, limited the lengths of
external-procedure names to seven characters in order to make the
eighth, rightmost character available for single-character suffixes
that identified each of the multiple CSECTs that the compiler
generated for that procedure.

Or again, I was pleased to discover when I first began to use Stratus
VOS that its filenames could  be 32 characters in length, but this
maximum turned out to be illusory. VOS had the habit of naming backup
files using the suffixing scheme

.bkup

so that the 32-character maximum turned out, as a practical matter, to
be a 27-character one.

Examples of this sort could be multiplied ad infinitum et nauseam.  I
have concluded that the only way around such infelicities is to make
external-name size limitations much larger than life, to chose, say,
the value  2^15 - 1 = 32767 characters for them and to make this value
a design point even though it is not yet globally usable.

Considerable work will have to be done to eliminate the
seven-character TSO userid maximum, and it would be a work wasted if
an already obsolescent eight-character maximum replaced it.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Tapeless Solutions

[R.S.]

W dniu 2011-12-24 10:50, Tommy Tsui pisze:

It seems the only choice for enterprise tapeless solution is only vsm or
7720, anyone will consider bustech or ca-tape software solution what is
pros and cons
Well, I never said that. BusTech MDL is also a choice, as well as 
Luminex product or Interkom one.
Actually all of mentioned products are a PART of the solution, all of 
them need some "open system" (FBA) storage to store the data.
Pros and cons - well, at least Luminex is not tied to given storage 
manufacturer (BusTech is part of EMC), so in this case you have wider 
choice of devices. Another issue is performance, scalability, remote 
copy, etc.


Regards
--
Radoslaw Skorupka
Lodz, Poland


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, e-mail: i...@brebank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2011 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.346.696 złotych.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Tapeless Solutions

[Tommy Tsui]

It seems the only choice for enterprise tapeless solution is only vsm or
7720, anyone will consider bustech or ca-tape software solution what is
pros and cons
 On 2011-12-24 上午8:52, "R.S."  wrote:

> W dniu 2011-12-23 20:44, Cosby, Bob - OCFO pisze:
>
>> At the time of this tape implementation we were utilizing 3490 1.8gbs
>> tapes and 9849C 20gbs uncompressed /40gbs
>> compressed tapes so by definition 75gbs uncompressed I would consider
>> that to be High capacity;
>>
> At the same time you had T1 (A) drives with 500/1000GB capacity. 9840
> drives were never considered as high capacity ones - it STK nomenclature.
> 9840 with great SL8500 robots gives something between real tape and VTS.
> IMHO there is no reason to use 9840's as RTDs for VSM. My €0.02
>
>  but what wasreally nice about staying with Oracle/SUN/STK that Larry
>> Davis brought
>>
> out was the 7,500 9840C tapes
>
>> that we were using on the 9840C drives once they went Scratched we could
>> not only use them on the 9840D tape drives
>> but get the capacity of the 9840D tapes.
>>
> The same can be told about almost all "enterprise" tapes and drives (LTO,
> MAGSTAR, JAGUAR, 9840, 9940, T1). Of course the compatibility is
> limited.
>
>  This was at minimum of half a million dollars cost saving or a cost
>> avoidance of having to buy new high capacity
>> tapes. And yes our Open Systems environment has T1 tape drives.
>>
> It's even more interesting: why did you decided to use 9840 for mainframe?
>
>  Remote replication is next: we are working with a company called LEVEL 3
>> that is recommending two (2) 10gb pipes
>> to ship our data. The current VSM will ship data over TCP/IP unlike the
>> IBM VTS B20 model that we have;
>>
> > that is one of the many reasons we need to put it out to pasture.
> 1. TCP/IP is one of the methods, another one is FICON over dark fiber
> (with DWDM). The second one is usually much more expensive, but it was
> available in VTS. Nowadays also IBM uses TCP/IP for replication. Oh, BTW:
> VSM replication over TCP/IP is also new, I would bet it came later, after
> IBM released it!
>
> >  We had two (2) IBM VTS's  in a Composite
>
>> library status using Peer to Peer (PtP) remote copy after Katrina
>> but the TELCOM cost was to much so we UN-Peered them.
>>
>> This is not an advertisement just my experiences as a mainframe storage
>> guy.
>>
> OK, OK, I was joking ;-)
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
> --
> Treść tej wiadomości może zawierać informacje prawnie chronione Banku
> przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być
> jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś
> adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej
> przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie,
> rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie
> zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo,
> prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale
> usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub
> zapisane na dysku.
>
> This e-mail may contain legally privileged information of the Bank and is
> intended solely for business use of the addressee. This e-mail may only be
> received by the addressee and may not be disclosed to any third parties. If
> you are not the intended addressee of this e-mail or the employee
> authorised to forward it to the addressee, be advised that any
> dissemination, copying, distribution or any other similar activity is
> legally prohibited and may be punishable. If you received this e-mail by
> mistake please advise the sender immediately by using the reply facility in
> your e-mail software and delete permanently this e-mail including any
> copies of it either printed or saved to hard drive.
> BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00,
> fax +48 (22) 829 00 33, e-mail: i...@brebank.pl
> Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego
> Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP:
> 526-021-50-88. Według stanu na dzień 01.01.2011 r. kapitał zakładowy BRE
> Banku SA (w całości wpłacony) wynosi 168.346.696 złotych.
>
> --**--**--
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Stephen J Bell is unavailable

[Steve Bell]

I will be out of the office starting  12/24/2011 and will not return until
01/03/2012.

HAPPY HOLIDAYS!!  I will respond to your Note when I return.  If you need
immediate assistance, please contact the Technical Services hotline x12880

--
CONFIDENTIALITY STATEMENT. The information contained in this e-mail message, 
including attachments, is the confidential information of, and/or is the 
property of, Vanguard. The information is intended for use solely by the 
individual or entity named in the message. If you are not an intended recipient 
or you received this in error, then any review, printing, copying, or 
distribution of any such information is prohibited, and please notify the 
sender immediately by reply e-mail and then delete this e-mail from your system.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN