Re: What was a 3314?

[Anne & Lynn Wheeler]

edgould1...@comcast.net (Edward Gould) writes:
> It addressing had MMBBCCHHR(R?) so I guess you could address it
> directly. Anyone remember how to do that? (progr5amming for a 2321 is
> a lost art (where is Seymour?).

the "BB" was to select the BIN that the magnetic strips were located
in. 
https://www-03.ibm.com/ibm/history/exhibits/storage/storage_2321.html
and
https://en.wikipedia.org/wiki/IBM_2321_Data_Cell

Generically, at the OS level, IBM defined the six bytes as BBCCHH, for
Bin, Bin, Cylinder, Cylinder, Head and Head respectively.

... snip ... 

referenced from:
http://www.bitsavers.org/pdf/ibm/360/os/R21.7_Apr73/GC28-6628-9_OS_System_Ctl_Blks_R21.7_Apr73.pdf


the bins (cells) rotated under the r/w heads.
https://www-03.ibm.com/ibm/history/exhibits/storage/storage_PH2321B.html
http://www.computer-history.info/Page4.dir/pages/Photostore.dir/images/Picture.1.jpg

as undergraduate, univ. hired me as fulltime support for the production
ibm systems. the univ. library got an ONR grant to do online catalog
... and used part of the money to get a 2321 datacell. The project was
also selected to be one of the original CICS product betatest sites and
I got tasked with debugging/supporting CICS (one of the "bugs" was that
CICS original implementation at customer site used specific set of BDAM
options which was hardcoded in the source ... and the library had chosen
a different set of BDAM options ... it took some dump analysis to
discover the issue since it wasn't documented).

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

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

Re: What was a 3314? (was: Whither VIO)

[Martin Packer]

It's sort of come back to me:

A small track size limits the virtual storage window (probably usually
below the line in 1989 when I looked at this). Or it might've been
cylinder. But I think it was track.

I'm wondering if anyone else remembers something like this.

Cheers, Martin

Sent from my iPad

On 19 May 2016, at 05:20, Edward Gould  wrote:

>> On May 18, 2016, at 7:50 PM, Charles Mills  wrote:
>>
>> I remember them well. I was answering Steve's two implied questions.
>>
>> 2321 was certainly characterized as DASD. It was indeed a direct access
storage device. Not a disk, but DASD nonetheless. Certainly not magnetic
tape (though it had a family resemblance!) and certainly not unit record.
>
> It addressing had MMBBCCHHR(R?) so I guess you could address it directly.
Anyone remember how to do that? (progr5amming for a 2321 is a lost art
(where is Seymour?).
>
> Ed
>
>>
>> I don't think anyone recalls a 3314. I think the OP said it was a typo,
2314 mis-remembered as 3000-series DASD.
>>
>> Charles
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Edward Gould
>> Sent: Wednesday, May 18, 2016 5:33 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: What was a 3314? (was: Whither VIO)
>>
>> Chales,
>>
>> 2321 was a data cell (magnetic strip) hardly could be called DASD) I
don’t recall a 3314 . The removable 3340 (not sure the number anyone?)
>>
>> Ed
>>
>>> On May 16, 2016, at 7:47 PM, Charles Mills  wrote:
>>>
>>>
>>>
>>> 2301, 2321.
>>> CharlesSent from a mobile; please excuse the brevity
>>>
>>>  Original message 
>>> From: Steve Thompson 
>>> Date: 05/16/2016  4:51 PM  (GMT-08:00)
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: What was a 3314? (was: Whither VIO)
>>>
>>> 2314, 2419, 2311, these are just a few of the "IBM" DASD that I've had
>>> the pleasure of working with. I've forgotten the drum device numbers
>>> and the noodle snatcher model number.
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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

Re: What was a 3314? (was: Whither VIO)

[Edward Gould]

> On May 18, 2016, at 7:50 PM, Charles Mills  wrote:
> 
> I remember them well. I was answering Steve's two implied questions.
> 
> 2321 was certainly characterized as DASD. It was indeed a direct access 
> storage device. Not a disk, but DASD nonetheless. Certainly not magnetic tape 
> (though it had a family resemblance!) and certainly not unit record.

It addressing had MMBBCCHHR(R?) so I guess you could address it directly. 
Anyone remember how to do that? (progr5amming for a 2321 is a lost art (where 
is Seymour?).

Ed

> 
> I don't think anyone recalls a 3314. I think the OP said it was a typo, 2314 
> mis-remembered as 3000-series DASD.
> 
> Charles
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Edward Gould
> Sent: Wednesday, May 18, 2016 5:33 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: What was a 3314? (was: Whither VIO)
> 
> Chales,
> 
> 2321 was a data cell (magnetic strip) hardly could be called DASD) I don’t 
> recall a 3314 . The removable 3340 (not sure the number anyone?)
> 
> Ed
> 
>> On May 16, 2016, at 7:47 PM, Charles Mills  wrote:
>> 
>> 
>> 
>> 2301, 2321.
>> CharlesSent from a mobile; please excuse the brevity
>> 
>>  Original message 
>> From: Steve Thompson 
>> Date: 05/16/2016  4:51 PM  (GMT-08:00)
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: What was a 3314? (was: Whither VIO)
>> 
>> 2314, 2419, 2311, these are just a few of the "IBM" DASD that I've had 
>> the pleasure of working with. I've forgotten the drum device numbers 
>> and the noodle snatcher model number.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Product name by module

[Edward Gould]

> On May 18, 2016, at 3:00 AM, Peter  wrote:
> 
> Hi,
> 
> One of the module shows me the below copyright but I do not see the product
> name.
> 
> EIRFUCB2V1R1M0  5706-110 (C) COPYRIGHT IBM CORP. 1990 19945706-110 (C)


The old Program product number is 5706-110 Try a google search or there used to 
be an IBM manual that listed all the PP #’s. IIRC it was a slim yellow (not 8.5 
by 11) manual. I used it all the time. Not sure if IBM kept it around.
Barring that ask your friendly IBMer.

Ed

> 
> Is there a Link within IBM which can help me to track ?
> 
> On Wed, May 18, 2016 at 1:00 PM, Edward Finnell <
> 000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote:
> 
>> Just to refine what Elardus has recommended. You can turn on audit in RACF
>> and see who's hitting them.
>> Check PROCLIBs and SYSPROCs/SYSEXEC for occurrences. With ISRDDN check to
>> see if they're LINKLST'd or APFLST'd. In ISPF browse have the option to
>> sort
>> on  columns. Something like
>> 'SORT LNKED D|A' just to see if they've been actively modified.
>> 
>> 
>> In a message dated 5/18/2016 2:03:24 A.M. Central Daylight Time,
>> elardus.engelbre...@sita.co.za writes:
>> 
>> 
>> You  can buy expensive audit software which can scan your volsers for
>> unlicensed  software.
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Product name by module

[Edward Gould]

> On May 18, 2016, at 12:12 AM, Ed Jaffe  wrote:
> 
> On 5/17/2016 9:56 PM, Peter wrote:
>> Is it always possible to identify the product name by looking through the
>> load modules.
> 
> No.
> 
>> Here in our shop there are some DATASET lying where we do not
>> have any clue to which product it belongs to.
>> 
>> Any pointers or ideas to know the product name by looking through the
>> module ?
> 
> Look for copyright information.

That is one way and a darn good one I might add another sometime effective was 
is to look at the IDR of the module. Some companies put information there .
Ed

> 
> -- 
> Edward E Jaffe
> Phoenix Software International, Inc
> 831 Parkview Drive North
> El Segundo, CA 90245
> http://www.phoenixsoftware.com/
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Ancient software (Re: Product name by module)

[Edward Gould]

We had a CICS “application” that we were paying big bucks for . We did a 
similar thing but inserted code into the “application” that did a WTO . we 
scanned the syslogs daily and not once in 6 months was this “application” used. 
We took the empty logs to the user and said see you aren’t using it. They said 
otherwise. So we essentially did a br r14 into the code and waited another six 
months and went back to the user and asked if they were still using the 
application. They again said yes so we deleted the cics application and never 
brought it up again. The user never had a clue and we saved $60K (US) after 2 
years. We made sure management was aware of this and got their blessing. I 
don’t think they believed the user anymore after that. I wish I could have 
gotten 10 percent of the savings.

Ed
 
> On May 18, 2016, at 7:17 AM, Elardus Engelbrecht 
>  wrote:
> 
> Radowslaw Skorupka wrote:
> 
>> Of course I can imagine an answer like "we've been running this job for 15 
>> years, Frankie said it's important, but he retired 10 years ago, we don't 
>> know who's currently using it, nor what is the name of the application". ;-)
> 
> It was my unpleasant task to get rid of an expensive software suite, because 
> *all* are using it for many years and it is that *important*. The same as 
> Radoslaw said.
> 
> Really? The original person who maintained that software went away for a 
> better pay job overseas.
> 
> It was troublesome to even think of that removal story, because one of our 
> clients swore high and low they are *really* using it and ALL of its 
> connectors to the various database subsystems.
> 
> And they said *many* persons are using it.
> 
> I laid out a nasty trap to satisfy my bosses: 
> I used RACF WARNING and turned off those connectors. Nothing happened. I told 
> my boss what happened, we met up next month with the client. I showed my 
> proof, only ONE person is using it and NOT those connectors.
> 
> They relented. We then moved that software to a LPAR with 1 CPU allocated. 
> They complained about bad response time, etc. and eventually they used those 
> database own software to collect all the data they needed.
> 
> Next month my stats showed that NO ONE actually used that expensive software 
> suite.
> 
> Good. We notified the vendor that we drop them due to costs and no-one is 
> using it. They missed the boat in the sense they tried to persuade us to buy 
> a more EXPENSIVE suite. Tsk, tsk, tsk.
> 
> I believe many IBM-MAIN persons are sitting in the same boat. Getting rid of 
> ancient legacy (I hate that fancy word!) stuff because of costs and because 
> as one often said 'they're going off the mainframe'.
> 
> Groete / Greetings
> Elardus Engelbrecht
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: What was a 3314? (was: Whither VIO)

[Steve Thompson]

Well, the S/360-20 had TPS (Tape Processing System, not to be 
confused with Tape Operating System) which had a RESVOL that was 
a tape. And there were utilities to update the tape in place (not 
copy to another tape and then back, actual update blocks in 
place). From time to time one would have to make a new copy of 
the REsVOL to, kinda defrag it as I remember.


By the time I got to TPS (Tape Processing System), IBM was no 
longer putting out maint. Or we just weren't getting any maint 
for it from IBM (1977-78 when I was working on that system).


The Noodle snatcher had "data cells" which were segments that had 
x strips of tape hanging in them (where x is a number that I've 
forgotten). It was tape that could be randomly accessed, so it 
was a kind of DASD.


It had a very interesting instruction. RFWBS, Read Forward, Write 
Backward with Shredding. Yep, catch that mylar strip (aka, 
noodle) on the edge of the slot and it would peal/slice it in 
two. That could wreck you whole day.


And if you had just had maintenance done, and one of the segments 
was not correctly fastened in place, when that sucker would 
rotate, it would fling that segment right through the "glass" and 
well, things just got exciting for a bit.


Makes one very glad to have things like thumb drives that we have 
today. Now if I could just get one big enough to IPL z/OS...


Regards,
Steve Thompson


On 05/18/2016 09:07 PM, Paul Gilmartin wrote:

On Wed, 18 May 2016 17:50:53 -0700, Charles Mills wrote:


... It was indeed a direct access storage device. Not a disk, but DASD 
nonetheless. Certainly not magnetic tape (though it had a family resemblance!) 
and certainly not unit record.


What's the criterion?  Max/Min latency ratio?  Statistical distribution of 
latency
between randomly selected records?  For tape, it's sort of triangular; for DASD
it has a sort of plateau.

Addressable by block and writable randomly without corrupting other blocks?
DECtape had preformatted addressable blocks; it held a filesystem with a
directory.  It moved from reel to reel past a stationary R/W head.  It met some
criteria for DASD and some for tape; it was both.

-- gil

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



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

Re: What was a 3314? (was: Whither VIO)

[Paul Gilmartin]

On Wed, 18 May 2016 17:50:53 -0700, Charles Mills wrote:

> ... It was indeed a direct access storage device. Not a disk, but DASD 
> nonetheless. Certainly not magnetic tape (though it had a family 
> resemblance!) and certainly not unit record.
>
What's the criterion?  Max/Min latency ratio?  Statistical distribution of 
latency
between randomly selected records?  For tape, it's sort of triangular; for DASD
it has a sort of plateau.

Addressable by block and writable randomly without corrupting other blocks?
DECtape had preformatted addressable blocks; it held a filesystem with a
directory.  It moved from reel to reel past a stationary R/W head.  It met some
criteria for DASD and some for tape; it was both.

-- gil

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

Re: What was a 3314? (was: Whither VIO)

[Charles Mills]

I remember them well. I was answering Steve's two implied questions.

2321 was certainly characterized as DASD. It was indeed a direct access storage 
device. Not a disk, but DASD nonetheless. Certainly not magnetic tape (though 
it had a family resemblance!) and certainly not unit record.

I don't think anyone recalls a 3314. I think the OP said it was a typo, 2314 
mis-remembered as 3000-series DASD.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edward Gould
Sent: Wednesday, May 18, 2016 5:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What was a 3314? (was: Whither VIO)

Chales,

2321 was a data cell (magnetic strip) hardly could be called DASD) I don’t 
recall a 3314 . The removable 3340 (not sure the number anyone?)

