Re: Head's Up - zIIP issue OA17458/UA28419

[Edward Jaffe]

Thompson, Steve (SCI TW) wrote:



If this pervasive and well-established technique becomes unreliable, I 
predict *lots* of software will break!



Shall I give two for instances? 


JES2 and JES3 exits and interfacing code?

The values of EQUates and the existence of field names are used to
determine which level of code to generate (PARTICULARLY WHEN a field has
moved from one C/B to another).
  


The JES developers have always done a pretty good job in this area. 
Control block fields appear only when the function that needs them (or 
toleration code on back releases) is present. If this wasn't true, I can 
assure you that (E)JES would have encountered some *major* difficulties 
over the past 16 years. And, I suspect numerous other JES interface 
would have had problems as well ... including SDSF.


Not every component has an equivalent to SYSSTATE_OSREL. And, even if 
such interfaces were pervasive, the release/modification boundary 
granularity is insufficient to allow code to adapt to behavioral changes 
that might occur when PTFs are installed. There's just no reliable way 
at run time or assembly time to query the SMP/E data base!


Prior to this discussion, I would have stated unequivocally that the 
_most_ reliable way to know if a particular behavior (implemented via 
release boundary or APAR/PTF) is present is to test for the presence of 
new control block fields that it defines (or old ones it removes). I 
think it's still mostly true. But, obviously there are exceptions.


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

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

Re: Head's Up - zIIP issue OA17458/UA28419

[Thompson, Steve (SCI TW)]

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Edward Jaffe
Sent: Saturday, August 26, 2006 11:34 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Head's Up - zIIP issue OA17458/UA28419

Peter Relson wrote:
> I can only say "I am astonished" that someone would code based on the
> presence of a field name. We have every right to define fields in any
level
> of macros that are convenient.
>   


If this pervasive and well-established technique becomes unreliable, I 
predict *lots* of software will break!


Shall I give two for instances? 

JES2 and JES3 exits and interfacing code?

The values of EQUates and the existence of field names are used to
determine which level of code to generate (PARTICULARLY WHEN a field has
moved from one C/B to another).

Regards,
Steve Thompson

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

Re: Head's Up - zIIP issue OA17458/UA28419

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 08/26/2006
   at 09:33 PM, Edward Jaffe <[EMAIL PROTECTED]> said:

>And, I'm astonished at your astonishment!

But Peter is right.

