Re: TCPIP question

[shai hess]

Thanks,
Shai

On Wed, Dec 21, 2011 at 9:12 AM, Michael Klaeschen <
michael.klaesc...@deutscherring.de> wrote:

> I think yes, the answer is simple by changing some parameters in the TCPIP
> options file. To be precise: your objective of limiting access to IP
> addresses or ports can be achieved with NETACCESS statements. Just name
> the inbound and outbound networks, ports etc. and then set up proper
> SERVAUTH profiles in RACF. That's all.
>
> Having multiple TCPIP stacks is something totally different. However: your
> question regarding balancing load between or within one or more TCPIP
> stacks should be answered in WLM brochures. A more general approach of
> this is distributed source VIPA in parallel sysplex  -- well, focus here
> is non-disruptive TCPIP service but load balancing is kind of a spin-off.
>
> Cheers
> Michael
>
>
>
> Von:shai hess 
> An: IBM-MAIN@bama.ua.edu
> Datum:  2011-12-21 06:20
> Betreff:Re: TCPIP question
> Gesendet von:   IBM Mainframe Discussion List 
>
>
>
> Thank you Chris and others,
>
> I will continue if I will need with the proper forum.
> I thought that the answer to my customer can be simple by changing some
> parameters in the TCPIP option file.
>
> Anyway, I thought that changing parameter in TCP can better balance the
> OSA
> HW between production load for TCP and MFNetDisk load for consuming the
> TCP
> in the same MF.
>
> But I think that the subject is more complicate than I thought. More
> knowledge required.
> I wish I had the time to spent more time and digging into the MF system
> network administrator to support some "simple" questions of users which
> expect me to know more MF network which is component which MFNetDisk uses
> a
> lot.
>
> Thanks,
> Shai
>
>
>
> On Wed, Dec 21, 2011 at 3:41 AM, Chris Mason
> wrote:
>
> > Shai
> >
> > As I have already reminded Lindy Mayfield, the best list for this sort
> of
> > query is the following:
> >
> > For IBMTCP-L subscribe / signoff / archive access instructions, send
> email
> > to lists...@vm.marist.edu with the message: INFO IBMTCP-L
> >
> > -
> >
> > I detect that you are not very comfortable with the details of how to
> > configure the statements in the PROFILE data set of the IP component of
> > z/OS Communications Server. That being so, you need to explain whet you
> > really want to do to the IP system programmer at the customer location.
> >
> > If, as appears to be the case, your customer has two "home" IP
> addresses,
> > 192.168.254.200 and 192.168.254.254, and IP address 192.168.254.254 is
> the
> > address assigned to the interface normally used to enter the local
> intranet
> > ...
> >
> > Actually I suspect your relative inexperience has managed to introduce
> > some confusion here. I suspect 192.168.254.254 is the IP address of the
> > interface on the shared LAN belonging to the adjacent router which
> features
> > on the ROUTE DEFAULT statement and not the IP address of the local
> > interface on the shared LAN. That "254" is a bit of a "give-away" since
> it
> > is the Cisco convention for the *logical* IP address of the interface on
> > the shared LAN belonging to the adjacent router when in fact there are
> > typically two adjacent routers to the interfaces on the shared LAN of
> which
> > the actual IP addresses end with "253" and "252". All this depends on
> > having what used in olden times to be called a "class C" address range
> for
> > the local LAN, also typically used when an intranet uses RFC 1918 IP
> > addresses and addresses can be assigned with relatively gay abandon!
> >
> > If I am correct here I expect 192.168.254.200 may well be the address of
> > the PC on the local LAN.
> >
> > And, if all of this is correct, you don't even need to ask your original
> > question because it will all simply work exactly as you want!
> >
> > In other words, the PC to which you refer is connected to the local LAN
> > and this local LAN has the following interfaces connected to it:
> >
> > - the probably z Series OSA feature with IP address 192.168.254.xxx
> >
> > - the PC with IP address 192.168.254.200
> >
> > - the adjacent router (logically) with IP address 192.168.254.254
> >
> > All these addresses fall within the IP address range 192.168.254.0 to
> > 192.168.254.255 or more strictly 192.168.254.1 to 192.168.254.254 since
> > 192.168.254.0 and 192.168.254.255 would not be used as specific
> interface
> > IP addresses.
> >
> > Note that the marvels of the usual processing directed by the IP routing
> > table in each of the nodes mentioned will route your IP traffic exactly
> as
> > you want without having to introduce any additional complications such
> > multiple instances of the IP component of z/OS Communications Server,
> > VIPAs, whether static or dynamic, the SRCIP/ENDSRCIP block or BIND
> > parameters of PORT statement list entries.
> >
> > You may even like to persuade the customer person who asked the question
> > to have a word with the IP system programmer, either 

Re: Tapeless Solutions

[shai hess]

Yes, I also read it as TOPLESS, so I smile.
I hope I did not make to myself bad name, more then before.

On Wed, Dec 21, 2011 at 7:58 AM, Timothy Sipples  wrote:

> Am I the only one who read the subject line too quickly, mentally
> substituting an "o" for the "a" and dropping the first "e"?
>
> I must be regressing.
>
>
> 
> Timothy Sipples
> Resident Enterprise Architect (Based in Singapore)
> E-Mail: timothy.sipp...@us.ibm.com
>
> --
> 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

Another new customer in Spain[ad]

[shai hess]

HI,

 Another email from Spain.
 I assume that more then 90% of the MF users never heard about MFNetDisk.
 I only publish my product in this forum and sometime in the past in
Hercules forum.
 So, the product is spread by old and happy users to new users and that
make me happy.

Some people offer me to help me to market the product to all MF users.
Meanwhile I am happy with the current status of my product.

 thanks,
 Shai



Hi, Shai:

I'm promoting your application with my mainframe systems colleages, and all
of them are very surprised with the disk replication and tape
virtualization features. In one case, one of my colleages work for
enterprise called CIMUBISA (The Bilbao's Town Hall computer outsourcing
services) and were very interested in it, because they have an extremely
old tape robot with several tape failures and don't have money to buy a new
one, and, because of this, I talked about your program and were very
interested testing it. They were so interested, that in my free times I go
to CIMUBISA and help them to install and configure your tool (free time,
because they also don't have money to pay to an enterprise nor me to do the
job, but they are my very best friends).

Now, I installed the MFNetDisk tool and the system is working in
Development LPAR (not in production) and they are very confortable and
happy with the power and performance (although MPC started task was to be
configured inside a policy under WLM, because in peak work hours, the MPC
and so TCPIP started task takes plenty of CPU, and they system has only 15
MSUs, so if anything consumes a bit more of CPU, the entire system is
affected).

So, they want to say to you that you have created an extraordinary and
wonderfull tool and want to show your appreciation.

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

Re: Tapeless Solutions

[Timothy Sipples]

Am I the only one who read the subject line too quickly, mentally
substituting an "o" for the "a" and dropping the first "e"?

I must be regressing.


Timothy Sipples
Resident Enterprise Architect (Based in Singapore)
E-Mail: timothy.sipp...@us.ibm.com

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

Re: TCPIP question

[shai hess]

Thank you Chris and others,

I will continue if I will need with the proper forum.
I thought that the answer to my customer can be simple by changing some
parameters in the TCPIP option file.

Anyway, I thought that changing parameter in TCP can better balance the OSA
HW between production load for TCP and MFNetDisk load for consuming the TCP
in the same MF.

But I think that the subject is more complicate than I thought. More
knowledge required.
I wish I had the time to spent more time and digging into the MF system
network administrator to support some "simple" questions of users which
expect me to know more MF network which is component which MFNetDisk uses a
lot.

Thanks,
Shai



On Wed, Dec 21, 2011 at 3:41 AM, Chris Mason wrote:

> Shai
>
> As I have already reminded Lindy Mayfield, the best list for this sort of
> query is the following:
>
> For IBMTCP-L subscribe / signoff / archive access instructions, send email
> to lists...@vm.marist.edu with the message: INFO IBMTCP-L
>
> -
>
> I detect that you are not very comfortable with the details of how to
> configure the statements in the PROFILE data set of the IP component of
> z/OS Communications Server. That being so, you need to explain whet you
> really want to do to the IP system programmer at the customer location.
>
> If, as appears to be the case, your customer has two "home" IP addresses,
> 192.168.254.200 and 192.168.254.254, and IP address 192.168.254.254 is the
> address assigned to the interface normally used to enter the local intranet
> ...
>
> Actually I suspect your relative inexperience has managed to introduce
> some confusion here. I suspect 192.168.254.254 is the IP address of the
> interface on the shared LAN belonging to the adjacent router which features
> on the ROUTE DEFAULT statement and not the IP address of the local
> interface on the shared LAN. That "254" is a bit of a "give-away" since it
> is the Cisco convention for the *logical* IP address of the interface on
> the shared LAN belonging to the adjacent router when in fact there are
> typically two adjacent routers to the interfaces on the shared LAN of which
> the actual IP addresses end with "253" and "252". All this depends on
> having what used in olden times to be called a "class C" address range for
> the local LAN, also typically used when an intranet uses RFC 1918 IP
> addresses and addresses can be assigned with relatively gay abandon!
>
> If I am correct here I expect 192.168.254.200 may well be the address of
> the PC on the local LAN.
>
> And, if all of this is correct, you don't even need to ask your original
> question because it will all simply work exactly as you want!
>
> In other words, the PC to which you refer is connected to the local LAN
> and this local LAN has the following interfaces connected to it:
>
> - the probably z Series OSA feature with IP address 192.168.254.xxx
>
> - the PC with IP address 192.168.254.200
>
> - the adjacent router (logically) with IP address 192.168.254.254
>
> All these addresses fall within the IP address range 192.168.254.0 to
> 192.168.254.255 or more strictly 192.168.254.1 to 192.168.254.254 since
> 192.168.254.0 and 192.168.254.255 would not be used as specific interface
> IP addresses.
>
> Note that the marvels of the usual processing directed by the IP routing
> table in each of the nodes mentioned will route your IP traffic exactly as
> you want without having to introduce any additional complications such
> multiple instances of the IP component of z/OS Communications Server,
> VIPAs, whether static or dynamic, the SRCIP/ENDSRCIP block or BIND
> parameters of PORT statement list entries.
>
> You may even like to persuade the customer person who asked the question
> to have a word with the IP system programmer, either the one responsible
> for the IP component of z/OS Communications Server or the typically Cisco
> adjacent router(s), who may well be a "Cisco person", and he or she or they
> will confirm what I have said - assuming I have guessed the configuration
> correctly.
>
> If I have made too many guesses, please explain more of your configuration
> and post HOME statement and the statements which constitute the routing
> table in the PROFILE data set of the single instance of the IP component of
> z/OS Communications Server.
>
> -
>
> If it's important in order to support your product, you might like to get
> some education in IP matters.
>
> As self-study, you can use redbooks which can be downloaded starting with
> "TCP/IP Tutorial and Technical Overview":
>
> http://www.redbooks.ibm.com/abstracts/gg243376.html
>
> and ending with the "IBM z/OS V1R13 Communications Server TCP/IP
> Implementation" set:
>
> http://www.redbooks.ibm.com/redpieces/abstracts/sg247996.html
> http://www.redbooks.ibm.com/redpieces/abstracts/sg247997.html
> http://www.redbooks.ibm.com/redpieces/abstracts/sg247998.html
> http://www.redbooks.ibm.com/abstracts/sg247899.html
>
> Note that I have been obliged to include the V1R12

Re: Imagine having to deal with THIS in production

[John Gilmore]

Robert A. Rosenberg writes:


. . . There is also the issue that in some calenders the date of New
Year's Day (ie: When the new year starts) is not a fixed number of
days from the start of the year but needs to be decided at the last
moment by an official who issues his ruling.


and I am not sure that I fully understand this formulation.

Lunar and, to some slight degree, lunisolar calendars may have an
observational component.  The putative date of a new moon and thus
also a new month is always known with some precision; but until that
new moon is in fact observed at a specific location the corresponding
event does not occur there; its celebration is deferred.

These observations are made by clerics, who may be important figures
but who are not really 'officials'; and only in very special
circumstances do these clerics have much discretion about whether a
new moon has been observed in the night sky.  Others are observing
this sky too, and no cleric wishes to be made a figure of fun by
denying what is obvious to many others.

John Gilmore

On 12/20/11, Robert A. Rosenberg  wrote:
> At 23:02 -0600 on 12/19/2011, Joel C. Ewing wrote about Re: Imagine
> having to deal with THIS in production:
>
>>There are of course other strong arguments against universal usage
>>of JD for dates any time in our lifetime.  As long as we remain an
>>Earth-centric and not a space-centric culture, that makes it
>>unlikely most people would favor an ordinal-based standard date
>>format like "Star Date" or "Julian Day" which has no obvious
>>relationship to Earth's annual seasons, when awareness of those
>>seasons is so important to our physical comfort and survival.
>
> There is also the issue that in some calenders the date of New Year's
> Day (ie: When the new year starts) is not a fixed number of days from
> the start of the year but needs to be decided at the last moment by
> an official who issues his ruling. Note that while the Hebrew
> Calender has various length years (with an added month in some years
> and months with added or missing days), the start of the new year is
> known in advance at all times no matter how far in the future you
> want to go and this need to get an official pronouncement of "Happy
> New Year" at year end from an official does not exist.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>


-- 
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: Imagine dealing with THIS in production

[Mike Schwab]

On Tue, Dec 20, 2011 at 5:47 PM, Robert A. Rosenberg  wrote:
> At 20:38 -0600 on 12/16/2011, Chris Mason wrote about Re: Imagine dealing
> with THIS in production:
>>
>> "Paradoxically" a 29th February birthday can have happy consequences - at
>> least in the fertile imagination of a writer of libretti for comic opera
>> such as William Schwenck Gilbert:
>>
>> 
>>
>> You are the victim of this clumsy arrangement, having been born in
>> leap-year,
>>  on the twenty-ninth of February;
>> And so, by a simple arithmetical process, youšll easily discover,
>> That though youšve lived twenty-one years, yet, if we go by birthdays,
>>  youšre only five and a little bit over!
>>
>> 
>>
>> http://math.boisestate.edu/gas/pirates/web_op/pirates18.html
>>
>> Chris Mason
>
> But when was he born? While the 21st birthday is supposed to occur in 1940,
> will he be 84 or 88 then? The year 1900 was NOT a leap year so he would need
> to wait from 1896 until 1904 for his next birthday (unless Gilbert goofed
> and counted the non-existent February 29, 1900). See Isaac Asimov's Black
> Widower "Year of the Action" for details.

That depends on where he is living.  The Orthodox in Eastern Europe
(Greece, Russia, etc) was still on the Julian calender and they DID
have February 29, 1900.  There was a lot of Passport / Visa mixups
from the 11/12 day difference between calenders for those coming from
America and Western Europe. to the Greece Olympics.
-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: TCPIP question

[Chris Mason]

Lindy

I recalled there had been a recent discussion regarding the desirability or 
otherwise of using more that one instance of the IP component of z/OS 
Communications Server supported by the same z/OS (in one LPAR obviously).

Then I checked - and, in terms of "list-craft", it's a bit of a mess!

First one Lindy Mayfield initiated a thread on September 19th with a Subject 
line misspelling as "Multile TCP/IP Stacks". Some handy answers were already 
supplied in this thread.

Dave Gibney offered a contribution on September 20th with a corrected Subject 
line and there were some further responses to this thread in the following 
month.

Unless, magically, some expertise joined the list in the intervening 2 months, 
you cannot really expect to receive any further wisdom on the topic - on 
IBM-MAIN.

What you could do/have done - as you were advised before but, for some reason, 
did not follow up - was post your query on the IBMTCP-L list:

For IBMTCP-L subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO IBMTCP-L
 
Chris Mason

On Tue, 20 Dec 2011 19:33:53 +, Lindy Mayfield  
wrote:

>Now, as I have asked a few times yet I don't quite "get " it, why do you need 
>multiple stacks?
>
>Ok, I have my own personal mainframe, what can I accomplish with multiple 
>tcp/ip stacks, and to have the, what is it called, something affinity?, in any
> case, there is a default and another choice.
>
>You guys have explained it to me, but I didn't get.  I'm a bit daft and slow, 
>sorry about that.  I just want to learn.
>
>Kindest regards,
>Lindy
>
>
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
>Itschak Mugzach
>Sent: Tuesday, December 20, 2011 9:18 PM
>To: IBM-MAIN@bama.ua.edu
>Subject: Re: TCPIP question
>
>You can run several IP stacks in the same lpar.
>
>ITschak

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

Re: Imagine dealing with THIS in production

[Robert A. Rosenberg]

At 22:44 -0600 on 12/18/2011, David Mierowsky wrote about Re: Imagine 
dealing with THIS in production:


At least they didn't have to deal with this! Thankfully this was 
sorted out long before computers were around!


The Changes of 1752
In accordance with a 1750 act of Parliament, England and its 
colonies changed calendars in 1752. By that time, the discrepancy 
between a solar year and the Julian Calendar had grown by an 
additional day, so that the calendar used in England and its 
colonies was 11 days out-of-sync with the Gregorian Calendar in use 
in most other parts of Europe.


England's calendar change included three major components. The 
Julian Calendar was replaced by the Gregorian Calendar, changing the 
formula for calculating leap years.  The beginning of the legal new 
year was moved from March 25 to January 1.  Finally, 11 days were 
dropped from the month of September 1752. 


