Re: SMF in logstream and IFASMFDL

[Skip Robinson]

Radoslaw,

Despite aforementioned warts, I stand by my recommendation to check this
puppy out of the pound for a trial weekend at home. Spread out newspapers,
warn domestic partners of unseemly behaviors, and settle in for some
exchange of exuberant pet breath and saliva. The shortcomings of the MANx
mantra are legion and legendary. This is a big step in a hopeful direction.




   
 "R.S."
 <[EMAIL PROTECTED] 
 LTIBANK.COM.PL>To 
 Sent by: IBM  IBM-MAIN@bama.ua.edu
 Mainframe  cc 
 Discussion List   
 <[EMAIL PROTECTED] Subject 
 .edu> Re: SMF in logstream and IFASMFDL   
   
   
 03/22/2008 09:39  
 AM
   
   
 Please respond to 
   IBM Mainframe   
  Discussion List  
 <[EMAIL PROTECTED] 
   .edu>   
   
   




Ken,
I'm aware how should I delete tunnel-type logstream datasets (by
adjusting the logstream definitions, not manual deletion of VSAM files).
However I asked about IFASMFDL role in this process.
Nevermind, thank you for the interest.

According to Skip's answer it's tunnel-type logstream and IFASMFDL is
neither aware was already offloaded nor it does delete records from
logstream.
So, my humble opinion is "no, thanks". YMMV.

Regards
--
Radoslaw Skorupka
Lodz, Poland


Kenneth E Tomiak wrote:
> The current complaints are you do not clear the logstream. A problem for
> shops that do not IPL for months on end. I have not heard of anyone
forcibly
> reming logstreams, System Logger rules!
>
>
> On Sat, 22 Mar 2008 13:13:18 +0100, R.S.
> <[EMAIL PROTECTED] could snip this!> wrote:
>
>> I'm trying to learn more about new feature: SMF in logstream instead of
>> SYS1.MANx.
>> Q: Does IFASMFDL utility clear logstream, or it is tunnel-type log
>> (deletion of oldest entries is up to logstream administrator) ?



--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego,
nr rejestru przedsibiorców KRS 025237
NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA  wynosi
118.642.672 zote i zosta w caoci wpacony.

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

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

Re: Stand alone Dump with ICC cards

[Jim Mulder]

IBM Mainframe Discussion List  wrote on 03/23/2008 
12:29:20 AM:

> I also use only the HMC for SAD support
> 
> our basic operator instructions:
> 1. logon to HMC as OPERATOR
> 2. logon to MVS Console on SYSPLEX partner system
> 3. Select SAD_sysname HMC Icon.
> 4. Perform RESET-NORMAL, Answer YES and OK.
> 5. On MVS Console, reply to IXC402D or IXC102A messages, or issue V 
> XCF,sysname,OFFLINE (reply is SYSNAME=sysname)
> 
> Actions 3-5 expedite sysplex system recovery actions.
> 
> 6. Perform ACTIVATE SAD_sysname HMC ICON, Answer Yes and OK.
> 7. Start Operating System Messages (double-click with SAD_sysname Icon 
> highlighted)
> 8. Enter a NULL command, by clicking on SEND COMMAND and then clicking 
on 
> SEND button.
> 
> 9+++ now answer SAD prompts as required.

  You can avoid step 8 by specifying 

 SCSYSC

 as the Load Parameter in the profile that you are using to
IPL SAD. 

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

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

Re: Stand alone Dump with ICC cards

[Bruce Hewson]

Hello Andy,

I also use only the HMC for SAD support

our basic operator instructions:
1. logon to HMC as OPERATOR
2. logon to MVS Console on SYSPLEX partner system
3. Select SAD_sysname HMC Icon.
4. Perform RESET-NORMAL, Answer YES and OK.
5. On MVS Console, reply to IXC402D or IXC102A messages, or issue V 
XCF,sysname,OFFLINE (reply is SYSNAME=sysname)

Actions 3-5 expedite sysplex system recovery actions.

6. Perform ACTIVATE SAD_sysname HMC ICON, Answer Yes and OK.
7. Start Operating System Messages (double-click with SAD_sysname Icon 
highlighted)
8. Enter a NULL command, by clicking on SEND COMMAND and then clicking on 
SEND button.

9+++ now answer SAD prompts as required.

Regards
Bruce Hewson

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

Re: Can forked/spawned address spaces be identified as such?

[Alan Altmark]

On Fri, 21 Mar 2008 17:20:24 -0500, Kirk Wolf <[EMAIL PROTECTED]> wrote:
>I hesitate responding to your post - its mass might otherwise tend to kill
>this thread, which IMO would be a good thing :-)

I'm with you on that point... however    ;-)

>I agree with most of what you've written.  IBM needs to transition from
>worrying about protecting z/OS source code to worrying that nobody will
>want to see it.

Having done development in the Linux kernel (for System z) and in z/VM (a 
mix of source and OCO), having source code is of limited use.  If you don't 
know *why* it works the way it does, the source is meaningless.  Over time 
you can certainly teach yourself *how*, but not *why*.

