Re: JES2 - get system name without JCT addressability.

[Lizette Koehler]

I am not sure if this will help, but there is a JES2 List that might be able to 
provide some guidance.

To join, if you have not done so, go here
http://listserv.vt.edu/cgi-bin/wa?A0=jes2-l

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Leonardo Vaz
> Sent: Wednesday, September 02, 2015 8:06 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JES2 - get system name without JCT addressability.
> 
> I knew I had to be missing something! Thank you very much John! "You're da 
> best!"
> I'll give it a shot!
> 
> Regards,
> Leonardo Vaz
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John McKown
> Sent: Wednesday, September 02, 2015 10:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JES2 - get system name without JCT addressability.
> 
> $CBIO doesn't work? It has an input parameter of MTTR with it says is a SPOOL 
> TTR.
> ref: http://publibfp.dhe.ibm.com/epubs/pdf/has2q000.pdf
> 
> MTTR= Specifies the label of, or a register that contains, the spool track 
> address of
> the record to be read or written. If you specify a register, the spool MTTR 
> (module
> track record) must be loaded into the designated register before executing 
> this
> macro instruction. MTTR is required for TYPE=READ or TYPE=WRITE, but is not
> allowed with TYPE=WAIT.
> 
> 
> On Wed, Sep 2, 2015 at 9:29 AM, Leonardo Vaz  wrote:
> 
> > Thanks for the help guys! You understand my problem now, so from the
> > system I'm executing the command from It's not trivial to get the
> > system where the job is running, the easiest field I found is
> > JCTMVSNM, but JCT is probably not resident on the system I'm executing
> > the command from, I think that's why JQE points to the track on the
> > spool where I can find the JCT, but I still couldn't figure out how to read 
> > that track
> on the spool.
> >
> > It doesn't sound something extraordinary, but something rather simple,
> > but I've learned a while ago that assembler is rarely simple.
> >
> > Thanks and regards,
> > Leonardo Vaz
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Charles Mills
> > Sent: Tuesday, September 01, 2015 8:01 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: JES2 - get system name without JCT addressability.
> >
> > Ah. It seemed like too simple an answer; that's why I was kind of
> > tentative.
> > At least now I understand the problem.
> >
> > Could one determine "which member of the JES plex" somehow and then
> > have a table that mapped that "which" to the actual system name? Or
> > does this have to be more portable than that (such as for a vendor product)?
> >
> > Charles
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of J O Skip Robinson
> > Sent: Tuesday, September 01, 2015 4:49 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: JES2 - get system name without JCT addressability.
> >
> > I was going to reply similarly, but I then noticed that OP is talking
> > about a running job, not necessarily the current system. A job can be
> > running on any member of the JES plex. I don't have an easy answer for
> > that question.
> >
> > --
> > 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
> >
> 
> 
> 
> --
> 
> Schrodinger's backup: The condition of any backup is unknown until a restore 
> is
> attempted.
> 
> Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.
> 
> He's about as useful as a wax frying pan.
> 
> 10 to the 12th power microphones = 1 Megaphone
> 
> 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: IBM z/OS Internet Library trimmed to z/OS 1.13 and above

[Lizette Koehler]

And those releases are out of support.

However, try this.  See if this works for older releases:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves?filter=z%2Fos+v1=Find

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Gord Tomlin
> Sent: Wednesday, September 02, 2015 9:45 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IBM z/OS Internet Library trimmed to z/OS 1.13 and above
> 
> I went to my usual place to view z/OS manuals today (http://www-
> 03.ibm.com/systems/z/os/zos/library/bkserv/index.html),
> and discovered that the links to releases prior to z/OS 1.13 have now been 
> removed.
> 
> So much for being able to go back and research what release introduced a new
> facility or enhancement.
> 
> --
> 
> Regards, Gord Tomlin
> Action Software International
> (a division of Mazda Computer Corporation)
> Tel: (905) 470-7113, Fax: (905) 470-6507

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

Re: IBM z/OS Internet Library trimmed to z/OS 1.13 and above

[Charles Mills]

The rapid dropping of support for "traditional" manuals really ticks me off.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gord Tomlin
Sent: Wednesday, September 02, 2015 9:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IBM z/OS Internet Library trimmed to z/OS 1.13 and above

I went to my usual place to view z/OS manuals today 
(http://www-03.ibm.com/systems/z/os/zos/library/bkserv/index.html),
and discovered that the links to releases prior to z/OS 1.13 have now been 
removed.

So much for being able to go back and research what release introduced a new 
facility or enhancement.

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

Re: how to know the length and blocksize of each member in dataset

[J O Skip Robinson]

This is not exactly what was requested by OP, but the PDS command and its 
program product heir StarTool will produce member stats with the VERIFY 
subcommand. See sample output below for a whole member list scan. VERIFY can 
also be used on a single member. I don't know of any way to display every block 
of every member. Sounds like TMI to me. ;-)

As for why not '32,767' for maximum blocksize, I've never heard a cogent 
explanation for the original choice, but the justification for leaving it at 
32,760 is self-evident: a huge amount of work ($$$) all over the OS in order to 
gain 7 bytes out of 32K. A miserable ROI.


