Re: GETMAIN LOC=32

[somitcw]

SG24-7605-00
z/OS Version 1 Release 10 Implementation
April 2009
Pages 6 and 104
Claims that next to E-Nuc is ESQA, ELPA, ECSA, then E-private.

When did they move?
Are we requesting a feature that is already there?
IBM could do that real quick.

Paul's wanting SVC 120 to get memory up to 4GB-1 and
have IARV64 and IARST64 stick with 33 to 64bit addresses
would actually need a couple of code changes and a little
documentation.

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

Re: [TSO-REXX] Sdsf rexx

[Edward Gould]

> On May 10, 2018, at 10:30 PM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> ——SNIP---
> 
> Fear of indention is collateral damage of RECFM=FB,80.  When Rexx first came
> to TSO it came with a GIM that recommended RECFM=VB,LRECL=generous.
> IBM then ignored its own advice and made SYSPROC FB,80, dragging wiser
> coders down with it.
> —_SNIP——

This issue long predates Rexx. Someone please correct me but the first conflict 
came in Netview (no idea of release but it was early even then)
There also may have been an issue with SPF (early version) We did not jump on 
that bandwagon .
Memory says it was Netview though. They were the second people to come along 
with clists. This was in the 70’s (i think) I was caught in the middle trying 
to keep both.
My memory also could be wrong as somewhere in this mess as IBM insisted that 
source had to be maintained by IEBUPDTE. Somewhere in that mess VB won out, I 
*vaguely* remember arguments at SHARE/GUIDE (not sure which) as what the right 
way to go. A memory says there were factions at SHARE and they almost got into 
a fight over this but it was almost 40 years ago and after drinking at Scids 
everybody calmed down. It is still discussed today so nobody was happy with the 
solution. REXX for MVS did not appear until 1992(?). I remember it was that 
time frame as management wanted some device support on an IPO but I knew the 
next IPO contained REXX so I was able to hold back and wait for REXX.

Ed
> -- gil


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

Re: [TSO-REXX] Sdsf rexx

[Paul Gilmartin]

On Thu, 10 May 2018 21:09:48 -0400, Hobart Spitz wrote:

>For those who may not be aware, SIGNAL is *not* a GOTO.
>
>I counted 18 SIGNALs, and only 1 CALL.  Many of the SIGNALs here seem to
>have been better done with DO...END.
>
>In the words of TRL, SIGNAL terminates "all active pending DO loops, DO
>groups, IF constructs, SELECT construct, and INTERPRET instructions" such
>that "they cannot be reactivated".
>
>With apologies to Eileen and/or the original coder:  Not being aware of
>that fact has apparently let the coder down into a "black hole".  I hope my
>post can encourage anyone who thinks this is the way to write REXX, to do
>better, and that anyone who copies sees this code not use it as an model
>for anything.
>
>This is not an issue of style, pedantics, or personal preference.  Using
>SIGNAL this way is even more of a barrier to maintainable, readable code
>than a GOTO.  For more information, see the appropriate resources.
> 
I saw that; I was appalled.  Also by the (lack of) indention.  There were a
few meager DO loops, mostly with a single line body.

Fear of indention is collateral damage of RECFM=FB,80.  When Rexx first came
to TSO it came with a GIM that recommended RECFM=VB,LRECL=generous.
IBM then ignored its own advice and made SYSPROC FB,80, dragging wiser
coders down with it.

"Black hole" is an apt metaphor.  It's hard to escape.  To convert SIGNA
loops to DO loops the programmer must eliminate any interior SIGNALs.

We had a VM sysprog who was SIGNAL-afficted.  Now retired, but his ugly
code remains.  In some fairnes, it was an interactive menu-driven system
and some menus had options to jump to other menus.  But I would have
used a SELECT within a main DO loop, even though that mostly emulates
GOTO.

-- gil

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

Re: GETMAIN LOC=32

[Lee B]

Agreed. And I'll wager any readers of the Herc lists will not have been 
surprised at the way this thread progressed...

Lee B.