Ed

> On May 16, 2016, at 7:47 PM, Charles Mills  wrote:
> 
> 
> 
> 2301, 2321.
> CharlesSent from a mobile; please excuse the brevity
> 
>  Original message 
> From: Steve Thompson 
> Date: 05/16/2016  4:51 PM  (GMT-08:00)
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: What was a 3314? (was: Whither VIO)
> 
> 2314, 2419, 2311, these are just a few of the "IBM" DASD that I've had 
> the pleasure of working with. I've forgotten the drum device numbers 
> and the noodle snatcher model number.

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

Re: Suggestion for conditioning step on symbols

[Edward Gould]

> On May 16, 2016, at 7:23 AM, Elardus Engelbrecht 
>  wrote:
> 
> John McKown wrote:
> 
>>> You can always write a 3rd SORT system with a build in programming 
>>> language. Hopefully that system is sort of free...
> 
>> ​Oh, yeah. Perhaps based on Guile (big grin)
>> https://en.wikipedia.org/wiki/GNU_Guile. It's a LISP variant.
> 
> H, very very interesting part of the GNU project. I have bookmarked that! 
> Many thanks!
> 
> 
>> ​CA-Easytrieve Plus might fit your bill. Of course, being as how it's from 
>> CA, it is not free at all. But it is faster and easier to write than COBOL.​

I would disagree with that statement a lot. I could whip out SMF reports faster 
than management could ask. COBOL was OK (but not even close).

Ed

> 
> My purse (usually empty and made from scottish leather) will drop me real 
> faster than I write than COBOL or use that software ... 
> 
> Groete / Greetings
> Elardus Engelbrecht
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: What was a 3314? (was: Whither VIO)

[Edward Gould]

Chales,

2321 was a data cell (magnetic strip) hardly could be called DASD)
I don’t recall a 3314 . The removable 3340 (not sure the number anyone?)

Ed

> On May 16, 2016, at 7:47 PM, Charles Mills  wrote:
> 
> 
> 
> 2301, 2321.
> CharlesSent from a mobile; please excuse the brevity
> 
>  Original message 
> From: Steve Thompson  
> Date: 05/16/2016  4:51 PM  (GMT-08:00) 
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: What was a 3314? (was: Whither VIO) 
> 
> 2314, 2419, 2311, these are just a few of the "IBM" DASD that 
> I've had the pleasure of working with. I've forgotten the drum 
> device numbers and the noodle snatcher model number.
> 
> Regards,
> Steve Thompson
> 
> On 05/16/2016 07:24 PM, Jesse 1 Robinson wrote:
>> OK, the sleeping dog wants some attention. Before my first reply, I 
>> carefully Googled device type 2314 to verify the number. Then I typed '3314' 
>> because who has ever worked with DASD that started with something other than 
>> '33'? 2314 remained valid in the IODEVICE macro long, long after the final 
>> one disappeared into the sunset. And as I said, I was advised to use it for 
>> VIO because of 'device architecture', whatever that meant. Track size, I 
>> guess, from what others have posted.
>> 
>> .
>> .
>> .
>> J.O.Skip Robinson
>> Southern California Edison Company
>> Electric Dragon Team Paddler
>> SHARE MVS Program Co-Manager
>> 323-715-0595 Mobile
>> 626-302-7535 Office
>> robin...@sce.com
>> 
>> 
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>> Behalf Of Clark Morris
>> Sent: Monday, May 16, 2016 4:16 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: (External):Re: What was a 3314? (was: Whither VIO)
>> 
>> [Default] On 16 May 2016 07:01:50 -0700, in bit.listserv.ibm-main 
>> jcal...@narsil.org (Jerry Callen) wrote:
>> 
>>> In the "Whither VIO" thread, J.O.Skip Robinson wrote:
>>> 
In a previous life, we defined VIO (I believe) to device 3314 even
 though we had none left on the floor
>>> 
>>> That's a device type I've never heard of, and the Google knows not of. 
>>> Could this be a typo for "2314"?
>> 
>> I believe the OP meant 2314 which had 7294 bytes per track.  It was a 
>> removable disk.
>> 
>> Clark Morris
>>> 
>>> -- Jerry
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Respack Volume Size Challenge

[ronjhawk...@sbcglobal.net]

Jesse,
That's exactly the sort of testing we do. Truecopy, HUR, Flashcopy, 
Shadowimage, FCSE...
Setting up target volumes on the primary, local and remote controllers is 
equally easy. Especially when we use scripts to provision tens of thousands of 
volumes in a single hit. The same script runs against each controller.
Even using a GUI I can create 20,000 volumes with a mix of 10 cylinder. 
3390-3/27/54/250/1GB sized volumes in about two hours starting with just the 
unformatted parity groups installed. I'm sure the other vendor's interfaces are 
equally fast and easy to use.
Ron