One of the most difficult problems I faced writing the original IUCV support 
for 
Linux was the complete lack of professional high-level and low-level design 
materials, not the lack of source code.  And that source code is in C, where 
the "how" is more obvious than in my native language (assembler).  It just 
didn't help.  And, sure enough, there were later changes in the 
internal "interfaces" that I unknowingly misused.   Nuances I had missed.  It 
worked, but it wasn't pretty and ultimately to be re-written.

Don't read the above as being anti-Source; it isn't, and I'm not.  I just I 
hope 
it illustrates that source code is not a panacea.  For some things it is 
necessary, but not sufficient.

>I have a different view of Peter Relson's posts - I think that he is only
>trying to explain which parts of control blocks are meant to be interfaces
>and which are not.   This distinction has no analog in modern operating
>systems, where interfaces are expressed *entirely* by APIs and service
>routines, and not by skipping through PSA->ASCB->etc.etc.

Control blocks aren't the problem.  Understanding the why's and wherefore's 
of the values in them is the problem.   They're in the same control block, so 
they have a relationship, but what is it?

I think Peter's most important point was that of stability.  The more you use 
with things the author didn't intend you to use, the more risk you add to your 
system.

I think that the clear delineation and respect for "application 
interfaces", "product-specific system interfaces", and "non-interfaces", has in 
no small part contributed to the longevity of the platform.  Compatibility is 
not 
an accident.

>In any case, I appreciate Mr. Relson's (and other IBMers) contributions to
>IBM-MAIN, even if I don't always like what they say.

Glad to hear it!  "Intelligent minds may differ."

>A sore point with me is always "submit a requirement", but that's
>another topic.

When you feel up to it, please start another thread and let's find out why.  
It's 
not the first time I've heard that.

Alan Altmark
z/VM Development (25+ years)
IBM

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

Re: SMF in logstream and IFASMFDL

[R.S.]

Ken,
I'm aware how should I delete tunnel-type logstream datasets (by 
adjusting the logstream definitions, not manual deletion of VSAM files). 
However I asked about IFASMFDL role in this process.

Nevermind, thank you for the interest.

According to Skip's answer it's tunnel-type logstream and IFASMFDL is 
neither aware was already offloaded nor it does delete records from 
logstream.

So, my humble opinion is "no, thanks". YMMV.

Regards
--
Radoslaw Skorupka
Lodz, Poland


Kenneth E Tomiak wrote:
The current complaints are you do not clear the logstream. A problem for 
shops that do not IPL for months on end. I have not heard of anyone forcibly 
reming logstreams, System Logger rules!



On Sat, 22 Mar 2008 13:13:18 +0100, R.S. 
<[EMAIL PROTECTED] could snip this!> wrote:



I'm trying to learn more about new feature: SMF in logstream instead of
SYS1.MANx.
Q: Does IFASMFDL utility clear logstream, or it is tunnel-type log
(deletion of oldest entries is up to logstream administrator) ?




--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy 
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, 
nr rejestru przedsibiorców KRS 025237

NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA  wynosi 
118.642.672 zote i zosta w caoci wpacony.

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

Re: SMF in logstream and IFASMFDL

[Skip Robinson]

At the behest of Sam Knutson and the SHARE MVSE Project, I delved into SMF
with logger in time to pull together a user pitch in Orlando: Session 2850
, where I tout virtues and expose warts, which IBM informally acknowledge
but as yet have no specific solutions to announce. The pitch includes
references to an IBM session on the subject presented first in San Diego
and repeated in Orlando. Also pointers to some manuals I consulted.

One problem I noted with managing Logger for SMF is the large amount of
DASD space that could be tied up to contain just one day's worth of data.
(System Logger retains data for a minimum of one day.) It was pointed out
to me after my session that offload data sets can be migrated. I had read
that comment in the doc but never pursued how it would work in practice.
SMF data can be offloaded as often as you choose. I wrote a Rexx that dumps
data to tape (for example) as often as once an hour. The trouble with the
Logger implementation is that dumped data is not 'marked'. The only way to
avoid dumping the same data over and over is to adjust the start/end values
in IFASMFDL. In any case, the data lives on until System Logger expires it.

Nonetheless, I believe that SMF with Logger provides enough benefit to make
it worth the exercise.

.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[EMAIL PROTECTED]


   
 Kenneth E Tomiak  
To 
 Sent by: IBM  IBM-MAIN@bama.ua.edu
 Mainframe  cc 
 Discussion List   
 <[EMAIL PROTECTED] Subject 
 .edu> Re: SMF in logstream and IFASMFDL   
   
   
 03/22/2008 07:00  
 AM
   
   
 Please respond to 
   IBM Mainframe   
  Discussion List  
 <[EMAIL PROTECTED] 
   .edu>   
   
   




The current complaints are you do not clear the logstream. A problem for
shops that do not IPL for months on end. I have not heard of anyone
forcibly
reming logstreams, System Logger rules!


