Re: Bypassing s322

[Bill Woodger]

I had been wondering why there were not "rules of algebra" explanations for the 
floating-point variants of MULTIPLY. So I looked:

"The sign of the product, if the product is numeric, is the exclusive or of the 
operand signs. This includes the sign of a zero or infinite product."

In mathematics, is there a problem with infinity having a sign? Drifting OT 
again...

--
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)

[Timothy Sipples]

Tom Marchant wrote:
>Yes, AFAIK TSO is still an acronym for Time Sharing Option. Big deal.
>TSO was an option for OS/MVT. It never was an option for MVS.

Of course TSO is optional in the plain meaning of the word, beyond de
minimis use at least. That should have been clear from my Cognos example.

To pick a couple more random examples, z/OS Version 2 includes the z/OS
Font Collection and the IBM Directory Server for z/OS. Must you use those
elements? I hope you do, but no, their use is optional. They are shipped at
no additional charge with the base operating system, and surely that's a
good thing, but so what? When I use Cognos, I'm a z/OS user. I'm not a TSO
user. There are literally billions of z/OS users who are not TSO users.

As another analogy, there are also billions of Linux users. All Android
smartphone users are Linux users, for example. Only a tiny fraction of
Linux users are bash (the specific command line shell) users. A bash
restriction would only be meaningful, if it's meaningful, to bash users
specifically. Not to all Linux or all Android users. And that simple,
factual observation doesn't change whether bash is or is not sitting on the
disk (or flash memory) of the particular Linux device.

But, don't get me wrong, I'm certainly not opposed to longer length TSO
user IDs! I wrote that I'm in favor. I recommend letting IBM know what
business problem you're not solving today that you could be solving if TSO
had longer length IDs. However, if there's no "tree falling in the woods,"
then what are we worried about? A "restriction" matters only if it, er,
restricts. Please tell IBM what actually restricts you from solving a
business problem, or at least could based on reasonable forecasts.

Tony Harminc wrote:
>I obviously wasn't clear: It's the "subsystem" part I'm asking about,
>not the "MVS" part.

Oh, OK. I would refer you to John Eells's excellent explanation. (Thanks,
John.)


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: Bypassing s322

[Jesse 1 Robinson]

OK, true story. This will probably never happen again. The first CMOS 
processors were way slower than the water-cooled bipolar processors they 
replaced. We were fairly early in the transformation process. Overall a many-CP 
9672 had lots of MSUs, but each individual CP was a dog; as little as one third 
the speed. Regardless of composite MSUs, batch runs on a single CP. We 
discovered early on that jobs that had run fine for years were suddenly getting 
S322 abends. Faced with the daunting task of updating TIME= on hundreds of 
jobs, we wrote an IEFUTL exit that granted two time extensions. The coded time 
value was not changed, just repeated. 

Down side? Even though CMOS processors are now way faster than their soggy 
progenitors, we never removed the code. Batch jobs today hum along for quite a 
while. ;-)

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Woodger
Sent: Thursday, September 15, 2016 2:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Bypassing s322

Oh, I think there's been a certain amount of "drift" in the topic. There are 
lots of simple ways the issue you mention could have occurred, even though 
we'll never know exactly.

I agree, rather than trying to give a program more CPU, I'd be wondering why it 
is sucking up all the CPU that it is. Complete CPU-hogs that actually get to a 
normal end are rare, in my experience.


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

Re: PDS/E Cobol

[Jesse 1 Robinson]

I don't think an 'interim' data set will solve the problem. 

DSN(A) --> DSN(B) --> DSN(C)

Whether DSN(B) belongs to SYSA or SYSC, there is still the same problem of 
crossing sysplex boundaries on one copy or the other. 

The transfer needs to be 'DSN free'. Something like FTP or XMIT/RECEIVE or 
Connect:Direct straight from SYSA to SYSC. Or maybe BDT if anyone still uses 
it. The bottom line is that the concurrent sharing of PDSE load (program 
object) libraries across sysplex boundaries is deadly. I see this as the 
biggest obstacle for those shops that historically share PO load libraries 
across boundaries: the entire migration/promotion process has to be 
reconstructed before COBOL V5+ is implemented. 

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edward Finnell
Sent: Thursday, September 15, 2016 3:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: PDS/E Cobol

I'm with Lizette here.
 
I'd use XMIT to ODSN
FTP ODSN to secondary LRECL 80 BLKSIZE 3120 RECEIVE ODSN  * It will have SPACE 
and DCB of the original
 
 
In a message dated 9/15/2016 3:26:47 P.M. Central Daylight Time, 
stars...@mindspring.com writes:

I would  probably use an interim dataset so that there is no potential for 
PDS/E  Corruption

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

Re: IODF Dynamic Activation Reversion

[Jesse 1 Robinson]

It's (thankfully) been a while since I stumbled into this quagmire, but I'm 
pretty sure that the rule is this: for any dynamic IODF activation, the 
*current* software IODF must match the *current* HSA IODF. That a software IODF 
retro-activation will eventually match the hardware IODF is not sufficient to 
allow dynamic activation to proceed. You don't however have to POR to extricate 
yourself. Two choices.

1. Slog on bravely through the activation steps until all OS systems on the CEC 
match the newly activated HSA IODF. Then go back to the previous level 
traversing the same steps in reverse. The intermediate state(s) may be messy, 
but as long as the systems stay up, you should be able to push on back the old 
status quo.

2. If (1) is not workable, you can IPL individual systems to get them back 
where you started. This depends on having DASD resident copies of the IODF than 
match the old unchanged HSA copy. Remember that name alone is not sufficient 
for a match. There is a token at the beginning of each IODF, which must match 
byte for byte between HSA and OS copy. 

ACTIVATE TEST should steer you away from this conundrum, but there are cases 
where you must specify FORCE on the hardware ACTIVATE. That keyword as always 
should give you pause.

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Neubert, Kevin
Sent: Thursday, September 15, 2016 5:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: IODF Dynamic Activation Reversion

What change are you making?

Until you activate hardware, would expect all your software activations to be 
reversible.

You shouldn’t have to POR until you lose the ability to dynamically get to 
where you want to be.  Which more likely be due to lack of maintenance time, 
frustration, etc. and convenience of instant resolution.

For example, bad change to your only OSA.  You can’t logon to fix and go 
forward and you’re out of sync/unable to go backward.

Have you tested the activation on all your systems and/or tested the software 
only change on a test system?  The prior will highlight the changes and give 
you a better idea of the risk.

For example, some changes to an existing definition actually result in a delete 
then add of the definition.  So the respective definition would need to 
offline, not in use, etc.

Regards,

Kevin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elaine Beal
Sent: Thursday, September 15, 2016 12:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IODF Dynamic Activation Reversion

I'm rolling out IODF changes dynamically, all SOFT and HARD on the final LPAR.
Our change management rules have gotten more stringent and I need to define a 
reversion plan.

If on say, the third LPAR something goes awry and we need to back out, are 
there options besides 

1) POR  or
2) continue on to HARD  activate and then perform the process across all LPARs 
with the old IODF (soft on all except HARD on last)

I have an old ETR that says I can back out on a SOFT activate but at that point 
dynamic activation is disabled.

Thanks,
Elaine
 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.

[Anthony Thompson]

SMF parm for CLISTS? Lizette, I think your referring to SMF type 32 (TSO 
command usage), turned on by specifying DETAIL for SUBSYS(TSO) in SMFPRMxx. 

I don't think that helps Massimo, given that it requires code within the 
command in order to be registered in SMF 32's (an SVC 109 function) and doesn't 
work for TSO batch.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Thursday, 15 September 2016 10:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Capture REXX/CLIST software usage.

If the REXX/CLIST is a member in a dataset, then SMF Type 42 records may be 
helpful.  It can track in a subtype the use of a member.  It will depend on 
your level of z/OS.

