Re: z/OS MF environment - effort estimation.

[Rugen, Len]

We kept a 120 MIP system on "hospice" for several years starting with 4 FTE and 
dwindling down to 1.5 FTE.  Even a doomed system required 2 hardware upgrades, 
several OS versions, encryption for TN3270, distributed printing, internet data 
transfer and general hand holding.


Len Rugen

University of Missouri
Division of Information Technology
Systems & Operations - Metrics & Automation Team

From: IBM Mainframe Discussion List  on behalf of 
ANIL KUMAR 
Sent: Tuesday, February 13, 2018 9:45:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS MF environment - effort estimation.

Hi Elardus - Thanks very much for your support.

I was specifically looking at effort / man hours estimate for supporting
standard z/OS MF infrastructure which does not include H/W support.
Basically wanted to
how many FTEs does the industry standard recommend for no of LPARs. etc.,
for DB2 sysproc activities , cics sysprog activities etc.

Any one has any further inputs please advise.
have nice day.

On Mon, Dec 18, 2017 at 4:23 PM, Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:

> Anil Kumar wrote:
>
> >Good day. I needed expert advise on how do we calculate the numbers
> (effort estimation )
>
> What numbers / effort? Costs? Man-hours? CPU estimate? Licenses?
> Infrastructure? etc.?
>
>
> > ... provided that we have the infrastructure that we support.
>
> Are these things in place: Power (Main and UPS), Room space, Physical
> security?
>
>
> >... Assuming that I have the below:
>
> >1) # of LPARs.
> >2) # of ISV products.
> >3) Automation on z/os on all LPARs.
> >4) Storage
> >5)MIPS
> >6) # of CICS regions
> >7) # of DB2 subsystems
> >8) MQ regions
> >9) # of WAS
> >10) # of IMS subsystems
>
> More things to add...
>
>  11) Network infrastructure including remote connection.
>  12) Security product(s)
>  13) PPRC and what else too for your storage...
>  14) You forgot about DRP. This will certainly double (sort off) your
> 'effort'.
>  15) Workstations to access above things ...
>  16) XCF, Sysplex Timers
>  17) Add more toys and tools including having a 'Sandbox' LPAR for
> SMP/E and testing out products.
>
>
> >I understand that different shops have different strategy in calculating
> the same. However I needed valuable inputs on how to start estimating.
>
> Ask first, how much staff do you have and how much are you willing to pay
> or pulling in contractors.
>
> How many clients / users do you have for each of those listed systems?
>
>
> >Is there any industry standard or best practice available.
>
> Yes, there is only ONE standard, it is named 'No Standard'. You will have
> to figure out yourself what is the best for you. Perhaps there are IBM-MAIN
> members who can help you or supply you a product which can do those
> estimates...
>
>
> >I really appreciate all your inputs in this regard. Please let me know
> for any further information required from my end.
>
> Ask your vendors. They know their products and can give you a ball-park
> figure of everything.
>
> Good luck.
>
> 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
>

--
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: z/OS MF environment - effort estimation.

[ANIL KUMAR]

Hi Elardus - Thanks very much for your support.

I was specifically looking at effort / man hours estimate for supporting
standard z/OS MF infrastructure which does not include H/W support.
Basically wanted to
how many FTEs does the industry standard recommend for no of LPARs. etc.,
for DB2 sysproc activities , cics sysprog activities etc.

Any one has any further inputs please advise.
have nice day.

On Mon, Dec 18, 2017 at 4:23 PM, Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:

> Anil Kumar wrote:
>
> >Good day. I needed expert advise on how do we calculate the numbers
> (effort estimation )
>
> What numbers / effort? Costs? Man-hours? CPU estimate? Licenses?
> Infrastructure? etc.?
>
>
> > ... provided that we have the infrastructure that we support.
>
> Are these things in place: Power (Main and UPS), Room space, Physical
> security?
>
>
> >... Assuming that I have the below:
>
> >1) # of LPARs.
> >2) # of ISV products.
> >3) Automation on z/os on all LPARs.
> >4) Storage
> >5)MIPS
> >6) # of CICS regions
> >7) # of DB2 subsystems
> >8) MQ regions
> >9) # of WAS
> >10) # of IMS subsystems
>
> More things to add...
>
>  11) Network infrastructure including remote connection.
>  12) Security product(s)
>  13) PPRC and what else too for your storage...
>  14) You forgot about DRP. This will certainly double (sort off) your
> 'effort'.
>  15) Workstations to access above things ...
>  16) XCF, Sysplex Timers
>  17) Add more toys and tools including having a 'Sandbox' LPAR for
> SMP/E and testing out products.
>
>
> >I understand that different shops have different strategy in calculating
> the same. However I needed valuable inputs on how to start estimating.
>
> Ask first, how much staff do you have and how much are you willing to pay
> or pulling in contractors.
>
> How many clients / users do you have for each of those listed systems?
>
>
> >Is there any industry standard or best practice available.
>
> Yes, there is only ONE standard, it is named 'No Standard'. You will have
> to figure out yourself what is the best for you. Perhaps there are IBM-MAIN
> members who can help you or supply you a product which can do those
> estimates...
>
>
> >I really appreciate all your inputs in this regard. Please let me know
> for any further information required from my end.
>
> Ask your vendors. They know their products and can give you a ball-park
> figure of everything.
>
> Good luck.
>
> 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
>

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

TSSO question

[Tony Thigpen]

(Posting for a co-worker)

We have installed TSSO (PRE Z1 .8 version) Our test:

DIPLINF  TABENTRY MSG=IEE254I,ACTION=OSCMD,MATCHLIM=17,ECHO=YES,   X
   TEXT='D A,L'
IEE254I is the message response from a D IPLINFO.

When we issue D IPLINFO and the message fires...
TSSO rapidly issue 17 "D A,L" commands...

Anyone ever seen this before?

--
Tony Thigpen

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

Re: Question for COBOL users

[Paul Gilmartin]

On Tue, 13 Feb 2018 20:00:47 -0600, Jim Ruddy wrote:

>Wouldn't a 64K byte parameter list run into problems with programs such as 
>HLASM, compilers, and other programs which allow an optional DD name list to 
>be passed as a second parameter when invoked from a program? As I recall, they 
>detect whether the DD name list is passed by testing the high bit - the "sign" 
>bit - of the first parameter.
> 
No, they test the high bit of the *address* of the first parameter.

(VL is not supported in 64-bit mode.)

--  gil

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

Re: Question for COBOL users

[Jim Ruddy]

Nevermind - wrong bit - been too long and too long of a day. Sorry.

Jim

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

Re: Question for COBOL users

[Jim Ruddy]

Wouldn't a 64K byte parameter list run into problems with programs such as 
HLASM, compilers, and other programs which allow an optional DD name list to be 
passed as a second parameter when invoked from a program? As I recall, they 
detect whether the DD name list is passed by testing the high bit - the "sign" 
bit - of the first parameter.

Jim

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

Re: Question for COBOL users

[Paul Gilmartin]

On Tue, 13 Feb 2018 17:46:28 -0800, Charles Mills wrote:

>And no real reason a program could not support 64ki-1 bytes. Not looking at 
>the specs for "standard linkage" but there is no real good reason to treat the 
>length as signed.
> 
Tradition?  ("real good reason"?)

A while ago, I experimented.

BPXBATCH reasonably processes x''.

Rexx address LINKMVS considers >=x'8000' a syntax error.

HLASM reasonably processes x'7FFF'.  At x'8000' it issues several hundred 
thousand
lines of error messages then program checks.  Ugh!  Sign extension?

BPXWDYN reasonably processes X'37FF'.  At x'4000' it fails, expecting a 
null-terminated
string rather than a CALL-style parm.  This has been documented as a 
restriction ever
since my RCF.  The reporting is not ideal.

>Beyond that would require a significant change in the linkage.
>
Yes.

-- gil

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

Re: Is this possible to expand only one row in table display?

[W Mainframe]

Hello,
I am not sure if it is possible using TBDISPL service. I am able to do that 
using dynamic area in panels. Of course, more work, more controls...
Dan


Sent from Yahoo Mail for iPhone


On Monday, February 12, 2018, 3:39 PM, ITschak Mugzach  
wrote:

Tried that. it does show as two lines including cases where the second line
is empty.  I wonder how can I suppress empty lines displayed using TBDISPL
service

ITschak

On Mon, Feb 12, 2018 at 5:52 PM, Carmen Vitullo  wrote:

