Re: IEFSSREQ SSOBUSER Validate A JES2 Destid

[Binyamin Dissen]

On Tue, 1 Dec 2015 18:26:07 -0600 SUBSCRIBE IBM-MAIN Harold Gray
 wrote:

:>Yes, that is the one I replied to.  I guess it started a new number since it 
was so old.  I was searching on the IEFSSREQ requests and saw the function code 
11 which is exactly what I am doing.  The R15 rc is 0 and the SSOBRETN value is 
0 on any destination I submit to the function.  I was wondering if  JES2 has 
changed as I don't know when the IEFSSREQ quit working.  I noticed in the SSUS 
block, we were defaulting to version 0 (SSUSVER) so I changed the code to 
specify version 1 and increased the length of the block to 32 thinking maybe 
JES didn't work right with a version 1 block.  I left the flag byte SSUSFLG1 
set to X'00' but no difference.  

Did it ever work?

Show your code.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: What does the 8th character of Load parm mean

[Mark Jacobs - Listserv]

Yes, I meant DAT-OFF. Sorry for the confusion.

Mark Jacobs


Jim Mulder 
December 2, 2015 at 1:29 AM

It's less useful than it once was, and I don't see any need to use
anything other than the default (1) any longer. IEANUC01, IEANUC11 and
IEANUC21 are logically the same nucleus;

IEANUC01, V=V Nucleus Modules
IEANUC11, V=R Nucleus Modules, 31 Bit, not used any longer (Look at the
length of the load module, you'll see that it has almost nothing in it)
IEANUC21, V=R Nucleus Modules, 64 Bit.


John Mattson
December 1, 2015 at 7:16 PM
According to zOS MVS System Commands manual
4. The last character (character 8 of the LOAD parameter) specifies

the

alternate
nucleus identifier (0-9). Use this character at the system

programmer's

direction.
If you do not specify an alternate nucleus identifier, the system
loads the
standard (or primary) nucleus (IEANUC01) and an architectural

extension of

the nucleus (IEANUC11 or IEANUC21), unless the NUCLEUS statement is
specified in the LOADxx member.
Unfortunately they do NOT give an example. In my case I have
inherited an HMC with 00T1 as its value. I understand the first 7
chars, but does the "1" mean IEANUC01 11, 21, or what?
Fortunately "T" turns on Informational messages and I see in the

syslog

"IEA091I NUCLEUS 1 SELECTED" and the message is actually useful (for

once)

and says that IEANUC01 was selected. I would think that they would
just put
that in the syslog message, but that would be too easy.
My concern is what about the "architctural extension"? I doubt that I
would ever want to change this value, but I would like to know just in



case
I do someday. I think the manual should just SAY "1" is the default

and

corresponds to IEANUC01 IEANUC11 IEANUC21 and so on. "2" would be

IEANUC02

and so on. I think this is the case but would like verification. And

an

update to the manual.


  The 8th character of the load parm selects the y in IEANUCxy (so y
represents the logical nucleus number).


IEANUC0y contains the modules loaded regardless of the ARCHLVL.
IEANUC1y contains the additional modules loaded when ARCHLVL=1
  (ESA/390 mode, which z/OS does not support after z/OS 1.5)
IEANUC2y contains the additional modules loaded when ARCHLVL=2
  (zArchitecture mode, which has been the only choice since z/OS
1.6).

  None of these are V=R.  There has been no V=R nucleus since the
beginning of MVS/XA.

  There is a small DAT-off nucleus loaded from SYS1.NUCLEUS(IEAVEDAT).
The DAT-off nucleus is not V=R.

  Since MVX/XA, the only storage which is V=R is the 24-bit low
private storage in a V=R job step, and the prefix page(s).

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


Please be alert for any emails that may ask you for login information or 
directs you to login via a link. If you believe this message is a phish or 
aren't sure whether this message is trustworthy, please send the original 
message as an attachment to 'phish...@timeinc.com'.

Mark Jacobs - Listserv 
December 1, 2015 at 7:31 PM
It's less useful than it once was, and I don't see any need to use 
anything other than the default (1) any longer. IEANUC01, IEANUC11 and 
IEANUC21 are logically the same nucleus;


IEANUC01, V=V Nucleus Modules
IEANUC11, V=R Nucleus Modules, 31 Bit, not used any longer (Look at 
the length of the load module, you'll see that it has almost nothing 
in it)

IEANUC21, V=R Nucleus Modules, 64 Bit.

Mark Jacobs


John Mattson 
December 1, 2015 at 7:16 PM
According to zOS MVS System Commands manual
4. The last character (character 8 of the LOAD parameter) specifies the
alternate
nucleus identifier (0-9). Use this character at the system programmer's
direction.
If you do not specify an alternate nucleus identifier, the system 
loads the

standard (or primary) nucleus (IEANUC01) and an architectural extension of
the nucleus (IEANUC11 or IEANUC21), unless the NUCLEUS statement is
specified in the LOADxx member.
Unfortunately they do NOT give an example. In my case I have
inherited an HMC with 00T1 as its value. I understand the first 7
chars, but does the "1" mean IEANUC01 11, 21, or what?
Fortunately "T" turns on Informational messages and I see in the syslog
"IEA091I NUCLEUS 1 SELECTED" and the message is actually useful (for once)
and says that IEANUC01 was selected. I would think that they would 
just put

that in the syslog message, but that would be too easy.
My concern is what about the "architctural extension"? I doubt that I
would ever want to change this value, but I would like to know just in 
case

I do someday. I think the manual should just SAY "1" is the default and
corresponds to IEAN

Re: User Cats and Replication Sites

[Ron Hawkins]

Skip,

Is there a case here for taking regular snapshots of your UCATs and other small 
critical datasets?

Using persistent FlashCopy the UCATs or their volumes could be copied every 
hour and retained for quick receovery.

30 days' worth of hourly copies of a 1000 Cyl UCAT would use less than 1GB of 
space. Persistent FC would give you a good backup in both sites.

Ron



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of J O Skip Robinson
Sent: Sunday, November 29, 2015 11:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] User Cats and Replication Sites

Touche. We had a near catastrophic catalog problem some time back. Of course 
the replicated copy faithfully mirrored the errors, which were procedural 
rather than structural--tons of vital data deleted by mistake. Still I value 
mirroring for the classic case of disaster recovery: the production data center 
suddenly goes offline and cannot be resuscitated within an acceptable window. 
Mirrored DR allows you get up and running quickly, warts and all.

.
.
.
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 Shane Ginnane
Sent: Wednesday, November 25, 2015 2:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: User Cats and Replication Sites

On Wed, 25 Nov 2015 20:53:09 +, J O Skip Robinson wrote:

>Nothing beats replication, the more the better. 

Hmmm - unless you happen to have a critical error in the source. Replicating 
that quietly everywhere can leave you with non-IPLable systems *everywhere*.
Which you may not find out about until you try an IPL.
And yes, it has happened - LE bug that broke MCAT access for example; ran fine 
till IPL.
Brings to mind the "Schrodingers backup" discussion a few months back.

Shane ...


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

Translation Exception address shown in PGM System Trace entries

[Peter Hunkeler]

When I look at system trace entries for translation exceptions (PBG 10, 11, 
etc) I see for example

PGM011 _25A00E32  00060011 .. 07852001 
8000 .. 4400


(replaced blanks with dots, to somehow keep the data aligned)


>From the "MVS Tools & Service Aids" manual I understand that the last words on 
>the two lines are the address which cause the tramslation exception (TEA, High 
>word on upper line, low word on lower line). In the above example my program 
>was accessing storage at x'_4000' (first reference). The trace 
>entry shows this as x'_4400'.

The TEA seems to always point to the start of the page where within the page 
the access was (which makes sense), but what is the x'400' in the low 12 bit 
telling me? The manual only talks about the high order bit indicating primary 
or secondary address space. I guess it some flags, but where is this documented?


--
Peter Hunkeler


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


Check out our new brand campaign: www.ubs.com/together
E-mails can involve SUBSTANTIAL RISKS, e.g. lack of confidentiality, potential 
manipulation of contents and/or sender's address, incorrect recipient 
(misdirection), viruses etc. Based on previous e-mail correspondence with you 
and/or an agreement reached with you, UBS considers itself authorized to 
contact you via e-mail. UBS assumes no responsibility for any loss or damage 
resulting from the use of e-mails. 
The recipient is aware of and accepts the inherent risks of using e-mails, in 
particular the risk that the banking relationship and confidential information 
relating thereto are disclosed to third parties.
UBS reserves the right to retain and monitor all messages. Messages are 
protected and accessed only in legally justified cases.
Privacy statements: http://www.ubs.com/global/en/legalinfo2/privacy.html

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

