Re: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10

[Barbara Nitz]

Have to chime in on this one:

>The ONLY way to find all of the programs that make erroneous assumptions 
>about the initial contents of acquired storage is to test with the 
>IgvInitGetmain DIAG trap enabled. I repeat, it's the ONLY way! 
I agree wholeheartedly. And I am not talking about "bad" code or "bad" 
programmers. Things can get overlooked at the nth change to a program. 

>But, so far IBM has not documented that facility. IMHO, APAR OA27291
>provided an appropriate opportunity for them to do so. Unfortunately,
>that opportunity was missed. :-(
I agree wholeheartedly, too! I have done quite a bit of fighting to even be 
allowed to do the first test with the traps enabled. Common reaction was: If 
it's not documented, we cannot turn it on!

Don't know if it is due to language or due to bits, but it appears very hard 
for a sysprog to understand *why* the getmain traps are the only way to test 
and be reasonably safe. It took me a long document with detailed explanations 
and 'translations' of control block content, and after that there were still 
questions. And I am NOT patient to begin with!

>And, yet there is no DOCUMENTED or SUPPORTED way for IBM's customers to
>find and fix these erroneous programs! 
And I shudder to think that an area that wasn't cleared contains data that can 
be interpreted as numbers that are used to calculate debt, for instance. The 
program will end with cc=0, with no one the wiser. Might add to the worldwide 
financial crisis!

>We have 20+ year old programs running. How can we determine if the
>programmer coded them correctly?
Same here. A RACF exit was running for 25 years and had never caused a problem. 
In preparation for IPLing with the traps active, I had checked all our 
'usermods' (i.e. exits), and that one stood out as a) having an unbalanced 
number of getmains and freemains (why?) and b) the part with only the getmain 
just *felt* suspicious. We had decided to deinstall that exit on my gut feeling 
but my colleague forgot. The first IPL failed with about 20 dumps in that exit 
because it was accessing PSA that was now made x''. (And it has done 
that for 25+ years.)

So, I don't think there is a 'good way' to determine if things were coded 
correctly. But checking to see if every getmain has a corresponding freemain 
and every getmained area is cleared is fairly easy, in my opinion. *Then* it 
needs a closer look *why* an areas wasn't cleared (might be intentionally if 
it'S a buffer, for instance). The ultimate arbiter is the diag trap, though! 
And it makes it *a lot* easier to see that we're talking about uninitialized 
storage! Those x'FF' are really hard to miss.

>How long will this mode remain supported?
One of my arguments was the allowuserkeycsa trap.I have predicted that there 
will be a health check in the near future (say 1.11) that checks for the new 
behaviour and issues a warning. Depending on how fast user key csa is made to 
abend every time, the 1.10 behaviour will probably follow it.

Remember the 64-bit mode migration? 

>Arguably, this VSM change should have been handled more like Vsm 
>AllowUserKeyCsa was. Put out the option with default as 'no change' and 
>eventually change the default. That more deliberate approach probably 
>wouldn't have ruffled so many feathers...
Well, I don't think IBM expected so many vendors to fail. Given what Jim has 
explained before, IBM fixed part of their own bugs (but IBM System Test has 
been running with the traps on forever!). Now, did I mention that Omegamon for 
DB2 (now Tivoli-something-or-other)had three different abends, too, when we 
tested?

Oh, and the common sysprog/customer reaction will probably be the same as here: 
Why should *WE* test IBM/vendorX/vendorY code? (anyone have a good 
counterargument for that one?) Not to mention the fight that you have every 
time you report a problem caused by the traps. And before you're able to get up 
a system properly, you cannot even test your inhouse code!

Best regards, Barbara
-- 
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: 
http://www.gmx.net/de/go/multimessenger01

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

does anybody know details on this dynamic LPA detail?

[Dr. Stephen Fedtke]

hi,

does anybody know the function of this bit (dynamic LPA module handling),
and how to apply it:

+LPMEASVC EQU   X'80' This entry is an SVC. The SVC number is in  
+ LpmeaxSvcnum.   

does its usage prevent any removal, or similar.

thanks
stephen


---
Dr. Stephen Fedtke
Enterprise-IT-Security.com

Seestrasse 3a
CH-6300  Zug
Switzerland
Tel. ++41-(0)41-710-4005
www.enterprise-it-security.com


Meet you at Share to talk about current concerns: "Why do mainframe users
pay too much for even incomplete security & compliance monitoring?"
(Austin, March 1-6, 2009)

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

Re: VTAM USSTAB QUESTION

[Chris Mason]

Lizette



If REP is not coded, it takes the value of PARM. (That is, the user-entered 
parameter is used as entered.)



Chris Mason

On Mon, 9 Feb 2009 15:22:45 -0500, Lizette Koehler 
 wrote:

>Howard,
>
>I do not know if this will help, but in our USS tab we code TMON this way
>
>TMONMVS  USSCMD CMD=TMONMVS,REP=LOGON,FORMAT=BAL
> USSPARM PARM=APPLID,REP=APPLID,DEFAULT=TMONMVS
> USSCMD CMD=TMVS,REP=LOGON,FORMAT=BAL
> USSPARM PARM=APPLID,REP=APPLID,DEFAULT=TMONMVS
>
>Our USSPARM has a REP=APPLID  but I do not see one in yours.
>
>Lizette
>
>
>
>>
>>I have the following entry in my USSTAB:
>>
>>P39TMMVS USSCMD CMD=P39TMMVS,REP=LOGON,FORMAT=BAL
>> USSPARM PARM=APPLID,DEFAULT=TMONMVS
>>
>>When I key in P39TMMVS we are really getting TMONMVS as the 
executable.
>>
>>What I don't understand is what path is followed to execute TMONMVS?
>>
>>Any help will be appreciated.

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

Re: VTAM USSTAB QUESTION

[Chris Mason]

Howard

I seem to detect that you are taking an UNIX view of the world here. It is as 
if the window into which you key "P39TMMVS" were controlled by some sort of 
operating system and the command keyed mapped directly to a command 
which was one of the operating system's repertoire of commands.

It isn't like that, it's sort-of simpler and maybe also sort-of more 
complicated! 
Let us say just different!

Behind TMONMVS there is an application program, x, which is already running 
in the z/OS system - I assume of the z operating systems. It was started, 
probably using clever automation, with a z/OS START command referring to a 
stored procedure in the procedure library the JCL of which included crucially 
something like // EXEC PGM=x.

Early in its life, the program issued a call over the VTAM API involving a 
supervisor call which "opened" an application control block (ACB). The ACB 
referred to a text string which specified "TMONMVS". "TMONMVS" is the name 
of a logical unit, LU, an entity within Systems Network Architecture, SNA, 
which, together with the logical support of programming within computing 
nodes within a network of interconnected nodes, allows reliable communication 
between such an LU and another complementary LU comprising an SNA 
session.

Note that reliable - connection-oriented - communication using SNA owes 
absolutely nothing to the thoroughly unreliable - connectionless - 
communication architecture normally associated with UNIX. SNA was devised 
for business communication and was announced back in 1975. It has been 
used extensively ever since. Only recently has the thoroughly unreliable 
communication architecture normally associated with UNIX managed gradually 
to push it aside and only because of massive efforts in piling up additional 
nodes, protocols and programming to cover up the inherent deficiencies and 
because the inherent inefficiency can be masked by the relative cheapness 
of "bandwidth" - but I digress.

Presumably you are sitting at some sort of emulator entering your Unformatted 
Systems Services (USS) command. Behind that emulator may be programming 
actually supporting the LU which will become the SNA communications partner. 
Alternatively, you may be rather closer to the UNIX experience and using 
TELNET, specifically the "3270" flavour of TELNET, TN3270, more specifically, 
since you have the ability to use USS commands, TN3270E. The partner in the 
TN3270E connection will be a TN3270E server, either another program running 
under z/OS - started incidentally in all likelihood as program x was started. 
Alternatively it may be "outboard" and running in a node within the network 
where there is a change of network protocol. If a TN3270E server is being 
used it will be supporting additionally the LU which will become the SNA 
communications partner.

When you enter the "P39TMMVS" command it is sent over a session which was 
established when VTAM or, in the terminology of SNA, the System Services 
Control Point (SSCP) "activated" the LU which will become the SNA 
communications partner - actually a process comparable to that involved with 
the "opening" of the ACB mentioned earlier. The session is the SSCP-LU 
session. Note that the VTAMs involved need not be the same since we are 
dealing with an advanced set of communication protocols here!

If there is no intervening TN3270E connection, the VTAM (SSCP) which 
received the "P39TMMVS" command now refers to the USS table ideally 
implicitly[1] defined for use with the LU. In your case, there is a mapping 
of "P39TMMVS" to the USSCMD macro CMD operand - the name is typically 
the same but is, in effect, a comment in the source since it is not present in 
the object module. The USSCMD macro REP operand specifies that the 
appropriate prototype is the "LOGON" command - as opposed to the LOGOFF 
or IBMTEST - or, for VM systems, UNDIAL - commands.

The LOGON command prototype - which is, incidentally always available since, 
if the command does not map to a command defined in the USS table defined 
with the LU, the IBM-supplied USS table ISTINCDT is used - is, as Jim Wangler 
partially indicated, as follows - in an abbreviated form concentrating on the 
principle keywords:

LOGON APPLID(appl-name)DATA(logon-data)LOGMODE(logmode-entry-name)

Your USSPARM macro specifies that the default value for the APPLID keyword 
is to be "TMONMVS". Thus your command "P39TMMVS" causes a session setup 
request between the LU supported by your emulator and the application LU 
known within SNA, and happening to be supported in the z/OS node over the 
VTAM API, as "TMONMVS". The newly established LU-LU session now "takes 
over" your emulator window. There may well be a little symbol in the bottom 
left of the window which shows a "stick man" at the time you can enter the 
USS command and a solid rectangle when the LU-LU session has "taken over".

QED

You will note that you have not supplied any value for the DATA keyword nor 
the LO

Re: Assembler Question

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Ivan Warren
Sent: Monday, February 09, 2009 6:30 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Assembler Question

Gerhard Postpischil wrote:
>
> Babbage's Analytical Engine? 
>

ok.. lemme rephrase this !

Is there any package - Besides Ada Lovelace's running on Babbage machine
- that can run today on a +45 Year old machine :P


That would possibly be MVS 3.8J. I'm not sure if DOS/360 is still
available. The Hercules crowd would know about that.

I think someone still has a S/370 Basic copy of WYLBUR, but I'm not sure
about that either.

The IESRPG for OS/MVT is still available (RPG not RPGII).

Or did I miss what you are getting at still?

Regards,
Steve Thompson

-- Opinions expressed by poster may not reflect poster's employer's
opinions. --

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

Re: 1.9 and PDF's EDIT hide function

[Wilkins, Mike]

Here's a rexx edit macro that displays only recs of a member that
contain search criteria.


/* REXX **  
Title: SHOW
Usage: show searchtext

 Disc: Show only lines containing search criteria.  
   By: Mike Wilkins, Accenture. 
 Date: 12/03/2007   
  Mod: 02/09/2009 - Added HIDE option and comments. 
*/  

TRACE n 
ADDRESS ISPEXEC 

'ISREDIT MACRO (PARM1) NOPROCESS'   
"ISREDIT EX ALL"
"ISREDIT F '" || parm1 || "' ALL"   
"ISREDIT hide x"

/* Add temporary comments, so as not to PANIC users. */ 
c. = '' 
c.1  = "SHOW v1.0 - Note: No lines have been deleted - only hidden."
c.2  = "Options entered on the command line."   
c.3  = "   res - Reset member back to normal."  
c.4  = "  flip - Switch between showing search results, and, the member"
c.5  = " without the search results."   
c.6  = copies('*',133)  
c.7  = " "  
rc = Add_Comment("TOP") 

/* Position the cursor in the command line & exit. */   
exit:   
exit 1  

Add_Comment:
arg option  

do x = 15 to 1 by -1
  if length(c.x) = 0 then iterate   
  if option = "TOP" then
"ISREDIT LINE_AFTER .ZF = NOTELINE '"c.x"'" 
  if option = "BOT" then
"ISREDIT LINE_AFTER .ZL = NOTELINE '"c.x"'" 
end 
return 0




CTop:   
parse arg mytext
"ISREDIT LINE_AFTER .ZF = NOTELINE '"mytext"'"  
return 0

CBot:   
parse arg mytext
"ISREDIT LINE_AFTER .ZF = NOTELINE '"mytext"'"  
return 0


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of John Kelly
Sent: Friday, January 30, 2009 3:30 PM
To: IBM-MAIN@bama.ua.edu
Subject: 1.9 and PDF's EDIT hide function

has anyone tried the SPF edit 'hide' function on 1.9? I just brought up 
1.9 and didn't touch the panels but when i try the edit command 'hide x'
i 
get the message 'ISRE200 The edit panel has not been configured to
support 
the HIDEX command." This is the ISREDDE3 panel that comes with ServPac. 
The ServPac folks said that they don't touch any panel except ISPF folks