Sent via the Samsung Galaxy S®6 active, an AT 4G LTE smartphone 
Original message From: Jesse 1 Robinson  Date: 
5/18/2016  15:45  (GMT-08:00) To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 
[IBM-MAIN] Respack Volume Size Challenge 
There's one wrinkle that you may not see in a lab. We mirror all production 
DASD to our DR site. If I create an oddball volume in production, it requires 
creation of two more identical ones at the recovery site: one for direct 
mirroring and another one to flash to for running a system. This complicates 
volume mapping. I've been told by storage managers that 'wasted space' is a 
smaller problem for them than trying to manage odd-sized volumes. My few odd 
sizes are, for example, to contain sysplex couple data sets or JES2 checkpoint. 
Very small volumes for data sets that do not party well with others. 

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ron Hawkins
Sent: Wednesday, May 18, 2016 2:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Respack Volume Size Challenge

All,

It's hard to imagine that any customer is limited to specific volume size 
nowadays.

For a decade or so now all the storage vendors have delivered the ability to 
make right-sized volumes, usually only limited to what z/OS supported around 
the time the controller model was introduced.

With virtual volumes now (HDS call it HDP) creating a right-sized volume is a 
piece of cake. Being in a lab this has made life extraordinarily easy to 
provision a range of volume sizes with a couple of mouse clicks, or some 
scripts. Alternatively, with thin provisioning offered by all three vendors you 
could make your SYSRES a 3390-54 and just use the space required for the one 
pack SYSRES. If you just use 20,000 CYLs then that's all you use from the pool 
- a bit like Iceberg revisited.

Ron

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ted MacNEIL
Sent: Sunday, May 15, 2016 6:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Respack Volume Size Challenge

Years ago (pre-9) respacks had ‎to be 'split up'. Now, we ask the risk!

-teD
  Original Message
From: Lucas Rosalen
Sent: Thursday, April 21, 2016 05:14
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Respack Volume Size Challenge

As far as I have seen, it's quite simple: create a  symbol (using
 and changing last char from 1 to 2, for example) and update MCAT 
accordingly.
Once I've worked for a client that had 3-volumes respack. It indeed worked.
We used to keep datasets like LINKLIB, MACLIB, NUCLEUS, etc in 1st volumes 
though...

---
*Lucas Rosalen*
Emails: rosalen.lu...@gmail.com / *lrosa...@pl.ibm.com
*
LinkedIn: http://br.linkedin.com/in/lrosalen
Phone: +48 (71) 792 809 198


2016-04-21 10:45 GMT+02:00 Jake Anderson :

> Hello,
>
> From the z/OS 2.1, I have started using Mod-27 as the Load
> address(Respack) for IPLing the z/OS 2.1 LPAR. I am curious how the 
> other Shops are managing when they do not options of using Mod-27 and 
> they have to survive with Mod-9. I believe the Extended Indirect cataloging 
> is one Options.
>
> What kind of challenges are there when the Respack is divided into two 
> Volumes ?
>
> Jake
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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

--

Re: Respack Volume Size Challenge

[Jesse 1 Robinson]

There's one wrinkle that you may not see in a lab. We mirror all production 
DASD to our DR site. If I create an oddball volume in production, it requires 
creation of two more identical ones at the recovery site: one for direct 
mirroring and another one to flash to for running a system. This complicates 
volume mapping. I've been told by storage managers that 'wasted space' is a 
smaller problem for them than trying to manage odd-sized volumes. My few odd 
sizes are, for example, to contain sysplex couple data sets or JES2 checkpoint. 
Very small volumes for data sets that do not party well with others. 

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ron Hawkins
Sent: Wednesday, May 18, 2016 2:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Respack Volume Size Challenge

All,

It's hard to imagine that any customer is limited to specific volume size 
nowadays.

For a decade or so now all the storage vendors have delivered the ability to 
make right-sized volumes, usually only limited to what z/OS supported around 
the time the controller model was introduced.

With virtual volumes now (HDS call it HDP) creating a right-sized volume is a 
piece of cake. Being in a lab this has made life extraordinarily easy to 
provision a range of volume sizes with a couple of mouse clicks, or some 
scripts. Alternatively, with thin provisioning offered by all three vendors you 
could make your SYSRES a 3390-54 and just use the space required for the one 
pack SYSRES. If you just use 20,000 CYLs then that's all you use from the pool 
- a bit like Iceberg revisited.

Ron

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ted MacNEIL
Sent: Sunday, May 15, 2016 6:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Respack Volume Size Challenge

Years ago (pre-9) respacks had ‎to be 'split up'. Now, we ask the risk!

-teD
  Original Message
From: Lucas Rosalen
Sent: Thursday, April 21, 2016 05:14
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Respack Volume Size Challenge

As far as I have seen, it's quite simple: create a  symbol (using
 and changing last char from 1 to 2, for example) and update MCAT 
accordingly.
Once I've worked for a client that had 3-volumes respack. It indeed worked.
We used to keep datasets like LINKLIB, MACLIB, NUCLEUS, etc in 1st volumes 
though...

---
*Lucas Rosalen*
Emails: rosalen.lu...@gmail.com / *lrosa...@pl.ibm.com
*
LinkedIn: http://br.linkedin.com/in/lrosalen
Phone: +48 (71) 792 809 198


2016-04-21 10:45 GMT+02:00 Jake Anderson :

> Hello,
>
> From the z/OS 2.1, I have started using Mod-27 as the Load
> address(Respack) for IPLing the z/OS 2.1 LPAR. I am curious how the 
> other Shops are managing when they do not options of using Mod-27 and 
> they have to survive with Mod-9. I believe the Extended Indirect cataloging 
> is one Options.
>
> What kind of challenges are there when the Respack is divided into two 
> Volumes ?
>
> Jake
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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

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


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

Re: LOGR Format Level

[Jesse 1 Robinson]

Here are the IXCL1DSU control statements for LOGR in 2.1. Nothing has changed 
in a while. The SMDUPLEX value is not a 'count'. It's really a switch that says 
'support system managed duplex'. 

DATA TYPE(LOGR)
 ITEM NAME(LSR) NUMBER(200)
 ITEM NAME(LSTRR) NUMBER(32)   
 ITEM NAME(DSEXTENT) NUMBER(10)
 ITEM NAME(SMDUPLEX) NUMBER(1) 
   

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Zelden
Sent: Wednesday, May 18, 2016 2:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: LOGR Format Level

On Wed, 18 May 2016 14:04:59 -0400, Dazzo, Matt  wrote:

>>Started the 1.13 to 2.2 migration guide and they suggest upgrading 
>>LOGR dsn's to  level HBB7705, we are at HBB6603. We are a monoplex 
>>shop and probably always  will be. Is there any need to take this action in 
>>our environment?


>
> Below are the dsn's defined in couplxx member.  
> 
>DATA   TYPE(LOGR)  
>  PCOUPLE(SYS1.LOGR.ZOS.TECH01,OSPAG2)
> ACOUPLE(SYS1.LOGR.ZOS.TECH02,OSMCAT)
> 
>When I issue command D LOGGER,CONN,SYSPLEX,LSN=*, the display does not contain 
>those
> datasets.  Does that mean nothing  is writing to them?   
 
The command you issued displays logstreams, not couple data sets.  Do you see 
any
DASD logstreams in use?   I'm assuming you do.

To display the LOGR couple data sets the command would be:
   D XCF,COUPLE,TYPE=LOGR  or D XCF,CPL,TYPE=LOGR

I would have to go back and RTFM to know for sure, but IIRC the change was for 
SMDUPLEX (support system managed duplex rebuilding of structures) which you 
would never use in a monoplex.  So no, you don't have to do it but it wouldn't 
hurt and if it were me, I would do it anyway.

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 
Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: 
http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/


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

Re: Respack Volume Size Challenge

[Ron Hawkins]

All,

It's hard to imagine that any customer is limited to specific volume size 
nowadays.

For a decade or so now all the storage vendors have delivered the ability to 
make right-sized volumes, usually only limited to what z/OS supported around 
the time the controller model was introduced.

With virtual volumes now (HDS call it HDP) creating a right-sized volume is a 
piece of cake. Being in a lab this has made life extraordinarily easy to 
provision a range of volume sizes with a couple of mouse clicks, or some 
scripts. Alternatively, with thin provisioning offered by all three vendors you 
could make your SYSRES a 3390-54 and just use the space required for the one 
pack SYSRES. If you just use 20,000 CYLs then that's all you use from the pool 
- a bit like Iceberg revisited.

Ron

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ted MacNEIL
Sent: Sunday, May 15, 2016 6:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Respack Volume Size Challenge

Years ago (pre-9) respacks had ‎to be 'split up'. Now, we ask the risk!

-teD
  Original Message
From: Lucas Rosalen
Sent: Thursday, April 21, 2016 05:14
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Respack Volume Size Challenge

As far as I have seen, it's quite simple: create a  symbol (using
 and changing last char from 1 to 2, for example) and update MCAT 