> ITschak, logically I think that works, but I wonder if initially the
> row's, even if the data is not presented without the "+" would not the row
> still display as 2 rows
> if I am understaing correctly using the )MODEL CLEAR(xx) panel option
> may be what you're looking for ?
>
>
> I've done similar but using one row - I've never tried expanding beyond
> that
>
>
>
> +---
>
>
> )MODEL CLEAR(SELECT) ROWS(ALL)
>
>
> @Z+ #DDNAME #DSN #DISP1 #DISP2+
>
>
> )INIT
>
>
> .ZVARS='(SELECT)'
>
>
> )END
>
> Carmen Vitullo
>
> - Original Message -
>
> From: "ITschak Mugzach" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Monday, February 12, 2018 9:43:30 AM
> Subject: Re: Is this possible to expand only one row in table display?
>
> Carmen,
>
> I may not explained my issue the problem is "HOW". I can think of one
> option that i'll try later today that goes like this:
>
> - remember crp
> - add name to table row with a value coppied from a real NAMES variable
> - The panel )model section should always be defined with two rows, The
> first that I want to display and the second is has the addded name to row.
> This way only one row will have this variable.
> - at end, update the variable defined at NAMES and delete the name from
> varlist.
>
> I hope there is a better, more elegant way that will allow doing that.
>
> ITschak
>
> On Mon, Feb 12, 2018 at 5:21 PM, Carmen Vitullo 
> wrote:
>
> > If the ISPF application is your own you can do what you want. you have to
> > code the dialog to take an action when the user puts a plus sign in the
> > line operator '_' much like the ISPF ISMF dialog.
> > I'm not sure if the table row display (PANEL) can be altered once
> > displayed without a new table panel being displayed based on the + line
> > operator, I've not designed any ISPF applications for a while, maybe you
> > can.
> > I would think you'd need to perform a TBDISPL with a panel LIKE the panel
> > you are presenting, with the additional fields, keeping the current row
> > position, then once the - minus sign or END command is entered, you'd go
> > back to the original display.
> > this would be a good exercise and I'm sure some folks that still develop
> > ISPF applications would know for sure.
> >
> > Carmen Vitullo
> >
> > - Original Message -
> >
> > From: "ITschak Mugzach" 
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Sent: Monday, February 12, 2018 8:57:02 AM
> > Subject: Is this possible to expand only one row in table display?
> >
> > Assume I am listing datasets ip OPT3.4. It is an ISPF table (DSLx).
> > also assume I have access to code. I would like to enter a plus sign in
> > front of a tbe entry and get the rest of the rows listed bebind the row,
> > without affecting the other rows display (of course they mill move down.
> > When I click '-' is will close the display. Is this possible with Table
> > display? I know how to do that with dynamic areas but it is a more
> > complex.
> >
> > ​Thanks for your ideas.​
> >
> > --
> > ITschak Mugzach
> > *|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
> > for Legacy **| *
> >
> > --
> > 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
> >
>
>
>
> --
> ITschak Mugzach
> *|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
> for Legacy **| *
>
> --
> 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
>



-- 
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
for Legacy **|  *

--
For IBM-MAIN subscribe / signoff / archive access 

Re: Question for COBOL users

[Charles Mills]

And no real reason a program could not support 64ki-1 bytes. Not looking at the 
specs for "standard linkage" but there is no real good reason to treat the 
length as signed.

Beyond that would require a significant change in the linkage.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, February 13, 2018 4:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question for COBOL users

On Wed, 14 Feb 2018 00:00:10 +, Farley, Peter x23353 wrote:
>
>PMFJI here but the limit with PARMDD is 32K I believe.  JES/JCL limit is 100, 
>not 255.  The COBOL questions is, does the compiler correctly process PARMDD 
>input > 255 characters, and if so which version(s)?  Only V5+?  I could 
>understand V4 not supporting it, but not V5+.
> 
This is hardly such a novelty:  for a half-century the Assembler 
CALL/LINK/ATTACH macro could invoke the compiler with up to 32Ki-1 bytes in 
PARM.

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

Re: Question for COBOL users

[Dale R. Smith]

On Tue, 6 Feb 2018 10:49:38 -0800, Tom Ross  wrote:

>IBM COBOL development needs your help!
>
>We are reviewing a request to change our support for OPTFILE and SYSOPTF
>to allow usage of DD SYSOPTF without the compiler option OPTFILE.
>
>For background, this is where you can avoid the 255 character limit for
>PARM= in JCL when specifying COBOL compiler options.  Currently, if you
>specify compiler option OPTFILE, the compiler tries to OPEN the file
>allocated to DD SYSOPTF, and read compiler options from that file.
>
>OK, we got an RFE (Request For Enhancement) to have the compiler always
>try to use SYSOPTF, with or without the OPTFILE compiler option.  The use
>of SYSOPTF would then only be controlled by the existence of SYSOPTF.
>
>Our concern is, would this affect current users of SYSOPTF?  Are there users
>of SYSOPTF with COBOL who sometimes compile with NOOPTFILE and leave the
>DD statement for SYSOPFT in their JCL/Changeman compile jobs?
>If so, then automatically accessing SYSOPTF without using OPTFILE could
>cause problems.
>
>This leads to another question...do any of your shops  use OPTFILE and
>SYSOPTF for COBOL compiles?
>
>Cheers,
>TomR  >> COBOL is the Language of the Future! <<

We use OPTFILE to supply Compiler defaults.  We specify it as the first parm to 
the Compiler and then specify any options we want to override or options that 
are not in the defaults after OPTFILE.  Since we always use OPTFILE, we always 
have a SYSOPTF DD statement supplied also so we would be OK with this change.  
However, I see the following statements in the COBOL Programming Guide:

The precedence of options in the SYSOPTF data set is determined by where you
specify the OPTFILE option. For example, if you specify OPTFILE in the 
invocation
PARM string, an option specified later in the PARM string supersedes any option
specified in the SYSOPTF data set that conflicts with it.

(Conceptually, OPTFILE in an options specification is replaced with the options 
that
are in the SYSOPTF data set; then the usual rules about precedence of compiler
options and conflicting compiler options apply.)


This seems to imply that options specified as Compiler Parms before OPTFILE 
could be overridden by options in SYSOPTF.  If that's the case and COBOL was 
changed to always use SYSOPTF, would the options in SYSOPTF be processed before 
any Parm options or after all Parm options?

I see in your latest posting that you will probably need to add a new Compiler 
option.  The manual also says that OPTFILE cannot be set as an installation 
default option.  Maybe if it was allowed to be an installation default, that 
would satisfy the RFE?  Maybe with an additional parameter for an installation 
default to specify when SYSOPTF is to processed, first or last?

-- 
Dale R. Smith   

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

Old-timer question

[Tony Thigpen]

Today, during a 'back when' discussion, this came up.

Back in '81, during my last year in college (Management Information 
Science they called it then), the advanced students 'played' with a 
training database written in Fortran. We had the source, compiled it, 
and added features.


One of the guys asked "What happened to it?"

So, does anybody else remembers such. And, what happened to it?

--
Tony Thigpen

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

Re: IEA303W ABEND 878 REASON 00000004

[Jesse Lynch]

Thank you very much for all your help

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

Re: InfoPrint GUI

[Roger Bolan]

Hi Anne,
Redirect might sound like administration, but I know Infoprint Central can
display the printer definitions from the inventory but it does not edit
them.  You need Administrator authority to change the printer definitions
either with the ISPF panels or with the pidu command in OMVS.  The redirect
function tells Printway to send jobs targeted to one printer to another
printer instead.  Restore will end the temporary redirection.   The book
doesn't give details on exactly what happens under the covers to make that
happen. I think this is intended as a way to print jobs that were destined
for a printer which is temporarily out of service.

I know if you're using JCL to submit jobs you can use an OUTPUT JCL
statement with DEST=IP:nnn.nnn.nnn.nnn to direct print to a specific IP
address even if that address is not in one of your existing printer
definitions.  If you want to combine a new IP address with one of your
existing printer definitions for other attributes you can specify both.
See
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.aopu000/sing3.htm
for an example of using FSSDATA to select a printer definition by name, and
also override the IP address with DEST=IP:
That only affects that job.  To permanently change the IP address for a
printer definiton you have to use the pidu command or the ISPF panels.
Regards,
--Roger

On Tue, Feb 13, 2018 at 6:31 AM, Adams, Anne (DTI) 
wrote:

