Re: which 3270 terminal

[ibmm...@foxmail.com]

Dear 
 
 We  don't want to "control" who gets what, and only wish to monitor and audit 
what incoming IP's are coming in for each TSO or CICS userid for one year.

Thanks a lot!

Jason Cai
 

It would depend upon which IP's you are trying to keep track of.  You can 
control the outside IP's as to which which inside LU's they are allowed to use 
and you can assign them one to one if you wish via LUGROUP and LUMAP in your 
TN3270 profile.  
 
If you don't want to "control" who gets what, and only wish to monitor what 
incoming IP's are coming in, assuming they are going ot get an LU at some point 
(and what LU they get if you want), then you can use the TN3270 LU exit, which 
has the incoming IP in Register 1 when the function code in Register 0 is "01- 
assign).  At that point in time you could generate a WTO of the parts you're 
interested in, or generate an SMF record (sort of like FTCHKIP does for FTP).
 
To better answer your question you would need to provide more information on 
just what it is you are trying to accomplish.  If you just want to "know" what 
IP's are coming in at all times, then I have to submit that it's almost foolish 
to do so because while it might be interesting for a couple minutes to look at 
it, but after a while it would likely be ignored and someone (rightly so) would 
probably exclude your WTO in MPFLSTxx.  If you are doing it to be able to exert 
some control over the functionality and "who (which IP) gets in to go where", 
then there are already really good controls built-in filters in TCP do do that, 
(including the TN3270 ones I mentioned above).  There are filters that you can 
use and act on.
 
If you just want to know what IPs are coming in right now and where they are 
going to (application wise), then you can get that from a simple "NETSTAT CONN" 
command.
 
So without knowing more of what you are trying to get and use, it's hard to 
give you help.
 
Brian
  
 
On Wed, 21 Mar 2018 09:02:33 +0800, ibmmain  wrote:
 
>Hi all
>
>
>  We want to monitor  which 3270 terminal (ip address) every  TSO user  logon 
> on .
>
>
>Could you help us?
>
>
>Thanks a lot !
>
>
>Jason Cai
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
 
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
 

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

Re: which 3270 terminal

[Brian Westerman]

It would depend upon which IP's you are trying to keep track of.  You can 
control the outside IP's as to which which inside LU's they are allowed to use 
and you can assign them one to one if you wish via LUGROUP and LUMAP in your 
TN3270 profile.  

If you don't want to "control" who gets what, and only wish to monitor what 
incoming IP's are coming in, assuming they are going ot get an LU at some point 
(and what LU they get if you want), then you can use the TN3270 LU exit, which 
has the incoming IP in Register 1 when the function code in Register 0 is "01- 
assign).  At that point in time you could generate a WTO of the parts you're 
interested in, or generate an SMF record (sort of like FTCHKIP does for FTP).

To better answer your question you would need to provide more information on 
just what it is you are trying to accomplish.  If you just want to "know" what 
IP's are coming in at all times, then I have to submit that it's almost foolish 
to do so because while it might be interesting for a couple minutes to look at 
it, but after a while it would likely be ignored and someone (rightly so) would 
probably exclude your WTO in MPFLSTxx.  If you are doing it to be able to exert 
some control over the functionality and "who (which IP) gets in to go where", 
then there are already really good controls built-in filters in TCP do do that, 
(including the TN3270 ones I mentioned above).  There are filters that you can 
use and act on.

If you just want to know what IPs are coming in right now and where they are 
going to (application wise), then you can get that from a simple "NETSTAT CONN" 
command.

So without knowing more of what you are trying to get and use, it's hard to 
give you help.

Brian
  

On Wed, 21 Mar 2018 09:02:33 +0800, ibmmain  wrote:

>Hi all
>
>
>  We want to monitor  which 3270 terminal (ip address) every  TSO user  logon 
> on .
>
>
>Could you help us?
>
>
>Thanks a lot !
>
>
>Jason Cai
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: which 3270 terminal

[Paul Gilmartin]

On Tue, 20 Mar 2018 20:13:07 -0700, Charles Mills wrote:

>I am responsible for a product that can do that. Real-time alerting to you
>cellphone if someone from, say, a Uzbekistan IP address, logs on.
>
>https://correlog.com/mainframe-security-solutions/
>
>-Original Message-
>From: ibmmain
>Sent: Tuesday, March 20, 2018 6:03 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>
>  We want to monitor  which 3270 terminal (ip address) every  TSO user
>logon on .
>
I suddenly remember:  https://en.wikipedia.org/wiki/Utmp

On Solaris, utmpx is updated at login by a SUID utility.  Several years ago, I 
noticed
that the corresponding utility on MVS was not SUID and the information was not 
being
captured.  Went to SR.  Got WAD.

-- gil

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

Re: which 3270 terminal

[Paul Gilmartin]

On Tue, 20 Mar 2018 20:13:07 -0700, Charles Mills wrote:

>I am responsible for a product that can do that. Real-time alerting to you
>cellphone if someone from, say, a Uzbekistan IP address, logs on.
>
>https://correlog.com/mainframe-security-solutions/
>
>-Original Message-
>From: ibmmain
>Sent: Tuesday, March 20, 2018 6:03 PM
>
>  We want to monitor  which 3270 terminal (ip address) every  TSO user
>logon on .
> 
If you don't need real-time alerts, this sounds like the sort of thing SMF 
likes to do.

-- gil

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

Re: which 3270 terminal

[Charles Mills]

I am responsible for a product that can do that. Real-time alerting to you
cellphone if someone from, say, a Uzbekistan IP address, logs on.

https://correlog.com/mainframe-security-solutions/ 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of ibmmain
Sent: Tuesday, March 20, 2018 6:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: which 3270 terminal

Hi all


  We want to monitor  which 3270 terminal (ip address) every  TSO user
logon on .


Could you help us?


Thanks a lot !


Jason Cai

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

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

Historical recreation/restoration of original FORTH on the IBM 1130

[Jack J. Woehr]

http://rescue1130.blogspot.com.au/2018/03/historical-recreationrestoration-of.html

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

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

Re: which 3270 terminal

[Steve Beaver]

You will need a huge graphics card that can support as large a flat screen(s) 
and then a ton of memory to have them all active all at the same time 

Sent from my iPhone

Sorry for the autocorrect issues 

> On Mar 20, 2018, at 20:02, ibmmain  wrote:
> 
> Hi all
> 
> 
>  We want to monitor  which 3270 terminal (ip address) every  TSO user  logon 
> on .
> 
> 
> Could you help us?
> 
> 
> Thanks a lot !
> 
> 
> Jason Cai
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: which 3270 terminal

[Paul Gilmartin]

On Wed, 21 Mar 2018 09:02:33 +0800, ibmmain wrote:
>
>  We want to monitor  which 3270 terminal (ip address) every  TSO user  logon 
> on .
> 
Do you want to monitor ssh similarly?

-- gil

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

which 3270 terminal

[ibmmain]

Hi all


  We want to monitor  which 3270 terminal (ip address) every  TSO user  logon 
on .


Could you help us?