Re: Translation Exception address shown in PGM System Trace entries

[Peter Hunkeler]

Well, the formatting worked only partly. Trying again ...



When I look at system trace entries for translation exceptions (PBG 10, 11, 
etc) I see for example

PGM011 _25A00E32  00060011 


.. 07852001 8000 .. 4400


(replaced blanks with dots, to somehow keep the data aligned)


>From the "MVS Tools & Service Aids" manual I understand that the last words on 
>the two lines are the address which cause the tramslation exception (TEA, High 
>word on upper line, low word on lower line). In the above example my program 
>was accessing storage at x'_4000' (first reference). The trace 
>entry shows this as x'_4400'.

The TEA seems to always point to the start of the page where within the page 
the access was (which makes sense), but what is the x'400' in the low 12 bit 
telling me? The manual only talks about the high order bit indicating primary 
or secondary address space. I guess it some flags, but where is this documented?


--
Peter Hunkeler


--
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: any shops hiring in DFW?

[Tim Brown]

Check Hudson Valley NY , opening available

Tim

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Post
Sent: Tuesday, 01 December, 2015 9:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: any shops hiring in DFW?


**THIS IS AN EXTERNAL EMAIL**
 Do not open links or attachments unless you trust the sender and never provide 
USER ID or PASSWORD information.


__
>>> On 12/1/2015 at 04:56 PM, John McKown  wrote: 
> I know it's a long shot, but does anybody know of any z/OS shops 
> around DFW who are hiring or may start in 2016? Looks like it is 
> definite that this place will be gone 2Q2016 at the very latest.

Based on what I've been seeing lately, you may wind up having to move.  If you 
do, however, I've seen a number of jobs that require mainframe skills, as well 
as Linux, and even z/VM.  Since that seems to fall into your areas of interest, 
you might want to consider it.


Mark Post

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

Is first page always backed by real storage upon return from STORAGE OBTAIN?

[Peter Hunkeler]

Allocating 100 MB area, I found that the first page in the newly allocated area 
always seems to be backed by real storage upon return from STORAGE OBTAIN. Is 
this true? Where is this documented?



--
Peter Hunkeler

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

Re: Is first page always backed by real storage upon return from STORAGE OBTAIN?

[Elardus Engelbrecht]

Peter Hunkeler wrote:

>Allocating 100 MB area, I found that the first page in the newly allocated 
>area always seems to be backed by real storage upon return from STORAGE 
>OBTAIN. 

Before or after actual reference? Say you execute some instructions after 
STORAGE OBTAIN, do you observe that status of that first page?

Or, how did you found that out? Paging activity?

>Is this true? Where is this documented?

I wish I know where to search for that, but my fading memory tells me, that 
pages are backed up or swapped AFTER the first reference (read/write).

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: Any clever way to defeat the C compiler's options precedence?

[Charles Mills]

Exactly. I would like to "automate" it. FWIW I currently do not have one job
per source module -- I have one compile job total and //SYSIN DD
PATH=/source/hfs/folder

I have currently come up with a kluge solution. I am thinking about
something like what Wayne suggests, where my source folder could have
subfolders, and each subfolder would contain a options file, so I could have
something like

//SYSOPTF DD DISP=SHR,DSN=MAIN.OPTIONS.FILE
//DD PATH=/source/hfs/folder/subfolder/options.file
//SYSIN   DD PATH=/source/hfs/folder/subfolder

Currently the kluge is sufficient to the need.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Robert A. Rosenberg
Sent: Tuesday, December 01, 2015 8:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Any clever way to defeat the C compiler's options precedence?

At 20:03 -0600 on 12/01/2015, Wayne Driscoll wrote about Re: Any clever way
to defeat the C compiler's options prece:

>I'll preface this by saying that I haven't coded C/C++ in almost a 
>decade, and via JCL even longer, but if the SYSOPTF can be a 
>concatenation (I don't know, and don't have source sitting around to 
>test with) could you do something like the following:
>
>//SYSOPTF DD DISP=SHR,DSN=USER.COPTS(MAINOPTS)
>//DD  DISP=SHR,DSN=USER.COPTS(ARCH&AVER.)
>
>And have a
>
>//  SET AVER=9 at the start of job, put the steps for the compiles that 
>require ARCH(5) at the bottom with a SET AVER=5 before them and member
>ARCH9 contains
>ARCH(9)
>and member ARCH5 contains
>ARCH(5)

That might work BUT it requires you to reorder your JCL to handle which
modules are ARCH9 and which are ARCH5. If you want to make a module which is
currently ARCH9 into a ARCH5, you have to move its compile step from the
ARCH9 area to the ARCH5 area. What was asked for was a way for the module to
define itself as ARCH9 or ARCH5 via the in source parm statement without
needing to alter the JCL stream.

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

Re: Is first page always backed by real storage upon return from STORAGE OBTAIN?

[Tom Marchant]

On Wed, 2 Dec 2015 14:06:28 +0100, Peter Hunkeler wrote:

>Allocating 100 MB area, I found that the first page in the newly 
>allocated area always seems to be backed by real storage upon 
>return from STORAGE OBTAIN.

Do you specify BNDRY=PAGE?
Are you using z/OS 1.9 rules or z/OS 1.10 rules?
How were you able to determine this? LRA perhaps?
Why do you care?

>Is this true? 

I don't know; maybe Jim or Peter will have an answer.

>Where is this documented?

I wouldn't expect that it is.

-- 
Tom Marchant

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

Re: Is first page always backed by real storage upon return from STORAGE OBTAIN?

[Blaicher, Christopher Y.]

Not knowing the internals, but making some reasonable, I think, assumptions...
If you are doing anything other than a full page, or full pages, STORAGE 
OBTAIN, the system has to put a FQE element in the top of the page, and so it 
would have to back the first virtual page with a real page.
If you are doing full page STORAGE OBTAIN or GETMAIN, then no FQE is needed and 
I wouldn't expect the page to be backed.
It is an interesting question, but does it matter in this day of machines 
having millions of real pages?  Maybe it did back with a 168 and maybe a whole 
meg or two of real memory.

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Wednesday, December 02, 2015 9:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is first page always backed by real storage upon return from 
STORAGE OBTAIN?

On Wed, 2 Dec 2015 14:06:28 +0100, Peter Hunkeler wrote:

>Allocating 100 MB area, I found that the first page in the newly
>allocated area always seems to be backed by real storage upon return
>from STORAGE OBTAIN.

Do you specify BNDRY=PAGE?
Are you using z/OS 1.9 rules or z/OS 1.10 rules?
How were you able to determine this? LRA perhaps?
Why do you care?

>Is this true?

I don't know; maybe Jim or Peter will have an answer.

>Where is this documented?

I wouldn't expect that it is.

--
Tom Marchant

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





ATTENTION: -

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

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

Re: IEFSSREQ SSOBUSER Validate A JES2 Destid

[SUBSCRIBE IBM-MAIN Harold Gray]

Yes, it did at one point but I'm not sure when it stopped.  I only have access 
to z/OS 1.13 and 2.1 and JES2 in both accepts any destination name.

CODE:
 LAR1,#JESSSIB LOAD AND DECLARE 
 USING SSIB,R1 SSIB BASE
 MVC   SSIBSSNM,$JESSYSSETUP JESX SUBSYSTEM NAME
 DROP  R1   
 LAR1,#JESSSOB LOAD AND DECLARE 
 USING SSOB,R1 SSOB BASE
 LAR14,#JESSSUS-#JESSSOB  SETUP MVS/XA SSOB LENGTH  
 STH   R14,SSOBLEN SAVE SSOB HEADER LENGTH  
 XCSSOBRETN,SSOBRETN   ZERO RC FIELD
 DROP  R1   
 LAR1,#JESSSUS LOAD AND DECLARE 
 USING SSOBEXT,R1  SSOB EXTENSION BASE  
 MVC   SSUSUSER,0(R2)  SETUP DESTINATION NAME   
 DROP  R1   
 LAR1,AJESSSOB -> SSOB PARMLIST 
 IEFSSREQ ,ISSUE SUBSYTEM REQUEST   