The changeover involved a series of steps:
€December 31, 1750 was followed by January 1, 1750 (under the "Old 
Style" calendar, December was the 10th month and January the 11th)
€March 24, 1750 was followed by March 25, 1751 (March 25 was the 
first day of the "Old Style" year)
€December 31, 1751 was followed by January 1, 1752 (the switch from 
March 25 to January 1 as the first day of the year)
€September 2, 1752 was followed by September 14, 1752 (drop of 11 
days to conform to the Gregorian calendar)


You forgot step 4 which were the riots when the landlords charged a 
full 3 month rent for the July-September 1752 quarter instead of 
giving a rebate for the non-existent 11 days in the quarter.


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

Re: Imagine having to deal with THIS in production

[Robert A. Rosenberg]

At 23:02 -0600 on 12/19/2011, Joel C. Ewing wrote about Re: Imagine 
having to deal with THIS in production:


There are of course other strong arguments against universal usage 
of JD for dates any time in our lifetime.  As long as we remain an 
Earth-centric and not a space-centric culture, that makes it 
unlikely most people would favor an ordinal-based standard date 
format like "Star Date" or "Julian Day" which has no obvious 
relationship to Earth's annual seasons, when awareness of those 
seasons is so important to our physical comfort and survival.


There is also the issue that in some calenders the date of New Year's 
Day (ie: When the new year starts) is not a fixed number of days from 
the start of the year but needs to be decided at the last moment by 
an official who issues his ruling. Note that while the Hebrew 
Calender has various length years (with an added month in some years 
and months with added or missing days), the start of the new year is 
known in advance at all times no matter how far in the future you 
want to go and this need to get an official pronouncement of "Happy 
New Year" at year end from an official does not exist.


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

Re: Imagine dealing with THIS in production

[Robert A. Rosenberg]

At 20:38 -0600 on 12/16/2011, Chris Mason wrote about Re: Imagine 
dealing with THIS in production:



Mike


 Just think about all the people born on Feb 29th.



 They would have their 15th birthdate when they are 60 years old.


"Paradoxically" a 29th February birthday can have happy consequences 
- at least in the fertile imagination of a writer of libretti for 
comic opera such as William Schwenck Gilbert:




You are the victim of this clumsy arrangement, having been born in leap-year, 
  on the twenty-ninth of February;
And so, by a simple arithmetical process, you¹ll easily discover,
That though you¹ve lived twenty-one years, yet, if we go by birthdays, 
  you¹re only five and a little bit over!



http://math.boisestate.edu/gas/pirates/web_op/pirates18.html

Chris Mason


But when was he born? While the 21st birthday is supposed to occur in 
1940, will he be 84 or 88 then? The year 1900 was NOT a leap year so 
he would need to wait from 1896 until 1904 for his next birthday 
(unless Gilbert goofed and counted the non-existent February 29, 
1900). See Isaac Asimov's Black Widower "Year of the Action" for 
details.





On Fri, 16 Dec 2011 16:09:21 -0600, Mike Schwab 
 wrote:



They would have their 15th birthdate when they are 60 years old.

On Fri, Dec 16, 2011 at 3:49 PM, Tom Marchant 
 wrote:

 On Fri, 16 Dec 2011 14:57:14 -0600, Mike Schwab wrote:


At least they only loose 1 birthday a lifetime.  Just think about all
the people born on Feb 29th.


 The 60th day of the year?  What's the big deal with that?

 --
 Tom Marchant


--
Mike A Schwab, Springfield IL USA


--
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: TCPIP question

[Chris Mason]

Shai

As I have already reminded Lindy Mayfield, the best list for this sort of query 
is the following:

For IBMTCP-L subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO IBMTCP-L

-

I detect that you are not very comfortable with the details of how to configure 
the statements in the PROFILE data set of the IP component of z/OS 
Communications Server. That being so, you need to explain whet you really want 
to do to the IP system programmer at the customer location.

If, as appears to be the case, your customer has two "home" IP addresses, 
192.168.254.200 and 192.168.254.254, and IP address 192.168.254.254 is the 
address assigned to the interface normally used to enter the local intranet ...

Actually I suspect your relative inexperience has managed to introduce some 
confusion here. I suspect 192.168.254.254 is the IP address of the interface on 
the shared LAN belonging to the adjacent router which features on the ROUTE 
DEFAULT statement and not the IP address of the local interface on the shared 
LAN. That "254" is a bit of a "give-away" since it is the Cisco convention for 
the *logical* IP address of the interface on the shared LAN belonging to the 
adjacent router when in fact there are typically two adjacent routers to the 
interfaces on the shared LAN of which the actual IP addresses end with "253" 
and "252". All this depends on having what used in olden times to be called a 
"class C" address range for the local LAN, also typically used when an intranet 
uses RFC 1918 IP addresses and addresses can be assigned with relatively gay 
abandon!

If I am correct here I expect 192.168.254.200 may well be the address of the PC 
on the local LAN.

And, if all of this is correct, you don't even need to ask your original 
question because it will all simply work exactly as you want!

In other words, the PC to which you refer is connected to the local LAN and 
this local LAN has the following interfaces connected to it:

- the probably z Series OSA feature with IP address 192.168.254.xxx

- the PC with IP address 192.168.254.200

- the adjacent router (logically) with IP address 192.168.254.254

All these addresses fall within the IP address range 192.168.254.0 to 
192.168.254.255 or more strictly 192.168.254.1 to 192.168.254.254 since 
192.168.254.0 and 192.168.254.255 would not be used as specific interface IP 
addresses.

Note that the marvels of the usual processing directed by the IP routing table 
in each of the nodes mentioned will route your IP traffic exactly as you want 
without having to introduce any additional complications such multiple 
instances of the IP component of z/OS Communications Server, VIPAs, whether 
static or dynamic, the SRCIP/ENDSRCIP block or BIND parameters of PORT 
statement list entries.

You may even like to persuade the customer person who asked the question to 
have a word with the IP system programmer, either the one responsible for the 
IP component of z/OS Communications Server or the typically Cisco adjacent 
router(s), who may well be a "Cisco person", and he or she or they will confirm 
what I have said - assuming I have guessed the configuration correctly.

If I have made too many guesses, please explain more of your configuration and 
post HOME statement and the statements which constitute the routing table in 
the PROFILE data set of the single instance of the IP component of z/OS 
Communications Server.

-

If it's important in order to support your product, you might like to get some 
education in IP matters.

As self-study, you can use redbooks which can be downloaded starting with 
"TCP/IP Tutorial and Technical Overview":

http://www.redbooks.ibm.com/abstracts/gg243376.html

and ending with the "IBM z/OS V1R13 Communications Server TCP/IP 
Implementation" set:

http://www.redbooks.ibm.com/redpieces/abstracts/sg247996.html
http://www.redbooks.ibm.com/redpieces/abstracts/sg247997.html
http://www.redbooks.ibm.com/redpieces/abstracts/sg247998.html
http://www.redbooks.ibm.com/abstracts/sg247899.html

Note that I have been obliged to include the V1R12 version of Volume 4, since 
the V1R13 version has not yet appeared.

Chris Mason

On Tue, 20 Dec 2011 20:45:16 +0200, shai hess  wrote:

>HI,
>
> I have a customer question:
>
>
>1. How could I configure MFNetDisk in ZOS in order to use ONLY the IP
>192.168.254.200, instead of 192.168.254.254, because the last one is used
>for production traffic?
>
> MFNetDIsk uses TCP EZASMI API.
>
> Can I run 2 TCPIP procedure running together?
>  TCPIP which will use IP 192.168.254.254 (for production) and the second,
>TCPIPMPC (for only MFNetDisk) which will use 192.168.254.200?
>
>Thanks,
>Shai

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

Re: Imagine having to deal with THIS in production

[John Gilmore]

Coping with the Jewish calendar in fact provides an excellent vehicle
for learning to do date arithmetic in general.

Among the not quite obvious pitfalls: There are Jewish holidays that,
at long intervals, do not occur at all in some Gregorian year, and
there are others that occur, again infrequently, twice in a single
Gregorian year.

After dealing with it I found dealing with other lunisolar calendars
easy, and I recommend it as a test vehicle to anyone who is developing
a date-handling package.

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: TCPIP question

[Ward, Mike S]

Shai, I'm not sure I understand what you are asking..

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of shai hess
Sent: Tuesday, December 20, 2011 2:42 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: TCPIP question

Thank you. I think that this can be the best answer for my case.
Just to make it sure. If ZOS is the client (source) and PC is the
(destination).
If client ic MF want to connect and send data to PC, then if I will
specify in MF TCPIP address space

SRCIP
JOBNAME MFNetDisk 172.26.1.1
ENDSRCIP
Is it means that MF TCPIP will use the source MF IP 172.26.1.1 to
trabnsfer
the data to PC?
Thanks,
Shai

On Tue, Dec 20, 2011 at 10:29 PM, Ward, Mike S  wrote:

> You can use the SRCIP in the tcpprof
>
> SRCIP
> JOBNAME S250XXXD 172.26.1.1
> JOBNAME XXXA 172.27.1.65
> JOBNAME YYYR 172.27.1.65
> ENDSRCIP
>
> You can also bind at the port level if you want
>
> PORT
>21 TCP FTPD1 BIND 172.26.1.1;FTP Server
>23 TCP TN3270   ; Telnet 3270 Server
>23 TCP INETD1 BIND 9.67.113.3   ; z/OS UNIX Telnet server
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of shai hess
> Sent: Tuesday, December 20, 2011 12:45 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: TCPIP question
>
>  HI,
>
>  I have a customer question:
>
>
> 1. How could I configure MFNetDisk in ZOS in order to use ONLY the IP
> 192.168.254.200, instead of 192.168.254.254, because the last one is
> used
> for production traffic?
>
>  MFNetDIsk uses TCP EZASMI API.
>
>  Can I run 2 TCPIP procedure running together?
>  TCPIP which will use IP 192.168.254.254 (for production) and the
> second,
> TCPIPMPC (for only MFNetDisk) which will use 192.168.254.200?
>
> Thanks,
> Shai
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>
> ==
> This email and any files transmitted with it are confidential and
intended
> solely for the use of the individual or entity
> to which they are addressed. If you have received this email in error
> please notify the system manager. This message
> contains confidential information and is intended only for the
individual
> named. If you are not the named addressee you
> should not disseminate, distribute or copy this e-mail. Please notify
the
> sender immediately by e-mail if you
> have received this e-mail by mistake and delete this e-mail from your
> system. If you are not the intended recipient
> you are notified that disclosing, copying, distributing or taking any
> action in reliance on the contents of this
> information is strictly prohibited.
>
> --
> 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

==
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity
to which they are addressed. If you have received this email in error please 
notify the system manager. This message
contains confidential information and is intended only for the individual 
named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please notify the 
sender immediately by e-mail if you
have received this e-mail by mistake and delete this e-mail from your system. 
If you are not the intended recipient
you are notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this
information is strictly prohibited.

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

Re: Imagine having to deal with THIS in production

[Shmuel Metz (Seymour J.)]

In
,
on 12/20/2011
   at 12:40 PM, Mike Schwab  said:

>The Jewish calendear might be worse.  They use leap months to keep
>the calendar roughly aligned with the season.

There are also smaller adjustments such that certain holidays can't
occur on certain days of the week. 
 
-- 
 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: TCPIP question

[Lindy Mayfield]

don't stop here.  please dig deeper.  this isn't in my opinion the answer you 
are looking for.

Most kind regards, Lindy

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
shai hess
Sent: Tuesday, December 20, 2011 10:42 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: TCPIP question

Thank you. I think that this can be the best answer for my case.
Just to make it sure. If ZOS is the client (source) and PC is the (destination).
If client ic MF want to connect and send data to PC, then if I will specify in 
MF TCPIP address space

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

Re: TCPIP question

[Lindy Mayfield]

first, as always, I do NOT speak for SAS.  I am just another contributor to 
this list, mostly I just learn.  I contribute when I can, but alas it isn't as 
often as I would like.

it is sometimes called the  "stack affinity."  Google it a bit.  you need to 
know MUCH more about how to get the information than you need that I can tell 
you.  suffice to say, it is still an enigma for me, too.

if I can find the time, I will try to explain all this stuff to myself first.  
but you are very clever, one of the most clever people I know, so when you 
figure it out, please, please tell me (us), too.

me, if I cannot do it in rexx, I need to do something else.  :-)  I hate c, so 
selling hot-dogs on the streets of Helsinki may perhaps be an alternative 
choice.  :-)