Thanks a lot !


Jason Cai

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

Re: invalid ENTRY address for IDENTIFY macro

[Charles Mills]

Good thought! Also, is IDENTIFY sensitive to the high-order bit as an AMODE 
indicator?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Tuesday, March 20, 2018 3:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: invalid ENTRY address for IDENTIFY macro

On 20 March 2018 at 17:44, Thomas David Rivers  wrote:

> I'm having some situations where IDENTIFY "sometimes"
> works, but sometimes it gives me a return-code of 12
> in R15.   Return code 12 says:
>
> Entry Address is not within an eligible load module; entry address was 
> not added.

> I'll keep looking - I imagine it's a "head-slapper" - but I was just 
> wondering if anyone had bumped into this before.

Passing IDENTIFY a 24-bit address with some junk in the high byte while in 
31-bit mode?

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

Re: invalid ENTRY address for IDENTIFY macro

[Tony Harminc]

On 20 March 2018 at 17:44, Thomas David Rivers  wrote:

> I'm having some situations where IDENTIFY "sometimes"
> works, but sometimes it gives me a return-code of 12
> in R15.   Return code 12 says:
>
> Entry Address is not within an eligible load module;
> entry address was not added.

> I'll keep looking - I imagine it's a "head-slapper" - but I was just
> wondering if anyone had bumped into this before.

Passing IDENTIFY a 24-bit address with some junk in the high byte
while in 31-bit mode?

Tony H.

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

SMF 90 question

[Charles Mills]

Can anyone enlighten me on SMF 90 fields SMF90WKN, SMF90ASN and SMF90APM?

- What is the difference between the two "subsystem" fields?
- What SET  or SET command takes a subsystem parameter or an
accounting parameter (that would then be recorded in AMF90ASN and SMF90APM)?


Thanks,

Charles 

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

Re: mainframe distribution

[Charles Mills]

IBM of course runs their business as they see fit. No amount of logic on 
IBM-MAIN is likely to change their minds. The people at IBM who make these 
decisions probably do not read IBM-MAIN. 

If we take Phil's point about some Wall Street analyst being able to say "look, 
the mainframe is dying" [or even "not growing very much"] it is one thing if he 
is working from best guesses from employment agencies, etc. It would be quite 
another thing if he had IBM's official numbers to cite.

Phil gave you numbers (that no one here has yet disagreed with) that should be 
good enough for you to make decisions about your business. What would you do 
differently if you knew there were exactly 4763 z/OS sites as opposed to Phil's 
"low thousands"? 

I'd like to know too. But there's a lot of things I would like that I'm not 
going to get.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of ITschak Mugzach
Sent: Tuesday, March 20, 2018 12:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: mainframe distribution

Phil,

It is funny they are trying to hide it. The information can be collected from 
free resources like job seeking portals, linkedin searches, etc. it's just a 
question of time one has to invest collecting this info. IBM or any other 
vendor can't block clients from posting jobs.  As IBM claims they achieved new 
clients (and they publish names from time to time, like the south african 
bank). They should be proud they drive the world, don't they?

ITschak

On Tue, Mar 20, 2018 at 9:29 PM, Phil Smith  wrote:

> ITschak Mugzach wrote:
> >I wonder if anyone (vendors, maybe) has an insight into the mainframe
> market ...
>
> (And then after various discussion):
> >Strange it is so hard to collect this information.
>
> Why? It's proprietary information for IBM about their market. As a 
> vendor for the last 35 years, I've wished for this information, but 
> was never surprised that it wasn't available. Why would they want to release 
> it?
> Sure, in boom times - at one point they said there were 20,000 VM 
> installations. But that was a long time ago, and many of those were 
> probably 9370s in a closet that were never really used. Now? All it 
> would do is provide fodder for folks saying "See, the mainframe 
> business is shrinking". (Whether that's true or not is irrelevant: the 
> number of licenses is surely shrinking, as companies consolidate and 
> few if any new z shops are created.)
>
> Best guesses I've seen in recent years: low thousands for z/OS; fewer 
> for z/VM (still > 1K; I think); fewer still for z/VSE; and 150 max for 
> z/TPF (perhaps half that).

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

invalid ENTRY address for IDENTIFY macro

[Thomas David Rivers]

The IDENTIFY macro/service is used to match a name
to an address to create an entry point (that entry-point
can later be used on ATTACH for example.)

I'm having some situations where IDENTIFY "sometimes"
works, but sometimes it gives me a return-code of 12
in R15.   Return code 12 says:

Entry Address is not within an eligible load module;
entry address was not added.

The address is actually within the load module invoking
the IDENTIFY macro, and that load module was kicked off
with a TSO CALL (which presumably does a LOAD or LINK
to get the program running?)

I say this is "sometimes" - because sometimes it works.. it
seems to depend on changes to the program. 


I thought, perhaps, there were some alignment requirements
on the address (since it change when I edit the program.)
But double-word aligning the entry point (and verifying
that the address is actually double-word aligned) didn't
seem to change anything...

I'll keep looking - I imagine it's a "head-slapper" - but I was just
wondering if anyone had bumped into this before.

   - Thanks -
   - Dave Rivers -


--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

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

Exit 6 that sets the job class was Re: EXIT to control use of Class

[Jesse 1 Robinson]

I'm not familiar with the CBT version of Exit 6, but ours does exactly this 
sort of thing. You can set/change all kinds of attributes based on all kinds of 
criteria. It's a very powerful mechanism.  

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Clark Morris
Sent: Tuesday, March 20, 2018 2:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Exit 6 that sets the job class was Re: EXIT to control use 
of Class

[Default] On 16 Mar 2018 10:38:43 -0700, in bit.listserv.ibm-main 
dbajava...@gmail.com (Peter) wrote:

>Hi
>
>Is there an EXIT which can assign CLASS to the users based on RACF ID ? 
>For example even if a user tries to use CLASS C the user Job must run 
>only using CLASS A.

File 175 contains the Philips Lighting JES2 mods that were designed to ease the 
conversion from JES 3 to JES2.  The primary changes were in an upgrade to the 
American Natural Resources EXIT6.  While the exit was based on the first 3 
characters of user=id, it was changed after I left to use ACF2 or RACF to 
determine privilege.


The exit does the following:

For production jobs submitted by CA-7, the class is left as A unless it uses a 
TCAM queue in which case it is set to the class for that queue.  The class is 
shared with test jobs.

For test jobs, the class is set based on time requested in the job card and the 
number of tape drives.  Systems programmer jobs were set to a corresponding set 
of classes that would run if test jobs were held by turning off the class.  The 
catalog was checked for all input data sets to determine whether the data set 
was on tape. 

In most if not all cases the class on the job card is ignored.  The FCB was set 
based on form and there may be other things I forget offhand.

All PROC usage was logged in SMF with the JES2 library concatenation.

From what I have read, if you use exit 6 you may also have to code another 
corresponding exit. With the many changes in JCL since 1991, especially, with 
the JCLLIB, multiple levels of PROC and INCLUDE statements, major changes might 
have to be made.