#JESSSOB DS0F   
 DCCL4'SSOB'   SSOBID   
 DCAL2(0)  SSOBLEN  
 DCAL2(SSOBUSER)   SSOBFUNC 
 DCA(#JESSSIB) SSOBSSIB 
 DCF'0'SSOBRETN 
 DCA(#JESSSUS) SSOBINDV 
 DCA(0)SSOBRETA  ** MVS/XA ONLY **  
 DCCL4' '  SSOBRSV1  ** MVS/XA ONLY **  
#JESSSUS DS0F   
 DCAL2(SSUSIZE)SSUSLEN  
*DCH'0'SSUSRESV  --- 
original 
 DCH'1'SSUSFLG1(X'00') / SSUSVER(X'01')  new 
code
 DCF'0'SSUSRSV1 
 DCCL8' '  SSUSUSER 
 DCXL16'00'Rest of SSUS area   
new code 
*   
#JESSSIB DS0F   
 DCCL4'SSIB'   SSIBID   
 DCAL2(SSIBSIZE)   SSIBLEN  
 DCX'00'   SSIBFLG1 
 DCX'00'   SSIBRESV 
 DCCL4' '  SSIBSSNM 
 DCCL8' '  SSIBJBID 
 DCCL8' '  SSIBDEST 
 DCF'0'SSIBRSV1 
 DCF'0'SSIBSUSE 
*   
AJESSSOB DCX'80',AL3(#JESSSOB) IEFSSREQ PARMLIST
*   


Thanks,  Harold

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

Re: any shops hiring in DFW?

[Longabaugh, Robert E]

Check ca.com/careers.  The facility is in Plano.

Good luck

Bob Longabaugh
CA Technologies
Storage Management

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tim Brown
Sent: Wednesday, December 02, 2015 6:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: any shops hiring in DFW?

Check Hudson Valley NY , opening available

Tim

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Post
Sent: Tuesday, 01 December, 2015 9:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: any shops hiring in DFW?


**THIS IS AN EXTERNAL EMAIL**
 Do not open links or attachments unless you trust the sender and never provide 
USER ID or PASSWORD information.


__
>>> On 12/1/2015 at 04:56 PM, John McKown  wrote: 
> I know it's a long shot, but does anybody know of any z/OS shops 
> around DFW who are hiring or may start in 2016? Looks like it is 
> definite that this place will be gone 2Q2016 at the very latest.

Based on what I've been seeing lately, you may wind up having to move.  If you 
do, however, I've seen a number of jobs that require mainframe skills, as well 
as Linux, and even z/VM.  Since that seems to fall into your areas of interest, 
you might want to consider it.


Mark Post

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

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

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

Re: any shops hiring in DFW?

[John McKown]

Plano is a bit north of me. But given when I drive (before 06:00), it might
be OK. So long as I stay off of Central!

On Wed, Dec 2, 2015 at 8:54 AM, Longabaugh, Robert E <
robert.longaba...@ca.com> wrote:

> Check ca.com/careers.  The facility is in Plano.
>
> Good luck
>
> Bob Longabaugh
> CA Technologies
> Storage Management
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Tim Brown
> Sent: Wednesday, December 02, 2015 6:42 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: any shops hiring in DFW?
>
> Check Hudson Valley NY , opening available
>
> Tim
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Mark Post
> Sent: Tuesday, 01 December, 2015 9:49 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: any shops hiring in DFW?
>
>
> **THIS IS AN EXTERNAL EMAIL**
>  Do not open links or attachments unless you trust the sender and never
> provide USER ID or PASSWORD information.
>
>
>
> __
> >>> On 12/1/2015 at 04:56 PM, John McKown 
> wrote:
> > I know it's a long shot, but does anybody know of any z/OS shops
> > around DFW who are hiring or may start in 2016? Looks like it is
> > definite that this place will be gone 2Q2016 at the very latest.
>
> Based on what I've been seeing lately, you may wind up having to move.  If
> you do, however, I've seen a number of jobs that require mainframe skills,
> as well as Linux, and even z/VM.  Since that seems to fall into your areas
> of interest, you might want to consider it.
>
>
> Mark Post
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 

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

AW: Re: Is first page always backed by real storage upon return from STORAGE OBTAIN?

[Peter Hunkeler]

>>Allocating 100 MB area, I found that the first page in the newly allocated 
>>area always seems to be backed by real storage upon return from STORAGE 
>>OBTAIN.

>Before or after actual reference?



I tought "upon return from STORAGE OBTAIN" would be clear. Anyway, no I have 
not referenced any byte within the new area. I found by looking at the area in 
a dump.


--
Peter Hunkeler



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

AW: Re: Is first page always backed by real storage upon return from STORAGE OBTAIN?

[Peter Hunkeler]

> Do you specify BNDRY=PAGE?




No, but from what the manual says I guess in my case the rule "8192 or more 
from  pageable, private subpool" applies", so the storage is cleared. I was 
just expecting that the backing and clearing only takes place when I access the 
storage.




> Are you using z/OS 1.9 rules or z/OS 1.10 rules?


New rules



>How were you able to determine this? LRA perhaps?


Looking at a dump




>Why do you care?


Curiosity.



--
Peter Hunkeler



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

AW: Re: Is first page always backed by real storage upon return from STORAGE OBTAIN?

[Peter Hunkeler]

>If you are doing anything other than a full page, or full pages, STORAGE 
>OBTAIN, the system has to put a FQE element in the top of the page, and so it 
>would have to back the first virtual page with a real page.


I'm allocating 10MiB, that is to work like fill page, I assume. IPCS tells me 
the full page is X'00', so there is nothing written in that page.



>It is an interesting question, but does it matter in this day of machines 
>having millions of real pages?  Maybe it did back with a 168 and maybe a whole 
>meg or two of real memory.


As said in another response, it's pure curiosity.



--
Peter Hunkeler



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

Re: Is first page always backed by real storage upon return from STORAGE OBTAIN?

[Tom Marchant]

On Wed, 2 Dec 2015 14:12:04 +, Blaicher, Christopher Y. wrote:

>If you are doing anything other than a full page, or full pages, STORAGE 
>OBTAIN, 
>the system has to put a FQE element in the top of the page

I've never seen an FQE located within the area containing the free space. 
The data areas book says that FQEs are in SP 245 or 255, SQA or LSQA.

-- 
Tom Marchant

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

Re: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[Dana Mitchell]

On Tue, 1 Dec 2015 23:03:59 +, J O Skip Robinson  
wrote:

>(This whole season feels like Friday.) A doughnut, on the other hand, requires 
>the hole for its very definition. The hole supplies no mass or nutritional 
>value, but without it the thing is not a doughnut. By contrast a punch card 
>requires the solid part to give the holes meaning; they would otherwise 
>collapse into gibberish. 
>

In school we verified that if you multi-punch every possible punch out of a 
card, the result is indeed very fragile.  But it was fun to dupe

Dana

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

Re: any shops hiring in DFW?

[Roberto Halais]

I don't know if EDS still exists but they had their IPC in Plano.
On Dec 2, 2015 10:57 AM, "John McKown"  wrote:

> Plano is a bit north of me. But given when I drive (before 06:00), it might
> be OK. So long as I stay off of Central!
>
> On Wed, Dec 2, 2015 at 8:54 AM, Longabaugh, Robert E <
> robert.longaba...@ca.com> wrote:
>
> > Check ca.com/careers.  The facility is in Plano.
> >
> > Good luck
> >
> > Bob Longabaugh
> > CA Technologies
> > Storage Management
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Tim Brown
> > Sent: Wednesday, December 02, 2015 6:42 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: any shops hiring in DFW?
> >
> > Check Hudson Valley NY , opening available
> >
> > Tim
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Mark Post
> > Sent: Tuesday, 01 December, 2015 9:49 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: any shops hiring in DFW?
> >
> >
> > **THIS IS AN EXTERNAL EMAIL**
> >  Do not open links or attachments unless you trust the sender and never
> > provide USER ID or PASSWORD information.
> >
> >
> >
> >
> __
> > >>> On 12/1/2015 at 04:56 PM, John McKown 
> > wrote:
> > > I know it's a long shot, but does anybody know of any z/OS shops
> > > around DFW who are hiring or may start in 2016? Looks like it is
> > > definite that this place will be gone 2Q2016 at the very latest.
> >
> > Based on what I've been seeing lately, you may wind up having to move.
> If
> > you do, however, I've seen a number of jobs that require mainframe
> skills,
> > as well as Linux, and even z/VM.  Since that seems to fall into your
> areas
> > of interest, you might want to consider it.
> >
> >
> > Mark Post
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> email
> > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> email
> > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
>
> --
>
> 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: any shops hiring in DFW?

[Burrell, C. Todd (CDC/OCOO/OCIO/ITSO) (CTR)]

EDS was swallowed a while back by HP - which is now HP Enterprise.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Roberto Halais
Sent: Wednesday, December 02, 2015 11:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: any shops hiring in DFW?

I don't know if EDS still exists but they had their IPC in Plano.
On Dec 2, 2015 10:57 AM, "John McKown"  wrote:

> Plano is a bit north of me. But given when I drive (before 06:00), it 
> might be OK. So long as I stay off of Central!
>
> On Wed, Dec 2, 2015 at 8:54 AM, Longabaugh, Robert E < 
> robert.longaba...@ca.com> wrote:
>
> > Check ca.com/careers.  The facility is in Plano.
> >
> > Good luck
> >
> > Bob Longabaugh
> > CA Technologies
> > Storage Management
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tim Brown
> > Sent: Wednesday, December 02, 2015 6:42 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: any shops hiring in DFW?
> >
> > Check Hudson Valley NY , opening available
> >
> > Tim
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Post
> > Sent: Tuesday, 01 December, 2015 9:49 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: any shops hiring in DFW?
> >
> >
> > **THIS IS AN EXTERNAL EMAIL**
> >  Do not open links or attachments unless you trust the sender and 
> > never provide USER ID or PASSWORD information.
> >
> >
> >
> >
> __
> __
> __
> > >>> On 12/1/2015 at 04:56 PM, John McKown 
> > >>> 
> > wrote:
> > > I know it's a long shot, but does anybody know of any z/OS shops 
> > > around DFW who are hiring or may start in 2016? Looks like it is 
> > > definite that this place will be gone 2Q2016 at the very latest.
> >
> > Based on what I've been seeing lately, you may wind up having to move.
> If
> > you do, however, I've seen a number of jobs that require mainframe
> skills,
> > as well as Linux, and even z/VM.  Since that seems to fall into your
> areas
> > of interest, you might want to consider it.
> >
> >
> > Mark Post
> >
> > 
> > -- For IBM-MAIN subscribe / signoff / archive access instructions, 
> > send
> email
> > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > 
> > -- For IBM-MAIN subscribe / signoff / archive access instructions, 
> > send
> email
> > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > 
> > -- For IBM-MAIN subscribe / signoff / archive access instructions, 
> > send email to lists...@listserv.ua.edu with the message: INFO 
> > IBM-MAIN
> >
>
>
>
> --
>
> 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

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

Re: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[Paul Gilmartin]

On Wed, 2 Dec 2015 10:02:01 -0600, Dana Mitchell wrote:

>On Tue, 1 Dec 2015 23:03:59 +, J O Skip Robinson wrote:
>
>>(This whole season feels like Friday.) A doughnut, on the other hand, 
>>requires the hole for its very definition. The hole supplies no mass or 
>>nutritional value, but without it the thing is not a doughnut. By contrast a 
>>punch card requires the solid part to give the holes meaning; they would 
>>otherwise collapse into gibberish. 
>
>In school we verified that if you multi-punch every possible punch out of a 
>card, the result is indeed very fragile.  But it was fun to dupe
> 
This could inspire a Retro engineering project:  Given the constraint of 
required mechanical
strength, devise an encoding that maximizes information density.  Akin to GCR:

https://en.wikipedia.org/wiki/Group_code_recording

(How much does the hole diminish the mechanical strength of the bagel?)

-- gil

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

at Re: AW: Re: Is first page always backed by real storage upon return from STORAGE OBTAIN?

[Mike Myers]

Peter:

It's been several years since I had a hand in that code (as the team 
leader of the VSM development team for the first release of MVS back in 
1972-1974), but someone mentioned the existence of the FQE (Free Queue 
Element). The FQE described the number of bytes that were free within 
the block of storage obtained. If the storage size requested was less 
than a page or some multiple of pages, there would be some free space, 
which would always be in the first page of the obtained area and an FQE 
would be put at the start of that first page to identify the amount of 
free space.


Storage requests were always oriented to the high end of of the last 
page of the requested area, so that an attempt to access storage beyond 
the end of the area would result in a page fault. The idea being that 
the more common storage addressing error resulted from having a 
legitimate storage address, but an offset that exceeded the size of the 
actual obtained area.


Mike Myers
Mentor Services Corporation

  On 12/02/2015 10:07 AM, Peter Hunkeler wrote:

Allocating 100 MB area, I found that the first page in the newly allocated area 
always seems to be backed by real storage upon return from STORAGE OBTAIN.
  

Before or after actual reference?


I tought "upon return from STORAGE OBTAIN" would be clear. Anyway, no I have 
not referenced any byte within the new area. I found by looking at the area in a dump.


--
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@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: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[J O Skip Robinson]

One urban legend (not necessarily fiction) is an explanation for the curious 
layout in EBCDIC coding. We have

A - I as C1 - C9
J - R as D1 - D9
S - Z as E2 - E9

Of course there is one more hex value in the neighborhood than there are 
letters in English, but why jump from D9 to E2 instead of using E1 - E8? The 
story I heard in computer school is that the EBCDIC ultimately derived from the 
punch card layout. To represent a letter, a card required both a 'zone' punch 
in one of the first three rows at the top plus a 'digit' punch further down in 
the same column. The first group of letters used the top zone row and so on 
through the alphabet. The last group of letters worked off the third zone row. 
The story goes that early punch equipment and card stock were imprecise and 
flimsy. In order to avoid having to deal with two vertically adjacent 
punches--third zone row plus first digit row--the code was constructed to skip 
the 1 digit for the letter S. Since a gap was needed anyhow, this was the ideal 
place for it. 

I love this story too much to challenge it.  

.
.
.
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, December 02, 2015 8:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: What's a "ton" of JCL? [was:RE: Straightforward way to 
determine hardware architecture level?]

On Wed, 2 Dec 2015 10:02:01 -0600, Dana Mitchell wrote:

>On Tue, 1 Dec 2015 23:03:59 +, J O Skip Robinson wrote:
>
>>(This whole season feels like Friday.) A doughnut, on the other hand, 
>>requires the hole for its very definition. The hole supplies no mass or 
>>nutritional value, but without it the thing is not a doughnut. By contrast a 
>>punch card requires the solid part to give the holes meaning; they would 
>>otherwise collapse into gibberish. 
>
>In school we verified that if you multi-punch every possible punch out 
>of a card, the result is indeed very fragile.  But it was fun to dupe
> 
This could inspire a Retro engineering project:  Given the constraint of 
required mechanical strength, devise an encoding that maximizes information 
density.  Akin to GCR:

https://en.wikipedia.org/wiki/Group_code_recording

(How much does the hole diminish the mechanical strength of the bagel?)

-- gil


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

Re: Straightforward way to determine hardware architecture level?

[Shmuel Metz (Seymour J.)]

In
,
on 12/01/2015
   at 10:57 PM, J O Skip Robinson  said:

>MVCIN was indeed a useful instruction. I encountered it (IIRC) on a
>4381. I assumed that, like typical new instructions, it would stick
>around for the duration. I was later shocked to discover that it had
>been abandoned on a siding somewhere along the railway to the future.
>Probably still there somewhere in Nebraska with a smudged bar code. 

It's present in ECPS:VSE PoOps, XA PoOps, ESA/370 PoOps, ESA/390 PoOps
and z PoOps; that looks like sticking around to me. I don't know what
the story is on the 3090.
 
-- 
 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: Straightforward way to determine hardware architecture level?

[J O Skip Robinson]

I'm grateful to this thread for the news that MVCIN lives on. When it 
disappeared on the 3090--talk about unexpected S0C1--I did a brief RIP and 
never looked for it again. MVCIN allowed you to reverse a string and use TRT to 
find stuff that would otherwise have required a backwards loop search. Very 
handy.

.
.
.
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 Shmuel Metz (Seymour J.)
Sent: Tuesday, December 01, 2015 6:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Straightforward way to determine hardware architecture 
level?

In
,
on 12/01/2015
   at 10:57 PM, J O Skip Robinson  said:

>MVCIN was indeed a useful instruction. I encountered it (IIRC) on a 
>4381. I assumed that, like typical new instructions, it would stick 
>around for the duration. I was later shocked to discover that it had 
>been abandoned on a siding somewhere along the railway to the future.
>Probably still there somewhere in Nebraska with a smudged bar code. 

It's present in ECPS:VSE PoOps, XA PoOps, ESA/370 PoOps, ESA/390 PoOps and z 
PoOps; that looks like sticking around to me. I don't know what the story is on 
the 3090.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT

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

Re: IEFSSREQ SSOBUSER Validate A JES2 Destid

[Tony Harminc]

On 2 December 2015 at 09:54, SUBSCRIBE IBM-MAIN Harold Gray <
harold.g...@mantissa.com> wrote:

> Yes, it did at one point but I'm not sure when it stopped.  I only have
> access to z/OS 1.13 and 2.1 and JES2 in both accepts any destination name.


What is the actual invalid name that it's accepting? There are many valid
destination formats; is it possible that your bad one by chance passes a
check different from the one you were expecting?

The code for this is (still) not OCO. You can follow along yourself in
HASCSIRQ routine USERDEST. This is the internal routine that handles
things; the subsystem request code that calls USERDEST is also in the same
source module at label SSIUSUSE. I suppose the divide & conquer approach
would be to see if the latter is actually calling the former, though I
don't see a path for unconditional RC=0 from SSIUSUSE.

Tony H.

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

Re: Straightforward way to determine hardware architecture level?

[John McKown]

On Wed, Dec 2, 2015 at 11:44 AM, J O Skip Robinson  wrote:

> I'm grateful to this thread for the news that MVCIN lives on. When it
> disappeared on the 3090--talk about unexpected S0C1--I did a brief RIP and
> never looked for it again. MVCIN allowed you to reverse a string and use
> TRT to find stuff that would otherwise have required a backwards loop
> search. Very handy.
>

​You might want to look at the TRTR and TRTRE instructions in the -10 POPS.

The argument characters of the first operand are
used to select function codes from a function-code
table designated by general register 1. For TRANS-
LATE AND TEST EXTENDED, the argument charac-
ters are processed in a left-to-right direction; for
TRANSLATE AND TEST REVERSE EXTENDED,
the argument characters are processed in a right-to-
left direction. When a nonzero function code is
selected, it is inserted in general register R2, the
related argument address is placed in general regis-
ter R1 , and the first-operand length in general register
R1 + 1 is decremented by the number of bytes pro-
cessed. The operation proceeds until a nonzero func-
tion code is encountered, the end of the first operand
is reached, or a CPU-determined number of charac-
ters have been processed, whichever occurs first.
The result is indicated in the condition code.

​



>
> .
> .
> .
> J.O.Skip Robinson
>

-- 

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: User Cats and Replication Sites

[Lizette Koehler]

Thanks to all the input.
We have successfully replicated the catalog to our alternate site and was able
to IMPORT CONNECT it and use it.

This will make our new process successful.  Since I have a tendency to over
think processes, this was very helpful.

Thank you very much Skip.

Lizette


> -Original Message-
> From: Lizette Koehler [mailto:stars...@mindspring.com]
> Sent: Wednesday, November 25, 2015 12:59 PM
> To: 'IBM Mainframe Discussion List'
> Subject: RE: User Cats and Replication Sites
> 
> To try and answer the question : Why do this?
> 
> If you do normal dumps/unloads of production data and ship it to your
> DEV/QA/Lifecycle environment - you might use productions like NDM, FTP,
> IND$FILE, etc... slow and dependent on your IP traffic or pipes.  Or you might
dump
> to tapes and either mail physical tape or have your tape environment use its
own
> replication process.
> 
> With Replication you could land your data needed in the lifecycle environment
and
> use the speed of Replication.  So, just pushing the data to a new location
faster.
> 
> Skip - This is what I was thinking.  I tend to over think, so this is very
helpful.
> 
> Thanks all very much
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of J O Skip Robinson
> > Sent: Wednesday, November 25, 2015 11:09 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: User Cats and Replication Sites
> >
> > (Reposting with edited subject. Sorry that I forget to massage it so
> > often.)
> >
> > In order to make a 'foreign' catalog available, I don't believe you
> > DEFINE RECAT because the catalog already exists. IMPORT CONNECT
> > (whereby you name the
> > volume) creates all the necessary pointers in the current system's master
catalog.
> > Furthermore, IMPORT CONNECT does not require that the catalog be
> > physically accessible. CATALOG task does not attempt to access the
> > catalog until you perform some action that requires opening it, such
> > as LIST. If the catalog is available, the catalog is opened and the
> > action completes. Otherwise you get a catalog open error. I'm basing
> > these observations on experience with making various master catalogs
> > available to each other, which we do a lot. The foreign catalog becomes a
'user
> catalog' in the current master regardless of its status in the foreign system.
> >
> > So in the steps you propose, eliminate 3. Step 4 can be done at any
> > time even if the volume is (still) offline; even now. Assuming that
> > you IMPORT CONNECT ahead of time, you're left with 1, 2, and 5. As for
> > aliases--if you want them--you can DEFINE ALIAS at any time after IMPORT
> CONNECT.
> >
> > .
> > .
> > .
> > 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 R.S.
> > Sent: Wednesday, November 25, 2015 2:33 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: (External):Re: User Cats and Replication Sites
> >
> > As far as I udnerstand you replicate UCAT, but cataloged datasets
> > (volumes with datasets).
> > I don't see any value in such approach. What's your goal?
> >
> > Note: it could worth to consider to replicate a set of datasets and UCAT.
> >
> > --
> > Radoslaw Skorupka
> > Lodz, Poland
> >
> >
> >
> >
> >
> >
> > W dniu 2015-11-24 o 23:24, Lizette Koehler pisze:
> > > I have two sites, A and B
> > >
> > > A usercat is replicated (asynchronously) from Site A to Site B (one
> > > way trip) The volumes are offline in SITE B and ONLINE in SITE A
> > >
> > > I want to use that usercat on Site B at some point.
> > >
> > > So my plan is to
> > > 1) Break Replication
> > > 2) Vary the replication Volumes online to Site B
> > > 3) Define  RECAT the USERCAT
> > > 4) Connect the UCAT to my MCAT on SITE B using IMPORT CONNECT.
> > > 5) Then access the files and VSAM datasets on SITE B through the
> > > replicated UCAT.
> > >
> > > I am fairly comfortable with an IMPORT CONNECT, but was wondering if
> > > there were other steps other than ensuring the aliases from Site A
> > > to this UCAT are available/installed/defined in Site B.
> > >
> > >
> > > Anything I need to be concerned about?
> > >
> > > I have discussed a couple of ideas with my team, but wanted to see
> > > if there was any other wisdom in this group that might help me make this
right.
> > >
> > > Thanks
> > >
> > >
> > > Lizette Koehler

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

