Re: z/OS Control block question
The tcb->tiot chain has worked well for a long time but GETDSAB may provide a longer term solution for new code if the OP is only trying to access the current TIOT for the job step they are running under (see XTIOT). http://publib.boulder.ibm.com/infocenter/zos/v1r11/index.jsp?topic=/com.ibm.zos.r11.ieaa200/iea2a2a0290.htm ...chris. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Walt Farrell Sent: Monday, October 24, 2011 10:22 AM To: IBM-MAIN@bama.ua.edu Subject: Re: z/OS Control block question On Mon, 24 Oct 2011 10:03:58 -0500, Wayne Driscoll wrote: >Walt, >Thanks, I missed an important qualifier what I should have said was "all >non-job step TCB's under a given JSTCB will point to the same TIOT." No, that still doesn't work, Wayne, as it still has that ambiguous ues of "under". I think you really do need to say 'with the same TCBJSTCB" rather than "under a given JSTCB". Consider, for example, the case where you have // EXEC PGM=A where A, running authorized, attaches B and C both as jobstep TCBs, and with separate TIOTs. B then attaches non-jobstep TCBs B1 and B2, which share B's TIOT. C attaches non-jobstep TCBs C1 and C2, which share C's TIOT. In the sense of subtasking, all of B1, B2, C1, and C2 are "under" A, but none share A's TIOT. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption routine from IBM accepting limited set of input characters
Sounds like base-64 encoding, which does not really count as encryption. A-Za-z0-9+/ are the characters. You can search for base64 to get more information. ...chris. > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Hunkeler Peter (KIUK 3) > Sent: Thursday, December 11, 2008 4:31 AM > To: IBM-MAIN@bama.ua.edu > Subject: Encryption routine from IBM accepting limited set of input > characters > > Has anyone heard of an encryption routine from IBM which > only accepts a limited set of characters in the input field > to be encrypted? I was told the routine will refuse working > on any byte which is not part of a "64-character-set". > > I don't know more details at the moment. > > -- > Peter Hunkeler > CREDIT SUISSE > > -- > 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: Controlling the execution sequence of dependant jobs in JES2
If you don't want to make the jobs submit each other and have no scheduling package, there is another alternative using UNIX tools (or windows). We have perl packages to do FTP (although you could also do it in rexx). Using make (or gnumake), you can make each job dependent upon the other. The completion of each job would cause the next to be submitted (make rules can be written to turn a .jcl into a .list or something like that). ...chris. (25+ years (satisfied) user of XDC (nee DBC)) -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Cole Sent: Friday, May 23, 2008 10:19 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Controlling the execution sequence of dependant jobs in JES2 At 5/23/2008 08:25 AM, Mark Zelden wrote: >On Fri, 23 May 2008 04:25:10 -0400, David Cole <[EMAIL PROTECTED]> wrote: > > >Hi, > > > >I have a process that submits up to a couple of hundred jobs for > >execution. I require that these jobs execute in the same order in > >which they were submitted. > > > >For decades I have accomplished this by assigning all of the jobs to > >a specific job class and then insuring that there was never more that > >one initiator that had that job class assigned. > > > >I am now running at a new data center. (Guess where...) And I have > >just discovered that my jobstream is running out of sequence. For > >some reason, my single-threading initiator is selecting jobs from the > >input queue out of sequence. > > > >Is there an "official" way to enforce job execution sequencing? > > > >TIA > > > >Dave Cole REPLY TO: [EMAIL PROTECTED] > >Cole Software WEB PAGE: http://www.colesoft.com > >736 Fox Hollow RoadVOICE:540-456-8536 > >Afton, VA 22920FAX: 540-456-6658 > > > >Schedrun? :-) Nope. :-( Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- 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: C++ Workable Mainframe Debuggers
I have been using z/XDC to debug C++ for years (before it was even
called z/XDC). Of course, you have to be able to read assembler to do
so without any source code support. The assembler listings from the
compiler are pretty much the same as any assembler listing and the
compiler code generation becomes quite familiar after awhile.
If you developers don't know assembler very well, this may not work for
them.
...chris.
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of David Logan
Sent: Monday, April 14, 2008 8:36 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: C++ Workable Mainframe Debuggers
Does "C Source code support" also mean C++?
David Logan
Manager of Product Development, Pitney Bowes Software, Inc.
http://centrus.com
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf
Of David Cole
Sent: Sunday, April 13, 2008 5:10 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: C++ Workable Mainframe Debuggers
>Cole Software's z/XDC - no
We are on the verge of publishing C Source code support ("c/XDC") to
beta testers.
More soon.
Dave Cole
At 4/13/2008 05:53 AM, you wrote:
>If you're debugging C/C++ on z/OS:
>
>1. There's dbx for UNIX System Services (only):
>
>http://www.ibm.com/servers/eserver/zseries/zos/unix/bpxa1dbx.html
>
>No charge.
>
>2. IBM Debug Tool for z/OS is available. IBM has introduced a new
version
>annually for years now, so you want to stay current and take a fresh
look
>if you remember an old version. Version 7, in particular, introduced
some
>substantial C++ related improvements. Version 8 is current. I see a lot
of
>old Debug Tool installed out there, unfortunately.
>
>You can license Debug Tool as MLC or, in the form of the Debug Tool
>Utilities & Advanced Functions superset product, as OTC with
subscription.
>As you prefer.
>
>Unfortunately for z/OS 1.5 you'll be limited to Debug Tool (or DTU&AF)
>Version 7, so please try to get your z/OS release updated as soon as
you
>can, at least for the development LPAR(s) where you're most likely to
be
>debugging. You may be able to work with IBM to order DT or DTU&AF
Version 8
>and arrange temporary use of Version 7; can't hurt to ask. Actually, as
I
>write this Debug Tool V7 MLC is still orderable so no harm there, but
for
>reasons of subscription you'll want to order DTU&AF V8 if you go the
OTC
>route.
>
>For graphical debugging use Rational Developer for System z (or
WebSphere
>Developer Debugger for System z) in conjunction with Debug Tool (or
>DTU&AF). I think those tools also provide graphical debugging with dbx
now.
>Very slick.
>
>A certain popular IBM-MAIN training firm has a course on C/C++
debugging.
>Details here:
>
>http://www.trainersfriend.com/C_courses/N735descr.htm
>
>3. There are a number of commercial debugger products for z/OS, most
>already mentioned. However, many (all?) of them don't support C++.
Here's
>the latest information I have, and someone please correct me if my
>information is out of date:
>
>Cole Software's z/XDC - no
>CA-InterTest - no
>Compuware's Xpediter - C yes, C++ ?
>Gary Bergman Associates' Advanced Debugging System (ADS) for CICS - C
yes,
>C++ ?
>Macro4's Tracemaster - no
>MacKinney Systems' Track and Xray - no
>ASG's (formerly Viasoft's) SmartTest - no
>Serena's StarTool ATD - product withdrawn?
>
>- - - - -
>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
--
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
Connex was RE: ATMs (Was: High order bit in 31/24 bit address)
I have a wine coloured mug that says Connex on one side and A.O. Smith Data Systems on the other. I worked at a large Canadian bank and we had a joint project going with IBM in the late 80s/early 90s. We installed the Connex software for an internal system with an eye to IBM marketing it as part of the joint project. This was not EFT related at all and I think it was before any of the other banks used it for the inter-bank EFT. The Connex team (mostly one guy - a contractor out of San Francisco who eventually went to Compuware) wrote an API to provide the services our software needed. Our software provided store and forward and workflow services for messaging between the PC and the mainframe. This was phase I. While we were working on phase II, we started talking to IBM Hursley about a new store and forward system they were working on. It was called MQ and was pretty much the death knell for our joint project. ...chris. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Saturday, November 10, 2007 8:48 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: ATMs (Was: High order bit in 31/24 bit address) >AOSmith=>Deluxe=>DeluxeData=>DeluxeEelectronicPaymentSystems(DEPS)=>eFu nds. You're correct! My bad! It was Deluxe. Fault of a failing memory. (Still thought it was a funny choice of name -- in a league with ACME) -- 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: z/OS 1.8 Conditional Storage Obtain/Getmain Return Code
Thanks for pointing out the doc. Time to re-read chapter 2. Should have searched the assembler list (as Ed pointed out) and the guide (instead of browsing the TOC for a suitable subject). Doesn't this make the doc change in the reference (storage/obtain/return codes) redundant? Back to mostly lurking. ...chris. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Peter Relson Sent: Friday, October 26, 2007 6:28 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: z/OS 1.8 Conditional Storage Obtain/Getmain Return Code The general rule is this: Unless otherwise documented, the return code is 4 bytes wide. That means use of LTGR is incorrect in the general case.. Unless otherwise documented, the high halves of GPRs 0, 1, and 15 (and ARs 0, 1, 14 and 15) are unpredictable on return from any service. I am unaware of any exceptions to this. Not that I tend to be a slave to what is documented versus what is not, from the assembler services guide: 2.1 Saving the Calling Program's Registers http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.8 Conditional Storage Obtain/Getmain Return Code
The behavior does differ. The change is that r15 now contains something in bits 0-31. This has been verified by clearing r15 prior to the getmain and getting the same result. While I understand the doc change now indicates this can happen, it is not in an obvious location. I experienced the problem with a getmain and searched through the getmain doc. Even in storage obtain, it should also be doc'ed in the output register information. Part of the concern here is whether the use of LTGR is valid after any SVC/PC/callable service or, it can be used with some or, it must be used with some. The posting was to let others know about the change in behavior (intended or otherwise). You are correct about AMODE 64 has nothing to do with it - part of the poorly doc'ed comment. ...chris. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jim Mulder Sent: Thursday, October 25, 2007 4:22 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: z/OS 1.8 Conditional Storage Obtain/Getmain Return Code IBM Mainframe Discussion List wrote on 10/25/2007 03:20:31 PM: > News to me and I could not find any trace in the archives. > > With z/OS v1.8 and later, r15 behavior has changed for a conditional > storage obtain/getmain. For a successful request, the register may > contain: 0010_ > > IBM has (poorly) documented this behavior at > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2A980/67.2 > 8?SHELF=IEA2BK80&DT=20070514031429&CASE= > > Which states: > > When running in an AMODE64 environment, only the low half of GPR15 > contains a return code. There is no guarantee for the contents of the > high half of GPR15. I don't think that VSM changed the r15 behavior in z/OS v1.8. More likely, someone requested that the documentation be updated to attempt to better describe the existing behavior. However, as you point out, "an AMODE64 environment" is rather nebulous terminology, and in fact Amode has nothing to do with this. The fact is that VSM sets a return code in bits 32-63 of GPR15, and does not at that point do anything to change the contents of bits 0-31 of GPR15, and that is the same behavior which existed prior to z/OS v1.8. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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
z/OS 1.8 Conditional Storage Obtain/Getmain Return Code
News to me and I could not find any trace in the archives. With z/OS v1.8 and later, r15 behavior has changed for a conditional storage obtain/getmain. For a successful request, the register may contain: 0010_ IBM has (poorly) documented this behavior at http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2A980/67.2 .8?SHELF=IEA2BK80&DT=20070514031429&CASE= Which states: When running in an AMODE64 environment, only the low half of GPR15 contains a return code. There is no guarantee for the contents of the high half of GPR15. IOW, do not use LTGR to test for a successful getmain/storage obtain unless preceded by LLGFR. ...chris. bmcsoftware 10431 Morado Circle Austin, Tx. 78759 -- 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: TSO Unallocate Dataset.
ISRDDN was added to the ISPF command tables as DDLIST at some point (as was DSLIST). DDLIST0 SELECT PGM(ISRDDN) NEWAPPL(ISR) SUSPEND SCRNAME(DDLIST) Formal documentation: Summary of Changes for z/OS 01.02.00 ISPF o The ISRDDN utility is now documented in the ISPF User's Guide. ...chris. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Chiam, Susan Mee-Shia Sent: Friday, July 22, 2005 6:37 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: TSO Unallocate Dataset. We do nothing of that kind here, we do not restrict the use of ISRDDN. In fact I told security about it as he wants to see his datasets allocation for his TSO. I am encouraging them to use and they just learned about "SJ" on the output in SDSF. Every new thing they are learning from me, they question me "is this a tool for sysprog?". I must say that most sysprogs make use of handy tools/sharewares that we port them to most sites. I suppose you can call these 'tools of the trade'. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Richards.Bob Sent: Friday, 22 July 2005 5:45 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: TSO Unallocate Dataset. ISRDDN is no more a sysprog tool than LISTA. Sure, it has more functionality, but what are you afraid of? That your users might screw up some datasets? There are lots of ways for them to do that anyway. Teach them how it works and why it is useful. Empower them with a little knowledge. Make a friend and save a future phone call. Bob -- 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