The major philosophy of the exit was that the system could determine the proper 
job class and if it could determine it, the system should set it and the 
programmer didn't have to know the rules.

Packages and workload manager may be able to handle some or all of the 
functions of this exit. 

If anyone is interested, File 175 can be downloaded from www.cbttape.org.  Sam 
Golob has included my home phone number which does have call answer in the 
writeup for FILE 175.  It is a standard North American phone number and I have 
had it for over 26 years. Since I have North America wide free calling I can 
return phone calls without penalty.  I have a copy of file 175 on my computer 
so I may be able to help if someone actually wants to use any of the files in 
the submission.  It has been a fun trip through memory lane.  

Having the CBT tape, IPO samples and a concurrent conversion of production 
output SYSOUT to put all reports in CA-DISPATCH enabled us to convert in a 3 - 
4 month timeframe from JES3 to JES2 with little effect on the application 
programmers.

Clark Morris   
>
>This is for our training LPAR and I would like to implement this feature.
>
>We are at zOS1.13
>
>Regards
>Peter


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

Re: Moving to capped LPARs

[Jesse 1 Robinson]

We're not looking to save money on these products. Any savings would be in not 
having to run a separate z/OS CEC to support them. We also don't want to spend 
a whole lot more in a capped LPAR on a larger CEC.

For ten years we've run a 'Mutt and Jeff' configuration: one large data host 
and one very small penalty box. In our next upgrade, we'd like to turn the 
penalty box into a CF-only machine and run all z/OS LPARs on the larger box. 
It's the products I named that will do exactly the same work as currently but 
in a capped LPAR. 

BTW I learned at SHARE that ISVs are in the process of signing on to SCRT with 
IBM's full support. Most customers like this idea. One way to report s/w usage 
to all vendors. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Porowski, Kenneth
Sent: Tuesday, March 20, 2018 2:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Moving to capped LPARs

I have found that most (but not all) vendors will do some type of sub-capacity 
licensing.
I haven't found any yet that do monthly usage based upon SCRT reports.
For a MIPS based license I've had luck with a max 4HA usage for the year with 
overage true up at year end.
Certain products can have a usage metric applied.  Concurrent users, number of 
printers, number of jobs submitted, etc.
Don't expect low dollar products to have sub-capacity.

And of course whenever you change your licensing don't expect the price to go 
down from your current metric.
The vendor wants to preserve their incoming cash so moving from a full box MIPS 
license to a sub-capacity MIPS or usage based license your overall price will 
not drastically go down (unless you really fight for it).



This email message and any accompanying materials may contain proprietary, 
privileged and confidential information of CIT Group Inc. or its subsidiaries 
or affiliates (collectively, “CIT”), and are intended solely for the 
recipient(s) named above.  If you are not the intended recipient of this 
communication, any use, disclosure, printing, copying or distribution, or 
reliance on the contents, of this communication is strictly prohibited.  CIT 
disclaims any liability for the review, retransmission, dissemination or other 
use of, or the taking of any action in reliance upon, this communication by 
persons other than the intended recipient(s).  If you have received this 
communication in error, please reply to the sender advising of the error in 
transmission, and immediately delete and destroy the communication and any 
accompanying materials.  To the extent permitted by applicable law, CIT and 
others may inspect, review, monitor, analyze, copy, record and retain any 
communications sent from or received at this email address.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Tuesday, March 20, 2018 3:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] Moving to capped LPARs

We'd like to move a few ISV products from a small CEC to a larger CEC with 
capped LPARs. The capped LPARs would be no larger than the small-CEC LPARs 
they're in now. The question is whether anyone has experience in this sort of 
move. In particular, would these vendors likely agree to such a move? The list 
includes

LRS (VPS and DRS)
System Ware (JHS)
BMC (CONTROL-D/V)
CA (TPX)

Of course we are contacting the vendors directly. Just want a feel for others' 
experience. We've never done this before.


.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office <= NEW
robin...@sce.com


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


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

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

Re: mainframe distribution

[Porowski, Kenneth]

And the various employment/contracting agencies probably have a better list 
that we can come up with but I doubt that would be published.



This email message and any accompanying materials may contain proprietary, 
privileged and confidential information of CIT Group Inc. or its subsidiaries 
or affiliates (collectively, “CIT”), and are intended solely for the 
recipient(s) named above.  If you are not the intended recipient of this 
communication, any use, disclosure, printing, copying or distribution, or 
reliance on the contents, of this communication is strictly prohibited.  CIT 
disclaims any liability for the review, retransmission, dissemination or other 
use of, or the taking of any action in reliance upon, this communication by 
persons other than the intended recipient(s).  If you have received this 
communication in error, please reply to the sender advising of the error in 
transmission, and immediately delete and destroy the communication and any 
accompanying materials.  To the extent permitted by applicable law, CIT and 
others may inspect, review, monitor, analyze, copy, record and retain any 
communications sent from or received at this email address.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Phil Smith
Sent: Tuesday, March 20, 2018 3:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] mainframe distribution

ITschak Mugzach wrote:
>I wonder if anyone (vendors, maybe) has an insight into the mainframe market 
>...

(And then after various discussion):
>Strange it is so hard to collect this information.

Why? It's proprietary information for IBM about their market. As a vendor for 
the last 35 years, I've wished for this information, but was never surprised 
that it wasn't available. Why would they want to release it? Sure, in boom 
times - at one point they said there were 20,000 VM installations. But that was 
a long time ago, and many of those were probably 9370s in a closet that were 
never really used. Now? All it would do is provide fodder for folks saying 
"See, the mainframe business is shrinking". (Whether that's true or not is 
irrelevant: the number of licenses is surely shrinking, as companies 
consolidate and few if any new z shops are created.)

Best guesses I've seen in recent years: low thousands for z/OS; fewer for z/VM 
(still > 1K; I think); fewer still for z/VSE; and 150 max for z/TPF (perhaps 
half that).
--
...phsiii

Phil Smith III
Senior Architect & Product Manager, Mainframe & Enterprise Distinguished 
Technologist Micro Focus (Voltage)

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


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

Exit 6 that sets the job class was Re: EXIT to control use of Class

[Clark Morris]

[Default] On 16 Mar 2018 10:38:43 -0700, in bit.listserv.ibm-main
dbajava...@gmail.com (Peter) wrote:

>Hi
>
>Is there an EXIT which can assign CLASS to the users based on RACF ID ? For
>example even if a user tries to use CLASS C the user Job must run only
>using CLASS A.

File 175 contains the Philips Lighting JES2 mods that were designed to
ease the conversion from JES 3 to JES2.  The primary changes were in
an upgrade to the American Natural Resources EXIT6.  While the exit
was based on the first 3 characters of user=id, it was changed after I
left to use ACF2 or RACF to determine privilege.


The exit does the following:

For production jobs submitted by CA-7, the class is left as A unless
it uses a TCAM queue in which case it is set to the class for that
queue.  The class is shared with test jobs.