> Thanks Roger,
> Still a little confused though. Upon looking at (SA38-0693-00) Infoprint
> Server Operation and Administraion, Using Infoprint Central, Work with
> Printers, IP PrintWay printers. (I can) start, stop, and redirect ... which
> does appear to be an admin function. Again, the change does not appear
> permanent. However, it may be as you said ... those functions are not
> available
>
> ~Anne
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Roger Bolan
> Sent: Monday, February 12, 2018 3:21 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: InfoPrint GUI
>
> Anne,
> I see it.  Infoprint Central (what we call the GUI) is for working with
> jobs and printers for operations basically, but not for Adminstrator
> tasks.  The book says, on that page:
>
> Infoprint Central lets users display information about, but not work with,
> these
> objects:
> * Printer definitions
> * Printer pool definitions
> * Infoprint Server daemons
>
> To make a permanent new IP address for one of the printer definitions, use
> the ISPF panels instead of Infoprint Central.
> You should be a member of the AOPADMIN group to change printer definitions
> in the inventory.  See page 55 in that manual for more details.
>
> If you want to change the mapping of a host-name to an IP address, that
> would be done in your DNS instead of Infoprint.
>
> Changing the IP address for a printer definition in the ISPF panels does
> not require an IPL.  As soon as you PF3 back out of the panel where you
> changed the printer definition, you will see a message like "Element was
> updated".  As soon as you see that your printer definition modifications
> are in effect to be used.
> --Roger
>
>
>
> On Mon, Feb 12, 2018 at 12:14 PM, Adams, Anne (DTI) <
> anne.ad...@state.de.us>
> wrote:
>
> > Hey Roger -
> >
> > People here want to be able to change the printer definitions (ie. The
> > ip
> > address) using the GUI. From the manual (p. 339 from the infoprint
> > manual, Chapter 8, Customizing Infoprint Central.  aop1c010) it
> > appears that definitions are not supported and testing appears to
> > confirm that. We change the IP address but lose it when we IPL.
> > Unfortunately, I can't include an image of the page or an attachment.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Roger Bolan
> > Sent: Monday, February 12, 2018 12:11 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: InfoPrint GUI
> >
> > Hi Anne,
> > I'm not sure what you're referring to.   Can you put in a link to the
> > statement in the documentation your question is about?
> > Is this something you see in the IBM Knowledge Center or a Redbook or
> what?
> > --Roger
> >
> > On Mon, Feb 12, 2018 at 7:53 AM, Adams, Anne (DTI)
> >  > >
> > wrote:
> >
> > > Hello all,
> > >
> > > Anyone know anything about the InfoPrint GUI? In particular, I've
> > > been told (it's in the manual) that changes made using the GUI are
> > > not permanent. They will revert back after an IPL. Management wants
> > > us to use the GUI, but that is not acceptable. Am I missing something?
> > >
> > > Anne R Adams, CISSP
> > > DTI, Systems Engineering
> > > Sr. Mainframe Services Analyst
> > > 302.298.3196
> > >
> > > This communication is for use by the intended recipient and contains
> > > information that may be Privileged, confidential or copyrighted
> > > under applicable law. If you are not 

Re: Question for COBOL users

[Paul Gilmartin]

On Wed, 14 Feb 2018 00:00:10 +, Farley, Peter x23353 wrote:
>
>PMFJI here but the limit with PARMDD is 32K I believe.  JES/JCL limit is 100, 
>not 255.  The COBOL questions is, does the compiler correctly process PARMDD 
>input > 255 characters, and if so which version(s)?  Only V5+?  I could 
>understand V4 not supporting it, but not V5+.
> 
This is hardly such a novelty:  for a half-century the Assembler 
CALL/LINK/ATTACH macro
could invoke the compiler with up to 32Ki-1 bytes in PARM.

>-Original Message-
>From: Behalf Of Tom Ross
>Sent: Tuesday, February 13, 2018 6:42 PM
>
>We added OPTFILE as a response to customer request, I believe it was
>well before PARMDD, but not positive.
>
>Someone else asked what the COMPILER limit for reading the PARM=
>options string is, but there is none.  There is a JCL/JES limit of
>255 bytes.  There is no limit for SYSOPTF (using OPTFILE).
>
I'm sticking with the consensus of 100 bytes.  But do you mean that CALL,
etc. can invoke COBOL with the much longer PARM?  That this has been
true for many releases?

>It seems pretty clear that we cannot change the default behavior to
>read SYSOPTF whenever it is present, regardless of OPTFILE, so we
>will probably add another (sigh) compiler option
>
In your first ply you said that the motivation was that the requestor
was too close to the (255?) 100-character limit to accommodate one
more option, so a different option provides no relief.  (Well, minimal,
insofar as it's shorter than the 7 characters in "OPTFILE".)

Has PARMDD been suggested to the requestor?  AFAICT, the only
distinction between EXEC PARM= and PARMDD is that the latter
can not end with a blank.

PARMDD should provide the solution; the RFE should be rejected.

>On Mon, 12 Feb 2018 12:08:16 -0600, Mike Schwab wrote:
[ Header synthesized -- gil]
>>There is nothing to prevent a user or product to go ahead and use
>>PARMDD, and it could point to the program's (compiler's) specific
>>overrides.  The program (compiler) can only read the PARM for the
>>length it specifies (100/255) until modified to allow a parm length of
>>32K.  Maybe a couple releases down the road you can give a warning
>>message that the program (compiler) specific parm will be removed.

Tom has said COBOL has no such limit, so no problem.  The JCL limit
is unlikely to change (although that should have been done long ago.)

-- gil

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

Re: Question for COBOL users

[Farley, Peter x23353]

Tom,

PMFJI here but the limit with PARMDD is 32K I believe.  JES/JCL limit is 100, 
not 255.  The COBOL questions is, does the compiler correctly process PARMDD 
input > 255 characters, and if so which version(s)?  Only V5+?  I could 
understand V4 not supporting it, but not V5+.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Ross
Sent: Tuesday, February 13, 2018 6:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question for COBOL users

We added OPTFILE as a response to customer request, I believe it was
well before PARMDD, but not positive.

Someone else asked what the COMPILER limit for reading the PARM=
options string is, but there is none.  There is a JCL/JES limit of
255 bytes.  There is no limit for SYSOPTF (using OPTFILE).

It seems pretty clear that we cannot change the default behavior to
read SYSOPTF whenever it is present, regardless of OPTFILE, so we
will probably add another (sigh) compiler option

>There is nothing to prevent a user or product to go ahead and use
>PARMDD, and it could point to the program's (compiler's) specific
>overrides.  The program (compiler) can only read the PARM for the
>length it specifies (100/255) until modified to allow a parm length of
>32K.  Maybe a couple releases down the road you can give a warning
>message that the program (compiler) specific parm will be removed.

--


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

Re: Question for COBOL users

[Tom Ross]

We added OPTFILE as a response to customer request, I believe it was
well before PARMDD, but not positive.

Someone else asked what the COMPILER limit for reading the PARM=
options string is, but there is none.  There is a JCL/JES limit of
255 bytes.  There is no limit for SYSOPTF (using OPTFILE).

It seems pretty clear that we cannot change the default behavior to
read SYSOPTF whenever it is present, regardless of OPTFILE, so we
will probably add another (sigh) compiler option

>There is nothing to prevent a user or product to go ahead and use
>PARMDD, and it could point to the program's (compiler's) specific
>overrides.  The program (compiler) can only read the PARM for the
>length it specifies (100/255) until modified to allow a parm length of
>32K.  Maybe a couple releases down the road you can give a warning
>message that the program (compiler) specific parm will be removed.

Cheers,
TomR  >> COBOL is the Language of the Future! <<

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

Re: Apply error WAS product

[Jesse 1 Robinson]

I thought that if PTF A was superseded by B, and B superseded by C, then SMPE 
would only install only C and mark A and B as SUP'D. That logic, if it obtains, 
always made sense to me. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, February 13, 2018 3:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Apply error WAS product

On Tue, 13 Feb 2018 16:52:06 -0600, Matthew Stitt wrote:

>With WAS, I've encountered certain PTFs (fixpacks) which supersede other ones 
>and create errors like this when both (or more) fixpacks are being applied at 
>once.  The solution I've found is to apply each fixpack separately.
>
That sounds PMR-worthy.  Are you doing what IBM recommended?

>On Tue, 13 Feb 2018 10:13:18 -0500, John Eells wrote:
>
>>Did you open a PMR?
>>
>>Please do, if not; and, please post the PMR number

-- gil


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

Re: Best Practices for z/OS Maintenance

[Tom Conley]

On 2/13/2018 5:23 PM, Jesse 1 Robinson wrote:

This schema looks good, but I don't understand how '/SERVICE/' alone can handle 
more than one z/OS release concurrently. We use '/OSRxx/' where xx represents 
the version/release such as 12, 13, 21, 23. That way any number of releases can 
be managed and *distinguished* concurrently. This has served us well since OMVS 
was introduced. Besides handling the transition from one ver/rel to another, we 
have at times had to keep more than one in production for extended periods.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com



