z13s information

[גדי בן אבי]

https://www-03.ibm.com/systems/z/hardware/z13s.html


לשימת לבך, בהתאם לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או חברה קשורה שלה 
(להלן : "החברה") וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, 
מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או 
שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף 
להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין 
להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.

Please note that in accordance with Malam and/or its subsidiaries (hereinafter 
: "Malam") regulations and signatory rights, no offer, agreement, concession or 
representation is binding on the Malam, unless accompanied by a duly signed 
separate document (or a scanned version thereof), affixed with the Malam seal.

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

IBM z13s article.

[Mike Schwab]

http://www.pcworld.com/article/3033464/ibm-unveils-z13s-mainframe-focused-on-security-and-hybrid-clouds.html
N10 with 1TB or N20 with 4TB.

-- 
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: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

[Itschak Mugzach]

Did you oonsider responding with an automation tool and save your fingers?
this is a well defined case where automation can help...

ITschak

ITschak Mugzach
Z/OS, ISV Products and Application Security & Risk Assessments Professional

On Mon, Feb 15, 2016 at 10:30 PM, Joe Aulph  wrote:

> In previous and current assignments I have, in test, destroyed a DB and
> attempted an IPL, after 45 minutes of bleeding-finger console responses we
> gave up and IPL'd off a good DB.
> We have forced the DB offline, fail soft testing, and after 50-70 console
> responses were able to get 1 TSO user logged on via UADS.
> Then there was the day I cam into the office and my DB was GONE! Only
> because I had a recent backup on an available volume, and a handy IBM tech
> (thank you Russ) we had no real outage and lost only 4 hours of password
> updates.
> All  of which underscores the point, you want a dozen different options
> before you are forced to use UADS, and an on-line available copy of the DB
> is a life saver.
>
> Cheers,
> Joe
>
> On Mon, Feb 15, 2016 at 9:09 AM, John Eells  wrote:
>
> > I would not want to run with such an MPF exit or AUTORxx member active in
> > production.  You can have it there for emergencies and activate it with a
> > SET command.  This keeps the pain level of failsoft mode a lot more
> > tolerable.  We used to have a couple of such exits waiting in the wings
> for
> > recovery to automate operator approvals during system recovery, though at
> > this point I can't recall specifically for what other messages they
> > automated the responses.
> >
> > I absolutely agree with those who express a preference for a one-pack
> > recovery system, by the way.  But I'm a belt-and-suspenders kind of guy
> and
> > would still want one more last-ditch recovery option.
> >
> >
> > Skip Robinson wrote:
> >
> >> This problem occurs so seldom that I never thought of automating a
> >> response. As of R12 or so, we now have AUTORxx, which can reply to WTORs
> >> very early in the IPL. Not sure who here would have to approve such a
> >> change. The chances of mischief being perpetrated are minimal, but it
> does
> >> open a very small window for a clever miscreant.
> >>
> >> .
> >> .
> >> .
> >> J.O.Skip Robinson
> >> Southern California Edison Company
> >> Electric Dragon Team Paddler
> >> SHARE MVS Program Co-Manager
> >> 323-715-0595 Mobile
> >> jo.skip.robin...@att.net
> >>
> >>
> >> -Original Message-
> >>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> >>> On Behalf Of Ed Jaffe
> >>> Sent: Sunday, February 14, 2016 07:37 AM
> >>> To: IBM-MAIN@LISTSERV.UA.EDU
> >>> Subject: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)
> >>>
> >>> On 2/13/2016 8:04 PM, Skip Robinson wrote:
> >>>
>  This opinion is based on (thankfully) limited experience. If you are
>  forced to IPL without a usable RACF data base, you are totally
>  scr*wed. During IPL, operator will be prompted to allow even READ
>  access to *every* data set opened by *every* task except for a tiny
>  handful like JES that bypass integrity. By the time you get to the
>  point of actually logging on to TSO, operator's fingers will be
>  bleeding profusely. If at any time during this process, you are
>  god-forbid required to start over, yet more finger tips will have to
>  sacrificed.
> 
> >>>
> >>> We solved this with an MPF exit that would always reply 'Y' to each of
> >>> those
> >>> prompts (except for the first few IIRC).
> >>>
> >> 
> >
> > --
> > John Eells
> > IBM Poughkeepsie
> > ee...@us.ibm.com
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> 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: Query: Will modern z/OS and z/VM classes suffice for MVS and VM/370

[Mike Schwab]

I heavily recommend signing up for the Hercules yahoo groups for
installing VM/370, MVS 3.8, DOS/VS, Music, PDOS, MVT 21.8F with
APL\360, etc.  Yes, they have been working on emulators, but using
these versions of software.  They even have install tape images and
scripts to load empty volumes.

http://www.jaymoseley.com/hercules/installMVS/install.htm
MVS 3.7 starter system then build 3.8.

http://www.bsp-gmbh.com/turnkey/
http://www.bsp-gmbh.com/turnkey/cookbook/
Turnkey 3 CD-ROM with MVS 3.8J.  The Hercules on the CD-Rom is quite old.

http://mvs380.sourceforge.net/ Turnkey 3 MVS 3.8J with 31 bit
extensions so GCC can recompile itself.  Of course the extentions
won't work on real hardware, but just skip the enabling instruction.

http://wotho.ethz.ch/tk4-/ Turnkey 3 with cleanups and improvements
without the 31 bit changes for GCC.

So, pick one, install on hercules, xmit370 to disk files, download to
PC, load up to your disks.

How will you install your starter system?

On Mon, Feb 15, 2016 at 8:42 PM, Anne & Lynn Wheeler  wrote:
> ri...@livingcomputermuseum.org (Rich Alderson) writes:
>> We are currently in the process of restoring a 4341 to operating
>> condition.  We have just last week corrected a fault in the power
>> system, and are able to power the system up and IML it from floppy.
>>
>> We are now deciding what operating system to run on the restored
>> system.  Most likely, we will run VM/370, but possibly we will run an
>> MVS guest as well.  I used to be an MVS systems programmer, but that
>> was more than 30 years ago, and even the rust has eroded away.
>>
>> I would like to brush up on operations and systems programming, which
>> would be much simpler if a modern z/OS and/or z/VM course would
>> suffice for the older operating systems.  Have the operator commands
>> and programming utilities changed radically since 1984 (JES2, CMS)?
>>
>> Please feel free to reply privately if you wish to tell me how foolish this 
>> sounds.
>>
>> Thanks,
>> Rich Alderson
>
>
> Hercules comes with 4341 era vm370
> https://en.wikipedia.org/wiki/Hercules_%28emulator%29
>
> vast majority of 4341s were shipped with FBA disks ... you would need
> some sort of CKD disks in order to bring up MVS.
>
> huge percentage of 4341s went out into departmental areas with 3370 FBA
> disks, sort of leading edge of distributed computing tsunami ... not
> requiring datacenter provisioning.
>
> --
> 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



-- 
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: Query: Will modern z/OS and z/VM classes suffice for MVS and VM/370

[David L. Craig]

On 16Feb15:1842-0800, Anne & Lynn Wheeler wrote:

> vast majority of 4341s were shipped with FBA disks ... you would need
> some sort of CKD disks in order to bring up MVS.
> 
> huge percentage of 4341s went out into departmental areas with 3370 FBA
> disks, sort of leading edge of distributed computing tsunami ... not
> requiring datacenter provisioning.

My shop must have been the first.  My SE and I were in the
WSC after midnight using blocktime to preconfigure VM with
BSEPP for our 4341 still a month out or so.  Only the media
wouldn't load.  The SE got on the phone--I never got to say
a word.  It turned out B was never able to test the FBA
media because they didn't have any FBAs yet--my SE and I
were the first to try it.  He was orders of magnitude more
upset than I was.
-- 

May the LORD God bless you exceedingly abundantly!

Dave_Craig__
"So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe."
__--from_Nightfall_by_Asimov/Silverberg_

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

Re: SMPE: Un-ACCEPTing USERMOD

[Bruce Hewson]

Hi,

Thanks for the responses.

The ACCEPT occurred by accident (I am assuming) in 2013.

Haven't fully scoped if I can recreate the whole DLIB zone from scratch, but my 
expectation is low probability of success due missing MCS.

The "canned" dialog will not permit generation of ACCEPT code these days, so 
future failure of process should be minimal.

Thanks again for assistance.

Bruce Hewson

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

Re: Query: Will modern z/OS and z/VM classes suffice for MVS and VM/370