For test jobs, the class is set based on time requested in the job
card and the number of tape drives.  Systems programmer jobs were set
to a corresponding set of classes that would run if test jobs were
held by turning off the class.  The catalog was checked for all input
data sets to determine whether the data set was on tape. 

In most if not all cases the class on the job card is ignored.  The
FCB was set based on form and there may be other things I forget
offhand.

All PROC usage was logged in SMF with the JES2 library concatenation.

From what I have read, if you use exit 6 you may also have to code
another corresponding exit. With the many changes in JCL since 1991,
especially, with the JCLLIB, multiple levels of PROC and INCLUDE
statements, major changes might have to be made.

The major philosophy of the exit was that the system could determine
the proper job class and if it could determine it, the system should
set it and the programmer didn't have to know the rules.

Packages and workload manager may be able to handle some or all of the
functions of this exit. 

If anyone is interested, File 175 can be downloaded from
www.cbttape.org.  Sam Golob has included my home phone number which
does have call answer in the writeup for FILE 175.  It is a standard
North American phone number and I have had it for over 26 years. Since
I have North America wide free calling I can return phone calls
without penalty.  I have a copy of file 175 on my computer so I may be
able to help if someone actually wants to use any of the files in the
submission.  It has been a fun trip through memory lane.  

Having the CBT tape, IPO samples and a concurrent conversion of
production output SYSOUT to put all reports in CA-DISPATCH enabled us
to convert in a 3 - 4 month timeframe from JES3 to JES2 with little
effect on the application programmers.

Clark Morris   
>
>This is for our training LPAR and I would like to implement this feature.
>
>We are at zOS1.13
>
>Regards
>Peter
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Moving to capped LPARs

[Porowski, Kenneth]

I have found that most (but not all) vendors will do some type of sub-capacity 
licensing.
I haven't found any yet that do monthly usage based upon SCRT reports.
For a MIPS based license I've had luck with a max 4HA usage for the year with 
overage true up at year end.
Certain products can have a usage metric applied.  Concurrent users, number of 
printers, number of jobs submitted, etc.
Don't expect low dollar products to have sub-capacity.

And of course whenever you change your licensing don't expect the price to go 
down from your current metric.
The vendor wants to preserve their incoming cash so moving from a full box MIPS 
license to a sub-capacity MIPS or usage based license your overall price will 
not drastically go down (unless you really fight for it).



This email message and any accompanying materials may contain proprietary, 
privileged and confidential information of CIT Group Inc. or its subsidiaries 
or affiliates (collectively, “CIT”), and are intended solely for the 
recipient(s) named above.  If you are not the intended recipient of this 
communication, any use, disclosure, printing, copying or distribution, or 
reliance on the contents, of this communication is strictly prohibited.  CIT 
disclaims any liability for the review, retransmission, dissemination or other 
use of, or the taking of any action in reliance upon, this communication by 
persons other than the intended recipient(s).  If you have received this 
communication in error, please reply to the sender advising of the error in 
transmission, and immediately delete and destroy the communication and any 
accompanying materials.  To the extent permitted by applicable law, CIT and 
others may inspect, review, monitor, analyze, copy, record and retain any 
communications sent from or received at this email address.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Tuesday, March 20, 2018 3:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] Moving to capped LPARs

We'd like to move a few ISV products from a small CEC to a larger CEC with 
capped LPARs. The capped LPARs would be no larger than the small-CEC LPARs 
they're in now. The question is whether anyone has experience in this sort of 
move. In particular, would these vendors likely agree to such a move? The list 
includes

LRS (VPS and DRS)
System Ware (JHS)
BMC (CONTROL-D/V)
CA (TPX)

Of course we are contacting the vendors directly. Just want a feel for others' 
experience. We've never done this before.


.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office <= NEW
robin...@sce.com


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


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

Re: Moving to capped LPARs

[Feller, Paul]

We did that same thing.  We put the three lpars from the small box into a 
capacity group on the bigger box.  We set the group capacity (MSU) to the same 
as what the small box had.  As others have said the issue is to get the vendors 
to accept subcapacity licensing.  We had a struggle with a few vendors.  


Thanks..

Paul Feller
AGT Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Tuesday, March 20, 2018 14:23
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Moving to capped LPARs

We'd like to move a few ISV products from a small CEC to a larger CEC with 
capped LPARs. The capped LPARs would be no larger than the small-CEC LPARs 
they're in now. The question is whether anyone has experience in this sort of 
move. In particular, would these vendors likely agree to such a move? The list 
includes

LRS (VPS and DRS)
System Ware (JHS)
BMC (CONTROL-D/V)
CA (TPX)

Of course we are contacting the vendors directly. Just want a feel for others' 
experience. We've never done this before.


.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office <= NEW
robin...@sce.com


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

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

Re: mainframe distribution

[ITschak Mugzach]

Phil,

It is funny they are trying to hide it. The information can be collected
from free resources like job seeking portals, linkedin searches, etc. it's
just a question of time one has to invest collecting this info. IBM or any
other vendor can't block clients from posting jobs.  As IBM claims they
achieved new clients (and they publish names from time to time, like the
south african bank). They should be proud they drive the world, don't they?

ITschak

On Tue, Mar 20, 2018 at 9:29 PM, Phil Smith  wrote:

> ITschak Mugzach wrote:
> >I wonder if anyone (vendors, maybe) has an insight into the mainframe
> market ...
>
> (And then after various discussion):
> >Strange it is so hard to collect this information.
>
> Why? It's proprietary information for IBM about their market. As a vendor
> for the last 35 years, I've wished for this information, but was never
> surprised that it wasn't available. Why would they want to release it?
> Sure, in boom times - at one point they said there were 20,000 VM
> installations. But that was a long time ago, and many of those were
> probably 9370s in a closet that were never really used. Now? All it would
> do is provide fodder for folks saying "See, the mainframe business is
> shrinking". (Whether that's true or not is irrelevant: the number of
> licenses is surely shrinking, as companies consolidate and few if any new z
> shops are created.)
>
> Best guesses I've seen in recent years: low thousands for z/OS; fewer for
> z/VM (still > 1K; I think); fewer still for z/VSE; and 150 max for z/TPF
> (perhaps half that).
> --
> ...phsiii
>
> Phil Smith III
> Senior Architect & Product Manager, Mainframe & Enterprise
> Distinguished Technologist
> Micro Focus (Voltage)
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
for Legacy **|  *

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

Re: Moving to capped LPARs

[Jerry Whitteridge]

We moved from a penalty box CEC to an Capped LPAR with no issues but none
of your products were part of our stack on that penalty box.

I'm pretty sure that BMC does NOT provide Sub Cap licenses from some of the
other products we have from BMC.

2 things to check are if the Vendor will give you a subcap license in the
first place, and then if they will accept the capping and how to report on
the results. We attempt to have them use the z/OS value for the LPAR in the
SCRT report where we can.

Jerry Whitteridge
Delivery Manager - Safeway
602 527 4871 Mobile
jerry.whitteri...@ibm.com

IBM Services

IBM Mainframe Discussion List  wrote on
03/20/2018 12:22:33 PM:

> From: Jesse 1 Robinson 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 03/20/2018 12:23 PM
> Subject: Moving to capped LPARs
> Sent by: IBM Mainframe Discussion List 
>
> We'd like to move a few ISV products from a small CEC to a larger
> CEC with capped LPARs. The capped LPARs would be no larger than the
> small-CEC LPARs they're in now. The question is whether anyone has
> experience in this sort of move. In particular, would these vendors
> likely agree to such a move? The list includes
>
> LRS (VPS and DRS)
> System Ware (JHS)
> BMC (CONTROL-D/V)
> CA (TPX)
>
> Of course we are contacting the vendors directly. Just want a feel
> for others' experience. We've never done this before.
>
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office <= NEW
> robin...@sce.com
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Moving to capped LPARs

[Gibney, Dave]

We do VPS and DRS with a number of printers license, so it isn't effected by 
CPU capacity.
BMC was not easy to deal with. At first, they denied the entire concept of 
subcapacity licenseing. I think we shifted to some other metric and suffered a 
$10K re-hosing fee.
We don't have TPX, but CA was reasonable with our other products.

No Systemware here.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Jesse 1 Robinson
> Sent: Tuesday, March 20, 2018 12:23 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Moving to capped LPARs
> 
> We'd like to move a few ISV products from a small CEC to a larger CEC with
> capped LPARs. The capped LPARs would be no larger than the small-CEC
> LPARs they're in now. The question is whether anyone has experience in this
> sort of move. In particular, would these vendors likely agree to such a move?
> The list includes
> 
> LRS (VPS and DRS)
> System Ware (JHS)
> BMC (CONTROL-D/V)
> CA (TPX)
> 
> Of course we are contacting the vendors directly. Just want a feel for others'
> experience. We've never done this before.
> 
> 
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office <= NEW
> robin...@sce.com
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: mainframe distribution

[Phil Smith]

ITschak Mugzach wrote:
>I wonder if anyone (vendors, maybe) has an insight into the mainframe market 
>...

(And then after various discussion):
>Strange it is so hard to collect this information.

Why? It's proprietary information for IBM about their market. As a vendor for 
the last 35 years, I've wished for this information, but was never surprised 
that it wasn't available. Why would they want to release it? Sure, in boom 
times - at one point they said there were 20,000 VM installations. But that was 
a long time ago, and many of those were probably 9370s in a closet that were 
never really used. Now? All it would do is provide fodder for folks saying 
"See, the mainframe business is shrinking". (Whether that's true or not is 
irrelevant: the number of licenses is surely shrinking, as companies 
consolidate and few if any new z shops are created.)

Best guesses I've seen in recent years: low thousands for z/OS; fewer for z/VM 
(still > 1K; I think); fewer still for z/VSE; and 150 max for z/TPF (perhaps 
half that).
--
...phsiii

Phil Smith III
Senior Architect & Product Manager, Mainframe & Enterprise
Distinguished Technologist
Micro Focus (Voltage)

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

Moving to capped LPARs

[Jesse 1 Robinson]

We'd like to move a few ISV products from a small CEC to a larger CEC with 
capped LPARs. The capped LPARs would be no larger than the small-CEC LPARs 
they're in now. The question is whether anyone has experience in this sort of 
move. In particular, would these vendors likely agree to such a move? The list 
includes

LRS (VPS and DRS)
System Ware (JHS)
BMC (CONTROL-D/V)
CA (TPX)

Of course we are contacting the vendors directly. Just want a feel for others' 
experience. We've never done this before.


.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office <= NEW
robin...@sce.com


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

Re: [External] Re: mainframe distribution

[ITschak Mugzach]

Ok. Let's make it even simpler. Number of mainframe clients, will work?

Strange it is so hard to collect this information.

ITschak

בתאריך 20 במרץ 2018 20:54,‏ "Pommier, Rex"  כתב:

> Heck, I don't even know how many installations are in my city - and that's
> only a couple hundred thousand people!
>
> The next question concerns "what's a site?"  Does a site need a
> mainframe?  Or can the physical equipment be across the country or
> somewhere else on another continent?  I know of at least 2 companies that
> have development staff local (one has hundreds of developers) but no
> hardware because their equipment is all at other locations.  We also have
> another large installation that will remain nameless that has lots of
> equipment but a skeleton staff maintaining it.  All operations,
> development, etc is elsewhere, they just have a data center here.  Which of
> these qualifies as a site or an installation?
>
> Rex
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of zMan
> Sent: Tuesday, March 20, 2018 1:37 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [External] Re: mainframe distribution
>
> Same problem. We have a lot of BIG states, with widely spaced cities...
>
> On Tue, Mar 20, 2018 at 1:35 PM, ITschak Mugzach 
> wrote:
>
> > So let's divide it into states...
> >
> > On Tue, Mar 20, 2018 at 7:01 PM, zMan  wrote:
> >
> > > Maybe in smaller countries. In U.S.? Not so much.
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> The information contained in this message is confidential, protected from
> disclosure and may be legally privileged.  If the reader of this message is
> not the intended recipient or an employee or agent responsible for
> delivering this message to the intended recipient, you are hereby notified
> that any disclosure, distribution, copying, or any action taken or action
> omitted in reliance on it, is strictly prohibited and may be unlawful.  If
> you have received this communication in error, please notify us immediately
> by replying to this message and destroy the material in its entirety,
> whether in electronic or hard copy format.  Thank you.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

AW: Re: Using Pseudo Post

[Peter Hunkeler]

The WAIT service sets the task non-dispatchable. How would the task being woken 
up using a quick post? MVS is not monitoring the ECB. It is the POST service 
which understands that a task has to be woken up.
A quick post works only if the ECB has not already been used in a WAIT service, 
i.e. the task has *not yet* been set non-dispatchable by a WAIT on that 
specific ECB.

--Peter Hunkeler


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

RES: zhyperwrite monitor

[ITURIEL DO NASCIMENTO NETO]

Jason,

You can see response time of both primary and secondary dasds, if zHyperwrite 
is enabled, in RMF monitor II.
If zHyperwrite is turned off, you will only see primary dasd.

Atenciosamente / Regards / Saludos

Ituriel do Nascimento Neto
BANCO BRADESCO S.A.
4250 / DITI Engenharia de Software
Sistemas Operacionais Mainframes
Tel: +55 11 3684-9602 R: 49602 3-1404
Fax: +55 11 3684-4427



-Mensagem original-
De: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Em nome de 
ibmm...@foxmail.com
Enviada em: segunda-feira, 12 de março de 2018 22:59
Para: IBM-MAIN@LISTSERV.UA.EDU
Assunto: zhyperwrite monitor

Hi all

We want to use ZHYPERWRITE.

 If there are any issues (including performance) with FICON channels to the 
secondary DB2 log volume,

DFSMS will give instruction to the DS8880 to start Metro Mirror replication

Could you tell how to know the system use zhyperwrite to  the secondary DB2 log 
volume directly or start

 Metro Mirror replication to the DB2 Log ?


Thanks a lot!

Jason Cai


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

