Free z/OS System Automation Software at Share

[Brian Westerman]

Hi,

We are again going to be handing out coupons at Share in LA for a free copy of 
any ONE of our automation software products, and I remember that last time I 
did this (2010) I received a bunch of calls and email from people after the 
fact who felt they were "left out and/or screwed" just because they didn't or 
couldn't attend Share that time.

So this time I wanted to make the offer ahead of time so that (hopefully) I 
won't get so many complaints about the coupons.

Any way, to receive one, you have to be either a member of Share OR have an 
active ID on IBM-MAIN.  I am assuming that if you are reading this that you are 
one or the other.

The products that you can choose from are: (you can get detail descriptions 
and/or manuals on www.SyzygyInc.com)

SyzAUTO/z  -   z/OS Automatic (Time Of Day) Commands Scheduler and JOB 
Submittal System
SyzCMD/z  -  z/OS Command Scripting Facility - Fully interactive operator and 
System command scripting
SyzMPF/z  -  z/OS Message Processing Facility for console message traffic 
automation (+automatic email of MaxCC support)
SyzSPOOL/z  -  z/OS JES/2 and JES/3 Spool management (offload and display 
facility via TSO and the web)
SyzMAIL/z - Create and send Email from any Syzygy product 
SyzTEXT/z - Send Text via Email or SMS text message directly from z/OS
SyzMON/z - System Monitor for running Tasks Resources and Applications (still 
in beta, but will ship in March)

The offer is only for ONE product and is not valid for existing clients, (they 
get a different offer at Share in LA).  The offer expires when Share in LA is 
over, and this time there is no exceptions. :)  The license is by physical CPU, 
not LPAR, and the size of the CPU is not a factor for any of our software.  The 
only actual restriction is that we do not allow virtual servers (i.e 
HERCULES/390 under this offer), just real z/series boxes.

The normal cost for these products are between $1,500 and $5,000, depending on 
the product. (SyzMail/z is much cheaper, and is not meant to be a standalone 
product, it is an add-on for the other products, it's listed separately here 
only because Cut/paste was easier than typing:). 

Those interested should send an email to clientsupp...@syzygyinc.com and 
request the "SHARE/LA coupon offer" or offline to me directly and I will see to 
it that you get one. 

At Share in LA, you will either have to attend one of the presentations I am 
giving, or find me lurking around the place to get a coupon.  Just like last 
time, there are only going to be 200 of these coupons and double-dipping is not 
allowed.

Brian Westerman

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

Re: RACF USERMOD APPLY

[venkat kulkarni]

 I check this MOD (ICHRDSNT)  in target zone  and found that its available
in DISTLIB: AOSBN. But in JCL we pointed to something else as below. The
system currently
 I am working is z/OS 2.1

++SRC(ICHRDSNT) DISTLIB(AORASRC) DISTMOD(ALINKLIB) .



   CSI QUERY - MOD ENTRY   Row 1 to 1
of 1
===>  SCROLL ===>
PAGE

 To return to the previous panel, enter END .

 Primary Command: FIND

 Entry Type:  MOD Zone Name: MVST100
 Entry Name:  ICHRDSNTZone Type: TARGET

   FMID:HRF7790 LASTUPD: CPPDSNT  TYPE=ADD
   RMID:CPPDSNT DISTLIB: AOSBN

 Link-edit Parameters:
       
LMOD ICHRDSNT
*** Bottom of data
***



But when I check my older version of z/OS system like z/OS 1.13, I found
this MOD in DISTLIB: ALINKLIB  . So I think the JCL was setup for older
version.

CSI QUERY - MOD ENTRY   Row 1 to 1
of 1
 ===>  SCROLL ===>
PAGE

  To return to the previous panel, enter END .

  Primary Command: FIND

  Entry Type:  MOD Zone Name: MVST100
  Entry Name:  ICHRDSNTZone Type: TARGET

FMID:HRF7780 LASTUPD: SP1D001  TYPE=ADD
RMID:SP1D001 DISTLIB: ALINKLIB RMIDASM

  Link-edit Parameters:

        
 LMOD ICHRDSNT
 *** Bottom of data


After seeing this, I modified my JCL  from

++SRC(ICHRDSNT) DISTLIB(AORASRC) DISTMOD(ALINKLIB) .

to

++SRC(ICHRDSNT) DISTLIB(AORASRC) DISTMOD(AOSBN) .   and run apply check
Job. it run good.

Am I doing correct or anything more I am missing before actually apply of
this USERMOD

Regards


On Tue, Feb 4, 2014 at 11:25 AM, Lizette Koehler wrote:

> You need to list your SMP/E V2.1 CSI Global zone and see where the Module
> ICHRDSNT resides.
>
> There is a LISTMOD command you can use (or Option 3 in the SMP/E Panels)
> that will help you know what you need to code.
>
> The message says:  THE DISTLIB VALUE (AOSBN)  so your DISTLIB value of
> ALINKLIB is not correct.
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of venkat kulkarni
> > Sent: Monday, February 03, 2014 10:46 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: RACF USERMOD APPLY
> >
> > Answers are below.
> >
> > When was the last time you ran this Usermod successfully?
> >
> > I found this USERMOD in one of our old USERMOD library and I modified it
> to
> > make it work for z/OS 2.1 . Like FMID etc
> >
> > Why are did you code it with both DISTMOD and DISTLIB?
> >
> > I have not coded anything in this. It was already there.
> >
> >
> > Have you listed the module ICHRDSNT to see where it lives?
> >
> > It is under SYS1.LINKLIB(ICHRDSNT)
> >
> >
> > What version of z/OS is this for?
> >
> > z/OS 2.1
> >
> >
> > On Tue, Feb 4, 2014 at 11:10 AM, Lizette Koehler
> > wrote:
> >
> > > When was the last time you ran this Usermod successfully?
> > >
> > > Why are did you code it with both DISTMOD and DISTLIB?
> > >
> > > Have you listed the module ICHRDSNT to see where it lives?
> > >
> > > What version of z/OS is this for?
> > >
> > > The messages are very helpful in resolving your issue
> > > > GIM40501E ** THE DISTLIB VALUE (ALINKLIB) SPECIFIED FOR MOD
> > ICHRDSNT
> > > > IN SYSMOD
> > > >  SP21001 DOES NOT MATCH THE DISTLIB VALUE (AOSBN) IN
> > THE
> > > > MOD ENTRY
> > > >  FOR ICHRDSNT.
> > >
> > > If you have access to the SMP/E Panels in ISPF, use Option 3 QUERY.
> > >
> > >
> > > Thanks
> > >
> > > Lizette
> > >
> > > > -Original Message-
> > > > From: IBM Mainframe Discussion List
> > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of venkat kulkarni
> > > > Sent: Monday, February 03, 2014 7:43 PM
> > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > Subject: RACF USERMOD APPLY
> > > >
> > > > Hello,
> > > >  I am getting issue while applying RACF USERMOD for changing
> > > > RACF NAME TABLE.
> > > >
> > > > //USERMOD1 JOB   ((660)),
> > > > // 'VENKAT',
> > > > // CLASS=A,
> > > > // MSGCLASS=A,
> > > > // TIME=1440,NOTIFY=&SYSUID
> > > > //*
> > > > //STEP1EXEC PGM=GIMSMP,REGION=6M,
> > > > // TIME=120
> > > > //SMPCSI   DD  DSN=SMPE.GLOBAL.CSI,
> > > > // DISP=SHR
> > > > //SMPHOLD  DD  DUMMY
> > > > //SMPOUT   DD  SYSOUT=*
> > > > //SMPRPT   DD  SYSOUT=*
> > > > //SYSPRINT DD
> > SYSOUT=*,DCB=(LRECL=133,BLKSIZE=2660,RECFM=FB)
> > > > //SMPCNTL  DD  *
> > > >  SET BDY(GLOBAL) .
> > > >  RECEIVE S(UM21001) .
> > > >  

Re: CPU time

[Peter Relson]

Instructions counts are captured only on machines that have the 
appropriate support.
I view that data as, more or less, an experiment. 

If and when they are deemed worthy of being an analog of CPU time, 
additional support would be provided.

>Hopefully, they are not counting time spent resolving page faults and 
>such that _validly_ belong in "uncaptured" time today.

It appears that the "Hopefully" is not part of the current implementation. 
But it would be part of any complete implementation.

Peter Relson
z/OS Core Technology Design

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

Re: RACF USERMOD APPLY

[Tom Marchant]

On Tue, 4 Feb 2014 08:13:24 +0530, venkat kulkarni wrote:

> I am getting issue while applying RACF USERMOD for changing RACF
>NAME TABLE.
>

>//SMPPTFIN DD  DATA,DLM='%%'
>++USERMOD(UM21001)  REWORK(2014034)   .
>++VER(Z038) FMID(HRF7790) PRE(CPPDSNT) .

The following JCLIN doesn't make any sense.  JCLIN should describe how to 
create the target element from the distribution zone.  SMP/E uses this 
information along with other information that you provide to create the element 
at APPLY time.  In this case, you are telling SMP/E to get module ICHRDSNT from 
LINKLIB and store it in LINKLIB.