If it is instream, then I think harder to do.

There was or is an SMF Parm for CLISTs I think.  It has been  some time since I 
looked at that.

Do you have tools like:  SAS/MXG, SAS/MICS, Tivoli, etc.?  Otherwise I think 
DFSORT ICETOOLS can use the SMF Type 42 and break it down.

Other option is to install DAF from cbttape.org.  You can tailor that to what 
you need for SMF reporting.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Massimo Biancucci
> Sent: Thursday, September 15, 2016 3:12 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Capture REXX/CLIST software usage.
> 
> My main goal is to find out who uses what.
> 
> If I will success after a while I'll have a view of what REXX/CLIST 
> are still in use.
> 
> I'm working on systems who were build ages ago and dealing with 
> different thousands of exec on tenth of libraries.
> 
> The VLF maybe a parallel way even though I've to discuss with customer 
> in order to evaluate pro (a lot) and cons.
> 
> I know that the more I monitor the worst I get, anyway we use TADz to 
> delete old applications and we'd like to do the same for system pgmr stuffs.
> 
> Thanks again to everybody.
> Massimo
> 
> 2016-09-15 3:04 GMT+02:00 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: TSO User ID Rules (Was: z/OS and code pages)

[Jesse 1 Robinson]

The requirement for a leading alphabetic/national character in so many MVS 
names is not a myth. It's baked into myriad processes where a user specifies a 
name. Using a programmatic interface, you can create almost any (for example) 
member name subject to the eight-character limit. But most user interfaces will 
disallow a non-standard name on, say, an ISPF panel. 

We used to see weird member names in the old SMP (pre-E) environment. They even 
had non-alpha non-numeric 'characters'. These names were created and managed by 
SMP itself. Even now SVC modules may contain non-alpha characters. None of this 
negates the standard name rules. It really is true that exception(s) prove the 
rules. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, September 15, 2016 2:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: TSO User ID Rules (Was: z/OS and code pages)

On Thu, 15 Sep 2016 07:01:42 -0400, John Eells wrote:
>
>The MVS restriction stems from the need to name PDS members starting 
>with an alphabetic or national character, as all users were originally
>
That "need" is largely a superstition.  Consider the following from an ISPF 
member list, retouched only to obfuscate HLQ.

  DSLISTUser.TEMP.MIXED.CASE.LINKLIB  Row 001 of 013
  Command ===>  Scroll ===> CSR
 Name PromptAlias-of Size  TTR AC   AM   RM
  _ .FooBar0008   000117   0024   24
  _ +1 0008   000127   0024   24
  _ $FooBar0008   00010F   0024   24
  _ Foo.Bar0008   000211   0024   24
  _ Foo+Bar0008   000137   0024   24
  _ Foo$Bar0008   000219   0024   24
  _ Foo*Bar0008   000147   0024   24
  _ Foo-Bar0008   00013F   0024   24
  _ Foo/Bar0008   000201   0024   24
  _ Foo_Bar0008   00012F   0024   24
  _ Foo=Bar0008   000209   0024   24
  _ 0FooBar0008   000107   0024   24
  _ 1234   0008   00011F   0024   24
**End**

All generated by a common z/OS utility with documented options.
No assembler, Rexx, or user written code; only control statements.

I'll grant that some of these member names might be problematic when used with 
some facilities such as JCL or UNIX shell.

>represented by one or more members of the User Attribute Data Set 
>(UADS).  User IDs  defined in RACF today can also be defined in UADS, 
>so the restriction remains.
>
>The 7-character length restriction comes from the same source.  Users 
>in UADS have one or more members in that data set, depending on its 
>block size and the number of attributes in their user entries.  The 
>last character is numeric, so someone with a lot of attributes might 
>have UADS members USERID0-USERID9.  This causes the last character to 
>be "reserved," and as PDS members may have 1-8 character names, TSO/E 
>user IDs can be 1-7 characters in length.
> 
So why not relax the 7 character restriction for customers who are willing to 
commit to relying on RACF and forgoing UADS?  ISPF and TSO SUBMIT don't require 
a user ID prefix.  I rarely use that;
8 characters are too precious to squander on redundant information.
The TSO OUTPUT command?  How many still rely on that in preference to SDSF or 
(E)JES.  I suppose one at each site.  Sigh.  Does the SMP/E interactive 
"Command Generation" still issue "OUTPUT" after submitting a job?  It won't 
find mine.

On Thu, 15 Sep 2016 12:09:12 -0500, Tom Marchant wrote:
>On Thu, 15 Sep 2016 14:41:20 +0800, Timothy Sipples wrote:
>>The O in TSO is "Option," after all.
>
>Yes, AFAIK TSO is still an acronym for Time Sharing Option. Big deal.
>TSO was an option for OS/MVT. It never was an option for MVS.
>
Right!  Imagine the reaction from significant customers if IBM were to announce 
that the follow-on to z/OS 2.2 would eliminate TSO or even make it a separately 
(highly) priced option.  But some might benefit by eliminating TSO from most 
LPARs.

-- gil


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

Re: IODF Dynamic Activation Reversion

[Neubert, Kevin]

What change are you making?

Until you activate hardware, would expect all your software activations to be 
reversible.

You shouldn’t have to POR until you lose the ability to dynamically get to 
where you want to be.  Which more likely be due to lack of maintenance time, 
frustration, etc. and convenience of instant resolution.

For example, bad change to your only OSA.  You can’t logon to fix and go 
forward and you’re out of sync/unable to go backward.

Have you tested the activation on all your systems and/or tested the software 
only change on a test system?  The prior will highlight the changes and give 
you a better idea of the risk.

For example, some changes to an existing definition actually result in a delete 
then add of the definition.  So the respective definition would need to 
offline, not in use, etc.

Regards,

Kevin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elaine Beal
Sent: Thursday, September 15, 2016 12:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IODF Dynamic Activation Reversion

I'm rolling out IODF changes dynamically, all SOFT and HARD on the final LPAR.
Our change management rules have gotten more stringent and I need to define a 
reversion plan.

If on say, the third LPAR something goes awry and we need to back out, are 
there options besides 

1) POR  or
2) continue on to HARD  activate and then perform the process across all LPARs 
with the old IODF (soft on all except HARD on last)

I have an old ETR that says I can back out on a SOFT activate but at that point 
dynamic activation is disabled.

Thanks,
Elaine

--
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: IODF Dynamic Activation Reversion

[retired mainframer]

Can't you just reactivate the previous IODF?

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Elaine Beal
> Sent: Thursday, September 15, 2016 12:26 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IODF Dynamic Activation Reversion
> 
> I'm rolling out IODF changes dynamically, all SOFT and HARD on the final LPAR.
> Our change management rules have gotten more stringent and I need to define a 
> reversion
> plan.
> 
> If on say, the third LPAR something goes awry and we need to back out,
> are there options besides
> 
> 1) POR  or
> 2) continue on to HARD  activate and then perform the process across all 
> LPARs with the
> old IODF (soft on all except HARD on last)
> 
> I have an old ETR that says I can back out on a SOFT activate but at that 
> point dynamic
> activation is disabled.

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

Re: PDS/E Cobol

[Edward Finnell]

I'm with Lizette here.
 
I'd use XMIT to ODSN
FTP ODSN to secondary LRECL 80 BLKSIZE 3120
RECEIVE ODSN  * It will have SPACE and DCB of the original
 
 
In a message dated 9/15/2016 3:26:47 P.M. Central Daylight Time,  
stars...@mindspring.com writes:

I would  probably use an interim dataset so that there is no potential for 
PDS/E  Corruption