most kind regards
Lindy



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
shai hess
Sent: Tuesday, December 20, 2011 8:45 PM
To: IBM-MAIN@bama.ua.edu
Subject: TCPIP question

HI,

 I have a customer question:


1. How could I configure MFNetDisk in ZOS in order to use ONLY the IP 
192.168.254.200, instead of 192.168.254.254, because the last one is used for 
production traffic?

 MFNetDIsk uses TCP EZASMI API.

 Can I run 2 TCPIP procedure running together?
  TCPIP which will use IP 192.168.254.254 (for production) and the second, 
TCPIPMPC (for only MFNetDisk) which will use 192.168.254.200?

Thanks,
Shai

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

Re: TCPIP question

[shai hess]

Thank you. I think that this can be the best answer for my case.
Just to make it sure. If ZOS is the client (source) and PC is the
(destination).
If client ic MF want to connect and send data to PC, then if I will
specify in MF TCPIP address space

SRCIP
JOBNAME MFNetDisk 172.26.1.1
ENDSRCIP
Is it means that MF TCPIP will use the source MF IP 172.26.1.1 to trabnsfer
the data to PC?
Thanks,
Shai

On Tue, Dec 20, 2011 at 10:29 PM, Ward, Mike S  wrote:

> You can use the SRCIP in the tcpprof
>
> SRCIP
> JOBNAME S250XXXD 172.26.1.1
> JOBNAME XXXA 172.27.1.65
> JOBNAME YYYR 172.27.1.65
> ENDSRCIP
>
> You can also bind at the port level if you want
>
> PORT
>21 TCP FTPD1 BIND 172.26.1.1;FTP Server
>23 TCP TN3270   ; Telnet 3270 Server
>23 TCP INETD1 BIND 9.67.113.3   ; z/OS UNIX Telnet server
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of shai hess
> Sent: Tuesday, December 20, 2011 12:45 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: TCPIP question
>
>  HI,
>
>  I have a customer question:
>
>
> 1. How could I configure MFNetDisk in ZOS in order to use ONLY the IP
> 192.168.254.200, instead of 192.168.254.254, because the last one is
> used
> for production traffic?
>
>  MFNetDIsk uses TCP EZASMI API.
>
>  Can I run 2 TCPIP procedure running together?
>  TCPIP which will use IP 192.168.254.254 (for production) and the
> second,
> TCPIPMPC (for only MFNetDisk) which will use 192.168.254.200?
>
> Thanks,
> Shai
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>
> ==
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity
> to which they are addressed. If you have received this email in error
> please notify the system manager. This message
> contains confidential information and is intended only for the individual
> named. If you are not the named addressee you
> should not disseminate, distribute or copy this e-mail. Please notify the
> sender immediately by e-mail if you
> have received this e-mail by mistake and delete this e-mail from your
> system. If you are not the intended recipient
> you are notified that disclosing, copying, distributing or taking any
> action in reliance on the contents of this
> information is strictly prohibited.
>
> --
> 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: TCPIP question

[Ward, Mike S]

You can use the SRCIP in the tcpprof

SRCIP
JOBNAME S250XXXD 172.26.1.1
JOBNAME XXXA 172.27.1.65
JOBNAME YYYR 172.27.1.65
ENDSRCIP

You can also bind at the port level if you want

PORT
21 TCP FTPD1 BIND 172.26.1.1;FTP Server
23 TCP TN3270   ; Telnet 3270 Server
23 TCP INETD1 BIND 9.67.113.3   ; z/OS UNIX Telnet server

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of shai hess
Sent: Tuesday, December 20, 2011 12:45 PM
To: IBM-MAIN@bama.ua.edu
Subject: TCPIP question

HI,

 I have a customer question:


1. How could I configure MFNetDisk in ZOS in order to use ONLY the IP
192.168.254.200, instead of 192.168.254.254, because the last one is
used
for production traffic?

 MFNetDIsk uses TCP EZASMI API.

 Can I run 2 TCPIP procedure running together?
  TCPIP which will use IP 192.168.254.254 (for production) and the
second,
TCPIPMPC (for only MFNetDisk) which will use 192.168.254.200?

Thanks,
Shai

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

==
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity
to which they are addressed. If you have received this email in error please 
notify the system manager. This message
contains confidential information and is intended only for the individual 
named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please notify the 
sender immediately by e-mail if you
have received this e-mail by mistake and delete this e-mail from your system. 
If you are not the intended recipient
you are notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this
information is strictly prohibited.

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

Re: TCPIP question

[Wolfgang Fritz]

Am 20.12.2011 19:45, schrieb shai hess:
> HI,
> 
>  I have a customer question:
> 
> 
> 1. How could I configure MFNetDisk in ZOS in order to use ONLY the IP
> 192.168.254.200, instead of 192.168.254.254, because the last one is used
> for production traffic?
> 
>  MFNetDIsk uses TCP EZASMI API.
> 
>  Can I run 2 TCPIP procedure running together?
>   TCPIP which will use IP 192.168.254.254 (for production) and the second,
> TCPIPMPC (for only MFNetDisk) which will use 192.168.254.200?
> 
> Thanks,
> Shai
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
HI
for incomming traffic use dynamic VIPA adresses
for outgoing traffic user SRCIP with your dynamic VIPA address, you have
already defined the step befor.

regards
Wolfgang

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

Re: TCPIP question

[Lindy Mayfield]

Now, as I have asked a few times yet I don't quite "get " it, why do you need 
multiple stacks?

Ok, I have my own personal mainframe, what can I accomplish with multiple 
tcp/ip stacks, and to have the, what is it called, something affinity?, in any
 case, there is a default and another choice.

You guys have explained it to me, but I didn't get.  I'm a bit daft and slow, 
sorry about that.  I just want to learn.

Kindest regards,
Lindy



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Itschak Mugzach
Sent: Tuesday, December 20, 2011 9:18 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: TCPIP question

You can run several IP stacks in the same lpar.

ITschak

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

Re: TCPIP question

[Itschak Mugzach]

You can run several IP stacks in the same lpar.

ITschak

On Tue, Dec 20, 2011 at 8:45 PM, shai hess  wrote:

> HI,
>
>  I have a customer question:
>
>
> 1. How could I configure MFNetDisk in ZOS in order to use ONLY the IP
> 192.168.254.200, instead of 192.168.254.254, because the last one is used
> for production traffic?
>
>  MFNetDIsk uses TCP EZASMI API.
>
>  Can I run 2 TCPIP procedure running together?
>  TCPIP which will use IP 192.168.254.254 (for production) and the second,
> TCPIPMPC (for only MFNetDisk) which will use 192.168.254.200?
>
> Thanks,
> Shai
>
> --
> 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

TCPIP question

[shai hess]

HI,

 I have a customer question:


1. How could I configure MFNetDisk in ZOS in order to use ONLY the IP
192.168.254.200, instead of 192.168.254.254, because the last one is used
for production traffic?

 MFNetDIsk uses TCP EZASMI API.

 Can I run 2 TCPIP procedure running together?
  TCPIP which will use IP 192.168.254.254 (for production) and the second,
TCPIPMPC (for only MFNetDisk) which will use 192.168.254.200?

Thanks,
Shai

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

Re: Imagine having to deal with THIS in production

[Mike Schwab]

On Tue, Dec 20, 2011 at 9:53 AM, Ted MacNEIL  wrote:
> Muslims.