VERIFY :
PDS111I 2,061 physical blocks were input 
PDS112I 32,760 characters in the largest physical block  
PDS113I 1,464 characters per average physical block  
PDS114I 0 tracks could be regained by compressing this data set  
PDS115I 137 members were checked 
 
PDS130I The following is a track usage map of the data set   
PDS130I DXXX 
PDS130I XL.  
 
PDS118I 52 members RMODE24; size is 1,294K   
PDS119I 76 members RMODEANY; size is 2,171K  

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, September 02, 2015 4:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: how to know the length and blocksize of each member in dataset

On Wed, 2 Sep 2015 07:32:15 -0400, John Eells wrote:

>elardus.engelbre...@sita.co.za wrote:
>
>> Mind you, max blocksize is 32768, but that info is useless. AMBLIST can 
>> *probably* help you, but ...
>
>The maximum block size for z/OS is actually 32760.  (We have to reserve 
>space for those pesky RDWs and BDWs.)
> 
No, the block size counts the BDW and RDWs, so the longest data portion is 
32752.

The count in a CCW allows up to 65535.  Originally, a smaller value was chosen 
because the s/360 hardware has no direct support for unsigned halfword 
arithmetic.  It could have been done, SMOP, but with added code at a time when 
storage was precious.  And using more than 32 Kib for a buffer was likewise 
unthinkable.

Why not 32767?  The best explanation I've gotten here is that the access method 
requires a few overhead bytes with each buffer, and there is (was?) a desire to 
obtain buffer storage page-aligned.

Bad History.  Otherwise, full track on a 3390 would be practical.

And 32768 is reserved for LRECL=X.

-- gil

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

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

Re: IBM z/OS Internet Library trimmed to z/OS 1.13 and above

[John Eells]

gt.ibm.li...@actionsoftware.com (Gord Tomlin) wrote:

I went to my usual place to view z/OS manuals today
(http://www-03.ibm.com/systems/z/os/zos/library/bkserv/index.html),
and discovered that the links to releases prior to z/OS 1.13 have now
been removed.

So much for being able to go back and research what release introduced a
new facility or enhancement.



I'm told they'll be back "soon," probably at the bottom of the page 
under a new heading that says, in effect, "Ye Olde Books Below."


--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

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

IBM z/OS Internet Library trimmed to z/OS 1.13 and above

[Gord Tomlin]

I went to my usual place to view z/OS manuals today
(http://www-03.ibm.com/systems/z/os/zos/library/bkserv/index.html),
and discovered that the links to releases prior to z/OS 1.13 have now 
been removed.


So much for being able to go back and research what release introduced a 
new facility or enhancement.


--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507

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

Re: IBM z/OS Internet Library trimmed to z/OS 1.13 and above

[Ed Finnell]

Seems like 'Page under Destruction' would be apropos.
 
 
In a message dated 9/2/2015 11:56:27 A.M. Central Daylight Time,  
ee...@us.ibm.com writes:

I'm told  they'll be back "soon," probably at the bottom of the page 
under a new  heading that says, in effect, "Ye Olde Books  Below."


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

Re: Source for "98% of the checking transactions flow through a mainframe" type statements

[Steve Thompson]

On 09/02/2015 08:29 PM, Charles Mills wrote:

I have seen an IBM SHARE keynote or the like where IBM rolled out a bunch of
statements like

98% of the checking transactions pass through a mainframe
72% of the credit card transactions involve a mainframe
etc.


I read somewhere that 98.6% of all statistics quoted like that 
are made up on the spot


Just say'n'.

Regards,
Steve Thompson

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

Source for "98% of the checking transactions flow through a mainframe" type statements

[Charles Mills]

I have seen an IBM SHARE keynote or the like where IBM rolled out a bunch of
statements like

98% of the checking transactions pass through a mainframe
72% of the credit card transactions involve a mainframe
etc.

I would like to use those statements in a presentation (for an audience that
will mostly think the mainframe is dead). Does anyone have a link or a Web
page with those IBM statements on it?

IBM keynotes never seem to have available handouts.

Thanks,

Charles Mills
Consulting in Business & Technology
CharlesMillsConsulting.com
+1-707-291-0908

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

Re: Source for "98% of the checking transactions flow through a mainframe" type statements

[Bill Godfrey]

On Wed, 2 Sep 2015 22:58:31 -0500, Bill Godfrey wrote:

>On Wed, 2 Sep 2015 17:29:54 -0700, Charles Mills wrote:
>
>>I have seen an IBM SHARE keynote or the like where IBM rolled out a bunch of
>>statements like
>>
>>98% of the checking transactions pass through a mainframe
>>72% of the credit card transactions involve a mainframe
>>etc.
>>
>>I would like to use those statements in a presentation (for an audience that
>>will mostly think the mainframe is dead). Does anyone have a link or a Web
>>page with those IBM statements on it?
>>
>>IBM keynotes never seem to have available handouts.
>>
>>Thanks,
>>
>>Charles Mills
>>Consulting in Business & Technology
>>CharlesMillsConsulting.com
>>+1-707-291-0908
>>
>Here's one.
>http://www.share.org/p/bl/et/blogid=2=234
>
>Bill
>
I should add that I know it isn't an IBM statement.

Bill

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

Re: Smaller Private Area in DR

[Jim Mulder]

> I have been reviewing the data for private and am puzzled with what I 
see.
> The data from PROD taken with SYSVIEW is as follows;
> 
> RegionStart
> EndLength   Bytes  Used
> RONUC _00FE3000 _00FF _0001D000  116K 
113K
> RWNUC_00FD4000 _00FE2FFF _F000
> 60K55.9K
> SQA  _00EB5000 _00FD3FFF _0011F000 1.12M
> 502K
> PLPA_00C98000  _00EB4FFF _0021D000 2.11M
> 2.11M
> FLPA_   _ _
> 0 0
> MLPA_  _ _
> 0 0
> CSA  _0080  _00C97FFF _00498000
> 4.59M  791K
> PVT  _6000  _007F _007FA000
> 7.98M  655K
> RCT _2000   _5FFF _4000
> 16Kn/a
> PSA _   _1FFF _2000
> 8Kn/a
> 
> From Parmlib;
> 
> CSA=(4100K,150M)
> SQA=(384K,24M)
> 
> According to this map, the system has allocated about 200+K more for SQA
> and about 500K more for CSA. Everything aligns on the 8M boundary
> and this is fine in production.
> 
> However, in DR we lost a meg and private dropped to 7M. Given that more
> than half of SQA is unused and only a fraction of CSA is used, my
> expectation is that there was ample storage to accommodate a bigger I/O
> configuration and still stay with the 8M boundary. The big assumption is
> that my problem in DR was the I/O configuration. Whatever increased in 
DR
> had to be pretty large is my thinking.
> 
> Many of you stated how important it was to define CSA to fall around a 
1/2M
> boundary. Our CSA allocation of 4.1M takes common to around the 7.33M 
mark
> leaving private with 8M. How does this look to you?
> 
> The CSA allocation seems to be unnecessarily large and I can't explain 
it
> as I am new to the shop. That however is a separate issue.

  The first thing I would do, using a dump of PROD and a dump of DR,
is for each dump, under IPCS, do

IOSCHECK ALLUCBS
FIND 'UCB AT 00' ALL

  This will count the number of UCBs in SQA below 16MB.


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

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

Re: Source for "98% of the checking transactions flow through a mainframe" type statements

[Bill Godfrey]

On Wed, 2 Sep 2015 17:29:54 -0700, Charles Mills wrote:

>I have seen an IBM SHARE keynote or the like where IBM rolled out a bunch of
>statements like
>
>98% of the checking transactions pass through a mainframe
>72% of the credit card transactions involve a mainframe
>etc.
>
>I would like to use those statements in a presentation (for an audience that
>will mostly think the mainframe is dead). Does anyone have a link or a Web
>page with those IBM statements on it?
>
>IBM keynotes never seem to have available handouts.
>
>Thanks,
>
>Charles Mills
>Consulting in Business & Technology
>CharlesMillsConsulting.com
>+1-707-291-0908
>
Here's one.
http://www.share.org/p/bl/et/blogid=2=234

Bill

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

Re: Smaller Private Area in DR

[phil yogendran]

Hello All,

I have been reviewing the data for private and am puzzled with what I see.
The data from PROD taken with SYSVIEW is as follows;

RegionStart
EndLength   Bytes  Used
RONUC _00FE3000 _00FF _0001D000  116K  113K
RWNUC_00FD4000 _00FE2FFF _F000
60K55.9K
SQA  _00EB5000 _00FD3FFF _0011F000  1.12M
502K
PLPA_00C98000  _00EB4FFF _0021D000  2.11M
2.11M
FLPA_   _ _
0 0
MLPA_  _ _
0 0
CSA  _0080  _00C97FFF _00498000
4.59M  791K
PVT  _6000  _007F _007FA000
7.98M  655K
RCT _2000   _5FFF _4000
16Kn/a
PSA _   _1FFF _2000
8Kn/a

>From Parmlib;

CSA=(4100K,150M)
SQA=(384K,24M)

According to this map, the system has allocated about 200+K more for SQA
and about 500K more for CSA. Everything aligns on the 8M boundary
and this is fine in production.

However, in DR we lost a meg and private dropped to 7M. Given that more
than half of SQA is unused and only a fraction of CSA is used, my
expectation is that there was ample storage to accommodate a bigger I/O
configuration and still stay with the 8M boundary. The big assumption is
that my problem in DR was the I/O configuration. Whatever increased in DR
had to be pretty large is my thinking.

Many of you stated how important it was to define CSA to fall around a 1/2M
boundary. Our CSA allocation of 4.1M takes common to around the 7.33M mark
leaving private with 8M. How does this look to you?

The CSA allocation seems to be unnecessarily large and I can't explain it
as I am new to the shop. That however is a separate issue.

Your comments are much appreciated.

Thanks



On Mon, Aug 31, 2015 at 1:34 PM, J O Skip Robinson  wrote:

> I think a lot of shops use this strategy for managing the common/private
> boundary.
>
> 1. Look at a running system.
> 2. Verify that the system is happy with defined CSA/SQA.
> 3. Verify that the private area is 'satisfactory', i.e. not too small nor
> needlessly large.
> 4. Calculate the contribution to CSA/SQA that IEASYSxx values have added
> to the z/OS requirement.
> 5. Adjust the IEASYSxx values to the midpoint of the final 1M portion.
>
> Since the user specification will tweak the 1M boundary placement, we aim
> to maximize any possible fluctuation that will preserve the private area
> sweet spot. That is, allow for 512K up or down in z/OS calculation without
> changing private area, which many (most?) systems are most sensitive to.
> OP's problem after all is to explain a 1M drop in private, not a change to
> common.
>
> BTW I looked at my VSM health checks but did not see this information
> displayed starkly.
>
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 626-302-7535 Office
> 323-715-0595 Mobile
> jo.skip.robin...@sce.com
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter Relson
> Sent: Saturday, August 29, 2015 6:55 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Smaller Private Area in DR
>
> 
> The real question is when the COMMON/PRIVATE boundary gets set. IODF must
> be read and digested very early in IPL, certainly before SYS1.PARMLIB is
> opened. By the time IEASYSxx is processed, do below-the-line UCBs figure
> into the boundary calculation?
> 
>
>
> It works something like this:
>
> -- Load the nucleus. Thus we have a definition for where that starts and
> ends.
> -- Build things such as UCB's that require common storage (think of that
> as initial SQA)
> -- Read system parameters to see the definitions of SQA, CSA
> -- Now determine the boundary of SQA (multiple of 64K?) based on the
> initial SQA and the SQA specification
> -- Now build LPA
> -- Use the LPA boundaries and the CSA size to define the CSA boundaries
> (1M multiple?)
> -- That is when the Common/Private boundary is set
>
> Any differences in the "earlier" areas can affect the Common/Private
> boundary.
>
> I seem to recall (but might be wrong) that one of the VSM health checks
> reports on how close you are to the point where you will lose 1M of private.
>
> 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 

Re: how to know the length and blocksize of each member in dataset

[John Eells]

The root of this problem is poorly chosen block sizes for the output 
data sets that contain load modules.  Always, always, always use a block 
size of 32760 for RECFM U data sets that contain load modules and move 
them around using COPYMOD.  Specify PARM=SPCLCMOD so you don't get 
warning messages about the few modules that COPYMOD won't reblock.  (It 
will do what you want; don't worry, be happy...just use BLKSIZE=32760 
and COPYMOD with PARM=SPCLCMOD.)