said to follow thew manual, ie 
To enable HIDE EXCLUDED, set the ISPF variable, &ZHIDEX, to "Y" and 
provide attribute bytes 13, 16, 17, and 1D as shown in Figure 66. 

This seems a strange thing to have to do with panels from the factory?

Jack Kelly
202-502-2390 (Office)

---

Re: Assembler Question

[Steve Comstock]

Ivan Warren wrote:

Don Russell wrote:

BAS/BASR work fine in 24 bit mode too. Stop living in the past. ;-) (Just
teasing)

Do you use the linkage information in the high byte?

  

I *HAVE* to live in the past.. S/370 to us is the only option. The
powers that be leave us no choice !

--Ivan

(If you're wondering about the cryptic message above, do not hesitate to
ask me)


Well, I'm curious. Tell me. Off-list if you prefer.



Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

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

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

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

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

Re: Assembler Question

[Paul Gilmartin]

On Mon, 9 Feb 2009 14:24:12 -0800, Don Russell wrote:
>
>That sounds like the subroutine was trying to be bi-modal, and probably used
>BSM to return. If it were called via BAL, the "addressing mode" bit in the
>return register is not reliable for determining address mode when the caller
>is in 24 bit mode. BAL sets the two high order bits of the regsiter to
>B'10', an ILC of 2. However, if the  caller were in 24 bit mode,  a BSM Rx
>would then incorrectly set the amode to 31 because the high-order bit is on.
>
>i.e. BSM may be used to return from calls via BAS, BASR, BASSM and BALR when
>the caller is in either 24 or 31 bit mode, but from BAL only if the caller
>is in 31 bit mode.
>
I did something like that in the Bad Old Days when access methods needed
to be called in 24-bit mode.  IIRC (vaguely):

Entry Code:

 STM
 BALR  0,0
 LTR   0,0
* if entered in 31-bit mode, BSM to enter 24-bit mode.
* if entered in 24-bit mode, clear the top bit of R14
* in the RSA.

Exit code:

 LM
 LTR   R14,R14
 BNMR  R14
 BSMR  R14

... runs in 24 bit mode on either architecture; never issues a
BSM to cause an instruction exception on 370.

-- gil

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

Re: Assembler Question

[Ivan Warren]

Gerhard Postpischil wrote:


Babbage's Analytical Engine? 



ok.. lemme rephrase this !

Is there any package - Besides Ada Lovelace's running on Babbage machine
- that can run today on a +45 Year old machine :P

--Ivan

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

Re: Assembler Question

[Edward Jaffe]

Ivan Warren wrote:

Edward Jaffe wrote:


I haven't coded a BALR for program linkage in decades. Up until a few 
years ago, I still used it on occasion to "sense" the current AMODE.



And I still use 'BALR' because most of my work still involves 24
AMODE/RMODE code ;)


Why not BASR? You mean you actually *want* to worry about the ILC, 
condition code and program mask in the upper byte?


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

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

Re: Assembler Question

[Gerhard Postpischil]

Ivan Warren wrote:

Please.. find *ONE* single architecture that's still capable of running
programs written 45 years ago !


Babbage's Analytical Engine? 


Gerhard Postpischil
Bradford, VT

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

Re: Assembler Question

[Ivan Warren]

Don Russell wrote:

BAS/BASR work fine in 24 bit mode too. Stop living in the past. ;-) (Just
teasing)

Do you use the linkage information in the high byte?

  

I *HAVE* to live in the past.. S/370 to us is the only option. The
powers that be leave us no choice !

--Ivan

(If you're wondering about the cryptic message above, do not hesitate to
ask me)

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

Re: Assembler Question

[Don Russell]

On Mon, Feb 9, 2009 at 3:53 PM, Ivan Warren  wrote:

>
>>  And I still use 'BALR' because most of my work still involves 24
> AMODE/RMODE code ;)
>

BAS/BASR work fine in 24 bit mode too. Stop living in the past. ;-) (Just
teasing)

Do you use the linkage information in the high byte?

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

Re: Assembler Question

[Ivan Warren]

Don Russell wrote:

Well, good luck with your SIO instructions there. ;-)

  
I said BC mode.. Never said Pre-XA ! (all I said is that a z/Arch PSW is 
no longer an EC mode PSW since the E bit in the PSW is 0 in z/Arch (lest 
you want an early Specification Exception to occur))


(However, some virtualization solutions with 370ACCOM will allow SIOs !)

--Ivan

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

Re: Assembler Question

[Don Russell]

On Mon, Feb 9, 2009 at 3:40 PM, Ivan Warren  wrote:

> Don Russell wrote:
>
>> BC mode PSWs are no longer supported, so if you are still running ACP 9 or
>> TPF 1.0 you have some old hardware indeed. ;-)
>>
>>
>>
> The fact is..
>
> A z/Arch PSW is a BC mode PSW ;) (E bit is 0 !)


Well, good luck with your SIO instructions there. ;-)

I think your argument is what might be called a "straw man". Pre-ESA the
BC/EC mode was used to change between 360 and 370 mode. 360 mode is gone
now, though I suppose some 360 applications would continue to run. But not
programs that depend on the architecture. SIO vs SSCH for example.

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

Re: Assembler Question

[Ivan Warren]

Edward Jaffe wrote:


I haven't coded a BALR for program linkage in decades. Up until a few 
years ago, I still used it on occasion to "sense" the current AMODE.



And I still use 'BALR' because most of my work still involves 24
AMODE/RMODE code ;)

--Ivan

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

Re: Assembler Question

[Edward Jaffe]

Don Russell wrote:

I agree. I'm not advocating that BAL/BALR be dropped from the instruction
set. I'm advocating that people stop using them in new/updated code.
  


IBM is scraping the bottom of the barrel looking for ways to improve 
performance. One way would be to offload processing for older, redundant 
instructions or functions to millicode.


Indeed, there was even some talk a while ago about possibly converting 
BALR (specifically the parts of it that set the upper byte in 24-bit 
mode) to millicode in order to save some System z chip "real estate".


I haven't coded a BALR for program linkage in decades. Up until a few 
years ago, I still used it on occasion to "sense" the current AMODE.


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

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

Re: Assembler Question

[Ivan Warren]

Don Russell wrote:

BC mode PSWs are no longer supported, so if you are still running ACP 9 or
TPF 1.0 you have some old hardware indeed. ;-)

  

The fact is..

A z/Arch PSW is a BC mode PSW ;) (E bit is 0 !)

--Ivan

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

Re: Here's what IBM pays an IOS developer

[Ivan Warren]

Carlos Cordero wrote:
 
I agree with that; IBM and Mainframe customers should be "really concerned" about this situation; if not; let me tell you that is the beginning of the end of a honorary ancient legacy ..
 
In other countries, almost the same situation ..
 
  

Only if we let it happen !

Remember.. They actually depend on *US* !

--Ivan

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

Re: Assembler Question

[Don Russell]

On Mon, Feb 9, 2009 at 3:23 PM, Ivan Warren  wrote:

> Hopefully..
>
> BAL/BALR will still be around.. It's been around since S/360 and it's
> here to stay.
>
> That's the power of the architecture..
>
> Please.. find *ONE* single architecture that's still capable of running
> programs written 45 years ago !
>


I agree. I'm not advocating that BAL/BALR be dropped from the instruction
set. I'm advocating that people stop using them in new/updated code.

BC mode PSWs are no longer supported, so if you are still running ACP 9 or
TPF 1.0 you have some old hardware indeed. ;-)

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

Re: Assembler Question

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Ivan Warren
Sent: Monday, February 09, 2009 5:23 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Assembler Question

Hopefully..

BAL/BALR will still be around.. It's been around since S/360 and it's
here to stay.

That's the power of the architecture..

Please.. find *ONE* single architecture that's still capable of running
programs written 45 years ago !



Discussed this very thing with a person who used to work on Burroughs
systems.

Seems that UNISYS systems that are patterned after the Burroughs
machines are able to run programs that old. Not sure about the UNIVAC
side of the house. 

Seems that the BUNCH had a common idea at some point of protecting the
investment that their clients made in software.

(BUNCH - Burroughs Univac Ncr Cdc Honeywell -- if I remember correctly).

Regards,
Steve Thompson

PS. BAS and BASR were implemented on the S/360-20. Because it only had
16 bit registers, not the full 32 of its bigger siblings.

-- Opinions posted by this poster may not be those of poster's employer.
--

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

Re: Here's what IBM pays an IOS developer

[Carlos Cordero]

 
I agree with that; IBM and Mainframe customers should be "really concerned" 
about this situation; if not; let me tell you that is the beginning of the end 
of a honorary ancient legacy ..
 
In other countries, almost the same situation ..
 
> Date: Mon, 9 Feb 2009 15:57:21 -0500> From: pinnc...@rochester.rr.com> 
> Subject: Here's what IBM pays an IOS developer> To: IBM-MAIN@bama.ua.edu> > 
> From a job posting today on NetTemps:> > CTG is in need of a PLX Programmer 
> for one of our top clients in > Poughkeepsie, NY.> Skills required:> PLX 
> Programming skills (Very important as that is what the code is written > in)> 
> OS/390 skills (MVS) Experience (Equally important as this is the operating > 
> system that the code will run under).> S390 eServer hardware and millicode 
> knowledge (Important as this is what the > code is manipulating).> 
> Architecture Verification skills- Must be able to read and interpret > 
> architecture documents, technical specs so to speak, and be able to write > 
> code (in PLX) to stress and test that architecture> Working knowledge or 
> experience with S/390 eServer Channel I/O architecture > and I/O devices (All 
> of this work deals with I/O not CPU)> > Location: Poughkeepsie, NY> Shift: 
> 1st shift, Monday-Friday> Compensation: $35/hr or $61,000 depending on 
> benefits needed)> > And IBM continues to wonder why people leave mainframes 
> in droves.> > Regards,> Tom Conley > > 
> --> For 
> IBM-MAIN subscribe / signoff / archive access instructions,> send email to 
> lists...@bama.ua.edu with the message: GET IBM-MAIN INFO> Search the archives 
> at http://bama.ua.edu/archives/ibm-main.html
_
Comparte fotos, juega y charla en Messenger.
http://download.live.com/messenger
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Assembler Question

[Ivan Warren]

Hopefully..

BAL/BALR will still be around.. It's been around since S/360 and it's
here to stay.

That's the power of the architecture..

Please.. find *ONE* single architecture that's still capable of running
programs written 45 years ago !

--Ivan

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

Re: Assembler Question

[Don Russell]

On Mon, Feb 9, 2009 at 12:38 PM, John McKown  wrote:

> On Mon, 9 Feb 2009 12:19:53 -0800, Don Russell 
> wrote:
>
> >BAL was  pretty much obsolete when IPM came into existance. Unless of
> course
> >your code had to run on an old box. I have not come across an instance yet
> >when I needed BAL, and often use OPSYN to map BAL/R to BAS/R.
> >If I REALLY need BAL/R, I'll code a  DC X'45' or DC X'05' and add a
> comment
> >saying I really, really need BAL/R here...
> >
>
> I have a very vague memory of one subroutine which was written to be
> sensitive to whether it was invoked via a BAL or a BALR instruction. It
> looked at the ILC in the "link register" and set a flag depending on
> whether
> the ILC was 1 (BALR) or 2 (BAL). Of course, it only worked in AMODE(24), so
> it not really very useful anymore.
>

That sounds like the subroutine was trying to be bi-modal, and probably used
BSM to return. If it were called via BAL, the "addressing mode" bit in the
return register is not reliable for determining address mode when the caller
is in 24 bit mode. BAL sets the two high order bits of the regsiter to
B'10', an ILC of 2. However, if the  caller were in 24 bit mode,  a BSM Rx
would then incorrectly set the amode to 31 because the high-order bit is on.

i.e. BSM may be used to return from calls via BAS, BASR, BASSM and BALR when
the caller is in either 24 or 31 bit mode, but from BAL only if the caller
is in 31 bit mode.


BAL and BALR still work in 31 bit mode, they just behave differently than in
24 bit mode. (which is one of the reasons to stop using it). If all you care
about is the address following BAL/BALR, AMODE doesn't matter. If you care
about the linkage information BAL sets in 24 bit mode, then yes, you need to
update your code to use IPM if you want it to work in 31 (or 64) bit mode.



Don

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

Re: Couple Datasets

[Skip Robinson]