I rise in support of my good friend, the distinguished gentleman from 
SoCal, and proffer another option.  I now use the mountpoint / 
for my version root, so /Z21RS1, /Z21RS2, etc.  /SERVICE is so last 
century.  PITA to maintain, PITA to keep current.  With the volume name 
as the mount point, mounting and maintaining the version filesystem is a 
snap.  Just edit the path name to change all the paths after your 
ZONECOPY, and you're done.  If you have a symbol for your alternate res, 
you can mount the offline filesystem at IPL time.


Regards,
Tom Conley

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

Re: Apply error WAS product

[Paul Gilmartin]

On Tue, 13 Feb 2018 16:52:06 -0600, Matthew Stitt wrote:

>With WAS, I've encountered certain PTFs (fixpacks) which supersede other ones 
>and create errors like this when both (or more) fixpacks are being applied at 
>once.  The solution I've found is to apply each fixpack separately.
>
That sounds PMR-worthy.  Are you doing what IBM recommended?

>On Tue, 13 Feb 2018 10:13:18 -0500, John Eells wrote:
>
>>Did you open a PMR?
>>
>>Please do, if not; and, please post the PMR number

-- gil

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

Re: Apply error WAS product

[Matthew Stitt]

With WAS, I've encountered certain PTFs (fixpacks) which supersede other ones 
and create errors like this when both (or more) fixpacks are being applied at 
once.  The solution I've found is to apply each fixpack separately.

HTH

Matthew

On Tue, 13 Feb 2018 10:13:18 -0500, John Eells  wrote:

>Did you open a PMR?
>
>Please do, if not; and, please post the PMR number.
>
>Peter wrote:
>> This time again it failed
>>
>> BPXF140E RETURN CODE 0090, REASON CODE 0549010C.  A LINK FAILED FOR
>> LINK NAME /usr/lpp/InstallationManagerRepository/HBBO850/IBM
>> /../bbodrmak.
>
>

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

Re: Best Practices for z/OS Maintenance

[Jesse 1 Robinson]

This schema looks good, but I don't understand how '/SERVICE/' alone can handle 
more than one z/OS release concurrently. We use '/OSRxx/' where xx represents 
the version/release such as 12, 13, 21, 23. That way any number of releases can 
be managed and *distinguished* concurrently. This has served us well since OMVS 
was introduced. Besides handling the transition from one ver/rel to another, we 
have at times had to keep more than one in production for extended periods. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Tuesday, February 13, 2018 6:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Best Practices for z/OS Maintenance

On Fri, 9 Feb 2018 04:46:33 +, Craig Pace wrote:

>I always kept a SERVICE copy of the filesystems that were IBM related and then 
>applied and that is what SMP/E pointed to.  Each shop usually has what works 
>best for them, but below are the two main ways that I have done it.
>
>1)  Less Work, but Less Control (from SMP/E that is if someone bypasses SMP/E).
>
>Have a single set of RESVOLs, DLIBVOLs and USS Filesystem libraries that SMP/E 
>points toward.  If you have a stand-along Tech LPAR or Sandbox, have the 
>ability to IPL from this only for validation, but I try to keep this just for 
>SMP/E only!
>
>2)  More Work/More SME/E Control
>
>Have a Tech set of SMP/E SYSRES, DLIB and USS Filesystems.  Applied all 
>initial maintenance (RECEIVE, APPLY, ACCEPT) to this as normal 
>processing
>
>Have a separate SMP/E SYSRES, DLIB and USS Filesystems per shared (or single) 
>environment.  Once maintenance is validated within the Tech environment, you 
>can run SMP/E compares between the Tech and next environment to dynamically 
>create the required SMP/E input statement to APPLY and/or ACCEPT as needed.
>

Or, my preference:
3)  More DASD, more flexibility

Clone SYSRES, DLIB and USS Filesystems as needed. Choose 4 or 5 unique 
characters for each that will become part of the SYSRES VOLSER(s), DLIB 
VOLSER(s), Target zone name, and Distribution zone name. The zFS filesystem 
name includes the SYSRES VOLSER as part of the name and it is mounted using 
 DDDEFs in target zone TZONE for Unix paths are mounted at 
/SERVICE/TZONE and /SERVICE is automount managed, so that the correct 
Filesystem is always used.

When a SYSRES, DLIB and USS Filesystem set is no longer needed, get rid of it. 

Setting this all up is a bit of work, but once done, it works very well.

--
Tom Marchant

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

Re: TCBFSA field in the TCB DSECT

[Jim Mulder]

  TCBFSA is 0 when SVAREA=NO is specified on ATTACH.
TCBFSA points to above-the-line storage for key 9 TCBs 

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY

IBM Mainframe Discussion List  wrote on 
02/13/2018 04:07:10 AM:

> From: Steff Gladstone 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 02/13/2018 04:44 PM
> Subject: TCBFSA field in the TCB DSECT
> Sent by: IBM Mainframe Discussion List 
> 
> Hi,
> 
> I am in the process of converting several routines to AMODE=31 
RMODE=ANY.
> One of them references the address of the first problem program save 
area
> found in the TCB.
> 
> The field is defined as follows:
> 
> TCBFSA   DS0A -ADDRESS OF THE FIRST PROBLEM PROGRAM SAVE AREA
> 
> DSFL1 -   FIRST BYTE OF TCBFSA
> @G381P9A
> 
> TCBFSAB  DSAL3 -   ADDRESS OF THE FIRST PROBLEM PROGRAM SAVE AREA
> 
> My question:  what is the status of the first byte?  It does not seem to
> contain flag bits as is often the case.  On the other hand, defining the
> field TCBFSAB seems to imply that the address is a 24-bit address.  So 
in
> AMODE=31 can the first problem program save area (which is provided by 
the
> system to the top-level program) be above the line?  Should I relate to 
all
> four bytes as the address of the FSA?  Or could the first byte contain
> garbage?



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

Re: Question on Autologon for JES2 REMOTES HASP207

[Cieri, Anthony]

There are some configuration mis-matches that could cause the Autologon 
to fail. As already mentioned, an incorrect LUNAME could cause this, also an 
incorrect password (if you are using them).  I recall some vendor type RJE 
device that never successfully signed on  with the JES2 Autologon feature. In 
order to successfully restart the RJE, we had to Inactivate and reactive the PU 
associated with the remote device.

If cleaning up "old" RJE definitions is the primary goal, you might 
consider checking SMF records. I believe that SNA RJE devices cut a SMF type 52 
record and BSC (if you still have them) RJE devices cut a SMF type 47 record 
for JES2 LOGON/SIGNONs. Yes, I am still running some reports...

Hth
Tony

 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rugen, Len
Sent: Tuesday, February 13, 2018 2:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question on Autologon for JES2 REMOTES HASP207

There is a chance that no one remembers :-)  

Is the LU active?  Is the luname correct?  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Tuesday, February 13, 2018 1:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question on Autologon for JES2 REMOTES HASP207

I guess no one remembers JES2 Remotes or can answer this very simple question

Lizette

;-D


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Lizette Koehler
> Sent: Monday, February 12, 2018 4:47 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Question on Autologon for JES2 REMOTES HASP207
> 
> List - I am only seeing the HASP207 AUTOLOGON Failed for some remotes.
> 
> Can I guess that the remote is either
> 
>1) Powered down when the autologon occurred?
>2) Or the remote no longer exists?
> 
> Which makes more sense?  Trying to do remote clean up
> 
> 
> Lizette
> 
> A theory can never be proven, but it can be falsified.  Karl Raimund 
> Popper

--
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: Question on Autologon for JES2 REMOTES HASP207

[Rugen, Len]

There is a chance that no one remembers :-)  

Is the LU active?  Is the luname correct?  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Tuesday, February 13, 2018 1:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question on Autologon for JES2 REMOTES HASP207

I guess no one remembers JES2 Remotes or can answer this very simple question

Lizette

;-D


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Lizette Koehler
> Sent: Monday, February 12, 2018 4:47 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Question on Autologon for JES2 REMOTES HASP207
> 
> List - I am only seeing the HASP207 AUTOLOGON Failed for some remotes.
> 
> Can I guess that the remote is either
> 
>1) Powered down when the autologon occurred?
>2) Or the remote no longer exists?
> 
> Which makes more sense?  Trying to do remote clean up
> 
> 
> Lizette
> 
> A theory can never be proven, but it can be falsified.  Karl Raimund 
> Popper

--
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: Question on Autologon for JES2 REMOTES HASP207