Re: Translation Exception address shown in PGM System Trace entries

[Tony Harminc]

On 2 December 2015 at 06:47, Peter Hunkeler  wrote:

> When I look at system trace entries for translation exceptions (PBG 10,
> 11, etc) I see for example
>
> PGM011 _25A00E32  00060011 .. 07852001
> 8000 .. 4400
>
>
> (replaced blanks with dots, to somehow keep the data aligned)
>
>
> From the "MVS Tools & Service Aids" manual I understand that the last
> words on the two lines are the address which cause the tramslation
> exception (TEA, High word on upper line, low word on lower line). In the
> above example my program was accessing storage at x'_4000'
> (first reference). The trace entry shows this as x'_4400'.
>
> The TEA seems to always point to the start of the page where within the
> page the access was (which makes sense), but what is the x'400' in the low
> 12 bit telling me? The manual only talks about the high order bit
> indicating primary or secondary address space. I guess it some flags, but
> where is this documented?
>


In the Principles of Operation Chapter 3, under Assigned Storage Locations
168-175 (A8-AF hex). This part also refers to the descriptions of
[Enhanced] Suppression on Protection earlier in the same chapter. Perhaps
we're back to testing the facility bits before you can be sure what goes
on...

Bits 0-51 are the address (to the page level), and there are several flag
bits defined and other bits to the right that may be "unpredicatable" under
various circumstances.