--
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 Thu, 15 Sep 2016 07:01:42 -0400, John Eells wrote:
>
>The MVS restriction stems from the need to name PDS members starting
>with an alphabetic or national character, as all users were originally
>
That "need" is largely a superstition.  Consider the following from an
ISPF member list, retouched only to obfuscate HLQ.

  DSLISTUser.TEMP.MIXED.CASE.LINKLIB  Row 001 of 013
  Command ===>  Scroll ===> CSR
 Name PromptAlias-of Size  TTR AC   AM   RM
  _ .FooBar0008   000117   0024   24
  _ +1 0008   000127   0024   24
  _ $FooBar0008   00010F   0024   24
  _ Foo.Bar0008   000211   0024   24
  _ Foo+Bar0008   000137   0024   24
  _ Foo$Bar0008   000219   0024   24
  _ Foo*Bar0008   000147   0024   24
  _ Foo-Bar0008   00013F   0024   24
  _ Foo/Bar0008   000201   0024   24
  _ Foo_Bar0008   00012F   0024   24
  _ Foo=Bar0008   000209   0024   24
  _ 0FooBar0008   000107   0024   24
  _ 1234   0008   00011F   0024   24
**End**

All generated by a common z/OS utility with documented options.
No assembler, Rexx, or user written code; only control statements.

I'll grant that some of these member names might be problematic
when used with some facilities such as JCL or UNIX shell.

>represented by one or more members of the User Attribute Data Set
>(UADS).  User IDs  defined in RACF today can also be defined in UADS, so
>the restriction remains.
>
>The 7-character length restriction comes from the same source.  Users in
>UADS have one or more members in that data set, depending on its block
>size and the number of attributes in their user entries.  The last
>character is numeric, so someone with a lot of attributes might have
>UADS members USERID0-USERID9.  This causes the last character to be
>"reserved," and as PDS members may have 1-8 character names, TSO/E user
>IDs can be 1-7 characters in length.
> 
So why not relax the 7 character restriction for customers who are
willing to commit to relying on RACF and forgoing UADS?  ISPF
and TSO SUBMIT don't require a user ID prefix.  I rarely use that;
8 characters are too precious to squander on redundant information.
The TSO OUTPUT command?  How many still rely on that in preference
to SDSF or (E)JES.  I suppose one at each site.  Sigh.  Does the SMP/E
interactive "Command Generation" still issue "OUTPUT" after submitting
a job?  It won't find mine.

On Thu, 15 Sep 2016 12:09:12 -0500, Tom Marchant wrote:
>On Thu, 15 Sep 2016 14:41:20 +0800, Timothy Sipples wrote:
>>The O in TSO is "Option," after all.
>
>Yes, AFAIK TSO is still an acronym for Time Sharing Option. Big deal.
>TSO was an option for OS/MVT. It never was an option for MVS.
>
Right!  Imagine the reaction from significant customers if IBM were
to announce that the follow-on to z/OS 2.2 would eliminate TSO
or even make it a separately (highly) priced option.  But some
might benefit by eliminating TSO from most LPARs.

-- 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

[Bill Woodger]

Oh, I think there's been a certain amount of "drift" in the topic. There are 
lots of simple ways the issue you mention could have occurred, even though 
we'll never know exactly.

I agree, rather than trying to give a program more CPU, I'd be wondering why it 
is sucking up all the CPU that it is. Complete CPU-hogs that actually get to a 
normal end are rare, in my experience.

--
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 15 September 2016 at 16:24, Bill Woodger  wrote:
> February this year, in the Archives, "COBOL Code Gened for MOVE COMP-3 S9(9) 
> to S9(8)"

Got it, thanks.

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

[Gibney, Dave]

The program I was talking about was 1981, pre COBOL II. We did have the Capex 
Optimizer :)

We never saw COBOL II, jumped to 3 point something and are pretty much still 
there. 

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Bill Woodger
> Sent: Thursday, September 15, 2016 1:44 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Bypassing s322
> 
> Oh, we're talking about years after 1981 :-)
> 
> Probably the middle-late '80 to early 90s.
> 
> You don't need to assert anything, it is documented. Could look it up and
> make those dates a bit more accurate, but it doesn't matter, does it?
> 
> Unfortunately, for the potential Herculean effort, pre-COBOL II for sure
> allowed negative zeros in the sense that there was no code to prevent them
> appearing as results in a COBOL program. The dates for COBOL II and the
> OSes you can run or Hercules would preclude using Hercules to show the
> first compiler which killed negative zeros in actual action.
> 
> --
> 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

[Bill Woodger]

Oh, we're talking about years after 1981 :-)

Probably the middle-late '80 to early 90s.

You don't need to assert anything, it is documented. Could look it up and make 
those dates a bit more accurate, but it doesn't matter, does it?

Unfortunately, for the potential Herculean effort, pre-COBOL II for sure 
allowed negative zeros in the sense that there was no code to prevent them 
appearing as results in a COBOL program. The dates for COBOL II and the OSes 
you can run or Hercules would preclude using Hercules to show the first 
compiler which killed negative zeros in actual action. 

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

Re: PDS/E Cobol

[Gibney, Dave]

Actually, FTP of a member from z/OS to z/OS were none of the datasets are 
physically shared should work just fine.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Lizette Koehler
> Sent: Thursday, September 15, 2016 1:27 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PDS/E Cobol
> 
> I would probably use an interim dataset so that there is no potential for
> PDS/E Corruption.
> 
> OP did not indicate the environment or more specifics that Shared Dasd, FTP.
> Sounds like they have a process that uses FTP to move programs from one
> system to another but using Shared Dasd.  I would consider using an interim
> dataset to keep PDS/E Corruption to a minimal chance.
> 
> Copy from Original library to interim file FTP interim File Copy from Interim
> file to Production Library
> 
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Paul Gilmartin
> > Sent: Thursday, September 15, 2016 10:48 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: PDS/E Cobol
> >
> > On Thu, 15 Sep 2016 10:26:53 -0700, Lizette Koehler  wrote:
> >
> > >You can use normal utilities to copy a PDS/E member to another place.
> > >
> > >TRSMAIN,
> > >TSO XMIT/RECEIVE
> > >IEBCOPY Unload
> > >
> > May require parallel sysplex.  But no need to unload; can IEBCOPY from
> > PDSE to PDSE.
> >
> > >DFDSS Dump/RESTORE
> > >
> > >If you are using PDS/E Generations, there are some challenges with that.
> >
> > -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: PDS/E Cobol

[Lizette Koehler]

I would probably use an interim dataset so that there is no potential for PDS/E 
Corruption.

OP did not indicate the environment or more specifics that Shared Dasd, FTP.  
Sounds like they have a process that uses FTP to move programs from one system 
to another but using Shared Dasd.  I would consider using an interim dataset to 
keep PDS/E Corruption to a minimal chance.

Copy from Original library to interim file
FTP interim File
Copy from Interim file to Production Library


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Thursday, September 15, 2016 10:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PDS/E Cobol
> 
> On Thu, 15 Sep 2016 10:26:53 -0700, Lizette Koehler  wrote:
> 
> >You can use normal utilities to copy a PDS/E member to another place.
> >
> >TRSMAIN,
> >TSO XMIT/RECEIVE
> >IEBCOPY Unload
> >
> May require parallel sysplex.  But no need to unload; can IEBCOPY from PDSE to
> PDSE.
> 
> >DFDSS Dump/RESTORE
> >
> >If you are using PDS/E Generations, there are some challenges with that.
> 
> -- 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

[Bill Woodger]

February this year, in the Archives, "COBOL Code Gened for MOVE COMP-3 S9(9) to 
S9(8)"

Or just search for "negative zero COBOL" I guess.

I would imagine it fair to say that a numeric field is tested more often than 
it is set.

--
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 18:05, Bill Woodger  wrote:
> Yes, the compiler generates additional code to ensure that a -ve zero cannot 
> be the result of anything in COBOL.