On 2018年5月11日 9:01:24 GMT+09:00, "Jackson, Rob"  
wrote:
>Hear hear.  I wholeheartedly agree.  This started off bewildering; then
>it became entertaining; now it's just irritating.  I'm adding a filter
>to dump "GETMAIN LOC=32" in deleted.  This has turned from a flight of
>fantasy into a waste of resources.
>
>First Tennessee Bank
>Mainframe Technical Support
>
>
>-Original Message-
>From: IBM Mainframe Discussion List  On
>Behalf Of Steve Smith
>Sent: Thursday, May 10, 2018 5:43 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: GETMAIN LOC=32
>
>[External Email]
>
>Somewhere along the way, you seem to have missed the point.  Which is,
>the proposal is REJECTED, with prejudice.  It has no more chance than a
>baby june bug in a 100-watt zapper (unless your org. provides >5% of
>IBM's revenue, and Ginny R. always answers your calls).
>
>Y'all feel free to continue down your primrose path, perhaps noting
>that no one is listening to you anymore.  You've come up with a
>solution to a problem no one has.  The best way to shorten this
>tiresome thread would be to stop extending it.  Nevertheless, I'm
>confident P. Edwards will have to have the last word. Which is fine and
>dandy; but the sooner the better.
>
>sas
>
>On Thu, May 10, 2018 at 5:27 PM, somitcw <
>01b1f179dc6e-dmarc-requ...@listserv.ua.edu> wrote:
>
>> ​...
>> Please help shorten this thread by helping with the wording needed to
>
>> request an AMODE 64 enhancement for AMODE 64 programs that would 
>> double the 4-byte addressable for data.
>> Moving extended common would be icing on the cake.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions, send
>email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>FIRST TENNESSEE
>
>Confidentiality notice: 
>This e-mail message, including any attachments, may contain legally
>privileged and/or confidential information. If you are not the intended
>recipient(s), or the employee or agent responsible for delivery of this
>message to the intended recipient(s), you are hereby notified that any
>dissemination, distribution, or copying of this e-mail message is
>strictly prohibited. If you have received this message in error, please
>immediately notify the sender and delete this e-mail message from your
>computer.
>
>
>--
>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: [TSO-REXX] Sdsf rexx

[Hobart Spitz]

For those who may not be aware, SIGNAL is *not* a GOTO.

I counted 18 SIGNALs, and only 1 CALL.  Many of the SIGNALs here seem to
have been better done with DO...END.

In the words of TRL, SIGNAL terminates "all active pending DO loops, DO
groups, IF constructs, SELECT construct, and INTERPRET instructions" such
that "they cannot be reactivated".

With apologies to Eileen and/or the original coder:  Not being aware of
that fact has apparently let the coder down into a "black hole".  I hope my
post can encourage anyone who thinks this is the way to write REXX, to do
better, and that anyone who copies sees this code not use it as an model
for anything.

This is not an issue of style, pedantics, or personal preference.  Using
SIGNAL this way is even more of a barrier to maintainable, readable code
than a GOTO.  For more information, see the appropriate resources.

It should not even be necessary to say it, but I vote for SIGNAL-less
coding (except for SIGNAL ON/OFF, and where actually necessary.)

OREXXMan
JCL is the buggy whip of 21st century computing.
We want Pipelines in the z/OS base.

On Tue, May 8, 2018 at 4:18 PM, Barkow, Eileen 
wrote:

> This is a SDSF/REXX clist that extracts sysout datasets with names S*
> on the ST queue and archives them to datatsets.
> It can be adapted to extract datasets with other criteria.
>
> /* REXX */
> TRACE e
> /*ISFTRACE="ON" */
> /*ISFTRMASK="ALL" */
> PROFILE NOPREFIX
> rc=isfcalls('ON')
> PARSE ARG p1 p2 p3
> IF p1 ="" THEN DO
> ISFPREFIX = 'CICS*'
> END
> ELSE
> DO
> ISFPREFIX = p1
> END
> IF p2 ="" THEN DO
> HLQ   = 'XCICSR.'
> END
> ELSE
> DO
> HLQ   = p2||'.'
> END
> IF p3 ="" THEN DO
> ISFPRTVOLSER = 'W1STG1'
> END
> ELSE
> DO
> ISFPRTVOLSER = 'W1STG1'
> END
> ISFOWNER  = '*'
> ISFFILTER = 'QUEUE PRINT'
> CICSJOBN = ISFPREFIX
> ASTPO = POS('*',CICSJOBN)
> if ASTPO ^= 0 then
> do
> ASTPO = ASTPO - 1
> CICSJOBN = SUBSTR(CICSJOBN,1,ASTPO)
> end
> /* Access the ST panel. A TOKEN variable is */
> /* created for each row which is subsequently */
> /* needed to perform actions */
> Address SDSF "ISFEXEC ST"
> lrc=rc
> call msgrtn
> /* Find a job starting with CICSjobn and list data sets */
> /* rexx */
> numrows=isfrows
> if isfrows<=0 then exit
> six = 1
> setix:
> if six > numrows then signal endit
> do ix=six to numrows /* Loop for all rows returned */
> if pos(CICSJOBN,JNAME.ix) = 1 then /* If this is desired row */
> do
> /* Issue the ? action character for the job */
> /* identified by the token variable. Note */
> /* the token must be enclosed in single quotes */
> /* Use the prefix option to ensure unique */
> /* variables are created, beginning with JDS_ */
> Address SDSF "ISFACT ST TOKEN('"TOKEN.ix"') PARM(NP ?)",
> "("prefix JDS_
> if JDS_DDNAME.0 = 0 then exit
> lrc=rc
> if lrc<>0 then
> exit 20
> startjx = 2
> jf = 0
> IF JDS_DDNAME.0 =1 then signal SETJL1
> /***if 2 jesmsglgs use 2nd  */
> do jf = 2 to JDS_DDNAME.0 /* loop for all rows returned */
> IF SUBSTR(JDS_DDNAME.jf,1,4) = 'JESM' then signal GETJLINF
> end
> SETJL1:
> startjx = 1
> GETJLINF:
> do jx=startjx to JDS_DDNAME.0 /* loop for all rows returned */
> IF SUBSTR(JDS_DDNAME.jx,1,4) = 'JESM' then signal GOTJESM
> end
> signal nextjob
> lrc=rc
> call msgrtn
> if lrc<>0 then do
> exit 20
> GOTJESM:
> sjx= jx  /*save position of current ddname entry */
> Address SDSF "ISFACT ST TOKEN('"JDS_TOKEN.jx"') PARM(NP SA)"
> lc = rc
> k = isfddname.0
> /***READ 3RD   RECORD TO GET STARTED TASK NUMBER  */
>  "EXECIO 1  DISKR " isfddname.k 3 " (STEM STCREC. "
>  lrc = rc
>  If lrc ^= 0 THEN SIGNAL NOSTC
>  PARSE VAR STCREC.1  S1 STRNUM S3
>  STRNUM = STRIP(STRNUM)
>  STCNUM = SUBSTR(STRNUM,1,8)
> /***READ 4TH   RECORD TO GET JOBNAME  */
>  "EXECIO 1  DISKR " isfddname.k 4 " (STEM STCREC. "
>  PARSE VAR STCREC.1  X1 X2 X3 JN XX
>  JN = STRIP(JN)
>  "EXECIO 0  DISKR " isfddname.k  " (finis"
>  sjx = sjx+1
>  signal setjx
> setjx:
> IF sjx >  JDS_DDNAME.0 then signal nextjob
> do jx=sjx to JDS_DDNAME.0 /* loop for all rows returned */
> IF SUBSTR(JDS_DDNAME.jx,1,4) = 'S000' then signal GOTSTAT
> end
> signal NOSTAT
> NOSTC:
> EXIT
> NOSTAT:
> six =six+1
> signal setix
> EXIT
> GOTSTAT:
> Address SDSF "ISFACT ST TOKEN('"JDS_TOKEN.jx"') PARM(NP SA)",
> "("prefix SDS_
> lc = rc
> k = isfddname.0
> STATIN = isfddname.k
> STATDS = isfdsname.k
> /***READ FIRST RECORD TO GET INFO TO WRITE OUTPUT DATAST  */
>  "EXECIO *  DISKR " isfddname.k " (STEM REC. "
>  lrc = rc
>  If lrc ^= 0 THEN SIGNAL noapp
>  PARSE VAR REC.1  A  A2 A3 A4 A5 JN A7 JD A9 JT A6
>  IF SUBSTR(A,1,4) = '1App' THEN SIGNAL GOTAPP
> noapp:
>  EXIT
> GOTAPP:
>  JDATE= ".D"||SUBSTR(JD,1,2)||SUBSTR(JD,4,2)||SUBSTR(JD,9,2)
>  JTIME= ".T"||SUBSTR(JT,1,2)||SUBSTR(JT,4,2)||SUBSTR(JT,7,2)
>  STPNUM = "."||STCNUM
>  "FREE FILE(STATOUT)"
>  /*OUTDS = "XCICS."||JN||JDATE||STPNUM||JTIME */
>  OUTDS =  HLQ||JN||JDATE||STPNUM||JTIME
> /*if SYSDSN(OUTDS) ^= 'OK' */
> /* THEN SIGNAL 

Re: Anybody running this?

[Greg Boyd]

I don't think the agenda for St. Louis has been published yet, but Eysha Powers 
did a z14 Crypto Update in Sacramento.  Roan Dawkins did a similar session at 
IBM Tech U in Orlando last week.
Greg
Greg Boyd
www.mainframecrypto.com


On Thu, 10 May 2018 17:05:39 -0500, Edward Gould  
wrote:

>> On May 10, 2018, at 1:05 PM, Greg Boyd  wrote:
>> 
>> I know of several customers running this newest level.  The other new 
>> function is support for STATs.  That's an option you can enable to generate 
>> SMF records with counters on use of engines, algorithms and services.  Could 
>> be a significant step forward in monitoring your crypto workload.
>> Greg
>> Greg Boyd
>> www.mainframecrypto.com 
>
>That sounds promising. Does anyone know if there will be a SHARE presentation 
>on this at the next SHARE?
>
>Ed
>
>
>--
>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: GETMAIN LOC=32

[somitcw]

Thank you, but I don't believe that that is what Paul trying to do?
Paul requested GETMAIN 
LOC=2GBto4GB-1.if.unavailable.16MBto4GB-1.if.unavailable.0Bto16MB-1
Moving extended common to put it near the common E-Nuc was not originally 
thought of.

Is there anyway the "already available" could block allocation in the 4GB to 
32GB-1 range.
Perhaps GETSTOR for all 30GB to get 2GB and not use the 28GB over 4GB-1 ?
Or an RFE to add IARV64 GETSTOR with Use2Gto4G=YES
Which still would not add what Paul said he was after and when full, might not 
drop to lower
memory addresses.

Or as most people would agree, kill the thread.

 - - - old notes below - - -

On Thu, 10 May 2018 18:58:41 -0400, Jim Mulder  posted:

  It would be a waste of time to submit such an RFE.

  GETMAIN will not be changed to manage addresses 
above 2GB.

  Extended common will not be moved.

  The interface to allocate the storage in the 2GB to 4GB-1 
address range is already available - 
IARV64 GETSTOR  with  USE2GTO32G=YES
 
Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY

> The request was for suggested wording for an RFE for AMODE 64 to change
> data addresses 2GB to 4GB-1 so AMODE 64 could use GETMAIN to get
> memory there.  To insure that only AMODE 64 programs that wanted the
> memory, the AMODE 64 program would specify something like
> GETMAIN LOC=32 in the source of the AMODE 64 program.
> 
> The RFE would double the addressable memory with an address
> storable in four bytes for data for an AMODE 64 program.
> That is an incredible enhancement allowed for AMODE 64 programs.
> If people wish to convert old programs from their existing AMODE to
> a different AMODE, that is fine.  If they want to use the AMODE 64
> enhancement that the RFE would request, then their program would
> need to be AMODE 64 or converted to AMODE 64.
> 
> Posts about BAL, BALR, crap bytes, AMODE 24, AMODE 31, AMODE 32,
> S/370-24bit, S/370-31bit, S/360-32bit, MVS 3.8j, PDOS, MVS/XA,
> ESA/370, and other totally off a tangent responses do not help
> address the RFE wording question.
> 
> Please help shorten this thread by helping with the wording needed to
> request an AMODE 64 enhancement for AMODE 64 programs that
> would double the 4-byte addressable for data.
> Moving extended common would be icing on the cake.

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

Sample program for JES dataset read?

[Charles Mills]

Is there a sample program - say in SYS1.SAMPLIB or on the CBT tape (yes, I
looked) - that shows an example of how to allocate and read a JES spool
dataset?

How to do this, in other words: https://ibm.co/2IbrcGV  

Charles

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

Re: PDSE V2 Corruption - A Warning - Correction (kinda)

[Tabari H Alexander]

> Also, there is an interesting (at least for me) RFE that proposes either 
to
> change the Edit of an "old" member generation to View, or to allow the 
Edit
> but save it like a new generation. Here =>
> 
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=101120


FWIW, the default behavior for save in ISPF can be changed => 
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.f54pc00/isppcgeniset.htm
 


---
Tabari Alexander
IBM Advisory Software Engineer
PDSE Product Owner

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

Re: GETMAIN LOC=32

[Jackson, Rob]

Hear hear.  I wholeheartedly agree.  This started off bewildering; then it 
became entertaining; now it's just irritating.  I'm adding a filter to dump 
"GETMAIN LOC=32" in deleted.  This has turned from a flight of fantasy into a 
waste of resources.

First Tennessee Bank
Mainframe Technical Support


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Smith
Sent: Thursday, May 10, 2018 5:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

[External Email]

Somewhere along the way, you seem to have missed the point.  Which is, the 
proposal is REJECTED, with prejudice.  It has no more chance than a baby june 
bug in a 100-watt zapper (unless your org. provides >5% of IBM's revenue, and 
Ginny R. always answers your calls).

Y'all feel free to continue down your primrose path, perhaps noting that no one 
is listening to you anymore.  You've come up with a solution to a problem no 
one has.  The best way to shorten this tiresome thread would be to stop 
extending it.  Nevertheless, I'm confident P. Edwards will have to have the 
last word. Which is fine and dandy; but the sooner the better.

sas

On Thu, May 10, 2018 at 5:27 PM, somitcw < 
01b1f179dc6e-dmarc-requ...@listserv.ua.edu> wrote:

> ​...
> Please help shorten this thread by helping with the wording needed to 
> request an AMODE 64 enhancement for AMODE 64 programs that would 
> double the 4-byte addressable for data.
> Moving extended common would be icing on the cake.

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

Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.


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

Re: GETMAIN LOC=32

[Jim Mulder]

  It would be a waste of time to submit such an RFE.

  GETMAIN will not be changed to manage addresses 
above 2GB.

  Extended common will not be moved.

  The interface to allocate the storage in the 2GB to 4GB-1 
address range is already available - 
IARV64 GETSTOR  with  USE2GTO32G=YES
 
Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY

> The request was for suggested wording for an RFE for AMODE 64 to change
> data addresses 2GB to 4GB-1 so AMODE 64 could use GETMAIN to get
> memory there.  To insure that only AMODE 64 programs that wanted the
> memory, the AMODE 64 program would specify something like
> GETMAIN LOC=32 in the source of the AMODE 64 program.
> 
> The RFE would double the addressable memory with an address
> storable in four bytes for data for an AMODE 64 program.
> That is an incredible enhancement allowed for AMODE 64 programs.
> If people wish to convert old programs from their existing AMODE to
> a different AMODE, that is fine.  If they want to use the AMODE 64
> enhancement that the RFE would request, then their program would
> need to be AMODE 64 or converted to AMODE 64.
> 
> Posts about BAL, BALR, crap bytes, AMODE 24, AMODE 31, AMODE 32,
> S/370-24bit, S/370-31bit, S/360-32bit, MVS 3.8j, PDOS, MVS/XA,
> ESA/370, and other totally off a tangent responses do not help
> address the RFE wording question.
> 
> Please help shorten this thread by helping with the wording needed to
> request an AMODE 64 enhancement for AMODE 64 programs that
> would double the 4-byte addressable for data.
> Moving extended common would be icing on the cake.



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

Re: Anybody running this?

[Edward Gould]

> On May 10, 2018, at 1:05 PM, Greg Boyd  wrote:
> 
> I know of several customers running this newest level.  The other new 
> function is support for STATs.  That's an option you can enable to generate 
> SMF records with counters on use of engines, algorithms and services.  Could 
> be a significant step forward in monitoring your crypto workload.
> Greg
> Greg Boyd
> www.mainframecrypto.com 

That sounds promising. Does anyone know if there will be a SHARE presentation 
on this at the next SHARE?

Ed


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

Re: Tapeless delivery

[Mike Schwab]

https://www.theregister.co.uk/2018/05/10/ibm_bans_all_removable_storage_for_all_staff_everywhere/
Not sure what hoops you will have to jump through to send any data on
any media soon.

On Sat, Apr 28, 2018 at 3:25 AM, Edward Gould  wrote:
>> On Apr 27, 2018, at 1:01 PM, J R  wrote:
>>
>>
>>
>>> Dr. Evil wrote:
>>>
>>> ... The data that is in these files are only known by the President of the 
>>> company and I think one VP. The President’s boss work’s in another country 
>>> and the board is scattered around the world, if I met one in the hallway I 
>>> would not know him. The “board” is only known by the President. Where the 
>>> money comes from that pays us, I have no clue as we do not (AFAIK) publish 
>>> or see or exchange anything that would bring $$ into the company. All I 
>>> know is that everyones gets paid (well) and there hasn’t been a person 
>>> dismissed/fired/let go/asked to find another job.
>>
>> It's inconceivable that you expect us to believe such rubbish.  You are not 
>> an employee, you don't get paid, and yet you can waltz in every day and play 
>> in the sandbox.  Does this appear to be an ultra secure environment?  I 
>> don't think so!
>>
>> BTW the asylum called; if you leave now you'll be just in time for a story 
>> before bed.
>
> I don’t care what you do or do not believe.
> I work in this situation . I have worked in other crazy companies, this one 
> is security conscious. Others have each their own  crazy world, luckily in 
> the past it was reasonable to a point. This one seems to have a privacy 
> issue. The company is legit and they have the connections to prove it. I live 
> and work in this environment for free, they only thing in real money that it 
> cost me is gas/food. I have enough money to keep me doing what I have done in 
> the past. These people are pleasant to work with. In the past I have worked 
> in several hostile work environments, this is interesting and allows me to 
> try things out that in other companies I would be shutdown. The people are 
> really nice and it nice to work in an environment that learning is 
> encouraged. I will continue to work here for a few more years and then really 
> retire.
>
> Ed
>  I could write several volumes of bad companies I have worked for, This 
> company is actually fun to work for, I wake up in the AM and I am happy to go 
> to work. The bad companies are starting to disappear into the bitbucket. I 
> enjoy retirement doing what I did before, wouldn’t you like to have something 
> fun and interesting to do in your retirement?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: GETMAIN LOC=32

[Charles Mills]

Amen. Flagellum equus mortuus. The suggested wording for the RFE is "never 
mind."

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Thursday, May 10, 2018 2:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

Somewhere along the way, you seem to have missed the point.  Which is, the
proposal is REJECTED, with prejudice.  It has no more chance than a baby
june bug in a 100-watt zapper (unless your org. provides >5% of IBM's
revenue, and Ginny R. always answers your calls).

Y'all feel free to continue down your primrose path, perhaps noting that no
one is listening to you anymore.  You've come up with a solution to a
problem no one has.  The best way to shorten this tiresome thread would be
to stop extending it.  Nevertheless, I'm confident P. Edwards will have to
have the last word. Which is fine and dandy; but the sooner the better.

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

Re: GETMAIN LOC=32

[Paul Edwards]

On Thu, 10 May 2018 16:27:50 -0500, somitcw  wrote:

>The RFE would double the addressable memory with an address
>storable in four bytes for data for an AMODE 64 program.
>That is an incredible enhancement allowed for AMODE 64 programs.

I'm glad someone else can see that!

Thankyou for your post.

BFN. Paul.

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

Re: GETMAIN LOC=32

[Steve Smith]

Somewhere along the way, you seem to have missed the point.  Which is, the
proposal is REJECTED, with prejudice.  It has no more chance than a baby
june bug in a 100-watt zapper (unless your org. provides >5% of IBM's
revenue, and Ginny R. always answers your calls).

Y'all feel free to continue down your primrose path, perhaps noting that no
one is listening to you anymore.  You've come up with a solution to a
problem no one has.  The best way to shorten this tiresome thread would be
to stop extending it.  Nevertheless, I'm confident P. Edwards will have to
have the last word. Which is fine and dandy; but the sooner the better.

sas

On Thu, May 10, 2018 at 5:27 PM, somitcw <
01b1f179dc6e-dmarc-requ...@listserv.ua.edu> wrote:

> ​...
> Please help shorten this thread by helping with the wording needed to
> request an AMODE 64 enhancement for AMODE 64 programs that
> would double the 4-byte addressable for data.
> Moving extended common would be icing on the cake.

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

Re: GETMAIN LOC=32

[somitcw]

Tom Marchant  posted:
>On Thu, 10 May 2018 08:47:33 -0500, Paul Edwards wrote:
>This is a matter of defining "best programming
>>practices" and noting that you can't rely on the
>>BALR crap byte
> est for you perhaps. Using only a limited subset of the instruction set. 
>And you don't seem to understand the value of the linkage information 
>saved in R1 by BAL and BALR in AMODE(24).
> This is a pointless discussion.
> -- 
>Tom Marchant

The request was for suggested wording for an RFE for AMODE 64 to change
data addresses 2GB to 4GB-1 so AMODE 64 could use GETMAIN to get
memory there.  To insure that only AMODE 64 programs that wanted the
memory, the AMODE 64 program would specify something like
GETMAIN LOC=32 in the source of the AMODE 64 program.

The RFE would double the addressable memory with an address
storable in four bytes for data for an AMODE 64 program.
That is an incredible enhancement allowed for AMODE 64 programs.
If people wish to convert old programs from their existing AMODE to
a different AMODE, that is fine.  If they want to use the AMODE 64
enhancement that the RFE would request, then their program would
need to be AMODE 64 or converted to AMODE 64.

Posts about BAL, BALR, crap bytes, AMODE 24, AMODE 31, AMODE 32,
S/370-24bit, S/370-31bit, S/360-32bit, MVS 3.8j, PDOS, MVS/XA,
ESA/370, and other totally off a tangent responses do not help
address the RFE wording question.

Please help shorten this thread by helping with the wording needed to
request an AMODE 64 enhancement for AMODE 64 programs that
would double the 4-byte addressable for data.
Moving extended common would be icing on the cake.

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

Re: GETMAIN LOC=32

[Paul Edwards]

On Thu, 10 May 2018 14:35:08 -0500, Tom Marchant  
wrote:

>>This is a matter of defining "best programming
>>practices" and noting that you can't rely on the
>>BALR crap byte
>
>Best for you perhaps. Using only a limited subset of the instruction set. 
>And you don't seem to understand the value of the linkage information 
>saved in R1 by BAL and BALR in AMODE(24).

Wow, we're still struggling to wean people off
AM24, nevermind writing 64-bit apps.

Do you want the linkage information for debugging
purposes or are you trying to access it programmatically?

If the former, then you can still write trimodal
applications according to what I would call best
programming practices, but simply mark your
modules as AM24 so that they always get run
in AM24 whenever you are trying to debug them.
Someone else who wants lots of memory can
mark the exact same load module as AM31
or AM64 instead.

BFN. Paul.

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

z/OSMF Data Directory Location

[John Eells]

On May 1st (when I wasn't looking), the PTF for z/OSMF APAR PI92211 closed.

This PTF moves the default location for the z/OSMF data directory from 
under /var (a system-specific directory) to under /global (a 
sysplex-wide directory) with updated samples and documentation.  This 
move puts the data repository for z/OSMF's sysplex management 
applications to a spot where it can be mounted on whichever system 
z/OSMF happens to start on, making it more likely to be congruent with 
other repositories that are usually sysplex-wide (like the security 
database and TCP/IP profile).  Also, it simplifies moving the server 
between systems, including for recovery.


If you run more than one z/OSMF in a sysplex concurrently, there's a bit 
more to the story; in that case, you'll need one directory under /global 
for each autostart group.


An updated z/OSMF Configuration Guide was posted a few days after the 
PTF became available.


If you are setting up z/OSMF for the first time, use the updated book 
and the new samples for setup.  If you've got it set up already, I 
recommend you review your setup and (most likely) move the z/OSMF data 
repository from /var/zosmf to /global/zosmf when you get around to it.


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

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

Re: PDSE V2 Corruption - A Warning - Correction (kinda)

[Lucas Rosalen]

Hey fellas,

Apparently the APAR has been closed and PTFs are: z/OS 2.1 UA96169; z/OS
2.2 UA96170; z/OS 2.3 UA96168

Also, there is an interesting (at least for me) RFE that proposes either to
change the Edit of an "old" member generation to View, or to allow the Edit
but save it like a new generation. Here =>
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=101120



---
*Lucas Rosalen*
rosalen.lu...@gmail.com / lucas.rosal...@ibm.com
http://br.linkedin.com/in/lrosalen


2018-02-14 21:01 GMT+01:00 Dyck, Lionel B. (TRA) :

> IBM has taken an APAR on this:
>
> From IBM:
> ===
> APAR OA54890 has been opened.
>
> Additionally, DSC has a number of setup/processing parameters. Under my
> setup an edit of a non-zero generation is like a STOW REPLACE of the
> member, the edited generation replaces the base and the rest of the
> generations roll accordingly.
> ===
>
> So it would seem that the DSC developers figured out that editing a non-0
> generation made no sense as the updates could not be accessed from JCL,
> Dynamic Allocation, or 99% of ISPF application and utilities. I may be
> biased but I prefer the approach that PDSEGEN takes which is to convert the
> Edit request to View.
>
> --
> Lionel B. Dyck <
> Mainframe Systems Programmer - TRA
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Dyck, Lionel B. (TRA)
> Sent: Wednesday, February 14, 2018 11:47 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: PDSE V2 Corruption - A Warning - Correction (kinda)
>
> According to IBM PDSE L2 this is not true corruption but an issue with
> IEBPDSE for which an APAR will be created.
>
> --
> Lionel B. Dyck <
> Mainframe Systems Programmer - TRA
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Dyck, Lionel B. (TRA)
> Sent: Wednesday, February 14, 2018 8:21 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] PDSE V2 Corruption - A Warning
>
> If you are using PDSE V2 libraries with member generations enabled be
> aware that native ISPF, and potentially other tools, allow you to actually
> EDIT a generation. When doing this and doing a SAVE the updated generation
> does not replace the base member and no new generation is created.
>
> BUT what does also happen is that the PDSE becomes corrupt as reported by
> the IEBPDSE utility.
>
> When a PDSE is corrupt you may see any, or all, or none, of the following:
>
>
> 1.  Corrupt members or generations
>
> 2.  Missing members or generations
>
> 3.  No change until something else happens
>
> Note: If you are using PDSEGEN and try to Edit a generation the Edit is
> converted to View to prevent this from happening.
>
> --
> Lionel B. Dyck <
> Mainframe Systems Programmer - TRA
>
>
> --
> 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
>

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

Re: GETMAIN LOC=32

[Tom Marchant]

On Thu, 10 May 2018 08:47:33 -0500, Paul Edwards wrote:

>This is a matter of defining "best programming
>practices" and noting that you can't rely on the
>BALR crap byte

Best for you perhaps. Using only a limited subset of the instruction set. 
And you don't seem to understand the value of the linkage information 
saved in R1 by BAL and BALR in AMODE(24).

This is a pointless discussion.

-- 
Tom Marchant

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

Re: Anybody running this?

[Greg Boyd]

I know of several customers running this newest level.  The other new function 
is support for STATs.  That's an option you can enable to generate SMF records 
with counters on use of engines, algorithms and services.  Could be a 
significant step forward in monitoring your crypto workload.
Greg
Greg Boyd
www.mainframecrypto.com


On Wed, 9 May 2018 18:48:38 -0500, Edward Gould  wrote:

>ICSF Delivers With the New FMID HCR77C1 Release 
>
>Usability improvements, such as an ISPF-based browser for CKDS key material, 
>and integrated support for a PCI HSM configured CCA coprocessor, are among the 
>enhancements to Cryptographic Support for z/OS V2R1 - z/OS V2R3, which was 
>released in September 2017.
>
>
>
>--
>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: Knowledge Centre - (was Re: Rant)

[van der Grijn, Bart (B)]

Hi Sue, thanks for the follow up. I sent you a direct email so I could include 
screen prints of what I'm getting. 

Thanks,
Bart

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Susan Shumway
Sent: Thursday, May 10, 2018 8:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Knowledge Centre - (was Re: Rant)

Hi Bart,

I followed your example on Firefox and wasn't able to recreate a reset 
nav. First, I opened the nav and clicked the pushpin icon at the top 
right corner to pin it open. I then clicked through the nav to the "MVS 
system commands reference" topic and then clicked the "MODIFY command" 
link near the bottom to bring me to that topic. The nav on the left 
refreshed and did look like it reset - it didn't scroll properly to show 
the "MODIFY command" topic in the branching. However, after I scrolled a 
bit to find it, I saw that it was indeed highlighted as the active topic 
and expanded.

The IBM KC product development team has been working to improve the nav, 
so I'll pass your comment along to them as an example of the current 
user concerns. Thanks!

-Sue Shumway

On 05/09/18 8:00 AM, van der Grijn, Bart , B wrote:
> So while we're on a rant/wishlist for kc4z, can I ask that the random 
> behaviour of the left panel gets addressed?
> 
> Example:
> Let's say I want to look in to MVS commands. I navigate the TOC panel on the 
> left to select z/OS 2.3, then z/OS MVS, then z/OS MVS System Commands, and 
> then MVS System Command Reference (yes, I know I can just search instead, but 
> this is just an example). On the right contents panel I then click a link to 
> take me to the MODIFY command. At that time my left panel resets and I lost 
> the navigation I did to get to the section of the manual I want to be at. In 
> my mind the left panel should either stay where it is or follow where the 
> link takes me.
> 
> Bart
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Carmen Vitullo
> Sent: Tuesday, May 08, 2018 11:39 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Knowledge Centre - (was Re: Rant)
> 
> This email originated from outside of the organization.
> 
> 
> Yep, that's exactly what I'm looking for, z/OS Plus IMS, DB2, I know I have 
> CICS, and CICS/FA loaded, but I'd like to have Omegamon, CDC 
> (Infosphere).to name a few.
> 
> 
> 
> Carmen Vitullo
> 
> - Original Message -
> 
> From: "Susan Shumway" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Tuesday, May 8, 2018 10:31:17 AM
> Subject: Re: Knowledge Centre - (was Re: Rant)
> 
> Hi Mike,
> 
> Good idea, but that index file only serves as a local ToC with links to
> the PDFs that you've downloaded from
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fservers%2Fresourcelink%2Fsvc00100.nsf%2Fpages%2FzOSV2R3Library=02%7C01%7Cbvandergrijn%40DOW.COM%7C4d6fc308aa384c86d59208d5b4f9db5b%7Cc3e32f53cb7f4809968d1cc4ccc785fe%7C0%7C0%7C636613907583381095=uGN6RH%2Bf7tcy4QrPGkg502%2B3HgUwRVW40wARNJcckIs%3D=0
> , which pretty much contains only z/OS elements and features. It's very
> useful for what it does for z/OS, but it doesn't help for separate
> products like DB2, IMS, etc.
> 
> -Sue Shumway
> 
> 
> On 05/08/18 11:20 AM, Mike Schwab wrote:
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww-304.ibm.com%2Fservers%2Fresourcelink%2Fsvc00100.nsf%2Fpages%2FzOSV2R3IndexFile=02%7C01%7Cbvandergrijn%40DOW.COM%7C4d6fc308aa384c86d59208d5b4f9db5b%7Cc3e32f53cb7f4809968d1cc4ccc785fe%7C0%7C0%7C636613907583381095=VdUXC7%2FEZheo7VUFvo8VBhAtD5qufLeDwvGqaK1%2F9sM%3D=0
>>
>> On Tue, May 8, 2018 at 9:57 AM, Susan Shumway  wrote:
>>> Hi Elardus,
>>>
>>> Wow, you're even more expensive than my babysitter! Never mind. ;-)
>>>
>>> I completely agree that it would be nice if all products that run on z/OS
>>> could provide content in the same downloadable format and that it's all easy
>>> to find. In the meantime, I like your idea of a ""big-mother-of-all" URL"
>>> and will run it by our strategist. (Of course, we have
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fservers%2Fresourcelink%2Fsvc00100.nsf%2Fpages%2FzosInternetLibrary=02%7C01%7Cbvandergrijn%40DOW.COM%7C4d6fc308aa384c86d59208d5b4f9db5b%7Cc3e32f53cb7f4809968d1cc4ccc785fe%7C0%7C0%7C636613907583381095=YQaU%2F0L7wGPbQHOkI0wYpCHBK3cM5PoaCCNqXuNYolo%3D=0
>>> for z/OS, but that doesn't include the other products.) Consider opening a
>>> requirement for it - that will help with participation from the other
>>> products.
>>>
>>> -Sue Shumway
>>>
>>> On 05/07/18 4:22 AM, Elardus Engelbrecht wrote:

 Susan Shumway wrote:

> You're hired, Elardus! ;-)


 Thanks for your nice compliment, I am humbled by your comments. Ok, but I
 am way too expensive - starting at $1 million per second, can you afford
 that? ;-D

 

Re: GETMAIN LOC=32

[Paul Edwards]

On Thu, 10 May 2018 11:01:12 -0500, Paul Edwards  wrote:

>> If it's bimodal than it's not running under
>> OS/VS2 3.8 (MVS).
>
>Confusion in terms again.
>
>By "bimodal" I mean "capable of being run
>as *either* AM24 or AM31".

ie IEFBR14 is bimodal. Even trimodal in fact.
Start from IEFBR14 and work your way up
to the 3 MiB load module called "GCC".
What is preventing GCC from being trimodal
and being able to compile small C programs
under MVS 3.8j, much larger programs
under MVS/XA, and double the size on a
future z/OS, all with the exact same 32-bit
(uses only 32-bit registers found in S/370
so that it can still run on MVS 3.8j) load
module?

BFN. Paul.

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

Re: GETMAIN LOC=32

[Paul Edwards]

On Thu, 10 May 2018 15:29:15 +, Seymour J Metz  wrote:

> If it's bimodal than it's not running under
> OS/VS2 3.8 (MVS).

Confusion in terms again.

By "bimodal" I mean "capable of being run
as *either* AM24 or AM31".

So yes, a bimodal 32-bit module, like the ones
I create, run just fine under MVS 3.8j running
on standard S/370 hardware. Of course they
are limited to 16 MiB of memory when run in
such an environment. But take the bimodal
(actually trimodal) load module to MVS/XA
and suddenly you get 2 GiB of memory
available. What I am asking for is for z/OS to
up that limit for trimodal 32-bit modules to 4 GiB.

> If it's bimodal and it is running into memory
> constraints, trimodal is only a bandaid; it needs
> a rewrite as AMODE64.

Needs a rewrite as a 64-bit module using 64-bit
registers with 64-bit addressing. Yes, it depends
on the specific application. If an extra whopping
2 GiB saves the day, you don't need the overhead
of 64-bit registers.

> The question isn't whether AMOD24 behavior
> can be dispensed with; it's tracking down all of
> the existing code that has to be changed.

If you find that your AMODE24 application is
starting to break the 16 MiB limit, then my
suggestion is that you track down those
references and make your application not
just bimodal, but trimodal, in preparation
for one day having accessing to 4 GiB of
memory instead of just 2 GiB.

> How many people are changing memory constrained
> AMOD24 code to AMODE31 these days, rather than
> rewriting it as AMODE64? How many errors will get
> introduced in the process?

I have no idea how many people are simply
making their code bimodal instead of
creating 64-bit applications. As far as I know
it is unusual to switch to 64-bit applications.
Regardless, I am actually interested more in
compilers changing to start producing trimodal
32-bit load modules, or unimodal 64-bit load
modules, as a user option.

BFN. Paul.

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

Re: GETMAIN LOC=32

[Seymour J Metz]

If it's bimodal than it's not running under OS/VS2 3.8 (MVS). If it's bimodal 
and it is running into memory constraints, trimodal is only a bandaid; it needs 
a rewrite as AMODE64.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Paul Edwards 
Sent: Thursday, May 10, 2018 9:03 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: GETMAIN LOC=32

On Thu, 10 May 2018 12:45:56 +, Seymour J Metz  wrote:

> Actually, the 32 bit registers go back *before*
> S/370. The issue is compatibility of AMODE24 code.

Which was solved initially by making code bimodal
(24/31), but it would be good if people made that
code trimodal (24/31/64)

BFN. Paul.

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

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

Re: GETMAIN LOC=32

[Seymour J Metz]

The question isn't whether AMOD24 behavior can be dispensed with; it's tracking 
down all of the existing code that has to be changed.

How many people are changing memory constrained AMOD24 code to AMODE31 these 
days, rather than rewriting it as AMODE64? How many errors will get introduced 
in the process?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Paul Edwards 
Sent: Thursday, May 10, 2018 9:44 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: GETMAIN LOC=32

On Thu, 10 May 2018 13:18:07 +, Seymour J Metz  wrote:

>How do run, in AMODE64, an AMODE24 program that
> relies on bits 0-7 after a BAL or BALR?

The same way you do when you are faced with
converting your code to bimodal AMODE31 -
you don't write code like that, and it is not
something that has an application-defined
purpose that can't be dispensed with.

> Admittedly IEFBR14 will work fine in AMOD64
> if the high 32 bits of R14 and R15 are zero.
> However, if you have to deal with legacy
> 24-bit code, then you have to deal with the
> incompatibility between AMODE24 and AMODE64.

The same is true of AMODE31. All I am asking
for is that when someone goes to the effort of
making their legacy AM24 application bimodal,
they make it trimodal at the same time.

BFN. Paul.

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

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

Re: arm police

[Jim Ruddy]

While you can cancel IRLM or DB2, this should only be done as a last resort
if DB2 is not responding to -STOP DB2 or -STOP DB2 MODE(FORCE). In ancient
times when there were real tape drives, DB2 would hang waiting for a tape
mount to archive logs when the logs had all filled or if a QMF user hit
attention twice.

Jim Ruddy

On Thu, May 10, 2018 at 7:11 AM, Lizette Koehler 
wrote:

> What version of z/OS?
>
> What version of DB2?
>
> Did you google   IBM  DB2  ARM  POLICY
>
> I found the following hit that may be helpful
>
> https://www.ibm.com/support/knowledgecenter/en/SSEPEK_11.
> 0.0/inst/src/tpc/db2z_createautorestartpolicy.html
>
> Also, you might want to post on the DB2 List as this link is from DB2 V11
>
> To join, if you have not done so,  go toidug.org
>
>
> I think you can only cancel the IRLM which would cause DB2 to fail.  I am
> not sure you can cancel DB2.
>
> Hope this helps
>
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> Behalf Of
> > Jason Cai
> > Sent: Thursday, May 10, 2018 12:51 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: arm police
> >
> > hi all
> >
> >  In our shop, DB2 is registered as an element of the automatic restart
> manage
> > The detailed information is shown below.ELEMENT(elementname)
> >RESTART_METHOD(SYSTERM,STC,'cmdprfx STA DB2,LIGHT(YES)')If we cancel
> db2
> > ,db2 will be restarted by arm . We don't hope db2 will be restarted by
> arm
> > after issuing cancel db2.How to do it?
> > Thanks a lot!Jason Cai
> >
> >
>
> --
> 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: arm police

[Lizette Koehler]

What version of z/OS?

What version of DB2?

Did you google   IBM  DB2  ARM  POLICY

I found the following hit that may be helpful

https://www.ibm.com/support/knowledgecenter/en/SSEPEK_11.0.0/inst/src/tpc/db2z_createautorestartpolicy.html

Also, you might want to post on the DB2 List as this link is from DB2 V11

To join, if you have not done so,  go toidug.org


I think you can only cancel the IRLM which would cause DB2 to fail.  I am not 
sure you can cancel DB2.

Hope this helps


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Jason Cai
> Sent: Thursday, May 10, 2018 12:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: arm police
> 
> hi all
> 
>  In our shop, DB2 is registered as an element of the automatic restart manage
> The detailed information is shown below.ELEMENT(elementname)
>RESTART_METHOD(SYSTERM,STC,'cmdprfx STA DB2,LIGHT(YES)')If we cancel db2
> ,db2 will be restarted by arm . We don't hope db2 will be restarted by arm
> after issuing cancel db2.How to do it?
> Thanks a lot!Jason Cai
> 
> 

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

Re: GETMAIN LOC=32

[Paul Edwards]

On Thu, 10 May 2018 08:24:18 -0500, Joe Monk  wrote:

>"Allowing 32-bit registers to address 32-bit virtual
>addresses is not a limitation/constraint. It is the
>ultimate you can get from a 32-bit register."
>
>It is if it breaks all existing code in the process.

Not ALL existing code is broken in the process.
Especially not code that has already been
converted to run as AM31.

> You can't take away
>what you call the "crap byte" in BALR and expect
> existing code to continue to run.

This is a matter of defining "best programming
practices" and noting that you can't rely on the
BALR crap byte and still have your program
work as AM31. Or AM64 either for that matter.

BFN. Paul.

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

Re: GETMAIN LOC=32

[Paul Edwards]

On Thu, 10 May 2018 13:18:07 +, Seymour J Metz  wrote:

>How do run, in AMODE64, an AMODE24 program that
> relies on bits 0-7 after a BAL or BALR?

The same way you do when you are faced with
converting your code to bimodal AMODE31 -
you don't write code like that, and it is not
something that has an application-defined
purpose that can't be dispensed with.

> Admittedly IEFBR14 will work fine in AMOD64
> if the high 32 bits of R14 and R15 are zero.
> However, if you have to deal with legacy
> 24-bit code, then you have to deal with the
> incompatibility between AMODE24 and AMODE64.

The same is true of AMODE31. All I am asking
for is that when someone goes to the effort of
making their legacy AM24 application bimodal,
they make it trimodal at the same time.

BFN. Paul.

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

Re: GETMAIN LOC=32

[Joe Monk]

"Allowing 32-bit registers to address 32-bit virtual
addresses is not a limitation/constraint. It is the
ultimate you can get from a 32-bit register."

It is if it breaks all existing code in the process. You can't take away
what you call the "crap byte" in BALR and expect existing code to continue
to run.

Joe

On Thu, May 10, 2018 at 8:18 AM, Paul Edwards  wrote:

> On Thu, 10 May 2018 08:09:32 -0500, Joe Monk  wrote:
>
> >For instance, if you look at his PDOS, the command processor is named
> >command.com. He wants the mainframe to behave like a big PC-DOS box, and
> so
> >he is trying to impose the same limitations/constraints, etc.
>
> Allowing 32-bit registers to address 32-bit virtual
> addresses is not a limitation/constraint. It is the
> ultimate you can get from a 32-bit register.
>
> BFN. Paul.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: GETMAIN LOC=32

[Seymour J Metz]

Admittedly IEFBR14 will work fine in AMOD64 if the high 32 bits of R14 and R15 
are zero. However, if you have to deal with legacy 24-bit code, then you have 
to deal with the incompatibility between AMODE24 and AMODE64.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Paul Edwards 
Sent: Wednesday, May 9, 2018 7:10 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: GETMAIN LOC=32

On Wed, 9 May 2018 20:04:57 +, Seymour J Metz  wrote:

>>What do you suggest calling a module that has been built on MVS 3.8j,
>>using 32-bit registers for both data and addresses, and works fine as
>>AM24, and then has been taken to z/OS and the "PDS" utility has been
>>used to mark it as AM64, and the program runs fine, regardless of what
>>AMODE it has been set to?
>
>"implausible"; various instructions work differently in AM24 and AM31, much 
>less AM64.

It's not implausible, it's what I do. I produce 32-bit
load modules that work on all 3 AMODEs. They
passively accept whatever AMODE they were
called with. They don't even require different code
paths internally.

BFN. Paul.

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

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

Re: GETMAIN LOC=32

[Paul Edwards]

On Thu, 10 May 2018 08:09:32 -0500, Joe Monk  wrote:

>For instance, if you look at his PDOS, the command processor is named
>command.com. He wants the mainframe to behave like a big PC-DOS box, and so
>he is trying to impose the same limitations/constraints, etc.

Allowing 32-bit registers to address 32-bit virtual
addresses is not a limitation/constraint. It is the
ultimate you can get from a 32-bit register.

BFN. Paul.

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

Re: GETMAIN LOC=32

[Seymour J Metz]

How do run, in AMODE64, an AMODE24 program that relies on bits 0-7 after a BAL 
or BALR?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Paul Edwards 
Sent: Wednesday, May 9, 2018 7:46 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: GETMAIN LOC=32

On Wed, 9 May 2018 18:40:40 -0500, Paul Gilmartin  wrote:

>>>"implausible"; various instructions work differently in AM24 and AM31, much 
>>>less AM64.
>>
>>It's not implausible, it's what I do. I produce 32-bit
>>load modules that work on all 3 AMODEs. They
>>passively accept whatever AMODE they were
>>called with. They don't even require different code
>>paths internally.
>>
>What about exploiting dual address space mode, AR mode, ESA, Hiperspaces,
>any other historic side roads that mainframe development has followed?
>
>I agree with Shmuel here, perhaps to his dismay.

No, of course I can't use such features and have
it still run all the way back to MVS 3.8j. But for
basic applications, like diff3 or sed, that just do
normal I/O, it can run in any AMODE. Basically
if you stick to the capabilities that MVS 3.8j had,
then you can write a program that will run in
any AMODE, including AM64.

BFN. Paul.

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

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

Re: GETMAIN LOC=32

[Seymour J Metz]

There are no address registers or data registers, only general registers, which 
prior to z were 32 bits. XA and ESA mode only used 31 bits for addressing, with 
the high bit designating addressing mode (except when it didn't). The behavior 
of some instructions is different in 24 bit mode.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Tony Thigpen 
Sent: Wednesday, May 9, 2018 10:31 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: GETMAIN LOC=32

Paul said:
 > You're quibbling over semantics. A program that
 > uses 32-bit data registers and 32-bit address
 > registers and 32-bit code pointers and 32-bit
 > data pointers is a 32-bit load module.

There is just so much wrong with that statement. Address registers are
only 31bit, not 32bit. The first bit is ignored on real IBM hardware.
Same for data registers, code pointers and data pointers. And there is
not such thing as a "32-bit load module" on *REAL* IBM hardware. (If you
want to talk 64-bit, that is another animal.)

No matter how many time you say it, it does not make it true. 32bit does
not exist on any IBM mainframe.

You keep saying it is semantics. It's as much semantics as saying Red is
Blue.

Tony Thigpen

Paul Edwards wrote on 05/09/2018 08:26 PM:
> On Wed, 9 May 2018 19:17:37 -0500, Joe Monk  wrote:
>
>> There is no such thing as a 32-bit load module on any of the platforms you
>> have mentioned.
>
> You're quibbling over semantics. A program that
> uses 32-bit data registers and 32-bit address
> registers and 32-bit code pointers and 32-bit
> data pointers is a 32-bit load module.
>
>> IBM 370 machines running MVS 3.8J (OS/VS2 3.8) are incapable of running
>> 32-bit code due to their use of the high bit for passing parameter lists,
>> which is the entire reason for the existence of the 2GB-4GB bar.
>
> That is not correct. You can run in AMODE 64
> so long as you step down to AMODE 24/31
> (wherever you were loaded) prior to executing
> whatever code requires the parameter list
> convention. You also need to obtain the memory
> for the parameters from 31-bit storage. AM64
> means that 32-bit modules no longer need to
> be constrained by the 2GiB bar, which is the
> entire reason for this thread.
>
> BFN. Paul.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>

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

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

Re: GETMAIN LOC=32

[Joe Monk]

What Paul can't separate in his mind is that a machine can have larger
registers than it has memory addresses (i.e. 32-bit registers but 24-bit
AMODE).

Thats where most of this is coming from ... his attempts to make the
mainframe be a PC.

For instance, if you look at his PDOS, the command processor is named
command.com. He wants the mainframe to behave like a big PC-DOS box, and so
he is trying to impose the same limitations/constraints, etc.

Joe

On Thu, May 10, 2018 at 7:45 AM, Seymour J Metz  wrote:

> Actually, the 32 bit registers go back *before* S/370. The issue is
> compatibility of AMODE24 code.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Paul Edwards 
> Sent: Thursday, May 10, 2018 6:50 AM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: GETMAIN LOC=32
>
> On Wed, 9 May 2018 20:45:46 -0500, Joe Monk  wrote:
>
> >Once again, you dont comprehend.
> >
> >IBM 370 can run XA (31-bit) (a la 3084). They CANNOT run AMODE 64.
>
> And non-XA IBM 370 CANNOT run AMODE 31.
> So what? What's your point. Yes, I know some
> hardware supports AM24 only, some supports
> AM31 and AM24, and some supports ALL of
> AM64, AM31 and AM24.
>
> Ideally, when you are producing a load module
> that uses the 32-bit registers found all the way
> back to non-XA 370, it should be AMODE-neutral
> and run in ALL THREE AMODEs.
>
> >Everything you are doing with your "32-bit" shenanigans will not work on
> >real IBM 370 hardware because it cannot run AMODE 64.
>
> It doesn't need to. That's why the gods invented z/Arch
> because IT CAN run AMODE 64.
>
> BFN. Paul.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: GETMAIN LOC=32

[Paul Edwards]

On Thu, 10 May 2018 12:45:56 +, Seymour J Metz  wrote:

> Actually, the 32 bit registers go back *before*
> S/370. The issue is compatibility of AMODE24 code.

Which was solved initially by making code bimodal
(24/31), but it would be good if people made that
code trimodal (24/31/64)

BFN. Paul.

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

Re: Knowledge Centre - (was Re: Rant)

[Susan Shumway]

Hi Bart,

I followed your example on Firefox and wasn't able to recreate a reset 
nav. First, I opened the nav and clicked the pushpin icon at the top 
right corner to pin it open. I then clicked through the nav to the "MVS 
system commands reference" topic and then clicked the "MODIFY command" 
link near the bottom to bring me to that topic. The nav on the left 
refreshed and did look like it reset - it didn't scroll properly to show 
the "MODIFY command" topic in the branching. However, after I scrolled a 
bit to find it, I saw that it was indeed highlighted as the active topic 
and expanded.


The IBM KC product development team has been working to improve the nav, 
so I'll pass your comment along to them as an example of the current 
user concerns. Thanks!


-Sue Shumway

On 05/09/18 8:00 AM, van der Grijn, Bart , B wrote:

So while we're on a rant/wishlist for kc4z, can I ask that the random behaviour 
of the left panel gets addressed?

Example:
Let's say I want to look in to MVS commands. I navigate the TOC panel on the 
left to select z/OS 2.3, then z/OS MVS, then z/OS MVS System Commands, and then 
MVS System Command Reference (yes, I know I can just search instead, but this 
is just an example). On the right contents panel I then click a link to take me 
to the MODIFY command. At that time my left panel resets and I lost the 
navigation I did to get to the section of the manual I want to be at. In my 
mind the left panel should either stay where it is or follow where the link 
takes me.

Bart

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo
Sent: Tuesday, May 08, 2018 11:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Knowledge Centre - (was Re: Rant)

This email originated from outside of the organization.


Yep, that's exactly what I'm looking for, z/OS Plus IMS, DB2, I know I have 
CICS, and CICS/FA loaded, but I'd like to have Omegamon, CDC 
(Infosphere).to name a few.



Carmen Vitullo

- Original Message -

From: "Susan Shumway" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Tuesday, May 8, 2018 10:31:17 AM
Subject: Re: Knowledge Centre - (was Re: Rant)

Hi Mike,

Good idea, but that index file only serves as a local ToC with links to
the PDFs that you've downloaded from
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fservers%2Fresourcelink%2Fsvc00100.nsf%2Fpages%2FzOSV2R3Library=02%7C01%7Cbvandergrijn%40DOW.COM%7C4d6fc308aa384c86d59208d5b4f9db5b%7Cc3e32f53cb7f4809968d1cc4ccc785fe%7C0%7C0%7C636613907583381095=uGN6RH%2Bf7tcy4QrPGkg502%2B3HgUwRVW40wARNJcckIs%3D=0
, which pretty much contains only z/OS elements and features. It's very
useful for what it does for z/OS, but it doesn't help for separate
products like DB2, IMS, etc.

-Sue Shumway


On 05/08/18 11:20 AM, Mike Schwab wrote:

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww-304.ibm.com%2Fservers%2Fresourcelink%2Fsvc00100.nsf%2Fpages%2FzOSV2R3IndexFile=02%7C01%7Cbvandergrijn%40DOW.COM%7C4d6fc308aa384c86d59208d5b4f9db5b%7Cc3e32f53cb7f4809968d1cc4ccc785fe%7C0%7C0%7C636613907583381095=VdUXC7%2FEZheo7VUFvo8VBhAtD5qufLeDwvGqaK1%2F9sM%3D=0

On Tue, May 8, 2018 at 9:57 AM, Susan Shumway  wrote:

Hi Elardus,

Wow, you're even more expensive than my babysitter! Never mind. ;-)

I completely agree that it would be nice if all products that run on z/OS
could provide content in the same downloadable format and that it's all easy
to find. In the meantime, I like your idea of a ""big-mother-of-all" URL"
and will run it by our strategist. (Of course, we have
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fservers%2Fresourcelink%2Fsvc00100.nsf%2Fpages%2FzosInternetLibrary=02%7C01%7Cbvandergrijn%40DOW.COM%7C4d6fc308aa384c86d59208d5b4f9db5b%7Cc3e32f53cb7f4809968d1cc4ccc785fe%7C0%7C0%7C636613907583381095=YQaU%2F0L7wGPbQHOkI0wYpCHBK3cM5PoaCCNqXuNYolo%3D=0
for z/OS, but that doesn't include the other products.) Consider opening a
requirement for it - that will help with participation from the other
products.

-Sue Shumway

On 05/07/18 4:22 AM, Elardus Engelbrecht wrote:


Susan Shumway wrote:


You're hired, Elardus! ;-)



Thanks for your nice compliment, I am humbled by your comments. Ok, but I
am way too expensive - starting at $1 million per second, can you afford
that? ;-D

Ok, seriously.


My own broken record statement is that we're constantly trying to improve
how the Knowledge Center handles the extensive z/OS library of content. We
always appreciate input, though.



What about Carmen Vitullo comments? He said:


That sounds great Susan, and I have the KC server running on an LPAR
here, (2.2) and using Softcopy Librarian V5 to load the contents, so where
are all the 'other' books I'd like to load, DB2, MQ, IMS...to name a few?
those KC books do not appear in any selection, .Boo or .PDF format for
me to download. what am I missing?



They are 

Re: GETMAIN LOC=32

[Seymour J Metz]

Actually, the 32 bit registers go back *before* S/370. The issue is 
compatibility of AMODE24 code.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Paul Edwards 
Sent: Thursday, May 10, 2018 6:50 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: GETMAIN LOC=32

On Wed, 9 May 2018 20:45:46 -0500, Joe Monk  wrote:

>Once again, you dont comprehend.
>
>IBM 370 can run XA (31-bit) (a la 3084). They CANNOT run AMODE 64.

And non-XA IBM 370 CANNOT run AMODE 31.
So what? What's your point. Yes, I know some
hardware supports AM24 only, some supports
AM31 and AM24, and some supports ALL of
AM64, AM31 and AM24.

Ideally, when you are producing a load module
that uses the 32-bit registers found all the way
back to non-XA 370, it should be AMODE-neutral
and run in ALL THREE AMODEs.

>Everything you are doing with your "32-bit" shenanigans will not work on
>real IBM 370 hardware because it cannot run AMODE 64.

It doesn't need to. That's why the gods invented z/Arch
because IT CAN run AMODE 64.

BFN. Paul.

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

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

Re: Anybody running this?

[Doug Henry]

Yes

On Wed, 9 May 2018 18:48:38 -0500, Edward Gould  wrote:

>ICSF Delivers With the New FMID HCR77C1 Release 
>Usability improvements, such as an ISPF-based browser for CKDS key material, 
>and integrated support for a PCI HSM configured CCA coprocessor, are among the 
>enhancements to Cryptographic Support for z/OS V2R1 - z/OS V2R3, which was 
>released in September 2017.

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

Re: GETMAIN LOC=32

[Paul Edwards]

On Thu, 10 May 2018 09:57:22 +0200, Bernd Oppolzer  
wrote:

>just for the record:
>
>to support 32 bit virtual addresses, it is not really needed
>that the underlying hardware supports 32 bit real addresses.
>It would be possible to support 32 bit virtual on a 31 bit real machine,
>if the DAT tables accept 32 bit virtual addresses as arguments
>and yield 31 bit real addresses. So your argument, that the address lines
>on the real IBM hardware only supports 31 bits is a weak one.

Thanks for adding that clarity.

Yes, at any point in time IBM could have added a
PSW.31 bit to their allegedly 31-bit hardware which
would have seen the entire upper 12 bit bits of the
address used as an index into the segment table,
and voila, 32-bit virtual addressing.

>That said, Paul's statements are anyway strange sometimes, because
>he claims that his operation system (which he calles PDOS, IIRC)
>will not make use of address translation ...

PDOS/370 uses a S/370 DAT allowing for the use
of 64 MiB of real memory for 16 MiB address
spaces.

PDOS/380 uses a split DAT (S/370 below 16 MiB
and XA above 16 MiB).

PDOS/390 uses a pure XA DAT.

I intend to change PDOS/380 so that it no longer
really uses DAT, but I have not yet done so. Future
PDOS developments are totally irrelevant to the
discussion on allowing 32-bit virtual memory for
32-bit programs (radical!) though.

BFN. Paul.

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

Re: Anybody running this?

[Jousma, David]

Yes.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edward Gould
Sent: Wednesday, May 09, 2018 7:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Anybody running this?

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

ICSF Delivers With the New FMID HCR77C1 Release 

Usability improvements, such as an ISPF-based browser for CKDS key material, 
and integrated support for a PCI HSM configured CCA coprocessor, are among the 
enhancements to Cryptographic Support for z/OS V2R1 - z/OS V2R3, which was 
released in September 2017.



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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**



This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: GETMAIN LOC=32

[Paul Edwards]

On Wed, 9 May 2018 20:45:46 -0500, Joe Monk  wrote:

>Once again, you dont comprehend.
>
>IBM 370 can run XA (31-bit) (a la 3084). They CANNOT run AMODE 64.

And non-XA IBM 370 CANNOT run AMODE 31.
So what? What's your point. Yes, I know some
hardware supports AM24 only, some supports
AM31 and AM24, and some supports ALL of
AM64, AM31 and AM24.

Ideally, when you are producing a load module
that uses the 32-bit registers found all the way
back to non-XA 370, it should be AMODE-neutral
and run in ALL THREE AMODEs.

>Everything you are doing with your "32-bit" shenanigans will not work on
>real IBM 370 hardware because it cannot run AMODE 64.

It doesn't need to. That's why the gods invented z/Arch
because IT CAN run AMODE 64.

BFN. Paul.

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

Re: GETMAIN LOC=32

[Bernd Oppolzer]

Am 10.05.2018 um 04:31 schrieb Tony Thigpen:

Paul said:
> You're quibbling over semantics. A program that
> uses 32-bit data registers and 32-bit address
> registers and 32-bit code pointers and 32-bit
> data pointers is a 32-bit load module.

There is just so much wrong with that statement. Address registers are 
only 31bit, not 32bit. The first bit is ignored on real IBM hardware. 
Same for data registers, code pointers and data pointers. And there is 
not such thing as a "32-bit load module" on *REAL* IBM hardware. (If 
you want to talk 64-bit, that is another animal.)


No matter how many time you say it, it does not make it true. 32bit 
does not exist on any IBM mainframe.




just for the record:

to support 32 bit virtual addresses, it is not really needed
that the underlying hardware supports 32 bit real addresses.
It would be possible to support 32 bit virtual on a 31 bit real machine,
if the DAT tables accept 32 bit virtual addresses as arguments
and yield 31 bit real addresses. So your argument, that the address lines
on the real IBM hardware only supports 31 bits is a weak one.

In theory, it would even be possible to support a 64 bit operating
system on a 31 bit hardware. That's one core feature of virtual memory:
supporting large address spaces on small machines.

That said, Paul's statements are anyway strange sometimes, because
he claims that his operation system (which he calles PDOS, IIRC)
will not make use of address translation ...

Kind regards

Bernd


You keep saying it is semantics. It's as much semantics as saying Red 
is Blue.


Tony Thigpen


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

arm police

[Jason Cai]

hi all

 In our shop, DB2 is registered as an element of the automatic restart manage
 The detailed information is shown below.ELEMENT(elementname)
   RESTART_METHOD(SYSTERM,STC,'cmdprfx STA DB2,LIGHT(YES)')If we cancel db2 
,db2 will be restarted by arm . We don't hope db2 will be restarted by arm 
after issuing cancel db2.How to do it?
Thanks a lot!Jason Cai




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

Re: GETMAIN LOC=32

[Elardus Engelbrecht]

Paul Edwards wrote:

>The 32-bit load modules I produce run on MVS 3.8j, MVS/XA, OS/390 and z/OS. 

Ok. On what hardware are you working? Say for example, 3090, z890, z990, zEC12, 
z13, etc. ?

I am sure you know IBM will NOT accept any request(s) for unsupported systems 
and hardware like MVS 3.8j, MVS/XA, OS/390 , etc.

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