That will make this entire issue evaporate.  As a bonus, your load 
libraries will likely take less space (never more) and performance might 
improve slightly (and will never be worse).


To partly answer what you asked: What I believe you think you want to 
find is the length of the longest text record, not the length of the 
member.  Each member of a load library comprises some number of text 
records of variable length (up to the block size) and a number of other 
records.  If you search the archives you will find a lengthy post I 
wrote some years ago that explains how the Binder and IEBCOPY write text 
records that will probably shed some light on what you are seeing.  And, 
you can look up which record contains the length of the next text record 
and process those records to get that information if you choose to.


However, finding the length of the longest text record in a load library 
as a means for trying to prevent IEB188I messages or their rarer COPYMOD 
counterparts is, in my opinion, not a productive use of time when the 
best and smoothest road to improvement is paved with the right choice of 
block size.



ibmm...@foxmail.com (ibmmain) wrote:

Hi
   Which length do you mean?  The length of the member?

   We want to know the length of the member.

  When we copy some members in a loadlib to other one,we  received the IEB188I 
message, and only want to copy the dataset

Later we used COPYMOD instead of a COPY  to do this.

However, We want to know the length of the member in the new LOADLIB .We wonder 
wherther record with length is longer than blocksize in the new dataset

Thanks a lot!



--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: how to know the length and blocksize of each member in dataset

[John Eells]

elardus.engelbre...@sita.co.za (Elardus Engelbrecht) wrote:


Mind you, max blocksize is 32768, but that info is useless. AMBLIST can 
*probably* help you, but ...


The maximum block size for z/OS is actually 32760.  (We have to reserve 
space for those pesky RDWs and BDWs.)


--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: QNAMEs (was: ENQ rname_addr description)

[Peter Relson]

>I can imagine a DoS attack in which an unauthorized user bogarts a 
QNAME/RNAME
>generally used by an authorized facility.

And that is why use of non-authorized QNAMEs by an authorized caller is 
poor form.

In some cases existing QNAMEs that are not SYSZ have been made 
authorized-only (thus protecting that qname from being used by an 
unauthorized caller) to save the exploiter from having to change (as 
sometimes such a change would have adverse effects not only on the 
exploiter but on others that legitimately rely on the qname/rname).

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: how to know the length and blocksize of each member in dataset

[Elardus Engelbrecht]

John Eells wrote:

>> Mind you, max blocksize is 32768, but that info is useless. AMBLIST can 
>> *probably* help you, but ...

>The maximum block size for z/OS is actually 32760.  (We have to reserve space 
>for those pesky RDWs and BDWs.)

Ouch. Ouch. Ouch. 

Sorry, I'm wrong, perhaps I played too much with SMF... and its very extra 
loong BLKSIZE...

You're absolutely right of course. Many thanks for your kind reminder.

Groete / Greetings
Elardus Engelbrecht

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

Re: how to know the length and blocksize of each member in dataset

[Paul Gilmartin]

On Wed, 2 Sep 2015 07:32:15 -0400, John Eells wrote:

>elardus.engelbre...@sita.co.za wrote:
>
>> Mind you, max blocksize is 32768, but that info is useless. AMBLIST can 
>> *probably* help you, but ...
>
>The maximum block size for z/OS is actually 32760.  (We have to reserve
>space for those pesky RDWs and BDWs.)
> 
No, the block size counts the BDW and RDWs, so the longest data portion
is 32752.

The count in a CCW allows up to 65535.  Originally, a smaller value was chosen
because the s/360 hardware has no direct support for unsigned halfword
arithmetic.  It could have been done, SMOP, but with added code at a time
when storage was precious.  And using more than 32 Kib for a buffer was
likewise unthinkable.

Why not 32767?  The best explanation I've gotten here is that the access
method requires a few overhead bytes with each buffer, and there is (was?)
a desire to obtain buffer storage page-aligned.

Bad History.  Otherwise, full track on a 3390 would be practical.

And 32768 is reserved for LRECL=X.

-- gil

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

Re: FTP - how get RDW and ASCII

[Shmuel Metz (Seymour J.)]

In <0fac01d0e4c7$1cbd7eb0$56387c10$@mcn.org>, on 09/01/2015
   at 08:01 AM, Charles Mills  said:

>I have a legacy dataset in VB format. I would like to FTP it to a PC
>(1) translating the record data to ASCII and (2) preserving the LLBB
>record control words.

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

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

Re: QNAMEs (was: ENQ rname_addr description)

[Paul Gilmartin]

On Tue, 1 Sep 2015 10:03:46 -0500, Walt Farrell wrote:
>>>
>>I can imagine a DoS attack in which an unauthorized user bogarts a QNAME/RNAME
>>generally used by an authorized facility.  But such contention could arise 
>>entirely
>>among unauthorized users.
>
>Yes, contention could arise strictly between unauthorized users, and that is 
>OK in the sense that it could not contribute to a system integrity exposure.
>
>>Are there, perhaps, RACF rules to restrict use of selected QNAMEs to 
>>specified user profiles?
>
Alas, the system is designed to protect itself from mischievous users, but not 
to protect
the mischievous users from each other.

But maybe it doesn't matter.  I wonder if Bad Things happen if the mischievous
user simply codes:

//STEP  EXEC  PGM=IEFBR14,COND=(0,LE)
//FILE  DDDISP=OLD,DSN=SYS1.LINKLIB  (SYS1.**, ad lib.)

-- gil

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

Re: opinion: "upgrade" use of CCSID in JCL.

[Paul Gilmartin]

On Wed, 2 Sep 2015 07:38:11 -0500, John McKown wrote:

>I am wondering if anyone else thinks that it might be useful for IBM to
>make an enhancement to BSAM/QSAM support for the CCSID parameter in JCL.
>
>ref:
>http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2b6a0/12.9
>
>
>Purpose
>
>You can request the access method to convert data between the coded
>character set identifier (CCSID) specified on the JOB or EXEC statement and
>the CCSID specified on the DD statement. Data conversion is supported on
>access to ISO/ANSI Version 4 tapes using access methods BSAM or QSAM, but
>not using EXCP.
>
>
>Why does this only support ASCII tapes? Would it be helpful to generalize
>it to any data source read or written by BSAM/QSAM?
>​ Of course, this is only of use for "pure text" data sets. But it might
>address the recent thread on FTP'ing a VB data set, keeping the LLBB field
>intact but translating the "data" portion to ASCII.
> 
Yes, yes, yes.  This is another instance of IBM's implementing a valuable
facility but with unduly restrictive scope, perhaps at the wrong implementation
layer.  (Does the code reside in the tape driver?  Even if so, why restrict
it to ISO/ANSI tapes?)

Related:  I can use SDSF to extract SYSOUT to UNIX files.  I'd like to tag
those files with CCSID for possible subsequent conversion to Unicode.
How can I determine the effective CCSID for a SYSOUT.  UCS and/or
CHARS appear to carry similar information: how to render code points
as viewable glyphs/graphemes.  Is there a table, somewhere, that
relates UCS or CHARS to CCSID?

And a disappointment.  If I have a file tagged CCSID=1047, FORMAT=NL,
and I use pax to convert it to ASCII, the resultant files appear tagged
CCSID=819, FORMAT=NL.  But the NLs are converted to LFs, so the
FORMAT should be LF.  Submitted SR.  Got WAD.

-- gil

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

Re: QNAMEs (was: ENQ rname_addr description)

[John McKown]

On Wed, Sep 2, 2015 at 8:22 AM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Wed, 2 Sep 2015 07:17:47 -0500, John McKown wrote:
> >
> >> //STEP  EXEC  PGM=IEFBR14,COND=(0,LE)
> >> //FILE  DDDISP=OLD,DSN=SYS1.LINKLIB  (SYS1.**, ad lib.)
> >>
> >​A JOB with that particular DSN in it with DISP=OLD will never run.
> >SYS1.LINKLIB is share enqueued by both LLA and XCFAS on a normally running
> >system. ​
> >
> Understood that it will "never run".  However, I believe it will linger in
> an
> initiator in job setup requesting ENQ EXC, thereby preventing any other
> jobs' allocating that DSN.
>
> And tying up the initiator to boot.
>

​Until the "mad sysprog" (present!) decides to stuff the person (note
proper use of non-sexist pronoun) down the elevator shaft. Or, as I
actually did back when the system was "unavailable" on Sundays, set an
obnoxious user's RACF id to not allow them to log on (in this case on
Sundays). guy kept running tape jobs (pre-ATL) and complaining when they
would time out due to no operators on site.​



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



