date:20151126

1. Yeah, a separate folder solves this problem while complicating other chores 
issues or requirements or habits or whatever. I suspect it is the only 
solution. Grrr.

2. You can't do it with a #pragma! #pragma options only supports C and this is 
C++. Go figure.

Make may be goodness for a thousand reasons but it does nothing for this 
problem, unless you happen to be happier with CD commands than with paths in DD 
statements (which many people are -- I am roughly equally happy with each).

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jack J. Woehr
Sent: Thursday, November 26, 2015 11:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Any clever way to defeat the C compiler's options precedence?

Charles Mills wrote:
> For your specific "omit the problem file from the JCL" suggestion there are 
> no files in the JCL. //SYSIN specifies a UNIX folder and the compiler grabs 
> all of the .C or .c files.
Okay. Two Ideas and one "But Anyway"

 1. Move the problem file out of the folder, compile separately, put object in 
the object folder, run the JCL link step.
 2. Remove the OPT=ARCH(5) or whatever from the JCL and edit the corresponding 
#pragma into the source files.

"But Anyway"

If they're not in a data set but already in a directory under OMVS, it's 
going to take a lot less time to learn
'make' than to solve this any other way.

...
###
# Compilation rules
###

CC = c89
LD = ld

$(OBJDIR1)/%.o : $(SRCDIR1)/%.cpp
 $(CC) $(INC_PATH_FLAGS) $(CFLAGS1) -c $< -o $@

$(OBJDIR2)/%.o : $(SRCDIR2)/%.cpp
 $(CC) $(INC_PATH_FLAGS) $(CFLAGS2) -c $< -o $@

.. where the two different CFLAGS would have your different options in this 
very simple example
There are other ways to pass different flags to different files aside from 
sorting them into different dirs.

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

Re: Any clever way to defeat the C compiler's options precedence?

G. Please read the thread. I keep explaining the same points.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Crayford
Sent: Thursday, November 26, 2015 2:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Any clever way to defeat the C compiler's options precedence?

Try PARM="ARCH(5),OPTF"



> On 27 Nov 2015, at 2:56 am, Charles Mills  wrote:
> 
> ARCH(9) / ARCH(5)

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

LE question

2015-11-26 Thread Scott Ford

All,

I have a new to verify the correct LE runoption are in effect prior to our
STCs initialization.
I need to check things like:

1.ALL31
2.   HEAP
3.   STACK

I would like to do this pro grammatically. Can i do this ?
If I can , can some point me the direction of a manual which mentions it ?

Regards,
Scott
www.idmworks.com

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

Re: LE question

I think Scott is the vendor and is worried about the customer doing a 
PARM='some LE option/...' or a //CEEOPTS DD and then calling their support when 
the STC does not perform as desired. Or at least confusing their support desk 
because things are not exactly as the vendor expects.

I don't know of a solution but it would be a nice thing -- an LE service to 
return all of the options currently in effect.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Thursday, November 26, 2015 1:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LE question

The parms are controlled via (depending on the z/OS Level) a CEEPRMxx member in 
Parmlib or CEEOPT module in the code.  Generally - one size fits all.  In 
CEEPRMxx are parms for CICS, Other, and I am not sure if there is another 
delineation or not.

So depending on the environment - I would start with SYS1.PARMLIB and CEEPRMxx 
- see if it is there.

Start with the z/OS 2.1.0>z/OS MVS>z/OS MVS Initialization and Tuning 
Reference>Members of SYS1.PARMLIB>CEEPRMxx (runtime option 
parameters)>Statements/parameters for CEEPRMxx

Not sure about programmatically.  Most STCs should be using the system defined 
CEEPRMxx.  However that is not to say a vendor did not create their own CEEDOPT 
and link it into the STC.

You can issue a D CEE,ALL command through the console z/OS 2.1.0>z/OS MVS>z/OS 
MVS System Commands>MVS system commands reference>DISPLAY command>Displaying 
the current system level language environment run-time options

For CICS you can enter the CLER trans.

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

Re: Any clever way to defeat the C compiler's options precedence?

2015-11-26 Thread David Crayford

Try PARM="ARCH(5),OPTF"



> On 27 Nov 2015, at 2:56 am, Charles Mills  wrote:
> 
> ARCH(9) / ARCH(5)
> 
> Charles
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jack J. Woehr
> Sent: Thursday, November 26, 2015 10:16 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Any clever way to defeat the C compiler's options precedence?
> 
> Jack J. Woehr wrote:
>> If you didn't previously post in detail,
> Ok, what option is being set by the JCL and what do you want to do instead
> on one file?
> 
> -- 
> Jack J. Woehr # Science is more than a body of knowledge. It's a way of
> www.well.com/~jax # thinking, a way of skeptically interrogating the
> universe www.softwoehr.com # with a fine understanding of human fallibility.
> - Carl Sagan
> 
> --
> 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: LE question

2015-11-26 Thread Hank Oerlemans

If you can assume R12 point to the CAA then:

USING CEECAA,12 
USING CEEEDB,11 
USING CEEOCB,10 
L 11,CEECAAEDB 
L 10,CEEEDBOPTCB
CEECAA 
CEEEDB 
CEEOCB  

then use the following information to parse 

https://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceev100/appocb.htm?lang=en

If you need to find the CAA then use "CEEARLU — anchor lookup"

Cheers Hank


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

Re: LE question

2015-11-26 Thread Scott Ford

Hank:

Much appreciated , exactly what I needed.

Regards,
Scott
IDMworks

On Thu, Nov 26, 2015 at 5:13 PM, Hank Oerlemans  wrote:

> If you can assume R12 point to the CAA then:
>
> USING CEECAA,12
> USING CEEEDB,11
> USING CEEOCB,10
> L 11,CEECAAEDB
> L 10,CEEEDBOPTCB
> CEECAA
> CEEEDB
> CEEOCB
>
> then use the following information to parse
>
>
> https://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceev100/appocb.htm?lang=en
>
> If you need to find the CAA then use "CEEARLU — anchor lookup"
>
> Cheers Hank
>
>
> --
> 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: FW: Help with mount?

2015-11-26 Thread Steve Beaver

Do you have UID(0) on your USERID?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Hunkeler
Sent: Wednesday, November 25, 2015 11:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: FW: Help with mount?

>Thanks to some help offline, I was pointed to RDEFINE TSOAUTH MOUNT
UACC(NONE).  This allowed me to enter "mount -qv /".  Thanks Steve. 

I'm baffled. I've never before detected a connection between TSOAUTH in
general, and TSOAUTH MOUNT especially and any z/OS UNIX authority. 

Where is the relation between TSOAUTH MOUNT and z/OS UNIX file system mount
described?

TSOAUTH is described in "z/OS V2R1.0 TSO/E Customization - Chapter 18.
Protecting the resources TSO/E users can access". There I read at the end of
the chapter:

Summary of resources protected using RACF

TSOAUTH 

MOUNT Allow this user to issue dynamic allocation requests that result in
the need for volume mounting.

No mention of UNIX mount.

--
Peter Hunkeler

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

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

Re: LE question

2015-11-26 Thread Lizette Koehler

The parms are controlled via (depending on the z/OS Level) a CEEPRMxx member in 
Parmlib or 
CEEOPT module in the code.  Generally - one size fits all.  In CEEPRMxx are 
parms for CICS, Other, and I am not sure if there is another delineation or not.

So depending on the environment - I would start with SYS1.PARMLIB and CEEPRMxx 
- see if it is there.

Start with the z/OS 2.1.0>z/OS MVS>z/OS MVS Initialization and Tuning 
Reference>Members of SYS1.PARMLIB>CEEPRMxx (runtime option 
parameters)>Statements/parameters for CEEPRMxx

Not sure about programmatically.  Most STCs should be using the system defined 
CEEPRMxx.  However that is not to say a vendor did not create their own CEEDOPT 
and link it into the STC.

You can issue a D CEE,ALL command through the console
z/OS 2.1.0>z/OS MVS>z/OS MVS System Commands>MVS system commands 
reference>DISPLAY command>Displaying the current system level language 
environment run-time options

