Rob Weiss is not available today
I will be out of the office starting 05/02/2008 and will not return until 05/19/2008. I am working in Brazil with limited access to the internet. I will check e-mail daily. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SVC99
Hi, In one of our programs say XYZ, we are accessing USER catalog by dynamically allocating the Catalog using SVC 99 (in shared access mode) to get some dataset related information from the catalog. Before this dynamic allocation we are actually turning-on all the wait bits (S99WTVOL+S99WTDSN+S99WTUNT+S99OFFLN) in S99FLG21 byte. So far so good, but we seem to be getting allocation failures on the catalog in our program XYZ, whenever our catalog compression jobs are running (Catalog compress jobs have exclusive ENQ on the catalog during compress). As per our understanding, the dynamic allocation in XYZ program should wait for the shared access of Catalog as the catalog is locked for exclusive use by Catalog compression jobs. And since the DSN is unavailable to our program XYZ, it should wait for the DSN till the catalog compress job releases the exclusive lock on catalog. Any pointers to why the S99FLG21 wait bits are not working would be of great help to us? We also have CA-MIM would this cause any effect on the catalog allocation. Thanks Regards, Saravanan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Shop zSeries Ordering Issues
exactly, and it has included Unix for quite awhile now, O/E first showed up with MVS V4 - Original Message - From: Timothy Sipples [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Saturday, May 03, 2008 1:21 AM Subject: Re: Shop zSeries Ordering Issues Barry Schwarz writes: If I wanted a Unix system, I would have bought one. You did. :-) z/OS includes UNIX(TM). - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVC99
Are you running authorized? The FM states: Requesting a Data Set That Is In Use: Rather than wait for another user to release a data set, volume, or device to obtain use of it, dynamic allocation fails a request by an unauthorized program. If an authorized program specifically requests a wait, dynamic allocation will wait. Date: Sat, 3 May 2008 05:58:25 -0500 From: [EMAIL PROTECTED] Subject: SVC99 To: IBM-MAIN@BAMA.UA.EDU Hi, In one of our programs say XYZ, we are accessing USER catalog by dynamically allocating the Catalog using SVC 99 (in shared access mode) to get some dataset related information from the catalog. Before this dynamic allocation we are actually turning-on all the wait bits (S99WTVOL+S99WTDSN+S99WTUNT+S99OFFLN) in S99FLG21 byte. So far so good, but we seem to be getting allocation failures on the catalog in our program XYZ, whenever our catalog compression jobs are running (Catalog compress jobs have exclusive ENQ on the catalog during compress). As per our understanding, the dynamic allocation in XYZ program should wait for the shared access of Catalog as the catalog is locked for exclusive use by Catalog compression jobs. And since the DSN is unavailable to our program XYZ, it should wait for the DSN till the catalog compress job releases the exclusive lock on catalog. Any pointers to why the S99FLG21 wait bits are not working would be of great help to us? We also have CA-MIM would this cause any effect on the catalog allocation. Thanks Regards, Saravanan _ With Windows Live for mobile, your contacts travel with you. http://www.windowslive.com/mobile/overview.html?ocid=TXT_TAGLM_WL_Refresh_mobile_052008 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Concatenating Uncataloged Data Sets w/CLIST (was Re: What is needed to run IPCS ...)
On Fri, 2 May 2008 19:26:34 -0500, Paul Gilmartin [EMAIL PROTECTED] wrote: In your circumstance, I'd be inclined to use MSG(WTP) rather than MSG(2). But I've already been wrong once today. YMMV. Yes, that would be a better option also. Thanks. No excuse except that I copied the code from somewhere else without thinking about it. Although if the ALLOCATE above worked I would never expect the CONCAT to fail and if the ALLOCATE failed I would see that. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVC99
On Sat, 3 May 2008 07:28:43 -0400, J R wrote: Requesting a Data Set That Is In Use: Rather than wait for another user to release a data set, volume, or device to obtain use of it, dynamic allocation fails a request by an unauthorized program. ... I've long wondered why. Is there some particular integrity or security hazard associated with a program's waiting for another user to release a data set? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVC99
Probably to ensure that not just anybody can cause a deadly embrace: S99WTVOL / S99WTDSN / S99WTUNT / S99OFFLN / S99MOUNT : Use care when you set these flags; setting any one of them might cause a deadlock situation. For example, consider the situation where JOBA owns a resource that JOBB wants and JOBB owns a resource that JOBA wants. If one of the above flags are on, the two jobs will wait until one job is cancelled. Date: Sat, 3 May 2008 11:12:23 -0500 From: [EMAIL PROTECTED] Subject: Re: SVC99 To: IBM-MAIN@BAMA.UA.EDU On Sat, 3 May 2008 07:28:43 -0400, J R wrote: Requesting a Data Set That Is In Use: Rather than wait for another user to release a data set, volume, or device to obtain use of it, dynamic allocation fails a request by an unauthorized program. ... I've long wondered why. Is there some particular integrity or security hazard associated with a program's waiting for another user to release a data set? -- gil _ Make Windows Vista more reliable and secure with Windows Vista Service Pack 1. http://www.windowsvista.com/SP1?WT.mc_id=hotmailvistasp1banner -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVC99
Yes the program is authorised. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVC99
On Sat, 3 May 2008 12:23:37 -0400, J R wrote: Probably to ensure that not just anybody can cause a deadly embrace: Why is a deadly embrace caused by an authorized program deemed less harmful than one caused by an unauthorized program? S99WTVOL / S99WTDSN / S99WTUNT / S99OFFLN / S99MOUNT : Use care when you set these flags; setting any one of them might cause a deadlock situation. For example, consider the situation where JOBA owns a resource that JOBB wants and JOBB owns a resource that JOBA wants. If one of the above flags are on, the two jobs will wait until one job is cancelled. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Cics Transactions
Hi list, I will post this in the cics list also but maybe someone here will know... we are cics ts 2.3 Terminal starting a session to TOR and then submit transaction A that have REMOTESYSTEM of AOR1 in the definition. Transaction A in AOR1 issue the start command with terminal to Transaction B. In the definition of transaction B in AOR1 there is REMOTESYSTEM of the TOR. In the definition of transaction B in TOR there is REMOTESYSTEM of AOR2. This process work OK. As part of our CICSPLEX project Now we want to use two TOR with vtam generic, In this situation I cannot put in the definition of transaction B in AOR1 REMOTESYSTEM of TOR, because there are two TOR I cannot use the enhanced start (define routable in the transaction definition). How can I do this? TIA, Magen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SDSF REXX problem
Thomas,
You're not alone :)
I think your ISFMSG2 stem variable is empty...
Try adding a VERBOSE parameter on your ISFACT call. That should put some
diagnostic messages in ISFMSG2 which may help you debug.
Gil.
On Fri, May 2, 2008 at 9:07 AM, Thomas Berg [EMAIL PROTECTED] wrote:
*Am I the only one that uses the SDSF REXX interface ?
Or is is time to buf IBM ?
TIA
Thomas Berg
*
== Thomas Berg == wrote2008-04-30 14:37:
Hi!
I have a problem when running SDSF REXX commands.
When looping the returned isfrows after ISFEXEC ST command, the second
ISFACT returns INVALID COMMAND (and rc = 0).
I can't see why.
The REXX:
/* REXX */ Trace R x =
Isfcalls('ON')isfprefix =
'S000TBE5'isfcols = 'JNAME JOBID OWNERID
JCLASS POS STATUS' , 'SYSNAME WORKLOAD CPU TRANACT SRVCLS SRVCLASS
ACTSYS' ,
'SYSAFF TOKEN PRTDEST' Address SDSF
'ISFEXEC ST (ALTERNATE)' isfcols2 = ,
'DDNAME STEPN PROCS DSID OCLASS RECCNT BYTECNT
DSNAME'Do i = 1
To isfrows Address SDSF ISFACT ST
TOKEN('token.i') ,'PARM(NP ?)'
Trace N
Say rcSay isfmsg
Do j = 1 To isfmsg2.0
Say isfmsg2.j End
Do j = 1 To dsname.0
Say dsname.j End
Trace R
End
x = Isfcalls('OFF')
Exit 0
The output:
2 *-* x = Isfcalls('ON')
0
3 *-* isfprefix = 'S000TBE5'
S000TBE5
4 *-* isfcols = 'JNAME JOBID OWNERID JCLASS POS STATUS' ,
'SYSNAME WORKLOAD CPU TRANACT SRVC
LS SRVCLASS ACTSYS' , 'SYSAFF TOKEN PRTDEST'
JNAME JOBID OWNERID JCLASS POS STATUS SYSNAME WORKLOAD
CPU TRANACT SRVCLS SRVCLASS ACTSYS SYSAFF TOKEN PRTDEST7 *-*
Address SDSF 'ISFEXEC ST (ALTERNATE)'
ISFEXEC ST (ALTERNATE)
8 *-* isfcols2 = ,
'DDNAME STEPN PROCS DSID OCLASS RE
CCNT BYTECNT DSNAME'
DDNAME STEPN PROCS DSID OCLASS RECCNT BYTECNT DSNAME
11 *-* Do i = 1 To isfrows
1
2
12 *-* Address SDSF ISFACT ST TOKEN('token.i') ,
'PARM(NP ?)'ISFACT ST
TOKEN('6jkSNicbJpKic/D1m8LEQNp38PrbwuNA6yKmVtAgRrDmEzI1o1LFTisSNjQ6IReE4
tDw6OPDUEDj+XPw4rJGQOP4fPDrExO
CEgEGCBQ=') PARM(NP ?)
14 *-* Trace N
0
ISF754I Command 'PREFIX S000TBE5' generated from associated variable
ISFPREFIX.
S000TBE.S000TBE5.JOB01687.D002.JESMSGLG
S000TBE.S000TBE5.JOB01687.D003.JESJCL
S000TBE.S000TBE5.JOB01687.D004.JESYSMSG
S000TBE.S000TBE5.JOB01687.D104.?
S000TBE.S000TBE5.JOB01687.D108.?
S000TBE.S000TBE5.JOB01687.D111.?
27 *-* End
11 *-* Do i = 1 To isfrows
12 *-* Address SDSF ISFACT ST TOKEN('token.i') ,
'PARM(NP ?)'ISFACT ST
TOKEN('6jkSNicbJpKic/D1esLEQNp38PrbwuNA67SCN30gRrDmEzI1o1LFTisSNjQ6IReE4
tDw6OPAUEDj+XPw4kpGQOP4c/DhUsT
K4vH1c+PDVMPi8fh849MUliAAAQYbNapb/Q768OPGPQ==') PARM(NP ?)
14 *-* Trace N
0
INVALID COMMAND
ISF754I Command 'PREFIX S000TBE5' generated from associated variable
ISFPREFIX.
S000TBE.S000TBE5.JOB01687.D002.JESMSGLG
S000TBE.S000TBE5.JOB01687.D003.JESJCL
S000TBE.S000TBE5.JOB01687.D004.JESYSMSG
S000TBE.S000TBE5.JOB01687.D104.?
S000TBE.S000TBE5.JOB01687.D108.?
S000TBE.S000TBE5.JOB01687.D111.?
27 *-* End
11 *-* Do i = 1 To isfrows
29 *-* x = Isfcalls('OFF')
0
30 *-* Exit 0
0
***
TIA
Thomas Berg
__
Thomas Berg Specialist IT-U SWEDBANK
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
--
__
Mundus Vult Decipi__
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.
- Benjamin Franklin
Military justice is to justice what military music is to music.
- Groucho Marx
--
For
Re: SVC99
Why is a deadly embrace caused by an authorized program deemed less harmful than one caused by an unauthorized program? I suspect you know that's not what I meant. I think the assumption is that, if you are writing authorized code, you know what you are doing and will take precautions to avoid deadlocks or detect and recover from them. Date: Sat, 3 May 2008 11:36:07 -0500 From: [EMAIL PROTECTED] Subject: Re: SVC99 To: IBM-MAIN@BAMA.UA.EDU On Sat, 3 May 2008 12:23:37 -0400, J R wrote: Probably to ensure that not just anybody can cause a deadly embrace: Why is a deadly embrace caused by an authorized program deemed less harmful than one caused by an unauthorized program? S99WTVOL / S99WTDSN / S99WTUNT / S99OFFLN / S99MOUNT : Use care when you set these flags; setting any one of them might cause a deadlock situation. For example, consider the situation where JOBA owns a resource that JOBB wants and JOBB owns a resource that JOBA wants. If one of the above flags are on, the two jobs will wait until one job is cancelled. -- gil _ Get Free (PRODUCT) RED™ Emoticons, Winks and Display Pics. http://joinred.spaces.live.com?ocid=TXT_HMTG_prodredemoticons_052008 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVC99
That doesn't answer my question. Date: Sat, 3 May 2008 11:34:25 -0500 From: [EMAIL PROTECTED] Subject: Re: SVC99 To: IBM-MAIN@BAMA.UA.EDU Yes the program is authorised. _ Make Windows Vista more reliable and secure with Windows Vista Service Pack 1. http://www.windowsvista.com/SP1?WT.mc_id=hotmailvistasp1banner -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVC99
On Sat, 3 May 2008 14:17:44 -0400, J R wrote: That doesn't answer my question. I know this one! I.e. the program may have been bound with AC=1, but into a non-authorized library; or it may have been invoked by CALL, LINK, ATTACH, or XCTL from a non-authorized parent; or there may have been a non-authorized STEPLIB catenand; any of which would cause it to run non-authorized. (Others?) Date: Sat, 3 May 2008 11:34:25 -0500 From: [EMAIL PROTECTED] Yes the program is authorised. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVC99
On Sat, 3 May 2008 14:14:02 -0400, J R wrote: Why is a deadly embrace caused by an authorized program deemed less harmful than one caused by an unauthorized program? I suspect you know that's not what I meant. I think the assumption is that, if you are writing authorized code, you know what you are doing and will take precautions to avoid deadlocks or detect and recover from them. Is it proper, then, to make the assumption that if two authorized programs fall into a deadlock with each other, and fail to detect or recover, a developer didn't know what he was doing, and at least one of the programs should be APARable? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVC99
Paul Gilmartin wrote: Is it proper, then, to make the assumption that if two authorized programs fall into a deadlock with each other, and fail to detect or recover, a developer didn't know what he was doing, and at least one of the programs should be APARable? APAR = Authorized Program Analysis Report -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVC99
May I have a go at it, too? Someone just helped me figure this out. I haven't learned how to set a trap for something like this yet to get a dump, but I imagine it isn't hard. But from an SVC dump you find the abending TCB. Then from there look at the JSCB. In the BOPTS check if the JSCBAUTH bit is on or off. If off then you are not running authorized. Is that close? Lindy -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: 3. toukokuuta 2008 22:22 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: SVC99 On Sat, 3 May 2008 14:17:44 -0400, J R wrote: That doesn't answer my question. I know this one! I.e. the program may have been bound with AC=1, but into a non-authorized library; or it may have been invoked by CALL, LINK, ATTACH, or XCTL from a non-authorized parent; or there may have been a non-authorized STEPLIB catenand; any of which would cause it to run non-authorized. (Others?) Date: Sat, 3 May 2008 11:34:25 -0500 From: [EMAIL PROTECTED] Yes the program is authorised. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Shop zSeries Ordering Issues
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Schwarz, Barry A Sent: Friday, May 02, 2008 5:14 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Shop zSeries Ordering Issues Yes it's great if you are allowed to connect your system to the internet. For the rest (few?) of us who cannot, we still need maintenance. And while we are on the subject, why does an internet download have to go to a Unix file? Is there some reason SMP/E couldn't handle a normal dataset? If I wanted a Unix system, I would have bought one. You did buy one! z/OS is UNIX, ... and more! You get two clickclick two clickclick two systems in one! (pardons to the Doublemint Gum people) -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVC99
On Sat, 3 May 2008 05:58:25 -0500, Saravanan J wrote: In one of our programs say XYZ, we are accessing USER catalog by dynamically allocating the Catalog using SVC 99 (in shared access mode) to get some dataset related information from the catalog. Before this dynamic allocation we are actually turning-on all the wait bits (S99WTVOL+S99WTDSN+S99WTUNT+S99OFFLN) in S99FLG21 byte. So far so good, but we seem to be getting allocation failures on the catalog in our program XYZ, whenever our catalog compression jobs are running (Catalog compress jobs have exclusive ENQ on the catalog during compress). As per our understanding, the dynamic allocation in XYZ program should wait for the shared access of Catalog as the catalog is locked for exclusive use by Catalog compression jobs. And since the DSN is unavailable to our program XYZ, it should wait for the DSN till the catalog compress job releases the exclusive lock on catalog. Any pointers to why the S99FLG21 wait bits are not working would be of great help to us? I suspect that the problem your program is having has less to do with the SYSDSN enqueue that S99WTDSN was designed to cope with, and more to do with the SYSVSAM enqueue that Catalog management and VSAM use for proper serialization during the catalog compression processes. I do not recall any user control over that SYSVSAM intersect via SVC99. -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVC99
At 05:58 -0500 on 05/03/2008, Saravanan J wrote about SVC99: As per our understanding, the dynamic allocation in XYZ program should wait for the shared access of Catalog as the catalog is locked for exclusive use by Catalog compression jobs. And since the DSN is unavailable to our program XYZ, it should wait for the DSN till the catalog compress job releases the exclusive lock on catalog. If for some reason you can not get it to work why not issue a WTOR stating that the SVC99 failed, do a timed wait on a 2nd ECB and wait on both the WTOR and STIMER ECBs. If the WTOR gets responded to, TTIMER and quit the program. The STIMER ECB getting posted would trigger a DOM of the WTOR and a retry of the SVC99. This will be the equivalent of the SVC99 wait (except for you not being on the ENQ queue and thus subject to having another EXC-ENQ getting issued during your waiting period). I KNOW that this does not answer your question but it does provide a work around of the issue. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MVS booklist again
Bruno's book has been OCRed and can be downloaded from http://www.prycroft6.com.au/misc/ (currently last item on the page). At under 4 meg it is a fair bit smaller than Bruno's original scan, but could not have been created without it. Thanks, Bruno! Cheers, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