This all assumes that the data at A8-AF is copied exactly to the trace
record, and that the trace record as formatted by IPCS shows exactly those
same bits. I guess that these are both the case, but I don't know.

Tony H.

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

Re: Straightforward way to determine hardware architecture level?

[Dana Mitchell]

On Wed, 2 Dec 2015 17:44:38 +, J O Skip Robinson  
wrote:

>I'm grateful to this thread for the news that MVCIN lives on. When it 
>disappeared on the 3090--talk about unexpected S0C1--I did a brief RIP and 
>never looked for it again. MVCIN allowed you to reverse a string and use TRT 
>to find stuff that would otherwise have required a backwards loop search. Very 
>handy.
>

I noticed the disappearance of MVCIN going from 4341 to 3083. I used it in a 
CICS program for precisely that reason, removing trailing blanks from print 
lines,  back when line speeds were so slow that this made quite a big 
difference.

Dana

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

Re: Translation Exception address shown in PGM System Trace entries

[Jim Mulder]

> > From the "MVS Tools & Service Aids" manual I understand that the last
> > words on the two lines are the address which cause the tramslation
> > exception (TEA, High word on upper line, low word on lower line). In 
the
> > above example my program was accessing storage at x'_4000'
> > (first reference). The trace entry shows this as x'_4400'.
> >
> > The TEA seems to always point to the start of the page where within 
the
> > page the access was (which makes sense), but what is the x'400' in the 
low
> > 12 bit telling me? The manual only talks about the high order bit
> > indicating primary or secondary address space. I guess it some flags, 
but
> > where is this documented?
> 
> In the Principles of Operation Chapter 3, under Assigned Storage 
Locations
> 168-175 (A8-AF hex). This part also refers to the descriptions of
> [Enhanced] Suppression on Protection earlier in the same chapter. 
Perhaps
> we're back to testing the facility bits before you can be sure what goes
> on...
> 
> Bits 0-51 are the address (to the page level), and there are several 
flag
> bits defined and other bits to the right that may be "unpredicatable" 
under
> various circumstances.
> 
> This all assumes that the data at A8-AF is copied exactly to the trace
> record, and that the trace record as formatted by IPCS shows exactly 
those
> same bits. I guess that these are both the case, but I don't know.

  Your guess is correct.

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: AW: Re: Is first page always backed by real storage upon return from STORAGE OBTAIN?