[Lizette Koehler]

I guess no one remembers JES2 Remotes or can answer this very simple question

Lizette

;-D


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Monday, February 12, 2018 4:47 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Question on Autologon for JES2 REMOTES HASP207
> 
> List - I am only seeing the HASP207 AUTOLOGON Failed for some remotes.
> 
> Can I guess that the remote is either
> 
>1) Powered down when the autologon occurred?
>2) Or the remote no longer exists?
> 
> Which makes more sense?  Trying to do remote clean up
> 
> 
> Lizette
> 
> A theory can never be proven, but it can be falsified.  Karl Raimund Popper

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

Re: RMM question

[Tony Thigpen]

My main worry about using WHILECATALOG is that there was an old practice 
were some tapes were manually set in CA-1 to have extended retention 
periods because of something that happened 'special' the day they were 
created.


On the other hand, all the people that used to know the why those 
versions were kept are long gone, so I might as well scratch them. I 
just need to do a trial run and check to make sure that no year-end 
tapes show up.


Tony Thigpen

Jesse 1 Robinson wrote on 02/13/2018 12:44 PM:

RMM was designed around the assumption that tape datasets would be cataloged or 
else scratched. When we converted to it many years ago, we had to deal with a 
wholly different business practice: keep tape data sets, including 'GDG 
members', more or less forever. In the early days we had to install exit code 
to achieve the desired result. Today I believe that it can be done purely with 
parm values (I'm not an RMM guy). The important thing in a conversion is to 
make sure that tape handling is consistent across products, whatever that takes.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Conley
Sent: Tuesday, February 13, 2018 9:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: RMM question

On 2/13/2018 9:24 AM, Tony Thigpen wrote:

Thanks Tom.

Yes, I did mean VRS.

No, IBM did not do the conversion.

The output shows:
Exit status:
EDGUX100 = NONE

Are you suggesting that I not use EDGUX100, but instead use:
RMM ADDVRS DSNAME(’**’) WHILECATALOG

Will this affect all existing volumes? Is there a way to see the
effect without accidentally messing everything up?

Tony Thigpen



Tony,

I'm not sure how RMM will interpret 99000 without EDGUX100.  I've always 
implemented at least the default EDGUX100 and UXTABLE.  Is there a retention 
date listed in the volume record?

About that '**' VRS, that will essentially make WHILECATALOG the default 
retention for everything, but then you will also have the overhead of VRSEL 
processing for everything.  There are better ways to set that up.
I would recommend that with your current setup, you create a VRS for the GDG's 
that you want to be WHILECATALOG controlled.  You can run VRSEL with the VERIFY 
option to see the effects without actually doing anything.  Please contact me 
offline if you'd like to discuss other options.

Regards,
Tom Conley


--
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: RMM question

[Jesse 1 Robinson]

RMM was designed around the assumption that tape datasets would be cataloged or 
else scratched. When we converted to it many years ago, we had to deal with a 
wholly different business practice: keep tape data sets, including 'GDG 
members', more or less forever. In the early days we had to install exit code 
to achieve the desired result. Today I believe that it can be done purely with 
parm values (I'm not an RMM guy). The important thing in a conversion is to 
make sure that tape handling is consistent across products, whatever that 
takes. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Conley
Sent: Tuesday, February 13, 2018 9:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: RMM question

On 2/13/2018 9:24 AM, Tony Thigpen wrote:
> Thanks Tom.
> 
> Yes, I did mean VRS.
> 
> No, IBM did not do the conversion.
> 
> The output shows:
> Exit status:
>    EDGUX100 = NONE
> 
> Are you suggesting that I not use EDGUX100, but instead use:
> RMM ADDVRS DSNAME(’**’) WHILECATALOG
> 
> Will this affect all existing volumes? Is there a way to see the 
> effect without accidentally messing everything up?
> 
> Tony Thigpen
> 

Tony,

I'm not sure how RMM will interpret 99000 without EDGUX100.  I've always 
implemented at least the default EDGUX100 and UXTABLE.  Is there a retention 
date listed in the volume record?

About that '**' VRS, that will essentially make WHILECATALOG the default 
retention for everything, but then you will also have the overhead of VRSEL 
processing for everything.  There are better ways to set that up. 
I would recommend that with your current setup, you create a VRS for the GDG's 
that you want to be WHILECATALOG controlled.  You can run VRSEL with the VERIFY 
option to see the effects without actually doing anything.  Please contact me 
offline if you'd like to discuss other options.

Regards,
Tom Conley


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

Re: TCBFSA field in the TCB DSECT

[Tony Harminc]

On 13 February 2018 at 07:44, Steff Gladstone  wrote:
> Or you could check if R14 is pointing to a SVC 3 instruction.

That may or may not work. If you are running under TSO TEST it will
point to an SVC 97 instead.

> Actually the routine (not written by me) was using the FSA to retrieve the
> pointer to the value of the PARM= parameter (saved R1).
> Presumably that's a valid use as well.

A program has no obligation to save the registers in its caller's save
area. So R1 will be saved there only by the grace of the invoked
program. Certainly it's the norm, but not strictly "valid".

Tony H.

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

Re: RMM question

[Tom Conley]

On 2/13/2018 9:24 AM, Tony Thigpen wrote:

Thanks Tom.

Yes, I did mean VRS.

No, IBM did not do the conversion.

The output shows:
Exit status:
   EDGUX100 = NONE

Are you suggesting that I not use EDGUX100, but instead use:
RMM ADDVRS DSNAME(’**’) WHILECATALOG

Will this affect all existing volumes? Is there a way to see the effect 
without accidentally messing everything up?


Tony Thigpen



Tony,

I'm not sure how RMM will interpret 99000 without EDGUX100.  I've always 
implemented at least the default EDGUX100 and UXTABLE.  Is there a 
retention date listed in the volume record?


About that '**' VRS, that will essentially make WHILECATALOG the default 
retention for everything, but then you will also have the overhead of 
VRSEL processing for everything.  There are better ways to set that up. 
I would recommend that with your current setup, you create a VRS for the 
GDG's that you want to be WHILECATALOG controlled.  You can run VRSEL 
with the VERIFY option to see the effects without actually doing 
anything.  Please contact me offline if you'd like to discuss other options.


Regards,
Tom Conley

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

Re: TCBFSA field in the TCB DSECT

[Seymour J Metz]

The first save area must be below the line.


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


From: IBM Mainframe Discussion List [IBM-MAIN@listserv.ua.edu] on behalf of 
Steff Gladstone [steff.gladst...@gmail.com]
Sent: Tuesday, February 13, 2018 4:07 AM
To: IBM-MAIN@listserv.ua.edu
Subject: TCBFSA field in the TCB DSECT

Hi,

I am in the process of converting several routines to AMODE=31 RMODE=ANY.
One of them references the address of the first problem program save area
found in the TCB.

The field is defined as follows:

TCBFSA   DS0A -ADDRESS OF THE FIRST PROBLEM PROGRAM SAVE AREA

DSFL1 -   FIRST BYTE OF TCBFSA
@G381P9A

TCBFSAB  DSAL3 -   ADDRESS OF THE FIRST PROBLEM PROGRAM SAVE AREA

My question:  what is the status of the first byte?  It does not seem to
contain flag bits as is often the case.  On the other hand, defining the
field TCBFSAB seems to imply that the address is a 24-bit address.  So in
AMODE=31 can the first problem program save area (which is provided by the
system to the top-level program) be above the line?  Should I relate to all
four bytes as the address of the FSA?  Or could the first byte contain
garbage?

Thanks,
Steff

--
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: Apply error WAS product

[John Eells]

Did you open a PMR?

Please do, if not; and, please post the PMR number.

Peter wrote:

This time again it failed

BPXF140E RETURN CODE 0090, REASON CODE 0549010C.  A LINK FAILED FOR
LINK NAME /usr/lpp/InstallationManagerRepository/HBBO850/IBM
/../bbodrmak.



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

GSE - Large Systems Working Group - Virtual Event

[Leanne Wilson]

I am pleased to invite you to a GSE Large Systems Working Group event. The 
event will be a virtual event via WebEx on the 21st February 2018 from 15:00 – 
16:15 GMT.

The event will contain a 1 hour session presented by Martin Packer and Anna 
Shugol from IBM on “IBM zHyperlinks: new low latency I/O paradigm for IBM z14 
and DS8880.”

Session abstract:
IBM zHyperlink is a new short distance I/O link for IBM Z and IBM Storage, 
accelerating database transactions' throughput and improving performance.

This session will present best practices on how to leverage zHyperlink in a 
customer's shop.

If you wish to attend the event, please follow the registration link 
HERE

WebEx sign in details will be sent prior to the meeting, providing attendees 
have registered for the event.

For the agenda, please click 
HERE




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

Re: Question about ABEND Macro and IARV64

[Steve Smith]

Yes... I've had the pleasure of working on many dumps with above-the-bar
storage.  Pro-tip: you use ! instead of ? to jump to an 8-byte address in
IPCS Browse (or XDC, if that's your thing).

I've avoided SYSUDUMP for years... they seem to be set up to print only
what I don't need to see; besides being increasingly unwieldy.

sas

On Tue, Feb 13, 2018 at 9:15 AM, Tom Marchant <
000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

> On Sat, 10 Feb 2018 07:57:01 -0500, Peter Relson wrote:
>
> >>Will the Segment created by IARV64 be visable in a dump
> >>when the program issues  ABEND ,DUMP,STEP
> >
> >A true z/OS answer: it depends.
> >
> >For SYSABEND/SYSUDUMP: no.
> >For SYSMDUMP, I think, yes.
> >
> >There is no support for 64-bit storage in the "formatted dump" variants.
>
> I can confirm that 64-bit storage is present and viewable in a SYSMDUMP.
>
> --
> Tom Marchant
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
sas

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

Re: RMM question

[Tony Thigpen]

Thanks Tom.

Yes, I did mean VRS.

No, IBM did not do the conversion.

The output shows:
Exit status:
  EDGUX100 = NONE

Are you suggesting that I not use EDGUX100, but instead use:
RMM ADDVRS DSNAME(’**’) WHILECATALOG

Will this affect all existing volumes? Is there a way to see the effect 
without accidentally messing everything up?


Tony Thigpen

Tom Conley wrote on 02/13/2018 09:04 AM:

On 2/13/2018 8:19 AM, Tony Thigpen wrote:

We recently converted from CA-1 to RMM.

I am having an issue with some tape volumes containing GDGs not
scratching after x days.

I have determined it is due to EXPDT=99000, and I am now waiting for
the person who performed the conversion to let me know if the EDGUX100
exit is installed and activated.

I am now looking at the process to create the correct VDS records for
these GDGs.

Currently, using a LISTCAT GDG ALL, I can see that the number of
versions to be retained is 7. And only 7 DGDs show up in the LISTCAT.
RMM has more versions in it's catalog.

In creating the VDS in RMM, it appears that I will need to also tell
it the number of GDGs to retain.

Maybe I am looking at this wrong, but it looks like I will need to
maintain the number of generations to retain in both locations?



Tony,

If you mean VRS, set it to WHILECATALOG for that GDG, and the other
versions that RMM has will go to scratch.  99000 with EDGUX100 should do
the same.  Does TSO RMM LC ALL show EDGUX100 active?  If IBM did your
CA-1 to RMM conversion, this should have been done.

Regards,
Tom Conley

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

Job opening - Assembler / C developer

[Calin Cole]

Hi folks, 

As the title says Colesoft is looking to hire an additional developer. The full 
job posting can be found here: http://www.colesoft.com/careers/

Please contact us off list with questions. 

Thanks

Calin Cole

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

Re: Question about ABEND Macro and IARV64

[Tom Marchant]

On Sat, 10 Feb 2018 07:57:01 -0500, Peter Relson wrote:

>>Will the Segment created by IARV64 be visable in a dump 
>>when the program issues  ABEND ,DUMP,STEP 
>
>A true z/OS answer: it depends.
>
>For SYSABEND/SYSUDUMP: no.
>For SYSMDUMP, I think, yes.
>
>There is no support for 64-bit storage in the "formatted dump" variants.

I can confirm that 64-bit storage is present and viewable in a SYSMDUMP.

-- 
Tom Marchant

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

Re: Best Practices for z/OS Maintenance

[Tom Marchant]

On Fri, 9 Feb 2018 04:46:33 +, Craig Pace wrote:

>I always kept a SERVICE copy of the filesystems that were IBM related and then 
>applied and that is what SMP/E pointed to.  Each shop usually has what works 
>best for them, but below are the two main ways that I have done it.
>
>1)  Less Work, but Less Control (from SMP/E that is if someone bypasses SMP/E).
>
>Have a single set of RESVOLs, DLIBVOLs and USS Filesystem libraries that SMP/E 
>points toward.  If you have a stand-along Tech LPAR or Sandbox, have the 
>ability to IPL from this only for validation, but I try to keep this just for 
>SMP/E only!
>
>2)  More Work/More SME/E Control
>
>Have a Tech set of SMP/E SYSRES, DLIB and USS Filesystems.  Applied all 
>initial maintenance (RECEIVE, APPLY, ACCEPT) to this as normal processing
>
>Have a separate SMP/E SYSRES, DLIB and USS Filesystems per shared (or single) 
>environment.  Once maintenance is validated within the Tech environment, you 
>can run SMP/E compares between the Tech and next environment to dynamically 
>create the required SMP/E input statement to APPLY and/or ACCEPT as needed.
>

Or, my preference:
3)  More DASD, more flexibility