[Anne & Lynn Wheeler]

ri...@livingcomputermuseum.org (Rich Alderson) writes:
> We are currently in the process of restoring a 4341 to operating
> condition.  We have just last week corrected a fault in the power
> system, and are able to power the system up and IML it from floppy.
>
> We are now deciding what operating system to run on the restored
> system.  Most likely, we will run VM/370, but possibly we will run an
> MVS guest as well.  I used to be an MVS systems programmer, but that
> was more than 30 years ago, and even the rust has eroded away.
>
> I would like to brush up on operations and systems programming, which
> would be much simpler if a modern z/OS and/or z/VM course would
> suffice for the older operating systems.  Have the operator commands
> and programming utilities changed radically since 1984 (JES2, CMS)?
>
> Please feel free to reply privately if you wish to tell me how foolish this 
> sounds.
>
> Thanks,
> Rich Alderson


Hercules comes with 4341 era vm370
https://en.wikipedia.org/wiki/Hercules_%28emulator%29

vast majority of 4341s were shipped with FBA disks ... you would need
some sort of CKD disks in order to bring up MVS.

huge percentage of 4341s went out into departmental areas with 3370 FBA
disks, sort of leading edge of distributed computing tsunami ... not
requiring datacenter provisioning.

-- 
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: Query: Will modern z/OS and z/VM classes suffice for MVS and VM/370

[Clark Morris]

On 15 Feb 2016 18:24:12 -0800, in bit.listserv.ibm-main you wrote:

>We are currently in the process of restoring a 4341 to operating condition.  
>We have just last week corrected a fault in the power system, and are able to 
>power the system up and IML it from floppy.
>
>We are now deciding what operating system to run on the restored system.  Most 
>likely, we will run VM/370, but possibly we will run an MVS guest as well.  I 
>used to be an MVS systems programmer, but that was more than 30 years ago, and 
>even the rust has eroded away.


You could always run MVT release 21.8.  Just gen it as 158.  I'll try
to remember more details from when I did it back in the 1980s due to a
flooded out 360/65.  War story available without much prompting. Brush
up on unit control words for your peripherals regardless of operating
system.

Clark Morris 
>I would like to brush up on operations and systems programming, which would be 
>much simpler if a modern z/OS and/or z/VM course would suffice for the older 
>operating systems.  Have the operator commands and programming utilities 
>changed radically since 1984 (JES2, CMS)?
>
>Please feel free to reply privately if you wish to tell me how foolish this 
>sounds.
>
>Thanks,
>Rich Alderson
>
>
>Rich Alderson
>Sr. Systems Engineer
>Living Computer Museum
>2245 1st Ave S
>Seattle, WA 98134
>
>
>http://www.LivingComputerMuseum.org/
>
>
>
>--
>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

Query: Will modern z/OS and z/VM classes suffice for MVS and VM/370

[Rich Alderson]

We are currently in the process of restoring a 4341 to operating condition.  We 
have just last week corrected a fault in the power system, and are able to 
power the system up and IML it from floppy.

We are now deciding what operating system to run on the restored system.  Most 
likely, we will run VM/370, but possibly we will run an MVS guest as well.  I 
used to be an MVS systems programmer, but that was more than 30 years ago, and 
even the rust has eroded away.

I would like to brush up on operations and systems programming, which would be 
much simpler if a modern z/OS and/or z/VM course would suffice for the older 
operating systems.  Have the operator commands and programming utilities 
changed radically since 1984 (JES2, CMS)?

Please feel free to reply privately if you wish to tell me how foolish this 
sounds.

Thanks,
Rich Alderson


Rich Alderson
Sr. Systems Engineer
Living Computer Museum
2245 1st Ave S
Seattle, WA 98134


http://www.LivingComputerMuseum.org/



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

Default overrides for binder?

[Frank Swarbrick]

The assembler has the ASMAOPT macro to build the ASMADOPT CSECT containing the 
shop defaults for HLASM.  COBOL has the  IGYCOPT macro to build the IGYCDOPT 
CSECT containing the shop defaults for COBOL. There does not appear to be 
anything similar for the binder.  Am I overlooking it?  (I know about using the 
PARM and/or IEWPARMS DD or OPTIONS(ddname) to override the defaults).

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

Re: Reading the CA-1 Tape Catalog

[Tim Hare]

The BUFNO= is only needed if you did _not_ increase the block size of your TMC 
(available in latest releases, along with other improvements to the TMC 
including uptime improvements like allowing online extension of a TMC in use by 
multiple systems.. Thanks, CA! - I'm retired and only 'consulting' now but 
those were great changes when I used them).

Also - to the original poster - be sure to check the ACCODE/RETPD in the JCL,  
and whether or not you have an RPGDG parameter coded in  TMOOPTxx.   It sounds 
like you're not expiring the datasets in CA-1 when they roll off the GDG.

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

Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

[Joe Aulph]

In previous and current assignments I have, in test, destroyed a DB and
attempted an IPL, after 45 minutes of bleeding-finger console responses we
gave up and IPL'd off a good DB.
We have forced the DB offline, fail soft testing, and after 50-70 console
responses were able to get 1 TSO user logged on via UADS.
Then there was the day I cam into the office and my DB was GONE! Only
because I had a recent backup on an available volume, and a handy IBM tech
(thank you Russ) we had no real outage and lost only 4 hours of password
updates.
All  of which underscores the point, you want a dozen different options
before you are forced to use UADS, and an on-line available copy of the DB
is a life saver.

Cheers,
Joe

On Mon, Feb 15, 2016 at 9:09 AM, John Eells  wrote:

> I would not want to run with such an MPF exit or AUTORxx member active in
> production.  You can have it there for emergencies and activate it with a
> SET command.  This keeps the pain level of failsoft mode a lot more
> tolerable.  We used to have a couple of such exits waiting in the wings for
> recovery to automate operator approvals during system recovery, though at
> this point I can't recall specifically for what other messages they
> automated the responses.
>
> I absolutely agree with those who express a preference for a one-pack
> recovery system, by the way.  But I'm a belt-and-suspenders kind of guy and
> would still want one more last-ditch recovery option.
>
>
> Skip Robinson wrote:
>
>> This problem occurs so seldom that I never thought of automating a
>> response. As of R12 or so, we now have AUTORxx, which can reply to WTORs
>> very early in the IPL. Not sure who here would have to approve such a
>> change. The chances of mischief being perpetrated are minimal, but it does
>> open a very small window for a clever miscreant.
>>
>> .
>> .
>> .
>> J.O.Skip Robinson
>> Southern California Edison Company
>> Electric Dragon Team Paddler
>> SHARE MVS Program Co-Manager
>> 323-715-0595 Mobile
>> jo.skip.robin...@att.net
>>
>>
>> -Original Message-
>>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>>> On Behalf Of Ed Jaffe
>>> Sent: Sunday, February 14, 2016 07:37 AM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)
>>>
>>> On 2/13/2016 8:04 PM, Skip Robinson wrote:
>>>
 This opinion is based on (thankfully) limited experience. If you are
 forced to IPL without a usable RACF data base, you are totally
 scr*wed. During IPL, operator will be prompted to allow even READ
 access to *every* data set opened by *every* task except for a tiny
 handful like JES that bypass integrity. By the time you get to the
 point of actually logging on to TSO, operator's fingers will be
 bleeding profusely. If at any time during this process, you are
 god-forbid required to start over, yet more finger tips will have to
 sacrificed.

>>>
>>> We solved this with an MPF exit that would always reply 'Y' to each of
>>> those
>>> prompts (except for the first few IIRC).
>>>
>> 
>
> --
> John Eells
> IBM Poughkeepsie
> ee...@us.ibm.com
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Would ISGQUERY be the proper Service

[esst...@juno.com]

Thanks Leo,

-- Original Message --
From: Leonardo Vaz 
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Would ISGQUERY be the proper Service
Date: Mon, 15 Feb 2016 16:21:12 +