On Sat, 22 Mar 2008 13:13:18 +0100, R.S.
<[EMAIL PROTECTED]> wrote:

>I'm trying to learn more about new feature: SMF in logstream instead of
>SYS1.MANx.
>Q: Does IFASMFDL utility clear logstream, or it is tunnel-type log
>(deletion of oldest entries is up to logstream administrator) ?
>
>Happy Easter
>--
>Radoslaw Skorupka
>Lodz, Poland

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

Re: Unable To Delete Archived Dataset

[Kenneth E Tomiak]

Rename would require the dataset to be recalled which is failing. The catalog 
entry is easily changed, but renaming a migrated dataset would require 
intelligence in the HSM/DMS software to update it's data about the dataset, 
which could be on tape. The tape would have to be rewritten in order to 
adjust for the possible change to the length of the DSN. A time consuming 
prospect for the ever increasing size of cartridges.

I think she should call the vendor who supports DMS and ask what to do.

On Thu, 20 Mar 2008 10:40:30 +0800, Cobe Xu <[EMAIL PROTECTED]> wrote:

>very interesting...
>
>can the dataset be renamed??
>
>

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

Re: Need MASS recall advice

[Kenneth E Tomiak]

Have the CIO key the names into the JCL. I caught you said 100,000's of files. 
So write a program to read the list and build what your solution method is. 
Either a job with IEFBR14 or if you used REXX to read the list you could issue 
the HRECALL command, not caring if it worked or not, you could use LISTDSI 
with an option to wait and then you know if it worked or not. That REXX code 
could run IKJEFT1B as a batch job so you do not tie up your TSO session.

Letting REXX submit 500+ HRECALL commands will flood HSM but you can get 
better throughput as multiple recalls from the same tape requested in the right 
sequence will just go from file to file. TSO allocate may dismount the tape 
before your next allocation, and certainly the tape will be rewinding. Try 
batching requests by the tape they are on in the sequence they are on the 
tape.

On Fri, 21 Mar 2008 17:23:09 -0500, Bruno Sugliani <[EMAIL PROTECTED]> 
wrote:

>On Fri, 21 Mar 2008 10:25:01 -0500, Rugen, Len <[EMAIL PROTECTED]> 
wrote:
>
>>Is there a faster way?  If I had a list of files they wanted, could I
>>send the recalls in tape - file sequence somehow to "batch" them?
>>
>AFAIK , you do not even need to do explicit Hrecall
>If you have the  list , you just run a BR14 and it will trigger an implicit
>hrecall .
>The list sorted by volume , in order to reduce the number of mount  should
>improve
>performance .
> Bruno
>Bruno(dot)sugliani(at)groupemornay(dot)asso(dot)fr
>

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

Re: SMF in logstream and IFASMFDL

[Kenneth E Tomiak]

The current complaints are you do not clear the logstream. A problem for 
shops that do not IPL for months on end. I have not heard of anyone forcibly 
reming logstreams, System Logger rules!


On Sat, 22 Mar 2008 13:13:18 +0100, R.S. 
<[EMAIL PROTECTED]> wrote:

>I'm trying to learn more about new feature: SMF in logstream instead of
>SYS1.MANx.
>Q: Does IFASMFDL utility clear logstream, or it is tunnel-type log
>(deletion of oldest entries is up to logstream administrator) ?
>
>Happy Easter
>--
>Radoslaw Skorupka
>Lodz, Poland

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

Re: Convert EBCDIC to ASCII in batch?

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 03/20/2008
   at 07:10 PM, Ed Finnell <[EMAIL PROTECTED]> said:

>'Fraid it's more serious these days. Had a  friend whose dad was in 
>'retirement village' after spouse passed away and was  getting ready for
>dove season by  cleaning his 12gauge and this guy kicks in  the front
>door! So he snaps the  breach and 'Says, hard to miss at this range'  so
>the guy takes off running and  made it about half way down the block
>before  dead centering the dempster  dumpster. When the county mounties
>arrived they  wanted to know how many times  he'd been shot? 'None, but
>he moved the dumpster  about eight inches with his  head...' 

Who paid for the damage to the dumpster?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

SMF in logstream and IFASMFDL

[R.S.]

I'm trying to learn more about new feature: SMF in logstream instead of 
SYS1.MANx.
Q: Does IFASMFDL utility clear logstream, or it is tunnel-type log 
(deletion of oldest entries is up to logstream administrator) ?


Happy Easter
--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sąd Rejonowy dla m. st. Warszawy 
XII Wydział Gospodarczy Krajowego Rejestru Sądowego, 
nr rejestru przedsiębiorców KRS 025237

NIP: 526-021-50-88
Według stanu na dzień 01.01.2008 r. kapitał zakładowy BRE Banku SA  wynosi 
118.642.672 złote i został w całości wpłacony.

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

James Obrizok/Poughkeepsie/IBM is out of the office.

[James Obrizok]

I will be out of the office starting  03/22/2008 and will not return until
03/25/2008.

For assistance with the System z Developer Discount offering, please
contact Fernando Vega at 1-404-238-4580. Thank you.

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