This would surely have potentially as much overhead as using CP rather
than CLC in the first place. Do you by any chance have an example of
the generated code for this? I don't write COBOL, so it would take me
roughly forever to come up with an example.

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

[Gibney, Dave]

The Cobol of 1981 is not the Cobol of today. Absolute statements regarding 
behavior 35 years ago are almost unprovable. Except maybe some Herculean effort 
:)

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Bill Woodger
> Sent: Thursday, September 15, 2016 10:00 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Bypassing s322
> 
> Ah. Well. Preferred signs.
> 
> The thing is, preferred signs are not a problem as output from a "decimal
> instruction", because no matter what goes in (as long the sign is A-F, else
> Bang!) then only C or D can come out. No enforcing is necessary, it is just 
> the
> way it happens.
> 
> Calculations in COBOL only generate C or D, and if the required result is to 
> be
> unsigned, code is generated by the compiler to "clobber" the sign to an F.
> 
> COBOL cannot generate a non-preferred sign (A, B, E) and there is no
> compiler-generated code to modify any potential production of same (if
> someone wants to get picky about F, then they can just pretend that I qualify
> correctly everywhere a correct qualification would apply).
> 
> There has to be compiler-generated code to allow for the initial generation,
> by "multiply", or by truncation, of a "negative zero".
> 
> So they are different there.
> 
> You *can still get* negative zeros in a COBOL program. There is no check on
> "source" to prevent a negative zero being involved (specifically as a negative
> zero). Thus, an incoming record or other incoming data, especially from an
> "external" source, but even from a non-COBOL source, could contain a
> negative zero and things could go badly. Another way is by screwing up with
> REDEFINES or group-MOVEs or LINKAGE SECTION definitions.
> 
> Which takes us to non-preferred signs, where basically the culprits are the
> same, but also adding COBOL generation where the same "data" is defined in
> different ways (signed and unsigned) in different places.
> 
> But yes, "character compares" (faster) over "decimal compares" does
> require that actual equivalence exists where logical equivalence exists, if
> your data doesn't "conform to PICture" (if it can contain "non-preferred"
> signs, and yes, for a signed field, that includes an F). So character compares
> require conformance to PICture, and that is what you promise with compiler
> option NUMPROC with sub-option PFD.
> 
> For NOPFD, the compiler has to either generate code to clobber (rectify) the
> signs in a temporary-stoage copy of the data, for comparisons, or to use the
> decimal instructions.
> 
> Then there was NUMPROC(MIG). An old "migration" setting, to have COBOL II
> for data with non-preferred signs behave more like OS/VS COBOL. However,
> since MIG was "faster" than NOPFD, and less hated than PFD (contentious),
> MIG survived a long time, until it disappeared with V5.
> 
> Its disappearance caused angst. However, there is "good" news. The code
> generated by NOPFD has been improved (PTF) and NOPFD is now much more
> comparable to what MIG was, and closer in performance to PFD. So if you
> have sloppy data, by accident or design, there is less of a performance hit.
> 
> There is not (as far as I'm aware) less of a "data hit". By this I mean the
> capability of NOPFD to take "bad data" and make it look good, which is
> extended over what is possible with PFD. NOPFD does use CLCs at times. PFD
> does use CP at times. I am writing of up to V4.2, heaps of things have changed
> for V5+ and anything could be different.
> 
> --
> 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

[Gibney, Dave]

I am pretty sure I misremembered it as binary and in reality it was packed. I 
didn't actually write the code. It was a subroutine that tried to distribute 
the difference due to rounding across a variable and not small number or 
"transactions". This was during testing and it didn't get into production with 
the failure in place. Of course, in 1981, we only had the one MVS system, so 
testing and production were commingled.

My original note was meant to reinforce the idea that if a program is using 
larger than expect amounts of CPU time, giving it more time is not always a 
good idea and that identifying why the CPU use is high can be more productive.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Tom Marchant
> Sent: Thursday, September 15, 2016 8:41 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Bypassing s322
> 
> On Wed, 14 Sep 2016 15:34:32 -0500, Bill Woodger wrote:
> 
> >When IBM decided to use "character" comparisons where possible for
> numerics, they had to ban the negative zero.
> 
> They also had to enforce the preferred sign. Just as X'0C' and X'0D' would be
> equal using a CP instruction, they are also equal to X'0F', but they are not
> when performing a character compare.
> 
> As to the idea that X'8000' could be a negative zero, consider what
> happens when you add 1 to it. You get X'8001'.
> 
> Dave may indeed have had a loop that used a binary counter that started out
> negative and eventually reached X'8000'. Someone at the time may
> have looked at and mistakenly thought that it was negative zero, but it would
> have in fact been the maximum negative number, and subtracting one again
> would have resulted in overflow. If the overflow was ignored, the value
> would then be X'7FFF'. It would take a while for that counter to reach
> zero.
> 
> --
> Tom Marchant
> 
> --
> 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

IODF Dynamic Activation Reversion

[Elaine Beal]

I'm rolling out IODF changes dynamically, all SOFT and HARD on the final LPAR.
Our change management rules have gotten more stringent and I need to define a 
reversion plan.

If on say, the third LPAR something goes awry and we need to back out,
are there options besides 

1) POR  or 
2) continue on to HARD  activate and then perform the process across all LPARs 
with the old IODF (soft on all except HARD on last)

I have an old ETR that says I can back out on a SOFT activate but at that point 
dynamic activation is disabled.

Thanks,
Elaine

--
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]

Well, try to IMPORT the back-up on a test system or different name and see what 
happens.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of willie bunter
> Sent: Thursday, September 15, 2016 10:07 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: REASON: 3 - RECORD TYPE NOT RECOGNIZED
> 
> I was told that EXPORT/IMPORT would not fix the problem because it would
> export the bad records only REPOR MERGECAT would work.
> 
> I ran a LISTCAT on the dataset (as flagged by the DIAGNOSE) and it came
> clean.  This leads me to believe that it may not be the offending dsn.  The 
> dsn
> is on the volumes (3)
> 
> The catalog is backed up via IDCAMS EXPORT daily successfully.
> 
> I plan to run a VERIFY/EXAMINE (as recommended) and see what comes out.
> 
> 
> On Wed, 9/14/16, retired mainframer 
> wrote:
> 
>  Subject: Re: REASON: 3 - RECORD TYPE NOT RECOGNIZED
>  To: IBM-MAIN@LISTSERV.UA.EDU
>  Received: Wednesday, September 14, 2016, 12:37 PM
> 
>  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-
> m...@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
> 
> --
> 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: PDS/E Cobol

[Gibney, Dave]

You can't update a PDS/E from one Lpar and expect the updates to be seen from 
another Lpar unless you are sharing in at least a basic Sysplex. A mixed set of 
Monoplexs like mine need not apply. And if the update is in anyway 
bidirectional, you will experience a corrupted PDS/E

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Paul Gilmartin
> Sent: Thursday, September 15, 2016 10:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PDS/E Cobol
> 
> On Thu, 15 Sep 2016 10:26:53 -0700, Lizette Koehler  wrote:
> 
> >You can use normal utilities to copy a PDS/E member to another place.
> >
> >TRSMAIN,
> >TSO XMIT/RECEIVE
> >IEBCOPY Unload
> >
> May require parallel sysplex.  But no need to unload; can IEBCOPY from PDSE
> to PDSE.
> 
> >DFDSS Dump/RESTORE
> >
> >If you are using PDS/E Generations, there are some challenges with that.
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: PDS/E Cobol

[Jousma, David]

I think the requirement was separate sysplex's.  So, don’t copy pdse to pdse 
unless you want a mess.

_
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 Paul Gilmartin
Sent: Thursday, September 15, 2016 1:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PDS/E Cobol

On Thu, 15 Sep 2016 10:26:53 -0700, Lizette Koehler  wrote:

>You can use normal utilities to copy a PDS/E member to another place.
>
>TRSMAIN,
>TSO XMIT/RECEIVE
>IEBCOPY Unload
>
May require parallel sysplex.  But no need to unload; can IEBCOPY from PDSE to 
PDSE.

>DFDSS Dump/RESTORE
>
>If you are using PDS/E Generations, there are some challenges with that.

-- gil

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


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


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

Re: REASON: 3 - RECORD TYPE NOT RECOGNIZED

[retired mainframer]

Told by whom?  Since the error message says an I/O error occurred, it seems the 
offending record would be unreadable to any process.

What happens if you LISTCAT the entire catalog?  Do it in batch since TSO 
automatically changes the command if you don't specify an ENTRIES or LEVEL 
operand.  (This will also give you a list of all the HLQs you will need for the 
MERGECAT.)  If it comes back clean, then DIAGNOSE may be reporting a problem in 
a currently unused area.  In that case, MERGECAT might not have any problem at 
all.  If there is an error message, it might give more detail than DIAGNOSE did.

If the daily EXPORT runs OK, it should be impossible for IMPORT to build a bad 
record.  If anything is wrong with the exported data, I would expect IMPORT to 
either discard the offending record with a suitable info diagnostic 
(preferable) or abort the entire effort.

EXAMINE is concerned with BCS/VVDS consistency.  I don't think it cares that 
much about catalog structure.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of willie bunter
> Sent: Thursday, September 15, 2016 10:07 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: REASON: 3 - RECORD TYPE NOT RECOGNIZED
> 
> I was told that EXPORT/IMPORT would not fix the problem because it would 
> export the
> bad records only REPOR MERGECAT would work.
> 
> I ran a LISTCAT on the dataset (as flagged by the DIAGNOSE) and it came 
> clean.  This
> leads me to believe that it may not be the offending dsn.  The dsn is on the 
> volumes (3)
> 
> The catalog is backed up via IDCAMS EXPORT daily successfully.
> 
> I plan to run a VERIFY/EXAMINE (as recommended) and see what comes out.

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

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

[Charles Mills]

I am told that was a fallout, not the reason.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: Thursday, September 15, 2016 10:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: TSO User ID Rules (Was: z/OS and code pages)

Or was it because the default jobname was tso userid plus 1 character and a 
jobname could only be 8 characters?

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

Re: PDS/E Cobol

[Paul Gilmartin]

On Thu, 15 Sep 2016 10:26:53 -0700, Lizette Koehler  wrote:

>You can use normal utilities to copy a PDS/E member to another place.
>
>TRSMAIN,
>TSO XMIT/RECEIVE
>IEBCOPY Unload
>
May require parallel sysplex.  But no need to unload; can IEBCOPY from
PDSE to PDSE.

>DFDSS Dump/RESTORE
>
>If you are using PDS/E Generations, there are some challenges with that.

-- gil

--
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)

[Charles Mills]

I am told off-list that that is probably the main reason.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Thursday, September 15, 2016 10:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TSO User ID Rules (Was: z/OS and code pages)

Did the reason for the 7 char TSO HLQ come from the UADS process needing the 
last char in the member name to chain the information for a given TSO ID in 
SYS1.UADS (think ACCOUNT Function)?

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

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

[Jerry Whitteridge]

My misty memories say yes - the last char was used in chaining multiple entries 
based on the first 7.

Jerry Whitteridge
Manager Mainframe Systems & Storage
Albertsons - Safeway Inc.
925 738 9443
Corporate Tieline - 89443

If you feel in control
you just aren't going fast enough.




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Thursday, September 15, 2016 10:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: TSO User ID Rules (Was: z/OS and code pages)

Did the reason for the 7 char TSO HLQ come from the UADS process needing the 
last char in the member name to chain the information for a given TSO ID in 
SYS1.UADS (think ACCOUNT Function)?

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Mike Schwab
> Sent: Thursday, September 15, 2016 10:19 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: TSO User ID Rules (Was: z/OS and code pages)
>
> The TSO ID is used as a HLQ for data set names.  Therefore it must meet the
> rules for MVS Dataset names: first character A-Z@#$, second to seventh
> character A-Z@#$0-9, max 7 due to PDS member needing 8th character.  Minimum
> length determined by site.
>
> On Thu, Sep 15, 2016 at 11:19 AM, Tony Harminc  wrote:
> > On 15 September 2016 at 02:41, Timothy Sipples  wrote:
> >> 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. :)
> >
> > I already had, and the phrase "MVS subsystem" does not appear in that book.
> >
> >> 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')."
> >
> > That says nothing about "subsystem". You appear to have inserted the
> > word, and I'm just trying to understand why and with what meaning.
> >
> >> 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.
> >
> > I obviously wasn't clear: It's the "subsystem" part I'm asking about,
> > not the "MVS" part. I know at least a couple of meanings of the word
> > "subsystem" in MVS. But I don't know of any such usage that sets these
> > additional requirements for userids. Unless you are using it with some
> > trivial meaning like "stuff that runs on MVS that isn't UNIX or TSO
> > and somehow, you know, does stuff with userids".
> >
> > Tony H.
> >

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

 Warning: All e-mail sent to this address will be received by the corporate 
e-mail system, and is subject to archival and review by someone other than the 
recipient. This e-mail may contain proprietary information and is intended only 
for the use of the intended recipient(s). If the reader of this message is not 
the intended recipient(s), you are notified that you have received this message 
in error and that any review, dissemination, distribution or copying of this 
message is strictly prohibited. If you have received this message in error, 
please notify the sender immediately.


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

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

[Dyck, Lionel B. (TRA)]

Or was it because the default jobname was tso userid plus 1 character and a 
jobname could only be 8 characters?

--
Lionel B. Dyck (TRA Contractor)
Mainframe Systems Programmer 
Enterprise Infrastructure Support (Station 200) (005OP6.3.10)
VA OI Service Delivery & Engineering


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Thursday, September 15, 2016 12:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: TSO User ID Rules (Was: z/OS and code pages)

Did the reason for the 7 char TSO HLQ come from the UADS process needing the 
last char in the member name to chain the information for a given TSO ID in 
SYS1.UADS (think ACCOUNT Function)?

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Mike Schwab
> Sent: Thursday, September 15, 2016 10:19 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: TSO User ID Rules (Was: z/OS and code pages)
> 
> The TSO ID is used as a HLQ for data set names.  Therefore it must 
> meet the rules for MVS Dataset names: first character A-Z@#$, second 
> to seventh character A-Z@#$0-9, max 7 due to PDS member needing 8th 
> character.  Minimum length determined by site.
> 
> On Thu, Sep 15, 2016 at 11:19 AM, Tony Harminc  wrote:
> > On 15 September 2016 at 02:41, Timothy Sipples  wrote:
> >> 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. :)
> >
> > I already had, and the phrase "MVS subsystem" does not appear in that book.
> >
> >> 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')."
> >
> > That says nothing about "subsystem". You appear to have inserted the 
> > word, and I'm just trying to understand why and with what meaning.
> >
> >> 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.
> >
> > I obviously wasn't clear: It's the "subsystem" part I'm asking 
> > about, not the "MVS" part. I know at least a couple of meanings of 
> > the word "subsystem" in MVS. But I don't know of any such usage that 
> > sets these additional requirements for userids. Unless you are using 
> > it with some trivial meaning like "stuff that runs on MVS that isn't 
> > UNIX or TSO and somehow, you know, does stuff with userids".
> >
> > Tony H.
> >

--
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)

[Lizette Koehler]

