Re: TSO User ID Rules (Was: z/OS and code pages)

[Timothy Sipples]

Paul Gilmartin wrote:
>The antiquated TSO restriction is armament for managers
>who oppose moving applications to z/OS.

Microsoft Windows supports only 26 drive letters, an "antiquated
restriction" lifted from CP/M. CP/M might have inherited drive letters from
CP/CMS (minidisks). CP/M debuted 43 years ago. Microsoft Windows also still
has 80 column command line windows. The 80 column width dates back to 1928
with IBM's introduction of 80 column punched cards. Are these "antiquated
restrictions" problems? In fairness, no. Windows has supported volume mount
points for many years, and the use of drive letters is optional or at least
trivial. You get 26 drive letter "shortcuts" to spend wisely (and to keep
certain older applications happy), but you don't need those shortcuts to
access storage. Volume mount point names can also be short if you wish, and
volume spanning means the single Drive Q (or whatever) can cross multiple
disks. Moreover, although 80 column command line windows are the default
and quite common, there's no obligation to use them, especially in typical
end user situations with mice, touch screens, proportional fonts, pull down
menus, etc.

It's the same with z/OS. The O in TSO is "Option," after all. When I use
Cognos to get some reports from a DB2 data warehouse, I'm using z/OS a
great deal but not using TSO at all. (And my user ID is quite lengthy.)
z/OS systems serve billions of users, but the vast majority don't have TSO
IDs.

That said, it'd be "nice" if TSO-compliant IDs had no additional
constraints. It'd also be nice to have more than 26 drive letters in
Windows.

I cannot think of a platform that does not have "antiquated restrictions."
To pick another example, Apple just introduced the iPhone 7. The iPhone 7
has several antiquated restrictions. One of them is the number of display
pixels. Even though competing smartphones have more pixels and more dense
pixel counts, Apple hasn't budged since the "antiquated" iPhone 6. (And the
iPhone 6 pixel count and density was heavily constrained based on prior
decisions.) That's because application compatibility is quite important.
Changing the number of pixels now, "too soon," would break too many
applications.

There are *always* political arguments available, mostly dumb ones, if
that's somebody's thing. Do the hypothetical restrictions matter?
Occasionally yes, usually no. If you're struggling to port an application
to TSO (specifically) because of TSO's user ID length limit -- or if the
TSO user ID limit is otherwise preventing you from getting something
business-valuable done -- please let "your friendly IBM representative"
know.

Tony Harminc wrote:
>What, in this context, is an MVS subsystem? ...And where is this
>text from -- evidently not the RACF Security Administrator's Guide?

You are allowed to take a look at the Administrator's Guide. :) But here's
a copy/paste:

"TSO and MVS also require that the first character of user IDs be uppercase
A - Z, # (X'7B'), $ (X'5B'), or @ (X'7C')."

So what does "MVS" mean in this context? The Administrator's Guide doesn't
say. "Not z/OS UNIX System Services" is a reasonable answer, but it might
be a partial one.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

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

Re: serial numbers ... real and imagine

[Brian Westerman]

We don't use the fact that the hardware is emulated to decide whether or not to 
run, only how we will execute some functions.  So things will still work, just 
some things won't be as efficient.

BRian

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

Re: serial numbers ... real and imagine

[Brian Westerman]

It's actually very simple (as a vendor) to tell whether you are running on 
emulated hardware (i.e. under VM) or not.  

I can look up the logic if you need it, but we do it with our software to 
decide whether or not to take advantage of features of the operating system or 
not.  Under emulation, things don't always operate the same or as fast. 

Brian

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

Re: RACF Digital Certificates

[Elardus Engelbrecht]

Dean (Dno) wrote:

>We generated a certificate with an NOTAFTER date of 2026-12-31. 

Pleas show us the commands used to generate that Cert.

>When the REXX exec from SDFHSAMP is run using the NOTAFTER date, RACF 
>complains about an invalid date range and generates the ring entry for the 
>userid as NOTRUST. 

Please post all messages from RACF including the one about date range. [1]

>I read some old threads but was not clear on what the solution was.
>Any thoughts?

Perhaps you can also post your question on RACF-L. 

Groete / Greetings
Elardus Engelbrecht

[1] - It could be that your system is asking for date like -mm-dd for 
example, but you gave -dd-mm or something  like that.

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

Re: Bypassing s322

[Bill Woodger]

It is not so much what I mean, as what the Principles of Operations means.

"The sign of the product is determined by the rules of algebra from the 
multiplier and multiplicand signs, even if one or both operands are zeros."

It is the old "two negatives make a positive, two positives make a positive, 
positive and negative make a negative" that you learned at school just to know 
the sign of the result.

There is no reference to zero in the "rules of algebra" as remembered from 
around 45 years ago, we should have asked at the time. 

Perhaps a bit of code on the chip to say "negative zero, I'm not having that, 
become positive" would be pointless overhead?

Divide says, in a note on an example, "Because the dividend and divisor have 
different signs, the quotient receives a negative sign."

Addition and subtraction have no such rule, so zero is just (positive) zero out 
of those.

So, Enterprise COBOL is wont at add a "ZAP-to-itself" when there is a danger 
that a result field (from calculation or truncation) may have produced a 
negative zero.

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

Re: Capture REXX/CLIST software usage.

[Anthony Thompson]

Maybe you can add your REXX/CLIST libraries to VLF and use SMF type 41 records 
to see which ones are being called.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Massimo Biancucci
Sent: Wednesday, 14 September 2016 7:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Capture REXX/CLIST software usage.

Hi everybody,