ISGQUERY should work for what you are attempting, the following simple test 
worked fine for me to show the first job enqueueing the dataset:

 OPEN  (SYSPRINT,(OUTPUT))
 STORAGE OBTAIN,ADDR=(R10),LENGTH=4096
 ISGQUERY REQINFO=QSCAN,SCANACTION=START,  X
   ANSAREA=(R10),ANSLEN=4096,ANSDETAIL=FULL2,  X
   SEARCH=BY_FILTER,QNAMEMATCH=SPECIFIC,QNAME==CL8'SYSDSN',X
   RNAMEMATCH=PATTERN,RNAMELEN=12, X
   RNAME==CL12'SYS1.PARMLIB',  X
   RETCODE=LRETCODE,RSNCODE=LRSNCODE
 USING ISGYQUAAHDR,R10
 L R9,ISGYQUAAHDRFIRSTRECORD31
 USING ISGYQUAARS,R9
 L R8,ISGYQUAARSFIRSTRQ31
 USING ISGYQUAARQ,R8
 L R7,ISGYQUAARQRQX31
 USING ISGYQUAARQX,R7
 PUT   SYSPRINT,ISGYQUAARQXJOBNAME
 STORAGE RELEASE,ADDR=(R10),LENGTH=4096
 CLOSE (SYSPRINT)

As John McKown has stated, maybe use SYSVSAM instead of SYSDSN.

Regards,
Leo

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of esst...@juno.com
Sent: Sunday, February 14, 2016 5:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Would ISGQUERY be the proper Service

Hello,
.
I have a Started Task (STC), and sometimes a another job will hold a VSAM 
dataset needed by this STC. This prevents the STC from properly re-opening the 
dataset.
.
The VSAM datasets are defined with Share Options are 2,3 and Transactional VSAM 
(RLS) is not an option.
.
.
Im looking for a z/OS macro or callable service that will allow the Started 
Task to identify the name of the other job that has opened a VSAM dataset which 
the Started Task needs. 
.
.
I started reading the description of the ISGQUERY and its various Mapping 
Macros but I dont see where it would returns the name of a batch job that has 
allocated the dataset. 
.
I suspect I would use GATHERFROM=SYSTEM  with SCOPE=SYSTEM, since the batch 
processing occurs on the same LPAR as the Started Task.

Is ISGQUERY the proper macro/service to accomplish this ?
.
Would someone provide some sample code and point me to the proper macro/service 
to invoke to accomplish this.
.
.
The Started Task happens to be a CICS Address Space and we would use a standard 
CICS Supplied Open Exit to drive this.
.
.
Paul
*
*

--
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: Issues with VSAM Enqueuers and Batch job with IDCAMS

[Charles Mills]

I think Lizette said the problem is fleeting. By the time you know you have
the problem ... it's gone.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Pinnacle
Sent: Monday, February 15, 2016 10:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Issues with VSAM Enqueuers and Batch job with IDCAMS


Lizette,

Run the GRS Monitor, you'll get your answer.

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

Re: Issues with VSAM Enqueuers and Batch job with IDCAMS

[Pinnacle]

On 2/15/2016 11:52 AM, Lizette Koehler wrote:

I have an issue where an STC holds a VSAM Dataset.  The STC is a scheduling
software that writes all of the info on jobs running/completed/failed and so
forth, to this file.

Once per day we close and free the VSAM file from the STC, run an archive
process and then re-open then file to the STC.

This works nearly all of the time.  However, on occasion (a couple times a year)
the job will fail in the IDCAMS Step with DATASET IN USE BY ANOTHER TASK
message.  The enq is so fast, I do not have any indication of what was holding
it.
The IDCAMS Step reloads the history file with the last 3 days' worth of
information about jobs.  It is a very simple
REPO IFILE(x) OFILE(y)


I opened an SR to IBM DFSMS and asked if they could add some checks in IDCAMS
for the nonzero return code from the enq and let me know what job is using it.
They indicated that extra code path to do that would not help.  They felt that
the enq is released so soon the extra test for the enqueue would not provide the
name of the task.

I have looked at RMF reports - I could see nothing.
I have looked at DAF reports for the 5 min time frame - I could see nothing.
When the step fails with RC12, I do the D GRS,C and nothing shows up.
I am tempted to start the ISG Monitor for Enqueues for the 15 minute window when
this job runs.



Lizette,

Run the GRS Monitor, you'll get your answer.

Regards,
Tom Conley

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

Re: Issues with VSAM Enqueuers and Batch job with IDCAMS

[Steve Thompson]

On a completely different tack:

What if you defined the VSAM file as ESDS, and used an AIX and PATH?

Would you still need to sort the data? Would this give you the 
speed and efficiency you need and possibly solve this issue?


The only splits you would get would be in the AIX. And you could 
do the whole process of repro, delete, define, repro in a single 
JOB where you could do a RESTART= should it fail.


Just wondering if this would make for a single JOB to do it all 
and provide other efficiencies.


Regards,
Steve Thompson

On 02/15/2016 12:42 PM, Lizette Koehler wrote:

So, the step previous is a DFSORT Step.  Then the IDCAMS REPRO step

The SYSS.HISTTEMP.BKUP is the data that will be reloaded back into the
SYSS.HISTFILE.  The sort step is just to put the records in correct sequence
before reloading.


//STEP1G   EXEC PGM=SORT,COND=(0,LT)
//SORTIN   DD   DSN=SYSS.HISTTEMP.BACKUP,DISP=SHR
//SORTOUT  DD   DSN=SYSS.HISTTEMP.BKUP,DISP=SHR
//SYSOUT   DD   SYSOUT=*
   (sort statements removed)