>The technique of testing for the presence of control block fields at
> assembly time e.g., AIF (NOT D'CVTH) to skip around 
>release-dependent code for source-maintained products has been a 
>standard practice for _decades_

The practice of introducing symbols that will be needed in a future
release has also been a standard practice for decades.

>Assembler H (IEV90)!

The early provision of symbols goes back to Assembler (F).

>If this pervasive and well-established technique becomes unreliable,

It can't *become* unreliable because it was *ALWAYS* unreliable.
BTDTGTS.

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

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

Re: Head's Up - zIIP issue OA17458/UA28419

[Shmuel Metz (Seymour J.)]

In
<[EMAIL PROTECTED]>,
on 08/26/2006
   at 05:52 AM, "Schiradin,Roland HG-Dir itb-db/dc"
<[EMAIL PROTECTED]> said:

>Checking the runtime level happen during runtime but at assembly 
>time I would like to know what is maximum of info.

I've often used SYSPARM to control assembling for different
environments. I use a parsing macro up front to set several globals
and then use those globals in my other macros and open code.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Head's Up - zIIP issue OA17458/UA28419

[Thomas, Jim]

Peter, 
 
I concur with Ed. 
 
Put in another light, validation for eye-catcher's, flag bit's and the likes, 
have been around for decades and has thus far been a reliable 
and dependant way for decades. Perhaps more importantly, it's the only reliable 
avenue. 
 
Infact, if I may, I'd have to say that the practice is relatively the same even 
internally, to the big blue. 
 
Once more, in line w/Ed, if this philosophy changed .. I'd imagine lot's of 
software would break .. to include big blue's code !!. 
 
 
Kind Regards.
 
Jim Thomas
The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it. 

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

Re: Head's Up - zIIP issue OA17458/UA28419

[Schiradin,Roland HG-Dir itb-db/dc]

As of now SHOWzOS has been changed to handle this. 
I agree with ED but can't wait for such kind of discussion and it seems
IBM wont change this. I also guess a lot of source code and release dependent
code might fail because of this. 

Roland

-Original Message-
From: IBM Mainframe Discussion List 
[mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe
Sent: Sunday, August 27, 2006 6:34 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Head's Up - zIIP issue OA17458/UA28419


Peter Relson wrote:
> I can only say "I am astonished" that someone would code based on the 
> presence of a field name. We have every right to define fields in any 
> level of macros that are convenient.
>   

And, I'm astonished at your astonishment!

The technique of testing for the presence of control block fields at 
assembly time e.g., AIF (NOT D'CVTH) to skip around 
release-dependent code for source-maintained products has been a 
standard practice for _decades_ -- ever since the introduction of 
Assembler H (IEV90)! Simply assemble the product against the proper 
maclibs for the target system and all is well.

If this pervasive and well-established technique becomes unreliable, I 
predict *lots* of software will break!

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

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

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

Re: Head's Up - zIIP issue OA17458/UA28419

[Edward Jaffe]

Peter Relson wrote:

I can only say "I am astonished" that someone would code based on the
presence of a field name. We have every right to define fields in any level
of macros that are convenient.
  


And, I'm astonished at your astonishment!

The technique of testing for the presence of control block fields at 
assembly time e.g., AIF (NOT D'CVTH) to skip around 
release-dependent code for source-maintained products has been a 
standard practice for _decades_ -- ever since the introduction of 
Assembler H (IEV90)! Simply assemble the product against the proper 
maclibs for the target system and all is well.


If this pervasive and well-established technique becomes unreliable, I 
predict *lots* of software will break!


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

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

Re: Head's Up - zIIP issue OA17458/UA28419

[Schiradin,Roland HG-Dir itb-db/dc]

This was the best way to detect the level of operating system at assembly time.
So I was able to assemble at the highest level and run it on "several" older 
version. Also this works for several years (+10 or even more). 

Well checking the runtime wouldn't assemble clean if running on older version. 
 AIF   (NOT D'CVTH7720).SPLVL31S
 TMCVTOSLV5,CVTH7720   z/OS R7? 
 JZSPLVL31Sno, jump 

Wlll look at the SYSSTATE TEST as this sounds to be a very good idea

Roland



-Original Message-
From: IBM Mainframe Discussion List 
[mailto:[EMAIL PROTECTED] On Behalf Of Peter Relson
Sent: Saturday, August 26, 2006 10:05 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Head's Up - zIIP issue OA17458/UA28419


I can only say "I am astonished" that someone would code based 
on the presence of a field name. We have every right to define 
fields in any level of macros that are convenient.

This will almost certainly not be changed.

For what it's worth, you can probably use
SYSSTATE_OSREL, created via SYSSTATE TEST as of z/OS 1.8 (and 
shipped also into JBB77S9 and JBB772S) to indicate the release 
of the macro.

If SYSSTATE_OSREL has no value, then your old check will 
probably work (no guarantees). If it has a value, then consider 
using it.

This issue really has nothing do with the APAR, which is hiper, 
and refers to the fact that the bit CVTZOS_010700 / CVTZOS_V1R7 
/ CVTH7720  (they're all the same bit) is incorreclty on, so 
any runtime determination looking for "am I on z/OS 1.7 or 
later" would be misled.

Peter Relson
z/OS Core Technology Design

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

Re: Head's Up - zIIP issue OA17458/UA28419

[Peter Relson]

I can only say "I am astonished" that someone would code based on the
presence of a field name. We have every right to define fields in any level
of macros that are convenient.

This will almost certainly not be changed.

For what it's worth, you can probably use
SYSSTATE_OSREL, created via SYSSTATE TEST as of z/OS 1.8 (and shipped also
into JBB77S9 and JBB772S) to indicate the release of the macro.

If SYSSTATE_OSREL has no value, then your old check will probably work (no
guarantees). If it has a value, then consider using it.

This issue really has nothing do with the APAR, which is hiper, and refers
to the fact that the bit CVTZOS_010700 / CVTZOS_V1R7 / CVTH7720  (they're
all the same bit) is incorreclty on, so any runtime determination looking
for "am I on z/OS 1.7 or later" would be misled.

Peter Relson
z/OS Core Technology Design

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

Re: Head's Up - zIIP issue OA17458/UA28419

[Schiradin,Roland HG-Dir itb-db/dc]

>Maybe I'm too tired this evening. I can't see how testing for 
>the existence of a symbol at assembly time tells you anything 
>about the runtime system level.
Checking the runtime level happen during runtime but at assembly 
time I would like to know what is maximum of info. This means I can
assmble on z/OS R7 with all the news but still run on z/OS R6. 

>What is IPACEE and why do you need its offset?
It's just one sample and IPACEE provide the CEEPRM member suffix

>Could you change the AIF to check for D'IPACEE (assuming you've 
>previously expanded the IPAPDESC dsect map)?
Yep but this require a large change and yes I read the thread about this.
However like others I prefer to have the "unprinted" DSECTS at the end.
I know you prefer the beginning and now I see why :-))

Roland




-Original Message-
From: IBM Mainframe Discussion List 
[mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey D. Smith
Sent: Saturday, August 26, 2006 5:36 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Head's Up - zIIP issue OA17458/UA28419



Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/

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

Re: Head's Up - zIIP issue OA17458/UA28419

[Jeffrey D. Smith]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Schiradin,Roland HG-Dir itb-db/dc
> Sent: Friday, August 25, 2006 9:22 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Head's Up - zIIP issue OA17458/UA28419
> 
> Well this ptf just fix a part of the problem. Since
> JBB77S9 the CVT defines
> 
> CVTOSLV5 DCXL1'00'   BYTE 5 OF CVTOSLVL
> CVTZOSE  EQU   X'80' z/OS.e
> CVTZOSAS EQU   X'80' z/OS.e
> CVTPUMA  EQU   X'80' z/OS.e
> CVTZOS_010700 EQU X'40'  z/OS V1R7
> CVTZOS_V1R7   EQU X'40'  z/OS V1R7
> CVTH7720 EQU   X'40' HBB7720
> 
> so any conditional assembly like SHOWzOS use will fail because
> 
>  AIF   (NOT D'CVTH7720).IPA300A z/OS R7?
>  DCC'CEE ',AL2(IPACEE-IPAPDESC)
> .IPA300A ANOP
> 
> this is true even you're not running on z/OS R7  and IPACEE doesn't
> exist before z/OS R7. Based on this the assembly will ends with RC8.

Maybe I'm too tired this evening. I can't see how testing for the
existence of a symbol at assembly time tells you anything about
the runtime system level.

What is IPACEE and why do you need its offset?

Could you change the AIF to check for D'IPACEE (assuming you've
previously expanded the IPAPDESC dsect map)?

> I have no idea how to fix this issue in SHOWzOS. Hopefully other products
> or IBM software have the same problem.
> 
> 
> Regards Roland
/snip/

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/

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

Re: Head's Up - zIIP issue OA17458/UA28419

[Schiradin,Roland HG-Dir itb-db/dc]

Well this ptf just fix a part of the problem. Since
JBB77S9 the CVT defines

CVTOSLV5 DCXL1'00'   BYTE 5 OF CVTOSLVL  
CVTZOSE  EQU   X'80' z/OS.e  
CVTZOSAS EQU   X'80' z/OS.e  
CVTPUMA  EQU   X'80' z/OS.e  
CVTZOS_010700 EQU X'40'  z/OS V1R7   
CVTZOS_V1R7   EQU X'40'  z/OS V1R7   
CVTH7720 EQU   X'40' HBB7720 

so any conditional assembly like SHOWzOS use will fail because

 AIF   (NOT D'CVTH7720).IPA300A z/OS R7? 
 DCC'CEE ',AL2(IPACEE-IPAPDESC)  
.IPA300A ANOP

this is true even you're not running on z/OS R7  and IPACEE doesn't exist 
before z/OS R7. Based on this the assembly will ends with RC8.

I have no idea how to fix this issue in SHOWzOS. Hopefully other products or 
IBM software have the same problem. 


Regards Roland


-Original Message-
From: IBM Mainframe Discussion List 
[mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden
Sent: Tuesday, August 22, 2006 6:07 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Head's Up - zIIP issue OA17458/UA28419


This may have been mentioned already, but according to the APAR 
text the PTF is now available.  It only affects systems with 
zIIP support
installed on z/OS 1.6 (JBB77S9).   

If you are an FDRCPK user and don't get their email /newsletter 
notifications, contact Innovation for details on how this may affect 
you.

  APAR Identifier .. OA17458  Last Changed  06/08/22
  JBB77S9 CVT +X'4F5' CVTOSLV5 HAS CVTZOS_V1R7 ON.
 
 

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