-- 

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

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: QNAMEs (was: ENQ rname_addr description)

[Vernooij, CP (ITOPT1) - KLM]

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: 02 September, 2015 15:23
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: QNAMEs (was: ENQ rname_addr description)

On Wed, 2 Sep 2015 07:17:47 -0500, John McKown wrote:
>
>> //STEP  EXEC  PGM=IEFBR14,COND=(0,LE)
>> //FILE  DDDISP=OLD,DSN=SYS1.LINKLIB  (SYS1.**, ad lib.)
>>
>​A JOB with that particular DSN in it with DISP=OLD will never run.
>SYS1.LINKLIB is share enqueued by both LLA and XCFAS on a normally running
>system. ​
> 
Understood that it will "never run".  However, I believe it will linger in an
initiator in job setup requesting ENQ EXC, thereby preventing any other
jobs' allocating that DSN.

And tying up the initiator to boot.

-- gil

--

No JCL needs to and should allocate SYS1.LINKLIB, because it is in the LNKLST.

Kees.


For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286




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

Re: QNAMEs (was: ENQ rname_addr description)

[Paul Gilmartin]

On Wed, 2 Sep 2015 08:30:49 -0500, John McKown  wrote:
>
>​Until the "mad sysprog" (present!) decides to stuff the person (note
>proper use of non-sexist pronoun) down the elevator shaft. ...​
>
For gender inclusiveness, I sometimes use "(fe)malefactor".


On 2015-09-02, at 07:32, Vernooij, CP (ITOPT1) - KLM wrote:

>No JCL needs to and should allocate SYS1.LINKLIB, because it is in the LNKLST.
>
Perhaps to control library search order, as:

//STEPLIB  DD  DISP=SHR,DSN=SYS1.LINKLIB
//DD  DISP=SHR,DSN=

And I sometimes run Binder experiments with:

//STEPEXEC  PGM=IEWL
//SYSLIB  DD  DISP=SHR,DSN=SYS1.LINKLIB

On Wed, 2 Sep 2015 08:43:54 -0500, John McKown wrote:
>
>​I think that both Gil and I are assuming malevolent intent to do a denial
>of service. 
>
(Or femalevolent.)  But Kees was suggesting that the DoS would be ineffective
because it impacts no one.

-- gil

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

Re: QNAMEs (was: ENQ rname_addr description)

[John McKown]

On Wed, Sep 2, 2015 at 8:32 AM, Vernooij, CP (ITOPT1) - KLM <
kees.verno...@klm.com> wrote:

>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: 02 September, 2015 15:23
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: QNAMEs (was: ENQ rname_addr description)
>
> On Wed, 2 Sep 2015 07:17:47 -0500, John McKown wrote:
> >
> >> //STEP  EXEC  PGM=IEFBR14,COND=(0,LE)
> >> //FILE  DDDISP=OLD,DSN=SYS1.LINKLIB  (SYS1.**, ad lib.)
> >>
> >​A JOB with that particular DSN in it with DISP=OLD will never run.
> >SYS1.LINKLIB is share enqueued by both LLA and XCFAS on a normally running
> >system. ​
> >
> Understood that it will "never run".  However, I believe it will linger in
> an
> initiator in job setup requesting ENQ EXC, thereby preventing any other
> jobs' allocating that DSN.
>
> And tying up the initiator to boot.
>
> -- gil
>
> --
>
> No JCL needs to and should allocate SYS1.LINKLIB, because it is in the
> LNKLST.
>

​I think that both Gil and I are assuming malevolent intent to do a denial
of service. Or maybe somebody who did:

//SYSLIB DD DSN=SYS1.LINKLIB ,DISP=SHR

Note that blank before the , which makes the ,DISP=SHR a comment and thus
defaults to DISP=NEW. Which causes an enclusive ENQ on the DSN.

We have actually had that problem, although not with SYS1.LINKLIB. A person
did it, by accident, in a PROC. Used the PROC in a production job, run by
CA-7 with CA-11 restart enabled. CA-11 promptly deleted the master file
referenced and then the step failed with a JCL error. Panic ensued trying
to find a backup.​ We lost a day of on-line processing.



>
> Kees.
>
>
-- 

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

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: QNAMEs (was: ENQ rname_addr description)

[Joe Gentile]

Check out 
http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieag400/autqna.htm
 for more info on the topic of authorized qnames.

-Joe

Joe Gentile
z/OS GRS Lead
(845)435-2184 (T/L 295-2184)
jwgen...@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: how to know the length and blocksize of each member in dataset

[Elardus Engelbrecht]

ibmmain - Jason Cai wrote:
 
>Is there any utility to know  the length and blocksize of each member 
>(modules) in dataset ? 

You will have a hard time, perhaps impossible according to Shmuel, to get these 
info as others said. What type of dataset and what RECFM is that? 

But your question is ambiguous - what length? member name? record length? the 
records *inside* the modules? module sizes in dataset or in storage?

Like John Eells asked: Why do you want to know? Is there a problem or 
requirement you need to solve?

Mind you, max blocksize is 32768, but that info is useless. AMBLIST can 
*probably* help you, but ...