I'm wondering what's (if it's reasonable) the best way to capture usage of 
REXX/CLIST member.

For LOAD member it's possible to "monitor" some SVC and capture the information 
(like TADz).

I've tried to run a simple JCL:

//ST003EXEC  PGM=IKJEFT01
//SYSPROC  DD DSN=myexec,DISP=SHR
//SYSTSPRT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSTSIN  DD *
 %TEST
/*

and capture with a GTF all the SVCs called.

I'm expecting at least a BLDL but nothing.

The goal is to know what piece of software are used and, in a statistic way, 
clean the libraries from unused software,

Any idea ?

Thanks a lot for your support.
Massimo

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

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

Re: SMP/E Receive FROMNETWORK

[Paul Gilmartin]

On Wed, 14 Sep 2016 14:49:44 -0700, Lizette Koehler wrote:
>
>Also HTTPS is much easier than FTPS
> 
Particularly in that firewalls tend to be friendlier to HTTPS.
It's cultural.  If they block FTPS, a few impacted IT
personnel would be voices crying in the wilderness.  If they
block HTTPS, the CEO complains within the hour about the
inaccessibility of Amazon.

-- gil

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

Re: Bypassing s322

[Joel C. Ewing]

On 09/14/2016 05:09 PM, Bill Woodger wrote:
> Yes, "the rules of algebra" has lead to a minus zero... but it is still zero, 
> the sign for zero has no significance in algebra.
>
> In two's-complement, there is no negative zero.
>
> In packed-decimal 'rithmetic, there is, as explained in the PoP. The sign of 
> the result is according to the rules of algebra, even when the result is zero.
>
>
I'm not sure what you mean by "the rules of algebra" lead to minus
zero.  In algebra and mathematics "0" is "0", neither positive or
negative.   A signed zero is not a concept in algebra but purely an
artifact of the way we choose to represent the abstract concept of real
and natural numbers on a physical device -- namely, the choice of a
sign-magnitude representation, with one bit reserved for sign.  The sign
bit is meaningless mathematically for a zero magnitude value but must
still have some state in the physical representation for the number.. 
Some architectures may choose to allow such "-0" values to have special
meaning rather than ever allowing it to be used as a zero value in a 
computation or be generated for a zero result.
Joel C. Ewing

-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

RACF Digital Certificates

[Dno]

Hi,

We generated a certificate with an NOTAFTER date of 2026-12-31. 

When the REXX exec from SDFHSAMP is run using the NOTAFTER date, RACF complains 
about an invalid date range and generates the ring entry for the userid as 
NOTRUST. 

No idea why, and have tried several different times, using different NOTAFTER 
dates. 

I read some old threads but was not clear on what the solution was.

Any thoughts?

Thanks,
Dean

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

Re: Bypassing s322

[Bill Woodger]

Yes, "the rules of algebra" has lead to a minus zero... but it is still zero, 
the sign for zero has no significance in algebra.

In two's-complement, there is no negative zero.

In packed-decimal 'rithmetic, there is, as explained in the PoP. The sign of 
the result is according to the rules of algebra, even when the result is zero.

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

Re: Bypassing s322

[Bill Woodger]

Yes, the compiler generates additional code to ensure that a -ve zero cannot be 
the result of anything in COBOL. This was discussed fairly recently here. The 
machine instructions obey the rules of algebra, COBOL doesn't as they apply to 
zero. Minus five times zero is zero, and always positive (in a signed field, 
irrelevant for an unsigned field).

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

CA Technologies LMP key at DR sites (WAS: serial numbers ... real and imagine)

[Longabaugh, Robert E]

Here are selected results from a search on "disaster recovery lmp site:ca.com". 
 These Knowledge Base articles should clarify that recovery can proceed without 
having the correct recovery site LMP key in advance of a disaster drill, or if 
the CPU serial is different than the one that the LMP key was generated for. 

These articles were written by different product groups but apply across the 
board since products call CA Common Services for LMP checking.

What will happen if I don't have valid LMPKEYs for my Disaster Recovery site?
http://www.ca.com/us/support/ca-support-online/product-content/knowledgebase-articles/tec471961.aspx

How can LMP keys be obtained in an emergency?
http://www.ca.com/us/support/ca-support-online/product-content/knowledgebase-articles/tec476815.aspx


Bob Longabaugh
CA Technologies 
Storage Management


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve
Sent: Wednesday, September 14, 2016 2:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: serial numbers ... real and imagine


Must of us have too many ethics to violate anything associated with M/F 
Licensing
 
Steve  
 
 
-Original Message-
From: "Dana Mitchell" 
Sent: Wednesday, September 14, 2016 2:55pm
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: serial numbers ... real and imagine



Falls under one of my favorite sayings:

Never ascribe to malice that which can be adequately explained by stupidity. 

Or the British version: cock-up before conspiracy

Dana


>On Wed, Sep 14, 2016 at 11:48 AM, Charles Mills  wrote:
>
>> Speaking as a vendor here -- and at the risk of flames -- it's not 
>> just "bad" customers. With the amount of outsourcing, turnover, 
>> overwork and layoffs of skilled people we were seeing a fair amount of 
>> "inadvertent"
>> license violation before we implemented the serial number check. 
>> Junior sysprogs or managers who just assumed they could install the 
>> software on another LPAR.
>>

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

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

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

Re: Bypassing s322

[Charles Mills]

Way OT, but does "algebra" recognize +/-0? Or is that just an artifact of 
packed notation (which is itself an artifact of Hollerith cards)?

What is -5 * 0 in fullword arithmetic? SURELY not -0.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Wednesday, September 14, 2016 2:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bypassing s322

On 14 September 2016 at 16:34, Bill Woodger  wrote:

> When IBM decided to use "character" comparisons where possible for numerics, 
> they had to ban the negative zero.
> Although in a decimal compare a zero is zero, no matter how signed, in 
> a character compare it is not. Ergo -ve zero could not be allowed to 
> exist. (you can of course screw things up by being deliberate, but no 
> calculation in COBOL will ever generate a -ve zero result, nor will any 
> truncation).

So in COBOL, +0 times -5 is +0, i.e the rules of algebra don't apply?
The generated code must go out of its way to accomplish this.

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

Re: SMP/E Receive FROMNETWORK

[Lizette Koehler]

Search the IBMMAIN Archives, there are many examples of how to change this to
work.  There are a lot of threads. 

Many control examples.  No real JCL changes.


Also HTTPS is much easier than FTPS 

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lopez, Sharon
> Sent: Wednesday, September 14, 2016 1:09 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SMP/E Receive FROMNETWORK
> 
> We are trying to SMP/E RECEIVE FROMNETWORK and we are getting the message that
> SSL is mandatory.  Does anyone have any sample JCL they would like to share?
> Did the entire process change?
> 
> Thanks in advance.

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

Re: Bypassing s322

[Tony Harminc]

On 14 September 2016 at 16:34, Bill Woodger  wrote:

> When IBM decided to use "character" comparisons where possible for numerics, 
> they had to ban the negative zero.
> Although in a decimal compare a zero is zero, no matter how signed, in a 
> character compare it is not. Ergo -ve zero could
> not be allowed to exist. (you can of course screw things up by being 
> deliberate, but no calculation in COBOL will ever
> generate a -ve zero result, nor will any truncation).

So in COBOL, +0 times -5 is +0, i.e the rules of algebra don't apply?
The generated code must go out of its way to accomplish this.

Tony H.

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

Re: Bypassing s322

[Bill Woodger]

Very old Mainframe COBOLs did allow -ve zero to exist. 

The test for a zero where the source may have been a negative zero should have 
been unproblematic, because at the time only "decimal" instructions were used 
for numeric comparisons in the code generated by the compiler. And zero is zero.

When IBM decided to use "character" comparisons where possible for numerics, 
they had to ban the negative zero. Although in a decimal compare a zero is 
zero, no matter how signed, in a character compare it is not. Ergo -ve zero 
could not be allowed to exist. (you can of course screw things up by being 
deliberate, but no calculation in COBOL will ever generate a -ve zero result, 
nor will any truncation).

There's lots of ways the problem being talked about probably happened: PIC 99 
and test for greater than 100 is a good one. PIC 9(4) and with subtraction, 
test for less than zero. One of my favourites "ADD ONE TO somefield" where 
data-name ONE is defined with VALUE ZERO. 

How about this fun one. Job running a long time, so someone decides to cancel 
it. Investigation reveals that it was processing the final record on the file. 
Some bright spark says "it's a pity we cancelled it, it had nearly finished, 
let's submit it again..." and they were going to. The loop was in processing 
some accumulated totals, and was of the type mentioned above. I think the job 
was originally cancelled after about three hours. With the code corrected, it 
ran in under 10 minutes. I had only arrived at the final conversation. One of 
those moments when you feel you've stepped into some sort of alternate 
Universe...

And don't ask how it got through testing...

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

Re: Bypassing s322

[John McKown]

On Wed, Sep 14, 2016 at 3:08 PM, Gibney, Dave  wrote:

> It's been 35 years :) It might even have been a packed field. But it did
> loop because the negative representation of zero did not match the zero the
> code was looping unitl :)
>
>

​Oh, yeah, a packed negative zero, 0x0D​

​, might not get recognized in a COBOL program. I don't remember the
compile options back then, but I think there was one which said "all zones
are correct" and the code would do a CLC instead of a CP because it was
faster on the machine.​


-- 
Unix: Some say the learning curve is steep, but you only have to climb it
once. -- Karl Lehenbauer
Unicode: http://xkcd.com/1726/

Maranatha! <><
John McKown

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

Re: SMP/E Receive FROMNETWORK

[Lopez, Sharon]

We are looking at that now.  Which is the recommended way?  We will probably do 
FTPS.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Jacobs - Listserv
Sent: Wednesday, September 14, 2016 4:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E Receive FROMNETWORK

Have you setup ftps or https for SMP/E downloads?

> Lopez, Sharon  September 14, 2016 at 4:08
> PM We are trying to SMP/E RECEIVE FROMNETWORK and we are getting the
> message that SSL is mandatory. Does anyone have any sample JCL they
> would like to share? Did the entire process change?
>
> Thanks in advance.
>
> 
>
> Email correspondence to and from this address may be subject to the
> North Carolina Public Records Law and may be disclosed to third
> parties by an authorized state official.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> Please be alert for any emails that may ask you for login information
> or directs you to login via a link. If you believe this message is a
> phish or aren't sure whether this message is trustworthy, please send
> the original message as an attachment to 'phish...@timeinc.com'.
>

--

Mark Jacobs
Time Customer Service
Technology and Product Engineering

The standard you walk past is the standard you accept.
Lt. Gen. David Morrison


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



Email correspondence to and from this address may be subject to the North 
Carolina Public Records Law and may be disclosed to third parties by an 
authorized state official.

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

Re: SMP/E Receive FROMNETWORK

[Mark Jacobs - Listserv]

Have you setup ftps or https for SMP/E downloads?


Lopez, Sharon 
September 14, 2016 at 4:08 PM
We are trying to SMP/E RECEIVE FROMNETWORK and we are getting the 
message that SSL is mandatory. Does anyone have any sample JCL they 
would like to share? Did the entire process change?


Thanks in advance.



Email correspondence to and from this address may be subject to the 
North Carolina Public Records Law and may be disclosed to third 
parties by an authorized state official.


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


Please be alert for any emails that may ask you for login information 
or directs you to login via a link. If you believe this message is a 
phish or aren't sure whether this message is trustworthy, please send 
the original message as an attachment to 'phish...@timeinc.com'.




--

Mark Jacobs
Time Customer Service
Technology and Product Engineering

The standard you walk past is the standard you accept.
Lt. Gen. David Morrison


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

Re: Bypassing s322

[Gibney, Dave]

It's been 35 years :) It might even have been a packed field. But it did loop 
because the negative representation of zero did not match the zero the code was 
looping unitl :)

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of John McKown
> Sent: Wednesday, September 14, 2016 1:00 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Bypassing s322
> 
> On Wed, Sep 14, 2016 at 2:51 PM, Gibney, Dave  wrote:
> 
> > Once, in my first months here, a program appeared to be looping, but
> > maybe not. It was impacting the system, but I insisted it be allowed
> > to run and it was for a while.
> > It was a Cobol program. Perform until some COMP field reached zero.
> > The Cobol of the time did not recognize negative zero (X'8000')
> > in a COMP field as zero.
> >
> >
> ​Hum, x'8000' in 2-complement binary is not -0, it is
>  -2,147,483,648
> ​ . ref:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__en.wikipedia.org_wiki_32-
> 2Dbit&d=DQIFaQ&c=C3yme8gMkxg_ihJNXS06ZyWk4EJm8LdrrvxQb-
> Je7sw&r=u9g8rUevBoyCPAdo5sWE9w&m=vyEGno2UwsNi3TyWCpgDmFCJ2r
> oOpPY30QnpZVR9LCw&s=Ch2PMt6L1Xyzxt5izQlcs9D87adUiSxqt9pH-
> GMLK9w&e=
> ​
> ​
> 
> 
> 
> --
> Unix: Some say the learning curve is steep, but you only have to climb it
> once. -- Karl Lehenbauer
> Unicode: https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__xkcd.com_1726_&d=DQIFaQ&c=C3yme8gMkxg_ihJNXS06ZyWk4EJm8L
> drrvxQb-
> Je7sw&r=u9g8rUevBoyCPAdo5sWE9w&m=vyEGno2UwsNi3TyWCpgDmFCJ2r
> oOpPY30QnpZVR9LCw&s=uulDZEnFlqF00D7MI1Lfc-
> nYsxV9EQKC0VSYBXwe590&e=
> 
> Maranatha! <><
> John McKown
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

SMP/E Receive FROMNETWORK

[Lopez, Sharon]

We are trying to SMP/E RECEIVE FROMNETWORK and we are getting the message that 
SSL is mandatory.  Does anyone have any sample JCL they would like to share?  
Did the entire process change?

Thanks in advance.



Email correspondence to and from this address may be subject to the North 
Carolina Public Records Law and may be disclosed to third parties by an 
authorized state official.

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

Re: Bypassing s322

[John McKown]

On Wed, Sep 14, 2016 at 2:51 PM, Gibney, Dave  wrote:

> Once, in my first months here, a program appeared to be looping, but maybe
> not. It was impacting the system, but I insisted it be allowed to run and
> it was for a while.
> It was a Cobol program. Perform until some COMP field reached zero. The
> Cobol of the time did not recognize negative zero (X'8000')  in a COMP
> field as zero.
>
>
​Hum, x'8000' in 2-complement binary is not -0, it is
 -2,147,483,648
​ . ref:
https://en.wikipedia.org/wiki/32-bit
​
​



-- 
Unix: Some say the learning curve is steep, but you only have to climb it
once. -- Karl Lehenbauer
Unicode: http://xkcd.com/1726/

Maranatha! <><
John McKown

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

Re: Bypassing s322

[Gibney, Dave]

Once, in my first months here, a program appeared to be looping, but maybe not. 
It was impacting the system, but I insisted it be allowed to run and it was for 
a while.
It was a Cobol program. Perform until some COMP field reached zero. The Cobol 
of the time did not recognize negative zero (X'8000')  in a COMP field as 
zero.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Elardus Engelbrecht
> Sent: Wednesday, September 14, 2016 5:30 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Bypassing s322
> 
> Scott Chapman wrote:
> 
> >Of course, when anybody came to me complaining about an S322, assuming
> it was already in one of the classes that allowed them to get the max we
> allowed of 1 or 2 hours of CPU time, my first reaction was always something
> along the lines of "Are you sure you aren't looping? Are you sure you don't
> have a tuning opportunity that needs to be fixed?" An hour of CPU time is
> usually a whole lot of work.
> 
> Agreed.
> 
> Watch the CPU usage of that job. If it is very high in relation of the other
> tasks, then there is a possible loop. Or lots of I/Os. Or you see excessive 
> SMF
> records being written. Or you see that job is spitting out gazillion lines.
> 
> Scott, I would go the same tuning route as you (and slap that complainer hard
> and loud. ;-D )
> 
> Groete / Greetings
> Elardus Engelbrecht
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: REASON: 3 - RECORD TYPE NOT RECOGNIZED

[Gibney, Dave]

Also consider asking for a trial of CR+ (now with Rocket) or Dinosoft's catalog 
maintenance product.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Lizette Koehler
> Sent: Wednesday, September 14, 2016 10:34 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: REASON: 3 - RECORD TYPE NOT RECOGNIZED
> 
> I would probably open an SR with IBM on DFSMS VSAM - any actions taken
> might require their assistance to recover.  Better to have them look and help
> provide the right guidance.
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of willie bunter
> > Sent: Wednesday, September 14, 2016 4:33 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: REASON: 3 - RECORD TYPE NOT RECOGNIZED
> >
> > The DIAGNOSE gives the same error and no change.  I ran examine (using
> > the following parms) and " NO ERRORS DETECTED"
> >
> > INDEXTEST DATATEST
> > ITEST NODATATEST ERRORLIMIT(1000)
> > NOITEST DATATEST ERRORLIMIT(1000)
> >
> > I ran LISTCAT against the CATALOG and it flagged the same VSAM dsn
> > posting the following error messages:
> > IEC331I 028-002,LISTCAT ,STEP1   ,IGG0CLEG
> > According to the problem explanation
> > Explanation: An I/O error processing the catalog occurred while
> > processing an access method services command that requires modifying
> > the catalog.
> > Programmer Response: Messages IEC331I, IEC332I, and IEC333I have been
> > printed to aid in determining the cause of the error and where the
> > error occurred. If a hardware error is not causing the problem,
> > restore or rebuild the catalog.
> >
> > I have read up on the process of rebuilding the catalog (REPRO
> > MERGECAT) however there could be a problem when using LEVEL or
> ENTRIES
> > parm.  According to the doc "may cause data sets to no longer be
> > found".  This is not reassuring.
> >
> > I would prefer to restore the CATALOG which seems safer.  I would like
> > guidance on this subject.
> >
> > Thanks.
> > 
> > On Tue, 9/13/16, retired mainframer 
> wrote:
> >
> >  Subject: Re: REASON: 3 - RECORD TYPE NOT RECOGNIZED
> >  To: IBM-MAIN@LISTSERV.UA.EDU
> >  Received: Tuesday, September 13, 2016, 1:01 PM
> >
> >  > -Original
> >  Message-
> >  > From: IBM Mainframe
> >  Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]  On  > Behalf Of
> > willie bunter  > Sent: Tuesday, September 13, 2016 9:01  AM  > To:
> > IBM- m...@listserv.ua.edu  > Subject: REASON: 3 - RECORD TYPE NOT
> > RECOGNIZED  >  > Hi  All,  >  > While  running a DIAGNOSE on a USERCAT
> > the following error was picked up:
> >  >
> >  >
> >  IDC21364I ERROR DETECTED BY DIAGNOSE:
> >  >   ICFCAT ENTRY: 05:26:06.214
> >  UTMOPB08: START TWRC MSGID(AFE7 (7)
> >  >   RECORD: 05:26:06.214
> >  UTMOPB08: START TWRC MSGID(AFE7 /F0
> >  >   OFFSET: X'0002'
> >  >   REASON: 3 - RECORD TYPE NOT
> >  RECOGNIZED
> >  > IDC21365I ICFCAT RECORD
> >  DISPLAY:
> >  >   RECORD:
> >  05:26:06.214 UTMOPB08: START TWRC MSGID(AFE7 /F0  >  > The
> programmer
> > response (I hope I read it right) says  >  Use DELETE NOSCRATCH to
> > remove the sphere or base record, if  it exists.
> >  >
> >  > I have
> >  2 questions:
> >  > Since the dsn is not
> >  listed in the job output after IDC21364i message I assume  that the
> > dsn -  > listed on side (cols 85  to 119) -  > I assume that is the dsn in
> question.
> > Please correct me if I am wrong.
> >  >
> >  > Is this problem
> >  serious or it can wait for action to be taken?  The problem  was
> > detected  > about 10 days ago.
> >
> >  You have already waited ten
> >  days and not yet taken any action.  Has there been any  noticeable
> > impact?  If you run the DIAGNOSE again, do the  results change?  For
> > better or worse?
> >
> >  Were other activities that use the catalog  running at the same time
> > as your DIAGNOSE?  When I was  running EXAMINE jobs to confirm
> > consistency between catalogs  and VVDSs, I determined that some
> > reported errors were  transient and could be eliminated by executing
> > the VERIFY  command just prior to the EXAMINE.  I don't know if the  same
> issue could affect DIAGNOSE.
> >
> >  If it is a permanent error, I would be more  concerned with how it
> > occurred and what to do to prevent it  in the future.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Capture REXX/CLIST software usage.

[Gibney, Dave]

Update each member with a call rexx_monitor directly after the /* rexx */

:)

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Lizette Koehler
> Sent: Wednesday, September 14, 2016 10:37 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Capture REXX/CLIST software usage.
> 
> What problem are you trying to solve.
> 
> The more you monitor the slower it can get.
> 
> Are you trying to identify who is using what?
> 
> Are you trying to identify who is a consumer of resources?
> 
> ??
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Massimo Biancucci
> > Sent: Wednesday, September 14, 2016 3:05 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Capture REXX/CLIST software usage.
> >
> > Hi everybody,
> >
> > I'm wondering what's (if it's reasonable) the best way to capture
> > usage of REXX/CLIST member.
> >
> > For LOAD member it's possible to "monitor" some SVC and capture the
> > information (like TADz).
> >
> > I've tried to run a simple JCL:
> >
> > //ST003EXEC  PGM=IKJEFT01
> > //SYSPROC  DD DSN=myexec,DISP=SHR
> > //SYSTSPRT DD SYSOUT=*
> > //SYSPRINT DD SYSOUT=*
> > //SYSTSIN  DD *
> >  %TEST
> > /*
> >
> > and capture with a GTF all the SVCs called.
> >
> > I'm expecting at least a BLDL but nothing.
> >
> > The goal is to know what piece of software are used and, in a
> > statistic way, clean the libraries from unused software,
> >
> > Any idea ?
> >
> > Thanks a lot for your support.
> > Massimo
> >
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: TSO User ID Rules (Was: z/OS and code pages)

[Tony Harminc]

On 14 September 2016 at 02:05, Timothy Sipples  wrote:

> (a) If you want your RACF ID to be usable within MVS subsystems, the first
> character cannot be a numeric digit (0 through 9).

What, in this context, is an MVS subsystem? And what does "to be
usable within MVS subsystems" mean? And where is this text from --
evidently not the RACF Security Administrator's Guide?

Tony H.

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

Re: ServerPAC/DB2

[Lizette Koehler]

How are you running the ServerPac install for DB2?

There is a member that explains how to run the process.  It tells you the jobs
to run to build the CPAC environment, then what jobs to run are specified in the
ISPF Dialog once the CPAC is installed.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Jodlowski
> Sent: Wednesday, September 14, 2016 12:26 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: ServerPAC/DB2
> 
> All:
> 
> I think a job did not run correctly for my DB2 ServerPac install.
> When I try to Apply check some maintenance I get the following message:
>  GIM24801S ** NO SYSMODS SATISFIED THE OPERANDS SPECIFIED ON THE APPLY
> COMMAND.
> 
> I REPORT SOURCEID ZONES(DB2T300) . and get NO SOURCEIDs ???
> 
> It looks like all the jobs ran as expected.
> Which job out of the ServerPac install updates SMPe target zone?
> 
> Thank you
> 

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

ServerPAC/DB2

[Paul Jodlowski]

All:

I think a job did not run correctly for my DB2 ServerPac install. 
When I try to Apply check some maintenance I get the following message:
 GIM24801S ** NO SYSMODS SATISFIED THE OPERANDS SPECIFIED ON THE APPLY COMMAND. 

I REPORT SOURCEID ZONES(DB2T300) . and get NO SOURCEIDs ??? 

It looks like all the jobs ran as expected. 
Which job out of the ServerPac install updates SMPe target zone? 

Thank you 

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

Re: z/OS and code pages

[Tony Harminc]

On 14 September 2016 at 14:53, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>>But Katakana shares the same hex values as lower case English letters. I have 
>>always had upper case User IDs and passwords. Perhaps it is a RACF 
>>restriction?
>>
> What technical concern (I presume there was one) motivated EBCDIC's
> usurping the Latin minuscule code points for non-Latin characters, rather
> than first employing the code points left uncommitted in the s360 Principles
> as the ISO8859-x family did?

Memory, or rather, lack thereof, presumably in the 3277 terminal and
its control unit. Plus IBM's famous early indifference to non-US
character requirements. Each country/region got a locally designed
(maybe even locally implemented, at first?) character set (glyph) ROM
and mapping table for the characters thought to be needed. Since the
3277 did not display lower case Latin letters anyway, it probably
seemed reasonable to use those positions for the fairly large Katakana
set. Perhaps keyboard mapping also contributed. If there existed
typewriters with both Latin and Katakana, that keystroke mapping with
the ability to lock the keyboard into one or the other mode would be
someting to be preserved.

Tony H.

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

Re: serial numbers ... real and imagine

[Steve]

Must of us have too many ethics to violate anything associated with M/F 
Licensing
 
Steve  
 
 
-Original Message-
From: "Dana Mitchell" 
Sent: Wednesday, September 14, 2016 2:55pm
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: serial numbers ... real and imagine



Falls under one of my favorite sayings:

Never ascribe to malice that which can be adequately explained by stupidity. 

Or the British version: cock-up before conspiracy

Dana


>On Wed, Sep 14, 2016 at 11:48 AM, Charles Mills  wrote:
>
>> Speaking as a vendor here -- and at the risk of flames -- it's not just
>> "bad" customers. With the amount of outsourcing, turnover, overwork and
>> layoffs of skilled people we were seeing a fair amount of "inadvertent"
>> license violation before we implemented the serial number check. Junior
>> sysprogs or managers who just assumed they could install the software on
>> another LPAR.
>>

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

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

Re: serial numbers ... real and imagine

[Dana Mitchell]

Falls under one of my favorite sayings:

Never ascribe to malice that which can be adequately explained by stupidity.  

Or the British version:  cock-up before conspiracy

Dana


>On Wed, Sep 14, 2016 at 11:48 AM, Charles Mills  wrote:
>
>> Speaking as a vendor here -- and at the risk of flames -- it's not just
>> "bad" customers. With the amount of outsourcing, turnover, overwork and
>> layoffs of skilled people we were seeing a fair amount of "inadvertent"
>> license violation before we implemented the serial number check. Junior
>> sysprogs or managers who just assumed they could install the software on
>> another LPAR.
>>

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

Re: z/OS and code pages

[Paul Gilmartin]

On Wed, 14 Sep 2016 07:34:23 -0400, Cameron Conacher wrote:
>
>But Katakana shares the same hex values as lower case English letters. I have 
>always had upper case User IDs and passwords. Perhaps it is a RACF restriction?
> 
What technical concern (I presume there was one) motivated EBCDIC's
usurping the Latin minuscule code points for non-Latin characters, rather
than first employing the code points left uncommitted in the s360 Principles
as the ISO8859-x family did?

-- gil

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

Re: serial numbers ... real and imagine

[Paul Gilmartin]

On Wed, 14 Sep 2016 14:26:09 -0400, Steve wrote:
>
DR drills and testing are always free.  It part of the license agreement.  Its 
for a finite time
like 2 to 3 weeks  
 
For CA products you will have to provide license support with the type-model 
and serial  number
and they will send you the keys before hand
 
You need merely to anticipate your disaster.

-- gil

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

Re: serial numbers ... real and imagine

[Steve]

DR drills and testing are always free.  It part of the license agreement.  Its 
for a finite time
like 2 to 3 weeks  
 
For CA products you will have to provide license support with the type-model 
and serial  number
and they will send you the keys before hand
 
Steve 
 
 
-Original Message-
From: "Neubert, Kevin" 
Sent: Wednesday, September 14, 2016 1:50pm
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: serial numbers ... real and imagine



Some vendors provide automatic grace periods for their software per IPL, etc. 
and others flat out cease working. Based on your software, the prior may 
suffice for your needs. Regardless, I would acquire 
codes/keys/licenses/passwords, etc. beforehand and go from there. In my 
experience, I have never seen penalties for semiannual use of this type of 
support.

You may want to research the z/VM CPU/OPTION CPUID control statement(s) 
regarding the STIDP instruction, etc. and your software. I have seen a unique 
combination to me, where the vendor used the remote (DR) CPU model/model type 
and local (customer) processor identification number to generate the temporary 
authorization.

Regards,

Kevin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Adams, Anne (DTI)
Sent: Wednesday, September 14, 2016 9:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: serial numbers ... real and imagine

Hello friends,

How can I determine where a software product is pulling the serial number of 
the hardware? We'd like to be able to run a z/VM guest (for DR) with the same 
serial number as our current mainframe. That way we don’t have to call for 
temporary license keys. However, our DR provider has warned us that some 
products will interrogate the physical hardware rather than what the OS is 
holding or what I have in the iodf. Any way beforehand to see where those 
values are coming from?
Thanks.

Anne R Adams, CISSP
DTI, Systems Engineering
Sr. Mainframe Services Analyst
302.298.3196
 
This communication is for use by the intended recipient and contains 
information that may be Privileged, confidential or copyrighted under 
applicable law. If you are not the intended recipient, you are hereby formally 
notified that any use, copying or distribution of this e-mail, in whole or in 
part, is strictly prohibited. Please notify the sender by return e-mail and 
delete this e-mail from your system. Unless explicitly and conspicuously 
designated as "E-Contract Intended", this e-mail does not constitute a contract 
offer, a contract amendment, or an acceptance of a contract offer. This e-mail 
does not constitute a consent to the use of sender's contact information for 
direct marketing purposes or for transfers of data to third parties.



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

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

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

Re: serial numbers ... real and imagine

[Neubert, Kevin]

Some vendors provide automatic grace periods for their software per IPL, etc. 
and others flat out cease working.  Based on your software, the prior may 
suffice for your needs.  Regardless, I would acquire 
codes/keys/licenses/passwords, etc. beforehand and go from there.  In my 
experience, I have never seen penalties for semiannual use of this type of 
support.

You may want to research the z/VM CPU/OPTION CPUID control statement(s) 
regarding the STIDP instruction, etc. and your software.  I have seen a unique 
combination to me, where the vendor used the remote (DR) CPU model/model type 
and local (customer) processor identification number to generate the temporary 
authorization.

Regards,

Kevin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Adams, Anne (DTI)
Sent: Wednesday, September 14, 2016 9:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: serial numbers ... real and imagine

Hello friends,

How can I determine where a software product is pulling the serial number of 
the hardware? We'd like to be able to run a z/VM guest (for DR) with the same 
serial number as our current mainframe. That way we don’t have to call for 
temporary license keys. However, our DR provider has warned us that some 
products will interrogate the physical hardware rather than what the OS is 
holding or what I have in the iodf. Any way beforehand to see where those 
values are coming from?
Thanks.

Anne R Adams, CISSP
DTI, Systems Engineering
Sr. Mainframe Services Analyst
302.298.3196
 
This communication is for use by the intended recipient and contains 
information that may be Privileged, confidential or copyrighted under 
applicable law. If you are not the intended recipient, you are hereby formally 
notified that any use, copying or distribution of this e-mail, in whole or in 
part, is strictly prohibited. Please notify the sender by return e-mail and 
delete this e-mail from your system. Unless explicitly and conspicuously 
designated as "E-Contract Intended", this e-mail does not constitute a contract 
offer, a contract amendment, or an acceptance of a contract offer. This e-mail 
does not constitute a consent to the use of sender's contact information for 
direct marketing purposes or for transfers of data to third parties.



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

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

Re: REASON: 3 - RECORD TYPE NOT RECOGNIZED

[Lizette Koehler]

I would probably open an SR with IBM on DFSMS VSAM - any actions taken might 
require their assistance to recover.  Better to have them look and help provide 
the right guidance.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of willie bunter
> Sent: Wednesday, September 14, 2016 4:33 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: REASON: 3 - RECORD TYPE NOT RECOGNIZED
> 
> The DIAGNOSE gives the same error and no change.  I ran examine (using the
> following parms) and " NO ERRORS DETECTED"
> 
> INDEXTEST DATATEST
> ITEST NODATATEST ERRORLIMIT(1000)
> NOITEST DATATEST ERRORLIMIT(1000)
> 
> I ran LISTCAT against the CATALOG and it flagged the same VSAM dsn posting the
> following error messages:
> IEC331I 028-002,LISTCAT ,STEP1   ,IGG0CLEG
> According to the problem explanation
> Explanation: An I/O error processing the
> catalog occurred while processing an access
> method services command that requires
> modifying the catalog.
> Programmer Response: Messages IEC331I,
> IEC332I, and IEC333I have been printed to aid
> in determining the cause of the error and
> where the error occurred. If a hardware error
> is not causing the problem, restore or
> rebuild the catalog.
> 
> I have read up on the process of rebuilding the catalog (REPRO MERGECAT)
> however there could be a problem when using LEVEL or ENTRIES parm.  According
> to the doc "may cause data sets to no longer be found".  This is not
> reassuring.
> 
> I would prefer to restore the CATALOG which seems safer.  I would like
> guidance on this subject.
> 
> Thanks.
> 
> On Tue, 9/13/16, retired mainframer  wrote:
> 
>  Subject: Re: REASON: 3 - RECORD TYPE NOT RECOGNIZED
>  To: IBM-MAIN@LISTSERV.UA.EDU
>  Received: Tuesday, September 13, 2016, 1:01 PM
> 
>  > -Original
>  Message-
>  > From: IBM Mainframe
>  Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]  On  > Behalf Of willie
> bunter  > Sent: Tuesday, September 13, 2016 9:01  AM  > To: IBM-
> m...@listserv.ua.edu  > Subject: REASON: 3 - RECORD TYPE NOT  RECOGNIZED  >  >
> Hi  All,  >  > While  running a DIAGNOSE on a USERCAT the following error was
> picked up:
>  >
>  >
>  IDC21364I ERROR DETECTED BY DIAGNOSE:
>  >   ICFCAT ENTRY: 05:26:06.214
>  UTMOPB08: START TWRC MSGID(AFE7 (7)
>  >   RECORD: 05:26:06.214
>  UTMOPB08: START TWRC MSGID(AFE7 /F0
>  >   OFFSET: X'0002'
>  >   REASON: 3 - RECORD TYPE NOT
>  RECOGNIZED
>  > IDC21365I ICFCAT RECORD
>  DISPLAY:
>  >   RECORD:
>  05:26:06.214 UTMOPB08: START TWRC MSGID(AFE7 /F0  >  > The programmer
> response (I hope I read it right) says  >  Use DELETE NOSCRATCH to remove the
> sphere or base record, if  it exists.
>  >
>  > I have
>  2 questions:
>  > Since the dsn is not
>  listed in the job output after IDC21364i message I assume  that the dsn -  >
> listed on side (cols 85  to 119) -  > I assume that is the dsn in  question.
> Please correct me if I am wrong.
>  >
>  > Is this problem
>  serious or it can wait for action to be taken?  The problem  was detected  >
> about 10 days ago.
> 
>  You have already waited ten
>  days and not yet taken any action.  Has there been any  noticeable
> impact?  If you run the DIAGNOSE again, do the  results change?  For better or
> worse?
> 
>  Were other activities that use the catalog  running at the same time as your
> DIAGNOSE?  When I was  running EXAMINE jobs to confirm consistency between
> catalogs  and VVDSs, I determined that some reported errors were  transient
> and could be eliminated by executing the VERIFY  command just prior to the
> EXAMINE.  I don't know if the  same issue could affect DIAGNOSE.
> 
>  If it is a permanent error, I would be more  concerned with how it occurred
> and what to do to prevent it  in the future.

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

Re: Capture REXX/CLIST software usage.

[Lizette Koehler]

What problem are you trying to solve.

The more you monitor the slower it can get.

Are you trying to identify who is using what?

Are you trying to identify who is a consumer of resources?

?? 

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Massimo Biancucci
> Sent: Wednesday, September 14, 2016 3:05 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Capture REXX/CLIST software usage.
> 
> Hi everybody,
> 
> I'm wondering what's (if it's reasonable) the best way to capture usage of
> REXX/CLIST member.
> 
> For LOAD member it's possible to "monitor" some SVC and capture the
> information (like TADz).
> 
> I've tried to run a simple JCL:
> 
> //ST003EXEC  PGM=IKJEFT01
> //SYSPROC  DD DSN=myexec,DISP=SHR
> //SYSTSPRT DD SYSOUT=*
> //SYSPRINT DD SYSOUT=*
> //SYSTSIN  DD *
>  %TEST
> /*
> 
> and capture with a GTF all the SVCs called.
> 
> I'm expecting at least a BLDL but nothing.
> 
> The goal is to know what piece of software are used and, in a statistic way,
> clean the libraries from unused software,
> 
> Any idea ?
> 
> Thanks a lot for your support.
> Massimo
> 

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

Re: serial numbers ... real and imagine

[Lizette Koehler]

I would ask your provider what software they found that does that.

As far as I know, when they bring up a zVM image for you to lay down your z/OS 
image on, the serial numbers are identical to what you run currently.  I have 
not seen a product that cannot run like that.

When I did DR at a DR Provider, they ensured through many meetings that our 
hardware layout (UCBs, etc) and serial numbers were what we were running at the 
time.

We logged onto z/VM at their site, downloaded our z/OS System and IPL'd.  We 
had no issues.

That they indicated they have seen that, perhaps they know what those are.

Note:  Many vendors can provide DR license codes to avoid these types of tests 
and issues

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Adams, Anne (DTI)
> Sent: Wednesday, September 14, 2016 9:05 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: serial numbers ... real and imagine
> 
> Hello friends,
> 
> How can I determine where a software product is pulling the serial number of
> the hardware? We'd like to be able to run a z/VM guest (for DR) with the same
> serial number as our current mainframe. That way we don’t have to call for
> temporary license keys. However, our DR provider has warned us that some
> products will interrogate the physical hardware rather than what the OS is
> holding or what I have in the iodf. Any way beforehand to see where those
> values are coming from?
> Thanks.
> 
> Anne R Adams, CISSP
> DTI, Systems Engineering
> Sr. Mainframe Services Analyst
> 302.298.3196

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

Re: TSO User ID Rules (Was: z/OS and code pages)

[Paul Gilmartin]

On Wed, 14 Sep 2016 14:05:44 +0800, Timothy Sipples wrote:

>zMan wrote:
>>If my name were "*�tienne*", would I be able to have that as a TSO userid?
>>Or would I have to suffer through just "*Etienne*", sans accent aigu?
>
>a RACF user ID is 1 to 8 characters in length ...
> 
Usage has evolved.  Perhaps "bytes" rather than "characters" may be more
suitable here nowadays.  "Étienne" is seven characters but perhaps 8 or
14 bytes.

The restriction of the character vocabulary is a concession to the EBCDIC
code page babel.  Poor Étienne might be unable to log on with a CP500
terminal.  Passwords are worse.

>Here are two more caveats:
>
>(a) If you want your RACF ID to be usable within MVS subsystems, the first
>character cannot be a numeric digit (0 through 9).
> 
Is there any good reason for this?  Any circumstance in which a syntax
allows either a number or a user ID and must be able to distinguish
by examining the first character?  "Company Policy"?

>(b) In addition to the MVS restriction, if you want your RACF ID to be
>usable within TSO, the user ID cannot be longer than 7 characters.
> 
And here TSO fails the "plays well with others" test.  Many enterprises
require for administrative convenience that each user have identical
IDs on all systems, and (for no good reason -- "Company Policy" again)
that 8 characters be supported or required.  The antiquated TSO restriction
is armament for managers who oppose moving applications to z/OS.

-- gil

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

Re: serial numbers ... real and imagine

[John McKown]

On Wed, Sep 14, 2016 at 11:48 AM, Charles Mills  wrote:

> Speaking as a vendor here -- and at the risk of flames -- it's not just
> "bad" customers. With the amount of outsourcing, turnover, overwork and
> layoffs of skilled people we were seeing a fair amount of "inadvertent"
> license violation before we implemented the serial number check. Junior
> sysprogs or managers who just assumed they could install the software on
> another LPAR.
>

​Or maybe moved a system image from one CEC to a different one (upgrade /
side-grade due to hardware problem). I couldn't think of a better word that
"bad" which is why I put it in quotes. They are "bad" because they aren't
taking the time to do the job correctly for some reason. Not that I'm
blaming the technicians, necessarily. Sometimes the customer is "bad"
because they can't find competent people, or don't want to pay what the
persons demands, or any number of other reasons which don't imply "moral
turpitude" or even "excessive management greed".



>
> Charles
>
>

-- 
Unix: Some say the learning curve is steep, but you only have to climb it
once. -- Karl Lehenbauer
Unicode: http://xkcd.com/1726/

Maranatha! <><
John McKown

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

Re: Capture REXX/CLIST software usage.

[Paul Gilmartin]

On Wed, 14 Sep 2016 07:21:03 -0500, Elardus Engelbrecht wrote:
>
>>//ST003EXEC  PGM=IKJEFT01
>>//SYSPROC  DD DSN=myexec,DISP=SHR
>>//SYSTSPRT DD SYSOUT=*
>>//SYSPRINT DD SYSOUT=*
>>//SYSTSIN  DD *
>> %TEST
>>/*
>
>>and capture with a GTF all the SVCs called.
>>I'm expecting at least a BLDL but nothing.
> 
I'm astonished.  Largely because I successfully use a mixture of PDS
and UNIX directories in my SYSEXEC concatenation (it's not supported
but I find it more convenient than keeping the directories reconciled).
It's unlikely that Rexx would add such a facility outside conventional
BLDL without supporting it.  But does GTF intercept BLDL?

>On a side note: I wish the REXX and CLIST interpreter has an exit which is 
>called BEFORE any interpreting is started. Are there such exits? They could be 
>useful for monitoring the usage of those interpreted program languages.
> 
I'd oppose such a facility if it interfered with the possibility of mixed
SYSEXEC concatenations.

-- gil

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

Re: serial numbers ... real and imagine

[Charles Mills]

Speaking as a vendor here -- and at the risk of flames -- it's not just "bad" 
customers. With the amount of outsourcing, turnover, overwork and layoffs of 
skilled people we were seeing a fair amount of "inadvertent" license violation 
before we implemented the serial number check. Junior sysprogs or managers who 
just assumed they could install the software on another LPAR.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Wednesday, September 14, 2016 9:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: serial numbers ... real and imagine

On Wed, Sep 14, 2016 at 11:04 AM, Adams, Anne (DTI) 
wrote:

> Hello friends,
>
> How can I determine where a software product is pulling the serial 
> number of the hardware? We'd like to be able to run a z/VM guest (for 
> DR) with the same serial number as our current mainframe. That way we 
> don’t have to call for temporary license keys. However, our DR 
> provider has warned us that some products will interrogate the 
> physical hardware rather than what the OS is holding or what I have in 
> the iodf. Any way beforehand to see where those values are coming from?
>

​Of course, I can't say for certain, but my best guess (FWIW) is that most 
products today use the Store System Information instruction (STSI). Most of 
this information is available to z/OS program via the CSRSI callable service.
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieaa100/CSRSI_Description.htm
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.iead100/iead100476.htm

How to really tell for a particular piece of software? Well, being a very old 
time, low-level, sort of person, I'd likely run the software (or the key 
validation part if that is separate) under a program I would write which would 
use the PER hardware to do an instruction trace. Figuring out how to do this is 
an exercise (in futility?) left to the reader.

As others have said, doing this would most likely violate your licensing 
agreement, even if it is possible. It would be no different from disassembling 
the code and simply zapping the license check to return "valid". Many vendors 
are now making it possible to get emergency keys via a web portal so you don't 
need to actually talk to a human immediately. If getting a D.R. key is a 
problem, that is a vendor customer support issue.
I'd basically tell them "fix it or I will do my best to replace all your 
products." I understand the need for keys due to "bad" customers (not paying or 
paying late), but I still dislike keys. I loved how one book publisher did 
their DRM. They would take an order from you and you'd get a download URL for 
the book. It was customized with your name, a serial number, and a note at the 
back that they paid if told about piracy of their material. So you really 
needed to trust anybody you "gave" the book to.



> Thanks.
>
> Anne R Adams, CISSP
> DTI, Systems Engineering
> Sr. Mainframe Services Analyst
> 302.298.3196
>
>


--
Unix: Some say the learning curve is steep, but you only have to climb it once. 
-- Karl Lehenbauer
Unicode: http://xkcd.com/1726/

Maranatha! <><
John McKown

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

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

Re: z/OS and code pages

[retired mainframer]

User IDs have always been restricted to upper case (at least as far back as
UADS).  RACF has supported upper and lower case password characters as an
option for many years now.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Cameron Conacher
> Sent: Wednesday, September 14, 2016 4:34 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS and code pages
> 
> I honestly don't know.
> But Katakana shares the same hex values as lower case English letters. I
have always had
> upper case User IDs and passwords. Perhaps it is a RACF restriction?

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

Re: REASON: 3 - RECORD TYPE NOT RECOGNIZED

[retired mainframer]

REPRO MERGECAT does not seem like the best choice to me.  It might work for a 
user catalog since the DSN is not needed by users to access their datasets.  
For every level that is moved, you need to change the alias in the master to 
relate to the new DSN.  (This is what the warning is about.)  What will REPRO 
do when it encounters the bad record?

It's been a while but I seem to remember using EXPORT followed by IMPORT for 
issues like this.  Don't forget to lock the catalog for the job's duration.  
(You may need to do this during scheduled down time without users accessing the 
catalog.)

What happens if you try to access the dataset by way of the catalog, such as 
specifying it on a DD statement?   Have you tried to manually delete and 
recreate the offending catalog entry?  Is the dataset physically on the volume 
the catalog thinks it's on?

>From where would you restore the catalog?  How was it backed up?  If by DFDSS, 
>was it a physical or logical backup?

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of willie bunter
> Sent: Wednesday, September 14, 2016 4:33 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: REASON: 3 - RECORD TYPE NOT RECOGNIZED
> 
> The DIAGNOSE gives the same error and no change.  I ran examine (using the 
> following
> parms) and " NO ERRORS DETECTED"
> 
> INDEXTEST DATATEST
> ITEST NODATATEST ERRORLIMIT(1000)
> NOITEST DATATEST ERRORLIMIT(1000)
> 
> I ran LISTCAT against the CATALOG and it flagged the same VSAM dsn posting the
> following error messages:
> IEC331I 028-002,LISTCAT ,STEP1   ,IGG0CLEG
> According to the problem explanation
> Explanation: An I/O error processing the
> catalog occurred while processing an access
> method services command that requires
> modifying the catalog.
> Programmer Response: Messages IEC331I,
> IEC332I, and IEC333I have been printed to aid
> in determining the cause of the error and
> where the error occurred. If a hardware error
> is not causing the problem, restore or
> rebuild the catalog.
> 
> I have read up on the process of rebuilding the catalog (REPRO MERGECAT) 
> however
> there could be a problem when using LEVEL or ENTRIES parm.  According to the 
> doc
> "may cause data sets to no longer be found".  This is not reassuring.
> 
> I would prefer to restore the CATALOG which seems safer.  I would like 
> guidance on this
> subject.

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

Re: serial numbers ... real and imagine

[John McKown]

On Wed, Sep 14, 2016 at 11:04 AM, Adams, Anne (DTI) 
wrote:

> Hello friends,
>
> How can I determine where a software product is pulling the serial number
> of the hardware? We'd like to be able to run a z/VM guest (for DR) with the
> same serial number as our current mainframe. That way we don’t have to call
> for temporary license keys. However, our DR provider has warned us that
> some products will interrogate the physical hardware rather than what the
> OS is holding or what I have in the iodf. Any way beforehand to see where
> those values are coming from?
>

​Of course, I can't say for certain, but my best guess (FWIW) is that most
products today use the Store System Information instruction (STSI). Most of
this information is available to z/OS program via the CSRSI callable
service.
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieaa100/CSRSI_Description.htm
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.iead100/iead100476.htm

How to really tell for a particular piece of software? Well, being a very
old time, low-level, sort of person, I'd likely run the software (or the
key validation part if that is separate) under a program I would write
which would use the PER hardware to do an instruction trace. Figuring out
how to do this is an exercise (in futility?) left to the reader.

As others have said, doing this would most likely violate your licensing
agreement, even if it is possible. It would be no different from
disassembling the code and simply zapping the license check to return
"valid". Many vendors are now making it possible to get emergency keys via
a web portal so you don't need to actually talk to a human immediately. If
getting a D.R. key is a problem, that is a vendor customer support issue.
I'd basically tell them "fix it or I will do my best to replace all your
products." I understand the need for keys due to "bad" customers (not
paying or paying late), but I still dislike keys. I loved how one book
publisher did their DRM. They would take an order from you and you'd get a
download URL for the book. It was customized with your name, a serial
number, and a note at the back that they paid if told about piracy of their
material. So you really needed to trust anybody you "gave" the book to.



> Thanks.
>
> Anne R Adams, CISSP
> DTI, Systems Engineering
> Sr. Mainframe Services Analyst
> 302.298.3196
>
>


-- 
Unix: Some say the learning curve is steep, but you only have to climb it
once. -- Karl Lehenbauer
Unicode: http://xkcd.com/1726/

Maranatha! <><
John McKown

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

Re: serial numbers ... real and imagine

[Feller, Paul]

Are you sure they are only looking at the serial number?  Some vendors look at 
both the model and the serial as part of their license.  As for the serial 
number you are correct about being concerned about what are they looking at.  
I've seen some look at the lpar serial number and some look at the serial 
number for the box.  I have been bitten by that in the past.  Then I've seen 
some just look at the last 4 digits of the serial number.

So bottom line I agree you need to somehow politely ask the vendor.

Thanks..

Paul Feller
AGT Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Wednesday, September 14, 2016 11:12
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: serial numbers ... real and imagine

Are you on support? Ask the vendor?

Speaking as a vendor, I would not ask "where do you get your serial number 
from?" but rather "what are the terms of our license and what is your 
definition of a 'machine' for license purposes?" You don't want to fool the 
product and then end up on 60 Minutes because you are violating the (paper) 
license.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Adams, Anne (DTI)
Sent: Wednesday, September 14, 2016 9:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: serial numbers ... real and imagine

Hello friends,

How can I determine where a software product is pulling the serial number of 
the hardware? We'd like to be able to run a z/VM guest (for DR) with the same 
serial number as our current mainframe. That way we don’t have to call for 
temporary license keys. However, our DR provider has warned us that some 
products will interrogate the physical hardware rather than what the OS is 
holding or what I have in the iodf. Any way beforehand to see where those 
values are coming from?
Thanks.

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

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

Re: What is the STCB?

[Steve]

TCBJSTCB field of the TCB data area (jobstep TCB)
 
-Original Message-
From: "Rupert Reynolds" 
Sent: Wednesday, September 14, 2016 11:42am
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What is the STCB?



Related to this, does anyone have a scan of a big control block map, of the
sort IMI Computing gave on their sysprog courses?

Can be very useful for finding a CB or seeing where one can take you next
:-)

I lost mine :-(
On 12 Sep 2016 15:16, "Charles Mills"  wrote:

> What is the STCB? For example,
>
> 312 (138) ADDRESS 4 TCBSTCB ADDRESS OF STCB
>
> Charles
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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

Re: serial numbers ... real and imagine

[Steve]

Issue a D M=(CPU) and the will give you what the system knows about your box
 
 
-Original Message-
From: "Adams, Anne (DTI)" 
Sent: Wednesday, September 14, 2016 12:04pm
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: serial numbers ... real and imagine



Hello friends,

How can I determine where a software product is pulling the serial number of 
the hardware? We'd like to be able to run a z/VM guest (for DR) with the same 
serial number as our current mainframe. That way we don’t have to call for 
temporary license keys. However, our DR provider has warned us that some 
products will interrogate the physical hardware rather than what the OS is 
holding or what I have in the iodf. Any way beforehand to see where those 
values are coming from?
Thanks.

Anne R Adams, CISSP
DTI, Systems Engineering
Sr. Mainframe Services Analyst 
302.298.3196
 
This communication is for use by the intended recipient and contains 
information that may be Privileged, confidential or copyrighted under 
applicable law. If you are not the intended recipient, you are hereby formally 
notified that any use, copying or distribution of this e-mail, in whole or in 
part, is strictly prohibited. Please notify the sender by return e-mail and 
delete this e-mail from your system. Unless explicitly and conspicuously 
designated as "E-Contract Intended", this e-mail does not constitute a contract 
offer, a contract amendment, or an acceptance of a contract offer. This e-mail 
does not constitute a consent to the use of sender's contact information for 
direct marketing purposes or for transfers of data to third parties.



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

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

Re: serial numbers ... real and imagine

[Charles Mills]

Are you on support? Ask the vendor?

Speaking as a vendor, I would not ask "where do you get your serial number 
from?" but rather "what are the terms of our license and what is your 
definition of a 'machine' for license purposes?" You don't want to fool the 
product and then end up on 60 Minutes because you are violating the (paper) 
license.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Adams, Anne (DTI)
Sent: Wednesday, September 14, 2016 9:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: serial numbers ... real and imagine

Hello friends,

How can I determine where a software product is pulling the serial number of 
the hardware? We'd like to be able to run a z/VM guest (for DR) with the same 
serial number as our current mainframe. That way we don’t have to call for 
temporary license keys. However, our DR provider has warned us that some 
products will interrogate the physical hardware rather than what the OS is 
holding or what I have in the iodf. Any way beforehand to see where those 
values are coming from?
Thanks.

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

serial numbers ... real and imagine

[Adams, Anne (DTI)]

Hello friends,

How can I determine where a software product is pulling the serial number of 
the hardware? We'd like to be able to run a z/VM guest (for DR) with the same 
serial number as our current mainframe. That way we don’t have to call for 
temporary license keys. However, our DR provider has warned us that some 
products will interrogate the physical hardware rather than what the OS is 
holding or what I have in the iodf. Any way beforehand to see where those 
values are coming from?
Thanks.

Anne R Adams, CISSP
DTI, Systems Engineering
Sr. Mainframe Services Analyst 
302.298.3196
 
This communication is for use by the intended recipient and contains 
information that may be Privileged, confidential or copyrighted under 
applicable law. If you are not the intended recipient, you are hereby formally 
notified that any use, copying or distribution of this e-mail, in whole or in 
part, is strictly prohibited. Please notify the sender by return e-mail and 
delete this e-mail from your system. Unless explicitly and conspicuously 
designated as "E-Contract Intended", this e-mail does not constitute a contract 
offer, a contract amendment, or an acceptance of a contract offer. This e-mail 
does not constitute a consent to the use of sender's contact information for 
direct marketing purposes or for transfers of data to third parties.



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

Re: What is the STCB?

[Rupert Reynolds]

Related to this, does anyone have a scan of a big control block map, of the
sort IMI Computing gave on their sysprog courses?

Can be very useful for finding a CB or seeing where one can take you next
:-)

I lost mine :-(
On 12 Sep 2016 15:16, "Charles Mills"  wrote:

> What is the STCB? For example,
>
> 312 (138) ADDRESS 4 TCBSTCB ADDRESS OF STCB
>
> Charles
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: IBM FTPS connect

[Mark Pace]

I'm having them look at the firewall.  I tired HTTPS, but I believe at 1.13
it required a PTF to support https.  They must not have it applied as I get
a syntax error on the downloadmethod and the downloadkeyring parameters.

On Wed, Sep 14, 2016 at 8:44 AM, Kurt Quackenbush  wrote:

> On 9/12/2016 12:27 PM, Mark Pace wrote:
>
>> I'm setting up FTPS on a 1.13 system and am a little confused by this
>> sequence.  It logs on okay showing a secure connect.  But then it won't do
>> the actual download. So I'm confused if it's the certificate or not.
>>
>
> Not the certificate.
>
> 150 Opening BINARY mode SSL data connection for
>> /GIMPAF.XML.
>> EZA2870I TLS security mechanism negotiation failed - data connection
>> closed
>> 425 ftpd: (data conn) SSL_accept unspecified
>> error
>>
>
> I haven't seen this one before.  Your FTP.DATA seems proper.  Could be a
> firewall issue as someone suggested.  Sorry, but I think you'll need to
> open a problem with IBM Comm Server support and ask for their help to debug
> further.  Perhaps an IP trace is in order.
>
> As Skip suggested, HTTPS is usually way easier to use, especially with
> respect to firewalls.  Check it out:
> http://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.
> ibm.zos.v2r2.gim3000/dsetups.htm
>
> Kurt Quackenbush -- IBM, SMP/E Development
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

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

Re: Capture REXX/CLIST software usage.

[Elardus Engelbrecht]

Norbert Friemel wrote:

>>On a side note: I wish the REXX and CLIST interpreter has an exit which is 
>>called BEFORE any interpreting is started. Are there such exits? They could 
>>be useful for monitoring the usage of those interpreted program languages.

>IKJCT43I ? 
>http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj4b4c0/5.5.1?SHELF=all13be9

My oh my! This it it! I never used the word 'EXEC' in my searches before I 
posted that question.

Thanks! I believe that should help the OP. 'Examine the command buffer'

Thanks Norbert for your kind notes! Today I learned two things from you! ;-)

Groete / Greetings
Elardus Engelbrecht

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

Re: Capture REXX/CLIST software usage.

[Massimo Biancucci]

Thanks to everybody for putting the right spark into my mind !!!

I think exit processing is the best way.

I'll go deeper.

Regards.
Massimo

2016-09-14 14:40 GMT+02:00 Norbert Friemel :

> On Wed, 14 Sep 2016 07:21:03 -0500, Elardus Engelbrecht wrote:
>
> >
> >On a side note: I wish the REXX and CLIST interpreter has an exit which
> is called BEFORE any interpreting is started. Are there such exits? They
> could be useful for monitoring the usage of those interpreted program
> languages.
> >
>
> IKJCT43I ?
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/
> BOOKS/ikj4b4c0/5.5.1?SHELF=all13be9
>
> Norbert Friemel
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Is it ISPF error?

[R.S.]

ROUTER ERROR: FUNC=MSPOPEN  RETC=0008 REAS=0008

INITIALIZATION RETURN CODE 20 FROM WZZTS   (this is name of ISPW app)
COMMUNICATION FAILURE

--
Radoslaw Skorupka
Lodz, Poland






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

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

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


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

Re: IBM FTPS connect

[Kurt Quackenbush]

On 9/12/2016 12:27 PM, Mark Pace wrote:

I'm setting up FTPS on a 1.13 system and am a little confused by this
sequence.  It logs on okay showing a secure connect.  But then it won't do
the actual download. So I'm confused if it's the certificate or not.


Not the certificate.


150 Opening BINARY mode SSL data connection for
/GIMPAF.XML.
EZA2870I TLS security mechanism negotiation failed - data connection
closed
425 ftpd: (data conn) SSL_accept unspecified
error


I haven't seen this one before.  Your FTP.DATA seems proper.  Could be a 
firewall issue as someone suggested.  Sorry, but I think you'll need to 
open a problem with IBM Comm Server support and ask for their help to 
debug further.  Perhaps an IP trace is in order.


As Skip suggested, HTTPS is usually way easier to use, especially with 
respect to firewalls.  Check it out:

http://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.gim3000/dsetups.htm

Kurt Quackenbush -- IBM, SMP/E Development

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

Re: IBM FTPS connect

[Elardus Engelbrecht]

Rob Schramm wrote:

>I think that you are in GSKSVR trace land to get more details.  Here is a link 
>to an old post with the How To for GSKSRVR.

Also look in this book for more info about 'System SSL started task' (GSKSRVR): 

'Cryptographic Services System Secure Sockets Layer Programming'

Groete / Greetings
Elardus Engelbrecht

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

Re: Capture REXX/CLIST software usage.

[Norbert Friemel]

On Wed, 14 Sep 2016 07:21:03 -0500, Elardus Engelbrecht wrote:

>
>On a side note: I wish the REXX and CLIST interpreter has an exit which is 
>called BEFORE any interpreting is started. Are there such exits? They could be 
>useful for monitoring the usage of those interpreted program languages.
>

IKJCT43I ? 
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj4b4c0/5.5.1?SHELF=all13be9

Norbert Friemel

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

Re: Bypassing s322

[Elardus Engelbrecht]

Scott Chapman wrote:

>Of course, when anybody came to me complaining about an S322, assuming it was 
>already in one of the classes that allowed them to get the max we allowed of 1 
>or 2 hours of CPU time, my first reaction was always something along the lines 
>of "Are you sure you aren't looping? Are you sure you don't have a tuning 
>opportunity that needs to be fixed?" An hour of CPU time is usually a whole 
>lot of work.

Agreed.

Watch the CPU usage of that job. If it is very high in relation of the other 
tasks, then there is a possible loop. Or lots of I/Os. Or you see excessive SMF 
records being written. Or you see that job is spitting out gazillion lines.

Scott, I would go the same tuning route as you (and slap that complainer hard 
and loud. ;-D )

Groete / Greetings
Elardus Engelbrecht

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

Re: Capture REXX/CLIST software usage.

[Elardus Engelbrecht]

Massimo Biancucci wrote:

>I'm wondering what's (if it's reasonable) the best way to capture usage of 
>REXX/CLIST member.

I believe this was discussed earlier in IBM-MAIN or TSO-REXX-L or ISPF-L. (I 
think)

But, I believe you're probably SOL unless there is a solution which I certainly 
missed somewhere.

>I've tried to run a simple JCL:

>//ST003EXEC  PGM=IKJEFT01
>//SYSPROC  DD DSN=myexec,DISP=SHR
>//SYSTSPRT DD SYSOUT=*
>//SYSPRINT DD SYSOUT=*
>//SYSTSIN  DD *
> %TEST
>/*

>and capture with a GTF all the SVCs called.
>I'm expecting at least a BLDL but nothing.

GTF is somewhat expensive because there is an overhead. 

Anyways, your SMF records from that JCL will only show IKJEFT01, not subsequent 
called programs.

You could use RACF to audit myexec dataset. (AUDIT against the profile and 
LOGOPTIONS ALWAYS for DATASET class)

Alternatively, move the REXX/CLIST to somewhere else (or rename myexec) and 
wait until someone cries.

Great fun until you're at risk being fired for disrupting your production 
system.

On a side note: I wish the REXX and CLIST interpreter has an exit which is 
called BEFORE any interpreting is started. Are there such exits? They could be 
useful for monitoring the usage of those interpreted program languages.

Groete / Greetings
Elardus Engelbrecht

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

Re: 2FA in the Real World

[Steve]

I have never been a real fan of EMC.  I much prefer HDS G1000 class DASD using 
HUR, that is much, much easier to handle from ISPF for PPRC/XRC that CLI from a 
Windows open window
 
Steve
 
 
-Original Message-
From: "Scott Chapman" 
Sent: Wednesday, September 14, 2016 8:03am
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 2FA in the Real World



Their purchase of EMC just closed, so I guess Dell now also makes mainframe 
disk subsystems. Will be interesting to see what they do with that. 

Scott

On Tue, 13 Sep 2016 21:57:22 +0100, Vince Coen  wrote:

>Quest.
>
>Seem to recall some other m/f products as well. Toad ?
>
>Vince
>
>
>On 13/09/16 18:31, Steve wrote:
>> NC-Pass was purchased some time ago by Dell, and I don't remember who wrote 
>> itt
>>
>>
>> Steve
>> -Original Message-
>> From: "Vince Coen" 
>> Sent: Tuesday, September 13, 2016 1:23pm
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: 2FA in the Real World
>>
>>
>>
>> For me the problem is that it is a Dell product.
>>
>> Previous experience with them just leave a bitter taste in the mouth and
>> one I have no intention of repeating.
>>
>> Vincent
>>
>>
>> On 13/09/16 17:49, Steve wrote:
>>> Is anyone in the real not government world using this product?
>>>
>>> [ https://software.dell.com/products/defender-mainframe-edition/ ]( 
>>> https://software.dell.com/products/defender-mainframe-edition/ )
>>>
>>>
>>> Steve
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

Re: IBM FTPS connect

[Rob Schramm]

I think that you are in GSKSVR trace land to get more details.  Here is a
link to an old post with the How To for GSKSRVR.

https://www.mail-archive.com/ibm-main@listserv.ua.edu/msg29631.html

Rob Schramm

On Tue, Sep 13, 2016, 8:15 PM Nims,Alva John (Al)  wrote:

> To add my $0.02 of useless knowledge;
> In your FTP.DATA file did you also code?
>
> SECURE_MECHANISM  TLS
> TLSRFCLEVELRFC4217
>
> Just my $0.02 worth.  I am no expert when it comes to IBM's FTP, but I
> recently had to add those two to make a connection work.
>
> Al Nims
> University of Florida.
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Tuesday, September 13, 2016 3:36 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IBM FTPS connect
>
> Just a thought.  Kurt Q. has been helpful to folks offlist to resolve
> their FTP IBM issues.  You may wish to see if he will assist.  He really
> wants to be a smooth process and easy transition.
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Mark Pace
> > Sent: Tuesday, September 13, 2016 11:32 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: IBM FTPS connect
> >
> > That was a big help, thank you.  I was able to confirm that all the
> > correct FMIDs were installed.  So I know it "should" work.
> > I also tried FWFRIENDLY TRUE  that didn't seem to make any difference.
> > Turned on DEBUG SOC.  So now I'll have to research the output.
> >
> > > GET "/GIMPAF.XML" "/u/MP81136/test.content/GIMPAF.XML"
> > (REPLACE
> > >>> TYPE
> > I
> > 200 Type set to
> > I.
> > Command:
> >
> > SC1344 initDsConnection:
> > entered
> > >>>
> > EPSV
> >
> > 229 Entering Passive Mode
> > (|||65321|)
> > >>> RETR
> > /GIMPAF.XML
> > SC1981 connDsConnection:
> > entered
> > SC2075 connDsConnectionIPv4:
> > entered
> > GU4945 ftpSetApplData:
> > entered
> > 150 Opening BINARY mode SSL data connection for /GIMPAF.XML.
> > FU0388 protDataConn: secure_socket_init() failed with rc = 406 (Error
> > while read ing or writing
> > data)
> > CG1959 SETCEC code =
> > 17
> > TLS security mechanism negotiation failed - data connection closed
> > SC2637 dataClose:
> > entered
> > 425 ftpd: (data conn) SSL_accept unspecified error
> > CG4118 rcvFile: rc -1 rc_write 0 rc_close
> > 0
> > PC0921 setClientRC:
> > entered
> > PC0991 setClientRC: std_rc=16425, rc_type=STD,
> > rc=16425
> > Std Return Code = 16425, Error Code =
> > 00017
> > >>>
> > QUIT
> >
> > : Connection reset by
> > peer.
> > SC3358 endSession: entered
> > (sn=0F9EE7C8)
> > SC2637 dataClose:
> > entered
> >
> >
> > >
> > QUIT
> >
> >
> >
> > On Tue, Sep 13, 2016 at 12:50 PM, Cieri, Anthony 
> wrote:
> >
> > >
> > > For the record, there are several FMIDs that may be
> > > installed with the z/OS Security Lvl 3 and z/OS Communications
> > > Server Security lvl 3 may also be required. The FMIDs for Z/OS
> > > Security Lvl 3 at z/OS Version 1.13
> > > are:
> > >
> > > JCRY741
> > > JCPT3D1
> > > JSWK3D1
> > > JRLS3D1
> > >
> > > The FMID for z/OS Communications Server lvl 3 at z/OS Version
> > > 1.13.is:  (ask me how I know this!!!)
> > >
> > > JIP61DK
> > >
> > > You would most likely see errors in PAGENT and its
> > > associated tasks (like IKED) if you did NOT have these installed!!
> > >
> > > Since you appear to be getting a successful control
> > > connection established ad subsequently failing on the data
> > > connection, I would suspect a possible firewall issue. The error
> message provided:
> > >
> > > EZA1735I Std Return Code = 16425
> > >
> > > Indicates that the "get" command failed for one of the
> > > following
> > > reasons:
> > >
> > > 425: Can't open a data connection
> > > 425: Can't open a passive connection
> > > 425: Command terminated due to server shutdown in
> progress
> > > 425: Unable to open data connection
> > >
> > > HTH
> > > Tony
> > >
> > >
> > >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List
> > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rob Schramm
> > > Sent: Tuesday, September 13, 2016 11:53 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: IBM FTPS connect
> > >
> > > The instructions for debugging connection issues indicates to run
> > > with debug soc which should provide some additional information.
> > >
> > > Rob Schramm
> > >
> > > On Tue, Sep 13, 2016, 11:10 AM Mark Pace 
> wrote:
> > >
> > > > I'll have to go check on the z/OS Security lvl 3 FMID.  I didn't
> > > > install this system, so I'm not sure.
> > > >
> > > > On Tue, Sep 13, 2016 at 9:12 AM, Tim Deller 
> wrote:
> > > >
> > > > > Perhaps the list of ciphers in the ftpdata file is too
> > > > > restrictive or maybe the z/

Re: 2FA in the Real World

[Scott Chapman]

Their purchase of EMC just closed, so I guess Dell now also makes mainframe 
disk subsystems. Will be interesting to see what they do with that. 

Scott

On Tue, 13 Sep 2016 21:57:22 +0100, Vince Coen  wrote:

>Quest.
>
>Seem to recall some other m/f products as well.  Toad ?
>
>Vince
>
>
>On 13/09/16 18:31, Steve wrote:
>> NC-Pass was purchased some time ago by Dell, and I don't remember who wrote 
>> itt
>>
>>
>> Steve
>> -Original Message-
>> From: "Vince Coen" 
>> Sent: Tuesday, September 13, 2016 1:23pm
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: 2FA in the Real World
>>
>>
>>
>> For me the problem is that it is a Dell product.
>>
>> Previous experience with them just leave a bitter taste in the mouth and
>> one I have no intention of repeating.
>>
>> Vincent
>>
>>
>> On 13/09/16 17:49, Steve wrote:
>>> Is anyone in the real not government world using this product?
>>>
>>> [ https://software.dell.com/products/defender-mainframe-edition/ ]( 
>>> https://software.dell.com/products/defender-mainframe-edition/ )
>>>
>>>
>>> Steve
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Bypassing s322

[Scott Chapman]

You can't really bypass the system exits, but that doesn't mean that the exits 
might not include certain "secret" triggers that might allow you to specify a 
higher time value on the job card.  E.G. if the job is in this class and it's 
this time of day and this job name, then allow/set something higher. Talk to 
your friendly system programmer responsible for maintaining such controls. (If 
that's you because you've inherited a situation, you'll have to go do some 
research.)

In the distant past I remember using Omegamon to dynamically extend the limit 
of a running job. I don't remember the details at this point, but I think it 
was just adjusting the existing time limit, not doing something like taking it 
out of control of the exit or anything like that. 

Of course, when anybody came to me complaining about an S322, assuming it was 
already in one of the classes that allowed them to get the max we allowed of 1 
or 2 hours of CPU time, my first reaction was always something along the lines 
of "Are you sure you aren't looping? Are you sure you don't have a tuning 
opportunity that needs to be fixed?" An hour of CPU time is usually a whole lot 
of work.

Scott

On Tue, 13 Sep 2016 18:35:15 +0530, Peter  wrote:

>Hello
>
>I am running which is a long running job but it keeps abending with s322. I
>have used all the long running WLM initiators but still abends. I am not
>sure if IEFUTL exit is restricting it.
>
>The error message doesn't produce much information to diagnose.
>
>Is there a way to bypass any EXIT which might be timing out the Jobs ?
>
>Peter
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Capture REXX/CLIST software usage.

[Scott Barry]

Ah yes, and so goes one primary purpose/use of now-defunct (at CA's hands) the 
TSO/MON software product, originally an effective legacy Morino Associates tool 
written in the late '70s, that monitored various SYSEVENT actions.  As well, 
TSO/ISPF application program/panel usage could be monitored.
Scott Barry
SBBWorks, Inc.

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

Re: z/OS and code pages

[Cameron Conacher]

I honestly don't know. 
But Katakana shares the same hex values as lower case English letters. I have 
always had upper case User IDs and passwords. Perhaps it is a RACF restriction?

Sent from my iPhone

> On Sep 13, 2016, at 8:47 PM, Charles Mills  wrote:
> 
> Sure, but does z/OS tolerate it? Can you use Katakana characters in passwords 
> and userids?
> 
> Charles
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Cameron Conacher
> Sent: Tuesday, September 13, 2016 4:56 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS and code pages
> 
> EBCDIC code page 930 supports Japanese kanji and single byte katakana
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: REASON: 3 - RECORD TYPE NOT RECOGNIZED

[willie bunter]

The DIAGNOSE gives the same error and no change.  I ran examine (using the 
following parms) and " NO ERRORS DETECTED"

INDEXTEST DATATEST
ITEST NODATATEST ERRORLIMIT(1000)
NOITEST DATATEST ERRORLIMIT(1000)

I ran LISTCAT against the CATALOG and it flagged the same VSAM dsn posting the 
following error messages:
IEC331I 028-002,LISTCAT ,STEP1   ,IGG0CLEG
According to the problem explanation 
Explanation: An I/O error processing the   
catalog occurred while processing an access
method services command that requires  
modifying the catalog. 
Programmer Response: Messages IEC331I,   
IEC332I, and IEC333I have been printed to aid
in determining the cause of the error and
where the error occurred. If a hardware error
is not causing the problem, restore or   
rebuild the catalog. 

I have read up on the process of rebuilding the catalog (REPRO MERGECAT) 
however there could be a problem when using LEVEL or ENTRIES parm.  According 
to the doc "may cause data sets to no longer be found".  This is not reassuring.

I would prefer to restore the CATALOG which seems safer.  I would like guidance 
on this subject.

Thanks.

On Tue, 9/13/16, retired mainframer  wrote:

 Subject: Re: REASON: 3 - RECORD TYPE NOT RECOGNIZED
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Tuesday, September 13, 2016, 1:01 PM
 
 > -Original
 Message-
 > From: IBM Mainframe
 Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On
 > Behalf Of willie bunter
 > Sent: Tuesday, September 13, 2016 9:01
 AM
 > To: IBM-MAIN@LISTSERV.UA.EDU
 > Subject: REASON: 3 - RECORD TYPE NOT
 RECOGNIZED
 > 
 > Hi
 All,
 > 
 > While
 running a DIAGNOSE on a USERCAT the following error was
 picked up:
 > 
 >
 IDC21364I ERROR DETECTED BY DIAGNOSE:
 >   ICFCAT ENTRY: 05:26:06.214
 UTMOPB08: START TWRC MSGID(AFE7 (7)
 >   RECORD: 05:26:06.214
 UTMOPB08: START TWRC MSGID(AFE7 /F0
 >   OFFSET: X'0002'
 >   REASON: 3 - RECORD TYPE NOT
 RECOGNIZED
 > IDC21365I ICFCAT RECORD
 DISPLAY:
 >   RECORD:
 05:26:06.214 UTMOPB08: START TWRC MSGID(AFE7 /F0
 > 
 > The programmer
 response (I hope I read it right) says
 >
 Use DELETE NOSCRATCH to remove the sphere or base record, if
 it exists.
 > 
 > I have
 2 questions:
 > Since the dsn is not
 listed in the job output after IDC21364i message I assume
 that the dsn -
 > listed on side (cols 85
 to 119) -
 > I assume that is the dsn in
 question. Please correct me if I am wrong.
 > 
 > Is this problem
 serious or it can wait for action to be taken?  The problem
 was detected
 > about 10 days ago.
 
 You have already waited ten
 days and not yet taken any action.  Has there been any
 noticeable impact?  If you run the DIAGNOSE again, do the
 results change?  For better or worse?
 
 Were other activities that use the catalog
 running at the same time as your DIAGNOSE?  When I was
 running EXAMINE jobs to confirm consistency between catalogs
 and VVDSs, I determined that some reported errors were
 transient and could be eliminated by executing the VERIFY
 command just prior to the EXAMINE.  I don't know if the
 same issue could affect DIAGNOSE.  
 
 If it is a permanent error, I would be more
 concerned with how it occurred and what to do to prevent it
 in the future.
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN

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

Re: IDCAMs DEF AIX authorization

[Jousma, David]

Rex,

Here is the relevant cut/paste from the manuals, and as Steve mentioned, DEF 
AIX doesn’t require access to base, just authority to create the AIX, but 
BLDINDEX does require update to the base.

In your case:   

Table 2. Required Security Authorization for VSAM Data Sets 

--- 
|Function Performed | Required RACF | Required RACF | Comments| 
|   | for Data Set  | for Catalog   | | 
--- 
|Define alternate   | Alter | Update|See notes 2 and 3| 
|index  |   |   | | 
--- 

Notes:  

   2. Authorization is always to the cluster name for VSAM components   
  cataloged with the integrated catalog facility.  Integrated   
  catalog facility does not check for individual component names
  such as data, index, path, or alternate index.
   3. No authority is required to the catalog for the define of 
  SMS-managed data sets unless the catalog is the master catalog.   
  Update authority is required if the catalog is a master catalog.  

and:

Table 5. Required Security Authorization for Data Set Operations

--- 
|Function Performed | Required RACF | Required RACF | Comments| 
|   | for Data Set  | for Catalog   | | 
--- 
|BLDINDEX   | n/a   | Update|Authority is to  | 
|   |   |   |the base cluster.| 
--- 

Basically, authorization checking is done against the AIX being defined (ALTER 
access to the AIX cluster name as shown in the table above) not the VSAM 
dataset the AIX relates to.  Checking against the related VSAM 
cluster will be done when accessed by BLDINDEX. 

So, this is working as intended and documented.  If you wish, you could open an 
'enhancement request' to have this behavior changed.  To do so, 
just follow the instructions included in my last update.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pommier, Rex
Sent: Tuesday, September 13, 2016 4:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IDCAMs DEF AIX authorization

Dave,

First of all, I agree with you that the programmer shouldn't have been able to 
relate the AIX to the base cluster with only having read access to the base.  
But that being said, since they could relate them, why couldn't they run the 
BUILDIX command?  The BUILDIX doesn't update the base cluster, does it?  
Wouldn't read access to the base also have allowed the job to use that data to 
build the AIX?  Or does the BUILDIX somehow update the base?

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Tuesday, September 13, 2016 12:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IDCAMs DEF AIX authorization

Steve, the user tried to do the build index, but failed on lack of access S913 
as he should have.The user *should* have then deleted his AIX, but didn’t, 
and left it hanging out there.   I suspect that the error was unintentional, as 
our application dataset naming conventions here, leave a little to be desired.  
*.TAT.* is test, *.PAT.* is PROD for this particular business application.   It 
is my guess, that the user forgot to change the PAT to TAT in the RELATE 
portion of the DEF AIX.

_

Capture REXX/CLIST software usage.

[Massimo Biancucci]

Hi everybody,

I'm wondering what's (if it's reasonable) the best way to capture usage of
REXX/CLIST member.

For LOAD member it's possible to "monitor" some SVC and capture the
information (like TADz).

I've tried to run a simple JCL:

//ST003EXEC  PGM=IKJEFT01
//SYSPROC  DD DSN=myexec,DISP=SHR
//SYSTSPRT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSTSIN  DD *
 %TEST
/*

and capture with a GTF all the SVCs called.

I'm expecting at least a BLDL but nothing.

The goal is to know what piece of software are used and, in a statistic
way, clean the libraries from unused software,

Any idea ?

Thanks a lot for your support.
Massimo

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

AW: Converson of hex value to character

[bernd.oppol...@t-online.de]

Thank you very much ... 

BTW: I'm doing ASSEMBLER classes and training in Germany since 1985
for large companies of the financial sector, but in the last years there was 
not 
much need for this. But there should be, IMO, because there are still many 
ASSEMBLER programs running, and the maintenance (and migration, maybe) 
cannot all be done by us oldtimers - I'm only 57 :-) ... recently I was called 
for a mainframe project here in Germany, and I was the youngest candidate !!
The ages spanned from 57 to 73. 

and so we should try to teach ASSEMBLER etc. to young people, too. 

So: if you plan a project to teach ASSEMBLER to some younger people 
in your company somewhere in Europe, please call me; I would like 
to support you doing this. 

At the moment I'm working at a project in the financial area, which uses 
C and PL/1 (and DB2), but doing an ASSEMBLER teaching project 
in between should not be a problem at all. 

Kind regards

Bernd



-Original-Nachricht-
Betreff: Re: Converson of hex value to character
Datum: 2016-09-13T14:41:52+0200
Von: "Steve Smith" 
An: "IBM-MAIN@LISTSERV.UA.EDU" 

Bernd Oppolzer's answer is the best, 
...

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