For CICS you can enter the CLER trans.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Scott Ford
> Sent: Thursday, November 26, 2015 1:53 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: LE question
> 
> All,
> 
> I have a new to verify the correct LE runoption are in effect prior to our 
> STCs
> initialization.
> I need to check things like:
> 
> 1.ALL31
> 2.   HEAP
> 3.   STACK
> 
> I would like to do this pro grammatically. Can i do this ?
> If I can , can some point me the direction of a manual which mentions it ?
> 
> Regards,
> Scott
> www.idmworks.com

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

Re: LE question

2015-11-26 Thread Scott Ford

Charles:

Absolutely correct, I am going to write it and then share ,,if you guys
want me to...

Regards,
Scott

On Thu, Nov 26, 2015 at 4:53 PM, Charles Mills  wrote:

> I think Scott is the vendor and is worried about the customer doing a
> PARM='some LE option/...' or a //CEEOPTS DD and then calling their support
> when the STC does not perform as desired. Or at least confusing their
> support desk because things are not exactly as the vendor expects.
>
> I don't know of a solution but it would be a nice thing -- an LE service
> to return all of the options currently in effect.
>
> Charles
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Thursday, November 26, 2015 1:22 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: LE question
>
> The parms are controlled via (depending on the z/OS Level) a CEEPRMxx
> member in Parmlib or CEEOPT module in the code.  Generally - one size fits
> all.  In CEEPRMxx are parms for CICS, Other, and I am not sure if there is
> another delineation or not.
>
> So depending on the environment - I would start with SYS1.PARMLIB and
> CEEPRMxx - see if it is there.
>
> Start with the z/OS 2.1.0>z/OS MVS>z/OS MVS Initialization and Tuning
> Reference>Members of SYS1.PARMLIB>CEEPRMxx (runtime option
> parameters)>Statements/parameters for CEEPRMxx
>
> Not sure about programmatically.  Most STCs should be using the system
> defined CEEPRMxx.  However that is not to say a vendor did not create their
> own CEEDOPT and link it into the STC.
>
> You can issue a D CEE,ALL command through the console z/OS 2.1.0>z/OS
> MVS>z/OS MVS System Commands>MVS system commands reference>DISPLAY
> command>Displaying the current system level language environment run-time
> options
>
> For CICS you can enter the CLER trans.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Any clever way to defeat the C compiler's options precedence?

2015-11-26 Thread Paul Gilmartin

On Thu, 26 Nov 2015 12:48:05 -0700, Jack J. Woehr wrote:
>...
>###
># Compilation rules
>###
>
>CC = c89
>LD = ld
>
>$(OBJDIR1)/%.o : $(SRCDIR1)/%.cpp
> $(CC) $(INC_PATH_FLAGS) $(CFLAGS1) -c $< -o $@
>
>$(OBJDIR2)/%.o : $(SRCDIR2)/%.cpp
> $(CC) $(INC_PATH_FLAGS) $(CFLAGS2) -c $< -o $@
>
>.. where the two different CFLAGS would have your different options in 
> this very simple example
>There are other ways to pass different flags to different files aside from 
> sorting them into different dirs.
> 
I'd use a generic suffix rule for the preponderance of the sources and a 
specific
rule naming the few exceptions

-- gil

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

Re: Any clever way to defeat the C compiler's options precedence?


Paul Gilmartin wrote:

I'd use a generic suffix rule for the preponderance of the sources and a 
specific
rule naming the few exceptions

-- gil



That would be the right way for Charles Mills to go if he built with make/

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

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

Re: Any clever way to defeat the C compiler's options precedence?

2015-11-26 Thread David Crayford


Isn't this a bit of a no-brainer just using JCL?

//CPROCPROC M=,PARMS=
//COMPILE EXEC PGM=CCNDRVR,REGION=0M,
//PARM=('EXPORTALL OPTF LOC(EN_US.IBM-037) ')
//SYSMSGS  DD  DUMMY
//USERLIB  DD  DISP=SHR,DSN=DOC.USER.H
// DD  DISP=SHR,DSN=COM110.WDOC.H
// DD  DISP=SHR,DSN=COM110.DEVT.H
//SYSOPTF  DD  *
ARCH(9)
RENT,SS,NOSEQ,NOMARG,STA,LO,
SE(*),LSE(*),GOFF,SO,LIST,LANG(EXTC99)
DEF(_XOPEN_SOURCE_EXTENDED)
//SYSINDD  DISP=SHR,DSN=COM110.DEVT.C()
//SYSLIN   DD  DISP=SHR,DSN=COM110.WDOC.COBJECT()
//SYSPRINT DD  SYSOUT=*
//SYSOUT   DD  SYSOUT=*
//SYSCPRT  DD  SYSOUT=*
//*
// PEND
//*
//COMCISPF EXEC CPROC,M=COMCISPF,PARMS='ARCH(5)'
//COMDLL   EXEC CPROC,M=COMDLL
//COMDLLI  EXEC CPROC,M=COMDLLI
//COMDLLS  EXEC CPROC,M=COMDLLS
//COMDSN   EXEC CPROC,M=COMDSN
//COMHMAP  EXEC CPROC,M=COMHMAP


On 26/11/2015 3:24 AM, Charles Mills wrote:

The C/C++ compiler lets you set options globally with PARM= or DD:OPTFILE
(or equivalently on a UNIX command line for those who like that sort of
thing). You can also specify most options *first thing* in a source module
with #pragma OPTIONS.

The former overrides the latter. It seems to me that is backwards. I want to
compile all of my modules with OPTION FOO, except one module that I want to
compile with OPTION NOFOO. I would like to specify PARM=FOO globally and
specify #pragma OPTIONS ( NOFOO ) in the one module. Doesn't that sound
reasonable?

Am I RTFM incorrectly? Or has anyone figured out a bit of cleverness to have
global "default" options that one can override on a source module by source
module basis. (I have common JCL that I use "universally." I have hundreds
of source modules. I don't have hundreds of "compile jobs.")

Thanks,

Charles

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


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

Re: Any clever way to defeat the C compiler's options precedence?

Yes. Very much like what I do. But it is the framework of the problem, not
the solution. Here is the problem:

I want to compile the bulk of my modules by default ARCH(9) (changeable from
time to time) but two of them ARCH(5). Should be simple enough, right? (Why?
See related thread. I want to deal gracefully with a machine whose ARCH
level is lower than my build level. I want my main and the "deal with it"
module to be able to run without a S0C1 on any "z" machine.)

- You can't do the obvious: put ARCH(9) in OPTF and #pragma options (
ARCH(5) ) in the two because PARM=/OPTF overrides #pragma options -- the
main subject of this thread.
- I thought I was going to solve it by putting #pragma options ( ARCH(9) )
in a "universal" header and #ifdef around it in the two modules, ... BUT
- #pragma OPTIONS is C only and my code is 98% C++. I could make one of the
two C and split the other one up so part of it was C, but that still leaves
me with no way of specifying ARCH(9) for the bulk of the modules.
- Wait! IBM thoughtfully provided #pragma option_override! It overrides what
was specified on PARM=/OPTF. It's C and C++. Sounds perfect, right? But no
... it only supports the optimization options, and ARCH is in this
compiler's world not an optimization option -- only compact, level, spill
and strict.
- I am about convinced I can't get there from here. Does my problem seem
that unreasonable?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Crayford
Sent: Thursday, November 26, 2015 5:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Any clever way to defeat the C compiler's options precedence?

Isn't this a bit of a no-brainer just using JCL?

//CPROCPROC M=,PARMS=
//COMPILE EXEC PGM=CCNDRVR,REGION=0M,
//PARM=('EXPORTALL OPTF LOC(EN_US.IBM-037) ')
//SYSMSGS  DD  DUMMY
//USERLIB  DD  DISP=SHR,DSN=DOC.USER.H
// DD  DISP=SHR,DSN=COM110.WDOC.H
// DD  DISP=SHR,DSN=COM110.DEVT.H
//SYSOPTF  DD  *
ARCH(9)
RENT,SS,NOSEQ,NOMARG,STA,LO,
SE(*),LSE(*),GOFF,SO,LIST,LANG(EXTC99)
DEF(_XOPEN_SOURCE_EXTENDED)
//SYSINDD  DISP=SHR,DSN=COM110.DEVT.C()
//SYSLIN   DD  DISP=SHR,DSN=COM110.WDOC.COBJECT()
//SYSPRINT DD  SYSOUT=*
//SYSOUT   DD  SYSOUT=*
//SYSCPRT  DD  SYSOUT=*
//*
// PEND
//*
//COMCISPF EXEC CPROC,M=COMCISPF,PARMS='ARCH(5)'
//COMDLL   EXEC CPROC,M=COMDLL
//COMDLLI  EXEC CPROC,M=COMDLLI
//COMDLLS  EXEC CPROC,M=COMDLLS
//COMDSN   EXEC CPROC,M=COMDSN
//COMHMAP  EXEC CPROC,M=COMHMAP