accordingly.
Once I've worked for a client that had 3-volumes respack. It indeed worked.
We used to keep datasets like LINKLIB, MACLIB, NUCLEUS, etc in 1st volumes 
though...

---
*Lucas Rosalen*
Emails: rosalen.lu...@gmail.com / *lrosa...@pl.ibm.com
*
LinkedIn: http://br.linkedin.com/in/lrosalen
Phone: +48 (71) 792 809 198


2016-04-21 10:45 GMT+02:00 Jake Anderson :

> Hello,
>
> From the z/OS 2.1, I have started using Mod-27 as the Load 
> address(Respack) for IPLing the z/OS 2.1 LPAR. I am curious how the 
> other Shops are managing when they do not options of using Mod-27 and 
> they have to survive with Mod-9. I believe the Extended Indirect cataloging 
> is one Options.
>
> What kind of challenges are there when the Respack is divided into two 
> Volumes ?
>
> Jake
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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

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

Re: LOGR Format Level

[Mark Zelden]

On Wed, 18 May 2016 14:04:59 -0400, Dazzo, Matt  wrote:

>>Started the 1.13 to 2.2 migration guide and they suggest upgrading LOGR dsn's 
>>to
>> level HBB7705, we are at HBB6603. We are a monoplex shop and probably always
>> will be. Is there any need to take this action in our environment? 


>
> Below are the dsn's defined in couplxx member.  
> 
>DATA   TYPE(LOGR)  
>  PCOUPLE(SYS1.LOGR.ZOS.TECH01,OSPAG2)
> ACOUPLE(SYS1.LOGR.ZOS.TECH02,OSMCAT)
> 
>When I issue command D LOGGER,CONN,SYSPLEX,LSN=*, the display does not contain 
>those
> datasets.  Does that mean nothing  is writing to them?   
 
The command you issued displays logstreams, not couple data sets.  Do you see 
any
DASD logstreams in use?   I'm assuming you do.

To display the LOGR couple data sets the command would be:
   D XCF,COUPLE,TYPE=LOGR  or D XCF,CPL,TYPE=LOGR

I would have to go back and RTFM to know for sure, but IIRC the change 
was for SMDUPLEX (support system managed duplex rebuilding of structures)
which you would never use in a monoplex.  So no, you don't have to do 
it but it wouldn't hurt and if it were me, I would do it anyway.

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOGR Format Level

[Dazzo, Matt]

Elardus, I do not much at all about logr . Below are the dsn's defined in 
couplxx member. 

DATA   TYPE(LOGR) 
   PCOUPLE(SYS1.LOGR.ZOS.TECH01,OSPAG2)   
   ACOUPLE(SYS1.LOGR.ZOS.TECH02,OSMCAT)   

When I issue command D LOGGER,CONN,SYSPLEX,LSN=*, the display does not contain 
those datasets.  Does that mean nothing  is writing to them?  

Thanks Matt

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Wednesday, May 18, 2016 12:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LOGR Format Level

Dazzo, Matt wrote:

>Started the 1.13 to 2.2 migration guide and they suggest upgrading LOGR dsn's 
>to level HBB7705, we are at HBB6603. We are a monoplex shop and probably 
>always will be. Is there any need to take this action in our environment?

What are you using to write to those LOGR datasets?

>The archives did contain some info but it was very old, would like some up to 
>date comments.

Probably you need to do resizing those LOGR datasets if they are small and 
updated regularly?

Groete / Greetings
Elardus Engelbrecht

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

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

Re: Questions about EZAZSSI

[Jousma, David]

We happen to start it out of commnd00

COM='S TCPZSSI,SUB=MSTR' 

//TCPZSSI  PROC P= 
//STARTVT  EXEC PGM=EZAZSSI,PARM=,TIME=1440  

Along with the IEFSSN00 entries for VMCF and TNF is what actually starts the 
process.

SUBSYS SUBNAME(TNF)/* TCPIP */ 
SUBSYS SUBNAME(VMCF)   /* TCPIP */

_
Dave Jousma
Assistant Vice President, Manager, Mainframe Engineering
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Wednesday, May 18, 2016 1:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Questions about EZAZSSI

On Wed, May 18, 2016 at 11:54 AM, Mark Yuhas < 
003e4ad82c3a-dmarc-requ...@listserv.ua.edu> wrote:

> We do not use the Pascal socket interface.  We have not had Pascal on 
> our system since about 1992-1993.
>
> We have a home grown Automated IPL procedure.  It has been in use 
> since 1995.  TCP/IP gets started much later in the procedure after TNF 
> and VMCF are started.  The IPL procedure does not issue a start for 
> TNF and VMCF.  The subsystem definitions for TNF & VMC have START(NO).  
> TNF & VMCF are started 1 minute before TCP/IP.
>
> Our TCP/IP AUTOLOG section is:
> AUTOLOG 10
> FTPD JOBNAME FTPD1; FTP Server
> IMWEBSRV  ; HTTP Server
> ;   IOASRV; OSA/SF Server
> ;   LPSERVE   ; LPD Server
> ;   NAMED ; Domain Name Server
> ;   NCPROUT   ; NCPROUTE Server
> ;   OMPROUT   ; OMPROUTE Server
> OSNMPD; SNMP Agent Server
> ;   PAGENT; Policy Agent Server
> PORTMAP   ; Portmap Server (SUN 3.9)
> ;   PORTMAP JOBNAME PORTMAP1  ; USS Portmap Server (SUN 4.0)
> ;   RXSERVE   ; Remote Execution Server
> ;   SMTP  ; SMTP Server
> TN3270E   ; Telnet Server
> ;   TCPIPX25  ; X25 Server
> ;   CIGBRSRV  ; Breeze Listener
> ENDAUTOLOG
>
> So again, I query who starts EZAZSSI?
>

​have you searched the z/OS SYSLOG/OPERLOG for where it starts? Out of 
curiosity, I just tried that on z/OS 1.12 and found it.​ Of course, I have 
about 5 years worth of SYSLOG files on my desktop Linux system. I'm a "hoarder".

--
The unfacts, did we have them, are too imprecisely few to warrant our certitude.

Maranatha! <><
John McKown

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

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


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

Re: Questions about EZAZSSI

[John McKown]

On Wed, May 18, 2016 at 11:54 AM, Mark Yuhas <
003e4ad82c3a-dmarc-requ...@listserv.ua.edu> wrote:

> We do not use the Pascal socket interface.  We have not had Pascal on our
> system since about 1992-1993.
>
> We have a home grown Automated IPL procedure.  It has been in use since
> 1995.  TCP/IP gets started much
> later in the procedure after TNF and VMCF are started.  The IPL procedure
> does not issue a start for TNF and
> VMCF.  The subsystem definitions for TNF & VMC have START(NO).  TNF & VMCF
> are started 1 minute before
> TCP/IP.
>
> Our TCP/IP AUTOLOG section is:
> AUTOLOG 10
> FTPD JOBNAME FTPD1; FTP Server
> IMWEBSRV  ; HTTP Server
> ;   IOASRV; OSA/SF Server
> ;   LPSERVE   ; LPD Server
> ;   NAMED ; Domain Name Server
> ;   NCPROUT   ; NCPROUTE Server
> ;   OMPROUT   ; OMPROUTE Server
> OSNMPD; SNMP Agent Server
> ;   PAGENT; Policy Agent Server
> PORTMAP   ; Portmap Server (SUN 3.9)
> ;   PORTMAP JOBNAME PORTMAP1  ; USS Portmap Server (SUN 4.0)
> ;   RXSERVE   ; Remote Execution Server
> ;   SMTP  ; SMTP Server
> TN3270E   ; Telnet Server
> ;   TCPIPX25  ; X25 Server
> ;   CIGBRSRV  ; Breeze Listener
> ENDAUTOLOG
>
> So again, I query who starts EZAZSSI?
>

​have you searched the z/OS SYSLOG/OPERLOG for where it starts? Out of
curiosity, I just tried that on z/OS 1.12 and found it.​ Of course, I have
about 5 years worth of SYSLOG files on my desktop Linux system. I'm a
"hoarder".

-- 
The unfacts, did we have them, are too imprecisely few to warrant our
certitude.

Maranatha! <><
John McKown

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

Re: Questions about EZAZSSI

[Burrell, C. Todd (CDC/OCOO/OCIO/ITSO) (CTR)]

Doesn't it get started in COMMND00? 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Yuhas
Sent: Wednesday, May 18, 2016 12:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Questions about EZAZSSI

We do not use the Pascal socket interface.  We have not had Pascal on our 
system since about 1992-1993.

We have a home grown Automated IPL procedure.  It has been in use since 1995.  
TCP/IP gets started much later in the procedure after TNF and VMCF are started. 
 The IPL procedure does not issue a start for TNF and VMCF.  The subsystem 
definitions for TNF & VMC have START(NO).  TNF & VMCF are started 1 minute 
before TCP/IP.