>++JCLIN .
>//UM21001 JOB MVSSP121
>//ICHRDSNT EXEC PGM=IEWL,
>// PARM='LIST,LET,XREF,NCAL'
>//SYSPRINT DD SYSOUT=*
>//SYSUT1 DD UNIT=3390,SPACE=(CYL,(1,1))
>//SYSLMOD DD DSN=Z.LINKLIB,DISP=SHR
>//SYSLIN DD *
> INCLUDE SYSLMOD(ICHRDSNT)
> ENTRY ICHRDSNT
> NAME ICHRDSNT(R)
>/*
>++SRC(ICHRDSNT) DISTLIB(AORASRC) DISTMOD(ALINKLIB) .

The above MCS specifies that the distribution library for the ICHRDSNT module 
is ALINKLIB.

> ICHRDSNT CSECT
>  DCAL1(1)   # PRIMARY RACF DATASETS
>  DCCL44'SYS1.RACFP'  NAME OF PRIMARY
>  DCCL44'SYS1.RACFB'   NAME OF BACKUP
>  DCAL1(255) # RESIDENT BLOCKS (ONE TRACK)
>  DCX'80'UPDATES DUPLICATED ON BACKUP D
>  END
> %%
> //
>
> APPLY CHECK S(UM21001) REDO .
>
>GIM40501E ** THE DISTLIB VALUE (ALINKLIB) SPECIFIED FOR MOD ICHRDSNT IN
>SYSMOD
> SP21001 DOES NOT MATCH THE DISTLIB VALUE (AOSBN) IN THE MOD
>ENTRY
> FOR ICHRDSNT.

You have specified that the DISTLIB for ICHRDSNT is ALINKLIB.  The MOD entry in 
the DLIB zone says that it is AOSBN.

>GIM22601IAPPLY PROCESSING FAILED FOR SYSMOD UM21001.
>GIM20501IAPPLY PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 08.
>
>I am not able to find hint to solve this issue. Can anybody help me on this.

Did you look up message GIM40501E?

-- 
Tom Marchant

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

Re: RACF USERMOD APPLY

[Tom Marchant]

On Mon, 3 Feb 2014 22:40:36 -0700, Lizette Koehler wrote:

>Why are did you code it with both DISTMOD and DISTLIB?

Lizette,
On a ++SRC MCS, DISTLIB tells where the source is stored and DISTMOD tells 
where the module is stored in the DLIB zone.

-- 
Tom Marchant

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

Re: Dummy dataset

[Paul Gilmartin]

On Thu, 30 Jan 2014 20:18:05 +, Jousma, David wrote:

>We have an exit for DFSORT that scans TIOT to see if someone concatenated a 
>DUMMY dataset as input.  Here is what I believe to be the relevant snippet of 
>code:
>...
>* CHECK FOR DUMMY DD STATEMENT
>* NOTE: COULD ALSO BE DD *
>DDCHKCLC   TIOEFSRT,=AL3(0)   Q. REAL UCB ADDRESS ?   
> BEDDBAD  A. NO, BAD DD   
>...   
> 
How does this behave for DD PATH=...?  Is the UCB address nonzero
for zFS files?  Are you unwittingly prohibiting use of zFS in the
SORTIN concatenation?  That would be imprisoning your users in
the twentieth century.

Prohibiting "DD *" is also unduly harsh.

A similar question applies to Shmuel's suggestion of DEVTYPE.

The definitive test should be for DSNAME='NULLFILE'.

-- gil

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

Re: Dummy dataset

[Jousma, David]

No, we have users sorting data with path names as input.  Just ran a test.  
Single path input, concatenated, all work fine, unless they add a DD DUMMY 
between them.  As a side note, DFSORT doesn’t do a good job with dynamic sortwk 
allocations with PATH input because it cannot accurately determine the input 
filesize.   I had opened a ticket with IBM on this, and all I got was "this is 
the way it is".   My only option was to tell my developers to hardcode sorkwk 
datasets in their job.

//DFSORT   EXEC PGM=SORT   
//SORTINDD PATHDISP=KEEP,  
// PATHOPTS=ORDONLY,   
// FILEDATA=TEXT,  
// RECFM=VB,LRECL=255,BLKSIZE=25496,   
// PATH='/etc/httpd1443.conf'  
//  DD DUMMY   
//  DD PATHDISP=KEEP,  
// PATHOPTS=ORDONLY,   
// FILEDATA=TEXT,  
// RECFM=VB,LRECL=255,BLKSIZE=25496,   
// PATH='/etc/httpd1443.conf'  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, February 04, 2014 8:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dummy dataset

On Thu, 30 Jan 2014 20:18:05 +, Jousma, David wrote:

>We have an exit for DFSORT that scans TIOT to see if someone concatenated a 
>DUMMY dataset as input.  Here is what I believe to be the relevant snippet of 
>code:
>...
>* CHECK FOR DUMMY DD STATEMENT
>* NOTE: COULD ALSO BE DD *
>DDCHKCLC   TIOEFSRT,=AL3(0)   Q. REAL UCB ADDRESS ?   
> BEDDBAD  A. NO, BAD DD   
>...   
> 
How does this behave for DD PATH=...?  Is the UCB address nonzero for zFS 
files?  Are you unwittingly prohibiting use of zFS in the SORTIN concatenation? 
 That would be imprisoning your users in the twentieth century.

Prohibiting "DD *" is also unduly harsh.

A similar question applies to Shmuel's suggestion of DEVTYPE.

The definitive test should be for DSNAME='NULLFILE'.

-- 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: Dummy dataset

[John McKown]

On Tue, Feb 4, 2014 at 7:44 AM, Jousma, David  wrote:

> No, we have users sorting data with path names as input.  Just ran a test.
>  Single path input, concatenated, all work fine, unless they add a DD DUMMY
> between them.  As a side note, DFSORT doesn’t do a good job with dynamic
> sortwk allocations with PATH input because it cannot accurately determine
> the input filesize.   I had opened a ticket with IBM on this, and all I got
> was "this is the way it is".   My only option was to tell my developers to
> hardcode sorkwk datasets in their job.
>

Normally, I praise the DFSORT people. But "it cannot accurately determine
the input filesize" is _ignorant_. stat() on the file returns the size of
the file in bytes.  Of course, this doesn't for UNIX "files" which are not
really files. Such as named pipes, or "/dev/fd/?" type "files" for open
file descriptors. Which are not useful in batch anyway, so forget I
mentioned them.


>
> //DFSORT   EXEC PGM=SORT
> //SORTINDD PATHDISP=KEEP,
> // PATHOPTS=ORDONLY,
> // FILEDATA=TEXT,
> // RECFM=VB,LRECL=255,BLKSIZE=25496,
> // PATH='/etc/httpd1443.conf'
> //  DD DUMMY
> //  DD PATHDISP=KEEP,
> // PATHOPTS=ORDONLY,
> // FILEDATA=TEXT,
> // RECFM=VB,LRECL=255,BLKSIZE=25496,
> // PATH='/etc/httpd1443.conf'
>
>


-- 
Wasn't there something about a PASCAL programmer knowing the value of
everything and the Wirth of nothing?

Maranatha! <><
John McKown

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

Assembler code

[Ron Thomas]

Hello.

I am new to assembler, so not sure i am pharsing the query correctly.

In the attached code whether if the ITMAP bit is on for a memory location, then 
after executing the below code is it going to be turned off.? 

So basically need to know what all condtions the BIT gets turned on and off in 
ITMAP layout ?

XI@TMXI0(R6),0


Thanks
Ron T

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

8421

0110

0001,0110,1101


FORCEONE DS0H * 0898
 PACK  T@SAVE,CDSTOR   FIND BIT DISPLACEMENT  * 0899
 DPT@SAVE,=P'8' FOR STORE NUMBER. * 0900
 ZAP   BYTE,T@SAVE(7)  QUOTIENT IS BYTE DISPLACEMENT. * 0910
 ZAP   BIT,T@SAVE+7(1) REMAINDER IS BIT DISPLACEMENT. * 0920
 ZAP   T@SAVE,BYTE CONVERT BYTE DISPLACEMENT  * 0930
 CVB   R1,T@SAVETO BINARY * 0940
 STR1,BYTE   AND SAVE.* 0950
 ZAP   T@SAVE,BIT  CONVERT BIT DISPLACEMENT   * 0960
 CVB   R1,T@SAVETO BINARY * 0970
 STC   R1,BITAND SAVE.* 0980
 TRBIT,TR@TAB  TRANSLATE BIT DISPLACEMENT * 0990
*   TO 'TM' BIT.  * 0991
 L R4,BYTE BIT MAP DISPLACEMENT.  * 0992
 LAR6,ITMAP(R4)BYTE COMPARE ADDRESS.  * 0993
 SRR5,R5   CLEAR WORK REGISTER.   * 0994
 ICR5,BIT  TEST BIT.  * 0995
 EXR5,XI@TMTEST THE BIT.  * 0996
 BRR2  RETURN * 0997
* * 0998
XI@TMXI0(R6),0 TURN OFF STORE BIT * 0999
*** 1000


M@WORK   DC10D'0'  MACRO WORK AREA.   * 1796
M@SAVE   DC9D'0'   MACRO SAVE AREA.   * 1797
P@SAVE   DC9D'0'   PROGRAM SAVE AREA. * 1798
FEEDBACK DCF'0'   * 1799
DUMPCODE DCH'0'   * 1800
IM2KEY   DCXL20'00'IMS11  FILE KEY (READ).* 1810
SAVEKEY  DCXL20'00'IMS12  FILE KEY (REPL).*
ED@CNT   DCXL8'4020202020202120'  * 1820
UPD@CNT  DCPL4'0' * 1830
GCY@CNT  DCPL4'0' * 1840
VND@CNT  DCPL4'0' * 1850
DLT@CNT  DCPL4'0' * 1860
ZER@CNT  DCPL4'0' * 1870
* * 1880
RRNUMDCF'0'TEMPORARY SAVE AREA.   * 1890
T@SAVE   DCD'0'TEMPORARY SAVE AREA.   * 1891
UPDCNT   DCPL8'0'   * * *  MUST BE ON DOUBLEWORD BOUNDARY * * * * * 1892
REGSAVE  DC16F'0'  REG SAVE AREA. * 1893
PACKWK6  DCPL6'0'  PACK WORK AREA.* 1894
 DC30X'FF'* 1895
EOFVALUE DCC'0'END-OF-FILE INDICATOR. * 1896
* * 1897
BYTE DCF'0'   * 1898
BIT  DCXL1'00'* 1899
TR@TAB   DCXL8'8040201008040201'  * 1900
LOWVAL   DC750X'00'   * 1910
WRITIM2  DCC'N'   * 1920
* * 1930


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

Re: CPU time

[John Gilmore]

The issue here is not whether "time spent resolving page faults and
such" is counted.  It should be counted; but it should also be broken
out, reported separately.

The chief problem with "uncaptured" time is its
miscellaneous/heterogeneous character, which makes any scheme, however
clever, for partialling it out indefensible because "unfair" to some
users.

Any "complete implementation" that assigns more of it to functionally
meaningful categories is to be strongly encouraged.  Misattribution,
inclusion in the wrong category, would, on the other hand,  be a step
backward.  I strongly suspect that this is really EJ's concern, but he
can of course speak for himself.

John Gilmore, Ashland, MA 01721 - USA

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

Re: SMF (was REXX Tutorial)

[Mark Zelden]

I have an SMF 30 REXX example code (JOB accounting report) that I can 
contribute, 
but I don't have time do all the other informational doc I see with the other
samples.  Since virtually all my clients have had SAS, this is the only one I've
ever written in REXX (and it was a good exercise back in 1995). 
Otherwise I've only needed to process 70s with RMF/CMF.   

I've never added it to my CBT / web site, but I did just put it out the code to 
my
web site's "files" directory without any link from my pages.  Maybe I'll add it 
now.
Also, z/OS 2.1 REXX can process  variable block spanned records (finally!) so
the repro / reblock step wont be required. 

http://www.mzelden.com/mvsfiles/rxsmf30.txt

Cheers,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS  
ITIL v3 Foundation Certified   
mailto:m...@mzelden.com   
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://search390.techtarget.com/ateExperts/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Assembler code

[Ed Jaffe]

On 2/4/2014 6:18 AM, Ron Thomas wrote:

Hello.

I am new to assembler, so not sure i am pharsing the query correctly.


FYI. The best (and most appropriate) place for assembler-related 
questions is assembler-l...@listserv.uga.edu.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: SMF (was REXX Tutorial)

[Wolfgang Schüch]

Thank you very much Mark. I will see how I can integrate it, at least
partly, into the book :-)


2014-02-04 Mark Zelden :

> I have an SMF 30 REXX example code (JOB accounting report) that I can
> contribute,
> but I don't have time do all the other informational doc I see with the
> other
> samples.  Since virtually all my clients have had SAS, this is the only
> one I've
> ever written in REXX (and it was a good exercise back in 1995).
> Otherwise I've only needed to process 70s with RMF/CMF.
>
> I've never added it to my CBT / web site, but I did just put it out the
> code to my
> web site's "files" directory without any link from my pages.  Maybe I'll
> add it now.
> Also, z/OS 2.1 REXX can process  variable block spanned records (finally!)
> so
> the repro / reblock step wont be required.
>
> http://www.mzelden.com/mvsfiles/rxsmf30.txt
>
> Cheers,
>
> Mark
> --
> Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
> ITIL v3 Foundation Certified
> mailto:m...@mzelden.com
> Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
> Systems Programming expert at http://search390.techtarget.com/ateExperts/
> --
> 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: Assembler code

[Charles Mills]

There's an Assembler listserve as I am sure others will point out.

The XI instruction you quote is only half of the picture. It is "executed" in 
your code by the instruction with the opcode EX farther up in the listing. 
Think of EX as a subroutine call to a one-machine-instruction subroutine. The 
contents of register 5 are implicitly "ORed into" the 0 in the XI instruction.

Now you are down to a basic Boolean logic problem. The code will turn on or 
turn off (invert) whatever bits are set in the low order byte of R5.

Hope this helps.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ron Thomas
Sent: Tuesday, February 04, 2014 9:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Assembler code

Hello.

I am new to assembler, so not sure i am pharsing the query correctly.

In the attached code whether if the ITMAP bit is on for a memory location, then 
after executing the below code is it going to be turned off.? 

So basically need to know what all condtions the BIT gets turned on and off in 
ITMAP layout ?

XI@TMXI0(R6),0

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

Re: Dummy dataset

[Blaicher, Christopher Y.]

David,

The use of DD DUMMY in a concatenation ends the processing of input data.  The 
following is from the JCL Reference Manual:

Data sets concatenated to dummy data sets: The system treats data sets
concatenated to a DUMMY data set as dummy data sets in that I/O operations are
bypassed. However, the system performs disposition processing and allocates
devices and storage for any concatenated data sets.

So, in your example you only read the file once.  Without the DD DUMMY it would 
read the file twice.

Chris Blaicher
Principal Software Engineer, Software Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8260  |  M: 512-627-3803
E: cblaic...@syncsort.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Tuesday, February 04, 2014 8:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dummy dataset

No, we have users sorting data with path names as input.  Just ran a test.  
Single path input, concatenated, all work fine, unless they add a DD DUMMY 
between them.  As a side note, DFSORT doesn’t do a good job with dynamic sortwk 
allocations with PATH input because it cannot accurately determine the input 
filesize.   I had opened a ticket with IBM on this, and all I got was "this is 
the way it is".   My only option was to tell my developers to hardcode sorkwk 
datasets in their job.

//DFSORT   EXEC PGM=SORT
//SORTINDD PATHDISP=KEEP,
// PATHOPTS=ORDONLY,
// FILEDATA=TEXT,
// RECFM=VB,LRECL=255,BLKSIZE=25496,
// PATH='/etc/httpd1443.conf'
//  DD DUMMY
//  DD PATHDISP=KEEP,
// PATHOPTS=ORDONLY,
// FILEDATA=TEXT,
// RECFM=VB,LRECL=255,BLKSIZE=25496,
// PATH='/etc/httpd1443.conf'

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, February 04, 2014 8:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dummy dataset

On Thu, 30 Jan 2014 20:18:05 +, Jousma, David wrote:

>We have an exit for DFSORT that scans TIOT to see if someone concatenated a 
>DUMMY dataset as input.  Here is what I believe to be the relevant snippet of 
>code:
>...
>* CHECK FOR DUMMY DD STATEMENT
>* NOTE: COULD ALSO BE DD *
>DDCHKCLC   TIOEFSRT,=AL3(0)   Q. REAL UCB ADDRESS ?
> BEDDBAD  A. NO, BAD DD
>...
>
How does this behave for DD PATH=...?  Is the UCB address nonzero for zFS 
files?  Are you unwittingly prohibiting use of zFS in the SORTIN concatenation? 
 That would be imprisoning your users in the twentieth century.

Prohibiting "DD *" is also unduly harsh.

A similar question applies to Shmuel's suggestion of DEVTYPE.

The definitive test should be for DSNAME='NULLFILE'.

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





ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any use, disclosure, copying or distribution of this message, in any form, is 
strictly prohibited. If you have received this message in error, please 
immediately notify the sender and/or Syncsort and destroy all copies of this 
message in your possession, custody or control.

--
For IBM-MAIN subscribe / signoff / archive 

Re: RACF USERMOD APPLY

[Lizette Koehler]

Venkat,

When a usermod is created, it is best to allow SMP/E to keep the Dlib datasets 
where IBM places them.  For some reason your USERMOD is trying to move the 
module from AOSBN to ALINKLIB.  This is what the message GIM40501E is telling 
you.   If you want to do that, then you have to change your JCLIN, and do a 
UCLIN update to the module so SMP/E places it differently.

Since this is an IBM Shipped module, you will probably want to leave the DLIB 
information as IBM has it coded.  That is why I suggested you look at the 
listing of the module in SMPE Opt 3.  It will tell you where IBM currently has 
the module located for TLIB and DLIB functions.

You may wish to review the SMP/E manual on creating a usermod.

Or if you are not very familiar with building an SMP/E Usermod, you might ask 
if someone has a sample for ICHRDSNT that you can use as a model.  There are 
times when IBM will move a module in their base system to different libraries.  
That is why I always review what I have coded for a USERMOD against a listing 
of the module in the SMP/E environment.  If something changes, like a DISTLIB, 
then I recode according to what IBM has shipped.

If you go to the manual RACF Installation and Implementation for z/OS V2.1 and 
select Appendix D it will provide you with the sample of the usermod you are 
trying to do.

Or I have pasted the appendix here:

Appendix D. Database Name Table - Sample JCL
This appendix provides a sample SMP/E job to implement the RACF database name 
table.

//ASM1 EXEC PGM=IEV90,PARM=′ DECK,NOOBJECT′
//SYSLIB DD DISP=SHR,DSN=SYS1.AGENLIB
// DD DISP=SHR,DSN=SYS1.AMODGEN
//SYSUT1 DD UNIT=VIO,SPACE=(CYL,(20,5))
//SYSUT2 DD UNIT=VIO,SPACE=(CYL,(10,1))
//SYSUT3 DD UNIT=VIO,SPACE=(CYL,(2,1))
//SYSPRINT DD SYSOUT=*
//SYSPUNCH DD DSN=&&TEMP,DISP=(,PASS),
// SPACE=(TRK,(1,1)),UNIT=VIO
//SYSIN DD *
PUNCH ′++ USERMOD (RA2) REWORK(1994200) .′
PUNCH ′++ VER (Z038) FMID(HRF2210).′
PUNCH ′++ MOD (ICHRDSNT) DISTLIB(AOSBN) LMOD(ICHRDSNT).′
ICHRDSNT TITLE ′ RACF DATA SET NAME TABLE′
ICHRDSNT CSECT ,
ICHRDSNT AMODE 31
ICHRDSNT RMODE 24
*
DC AL1(1) ONE PRIMARY/BACKUP PAIR
DC CL44′ SYS1.RACFESA′ DSN PRIMARY
DC CL44′ SYS1.RACF.BKUP1′ DSN BACKUP
DC AL1(255) RESIDENT DATA BLOCKS
DC B′10001000′ FLAG BYTE
END
/*
//*
//SMP2 EXEC PGM=GIMSMP,COND=(0,NE)
//SMPCSI DD DISP=SHR,DSN=TOT.SMP.GLOBAL.CSI
//SMPHOLD DD DUMMY
//SMPPTFIN DD DSN=&&TEMP,DISP=(OLD,DELETE)
//LINKLIB DD DISP=SHR,DSN=SYS1.LINKLIB,
// UNIT=SYSALLDA,VOL=SER=RES02A
//SMPCNTL DD *
SET BDY(TGTM02A) .
UCLIN .
REP LMOD(ICHRDSNT) SYSLIB(LINKLIB) .
ENDUCL .
SET BDY(GLOBAL) .
RECEIVE S(RA2) SYSMODS .
SET BDY(TGTM02A) .
APPLY REDO S(RA2) .


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Tom Marchant
> Sent: Tuesday, February 04, 2014 6:33 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RACF USERMOD APPLY
> 
> On Tue, 4 Feb 2014 08:13:24 +0530, venkat kulkarni wrote:
> 
> > I am getting issue while applying RACF USERMOD for changing
> >RACF NAME TABLE.
> >
> 
> >//SMPPTFIN DD  DATA,DLM='%%'
> >++USERMOD(UM21001)  REWORK(2014034)   .
> >++VER(Z038) FMID(HRF7790) PRE(CPPDSNT) .
> 
> The following JCLIN doesn't make any sense.  JCLIN should describe how to
> create the target element from the distribution zone.  SMP/E uses this 
> information
> along with other information that you provide to create the element at APPLY 
> time.
> In this case, you are telling SMP/E to get module ICHRDSNT from LINKLIB and
> store it in LINKLIB.
> 
> >++JCLIN .
> >//UM21001 JOB MVSSP121
> >//ICHRDSNT EXEC PGM=IEWL,
> >// PARM='LIST,LET,XREF,NCAL'
> >//SYSPRINT DD SYSOUT=*
> >//SYSUT1 DD UNIT=3390,SPACE=(CYL,(1,1)) //SYSLMOD DD
> >DSN=Z.LINKLIB,DISP=SHR //SYSLIN DD *  INCLUDE SYSLMOD(ICHRDSNT)
> ENTRY
> >ICHRDSNT  NAME ICHRDSNT(R)
> >/*
> >++SRC(ICHRDSNT) DISTLIB(AORASRC) DISTMOD(ALINKLIB) .
> 
> The above MCS specifies that the distribution library for the ICHRDSNT module 
> is
> ALINKLIB.
> 
> > ICHRDSNT CSECT
> >  DCAL1(1)   # PRIMARY RACF DATASETS
> >  DCCL44'SYS1.RACFP'  NAME OF PRIMARY
> >  DCCL44'SYS1.RACFB'   NAME OF BACKUP
> >  DCAL1(255) # RESIDENT BLOCKS (ONE TRACK)
> >  DCX'80'UPDATES DUPLICATED ON BACKUP D
> >  END
> > %%
> > //
> >
> > APPLY CHECK S(UM21001) REDO .
> >
> >GIM40501E ** THE DISTLIB VALUE (ALINKLIB) SPECIFIED FOR MOD
> ICHRDSNT IN
> >SYSMOD
> > SP21001 DOES NOT MATCH THE DISTLIB VALUE (AOSBN) IN THE
> MOD
> >ENTRY
> > FOR ICHRDSNT.
> 
> You have specified that the DISTLIB for ICHRDSNT is ALINKLIB.  The MOD entry
> in the DLIB zone says that it is AOSBN.
> 
> >GIM22601IAPPLY PROCESSING FAILED FOR SYSMOD UM21001.
> >GIM20501IAPPLY PROCESSING IS COMPLETE. THE HIGHEST RETURN
> CODE WAS 08.
> >
> >I am not able to find hint to solve this issue. Can anybody help me on this.
> 
> Did you look up

Re: CPU time

[Ed Jaffe]

On 2/4/2014 6:22 AM, John Gilmore wrote:

Any "complete implementation" that assigns more of it to functionally
meaningful categories is to be strongly encouraged.  Misattribution,
inclusion in the wrong category, would, on the other hand,  be a step
backward.  I strongly suspect that this is really EJ's concern, but he
can of course speak for himself.


My concern was a simplistic one. I hoped that the (still experimental) 
instruction counts were handled in a way that was analogous to what's 
done today for CPU time, where smart choices were made to ensure things 
rightly classified as "system overhead" are not attributed to a running 
job. Obviously, there is still much work to do to make them work as a 
viable alternative to CPU time.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: RACF USERMOD APPLY

[Joel C. Ewing]

And if you follow what ought to be standard practice of applying but
NEVER accepting a USERMOD (so it can always be RESTOREd if necessary),
then the DLIB specified will never be used for storing the modified
ICHRDSNT MOD anyhow, since a store into a DLIB only occurs on ACCEPT.
   Joel C Ewing

On 02/04/2014 09:01 AM, Lizette Koehler wrote:
> Venkat,
> 
> When a usermod is created, it is best to allow SMP/E to keep the Dlib 
> datasets where IBM places them.  For some reason your USERMOD is trying to 
> move the module from AOSBN to ALINKLIB.  This is what the message GIM40501E 
> is telling you.   If you want to do that, then you have to change your JCLIN, 
> and do a UCLIN update to the module so SMP/E places it differently.
> 
> Since this is an IBM Shipped module, you will probably want to leave the DLIB 
> information as IBM has it coded.  That is why I suggested you look at the 
> listing of the module in SMPE Opt 3.  It will tell you where IBM currently 
> has the module located for TLIB and DLIB functions.
> 
> You may wish to review the SMP/E manual on creating a usermod.
> 
> Or if you are not very familiar with building an SMP/E Usermod, you might ask 
> if someone has a sample for ICHRDSNT that you can use as a model.  There are 
> times when IBM will move a module in their base system to different 
> libraries.  That is why I always review what I have coded for a USERMOD 
> against a listing of the module in the SMP/E environment.  If something 
> changes, like a DISTLIB, then I recode according to what IBM has shipped.
> 
> If you go to the manual RACF Installation and Implementation for z/OS V2.1 
> and select Appendix D it will provide you with the sample of the usermod you 
> are trying to do.
> 
> Or I have pasted the appendix here:
> 
> Appendix D. Database Name Table - Sample JCL
> This appendix provides a sample SMP/E job to implement the RACF database name 
> table.
> 
> //ASM1 EXEC PGM=IEV90,PARM=′ DECK,NOOBJECT′
> //SYSLIB DD DISP=SHR,DSN=SYS1.AGENLIB
> // DD DISP=SHR,DSN=SYS1.AMODGEN
> //SYSUT1 DD UNIT=VIO,SPACE=(CYL,(20,5))
> //SYSUT2 DD UNIT=VIO,SPACE=(CYL,(10,1))
> //SYSUT3 DD UNIT=VIO,SPACE=(CYL,(2,1))
> //SYSPRINT DD SYSOUT=*
> //SYSPUNCH DD DSN=&&TEMP,DISP=(,PASS),
> // SPACE=(TRK,(1,1)),UNIT=VIO
> //SYSIN DD *
> PUNCH ′++ USERMOD (RA2) REWORK(1994200) .′
> PUNCH ′++ VER (Z038) FMID(HRF2210).′
> PUNCH ′++ MOD (ICHRDSNT) DISTLIB(AOSBN) LMOD(ICHRDSNT).′
> ICHRDSNT TITLE ′ RACF DATA SET NAME TABLE′
> ICHRDSNT CSECT ,
> ICHRDSNT AMODE 31
> ICHRDSNT RMODE 24
> *
> DC AL1(1) ONE PRIMARY/BACKUP PAIR
> DC CL44′ SYS1.RACFESA′ DSN PRIMARY
> DC CL44′ SYS1.RACF.BKUP1′ DSN BACKUP
> DC AL1(255) RESIDENT DATA BLOCKS
> DC B′10001000′ FLAG BYTE
> END
> /*
> //*
> //SMP2 EXEC PGM=GIMSMP,COND=(0,NE)
> //SMPCSI DD DISP=SHR,DSN=TOT.SMP.GLOBAL.CSI
> //SMPHOLD DD DUMMY
> //SMPPTFIN DD DSN=&&TEMP,DISP=(OLD,DELETE)
> //LINKLIB DD DISP=SHR,DSN=SYS1.LINKLIB,
> // UNIT=SYSALLDA,VOL=SER=RES02A
> //SMPCNTL DD *
> SET BDY(TGTM02A) .
> UCLIN .
> REP LMOD(ICHRDSNT) SYSLIB(LINKLIB) .
> ENDUCL .
> SET BDY(GLOBAL) .
> RECEIVE S(RA2) SYSMODS .
> SET BDY(TGTM02A) .
> APPLY REDO S(RA2) .
> 
> 
> Lizette
> 
> 
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of Tom Marchant
>> Sent: Tuesday, February 04, 2014 6:33 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: RACF USERMOD APPLY
>>
>> On Tue, 4 Feb 2014 08:13:24 +0530, venkat kulkarni wrote:
>>
>>> I am getting issue while applying RACF USERMOD for changing
>>> RACF NAME TABLE.
>>>
>>
>>> //SMPPTFIN DD  DATA,DLM='%%'
>>> ++USERMOD(UM21001)  REWORK(2014034)   .
>>> ++VER(Z038) FMID(HRF7790) PRE(CPPDSNT) .
>>
>> The following JCLIN doesn't make any sense.  JCLIN should describe how to
>> create the target element from the distribution zone.  SMP/E uses this 
>> information
>> along with other information that you provide to create the element at APPLY 
>> time.
>> In this case, you are telling SMP/E to get module ICHRDSNT from LINKLIB and
>> store it in LINKLIB.
>>
>>> ++JCLIN .
>>> //UM21001 JOB MVSSP121
>>> //ICHRDSNT EXEC PGM=IEWL,
>>> // PARM='LIST,LET,XREF,NCAL'
>>> //SYSPRINT DD SYSOUT=*
>>> //SYSUT1 DD UNIT=3390,SPACE=(CYL,(1,1)) //SYSLMOD DD
>>> DSN=Z.LINKLIB,DISP=SHR //SYSLIN DD *  INCLUDE SYSLMOD(ICHRDSNT)
>> ENTRY
>>> ICHRDSNT  NAME ICHRDSNT(R)
>>> /*
>>> ++SRC(ICHRDSNT) DISTLIB(AORASRC) DISTMOD(ALINKLIB) .
>>
>> The above MCS specifies that the distribution library for the ICHRDSNT 
>> module is
>> ALINKLIB.
>>
>>> ICHRDSNT CSECT
>>>  DCAL1(1)   # PRIMARY RACF DATASETS
>>>  DCCL44'SYS1.RACFP'  NAME OF PRIMARY
>>>  DCCL44'SYS1.RACFB'   NAME OF BACKUP
>>>  DCAL1(255) # RESIDENT BLOCKS (ONE TRACK)
>>>  DCX'80'UPDATES DUPLICATED ON BACKUP D
>>>  END
>>> %%
>>> //
>>>
>>> APPLY CHECK S(UM21001) REDO .
>>>
>>> GIM40501E ** THE DISTLIB VALUE (ALINKLIB)

Re: Dummy dataset

[Jousma, David]

Chris, Yes, I am aware of that.   This thread started from an exit we run that 
detects this type of concatenation in a DFSORT SORTIN due to fallout 
encountered years ago involving the use of symbolics to override dataset names 
in the concatenation at runtime.   The fallout that occurred was because it 
took days for the affected app groups to determine that the concatenated 
datasets after the DUMMY dataset were never included in the SORTOUT.  I was not 
at this job when it occurred, but we are a bank, some maybe the affect was that 
someone's bank accounts were not accurate(I don’t know).  Some here call it a 
feature, some call it a shortcoming, regardless, it is the way the system 
operates.   The problem for us then was that the job ended RC(0), and it took a 
long time to figure out that the input data was ignored.   That’s why the exit 
came to life.   

I know that the same behavior exits using IEBGENER, and IDCAMS REPRO copying 
and we don’t have exits for those, and no one has complained.

Why do we have the ICE EXIT?  Politics.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Blaicher, Christopher Y.
Sent: Tuesday, February 04, 2014 10:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dummy dataset

David,

The use of DD DUMMY in a concatenation ends the processing of input data.  The 
following is from the JCL Reference Manual:

Data sets concatenated to dummy data sets: The system treats data sets 
concatenated to a DUMMY data set as dummy data sets in that I/O operations are 
bypassed. However, the system performs disposition processing and allocates 
devices and storage for any concatenated data sets.

So, in your example you only read the file once.  Without the DD DUMMY it would 
read the file twice.

Chris Blaicher
Principal Software Engineer, Software Development Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8260  |  M: 512-627-3803
E: cblaic...@syncsort.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Tuesday, February 04, 2014 8:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dummy dataset

No, we have users sorting data with path names as input.  Just ran a test.  
Single path input, concatenated, all work fine, unless they add a DD DUMMY 
between them.  As a side note, DFSORT doesn’t do a good job with dynamic sortwk 
allocations with PATH input because it cannot accurately determine the input 
filesize.   I had opened a ticket with IBM on this, and all I got was "this is 
the way it is".   My only option was to tell my developers to hardcode sorkwk 
datasets in their job.

//DFSORT   EXEC PGM=SORT
//SORTINDD PATHDISP=KEEP,
// PATHOPTS=ORDONLY,
// FILEDATA=TEXT,
// RECFM=VB,LRECL=255,BLKSIZE=25496,
// PATH='/etc/httpd1443.conf'
//  DD DUMMY
//  DD PATHDISP=KEEP,
// PATHOPTS=ORDONLY,
// FILEDATA=TEXT,
// RECFM=VB,LRECL=255,BLKSIZE=25496,
// PATH='/etc/httpd1443.conf'

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, February 04, 2014 8:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dummy dataset

On Thu, 30 Jan 2014 20:18:05 +, Jousma, David wrote:

>We have an exit for DFSORT that scans TIOT to see if someone concatenated a 
>DUMMY dataset as input.  Here is what I believe to be the relevant snippet of 
>code:
>...
>* CHECK FOR DUMMY DD STATEMENT
>* NOTE: COULD ALSO BE DD *
>DDCHKCLC   TIOEFSRT,=AL3(0)   Q. REAL UCB ADDRESS ?
> BEDDBAD  A. NO, BAD DD
>...
>
How does this behave for DD PATH=...?  Is the UCB address nonzero for zFS 
files?  Are you unwittingly prohibiting use of zFS in the SORTIN concatenation? 
 That would be imprisoning your users in the twentieth century.

Prohibiting "DD *" is also unduly harsh.

A similar question applies to Shmuel's suggestion of DEVTYPE.

The definitive test should be for DSNAME='NULLFILE'.

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

Re: RACF USERMOD APPLY

[Lizette Koehler]

I need to correct the manual I cited.  It was for OS/390 V2.1 not z/OS V2.1.  I 
have been searching the IBM website for a z/OS V2.1 RACF (Security Server) 
Installation guide and I have not found one yet.

However, the OS/390 Usermod does have what I think are the correct elements so 
long as z/OS V2.1 has not moved the module.  You will need to adjust some items 
like FMID, but I do not see a reason it could not work in z/OS V2.1


You can use this URL to see this manual I found the usermod in


TinyURL
http://tinyurl.com/2346d62

http://www-03.ibm.com/systems/resources/servers_eserver_zseries_zos_racf_pdf_racf_v2r1_installation_implementation_gg244405.pdf



Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Tuesday, February 04, 2014 8:02 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RACF USERMOD APPLY
> 
> Venkat,
> 
> When a usermod is created, it is best to allow SMP/E to keep the Dlib datasets
> where IBM places them.  For some reason your USERMOD is trying to move the
> module from AOSBN to ALINKLIB.  This is what the message GIM40501E is telling
> you.   If you want to do that, then you have to change your JCLIN, and do a 
> UCLIN
> update to the module so SMP/E places it differently.
> 
> Since this is an IBM Shipped module, you will probably want to leave the DLIB
> information as IBM has it coded.  That is why I suggested you look at the 
> listing of
> the module in SMPE Opt 3.  It will tell you where IBM currently has the module
> located for TLIB and DLIB functions.
> 
> You may wish to review the SMP/E manual on creating a usermod.
> 
> Or if you are not very familiar with building an SMP/E Usermod, you might ask 
> if
> someone has a sample for ICHRDSNT that you can use as a model.  There are
> times when IBM will move a module in their base system to different 
> libraries.  That
> is why I always review what I have coded for a USERMOD against a listing of 
> the
> module in the SMP/E environment.  If something changes, like a DISTLIB, then I
> recode according to what IBM has shipped.
> 
> If you go to the manual RACF Installation and Implementation for z/OS V2.1 and
> select Appendix D it will provide you with the sample of the usermod you are 
> trying
> to do.
> 
> Or I have pasted the appendix here:
> 
> Appendix D. Database Name Table - Sample JCL This appendix provides a sample
> SMP/E job to implement the RACF database name table.
> 
> //ASM1 EXEC PGM=IEV90,PARM=′ DECK,NOOBJECT′ //SYSLIB DD
> DISP=SHR,DSN=SYS1.AGENLIB // DD DISP=SHR,DSN=SYS1.AMODGEN
> //SYSUT1 DD UNIT=VIO,SPACE=(CYL,(20,5))
> //SYSUT2 DD UNIT=VIO,SPACE=(CYL,(10,1))
> //SYSUT3 DD UNIT=VIO,SPACE=(CYL,(2,1))
> //SYSPRINT DD SYSOUT=*
> //SYSPUNCH DD DSN=&&TEMP,DISP=(,PASS),
> // SPACE=(TRK,(1,1)),UNIT=VIO
> //SYSIN DD *
> PUNCH ′++ USERMOD (RA2) REWORK(1994200) .′ PUNCH ′++ VER
> (Z038) FMID(HRF2210).′ PUNCH ′++ MOD (ICHRDSNT) DISTLIB(AOSBN)
> LMOD(ICHRDSNT).′ ICHRDSNT TITLE ′ RACF DATA SET NAME TABLE′
> ICHRDSNT CSECT , ICHRDSNT AMODE 31 ICHRDSNT RMODE 24
> *
> DC AL1(1) ONE PRIMARY/BACKUP PAIR
> DC CL44′ SYS1.RACFESA′ DSN PRIMARY
> DC CL44′ SYS1.RACF.BKUP1′ DSN BACKUP
> DC AL1(255) RESIDENT DATA BLOCKS
> DC B′10001000′ FLAG BYTE
> END
> /*
> //*
> //SMP2 EXEC PGM=GIMSMP,COND=(0,NE)
> //SMPCSI DD DISP=SHR,DSN=TOT.SMP.GLOBAL.CSI //SMPHOLD DD
> DUMMY //SMPPTFIN DD DSN=&&TEMP,DISP=(OLD,DELETE) //LINKLIB DD
> DISP=SHR,DSN=SYS1.LINKLIB, // UNIT=SYSALLDA,VOL=SER=RES02A
> //SMPCNTL DD * SET BDY(TGTM02A) .
> UCLIN .
> REP LMOD(ICHRDSNT) SYSLIB(LINKLIB) .
> ENDUCL .
> SET BDY(GLOBAL) .
> RECEIVE S(RA2) SYSMODS .
> SET BDY(TGTM02A) .
> APPLY REDO S(RA2) .
> 
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Tom Marchant
> > Sent: Tuesday, February 04, 2014 6:33 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: RACF USERMOD APPLY
> >
> > On Tue, 4 Feb 2014 08:13:24 +0530, venkat kulkarni wrote:
> >
> > > I am getting issue while applying RACF USERMOD for changing
> > >RACF NAME TABLE.
> > >
> >
> > >//SMPPTFIN DD  DATA,DLM='%%'
> > >++USERMOD(UM21001)  REWORK(2014034)   .
> > >++VER(Z038) FMID(HRF7790) PRE(CPPDSNT) .
> >
> > The following JCLIN doesn't make any sense.  JCLIN should describe how
> > to create the target element from the distribution zone.  SMP/E uses
> > this information along with other information that you provide to create the
> element at APPLY time.
> > In this case, you are telling SMP/E to get module ICHRDSNT from
> > LINKLIB and store it in LINKLIB.
> >
> > >++JCLIN .
> > >//UM21001 JOB MVSSP121
> > >//ICHRDSNT EXEC PGM=IEWL,
> > >// PARM='LIST,LET,XREF,NCAL'
> > >//SYSPRINT DD SYSOUT=*
> > >//SYSUT1 DD UNIT=3390,SPACE=(CYL,(1,1)) //SYSLMOD DD
> > >DSN=Z.LINKLIB,DISP=SHR //SYSLIN DD *  INCLUDE
> SYSLMOD(ICHRDSNT)
> > ENTRY
> > >ICHRDSNT  NAME ICHRDSNT(R)
> > >/*
> > >++SRC(ICHRDSNT) DISTLIB(

Need a DB2 DBA under z/OS

[chris lindenhauer]

Hi Gang

We have a  desperate need for a DBA, Minneapolis MN.
If anyone is interested, or knows of anyone interested, please get back to
me at chrislindenha...@gmail.com

Thanks all :)

Chris

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

Re: CPU time

[John Gilmore]

I of course agree that "much work remains to be done"; but I am
hopeful that instruction-execution counts will in time come to
supplant CPU times, which are  increasing problematic because no
longer simply reproducible, for performance comparisons and
evaluations.

It would be agreeable to be able at  last to give literal meaning to
the phrase "path length".

If we must continue to use CPU times we shall all need to learn to
think like agronomists, to give up point measurements and instead to
view CPU times as mean values having high associated variances, and
thus to recognize that explicit, formal statistical
methods---experimental designs and multiple replications---will be
needed to obtain meaningful results.

John Gilmore, Ashland, MA 01721 - USA

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

Re: CPU time

[Mike Schwab]

I think a table of the shortest possible execution times for an
instruction would be useful, how many operands it uses, and at the end
a list of how much longer a fetch takes if an operand is not stored in
the fastest level of cache.

On Tue, Feb 4, 2014 at 10:01 AM, John Gilmore  wrote:
> I of course agree that "much work remains to be done"; but I am
> hopeful that instruction-execution counts will in time come to
> supplant CPU times, which are  increasing problematic because no
> longer simply reproducible, for performance comparisons and
> evaluations.
>
> It would be agreeable to be able at  last to give literal meaning to
> the phrase "path length".
>
> If we must continue to use CPU times we shall all need to learn to
> think like agronomists, to give up point measurements and instead to
> view CPU times as mean values having high associated variances, and
> thus to recognize that explicit, formal statistical
> methods---experimental designs and multiple replications---will be
> needed to obtain meaningful results.
>
> John Gilmore, Ashland, MA 01721 - USA
>
> --
> 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

Re: CPU time

[Thomas H Puddicombe]

Unfortunately, constants aren't and variables won't.

(g,d,r)

Vacation Notice: 

None currently scheduled

 
Tom Puddicombe
Principal Systems Engineer
Mainframe Performance & Capacity Planning
CSC

31 Brookdale Rd, Meriden, CT 06450
ITIS | (860) 428-3252 | tpudd...@csc.com | www.csc.com

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. 
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to 
any order or other contract unless pursuant to explicit written agreement 
or government initiative expressly permitting the use of e-mail for such 
purpose.



From:   Mike Schwab 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   02/04/2014 11:10 AM
Subject:Re: CPU time
Sent by:IBM Mainframe Discussion List 



I think a table of the shortest possible execution times for an
instruction would be useful, how many operands it uses, and at the end
a list of how much longer a fetch takes if an operand is not stored in
the fastest level of cache.

On Tue, Feb 4, 2014 at 10:01 AM, John Gilmore  wrote:
> I of course agree that "much work remains to be done"; but I am
> hopeful that instruction-execution counts will in time come to
> supplant CPU times, which are  increasing problematic because no
> longer simply reproducible, for performance comparisons and
> evaluations.
>
> It would be agreeable to be able at  last to give literal meaning to
> the phrase "path length".
>
> If we must continue to use CPU times we shall all need to learn to
> think like agronomists, to give up point measurements and instead to
> view CPU times as mean values having high associated variances, and
> thus to recognize that explicit, formal statistical
> methods---experimental designs and multiple replications---will be
> needed to obtain meaningful results.
>
> John Gilmore, Ashland, MA 01721 - USA
>
> --
> 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


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

Re: CPU time

[Tom Marchant]

On Tue, 4 Feb 2014 10:10:39 -0600, Mike Schwab wrote:

>I think a table of the shortest possible execution times for an
>instruction would be useful, how many operands it uses, and at the end
>a list of how much longer a fetch takes if an operand is not stored in
>the fastest level of cache.

John Eels had a SHARE presentation a couple of years ago where he described the 
cost of going to memory.  See page 88 of this:
https://share.confex.com/share/119/webprogramschedule/Handout/Session11718/SHARE
 119 Session 11718 Presentation.pdf

I don't remember what processor this information referred to.  Bottom line is 
that when the data comes from L1 cache, it is available during the same machine 
cycle.  If it has to come from main storage, it takes about 850 machine cycles.

-- 
Tom Marchant

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

Re: CPU time

[Anne & Lynn Wheeler]

jwgli...@gmail.com (John Gilmore) writes:
> I of course agree that "much work remains to be done"; but I am
> hopeful that instruction-execution counts will in time come to
> supplant CPU times, which are increasing problematic because no longer
> simply reproducible, for performance comparisons and evaluations.

long ago and far away we were doing some optimization on superfast
tcp/ip (for non-mainframe) 5k instruction pathlength and 5 buffer copies
and work on eliminating all buffer copies. this was also motivation for
adding hardware features that did direct storage to storage bypassing
cache.

a NFS 8kbyte packet was compared to LU6.2 through VTAM at 160k
instruction pathlength and 14 buffer copies. for mainframe processor at
the time, the 14 buffer copies could result in more processor time than
the 160k instructions, the copies would all be cache misses as well as
pushing stuff out of the cache that would have to be brought back in
later.

as an aside ... comingly used industry benchmark for processor
throughput (used across wide variety of different processors with
different instruction architectures) ... with references to MIPS and
BIPS ... is actual number of iterations compared to base number of
iterations on 370/158 taken to be 1MIP processor.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: Dummy dataset

[Mike Schwab]

Suggestion:  Add DD keyword SKIP.  Similar to DUMMY, but will continue
with the next concatenated DD statement.

On Tue, Feb 4, 2014 at 9:09 AM, Blaicher, Christopher Y.
 wrote:
> David,
>
> The use of DD DUMMY in a concatenation ends the processing of input data.  
> The following is from the JCL Reference Manual:
>
> Data sets concatenated to dummy data sets: The system treats data sets
> concatenated to a DUMMY data set as dummy data sets in that I/O operations are
> bypassed. However, the system performs disposition processing and allocates
> devices and storage for any concatenated data sets.
>
> So, in your example you only read the file once.  Without the DD DUMMY it 
> would read the file twice.
>
> Chris Blaicher
> Principal Software Engineer, Software Development
> Syncsort Incorporated
> 50 Tice Boulevard, Woodcliff Lake, NJ 07677
> P: 201-930-8260  |  M: 512-627-3803
> E: cblaic...@syncsort.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Jousma, David
> Sent: Tuesday, February 04, 2014 8:45 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Dummy dataset
>
> No, we have users sorting data with path names as input.  Just ran a test.  
> Single path input, concatenated, all work fine, unless they add a DD DUMMY 
> between them.  As a side note, DFSORT doesn't do a good job with dynamic 
> sortwk allocations with PATH input because it cannot accurately determine the 
> input filesize.   I had opened a ticket with IBM on this, and all I got was 
> "this is the way it is".   My only option was to tell my developers to 
> hardcode sorkwk datasets in their job.
>
> //DFSORT   EXEC PGM=SORT
> //SORTINDD PATHDISP=KEEP,
> // PATHOPTS=ORDONLY,
> // FILEDATA=TEXT,
> // RECFM=VB,LRECL=255,BLKSIZE=25496,
> // PATH='/etc/httpd1443.conf'
> //  DD DUMMY
> //  DD PATHDISP=KEEP,
> // PATHOPTS=ORDONLY,
> // FILEDATA=TEXT,
> // RECFM=VB,LRECL=255,BLKSIZE=25496,
> // PATH='/etc/httpd1443.conf'
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Paul Gilmartin
> Sent: Tuesday, February 04, 2014 8:37 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Dummy dataset
>
> On Thu, 30 Jan 2014 20:18:05 +, Jousma, David wrote:
>
>>We have an exit for DFSORT that scans TIOT to see if someone concatenated a 
>>DUMMY dataset as input.  Here is what I believe to be the relevant snippet of 
>>code:
>>...
>>* CHECK FOR DUMMY DD STATEMENT
>>* NOTE: COULD ALSO BE DD *
>>DDCHKCLC   TIOEFSRT,=AL3(0)   Q. REAL UCB ADDRESS ?
>> BEDDBAD  A. NO, BAD DD
>>...
>>
> How does this behave for DD PATH=...?  Is the UCB address nonzero for zFS 
> files?  Are you unwittingly prohibiting use of zFS in the SORTIN 
> concatenation?  That would be imprisoning your users in the twentieth century.
>
> Prohibiting "DD *" is also unduly harsh.
>
> A similar question applies to Shmuel's suggestion of DEVTYPE.
>
> The definitive test should be for DSNAME='NULLFILE'.
>
> -- 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
>
> 
>
>
>
> ATTENTION: -
>
> The information contained in this message (including any files transmitted 
> with this message) may contain proprietary, trade secret or other 
> confidential and/or legally privileged information. Any pricing information 
> contained in this message or in any files transmitted with this message is 
> always confidential and cannot be shared with any third parties without prior 
> written approval from Syncsort. This message is intended to be read only by 
> the individual or entity to whom it is addressed or by their designee. If the 
> reader of this message is not the intended recipient, you are on notice that 
> any use, disclosure, co

Re: CPU time

[Charles Mills]

Is "the shortest possible execution time" even a meaningful concept? My
understanding is that at least one possible answer is zero. That is, it may
be possible that you have a sequence of instructions A, B, C, and that I
could introduce one more instruction between A and B without changing the
length of time it takes the sequence to execute -- because it simply "fills
up" part of an inevitable delay before executing B or C -- so the answer to
your question is effectively zero.

OTOH, as I said and EJ confirmed, "how much longer a fetch takes if not in
L1 cache" is "one HECK of a lot longer." As I said my new mental model is
"instructions take essentially no time; (uncached) data fetches take a real
long time." I think the concept of "how long an instruction takes" is
essentially an outmoded way of thinking about the problem. Instructions
don't take time; data fetches do.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Mike Schwab
Sent: Tuesday, February 04, 2014 11:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CPU time

I think a table of the shortest possible execution times for an instruction
would be useful, how many operands it uses, and at the end a list of how
much longer a fetch takes if an operand is not stored in the fastest level
of cache.

On Tue, Feb 4, 2014 at 10:01 AM, John Gilmore  wrote:
> I of course agree that "much work remains to be done"; but I am 
> hopeful that instruction-execution counts will in time come to 

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

Re: Dummy dataset

[Tony Babonas]

This triggers a memory from my wayback machine.  Back then when symbolic 
references first became available this little annoyance was noticed by 
several application developers.  Our local circumvention was to code a 
symbolic reference one of several datasets that were created at various 
lrecls, kept empty, and used instead of DUMMY.  Crude, but effective.





On 2/4/2014 9:24 AM, Jousma, David wrote:

Chris, Yes, I am aware of that.   This thread started from an exit we run that 
detects this type of concatenation in a DFSORT SORTIN due to fallout 
encountered years ago involving the use of symbolics to override dataset names 
in the concatenation at runtime.   The fallout that occurred was because it 
took days for the affected app groups to determine that the concatenated 
datasets after the DUMMY dataset were never included in the SORTOUT.  I was not 
at this job when it occurred, but we are a bank, some maybe the affect was that 
someone's bank accounts were not accurate(I don’t know).  Some here call it a 
feature, some call it a shortcoming, regardless, it is the way the system 
operates.   The problem for us then was that the job ended RC(0), and it took a 
long time to figure out that the input data was ignored.   That’s why the exit 
came to life.

I know that the same behavior exits using IEBGENER, and IDCAMS REPRO copying 
and we don’t have exits for those, and no one has complained.

Why do we have the ICE EXIT?  Politics.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Blaicher, Christopher Y.
Sent: Tuesday, February 04, 2014 10:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dummy dataset

David,

The use of DD DUMMY in a concatenation ends the processing of input data.  The 
following is from the JCL Reference Manual:

Data sets concatenated to dummy data sets: The system treats data sets 
concatenated to a DUMMY data set as dummy data sets in that I/O operations are 
bypassed. However, the system performs disposition processing and allocates 
devices and storage for any concatenated data sets.

So, in your example you only read the file once.  Without the DD DUMMY it would 
read the file twice.

Chris Blaicher
Principal Software Engineer, Software Development Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8260  |  M: 512-627-3803
E: cblaic...@syncsort.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Tuesday, February 04, 2014 8:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dummy dataset

No, we have users sorting data with path names as input.  Just ran a test.  Single path 
input, concatenated, all work fine, unless they add a DD DUMMY between them.  As a side 
note, DFSORT doesn’t do a good job with dynamic sortwk allocations with PATH input 
because it cannot accurately determine the input filesize.   I had opened a ticket with 
IBM on this, and all I got was "this is the way it is".   My only option was to 
tell my developers to hardcode sorkwk datasets in their job.

//DFSORT   EXEC PGM=SORT
//SORTINDD PATHDISP=KEEP,
// PATHOPTS=ORDONLY,
// FILEDATA=TEXT,
// RECFM=VB,LRECL=255,BLKSIZE=25496,
// PATH='/etc/httpd1443.conf'
//  DD DUMMY
//  DD PATHDISP=KEEP,
// PATHOPTS=ORDONLY,
// FILEDATA=TEXT,
// RECFM=VB,LRECL=255,BLKSIZE=25496,
// PATH='/etc/httpd1443.conf'

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, February 04, 2014 8:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dummy dataset

On Thu, 30 Jan 2014 20:18:05 +, Jousma, David wrote:


We have an exit for DFSORT that scans TIOT to see if someone concatenated a 
DUMMY dataset as input.  Here is what I believe to be the relevant snippet of 
code:
...
* CHECK FOR DUMMY DD STATEMENT
* NOTE: COULD ALSO BE DD *
DDCHKCLC   TIOEFSRT,=AL3(0)   Q. REAL UCB ADDRESS ?
 BEDDBAD  A. NO, BAD DD
...


How does this behave for DD PATH=...?  Is the UCB address nonzero for zFS 
files?  Are you unwittingly prohibiting use of zFS in the SORTIN concatenation? 
 That would be imprisoning your users in the twentieth century.

Prohibiting "DD *" is also unduly harsh.

A similar question applies to Shmuel's suggestion of DEVTYPE.

The definitive test should be for DSNAME='NULLFILE'.

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

Re: Dummy dataset

[Gerhard Postpischil]

On 2/4/2014 8:37 AM, Paul Gilmartin wrote:

Prohibiting "DD *" is also unduly harsh.

A similar question applies to Shmuel's suggestion of DEVTYPE.

The definitive test should be for DSNAME='NULLFILE'.


If the code is intended for general use (e.g., a SORT invoked 
dynamically), then flag TIOSLTYP needs to be tested, as well as several 
bits in TIOELINK.


Gerhard Postpischil
Bradford, Vermont

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

Re: CPU time

[Anne & Lynn Wheeler]

m42tom-ibmm...@yahoo.com (Tom Marchant) writes:
> John Eels had a SHARE presentation a couple of years ago where he
> described the cost of going to memory.  See page 88 of this:
> https://share.confex.com/share/119/webprogramschedule/Handout/Session11718/SHARE
>  119 Session 11718 Presentation.pdf
>
> I don't remember what processor this information referred to.  Bottom
> line is that when the data comes from L1 cache, it is available during
> the same machine cycle.  If it has to come from main storage, it takes
> about 850 machine cycles.

for a decade or so the latency cost for a cache miss to memory counted
in processor cycles is similar to the count of 360 processor cycles for
a 360 disk i/o ... aka memory has become the new disk.

that is motivation for things like hyperthreading (multiple overlapped
i-streams) ... simulating multiprocessor ... aka the hardware equivalent
of multitasking to allow overlapping execution with things waiting. it
is also behind out-of-order execution (skipping past instruction stalled
on cache miss). Introduction of out-of-order execution for z196 is
claimed to be major factor in the increase in processor throughput
between z10 and z196 (something that dates back couple decades in some
other platforms).

also, processor cycle time has been getting faster than memory latency
... which harkens back to my theme in the 70s and early 80s ... that
processor was getting faster, much faster than disks were getting
faster. At one point in the early 80s, I was saying that relative system
disk speed had declined by a factor of ten times over a period of
15years (processor&memory got 40-50 times, disks got 3-5 times).  Disk
division executives assigned their performance group to refute my
statements ... but after a couple weeks they came back and effectively
said that I had slightly understated the problem ... the analysis is
respun and turns into a SHARE presentation on optimizing disk
configurations for system throughput.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: RACF USERMOD APPLY

[retired mainframer]

The error message refers to SYSMOD SP21001.  The job you showed applies
SYSMOD UM21001.  How are those two related?

:>: -Original Message-
:>: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
:>: Behalf Of venkat kulkarni
:>: Sent: Monday, February 03, 2014 6:43 PM
:>: To: IBM-MAIN@LISTSERV.UA.EDU
:>: Subject: RACF USERMOD APPLY
:>:
:>: Hello,
:>:  I am getting issue while applying RACF USERMOD for changing
:>: RACF
:>: NAME TABLE.
:>:
:>: //USERMOD1 JOB   ((660)),
:>: // 'VENKAT',
:>: // CLASS=A,
:>: // MSGCLASS=A,
:>: // TIME=1440,NOTIFY=&SYSUID
:>: //*
:>: //STEP1EXEC PGM=GIMSMP,REGION=6M,
:>: // TIME=120
:>: //SMPCSI   DD  DSN=SMPE.GLOBAL.CSI,
:>: // DISP=SHR
:>: //SMPHOLD  DD  DUMMY
:>: //SMPOUT   DD  SYSOUT=*
:>: //SMPRPT   DD  SYSOUT=*
:>: //SYSPRINT DD  SYSOUT=*,DCB=(LRECL=133,BLKSIZE=2660,RECFM=FB)
:>: //SMPCNTL  DD  *
:>:  SET BDY(GLOBAL) .
:>:  RECEIVE S(UM21001) .
:>:  SET BDY(MVST100) .
:>:   APPLY CHECK S(UM21001) REDO .
:>: /*
:>: //SMPPTFIN DD  DATA,DLM='%%'
:>: ++USERMOD(UM21001)  REWORK(2014034)   .
:>: ++VER(Z038) FMID(HRF7790) PRE(CPPDSNT) .
:>: ++JCLIN .
:>: //UM21001 JOB MVSSP121
:>: //ICHRDSNT EXEC PGM=IEWL,
:>: // PARM='LIST,LET,XREF,NCAL'
:>: //SYSPRINT DD SYSOUT=*
:>: //SYSUT1 DD UNIT=3390,SPACE=(CYL,(1,1))
:>: //SYSLMOD DD DSN=Z.LINKLIB,DISP=SHR
:>: //SYSLIN DD *
:>:  INCLUDE SYSLMOD(ICHRDSNT)
:>:  ENTRY ICHRDSNT
:>:  NAME ICHRDSNT(R)
:>: /*
:>: ++SRC(ICHRDSNT) DISTLIB(AORASRC) DISTMOD(ALINKLIB) .
:>:  ICHRDSNT CSECT
:>:   DCAL1(1)   # PRIMARY RACF DATASETS
:>:   DCCL44'SYS1.RACFP'  NAME OF PRIMARY
:>:   DCCL44'SYS1.RACFB'   NAME OF BACKUP
:>:   DCAL1(255) # RESIDENT BLOCKS (ONE TRACK)
:>:   DCX'80'UPDATES DUPLICATED ON BACKUP D
:>:   END
:>:  %%
:>:  //
:>:
:>:  APPLY CHECK S(UM21001) REDO .
:>:
:>: GIM40501E ** THE DISTLIB VALUE (ALINKLIB) SPECIFIED FOR MOD ICHRDSNT IN
:>: SYSMOD
:>:  SP21001 DOES NOT MATCH THE DISTLIB VALUE (AOSBN) IN THE MOD
:>: ENTRY
:>:  FOR ICHRDSNT.
:>: GIM22601IAPPLY PROCESSING FAILED FOR SYSMOD UM21001.
:>: GIM20501IAPPLY PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS
:>: 08.
:>:
:>: I am not able to find hint to solve this issue. Can anybody help me on
:>: this.
:>:
:>: --
:>: 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: Assembler code

[Ron Thomas]

Ok Thanks .so what would be o/p of this statement "TRBIT,TR@TAB " here ? 

Thanks,
Ron T

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

Re: Dummy dataset

[Jousma, David]

Sorry for being dense...Never heard of it?  What is SKIP?   I just looked in 
JCL reference, don't see anything?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Schwab
Sent: Tuesday, February 04, 2014 11:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dummy dataset

Suggestion:  Add DD keyword SKIP.  Similar to DUMMY, but will continue with the 
next concatenated DD statement.


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: Dummy dataset

[John McKown]

On Tue, Feb 4, 2014 at 11:45 AM, Jousma, David  wrote:

> Sorry for being dense...Never heard of it?  What is SKIP?   I just looked
> in JCL reference, don't see anything?
>

There is no SKIP parameter in JCL. Gil was wanting IBM to create such a
beasty just for this type of problem. How to "null out" a DD in the midst
of a concatenation, short of creating an empty data set with the correct
DCB information.


-- 
Wasn't there something about a PASCAL programmer knowing the value of
everything and the Wirth of nothing?

Maranatha! <><
John McKown

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

Re: JESGB400/IEFGB400

[SUBSCRIBE IBM-MAIN Harold Gray]

I have not reassembled as the pointers and offsets have not changed.  There are 
no abends and I know the code is not being called.  As far as I know all system 
messages are still coming out. I have a development system and I've set the 
code to abend if it gets called and nothing happens.

Our routine is looking for IEF287I messages to detect C'NOT CATLGD  2' 
messages.  We hook ourselves in front of the IBM routine and then branch to the 
original code once we've noted the NOT CATLGD 2 to our system. When I look at 
my job that tests the NOT CATLGD 2, there are two sets of messages dealing with 
this issue.  In the JOBLOG, the following message comes out:
IEF377I NOTCAT2 STEP6  440
OPS.NOTCAT2.TEST4 NOT CATLGD 2
In the MSGLOG the following message comes out:
IEF287I   OPS.NOTCAT2.TEST4NOT CATLGD  2  (this is 
the one we've always looked for).
I first thought the change was that IEF377I replaced the IEF287I and I changed 
the routine to look for either but I still didn't get my notification so I 
changed the code to abend to make sure it was getting called (development so 
hard abends would not be a problem) but everything works fine - except I don't 
get called which also means the original IEFGB400 program wouldn't have been 
called either.

I am looking for why the JESGB400/IEFGB400 isn't being called (JES or SYSTEM 
parmlib parameter??) or what replaced that message processor. I'm not sure how 
to setup a trap when it doesn't look like the JESGB400 pointer is being used at 
all.

Thanks,

Harold

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

Re: CPU time

[John Eells]

Tom Marchant wrote:

On Tue, 4 Feb 2014 10:10:39 -0600, Mike Schwab wrote:


I think a table of the shortest possible execution times for an
instruction would be useful, how many operands it uses, and at the end
a list of how much longer a fetch takes if an operand is not stored in
the fastest level of cache.


John Eels had a SHARE presentation a couple of years ago where he described the 
cost of going to memory.  See page 88 of this:
https://share.confex.com/share/119/webprogramschedule/Handout/Session11718/SHARE
 119 Session 11718 Presentation.pdf

I don't remember what processor this information referred to.  Bottom line is 
that when the data comes from L1 cache, it is available during the same machine 
cycle.  If it has to come from main storage, it takes about 850 machine cycles.



That example was deliberately both (a) simplified and (b) made generic 
(its purpose was to illustrate the "why" for HiperDispatch in a 
conceptual way).  In reality, there are multiple possible latencies for 
many of the levels of the cache and within the real memory hierarchy as 
well.  The concepts are sound but don't rely on the numbers as gospel. 
Also, if I recall correctly, average memory latency is more like 950 
cycles on current processors.


--
John Eells
z/OS Technical Marketing
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: Dummy dataset

[Paul Gilmartin]

On Tue, 4 Feb 2014 10:25:32 -0600, Mike Schwab wrote:

>Suggestion:  Add DD keyword SKIP.  Similar to DUMMY, but will continue
>with the next concatenated DD statement.
> 
No good:

user@HOST: rexx "say bpxwdyn( 'alloc skip msg(wtp)' )"
-22

-- gil

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

Re: Dummy dataset

[Paul Gilmartin]

On Tue, 4 Feb 2014 12:20:21 -0600, John McKown wrote:

>On Tue, Feb 4, 2014 at 11:45 AM, Jousma, David wrote:
>
>> Sorry for being dense...Never heard of it?  What is SKIP?   I just looked
>> in JCL reference, don't see anything?
>
>There is no SKIP parameter in JCL. Gil was wanting IBM to create such a
>beasty just for this type of problem. How to "null out" a DD in the midst
>of a concatenation, short of creating an empty data set with the correct
>DCB information.
> 
"Gil" who?  It was Mike's idea.  Perhaps he has a user exit.

-- gil

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

Re: Assembler code

[Andy Wood]

On Tue, 4 Feb 2014 11:22:32 -0600, Ron Thomas  wrote:

>Ok Thanks .so what would be o/p of this statement "TRBIT,TR@TAB " here ? 
>

When I look at that code, I am left thinking "there has to be an easier way". I 
would have done a single CVB immediately after the PACK, and then split it up 
into the byte and bit displacements.

However to answer your specific question: The remainder, after dividing by 8, 
and which has been placed in BIT, is a number in the range 0 to 7. The TR 
converts 0 to X'80', 1 to X'40', 2 to X'20' etc, for use as the "mask" in the 
TM.

 

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

Re: Assembler code

[Andy Wood]

On Tue, 4 Feb 2014 13:08:25 -0600, Andy Wood  wrote:

. . .
>
>However to answer your specific question: The remainder, after dividing by 8, 
>and which has been placed in BIT, is a number in the range 0 to 7. The TR 
>converts 0 to X'80', 1 to X'40', 2 to X'20' etc, for use as the "mask" in the 
>TM.
>

Ok, so I was mislead by the comments.  The X'80', X'40' etc is used in the XI, 
there being no TM instruction.

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

Re: Assembler code

[Bernd Oppolzer]

The TR translates a bit position in the range 0 to 7
to the appropriate bit mask, that is

0 is translated to B'1000'
1 to B'0100'
2 to B'0010'
3 to B'0001'

and so on

So the XI inverts the bit that is specified by those two parameters
on entry to the procedure:

 ZAP   BYTE,T@SAVE(7)  QUOTIENT IS BYTE DISPLACEMENT. * 
0910
 ZAP   BIT,T@SAVE+7(1) REMAINDER IS BIT DISPLACEMENT. * 
0920


Kind regards

Bernd



Am 04.02.2014 18:22, schrieb Ron Thomas:

Ok Thanks .so what would be o/p of this statement "TRBIT,TR@TAB " here ?

Thanks,
Ron T

--
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: CICS Transaction Server 5.2 Open Beta Program Announced

[Frank Swarbrick]

As an application developer I am excited about these two (or are are both of 
these describing the same feature?):
- Channels and containers allow applications to be able to use containers 
without the need to restructure COMMAREA-based programs. 
- Channels and containers are enhanced to introduce transaction containers
 that are created in the DFHTRANSACTION channel. This channel does not 
go out of scope when the link level changes; it is always accessible in 
the transaction. This allows all applications to use containers, 
including those that use COMMAREAs in program links.

Frank




>
> From: Timothy Sipples 
>To: IBM-MAIN@LISTSERV.UA.EDU 
>Sent: Monday, February 3, 2014 11:02 PM
>Subject: CICS Transaction Server 5.2 Open Beta Program Announced
> 
>
>I didn't see anyone else mention it yet, so here's IBM's announcement of
>the open beta program for CICS Transaction Server 5.2:
>
>http://www-01.ibm.com/common/ssi/rep_ca/5/897/ENUS214-015/ENUS214-015.PDF
>
>You can download the beta version of CICS TS 5.2 starting in late February,
>2014, by visiting this Web site:
>
>http://www.ibm.com/cics/openbeta
>
>You'll need z/OS 1.13 or higher to run the CICS TS 5.2 beta version(s) --
>and presumably the final release as well. (A single available z/OS 1.13 or
>higher LPAR or z/VM guest will do.) There's no charge for using the beta
>version. See the announcement letter for details on terms and conditions
>(which are simple and few).
>
>For those of you unfamiliar with CICS Transaction Server, it's one of the
>world's premier transaction processing and application hosting environments
>-- and that's an understatement, really. And it's probably the world's most
>popular mission-critical transaction manager. Here are some of the
>highlights in Version 5.2:
>
>- First class, updated support for the WebSphere Liberty Profile, meaning
>you can run all sorts of Java applications based on those popular
>Java-related standards in CICS TS. Nothing extra required -- it's ready to
>go and very convenient. Yes, if you have CICS TS you have Java and Java
>application hosting, standard, at no additional charge. And
>anybody/everybody developing Java-based applications -- including open
>source developers -- is already a CICS TS developer. It's genuine, 100%
>WebSphere Liberty and its rich function set, but with CICS TS service
>levels, fast startup, and reduced memory requirements. Great stuff here.
>Maybe Kirk (for example) can comment further on this aspect of CICS TS, but
>(if you can't tell) I think it's one of the best additions to CICS (and to
>z/OS) ever.
>
>- Integrated JSON and REST support, which will be of particular interest to
>those developing and deployment mobile applications. This support is
>available as a no charge add-on, but now it's part of the base CICS TS
>distribution and thus even more convenient. Likewise, more security
>features are integrated in the base distribution, e.g. SAML support.
>
>- More Unicode-related and COBOL-related support for service mappings (SOAP
>and JSON).
>
>- More exploitation of IP interconnectivity (IPIC) for more high
>availability deployment scenarios.
>
>- Applications which use COMMAREAs can now jump forward to use containers
>without application restructuring. So you can standardize on containers (no
>32K limit!) and gradually expand those COMMAREAs into container-sized data
>structures as/when you see fit. This is really great for application
>evolution.
>
>- More threadsafe support, and less use of 31-bit storage. (CICS TS is
>increasingly exploiting 64-bit storage, and those improvements continue.)
>
>- More cloud-oriented capabilities, such as multiple application versioning
>with the lifecycle management of first-class applications and greater
>dynamic control over CICS regions/topologies. The basic idea here is you
>have lots of capabilities for instantly or near-instantly, dynamically,
>automatically provisioning and de-provisioning CICS applications (and
>multi-component application topologies which include CICS-hosted
>components) and associated runtime environments.
>
>- CICS Explorer picks up lots of enhancements consistent with improvements
>to CICS TS itself, plus CICS Explorer 5.2 will let you define and manage
>workloads with CICSPlex System Manager (CPSM) workload management (WLM). I
>should editorialize here that CPSM does not require Sysplex or Parallel
>Sysplex, and some people get confused by the "Plex" in the name. CPSM is
>very useful indeed in many situations, even when you run CICS on a single
>LPAR in a monoplex. So don't skip over that CPSM information if you have
>previously because you didn't think you qualified. If you have CICS TS, you
>have CPSM, and you should strongly consider enabling CPSM if you haven't
>already.
>
>- There are even more features to trigger additional CICS autonomic actions
>based on service thresholds. This is very helpful if you have "problem
>child" transaction programs that curren

Re: CPU time

[Blaicher, Christopher Y.]

The whole question of latency could take up several lectures, if we were still 
in college, and a lot of research.

The CPU Measurement facilities mentioned before offer us a 'peek through the 
keyhole' view of what is going on behind the scenes that before now we had no 
way of seeing.

As I see it today there are four layers of latency.  The first is instruction 
fetch.  The next is address resolution followed by data fetch followed lastly 
by data store.  The first and third of these can be greatly affected by where 
the data is coming from, be it level 1 cache or level 4 cache.  Address 
resolution gets hit due to the use of a LOAD followed by a LOAD using the first 
as a base or index register.  Data store is most always into level 1 cache, but 
even this can cause delays because of the updating of the cache directory for 
all associated processors.

Hardware Instrumentation Services can tell us the number of cycles used to 
execute a number of instructions.  It also gives us the number of writes into 
the cache directory and the penalty cycles waiting for the data to harden.  
What is not clear to me is how those two inter-relate.  Does a cache penalty 
cycle also cause an instruction cycle?

In addition, does an MVCL with a padding byte of x'B0' bypass all the cache, or 
just level 1?  And does the bypass of cache, while not flushing cache, really 
save time because now it has to go farther out in memory?

All are questions that will be answered as we go along. I think the best we can 
say today is that we will get hints and glimmers of what is happening.

Chris Blaicher
Principal Software Engineer, Software Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8260  |  M: 512-627-3803
E: cblaic...@syncsort.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Anne & Lynn Wheeler
Sent: Tuesday, February 04, 2014 12:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CPU time

m42tom-ibmm...@yahoo.com (Tom Marchant) writes:
> John Eels had a SHARE presentation a couple of years ago where he
> described the cost of going to memory.  See page 88 of this:
> https://share.confex.com/share/119/webprogramschedule/Handout/Session1
> 1718/SHARE 119 Session 11718 Presentation.pdf
>
> I don't remember what processor this information referred to.  Bottom
> line is that when the data comes from L1 cache, it is available during
> the same machine cycle.  If it has to come from main storage, it takes
> about 850 machine cycles.

for a decade or so the latency cost for a cache miss to memory counted in 
processor cycles is similar to the count of 360 processor cycles for a 360 disk 
i/o ... aka memory has become the new disk.

that is motivation for things like hyperthreading (multiple overlapped
i-streams) ... simulating multiprocessor ... aka the hardware equivalent of 
multitasking to allow overlapping execution with things waiting. it is also 
behind out-of-order execution (skipping past instruction stalled on cache 
miss). Introduction of out-of-order execution for z196 is claimed to be major 
factor in the increase in processor throughput between z10 and z196 (something 
that dates back couple decades in some other platforms).

also, processor cycle time has been getting faster than memory latency ... 
which harkens back to my theme in the 70s and early 80s ... that processor was 
getting faster, much faster than disks were getting faster. At one point in the 
early 80s, I was saying that relative system disk speed had declined by a 
factor of ten times over a period of 15years (processor&memory got 40-50 times, 
disks got 3-5 times).  Disk division executives assigned their performance 
group to refute my statements ... but after a couple weeks they came back and 
effectively said that I had slightly understated the problem ... the analysis 
is respun and turns into a SHARE presentation on optimizing disk configurations 
for system throughput.

--
virtualization experience starting Jan1968, online at home since Mar1970

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





ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any use, disclosure, copying or distributi

Re: Assembler code

[Bernd Oppolzer]

I would like to add that the name of the code section and the comment
both are misleading, IMO.

The name of the code section is FORCEONE. If the bit really is forced
to one, the instruction executed should be OI, not XI.

And the comment says that a TM will be executed, but there is no TM.

I have the impression that this code section has been copied several
times; the instruction that is executed has been changed, but the
comments stayed the same. FORCEONE will only be OK, if the target
bit was zero before, otherwise it will change from one to zero, which
is not what the name FORCEONE makes us believe.

Kind regards

Bernd



Am 04.02.2014 20:27, schrieb Bernd Oppolzer:

The TR translates a bit position in the range 0 to 7
to the appropriate bit mask, that is

0 is translated to B'1000'
1 to B'0100'
2 to B'0010'
3 to B'0001'

and so on

So the XI inverts the bit that is specified by those two parameters
on entry to the procedure:

 ZAP   BYTE,T@SAVE(7)  QUOTIENT IS BYTE DISPLACEMENT. 
* 0910
 ZAP   BIT,T@SAVE+7(1) REMAINDER IS BIT DISPLACEMENT. 
* 0920


Kind regards

Bernd



Am 04.02.2014 18:22, schrieb Ron Thomas:
Ok Thanks .so what would be o/p of this statement "TRBIT,TR@TAB " 
here ?


Thanks,
Ron T

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

Orphaned VVR

[Mike Schwab]

We have an orphaned VVR in a VVDS.  Not in the catalog or VTOC.
DELETE data.set.name FILE(DD1) VVR failed NOT CATALOGED.
What do we need to do to clean this up.

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

Re: Orphaned VVR

[Graham Harris]

Might be worth trying ISMF.  I have found it amazingly adept at deleting
'broken stuff' in the past.


On 4 February 2014 20:01, Mike Schwab  wrote:

> We have an orphaned VVR in a VVDS.  Not in the catalog or VTOC.
> DELETE data.set.name FILE(DD1) VVR failed NOT CATALOGED.
> What do we need to do to clean this up.
>
> --
> 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
>

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

Re: Orphaned VVR

[Mike Schwab]

Not in the Catalog, Not in the VTOC.  Does not list either way.
Only shows up in the ADRDSSU backup and IDCAMS DIAGNOSE.

On Tue, Feb 4, 2014 at 3:28 PM, Graham Harris  wrote:
> Might be worth trying ISMF.  I have found it amazingly adept at deleting
> 'broken stuff' in the past.
>
>
> On 4 February 2014 20:01, Mike Schwab  wrote:
>
>> We have an orphaned VVR in a VVDS.  Not in the catalog or VTOC.
>> DELETE data.set.name FILE(DD1) VVR failed NOT CATALOGED.
>> What do we need to do to clean this up.
>>
>> --
>> 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
>>
>
> --
> 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

Re: Orphaned VVR

[Mark Zelden]

On Tue, 4 Feb 2014 15:34:51 -0600, Mike Schwab  wrote:

>Not in the Catalog, Not in the VTOC.  Does not list either way.
>Only shows up in the ADRDSSU backup and IDCAMS DIAGNOSE.
>

How about telling us the error code diagnose displayed and a copy
of the JCL / control statement you are running and output error messages? 

Does the original catalog still exist?   If not  add CATALOG(master.cat) to
your DELETE VVR sysin.  

--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS  
ITIL v3 Foundation Certified   
mailto:m...@mzelden.com   
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://search390.techtarget.com/ateExperts/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: JESGB400/IEFGB400

[Tony Harminc]

On 3 February 2014 14:24, SUBSCRIBE IBM-MAIN Harold Gray
 wrote:
[...]
>L R3,JESCTEXTLOAD PAGEABLE EXTENTION
>  DROP  R3
>  USING JESPEXT,R3 EST ADDRESSABILITY WITH EXT
>  L R4,JESGB400GET MSG WRITER ADDRESS
> *
> This code has been working since the 1990's.  The linkages still are valid 
> but the routine does not appear to be executed anymore. I've looked for any 
> notes in the migration doc's and I've compared the macro (JESCT) that 
> describes the aplicable areas and have not detected anything that would 
> account for what happened.

It's not looking good... The JESCT description in the 1.13 data areas
doesn't list JESPEXT as a PI field. And the z/OS 2.1 book that claims
to contain JESCT seems to be truncated after IXLYEEPL. :-(

Neither does the JES2 source or maclib contain the strings JESGB400 or
IEFGB400. I can't find any reference to either name in any of the
current z/OS doc.

So I would guess that IBM has quietly stopped using this interface,
since it seems not to have been documented for a long time. But you'd
need to ask IBM.

Tony H.

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

Re: Orphaned VVR

[Mike Schwab]

 DIAGNOSE VVDS INFILE(DIAGDD) COMPAREDD(DIAG01) -
INCLUDE(LEVEL (PERVDR.P.PERWCARL.R))
IDC21364I ERROR DETECTED BY DIAGNOSE:
  VVDS ENTRY: PERVDR.P.PERWCARL.R.X100608.T060521 (Z)
  RECORD: X'00AF1000'
  OFFSET: X'0002'
  REASON: 17 - VTOC ENTRY NOT FOUND
IDC21365I VVDS RECORD DISPLAY:
  RECORD: X'00AF1000'

*Z..PERVDR.P.PERWCARL.R.X*
*100608.T060521..PERVDR.P.PERWCAR*
*L.R.D100608.T060521..ICFCAT.PERV*
*DR.PERVDR.P.PERWCARL.R.D100608.T*
*060521{-...&...{*
*...8{...*
*..{..&..*
*..STANDARD..VSAMEXTE..ST*
*ANDARD..*
[trimmed periods and hex values]

IDC21363I THE FOLLOWING ENTRIES HAD ERRORS:
  PERVDR.P.PERWCARL.R.X100608.T060521 (Z) - REASON CODE: 17


 DELETE PERVDR.P.PERWCARL.R.X100608.T060521 -
   FILE(DD1) VVR
IDC3014I CATALOG ERROR
IDC3009I ** VSAM CATALOG RETURN CODE IS 90 - REASON CODE IS IGG0CLFP-38
IDC0551I ** ENTRY PERVDR.P.PERWCARL.R.X100608.T060521 NOT DELETED
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 8


On Tue, Feb 4, 2014 at 3:49 PM, Mark Zelden  wrote:
> On Tue, 4 Feb 2014 15:34:51 -0600, Mike Schwab  
> wrote:
>
>>Not in the Catalog, Not in the VTOC.  Does not list either way.
>>Only shows up in the ADRDSSU backup and IDCAMS DIAGNOSE.
>>
>
> How about telling us the error code diagnose displayed and a copy
> of the JCL / control statement you are running and output error messages?
>
> Does the original catalog still exist?   If not  add CATALOG(master.cat) to
> your DELETE VVR sysin.
>
> --
> Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
> ITIL v3 Foundation Certified
> mailto:m...@mzelden.com
> Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
> Systems Programming expert at http://search390.techtarget.com/ateExperts/
> --
> 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

Re: RACF USERMOD APPLY

[Skip Robinson]

ICHRDSNT comes with RACF as a MOD/LMOD entity only. There is no source 
supplied. You can create a usermod with source to replace the MOD/LMOD. 
You must use the same DISTLIB as the RACF-supplied MOD, which is AOSBN. 
Otherwise you'll get a mismatch error. Here's what our DSNT usermod looks 
like. Because this usermod will never be accepted, we don't need to 
specify an actual DISTLIB for SRC. SMP/E knows how to assemble source, so 
JCLIN does not need that step. 

//SMPPTFIN DD   DATA,DLM=$$ 
++USERMOD(RACF001) REWORK(2011175 ) . 
++VER(Z038) FMID(HRF7780) 
 /* 
  THIS USERMOD INSTALLS THE RACF DATASET NAME TABLE 
  MODULE (ICHRDSNT) . SOURCE IN INCLUDED INLINE. 
   */. 