On 26/11/2015 3:24 AM, Charles Mills wrote:
> The C/C++ compiler lets you set options globally with PARM= or 
> DD:OPTFILE (or equivalently on a UNIX command line for those who like 
> that sort of thing). You can also specify most options *first thing* 
> in a source module with #pragma OPTIONS.
>
> The former overrides the latter. It seems to me that is backwards. I 
> want to compile all of my modules with OPTION FOO, except one module 
> that I want to compile with OPTION NOFOO. I would like to specify 
> PARM=FOO globally and specify #pragma OPTIONS ( NOFOO ) in the one 
> module. Doesn't that sound reasonable?
>
> Am I RTFM incorrectly? Or has anyone figured out a bit of cleverness 
> to have global "default" options that one can override on a source 
> module by source module basis. (I have common JCL that I use 
> "universally." I have hundreds of source modules. I don't have 
> hundreds of "compile jobs.")
>
> Thanks,
>
> Charles
>
> --
> 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: LE question

Does not CEEOPTS etc. still override? A good thing if you want it; a bad thing 
if you don't.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Hank Oerlemans
Sent: Thursday, November 26, 2015 2:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LE question

If it's that sensitive then linking in your own options module would be a good 
idea.

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

Re: 3DES encryption using ICSF callable services

2015-11-26 Thread John Blythe Reid

Just in case it could help anyone else, I also discovered that I could have 
used this callable service to encipher the response:

Encode (CSNBECO and CSNEECO)
Use the encode callable service to encipher an 8-byte string using a clear key. 
The
callable service uses the electronic code book (ECB) mode of the DES. (This
service is available only on a DES-capable system.)

This service only allows eight bytes of clear text to be enciphered using an 
eight byte clear key, but that was just what I wanted to do.

Regards,
John.

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

Re: IBM Mainframe

2015-11-26 Thread John McKown

On Wed, Nov 25, 2015 at 5:37 PM, esst...@juno.com  wrote:

> From my personal observation I don't see a shortage of Mainframe Skills.
> I do see companies not willing to pay for an experience skill set. In to
> days economic climate business are very reluctant to hire staff positions,
> they would rather invest in contractors.
>

That's definitely true at the company I'm working for. Basically, the
company wants "ad hoc" workers for some project. But they don't seem to
have any concern about "maintenance" or having people on staff who
understand how things work. They want I.T. to be like the water/sewage
company or electricity. Or maybe like plumbers. Call when you have a
problem. Too bad, for them, that I.T. tends to be more "customized" and you
can't just unplug a programmer from one job and plug him into another,
unlike a light bulb or a lamp.

The company wants to only be an insurance company. They are outsourcing
I.T. infrastructure. They have already outsourced the DBA function, new
business data entry, and claims data entry. I'm not sure about the
applications themselves. I do know that the software for the agents is
actually written by programmers in the agency company, as opposed to the
insurance / underwriting company (us).

 .

> .
> Just my observation.
>
>
-- 

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

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

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

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

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

Re: IBM Mainframe

2015-11-26 Thread John McKown

On Wed, Nov 25, 2015 at 6:17 PM, John Mattson 
wrote:

> My personal experience.  I'm 67, laid off after 18 years May 2014,
> consultant with raise Sept 2014, Hired away with raise Aug 2015.  Yes,
> there is work to be had.  More so if you are able to travel and/or
> re-locate, but I am seeing more notices for work-from-home.  PS, once you
> are on Medicare, most company"benefits" are worth very little to you, so
> you might as well consult.
>
>
Unfortunately for me, I'm "in the hole". I'll be 63 when the company gets
rid of me. Likely too old to get hired somewhere else, too young for
Medicare. Oh well, maybe a massive heart attack is the answer. Too bad I
passed my nuclear stress test with flying colors. 


-- 

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

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

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

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

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

Re: IBM Mainframe

2015-11-26 Thread Elardus Engelbrecht

John McKown wrote:

>Unfortunately for me, I'm "in the hole". I'll be 63 when the company gets rid 
>of me. Likely too old to get hired somewhere else, too young for Medicare. 

Same here in Sunny South Africa. Generally retirement age is about 60 years, 
but you can retire at 55 - 65 years depending on approval from employer and 
employee and your health and productivity/performance status.

Oldies just can't get jobs, you'll have to be creative (moonlighting, extra 
classes, private services, contracting, etc.) to earn some money.

About that "hole". You get two such "holes" in your life - First one, after you 
get out of school and trying to get work somehow - but the catch 22 thing is - 
"they" want experienced guys/gals, but how do you get experience in the first 
place?

One way to solve is to try to do some charity or free work, apparently 
employers like that, but I see no proof that it can work.

Then your "hole", which is the second one, but that one is more frustrating 
because you need to plan for at least 10-20 years, while your money is being 
vacuumed up by all those hungry vultures...

Ok, let us go back about 'shortage of Mainframe Skills'. 

Here "they" want experienced skilled professionals, but "they" are too cheap to 
pay properly. Hence the 'virtual' shortage of skills. And the skilled persons 
just go overseas for a better future.

It is a Cruel Crazy Beautiful world... (apologies to the singer Johnny Clegg...)

Part of that song ...

"You have to wash with the crocodile in the river
You have to swim with the sharks in the sea
You have to live with the crooked politician
Trust those things that you can never see"