[nitz-ibm]

Peter,

> I'm allocating 10MiB, that is to work like fill page, I assume. IPCS tells me 
> the full page is X'00', so there is nothing written in that page.
> As said in another response, it's pure curiosity.

ask IPCS if the first page is really backed (ip rsmdata virtpage ra(x'page 
address')) and check the flags in the output. 

Barbara

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

Re: AW: Re: Is first page always backed by real storage upon return from STORAGE OBTAIN?

[Tony Harminc]

On 2 December 2015 at 13:38, nitz-ibm  wrote:

> ask IPCS if the first page is really backed (ip rsmdata virtpage ra(x'page
> address')) and check the flags in the output.


He already knows that *his* first page is backed; he's asking if this is
always the case.

Tony H.

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

Re: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[Doug]

Everyone pull that Write Punch and Silver patches and a box of cards..Grins

.

On Dec 2, 2015, at 12:33, J O Skip Robinson  wrote:

One urban legend (not necessarily fiction) is an explanation for the curious 
layout in EBCDIC coding. We have

A - I as C1 - C9
J - R as D1 - D9
S - Z as E2 - E9

Of course there is one more hex value in the neighborhood than there are 
letters in English, but why jump from D9 to E2 instead of using E1 - E8? The 
story I heard in computer school is that the EBCDIC ultimately derived from the 
punch card layout. To represent a letter, a card required both a 'zone' punch 
in one of the first three rows at the top plus a 'digit' punch further down in 
the same column. The first group of letters used the top zone row and so on 
through the alphabet. The last group of letters worked off the third zone row. 
The story goes that early punch equipment and card stock were imprecise and 
flimsy. In order to avoid having to deal with two vertically adjacent 
punches--third zone row plus first digit row--the code was constructed to skip 
the 1 digit for the letter S. Since a gap was needed anyhow, this was the ideal 
place for it. 

I love this story too much to challenge it.  

.
.
.
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, December 02, 2015 8:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: What's a "ton" of JCL? [was:RE: Straightforward way to 
determine hardware architecture level?]

> On Wed, 2 Dec 2015 10:02:01 -0600, Dana Mitchell wrote:
> 
>> On Tue, 1 Dec 2015 23:03:59 +, J O Skip Robinson wrote:
>> 
>> (This whole season feels like Friday.) A doughnut, on the other hand, 
>> requires the hole for its very definition. The hole supplies no mass or 
>> nutritional value, but without it the thing is not a doughnut. By contrast a 
>> punch card requires the solid part to give the holes meaning; they would 
>> otherwise collapse into gibberish. 
> 
> In school we verified that if you multi-punch every possible punch out 
> of a card, the result is indeed very fragile.  But it was fun to dupe
> 
This could inspire a Retro engineering project:  Given the constraint of 
required mechanical strength, devise an encoding that maximizes information 
density.  Akin to GCR:

   https://en.wikipedia.org/wiki/Group_code_recording

(How much does the hole diminish the mechanical strength of the bagel?)

-- 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: User Cats and Replication Sites

[J O Skip Robinson]

I'm a little curious about whether you defined aliases to the IMPORTed catalog. 
As I mentioned, we do this sort of thing a lot for master catalogs, but I don't 
recall doing it for a user catalog that probably has aliases on the original 
system. Aliases can be a problem when sharing a user catalog because of the 
likelihood of duplicates. A given alias can resolve only one way. 

.
.
.
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 Lizette Koehler
Sent: Wednesday, December 02, 2015 9:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: User Cats and Replication Sites

Thanks to all the input.
We have successfully replicated the catalog to our alternate site and was able 
to IMPORT CONNECT it and use it.

This will make our new process successful.  Since I have a tendency to over 
think processes, this was very helpful.

Thank you very much Skip.

Lizette


> -Original Message-
> From: Lizette Koehler [mailto:stars...@mindspring.com]
> Sent: Wednesday, November 25, 2015 12:59 PM
> To: 'IBM Mainframe Discussion List'
> Subject: RE: User Cats and Replication Sites
> 
> To try and answer the question : Why do this?
> 
> If you do normal dumps/unloads of production data and ship it to your 
> DEV/QA/Lifecycle environment - you might use productions like NDM, 
> FTP, IND$FILE, etc... slow and dependent on your IP traffic or pipes.  
> Or you might
dump
> to tapes and either mail physical tape or have your tape environment 
> use its
own
> replication process.
> 
> With Replication you could land your data needed in the lifecycle 
> environment
and
> use the speed of Replication.  So, just pushing the data to a new 
> location
faster.
> 
> Skip - This is what I was thinking.  I tend to over think, so this is 
> very
helpful.
> 
> Thanks all very much
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of J O Skip Robinson
> > Sent: Wednesday, November 25, 2015 11:09 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: User Cats and Replication Sites
> >
> > (Reposting with edited subject. Sorry that I forget to massage it so
> > often.)
> >
> > In order to make a 'foreign' catalog available, I don't believe you 
> > DEFINE RECAT because the catalog already exists. IMPORT CONNECT 
> > (whereby you name the
> > volume) creates all the necessary pointers in the current system's 
> > master
catalog.
> > Furthermore, IMPORT CONNECT does not require that the catalog be 
> > physically accessible. CATALOG task does not attempt to access the 
> > catalog until you perform some action that requires opening it, such 
> > as LIST. If the catalog is available, the catalog is opened and the 
> > action completes. Otherwise you get a catalog open error. I'm basing 
> > these observations on experience with making various master catalogs 
> > available to each other, which we do a lot. The foreign catalog 
> > becomes a
'user
> catalog' in the current master regardless of its status in the foreign system.
> >
> > So in the steps you propose, eliminate 3. Step 4 can be done at any 
> > time even if the volume is (still) offline; even now. Assuming that 
> > you IMPORT CONNECT ahead of time, you're left with 1, 2, and 5. As 
> > for aliases--if you want them--you can DEFINE ALIAS at any time 
> > after IMPORT
> CONNECT.
> >
> > .
> > .
> > .
> > 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 R.S.
> > Sent: Wednesday, November 25, 2015 2:33 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: (External):Re: User Cats and Replication Sites
> >
> > As far as I udnerstand you replicate UCAT, but cataloged datasets 
> > (volumes with datasets).
> > I don't see any value in such approach. What's your goal?
> >
> > Note: it could worth to consider to replicate a set of datasets and UCAT.
> >
> > --
> > Radoslaw Skorupka
> > Lodz, Poland
> >
> >
> >
> >
> >
> >
> > W dniu 2015-11-24 o 23:24, Lizette Koehler pisze:
> > > I have two sites, A and B
> > >
> > > A usercat is replicated (asynchronously) from Site A to Site B 
> > > (one way trip) The volumes are offline in SITE B and ONLINE in 
> > > SITE A
> > >
> > > I want to use that usercat on Site B at some point.
> > >
> > > So my plan is to
> > > 1) Break Replication
> > > 2) Vary the replication Volumes online to Site B
> > > 3) Define  RECAT the USERCAT
> > > 4) Connect the UCAT to my MCAT on SITE B using IMPORT CONNECT.
> > > 5) Then access the files and VSAM datasets on SI