Did the reason for the 7 char TSO HLQ come from the UADS process needing the 
last char in the member name to chain the information for a given TSO ID in 
SYS1.UADS (think ACCOUNT Function)?

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Mike Schwab
> Sent: Thursday, September 15, 2016 10:19 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: TSO User ID Rules (Was: z/OS and code pages)
> 
> The TSO ID is used as a HLQ for data set names.  Therefore it must meet the
> rules for MVS Dataset names: first character A-Z@#$, second to seventh
> character A-Z@#$0-9, max 7 due to PDS member needing 8th character.  Minimum
> length determined by site.
> 
> On Thu, Sep 15, 2016 at 11:19 AM, Tony Harminc  wrote:
> > On 15 September 2016 at 02:41, Timothy Sipples  wrote:
> >> 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. :)
> >
> > I already had, and the phrase "MVS subsystem" does not appear in that book.
> >
> >> 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')."
> >
> > That says nothing about "subsystem". You appear to have inserted the
> > word, and I'm just trying to understand why and with what meaning.
> >
> >> 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.
> >
> > I obviously wasn't clear: It's the "subsystem" part I'm asking about,
> > not the "MVS" part. I know at least a couple of meanings of the word
> > "subsystem" in MVS. But I don't know of any such usage that sets these
> > additional requirements for userids. Unless you are using it with some
> > trivial meaning like "stuff that runs on MVS that isn't UNIX or TSO
> > and somehow, you know, does stuff with userids".
> >
> > Tony H.
> >

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

Re: PDS/E Cobol

[Lizette Koehler]

You can use normal utilities to copy a PDS/E member to another place.

TRSMAIN,
TSO XMIT/RECEIVE
IEBCOPY Unload
DFDSS Dump/RESTORE

If you are using PDS/E Generations, there are some challenges with that.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lopez, Sharon
> Sent: Thursday, September 15, 2016 10:17 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: PDS/E Cobol
> 
> I know there has been a lot on here about the new versions of Cobol and PDS/E.
> I need some understanding, please.  We have a development lpar (SYSPLEX)
> sharing dasd with production lpar SYSPLEX.  Will we be able to FTP the
> development load mod to the production lpar?
> 
> Thank you.
> 

--
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)

[Mike Schwab]

The TSO ID is used as a HLQ for data set names.  Therefore it must
meet the rules for MVS Dataset names: first character A-Z@#$, second
to seventh character A-Z@#$0-9, max 7 due to PDS member needing 8th
character.  Minimum length determined by site.

On Thu, Sep 15, 2016 at 11:19 AM, Tony Harminc  wrote:
> On 15 September 2016 at 02:41, Timothy Sipples  wrote:
>> 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. :)
>
> I already had, and the phrase "MVS subsystem" does not appear in that book.
>
>> 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')."
>
> That says nothing about "subsystem". You appear to have inserted the
> word, and I'm just trying to understand why and with what meaning.
>
>> 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.
>
> I obviously wasn't clear: It's the "subsystem" part I'm asking about,
> not the "MVS" part. I know at least a couple of meanings of the word
> "subsystem" in MVS. But I don't know of any such usage that sets these
> additional requirements for userids. Unless you are using it with some
> trivial meaning like "stuff that runs on MVS that isn't UNIX or TSO
> and somehow, you know, does stuff with userids".
>
> Tony H.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

PDS/E Cobol

[Lopez, Sharon]

I know there has been a lot on here about the new versions of Cobol and PDS/E.  
I need some understanding, please.  We have a development lpar (SYSPLEX) 
sharing dasd with production lpar SYSPLEX.  Will we be able to FTP the 
development load mod to the production lpar?

Thank you.



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: TSO User ID Rules (Was: z/OS and code pages)

[Tom Marchant]

On Thu, 15 Sep 2016 14:41:20 +0800, Timothy Sipples wrote:

>The O in TSO is "Option," after all.

Yes, AFAIK TSO is still an acronym for Time Sharing Option. Big deal.
TSO was an option for OS/MVT. It never was an option for MVS.

-- 
Tom Marchant

--
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]

I was told that EXPORT/IMPORT would not fix the problem because it would export 
the bad records only REPOR MERGECAT would work.

I ran a LISTCAT on the dataset (as flagged by the DIAGNOSE) and it came clean.  
This leads me to believe that it may not be the offending dsn.  The dsn is on 
the volumes (3) 

The catalog is backed up via IDCAMS EXPORT daily successfully.

I plan to run a VERIFY/EXAMINE (as recommended) and see what comes out.  


On Wed, 9/14/16, retired mainframer  wrote:

 Subject: Re: REASON: 3 - RECORD TYPE NOT RECOGNIZED
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Wednesday, September 14, 2016, 12:37 PM
 
 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

--
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]

Ah. Well. Preferred signs.

The thing is, preferred signs are not a problem as output from a "decimal 
instruction", because no matter what goes in (as long the sign is A-F, else 
Bang!) then only C or D can come out. No enforcing is necessary, it is just the 
way it happens.

Calculations in COBOL only generate C or D, and if the required result is to be 
unsigned, code is generated by the compiler to "clobber" the sign to an F.

COBOL cannot generate a non-preferred sign (A, B, E) and there is no 
compiler-generated code to modify any potential production of same (if someone 
wants to get picky about F, then they can just pretend that I qualify correctly 
everywhere a correct qualification would apply).

There has to be compiler-generated code to allow for the initial generation, by 
"multiply", or by truncation, of a "negative zero".

So they are different there.

You *can still get* negative zeros in a COBOL program. There is no check on 
"source" to prevent a negative zero being involved (specifically as a negative 
zero). Thus, an incoming record or other incoming data, especially from an 
"external" source, but even from a non-COBOL source, could contain a negative 
zero and things could go badly. Another way is by screwing up with REDEFINES or 
group-MOVEs or LINKAGE SECTION definitions.

Which takes us to non-preferred signs, where basically the culprits are the 
same, but also adding COBOL generation where the same "data" is defined in 
different ways (signed and unsigned) in different places.

But yes, "character compares" (faster) over "decimal compares" does require 
that actual equivalence exists where logical equivalence exists, if your data 
doesn't "conform to PICture" (if it can contain "non-preferred" signs, and yes, 
for a signed field, that includes an F). So character compares require 
conformance to PICture, and that is what you promise with compiler option 
NUMPROC with sub-option PFD.

For NOPFD, the compiler has to either generate code to clobber (rectify) the 
signs in a temporary-stoage copy of the data, for comparisons, or to use the 
decimal instructions.

Then there was NUMPROC(MIG). An old "migration" setting, to have COBOL II for 
data with non-preferred signs behave more like OS/VS COBOL. However, since MIG 
was "faster" than NOPFD, and less hated than PFD (contentious), MIG survived a 
long time, until it disappeared with V5.

Its disappearance caused angst. However, there is "good" news. The code 
generated by NOPFD has been improved (PTF) and NOPFD is now much more 
comparable to what MIG was, and closer in performance to PFD. So if you have 
sloppy data, by accident or design, there is less of a performance hit.

There is not (as far as I'm aware) less of a "data hit". By this I mean the 
capability of NOPFD to take "bad data" and make it look good, which is extended 
over what is possible with PFD. NOPFD does use CLCs at times. PFD does use CP 
at times. I am writing of up to V4.2, heaps of things have changed for V5+ and 
anything could be different.

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

Re: Two running job program name discovery questions

[Dan]

I have a very old SPL: SMF manual.  For SMF30PGM it shows the source is 
SCTPGMNM.
I wish they still showed where the data came from in the doc as well as the 
MACRO itself.

Dan

--
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 15 September 2016 at 02:41, Timothy Sipples  wrote:
> 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. :)

I already had, and the phrase "MVS subsystem" does not appear in that book.

> 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')."

That says nothing about "subsystem". You appear to have inserted the
word, and I'm just trying to understand why and with what meaning.

> 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.