OP didn't say so explicitly, but I think the problem was that his couple
data sets 'somehow' (he apparently knows how but didn't say) acquired a
*future* time stamp. If other attributes match, this mess is very difficult
to get out of. Remember back in the lat-ish 90's (if you can) when everyone
was testing the heck out of their systems, some folks got into trouble when
IPLing 'back the present' after a futuristic test. That's when the
restriction was implemented that time stamps in the couple data set had to
be the same or *older* than the current system time.  The only problem case
I've heard of recently involved DR testing; I don't think much effort is
spent these days on future-date testing.

There are some suggestions in the following APARs for how to get out of
this bind. I don't think there's any magic escape hatch. One option--IPLing
in XCFLOCAL mode--may not even work any more.

OW26853
OW38694

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


   
 Brian Peterson
IBM-MAIN@bama.ua.edu
 Sent by: IBM   cc 
 Mainframe 
 Discussion List   Subject 
  
   
   
 02/09/2009 10:21  
 AM
   
   
 Please respond to 
   IBM Mainframe   
  Discussion List  

   
   




I think the trick is to bring up an LPAR in the sysplex which was not the
last LPAR shut down in the sysplex.

For example, say you have three LPARs in your sysplex, L1, L2 and L3.

Shut down the L1 and L2 LPARs, using the V XCF,name,OFFLINE command.

Then shut down L3.

Now fix the clock.

Now, once the clock is fixed, IPL either L1 or L2 first.  Early in the IPL,
I think you will get message IXC405D - reply I to "initialize" the sysplex.

-=-=-=-=-
Operator Response:  Choose one of the following replies:

I
To request that sysplex initialization continue because none of the
systems identified in message IXC404I are in fact participating in an
operating sysplex, that is, they are all residual systems. This system
will perform cleanup of old sysplex data, initialize the couple data
set, and start a "new" sysplex. If any of the systems identified in
message IXC404I are currently active in the sysplex, they will be
placed into a disabled wait state.
-=-=-=-=-

We have a sysplex timer so our GMT time always increases, so I have not
tried this myself.

Brian

On Mon, 9 Feb 2009 10:59:09 -0600, Mark Steely wrote:

>We are z/OS V1R9. I won't go into the sequence of events that happen
>this weekend, but we had a problem with the timestamp in the couple
>datasets and the system time mismatch ( we know how that happen) and we
>had to wait until the system time bypassed the the time in the couple
>datasets for the IPL to continue. Is there a way to reset (without
>rebuilding the datasets)  the couple datasets our tell the system to
>ignore the timestamp in the couple datasets.
>
>Any help would be appreciated.
>
>Thank You

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

Re: APAR OA25205 - SMF 42 for member add/del/rename

[Bob Rutledge]

The APAR is OA25688.

Bob

Bob Rutledge wrote:
The PTF for that APAR breaks macro IGWSMF, at least in HDZ1190.  We have 
a PMR open and fixing APAR has been promised.


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

Here's what IBM pays an IOS developer

[Pinnacle]

From a job posting today on NetTemps:


CTG is in need of a PLX Programmer for one of our top clients in 
Poughkeepsie, NY.

Skills required:
PLX Programming skills (Very important as that is what the code is written 
in)
OS/390 skills (MVS) Experience (Equally important as this is the operating 
system that the code will run under).
S390 eServer hardware and millicode knowledge (Important as this is what the 
code is manipulating).
Architecture Verification skills- Must be able to read and interpret 
architecture documents, technical specs so to speak, and be able to write 
code (in PLX) to stress and test that architecture
Working knowledge or experience with S/390 eServer Channel I/O architecture 
and I/O devices (All of this work deals with I/O not CPU)


Location: Poughkeepsie, NY
Shift: 1st shift, Monday-Friday
Compensation: $35/hr or $61,000 depending on benefits needed)

And IBM continues to wonder why people leave mainframes in droves.

Regards,
Tom Conley 


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

Re: Here's what IBM pays an IOS developer

[Jim Phoenix]

C'mon Tom,

You posted this same item on 3/26/2006 with the following line not 
included below:

Duration: Until 12/31/05 w/ possibility of extension

It was clearly old news then, and it is even older news today.

Pinnacle wrote:
CTG is in need of a PLX Programmer for one of our top clients in 
Poughkeepsie, NY.

Skills required:
PLX Programming skills (Very important as that is what the code is 
written in)
OS/390 skills (MVS) Experience (Equally important as this is the 
operating system that the code will run under).
S390 eServer hardware and millicode knowledge (Important as this is 
what the code is manipulating).
Architecture Verification skills- Must be able to read and interpret 
architecture documents, technical specs so to speak, and be able to 
write code (in PLX) to stress and test that architecture
Working knowledge or experience with S/390 eServer Channel I/O 
architecture and I/O devices (All of this work deals with I/O not CPU)


Location: Poughkeepsie, NY
Shift: 1st shift, Monday-Friday
Compensation: $35/hr or $61,000 depending on benefits needed)



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

Re: Here's what IBM pays an IOS developer

[Stephen McColley]

On Monday 09 February 2009 03:57:21 pm Pinnacle wrote:

That's probably a good wage for Bolivia, or Argentina, or wherever they 
are 'offshoring' to these days.  They also know they just layed off a ton of 
folks and hope someone will bite.

Stephen McColley
sgmccol...@alletl.net
(just my opinion)

> From a job posting today on NetTemps:
>
> CTG is in need of a PLX Programmer for one of our top clients in
> Poughkeepsie, NY.
> Skills required:
( .   .   .   )
>
> And IBM continues to wonder why people leave mainframes in droves.
>
> Regards,
> Tom Conley
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Assembler Question

[Don Russell]

BAL was  pretty much obsolete when IPM came into existance. Unless of course
your code had to run on an old box. I have not come across an instance yet
when I needed BAL, and often use OPSYN to map BAL/R to BAS/R.
If I REALLY need BAL/R, I'll code a  DC X'45' or DC X'05' and add a comment
saying I really, really need BAL/R here...

I would also opt for the immiediate-type instructions instead of referencing
separate storage locations...

i.e. LHI R5,L'BUFFER
or LHI R6,-2

They're faster because they don't require additional memory fetches...  and
they're "nicer" because if you look at a dump or object code, you can see
the operand right in the instruction. In many cases their use eliminates
literals.

I favor the branch-relative instructions (Jxxx mnemonics) where possible to
reduce base register needs (sometimes) and, I suppose they're faster because
they simply add the displacement to the currect PSW without all that adding,
checking if index or base reg are zero etc.


Don



On Fri, Feb 6, 2009 at 9:43 AM, Ward, Mike S  wrote:

> Hello, all I have a question. I was just looking through the principle
> of ops guide on an instruction I had a question on and noticed a BAS
> instruction. I started reading about it and noticed that it said we
> should use the BAS, BASR type of instructions instead of the BAL and
> BALR types. I won't bore you with the details. My question is: Is there
> a list of recommended instructions that we should be using instead of
> the old instructions we had been using?
>
> ==
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity
> to which they are addressed. If you have received this email in error
> please notify the system manager. This message
> contains confidential information and is intended only for the individual
> named. If you are not the named addressee you
> should not disseminate, distribute or copy this e-mail. Please notify the
> sender immediately by e-mail if you
> have received this e-mail by mistake and delete this e-mail from your
> system. If you are not the intended recipient
> you are notified that disclosing, copying, distributing or taking any
> action in reliance on the contents of this
> information is strictly prohibited.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PROGxx, linklist, LLA and fetch performance

[Scott Rowe]

The libraries are not currently in LLA, it is on my list of things to do, but 
it is not near the top.  The benefit is not huge in our case.
 
The updating of the aliases is very minor, it takes the DBA less than a minute 
as part of his upgrade.
 
Our use of aliases is far more time efficient for us than any suggestion you 
have made would be.
 
It may be your right to disagree, but I don't really don't think you should 
make general statements like "DB2 should always be in linklist".  Situations 
differ.  Heck, I could go your statement one step farther and ask why you 
didn't have DB2 in LPA, that would be even more efficient, if you are only 
running one level of DB2 per system.  With our having 16 DB2s on one LPAR, LPA 
would be my choice, if they were often at the same maintenance level.  That 
would save me many megabytes of central storage.
I really don't care how many LPARs you ran, that is irrelevant.  How many DB2s 
do you run on a single LPAR?  That's where it becomes difficult to manage 
keeping DB2 in linklist or LPA.  I simply don't have the time to spend on the 
level of "coordination" you are talking about.  Neither am I interested in 
changing my linklist concatenation that often.  This way the DBAs are free to 
perform maintenance as they see fit, without my having to perform functions 
like updating the current linklist for them.
 
I did not say we have multiple releases all the time, but we often have 
different maintenance levels.
 
The point I am trying to make is that you should not think that your limited 
experience is applicable to all environments.  You recently made some rather 
vitriolic statements about Ed, and I, for one, find some of your statements far 
less useful than his.
 
There are very few situations in our area of expertise where "always" and 
"never" are applicable.  Every shop is different, and different solutions are 
appropriate.  Telling someone that the way they are doing this is "wrong" is 
not very productive.  I have worked at quite a few shops in the last 30 years, 
and rarely have I found that the same solutions are appropriate at all of them.

>>> Ted MacNEIL  2/9/2009 2:25 PM >>>
>We just keep them out of linklist and use catalog aliases for everything.

I hope you at least have the libraries in LLA.

>The DBAs update the aliases when the do maintenance/upgrades.

Again, with the cost of a DBA (or a SYSPROG), is this practical.
Not criticising -- just asking.
We didn't find it so, and it's no more difference than the 'simple' suggestion 
I made.


>There is almost always more than one level of DB2 target libraries in use at 
>any one time, so there is really no sense in trying to put one in the linklist.

I disagree. But, that is my right.


>With 22 DB2 instances on two LPARs, it just isn't practical. 

Again, I disagree.
We had 19 LPARs across two sites, GDPS, data propagator, multiple IMS/CICS/DB2 
PLEXes, and we found a practical solution.
It just required co-ordination, and a will to do it.

Why did you have multiple releases all the time?
There has to be some period of stability.

But, YMMV!

-
Too busy driving to stop for gas!

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


CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains 
confidential and privileged information intended only for the addressee.  If 
you are not the intended recipient, please be advised that you have received 
this material in error and that any forwarding, copying, printing, 
distribution, use or disclosure of the material is strictly prohibited.  If you 
have received this material in error, please (i) do not read it, (ii) reply to 
the sender that you received the message in error, and (iii) erase or destroy 
the material. Emails are not secure and can be intercepted, amended, lost or 
destroyed, or contain viruses. You are deemed to have accepted these risks if 
you communicate with us by email. Thank you.

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

Workload Reports

[Luiz Paulo Telles]

Hi,

I'm looking for a program or tool to help me generate a report to show the use 
of service units for each service class for a period (monthly for example). Any 
suggestion ? 

Thanks 




 

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

Re: VTAM USSTAB QUESTION

[Lizette Koehler]

Howard,

I do not know if this will help, but in our USS tab we code TMON this way

TMONMVS  USSCMD CMD=TMONMVS,REP=LOGON,FORMAT=BAL   
 USSPARM PARM=APPLID,REP=APPLID,DEFAULT=TMONMVS
 USSCMD CMD=TMVS,REP=LOGON,FORMAT=BAL  
 USSPARM PARM=APPLID,REP=APPLID,DEFAULT=TMONMVS

Our USSPARM has a REP=APPLID  but I do not see one in yours.

Lizette



>
>I have the following entry in my USSTAB:
> 
>P39TMMVS USSCMD CMD=P39TMMVS,REP=LOGON,FORMAT=BAL
> USSPARM PARM=APPLID,DEFAULT=TMONMVS 
> 
>When I key in P39TMMVS we are really getting TMONMVS as the executable.
> 
>What I don't understand is what path is followed to execute TMONMVS?
> 
>Any help will be appreciated.
> 
>

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

Re: Workload Reports

[Staller, Allan]

RMF post processor: SYSRPTS(WLMGL(SCLASS,SCPER)). Vary the amount of
input data as required.

Also the RMF Spreadsheet Reporter

http://www-03.ibm.com/servers/eserver/zseries/zos/rmf/tools/#spr_win



I'm looking for a program or tool to help me generate a report to show
the use 
of service units for each service class for a period (monthly for
example). Any 
suggestion ? 


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

Re: Assembler Question

[John McKown]

On Mon, 9 Feb 2009 12:19:53 -0800, Don Russell  wrote:

>BAL was  pretty much obsolete when IPM came into existance. Unless of course
>your code had to run on an old box. I have not come across an instance yet
>when I needed BAL, and often use OPSYN to map BAL/R to BAS/R.
>If I REALLY need BAL/R, I'll code a  DC X'45' or DC X'05' and add a comment
>saying I really, really need BAL/R here...
>

I have a very vague memory of one subroutine which was written to be
sensitive to whether it was invoked via a BAL or a BALR instruction. It
looked at the ILC in the "link register" and set a flag depending on whether
the ILC was 1 (BALR) or 2 (BAL). Of course, it only worked in AMODE(24), so
it not really very useful anymore.

--
John

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

Re: VTAM USSTAB QUESTION

[Jim Wangler]

LOGON APPLID(TMONMVS)  


Jim Wangler 
214-502-6445
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Howard Rifkind
Sent: Monday, February 09, 2009 1:48 PM
To: IBM-MAIN@bama.ua.edu
Subject: VTAM USSTAB QUESTION

I have the following entry in my USSTAB:
 
P39TMMVS USSCMD CMD=P39TMMVS,REP=LOGON,FORMAT=BAL
 USSPARM PARM=APPLID,DEFAULT=TMONMVS 
 