/*
//STEP1H   EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSINDD *
REPRO IDS(SYSS.HISTTEMP.BKUP)-
   ODS(SYSS.HISTFILE) REUSE


As I stated, this runs 99% successfully.  Just one or two times a year does it
get the message in use by another task.


Lizette




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Leonardo Vaz
Sent: Monday, February 15, 2016 10:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Issues with VSAM Enqueuers and Batch job with IDCAMS

How is that VSAM file allocated on your repro step? DISP=OLD or DISP=SHR?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Lizette Koehler
Sent: Monday, February 15, 2016 11:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Issues with VSAM Enqueuers and Batch job with IDCAMS

I have an issue where an STC holds a VSAM Dataset.  The STC is a scheduling
software that writes all of the info on jobs running/completed/failed and so
forth, to this file.

Once per day we close and free the VSAM file from the STC, run an archive
process and then re-open then file to the STC.

This works nearly all of the time.  However, on occasion (a couple times a
year) the job will fail in the IDCAMS Step with DATASET IN USE BY ANOTHER TASK
message.  The enq is so fast, I do not have any indication of what was holding
it.
The IDCAMS Step reloads the history file with the last 3 days' worth of
information about jobs.  It is a very simple REPO IFILE(x) OFILE(y)


I opened an SR to IBM DFSMS and asked if they could add some checks in IDCAMS
for the nonzero return code from the enq and let me know what job is using it.
They indicated that extra code path to do that would not help.  They felt that
the enq is released so soon the extra test for the enqueue would not provide
the name of the task.

I have looked at RMF reports - I could see nothing.
I have looked at DAF reports for the 5 min time frame - I could see nothing.
When the step fails with RC12, I do the D GRS,C and nothing shows up.
I am tempted to start the ISG Monitor for Enqueues for the 15 minute window
when this job runs.

If we rerun the job it is successful.

Anyone have any other ideas to try and trap this rascally rabbit?



Lizette Koehler
statistics: A precise and logical method for stating a half-truth inaccurately


--
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: Issues with VSAM Enqueuers and Batch job with IDCAMS

[Leonardo Vaz]

Ok, so you are doing a REPRO ODS, not OFILE, like you had stated, I would try 
to have the VSAM file allocated with DISP=OLD and doing the repro OFILE, I 
believe that should guarantee you don't get the "DATASET IN USE BY ANOTHER 
TASK" message.

Considering you free the dataset from the CICS region, you should be able to 
DISP=OLD it.

Regards,
Leo

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Monday, February 15, 2016 12:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Issues with VSAM Enqueuers and Batch job with IDCAMS

So, the step previous is a DFSORT Step.  Then the IDCAMS REPRO step

The SYSS.HISTTEMP.BKUP is the data that will be reloaded back into the 
SYSS.HISTFILE.  The sort step is just to put the records in correct sequence 
before reloading.

   
//STEP1G   EXEC PGM=SORT,COND=(0,LT)  
//SORTIN   DD   DSN=SYSS.HISTTEMP.BACKUP,DISP=SHR 
//SORTOUT  DD   DSN=SYSS.HISTTEMP.BKUP,DISP=SHR 
//SYSOUT   DD   SYSOUT=*  
  (sort statements removed)
/*
//STEP1H   EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSINDD *
REPRO IDS(SYSS.HISTTEMP.BKUP)-
  ODS(SYSS.HISTFILE) REUSE


As I stated, this runs 99% successfully.  Just one or two times a year does it 
get the message in use by another task.


Lizette



> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Leonardo Vaz
> Sent: Monday, February 15, 2016 10:05 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Issues with VSAM Enqueuers and Batch job with IDCAMS
> 
> How is that VSAM file allocated on your repro step? DISP=OLD or DISP=SHR?
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Lizette Koehler
> Sent: Monday, February 15, 2016 11:53 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Issues with VSAM Enqueuers and Batch job with IDCAMS
> 
> I have an issue where an STC holds a VSAM Dataset.  The STC is a 
> scheduling software that writes all of the info on jobs 
> running/completed/failed and so forth, to this file.
> 
> Once per day we close and free the VSAM file from the STC, run an 
> archive process and then re-open then file to the STC.
> 
> This works nearly all of the time.  However, on occasion (a couple 
> times a
> year) the job will fail in the IDCAMS Step with DATASET IN USE BY 
> ANOTHER TASK message.  The enq is so fast, I do not have any 
> indication of what was holding it.
> The IDCAMS Step reloads the history file with the last 3 days' worth 
> of information about jobs.  It is a very simple REPO IFILE(x) OFILE(y)
> 
> 
> I opened an SR to IBM DFSMS and asked if they could add some checks in 
> IDCAMS for the nonzero return code from the enq and let me know what job is 
> using it.
> They indicated that extra code path to do that would not help.  They 
> felt that the enq is released so soon the extra test for the enqueue 
> would not provide the name of the task.
> 
> I have looked at RMF reports - I could see nothing.
> I have looked at DAF reports for the 5 min time frame - I could see nothing.
> When the step fails with RC12, I do the D GRS,C and nothing shows up.
> I am tempted to start the ISG Monitor for Enqueues for the 15 minute 
> window when this job runs.
> 
> If we rerun the job it is successful.
> 
> Anyone have any other ideas to try and trap this rascally rabbit?
> 
> 
> 
> Lizette Koehler
> statistics: A precise and logical method for stating a half-truth 
> inaccurately

--
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: Issues with VSAM Enqueuers and Batch job with IDCAMS

[Lizette Koehler]

So, the step previous is a DFSORT Step.  Then the IDCAMS REPRO step

The SYSS.HISTTEMP.BKUP is the data that will be reloaded back into the
SYSS.HISTFILE.  The sort step is just to put the records in correct sequence
before reloading.

   
//STEP1G   EXEC PGM=SORT,COND=(0,LT)  
//SORTIN   DD   DSN=SYSS.HISTTEMP.BACKUP,DISP=SHR 
//SORTOUT  DD   DSN=SYSS.HISTTEMP.BKUP,DISP=SHR 
//SYSOUT   DD   SYSOUT=*  
  (sort statements removed)
/*
//STEP1H   EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSINDD *
REPRO IDS(SYSS.HISTTEMP.BKUP)-
  ODS(SYSS.HISTFILE) REUSE


As I stated, this runs 99% successfully.  Just one or two times a year does it
get the message in use by another task.


Lizette



> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Leonardo Vaz
> Sent: Monday, February 15, 2016 10:05 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Issues with VSAM Enqueuers and Batch job with IDCAMS
> 
> How is that VSAM file allocated on your repro step? DISP=OLD or DISP=SHR?
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Monday, February 15, 2016 11:53 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Issues with VSAM Enqueuers and Batch job with IDCAMS
> 
> I have an issue where an STC holds a VSAM Dataset.  The STC is a scheduling
> software that writes all of the info on jobs running/completed/failed and so
> forth, to this file.
> 
> Once per day we close and free the VSAM file from the STC, run an archive
> process and then re-open then file to the STC.
> 
> This works nearly all of the time.  However, on occasion (a couple times a
> year) the job will fail in the IDCAMS Step with DATASET IN USE BY ANOTHER TASK
> message.  The enq is so fast, I do not have any indication of what was holding
> it.
> The IDCAMS Step reloads the history file with the last 3 days' worth of
> information about jobs.  It is a very simple REPO IFILE(x) OFILE(y)
> 
> 
> I opened an SR to IBM DFSMS and asked if they could add some checks in IDCAMS
> for the nonzero return code from the enq and let me know what job is using it.
> They indicated that extra code path to do that would not help.  They felt that
> the enq is released so soon the extra test for the enqueue would not provide
> the name of the task.
> 
> I have looked at RMF reports - I could see nothing.
> I have looked at DAF reports for the 5 min time frame - I could see nothing.
> When the step fails with RC12, I do the D GRS,C and nothing shows up.
> I am tempted to start the ISG Monitor for Enqueues for the 15 minute window
> when this job runs.
> 
> If we rerun the job it is successful.
> 
> Anyone have any other ideas to try and trap this rascally rabbit?
> 
> 
> 
> Lizette Koehler
> statistics: A precise and logical method for stating a half-truth inaccurately

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

Re: Issues with VSAM Enqueuers and Batch job with IDCAMS

[Leonardo Vaz]

How is that VSAM file allocated on your repro step? DISP=OLD or DISP=SHR?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Monday, February 15, 2016 11:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Issues with VSAM Enqueuers and Batch job with IDCAMS

I have an issue where an STC holds a VSAM Dataset.  The STC is a scheduling 
software that writes all of the info on jobs running/completed/failed and so 
forth, to this file.

Once per day we close and free the VSAM file from the STC, run an archive 
process and then re-open then file to the STC. 

This works nearly all of the time.  However, on occasion (a couple times a 
year) the job will fail in the IDCAMS Step with DATASET IN USE BY ANOTHER TASK 
message.  The enq is so fast, I do not have any indication of what was holding 
it.  
The IDCAMS Step reloads the history file with the last 3 days' worth of 
information about jobs.  It is a very simple REPO IFILE(x) OFILE(y)


I opened an SR to IBM DFSMS and asked if they could add some checks in IDCAMS 
for the nonzero return code from the enq and let me know what job is using it.
They indicated that extra code path to do that would not help.  They felt that 
the enq is released so soon the extra test for the enqueue would not provide 
the name of the task.

I have looked at RMF reports - I could see nothing.
I have looked at DAF reports for the 5 min time frame - I could see nothing.
When the step fails with RC12, I do the D GRS,C and nothing shows up.
I am tempted to start the ISG Monitor for Enqueues for the 15 minute window 
when this job runs.

If we rerun the job it is successful.

Anyone have any other ideas to try and trap this rascally rabbit?



Lizette Koehler
statistics: A precise and logical method for stating a half-truth inaccurately

--
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: Issues with VSAM Enqueuers and Batch job with IDCAMS

[Mike Schwab]

If you only use the dataset for two things, and right after the first
completes the second fails, the ENQ might not have cleared when the
second starts.  How about an IEFBR14 with a DD for the dataset at the
start of the STC task.

On Mon, Feb 15, 2016 at 10:52 AM, Lizette Koehler
 wrote:
> I have an issue where an STC holds a VSAM Dataset.  The STC is a scheduling
> software that writes all of the info on jobs running/completed/failed and so
> forth, to this file.
>
> Once per day we close and free the VSAM file from the STC, run an archive
> process and then re-open then file to the STC.
>
> This works nearly all of the time.  However, on occasion (a couple times a 
> year)
> the job will fail in the IDCAMS Step with DATASET IN USE BY ANOTHER TASK
> message.  The enq is so fast, I do not have any indication of what was holding
> it.
> The IDCAMS Step reloads the history file with the last 3 days' worth of
> information about jobs.  It is a very simple
> REPO IFILE(x) OFILE(y)
>
>
> I opened an SR to IBM DFSMS and asked if they could add some checks in IDCAMS
> for the nonzero return code from the enq and let me know what job is using it.
> They indicated that extra code path to do that would not help.  They felt that
> the enq is released so soon the extra test for the enqueue would not provide 
> the
> name of the task.
>
> I have looked at RMF reports - I could see nothing.
> I have looked at DAF reports for the 5 min time frame - I could see nothing.
> When the step fails with RC12, I do the D GRS,C and nothing shows up.
> I am tempted to start the ISG Monitor for Enqueues for the 15 minute window 
> when
> this job runs.
>
> If we rerun the job it is successful.
>
> Anyone have any other ideas to try and trap this rascally rabbit?
>
>
>
> Lizette Koehler
> statistics: A precise and logical method for stating a half-truth inaccurately
>
> --
> 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

Issues with VSAM Enqueuers and Batch job with IDCAMS

[Lizette Koehler]

I have an issue where an STC holds a VSAM Dataset.  The STC is a scheduling
software that writes all of the info on jobs running/completed/failed and so
forth, to this file.

Once per day we close and free the VSAM file from the STC, run an archive
process and then re-open then file to the STC. 

This works nearly all of the time.  However, on occasion (a couple times a year)
the job will fail in the IDCAMS Step with DATASET IN USE BY ANOTHER TASK
message.  The enq is so fast, I do not have any indication of what was holding
it.  
The IDCAMS Step reloads the history file with the last 3 days' worth of
information about jobs.  It is a very simple
REPO IFILE(x) OFILE(y)


I opened an SR to IBM DFSMS and asked if they could add some checks in IDCAMS
for the nonzero return code from the enq and let me know what job is using it.
They indicated that extra code path to do that would not help.  They felt that
the enq is released so soon the extra test for the enqueue would not provide the
name of the task.

I have looked at RMF reports - I could see nothing.
I have looked at DAF reports for the 5 min time frame - I could see nothing.
When the step fails with RC12, I do the D GRS,C and nothing shows up.
I am tempted to start the ISG Monitor for Enqueues for the 15 minute window when
this job runs.

If we rerun the job it is successful.

Anyone have any other ideas to try and trap this rascally rabbit?



Lizette Koehler
statistics: A precise and logical method for stating a half-truth inaccurately

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

Re: Manipulating system symbols

[Mike Schwab]

I would suggest they use the 3 character message prefix.

On Mon, Feb 15, 2016 at 10:08 AM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Mon, 15 Feb 2016 03:33:36 -0600, Art Gutowski wrote:

 Please note that with z/OS 2.2 the length of system symbols names has
 increased from 8 to 16, and may include the underscore character.

 -Original Message-
 On Behalf Of Paul Gilmartin
 Sent: Thursday, 4 February 2016 12:03 PM
 >
 The namespace is too small in this 21st century.
>>
>>I have a counter-proposal.  IBM can reserve certain prefixes or even complete 
>>names, as they do for SYSMOD IDs, that are off-limits, or 
>>use-at-your-own-risk.  They can further set up a registry, as they do for 
>>module names, and while this registry is voluntary, we can certainly 
>>encourage vendors to participate.
>>
> Such a registry shouldn't be the province of any single supplier; it should be
> global.  The prefix an ISV uses for z/OS should likewise apply to Linux,
> OS X, Windows, ...  There's a nascent convention of using a registered domain
> name, wrtten big-endian, as a qualifier, such as com.gm or edu.ua.listserv.
> That convention should be embraced more widely.
>
> -- gil
>
> --
> 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: Would ISGQUERY be the proper Service

[Leonardo Vaz]

ISGQUERY should work for what you are attempting, the following simple test 
worked fine for me to show the first job enqueueing the dataset:

 OPEN  (SYSPRINT,(OUTPUT))
 STORAGE OBTAIN,ADDR=(R10),LENGTH=4096
 ISGQUERY REQINFO=QSCAN,SCANACTION=START,  X
   ANSAREA=(R10),ANSLEN=4096,ANSDETAIL=FULL2,  X
   SEARCH=BY_FILTER,QNAMEMATCH=SPECIFIC,QNAME==CL8'SYSDSN',X
   RNAMEMATCH=PATTERN,RNAMELEN=12, X
   RNAME==CL12'SYS1.PARMLIB',  X
   RETCODE=LRETCODE,RSNCODE=LRSNCODE
 USING ISGYQUAAHDR,R10
 L R9,ISGYQUAAHDRFIRSTRECORD31
 USING ISGYQUAARS,R9
 L R8,ISGYQUAARSFIRSTRQ31
 USING ISGYQUAARQ,R8
 L R7,ISGYQUAARQRQX31
 USING ISGYQUAARQX,R7
 PUT   SYSPRINT,ISGYQUAARQXJOBNAME
 STORAGE RELEASE,ADDR=(R10),LENGTH=4096
 CLOSE (SYSPRINT)

As John McKown has stated, maybe use SYSVSAM instead of SYSDSN.

Regards,
Leo

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of esst...@juno.com
Sent: Sunday, February 14, 2016 5:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Would ISGQUERY be the proper Service

Hello,
.
I have a Started Task (STC), and sometimes a another job will hold a VSAM 
dataset needed by this STC. This prevents the STC from properly re-opening the 
dataset.
.
The VSAM datasets are defined with Share Options are 2,3 and Transactional VSAM 
(RLS) is not an option.
.
.
Im looking for a z/OS macro or callable service that will allow the Started 
Task to identify the name of the other job that has opened a VSAM dataset which 
the Started Task needs. 
.
.
I started reading the description of the ISGQUERY and its various Mapping 
Macros but I dont see where it would returns the name of a batch job that has 
allocated the dataset. 
.
I suspect I would use GATHERFROM=SYSTEM  with SCOPE=SYSTEM, since the batch 
processing occurs on the same LPAR as the Started Task.

Is ISGQUERY the proper macro/service to accomplish this ?
.
Would someone provide some sample code and point me to the proper macro/service 
to invoke to accomplish this.
.
.
The Started Task happens to be a CICS Address Space and we would use a standard 
CICS Supplied Open Exit to drive this.
.
.
Paul
*
*

--
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: Manipulating system symbols

[Paul Gilmartin]

On Mon, 15 Feb 2016 03:33:36 -0600, Art Gutowski wrote:
>>> 
>>> Please note that with z/OS 2.2 the length of system symbols names has
>>> increased from 8 to 16, and may include the underscore character.
>>> 
>>> -Original Message-
>>> On Behalf Of Paul Gilmartin
>>> Sent: Thursday, 4 February 2016 12:03 PM
>>> >
>>> The namespace is too small in this 21st century.
>
>I have a counter-proposal.  IBM can reserve certain prefixes or even complete 
>names, as they do for SYSMOD IDs, that are off-limits, or 
>use-at-your-own-risk.  They can further set up a registry, as they do for 
>module names, and while this registry is voluntary, we can certainly encourage 
>vendors to participate.
>
Such a registry shouldn't be the province of any single supplier; it should be
global.  The prefix an ISV uses for z/OS should likewise apply to Linux,
OS X, Windows, ...  There's a nascent convention of using a registered domain
name, wrtten big-endian, as a qualifier, such as com.gm or edu.ua.listserv.
That convention should be embraced more widely.

-- gil

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

Re: Would ISGQUERY be the proper Service

[Paul Gilmartin]

On Sun, 14 Feb 2016 16:25:19 -0800, Ed Jaffe wrote:

>On 2/14/2016 2:01 PM, essteam wrote:
>> Is ISGQUERY the proper macro/service to accomplish this ?
>
>ISGQUERY will give you information about ENQs and RESERVEs, including
>the system names, job names, ASIDs, and TCB addresses of those holding
>-- and those suspended waiting for -- resources. It has nothing to do
>with OPEN/CLOSE.
> 
Is this the service that ISPF DDLIST ENQ uses?

-- gil

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

Re: Would ISGQUERY be the proper Service

[Walt Farrell]

On Mon, 15 Feb 2016 13:50:27 GMT, esst...@juno.com  wrote:

>Im not trying to free and allocate CICS.
>I want to identify the current job that has a dataset allocated
>when my STC needs it.

However, if your concern is for a VSAM file then it sounds it's the share 
options that are causing an issue. In that case, does it matter who has it 
_allocated_ or is the real question who has it _open_ in some way that 
conflicts? 

All of the documentation I've seen about share options talks about who can have 
the file open. E.g., 
  
https://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.idad400/crso.htm

That means that looking at who has the SYSDSN ENQ won't necessarily give you 
the right answer. For a guaranteed correct answer you need to be using the same 
mechanism that VSAM would use, whatever that is. It _might_ be the SYSVSAM ENQ 
another poster mentioned, but I don't know for sure.

-- 
Walt

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

Re: Real Storage Allocation

[John Abell]

As long as your z/OS isn't running under, z/VM like may smaller ISVs, where 
LFAREA is not yet supported.

John T. Abell
Tel:800-295-7608Option 4
President
International:  1-416-593-5578  Option 4
E-mail:  john.ab...@intnlsoftwareproducts.com
Fax:800-295-7609

International:  1-416-593-5579


International Software Products
www.ispinfo.com

This email may contain confidential and privileged material for the sole use of 
the intended recipient(s). Any review, use, retention, distribution or 
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive on behalf of the named recipient), please 
contact the sender by reply email and delete all copies of this message. 
Also,email is susceptible to data corruption, interception,
tampering, unauthorized amendment and viruses. We only send and receive emails 
on the basis that we are not liable for any such corruption, interception, 
tampering, amendment or viruses or any consequence thereof.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Sunday, February 14, 2016 5:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Real Storage Allocation

On 2/14/2016 11:19 AM, Graham Harris wrote:
> Ed Jaffe wrote:
>
>
>> The nice thing about an overabundance of real storage is the ability
>> to
> create a very large LFAREA with plenty of room for 1MB >pageable pages
> and
> -- if you have software that can truly benefit from it (which we
> don't) -- 2G fixed pages.
>
>
> LFAREA does of course only generally hold fixed large pages, although
> it does also handle overflow of PLAREA when that becomes full, which
> maybe what you were thinking.

LFAREA (Large Frame Area) provides frame space for both fixed and pageable 
large pages. We specify:

LFAREA=7782M,  Large frame area

which is more than enough for our needs. Right after IPL I see some fairly 
small numbers:

D VS,LFAREA
IAR019I  13.56.52 DISPLAY VIRTSTOR 507
  SOURCE =  20
  TOTAL LFAREA = 7782M , 0G
  LFAREA AVAILABLE = 7257M , 0G
  LFAREA ALLOCATED (1M) = 0M
  LFAREA ALLOCATED (4K) = 311M
  MAX LFAREA ALLOCATED (1M) = 0M
  MAX LFAREA ALLOCATED (4K) = 311M
  LFAREA ALLOCATED (PAGEABLE1M) = 214M
  MAX LFAREA ALLOCATED (PAGEABLE1M) = 214M
  LFAREA ALLOCATED NUMBER OF 2G PAGES = 0
  MAX LFAREA ALLOCATED NUMBER OF 2G PAGES = 0

Of course, these numbers grow over 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


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

[John Eells]

I would not want to run with such an MPF exit or AUTORxx member active 
in production.  You can have it there for emergencies and activate it 
with a SET command.  This keeps the pain level of failsoft mode a lot 
more tolerable.  We used to have a couple of such exits waiting in the 
wings for recovery to automate operator approvals during system 
recovery, though at this point I can't recall specifically for what 
other messages they automated the responses.


I absolutely agree with those who express a preference for a one-pack 
recovery system, by the way.  But I'm a belt-and-suspenders kind of guy 
and would still want one more last-ditch recovery option.


Skip Robinson wrote:

This problem occurs so seldom that I never thought of automating a response. As 
of R12 or so, we now have AUTORxx, which can reply to WTORs very early in the 
IPL. Not sure who here would have to approve such a change. The chances of 
mischief being perpetrated are minimal, but it does open a very small window 
for a clever miscreant.

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Ed Jaffe
Sent: Sunday, February 14, 2016 07:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

On 2/13/2016 8:04 PM, Skip Robinson wrote:

This opinion is based on (thankfully) limited experience. If you are
forced to IPL without a usable RACF data base, you are totally
scr*wed. During IPL, operator will be prompted to allow even READ
access to *every* data set opened by *every* task except for a tiny
handful like JES that bypass integrity. By the time you get to the
point of actually logging on to TSO, operator's fingers will be
bleeding profusely. If at any time during this process, you are
god-forbid required to start over, yet more finger tips will have to sacrificed.


We solved this with an MPF exit that would always reply 'Y' to each of those
prompts (except for the first few IIRC).



--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: Would ISGQUERY be the proper Service

[Lizette Koehler]

My comment about - not everything is good to be done in CICS was the main reason
to for the suggestion.  If you put CICS in a wait state while an MVS function
goes off and "does something", then all of CICS waits.  So, you should be wary
when using come functions that are easily done in MVS but could be harmful to
CICS.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of esst...@juno.com
> Sent: Monday, February 15, 2016 6:50 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Would ISGQUERY be the proper Service
> 
> Im not trying to free and allocate CICS.
> I want to identify the current job that has a dataset allocated when my STC
> needs it.
> 
> -- Original Message --
> From: Lizette Koehler 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Would ISGQUERY be the proper Service
> Date: Sun, 14 Feb 2016 16:12:47 -0700
> 
> If you are trying to free and allocate a file from CICS, then you might have
> better response from the CICS list.
> 
> To join, if you have not done so,
> CICS  http://www.listserv.uga.edu/archives/cics-l.html
> 
> There are some functions you cannot perform in CICS because it will tie up
> CICS and impact the users.
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of esst...@juno.com
> > Sent: Sunday, February 14, 2016 3:01 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Would ISGQUERY be the proper Service
> >
> > Hello,
> > .
> > I have a Started Task (STC), and sometimes a another job will hold a
> > VSAM dataset needed by this STC. This prevents the STC from properly
> > re-opening the dataset.
> > .
> > The VSAM datasets are defined with Share Options are 2,3 and
> > Transactional VSAM (RLS) is not an option.
> > .
> > .
> > Im looking for a z/OS macro or callable service that will allow the
> > Started Task to identify the name of the other job that has opened a
> > VSAM dataset which the Started Task needs.
> > .
> > .
> > I started reading the description of the ISGQUERY and its various
> > Mapping Macros but I dont see where it would returns the name of a
> > batch job that has allocated the dataset.
> > .
> > I suspect I would use GATHERFROM=SYSTEM  with SCOPE=SYSTEM, since the
> > batch processing occurs on the same LPAR as the Started Task.
> >
> > Is ISGQUERY the proper macro/service to accomplish this ?
> > .
> > Would someone provide some sample code and point me to the proper
> > macro/service to invoke to accomplish this.
> > .
> > .
> > The Started Task happens to be a CICS Address Space and we would use a
> > standard CICS Supplied Open Exit to drive this.
> > .
> > .
> > Paul

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

Re: Would ISGQUERY be the proper Service

[esst...@juno.com]

Thank You
The "WHO' Command is exactly what Im looking for ONLY it needs to be issued 
from the CICS OPEN/CLOSE exit routine.

Thaks

-- Original Message --
From: Peter Relson 
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Would ISGQUERY be the proper Service
Date: Mon, 15 Feb 2016 07:43:01 -0500

>ISGQUERY will give you information about ENQs and RESERVEs...
>It has nothing to do with OPEN/CLOSE.

True, but there is a strong correlation between OPEN and Allocate and the 
SYSDSN ENQ that usually accompanies the allocation.
So I think of the OP's request as querying the SYSDSN ENQ for the data set 
in question to see who holds it.

On our system we have a "WHO" command that perhaps uses GQSCAN or ISGQUERY 
to obtain the information about who has the data set ENQ.

I'd also note that if you have an interface that gives you back an ASID 
you can determine the (current) jobname from that ASID programmatically 
via LOCASCB and the ASSB fields ASSBJBNI and ASSBJBNS (those two being 
slightly safer than the pointers in ASCBJBNI and ASCBJBNS). Serialization 
and/or recovery is needed if the ASID might "go away" (as the ASCB/ASSB 
could be freed).

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

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

Re: Would ISGQUERY be the proper Service

[esst...@juno.com]

Im not trying to free and allocate CICS.
I want to identify the current job that has a dataset allocated
when my STC needs it.

-- Original Message --
From: Lizette Koehler 
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Would ISGQUERY be the proper Service
Date: Sun, 14 Feb 2016 16:12:47 -0700

If you are trying to free and allocate a file from CICS, then you might have
better response from the CICS list.

To join, if you have not done so,
CICShttp://www.listserv.uga.edu/archives/cics-l.html

There are some functions you cannot perform in CICS because it will tie up CICS
and impact the users.  

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of esst...@juno.com
> Sent: Sunday, February 14, 2016 3:01 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Would ISGQUERY be the proper Service
> 
> Hello,
> .
> I have a Started Task (STC), and sometimes a another job will hold a VSAM
> dataset needed by this STC. This prevents the STC from properly re-opening the
> dataset.
> .
> The VSAM datasets are defined with Share Options are 2,3 and Transactional
> VSAM (RLS) is not an option.
> .
> .
> Im looking for a z/OS macro or callable service that will allow the Started
> Task to identify the name of the other job that has opened a VSAM dataset
> which the Started Task needs.
> .
> .
> I started reading the description of the ISGQUERY and its various Mapping
> Macros but I dont see where it would returns the name of a batch job that has
> allocated the dataset.
> .
> I suspect I would use GATHERFROM=SYSTEM  with SCOPE=SYSTEM, since the batch
> processing occurs on the same LPAR as the Started Task.
> 
> Is ISGQUERY the proper macro/service to accomplish this ?
> .
> Would someone provide some sample code and point me to the proper
> macro/service to invoke to accomplish this.
> .
> .
> The Started Task happens to be a CICS Address Space and we would use a
> standard CICS Supplied Open Exit to drive this.
> .
> .
> Paul
> *
> *
> 

--
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: Would ISGQUERY be the proper Service

[John McKown]

On Mon, Feb 15, 2016 at 6:43 AM, Peter Relson  wrote:

> >ISGQUERY will give you information about ENQs and RESERVEs...
> >It has nothing to do with OPEN/CLOSE.
>
> True, but there is a strong correlation between OPEN and Allocate and the
> SYSDSN ENQ that usually accompanies the allocation.
> So I think of the OP's request as querying the SYSDSN ENQ for the data set
> in question to see who holds it.
>

​Personally, iffin it t'were me, I'd check the SYSVSAM​ qname in addition
to the SYSDSN qname. Why? Because if you open a VSAM CLUSTER via a PATH,
the SYSDSN does _not_ get enqueued, but the base cluster _is_ open. And it
_will_show up with a SYSVSAM enqueue. IOW, you can do a SYSDSN check on a
base cluster; find it is not allocated; and still have the OPEN get an RC
because a PATH to the cluster _is_ OPEN. The SYSVSAM enqueue will warn you
of this before hand. But, be warned, the rname is not simply the cluster
name. Look at the output below (from an in-house UNIX command that I
wrote). The DSN is TSSTV.UMDB.ZAMFILE


===

SYSVSAM TSSTV.UMDT.ZAMFILE.DATACATALOG.ICF.VTSTH01...I  TCICS3
 LIH1SHARED  OWNED   SYSTEM
 009E19F0009B
SYSVSAM TSSTV.UMDT.ZAMFILE.DATACATALOG.ICF.VTSTH01...O  TCICS3
 LIH1SHARED  OWNED   SYSTEM
 009E19F0009B
SYSVSAM TSSTV.UMDT.ZAMFILE.INDEXCATALOG.ICF.VTSTH01...I TCICS3
 LIH1SHARED  OWNED   SYSTEM
 009E19F0009B
SYSVSAM TSSTV.UMDT.ZAMFILE.INDEXCATALOG.ICF.VTSTH01...O TCICS3
 LIH1SHARED  OWNED   SYSTEM
 009E19F0009B
SYSVSAM TSSTV.UMDT.ZAMFILECATALOG.ICF.VTSTH01...N   TCICS3
 LIH1SHARED  OWNED   SYSTEM
 009E19F0009B
SYSVSAM TSSTV.UMDT.ZAMFILECATALOG.ICF.VTSTH01...P   TCICS3
 LIH1SHARED  OWNED   SYSTEM
 009E19F0009B

===



>
> On our system we have a "WHO" command that perhaps uses GQSCAN or ISGQUERY
> to obtain the information about who has the data set ENQ.
>
> I'd also note that if you have an interface that gives you back an ASID
> you can determine the (current) jobname from that ASID programmatically
> via LOCASCB and the ASSB fields ASSBJBNI and ASSBJBNS (those two being
> slightly safer than the pointers in ASCBJBNI and ASCBJBNS). Serialization
> and/or recovery is needed if the ASID might "go away" (as the ASCB/ASSB
> could be freed).
>
> Peter Relson
> z/OS Core Technology Design
>
>

-- 
The man has the intellect of a lobotomized turtle.

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: UADS (was Re: [Bulk] Re: COBOL v5)

[Deepthi S]

...
On 01-Feb-2016 9:57 PM, "John Eells"  wrote:

> I hadn't really thought about (or researched) the display capabilities of
> RACF.  An RFE couldn't hurt if you find them lacking.
>
> Once one's TSO/E administrative routines have been converted to use the
> TSO segment, though, I think another good use of UADS is for recovery,
> including DR. It's the only way to log on when you have no security
> database, at least when RACF is the absent DB in question. I'd want to have
> "some number" of sysprog user IDs to be in UADS for recovery purposes. (And
> an appropriate MPF exit, for RACF!)
>
> As SA restore is a serial activity and batch restore is not, minimizing
> recovery time would seem to call for a small number of UADS-defined IDs to
> speed overall restore time if your security DB happens not to share a
> volume with some other data sets required to IPL and log on. But what do I
> know?
>
> Skip Robinson wrote:
>
>> Ah, UADS. A prime example of archaic mechanism. Defensible technically?
>> Probably not, although a security administrator who needs to know which
>> account numbers or which proclibs a user is authorized to use might tell a
>> different story. With UADS, a simple list command tells the story. With
>> TSOE
>> segment, it's a data mining operation. This difference alone has inhibited
>> conversion in some shops.
>>
> 
>
> --
> John Eells
> IBM Poughkeepsie
> ee...@us.ibm.com
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: UADS (was Re: [Bulk] Re: COBOL v5)

[Deepthi S]

..
On 01-Feb-2016 9:57 PM, "John Eells"  wrote:

> I hadn't really thought about (or researched) the display capabilities of
> RACF.  An RFE couldn't hurt if you find them lacking.
>
> Once one's TSO/E administrative routines have been converted to use the
> TSO segment, though, I think another good use of UADS is for recovery,
> including DR. It's the only way to log on when you have no security
> database, at least when RACF is the absent DB in question. I'd want to have
> "some number" of sysprog user IDs to be in UADS for recovery purposes. (And
> an appropriate MPF exit, for RACF!)
>
> As SA restore is a serial activity and batch restore is not, minimizing
> recovery time would seem to call for a small number of UADS-defined IDs to
> speed overall restore time if your security DB happens not to share a
> volume with some other data sets required to IPL and log on. But what do I
> know?
>
> Skip Robinson wrote:
>
>> Ah, UADS. A prime example of archaic mechanism. Defensible technically?
>> Probably not, although a security administrator who needs to know which
>> account numbers or which proclibs a user is authorized to use might tell a
>> different story. With UADS, a simple list command tells the story. With
>> TSOE
>> segment, it's a data mining operation. This difference alone has inhibited
>> conversion in some shops.
>>
> 
>
> --
> John Eells
> IBM Poughkeepsie
> ee...@us.ibm.com
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Would ISGQUERY be the proper Service

[Peter Relson]

>ISGQUERY will give you information about ENQs and RESERVEs...
>It has nothing to do with OPEN/CLOSE.

True, but there is a strong correlation between OPEN and Allocate and the 
SYSDSN ENQ that usually accompanies the allocation.
So I think of the OP's request as querying the SYSDSN ENQ for the data set 
in question to see who holds it.

On our system we have a "WHO" command that perhaps uses GQSCAN or ISGQUERY 
to obtain the information about who has the data set ENQ.

I'd also note that if you have an interface that gives you back an ASID 
you can determine the (current) jobname from that ASID programmatically 
via LOCASCB and the ASSB fields ASSBJBNI and ASSBJBNS (those two being 
slightly safer than the pointers in ASCBJBNI and ASCBJBNS). Serialization 
and/or recovery is needed if the ASID might "go away" (as the ASCB/ASSB 
could be freed).

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: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

[Robert S. Hansel (RSH)]

I wholeheartedly agree with Joel's recommendation for having a backup copy of 
the RACF database readily available for recovery. I just want to add that it is 
crucial to use RACF utilities to create the backup and to allocate it with the 
proper characteristics. The preferred utility to use to create the backup is 
IRRUT200 which momentarily serializes the database, thereby preventing updates, 
while it copies the database. IRRUT400 can also be used, but it locks the 
database which you then have to unlock. The backup should be allocated as one 
extent, contiguous, and non-movable and, if using IRRUT200, with the exact same 
size as the source.

As determine by one of our RACF surveys and as found in our numerous RACF 
reviews, many organizations are not using RACF utilities to back up their 
databases and risk having a corrupted backup. If you are interested, the survey 
"RACF Database Backup" can be found on the RACF Center webpage of our website 
at the following URL. For those unfamiliar with our website, you'll find lots 
of other useful RACF information there as well.

http://www.rshconsulting.com/racfres.htm

Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
www.linkedin.com/in/roberthansel
http://twitter.com/RSH_RACF
www.rshconsulting.com

Upcoming RSH RACF Training
- RACF Audit & Compliance Roadmap - APR 11-15, 2016
- RACF Level I Administration - MAY 17-20, 2016
- RACF Level II Administration -MAY 3-5, 2016
- RACF Level III Admin, Audit, & Compliance - JUN 14-16, 2016
- Securing z/OS UNIX  - WebEx - JUL 25-29, 2016


-Original Message-
Date:Sun, 14 Feb 2016 15:53:07 -0600
From:"Joel C. Ewing" 
Subject: Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

But the only way to "fix"an unusable RACF database is to have a fairly
recent backup copy of the RACF data base that can be restored.  I would
contend that is easier, and possibly safer, to do this from a fully
functional "one-drive" tech support emergency z/OS system accessing
production drives than to do it from a UADS-defined TSO user on a
crippled production system without RACF or with a known-damaged database
-- and there are so many other unanticipated problems such an emergency
system can address that it doesn't make sense to be without one. 

If the only problem that can be solved by having a UADS-defined TSO user
can be better addressed by a "must have" alternative, why persist with
any UADS-defined TSO users once the alternative is available?
Joel C. Ewing

On 02/14/2016 01:04 PM, Skip Robinson wrote:
> This problem occurs so seldom that I never thought of automating a response. 
> As of R12 or so, we now have AUTORxx, which can reply to WTORs very early in 
> the IPL. Not sure who here would have to approve such a change. The chances 
> of mischief being perpetrated are minimal, but it does open a very small 
> window for a clever miscreant. 
>
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler 
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> jo.skip.robin...@att.net
>
>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On Behalf Of Ed Jaffe
>> Sent: Sunday, February 14, 2016 07:37 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)
>>
>> On 2/13/2016 8:04 PM, Skip Robinson wrote:
>>> This opinion is based on (thankfully) limited experience. If you are
>>> forced to IPL without a usable RACF data base, you are totally
>>> scr*wed. During IPL, operator will be prompted to allow even READ
>>> access to *every* data set opened by *every* task except for a tiny
>>> handful like JES that bypass integrity. By the time you get to the
>>> point of actually logging on to TSO, operator's fingers will be
>>> bleeding profusely. If at any time during this process, you are
>>> god-forbid required to start over, yet more finger tips will have to 
>>> sacrificed.
>> We solved this with an MPF exit that would always reply 'Y' to each of those
>> prompts (except for the first few IIRC).
>>
>> --
>> Edward E Jaffe
>> Phoenix Software International, Inc
>> 831 Parkview Drive North
>> El Segundo, CA 90245
>> http://www.phoenixsoftware.com/


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

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

Re: Manipulating system symbols

[Art Gutowski]

On Wed, 3 Feb 2016 19:53:48 -0800, Skip Robinson  
wrote:

>Sweet. Did not pick up on that. All the more reason to prefix symbols with a 
>unique string. 
>
>> -Original Message-
>> On Behalf Of Anthony Thompson
>> Sent: Wednesday, February 3, 2016 07:48 PM
>> 
>> Please note that with z/OS 2.2 the length of system symbols names has
>> increased from 8 to 16, and may include the underscore character.
>> 
>> Ant.
>> 
>> -Original Message-
>> On Behalf Of Paul Gilmartin
>> Sent: Thursday, 4 February 2016 12:03 PM
>> 
>> On 2016-02-03 19:27, Skip Robinson wrote:
>> > This is why I strongly recommend that installation-defined symbols be
>> prefixed with a unique string, which I also recommend be the SHARE
>> installation code. It reduces the number of meaningful character to 5 or 6 
>> but
>> pretty much rules out stepping on toes. Debugging problems caused by
>> symbol 'overlays' could be excruciating.
>> >
>> The namespace is too small in this 21st century.
>> 
>> -- gil

In the meantime, we still have the 8-character limitation.  And whether we try 
to convert existing symbols to use a site prefix now or wait until we have 16 
characters available, that's no small feat.  Naming conventions of any kind, 
once they take hold, are time-consuming to change.  What if the installation is 
not a SHARE member?

We already use meaningful (to us) prefixes to make symbols intuitive to us 
without stepping on IBM symbols, let alone other vendors.  Further, in the case 
I pointed out previously, the vendor decided to use symbol names that conflict 
with IBM filter criterion, and could conflict with IBM symbols.  We have no 
control over such situations.  

Even if they don't conflict, should the installation be JES3, the changes won't 
get picked up, unless the product is issuing a *S ,CONNECT under the 
covers...more shenanigans.  I understand that with the advent of SETLOAD 
IEASYM, this has changed a little, but at z/OS 1.13, the vendor clearly is not 
using this facility to effect the change.

I stand by my earlier statement, no supplier should be dynmically inserting 
symbols into the table without express consent of the installation.  In other 
words, there should be a configuration switch for which the default setting 
should be OFF.  Better to document any symbols and have the customer define 
them explicitly at IPL via IEASYMxx.

I have a counter-proposal.  IBM can reserve certain prefixes or even complete 
names, as they do for SYSMOD IDs, that are off-limits, or use-at-your-own-risk. 
 They can further set up a registry, as they do for module names, and while 
this registry is voluntary, we can certainly encourage vendors to participate.

Regards,
Art Gutowski
General Motors, LLC

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

Re: Catalog VVDS confusion

[Art Gutowski]

On Fri, 5 Feb 2016 11:54:37 -0600, Tom Marchant  
wrote:

>Many years ago, I had a colleague run REPOR MERGECAT as a way of creating a 
>backup 
>copy of some catalogs. I didn't notice the caution in the manual that says 
>that the old 
>catalog should not be used to access the VSAM data sets after the MERGECAT 
>operation.
>
>The result was that the VVDS entries for all of the VSAM data sets in the 
>catalogs had been 
>updated to point to the new catalog. The aliases were not changed, so the 
>system continued 
>to use the old catalogs. There were a lot of data sets in the same condition 
>that you describe.
>
>I don't remember what the problem was that this caused. Perhaps it had to do 
>with restoring a 
>data set from a backup. Art called me the following week to tell me about the 
>problem and ask 
>for suggestions as to what he should do to fix it.
>
>Maybe Art remembers what problems were caused by it. We both learned a lot 
>from the 
>experience.

I was hoping never to speak of this again =^O  I did learn more about ICF 
catalog structure that I ever thought I wanted to.

The problem was actually with REPRO NOMERGECAT, though similar results can 
likely be achieved with MERGECAT, if you work at it.  Neither of us noticed the 
caution, which, if memory serves, is now a more visible _warning_.  BTW, this 
was in DFP v1 (yes, MVS/SP).

As Tom stated, the VVRs were updated, however the datasests were still accessed 
via the original catalogs.  As long as the datasets didn't move, everything was 
fine.  We ran for days, maybe even a week or more, until application reorgs 
started to run.  The standard process at the time was to REPRO to a PS file, 
delete/define, then REPRO from the PS file into the VSAM file.  The REPRO ran 
without incident.  So did the DELETE, though it shouldn't have (IMHO).  Because 
the VVR back-pointer didn't match the catalog containing the BCS entry, AMS did 
not delete the VVR entry, though it did delete the BCS and VTOC entries.  Next, 
the VSAM dataset is defined anew in the standard search order, so AMS created a 
BCS entry, a duplicate VVR entry, which fell after the previously orphaned VVR 
entry, and a VTOC entry.  Still no consistency checking done or errors 
reported.  Finally, when the REPRO ran to repopulate the VSAM dataset, all hell 
broke loose, because AMS found and used the old VVR entry, pointing back to the 
wrong catalog, with information that did not match up with the VTOC entry.  At 
this point AMS decided at last to throw an error message and fail the 
operation.  The error message of course was obscure and obtuse, and it took a 
sev1 with IBM to figure out what was really going on.

It was then suggested we run DIAGNOSE to see how much trouble we were 
in...let's just say it took us 2-3 weeks to dig out, because, well, we didn't 
stop at a single alternate catalog...we had to create one for every catalog in 
the system.  Thankfully we had a Rexx wizard who wrote up a couple of programs 
to process DIAGNOSE output and generate AMS statemnts to EXPORT PERMANENT, 
DELETE VVR, and IMPORT for each afflicted dataset.  Otherwise, it might have 
taken 2-3 months.  There were a handful of datasets that had VTOC problems, 
too, but it's a little hazy - those could have been from failed attempts to 
repair the problem before we fully understood it.  We had to zap a few VTOC 
VSAM bits so to complete the cleanup.

Art Gutowski
General Motors, LLC

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