Clone SYSRES, DLIB and USS Filesystems as needed. Choose 4 or 5 unique 
characters for each that will become part of the SYSRES VOLSER(s), DLIB 
VOLSER(s), Target zone name, and Distribution zone name. The zFS filesystem 
name includes the SYSRES VOLSER as part of the name and it is mounted using 
 DDDEFs in target zone TZONE for Unix paths are mounted at 
/SERVICE/TZONE and /SERVICE is automount managed, so that the correct 
Filesystem is always used.

When a SYSRES, DLIB and USS Filesystem set is no longer needed, get rid of it. 

Setting this all up is a bit of work, but once done, it works very well.

-- 
Tom Marchant

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

Re: ISPFCL sample

[Tom Conley]

On 2/13/2018 8:57 AM, Jake Anderson wrote:

Hi

Does anyone have a sample copy of ISPFCL ?

Jake



Jake,

From my Dynamic ISPF session:

/* Rexx */
/* trace i */
msgsave = msg()
x = msg('OFF')
address tso "ALLOC FI(ISPPROF) DA('"userid()".ISPF.ISPPROF') OLD"
if rc <> 0 then
   do
  profdsn = userid().ISPF.ISPPROF
  x = msg('ON')
  address tso "ALLOC FI(ISPPROF) DA('"profdsn"') NEW CATALOG",
  "CYLINDERS SPACE(1 1) DIR(45) DSORG(PO) RECFM(F B)",
  "LRECL(80) BLKSIZE(0)"
  if rc = 0 then
 say "ISPF profile dataset'"profdsn"'created"
  else
 say "Unable to allocate ISPF profile dataset'"profdsn"'"
   end
x = msg(msgsave)
/* queue “TSOLIB ACT DA(‘tsolib dsn’)”  Put TSOLIB ACT here if needed */ 


queue "ISPF NOLOGO"
/* queue “TSOLIB DEACT”  Put TSOLIB DEACT here if needed */

Regards,
Tom Conley

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

Re: RMM question

[Tom Conley]

On 2/13/2018 8:19 AM, Tony Thigpen wrote:

We recently converted from CA-1 to RMM.

I am having an issue with some tape volumes containing GDGs not 
scratching after x days.


I have determined it is due to EXPDT=99000, and I am now waiting for the 
person who performed the conversion to let me know if the EDGUX100 exit 
is installed and activated.


I am now looking at the process to create the correct VDS records for 
these GDGs.


Currently, using a LISTCAT GDG ALL, I can see that the number of 
versions to be retained is 7. And only 7 DGDs show up in the LISTCAT. 
RMM has more versions in it's catalog.


In creating the VDS in RMM, it appears that I will need to also tell it 
the number of GDGs to retain.


Maybe I am looking at this wrong, but it looks like I will need to 
maintain the number of generations to retain in both locations?




Tony,

If you mean VRS, set it to WHILECATALOG for that GDG, and the other 
versions that RMM has will go to scratch.  99000 with EDGUX100 should do 
the same.  Does TSO RMM LC ALL show EDGUX100 active?  If IBM did your 
CA-1 to RMM conversion, this should have been done.


Regards,
Tom Conley

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

ISPFCL sample

[Jake Anderson]

Hi

Does anyone have a sample copy of ISPFCL ?

Jake

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

Re: InfoPrint GUI

[Adams, Anne (DTI)]

Thanks Roger,
Still a little confused though. Upon looking at (SA38-0693-00) Infoprint Server 
Operation and Administraion, Using Infoprint Central, Work with Printers, IP 
PrintWay printers. (I can) start, stop, and redirect ... which does appear to 
be an admin function. Again, the change does not appear permanent. However, it 
may be as you said ... those functions are not available