AW: Re: AW: Re: Is first page always backed by real storage upon return from STORAGE OBTAIN?

[Peter Hunkeler]

>> ask IPCS if the first page is really backed (ip rsmdata virtpage ra(x'page
>> address')) and check the flags in the output.


> He already knows that *his* first page is backed; he's asking if this is
> always the case.




Well, at least I think I know it is backed from what IPCS tells me. IPCS Browse 
to the address returned by STORAGE OBTAIN says that all bytes in the first page 
(x000 to xFFF) are X'00' and then it says  "y000 to zFFF  
storage is unavailable". From this I conclude that the first page is backed.


I'll double check with the command Barbara suggested when I'm back in the 
office.


--
ßph

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

Re: Is first page always backed by real storage upon return from STORAGE OBTAIN?

[Jim Mulder]

> Allocating 100 MB area, I found that the first page in the newly 
> allocated area always seems to be backed by real storage upon return
> from STORAGE OBTAIN. Is this true? Where is this documented?

For requests where RSM is involved:
 If you specify BACK=ALL or BACK=NONE on the STORAGE macro,
that is treated as a hint by RSM, and may be what gets done.

 If you specify or default to BACK=BYSPT, the backing depends
on the subpool.  For most non-fixed subpools, we back the
first page (assuming there is sufficient real storage available).

  Except if you are running on a z13 machine with APAR OA46291
installed, in which case backing storage may not been freed
during a subsequent FREEMAIN, so it remains backed for a subsequent
GETMAIN. 

For requests where RSM is not involved (when the request
is satisfied from free storage represented by a DFE or FQE),
the backing is unchanged.

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: IEFSSREQ SSOBUSER Validate A JES2 Destid

[SUBSCRIBE IBM-MAIN Harold Gray]

Tony,

Thanks for the ideas especially looking at the source routine.  I just assumed 
that JES was mostly OCO now!

Anything I put in SSUSUSER is accepted. (ex HCGPRTR, XYZ, TRANSTT1 etc.).  
There are about 20 different id's that we use that do not correspond to JES.  
They are our own printers (desktops, LAN printers etc) that are only defined to 
our subsystem.

Our JES initialization is pretty much out of the box.  We just added our INIT 
and JOBCLASS definitions and an RSCS node for VM and that's it.  We don't have 
a real printer. 

In order to test this easier, I've copied the code into a test program and will 
be working with it to determine what is missing.  First pass test gives me a 
R15 = 20 (invalid block).  Hopefully will be able to report on what I find 
tomorrow. 

I am looking at the source now also.  Maybe something will pop out at me 
now   

Thanks again,

Harold

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

Re: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[Joel C. Ewing]

I just weighed the one almost-full box of some old programs and data
cards that I have retained for show-and-tell over the years, and it is a
little over 8 lbs.  Since the cards have holes punched, have some
lighter cardboard spacers, and new cards pack more tightly, I would
estimate 10 lbs as a better approximation for a box of 2000 unused cards.

Before we started conversion from DOS/VSE to MVS in 1985, all our
production JCL was on cards in several card filing cabinets.  My
recollection is that a cabinet drawer could hold around two boxes of
cards, so the maximum capacity of one cabinet might have been on the
order of 40 boxes of cards.  We could easily have had somewhere in the
neighborhood of 0.5 - 1.0 tons of cards containing JCL.  A larger shop
might literally have had several tons of JCL.
Joel C. Ewing

On 12/01/2015 02:41 PM, Barry Merrill wrote:
> I think a box of 2000 IBM cards is on the order of 6 pounds,
> so a TON of JCL cards would be 333 boxes, or about 666,666
> card images.
>
> But, the useful weight is zero, since we only use the holes.
>
> Barry
>
>
> Herbert W. "Barry" Merrill, PhD
> President-Programmer
> MXG Software
> Merrill Consultants
> 10717 Cromwell Drive
> Dallas, TX 75229-5112
> ba...@mxg.com
> Fax:  214 350 3694 - Still works, received as email
> Tel:  214 351 1966 - Unreliable, please use email
>
> www.mxg.comHomePage: FAQ answers most questions
> ad...@mxg.com  License Forms, Invoice, Payment, ftp information
> supp...@mxg.comTechnical Issues 
> MXG-L FREE ListServer  http://www.mxg.com/mxg-l_listserver/
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Farley, Peter x23353
> Sent: Tuesday, December 01, 2015 1:59 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: What's a "ton" of JCL? [was:RE: Straightforward way to determine
> hardware architecture level?]
>
> Re: "ton" of JCL, at least one large shop of my prior acquaintance (20 or so
> years ago) had over 250,000 members in the production applications JCL
> libraries.
>
> Not sure how much of that was obsolete at the time, but the batch operations
> control product they used had vast quantities of data as well.
>
> I think that counts as a "ton" or 2 . . . :)
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter Relson
> Sent: Tuesday, December 01, 2015 9:30 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Straightforward way to determine hardware architecture level?
>
> 
>
> . . . migrating from Cobol 4 to Cobol 5 without changing a ton of JCL (how
> much JCL is a "ton" anyway?).
>
> --


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

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

Re: at Re: AW: Re: Is first page always backed by real storage upon return from STORAGE OBTAIN?

[Jim Mulder]

> It's been several years since I had a hand in that code (as the team 
> leader of the VSM development team for the first release of MVS back in 
> 1972-1974), but someone mentioned the existence of the FQE (Free Queue 
> Element). The FQE described the number of bytes that were free within 
> the block of storage obtained. If the storage size requested was less 
> than a page or some multiple of pages, there would be some free space, 
> which would always be in the first page of the obtained area and an FQE 
> would be put at the start of that first page to identify the amount of 
> free space.
> 
> Storage requests were always oriented to the high end of of the last 
> page of the requested area, so that an attempt to access storage beyond 
> the end of the area would result in a page fault. The idea being that 
> the more common storage addressing error resulted from having a 
> legitimate storage address, but an offset that exceeded the size of the 
> actual obtained area.
> 
> Mike Myers
> Mentor Services Corporation

  VSM was completely rewritten in PL/S for the first release of MVS/XA.
As of that rewrite, all VSM control blocks are in cell pools in ELSQA,
so none are imbedded in the storage they describe.

  Taking a look at the ancient MVS/370 IEAVGM00 assembler module,
it appears that FQEs for LSQA and SQA were imbedded in the free space
that they described.  AQEs (representing TCB ownership for LSQA subpools
253 and 254) were also imbedded in the storage that they described. 

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: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[Shmuel Metz (Seymour J.)]

In
,
on 12/01/2015
   at 10:51 PM, Mike Schwab  said:

>Or a small flash drive of 64M to 2G.

Are they still making those?
 
-- 
 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: User Cats and Replication Sites

[J O Skip Robinson]

This looks like a great idea. Not sure how it might impact or be impacted by 
XRC, but it would be worth a look. Can't tell you how much grief we went 
through after usercats began dropping like flies. Fortunately it was DEV and 
not PROD, but lots of folks had their work disrupted for days on end. ;-( 

.
.
.
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 Ron Hawkins
Sent: Wednesday, December 02, 2015 3:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: User Cats and Replication Sites

Skip,

Is there a case here for taking regular snapshots of your UCATs and other small 
critical datasets?

Using persistent FlashCopy the UCATs or their volumes could be copied every 
hour and retained for quick receovery.

30 days' worth of hourly copies of a 1000 Cyl UCAT would use less than 1GB of 
space. Persistent FC would give you a good backup in both sites.

Ron



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of J O Skip Robinson
Sent: Sunday, November 29, 2015 11:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] User Cats and Replication Sites

