Re: We are what we are ...

[Ed Finnell]

 
In a message dated 6/30/2008 4:03:34 P.M. Central Daylight Time,  
[EMAIL PROTECTED] writes:

Sort of "pre-ordained" to be a geek  John ...


>>
RCA pocket protector and  Deitzen slide-rule come to mind... 







**Gas prices getting you down? Search AOL Autos for 
fuel-efficient used cars.  
(http://autos.aol.com/used?ncid=aolaut000507)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: David Caminer (1915-2008)

[Andy Wood]

On Mon, 30 Jun 2008 14:21:46 -0500, Patrick O'Keefe 
<[EMAIL PROTECTED]> wrote:

...
>
>Certainly no reflection on Mr. Camimer but that Seattle Times article
>would have been a bit better if it had not said:
>" ...developed two more generations of LEO, the last with transistors,
>rather than the noisy vacuum tubes used in the first two models. ..."

In the early 1970s I acquired several boards from a scrapped LEO III (the first 
and only transistorised LEO). I scavenged various components like transistors 
and diodes from them. From memory, those boards were better for vultures 
like myself than later generation boards, as the wires on the transistors were 
left quite long, making them easier to salvage.

Of course, I now know I should have kept the boards intact, they would 
probably now be worth a bit as historic relics.  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Another difference between platforms...

[Gary Green]

I enjoy cross-country motorcycle trips.  Unfortunately, once I started
working for a consulting outfit, that fell to the wayside.  :(  Perhaps at
my next job... (he says hopefully)


Gary Green
While the big event is over, there is still time for you to help me with my
efforts to assist those stricken with cancer!
Please support my efforts by visiting:
http://www.active.com/donate/tntsonj/tntsonjGGreen 
 
Thank you.

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Rick Fochtman
Sent: Monday, June 30, 2008 4:16 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Another difference between platforms...

---

>On all I concur...
>
>Their development platforms are just as bad.
>
>I remember a PC project I worked on somewhere around the tail end of the
90's, a pretty big one at that.  By the time project was complete, the
development environment and platform had changed under our feet.  I was so
pissed because we couldn't just leave the project on the older platform,
which caused us a few months delay.  I just shook my head wishing I had a
baseball bat so I can put it use on the head of someone at MS. WTH were
these folks thinking?
>
>Last year I was called in to solve a connectivity/IDMS/DB2 problem of a
home-grown VB application that connected with the mainframe DB platforms
using Shadow.  Turns out the ODBC driver was updated on a couple of
workstations and the app stopped working.  The only solution...?  Recompile
and rebind everything related to the app that ran on those workstations.
>
>I would like to say "don't get me started", but unfortunately, I 
>already am... :(
>
>Calm down, Green...  Calm down
>  
>

Pop a handful of Valium and start planning that mid-summer fishing
trip. Get you mind on something you enjoy. :-)

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the
archives at http://bama.ua.edu/archives/ibm-main.html

No virus found in this incoming message.
Checked by AVG. 
Version: 8.0.101 / Virus Database: 270.4.3/1526 - Release Date: 6/30/2008
8:43 AM

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: TN3270 *from* a host??

[Chris Mason]

Peter

You misunderstood. I wasn't talking about the "raw" option but your 
contention that "raw" wasn't supported. You were entirely correct.

Now you have explained and it looks just like what I described in my response 
to Natarajan as "echo" mode. So indeed such a protocol, efficient only when 
used on dedicated wire between the asynchronous ASCII device and the 
computer where the application resides, is *not* supported by the TSO 
TELNET command. However it is supported by the otelnetd server.

I learned all about this topic even before I started playing with UNIX systems 
by having to teach X.25 PAD and the 3708 protocol converter. There's no 
better way to drive the point home than by having students in an X.25 class 
enter set 2:0 .

Chris Mason

On Mon, 30 Jun 2008 08:33:11 +0200, Hunkeler Peter (KIUK 3) 
<[EMAIL PROTECTED]> wrote:

>>I was going to say "I fear that there is a risk that you may be
>>wrong again :-( and you're not taking me with you this time
>>:-)" - but see later.
>
>Sorry for not taking you with me. I probably leant out of the
>window too far this time; not my favourite subject, so I may
>well be choosing the wrong wording; I sure am not understanding
>all the nuts and bolts.
>
>
>Can you bear on last try?
>
>In TCP/IP based telnet, "raw mode" means that characters are send
>as they are typed. The application can respond to each and every
>key just when the user presses it.
>
>You cannot get into this mode when your (initial) session
>is a 3270based session. You always need to hit an action
>key in order to send data over the line. (I'd be happy to
>learn there is a way.) This is what I meant saying you
>can't get "raw mode" in TSO TELNET or TSO OMVS.
>
>--
>Peter Hunkeler
>Credit Suisse

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Utilization of Mainframe Software Licenses

[Tom Moulder]

Discounts have been an issue for years now.  It invariably leads to hard
feelings on both sides of the negotiating table.  Software companies feel
they have given up too much -- I've personally seen 90% discounts on MF
software license fees -- and customers feel like they are not getting as
good a deal as the other company down the street.  It is a lose/lose
situation.

Tom Moulder


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Ted MacNEIL
Sent: Monday, June 30, 2008 4:26 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Utilization of Mainframe Software Licenses

>The first thing that came to my mind was the term "Shelfware".

When Parallel SYSPLEX first came out, you got a discount on IBM software, if
you bought at least one coupling facility and one timer. This happened even
if you didn't hook them up.
Then, a couple of years later, you had to hook them up.
Then, later, you had to use them.
This was the ultimate in 'shelfware'.
If your shop was large enough the cost of the hardware was less than the
discount in software.

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: David Caminer (1915-2008)

[William Donzelli]

> When I went to the University of Waterloo, in the mid 1970's, I had a 
> professor who did his masters at MIT.
> They had a vacuum tube computer that had all its tubes mounted on both walls 
> of what was basically a 6-metre corridor.
> Somebody would have to go in everyday and run the erasor end of a pencil 
> across all the tubes. If the lights shook, the tube touched had to be 
> replaced or re-seated.

3033s had something along those lines as well. During installation,
the engineer would give each module a whack with a little hammer, and
look for flipped bits.

--
Will

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: David Caminer (1915-2008)

[Gerhard Postpischil]

Thompson, Steve wrote:

I don't remember what vacuum tube logic circuits looked like.  Are you
sure they were much noisier than the transisterized circuits that
replaced them?


I never saw the tubes in the earlier machines, except in 
pictures, but the last tube generation used any of a family of 
dual triodes: 12AU7, 12AW7, and 12AX7, also used back then in 
better radios and Hi-Fi equipment. Each pair was mounted in an 
open frame, approximately the size of a 200-300 page hardcover 
book, with discrete components (mostly resistors) aligned 
vertically. Additionally each module had two vertical shafts, 
one at each end, containing a cam that locked the module in place.


Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: David Caminer (1915-2008)

[Ted MacNEIL]

>If you have an old amp with tubes, try this - just very lightly tap the side 
>of the tube with a pencil, and hear what sounds like a Chinese gong being 
>struck.

When I went to the University of Waterloo, in the mid 1970's, I had a professor 
who did his masters at MIT.
They had a vacuum tube computer that had all its tubes mounted on both walls of 
what was basically a 6-metre corridor.
Somebody would have to go in everyday and run the erasor end of a pencil across 
all the tubes. If the lights shook, the tube touched had to be replaced or 
re-seated.

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: David Caminer (1915-2008)

[William Donzelli]

Last post of mine on this subject, hopefully...

> But the big difference is, lots of voltage = large electromagnetic
> field. Low voltage with low amperage = small electromagnetic field.
> Tubes use large voltage differences, solid state uses small differences.

It all boils down to noise margins. High voltage (tube) digital
circuits enjoy extremely wide noise margins, so most electrical crap
can be safely ignored.

There were lots of other issues with tube digital that made design
"fun", but that can wait...

--
Will

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: David Caminer (1915-2008)

[William Donzelli]

> Now you're making a connection back to the original article.  That
> high-pitched "whine" was from high frequency magnetic fields causing the
> internal ferrous parts of the tube to vibrate.  This would sometimes be
> at harmonic frequencies that would cause the external tube or even the
> mounting surface to vibrate, making the sound audible.

No, that is not correct.

The whine or hum sometimes heard in electronics can generally be
traced to cheap transformers (the laminations vibrate if they are not
tight) or the hetrodyne action of two RF signals fairly close to each
other.

The tubes do not make noise. If the elements of the tube did vibrate
so much that they could be heard with your ear, their movements would
cause any signal they are trying to deal with get completely swamped
out. If you have an old amp with tubes, try this - just very lightly
tap the side of the tube with a pencil, and hear what sounds like a
Chinese gong being struck.

Movement and vibration of the elements was a very serious design
issue. Officially the effect is called "microphonics", and great
lengths were taken to make sure it was minimized.

>  Nearly all of
> what we encountered tubes in as consumers were analog devices.  Now put
> those tubes in a computer, a digital device and start pushing square
> waves through them instead of nicely curved analog wave forms.  Magnetic
> fields that are basically going from full on to full off repeatedly.
> Small ferrous parts getting jerked back and forth all over the place.  I
> bet that "hummer" buzzed like a hive of angry bees.

The fields in tubes were basically electromagnetic. Magnetic fields
were generally kept to a very minimum. On a grid, for example, the
current is tiny - almost not there at all. With no current, there is
no magnetic field.

--
Will

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Utilization of Mainframe Software Licenses

[Ted MacNEIL]

>The first thing that came to my mind was the term "Shelfware".

When Parallel SYSPLEX first came out, you got a discount on IBM software, if 
you bought at least one coupling facility and one timer. This happened even if 
you didn't hook them up.
Then, a couple of years later, you had to hook them up.
Then, later, you had to use them.
This was the ultimate in 'shelfware'.
If your shop was large enough the cost of the hardware was less than the 
discount in software.

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: David Caminer (1915-2008)

[Craddock, Chris]

> --
> > I remember my first (and last) radio kit emitted a barely audible
> > high-pitched "whine" when turned on.  The only other detail I
remember
> --

[] my guitar amp is full of tubes and it is really really noisy,
but only when cranked up to 11 man! :-)

Regardless of all that hilarity, I think we can all agree that the man
was a true giant in our field. His passing should be noted.

CC

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: David Caminer (1915-2008)

[Bass, Walter W]

 
--
> I remember my first (and last) radio kit emitted a barely audible
> high-pitched "whine" when turned on.  The only other detail I remember
--

Now you're making a connection back to the original article.  That
high-pitched "whine" was from high frequency magnetic fields causing the
internal ferrous parts of the tube to vibrate.  This would sometimes be
at harmonic frequencies that would cause the external tube or even the
mounting surface to vibrate, making the sound audible.  Nearly all of
what we encountered tubes in as consumers were analog devices.  Now put
those tubes in a computer, a digital device and start pushing square
waves through them instead of nicely curved analog wave forms.  Magnetic
fields that are basically going from full on to full off repeatedly.
Small ferrous parts getting jerked back and forth all over the place.  I
bet that "hummer" buzzed like a hive of angry bees.

Bill Bass
Senior Applications Developer
United Health Care
Greenville, SC


This e-mail, including attachments, may include confidential and/or 
proprietary information, and may be used only by the person or entity to 
which it is addressed. If the reader of this e-mail is not the intended 
recipient or his or her authorized agent, the reader is hereby notified 
that any dissemination, distribution or copying of this e-mail is 
prohibited. If you have received this e-mail in error, please notify the 
sender by replying to this message and delete this e-mail immediately.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: David Caminer (1915-2008)

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Patrick O'Keefe
Sent: Monday, June 30, 2008 3:13 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: David Caminer (1915-2008)

On Mon, 30 Jun 2008 15:30:58 -0400, Thompson, Steve
<[EMAIL PROTECTED]> wrote:

...
>No, the writer is quite technically astute and meant that the vacuum 
>tube circuits with their chokes, coils, etc. were ELECTRICALLY noisy.
>...

You may be right.  You are definitely giving the author more credit than
I did.  I did briefly wonder if he might be talking about microphonics,
but decided that would have been a possible issue in an analog system
but would have been causght as a dead device by whatever error detection
was (hopefully) used.

I don't remember what vacuum tube logic circuits looked like.  Are you
sure they were much noisier than the transisterized circuits that
replaced them?


Well, given the Faday shielding that was needed between stages of
certain tube-type radios to prevent inductive coupling...

And then there are the formulae for gauss. If you take the B+
(200-500VDC) for the plate voltages (I seem to recall that logic only
used Triodes, and possibly dual Triodes), add to that the speed at which
you would want to change to grid voltage (from "open" to cut-off to give
1/0 or 0/1), and you will generate a very noisy square-wave. And
unshielded leads acted like acted like antennae. And then, you could
sometimes cross-couple circuits because of a bad choke/capacitor to
shield one stage from another using the same B+ feed... 

Man does this take me back a few years. I haven't used those formulae in
years and just realized I've all but forgotten all of them.

Now, going to transistors, one had to be very careful to avoid cross
coupling between layers (inductive and capacitive), or you would
generate noise into another circuit...

But the big difference is, lots of voltage = large electromagnetic
field. Low voltage with low amperage = small electromagnetic field.
Tubes use large voltage differences, solid state uses small differences.

Regards,
Steve Thompson

-- All opinions expressed by me are my own and may not necessarily
reflect those of my employer. --

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

We are what we are ...

[Shane Ginnane]

Quoting "Chase, John" :

> The only other detail I remember
> are the tubes it used:  One each 12SA7, 12SK7, 12SQ7, 50L6 and 35Z5.

Fancy still having that level of detail rattling around your head.
Sort of "pre-ordained" to be a geek  John ...

Shane ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SMS construct pgm name

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Jack Kelly
> Sent: Monday, June 30, 2008 3:34 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: SMS construct pgm name
> 
> Has anyone developed a methodology to determine if FTP is the program 
> creating SMS dsn?  Currently we have a fall thru test for pgm 
> = BPXPRECP 
> but I think that's the "exec()" program, not just FTP? Of 
> course we have 
> the various flavors of FTP, FTP port 21, sFTP (ported tools) 
> and TECTIA, 
> but I assume that shouldn't make a difference?
> TiA 
> 
> Jack Kelly

Whose stack? IBM or CA (I'd guess IBM). FTP client (GET) or FTP server
(PUT)? In my personal opinion, this is not really a good thing to test
for. I know you likely have a reason to know this. But I'd put the data
into a storage class / group based on something else, if possible. Why
should a given file created via ftp be in a different SC than the same
file, created by the same user, created by IEBGENER or any other batch
program? Or one created by IND$FILE (3270 file transfer)?

sftp from the ported tools only writes to UNIX files, so it is not a
consideration for SMS.

I never heard of TECTIA.

Not much help, I know.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SMS construct pgm name

[Darth Keller]

Jack - 

You can always add a code segment with a write statement to allow you to 
test.  Something like:

 IF (&DSN = 'your.test.data.set.name.here') THEN 
 DO  
   WRITE 'DCD0300 ' &DSN ' ' &PGM ' ' &DSORG ' ' &DATACLAS   
 END 

 


>Has anyone developed a methodology to determine if FTP is the program 
>creating SMS dsn?  Currently we have a fall thru test for pgm = BPXPRECP 
>but I think that's the "exec()" program, not just FTP? Of course we have 
>the various flavors of FTP, FTP port 21, sFTP (ported tools) and TECTIA, 
>but I assume that shouldn't make a difference?




**
This e-mail message and all attachments transmitted with it may contain legally 
privileged and/or confidential information intended solely for the use of the 
addressee(s). If the reader of this message is not the intended recipient, you 
are hereby notified that any reading, dissemination, distribution, copying, 
forwarding or other use of this message or its attachments is strictly 
prohibited. If you have received this message in error, please notify the 
sender immediately and delete this message and all copies and backups thereof.

Thank you.
**

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: David Caminer (1915-2008)

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Bass, Walter W
> 
> > --
> > Tubes can be VERY noisy, electrically. Even if they're virtually 
> > silent when you're standing there listening.
> > --
> 
> I was a young lad I would watch (and listen) most intently as 
> my father would frequently open up the back of our tube TV to 
> effect repairs.  I am quite certain that I recall hearing a 
> steady background hum of mumbled curses emanating from the 
> tubes.  If you scale that up by the far greater number of 
> tubes which a ca. 1950's computer must have contained vs. the 
> 1950's TV, I'm quite certain the noise level might have been 
> considered objectionable to some.

I remember my first (and last) radio kit emitted a barely audible
high-pitched "whine" when turned on.  The only other detail I remember
are the tubes it used:  One each 12SA7, 12SK7, 12SQ7, 50L6 and 35Z5.

-jc-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

SMS construct pgm name

[Jack Kelly]

Has anyone developed a methodology to determine if FTP is the program 
creating SMS dsn?  Currently we have a fall thru test for pgm = BPXPRECP 
but I think that's the "exec()" program, not just FTP? Of course we have 
the various flavors of FTP, FTP port 21, sFTP (ported tools) and TECTIA, 
but I assume that shouldn't make a difference?
TiA 

Jack Kelly
202-502-2390 (Office)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: David Caminer (1915-2008)

[Bass, Walter W]

> --
> Tubes can be VERY noisy, electrically. Even if they're 
> virtually silent 
> when you're standing there listening.
> --

I was a young lad I would watch (and listen) most intently as my father
would frequently open up the back of our tube TV to effect repairs.  I
am quite certain that I recall hearing a steady background hum of
mumbled curses emanating from the tubes.  If you scale that up by the
far greater number of tubes which a ca. 1950's computer must have
contained vs. the 1950's TV, I'm quite certain the noise level might
have been considered objectionable to some.

Bill Bass
Senior Applications Developer
United Health Care
Greenville, SC


This e-mail, including attachments, may include confidential and/or 
proprietary information, and may be used only by the person or entity to 
which it is addressed. If the reader of this e-mail is not the intended 
recipient or his or her authorized agent, the reader is hereby notified 
that any dissemination, distribution or copying of this e-mail is 
prohibited. If you have received this e-mail in error, please notify the 
sender by replying to this message and delete this e-mail immediately.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Issue with DB2 Tools (CA) and z/OS V1.9

[Lizette Koehler]

Thanks Sam.

Lizette


>
>Hi Lizette,
>
>You can upgrade to r11.5 SP1 to address this.  
>We are running the CA DB2 Tools Suite with ALLOWUSERKEYCSA(NO) without
>any problems after making that upgrade.
>
>I don't believe they have announced a General Availability date for
>CA/Unicenter DB2 11.5 SP2 yet so SP1 is the most current Service Pack.
>
>My notes also have a list of PTFs 
>
>UDTF194  PDT  11.5.1 OS CONFIRMED
>USAF082  PSA  11.5.1 OS CONFIRMED
>UTTF097  PTT  11.5.1 OS CONFIRMED
>UCID126  CIDB  11.5.1 OS CONFIRMED
>UXMF038  PXM  11.5.1 OS CONFIRMED
>UTGC040  TGR  11.5.1 OS CONFIRMED 
>
>I would suggest you contact CA support and plan on installing SP1. 
>Just a heads up.
>
>When I IPL'd our z/OS V1.9 system the DB2 Tools (PTXMAIN STC) died with
>a B78  REASON CODE=005C 
>
>I added VSM ALLOWCSAUSERKEY(YES) to DIAG00 and it worked.
>
>I guess this might have been another CA product bit by the
>ALLOWCSAUSERKEY issue.
>
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: David Caminer (1915-2008)

[Rick Fochtman]

-
No, the writer is quite technically astute and meant that the vacuum 
tube circuits with their chokes, coils, etc. were ELECTRICALLY noisy. 
But knowing that their audience wouldn't have a clue (as the editor 
didn't either) and so cut all that out so that it just said that the 
vacuum tubes were noisy (since the editor's only exposure to vacuum 
tubes are at their bank's drive-in).



I sioncerely doubt if that editor has any comprehension of a vacuum 
tube. He's probably young enough to be a son to many of us.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: David Caminer (1915-2008)

[Rick Fochtman]

--

Noisy vacuum tubes?  Vacuum tubes had a number of drawbacks 
but I don't recall their being particularly noisy.   I can only assume
the original models either had a bunch of clattering relays, or 
noisy cooling systems.
 


--
Tubes can be VERY noisy, electrically. Even if they're virtually silent 
when you're standing there listening.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Another difference between platforms...

[Rick Fochtman]

---


On all I concur...

Their development platforms are just as bad.

I remember a PC project I worked on somewhere around the tail end of the 90's, 
a pretty big one at that.  By the time project was complete, the development 
environment and platform had changed under our feet.  I was so pissed because 
we couldn't just leave the project on the older platform, which caused us a few 
months delay.  I just shook my head wishing I had a baseball bat so I can put 
it use on the head of someone at MS. WTH were these folks thinking?

Last year I was called in to solve a connectivity/IDMS/DB2 problem of a 
home-grown VB application that connected with the mainframe DB platforms using 
Shadow.  Turns out the ODBC driver was updated on a couple of workstations and 
the app stopped working.  The only solution...?  Recompile and rebind 
everything related to the app that ran on those workstations.

I would like to say "don't get me started", but unfortunately, I already am... 
:(

Calm down, Green...  Calm down
 



Pop a handful of Valium and start planning that mid-summer fishing 
trip. Get you mind on something you enjoy. :-)


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Utilization of Mainframe Software Licenses

[Rick Fochtman]

---
The first thing that came to my mind was the term "Shelfware". A valid 
question to ask is whether software that you are paying license fees to 
use is actually being used -- perhaps a rather unique view of 
utilization. Further, you might ask how large the user community is 
compared to the cost of the license.


You might also ask the users if they're willing to shoulder part of the 
cost. I'll bet that will get nothing but a Bronx cheer; and very little 
objection when the product is dropped.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: David Caminer (1915-2008)

[Patrick O'Keefe]

On Mon, 30 Jun 2008 15:30:58 -0400, Thompson, Steve 
<[EMAIL PROTECTED]> wrote:

...
>No, the writer is quite technically astute and meant that the vacuum
>tube circuits with their chokes, coils, etc. were ELECTRICALLY noisy.
>...

You may be right.  You are definitely giving the author more credit
than I did.  I did briefly wonder if he might be talking about 
microphonics, but decided that would have been a possible issue
in an analog system but would have been causght as a dead 
device by whatever error detection was (hopefully) used.

I don't remember what vacuum tube logic circuits looked like.  Are 
you sure they were much noisier than the transisterized circuits
that replaced them?

Pat O'Keefe   

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: USS file sharing in z/OS

[Rick Fochtman]

---
And, of course, your company is preparing for the departure of the older 
heads by training the younger heads, to guarantee some continuity of 
maintaining and enhancing the applications that keep the company running 
successfully.

---
Right. Did you notice that pig fly by outside your window? Or the pink 
elephant that landed on your roof last night?


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Issue with DB2 Tools (CA) and z/OS V1.9

[Knutson, Sam]

Hi Lizette,

You can upgrade to r11.5 SP1 to address this.  
We are running the CA DB2 Tools Suite with ALLOWUSERKEYCSA(NO) without
any problems after making that upgrade.

I don't believe they have announced a General Availability date for
CA/Unicenter DB2 11.5 SP2 yet so SP1 is the most current Service Pack.

My notes also have a list of PTFs 

UDTF194  PDT  11.5.1 OS CONFIRMED
USAF082  PSA  11.5.1 OS CONFIRMED
UTTF097  PTT  11.5.1 OS CONFIRMED
UCID126  CIDB  11.5.1 OS CONFIRMED
UXMF038  PXM  11.5.1 OS CONFIRMED
UTGC040  TGR  11.5.1 OS CONFIRMED 

I would suggest you contact CA support and plan on installing SP1. 

Best Regards, 

Sam Knutson, GEICO 
System z Performance and Availability Management 
mailto:[EMAIL PROTECTED] 
(office)  301.986.3574 

"Think big, act bold, start simple, grow fast..."



-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Lizette Koehler
Sent: Monday, June 30, 2008 2:56 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Issue with DB2 Tools (CA) and z/OS V1.9

Just a heads up.

When I IPL'd our z/OS V1.9 system the DB2 Tools (PTXMAIN STC) died with
a B78  REASON CODE=005C 

I added VSM ALLOWCSAUSERKEY(YES) to DIAG00 and it worked.

I guess this might have been another CA product bit by the
ALLOWCSAUSERKEY issue.

Lizette


This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: David Caminer (1915-2008)

[William Donzelli]

> No, the writer is quite technically astute and meant that the vacuum
> tube circuits with their chokes, coils, etc. were ELECTRICALLY noisy.
> But knowing that their audience wouldn't have a clue (as the editor
> didn't either) and so cut all that out so that it just said that the
> vacuum tubes were noisy (since the editor's only exposure to vacuum
> tubes are at their bank's drive-in).
> 

Noticing the sarcasm, but...

Tubes used in computer applications can indeed be noisy, but that is
not the issue. The noise can be tolerated quite easily in those high
voltage digital circuits. In fact, most computer tubes of the 1940s
and 50s were more or less standard radio types, maybe souped up a
little in some areas, but were tested using less stringent noise
tests. Likewise, computer tubes often were tested with less stringent
tests concerning balance of sections and hum. These qualities, like
noise,  just did not matter in a mainframe logic module.

Noise was more of an issue with the early semiconductors. They were
really rather poor performers, especially the British types, so noise
started to become a big issue. The low voltage everything operated at
in the transistor machines meant that external and internal
interference could result in garbage on the signal lines that could
get uncomfortably close to logic thresholds - flipped bits.

The article basically gets it wrong.

--
Will, wanting a 709

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: David Caminer (1915-2008)

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Patrick O'Keefe
Sent: Monday, June 30, 2008 2:22 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: David Caminer (1915-2008)

On Sun, 29 Jun 2008 19:43:08 +0200, Thomas Berg <[EMAIL PROTECTED]>
wrote:

>...
>http://seattletimes.nwsource.com/html/localnews/2008023617_camin
erobit29.html)
>...

Certainly no reflection on Mr. Camimer but that Seattle Times article
would have been a bit better if it had not said:  
" ...developed two more generations of LEO, the last with transistors,
rather than the noisy vacuum tubes used in the first two models. ..."

Noisy vacuum tubes?  Vacuum tubes had a number of drawbacks 
but I don't recall their being particularly noisy.   I can only assume
the original models either had a bunch of clattering relays, or noisy
cooling systems.


No, the writer is quite technically astute and meant that the vacuum
tube circuits with their chokes, coils, etc. were ELECTRICALLY noisy.
But knowing that their audience wouldn't have a clue (as the editor
didn't either) and so cut all that out so that it just said that the
vacuum tubes were noisy (since the editor's only exposure to vacuum
tubes are at their bank's drive-in).


Regards,
Steve.T

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: David Caminer (1915-2008)

[Patrick O'Keefe]

On Sun, 29 Jun 2008 19:43:08 +0200, Thomas Berg 
<[EMAIL PROTECTED]> wrote:

>...
>http://seattletimes.nwsource.com/html/localnews/2008023617_camin
erobit29.html)
>...

Certainly no reflection on Mr. Camimer but that Seattle Times article 
would have been a bit better if it had not said:  
" ...developed two more generations of LEO, the last with transistors, 
rather than the noisy vacuum tubes used in the first two models. ..."

Noisy vacuum tubes?  Vacuum tubes had a number of drawbacks 
but I don't recall their being particularly noisy.   I can only assume
the original models either had a bunch of clattering relays, or 
noisy cooling systems.

Pat O'Keefe 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Issue with DB2 Tools (CA) and z/OS V1.9

[Lizette Koehler]

Just a heads up.

When I IPL'd our z/OS V1.9 system the DB2 Tools (PTXMAIN STC) died with a B78  
REASON CODE=005C 

I added VSM ALLOWCSAUSERKEY(YES) to DIAG00 and it worked.

I guess this might have been another CA product bit by the ALLOWCSAUSERKEY 
issue.

Lizette

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Another difference between platforms...

[Gary Green]

On all I concur...

Their development platforms are just as bad.

I remember a PC project I worked on somewhere around the tail end of the 90's, 
a pretty big one at that.  By the time project was complete, the development 
environment and platform had changed under our feet.  I was so pissed because 
we couldn't just leave the project on the older platform, which caused us a few 
months delay.  I just shook my head wishing I had a baseball bat so I can put 
it use on the head of someone at MS. WTH were these folks thinking?

Last year I was called in to solve a connectivity/IDMS/DB2 problem of a 
home-grown VB application that connected with the mainframe DB platforms using 
Shadow.  Turns out the ODBC driver was updated on a couple of workstations and 
the app stopped working.  The only solution...?  Recompile and rebind 
everything related to the app that ran on those workstations.

I would like to say "don't get me started", but unfortunately, I already am... 
:(

Calm down, Green...  Calm down



 On Mon Jun 30 13:00 , 'McKown, John' <[EMAIL PROTECTED]> sent:

>> -Original Message-
>> From: IBM Mainframe Discussion List 
>> [EMAIL PROTECTED]','','','')">[EMAIL PROTECTED] On Behalf Of Gary Green
>> Sent: Monday, June 30, 2008 12:36 PM
>> To: IBM-MAIN@BAMA.UA.EDU
>> Subject: Another difference between platforms...
>> 
>> Back in the 80's we mainframe(rs) went from 24 bit to 31 bit, 
>> then towards the end of the millennium, we started migrating 
>> to 64 bit with the introduction of z/OS.  During all this 
>> time I do not recall any of the applications we ran on the 
>> older platforms ever "going dark" because of the change.  We 
>> all have a ton of stuff in our shop that was written decades 
>> ago and is still humming along just fine thank you.  Then why 
>> is it every time Mickeysoft changes their platform, 
>> everything we were using must change or be left behind?
>> 
>> http://www.computerworld.com/action/article.do\?command=viewArt
>> icleBasic&articleId=9103238&source=NLT_ES&nlid=42
>> 
>> Gary Green
>
>Enforced obsolescense! If the old apps continued to run on the new OS,
>how would MS force people to upgrade to the new application software?
>There is a lot of "chatter" than MS does this deliberately to force
>people to buy new versions of MS Office when they get a new OS, which is
>usually forced when they get new hardware. PROFIT!
>
>Personally, I think it is also because Windows is designed "ad hoc" with
>no real stragetic planning. I've also heard that every MS programmer
>things that they can do it better and so the API changes "as needed"
>with no regard to backwards compatability.
>
>--
>John McKown
>Senior Systems Programmer
>HealthMarkets
>Keeping the Promise of Affordable Coverage
>Administrative Services Group
>Information Technology
>
>The information contained in this e-mail message may be privileged
>and/or confidential.  It is for intended addressee(s) only.  If you are
>not the intended recipient, you are hereby notified that any disclosure,
>reproduction, distribution or other use of this communication is
>strictly prohibited and could, in certain circumstances, be a criminal
>offense.  If you have received this e-mail in error, please notify the
>sender by reply and delete this message without copying or disclosing
>it.  
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
>Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: DFDSS Question - DSCHA

[willie bunter]

I took your advice, however the datasets were not backed up from good voumes.  

--- On Fri, 6/27/08, Pinnacle <[EMAIL PROTECTED]> wrote:

From: Pinnacle <[EMAIL PROTECTED]>
Subject: Re: DFDSS Question - DSCHA
To: IBM-MAIN@BAMA.UA.EDU
Date: Friday, June 27, 2008, 12:17 PM

- Original Message - 
From: "willie bunter" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
Sent: Friday, June 27, 2008 1:21 PM
Subject: DFDSS Question - DSCHA


> Hallo All,
>
> I am executing an incremental backup of various volumes. I am using the 
> DSCHA parm. However, my problem is that I am receiving the following 
> messages which prevents them from being backed up:
>
> ADR322E SYSJPT.SPFLOG1.LIST WAS NOT SELECTED DUE TO DUPLICATE NAME
> ADR727E DATA SET SYSJ1.DDIR IN CATALOG SYS1.ICFCAT.SYSQND WAS NOT 
> PROCESSED BECAUSE IT NOT CATALOGED IN THE STANDARD ORDER OF SEARCH
>
> Is there a way of forcing DFDSS to backup the dsns regardless? Below are 
> my control cards:
> //DASD1 DD UNIT=SYSALLDA,VOL=SER=PTPRS1,DISP=SHR
> //DASD2 DD UNIT=SYSALLDA,VOL=SER=PTPRS2,DISP=SHR
> //DASD3 DD UNIT=SYSALLDA,VOL=SER=PTTRS1,DISP=SHR
> //DASD4 DD UNIT=SYSALLDA,VOL=SER=PTPMC1,DISP=SHR
> //DASD5 DD UNIT=SYSALLDA,VOL=SER=PTPPP1,DISP=SHR
> //DASD6 DD UNIT=SYSALLDA,VOL=SER=PTPPP2,DISP=SHR
> //DASD7 DD UNIT=SYSALLDA,VOL=SER=PTTPP1,DISP=SHR
> //DASD8 DD UNIT=SYSALLDA,VOL=SER=PTTMC1,DISP=SHR
> //TAPE DD DSN=SYS2.PTPR.DFDSS.INCRMNTL,DISP=(,CATLG,KEEP),
> // UNIT=3490,VOL=(,,,35),LABEL=RETPD=1
> //SYSIN DD *
> DUMP DATASET(INCLUDE(**) -
> EXCLUDE(SYS1.ICFCAT.** -
> SYS1.VVDS.** -
> SYS1.VTOCIX.**) -
> BY((DSCHA,EQ,YES))) -
> LOGINDDNAME(DASD1,DASD2,DASD3,DASD4,DASD5,DASD6,DASD7,DASD8) -
> OUTDD(TAPE) OPT(4) ALLDATA(*) ALLEXCP -
> SPHERE -
> TOL(ENQF)
>

Willie,

Just add the bad datasets to your EXCLUDE list.

Regards,
Tom Conley 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


  
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: DFDSS Question - DSCHA

[willie bunter]

I took 

--- On Fri, 6/27/08, Pinnacle <[EMAIL PROTECTED]> wrote:

From: Pinnacle <[EMAIL PROTECTED]>
Subject: Re: DFDSS Question - DSCHA
To: IBM-MAIN@BAMA.UA.EDU
Date: Friday, June 27, 2008, 12:17 PM

- Original Message - 
From: "willie bunter" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
Sent: Friday, June 27, 2008 1:21 PM
Subject: DFDSS Question - DSCHA


> Hallo All,
>
> I am executing an incremental backup of various volumes. I am using the 
> DSCHA parm. However, my problem is that I am receiving the following 
> messages which prevents them from being backed up:
>
> ADR322E SYSJPT.SPFLOG1.LIST WAS NOT SELECTED DUE TO DUPLICATE NAME
> ADR727E DATA SET SYSJ1.DDIR IN CATALOG SYS1.ICFCAT.SYSQND WAS NOT 
> PROCESSED BECAUSE IT NOT CATALOGED IN THE STANDARD ORDER OF SEARCH
>
> Is there a way of forcing DFDSS to backup the dsns regardless? Below are 
> my control cards:
> //DASD1 DD UNIT=SYSALLDA,VOL=SER=PTPRS1,DISP=SHR
> //DASD2 DD UNIT=SYSALLDA,VOL=SER=PTPRS2,DISP=SHR
> //DASD3 DD UNIT=SYSALLDA,VOL=SER=PTTRS1,DISP=SHR
> //DASD4 DD UNIT=SYSALLDA,VOL=SER=PTPMC1,DISP=SHR
> //DASD5 DD UNIT=SYSALLDA,VOL=SER=PTPPP1,DISP=SHR
> //DASD6 DD UNIT=SYSALLDA,VOL=SER=PTPPP2,DISP=SHR
> //DASD7 DD UNIT=SYSALLDA,VOL=SER=PTTPP1,DISP=SHR
> //DASD8 DD UNIT=SYSALLDA,VOL=SER=PTTMC1,DISP=SHR
> //TAPE DD DSN=SYS2.PTPR.DFDSS.INCRMNTL,DISP=(,CATLG,KEEP),
> // UNIT=3490,VOL=(,,,35),LABEL=RETPD=1
> //SYSIN DD *
> DUMP DATASET(INCLUDE(**) -
> EXCLUDE(SYS1.ICFCAT.** -
> SYS1.VVDS.** -
> SYS1.VTOCIX.**) -
> BY((DSCHA,EQ,YES))) -
> LOGINDDNAME(DASD1,DASD2,DASD3,DASD4,DASD5,DASD6,DASD7,DASD8) -
> OUTDD(TAPE) OPT(4) ALLDATA(*) ALLEXCP -
> SPHERE -
> TOL(ENQF)
>

Willie,

Just add the bad datasets to your EXCLUDE list.

Regards,
Tom Conley 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
  

Re: Utilization of Mainframe Software Licenses

[Tom Moulder]

The first thing that came to my mind was the term "Shelfware".  A valid
question to ask is whether software that you are paying license fees to use
is actually being used -- perhaps a rather unique view of utilization.
Further, you might ask how large the user community is compared to the cost
of the license.

Tom Moulder

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Jacky Bright
Sent: Friday, June 27, 2008 9:23 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Utilization of Mainframe Software Licenses

Can anyone help me in understanding the rerm Utilization of Mainframe
Software Licensing ? Does it mean taking care of licensing cost as per the
MIPS / MSU or it involves something more than that...?


JAcky

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: DFDSS Question - DSCHA

[willie bunter]

I took your 

--- On Fri, 6/27/08, Pinnacle <[EMAIL PROTECTED]> wrote:

From: Pinnacle <[EMAIL PROTECTED]>
Subject: Re: DFDSS Question - DSCHA
To: IBM-MAIN@BAMA.UA.EDU
Date: Friday, June 27, 2008, 12:17 PM

- Original Message - 
From: "willie bunter" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
Sent: Friday, June 27, 2008 1:21 PM
Subject: DFDSS Question - DSCHA


> Hallo All,
>
> I am executing an incremental backup of various volumes. I am using the 
> DSCHA parm. However, my problem is that I am receiving the following 
> messages which prevents them from being backed up:
>
> ADR322E SYSJPT.SPFLOG1.LIST WAS NOT SELECTED DUE TO DUPLICATE NAME
> ADR727E DATA SET SYSJ1.DDIR IN CATALOG SYS1.ICFCAT.SYSQND WAS NOT 
> PROCESSED BECAUSE IT NOT CATALOGED IN THE STANDARD ORDER OF SEARCH
>
> Is there a way of forcing DFDSS to backup the dsns regardless? Below are 
> my control cards:
> //DASD1 DD UNIT=SYSALLDA,VOL=SER=PTPRS1,DISP=SHR
> //DASD2 DD UNIT=SYSALLDA,VOL=SER=PTPRS2,DISP=SHR
> //DASD3 DD UNIT=SYSALLDA,VOL=SER=PTTRS1,DISP=SHR
> //DASD4 DD UNIT=SYSALLDA,VOL=SER=PTPMC1,DISP=SHR
> //DASD5 DD UNIT=SYSALLDA,VOL=SER=PTPPP1,DISP=SHR
> //DASD6 DD UNIT=SYSALLDA,VOL=SER=PTPPP2,DISP=SHR
> //DASD7 DD UNIT=SYSALLDA,VOL=SER=PTTPP1,DISP=SHR
> //DASD8 DD UNIT=SYSALLDA,VOL=SER=PTTMC1,DISP=SHR
> //TAPE DD DSN=SYS2.PTPR.DFDSS.INCRMNTL,DISP=(,CATLG,KEEP),
> // UNIT=3490,VOL=(,,,35),LABEL=RETPD=1
> //SYSIN DD *
> DUMP DATASET(INCLUDE(**) -
> EXCLUDE(SYS1.ICFCAT.** -
> SYS1.VVDS.** -
> SYS1.VTOCIX.**) -
> BY((DSCHA,EQ,YES))) -
> LOGINDDNAME(DASD1,DASD2,DASD3,DASD4,DASD5,DASD6,DASD7,DASD8) -
> OUTDD(TAPE) OPT(4) ALLDATA(*) ALLEXCP -
> SPHERE -
> TOL(ENQF)
>

Willie,

Just add the bad datasets to your EXCLUDE list.

Regards,
Tom Conley 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
  

Re: USS file sharing in z/OS

[Steve Comstock]

Andrew Metcalfe wrote:

[snip]

As none of us are getting any younger, 
I am trying to reduce complexity rather than introduce 
some bespoke processing that will trip up our succesors!




And, of course, your company is preparing for the departure
of the older heads by training the younger heads, to guarantee
some continuity of maintaining and enhancing the applications
that keep the company running successfully.

Right?



Thanks

Andrew



Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

  z/OS Application development made easier
* Our classes include
   + How things work
   + Programming examples with realistic applications
   + Starter / skeleton code
   + Complete working programs
   + Useful utilities and subroutines
   + Tips and techniques

==> Check out the Trainer's Friend Store to purchase z/OS  <==
==> application developer toolkits. Sample code in four<==
==> programming languages, JCL to Assemble or compile, <==
==> bind and test. <==
==>   http://www.trainersfriend.com/TTFStore/index.html<==

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Another difference between platforms...

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Gary Green
> Sent: Monday, June 30, 2008 12:36 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Another difference between platforms...
> 
> Back in the 80's we mainframe(rs) went from 24 bit to 31 bit, 
> then towards the end of the millennium, we started migrating 
> to 64 bit with the introduction of z/OS.  During all this 
> time I do not recall any of the applications we ran on the 
> older platforms ever "going dark" because of the change.  We 
> all have a ton of stuff in our shop that was written decades 
> ago and is still humming along just fine thank you.  Then why 
> is it every time Mickeysoft changes their platform, 
> everything we were using must change or be left behind?
> 
> http://www.computerworld.com/action/article.do?command=viewArt
> icleBasic&articleId=9103238&source=NLT_ES&nlid=42
> 
> Gary Green

Enforced obsolescense! If the old apps continued to run on the new OS,
how would MS force people to upgrade to the new application software?
There is a lot of "chatter" than MS does this deliberately to force
people to buy new versions of MS Office when they get a new OS, which is
usually forced when they get new hardware. PROFIT!

Personally, I think it is also because Windows is designed "ad hoc" with
no real stragetic planning. I've also heard that every MS programmer
things that they can do it better and so the API changes "as needed"
with no regard to backwards compatability.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: USS file sharing in z/OS

[Mark Zelden]

On Mon, 30 Jun 2008 12:15:00 -0500, Andrew Metcalfe
<[EMAIL PROTECTED]> wrote:

>.. but I guess that all systems in the subset have to be converted to have
>the new file systems e.g. sysplex root and version? 

Not true.   


>and the sysplex root has
>to be AUTOMOVE. 

Yes, for the participating systems.

>Whilst this may work technically, I feel that I might be
>buying into a whole stack of trouble!
>

Not if you implement it properly. 

>This will be difficult to implement given our standard build where we install
>once and ship many standard z/OS systems based on it. As none of us are
>getting any younger, I am trying to reduce complexity rather than introduce
>some bespoke processing that will trip up our succesors!
>

I do the same thing.   I even share the same physical sysres set between
sysplexes that have shared file systems and ones that don't (including 
some monplexes).   Although I don't have any sysplexes that only do 
partial sharing... but I may be doing that in the near future - at least
temporarily in order to satisfy a sharing requirement.

Have you read the doc?
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/BPXZB271/8.0?SHELF=E0Z2IN71&DT=20070122154602


Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Another difference between platforms...

[Gary Green]

Back in the 80's we mainframe(rs) went from 24 bit to 31 bit, then towards the 
end of the millennium, we started migrating to 64 bit with the introduction of 
z/OS.  During all this time I do not recall any of the applications we ran on 
the older platforms ever "going dark" because of the change.  We all have a ton 
of stuff in our shop that was written decades ago and is still humming along 
just fine thank you.  Then why is it every time Mickeysoft changes their 
platform, everything we were using must change or be left behind?

http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9103238&source=NLT_ES&nlid=42

Gary Green
While the big event is over, there is still time for you to help me with my 
efforts to assist those stricken with cancer!
Please support my efforts by visiting:
http://www.active.com/donate/tntsonj/tntsonjGGreen 
 
Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL SET command and instream SYSIn

[Bass, Walter W]

> 
> I agree that SET variables are very useful. But I think that 
> they could
> be more useful if they were more like UNIX environment variables -
> accessible to running programs. Perhaps via the ASASYMBM 
> interface. The
> 100 char limit on PARM, limits how much data you can pass to a program
> using it.
> 
> Another weird idea just occurred to me (though I may have 
> read it here).
> A subsystem, written by IBM, which "emulates" a sequential file. But
> what is read are the subsystem parameters on the JCL. Each 
> subparameter
> would be a separate record when read by the program. This 
> could be used
> to replace small SYSIN-like data with data which includes symbol
> substitution.
> 
> Eg:
> 
> //DEL EXEC PGM=IDCAMS
> //SYSPRINT DD SYSOUT=*
> //SYSIN DD SUBSYS=(READ,
> // ' DEL &DSN',
> // ' SET MAXCC=0'),
> // DCB=(RECFM=FB,LRECL=80,BLKSISE=80)
> 
> --
> John McKown
> Senior Systems Programmer


Also available on the CBT updates as file 779 is a program called
SYMBSUB which reads an 80 column file, does symbol substitutions using
values pulled from jobs own JESJCL and writes the file back out.  Using
the example from above, the equivalent function would be coded as
follows:

// SET &DSN=SOME.DSN.NAME
//DOSUBS   EXEC PGM=SYMBSUB
//CNTL001I DD *
 DEL &DSN
 SET MAXCC=0
//CNTL001O DD DSN=&&TMPSYSIN,DISP=(NEW,PASS),
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=0),
// UNIT=SYSDA,SPACE=(TRK,1)
//SYSOUT   DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//DEL  EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSINDD DSN=&&TMPSYSIN,DISP=OLD

With this there is no need to worry about limitations of parm lengths or
multiple job steps for multiple lines of data.  The program will also
handle more than one input and output file in a single step.  Just
supply matching CNTLxxxI and CNTLxxxO DD names and it will process them
all.

HTH,
Bill Bass
Senior Applications Developer
United Health Care
Greenville, SC



This e-mail, including attachments, may include confidential and/or 
proprietary information, and may be used only by the person or entity to 
which it is addressed. If the reader of this e-mail is not the intended 
recipient or his or her authorized agent, the reader is hereby notified 
that any dissemination, distribution or copying of this e-mail is 
prohibited. If you have received this e-mail in error, please notify the 
sender by replying to this message and delete this e-mail immediately.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: USS file sharing in z/OS

[Andrew Metcalfe]

. but I guess that all systems in the subset have to be converted to have 
the new file systems e.g. sysplex root and version? and the sysplex root has 
to be AUTOMOVE. Whilst this may work technically, I feel that I might be 
buying into a whole stack of trouble!

This will be difficult to implement given our standard build where we install 
once and ship many standard z/OS systems based on it. As none of us are 
getting any younger, I am trying to reduce complexity rather than introduce 
some bespoke processing that will trip up our succesors!

Thanks

Andrew

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FTP QUESTION - Put Command

[Mark Pace]

I think he was referring to the output from the command you issued.

On Mon, Jun 30, 2008 at 12:15 PM, John Dawes <[EMAIL PROTECTED]> wrote:

> Here it is:
> ftp> PUT
> Local file D:\Documents and Settings\SYSEN1\My Documents\NTP FTP\FTPTEST
>
>
> --- On Tue, 1/7/08, John P Kalinich <[EMAIL PROTECTED]> wrote:
>
> From: John P Kalinich <[EMAIL PROTECTED]>
> Subject: Re: FTP QUESTION - Put Command
> To: IBM-MAIN@BAMA.UA.EDU
> Received: Tuesday, 1 July, 2008, 2:08 AM
>
> John Dawes fo the IBM Mainframe Discussion List 
> wrote on 06/30/2008 11:06:50 AM:
>
> > Good Day,
> >
> > I am attempting to FTP a file to a sequential dataset which is
> > preallocated  on the MAINFRAME.
> >
> > When I issued the command :put jclbkup 'my.dsn.mainframe' .  The
> > jclbkup is the name of the file which is on my D drive.  The command
> > is accepted but I don't see any records being FTP'd.  I verify the
>
> > dsn on the MAINFRAME and it is empty.  Can anybody please point out my
> error?
>
> Can you post the FTP messages?
>
> Regards,
> John K
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
>
>   Get the name you always wanted with the new y7mail email address.
> www.yahoo7.com.au/mail
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
>


-- 
Mark Pace
Mainline Information Systems

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL SET command and instream SYSIN

[Itschak Mugzach]

As this problem drove me crazy today, I decided to developed some code. I
wrote a rexx exec that is an ISPF macro that replaces the buildin send
command, It does the following: 
 

*   save changes done until macro starts.
*   Force undo on and nosave in the member's profile to keep the
variables for future use
*   Scan the member for ORDER and INCLUDE card.
*   Allocate and read the INCLUDEd member (currently only one).  
*   create a table of variable (the set xxx become &xxx) and values
(after the eq sign.
*   find all Instream "DD *" data (Don't care for the DD name). 
*   Change all variables with the values (only those found in "DD *"
pseudo datasets.
*   submits the job with a TSO SUBMIT command
*   Undo all changes done  after the macro starts (to keep the variables
in the text).

So, what I have done is to put "converter" like step before the converter.
The program is almost done. Email me if you want a copy. I think that future
use will be to add support for more then one include member and to change
external allocation of SYSIN type datasets into instream for variable
substitution. 
 
The only problem I can see is that I have to replace the buildin submit
macro with the one I wrote (It is personal, kept in my private ispf profile
and not shared), or to name the macro other then SUB (for example SUBX). It
then be included from your sysproc library. 
 
Will be happy to get more ideas on this.
 
Regards, 
 
Itschak  
 
 
 
| Itschak Mugzach | Director | SecuriTeam Software |
| Email: [EMAIL PROTECTED] | Mob: +972 522 986404 | Skype: Itschak
Mugzach | Web: www.Securiteam.co.il    | 
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

BMC DBU December 2007 maintenance level plus a PTF (BPQ2035) needed for ALLOWUSERKEYCSA(NO)

[Knutson, Sam]

Hi,

We ran into an issue at DRP with the recovery jobs getting ABEND B78-5C running 
BACKUP AND RECOVERY FOR IMS VERSION  4.2.00 MAINTENANCE DATE  11/09/06 with 
z/OS setting ALLOWUSERKEYCSA(NO).

BMC DBU December 2007 maintenance level plus a PTF (BPQ2035) is required to 
finally remove allocation of user key common storage from these tools.


BROWSE    U06T03.FTP.PDS(BPQ2035)    L
 Command ===>  
* Top of Data *
++PTF(BPQ2035)  REWORK(08023000).  
++VER(BMCS,BOOL)       
  FMID(ZDLI460)    
  SUP(BAQ2247) 
  PRE(BPQ1789) 
  /*   
  PROBLEM DESCRIPTION(S):  
   
  BAQ2247 - EXTERNAL SORT IS USING KEY 8 CSA FOR GLOBAL
    CIRCULAR QUEUE.    
       
  COMPONENT: ZDLI460   
   
  APARS FIXED:  BAQ2247    
   
  TECHNICAL DESCRIPTION:   
   
   
   
  DOCUMENTATION:       
  LAST UPDATED: 23.JAN.08 11:10:55 BHM  */.

    

    Best Regards, 

    Sam Knutson, GEICO 
    Performance and Availability Management 
    mailto:[EMAIL PROTECTED] 
    (office)  301.986.3574

"Think big, act bold, start simple, grow fast..."





This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Utilization of Mainframe Software Licenses

[Rick Fochtman]

---

Perhaps your CEO read this article by Gartner?  


OVERCOMING THE SOFTWARE LICENSING COMPLEXITY CRISIS
The Case for a Universal Licensing Platform

http://www.softsummit.com/library/white_papers/gartner_overcomingcomplexity.pdf
 



Here we go again: "Management by Airline Magazine". While I agree that 
some of the material submitted by Gartner Group is valid and makes good 
sense, they also produce a great deal of trash. YMMV.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL SET command and instream SYSIn

[Rick Fochtman]

--
A JCL SET statement value can also be passed and resolved as a PARM= 
string, so it is possible to write a program in your favorite language 
that takes the PARM= value and writes the data to a DD allocation in a 
job-step. And if you must have multiple data lines substituted, for 
example as SYSIN, use multiple job-steps with DISP=NEW for the first 
step and DISP=MOD for each additional job-step.


I am contributing a "helper program" that might be useful in this area. 
It substitutes PARM= values into control statements and writes them to a 
DD named SYSIN, then invokes a program that's also specified in the PARM 
field. It's called UTILITY and I'm about 15 minutes away from sending it 
to the CBTTAPE site. A private E-Mail request will get you a copy.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FTP QUESTION - Put Command

[Alan Brown]

I think you need to add the (REPLACE command at the end of the FTP command

Alan Brown
IBM Software Group





John Dawes <[EMAIL PROTECTED]> 
Sent by: IBM Mainframe Discussion List 
06/30/2008 12:06 PM
Please respond to
IBM Mainframe Discussion List 


To
IBM-MAIN@BAMA.UA.EDU
cc

Subject
FTP QUESTION - Put Command






Good Day,
 
I am attempting to FTP a file to a sequential dataset which is 
preallocated  on the MAINFRAME.
 
When I issued the command :put jclbkup 'my.dsn.mainframe' .  The jclbkup 
is the name of the file which is on my D drive.  The command is accepted 
but I don't see any records being FTP'd.  I verify the dsn on the 
MAINFRAME and it is empty.  Can anybody please point out my error?
 
Thanks.


  Get the name you always wanted with the new y7mail email address.
www.yahoo7.com.au/mail

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FTP QUESTION - Put Command

[John Dawes]

Here it is:
ftp> PUT
Local file D:\Documents and Settings\SYSEN1\My Documents\NTP FTP\FTPTEST


--- On Tue, 1/7/08, John P Kalinich <[EMAIL PROTECTED]> wrote:

From: John P Kalinich <[EMAIL PROTECTED]>
Subject: Re: FTP QUESTION - Put Command
To: IBM-MAIN@BAMA.UA.EDU
Received: Tuesday, 1 July, 2008, 2:08 AM

John Dawes fo the IBM Mainframe Discussion List  
wrote on 06/30/2008 11:06:50 AM:

> Good Day,
>  
> I am attempting to FTP a file to a sequential dataset which is 
> preallocated  on the MAINFRAME.
>  
> When I issued the command :put jclbkup 'my.dsn.mainframe' .  The 
> jclbkup is the name of the file which is on my D drive.  The command
> is accepted but I don't see any records being FTP'd.  I verify the

> dsn on the MAINFRAME and it is empty.  Can anybody please point out my 
error?

Can you post the FTP messages?

Regards,
John K

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


  Get the name you always wanted with the new y7mail email address.
www.yahoo7.com.au/mail

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: USS file sharing in z/OS

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Metcalfe
> Sent: Monday, June 30, 2008 10:42 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: USS file sharing in z/OS
> 
> I have a slightly different requirement, and I have come to 
> the conclusion that 
> I can't meet it.
> 
> I have a user that wants to share zFSes between a subset of 
> systems within 
> a 13-way parallel sysplex. 
> Not all dasd is shared between all members of the sysplex. We 
> merged 3 
> sysplexes into one and only share the dasd necessary to run 
> the plex e.g. 
> CDS, logger, MII etc. We are in the process of converting to 
> a full sysplex 
> where all resources will be available, but this will take 
> some time (sometime 
> never!).
> 
> As all systems do not share the dasd, I cannot move to 
> SYSPLEX(YES) type 
> file sharing. I realise that I could share the files if they 
> were mounted R/O, but 
> I know the application wants to R/W. 
> Does anyone have any clever suggestions?
> 
> Thanks

NFS. A bit complicated, but workable. If you have hipersockets between
the z/OS images, it should be quite fast.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FTP QUESTION - Put Command

[John P Kalinich]

John Dawes fo the IBM Mainframe Discussion List  
wrote on 06/30/2008 11:06:50 AM:

> Good Day,
>  
> I am attempting to FTP a file to a sequential dataset which is 
> preallocated  on the MAINFRAME.
>  
> When I issued the command :put jclbkup 'my.dsn.mainframe' .  The 
> jclbkup is the name of the file which is on my D drive.  The command
> is accepted but I don't see any records being FTP'd.  I verify the 
> dsn on the MAINFRAME and it is empty.  Can anybody please point out my 
error?

Can you post the FTP messages?

Regards,
John K

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

FTP QUESTION - Put Command

[John Dawes]

Good Day,
 
I am attempting to FTP a file to a sequential dataset which is preallocated  on 
the MAINFRAME.
 
When I issued the command :put jclbkup 'my.dsn.mainframe' .  The jclbkup is the 
name of the file which is on my D drive.  The command is accepted but I don't 
see any records being FTP'd.  I verify the dsn on the MAINFRAME and it is 
empty.  Can anybody please point out my error?
 
Thanks.


  Get the name you always wanted with the new y7mail email address.
www.yahoo7.com.au/mail

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: USS file sharing in z/OS

[Mark Zelden]

On Mon, 30 Jun 2008 10:42:02 -0500, Andrew Metcalfe
<[EMAIL PROTECTED]> wrote:

>I have a slightly different requirement, and I have come to the conclusion that
>I can’t meet it.
>
>I have a user that wants to share zFSes between a subset of systems within
>a 13-way parallel sysplex.
>Not all dasd is shared between all members of the sysplex. We merged 3
>sysplexes into one and only share the dasd necessary to run the plex e.g.
>CDS, logger, MII etc. We are in the process of converting to a full sysplex
>where all resources will be available, but this will take some time (sometime
>never!).
>
>As all systems do not share the dasd, I cannot move to SYSPLEX(YES) type
>file sharing. I realise that I could share the files if they were mounted
R/O, but
>I know the application wants to R/W.
>Does anyone have any clever suggestions?
>

Not all systems have to participate in the shared filesystem environment. 
It can be a subset of your sysplex.  

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: USS file sharing in z/OS

[Andrew Metcalfe]

I have a slightly different requirement, and I have come to the conclusion that 
I can’t meet it.

I have a user that wants to share zFSes between a subset of systems within 
a 13-way parallel sysplex. 
Not all dasd is shared between all members of the sysplex. We merged 3 
sysplexes into one and only share the dasd necessary to run the plex e.g. 
CDS, logger, MII etc. We are in the process of converting to a full sysplex 
where all resources will be available, but this will take some time (sometime 
never!).

As all systems do not share the dasd, I cannot move to SYSPLEX(YES) type 
file sharing. I realise that I could share the files if they were mounted R/O, 
but 
I know the application wants to R/W. 
Does anyone have any clever suggestions?

Thanks

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Utilization of Mainframe Software Licenses

[Lizette Koehler]

Perhaps your CEO read this article by Gartner?  

OVERCOMING THE SOFTWARE LICENSING COMPLEXITY CRISIS
The Case for a Universal Licensing Platform


http://www.softsummit.com/library/white_papers/gartner_overcomingcomplexity.pdf

Lizette



>My CEO is asking me to generate report on software licensing usage ... Even
>I am not aware what this jargon is ?
>
>On 6/27/08, Schwarz, Barry A <[EMAIL PROTECTED]> wrote:
>>
>> Give some context please.
>>

>>
>> Can anyone help me in understanding the rerm Utilization of Mainframe
>> Software Licensing ? Does it mean taking care of licensing cost as per
>> the MIPS / MSU or it involves something more than that...?
>>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Strange Problem: System Code S106

[Peter Relson]

>we faced a strange problem with a system code S106,
>as response to a LOAD macro call.

The error was yours. If the system had been asked to load your module it
would have properly dealt with this situation.

You cannot just  do "lookup of the CDE" unless you account for any and
every bit combination that might be represented by the flags that exist,
and I do not propose to explain how you should do this because, simply, you
shouldn't do this.

For those curious enough to try, compare the CDE that is "left over" in
this case with the CDE that you get on a successful load. The case, in
particular is: a load fails with an I/O error, and the call does not
specify ERRET.  For what it's worth, with ERRET, this cleanup happens. The
reason for the behavioral difference between ERRET and no ERRET is lost to
history. It has behaved this way "forever".

Peter Relson
z/OS Core Technology Design
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Utilization of Mainframe Software Licenses

[Jacky Bright]

My CEO is asking me to generate report on software licensing usage ... Even
I am not aware what this jargon is ?

On 6/27/08, Schwarz, Barry A <[EMAIL PROTECTED]> wrote:
>
> Give some context please.
>
> -Original Message-
> From: Jacky Bright [mailto:snip]
> Sent: Friday, June 27, 2008 7:23 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Utilization of Mainframe Software Licenses
>
> Can anyone help me in understanding the rerm Utilization of Mainframe
> Software Licensing ? Does it mean taking care of licensing cost as per
> the MIPS / MSU or it involves something more than that...?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Is this RNL correct?

[Bobbie Justice]

We use the GRS RNL Pattern Conversion list for all three of the below.  


from II10752: 
The resource SYSIGGV2 MUST be converted to a SYSTEMS enqueue 
when using catalogs in ECS mode. Failure to do so will result
in damage to catalogs in ECS mode.   
This is applicable to all levels of DFSMS that support ECS   
(HDZ11F0, HDZ11G0, HDZ11H0, HDZ11J0, HDZ11K0, HDZ1180,   
HDZ1190).


The resources SYSZVVDS and SYSVTOC MUST be treated the same
way, either both converted or both excluded to prevent deadlocks   
   .   
See info apar II14297 for more discussion on Catalog and GRS   
resources.

FROM II14297 
   Note that in all cases the GRS QNAMEs SYSZVVDS and SYSVTOC  
must be treated the same way to avoid resource deadlocks. If you   
convert SYSVTOC you must convert SYSZVVDS, likewise if you
exclude SYSVTOC you must exclude SYSZVVDS.
 
   If you are sharing catalogs within a GRS complex, you must
have a generic entry for SYSIGGV2 in the Conversion RNL. Failure 
to do so may create lockouts. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL SET command and instream SYSIn

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Barkow, Eileen
> Sent: Monday, June 30, 2008 9:22 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: JCL SET command and instream SYSIn
> 
> I have a program that
> processes the SET command values passed to it in the parm field and it
> then
> uses them to set condition codes. 
>  The program passes numbers as condition codes and has a few reserved
> words it recognizes from the SET commands to pass condition 
> code values.
> 
> The SET commands are very useful.
> 

I agree that SET variables are very useful. But I think that they could
be more useful if they were more like UNIX environment variables -
accessible to running programs. Perhaps via the ASASYMBM interface. The
100 char limit on PARM, limits how much data you can pass to a program
using it.

Another weird idea just occurred to me (though I may have read it here).
A subsystem, written by IBM, which "emulates" a sequential file. But
what is read are the subsystem parameters on the JCL. Each subparameter
would be a separate record when read by the program. This could be used
to replace small SYSIN-like data with data which includes symbol
substitution.

Eg:

//DEL EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD SUBSYS=(READ,
// ' DEL &DSN',
// ' SET MAXCC=0'),
// DCB=(RECFM=FB,LRECL=80,BLKSISE=80)

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Chargeback tools

[Howard Brazee]

On 29 Jun 2008 09:54:16 -0700, [EMAIL PROTECTED] (Shmuel
Metz  , Seymour J.) wrote:

>>what else should be accounted for?
>
>There's really no "should"; it depends on local policy. What's important
>is that management understands and buys into the charge-back scheme.

Also, it is important to be able to adjust a charge-back scheme when
unintended consequences result.   And there are always unintended
consequences.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL SET command and instream SYSIn

[Barkow, Eileen]

I have a program that
processes the SET command values passed to it in the parm field and it
then
uses them to set condition codes. 
 The program passes numbers as condition codes and has a few reserved
words it recognizes from the SET commands to pass condition code values.

The SET commands are very useful.

Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of McKown, John
Sent: Monday, June 30, 2008 9:56 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: JCL SET command and instream SYSIn

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin
> Sent: Monday, June 30, 2008 8:37 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: JCL SET command and instream SYSIn
[snip]
> Gee, that's ugly.  And not quite modular: you have to first install
> the helper program.  I suppose it could be inline SYSIN to a leading
> assembler step.  Or Rexx in an IEBGENER step.  Gee, I still wish
> Rexx could access SET symbol values (Yeah, I know; use SDSF to
> read the JCL text.)
> 
> -- gil

The biggest "problem" to me with JCL SET commands is that the are not
really JCL. They don't exist once the converter uses them. Sort of like
HLASM GBLx variables. They don't generate any text records themselves.
They just modify the values in other instructions. Likewise, JCL SET
variables and values do not result in "internal text" records.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Is this RNL correct?

[Jimmy Wagner]

John,

The exclude version of the RNL is what we have here. No issues since it was 
set up by IBM during a MIM to GRS conversion over 3 years ago.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Is this RNL correct?

[Mark Zelden]

On Mon, 30 Jun 2008 08:49:34 -0500, McKown, John
<[EMAIL PROTECTED]> wrote:

>We had some DFHSM problems over the weekend (deadly embrace) on our
>basic sysplex. Looking at the output of some commands that I have
>automation issue, I found what I think may be a problem with an RNL
>entry:
>
>RNLDEF RNL(EXCL) TYPE(GENERIC)  QNAME(SYSZVVDS)
>
>Should this be removed or changed to:
>
>RNLDEF RNL(CON) TYPE(GENERIC)  QNAME(SYSZVVDS)
>

It depends.  What are you doing with SYSVTOC?   If you convert one, 
you  must convert both.   FYI... I don't convert either, but I am not
using GRS STAR nor MIM in a CF.  Plenty in the archives about this...

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL SET command and instream SYSIn

[Clement Clarke]

Jol allows this.  You can set up a symbolic variable, or use one of the 
pre-defined variables, and have it replaced on your card file.


For example, %DAY is set up by Jol

Then...

DCL X * REPLACE;
Today is %DAY
Month %MONTH
EOF;

Print x;   /* Print the card file */

See www.ozemail.com.au/~oscarptyltd


Cheers, 


Clem


[EMAIL PROTECTED] wrote:

I already tried that and it doesn't work: A jcl set variable orks only on real 
JCL not on instream SYSIN (DD *). Any workaround? Any alternative to modify JCL 
and SYSIN (for example, deleting/definning datasets with IDCAMS) at one 
parameter without having to use ISPF CHANGE ALL?

Thanks for your ideas

Itschak 



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

  


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL SET command and instream SYSIn

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin
> Sent: Monday, June 30, 2008 8:37 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: JCL SET command and instream SYSIn
[snip]
> Gee, that's ugly.  And not quite modular: you have to first install
> the helper program.  I suppose it could be inline SYSIN to a leading
> assembler step.  Or Rexx in an IEBGENER step.  Gee, I still wish
> Rexx could access SET symbol values (Yeah, I know; use SDSF to
> read the JCL text.)
> 
> -- gil

The biggest "problem" to me with JCL SET commands is that the are not
really JCL. They don't exist once the converter uses them. Sort of like
HLASM GBLx variables. They don't generate any text records themselves.
They just modify the values in other instructions. Likewise, JCL SET
variables and values do not result in "internal text" records.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Is this RNL correct?

[McKown, John]

We had some DFHSM problems over the weekend (deadly embrace) on our
basic sysplex. Looking at the output of some commands that I have
automation issue, I found what I think may be a problem with an RNL
entry:

RNLDEF RNL(EXCL) TYPE(GENERIC)  QNAME(SYSZVVDS)

Should this be removed or changed to:

RNLDEF RNL(CON) TYPE(GENERIC)  QNAME(SYSZVVDS)

?

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL SET command and instream SYSIn

[Paul Gilmartin]

On Mon, 30 Jun 2008 07:53:35 -0500, Scott Barry wrote:

>A JCL SET statement value can also be passed and resolved as a PARM=
>string, so it is possible to write a program in your favorite language that 
>takes
>the PARM= value and writes the data to a DD allocation in a job-step.  And if
>you must have multiple data lines substituted, for example as SYSIN, use
>multiple job-steps with DISP=NEW for the first step and DISP=MOD for each
>additional job-step.
>
Actually, for a temporary data set, you can use DISP=(MOD,PASS) for
every step because it starts out empty.  This makes it easier to
rearrange the order of steps if necessary.

>At one site I support, this technique is used to build IDCAMS control
>statements for execution.
>
Gee, that's ugly.  And not quite modular: you have to first install
the helper program.  I suppose it could be inline SYSIN to a leading
assembler step.  Or Rexx in an IEBGENER step.  Gee, I still wish
Rexx could access SET symbol values (Yeah, I know; use SDSF to
read the JCL text.)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL SET command and instream SYSIn

[Scott Barry]

A JCL SET statement value can also be passed and resolved as a PARM= 
string, so it is possible to write a program in your favorite language that 
takes 
the PARM= value and writes the data to a DD allocation in a job-step.  And if 
you must have multiple data lines substituted, for example as SYSIN, use 
multiple job-steps with DISP=NEW for the first step and DISP=MOD for each 
additional job-step. 

At one site I support, this technique is used to build IDCAMS control 
statements for execution.

Scott Barry
SBBWorks, Inc.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL SET command and instream SYSIn

[Paul Gilmartin]

On Mon, 30 Jun 2008 03:28:19 -0600, [EMAIL PROTECTED] wrote:

>I already tried that and it doesn't work: A jcl set variable orks only on real 
>JCL not on instream SYSIN (DD *). Any workaround? Any alternative to modify 
>JCL and SYSIN (for example, deleting/definning datasets with IDCAMS) at one 
>parameter without having to use ISPF CHANGE ALL?
>
Nope.

Thanks for your ideas
>
I keep some of my JCL members, including one which renames data sets
and defines aliases with IDCAMS, as UNIX shell scripts in which the
actual JCL appears as a here-document.  The shell scripts filter
and submit the JCL using parameter substitution in the simpler cases
and sed or awk in the more complicated.  One substitution I regularly
do is to create data set names incorporating the current date, not
possible with pure batch JCL.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL SET command and instream SYSIn

[Ted MacNEIL]

>I already tried that and it doesn't work: A jcl set variable orks only on real 
>JCL not on instream SYSIN (DD *). Any workaround?

This has been discussed many times (see the archives).
The answer is NO.
And, this is documented in the JCL manual(s).

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

JCL SET command and instream SYSIn

[[EMAIL PROTECTED]]

I already tried that and it doesn't work: A jcl set variable orks only on real 
JCL not on instream SYSIN (DD *). Any workaround? Any alternative to modify JCL 
and SYSIN (for example, deleting/definning datasets with IDCAMS) at one 
parameter without having to use ISPF CHANGE ALL?

Thanks for your ideas

Itschak 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Stupid Question of the day.

[Gerhard Postpischil]

Greg Price wrote:

The MULTITSO package in CBT file 134 appeared when the millenium was young,
and JES (at least JES2) only allowed one TSU job of a specific name to run at
a time.


I checked but could not find the relevant code (just came back 
from a convention). But last millennium we had two mods from the 
CBT on our system. One used a TSO pre-logon exit to handle our 
own user validation and set options; one feature was the option 
to change the exclusive to a shared ENQ, thus allowing multiple 
logons (before ISPF, so no profile problems, etc.). The other 
was an option to route the logon to a secondary JES. I'll keep 
looking.


Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html