Our TCP/IP AUTOLOG section is:
AUTOLOG 10
FTPD JOBNAME FTPD1; FTP Server
IMWEBSRV  ; HTTP Server
;   IOASRV; OSA/SF Server
;   LPSERVE   ; LPD Server
;   NAMED ; Domain Name Server
;   NCPROUT   ; NCPROUTE Server
;   OMPROUT   ; OMPROUTE Server
OSNMPD; SNMP Agent Server
;   PAGENT; Policy Agent Server
PORTMAP   ; Portmap Server (SUN 3.9)
;   PORTMAP JOBNAME PORTMAP1  ; USS Portmap Server (SUN 4.0)
;   RXSERVE   ; Remote Execution Server
;   SMTP  ; SMTP Server
TN3270E   ; Telnet Server
;   TCPIPX25  ; X25 Server
;   CIGBRSRV  ; Breeze Listener
ENDAUTOLOG

So again, I query who starts EZAZSSI?


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

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

Re: Questions about EZAZSSI

[Mark Yuhas]

We do not use the Pascal socket interface.  We have not had Pascal on our 
system since about 1992-1993.

We have a home grown Automated IPL procedure.  It has been in use since 1995.  
TCP/IP gets started much
later in the procedure after TNF and VMCF are started.  The IPL procedure does 
not issue a start for TNF and
VMCF.  The subsystem definitions for TNF & VMC have START(NO).  TNF & VMCF are 
started 1 minute before
TCP/IP.

Our TCP/IP AUTOLOG section is:
AUTOLOG 10
FTPD JOBNAME FTPD1; FTP Server
IMWEBSRV  ; HTTP Server
;   IOASRV; OSA/SF Server
;   LPSERVE   ; LPD Server
;   NAMED ; Domain Name Server
;   NCPROUT   ; NCPROUTE Server
;   OMPROUT   ; OMPROUTE Server
OSNMPD; SNMP Agent Server
;   PAGENT; Policy Agent Server
PORTMAP   ; Portmap Server (SUN 3.9)
;   PORTMAP JOBNAME PORTMAP1  ; USS Portmap Server (SUN 4.0)
;   RXSERVE   ; Remote Execution Server
;   SMTP  ; SMTP Server
TN3270E   ; Telnet Server
;   TCPIPX25  ; X25 Server
;   CIGBRSRV  ; Breeze Listener
ENDAUTOLOG

So again, I query who starts EZAZSSI?


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

Re: JCL "COMMAND" statements - Follow-up question

[Paul Gilmartin]

On Wed, 18 May 2016 12:23:33 -0400, Tony Thigpen wrote:

>One other question.
>
>Is there a way to wait between multiple commands when using the TSO
>command processor?
>
>I am guessing that I will need to create a small REXX that waits based
>on a parm.
> 
could you call BPXBATCH or BPXWUNIX to issue a "sleep" command?

-- gil

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

Re: JCL "COMMAND" statements - Follow-up question

[Leonardo Vaz]

"CALL *(BPXBATCH) 'SH sleep 20' ASIS" is what I usually use

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Thigpen
Sent: Wednesday, May 18, 2016 12:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL "COMMAND" statements - Follow-up question

One other question.

Is there a way to wait between multiple commands when using the TSO command 
processor?

I am guessing that I will need to create a small REXX that waits based on a 
parm.

Tony Thigpen