Touche. We had a near catastrophic catalog problem some time back. Of course 
the replicated copy faithfully mirrored the errors, which were procedural 
rather than structural--tons of vital data deleted by mistake. Still I value 
mirroring for the classic case of disaster recovery: the production data center 
suddenly goes offline and cannot be resuscitated within an acceptable window. 
Mirrored DR allows you get up and running quickly, warts and all.

.
.
.
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 Shane Ginnane
Sent: Wednesday, November 25, 2015 2:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: User Cats and Replication Sites

On Wed, 25 Nov 2015 20:53:09 +, J O Skip Robinson wrote:

>Nothing beats replication, the more the better. 

Hmmm - unless you happen to have a critical error in the source. Replicating 
that quietly everywhere can leave you with non-IPLable systems *everywhere*.
Which you may not find out about until you try an IPL.
And yes, it has happened - LE bug that broke MCAT access for example; ran fine 
till IPL.
Brings to mind the "Schrodingers backup" discussion a few months back.

Shane ...


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

Re: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[Ward, Mike S]

Yea, you still have to feed the punch. :)

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kirk Wolf
Sent: Tuesday, December 01, 2015 5:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What's a "ton" of JCL? [was:RE: Straightforward way to determine 
hardware architecture level?]

On Tue, Dec 1, 2015 at 2:41 PM, Barry Merrill  wrote:

> I think a box of 2000 IBM cards is on the order of 6 pounds, so a TON 
> of JCL cards would be 333 boxes, or about 666,666 card images.
>
> But, the useful weight is zero, since we only use the holes.
>
> Barry
>
> 
Since this is a thread well suited to reminiscence, I will relay this story.

My father managed a very large IBM data center in the 70's.   Huge floor
space, and a very large room to store blank punched cards.
One of the systems programmers who worked there was a cranky joke-ster.
He would read every month in the company newsletter about monetary employee 
suggestion awards handed out for suggestions that he thought were silly and 
banal.

Like:
- there is an extra phone on some desk that is not needed
- unnecessary copies of some large daily report were being printed
- 

The companies policy was that employee suggestions would be reviewed, first by 
corporate, and then by the line manager in charge of implementation.
The employee would get a cash award based on some percentage of the first 
year's savings.

My father gets a call one day from a very excited guy in corporate.
He says that this systems programmer has submitted a suggestion that will save 
many tens of thousands of dollars a year in the data center.
The suggestion was something like:

=
We store millions of blank punched cards so that they are available when needed 
for the data center.

I have designed and written two assembler programs (see listings attached) that 
allow us to eliminate this storage requirement.

- The first program allows us to read and store a "master image" of a single 
blank punched card, electronically, on spinning magnetic disk.

- The second program can be run, whenever needed, to punch out blank cards from 
the image stored on disk.  A parameter card specifies the count of how many 
blank cards to punch.

...
=

My father had to gently explain to the corporate guy how he had been suckered.

Cheers,

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

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

==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

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

Re: Is first page always backed by real storage upon return from STORAGE OBTAIN?

[Shmuel Metz (Seymour J.)]

In <7481950488678847.wa.m42tomibmmainyahoo@listserv.ua.edu>, on
12/02/2015
   at 10:02 AM, Tom Marchant
<000a2a8c2020-dmarc-requ...@listserv.ua.edu> said:

>I've never seen an FQE located within the area containing the free
>space.

Newby. From IBM System/3S0 Operating System: Programmer's Guide to
Debugging OS Release 21.7, GC28-6670-6:

 FQE: The FQE describes a free area within a set of 2K blocks
 described by a DQE. It occupies the first eight bytes of that
 free area. Since the FQE is within the subpool, it has the
 same protect. key as the task active within that subpool.
 Extreme care should be exercised to see that FQEs are not
 destroyed by the problem program. If an FQE is destroyed, the
 free space that it describes is lost to the system and cannot
 be assigned through a GETMAIN. 

>The data areas book says that FQEs are in SP 245 or 255, SQA or
>LSQA.

That may be true for contemporary systems, but it was not always thus.
 
-- 
 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: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[Shmuel Metz (Seymour J.)]

In
,
on 12/02/2015
   at 05:33 PM, J O Skip Robinson  said:

>One urban legend (not necessarily fiction) is an explanation for the
>curious layout in EBCDIC coding.

UL? It's well documented. See, e.g., IBM System/360 Principles of
Operation, A22-6821-7[1], Appendix F, USASCII-8 and EBCDIC Charts, p.
150.2

>Of course there is one more hex value in the neighborhood than 
>there are letters in English, but why jump from D9 to E2 instead 
>of using E1 - E8? The story I heard in computer school is that the
>EBCDIC ultimately derived from the punch card layout.

As is implicit in the name, EBCDIC derives from BCD, which in turn
derive from the card encodings.

[1]
http://bitsavers.org/pdf/ibm/360/princOps/A22-6821-7_360PrincOpsDec67.pdf
 
-- 
 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: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[Ed Gould]

On Dec 2, 2015, at 2:58 PM, Joel C. Ewing wrote:


I just weighed the one almost-full box of some old programs and data
cards that I have retained for show-and-tell over the years, and it  
is a

little over 8 lbs.  Since the cards have holes punched, have some
lighter cardboard spacers, and new cards pack more tightly, I would
estimate 10 lbs as a better approximation for a box of 2000 unused  
cards.


Before we started conversion from DOS/VSE to MVS in 1985, all our
production JCL was on cards in several card filing cabinets.  My
recollection is that a cabinet drawer could hold around two boxes of
cards, so the maximum capacity of one cabinet might have been on the
order of 40 boxes of cards.  We could easily have had somewhere in the
neighborhood of 0.5 - 1.0 tons of cards containing JCL.  A larger shop
might literally have had several tons of JCL.
Joel C. Ewing



Joel:
Interesting. I have never worked in a shop (last say 45 years) where  
there was that much punched cards. There were some cases where the  
programmer submitted boxes of cards for one time update to a source  
lib and maybe 5 or so JCL cards. Production was similar one or two  
job cards a joblib and exec and then probably either a /* or // card.


None of the shops I have ever worked in used that much JCL PERIOD.

This does not include a very few jobs that had "data" cards mind you.  
Those types of jobs were rare and were handled as a card to tape on  
the dos side and used a tape on the MFT/MVT side.


Ed

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

IBM Systems Magazine - CICS V5.3 Focuses on Agility, Efficiency, Cloud and DevOps

[Ed Gould]

http://www.ibmsystemsmag.com/mainframe/administrator/cics/V5-3- 
announcement/?utm_campaign=ibm- 
enews&utm_medium=email&utm_source=mainframe- 
dec1-2015&utm_content=exclusive1-headline


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

QMF for Workstation accessing DB2 for z/OS

[Jose Munoz]

Dear all,

Someone has experience using QMF for workstation and accessing to DB2 for
z/OS with Arabic data?

When I use QMF on TSO the Arabic data shows fine but when I run the same
query on QMF for workstation, the Arabic data no show as it is, it is wrong
totally wrong.

QMF for workstation is using DRDA to access DB2 for z/OS V10.

Sorry to post this subject here...

-- 
Regards
Jose Munoz
Senior IT Architect
(+965) 99925167
Kuwait

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

AW: Re: IEFSSREQ SSOBUSER Validate A JES2 Destid

[Peter Hunkeler]

> Anything I put in SSUSUSER is accepted. (ex HCGPRTR, XYZ, TRANSTT1 etc.).  
> There are about 20 different id's that we use that do not correspond to JES.  
> They are our own printers (desktops, LAN printers etc) that are only defined 
> to our subsystem.



What do you mean with "do not correspond to JES"? Have you tried some name that 
would most certinly be invalid, such as ABC.DEF or ABC??DEF. You don't need to 
define destinations to JES, so I assume JES will accept any name unless is 
conflicts with it's naming rules.




I only had a quick look at what SSI 11 offers. I don't see a validation option, 
only the conversion options, which you don't seem to ask for. You've set 
SSUSFLG1 to X'00'.


--
Peter Hunkeler



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

AW: Re: Is first page always backed by real storage upon return from STORAGE OBTAIN?

[Peter Hunkeler]

Thanks, Jim, just the information I was looking for. I have not specified 
BACK=, so the default is taken. The SP is 11, so non-fixed.


--
Peter Hunkeler




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

AW: Re: Translation Exception address shown in PGM System Trace entries

[Peter Hunkeler]

Thanks to Tony and Jim.


--
Peter Hunkeler



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