Groete / Greetings
Elardus Engelbrecht

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

opinion: "upgrade" use of CCSID in JCL.

[John McKown]

I am wondering if anyone else thinks that it might be useful for IBM to
make an enhancement to BSAM/QSAM support for the CCSID parameter in JCL.

ref:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2b6a0/12.9


Purpose

You can request the access method to convert data between the coded
character set identifier (CCSID) specified on the JOB or EXEC statement and
the CCSID specified on the DD statement. Data conversion is supported on
access to ISO/ANSI Version 4 tapes using access methods BSAM or QSAM, but
not using EXCP.


Why does this only support ASCII tapes? Would it be helpful to generalize
it to any data source read or written by BSAM/QSAM?
​ Of course, this is only of use for "pure text" data sets. But it might
address the recent thread on FTP'ing a VB data set, keeping the LLBB field
intact but translating the "data" portion to ASCII.

​Just another stupid idea, I guess.​


-- 

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

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: QNAMEs (was: ENQ rname_addr description)

[Paul Gilmartin]

On Wed, 2 Sep 2015 07:17:47 -0500, John McKown wrote:
>
>> //STEP  EXEC  PGM=IEFBR14,COND=(0,LE)
>> //FILE  DDDISP=OLD,DSN=SYS1.LINKLIB  (SYS1.**, ad lib.)
>>
>​A JOB with that particular DSN in it with DISP=OLD will never run.
>SYS1.LINKLIB is share enqueued by both LLA and XCFAS on a normally running
>system. ​
> 
Understood that it will "never run".  However, I believe it will linger in an
initiator in job setup requesting ENQ EXC, thereby preventing any other
jobs' allocating that DSN.

And tying up the initiator to boot.

-- gil

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

Re: QNAMEs (was: ENQ rname_addr description)

[John McKown]

On Wed, Sep 2, 2015 at 7:05 AM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Tue, 1 Sep 2015 10:03:46 -0500, Walt Farrell wrote:
> >>>
> >>I can imagine a DoS attack in which an unauthorized user bogarts a
> QNAME/RNAME
> >>generally used by an authorized facility.  But such contention could
> arise entirely
> >>among unauthorized users.
> >
> >Yes, contention could arise strictly between unauthorized users, and that
> is OK in the sense that it could not contribute to a system integrity
> exposure.
> >
> >>Are there, perhaps, RACF rules to restrict use of selected QNAMEs to
> specified user profiles?
> >
> Alas, the system is designed to protect itself from mischievous users, but
> not to protect
> the mischievous users from each other.
>
> But maybe it doesn't matter.  I wonder if Bad Things happen if the
> mischievous
> user simply codes:
>
> //STEP  EXEC  PGM=IEFBR14,COND=(0,LE)
> //FILE  DDDISP=OLD,DSN=SYS1.LINKLIB  (SYS1.**, ad lib.)
>
> -- gil
>

​A JOB with that particular DSN in it with DISP=OLD will never run.
SYS1.LINKLIB is share enqueued by both LLA and XCFAS on a normally running
system. ​

​Yes, they can be released by stopping LLA and do an UNALLOCATE command:
SETPROG LNKLIST,UNALLOCATE but a regular user should not be able to do
that. But you really could irritate a bunch of programmers by doing:

//WAITABIT EXEC PGM=BPXBATCH,
// PARM='SH sleep 30m'
//STDIN DD DUMMY
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//*
//IRRITATE EXEC PGM=IEFBR14
//DD1 DD DISP=OLD,DSN=... some production COPY library ...
//​


-- 

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

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: Can we use different translation tables via FTP

[Bill Godfrey]

On Tue, 1 Sep 2015 17:00:27 -0500, Jasi Grewal wrote:

>Greetings, I am trying to use different translation table and it states that 
>is not supported or not loaded.
>I have tried to define XLATE and SBDATACONN to TCPIP.STANDARD.TCPXLBIN in 
>ftp.data but still gets the following message:
>
>help sjiskanji
>Usage : SJISKANJI <(>  >  
>   change file transfer type to Shift JIS Kanji   
>Command:  
>sjiskanji (NOTYPE 
>Command not Supported. Translation Table not Loaded.  
>Command:  
>
>Any advise would be greatly appreciate it.
>
>Thanks in advance,
>Jasi.
>
This problem is mentioned in chapter 14 of the manual titled z/OS 
Communications Server: IP Diagnosis Guide.

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1C5B1/3.8.2.5.1

(begin quote)

 3.8.2.5.1 Double-byte character set (DBCS) support

If the DBCS translate tables are not available, the client issues the following 
message after a valid command to establish a double-byte transfer type (for 
example, SJISKANKI, BIG5, or 'TYPE B n') is entered:


 "EZA1865I Command not Supported. Translation Table not Loaded.


If this message is displayed, check the LOADDBCSTABLES statement in the 
TCPIP.DATA file.

(end quote)

There is more information after that.

You probably won't have permission to make a change to TCPIP.DATA yourself, 
unless you are an administrator.

Bill

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

Re: JES2 - get system name without JCT addressability.

[John McKown]

$CBIO doesn't work? It has an input parameter of MTTR with it says is a
SPOOL TTR. ref: http://publibfp.dhe.ibm.com/epubs/pdf/has2q000.pdf

MTTR= Specifies the label of, or a register that contains, the spool track
address of the record to be read or written. If you specify a register, the
spool MTTR (module track record) must be loaded into the designated
register before executing this macro instruction. MTTR is required for
TYPE=READ or TYPE=WRITE, but is not allowed with TYPE=WAIT.


On Wed, Sep 2, 2015 at 9:29 AM, Leonardo Vaz  wrote:

> Thanks for the help guys! You understand my problem now, so from the
> system I'm executing the command from It's not trivial to get the system
> where the job is running, the easiest field I found is JCTMVSNM, but JCT is
> probably not resident on the system I'm executing the command from, I think
> that's why JQE points to the track on the spool where I can find the JCT,
> but I still couldn't figure out how to read that track on the spool.
>
> It doesn't sound something extraordinary, but something rather simple, but
> I've learned a while ago that assembler is rarely simple.
>
> Thanks and regards,
> Leonardo Vaz
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Charles Mills
> Sent: Tuesday, September 01, 2015 8:01 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JES2 - get system name without JCT addressability.
>
> Ah. It seemed like too simple an answer; that's why I was kind of
> tentative.
> At least now I understand the problem.
>
> Could one determine "which member of the JES plex" somehow and then have a
> table that mapped that "which" to the actual system name? Or does this have
> to be more portable than that (such as for a vendor product)?
>
> Charles
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of J O Skip Robinson
> Sent: Tuesday, September 01, 2015 4:49 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JES2 - get system name without JCT addressability.
>
> I was going to reply similarly, but I then noticed that OP is talking
> about a running job, not necessarily the current system. A job can be
> running on any member of the JES plex. I don't have an easy answer for that
> question.
>
> --
> 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
>



-- 

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

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: JES2 - get system name without JCT addressability.

[Leonardo Vaz]

I knew I had to be missing something! Thank you very much John! "You're da 
best!" I'll give it a shot!

Regards,
Leonardo Vaz

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Wednesday, September 02, 2015 10:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES2 - get system name without JCT addressability.

$CBIO doesn't work? It has an input parameter of MTTR with it says is a SPOOL 
TTR. ref: http://publibfp.dhe.ibm.com/epubs/pdf/has2q000.pdf

MTTR= Specifies the label of, or a register that contains, the spool track 
address of the record to be read or written. If you specify a register, the 
spool MTTR (module track record) must be loaded into the designated register 
before executing this macro instruction. MTTR is required for TYPE=READ or 
TYPE=WRITE, but is not allowed with TYPE=WAIT.


On Wed, Sep 2, 2015 at 9:29 AM, Leonardo Vaz  wrote:

> Thanks for the help guys! You understand my problem now, so from the 
> system I'm executing the command from It's not trivial to get the 
> system where the job is running, the easiest field I found is 
> JCTMVSNM, but JCT is probably not resident on the system I'm executing 
> the command from, I think that's why JQE points to the track on the 
> spool where I can find the JCT, but I still couldn't figure out how to read 
> that track on the spool.
>
> It doesn't sound something extraordinary, but something rather simple, 
> but I've learned a while ago that assembler is rarely simple.
>
> Thanks and regards,
> Leonardo Vaz
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Charles Mills
> Sent: Tuesday, September 01, 2015 8:01 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JES2 - get system name without JCT addressability.
>
> Ah. It seemed like too simple an answer; that's why I was kind of 
> tentative.
> At least now I understand the problem.
>
> Could one determine "which member of the JES plex" somehow and then 
> have a table that mapped that "which" to the actual system name? Or 
> does this have to be more portable than that (such as for a vendor product)?
>
> Charles
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of J O Skip Robinson
> Sent: Tuesday, September 01, 2015 4:49 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JES2 - get system name without JCT addressability.
>
> I was going to reply similarly, but I then noticed that OP is talking 
> about a running job, not necessarily the current system. A job can be 
> running on any member of the JES plex. I don't have an easy answer for 
> that question.
>
> --
> 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
>



-- 

Schrodinger's backup: The condition of any backup is unknown until a restore is 
attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

--
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: JES2 - get system name without JCT addressability.

[Leonardo Vaz]

Thanks for the help guys! You understand my problem now, so from the system I'm 
executing the command from It's not trivial to get the system where the job is 
running, the easiest field I found is JCTMVSNM, but JCT is probably not 
resident on the system I'm executing the command from, I think that's why JQE 
points to the track on the spool where I can find the JCT, but I still couldn't 
figure out how to read that track on the spool.

It doesn't sound something extraordinary, but something rather simple, but I've 
learned a while ago that assembler is rarely simple.

Thanks and regards,
Leonardo Vaz


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Tuesday, September 01, 2015 8:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES2 - get system name without JCT addressability.

Ah. It seemed like too simple an answer; that's why I was kind of tentative.
At least now I understand the problem.

Could one determine "which member of the JES plex" somehow and then have a 
table that mapped that "which" to the actual system name? Or does this have to 
be more portable than that (such as for a vendor product)?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of J O Skip Robinson
Sent: Tuesday, September 01, 2015 4:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES2 - get system name without JCT addressability.

I was going to reply similarly, but I then noticed that OP is talking about a 
running job, not necessarily the current system. A job can be running on any 
member of the JES plex. I don't have an easy answer for that question.

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