When I key in P39TMMVS we are really getting TMONMVS as the executable.
 
What I don't understand is what path is followed to execute TMONMVS?
 
Any help will be appreciated.
 
T.Y.
_
LEGAL NOTICE
Unless expressly stated otherwise, this message is confidential and may be
privileged. It is intended for the addressee(s) only.
Access to this E-mail by anyone else is unauthorized.
If you are not an addressee, any disclosure or copying of the contents of
this E-mail or any action taken (or not taken) in reliance on it is
unauthorized and may be unlawful. If you are not an addressee, please inform
the sender immediately, then delete this message and empty from your trash.


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: VTAM USSTAB QUESTION

[Pommier, Rex R.]

>From what I remember from long ago is that the USSCMD replaces your
keyed-in P39TMMVF with a LOGON APPLID(TMONMVS) which is what VTAM
actually uses to log you on.  For further information, check the SNA
resource definition reference manual.  There is a section on USSTAB that
(kinda) explains the parameters.  :-)

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Howard Rifkind
Sent: Monday, February 09, 2009 1:48 PM
To: IBM-MAIN@bama.ua.edu
Subject: VTAM USSTAB QUESTION

I have the following entry in my USSTAB:
 
P39TMMVS USSCMD CMD=P39TMMVS,REP=LOGON,FORMAT=BAL
 USSPARM PARM=APPLID,DEFAULT=TMONMVS 
 
When I key in P39TMMVS we are really getting TMONMVS as the executable.
 
What I don't understand is what path is followed to execute TMONMVS?
 
Any help will be appreciated.
 
T.Y.

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

VTAM USSTAB QUESTION

[Howard Rifkind]

I have the following entry in my USSTAB:
 
P39TMMVS USSCMD CMD=P39TMMVS,REP=LOGON,FORMAT=BAL
 USSPARM PARM=APPLID,DEFAULT=TMONMVS 
 
When I key in P39TMMVS we are really getting TMONMVS as the executable.
 
What I don't understand is what path is followed to execute TMONMVS?
 
Any help will be appreciated.
 
T.Y.
_
LEGAL NOTICE
Unless expressly stated otherwise, this message is confidential
and may be privileged. It is intended for the addressee(s) only.
Access to this E-mail by anyone else is unauthorized.
If you are not an addressee, any disclosure or copying of the
contents of this E-mail or any action taken (or not taken) in
reliance on it is unauthorized and may be unlawful. If you are not an
addressee, please inform the sender immediately, then delete this
message and empty from your trash.


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

Re: PROGxx, linklist, LLA and fetch performance

[Ted MacNEIL]

>We just keep them out of linklist and use catalog aliases for everything.

I hope you at least have the libraries in LLA.

>The DBAs update the aliases when the do maintenance/upgrades.

Again, with the cost of a DBA (or a SYSPROG), is this practical.
Not criticising -- just asking.
We didn't find it so, and it's no more difference than the 'simple' suggestion 
I made.


>There is almost always more than one level of DB2 target libraries in use at 
>any one time, so there is really no sense in trying to put one in the linklist.

I disagree. But, that is my right.


>With 22 DB2 instances on two LPARs, it just isn't practical. 

Again, I disagree.
We had 19 LPARs across two sites, GDPS, data propagator, multiple IMS/CICS/DB2 
PLEXes, and we found a practical solution.
It just required co-ordination, and a will to do it.

Why did you have multiple releases all the time?
There has to be some period of stability.

But, YMMV!

-
Too busy driving to stop for gas!

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

Re: Extracting in-stream dataset (i.e. SYSIN) from SMF

[Hardee, Charles H]

Sorry everyone, this got sent to the wrong place.

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Hardee, Charles H
Sent: Monday, February 09, 2009 1:20 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Extracting in-stream dataset (i.e. SYSIN) from SMF

I haven't done CICS in ages, and I mean ages. 
So, if IDMSINTC is something we deliver and link via SMP/E, then I
suspect the fix I have may come into play here.
However, if the client assembles something and then links it together,
if we document a suggested link edit process, we need to make sure the
link edit process is correct and that the client has it linked correctly
as well.

Now, all that being said, the ultimate question is, "Who is loading the
program?" If loaded by the z/OS loader, then REENT, REUSE and REFR are
all honored and a module will be loaded into key-0 non-fetch protected
storage. However, if CICS is loading the module, does CICS issue an
Op/Sys load or load it on its own, like CV does?

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Walt Farrell
Sent: Monday, February 09, 2009 1:07 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Extracting in-stream dataset (i.e. SYSIN) from SMF

On Mon, 9 Feb 2009 16:27:51 +0100, Ferran Perxas 
wrote:

>In some cases, the developers dynamically build JCL and they submit
those
>via intrdr from CICS (super "fat-batch-running" transactions), my
client
>wants to keep this up and working, but i want to know which programs
are run
>in my productive environement. Or in this case "were" run.

The obvious place for you to capture the instream data is in whatever
process the developers use to build and then submit the jobs from CICS. 
Presumably they're using some transaction to do that.  Have it save a
copy
somewhere for you to examine later.  Or have it examine the job for the
things you want and just log that data.

-- 
  Walt

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Extracting in-stream dataset (i.e. SYSIN) from SMF

[Hardee, Charles H]

I haven't done CICS in ages, and I mean ages. 
So, if IDMSINTC is something we deliver and link via SMP/E, then I
suspect the fix I have may come into play here.
However, if the client assembles something and then links it together,
if we document a suggested link edit process, we need to make sure the
link edit process is correct and that the client has it linked correctly
as well.

Now, all that being said, the ultimate question is, "Who is loading the
program?" If loaded by the z/OS loader, then REENT, REUSE and REFR are
all honored and a module will be loaded into key-0 non-fetch protected
storage. However, if CICS is loading the module, does CICS issue an
Op/Sys load or load it on its own, like CV does?

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Walt Farrell
Sent: Monday, February 09, 2009 1:07 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Extracting in-stream dataset (i.e. SYSIN) from SMF

On Mon, 9 Feb 2009 16:27:51 +0100, Ferran Perxas 
wrote:

>In some cases, the developers dynamically build JCL and they submit
those
>via intrdr from CICS (super "fat-batch-running" transactions), my
client
>wants to keep this up and working, but i want to know which programs
are run
>in my productive environement. Or in this case "were" run.

The obvious place for you to capture the instream data is in whatever
process the developers use to build and then submit the jobs from CICS. 
Presumably they're using some transaction to do that.  Have it save a
copy
somewhere for you to examine later.  Or have it examine the job for the
things you want and just log that data.

-- 
  Walt

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PROGxx, linklist, LLA and fetch performance

[Scott Rowe]

We just keep them out of linklist and use catalog aliases for everything.  The 
DBAs update the aliases when the do maintenance/upgrades.  There is almost 
always more than one level of DB2 target libraries in use at any one time, so 
there is really no sense in trying to put one in the linklist.  With 22 DB2 
instances on two LPARs, it just isn't practical. 

>>> Ted MacNEIL  2/9/2009 12:48 PM >>>
>Considering the micro-economics of sysprog time, the scenario described above 
>requires I add and delete steplibs in every started task and programmer jcl in 
>every migration, and handle linklist too.   

1. Let the programmer handle it.
2. For started tasks:

a. Create a special INCLUDE member, somewhere:
   // SET DB2AVER=NIL
   // SET DB2BVER=R9
   // etc...
b. In the PROC
 // INCLUDE include member
 // other JCL statements
 // pseudo-code, because it's been awhile
 // if &db2aver<>NIL then
 //STEPLIB DD DISP=SHR,DSN=DB2.&db2aver..DSNLOAD
 // endif

You get the idea.

-
Too busy driving to stop for gas!

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


CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains 
confidential and privileged information intended only for the addressee.  If 
you are not the intended recipient, please be advised that you have received 
this material in error and that any forwarding, copying, printing, 
distribution, use or disclosure of the material is strictly prohibited.  If you 
have received this material in error, please (i) do not read it, (ii) reply to 
the sender that you received the message in error, and (iii) erase or destroy 
the material. Emails are not secure and can be intercepted, amended, lost or 
destroyed, or contain viruses. You are deemed to have accepted these risks if 
you communicate with us by email. Thank you.

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

Re: Extracting in-stream dataset (i.e. SYSIN) from SMF

[Walt Farrell]

On Mon, 9 Feb 2009 16:27:51 +0100, Ferran Perxas  wrote:

>In some cases, the developers dynamically build JCL and they submit those
>via intrdr from CICS (super "fat-batch-running" transactions), my client
>wants to keep this up and working, but i want to know which programs are run
>in my productive environement. Or in this case "were" run.

The obvious place for you to capture the instream data is in whatever
process the developers use to build and then submit the jobs from CICS. 
Presumably they're using some transaction to do that.  Have it save a copy
somewhere for you to examine later.  Or have it examine the job for the
things you want and just log that data.

-- 
  Walt

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

Re: GMT time

[Tom Marchant]

On Mon, 9 Feb 2009 11:37:50 -0600, Rick Fochtman wrote:

>
>
>Paul Gilmartin wrote:
>
>>Ah, I see.  Then an IPL is necessary to adjust the clock.
>>Usually undesirable.
>>
>--
>Makes me wish for the return of the Sysplex Timer. :-)

See the TOD-Clock-Steering Facility and the PTFF instruction.  Also note
that the Server-Time-Protocol Facility uses this to make adjustments to the
TOD clock.

-- 
Tom Marchant

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

Re: Moving DB2 Partition Datasets with DFDSS

[Wayne Driscoll]

As long as the tablespace (or at least the partition in question) is 
STOPPED to DB2, you should be able to use DSS to run a 
backup/delete/restore.  Remember that while DB2 sees the 6 datasets 
(partitions) as a single entity, to DSS (and all of DFP for that matter), 
it is six individual VSAM linear datasets.

===
Wayne Driscoll
Omegamon DB2 L3 Support/Development
wdrisco(AT)us.ibm.com
===



Lizette Koehler  
Sent by: IBM Mainframe Discussion List 
02/09/2009 12:40 PM
Please respond to
IBM Mainframe Discussion List 


To
IBM-MAIN@bama.ua.edu
cc

Subject
Moving DB2 Partition Datasets with DFDSS






I have not worked with this particular issue in awhile.  So I am looking 
for some pointers.

I have a DB2 Partitioned Table space where one of the pieces is on a wrong 
volume.  I need to move it to a better home.

What I need to know is the best, and fastest way to do this.

The DB2 TS part is 6th in the partition.  It is a 6000 cylinder data set, 
and part 6 is spread across 6 different volumes in my pool.  I need to 
move one of those pieces from VOLS01 to VOLSX1.

Can I move just the one part or is it better to backup the whole part 6, 
delete and then use DFDSS to restore it back to the pool?  My DBA says no 
one is using that table right now, so I can do what I need.

Typically I would backup it up to tape (the whole thing), delete it, and 
then restore from the backup tape.  I just do not know if that is the best 
way to do it for a DB2 partition or if there is a better way.   The DBAs 
have indicated it will take too long to do a reorg on the table itself.

Lizette

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Moving DB2 Partition Datasets with DFDSS

[Lizette Koehler]

I have not worked with this particular issue in awhile.  So I am looking for 
some pointers.

I have a DB2 Partitioned Table space where one of the pieces is on a wrong 
volume.  I need to move it to a better home.

What I need to know is the best, and fastest way to do this.

The DB2 TS part is 6th in the partition.  It is a 6000 cylinder data set, and 
part 6 is spread across 6 different volumes in my pool.  I need to move one of 
those pieces from VOLS01 to VOLSX1.

Can I move just the one part or is it better to backup the whole part 6, delete 
and then use DFDSS to restore it back to the pool?  My DBA says no one is using 
that table right now, so I can do what I need.

Typically I would backup it up to tape (the whole thing), delete it, and then 
restore from the backup tape.  I just do not know if that is the best way to do 
it for a DB2 partition or if there is a better way.   The DBAs have indicated 
it will take too long to do a reorg on the table itself.

Lizette

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

Re: Extracting in-stream dataset (i.e. SYSIN) from SMF

[Al Cole]

Can you search your JCL, PROC and source code for the ' call to an 
assemble(Software AG) '.

This should be a fixed reference in your JCL , proc , programs or wherever..


Alfred Cole
BJC HealthCare
mailstop 92-92-117
8374 Eager Road Suite 200
St Louis, MO 63144

(314) 362-7837
ahc5...@bjc.org



>>> "Scott Barry"  02/09/2009 11:55 AM >>>
On Mon, 9 Feb 2009 16:27:51 +0100, Ferran Perxas  wrote:

>Hi all,
>
>Thanks for all your answers. I'll explain the whole problem so we can focus
>the questions/answers.
>Here, in the site i'm working, the developement team works with Natural. The
>way they use to invoke these programs is via a call to an assembler
>(Software AG) with the PGM Natural to execute, written on the SYSIN
>statement.
>
>In some cases, the developers dynamically build JCL and they submit those
>via intrdr from CICS (super "fat-batch-running" transactions), my client
>wants to keep this up and working, but i want to know which programs are run
>in my productive environement. Or in this case "were" run.
>
>Because of your answers i can understand that is way impossible for me to
>obtain the information submited long ago. But, does anyone have an example
>of a userexit that can help me catch this information and direct it to some
>kind of log (i.e. not used SMF-record)?
>
>Thanks all,
>
>Ferran.
>
>
>On Mon, Feb 9, 2009 at 3:29 PM, David Logan  wrote:
>
>> Yep. If you wanted to log it, you would have to log it manually through an
>> exit, like in CI or something. Seems a bit weird to me, but you could do
>> it.
>>
>> David Logan
>> Manager of Product Development, Pitney Bowes Business Insight
>> http://centrus.com 
>> W: (720) 564-3056
>> C: (303) 818-8222
>>
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
>> Behalf
>> Of Ed Finnell
>> Sent: Monday, February 09, 2009 07:09
>> To: IBM-MAIN@bama.ua.edu 
>> Subject: Re: Extracting in-stream dataset (i.e. SYSIN) from SMF
>>
>>
>> In a message dated 2/9/2009 6:58:14 A.M. Central Standard Time,
>> lordbis...@gmail.com writes:
>>
>> belive that the info may be logged in other places than SMF, but i  don't
>> know where to start searching.
>>
>>
>> >>
>> If it is SYSIN DD * it is only kept on SPOOL.  If you have shop standards
>> that require SYSIN DD DSN=cntl_file you could have  a possibility with
>> jobnames
>> and  OPEN/CLOSE or RACF(or equivalent) facilities.
>>
>>
>>
>>
>> **A Good Credit Score is 700 or Above. See yours in just 2 easy
>> steps!
>> (
>> http://pr.atwola.com/promoclk/10075x1218550342x1201216770/aol?redir=htt 
>> p://
>> www.freecreditreport.com/pm/default.aspx?sc=668072%26hmpgID=62%26bcd=fe 
>>
bemailfooterNO62
>> )
>>


catch this information


How would you know what job(s) to "catch" - maybe by the "called" program? 
I would be more concerned that you have instream data programs being
executed in production mode, uncontrolled, possibly submitted by developers,
if I am understanding the circumstances.  When a job is purged from the
spool (SMF type 26 execution purge node), the job's SYSIN data is also
purged.  No chance for auditing or post-execution code review.

Scott Barry
SBBWorks, Inc.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Couple Datasets

[Brian Peterson]

I think the trick is to bring up an LPAR in the sysplex which was not the
last LPAR shut down in the sysplex.

For example, say you have three LPARs in your sysplex, L1, L2 and L3.

Shut down the L1 and L2 LPARs, using the V XCF,name,OFFLINE command.

Then shut down L3.

Now fix the clock.

Now, once the clock is fixed, IPL either L1 or L2 first.  Early in the IPL,
I think you will get message IXC405D - reply I to "initialize" the sysplex.

-=-=-=-=-
Operator Response:  Choose one of the following replies:  
  
I 
To request that sysplex initialization continue because none of the   
systems identified in message IXC404I are in fact participating in an 
operating sysplex, that is, they are all residual systems. This system
will perform cleanup of old sysplex data, initialize the couple data  
set, and start a "new" sysplex. If any of the systems identified in   
message IXC404I are currently active in the sysplex, they will be 
placed into a disabled wait state.
-=-=-=-=-

We have a sysplex timer so our GMT time always increases, so I have not
tried this myself.

Brian

On Mon, 9 Feb 2009 10:59:09 -0600, Mark Steely wrote:

>We are z/OS V1R9. I won't go into the sequence of events that happen
>this weekend, but we had a problem with the timestamp in the couple
>datasets and the system time mismatch ( we know how that happen) and we
>had to wait until the system time bypassed the the time in the couple
>datasets for the IPL to continue. Is there a way to reset (without
>rebuilding the datasets)  the couple datasets our tell the system to
>ignore the timestamp in the couple datasets. 
> 
>Any help would be appreciated. 
> 
>Thank You

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

Re: PROGxx, linklist, LLA and fetch performance

[Tom Marchant]

On Mon, 9 Feb 2009 11:18:26 -0600, Linda Hagedorn wrote:

>Keep the steplibs to a static named library
>and change the contents only.  This simplifies migration (change the contents
>of the steplib'd SDSNLOAD).

Or you could use data set aliases, perhaps with SYMBOLICRELATE.  That way
you could just change the value of the symbol using SYMUPDTE (check the
archives).  And you don't run the risk of breaking someone while you are
changing a load library.

-- 
Tom Marchant

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

Re: PROGxx, linklist, LLA and fetch performance

[Ted MacNEIL]

>Thank you very much.

I was imprecise.
Within a single library, modules cannot be duplicated.
Withi a single concatenation, modules will NOT be duplicated.

>Given duplicate modules exist in separate libraries, and LLA is making a 
>determination based on fetch performance and not sequential order, do you know 
>how the fetch performance is evaluated?

This is not a given.
LLA does NOT make fetch performance decisions!
The first module found is used.
And, the search is always started over.
It's just a cache.
Nothing more nothing less.

>I.e., how is one directory chose over another?  

First directory with the module found, in the order specified.


>Is it a function of the LLA search engine? 

It is a function of how concatenation works for all PDS/PDSE files.

It is not just programme fetch.
If you are scripting (DCF) a document and your imbed llib is a concatenation of 
text libraries, the first one found will be IMbedded.

If your SYSPROC is a series of concatenated libraries, the instance of the 
first REXX/CLIST matching the called name is invoked.

This is not a function of LLA/LNKLST/JOBLIB/STEPLIB.
It is a function of concatenation.

First module found.
LNKLST processing is just made faster by LLA.
(So can any library put in there)
But, the rules of concatenation are NOT vioated.
Just sped up.

-
Too busy driving to stop for gas!

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

Re: DFSORT options in PARMLIB

[Frank Yaeger]

Dave Josuma wrote on 02/09/2009 10:00:34 AM:
> Thanks Frank.  I found that out.  I just could not find any references
> to that in any of the DFSORT Doc on the bookshelf.  I guess I need to
> start reading the PGMDIR's that come for the Serverpac distributed
> products(I have not in the past).

Yep.  DFSORT is an optional feature of z/OS, so we're included in
the z/OS Program Directory (we don't have a separate one for DFSORT).

Frank Yaeger - DFSORT Development Team (IBM) - yae...@us.ibm.com
Specialties: FINDREP, WHEN=GROUP, DATASORT, ICETOOL, Symbols, Migration

 => DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort/

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

Re: DFSORT options in PARMLIB

[Jousma, David]

Thanks Frank.  I found that out.  I just could not find any references
to that in any of the DFSORT Doc on the bookshelf.  I guess I need to
start reading the PGMDIR's that come for the Serverpac distributed
products(I have not in the past).  


_
Dave Jousma
Assistant Vice President, Mainframe Services
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB1G
p 616.653.8429
f 616.653.8497


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Frank Yaeger
Sent: Monday, February 09, 2009 12:53 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: DFSORT options in PARMLIB

Dave Jousma wrote on 02/09/2009 09:33:58 AM:
> Frank,
>
> Thanks for the response.  Those are the books alright!  Show me in
there
> where the example of the PROC is.  I do not see it in any of the SICE*
> datasets.  I have no problems coding up the PARM members.
>
> I guess a RCF is in order.
>
> I did finally find the proc in SYS1.IBM.PROCLIB.  Not the place I
would
> have expected to find it.

I don't know what you mean by an "example of the PROC".  The ICEOPT PROC
is shipped with the product, installed in PROCLIB as specified in the
z/OS Program Directory, and used as shipped.

Frank Yaeger - DFSORT Development Team (IBM) - yae...@us.ibm.com
Specialties: FINDREP, WHEN=GROUP, DATASORT, ICETOOL, Symbols, Migration

 => DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort/

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

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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PROGxx, linklist, LLA and fetch performance

[Linda Hagedorn]

Thank you SO much!!!  I've been trying to figure out how to do just that!  

Linda 

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

Re: Extracting in-stream dataset (i.e. SYSIN) from SMF

[Scott Barry]

On Mon, 9 Feb 2009 16:27:51 +0100, Ferran Perxas  wrote:

>Hi all,
>
>Thanks for all your answers. I'll explain the whole problem so we can focus
>the questions/answers.
>Here, in the site i'm working, the developement team works with Natural. The
>way they use to invoke these programs is via a call to an assembler
>(Software AG) with the PGM Natural to execute, written on the SYSIN
>statement.
>
>In some cases, the developers dynamically build JCL and they submit those
>via intrdr from CICS (super "fat-batch-running" transactions), my client
>wants to keep this up and working, but i want to know which programs are run
>in my productive environement. Or in this case "were" run.
>
>Because of your answers i can understand that is way impossible for me to
>obtain the information submited long ago. But, does anyone have an example
>of a userexit that can help me catch this information and direct it to some
>kind of log (i.e. not used SMF-record)?
>
>Thanks all,
>
>Ferran.
>
>
>On Mon, Feb 9, 2009 at 3:29 PM, David Logan  wrote:
>
>> Yep. If you wanted to log it, you would have to log it manually through an
>> exit, like in CI or something. Seems a bit weird to me, but you could do
>> it.
>>
>> David Logan
>> Manager of Product Development, Pitney Bowes Business Insight
>> http://centrus.com
>> W: (720) 564-3056
>> C: (303) 818-8222
>>
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
>> Behalf
>> Of Ed Finnell
>> Sent: Monday, February 09, 2009 07:09
>> To: IBM-MAIN@bama.ua.edu
>> Subject: Re: Extracting in-stream dataset (i.e. SYSIN) from SMF
>>
>>
>> In a message dated 2/9/2009 6:58:14 A.M. Central Standard Time,
>> lordbis...@gmail.com writes:
>>
>> belive that the info may be logged in other places than SMF, but i  don't
>> know where to start searching.
>>
>>
>> >>
>> If it is SYSIN DD * it is only kept on SPOOL.  If you have shop standards
>> that require SYSIN DD DSN=cntl_file you could have  a possibility with
>> jobnames
>> and  OPEN/CLOSE or RACF(or equivalent) facilities.
>>
>>
>>
>>
>> **A Good Credit Score is 700 or Above. See yours in just 2 easy
>> steps!
>> (
>> http://pr.atwola.com/promoclk/10075x1218550342x1201216770/aol?redir=htt
>> p://
>> www.freecreditreport.com/pm/default.aspx?sc=668072%26hmpgID=62%26bcd=fe
>>
bemailfooterNO62
>> )
>>


catch this information


How would you know what job(s) to "catch" - maybe by the "called" program? 
I would be more concerned that you have instream data programs being
executed in production mode, uncontrolled, possibly submitted by developers,
if I am understanding the circumstances.  When a job is purged from the
spool (SMF type 26 execution purge node), the job's SYSIN data is also
purged.  No chance for auditing or post-execution code review.

Scott Barry
SBBWorks, Inc.

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

Re: DFSORT options in PARMLIB

[Frank Yaeger]

Dave Jousma wrote on 02/09/2009 09:33:58 AM:
> Frank,
>
> Thanks for the response.  Those are the books alright!  Show me in there
> where the example of the PROC is.  I do not see it in any of the SICE*
> datasets.  I have no problems coding up the PARM members.
>
> I guess a RCF is in order.
>
> I did finally find the proc in SYS1.IBM.PROCLIB.  Not the place I would
> have expected to find it.

I don't know what you mean by an "example of the PROC".  The ICEOPT PROC
is shipped with the product, installed in PROCLIB as specified in the
z/OS Program Directory, and used as shipped.

Frank Yaeger - DFSORT Development Team (IBM) - yae...@us.ibm.com
Specialties: FINDREP, WHEN=GROUP, DATASORT, ICETOOL, Symbols, Migration

 => DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort/

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

Re: Couple Datasets

[Rick Fochtman]

--
We are z/OS V1R9. I won't go into the sequence of events that happen 
this weekend, but we had a problem with the timestamp in the couple 
datasets and the system time mismatch ( we know how that happen) and we 
had to wait until the system time bypassed the the time in the couple 
datasets for the IPL to continue. Is there a way to reset (without 
rebuilding the datasets) the couple datasets our tell the system to 
ignore the timestamp in the couple datasets.


Any help would be appreciated.

I've always been really partial to using a Sysplex Timer to keep all the 
clocks synchronized. Does your equipment (CECs) have ETR ports? I'm a 
little out-of-date on this.


--
Rick
--
Remember that if you’re not the lead dog, the view never changes.

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

Re: PROGxx, linklist, LLA and fetch performance

[Ted MacNEIL]

>Considering the micro-economics of sysprog time, the scenario described above 
>requires I add and delete steplibs in every started task and programmer jcl in 
>every migration, and handle linklist too.   

1. Let the programmer handle it.
2. For started tasks:

a. Create a special INCLUDE member, somewhere:
   // SET DB2AVER=NIL
   // SET DB2BVER=R9
   // etc...
b. In the PROC
 // INCLUDE include member
 // other JCL statements
 // pseudo-code, because it's been awhile
 // if &db2aver<>NIL then
 //STEPLIB DD DISP=SHR,DSN=DB2.&db2aver..DSNLOAD
 // endif

You get the idea.

-
Too busy driving to stop for gas!

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

Re: Extracting in-stream dataset (i.e. SYSIN) from SMF

[Rick Fochtman]

---
The problem is that i want to extract the SYSIN info from jobs that were 
submited long ago, so their outputs are no longer in the spool. Anyway, 
i do not want to simply "read" or "see" the information, I want to treat 
it via REXX or others. Is there any place where the system logs this 
info, or my only shot is to keep it on spool and find a way to extract it?


That data is not "logged" anywhere in the system. Your only option is to 
keep the job in the spool until you can extract the necessary data.


Dumb question: why is this important?

--
Rick
--
Remember that if you’re not the lead dog, the view never changes.

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

Re: GMT time

[Rick Fochtman]

Paul Gilmartin wrote:


On Sun, 8 Feb 2009 15:10:21 -0600, Tom Marchant wrote:
 


r 00,'DATE=.ddd,CLOCK=hh.mm.ss,UTC|GMT'

   


Does specifying UTC on this command actually adjust the value
that will be returned by the TIME macro with the UTC/GMT option?
 


This is not a command.  It is the reply to message IEA888A, which is issued
if PROMPT is specified in CLOCKxx.  Yes, it does cause the TOD clock as seen
by this LPAR to be set.

   


Ah, I see.  Then an IPL is necessary to adjust the clock.
Usually undesirable.


--
Makes me wish for the return of the Sysplex Timer. :-)

--
Rick
--
Remember that if you're not the lead dog, the view never changes.



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

Re: DFSORT options in PARMLIB

[Jousma, David]

Frank,

Thanks for the response.  Those are the books alright!  Show me in there
where the example of the PROC is.  I do not see it in any of the SICE*
datasets.  I have no problems coding up the PARM members.

I guess a RCF is in order.  

I did finally find the proc in SYS1.IBM.PROCLIB.  Not the place I would
have expected to find it.

_
Dave Jousma
Assistant Vice President, Mainframe Services
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB1G
p 616.653.8429
f 616.653.8497

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Frank Yaeger
Sent: Monday, February 09, 2009 11:27 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: DFSORT options in PARMLIB

Dave Jousma wrote on 02/09/2009 07:57:42 AM:
> Either my eyesight is going bad, or I just plain cannot read.
>
> I am converting my DFSORT options from the MACRO's to the PARMLIB
> members.  The book says to enable the options at IPL time with a START
> ICEOPT,ICEPRM=nn
>
> I cannot find for the life of me, the documentation or sample JCL for
> ICEOPT.  Am I missing it?

Complete documentation for using PARMLIB members for DFSORT installation
options is in "z/OS DFSORT V1R10 Installation and Customization" which
you can access from

www.ibm.com/systems/support/storage/software/sort/mvs/srtmpub.html

More specifically, see:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ICE1CI10/2.2.
4?DT=20080602112557

ICEOPT is a PROC shipped with DFSORT.  You set up one or more
ICEPRMxx members with the installation options and then enable
the member(s) using ICEOPT.  For example, if you set up ICEPRM01, you
use:

START ICEOPT,ICEPRM=01

to enable it.,


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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: is there anyway to recreate a SMP GLOBAL zone?

[Ed Finnell]

 
In a message dated 2/9/2009 10:58:25 A.M. Central Standard Time,  
ebar...@doitt.nyc.gov writes:

we do not have a global to clone, so this may not be  relevant.>>
>>
Normally it's on the 'SMP' pack with the global ZONE. I'd be so afraid  of 
mismatched modules I'd just start  over.


**A Good Credit Score is 700 or Above. See yours in just 2 easy 
steps! 
(http://pr.atwola.com/promoclk/10075x1218550342x1201216770/aol?redir=http://www.freecreditreport.com/pm/default.aspx?sc=668072%26hmpgID=62%26bcd=fe
bemailfooterNO62)

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

Re: PROGxx, linklist, LLA and fetch performance

[Linda Hagedorn]

Skip, Ted, Tom, Scott, Kees, Jon, Ed, 

Thank you for the explanations.  I appreciate your time and the lively 
discussion.  I knew IBM-Main was the place to find the answer.  

Best regards, Linda 

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

Re: PROGxx, linklist, LLA and fetch performance

[Tom Marchant]

On Mon, 9 Feb 2009 16:37:33 +, Ted MacNEIL wrote:

>>Pardon me?
>>AIt builds an in-storage cache of directories and stages modules to VLF.
>>Modules are administrated per library, so is can manage duplicate modules.
>
>I meant per concatenation.
>No duplicate modules in a LNKLST concatenation.

I'm pretty sure that LLA simply caches the directories and has no idea
whether or not the same module exists in more than one data set.

If you have data sets A and B in the LNKLST, and both data sets have member
Z, the cache for both A and B will contain Z.  If both are in LLA with
FREEZE (the default), A is first in LNKLST and you STEPLIB to B, member Z
will be found in LLA.

-- 
Tom Marchant

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

Re: PROGxx, linklist, LLA and fetch performance

[Skip Robinson]

Linda,

You're attributing too much intelligence to LLA, which has no role in
determining *which* instance of a module to fetch, only how to locate a
module directly on a disk volume without the overhead of reading PDS
directories every time. Linklist--with or without LLA--will search (from
the top) the entire list of modules it has built and 'choose' the first one
that matches the name requested. Additional instances of the same name will
never be chosen. LLA does not provide any performance wisdom. It just does
what linklist would otherwise do but a lot faster.

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


   
 Linda Hagedorn
 To 
 Sent by: IBM  IBM-MAIN@bama.ua.edu
 Mainframe  cc 
 Discussion List   
  Re: PROGxx, linklist, LLA and fetch 
   performance 
   
 02/09/2009 08:57  
 AM
   
   
 Please respond to 
   IBM Mainframe   
  Discussion List  

   
   





>Pardon me?
>It builds an in-storage cache of directories and stages modules to VLF.
>Modules are administrated per library, so is can manage duplicate
>modules.
>
>Kees.

Hi Kees,

Thank you very much.  Given duplicate modules exist in separate libraries,
and
LLA is making a determination based on fetch performance and not sequential

order, do you know how the fetch performance is evaluated?  I.e., how is
one
directory chose over another?  Is it a function of the LLA search engine?

I'm trying to understand this scenario: When job 1 is looking for a module,
I
presume the engine looks at LLA before LNKLST.  Let's say it finds the
module,
and passes the address to the job.

Job 2 is looking for a module, and LLA looks for it.  Does the engine start
at
the beginning of the LLA in-storage cache of directories, or does it
continue
searching from where it was last?

Please excuse me if this should be obvious; I'm not a MVS Sysprog.

Thanks, Linda

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

Re: PROGxx, linklist, LLA and fetch performance

[Linda Hagedorn]

On Mon, 9 Feb 2009 16:49:22 +, Ted MacNEIL  
wrote:

>How I would handle/have handled it, is never have more than two active 
release running
>(especially with DB2, that can get expensive after a year).
>How you handle the release migration, is up to you.
>You can have one or the other steplib'd, and the opposite lnklst'd.
>But, when the dust settles, the current release should be in the lnklst.
>

Considering the micro-economics of sysprog time, the scenario described 
above requires I add and delete steplibs in every started task and programmer 
jcl in every migration, and handle linklist too.   

Instead, don't put DB2 in linklist.  Keep the steplibs to a static named 
library 
and change the contents only.  This simplifies migration (change the contents 
of the steplib'd SDSNLOAD).  I never change linklist, never change the started 
task jcl, and never affect programmers JCL.  This is the easiest way to 
manage the DB2 libraries - install, migration, and operation - and it 
eliminates 
the possibilities of typos too.  All I ever change is the library contents.   

But that's just my opinion too.  :)

Back to LLA.  Does anyone know the search mechanics of the LLA engine on a 
second request for a module?

Linda

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

Re: PROGxx, linklist, LLA and fetch performance

[Tom Marchant]

On Mon, 9 Feb 2009 10:57:23 -0600, Linda Hagedorn wrote:

>
>>Pardon me?
>>It builds an in-storage cache of directories and stages modules to VLF.
>>Modules are administrated per library, so is can manage duplicate
>>modules.
>>
>>Kees.
>
>Hi Kees,
>
>Thank you very much.  Given duplicate modules exist in separate libraries, and
>LLA is making a determination based on fetch performance and not sequential
>order, do you know how the fetch performance is evaluated?  I.e., how is one
>directory chose over another?  Is it a function of the LLA search engine?

LLA will tell VLF to stage the entire module in storage, making it much
quicker to load the module.  VLF storage is limited and LLA tries to
prioritize the usage of storage based upon, among other things, the size of
the modules and the frequency with which they are loaded.  This does not
alter the search order.

>I'm trying to understand this scenario: When job 1 is looking for a module, I
>presume the engine looks at LLA before LNKLST.  Let's say it finds the module,
>and passes the address to the job.

No.  The LNKLST search uses LLA to eliminate I/O when searching the
directories.  Standard search order still applies.

>Job 2 is looking for a module, and LLA looks for it.  Does the engine start at
>the beginning of the LLA in-storage cache of directories, or does it continue
>searching from where it was last?

All LNKLST searches start with the first library in the LNKLST and continue
until the module is found.

-- 
Tom Marchant

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

Re: is there anyway to recreate a SMP GLOBAL zone?

[Mark Zelden]

On Mon, 9 Feb 2009 10:40:17 -0500, Barkow, Eileen  wrote:

>I did not install this product and i am not sure how this happened, but
>somehow the global zone of a new CICS installation disappeared and we
>have no backup of whatever
>
>volume it was on. We still have the distlib and target zones. Is there
>anyway  to recreate a global zone?
>

This subject came up recently (within the last few months I think).  
Search the archives.  I think Brian Peterson gave a good answer and
there was some follow up from myself and Kurt Quackenbush. 

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

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

Couple Datasets

[Mark Steely]

We are z/OS V1R9. I won't go into the sequence of events that happen
this weekend, but we had a problem with the timestamp in the couple
datasets and the system time mismatch ( we know how that happen) and we
had to wait until the system time bypassed the the time in the couple
datasets for the IPL to continue. Is there a way to reset (without
rebuilding the datasets)  the couple datasets our tell the system to
ignore the timestamp in the couple datasets. 
 
Any help would be appreciated. 
 
Thank You

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

Re: PROGxx, linklist, LLA and fetch performance

[Linda Hagedorn]

>Pardon me?
>It builds an in-storage cache of directories and stages modules to VLF.
>Modules are administrated per library, so is can manage duplicate
>modules.
>
>Kees.

Hi Kees, 

Thank you very much.  Given duplicate modules exist in separate libraries, and 
LLA is making a determination based on fetch performance and not sequential 
order, do you know how the fetch performance is evaluated?  I.e., how is one 
directory chose over another?  Is it a function of the LLA search engine? 

I'm trying to understand this scenario: When job 1 is looking for a module, I 
presume the engine looks at LLA before LNKLST.  Let's say it finds the module, 
and passes the address to the job.  

Job 2 is looking for a module, and LLA looks for it.  Does the engine start at 
the beginning of the LLA in-storage cache of directories, or does it continue 
searching from where it was last?  

Please excuse me if this should be obvious; I'm not a MVS Sysprog.

Thanks, Linda  

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

Re: is there anyway to recreate a SMP GLOBAL zone?

[Barkow, Eileen]

where is the ref doc?
we do not have a global to clone, so this may not be relevant.


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Ed Finnell
Sent: Monday, February 09, 2009 11:38 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: is there anyway to recreate a SMP GLOBAL zone?


 
In a message dated 2/9/2009 10:33:31 A.M. Central Standard Time,  
ebar...@doitt.nyc.gov writes:

hopefully, we still have all of the datasets needed to re-receive  the
product.
this is a new installation so we may just have to start  over again.


>>
There's jobs setup to do this in your order.  Look in your ref doc for 
cloning your system?




**A Good Credit Score is 700 or Above. See yours in just 2
easy 
steps! 
(http://pr.atwola.com/promoclk/10075x1218550342x1201216770/aol?redir
=http://www.freecreditreport.com/pm/default.aspx?sc=668072%26hmpgID=62%2
6bcd=fe
bemailfooterNO62)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: GMT time

[Paul Gilmartin]

On Mon, 9 Feb 2009 11:34:20 -0500, David Andrews wrote:
>
>Who (what) sets CVTLSO?
>
ETR/STP by mechanism(s) deliberately left undocumented.  Might
it interrupt the CPU to request this?  I believe the same applies
to CVTLDTO if ETR/STP is present.  And that leap second adjustments
are scheduled at the ETR console.

-- gil

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

Re: PROGxx, linklist, LLA and fetch performance

[Ted MacNEIL]

>So Ted, how would you handle running many DB2 subsystems on the same MVS 
>image?  Require that they all do maintenance and version upgrades 
>simultaneously?  I think not.

As I said, in a previous post, migration vs daily operations is a different 
issue.

How I would handle/have handled it, is never have more than two active release 
running
(especially with DB2, that can get expensive after a year).
How you handle the release migration, is up to you.
You can have one or the other steplib'd, and the opposite lnklst'd.
But, when the dust settles, the current release should be in the lnklst.

Of course, this is my opinion, only.

It's amazing how a question regarding LNKLST/LLA search order becomes a 
maintenance controvery!

-
Too busy driving to stop for gas!

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

Re: PROGxx, linklist, LLA and fetch performance

[Ted MacNEIL]

>I have six lpars with four data sharing groups crossing the lpars, and having 
>DB2 in linklist won't work.

I've worked with up to 19 LPARs.

>The migration to a new release, if in linklist only, would affect six lpars 
>and four datasharing groups at once.

You weren't talking about migration to a new release, as far as I can tell.
I was talking about day to day operations.

>Given short migration windows, and the change in the DB2 catalog to unicode 
>between R710 and R810, I cannot migrate four production platforms in the 
>window, not to mention management would not accept a risk of that magnitude.   
>   

Yes. Migration is a different issue.
But, how often do you migrate?
Once you've completed that, why not leave the current version in the LNKLST.

DB2 is designed for performance optimisation.
Leaving STEP/JOB LIBs around (even if they're in LLA) is not necessarily a good 
thing.


-
Too busy driving to stop for gas!

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

Re: is there anyway to recreate a SMP GLOBAL zone?

[Ed Finnell]

 
In a message dated 2/9/2009 10:33:31 A.M. Central Standard Time,  
ebar...@doitt.nyc.gov writes:

hopefully, we still have all of the datasets needed to re-receive  the
product.
this is a new installation so we may just have to start  over again.


>>
There's jobs setup to do this in your order.  Look in your ref doc for 
cloning your system?




**A Good Credit Score is 700 or Above. See yours in just 2 easy 
steps! 
(http://pr.atwola.com/promoclk/10075x1218550342x1201216770/aol?redir=http://www.freecreditreport.com/pm/default.aspx?sc=668072%26hmpgID=62%26bcd=fe
bemailfooterNO62)

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

Re: PROGxx, linklist, LLA and fetch performance

[Ted MacNEIL]

>Pardon me? 
>AIt builds an in-storage cache of directories and stages modules to VLF.
>Modules are administrated per library, so is can manage duplicate modules.

I meant per concatenation.
No duplicate modules in a LNKLST concatenation.
The integrity of the LNKLST is maintained.
We were talking about the LNKLST, weren't we?
Maybe I wasn't precise enough.

-
Too busy driving to stop for gas!

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

Re: GMT time

[David Andrews]

On Mon, 2009-02-09 at 10:05 -0600, Paul Gilmartin wrote:
> CVTLSO

That Peter Relson reference was useful, thanks for the pointer.

Who (what) sets CVTLSO?

-- 
David Andrews
A. Duda and Sons, Inc.
david.andr...@duda.com

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

Tape migration to larger volumes.

[Bjarni Hauksson]

We are running 3 systems RMMPlex and need to copy large number of tapes to 
newer and higher capacity tape volumes.  Several tapes need to be stacked 
on the new tape volumes.
We would like to achieve this transition at the lowest possible cost and 
manual tailoring JCL seems little overwhelming. We have come across Tivoli 
Tape Optimizer as possible solution for the task.

The three systems in the RMMPlex are at very different capacities and the 
TTO is IPLA priced. Do you know if I install TTO in just one of the 3 systems 
and be charged just for it's size (MSU) ?

Any other ideas of low cost solutions for this transition.

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

Re: is there anyway to recreate a SMP GLOBAL zone?

[Barkow, Eileen]

thanks Tom and Joe for you response.
we will try creating anew global and pointing to the tgt/dlib zones via
the zoneindex as you say.
hopefully, we still have all of the datasets needed to re-receive the
product.
this is a new installation so we may just have to start over again.

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Joe Aulph
Sent: Monday, February 09, 2009 11:14 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: is there anyway to recreate a SMP GLOBAL zone?

Of course the Global Zone wouldn't know where it was APPLY'd that's kept
in
the TARGET zone.

As Tom said, create a new GLOBAL and point to the TGT & DLIB zones via
the
ZONEINDEX.

Besides re-RECEIVEing andy DDDEF's will need to be re-created.

Thank You,

Joe Aulph,
Senior Systems Programmer:
850-487-8945
joe_au...@dcf.state.fl.us


 

 Tom Marchant

 
To 
 Sent by: IBM  IBM-MAIN@bama.ua.edu

 Mainframe
cc 
 Discussion List

  Re: is there anyway to recreate a

   SMP GLOBAL zone?

 

 02/09/2009 10:57

 AM

 

 

 Please respond to

   IBM Mainframe

  Discussion List

 

 

 





On Mon, 9 Feb 2009 10:40:17 -0500, Barkow, Eileen wrote:

>I did not install this product and i am not sure how this happened, but
>somehow the global zone of a new CICS installation disappeared and we
>have no backup of whatever
>
>volume it was on. We still have the distlib and target zones. Is there
>anyway  to recreate a global zone?

You can create a new global zone and define your target and distribution
zones in it.  Of course, the new global zone won't know where anything
was
applied, but that shouldn't cause you any problem.  You will have to
re-receive any maintenance that you might need to apply.

--
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: DFSORT options in PARMLIB

[Frank Yaeger]

Dave Jousma wrote on 02/09/2009 07:57:42 AM:
> Either my eyesight is going bad, or I just plain cannot read.
>
> I am converting my DFSORT options from the MACRO's to the PARMLIB
> members.  The book says to enable the options at IPL time with a START
> ICEOPT,ICEPRM=nn
>
> I cannot find for the life of me, the documentation or sample JCL for
> ICEOPT.  Am I missing it?

Complete documentation for using PARMLIB members for DFSORT installation
options is in "z/OS DFSORT V1R10 Installation and Customization" which
you can access from

www.ibm.com/systems/support/storage/software/sort/mvs/srtmpub.html

More specifically, see:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ICE1CI10/2.2.4?DT=20080602112557

ICEOPT is a PROC shipped with DFSORT.  You set up one or more
ICEPRMxx members with the installation options and then enable
the member(s) using ICEOPT.  For example, if you set up ICEPRM01, you use:

START ICEOPT,ICEPRM=01

to enable it.,

You can find an example of an ICEPRMxx member at:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ICE1CI10/FIGWQ59?SHELF=&DT=20080602112557&CASE=&ScrollTOP=FIGWQ59#FIGWQ59

Frank Yaeger - DFSORT Development Team (IBM) - yae...@us.ibm.com
Specialties: FINDREP, WHEN=GROUP, DATASORT, ICETOOL, Symbols, Migration

 => DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PROGxx, linklist, LLA and fetch performance

[Tom Marchant]

On Mon, 9 Feb 2009 15:41:11 +, Ted MacNEIL wrote:
>
>And, LNKLST is faster than STEP/JOB LIBs.

Only if there is no JOBLIB or STEPLIB.  If there is, it is searched first,
slowing down access to LNKLST.

-- 
Tom Marchant

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

Re: is there anyway to recreate a SMP GLOBAL zone?

[Joe Aulph]

Of course the Global Zone wouldn't know where it was APPLY'd that's kept in
the TARGET zone.

As Tom said, create a new GLOBAL and point to the TGT & DLIB zones via the
ZONEINDEX.

Besides re-RECEIVEing andy DDDEF's will need to be re-created.

Thank You,

Joe Aulph,
Senior Systems Programmer:
850-487-8945
joe_au...@dcf.state.fl.us


   
 Tom Marchant  
   To 
 Sent by: IBM  IBM-MAIN@bama.ua.edu
 Mainframe  cc 
 Discussion List   
  Re: is there anyway to recreate a   
   SMP GLOBAL zone?
   
 02/09/2009 10:57  
 AM
   
   
 Please respond to 
   IBM Mainframe   
  Discussion List  

   
   




On Mon, 9 Feb 2009 10:40:17 -0500, Barkow, Eileen wrote:

>I did not install this product and i am not sure how this happened, but
>somehow the global zone of a new CICS installation disappeared and we
>have no backup of whatever
>
>volume it was on. We still have the distlib and target zones. Is there
>anyway  to recreate a global zone?

You can create a new global zone and define your target and distribution
zones in it.  Of course, the new global zone won't know where anything was
applied, but that shouldn't cause you any problem.  You will have to
re-receive any maintenance that you might need to apply.

--
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: GMT time

[Paul Gilmartin]

On Sun, 8 Feb 2009 23:07:53 -0500, David Andrews wrote:
>
>We periodically SET CLOCK to locally correct for this.  (I understand
>that this sets CVTLDTO.)
>
>> Mightn't this cause the Unix time to go backwards for some
>> values of the adjustment.
>
>Yeppers, it sure could, which is why we do this in quiet periods -- one
>of the advantages that we little fish have over the megacorporate 24/7
>behemoths.
>
>While I'm wishing, I wish the sysplex timers weren't so expensive.
>
... Or that there was a three-position switch adjusting the TOD
clock rate: -1%:NORMAL:+1%.  (The poor man's STP).

>> What if instead of the complexity you propose one simply fudged the
>> content of CVTLSO, not CVTLDTO,
>
>'splainey?  I'm not familiar with CVTLSO, and the CVT DSECT only says:
>"LEAP SECOND OFFSET IN TOD FORMAT"
>
From:

   Linkname: Re: Converting TOD to Local Time
URL: http://bama.ua.edu/cgi-bin/wa?A2=ind0512&L=ibm-main&P=69168

   Subject:  Re: Converting TOD to Local Time
   From: Peter Relson
   Reply-To: IBM Mainframe Discussion List 
   Date: Wed, 14 Dec 2005 07:54:23 -0500

   A STCK value, as Bob Wright mentioned, is considered "absolute time".
   Absolute to UTC: apply leap seconds
   Absolute to Local: apply leap seconds and time zone offset

   UtcTime = StckTimeStamp - CVTLSO
   LocalTime = StckTimeStamp + CVTLDTO - CVTLSO

   Assuming addressability to the CVT, and assuming z/Architecture,
   LGR1,StckTimeStamp
   ALG   R1,CVTLDTO
   SLG   R1,CVTLSO
   STG   R1,LocalTime

... so fudging CVTLDTO adjusts only local time; fudging CVTLSO
adjusts both local time and UTC time.  I'd recommend making such
an adjustment only during your "quiet periods".

-- gil

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

Re: DFSORT statement sequence

[Elardus Engelbrecht]

Frank Yaeger wrote:
>It's false.  The INCLUDE statement is processed before the SORT statement 
regardless of the order in which you specify them.

Thanks very much.

>For a figure showing the order of processing of DFSORT control statements, 
see:

Thanks for supplying that figure. Who said a pic is worth 1000 words? ;)

>Note that OUTFIL INCLUDE is processed after SORT so that would be less 
efficient than using an INCLUDE statement which is processed before SORT.

Thanks about the note about OUTFIL INCLUDE.

It is really kind of you for helping out here.

Groete / Greetings
Elardus Engelbrecht

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

Re: How to CAP CICS cpu resource using WLM resource group

[Michael Wickman]

We cap a CICS region by job name.  Our regions are not STC's.


*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Mike Wickman
Technical Services
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Greg Shirey
Sent: Monday, February 09, 2009 8:52 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: [IBM-MAIN] How to CAP CICS cpu resource using WLM resource
group

Tommy,

What do you mean that you failed?  

Our production CICS region has response time goals and we do not assign
any resource groups, but it does appear from the panels that it is
possible to do so.  
  
Regards,
Greg Shirey
Ben E. Keith Co.  

-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Tommy Tsui
Sent: Monday, February 09, 2009 1:58 AM

Hi all,
 I try to cap some CICS resources by using WLM resource group but
failed. Since CICS worload cannot be capped by resource group. Only
JES2 workload can be capped by resource group. However, we can't use
the CICS applid or subsystem group to classify those CICS resource.
How can I cap the CICS resource? only by it's jobname?

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








"This email is intended to be reviewed by only the intended recipient
 and may contain information that is privileged and/or confidential.
 If you are not the intended recipient, you are hereby notified that
 any review, use, dissemination, disclosure or copying of this email
 and its attachments, if any, is strictly prohibited.  If you have
 received this email in error, please immediately notify the sender by
 return email and delete this email from your system."


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

DFSORT options in PARMLIB

[Jousma, David]

All,

Either my eyesight is going bad, or I just plain cannot read.  

I am converting my DFSORT options from the MACRO's to the PARMLIB
members.  The book says to enable the options at IPL time with a START
ICEOPT,ICEPRM=nn

I cannot find for the life of me, the documentation or sample JCL for
ICEOPT.  Am I missing it?

_
Dave Jousma
Assistant Vice President, Mainframe Services
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB1G
p 616.653.8429
f 616.653.8497


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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: is there anyway to recreate a SMP GLOBAL zone?

[Tom Marchant]

On Mon, 9 Feb 2009 10:40:17 -0500, Barkow, Eileen wrote:

>I did not install this product and i am not sure how this happened, but
>somehow the global zone of a new CICS installation disappeared and we
>have no backup of whatever
>
>volume it was on. We still have the distlib and target zones. Is there
>anyway  to recreate a global zone?

You can create a new global zone and define your target and distribution
zones in it.  Of course, the new global zone won't know where anything was
applied, but that shouldn't cause you any problem.  You will have to
re-receive any maintenance that you might need to apply.

-- 
Tom Marchant

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

Re: DFSORT statement sequence

[Frank Yaeger]

Elardus Engelbrecht wrote on 02/09/2009 04:52:51 AM:

> Where is it documented that the sequence of sort control statement does
> play a role in performance? My searches on Google, IBM-MAIN and DFSORT
> couldn't produce something 'hard and fast'...
>
> My gut feeling is that
>
> INCLUDE COND=(1,8,CH,EQ,C'ABCDEFGH')
> SORT FIELDS=(1,8,CH,A)
>
> is better over this
>
> SORT FIELDS=(1,8,CH,A)
> INCLUDE COND=(1,8,CH,EQ,C'ABCDEFGH')
>
> for very LARGE input.
>
> Is this true or false? (If false, I can always do a COPY with
> INCLUDE and then
> do my SORT FIELDS)

It's false.  The INCLUDE statement is processed before the SORT
statement regardless of the order in which you specify them.

For a figure showing the order of processing of DFSORT control
statements, see:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ICE1CA30/FIGSTMTSEQ?SHELF=&DT=20080528171007&CASE=&ScrollTOP=FIGSTMTSEQ#FIGSTMTSEQ

Note that OUTFIL INCLUDE is processed after SORT so that would be
less efficient than using an INCLUDE statement which is processed
before SORT.

Frank Yaeger - DFSORT Development Team (IBM) - yae...@us.ibm.com
Specialties: FINDREP, WHEN=GROUP, DATASORT, ICETOOL, Symbols, Migration

 => DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PROGxx, linklist, LLA and fetch performance

[Scott Rowe]

So Ted, how would you handle running many DB2 subsystems on the same MVS image? 
 Require that they all do maintenance and version upgrades simultaneously?  I 
think not.

>>> Ted MacNEIL  2/9/2009 10:41 AM >>>
>In my experience, DB2 should not be in linklist; it does not need to be there. 

I disagree. It ensures everybody is running the same code.

>and leaves operational holes particularly in TSO.  

Again, I disagree.
If somebody changes the release, via new libraries, you can end up with a 
maintenance headache.

And, LNKLST is faster than STEP/JOB LIBs.



-
Too busy driving to stop for gas!

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


CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains 
confidential and privileged information intended only for the addressee.  If 
you are not the intended recipient, please be advised that you have received 
this material in error and that any forwarding, copying, printing, 
distribution, use or disclosure of the material is strictly prohibited.  If you 
have received this material in error, please (i) do not read it, (ii) reply to 
the sender that you received the message in error, and (iii) erase or destroy 
the material. Emails are not secure and can be intercepted, amended, lost or 
destroyed, or contain viruses. You are deemed to have accepted these risks if 
you communicate with us by email. Thank you.

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

Re: PROGxx, linklist, LLA and fetch performance

[Linda Hagedorn]

On Mon, 9 Feb 2009 15:41:11 +, Ted MacNEIL  
wrote:

>>In my experience, DB2 should not be in linklist; it does not need to be there.
>
>I disagree. It ensures everybody is running the same code.
>
>>and leaves operational holes particularly in TSO.
>
>Again, I disagree.
>If somebody changes the release, via new libraries, you can end up with a 
maintenance headache.
>
>And, LNKLST is faster than STEP/JOB LIBs.
>

I have six lpars with four data sharing groups crossing the lpars, and having 
DB2 in linklist won't work.  The migration to a new release, if in linklist 
only, 
would affect six lpars and four datasharing groups at once.  Given short 
migration windows, and the change in the DB2 catalog to unicode between 
R710 and R810, I cannot migrate four production platforms in the window, not 
to mention management would not accept a risk of that magnitude.  

For a less complex platform, perhaps a single DB2 per lpar, having the code 
linklisted is manageable.  

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

Re: PROGxx, linklist, LLA and fetch performance

[Elardus Engelbrecht]

Ted MacNeil wrote:

>If somebody changes the release, via new libraries, you can end up with a 
maintenance headache.

Yup, thats first class migraine, not common headache.

Problem with DB2 is that sometimes you need both versions to properly 
validate the new version. When finally settled on the new version, drop all 
references to old DB2 versions in STEP/JOB LIBs and LINKLIST. KEEP only DB2 
new version on LINKLIST.

If I had it my way I would keep different versions of DB2 on different LPARS, 
but I'm not a DB2 dog. :-/

>And, LNKLST is faster than STEP/JOB LIBs.

Of course. What is so difficult to understand this one... ;-)

Groete / Greetings
Elardus Engelbrecht

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

Re: PROGxx, linklist, LLA and fetch performance

[Vernooy, C.P. - SPLXM]

"Ted MacNEIL"  wrote in message
news:<484685675-1234194078-cardhu_decombobulator_blackberry.rim.net-6918
514...@bxe1065.bisx.prod.on.blackberry>...
> >In my experience, DB2 should not be in linklist; it does not need to
be there. 
> 
> I disagree. It ensures everybody is running the same code.
> 
> >and leaves operational holes particularly in TSO.  
> 
> Again, I disagree.
> If somebody changes the release, via new libraries, you can end up
with a maintenance headache.
> 
> And, LNKLST is faster than STEP/JOB LIBs.

Not necessarily true, you can have job/step libs managed by LLA and they
will perform also at cache-speed.

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

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

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

Re: PROGxx, linklist, LLA and fetch performance

[Tom Marchant]

On Mon, 9 Feb 2009 15:37:58 +, Ted MacNEIL wrote:
>
>This was taught to me in a basic JCL course.
>Order of search:
>STEPLIB
>JOBLIB
>LPA
>LNKLST

Not quite.

1. Requesting task's Load List
2. Job pack area
3. Task Library
4. STEPLIB.  If there is no STEPLIB, then JOBLIB
5. LPA
6. LKNLST

In particular, if there is a STEPLIB, JOBLIB is not searched.

-- 
Tom Marchant

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

Re: PROGxx, linklist, LLA and fetch performance

[Vernooy, C.P. - SPLXM]

"Ted MacNEIL"  wrote in message
news:<898850950-1234193875-cardhu_decombobulator_blackberry.rim.net-1121
3799...@bxe1065.bisx.prod.on.blackberry>...
> >Yes, LNKLST searches top-to-bottom, but what is LLA doing? 
> 
> LLA is standing in for LNKLST.
> 
> >Do you have information about how LLA choses between two duplicate
module 
> names in linklist when it's making a determination for fetch
performance?
> 
> As with BLDL, LLA does not know about duplicate modules.
> It only builds one entry per module name, so a second entry of the
same name is discarded.

Pardon me? 
It builds an in-storage cache of directories and stages modules to VLF.
Modules are administrated per library, so is can manage duplicate
modules.

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

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

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

Re: PROGxx, linklist, LLA and fetch performance

[Ted MacNEIL]

>DB2 does LOAD, not BLDL.  Do you know what LOAD does with LLA?  

Every load does a BLDL to find the module, if it's not already done in some 
manner.
BLDL is required to locate the module.


Again, there is only one entry per module in LLA.
The first one encounterd.
All other duplicated are discarded.
So, there is no second module to find.

LNKLST is just a fancy STEPLIB.
And, LLA is just a caching mechanism.

You never see duplicate modules in a STEPLIB (or JOBLIB); just the first one.
Same with LNKLST.
LLA is just a pre-built list that is used to locate the module.

-
Too busy driving to stop for gas!

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

Re: PROGxx, linklist, LLA and fetch performance

[Ted MacNEIL]

>In my experience, DB2 should not be in linklist; it does not need to be there. 

I disagree. It ensures everybody is running the same code.

>and leaves operational holes particularly in TSO.  

Again, I disagree.
If somebody changes the release, via new libraries, you can end up with a 
maintenance headache.

And, LNKLST is faster than STEP/JOB LIBs.



-
Too busy driving to stop for gas!

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

is there anyway to recreate a SMP GLOBAL zone?

[Barkow, Eileen]

I did not install this product and i am not sure how this happened, but
somehow the global zone of a new CICS installation disappeared and we
have no backup of whatever

volume it was on. We still have the distlib and target zones. Is there
anyway  to recreate a global zone?

 

   thank list


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

Re: PROGxx, linklist, LLA and fetch performance

[Ted MacNEIL]

>Yes, LNKLST searches top-to-bottom, but what is LLA doing? 

LLA is standing in for LNKLST.

>Do you have information about how LLA choses between two duplicate module 
names in linklist when it's making a determination for fetch performance?

As with BLDL, LLA does not know about duplicate modules.
It only builds one entry per module name, so a second entry of the same name is 
discarded.
LLA cannot fetch what is not not known about.

This was taught to me in a basic JCL course.
Order of search:
STEPLIB
JOBLIB
LPA
LNKLST

LLA is merely a cache mechanism, aiding (not changing) the standard search 
rules.

The only thing LLA is doing is speeding up the search.


-
Too busy driving to stop for gas!

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

Re: PROGxx, linklist, LLA and fetch performance

[Tom Marchant]

On Mon, 9 Feb 2009 09:15:36 -0600, Linda Hagedorn wrote:
>
>My concern is LLA and how it is chosing modules.  Since I have duplicate
>modules in linklist, which one is LLA going to pick?  Is PROGxx the order,
or is
>LLA performing analysis and picking the one that's fastest?

LLA does not choose modules.  It caches directories in memory to speed up
the standard directory search.

Perhaps this will help:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2E151/1.6.1?SHELF=IEA2BK90&DT=20080119071214
http://preview.tinyurl.com/cgukt9

You can issue D PROG,LNKLST to determine the concatenation order.

-- 
Tom Marchant

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

Re: PROGxx, linklist, LLA and fetch performance

[Linda Hagedorn]

On Mon, 9 Feb 2009 15:13:32 +, Ted MacNEIL  
wrote:

>The first one.
>
>>I need to know which of these sentences is true:
>
>>The order the datasets were typed into PROGxx is the
>>order the libraries will be searched,   and the order they
>>were typed can be relied upon.
>
>Yes.
>Otherwise, who knows what will happen.
>LLA is just an extension to BLDL, and preserves the order.
>Anything else would be chaos.
 

DB2 does LOAD, not BLDL.  Do you know what LOAD does with LLA?  

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

Re: Extracting in-stream dataset (i.e. SYSIN) from SMF

[Ferran Perxas]

Hi all,

Thanks for all your answers. I'll explain the whole problem so we can focus
the questions/answers.
Here, in the site i'm working, the developement team works with Natural. The
way they use to invoke these programs is via a call to an assembler
(Software AG) with the PGM Natural to execute, written on the SYSIN
statement.

In some cases, the developers dynamically build JCL and they submit those
via intrdr from CICS (super "fat-batch-running" transactions), my client
wants to keep this up and working, but i want to know which programs are run
in my productive environement. Or in this case "were" run.

Because of your answers i can understand that is way impossible for me to
obtain the information submited long ago. But, does anyone have an example
of a userexit that can help me catch this information and direct it to some
kind of log (i.e. not used SMF-record)?

Thanks all,

Ferran.


On Mon, Feb 9, 2009 at 3:29 PM, David Logan  wrote:

> Yep. If you wanted to log it, you would have to log it manually through an
> exit, like in CI or something. Seems a bit weird to me, but you could do
> it.
>
> David Logan
> Manager of Product Development, Pitney Bowes Business Insight
> http://centrus.com
> W: (720) 564-3056
> C: (303) 818-8222
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf
> Of Ed Finnell
> Sent: Monday, February 09, 2009 07:09
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Extracting in-stream dataset (i.e. SYSIN) from SMF
>
>
> In a message dated 2/9/2009 6:58:14 A.M. Central Standard Time,
> lordbis...@gmail.com writes:
>
> belive that the info may be logged in other places than SMF, but i  don't
> know where to start searching.
>
>
> >>
> If it is SYSIN DD * it is only kept on SPOOL.  If you have shop standards
> that require SYSIN DD DSN=cntl_file you could have  a possibility with
> jobnames
> and  OPEN/CLOSE or RACF(or equivalent) facilities.
>
>
>
>
> **A Good Credit Score is 700 or Above. See yours in just 2 easy
> steps!
> (
> http://pr.atwola.com/promoclk/10075x1218550342x1201216770/aol?redir=htt
> p://
> www.freecreditreport.com/pm/default.aspx?sc=668072%26hmpgID=62%26bcd=fe
> bemailfooterNO62
> )
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html