~Anne

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Roger Bolan
Sent: Monday, February 12, 2018 3:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: InfoPrint GUI

Anne,
I see it.  Infoprint Central (what we call the GUI) is for working with jobs 
and printers for operations basically, but not for Adminstrator tasks.  The 
book says, on that page:

Infoprint Central lets users display information about, but not work with, these
objects:
* Printer definitions
* Printer pool definitions
* Infoprint Server daemons

To make a permanent new IP address for one of the printer definitions, use the 
ISPF panels instead of Infoprint Central.
You should be a member of the AOPADMIN group to change printer definitions in 
the inventory.  See page 55 in that manual for more details.

If you want to change the mapping of a host-name to an IP address, that would 
be done in your DNS instead of Infoprint.

Changing the IP address for a printer definition in the ISPF panels does not 
require an IPL.  As soon as you PF3 back out of the panel where you changed the 
printer definition, you will see a message like "Element was updated".  As soon 
as you see that your printer definition modifications are in effect to be used.
--Roger



On Mon, Feb 12, 2018 at 12:14 PM, Adams, Anne (DTI) 
wrote:

> Hey Roger -
>
> People here want to be able to change the printer definitions (ie. The 
> ip
> address) using the GUI. From the manual (p. 339 from the infoprint 
> manual, Chapter 8, Customizing Infoprint Central.  aop1c010) it 
> appears that definitions are not supported and testing appears to 
> confirm that. We change the IP address but lose it when we IPL. 
> Unfortunately, I can't include an image of the page or an attachment.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Roger Bolan
> Sent: Monday, February 12, 2018 12:11 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: InfoPrint GUI
>
> Hi Anne,
> I'm not sure what you're referring to.   Can you put in a link to the
> statement in the documentation your question is about?
> Is this something you see in the IBM Knowledge Center or a Redbook or what?
> --Roger
>
> On Mon, Feb 12, 2018 at 7:53 AM, Adams, Anne (DTI) 
>  >
> wrote:
>
> > Hello all,
> >
> > Anyone know anything about the InfoPrint GUI? In particular, I've 
> > been told (it's in the manual) that changes made using the GUI are 
> > not permanent. They will revert back after an IPL. Management wants 
> > us to use the GUI, but that is not acceptable. Am I missing something?
> >
> > Anne R Adams, CISSP
> > DTI, Systems Engineering
> > Sr. Mainframe Services Analyst
> > 302.298.3196
> >
> > This communication is for use by the intended recipient and contains 
> > information that may be Privileged, confidential or copyrighted 
> > under applicable law. If you are not the intended recipient, you are 
> > hereby formally notified that any use, copying or distribution of 
> > this e-mail, in whole or in part, is strictly prohibited. Please 
> > notify the sender by return e-mail and delete this e-mail from your system.
> > Unless explicitly and conspicuously designated as "E-Contract 
> > Intended", this e-mail does not constitute a contract offer, a 
> > contract amendment, or an acceptance of a contract offer. This 
> > e-mail does not constitute a consent to the use of sender's contact 
> > information for direct marketing purposes or for transfers of data 
> > to
> third parties.
> >
> > 
> > -- 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

--
For IBM-MAIN subscribe / signoff / archive 

RMM question

[Tony Thigpen]

We recently converted from CA-1 to RMM.

I am having an issue with some tape volumes containing GDGs not 
scratching after x days.


I have determined it is due to EXPDT=99000, and I am now waiting for the 
person who performed the conversion to let me know if the EDGUX100 exit 
is installed and activated.


I am now looking at the process to create the correct VDS records for 
these GDGs.


Currently, using a LISTCAT GDG ALL, I can see that the number of 
versions to be retained is 7. And only 7 DGDs show up in the LISTCAT. 
RMM has more versions in it's catalog.


In creating the VDS in RMM, it appears that I will need to also tell it 
the number of GDGs to retain.


Maybe I am looking at this wrong, but it looks like I will need to 
maintain the number of generations to retain in both locations?


--
Tony Thigpen

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

Re: TCBFSA field in the TCB DSECT

[Roach, Dennis]

Using R13 can be an issue if the linkage stack is used instead of the save area.

Dennis Roach, CISSP
AIG

Identity & Access Management | Technology Services

2929 Allen Parkway, America Building, 3rd Floor | Houston, TX 77019
Phone:  713-591-1059 (cell)

dennis.ro...@aig.com | www.aig.com 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steff Gladstone
Sent: Tuesday, February 13, 2018 6:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TCBFSA field in the TCB DSECT

On 13 February 2018 at 13:02, Bernd Oppolzer 
wrote:

> Hi,
>
> IMO, the first save area should always be below the line.
> It is provided by the operating system so that the main program of the 
> called application (EXEC PGM=...) can store the registers on call there.
> And the first program may be AMODE 24 :-)
>
> On the other hand, I would never use TCBFSA to do anything with it.
> Because, for example, you would try to walk the save area chain from 
> there, you are stuck, because the forward pointers are not set 
> correctly by LE and others.
> What you should do instead: fetch register 13 and walk back, by using 
> the backward pointers, which are much more reliable in the general 
> case. When doing this, you could check for the value in TCBFSA to see, 
> if you arrived at the first save area. But you could also check for 
> NULL in the backward pointer.
>
> HTH, kind regards
>
> Bernd
>
>
>
> Am 13.02.2018 um 10:07 schrieb Steff Gladstone:
>
>> Hi,
>>
>> I am in the process of converting several routines to AMODE=31 RMODE=ANY.
>> One of them references the address of the first problem program save 
>> area found in the TCB.
>>
>> The field is defined as follows:
>>
>> TCBFSA   DS0A -ADDRESS OF THE FIRST PROBLEM PROGRAM SAVE AREA
>>
>>  DSFL1 -   FIRST BYTE OF TCBFSA
>> @G381P9A
>>
>> TCBFSAB  DSAL3 -   ADDRESS OF THE FIRST PROBLEM PROGRAM SAVE AREA
>>
>> My question:  what is the status of the first byte?  It does not seem 
>> to contain flag bits as is often the case.  On the other hand, 
>> defining the field TCBFSAB seems to imply that the address is a 
>> 24-bit address.  So in
>> AMODE=31 can the first problem program save area (which is provided 
>> by the system to the top-level program) be above the line?  Should I 
>> relate to all four bytes as the address of the FSA?  Or could the 
>> first byte contain garbage?
>>
>> Thanks,
>> Steff
>>
>> -
>> - 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: TCBFSA field in the TCB DSECT

[Steff Gladstone]

Or you could check if R14 is pointing to a SVC 3 instruction.

Actually the routine (not written by me) was using the FSA to retrieve the
pointer to the value of the PARM= parameter (saved R1).
Presumably that's a valid use as well.

It would make sense if the FSA is always below the line.  Although
theoretically the system could check the AMODE of the first program and
allocate the SA accordingly.

On 13 February 2018 at 13:02, Bernd Oppolzer 
wrote:

> Hi,
>
> IMO, the first save area should always be below the line.
> It is provided by the operating system so that the main program of the
> called application (EXEC PGM=...) can store the registers on call there.
> And the first program may be AMODE 24 :-)
>
> On the other hand, I would never use TCBFSA to do anything with it.
> Because, for example, you would try to walk the save area chain from there,
> you are stuck, because the forward pointers are not set correctly by LE
> and others.
> What you should do instead: fetch register 13 and walk back, by using the
> backward
> pointers, which are much more reliable in the general case. When doing
> this,
> you could check for the value in TCBFSA to see, if you arrived at the
> first save
> area. But you could also check for NULL in the backward pointer.
>
> HTH, kind regards
>
> Bernd
>
>
>
> Am 13.02.2018 um 10:07 schrieb Steff Gladstone:
>
>> Hi,
>>
>> I am in the process of converting several routines to AMODE=31 RMODE=ANY.
>> One of them references the address of the first problem program save area
>> found in the TCB.
>>
>> The field is defined as follows:
>>
>> TCBFSA   DS0A -ADDRESS OF THE FIRST PROBLEM PROGRAM SAVE AREA
>>
>>  DSFL1 -   FIRST BYTE OF TCBFSA
>> @G381P9A
>>
>> TCBFSAB  DSAL3 -   ADDRESS OF THE FIRST PROBLEM PROGRAM SAVE AREA
>>
>> My question:  what is the status of the first byte?  It does not seem to
>> contain flag bits as is often the case.  On the other hand, defining the
>> field TCBFSAB seems to imply that the address is a 24-bit address.  So in
>> AMODE=31 can the first problem program save area (which is provided by the
>> system to the top-level program) be above the line?  Should I relate to
>> all
>> four bytes as the address of the FSA?  Or could the first byte contain
>> garbage?
>>
>> Thanks,
>> Steff
>>
>> --
>> 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: Apply error WAS product