++JCLIN. 
//ICHRDSNT EXEC LINKS,PARM='XREF,LIST,LET,NCAL,RENT' 
//SYSLMOD  DD DISP=SHR,DSN=SYS1.LINKLIB 
//AOSBNDD DISP=SHR,DSN=SYS1.AOSBN 
//SYSLIN   DD * 
  INCLUDE AOSBN(ICHRDSNT) 
  NAME ICHRDSNT(R) 
++SRC (ICHRDSNT) DISTLIB (DUMMY) .
...
$$

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



From:   venkat kulkarni 
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   02/03/2014 06:43 PM
Subject:RACF USERMOD APPLY
Sent by:IBM Mainframe Discussion List 



Hello,
 I am getting issue while applying RACF USERMOD for changing RACF
NAME TABLE.

//USERMOD1 JOB   ((660)),
// 'VENKAT',
// CLASS=A,
// MSGCLASS=A,
// TIME=1440,NOTIFY=&SYSUID
//*
//STEP1EXEC PGM=GIMSMP,REGION=6M,
// TIME=120
//SMPCSI   DD  DSN=SMPE.GLOBAL.CSI,
// DISP=SHR
//SMPHOLD  DD  DUMMY
//SMPOUT   DD  SYSOUT=*
//SMPRPT   DD  SYSOUT=*
//SYSPRINT DD  SYSOUT=*,DCB=(LRECL=133,BLKSIZE=2660,RECFM=FB)
//SMPCNTL  DD  *
 SET BDY(GLOBAL) .
 RECEIVE S(UM21001) .
 SET BDY(MVST100) .
  APPLY CHECK S(UM21001) REDO .