I obviously wasn't clear: It's the "subsystem" part I'm asking about,
not the "MVS" part. I know at least a couple of meanings of the word
"subsystem" in MVS. But I don't know of any such usage that sets these
additional requirements for userids. Unless you are using it with some
trivial meaning like "stuff that runs on MVS that isn't UNIX or TSO
and somehow, you know, does stuff with userids".

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

[Tom Marchant]

On Wed, 14 Sep 2016 15:34:32 -0500, Bill Woodger wrote:

>When IBM decided to use "character" comparisons where possible for numerics, 
>they had to ban the negative zero.

They also had to enforce the preferred sign. Just as X'0C' and X'0D' would be 
equal using a CP instruction, they are also equal to X'0F', but they are not 
when performing a character compare.

As to the idea that X'8000' could be a negative zero, consider what happens 
when you add 1 to it. You get X'8001'.

Dave may indeed have had a loop that used a binary counter that started out 
negative and eventually reached X'8000'. Someone at the time may have 
looked at and mistakenly thought that it was negative zero, but it would have 
in fact been the maximum negative number, and subtracting one again would have 
resulted in overflow. If the overflow was ignored, the value would then be 
X'7FFF'. It would take a while for that counter to reach zero.

-- 
Tom Marchant

--
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]

Hi,

SMF 42 seems to be useful only at dataset level (subtype 23).

Other subtypes members related seem to be only for update purpose.

I've already tried DAF and it seems to know member (from SMF 30 JFCB) only
if the DDNAME is "library(member)" type.

Regards.
Massimo

2016-09-15 15:06 GMT+02:00 Lizette Koehler :

> If the REXX/CLIST is a member in a dataset, then SMF Type 42 records may
> be helpful.  It can track in a subtype the use of a member.  It will depend
> on your level of z/OS.
>
> If it is instream, then I think harder to do.
>
> There was or is an SMF Parm for CLISTs I think.  It has been  some time
> since I looked at that.
>
> Do you have tools like:  SAS/MXG, SAS/MICS, Tivoli, etc.?  Otherwise I
> think DFSORT ICETOOLS can use the SMF Type 42 and break it down.
>
> Other option is to install DAF from cbttape.org.  You can tailor that to
> what you need for SMF reporting.
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Massimo Biancucci
> > Sent: Thursday, September 15, 2016 3:12 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Capture REXX/CLIST software usage.
> >
> > My main goal is to find out who uses what.
> >
> > If I will success after a while I'll have a view of what REXX/CLIST are
> still
> > in use.
> >
> > I'm working on systems who were build ages ago and dealing with different
> > thousands of exec on tenth of libraries.
> >
> > The VLF maybe a parallel way even though I've to discuss with customer in
> > order to evaluate pro (a lot) and cons.
> >
> > I know that the more I monitor the worst I get, anyway we use TADz to
> delete
> > old applications and we'd like to do the same for system pgmr stuffs.
> >
> > Thanks again to everybody.
> > Massimo
> >
> > 2016-09-15 3:04 GMT+02:00 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: serial numbers ... real and imagine

[Holst, Jeffrey A]

It has been a while since I worked with VM, and I can only recall one vendor 
product that bothered to check to see if it was running on an unauthorized CPU 
under VM.

In order to do that check, a program would first do the normal CPU serial 
number check. Even when the VM directory provides a virtual CPU serial number, 
the high order byte is X'FF', so a program checking the CPU serial number knows 
it is running on a virtual machine. I seem to recall that there is a machine 
instruction of some sort that when running under VM will return the real CPU 
serial and model information. The virtual machine must have the authority to 
issue that instruction.  If it did not have the authority, some sort of error 
is returned or condition code set. 

The vendor product therefore required that if it was used on a virtual machine, 
the virtual machine have the authority to issue the necessary machine 
instruction.  If it did not, the product considered the product to be running 
on an unauthorized CPU. 

Jeffrey Holst
Systems Administator Senior
Technology and Operations, Shared Services
PNC Bank




The contents of this email are the property of PNC. If it was not addressed to 
you, you have no legal right to read it. If you think you received it in error, 
please notify the sender. Do not forward or copy without permission of the 
sender. This message may be considered a commercial electronic message under 
Canadian law or this message may contain an advertisement of a product or 
service and thus may constitute a commercial electronic mail message under US 
law. You may unsubscribe at any time from receiving commercial electronic 
messages from PNC at http://pages.e.pnc.com/globalunsub/
PNC, 249 Fifth Avenue, Pittsburgh, PA 15222; pnc.com




--
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

[Donald J.]

What is the output of :

RACDCERT ID(MP81136) LISTRING(bexarftp)

-- 
  Donald J.
  dona...@4email.net

On Wed, Sep 14, 2016, at 08:05 AM, Mark Pace wrote:
> 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

-- 
http://www.fastmail.com - Choose from over 50 domains or use your own

--
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)

[Charles Mills]

There's also something with TSO "liking" jobnames of the userid plus one
letter, right?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of John Eells
Sent: Thursday, September 15, 2016 4:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TSO User ID Rules (Was: z/OS and code pages)

Timothy Sipples wrote:

> "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.

The MVS restriction stems from the need to name PDS members starting with an
alphabetic or national character, as all users were originally represented
by one or more members of the User Attribute Data Set (UADS).  User IDs
defined in RACF today can also be defined in UADS, so the restriction
remains.

The 7-character length restriction comes from the same source.  Users in
UADS have one or more members in that data set, depending on its block size
and the number of attributes in their user entries.  The last character is
numeric, so someone with a lot of attributes might have UADS members
USERID0-USERID9.  This causes the last character to be "reserved," and as
PDS members may have 1-8 character names, TSO/E user IDs can be 1-7
characters in length.

--
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]

Finally got it to work with the help from my TCP/IP group.  Thanks to all.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kurt Quackenbush
Sent: Thursday, September 15, 2016 9:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E Receive FROMNETWORK

On 9/14/2016 4:08 PM, Lopez, Sharon wrote:
> 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?

Read this, and it should answer your questions:
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



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: serial numbers ... real and imagine)

[Pommier, Rex]

Dana and Anne,

This is what I recall as well.  I don't believe any of our third party software 
had issues with running on a z/OS client running on VM once the DR facility 
plugged the correct virtual serial number in.  As you said, we had some issues 
with a couple products (sorry, I don't remember what they were) refusing to 
work due to machine type/capacity setting being incorrect.  In one case we got 
bit because - as providence would have it - we happened to be running on a z10 
as was the DR facility.  In the ensuing year we upgraded to a z12 and the DR 
facility was still on the z10 and this product stopped working.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dana Mitchell
Sent: Thursday, September 15, 2016 8:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: serial numbers ... real and imagine)

Sorry Anne, I wasn't implying anything with my quote,  I was merely throwing it 
out there as supporting the reason that software vendors check serial numbers, 
catching implementation mistakes more often than nefarious intents...  
Especially in today's outsourced or skills deficient systems environments that 
seem to becoming more common as Charles noted.

I do recall in the past, setting our real CPU serial numbers in the VM images 
at a DR site, and at the time it seems like some software products were OK with 
it.   Others were OK with the feigned serial number but complained about the 
CPU model number (I don't remember if the 'real' CPU model number showed 
through or it was something clever like x'FF')

Dana

On Thu, 15 Sep 2016 13:14:34 +, Adams, Anne (DTI)  
wrote:
>I guess I’m not really explaining myself too well here. Firstly, I'm 
>not suggesting doing anything illegal or anything that would violate 
>any licensing >agreements. (Jiminy Crickets, what sort of person do you 
>think I am?)
 

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


--
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)

[John Eells]

Timothy Sipples wrote:


"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.


The MVS restriction stems from the need to name PDS members starting 
with an alphabetic or national character, as all users were originally 
represented by one or more members of the User Attribute Data Set 
(UADS).  User IDs  defined in RACF today can also be defined in UADS, so 
the restriction remains.