[Peter]

This time again it failed

BPXF140E RETURN CODE 0090, REASON CODE 0549010C.  A LINK FAILED FOR
LINK NAME /usr/lpp/InstallationManagerRepository/HBBO850/IBM
/../bbodrmak.

*Reason Code : 0549010C*
BPXFSLNK 03/10/11

JRLnkAcrossFilesets: The service tried to link across file
systems


Action: Reissue the request, specifying a new pathname that is within the
same file system as the existing pathname.
***


Error log:
  GIM69168E ** HFSCOPY PROCESSING TO THE SBBOIMR LIBRARY *FAILED FOR
SHELLSCR BBODRMAK IN SYSMOD UI50772*. THE RETURN CODE
 (12) EXCEEDED THE ALLOWABLE VALUE. DATE 18.043 - TIME 12:51:22
- SEQUENCE NUMBER 01.
GIM30227E ** APPLY PROCESSING FAILED FOR SYSMOD HBBO850 BECAUSE PROCESSING
FAILED FOR SYSMOD UI50772. SYSMOD UI50772
 CONTAINS HIGHER LEVELS OF COMMON ELEMENTS.

GIM30216IAPPLY PROCESSING FAILED FOR SYSMOD UI50772. SYSTEM UTILITY
PROCESSING FAILED FOR AN ELEMENT IN UI50772.
GIM30201E ** APPLY PROCESSING FAILED FOR SYSMOD HBBO800. ALL SYSMODS THAT
WOULD HAVE DELETED HBBO800 HAVE FAILED.


++ PTF (UI50772)/*

//UI50772  JOB 5655-50772,I3500,MSGLEVEL=(1,1),CLASS=A */
.
++ VER (Z038)

   FMID(HBBO850)

   PRE  (UI35842,UI35825,UI35824,UI35823,UI35822,UI35821,

 UI35820,UI35819)

   REQ  (UI50780,UI50779,UI50778,UI50777,UI50776,UI50775,

 UI50774,UI50773)

   SUP  (UI48569,UI48568,UI48567,UI48566,UI48565,UI48564,



 UI48563,UI48562,UI48561,UI43211,UI43210,
UI43209,

 UI43208,UI43207,UI43206,UI43205,UI43204,
UI43203,

 UI39709,UI39708,UI39707,UI39706,UI39705,UI39704,


 UI39703,AI87811,AI83950,AI83947,AI83946,
AI83945,

 AI83944,AI83942,AI83939,AI83938,AI83936,
AI73286,

 AI73285,AI73284,AI73283,AI73282,AI73281,AI73280,


 AI73279,AI73278,AI65610,AI65609,AI65608,
AI65607,

 AI65606,AI65605,AI65603)


 /*


   PROBLEM DESCRIPTION(S):


 PI87811 -


   *
***

   * USERS AFFECTED: All users of WebSphere Application Server
*

   * V8.5 for z/OS, including
*

   *- DMZ Secure Proxy Server,
*

   *- Web server plugins,
*

   *- IBM HTTP Server V8.5 on z/OS
*

   *
***

   * PROBLEM DESCRIPTION: A packaging issue with the previous
*

   *  WebSphere Application Server V8.5 for
*

   *  z/OS 8.5.5.12 PTFs prevented it from
*

   *  installing on top of WAS 8.5.5.9 and
*

   *  WAS 8.5.5.10.
*

   *
***

   * RECOMMENDATION:
*

   *
***

   Packaging errors in the original 8.5.5.12 PTFs caused SMP/E
to

   fail to APPLY the Fix Pack repository with


Packaging errors in the original 8.5.5.12 PTFs caused SMP/E to

fail to APPLY the Fix Pack repository with



GIM32501E ** APPLY PROCESSING HAS FAILED FOR SYSMOD UI48569.

UI48569 SUPERSEDES UI39703 BUT DOES NOT CONTAIN SHELLSCR

  BBODRMAK.



For documentation of the APAR contents for Fix Pack 8.5.5.12

please refer to the following URL:



http://www-01.ibm.com/support/docview.wss?uid=swg27036319

COMPONENT:  5655-I3500-HBBO850

*APARS FIXED: PI87811  *

SPECIAL CONDITIONS:

  COPYRIGHT: 5655-I3500 COPYRIGHT IBM CORP. 2012

 LICENSED MATERIAL - PROGRAM PROPERTY OF IBM

  DOCUMENTATION:

*The PTFs for Fix Pack 8.5.5.9 MUST be applied BEFORE you apply*

*the PTFs for Fix Pack 8.5.5.10 or later. File corruption will *

*occur if you attempt to install Fix Pack 8.5.5.9 along with a *

*subsequent fix pack. See below for an explanation.*



The Fix Pack 8.5.5.12 PTFs update the Installation Manager

repository for WebSphere Application Server Version 8.5

to include the 8.5.5.12 Fix Pack level for the WebSphere

Application Server full (traditional) profile, IBM HTTP Server,

and the Web Server Plugins.



Fix Pack 8.5.5.9 of WebSphere Application Server for z/OS is

the last Fix Pack that updates both the full (traditional)

profile and the Liberty profile of WebSphere Application Server.

On 13-Feb-2018 1:34 AM, "Neubert, Kevin" 
wrote:

> Confused.  You mention V10, link seems to indicate V8.5 and Liberty.
>
> Hopefully some of this helps.
>
> Liberty split from WebSphere maintenance V8.5.5.9.
>
> My understanding, as of V9, SMPE no longer applies maintenance to the
> local repositories, etc. just to the samples jobs (A/SBBOJCL).
>
> Take a look at the SBBOJCL(BBO1*) jobs for WebSphere or SBBOJCL(BBO5*) for
> Liberty.
>
> Regards,
>
> Kevin
>
> -Original 

Re: TCBFSA field in the TCB DSECT

[Bernd Oppolzer]

Hi,

IMO, the first save area should always be below the line.
It is provided by the operating system so that the main program of the
called application (EXEC PGM=...) can store the registers on call there.
And the first program may be AMODE 24 :-)

On the other hand, I would never use TCBFSA to do anything with it.
Because, for example, you would try to walk the save area chain from there,
you are stuck, because the forward pointers are not set correctly by LE 
and others.
What you should do instead: fetch register 13 and walk back, by using 
the backward
pointers, which are much more reliable in the general case. When doing 
this,
you could check for the value in TCBFSA to see, if you arrived at the 
first save

area. But you could also check for NULL in the backward pointer.

HTH, kind regards

Bernd


Am 13.02.2018 um 10:07 schrieb Steff Gladstone:

Hi,

I am in the process of converting several routines to AMODE=31 RMODE=ANY.
One of them references the address of the first problem program save area
found in the TCB.

The field is defined as follows:

TCBFSA   DS0A -ADDRESS OF THE FIRST PROBLEM PROGRAM SAVE AREA

 DSFL1 -   FIRST BYTE OF TCBFSA
@G381P9A

TCBFSAB  DSAL3 -   ADDRESS OF THE FIRST PROBLEM PROGRAM SAVE AREA

My question:  what is the status of the first byte?  It does not seem to
contain flag bits as is often the case.  On the other hand, defining the
field TCBFSAB seems to imply that the address is a 24-bit address.  So in
AMODE=31 can the first problem program save area (which is provided by the
system to the top-level program) be above the line?  Should I relate to all
four bytes as the address of the FSA?  Or could the first byte contain
garbage?

Thanks,
Steff

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

TCBFSA field in the TCB DSECT

[Steff Gladstone]

Hi,

I am in the process of converting several routines to AMODE=31 RMODE=ANY.
One of them references the address of the first problem program save area
found in the TCB.

The field is defined as follows:

TCBFSA   DS0A -ADDRESS OF THE FIRST PROBLEM PROGRAM SAVE AREA

DSFL1 -   FIRST BYTE OF TCBFSA
@G381P9A

TCBFSAB  DSAL3 -   ADDRESS OF THE FIRST PROBLEM PROGRAM SAVE AREA

My question:  what is the status of the first byte?  It does not seem to
contain flag bits as is often the case.  On the other hand, defining the
field TCBFSAB seems to imply that the address is a 24-bit address.  So in
AMODE=31 can the first problem program save area (which is provided by the
system to the top-level program) be above the line?  Should I relate to all
four bytes as the address of the FSA?  Or could the first byte contain
garbage?

Thanks,
Steff

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