Tony Thigpen wrote on 05/17/2016 08:01 AM:
> Thanks.
>
> It turns out that "OC" is part of OPS/MVS, so I now can document the job.
>
> Tony Thigpen
>
> Jeremy Nicoll wrote on 05/17/2016 07:30 AM:
>> On Tue, 17 May 2016, at 12:19, Tony Thigpen wrote:
>>> OK, dumb question time.
>>>
>>> My job is working with some JCL I found in another job:
>>> //STEP01   EXEC PGM=IKJEFT1A,REGION=0M
>>> //SYSPRINT DD SYSOUT=*
>>> //SYSTSPRT  DD SYSOUT=*
>>> //SYSTERM  DD SYSOUT=*
>>> //SYSTSOUT DD SYSOUT=*
>>> //SYSTSIN  DD *
>>>OC C('DS QD,TYPE=ALL,ONLINE')
>>> /*
>>>
>>> But, I want to look at the "OC" rexx and I can not find it in any of 
>>> the normal libraries that I have been told are used by our jobs.
>>
>> Wouldn't it be a TSO Command Processor (not a rexx exec), and thus in 
>> SYS1.CMDLIB ?
>>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>

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

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

Re: JCL "COMMAND" statements - Follow-up question

[Tony Thigpen]

One other question.

Is there a way to wait between multiple commands when using the TSO 
command processor?


I am guessing that I will need to create a small REXX that waits based 
on a parm.


Tony Thigpen

Tony Thigpen wrote on 05/17/2016 08:01 AM:

Thanks.

It turns out that "OC" is part of OPS/MVS, so I now can document the job.

Tony Thigpen

Jeremy Nicoll wrote on 05/17/2016 07:30 AM:

On Tue, 17 May 2016, at 12:19, Tony Thigpen wrote:

OK, dumb question time.

My job is working with some JCL I found in another job:
//STEP01   EXEC PGM=IKJEFT1A,REGION=0M
//SYSPRINT DD SYSOUT=*
//SYSTSPRT  DD SYSOUT=*
//SYSTERM  DD SYSOUT=*
//SYSTSOUT DD SYSOUT=*
//SYSTSIN  DD *
   OC C('DS QD,TYPE=ALL,ONLINE')
/*

But, I want to look at the "OC" rexx and I can not find it in any of the
normal libraries that I have been told are used by our jobs.


Wouldn't it be a TSO Command Processor (not a rexx exec), and thus in
SYS1.CMDLIB ?



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




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

Re: LOGR Format Level

[Elardus Engelbrecht]

Dazzo, Matt wrote:

>Started the 1.13 to 2.2 migration guide and they suggest upgrading LOGR dsn's 
>to level HBB7705, we are at HBB6603. We are a monoplex shop and probably 
>always will be. Is there any need to take this action in our environment?

What are you using to write to those LOGR datasets?

>The archives did contain some info but it was very old, would like some up to 
>date comments.

Probably you need to do resizing those LOGR datasets if they are small and 
updated regularly?

Groete / Greetings
Elardus Engelbrecht

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

LOGR Format Level

[Dazzo, Matt]

Started the 1.13 to 2.2 migration guide and they suggest upgrading LOGR dsn's 
to level HBB7705, we are at HBB6603. We are a monoplex shop and probably always 
will be. Is there any need to take this action in our environment?

The archives did contain some info but it was very old, would like some up to 
date comments.

Thanks Matt

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

Re: Old OS/390 1.3 loading in z890

[Jim Mulder]

> I´m trying to load an old OS/390 1.3 in a z890.
> 
> Since I´m ipling with loadparm cuuxxM (to get messages) I can see that 
> until it check page allocations all is going fine.
> 
> Next message is  IEA304W SYSTEM WAIT STATE CODE 80009064 DURING IEAVNP8B 

> INITIALIZATION so a disable wait code 9064 pointing to module ieavnp8b 
> and all is finished.
> 
> I found some apars saying about a commun problem about ESQA, but 
> SQA/ESQA parm in LOADxx isin´t supported in this old version. Many 
> problems is reported in google using Hercules, but I´m using a real z890 

> machine.
> 
> Same system goes up ok if I IPL it in a 9672 R36.
> 
> I know that this is a very old system, loose support before z890 comes 
> to streets, so no support is warranty from IBM.
> 
> But I´m just curiosuos if we can made this old system (31 bits) runs in 
> a 64 bits machine (z890 that is actually available).

 I don't see an IEAVNP8B in the NIP rim list for OS/390 1.3
(or any other release).  So unless you have an IEAVNP8B 
in SYS1.NUCLEUS that was supplied by some other vendor, and a zap
to IEADRIMS to invoke it, I don't see how you would be seeing
IEAVBP8B in the IEA304W message.

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY


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

Re: Privileged Users (was: EXTERNAL: Re: [EXTERNAL] Re: smp/e sha-2 support?)

[Jesse 1 Robinson]

I set up the job a couple of years ago with help from (I think) RACF-L. I did 
what was asked of me. No OMVS info was included. And no, I was not dumb enough 
to ask if they wanted that also. ;-)

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Robert S. Hansel (RSH)
Sent: Wednesday, May 18, 2016 2:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Privileged Users (was: EXTERNAL: Re: [EXTERNAL] Re: 
smp/e sha-2 support?)

Hi Skip,

OPERATIONS users actually can grant privileges because they can create dataset 
profiles for any group. And if they own a profile they create, they can permit 
access to it.

In z/OS 2.2, you will be able to replace the assignment of AUDITOR authority 
with ROAUDIT, which truly is benign because it allows a user to look at all 
profiles and SETROPTS options without changing any audit settings.

Just curious, in your 'elevated access' report, do you include users with UID 0 
or access to BPX.SUPERUSER?

Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
www.linkedin.com/in/roberthansel
http://twitter.com/RSH_RACF
www.rshconsulting.com

Upcoming RSH RACF Training
- RACF Audit & Compliance Roadmap - DEC 5-9, 2016
- RACF Level I Administration - MAY 17-20, 2016
- RACF Level II Administration - SEPT 19-23, 2016
- RACF Level III Admin, Audit, & Compliance - JUN 14-16, 2016
- Securing z/OS UNIX  - WebEx - JUL 25-29, 2016


-Original Message-
Date:Tue, 17 May 2016 16:37:50 +
From:Jesse 1 Robinson 
Subject: Re: EXTERNAL: Re: [EXTERNAL] Re: smp/e sha-2 support?

An interesting take on ADDSD. We produce a periodic report here on userids with 
'elevated access', which includes SPECIAL, OPERATIONS, and AUDITOR (the benign 
type). OPERATIONS cannot grant privileges but could do a lot of damage. I 
consider AUDITOR vital for sysprogs in order to diagnose--not necessarily 
fix--security problems at odd hours. It's been pointed out to me that AUDITOR 
allows someone to change RACF audit rules. A far-fetched but not inconceivable 
exposure. 

I think that managers here are required now and again to 'confirm' the need for 
elevated access, but no major battles have ensued within my earshot. ;-)

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Tuesday, May 17, 2016 8:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: EXTERNAL: Re: [EXTERNAL] Re: smp/e sha-2 support?

On Tue, May 17, 2016 at 9:41 AM, Mike Schwab 
wrote:

> Any ID that can grant privileges to another ID.
>

​By the above definition, _every_ id in RACF which has TSO capability is an 
administrator. How? Suppose that I am BUBBA. I log into TSO. I issue the
commands:

ADDSD MY.DATASET UACC(NONE)
PERMIT MY.DATASET ID(FRED) ACCESS(UPDATE)

I have granted priviliges to another ID, therefore I am an Admin user. I would 
really hope that what the auditor might be satisfied with would be people who 
are RACF SPECIAL or GROUP-SPECIAL. Of course, many of the z/OS sysprogs on 
​this list know how to make a joke of any security, short of encrypted data to 
which they don't have the key.


--
The unfacts, did we have them, are too imprecisely few to warrant our certitude.

Maranatha! <><
John McKown


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

Re: Product name by module

[Ed Jaffe]

On 5/18/2016 1:00 AM, Peter wrote:

One of the module shows me the below copyright but I do not see the product
name.

EIRFUCB2V1R1M0  5706-110 (C) COPYRIGHT IBM CORP. 1990 19945706-110 (C)

Is there a Link within IBM which can help me to track ?


If you search IBM's web site for product number "5706-110" (which takes 
less time than writing an email to IBM-MAIN), you will find:



THE FOLLOWING RFAs HAVE BEEN ANNOUNCED:

 1.1  RFA 20691

 1.1.1  OfficeVision/2 V1 & OS/2 Features W/D From Mktg

 IBM  OfficeVision  Family - OfficeVision/2 and OS/2 Office Features 
Withdrawal

 from Marketing and Discontinuance of Program Services

 Effective May 23,  1994,  IBM  will  withdraw  from  marketing the  
following
 programs  licensed  under  the IBM Customer Agreement.  In addition, 
effective

 September 23, 1994 program services will be discontinued.

Program Number   Program Name Version
--    ---
5706-110 IBM OfficeVision/2  1


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: What does it indicate when an SMF 30 subtype 4 or 5 has no completion section?

[Charles Mills]

Sorry. Make that "no SMF *30* record is cut."

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Barry Merrill
Sent: Wednesday, May 18, 2016 7:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What does it indicate when an SMF 30 subtype 4 or 5 has no
completion section?

Not true; there will be the JES 26 Purge Record for the job, and you can
tell it's a JCL error because the STARTIME will be missing (job never passed
to z/OS) and possibly the CONVERTERTIME will also be missing (depending on
the JCL error).

Barry
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Wednesday, May 18, 2016 9:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What does it indicate when an SMF 30 subtype 4 or 5 has no
completion section?

> 2) "Continuation record" due to "record too large conditions. I.e. due
multiple unconsolidated DD statements.

Yup. Thanks.

> 1) STEP was "flushed" due to JCL error or COND= processing.

Nope. If the job was flushed due to a JCL error no SMF record is cut. If the
step was flushed due to COND= then there is a completion section. The
indicator bit X'0100' is on and the completion and reason code fields are
zero.

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

Re: Product name by module

[Field, Alan]

In Servicelink there is a PCR (Product Cross Reference) option. Enter product 
number 5706-110.

Alan Field
Systems Engineer Principal
Blue Cross Blue Shield of MN

651.662.3546

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter
Sent: Wednesday, May 18, 2016 3:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Product name by module

Hi,

One of the module shows me the below copyright but I do not see the product 
name.

EIRFUCB2V1R1M0  5706-110 (C) COPYRIGHT IBM CORP. 1990 19945706-110 (C)

Is there a Link within IBM which can help me to track ?

On Wed, May 18, 2016 at 1:00 PM, Edward Finnell < 
000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote:

> Just to refine what Elardus has recommended. You can turn on audit in 
> RACF and see who's hitting them.
> Check PROCLIBs and SYSPROCs/SYSEXEC for occurrences. With ISRDDN check 
> to see if they're LINKLST'd or APFLST'd. In ISPF browse have the 
> option to sort on  columns. Something like 'SORT LNKED D|A' just to 
> see if they've been actively modified.
>
>
> In a message dated 5/18/2016 2:03:24 A.M. Central Daylight Time, 
> elardus.engelbre...@sita.co.za writes:
>
>
> You  can buy expensive audit software which can scan your volsers for 
> unlicensed  software.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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


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


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

Re: What does it indicate when an SMF 30 subtype 4 or 5 has no completion section?

[Barry Merrill]

Not true; there will be the JES 26 Purge Record for the job,
and you can tell it's a JCL error because the STARTIME will
be missing (job never passed to z/OS) and possibly the CONVERTERTIME
will also be missing (depending on the JCL error).

Barry
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Wednesday, May 18, 2016 9:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What does it indicate when an SMF 30 subtype 4 or 5 has no
completion section?

> 2) "Continuation record" due to "record too large conditions. I.e. due
multiple unconsolidated DD statements.

Yup. Thanks.

> 1) STEP was "flushed" due to JCL error or COND= processing.

Nope. If the job was flushed due to a JCL error no SMF record is cut. If the
step was flushed due to COND= then there is a completion section. The
indicator bit X'0100' is on and the completion and reason code fields are
zero.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Staller, Allan
Sent: Wednesday, May 18, 2016 5:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What does it indicate when an SMF 30 subtype 4 or 5 has no
completion section?

1) STEP was "flushed" due to JCL error or COND= processing.
2) "Continuation record" due to "record too large conditions. I.e. due
multiple unconsolidated DD statements.

Check the SMF manual for the gory details..

HTH,

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

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

Re: What does it indicate when an SMF 30 subtype 4 or 5 has no completion section?

[Charles Mills]

> 2) "Continuation record" due to "record too large conditions. I.e. due
multiple unconsolidated DD statements.

Yup. Thanks.

> 1) STEP was "flushed" due to JCL error or COND= processing.

Nope. If the job was flushed due to a JCL error no SMF record is cut. If the
step was flushed due to COND= then there is a completion section. The
indicator bit X'0100' is on and the completion and reason code fields are
zero.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Staller, Allan
Sent: Wednesday, May 18, 2016 5:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What does it indicate when an SMF 30 subtype 4 or 5 has no
completion section?

1) STEP was "flushed" due to JCL error or COND= processing.
2) "Continuation record" due to "record too large conditions. I.e. due
multiple unconsolidated DD statements.

Check the SMF manual for the gory details..

HTH,

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

Re: Old OS/390 1.3 loading in z890

[Vernooij, CP (ITOPT1) - KLM]

You have a waitstate 064 with reason code 009, which is:

009A program check occurred. Accompanying message IEA304W further explains this 
wait state and entry code. If the message does not appear on the console, you 
can find the message in the wait state message area (WSMA). The WSMA is 
described in z/OS MVS™ Data Areas in z/OS® Internet Library at 
http://www.ibm.com/systems/z/os/zos/bkserv/.

Does this help?
Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carlos Bodra
Sent: 18 May, 2016 15:43
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Old OS/390 1.3 loading in z890

Hello,

I´m trying to load an old OS/390 1.3 in a z890.

Since I´m ipling with loadparm cuuxxM (to get messages) I can see that 
until it check page allocations all is going fine.

Next message is  IEA304W SYSTEM WAIT STATE CODE 80009064 DURING IEAVNP8B 
INITIALIZATION so a disable wait code 9064 pointing to module ieavnp8b 
and all is finished.

I found some apars saying about a commun problem about ESQA, but 
SQA/ESQA parm in LOADxx isin´t supported in this old version. Many 
problems is reported in google using Hercules, but I´m using a real z890 
machine.

Same system goes up ok if I IPL it in a 9672 R36.

I know that this is a very old system, loose support before z890 comes 
to streets, so no support is warranty from IBM.

But I´m just curiosuos if we can made this old system (31 bits) runs in 
a 64 bits machine (z890 that is actually available).

Any comments or hints about

Thanks

-- 

CARLOS BODRA
São Paulo - SP - BRAZIL


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

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

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




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

Old OS/390 1.3 loading in z890

[Carlos Bodra]

Hello,

I´m trying to load an old OS/390 1.3 in a z890.

Since I´m ipling with loadparm cuuxxM (to get messages) I can see that 
until it check page allocations all is going fine.


Next message is  IEA304W SYSTEM WAIT STATE CODE 80009064 DURING IEAVNP8B 
INITIALIZATION so a disable wait code 9064 pointing to module ieavnp8b 
and all is finished.


I found some apars saying about a commun problem about ESQA, but 
SQA/ESQA parm in LOADxx isin´t supported in this old version. Many 
problems is reported in google using Hercules, but I´m using a real z890 
machine.


Same system goes up ok if I IPL it in a 9672 R36.

I know that this is a very old system, loose support before z890 comes 
to streets, so no support is warranty from IBM.


But I´m just curiosuos if we can made this old system (31 bits) runs in 
a 64 bits machine (z890 that is actually available).


Any comments or hints about

Thanks

--

CARLOS BODRA
São Paulo - SP - BRAZIL


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

Re: Product name by module

[Staller, Allan]

From the eye catcher below, the IBM product ID is 5706-110. 
Seaching IBM.COM show this to be part of Office Vision.

AFAIK, Office Vision has not been offered or supported for many years.

HTH,


EIRFUCB2V1R1M0  5706-110 (C) COPYRIGHT IBM CORP. 1990 19945706-110 (C)

Is there a Link within IBM which can help me to track ?


This email � including attachments � may contain confidential information. If 
you are not the intended recipient, do not copy, distribute or act on it. 
Instead, notify the sender immediately and delete the message.

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

Re: What does it indicate when an SMF 30 subtype 4 or 5 has no completion section?

[Staller, Allan]

1) STEP was "flushed" due to JCL error or COND= processing.
2) "Continuation record" due to "record too large conditions. I.e. due multiple 
unconsolidated DD statements.

Check the SMF manual for the gory details..

HTH,


>From time to time I see SMF 30 subtype 4 and 5 records with no completion 
>section. Kind of an oxymoron: a step or job completion record with no 
>completion section.

Can anyone educate me on what that would indicate? How would one "interpret"
such a record?

FWIW, I am looking at one now. Record + X'30' contains 022C 0008 -- a 
reasonable offset and the expected length but a count of zero.

Record + X'22C' is all zeros and "unused" -- the next triplet section begins at 
+X'234'.

It appears to be from an apparently normal TSO logoff. 

This is V2R1 but I have seen them on multiple releases.

This email – including attachments – may contain confidential information. If 
you are not the intended recipient, do not copy, distribute or act on it. 
Instead, notify the sender immediately and delete the message.

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

Ancient software (Re: Product name by module)

[Elardus Engelbrecht]

Radowslaw Skorupka wrote:

>Of course I can imagine an answer like "we've been running this job for 15 
>years, Frankie said it's important, but he retired 10 years ago, we don't know 
>who's currently using it, nor what is the name of the application". ;-)

It was my unpleasant task to get rid of an expensive software suite, because 
*all* are using it for many years and it is that *important*. The same as 
Radoslaw said.

Really? The original person who maintained that software went away for a better 
pay job overseas.

It was troublesome to even think of that removal story, because one of our 
clients swore high and low they are *really* using it and ALL of its connectors 
to the various database subsystems.

And they said *many* persons are using it.

I laid out a nasty trap to satisfy my bosses: 
I used RACF WARNING and turned off those connectors. Nothing happened. I told 
my boss what happened, we met up next month with the client. I showed my proof, 
only ONE person is using it and NOT those connectors.

They relented. We then moved that software to a LPAR with 1 CPU allocated. They 
complained about bad response time, etc. and eventually they used those 
database own software to collect all the data they needed.

Next month my stats showed that NO ONE actually used that expensive software 
suite.

Good. We notified the vendor that we drop them due to costs and no-one is using 
it. They missed the boat in the sense they tried to persuade us to buy a more 
EXPENSIVE suite. Tsk, tsk, tsk.

I believe many IBM-MAIN persons are sitting in the same boat. Getting rid of 
ancient legacy (I hate that fancy word!) stuff because of costs and because as 
one often said 'they're going off the mainframe'.

Groete / Greetings
Elardus Engelbrecht

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

Re: Privileged Users (was: EXTERNAL: Re: [EXTERNAL] Re: smp/e sha-2 support?)

[Elardus Engelbrecht]

Robert S. Hansel (RSH) wrote:

>OPERATIONS users actually can grant privileges because they can create dataset 
>profiles for any group. And if they own a profile they create, they can permit 
>access to it.

RACF by default will allow that OPERATIONS stunt. IRREVX01 can be used to block 
those acrobats.

I needed to block them, because 'they' created profiles causing outages. No 
Production STCs are going to use users own datasets. 

Groete / Greetings
Elardus Engelbrecht

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

Re: Product name by module

[Elardus Engelbrecht]

Vernooij, CP (ITOPT1) - KLM wrote:

>Peter has some cleanup to do: 

Indeed! Unless that thing is printing your payslips...

>In addition, effective September 23, 1994 program services will be 
>discontinued. 
> Program Number   Program Name Version 
> --    --- 
> 5706-110 IBM OfficeVision/2  1 

Wow! That's really ancient software. Did T-Rex roamed MVS/XA and MVS/ESA world 
in that time? ;-)

Groete / Greetings
Elardus Engelbrecht

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

Re: Privileged Users (was: EXTERNAL: Re: [EXTERNAL] Re: smp/e sha-2 support?)

[Robert S. Hansel (RSH)]

Hi Skip,

OPERATIONS users actually can grant privileges because they can create dataset 
profiles for any group. And if they own a profile they create, they can permit 
access to it.

In z/OS 2.2, you will be able to replace the assignment of AUDITOR authority 
with ROAUDIT, which truly is benign because it allows a user to look at all 
profiles and SETROPTS options without changing any audit settings.

Just curious, in your 'elevated access' report, do you include users with UID 0 
or access to BPX.SUPERUSER?

Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
www.linkedin.com/in/roberthansel
http://twitter.com/RSH_RACF
www.rshconsulting.com

Upcoming RSH RACF Training
- RACF Audit & Compliance Roadmap - DEC 5-9, 2016
- RACF Level I Administration - MAY 17-20, 2016
- RACF Level II Administration - SEPT 19-23, 2016
- RACF Level III Admin, Audit, & Compliance - JUN 14-16, 2016
- Securing z/OS UNIX  - WebEx - JUL 25-29, 2016


-Original Message-
Date:Tue, 17 May 2016 16:37:50 +
From:Jesse 1 Robinson 
Subject: Re: EXTERNAL: Re: [EXTERNAL] Re: smp/e sha-2 support?

An interesting take on ADDSD. We produce a periodic report here on userids with 
'elevated access', which includes SPECIAL, OPERATIONS, and AUDITOR (the benign 
type). OPERATIONS cannot grant privileges but could do a lot of damage. I 
consider AUDITOR vital for sysprogs in order to diagnose--not necessarily 
fix--security problems at odd hours. It's been pointed out to me that AUDITOR 
allows someone to change RACF audit rules. A far-fetched but not inconceivable 
exposure. 

I think that managers here are required now and again to 'confirm' the need for 
elevated access, but no major battles have ensued within my earshot. ;-)

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Tuesday, May 17, 2016 8:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: EXTERNAL: Re: [EXTERNAL] Re: smp/e sha-2 support?

On Tue, May 17, 2016 at 9:41 AM, Mike Schwab 
wrote:

> Any ID that can grant privileges to another ID.
>

​By the above definition, _every_ id in RACF which has TSO capability is an 
administrator. How? Suppose that I am BUBBA. I log into TSO. I issue the
commands:

ADDSD MY.DATASET UACC(NONE)
PERMIT MY.DATASET ID(FRED) ACCESS(UPDATE)

I have granted priviliges to another ID, therefore I am an Admin user. I would 
really hope that what the auditor might be satisfied with would be people who 
are RACF SPECIAL or GROUP-SPECIAL. Of course, many of the z/OS sysprogs on 
​this list know how to make a joke of any security, short of encrypted data to 
which they don't have the key.


--
The unfacts, did we have them, are too imprecisely few to warrant our certitude.

Maranatha! <><
John McKown

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

Re: Product name by module

[Edward Finnell]

Tied to a Display writer in the basement that only does one thing-print  
payroll checks! 
 
 
In a message dated 5/18/2016 4:09:56 A.M. Central Daylight Time,  
r.skoru...@bremultibank.com.pl writes:

Frankie  said it's important, but he retired 10 years ago, we 
don't know who's  currently using it, nor what is the name of the 
application".  ;-)


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

Re: Product name by module

[R.S.]

Wild thought:
The product is either in use or not used.
For the second case you simply delete it (of course after you're sure 
it's no longer in use)
For the first case you will see jobname, userid, some department, input, 
output - the clues who's using it, what's doing, etc.


Of course I can imagine an answer like "we've been running this job for 
15 years, Frankie said it's important, but he retired 10 years ago, we 
don't know who's currently using it, nor what is the name of the 
application". ;-)


Regards
--
Radoslaw Skorupka
Lodz, Poland






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

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

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.955.696 złotych.


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

Re: Product name by module

[Peter]

Hi,

Thank you so much. I was able to track the Product based on Program Number

On Wed, May 18, 2016 at 1:40 PM, Vernooij, CP (ITOPT1) - KLM <
kees.verno...@klm.com> wrote:

> You were just ahead of me.
> Man, Peter has some cleanup to do:
> "
> In addition, effective
>   September 23, 1994 program services will be discontinued.
>
>  Program Number   Program Name Version
>  --    ---
>  5706-110 IBM OfficeVision/2  1
> "
>
> Kees.
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lucas Rosalen
> Sent: 18 May, 2016 10:07
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Product name by module
>
> There is a link indeed, but not withing IBM: google :)
> I've found something about this product number:
>
> http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=an=ca=gpateam=899=ENUSLL94-0009
>
> Another tip is: check the strange loadlib names in your scheduling
> software's JCL lib. If you are lucky enough, there could be comments in the
> JCLs (if any uses this/these product(s)).
>
> Regards,
>
> ---
> *Lucas Rosalen*
> Emails: rosalen.lu...@gmail.com / *lrosa...@pl.ibm.com
> *
> LinkedIn: http://br.linkedin.com/in/lrosalen
> Phone: +48 (71) 792 809 198
>
>
> 2016-05-18 10:00 GMT+02:00 Peter :
>
> > Hi,
> >
> > One of the module shows me the below copyright but I do not see the
> product
> > name.
> >
> > EIRFUCB2V1R1M0  5706-110 (C) COPYRIGHT IBM CORP. 1990 19945706-110 (C)
> >
> > Is there a Link within IBM which can help me to track ?
> >
> > On Wed, May 18, 2016 at 1:00 PM, Edward Finnell <
> > 000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > > Just to refine what Elardus has recommended. You can turn on audit in
> > RACF
> > > and see who's hitting them.
> > > Check PROCLIBs and SYSPROCs/SYSEXEC for occurrences. With ISRDDN check
> to
> > > see if they're LINKLST'd or APFLST'd. In ISPF browse have the option to
> > > sort
> > > on  columns. Something like
> > > 'SORT LNKED D|A' just to see if they've been actively modified.
> > >
> > >
> > > In a message dated 5/18/2016 2:03:24 A.M. Central Daylight Time,
> > > elardus.engelbre...@sita.co.za writes:
> > >
> > >
> > > You  can buy expensive audit software which can scan your volsers for
> > > unlicensed  software.
> > >
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only. If
> you are not the addressee, you are notified that no part of the e-mail or
> any attachment may be disclosed, copied or distributed, and that any other
> action related to this e-mail or attachment is strictly prohibited, and may
> be unlawful. If you have received this e-mail by error, please notify the
> sender immediately by return e-mail, and delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> employees shall not be liable for the incorrect or incomplete transmission
> of this e-mail or any attachments, nor responsible for any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
> 
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Product name by module

[Vernooij, CP (ITOPT1) - KLM]

You were just ahead of me. 
Man, Peter has some cleanup to do:
"
In addition, effective
  September 23, 1994 program services will be discontinued.

 Program Number   Program Name Version
 --    ---
 5706-110 IBM OfficeVision/2  1
"

Kees.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lucas Rosalen
Sent: 18 May, 2016 10:07
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Product name by module

There is a link indeed, but not withing IBM: google :)
I've found something about this product number:
http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=an=ca=gpateam=899=ENUSLL94-0009

Another tip is: check the strange loadlib names in your scheduling
software's JCL lib. If you are lucky enough, there could be comments in the
JCLs (if any uses this/these product(s)).

Regards,
---
*Lucas Rosalen*
Emails: rosalen.lu...@gmail.com / *lrosa...@pl.ibm.com
*
LinkedIn: http://br.linkedin.com/in/lrosalen
Phone: +48 (71) 792 809 198


2016-05-18 10:00 GMT+02:00 Peter :

> Hi,
>
> One of the module shows me the below copyright but I do not see the product
> name.
>
> EIRFUCB2V1R1M0  5706-110 (C) COPYRIGHT IBM CORP. 1990 19945706-110 (C)
>
> Is there a Link within IBM which can help me to track ?
>
> On Wed, May 18, 2016 at 1:00 PM, Edward Finnell <
> 000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote:
>
> > Just to refine what Elardus has recommended. You can turn on audit in
> RACF
> > and see who's hitting them.
> > Check PROCLIBs and SYSPROCs/SYSEXEC for occurrences. With ISRDDN check to
> > see if they're LINKLST'd or APFLST'd. In ISPF browse have the option to
> > sort
> > on  columns. Something like
> > 'SORT LNKED D|A' just to see if they've been actively modified.
> >
> >
> > In a message dated 5/18/2016 2:03:24 A.M. Central Daylight Time,
> > elardus.engelbre...@sita.co.za writes:
> >
> >
> > You  can buy expensive audit software which can scan your volsers for
> > unlicensed  software.
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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

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




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

Re: Product name by module

[Lucas Rosalen]

There is a link indeed, but not withing IBM: google :)
I've found something about this product number:
http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=an=ca=gpateam=899=ENUSLL94-0009

Another tip is: check the strange loadlib names in your scheduling
software's JCL lib. If you are lucky enough, there could be comments in the
JCLs (if any uses this/these product(s)).

Regards,
---
*Lucas Rosalen*
Emails: rosalen.lu...@gmail.com / *lrosa...@pl.ibm.com
*
LinkedIn: http://br.linkedin.com/in/lrosalen
Phone: +48 (71) 792 809 198


2016-05-18 10:00 GMT+02:00 Peter :

> Hi,
>
> One of the module shows me the below copyright but I do not see the product
> name.
>
> EIRFUCB2V1R1M0  5706-110 (C) COPYRIGHT IBM CORP. 1990 19945706-110 (C)
>
> Is there a Link within IBM which can help me to track ?
>
> On Wed, May 18, 2016 at 1:00 PM, Edward Finnell <
> 000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote:
>
> > Just to refine what Elardus has recommended. You can turn on audit in
> RACF
> > and see who's hitting them.
> > Check PROCLIBs and SYSPROCs/SYSEXEC for occurrences. With ISRDDN check to
> > see if they're LINKLST'd or APFLST'd. In ISPF browse have the option to
> > sort
> > on  columns. Something like
> > 'SORT LNKED D|A' just to see if they've been actively modified.
> >
> >
> > In a message dated 5/18/2016 2:03:24 A.M. Central Daylight Time,
> > elardus.engelbre...@sita.co.za writes:
> >
> >
> > You  can buy expensive audit software which can scan your volsers for
> > unlicensed  software.
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Product name by module

[Peter]

Hi,

One of the module shows me the below copyright but I do not see the product
name.

EIRFUCB2V1R1M0  5706-110 (C) COPYRIGHT IBM CORP. 1990 19945706-110 (C)

Is there a Link within IBM which can help me to track ?

On Wed, May 18, 2016 at 1:00 PM, Edward Finnell <
000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote:

> Just to refine what Elardus has recommended. You can turn on audit in RACF
> and see who's hitting them.
> Check PROCLIBs and SYSPROCs/SYSEXEC for occurrences. With ISRDDN check to
> see if they're LINKLST'd or APFLST'd. In ISPF browse have the option to
> sort
> on  columns. Something like
> 'SORT LNKED D|A' just to see if they've been actively modified.
>
>
> In a message dated 5/18/2016 2:03:24 A.M. Central Daylight Time,
> elardus.engelbre...@sita.co.za writes:
>
>
> You  can buy expensive audit software which can scan your volsers for
> unlicensed  software.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Product name by module

[Edward Finnell]

Just to refine what Elardus has recommended. You can turn on audit in RACF  
and see who's hitting them.
Check PROCLIBs and SYSPROCs/SYSEXEC for occurrences. With ISRDDN check to  
see if they're LINKLST'd or APFLST'd. In ISPF browse have the option to sort 
on  columns. Something like 
'SORT LNKED D|A' just to see if they've been actively modified.
 
 
In a message dated 5/18/2016 2:03:24 A.M. Central Daylight Time,  
elardus.engelbre...@sita.co.za writes:


You  can buy expensive audit software which can scan your volsers for 
unlicensed  software.

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

Re: Product name by module

[Elardus Engelbrecht]

Peter wrote:

>Is it always possible to identify the product name by looking through the load 
>modules. 

Ed Jaffe gave you a good answer.


>Here in our shop there are some DATASET lying where we do not have any clue to 
>which product it belongs to.

Tsk, tsk, tsk. Too bad. Too sad. Use RACF to lockup those datasets. Wait until 
someone screams. [1] Until then, use SMF to check who is using what datasets.


>Any pointers or ideas to know the product name by looking through the module ?

Easy if they're from IBM. As Ed said, look at copyright statements and also 
look at eye-catchers.


>Any suggestions or ideas would help me to research further.

You can buy expensive audit software which can scan your volsers for unlicensed 
software.

Groete / Greetings
Elardus Engelbrecht

[1] - Careful with that. You may get a pavement promotion...

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