The Jewish calendear might be worse.  They use leap months to keep the
calendar roughly aligned with the season.  But after a leap month,
your year to year comparisons of the weather on a certain day of the
year would be similar to comparing March 1 of one year to March 31 of
the next year.  Quite a bit different.
-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Imagine dealing with THIS in production

[Mike Schwab]

That is where the Modified Julian Date comes in by subtracting 1/2 day
os 0.000 is midnight and 0.500 is noon.

Swatch time http://en.wikipedia.org/wiki/Swatch_Internet_Time and
watchs are almost the same thing, but they are using Central Europe
time of UTC+1.
0100Z = @000

On Mon, Dec 19, 2011 at 4:59 PM, Joel C. Ewing  wrote:
> On 12/19/2011 11:53 AM, Mike Schwab wrote:
>>
>> How about the Julian Day as used by astronomers?
>>
>> http://en.wikipedia.org/wiki/Julian_day
>> Julian day is used in the Julian date (JD) system of time measurement
>> for scientific use by the astronomy community, presenting the interval
>> of time in days and fractions of a day since January 1, 4713 BC
>> Greenwich noon. Julian date is recommended for astronomical use by the
>> International Astronomical Union.
>>
>> Almost 2.5 million Julian days have elapsed since the initial epoch.
>> JDN 2,400,000 was November 16, 1858. JD 2,500,000.0 will occur on
>> August 31, 2132 at noon UT.  (Often .leading 2.4 million is assumed
>> and the low order 5 digits is used.)
>>
>> Time is expressed as a fraction of a day.  0.1 day = 2.4 hours, 0.01 =
>> 14.4 minutes.
>> 0.001 = 1.44 minutes, 0.1 = 0.864 seconds. x.000 is Noon UT 1200Z
>>
>> Modified Julian Date subtracts 0.5 so x.000 is Midnight UT Z.
>>
>> On Mon, Dec 19, 2011 at 10:01 AM, Paul Gilmartin
>>  wrote:
>>>
>>> On Mon, 19 Dec 2011 08:44:00 -0600, Chase, John wrote:


 Perhaps the world's eventual conversion to "Star Date" (or similar) will
 be less confusing and disruptive  :-)

>>> Ummm... NVFL.  See:
>>>
>>>    http://en.wikipedia.org/wiki/Stardate
>>>
>>> -- gil
>
>
> Usage of Julian Day will never catch on with non-astronomers for one simple
> reason not yet mentioned - its formal definition requires the date change to
> occur at noon, not midnight.  That makes much sense for astronomers that
> work through the night and sleep during the day, but is a terrible fit for
> people and businesses that have to deal with "normal" work hours and who
> would never tolerate the same period of daylight being called by two
> different dates.
>
> --
> Joel C. Ewing,    Bentonville, AR       jcew...@acm.org
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Question on PR/SM dispatcher

[Vernooij, CP - SPLXM]

"Shmuel Metz  , Seymour J."  wrote in
message news:<20111220170650.bceecf58...@smtp.patriot.net>...
> In
> ,
> on 12/20/2011
>at 04:53 PM, "Vernooij, CP - SPLXM"  said:
> 
> >Of course, but I suppose you know what I meant:
> 
> You're welcome to suppose what you wish. Just don't be surprised when
> your suppositions are wrong more often than they're right.
>  

Yes, in this case this appears to be a good advise.

Kees.

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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

Re: FTP PUT of temporary files possible?

[Donald Johnson]

Thanks Ulrich and John...I was so intent on thinking of the filename, I had
forgotten the //DD functionality...I will give this a go!

Thanks, danke, Merry Christmas und Frohe Weihnachten!

*don*

On Tue, Dec 20, 2011 at 1:15 PM, Ulrich Krueger  wrote:

> You mean something like this?
>
> //STEP9  EXEC  PGM=FTP,PARM='(EXIT TIMEOUT 600'
>
> //RPTVLTF  DD DISP=(OLD),DSN=&&VLTF
> //RPTDRDD DISP=(OLD),DSN=&&DR
> //OUTPUT   DD  SYSOUT=*
> //SYSPRINT DD  SYSOUT=*
> //INPUTDD  *
> Id
> Password
> PUT //DD:RPTVLTF VLTF.TXT
> PUT //DD:RPTDR   #DR#.TXT
>
>
>
> Regards,
> Ulrich Krueger
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf
> Of Donald Johnson
> Sent: Tuesday, December 20, 2011 10:02 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: FTP PUT of temporary files possible?
>
>  Hi all! Does anyone know if or how it is possible to PUT temporary files
> (&&filenm) using FTP in z/OS?
>
> Thanks for the information!
> *don*
>
>  --
> 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
>

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

Re: FTP PUT of temporary files possible?

[McKown, John]

Rats! got the parms to the PUT reversed in the previous email.

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Donald Johnson
> Sent: Tuesday, December 20, 2011 12:02 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: FTP PUT of temporary files possible?
> 
> Hi all! Does anyone know if or how it is possible to PUT 
> temporary files
> (&&filenm) using FTP in z/OS?
> 
> Thanks for the information!
> *don*

Sort of. You can do this, in a batch FTP job:

//DOPUT EXEC PGM=FTP,PARM='(EXIT'
//OUTPUT DD SYSOUT=*
//TEMPFILE DD DISP=OLD,DSN=&&FILENM
//INPUT DD *
ipaddress
userid
password
put //DD:TEMPFILE remote.file
/*
//

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

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

Re: FTP PUT of temporary files possible?

[Ulrich Krueger]

You mean something like this?

//STEP9  EXEC  PGM=FTP,PARM='(EXIT TIMEOUT 600'

//RPTVLTF  DD DISP=(OLD),DSN=&&VLTF  
//RPTDRDD DISP=(OLD),DSN=&&DR
//OUTPUT   DD  SYSOUT=*  
//SYSPRINT DD  SYSOUT=* 
//INPUTDD  *
Id
Password
PUT //DD:RPTVLTF VLTF.TXT 
PUT //DD:RPTDR   #DR#.TXT   
   


Regards,
Ulrich Krueger


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Donald Johnson
Sent: Tuesday, December 20, 2011 10:02 AM
To: IBM-MAIN@bama.ua.edu
Subject: FTP PUT of temporary files possible?

Hi all! Does anyone know if or how it is possible to PUT temporary files
(&&filenm) using FTP in z/OS?

Thanks for the information!
*don*

--
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: FTP PUT of temporary files possible?

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Donald Johnson
> Sent: Tuesday, December 20, 2011 12:02 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: FTP PUT of temporary files possible?
> 
> Hi all! Does anyone know if or how it is possible to PUT 
> temporary files
> (&&filenm) using FTP in z/OS?
> 
> Thanks for the information!
> *don*

Sort of. You can do this, in a batch FTP job:

//DOPUT EXEC PGM=FTP,PARM='(EXIT'
//OUTPUT DD SYSOUT=*
//TEMPFILE DD DISP=OLD,DSN=&&FILENM
//INPUT DD *
ipaddress
userid
password
put remote.file //DD:TEMPFILE
/*
//

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

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

FTP PUT of temporary files possible?

[Donald Johnson]

Hi all! Does anyone know if or how it is possible to PUT temporary files
(&&filenm) using FTP in z/OS?

Thanks for the information!
*don*

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

Re: Questions on PR/SM dispatcher

[John Gilmore]

>From Martin Packer:

|  Chaucer spelt it "cherl".

He did indeed, and he explicated his use of it very neatly in

| For vileyns sinful deeds make a cherl.

in which vileyn/villein/villain is not yet pejorative.  Shane's use
was, I think, the more modern, now standard one that makes churlish is
a near synonym of loutish, rude, impolite, with some remaining
overtones of impropriety.

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: Question on PR/SM dispatcher

[Shmuel Metz (Seymour J.)]

In
,
on 12/20/2011
   at 04:53 PM, "Vernooij, CP - SPLXM"  said:

>Of course, but I suppose you know what I meant:

You're welcome to suppose what you wish. Just don't be surprised when
your suppositions are wrong more often than they're right.
 
-- 
 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: Question on PR/SM dispatcher

[Tom Marchant]

On Tue, 20 Dec 2011 09:19:35 +0100, Vernooij, CP wrote:

>I am quite sure that pr/sm always dispatched Logical CPs and Amdahls
>MDF dispatched entire domains (their word for lpar).

If by "dispatched entire domains" you mean that all of the 
logical processors for a domain were always dispatched 
together, I don't think that is correct.  For one thing, it 
would have made MDF more complicated than it needed to 
be.  For another, it would have meant that if you had 
domain A with 1 LP and domain B with 2 LPs on a system 
with two physical processors, whenever domain A was 
active, one of the processors would have always been idle. 
That would not have been very efficient.

-- 
Tom Marchant

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

Re: Question on PR/SM dispatcher

[Steve Thompson]

"Shane"  wrote in message
news:<20111220123112.2a437a52@xpfs>...
> On Mon, 19 Dec 2011 09:20:16 -0500 Tom Russell wrote:
>
> > PR/SM dispatches Logical CPs not Logical Partitions.


- I am quite sure that pr/sm always dispatched Logical CPs and Amdahls
MDF dispatched entire domains (their word for lpar).



PR/SM and LPARs are IBM's answer to MDF (Multiple Domain Facility and 
Domains). In fact, IBM was AMDAHL's second customer to pay for MDF. But 
because the machine they had wasn't ready to be field upgraded, IBM wasn't 
the second customer to have MDF (man, lots of memories have been awakened 
by this posting).

Through the 5990 machines, all LPs were dispatched simultaneously in a 
Domain. The idea was that we did not want to cause a spin lock loop 
problem that would cause ACR. We also were trying to solve a problem with 
I/O elongation (a domain would start an I/O, lose dispatch, the I/O would 
complete and the interrupt would be "hanging" until the Domain was 
dispatched again). We had discussed asynchronous dispatch, but it was 
decided to not implement it. Then came the big layoff of 1989 just after 
Thanksgiving... I have no idea what happened after that as I never saw any 
AMDAHL machines after the 5990-1400s in any shop where I worked.

I do know that IBM implemented asynchronous dispatch. When, I don't know. 
And the particulars I don't know. And I don't work in POK so I don't have 
access to the LPAR - PR/SM logic, so I honestly can't speak to that at 
all.

Regards,
Steve Thompson
Staff Software Engineer
Connect:Direct for z/OS
IBM - Software Group
(469) 524-2622
sthomp...@us.ibm.com

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

Re: Question on PR/SM dispatcher

[Tom Marchant]

On Tue, 20 Dec 2011 10:33:14 -0500, Shmuel Metz wrote:

>If I recall correctly, MDF was implemented in what Amdahl
>called macrocode, 

That's correct.  Very similar to the millicode on current IBM 
mainframes.  A superset of 370 instructions that ran in 
system state.

>not by dedicated hardware.

There was considerable hardware included in the Amdahl 
580 series processors to make macrocode and MDF work. 
There was a separate set of registers that were available 
in system state. System state was a third state of 
operation, in addition to problem and supervisor state. 
There were additional instructions for referencing the 
domain's registers and storage.  Ther was also hardware 
for mapping domain storage and 31-bit or 32-bit addressing.  
I can't remember which.  This was all designed long before 
Extended Architecture.

When IBM introduced XA, the design of the 580 allowed 
Amdahl to implement Extended Architecture relatively 
easily.

There was an ALTA Principles of Operation that described 
the additional registers, instructions, etc.  I turned in my 
copy of the ALTA POO when I left Amdahl, but I studied it 
thoroughly while I was there.

-- 
Tom Marchant

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

Re: Question on PR/SM dispatcher

[Tom Marchant]

On Tue, 20 Dec 2011 09:14:36 -0500, Shmuel Metz wrote:

>How did MDF detect the end of a timeslice if not by an interrupt?

That is how it detected the end of a time slice.  Early MDF code 
would dispatch a different domain as soon as a processor entered 
a wait state.  That was determined to cause performance problems, 
largely due to the effects of cache misses.  By the time MDF was 
delivered to the field, it was changed so that a domain was allowed 
to run on a processor until its time slice ended.  The result was 
improved performance.

-- 
Tom Marchant

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

Re: Question on PR/SM dispatcher

[Anne & Lynn Wheeler]

shmuel+ibm-m...@patriot.net (Shmuel Metz  , Seymour J.) writes:
> Certainly. If I recall correctly, MDF was implemented in what Amdahl
> called macrocode, not by dedicated hardware. So what triggered the
> redispatch at the end of a time slice if not an external interrupt?

the guys doing MDF use to come to baybunch and pump me for information
... I had done time-slice dispatching since my undergraduate days in the
60s and had been involved in design and implementation of ECPS for the
138/148 ...

there have numerous issues over the years with implementations trying to
get around use of timer-based considerations ... hoping that other
events would provide sufficient control not having to resort to the
additional overhead ... this has periodically resulted in monumental
gafs when the various other failed to occur in the anticipated ways.

the other issue was that the MDF implementation for Amdahl was
significantly simpler because of the macrocode use. 3090 had to respond
with pr/sm ... but that was a significantly more complex undertaking
because there wasn't any equivalent facility and they had to fallback to
horizontal microcode.

there was also issue in the early 1980s when somebody having gotten an
award for changes to mvs/xa, contacted me about whether similar changes
could be made to vm. I commented that I had not done it any other way
since my work as undergraduate in the 60s ... and in fact had arguments
with VS2/SVS (precursor to MVS) in the early 70s about they shouldn't be
doing it the wrong way.

past posts mentioning part of the effort for ECPS
http://www.garlic.com/~lynn/94.html#21

past posts mentioning dispatching/scheduling
http://www.garlic.com/~lynn/subtopic.html#fairshare

misc past posts mentioning macrocode:
http://www.garlic.com/~lynn/2002p.html#44 Linux paging
http://www.garlic.com/~lynn/2002p.html#48 Linux paging
http://www.garlic.com/~lynn/2003.html#9 Mainframe System 
Programmer/Administrator market demand?
http://www.garlic.com/~lynn/2003.html#56 Wild hardware idea
http://www.garlic.com/~lynn/2005d.html#59 Misuse of word "microcode"
http://www.garlic.com/~lynn/2005d.html#60 Misuse of word "microcode"
http://www.garlic.com/~lynn/2005h.html#24 Description of a new old-fashioned 
programming language
http://www.garlic.com/~lynn/2005p.html#14 Multicores
http://www.garlic.com/~lynn/2005p.html#29 Documentation for the New 
Instructions for the z9 Processor
http://www.garlic.com/~lynn/2005u.html#40 POWER6 on zSeries?
http://www.garlic.com/~lynn/2005u.html#43 POWER6 on zSeries?
http://www.garlic.com/~lynn/2005u.html#48 POWER6 on zSeries?
http://www.garlic.com/~lynn/2006b.html#38 blast from the past ... macrocode
http://www.garlic.com/~lynn/2006c.html#9 Mainframe Jobs Going Away
http://www.garlic.com/~lynn/2006j.html#32 Code density and performance?
http://www.garlic.com/~lynn/2006j.html#35 Code density and performance?
http://www.garlic.com/~lynn/2006m.html#39 Using different storage key's
http://www.garlic.com/~lynn/2006p.html#42 old hypervisor email
http://www.garlic.com/~lynn/2006u.html#33 Assembler question
http://www.garlic.com/~lynn/2006u.html#34 Assembler question
http://www.garlic.com/~lynn/2006v.html#20 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2007b.html#1 How many 36-bit Unix ports in the old 
days?
http://www.garlic.com/~lynn/2007d.html#3 Has anyone ever used self-modifying 
microcode? Would it even be useful?
http://www.garlic.com/~lynn/2007d.html#9 Has anyone ever used self-modifying 
microcode? Would it even be useful?
http://www.garlic.com/~lynn/2007j.html#84 VLIW pre-history
http://www.garlic.com/~lynn/2007k.html#74 Non-Standard Mainframe Language?
http://www.garlic.com/~lynn/2007n.html#96 some questions about System z PR/SM
http://www.garlic.com/~lynn/2008c.html#32 New Opcodes
http://www.garlic.com/~lynn/2008c.html#33 New Opcodes
http://www.garlic.com/~lynn/2008c.html#42 New Opcodes
http://www.garlic.com/~lynn/2008j.html#26 Op codes removed from z/10
http://www.garlic.com/~lynn/2008r.html#27 CPU time/instruction table
http://www.garlic.com/~lynn/2010m.html#74 z millicode: where does it reside?
http://www.garlic.com/~lynn/2011c.html#93 Irrational desire to author 
fundamental interfaces

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: Question on PR/SM dispatcher

[Vernooij, CP - SPLXM]

Of course, but I suppose you know what I meant: PR/SM sits waiting for
an LPAR to produce an interrupt and decides then what to do next. MDF
determines that it wants to take action after a certain timeslice,
whether the domains like it or not.

The fact that the end of the timeslice might be signalled by an
interrupt, nominates you for the 'sheesj of the week' posting.

Kees.

"Shmuel Metz  , Seymour J."  wrote in
message news:<20111220151739.9a61ef58...@smtp.patriot.net>...
> In
> ,
> on 12/20/2011
>at 04:15 PM, "Vernooij, CP - SPLXM"  said:
> 
> >Are you serious? 
> 
> Certainly. If I recall correctly, MDF was implemented in what Amdahl
> called macrocode, not by dedicated hardware. So what triggered the
> redispatch at the end of a time slice if not an external interrupt?
>  
> -- 
>  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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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

Re: Imagine having to deal with THIS in production

[Ted MacNEIL]

Muslims.
--Original Message--
From: John Gilmore
Sender: IBM Mainframe Discussion List
To: IBM Mainframe Discussion List
ReplyTo: IBM Mainframe Discussion List
Subject: Re: Imagine having to deal with THIS in production
Sent: 20 Dec 2011 09:47

Mike Schwab wrote:


Actually, the Islamic calendar is 12 lunar months of 29.5 days on
average.  So it is shorter than a solar year by about 11 days and the
1st day of the year cycles through the solar year about every 34 or so
years.


and his point in fact makes mine.  In the standard Moslem view the
aseasonality of the Islamic lunar calendar is one of its chief merits.

Moslems have designed lunisolar calendars.   The Djalali calendar
designed in the 11th century by the Persian poet and astronomer Omar
Khayyam and his colleagues is at least as good a lunisolar calendar as
our much later Gregorian one; and a variant of this calendar is the
one used for secular purposes in Iran today.

But Persian Moslems, be they Sunni or Shia, use the Islamic lunar
calendar for religious purposes.  Like other Moslems they perceive it
to be fairer.  Its aseasonality means that the considerable rigors of
the 9th penitential month of Ramazam/Ramadan are not aggravated for
some Moslems because it always falls in high summer and mitigated for
other Moslems because it always falls in the depths of winter.

A standard, day-serial-number (DSN) scheme is appropriate, indeed
necessary for the internal representation of dates in computer
systems.  External date representations now vary widely at different
places on the surface of this small planet, and since they serve very
different purposes this diversity is likely to persist.

It need not, however, be problematic.  Presentation services can
format dates that are to be printed or displayed in many different
ways.  To support any such display scheme d, one need write only two
trivial subroutines: one that performs the conversion d==>DSN and
another that performs the conversion DSN==>d; conversion between two
such display schemes d, D is then accomplished by the sequence
d==>DSN, DSN==>D.   N such schemes can be supported by writing 2N
subroutines, and a new scheme can be added by writing just two more of
them  (and reassembling a table).

To summarize now, the notion of a universal external date
representation is, I think, chimerical; and it would be easy to
stigmatize as provincial and authoritarian too.

Respect for seasonality is certainly desirable in some contexts and,
as I have tried to make clear, undesirable in others.

Moreover, if our species survives and undertakes space travel even the
notion of a month/lunation will have to be discarded as parochial.

There is a planet in our solar system---Its identification is left as
an exercise for the interested reader---that revolves about the sun in
a period that is shorter than the period of its rotation on its own
axis.  Months being longer than years there, its inhabitants' notion
of a month would surely be very different from ours.

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

-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL

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

Re: Question on PR/SM dispatcher

[Shmuel Metz (Seymour J.)]

In
,
on 12/20/2011
   at 04:15 PM, "Vernooij, CP - SPLXM"  said:

>Are you serious? 

Certainly. If I recall correctly, MDF was implemented in what Amdahl
called macrocode, not by dedicated hardware. So what triggered the
redispatch at the end of a time slice if not an external interrupt?
 
-- 
 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: Question on PR/SM dispatcher

[Martin Packer]

Chaucer spelt it "cherl".

Martin

Martin Packer,
Mainframe Performance Consultant, zChampion
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:
"McKown, John" 
To:
IBM-MAIN@bama.ua.edu, 
Date:
20/12/2011 13:10
Subject:
Re: Question on PR/SM dispatcher
Sent by:
IBM Mainframe Discussion List 



A "churl" is a very old word for a "peasant" or "free man". But became to 
be used for someone who has no manners or "breeding". To be "churlish" is 
to have "bad manners". Like telling a new mom: "That is one ugly baby!"

http://en.wikipedia.org/wiki/Churl

This meaning held through the 15th century, but by then the word had taken 
on negative overtone, meaning "a country person" and then "a low fellow". 
By the 19th century, a new and pejorative meaning arose, "one inclined to 
uncivil or loutish behaviour".


--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please 
contact the sender by reply e-mail and destroy all copies of the original 
message. HealthMarkets(r) is the brand name for products underwritten and 
issued by the insurance subsidiaries of HealthMarkets, Inc. -The 
Chesapeake Life Insurance Company(r), Mid-West National Life Insurance 
Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Vernooij, CP - SPLXM
> Sent: Tuesday, December 20, 2011 2:20 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Question on PR/SM dispatcher
> 
> "Shane"  wrote in message
> news:<20111220123112.2a437a52@xpfs>...
> > On Mon, 19 Dec 2011 09:20:16 -0500 Tom Russell wrote:
> > 
> > > PR/SM dispatches Logical CPs not Logical Partitions.
> > 
> > I wonder if it'd be considered churlish to point out this wasn't
> always
> > the case.
> > 
> > Shane ...
> > 
> 
> Shane,
> 
> - what is churlish, I can't find an understandable translation.
> - I am quite sure that pr/sm always dispatched Logical CPs and Amdahls
> MDF dispatched entire domains (their word for lpar).
> 
> Kees.
> 
> For information, services and offers, please visit our web 
> site: http://www.klm.com. This e-mail and any attachment may 
> contain confidential and privileged material intended for the 
> addressee only. If you are not the addressee, you are 
> notified that no part of the e-mail or any attachment may be 
> disclosed, copied or distributed, and that any other action 
> related to this e-mail or attachment is strictly prohibited, 
> and may be unlawful. If you have received this e-mail by 
> error, please notify the sender immediately by return e-mail, 
> and delete this message. 
> 
> Koninklijke Luchtvaart Maatschappij NV (KLM), its 
> subsidiaries and/or its employees shall not be liable for the 
> incorrect or incomplete transmission of this e-mail or any 
> attachments, nor responsible for any delay in receipt. 
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM 
> Royal Dutch Airlines) is registered in Amstelveen, The 
> Netherlands, with registered number 33014286
> 
> 
> 
> --
> 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








Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU






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

Re: Question on PR/SM dispatcher

[Vernooij, CP - SPLXM]

Are you serious? 
Kees.

"Shmuel Metz  , Seymour J."  wrote in
message news:<20111220144901.d5dcaf58...@smtp.patriot.net>...
> In
> ,
> on 12/19/2011
>at 09:29 AM, "Vernooij, CP - SPLXM"  said:
> 
> >You don't have to wait for it, you can also force it. Amdahl's MDF
> >did it. The main difference was that PR/SM is interrupt driven and
> >MDF was timeslice driven.
> 
> How did MDF detect the end of a timeslice if not by an interrupt?
>  
> -- 
>  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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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

Re: Imagine dealing with THIS in production

[Shmuel Metz (Seymour J.)]

In
,
on 12/19/2011
   at 02:03 PM, Mike Schwab  said:

>Actually, I think they are going to have to downgrade the Big Bang
>(creating all matter and the Universe) to a Large Bang (creating
>known matter withing 15 billion light years but within an existing
>universe past that point).

First they'd have to throw out the known data.
 
-- 
 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: Imagine dealing with THIS in production

[Shmuel Metz (Seymour J.)]

In <20111219091748.715752d5f...@urania.ugcs.caltech.edu>, on
12/19/2011
   at 01:17 AM, glen herrmannsfeldt  said:

>But if I understand it right, the date is computed from the value
>in the interval timer, along with various offsets, only when it is
>actually needed.

Do you really want to know about the 6-hour pseudo clock (SHPC) and
the 24-hour pseudo clock (THPC)?

>With the TOD clock of S/370,

For OS/360 or for OS/VS? Google for Chimera, or for Rube Goldberg.

--
 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: Imagine dealing with THIS in production

[Shmuel Metz (Seymour J.)]

In
,
on 12/19/2011
   at 01:47 PM, "Chase, John"  said:

>Why not specify the epoch origin as the "Big Bang"?

Because there are insurmountable theoretical difficulties in clock
synchronization and insurmountable practical difficulties in getting
an exact date for something billions of years in the past.
 
-- 
 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: Question on PR/SM dispatcher

[Shmuel Metz (Seymour J.)]

In
,
on 12/19/2011
   at 09:29 AM, "Vernooij, CP - SPLXM"  said:

>You don't have to wait for it, you can also force it. Amdahl's MDF
>did it. The main difference was that PR/SM is interrupt driven and
>MDF was timeslice driven.

How did MDF detect the end of a timeslice if not by an interrupt?
 
-- 
 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: WAIT ECB WITH 00 First Byte

[Shmuel Metz (Seymour J.)]

In
,
on 12/18/2011
   at 01:24 AM, Jim Mulder  said:

>I could not find anything in the manuals which says this, but it has
>worked this way for at least 30 years.

It's worked that way since the 1960's, although my documentation[1] is
somewhat more recent.

[1] GY28-6659-7,
IBM System/360 Operating System
MVT Supervisor
dated May 1973. 
 
-- 
 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: Imagine having to deal with THIS in production

[John Gilmore]

Mike Schwab wrote:


Actually, the Islamic calendar is 12 lunar months of 29.5 days on
average.  So it is shorter than a solar year by about 11 days and the
1st day of the year cycles through the solar year about every 34 or so
years.


and his point in fact makes mine.  In the standard Moslem view the
aseasonality of the Islamic lunar calendar is one of its chief merits.

Moslems have designed lunisolar calendars.   The Djalali calendar
designed in the 11th century by the Persian poet and astronomer Omar
Khayyam and his colleagues is at least as good a lunisolar calendar as
our much later Gregorian one; and a variant of this calendar is the
one used for secular purposes in Iran today.

But Persian Moslems, be they Sunni or Shia, use the Islamic lunar
calendar for religious purposes.  Like other Moslems they perceive it
to be fairer.  Its aseasonality means that the considerable rigors of
the 9th penitential month of Ramazam/Ramadan are not aggravated for
some Moslems because it always falls in high summer and mitigated for
other Moslems because it always falls in the depths of winter.

A standard, day-serial-number (DSN) scheme is appropriate, indeed
necessary for the internal representation of dates in computer
systems.  External date representations now vary widely at different
places on the surface of this small planet, and since they serve very
different purposes this diversity is likely to persist.

It need not, however, be problematic.  Presentation services can
format dates that are to be printed or displayed in many different
ways.  To support any such display scheme d, one need write only two
trivial subroutines: one that performs the conversion d==>DSN and
another that performs the conversion DSN==>d; conversion between two
such display schemes d, D is then accomplished by the sequence
d==>DSN, DSN==>D.   N such schemes can be supported by writing 2N
subroutines, and a new scheme can be added by writing just two more of
them  (and reassembling a table).

To summarize now, the notion of a universal external date
representation is, I think, chimerical; and it would be easy to
stigmatize as provincial and authoritarian too.

Respect for seasonality is certainly desirable in some contexts and,
as I have tried to make clear, undesirable in others.

Moreover, if our species survives and undertakes space travel even the
notion of a month/lunation will have to be discarded as parochial.

There is a planet in our solar system---Its identification is left as
an exercise for the interested reader---that revolves about the sun in
a period that is shorter than the period of its rotation on its own
axis.  Months being longer than years there, its inhabitants' notion
of a month would surely be very different from ours.

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: Question on PR/SM dispatcher

[McKown, John]

A "churl" is a very old word for a "peasant" or "free man". But became to be 
used for someone who has no manners or "breeding". To be "churlish" is to have 
"bad manners". Like telling a new mom: "That is one ugly baby!"

http://en.wikipedia.org/wiki/Churl

This meaning held through the 15th century, but by then the word had taken on 
negative overtone, meaning "a country person" and then "a low fellow". By the 
19th century, a new and pejorative meaning arose, "one inclined to uncivil or 
loutish behaviour".


--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Vernooij, CP - SPLXM
> Sent: Tuesday, December 20, 2011 2:20 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Question on PR/SM dispatcher
> 
> "Shane"  wrote in message
> news:<20111220123112.2a437a52@xpfs>...
> > On Mon, 19 Dec 2011 09:20:16 -0500 Tom Russell wrote:
> > 
> > > PR/SM dispatches Logical CPs not Logical Partitions.
> > 
> > I wonder if it'd be considered churlish to point out this wasn't
> always
> > the case.
> > 
> > Shane ...
> > 
> 
> Shane,
> 
> - what is churlish, I can't find an understandable translation.
> - I am quite sure that pr/sm always dispatched Logical CPs and Amdahls
> MDF dispatched entire domains (their word for lpar).
> 
> Kees.
> 
> For information, services and offers, please visit our web 
> site: http://www.klm.com. This e-mail and any attachment may 
> contain confidential and privileged material intended for the 
> addressee only. If you are not the addressee, you are 
> notified that no part of the e-mail or any attachment may be 
> disclosed, copied or distributed, and that any other action 
> related to this e-mail or attachment is strictly prohibited, 
> and may be unlawful. If you have received this e-mail by 
> error, please notify the sender immediately by return e-mail, 
> and delete this message. 
> 
> Koninklijke Luchtvaart Maatschappij NV (KLM), its 
> subsidiaries and/or its employees shall not be liable for the 
> incorrect or incomplete transmission of this e-mail or any 
> attachments, nor responsible for any delay in receipt. 
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM 
> Royal Dutch Airlines) is registered in Amstelveen, The 
> Netherlands, with registered number 33014286
> 
>   
> 
> --
> 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: Tapeless Solutions

[Steve Dover]

George,

Does it have to be IBM?  Per Radoslaw's last post, we are using Bustech MDL 
1000 with Data Domain back end storage.  We are a fairly small shop, and up to 
2 weeks ago we had about 5 TBs of data on tape.  Most of that was Mobius View 
Direct archives.  We just went through the Arcmover process to restack our 
tapes to compress things, and wrote the new output versions to virtual tape.  
It used CA1, just like physical tapes, but the back end storage is magic.  We 
added about 400 GB of "used" storage on the Data Domain after compression and 
deduplication.  I have not used CA Vtape, so I can't speak to that, but if you 
do not have to use IBM, this might be worth a look.

Steve

On Fri, 16 Dec 2011 20:35:32 +, Henke, George  wrote:

>Does anyone know of an IBM completely tapeless solution and what it might cost?
>
>I have heard of the TS7740, but it holds only 6 TB per draw.
>
>We have 750 TB on tape.
>
>
>
>--
>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: Tapeless Solutions

[Richard Pinion]

AMEN my brother!

Richard and Vickie Pinion

--- shai.h...@gmail.com wrote:

From: shai hess 
To: IBM-MAIN@bama.ua.edu
Subject: Re: Tapeless Solutions
Date: Tue, 20 Dec 2011 07:52:14 +0200

MFNetDisk also support tapeless solution for emulated tapes.
MFNetDisk tape emulation let you select MFNetDisk tape manager soultion or
CA or IBM or any other tape manager solution.

MF only trasfer the data and the CCW commands to PC and by that reduce the
CPU utilization in MF.
The PC emulates the TAPE and the 3390 DISK emulation.

MFNetDisk also have customers which are using the MFNetDisk virtual tape
solution in few countries.
You can share tape from any number of MF sites without any distance
limitation.
So, this is very good solution for DR cases.
Beside all of this, MFNetDisk is a free product.




On Tue, Dec 20, 2011 at 2:30 AM, Russell Witt  wrote:

> While the cache is MF DASD (which gives it great performance when writing
> and reading from cache), CA-Vtape now has the ability to be offloaded to
> cheaper dasd that is attached through an NFS Server (such as NetApp or Data
> Domain). And you even have the flexability of having the offload copy go
> through data de-duplication (with Data Domain) and/or having a replicated
> off-site copy and still have a physical tape copy (or two). It allows for
> the client to decide which options are best for which types of tape data.
>
> For example, backup data kept for DR purposes might be best on an NFS
> Server that is duplicated off-site at the DR location and kept for 2-4
> weeks. But for data that needs to be kept for decades (regulatory
> requirements) it might be a lot more cost effective to have 2 phsyical
> high-capacity drives and stack a couple of tera-bytes of data on each
> cartridge for long-term storage. The nice thing about a software solution
> such as CA-Vtape is that it gives you many different options.
>
> If you want a truely "Tapeless Solution" and don't mind keeping un-used
> and un-referenced data on dasd for decades (not very "green" of you) then
> something like CA-Vtape with a replicated NFS Server as the backstore might
> be a very good option. Of course, if you are going tapeless, replication is
> very-much the recommended method. While the NFS Server itself could be
> off-site, having only a single copy of all backup data runs the risk of
> putting all the eggs in a single basket. Which is why tape backups have had
> a primary and duplex copy for decades. Putting both the primary and duplex
> copy into the same physical box kind of defeats the whole point of having 2
> copies of the backup data.
>
> But these are just my opinions.
>
> Russell Witt
> CA 1 L2 Support Manager
>
>
> On 12/19/11, R.S. wrote:
>
> W dniu 2011-12-19 23:02, Henke, George pisze:
> > Will CA VTAPE work on regular MF or does it need the DS8800.
>
> What???
> CA VTAPE is from software being sold by CA. DS8800 is a DASD box being
> sold by IBM.
> CA VTAPE works on any mainframe DASD.
> I don't know what does it mean "work on regular MF".
>
> BTW: IMHO it is very expensive solution. It consumes CPU cycles,
> especially when compression is on (could be offloaded to zIIP), and
> consumes mainframe DASD, which is usually the most expensive DASD.
> Exception: FBA DASD connected using "magic box" like BusTech MDL or
> Luminex, or other. ...but then you don't need VTAPE - those boxes also
> emulate tape units.
>
> My €0.02
>
> --
> 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
>

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




_
Netscape.  Just the Net You Need.

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

RC4 encryption type supported on Kerberos z/OS ?

[Miklos Szigetvari]

Hi

RC4 encryption type supported on Kerberos z/OS ?

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

Re: Abend in LE - S0C1 at CEEHSFXS+310

[Binyamin Dissen]

Yes, I saw that.

It is happening on a CEEHHDLR call. There was previous COBOL but they all
ended.

Running LEDATA against the SVCDUMP I generated does not indicate any LE or
stack errors.

On Mon, 19 Dec 2011 11:49:43 -0500 Lizette Koehler 
wrote:

:>>Data at PSW is
:>>
:>>UNEXPECTED RETURN-CODE:  6576   
:>>
:>
:>
:>What level of z/OS?
:>What is this in COBOL, ASSEMBLER, PL1, etc..
:>
:>What function was involved at the time?
:>
:>Have you looked at the CEEDUMP and determined anything?
:>
:>
:>
:>CEEHSFXS   CEL Stack Frame eXit Schedule
:>
:>A COBOL application with a registered condition handler
:>repeatedly calls CEE3ABD to issue user abends. During the abend
:>processing, if the user handler has requested a resume, the
:>stack frame collapsing routine (CEEHTRAV) could potentially
:>update a wrong save area. It could later result in a branch
:>being taken to a free storage instead of a valid stack frame
:>exit code (SFXM), causing an 0C1.
:>
:>Verification Steps:
:>At the time of an 0C1, the PSW will match the R14 in the DSA of
:>the top entry in the traceback, and will point to a free heap
:>element.
:>
:>
:>Lizette
:>
:>--
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
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: Question on PR/SM dispatcher

[Vernooij, CP - SPLXM]

"Shane"  wrote in message
news:<20111220123112.2a437a52@xpfs>...
> On Mon, 19 Dec 2011 09:20:16 -0500 Tom Russell wrote:
> 
> > PR/SM dispatches Logical CPs not Logical Partitions.
> 
> I wonder if it'd be considered churlish to point out this wasn't
always
> the case.
> 
> Shane ...
> 

Shane,

- what is churlish, I can't find an understandable translation.
- I am quite sure that pr/sm always dispatched Logical CPs and Amdahls
MDF dispatched entire domains (their word for lpar).

Kees.

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



--
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-19 23:52, Henke, George pisze:

Offloading VTAPE to zIIP would not be so bad, no?

No.
(my opinion)


--
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