/*
//SMPPTFIN DD  DATA,DLM='%%'
++USERMOD(UM21001)  REWORK(2014034)   .
++VER(Z038) FMID(HRF7790) PRE(CPPDSNT) .
++JCLIN .
//UM21001 JOB MVSSP121
//ICHRDSNT EXEC PGM=IEWL,
// PARM='LIST,LET,XREF,NCAL'
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD UNIT=3390,SPACE=(CYL,(1,1))
//SYSLMOD DD DSN=Z.LINKLIB,DISP=SHR
//SYSLIN DD *
 INCLUDE SYSLMOD(ICHRDSNT)
 ENTRY ICHRDSNT
 NAME ICHRDSNT(R)
/*
++SRC(ICHRDSNT) DISTLIB(AORASRC) DISTMOD(ALINKLIB) .
 ICHRDSNT CSECT
  DCAL1(1)   # PRIMARY RACF DATASETS
  DCCL44'SYS1.RACFP'  NAME OF PRIMARY
  DCCL44'SYS1.RACFB'   NAME OF BACKUP
  DCAL1(255) # RESIDENT BLOCKS (ONE TRACK)
  DCX'80'UPDATES DUPLICATED ON BACKUP D
  END
 %%
 //

 APPLY CHECK S(UM21001) REDO .

GIM40501E ** THE DISTLIB VALUE (ALINKLIB) SPECIFIED FOR MOD ICHRDSNT IN
SYSMOD
 SP21001 DOES NOT MATCH THE DISTLIB VALUE (AOSBN) IN THE MOD
ENTRY
 FOR ICHRDSNT.
GIM22601IAPPLY PROCESSING FAILED FOR SYSMOD UM21001.
GIM20501IAPPLY PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 08.

I am not able to find hint to solve this issue. Can anybody help me on 
this.


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

Re: Dummy dataset

[Shmuel Metz (Seymour J.)]

In <5284287024729817.wa.paulgboulderaim@listserv.ua.edu>, on
02/04/2014
   at 07:37 AM, Paul Gilmartin  said:

>Is the UCB address nonzero for zFS files? 

The UCB address in the TIOT entry is zero for anything not allocated
to a device; that includes not only Unix files but also subsytem files
and TSO terminals. Back in the day it also included TCAM. There are
flag bits in, e.g., TIOELINK, to determine who did what to whom.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: RACF USERMOD APPLY

[Shmuel Metz (Seymour J.)]

In <00c801cf21bf$365935c0$a30ba140$@mindspring.com>, on 02/04/2014
   at 08:38 AM, Lizette Koehler  said:

>I need to correct the manual I cited.  It was for OS/390 V2.1

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

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

Re: Orphaned VVR

[Shmuel Metz (Seymour J.)]

In
,
on 02/04/2014
   at 02:01 PM, Mike Schwab  said:

>What do we need to do to clean this up.

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

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

Re: Assembler code

[Shmuel Metz (Seymour J.)]

In <6453954597906023.wa.ron5174gmail@listserv.ua.edu>, on
02/04/2014
   at 11:22 AM, Ron Thomas  said:

>Ok Thanks .so what would be o/p of this statement "TRBIT,TR@TAB "
>here ? 

How high is up? Nobody can answer your question until you say what BIT
and TR@TAB are.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Assembler code

[Shmuel Metz (Seymour J.)]

In <2073666706692890.wa.ron5174gmail@listserv.ua.edu>, on
02/04/2014
   at 08:18 AM, Ron Thomas  said:

>I am new to assembler, so not sure i am pharsing the query correctly.

Download and read Principles of Operation.

>In the attached code whether if the ITMAP bit is on for a memory
>location, then after executing the below code is it going to be
>turned off.? 

An exclusive or with zero is a no-op, other than setting the condition
code. OTOH, if you used an Execute instruction on XI@TM then the
result would depend on the register contents.

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

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

Re: Assembler code

[Bernd Oppolzer]

The OP attached the complete source code of his module
with his first mail.


Am 05.02.2014 00:29, schrieb Shmuel Metz (Seymour J.):

In <6453954597906023.wa.ron5174gmail@listserv.ua.edu>, on
02/04/2014
at 11:22 AM, Ron Thomas  said:


Ok Thanks .so what would be o/p of this statement "TRBIT,TR@TAB "
here ?

How high is up? Nobody can answer your question until you say what BIT
and TR@TAB are.
  


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

Re: Assembler code

[Bernd Oppolzer]

To make my point more clear:

I guess that the FORCEONE code section is planned to
FORCE the bit identified by the input parameters to ONE - that's
what the name says.

But what it really does: it puts a one bit in the correct position for
the relevant target bit and issues an XI instruction on this target bit.

So:

the bit there is INVERTED, not FORCED to ONE.

Could it be that you examine this code section, because you observed
some misbehaving of this code section?

Well: here is the explanation. The coder mixed up XI and OI.

Kind regards

Bernd



Am 04.02.2014 20:38, schrieb Bernd Oppolzer:

I would like to add that the name of the code section and the comment
both are misleading, IMO.

The name of the code section is FORCEONE. If the bit really is forced
to one, the instruction executed should be OI, not XI.

And the comment says that a TM will be executed, but there is no TM.

I have the impression that this code section has been copied several
times; the instruction that is executed has been changed, but the
comments stayed the same. FORCEONE will only be OK, if the target
bit was zero before, otherwise it will change from one to zero, which
is not what the name FORCEONE makes us believe.

Kind regards

Bernd



Am 04.02.2014 20:27, schrieb Bernd Oppolzer:

The TR translates a bit position in the range 0 to 7
to the appropriate bit mask, that is

0 is translated to B'1000'
1 to B'0100'
2 to B'0010'
3 to B'0001'

and so on

So the XI inverts the bit that is specified by those two parameters
on entry to the procedure:

 ZAP   BYTE,T@SAVE(7)  QUOTIENT IS BYTE DISPLACEMENT. 
* 0910
 ZAP   BIT,T@SAVE+7(1) REMAINDER IS BIT DISPLACEMENT. 
* 0920


Kind regards

Bernd



Am 04.02.2014 18:22, schrieb Ron Thomas:
Ok Thanks .so what would be o/p of this statement "TRBIT,TR@TAB 
" here ?


Thanks,
Ron T

--
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: JESGB400/IEFGB400

[SUBSCRIBE IBM-MAIN Harold Gray]

Thanks Tony, 

I'm coming to that conclusion also.  I can't seem to get the 2.1 data areas vol 
4 (JESCT) to download the whole book so I'll have to wait and try it again 
later.

I don't think any of these pointers were ever part of the Programming Interface 
so I'll have to come up with another way to determine if a NOT CATLGD 2 
occurred.  

Thanks again for your help.

Harold

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

Re: JESGB400/IEFGB400

[Ed Jaffe]

On 2/4/2014 3:51 PM, SUBSCRIBE IBM-MAIN Harold Gray wrote:

I'm coming to that conclusion also.  I can't seem to get the 2.1 data areas vol 
4 (JESCT) to download the whole book so I'll have to wait and try it again 
later.


Both pointers are present in the z/OS 2.1 version of IEFJESCT.

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: JESGB400/IEFGB400

[Tony Harminc]

On 4 February 2014 19:12, Ed Jaffe  wrote:
> On 2/4/2014 3:51 PM, SUBSCRIBE IBM-MAIN Harold Gray wrote:
>>
>> I'm coming to that conclusion also.  I can't seem to get the 2.1 data
>> areas vol 4 (JESCT) to download the whole book so I'll have to wait and try
>> it again later.
>
>
> Both pointers are present in the z/OS 2.1 version of IEFJESCT.

Sure, but the OP says the routine doesn't seem to be getting called.
And they are certainly not GUPI, or even anything-PI.

Tony H.

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

Re: RACF USERMOD APPLY

[venkat kulkarni]

Thanks for all reply. For now I modified my JCL  to point from
DISTMOD(ALINKLIB) to  DISTMOD(AOSBN) and it worked for me .Now I can see
updated ICHRDSNT  module in SYS1.LINKIB having new RACF DB and I IPL'd
system to take it effect.

Thanks for all help once again.




On Wed, Feb 5, 2014 at 4:54 AM, Shmuel Metz (Seymour J.) <
shmuel+ibm-m...@patriot.net> wrote:

> In <00c801cf21bf$365935c0$a30ba140$@mindspring.com>, on 02/04/2014
>at 08:38 AM, Lizette Koehler  said:
>
> >I need to correct the manual I cited.  It was for OS/390 V2.1
>
> ?
>
> --
>  Shmuel (Seymour J.) Metz, SysProg and JOAT
>  ISO position; see 
> We don't care. We don't have to care, we're Congress.
> (S877: The Shut up and Eat Your spam act of 2003)
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to 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: JESGB400/IEFGB400

[Jim Mulder]

> I have not reassembled as the pointers and offsets have not changed.
> There are no abends and I know the code is not being called.  As far
> as I know all system messages are still coming out. I have a 
> development system and I've set the code to abend if it gets called 
> and nothing happens.
> 
> Our routine is looking for IEF287I messages to detect C'NOT CATLGD 
> 2' messages.  We hook ourselves in front of the IBM routine and then
> branch to the original code once we've noted the NOT CATLGD 2 to our
> system. When I look at my job that tests the NOT CATLGD 2, there are
> two sets of messages dealing with this issue.  In the JOBLOG, the 
> following message comes out:
> IEF377I NOTCAT2 STEP6  440 
> OPS.NOTCAT2.TEST4 NOT CATLGD 2 
> In the MSGLOG the following message comes out:
> IEF287I   OPS.NOTCAT2.TEST4NOT CATLGD  2
> (this is the one we've always looked for).
> I first thought the change was that IEF377I replaced the IEF287I and
> I changed the routine to look for either but I still didn't get my 
> notification so I changed the code to abend to make sure it was 
> getting called (development so hard abends would not be a problem) 
> but everything works fine - except I don't get called which also 
> means the original IEFGB400 program wouldn't have been called either.
> 
> I am looking for why the JESGB400/IEFGB400 isn't being called (JES 
> or SYSTEM parmlib parameter??) or what replaced that message 
> processor. I'm not sure how to setup a trap when it doesn't look 
> like the JESGB400 pointer is being used at all.

  IEFGB400 is a tiny module located below the 16MB line which
does nothing but issue a PUT macro in 24-bit addressing mode.
It created in the days when PUT could not be called in
31-bit addressing mode.  That restriction being long gone,
the allocation message module was changed in z/OS 1.10 to
do its PUT directly, instead of calling IEFGB400.  So your
method of modifying JESGB400 in order to intercept allocation
joblog messages will no longer work, as of z/OS 1.10. 



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

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