The 7-character length restriction comes from the same source.  Users in 
UADS have one or more members in that data set, depending on its block 
size and the number of attributes in their user entries.  The last 
character is numeric, so someone with a lot of attributes might have 
UADS members USERID0-USERID9.  This causes the last character to be 
"reserved," and as PDS members may have 1-8 character names, TSO/E user 
IDs can be 1-7 characters in length.


--
John Eells
IBM Poughkeepsie
ee...@us.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)

[Dana Mitchell]

Sorry Anne, I wasn't implying anything with my quote,  I was merely throwing it 
out there as supporting the reason that software vendors check serial numbers, 
catching implementation mistakes more often than nefarious intents...  
Especially in today's outsourced or skills deficient systems environments that 
seem to becoming more common as Charles noted.

I do recall in the past, setting our real CPU serial numbers in the VM images 
at a DR site, and at the time it seems like some software products were OK with 
it.   Others were OK with the feigned serial number but complained about the 
CPU model number (I don't remember if the 'real' CPU model number showed 
through or it was something clever like x'FF')

Dana

On Thu, 15 Sep 2016 13:14:34 +, Adams, Anne (DTI)  
wrote:
>I guess I’m not really explaining myself too well here. Firstly, I'm not 
>suggesting doing anything illegal or anything that would violate any licensing 
>>agreements. (Jiminy Crickets, what sort of person do you think I am?) 


--
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)

[Adams, Anne (DTI)]

I guess I’m not really explaining myself too well here. Firstly, I'm not 
suggesting doing anything illegal or anything that would violate any licensing 
agreements. (Jiminy Crickets, what sort of person do you think I am?)

In z/VM, I there is a command SET CPUID, that will change the CPU identifier 
for a virtual processor. As our DR runs a z/OS guest under z/VM. we have 
considered using this feature in order to not have to change the license keys 
for a number of products. We're already licensed to run at the site by all 
vendors. Some products have no license keys, so no problem. Others, like those 
provided by CA will issue a "nasty-gram" about an incorrect key, but will allow 
us to run, so still no problem. A few however, require a new key. A certain 
amount of "angst" occurs in obtaining and applying those keys. Yes, I suppose 
it is a customer service, documentation, training the staff, issue ... but it 
is an issue. One that I'd like to circumvent if I can. According to all our 
vendors, this does not violate or software agreement(s). Asking the vendors 
where they obtain the CPU identifier in order to validate their keys is proving 
somewhat difficult as in many cases, Level One support honestly doesn't know. I 
know I can just "run this and see what happens" but I was curious if there was 
a way to determine beforehand where or how a product was pulling the CPU 
identifier in order to validate their key. 

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Longabaugh, Robert E
Sent: Wednesday, September 14, 2016 5:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: CA Technologies LMP key at DR sites (WAS: serial numbers ... real and 
imagine)

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

--
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]

If the REXX/CLIST is a member in a dataset, then SMF Type 42 records may be 
helpful.  It can track in a subtype the use of a member.  It will depend on 
your level of z/OS.

If it is instream, then I think harder to do.

There was or is an SMF Parm for CLISTs I think.  It has been  some time since I 
looked at that.

Do you have tools like:  SAS/MXG, SAS/MICS, Tivoli, etc.?  Otherwise I think 
DFSORT ICETOOLS can use the SMF Type 42 and break it down.

Other option is to install DAF from cbttape.org.  You can tailor that to what 
you need for SMF reporting.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Massimo Biancucci
> Sent: Thursday, September 15, 2016 3:12 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Capture REXX/CLIST software usage.
> 
> My main goal is to find out who uses what.
> 
> If I will success after a while I'll have a view of what REXX/CLIST are still
> in use.
> 
> I'm working on systems who were build ages ago and dealing with different
> thousands of exec on tenth of libraries.
> 
> The VLF maybe a parallel way even though I've to discuss with customer in
> order to evaluate pro (a lot) and cons.
> 
> I know that the more I monitor the worst I get, anyway we use TADz to delete
> old applications and we'd like to do the same for system pgmr stuffs.
> 
> Thanks again to everybody.
> Massimo
> 
> 2016-09-15 3:04 GMT+02:00 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

Re: SMP/E Receive FROMNETWORK

[Kurt Quackenbush]

On 9/14/2016 4:08 PM, Lopez, Sharon wrote:

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?


Read this, and it should answer your questions:
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: Bypassing s322

[Joel C. Ewing]

On 09/15/2016 01:02 AM, Bill Woodger wrote:
> 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.
More precisely the PoP should have said "by the rules of algebra from
the multiplier and multiplicand signs for a nonzero result and setting
the sign in a similar manner even if one or both operands are zeros". 
Yeah, we can tell what they mean, but the wording is imprecise whether
they meant to imply that the rules of algebra address the zero case or
that they are just extending those rules as if the result were
nonzero.   Since the rules of algebra don't associate any sign with
zero, the latter interpretation is the only reasonable one.
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

Re: ServerPAC/DB2

[Paul Jodlowski]

Lisette:
Installed through ISPF here are the jobs I ran. Stopped after DSNTIDXA because 
was doing an upgrade.  And the DBA did the rest
==> INSTALLATION JOBS   
 
DOC RUNNING INSTALLATION JOBS   
 
DOC INSTALLATION SETUP  

JOB INITIALIZE REQUIRED DASD  OFFLINIT 00 JOB09452
DOC DEFINE CATALOGS AND RESTORE 
   
JOB RACF PROFILES ON DRIVING SYSTEMRACFDRV  00 JOB00844
JOB DEFINE CATALOGSDEFCAT   00 
JOB09530
JOB DEFINE SYSTEM-SPECIFIC ALIASES  DEFSSA   00 JOB09533
JOB ALLOCATE AND CATALOG DSALLOCDS  00 JOB00855
JOB RESTORE DATA SETSRESTORE  04 
JOB01697
JOB UPDATE SUBSYSTEM PARMLIB  CPPUPDT  00 JOB01715
JOB RENAME DS TO FINAL NAMEALTCAT   00  
 
DOC DEFINE NEW SMP/E ENVIRONMENT
  
JOB UPDATE NEW SMP/E DDDEFSUP   04 JOB01727
DOC BUILD POST-APPLY LINKS  

JOB EXECUTE POST-APPLY LINKCALLLINK 00 JOB01732
DOC INSTALL IFREQ MAINTENANCE   
 
JOB SMP/E REPORT SYSMODS CMD  SMPREP   04 JOB02560
DOC MIGRATION   
 

  
==> DB2 POST-INSTALLATION TASKS 
   
DOC DB2 POST-INSTALL TASKS  

DOC DB2 10 FOR Z/OS 10.1.0  

JOB BUILD A DB2 ISPF PROCEDURE  LOGDB2   00 JOB02611
JOB COPY ISR@PRIM PANEL TO SDSNSPFPISRPRIM  04 JOB02615
JOB UPDATE SYS1.PARMLIB FOR DB2DB2PARM  00 JOB02617
JOB CREATE THE INSTALL CLIST INPUT  DSNTIDXA 00 JOB02619


>>> On 9/14/2016 at 2:35 PM, in message 
>>> <024a01d20ebf$1d882610$58987230$@mindspring.com>, Lizette Koehler 
>>>  wrote:
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

--
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]

My main goal is to find out who uses what.

If I will success after a while I'll have a view of what REXX/CLIST are
still in use.

I'm working on systems who were build ages ago and dealing with different
thousands of exec on tenth of libraries.

The VLF maybe a parallel way even though I've to discuss with customer in
order to evaluate pro (a lot) and cons.

I know that the more I monitor the worst I get, anyway we use TADz to
delete old applications and we'd like to do the same for system pgmr stuffs.

Thanks again to everybody.
Massimo

2016-09-15 3:04 GMT+02:00 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
>

--
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)

[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