AVISO LEGAL ...Esta mensagem é destinada exclusivamente para a(s) pessoa(s) 
a quem é dirigida, podendo conter informação confidencial e/ou legalmente 
privilegiada. Se você não for destinatário desta mensagem, desde já fica 
notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de 
qualquer forma, utilizar a informação contida nesta mensagem, por ser ilegal. 
Caso você tenha recebido esta mensagem por engano, pedimos que nos retorne este 
E-Mail, promovendo, desde logo, a eliminação do seu conteúdo em sua base de 
dados, registros ou sistema de controle. Fica desprovida de eficácia e validade 
a mensagem que contiver vínculos obrigacionais, expedida por quem não detenha 
poderes de representação. 
LEGAL ADVICE...This message is exclusively destined for the people to whom 
it is directed, and it can bear private and/or legally exceptional information. 
If you are not addressee of this message, since now you are advised to not 
release, copy, distribute, check or, otherwise, use the information contained 
in this message, because it is illegal. If you received this message by 
mistake, we ask you to return this email, making possible, as soon as possible, 
the elimination of its contents of your database, registrations or controls 
system. The message that bears any mandatory links, issued by someone who has 
no representation powers, shall be null or void.

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

Re: [External] Re: mainframe distribution

[Pommier, Rex]

Heck, I don't even know how many installations are in my city - and that's only 
a couple hundred thousand people!  

The next question concerns "what's a site?"  Does a site need a mainframe?  Or 
can the physical equipment be across the country or somewhere else on another 
continent?  I know of at least 2 companies that have development staff local 
(one has hundreds of developers) but no hardware because their equipment is all 
at other locations.  We also have another large installation that will remain 
nameless that has lots of equipment but a skeleton staff maintaining it.  All 
operations, development, etc is elsewhere, they just have a data center here.  
Which of these qualifies as a site or an installation?

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of zMan
Sent: Tuesday, March 20, 2018 1:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: mainframe distribution

Same problem. We have a lot of BIG states, with widely spaced cities...

On Tue, Mar 20, 2018 at 1:35 PM, ITschak Mugzach  wrote:

> So let's divide it into states...
>
> On Tue, Mar 20, 2018 at 7:01 PM, zMan  wrote:
>
> > Maybe in smaller countries. In U.S.? Not so much.
>

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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

Re: mainframe distribution

[zMan]

Same problem. We have a lot of BIG states, with widely spaced cities...

On Tue, Mar 20, 2018 at 1:35 PM, ITschak Mugzach  wrote:

> So let's divide it into states...
>
> On Tue, Mar 20, 2018 at 7:01 PM, zMan  wrote:
>
> > Maybe in smaller countries. In U.S.? Not so much.
>

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

Re: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell

[Seymour J Metz]

"Except each application running in the environment would need to be modified."

No. Those applications that ran in linemode would continue to run in line mode. 
Thos applications that ran with TN3270 would continue to run with TN3270. It's 
only the existing 3270 applications, e.g., ISPF, that IBM wanted to run with 
X11 that would need to be modified.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
David Boyes 
Sent: Monday, March 19, 2018 4:10 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell

> If you want a break with 3270, why a Rube Goldberg with line mode. Make the 
> application an X11 client instead.

Except each application running in the environment would need to be modified. 
The approach I suggested doesn't require any application code to be modified if 
you don't want/have to. It also would allow ordinary terminals to replace most 
real 3270s that aren't operator/service processor consoles (ASCII terminal 
controllers like the 7171 or 3174 AEA feature notwithstanding - if you had a 
7171, you could probably get rid of the operator consoles too).

> We'd all be better of if SUN's paradigm of the thin client (X11 server) had 
> caught on.

Kinda. Any GUI is going to be more processor-intensive than a character mode 
application; there's just more data to move. Moving the UI to a universal 
well-documented interface like X11 would have been nice, but too few systems at 
the time supported it (and at that time, the IBM TCP on MVS implementation 
probably would have rolled over and croaked if asked to support that kind of 
load; they were deep in the SNA vs TCP wars at the time and IBM didn't want TCP 
to look good in any way).


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

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

Re: Using Pseudo Post

[Seymour J Metz]

I see multiple issues with that code.

 1. Turning off bits 0 and 1 of R4 will prevent an equal compare when you want 
one

 2.  You aren't initializing bits 8-31 of the post code in R7

 3. If the wait bit is on then you need a real post

 4. I don't see the point of the STIMER and WTO

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of Joe 
Reichman 
Sent: Monday, March 19, 2018 6:40 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Using Pseudo Post

I am using Quick Post Here is the code

 L R4,RECOV#ECB
 L R8,RECOV#ECB Get ECB Address
 L R4,0(,R4)get ecb
 N R4,=X'3FFF'  Turn of wait post bit
 ICM   R7,B'1000',=X'40'Insret Post bit
 LAR11,5  try 5 times
CSLOOP   DS0H
 CSR4,R7,0(R8)
 BZPOSTDONE
 STIMER  WAIT,DINTVL=TWOSECS   WAIT A COUPLE
 WTO   'ERROR POSTING...'
 BCT   R11,CSLOOP
Sent from Mail for Windows 10

From: Charles Mills
Sent: Monday, March 19, 2018 6:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Using Pseudo Post

Did you code ASCB= (correctly). You need that even if the ECB is in common.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joe Reichman
Sent: Monday, March 19, 2018 3:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Using Pseudo Post

The ECB is in Fixed CSA running under a different Address space for some reason 
even after posted the task is still not dispatched I know this because I have 
placed a WTO right after

I am running under TESTAUTH and can observe the ECB  before with the 80 bit and 
the RB and after with 40 bit using TASID with the storage view function

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


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

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

Re: mainframe distribution

[ITschak Mugzach]

So let's divide it into states...

On Tue, Mar 20, 2018 at 7:01 PM, zMan  wrote:

> Maybe in smaller countries. In U.S.? Not so much.
>
> On Tue, Mar 20, 2018 at 11:26 AM, ITschak Mugzach 
> wrote:
>
> > I believe that most of us aware of the number of sites in their country.
> > They look for jobs from time to time, meet others in couses, fairs, etc.
> > Number should not be 100% accurate.
> >
> > ITschak
> >
> > בתאריך 20 במרץ 2018 16:15,‏ "Charles Mills"  כתב:
> >
> > > > can we back to the main issue here: Mainframe distribution"?
> > >
> > > Those who know don't say; those who say don't know.
> > >
> > > The question comes up here from time to time and the answer is always
> the
> > > same.
> > >
> > > Charles
> > >
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
>
> --
> zMan -- "I've got a mainframe and I'm not afraid to use it"
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
for Legacy **|  *

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

Re: mainframe distribution

[zMan]

Maybe in smaller countries. In U.S.? Not so much.

On Tue, Mar 20, 2018 at 11:26 AM, ITschak Mugzach 
wrote:

> I believe that most of us aware of the number of sites in their country.
> They look for jobs from time to time, meet others in couses, fairs, etc.
> Number should not be 100% accurate.
>
> ITschak
>
> בתאריך 20 במרץ 2018 16:15,‏ "Charles Mills"  כתב:
>
> > > can we back to the main issue here: Mainframe distribution"?
> >
> > Those who know don't say; those who say don't know.
> >
> > The question comes up here from time to time and the answer is always the
> > same.
> >
> > Charles
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

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

Re: mainframe distribution

[ITschak Mugzach]

I believe that most of us aware of the number of sites in their country.
They look for jobs from time to time, meet others in couses, fairs, etc.
Number should not be 100% accurate.

ITschak

בתאריך 20 במרץ 2018 16:15,‏ "Charles Mills"  כתב:

> > can we back to the main issue here: Mainframe distribution"?
>
> Those who know don't say; those who say don't know.
>
> The question comes up here from time to time and the answer is always the
> same.
>
> Charles
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Can the CSI info alone produce a final list required for full resolution of researched PTFs?

[Joel C. Ewing]

And no one seems to have mentioned that when an ERROR hold is first put
on one of the PTFs in your  chain, it rarely contains a resolving PTF
initially - that usually gets added later; so if you run your check
immediately after the HOLD is released, you know there is an APAR
problem you may need to resolve, but not what PTF resolves it.  And if
you run your check one day before the HOLD is issued, you may have a
potential problem, but just not know it.   As someone pointed out, this
is always an iterative process -- at any given point in time there are
always errors that haven't been discovered and errors that don't yet
have a resolving PTF.  If you stay roughly even with the pack, any
really serious/fatal bugs should be known and avoided, but there will
unavoidably always be some minor bugs present.   That's why you always
test after major maintenance just to be sure one of those minor bugs
isn't a critical issue in your environment.   It really makes little
difference whether you perform the search using your reasonably current
CSI PTF & HOLD data or whether IBM does it with their most current
data:  there is always the chance for undiscovered bugs that might be
more significant in your particular environment.
    Joel C Ewing

On 03/16/2018 08:32 AM, Jerry Callen wrote:
>>> Normally, the process of resolving all REQ/PREREQ/IFREQ requirements for
>>> given PTF(s) and collecting all missing items that prevent resolution, up 
>>> to 
>>> the point where APPLY CHECK suggests that actual APPLY could be successful
>>> could require several iterations.
>> I have used GROUPEXTEND since being introduced and can't recall ever being
>> successful in attaining full resolution with one pull.
>>
>> It always took several pulls (iterations) to attain a full resolution.
> It sounds to me as if the problem is that the SYSMODs identified by
> GROUPEXTEND can have their own REQs, which are (of course) not in the
> CSI until they get RECEIVEd.
>
> Is anyone aware of an IBM-provided REST API to the entire SYSMOD
> database? If you had that, you could presumably use that in
> conjunction with the SMP "GIMAPI" to construct the full graph.
>
> You could probably html-scrape content from Service Link, but that
> seems hopelessly primitive.
>
> I smell a nice science experiment brewing...
>
> -- Jerry
>
>

-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

Re: Using Pseudo Post

[Joseph Reichman]

Not really in the CS as I remember it R1 is the actual ECB while D2 B2 is the 
address of the ECB that’s not the way it’s presented  in the example 


> On Mar 20, 2018, at 10:13 AM, Charles Mills  wrote:
> 
> I was thinking about this last night. Exactly as Bin says!
> 
> It's not like when you use a CS for buffer control or to update a counter:
> you don't need a loop on the CS. You get one of two outcomes from the CS:
> 
> - The CC is 0, in which case the task is not waiting and you are all done
> here.
> - The CC is not 0, in which case the task is waiting and you need a real
> POST.
> 
> Isn't the example in Assembler Services Guide clear on the general flow of a
> fast POST?
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Binyamin Dissen
> Sent: Tuesday, March 20, 2018 2:38 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Using Pseudo Post
> 
> Logic issues.
> 
> If the wait bit is on you will need a real post. Your CS will set the post
> bit but not wake up the task.
> 
> If the CS fails because the post bit is on, it is perfectly fine and no need
> to retry.
> 
> On Mon, 19 Mar 2018 18:40:59 -0400 Joe Reichman 
> wrote:
> 
> :>I am using Quick Post Here is the code :>
> :> L R4,RECOV#ECB 
> :> L R8,RECOV#ECB Get ECB Address   
> :> L R4,0(,R4)get ecb   
> :> N R4,=X'3FFF'  Turn of wait post bit 
> :> ICM   R7,B'1000',=X'40'Insret Post bit   
> :> LAR11,5  try 5 times
> 
> :>CSLOOP   DS0H 
> :> CSR4,R7,0(R8)
> :> BZPOSTDONE   
> :> STIMER  WAIT,DINTVL=TWOSECS   WAIT A COUPLE  
> :> WTO   'ERROR POSTING...' 
> :> BCT   R11,CSLOOP 
> :>Sent from Mail for Windows 10
> :>
> :>From: Charles Mills
> :>Sent: Monday, March 19, 2018 6:36 PM
> :>To: IBM-MAIN@LISTSERV.UA.EDU
> :>Subject: Re: Using Pseudo Post
> :>
> :>Did you code ASCB= (correctly). You need that even if the ECB is in
> common.
> :>
> :>Charles
> :>
> :>
> :>-Original Message-
> :>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Joe Reichman
> :>Sent: Monday, March 19, 2018 3:25 PM
> :>To: IBM-MAIN@LISTSERV.UA.EDU
> :>Subject: Re: Using Pseudo Post
> :>
> :>The ECB is in Fixed CSA running under a different Address space for some
> reason even after posted the task is still not dispatched I know this
> because I have placed a WTO right after :> :>I am running under TESTAUTH and
> can observe the ECB  before with the 80 bit and the RB and after with 40 bit
> using TASID with the storage view function :>
> :>--
> :>For IBM-MAIN subscribe / signoff / archive access instructions, :>send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN :> :>
> :>--
> :>For IBM-MAIN subscribe / signoff / archive access instructions, :>send
> email to lists...@listserv.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...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: mainframe distribution

[Charles Mills]

> can we back to the main issue here: Mainframe distribution"?

Those who know don't say; those who say don't know.

The question comes up here from time to time and the answer is always the same.

Charles

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

Re: Using Pseudo Post

[Charles Mills]

I was thinking about this last night. Exactly as Bin says!

It's not like when you use a CS for buffer control or to update a counter:
you don't need a loop on the CS. You get one of two outcomes from the CS:

- The CC is 0, in which case the task is not waiting and you are all done
here.
- The CC is not 0, in which case the task is waiting and you need a real
POST.

Isn't the example in Assembler Services Guide clear on the general flow of a
fast POST?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Binyamin Dissen
Sent: Tuesday, March 20, 2018 2:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Using Pseudo Post

Logic issues.

If the wait bit is on you will need a real post. Your CS will set the post
bit but not wake up the task.

If the CS fails because the post bit is on, it is perfectly fine and no need
to retry.

On Mon, 19 Mar 2018 18:40:59 -0400 Joe Reichman 
wrote:

:>I am using Quick Post Here is the code :>
:> L R4,RECOV#ECB 
:> L R8,RECOV#ECB Get ECB Address   
:> L R4,0(,R4)get ecb   
:> N R4,=X'3FFF'  Turn of wait post bit 
:> ICM   R7,B'1000',=X'40'Insret Post bit   
:> LAR11,5  try 5 times

:>CSLOOP   DS0H 
:> CSR4,R7,0(R8)
:> BZPOSTDONE   
:> STIMER  WAIT,DINTVL=TWOSECS   WAIT A COUPLE  
:> WTO   'ERROR POSTING...' 
:> BCT   R11,CSLOOP 
:>Sent from Mail for Windows 10
:>
:>From: Charles Mills
:>Sent: Monday, March 19, 2018 6:36 PM
:>To: IBM-MAIN@LISTSERV.UA.EDU
:>Subject: Re: Using Pseudo Post
:>
:>Did you code ASCB= (correctly). You need that even if the ECB is in
common.
:>
:>Charles
:>
:>
:>-Original Message-
:>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Joe Reichman
:>Sent: Monday, March 19, 2018 3:25 PM
:>To: IBM-MAIN@LISTSERV.UA.EDU
:>Subject: Re: Using Pseudo Post
:>
:>The ECB is in Fixed CSA running under a different Address space for some
reason even after posted the task is still not dispatched I know this
because I have placed a WTO right after :> :>I am running under TESTAUTH and
can observe the ECB  before with the 80 bit and the RB and after with 40 bit
using TASID with the storage view function :>
:>--
:>For IBM-MAIN subscribe / signoff / archive access instructions, :>send
email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN :> :>
:>--
:>For IBM-MAIN subscribe / signoff / archive access instructions, :>send
email to lists...@listserv.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...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Can the CSI info alone produce a final list required for full resolution of researched PTFs?

[Tom Marchant]

On Fri, 16 Mar 2018 08:32:12 -0500, Jerry Callen wrote:

>>> Normally, the process of resolving all REQ/PREREQ/IFREQ requirements for
>>> given PTF(s) and collecting all missing items that prevent resolution, up 
>>> to 
>>> the point where APPLY CHECK suggests that actual APPLY could be successful
>>> could require several iterations.
>
>> I have used GROUPEXTEND since being introduced and can't recall ever being
>> successful in attaining full resolution with one pull.
>> 
>> It always took several pulls (iterations) to attain a full resolution.
>
>It sounds to me as if the problem is that the SYSMODs identified by
>GROUPEXTEND can have their own REQs, which are (of course) not in the
>CSI until they get RECEIVEd.
>
>Is anyone aware of an IBM-provided REST API to the entire SYSMOD
>database? If you had that, you could presumably use that in
>conjunction with the SMP "GIMAPI" to construct the full graph.

What's wrong with RECEIVE ORDER? AFAIK, it generates a file containing a 
list (bitmap) of all of the available PTFs on your system, which is used to 
package all of the maintenance that you need.

-- 
Tom Marchant

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

Re: Using Pseudo Post

[Binyamin Dissen]

Logic issues.

If the wait bit is on you will need a real post. Your CS will set the post bit
but not wake up the task.

If the CS fails because the post bit is on, it is perfectly fine and no need
to retry.

On Mon, 19 Mar 2018 18:40:59 -0400 Joe Reichman  wrote:

:>I am using Quick Post Here is the code
:>
:> L R4,RECOV#ECB 
:> L R8,RECOV#ECB Get ECB Address   
:> L R4,0(,R4)get ecb   
:> N R4,=X'3FFF'  Turn of wait post bit 
:> ICM   R7,B'1000',=X'40'Insret Post bit   
:> LAR11,5  try 5 times 
   
:>CSLOOP   DS0H 
:> CSR4,R7,0(R8)
:> BZPOSTDONE   
:> STIMER  WAIT,DINTVL=TWOSECS   WAIT A COUPLE  
:> WTO   'ERROR POSTING...' 
:> BCT   R11,CSLOOP 
:>Sent from Mail for Windows 10
:>
:>From: Charles Mills
:>Sent: Monday, March 19, 2018 6:36 PM
:>To: IBM-MAIN@LISTSERV.UA.EDU
:>Subject: Re: Using Pseudo Post
:>
:>Did you code ASCB= (correctly). You need that even if the ECB is in common.
:>
:>Charles
:>
:>
:>-Original Message-
:>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Joe Reichman
:>Sent: Monday, March 19, 2018 3:25 PM
:>To: IBM-MAIN@LISTSERV.UA.EDU
:>Subject: Re: Using Pseudo Post
:>
:>The ECB is in Fixed CSA running under a different Address space for some 
reason even after posted the task is still not dispatched I know this because I 
have placed a WTO right after
:> 
:>I am running under TESTAUTH and can observe the ECB  before with the 80 bit 
and the RB and after with 40 bit using TASID with the storage view function
:>
:>--
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
:>
:>
:>--
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to lists...@listserv.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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: mainframe distribution

[ITschak Mugzach]

Brend,

​Ten twins and none of them if Asia? Please recommend the city of Stuttgart
have a twin city in Israel ;-) I can recommend some, if needed...

And, Ladies & Gentlemen, can we back to the main issue here: Mainframe
distribution"?

ITschak


בתאריך 20 במרץ 2018 0:20,‏ "Bernd Oppolzer" 
כתב:

> Am 19.03.2018 um 17:07 schrieb Tony Harminc:
>
>> On 19 March 2018 at 11:45, Bernd Oppolzer 
>> wrote:
>>
>> Stuttgart and Lodz are partner towns (jumelage in French,
>>> don't know the English expression).
>>>
>> Often the expressions "twin towns" or "twin cities" are used, which is
>> exactly translatable with the French term. But the word is a little
>> awkward when there are multiple "twinnings". Wikipedia seems to think
>> that the common term is "sister cities", which makes sense in the case
>> of multiples. What term is used in German?
>>
>> Tony H.
>>
>>
> Partnerstadt - Stuttgart has ten "twins":
>
> Tschechien: Brno/Brünn seit 1989
> Wales: Cardiff (seit 1955)
> Ägypten: Kairo (seit 1979)
> Polen: Lodz (seit 1988)
> Tunesien: Menzel Bourguiba (seit 1971)
> Indien: Mumbai (Bombay) (seit 1968)
> Russland: Samara (seit 1992)
> Großbritanien: St. Helens (seit 1948)
> USA: St. Louis (seit 1960)
> Frankreich: Straßburg (seit 1962)
>
> I'm not living in Stuttgart, in fact;
> I'm living in Leinfelden-Echterdingen, which is about 12 to 15 km
> from Stuttgart (south).
>
> Leinfelden-Echterdingen has four "twins":
>
> Manosque (southern France)
> Poltawa (Ukraine)
> York (USA, Pennsylvania, IIRC)
> Voghera (Italy)
>
> I've been in Manosque very often, I have friends there :-)
> after all, it is a good region to spend the holidays
>
> Kind regards
>
> Bernd
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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