(From: http://www.johnnyclegg.com/lyrics/ccbw.html )

Groete / Greetings
Elardus Engelbrecht (48 years young...)

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

Re: Straightforward way to determine hardware architecture level?

2015-11-26 Thread Peter Relson

To answer your question directly: no there is no such way. Could there be, 
in the future? Sure.  If z/OS base control program were to provide it, it 
might not be the compiler ARCH value but might be the machine generation 
number (which happens to be +2 over the compiler ARCH level) -- e.g., z13 
happens to be "13" (not a big stretch). If LE or a compiler area were to 
provide it, then it would more likely be the number that they use.

The problem that you wrote that you were challenged with solving was "
couldn't we put out a better message than S0C1?""
And the answer is for the most part "yes", without requiring an answer to 
the question you posed: field the PIC 1 in recovery and deal with it in a 
nicer way than you currently do (such as a message, a unique abend/reason 
code pair that you document for your product, whatever).

Peter Relson
z/OS Core Technology Design


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

Re: Straightforward way to determine hardware architecture level?

2015-11-26 Thread Peter Relson

I wanted to add that the list of facilities mentioned in one of the posts

>ARCH(10) (xC12) execution-hint facility, the load-and-trap
>facility, the miscellaneous-instruction-extension facility, and the
>transactional-execution facility.

leads to some interesting points.

The availability of an instruction on the machine (which the facility bits 
indicate) do not necessarily correlate to whether you may use them.
When there is operating system support needed, there are often "function 
bits" that an application is expected to use to determine availability.
We have tried to improve the IHAFACL documentation going forward to help 
identify those bits that correlate to facility bit(s).

Transactional execution facility is one of interest. It is available only 
on certain z/OS releases (z/OS can run on a zEC12 on more releases than 
those z/OS releases that support the instruction).

Further, it is not available on any z/OS release if z/OS is running under 
VM. 

Thus, for example, running on z/OS 2.2 on a zEC12 does not mean that you 
can use transactional execution if you might be under VM. 
Apparently C/C++ users are supposed to understand this and not try to run 
something that is ARCH(10) if running z/OS under VM if they might have 
coded something that led the compiler to generate instructions that are 
part of the TEF.

Peter Relson
z/OS Core Technology Design


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

Re: Straightforward way to determine hardware architecture level?

2015-11-26 Thread Elardus Engelbrecht

Peter Relson wrote:

>Further, it is not available on any z/OS release if z/OS is running under VM. 

Very interesting. Are there other functions also absent when z/OS is running as 
a guest under z/VM?

If so, where is that documented?

Many thanks for your excellent posts. I value them all! 

TIA!

Groete / Greetings
Elardus Engelbrecht

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

Re: IBM Mainframe

2015-11-26 Thread esst...@juno.com

john McKown wrote

â€‹That's definitely true at the company I'm working for. Basically, the
company wants "ad hoc" workers for some project. But they don't seem to
have any concern about "maintenance" or having people on staff who
understand how things work. They want I.T. to be like the water/sewage company 
or electricity. Or maybe like plumbers. Call when you have a problem. Too bad, 
for them, that I.T. tends to be more "customized" and you can't just unplug a 
programmer from one job and plug him into another, unlike a light bulb or a 
lamp.

In the New York & New Jersey area this attitude is prevalant.
Many institutions have been burned on this "plug and Play: mentality. They do 
not look at inhoues I.T. personal as ASSESETS.
I suspect its due to the younger management.  
.

The company wants to only be an insurance company. They are outsourcing I.T. 
infrastructure. They have already outsourced the DBA function, new business 
data entry, and claims data entry. I'm not sure about the applications 
themselves. I do know that the software for the agents is actually written by 
programmers in the agency company, as opposed to the insurance / underwriting 
company (us).

I can understand this methodology and to some degree makes sense. However in my 
experience It has never been a proven long term strategy.
.
.

-- Original Message --
From: John McKown 
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM Mainframe
Date: Thu, 26 Nov 2015 05:51:36 -0600

On Wed, Nov 25, 2015 at 5:37 PM, esst...@juno.com  wrote:

> From my personal observation I don't see a shortage of Mainframe Skills.
> I do see companies not willing to pay for an experience skill set. In to
> days economic climate business are very reluctant to hire staff positions,
> they would rather invest in contractors.
>

â€‹That's definitely true at the company I'm working for. Basically, the
company wants "ad hoc" workers for some project. But they don't seem to
have any concern about "maintenance" or having people on staff who
understand how things work. They want I.T. to be like the water/sewage
company or electricity. Or maybe like plumbers. Call when you have a
problem. Too bad, for them, that I.T. tends to be more "customized" and you
can't just unplug a programmer from one job and plug him into another,
unlike a light bulb or a lamp.

The company wants to only be an insurance company. They are outsourcing
I.T. infrastructure. They have already outsourced the DBA function, new
business data entry, and claims data entry. I'm not sure about the
applications themselves. I do know that the software for the agents is
actually written by programmers in the agency company, as opposed to the
insurance / underwriting company (us).

 .

> .
> Just my observation.
>
>
-- 

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

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

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

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

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

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

WLM and Dispatching Priority

2015-11-26 Thread phil yogendran

Hello All,

I need some assistance with being able to get a proper DP assigned to a set
of tasks. The problem is this;

I have 2 tasks, SYSVIEW and CICSLOGR and many CICS tasks. CICSLOGR is a
subtask attached by SYSVIEW.

In WLM, SYSVIEW is set to a service class of 'monitor' with an importance
of 1 and velocity of 75.

The CICS regions are set to a service class of 'CICSA' which has an
importance of 1 and velocity goal of 65.

However, what I see is that the CICS regions run at a DP of F6 and SYSVIEW
is at F4.

How can I make sure that SYSVIEW and CICSLOGR run at a higher DP? I'm on
z/OS 1.13 and in a sysplex environment.

Looking forward to your response. Thanks.

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

Re: IBM Mainframe JOB market

2015-11-26 Thread esst...@juno.com

Steve Beaver wrote
"And I cover all zOS Systems, ACF2, RACF, TSS, CICS, DB2, IMS/DB-DC, Cobol, 
PL/I and Assembler."


I HATE THIS !
This is not a software specialist - it is a software Inventory
I have been known to respond to recruiters like this. And Yes the recruiters 
take too much, it partially due to out sources from other counteries bidding 
too low on contracts. They do not play by the same rules as the US contracters 
- so how can one compete ?
.
.
  

-- Original Message --
From: Steve Beaver 
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM Mainframe JOB market
Date: Wed, 25 Nov 2015 21:15:02 -0800

It's not the business doesn't want to pay.  The middle men/head hunters want
to keep a 2.5 to 1 ratio

If they pay you $60 they charge the customer $150.  I've also told these
middle men/head hunters, unless you
Personally can to the job you can have $30 per hour and I will take the $120
and they get more that a little
Upset.

And I cover all zOS Systems, ACF2, RACF, TSS, CICS, DB2, IMS/DB-DC, Cobol,
PL/I and Assembler.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of esst...@juno.com
Sent: Wednesday, November 25, 2015 3:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM Mainframe JOB market

We had a 71 Year old z/OS System Programmer take an early retirement
package. After 6 Months he was bored, so he took a contracting position with
an IBM customer. He lives in New Jersey and the data center is in Florida.
There is plenty of work around its just that Business don't want to PAY
$$.


-- Original Message --
From: David Speake 
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IBM Mainframe JOB market
Date: Wed, 25 Nov 2015 17:38:31 -0600

Last Friday I was told that there is a desperate shortage of IBM mainframe
talent at most all skill levels and specialties. I have   
not done my homework, say on Monster.com or otherwise.  Suspect that, if
true, it would be a hot topic here. So I scanned   
rather quickly through October and November archives. Any comment on  this
rumor. I am 71 years old and the same  
source cheered me a bit by noting that a local outfit had very recently
hired an 81 year old COBOL programmer. No info on  
his experience nor more importantly his skill level. A Good friend, also 71,
retired and then lost his entire retirement in failed business 
venture. Hope the rumor is true. Job security for those of us that  still
have them and maybe hope for him and some of the others   
less fortunate. 
   

Sorry, got distracted just before sending previous post.

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

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

Re: WLM and Dispatching Priority

2015-11-26 Thread Vernooij, CP (ITOPT1) - KLM

First: DP's are variable and adjusted by WLM such that the task meets its 
goals. Apparently WLM in convinced that it is doing its job well.
Second: you can move the critical monitors to Service Class SYSSTC.
I don't think the CPUCRITICAL attribute will help in your current setup, 
because both SC's have the same importance.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of phil yogendran
Sent: 26 November, 2015 16:08
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: WLM and Dispatching Priority

Hello All,

I need some assistance with being able to get a proper DP assigned to a set
of tasks. The problem is this;

I have 2 tasks, SYSVIEW and CICSLOGR and many CICS tasks. CICSLOGR is a
subtask attached by SYSVIEW.

In WLM, SYSVIEW is set to a service class of 'monitor' with an importance
of 1 and velocity of 75.

The CICS regions are set to a service class of 'CICSA' which has an
importance of 1 and velocity goal of 65.

However, what I see is that the CICS regions run at a DP of F6 and SYSVIEW
is at F4.

How can I make sure that SYSVIEW and CICSLOGR run at a higher DP? I'm on
z/OS 1.13 and in a sysplex environment.

Looking forward to your response. Thanks.

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

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

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




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

Re: Any clever way to defeat the C compiler's options precedence?

2015-11-26 Thread Paul Gilmartin

On Wed, 25 Nov 2015 22:31:48 -0700, Jack J. Woehr wrote:
>
>I write programming languages that would make your hair stand on end. You can 
>download FIJI for example
>http://fiji.sourceforge.net
> 
An extreme example:
https://en.wikipedia.org/wiki/%42%72%61%69%6e%66%75%63%6b

(I don't use it; just stumbled on and amused by.)

-- gil

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

Re: Any clever way to defeat the C compiler's options precedence?

2015-11-26 Thread Robert A. Rosenberg

At 19:11 -0700 on 11/25/2015, Jack J. Woehr wrote about Re: Any 
clever way to defeat the C compiler's options prece:


 > 1. Will make in fact solve this specific problem? Can one readily 
specify "global" compiler options for most modules and override them 
for specific modules?


Not exactly. #pragma is #pragma and sometimes you just have to bite 
the bullet and manually surround preprocessor

directives with platform #ifdefs

 #ifndef __Z_OS__ /* or whatever is the platform tag for you */
 #pragma(foo)
 #endif


Will using this use of ifndef solve the issue that if a compiler 
option is set at launch time due to being coded in the JCL or via a 
DD it can/will override the pragma supplied setting? The issue that 
was raised is that there is apparently no way to override the global 
settings via a pragma in the source code of a module being compiled. 
Unless this happens all the ifndef does is supply options to be used 
when compiling under Z/OS SO LONG AS THE COMPILER does not override 
the requested option due to a Global Default override.


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

RES: WLM and Dispatching Priority

2015-11-26 Thread ITURIEL DO NASCIMENTO NETO

Hello,

Generally it is recommended that "Monitors" should execute at SYSSTC.


Atenciosamente / Regards / Saludos

BANCO BRADESCO S.A.
4250 / DPCD Engenharia de Software
Sistemas Operacionais Mainframes
Ituriel do Nascimento Neto
Tel: +55 11 3684-2177 R: 42177 3-1404
Fax: +55 11 3684-4427



Banco Bradesco.
Patrocinador oficial dos Jogos Olímpicos e Paralímpicos Rio 2016.

-Mensagem original-
De: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Em nome de 
phil yogendran
Enviada em: quinta-feira, 26 de novembro de 2015 13:08
Para: IBM-MAIN@LISTSERV.UA.EDU
Assunto: WLM and Dispatching Priority

Hello All,

I need some assistance with being able to get a proper DP assigned to a set
of tasks. The problem is this;

I have 2 tasks, SYSVIEW and CICSLOGR and many CICS tasks. CICSLOGR is a
subtask attached by SYSVIEW.

In WLM, SYSVIEW is set to a service class of 'monitor' with an importance
of 1 and velocity of 75.

The CICS regions are set to a service class of 'CICSA' which has an
importance of 1 and velocity goal of 65.

However, what I see is that the CICS regions run at a DP of F6 and SYSVIEW
is at F4.

How can I make sure that SYSVIEW and CICSLOGR run at a higher DP? I'm on
z/OS 1.13 and in a sysplex environment.

Looking forward to your response. Thanks.

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

AVISO LEGAL ...Esta mensagem é destinada exclusivamente para a(s) pessoa(s) 
a quem é dirigida, podendo conter informação confidencial e/ou legalmente 
privilegiada. Se você não for destinatário desta mensagem, desde já fica 
notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de 
qualquer forma, utilizar a informação contida nesta mensagem, por ser ilegal. 
Caso você tenha recebido esta mensagem por engano, pedimos que nos retorne este 
E-Mail, promovendo, desde logo, a eliminação do seu conteúdo em sua base de 
dados, registros ou sistema de controle. Fica desprovida de eficácia e validade 
a mensagem que contiver vínculos obrigacionais, expedida por quem não detenha 
poderes de representação. 
LEGAL ADVICE...This message is exclusively destined for the people to whom 
it is directed, and it can bear private and/or legally exceptional information. 
If you are not addressee of this message, since now you are advised to not 
release, copy, distribute, check or, otherwise, use the information contained 
in this message, because it is illegal. If you received this message by 
mistake, we ask you to return this email, making possible, as soon as possible, 
the elimination of its contents of your database, registrations or controls 
system. The message that bears any mandatory links, issued by someone who has 
no representation powers, shall be null or void.

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

Re: WLM and Dispatching Priority

2015-11-26 Thread Ted MacNEIL

Put monitors in SYSSTC.
This gives them the second highest DP in the system. You cannot completely 
control the DP in Service Classes.

-
-teD
-
  Original Message  
From: phil yogendran
Sent: Thursday, November 26, 2015 11:02
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: WLM and Dispatching Priority

Hello All,

I need some assistance with being able to get a proper DP assigned to a set
of tasks. The problem is this;

I have 2 tasks, SYSVIEW and CICSLOGR and many CICS tasks. CICSLOGR is a
subtask attached by SYSVIEW.

In WLM, SYSVIEW is set to a service class of 'monitor' with an importance
of 1 and velocity of 75.

The CICS regions are set to a service class of 'CICSA' which has an
importance of 1 and velocity goal of 65.

However, what I see is that the CICS regions run at a DP of F6 and SYSVIEW
is at F4.

How can I make sure that SYSVIEW and CICSLOGR run at a higher DP? I'm on
z/OS 1.13 and in a sysplex environment.

Looking forward to your response. Thanks.

--
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: Straightforward way to determine hardware architecture level?

@Peter, thank you for the direct answer. Yes, I would consider an "ARCH
level," a "ZS- number" or a "marketing architecture number" such as 13 to be
a great answer to my need. As you move your emphasis more from assembler to
compiled languages an ARCH number rather than "op code bits" would be a good
idea IMHO.

Catching the S0C1 is more complicated than it sounds. There is kind of a
chicken and egg problem. The code is 95% in C++. I am trying to avoid
starting in assembler and calling the C main, which would however make this
problem trivial. I have a recovery routine and it works perfectly, knock on
wood. But setting it up and setting up the things it depends on requires
code, there is a problem (not insurmountable, but not easy -- see companion
thread) with compiling some modules at one ARCH level and some at another,
and so the C++ code S0C1s long before it gets its recovery routine set up.
(FWIW, it S0C1ed trying to display its initial "hello" and version number
message.)

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Thursday, November 26, 2015 6:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Straightforward way to determine hardware architecture level?

To answer your question directly: no there is no such way. Could there be,
in the future? Sure.  If z/OS base control program were to provide it, it
might not be the compiler ARCH value but might be the machine generation
number (which happens to be +2 over the compiler ARCH level) -- e.g., z13
happens to be "13" (not a big stretch). If LE or a compiler area were to
provide it, then it would more likely be the number that they use.

The problem that you wrote that you were challenged with solving was "
couldn't we put out a better message than S0C1?""
And the answer is for the most part "yes", without requiring an answer to
the question you posed: field the PIC 1 in recovery and deal with it in a
nicer way than you currently do (such as a message, a unique abend/reason
code pair that you document for your product, whatever).

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

Re: Any clever way to defeat the C compiler's options precedence?

1. So the use of make rather than JCL has ABSOLUTELY NOTHING WHATSOEVER to do 
with the problem I posted, the subject of the thread??!! Gee, thanks.

I am not a C newbie. I am totally familiar with #ifdef (the relevant macro is 
__MVS__ FWIW). My code is 95% bimodal (Windows/z/OS) and some is trimodal 
(throw in Intel Linux). No amount of #ifdef __MVS__ solves the problem that 
command line/PARM=/OPTF options override #pragma OPTIONS.

2. So what IS a good tutorial for z/OS UNIX make? Also for -- what is the tool 
-- revealing my ignorance here -- that reads through the code and builds the 
dependency list for make automatically?

FWIW I guess the solution to my problem is to move the option totally out of 
PARM=/OPTF and into a common header file. (I happen to already have a "first in 
every module" header file.) It will need to be surrounded with #ifdef's for 
platform independence and so that one or two modules can bypass it.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jack J. Woehr
Sent: Wednesday, November 25, 2015 6:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Any clever way to defeat the C compiler's options precedence?

Charles Mills wrote:
> Touché.
>
> Yes, yes, I know, I should be using make. We all have a little bit of 
> dinosaur blood in us. Some are stuck in assembler.

I love assembler. When in assembler, I'm doing it your way.

>   I happen to be stuck in batch JCL compiles. I should learn make but it is 
> never at the top of the critical path.

I know the feeling. I'd love to play with z/OS more, have access, but same 
issue.

> 1. Will make in fact solve this specific problem? Can one readily specify 
> "global" compiler options for most modules and override them for specific 
> modules?

Not exactly. #pragma is #pragma and sometimes you just have to bite the bullet 
and manually surround preprocessor directives with platform #ifdefs

 #ifndef __Z_OS__ /* or whatever is the platform tag for you */
 #pragma(foo)
 #endif

Classic porting_software_to_myPlatform() pain in the butt. Welcome to the club. 
I do it all the time because I'm on one of the less popular open source 
operating systems and have to constantly participate in our community porting 
process.

But once can use make and macros to do all sorts of things that can accomplish 
what you are trying to achieve.

> 2. What's a good learning source for make? 
> www.oreilly.com/openbook/make3/book/index.csp ?

That's a real good start. That's GNU make, by the way, which is way advanced 
over Sys V make. So the make command you have on your system may have issues 
with some things that work with GNU.

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

Re: IBM Mainframe

On 26 November 2015 at 06:51, John McKown  wrote:
>
> The company wants to only be an insurance company. They are outsourcing
> I.T. infrastructure. They have already outsourced the DBA function, new
> business data entry, and claims data entry. I'm not sure about the
> applications themselves. I do know that the software for the agents is
> actually written by programmers in the agency company, as opposed to the
> insurance / underwriting company (us).

So, um, what's left of an insurance company once it's outsourced all
the data related functions?  It's not like a company that bangs out
widgets on a production line; the data is everything. Insurance is
about pooling risk, and an insurance *company* exists to make a profit
on pooling risk. Why would such a company need more than a CEO and a
couple of actuaries on the payroll? Probably those could be outsourced
too, saving even more money.

Tony H.

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

Re: WLM and Dispatching Priority

2015-11-26 Thread phil yogendran

Thank you all for your response and advise. My only reservation is that
SYSVIEW, at times, tends to be heavy-footed and causes the system to
'pause'. This is only because of the data we capture at periodic intervals.
Anyway, that's for me to investigate further and fix.

Thanks, again,


On Thu, Nov 26, 2015 at 11:16 AM, Ted MacNEIL  wrote:

> Put monitors in SYSSTC.
> This gives them the second highest DP in the system. You cannot completely
> control the DP in Service Classes.
>
> -
> -teD
> -
>   Original Message
> From: phil yogendran
> Sent: Thursday, November 26, 2015 11:02
> To: IBM-MAIN@LISTSERV.UA.EDU
> Reply To: IBM Mainframe Discussion List
> Subject: WLM and Dispatching Priority
>
> Hello All,
>
> I need some assistance with being able to get a proper DP assigned to a set
> of tasks. The problem is this;
>
> I have 2 tasks, SYSVIEW and CICSLOGR and many CICS tasks. CICSLOGR is a
> subtask attached by SYSVIEW.
>
> In WLM, SYSVIEW is set to a service class of 'monitor' with an importance
> of 1 and velocity of 75.
>
> The CICS regions are set to a service class of 'CICSA' which has an
> importance of 1 and velocity goal of 65.
>
> However, what I see is that the CICS regions run at a DP of F6 and SYSVIEW
> is at F4.
>
> How can I make sure that SYSVIEW and CICSLOGR run at a higher DP? I'm on
> z/OS 1.13 and in a sysplex environment.
>
> Looking forward to your response. Thanks.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Any clever way to defeat the C compiler's options precedence?

On 25 November 2015 at 14:24, Charles Mills  wrote:
> The C/C++ compiler lets you set options globally with PARM= or DD:OPTFILE
> (or equivalently on a UNIX command line for those who like that sort of
> thing). You can also specify most options *first thing* in a source module
> with #pragma OPTIONS.
>
> The former overrides the latter. It seems to me that is backwards. I want to
> compile all of my modules with OPTION FOO, except one module that I want to
> compile with OPTION NOFOO. I would like to specify PARM=FOO globally and
> specify #pragma OPTIONS ( NOFOO ) in the one module. Doesn't that sound
> reasonable?

This seems incomprehensively BAD (Broken As Designed). Do other IBM
compilers behave this way? Surely this is worth complaining about,
even if that process is too slow for your current problem.

The High Level Assembler does it about right, as you doubtless know.
Quote from the book::

==
Assembler options are recognized in this order of precedence (highest
to lowest):

Fixed installation default options
Options on *PROCESS OVERRIDE statements
Options in the ASMAOPT file (CMS or z/OS) or library member (z/VSE)
Invocation options

Options on the JCL PARM parameter of the EXEC statement on z/OS and
z/VSE, or the ASMAHL command on CMS
Options on the JCL OPTION statement (z/VSE)
Options specified via the STDOPT (Standard JCL Options) command (z/VSE)

Options on *PROCESS statements
Non-fixed installation default options

You can specify an option as often as you want, and in as many sources
as you want. However, this may mean that you have specified the
positive and negative form of an option (for keyword pairs), or two or
more different values (for a value keyword). These option
specifications are "conflicting" options. If all specifications of a
particular option are at the same level of precedence, the last
specification takes effect, and a warning message is issued. If some
conflicting specifications are at different levels of precedence, then
the specification at the higher order of precedence takes effect, and
(in general) the assembler issues a warning message for each option
that is not accepted. A warning message is not issued if the higher
level of precedence is a *PROCESS OVERRIDE statement, unless the
option cannot be set by a *PROCESS statement.
==

Effectively the above is saying that the equivalent of a C #pragma can
be coded so as to override the global or other "per compile" options,
except for an option chosen at compiler installation to not be
overridable. Probably that's what C needs.

HLASM also has an option (PCONTROL) to override the value of various
operands of the PRINT statement. PRINT is very widely used, and
controls six or so details of what gets shown in the listing. It can
be very handy during testing and "for the record" building, but I'm
not sure there is a meaningful C equivalent.

Tony H.

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

Re: Straightforward way to determine hardware architecture level?

On 26 November 2015 at 09:47, Elardus Engelbrecht
 wrote:
> Peter Relson wrote:
>>Further, it [Transactional Execution] is not available on any z/OS release if 
>>z/OS is running under VM.
>
> Very interesting. Are there other functions also absent when z/OS is running 
> as a guest under z/VM?

Large (1MB) page support, among several others.

I guess (and I have no IBM-internal knowledge whatsoever about this)
that this is all about a three-way battle between Poughkeepsie,
Endicott, and Boeblingen. Pok has never been wild about running z/OS
under VM, and Boeblingen has shifted from VM as the hypervisor they
absolutely needed to make Linux practical, to KVM, and so perceives
that they can do it all on their own. Where does this leave z/VM? In
third place with insufficient resources, I suspect. Maybe little has
changed since the 1970s and 80s that Lynn Wheeler writes of here so
often...

Tony H.

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

Re: Any clever way to defeat the C compiler's options precedence?

Exactly. Thank you. Yes, and COBOL does it more or less right also.

It's even worse than what I wrote. I am about convinced I cannot get there from 
here.

Problem: I want to compile the bulk of my modules by default ARCH(9) 
(changeable from time to time) but two of them ARCH(5). Should be simple 
enough, right? (Why? See related thread. I want to deal gracefully with a 
machine whose ARCH level is lower than my build level. I want my main and the 
"deal with it" module to be able to run without a S0C1 on any "z" machine.)

- You can't do the obvious: put ARCH(9) in OPTF and #pragma options ( ARCH(5) ) 
in the two because PARM=/OPTF overrides #pragma options -- the main subject of 
this thread.
- I thought I was going to solve it by putting #pragma options ( ARCH(9) ) in a 
"universal" header and #ifdef around it in the two modules, ... BUT
- #pragma OPTIONS is C only and my code is 98% C++. I could make one of the two 
C and split the other one up so part of it was C, but that still leaves me with 
no way of specifying ARCH(9) for the bulk of the modules.
- Wait! IBM thoughtfully provided #pragma option_override! It overrides what 
was specified on PARM=/OPTF. It's C and C++. Sounds perfect, right? But no ... 
it only supports the optimization options, and ARCH is in this compiler's world 
not an optimization option -- only compact, level, spill and strict.
- I am about convinced I can't get there from here. Does my problem seem that 
unreasonable?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Thursday, November 26, 2015 8:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Any clever way to defeat the C compiler's options precedence?

On 25 November 2015 at 14:24, Charles Mills  wrote:
> The C/C++ compiler lets you set options globally with PARM= or 
> DD:OPTFILE (or equivalently on a UNIX command line for those who like 
> that sort of thing). You can also specify most options *first thing* 
> in a source module with #pragma OPTIONS.
>
> The former overrides the latter. It seems to me that is backwards. I 
> want to compile all of my modules with OPTION FOO, except one module 
> that I want to compile with OPTION NOFOO. I would like to specify 
> PARM=FOO globally and specify #pragma OPTIONS ( NOFOO ) in the one 
> module. Doesn't that sound reasonable?

This seems incomprehensively BAD (Broken As Designed). Do other IBM compilers 
behave this way? Surely this is worth complaining about, even if that process 
is too slow for your current problem.

The High Level Assembler does it about right, as you doubtless know.
Quote from the book::

==
Assembler options are recognized in this order of precedence (highest to 
lowest):

Fixed installation default options
Options on *PROCESS OVERRIDE statements
Options in the ASMAOPT file (CMS or z/OS) or library member (z/VSE) Invocation 
options

Options on the JCL PARM parameter of the EXEC statement on z/OS and z/VSE, or 
the ASMAHL command on CMS Options on the JCL OPTION statement (z/VSE) Options 
specified via the STDOPT (Standard JCL Options) command (z/VSE)

Options on *PROCESS statements
Non-fixed installation default options

You can specify an option as often as you want, and in as many sources as you 
want. However, this may mean that you have specified the positive and negative 
form of an option (for keyword pairs), or two or more different values (for a 
value keyword). These option specifications are "conflicting" options. If all 
specifications of a particular option are at the same level of precedence, the 
last specification takes effect, and a warning message is issued. If some 
conflicting specifications are at different levels of precedence, then the 
specification at the higher order of precedence takes effect, and (in general) 
the assembler issues a warning message for each option that is not accepted. A 
warning message is not issued if the higher level of precedence is a *PROCESS 
OVERRIDE statement, unless the option cannot be set by a *PROCESS statement.
==

Effectively the above is saying that the equivalent of a C #pragma can be coded 
so as to override the global or other "per compile" options, except for an 
option chosen at compiler installation to not be overridable. Probably that's 
what C needs.

HLASM also has an option (PCONTROL) to override the value of various operands 
of the PRINT statement. PRINT is very widely used, and controls six or so 
details of what gets shown in the listing. It can be very handy during testing 
and "for the record" building, but I'm not sure there is a meaningful C 
equivalent.

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

Re: IBM Mainframe


esst...@juno.com wrote:

Many institutions have been burned on this "plug and Play: mentality. They do 
not look at inhoues I.T. personal as ASSESETS.
It's true in IT all over. A company I consult to has gotten rather large being the plug-in for big biz companies in the 
Linux/Windows hosted cloud application space

that really can't afford a full IT department any more.

Sounds like an entrepreneurial opportunity. Go thee oldster to it and form the 
plug-and-play company.

I'm sort of drifting that way myself with my java-coded language that unifies Linux-based operations for i Series OS and 
z/VM.


--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

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

Re: Any clever way to defeat the C compiler's options precedence?


Paul Gilmartin wrote:

An extreme example:
 https://en.wikipedia.org/wiki/%42%72%61%69%6e%66%75%63%6b

(I don't use it; just stumbled on and amused by.)


A classic!

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

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

Re: Any clever way to defeat the C compiler's options precedence?

Robert A. Rosenberg wrote:

Will using this use of ifndef solve the issue that if a compiler option is set at launch time due to being coded in
the JCL or via a DD it can/will override the pragma supplied setting?

There are so many "things" in C/C++ compilation I have to look back in this thread and see what specifically you're up
against.

If you posted the exact problem.

Let me go to the archives and get back to you.

The issue that was raised is that there is apparently no way to override the global settings via a pragma in the
source code of a module being compiled. Unless this happens all the ifndef does is supply options to be used when
compiling under Z/OS SO LONG AS THE COMPILER does not override the requested option due to a Global Default override.

There's "compiler options" like what kind of error output goes where, and there's "compiler options" like how the C/++
preprocessor interprets stuff and they overlap.

Off to check on what you reported as your specific problem.

If you didn't previously post in detail, please repost with detailed description of JCL-set compiler option, any
pragmas, what you want, etc.

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

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

Re: Any clever way to defeat the C compiler's options precedence?

By "compiler options" I mean what the compiler documentation calls "compiler
options." See Chapter 4 of the User's Guide for a description of compiler
options.

The problem is that there is apparently no way to specify ARCH(9) at a
"global/default" sort of level and then override it at a particular module
level.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jack J. Woehr
Sent: Thursday, November 26, 2015 9:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Any clever way to defeat the C compiler's options precedence?

Robert A. Rosenberg wrote:
>
> Will using this use of ifndef solve the issue that if a compiler 
> option is set at launch time due to being coded in the JCL or via a DD it
can/will override the pragma supplied setting?

There are so many "things" in C/C++ compilation I have to look back in this
thread and see what specifically you're up against.

If you posted the exact problem.

Let me go to the archives and get back to you.

> The issue that was raised is that there is apparently no way to 
> override the global settings via a pragma in the source code of a 
> module being compiled. Unless this happens all the ifndef does is supply
options to be used when compiling under Z/OS SO LONG AS THE COMPILER does
not override the requested option due to a Global Default override.

There's "compiler options" like what kind of error output goes where, and
there's "compiler options" like how the C/++ preprocessor interprets stuff
and they overlap.

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

Re: Any clever way to defeat the C compiler's options precedence?


Jack J. Woehr wrote:

If you didn't previously post in detail,

Ok, what option is being set by the JCL and what do you want to do instead on 
one file?

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

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

Re: Any clever way to defeat the C compiler's options precedence?


Charles Mills wrote:

By "compiler options" I mean what the compiler documentation calls "compiler
options." See Chapter 4 of the User's Guide for a description of compiler
options.

The problem is that there is apparently no way to specify ARCH(9) at a
"global/default" sort of level and then override it at a particular module
level.


I'll bet you you're right. Off to RTFM ...

Okay, you're right. Can you just omit the problem file from the JCL, compile it separately, put it in the right dataset 
of output objects,

and then run the JCL and link it with the others?

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

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

Re: Any clever way to defeat the C compiler's options precedence?

On 26 November 2015 at 13:28, Jack J. Woehr  wrote:
> Okay, you're right. Can you just omit the problem file from the JCL, compile
> it separately, put it in the right dataset of output objects,
> and then run the JCL and link it with the others?

For some value of "just"...

Tony H.

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

RES: WLM and Dispatching Priority

2015-11-26 Thread ITURIEL DO NASCIMENTO NETO

You were talking about your monitors, that were using an importance 1 SC
instead of SYSSTC. And what about RMF ? RMF must be SYSSTC too.

Atenciosamente / Regards / Saludos

BANCO BRADESCO S.A.
4250 / DPCD Engenharia de Software
Sistemas Operacionais Mainframes
Ituriel do Nascimento Neto
Tel: +55 11 3684-2177 R: 42177 3-1404
Fax: +55 11 3684-4427

Banco Bradesco.
Patrocinador oficial dos Jogos Olímpicos e Paralímpicos Rio 2016.

-Mensagem original-
De: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Em nome de 
phil yogendran
Enviada em: quinta-feira, 26 de novembro de 2015 14:53
Para: IBM-MAIN@LISTSERV.UA.EDU
Assunto: Re: WLM and Dispatching Priority

Thank you all for your response and advise. My only reservation is that
SYSVIEW, at times, tends to be heavy-footed and causes the system to
'pause'. This is only because of the data we capture at periodic intervals.
Anyway, that's for me to investigate further and fix.

Thanks, again,

On Thu, Nov 26, 2015 at 11:16 AM, Ted MacNEIL  wrote:

> Put monitors in SYSSTC.
> This gives them the second highest DP in the system. You cannot completely
> control the DP in Service Classes.
>
> -
> -teD
> -
>   Original Message
> From: phil yogendran
> Sent: Thursday, November 26, 2015 11:02
> To: IBM-MAIN@LISTSERV.UA.EDU
> Reply To: IBM Mainframe Discussion List
> Subject: WLM and Dispatching Priority
>
> Hello All,
>
> I need some assistance with being able to get a proper DP assigned to a set
> of tasks. The problem is this;
>
> I have 2 tasks, SYSVIEW and CICSLOGR and many CICS tasks. CICSLOGR is a
> subtask attached by SYSVIEW.
>
> In WLM, SYSVIEW is set to a service class of 'monitor' with an importance
> of 1 and velocity of 75.
>
> The CICS regions are set to a service class of 'CICSA' which has an
> importance of 1 and velocity goal of 65.
>
> However, what I see is that the CICS regions run at a DP of F6 and SYSVIEW
> is at F4.
>
> How can I make sure that SYSVIEW and CICSLOGR run at a higher DP? I'm on
> z/OS 1.13 and in a sysplex environment.
>
> Looking forward to your response. Thanks.
>
> --
> 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

AVISO LEGAL ...Esta mensagem é destinada exclusivamente para a(s) pessoa(s) 
a quem é dirigida, podendo conter informação confidencial e/ou legalmente 
privilegiada. Se você não for destinatário desta mensagem, desde já fica 
notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de 
qualquer forma, utilizar a informação contida nesta mensagem, por ser ilegal. 
Caso você tenha recebido esta mensagem por engano, pedimos que nos retorne este 
E-Mail, promovendo, desde logo, a eliminação do seu conteúdo em sua base de 
dados, registros ou sistema de controle. Fica desprovida de eficácia e validade 
a mensagem que contiver vínculos obrigacionais, expedida por quem não detenha 
poderes de representação. 
LEGAL ADVICE...This message is exclusively destined for the people to whom 
it is directed, and it can bear private and/or legally exceptional information. 
If you are not addressee of this message, since now you are advised to not 
release, copy, distribute, check or, otherwise, use the information contained 
in this message, because it is illegal. If you received this message by 
mistake, we ask you to return this email, making possible, as soon as possible, 
the elimination of its contents of your database, registrations or controls 
system. The message that bears any mandatory links, issued by someone who has 
no representation powers, shall be null or void.

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

Re: Any clever way to defeat the C compiler's options precedence?


Tony Harminc wrote:

For some value of "just"...

Ha! Aint' that the truth in Big Iron World! I spent two weeks learning how to get a second virtual ethernet link working 
in z/VM.


Simple in Unix:

1. Comment out file name from list in Makefile
2. Run the compile target without running the link target
3. Compile problem file by hand
4. Uncomment file name in list in Makefile
5. Run link target.

Surely it's essentially the same thing.

The JCL must compile before linking.
JCL has a comment character
etc ..

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan


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

Re: Any clever way to defeat the C compiler's options precedence?

ARCH(9) / ARCH(5)

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jack J. Woehr
Sent: Thursday, November 26, 2015 10:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Any clever way to defeat the C compiler's options precedence?

Jack J. Woehr wrote:
> If you didn't previously post in detail,
Ok, what option is being set by the JCL and what do you want to do instead
on one file?

-- 
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the
universe www.softwoehr.com # with a fine understanding of human fallibility.
- Carl Sagan

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

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

Re: Any clever way to defeat the C compiler's options precedence?

Right. Exactly. This is not the only requirement. The problem space is not 
"demonstrate how one might ..."

I have other build issues or requirements or gotchas or whatever (habits?) that 
also come into consideration. I have multiple processes in place. And my hope 
had been that this was not a "rearrange my world" project but a simple "compile 
most of the product ARCH(9). Compile two modules ARCH(5) and use them (only) to 
catch a customer environment that is downlevel from the build target."

For your specific "omit the problem file from the JCL" suggestion there are no 
files in the JCL. //SYSIN specifies a UNIX folder and the compiler grabs all of 
the .C or .c files.

Yes, I could put them in a separate folder and have two compile steps. That 
starts to get off into the "rearrange my world" area. I also have a TSO command 
that compiles a single file from the "current" (and that is a whole requirement 
or gotcha or whatever of its own ...) code set folder. That would have to get 
improved somehow.

I guess my point is not that the problem as stated is impossible to solve but 
rather "there's got to be a better way."

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Thursday, November 26, 2015 10:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Any clever way to defeat the C compiler's options precedence?

On 26 November 2015 at 13:28, Jack J. Woehr  wrote:
> Okay, you're right. Can you just omit the problem file from the JCL, 
> compile it separately, put it in the right dataset of output objects, 
> and then run the JCL and link it with the others?

For some value of "just"...

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

Re: WLM and Dispatching Priority

2015-11-26 Thread phil yogendran

True,  RMF is SYSSTC. Clearly there's more faith and confidence here.

On Thu, Nov 26, 2015 at 1:39 PM, ITURIEL DO NASCIMENTO NETO <
4254.itur...@bradesco.com.br> wrote:

> You were talking about your monitors, that were using an importance 1 SC
> instead of SYSSTC. And what about RMF ? RMF must be SYSSTC too.
>
> Atenciosamente / Regards / Saludos
>
> BANCO BRADESCO S.A.
> 4250 / DPCD Engenharia de Software
> Sistemas Operacionais Mainframes
> Ituriel do Nascimento Neto
> Tel: +55 11 3684-2177 R: 42177 3-1404
> Fax: +55 11 3684-4427
>
>
>
>
> Banco Bradesco.
> Patrocinador oficial dos Jogos Olímpicos e Paralímpicos Rio 2016.
>
> -Mensagem original-
> De: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Em
> nome de phil yogendran
> Enviada em: quinta-feira, 26 de novembro de 2015 14:53
> Para: IBM-MAIN@LISTSERV.UA.EDU
> Assunto: Re: WLM and Dispatching Priority
>
> Thank you all for your response and advise. My only reservation is that
> SYSVIEW, at times, tends to be heavy-footed and causes the system to
> 'pause'. This is only because of the data we capture at periodic intervals.
> Anyway, that's for me to investigate further and fix.
>
> Thanks, again,
>
>
> On Thu, Nov 26, 2015 at 11:16 AM, Ted MacNEIL  wrote:
>
> > Put monitors in SYSSTC.
> > This gives them the second highest DP in the system. You cannot
> completely
> > control the DP in Service Classes.
> >
> > -
> > -teD
> > -
> >   Original Message
> > From: phil yogendran
> > Sent: Thursday, November 26, 2015 11:02
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Reply To: IBM Mainframe Discussion List
> > Subject: WLM and Dispatching Priority
> >
> > Hello All,
> >
> > I need some assistance with being able to get a proper DP assigned to a
> set
> > of tasks. The problem is this;
> >
> > I have 2 tasks, SYSVIEW and CICSLOGR and many CICS tasks. CICSLOGR is a
> > subtask attached by SYSVIEW.
> >
> > In WLM, SYSVIEW is set to a service class of 'monitor' with an importance
> > of 1 and velocity of 75.
> >
> > The CICS regions are set to a service class of 'CICSA' which has an
> > importance of 1 and velocity goal of 65.
> >
> > However, what I see is that the CICS regions run at a DP of F6 and
> SYSVIEW
> > is at F4.
> >
> > How can I make sure that SYSVIEW and CICSLOGR run at a higher DP? I'm on
> > z/OS 1.13 and in a sysplex environment.
> >
> > Looking forward to your response. Thanks.
> >
> > --
> > 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
>
> AVISO LEGAL ...Esta mensagem é destinada exclusivamente para a(s)
> pessoa(s) a quem é dirigida, podendo conter informação confidencial e/ou
> legalmente privilegiada. Se você não for destinatário desta mensagem, desde
> já fica notificado de abster-se a divulgar, copiar, distribuir, examinar
> ou, de qualquer forma, utilizar a informação contida nesta mensagem, por
> ser ilegal. Caso você tenha recebido esta mensagem por engano, pedimos que
> nos retorne este E-Mail, promovendo, desde logo, a eliminação do seu
> conteúdo em sua base de dados, registros ou sistema de controle. Fica
> desprovida de eficácia e validade a mensagem que contiver vínculos
> obrigacionais, expedida por quem não detenha poderes de representação.
> LEGAL ADVICE...This message is exclusively destined for the people to
> whom it is directed, and it can bear private and/or legally exceptional
> information. If you are not addressee of this message, since now you are
> advised to not release, copy, distribute, check or, otherwise, use the
> information contained in this message, because it is illegal. If you
> received this message by mistake, we ask you to return this email, making
> possible, as soon as possible, the elimination of its contents of your
> database, registrations or controls system. The message that bears any
> mandatory links, issued by someone who has no representation powers, shall
> be null or void.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Any clever way to defeat the C compiler's options precedence?