Accurate listing of IDRDATA to TRANSLATOR ID's

[Tom Ross]

>Does IBM maintain a list of Translator ID's that corollate to the language
>processor/compiler product that produced CSECTS?  Purpose is to identify=2
>
>What version of a compiler produced the CSECT.  The goal is to identify
>COBOL VS modules when reviewing an AMBLIST LISTIDR output. =20

All COBOL compilers AFTER OS/VS COBOL put out IDR data in the object program.
OS/VS COBOL does NOT put out IDR, you have to programmatically analyze to
figure out what the compiler was.  COBANAL by Roland Schiradin does this,
as does IBM Load Module Analyzer, IBM File Manager, and Compuware File-AID.
For VS COBOL II and later you can use IDR data.










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: Low softcapping on high capacity CEC

[Dave Barry]

We had the same issue with SAS driving up the R4HA.  We put the work in a 
service class with a resource group cap.  The type 72 records gave us a 
reasonable target service units/second for starters, and we reduced the cap 
incrementally until we were satisfied.  The jobs ran longer afterward, but all 
finished before their deadline.

Absolute capping sounds like an easy way out, but it wasn't designed with your 
purpose in mind.  It had to do with Linux partitions dynamically starting and 
stopping occasionally as a means of responding to changes in resource demand.  
You probably wouldn't do that with z/OS LPARs, which, once activated, usually 
remain active for the long haul.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gibney, Dave
Sent: Wednesday, March 31, 2021 12:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Low softcapping on high capacity CEC

CAUTION! This email originated outside of the organization. Please do not open 
attachments or click links from an unknown or suspicious origin.

==
My LPAR group, with my 4 LPARs is set with a cap of 12 MSU for z/OS charging 
purposes. We pay for 12 MSU. ABSNSUCapping would, as I read it, make permanent 
the condition I am trying to avoid, that is always being capped at 12.
Even if I could reliably identify the jobs, and online activity that are my 
high CPU spikes, AFAIK, unless I am in a capped state, the CP resource, being 
available, will be used. WLM doesn't care about anything when utilization is 
less than capacity.

The problem I'm addressing is to avoid becoming capped due to short spikes up 
to the 151 capacity of the CPs. It doesn’t take very long for these spikes to 
bring my 4/hr over 12. But, if I could have an limit on the size of these 
spikes, say 24 MSU, I could still get the work done, and not spend long periods 
actually capped at 12.

What is the purpose of the HMC setting, Absolute Capping for CPs that first 
gave me the idea that this was possible? What is the meaning of a setting from 
0.01 to 255.00 here?

> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Scott Chapman
> Sent: Wednesday, March 31, 2021 4:16 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Low softcapping on high capacity CEC
> 
> As was mentioned, ABSMSUCapping may be useful in that you can limit 
> the entire group to a specific number of MSUs. I.E. if you defined the 
> group of 4 LPARs in a capacity group at 24 MSUs (or whatever) and 
> enabled ABSMSUCapping on all of them, all 4 LPARs would be capped (in 
> total) at that
> 24 MSUs.
> 
> The Absolute CP Capping can work too, but you can't set the limit 
> across the 4 LPARs, so they can't borrow capacity from each other. 
> I.E. if you want the limit to be a combined 24 MSUs but you want each 
> to be able to consume up to 24 MSUs, then a group cap with Absolute MSU 
> Capping is the way to go.
> 
> If you want to limit individual workloads within the LPARs, then WLM 
> resource groups can do that for you. That's at a service class by 
> service class basis and most often are specified by SU/s (not the same 
> as MSUs). So assign the SAS work to a specific SC (BATHOGS?) and make 
> sure that SC has a resource group that limits how much CPU the work can 
> consume.
> 
> Scott Chapman
> 
> --
> 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: [External] Re: No file permissions or super user authority for executing a shell script

[Radoslaw Skorupka]

W dniu 02.04.2021 o 15:26, Pommier, Rex pisze:


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: Friday, April 2, 2021 5:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: No file permissions or super user authority for 
executing a shell script

W dniu 01.04.2021 o 22:01, Robert Hahne pisze:

Greetings ,

Is there a way a user can be allowed to execute a unix shell script in batch 
without changing the file permission bits or granting SUPERUSER authority ?

Currently the file has got 700 and the user is not the owner of the
file . Any suggestions would be great



Short answer: NO.

Longer answer: No. :-) Even superuser cannot execute script which is not marked 
as x (executable). Of course superuser can change it using chmod command.
However this is a script - some text file. Even regular user can run it
- assuming he have r right he can copy the script to other file and chmod the 
file to x. Of course it doesn't mean the user will have intended authorities 
and sometimes script have relative paths in the code, so it won't work 
correctly without modifications.

In your case the user has 0 (---) authorities - than means zero. Nothing.
Fine print: the above is NOT TRUE :-)
We don't know all the true, because we don't know the path and authorities. 700 
is enough to delete the file assuming the user has WRITE to the directory. He 
can't read it, he can't execute it, he can't write it, bu he can delete it. It 
is more than nothing.

--
Radoslaw Skorupka
(looking for new job)
Lodz, Poland

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


I'm asking this from a "I don't know" standpoint because I've never used them.  Doesn't 
RACF have extended ACLs that could possibly come into play here?  As in using RACF to grant read or 
execute authority to the script?  If so, how would that be shown?  I would assume that the 
"normal" Unix security would remain at 700 but the extended ACL would allow the access 
and show up elsewhere?


Rex,
You are perfectly right, my long answer should be longer. ACL can be 
used here. In fact user-group-other paradigm was enhanced to use named 
users or groups and access lists similarly to DATASET profiles. However 
IMHO it is rarely used. How to recognize "hidden ACL" existence?  ls -l 
file and you will see something like rwx -w- r-x + the + sing is the 
clue. Command getfacl should display details.

Note: existence of ACL is not enough. FSSEC class must be also active.

BTW: in case of ACL the information "700" is ambiguous. I can be 
understood as "rwx-- with no +" or just like "we don't know what 
about ACL". Or just "ACL? Oh, I forgot...".  ;-)


--
Radoslaw Skorupka
(looking for new job)
Lodz, Poland

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

Re: [External] Re: No file permissions or super user authority for executing a shell script

[Pommier, Rex]

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: Friday, April 2, 2021 5:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: No file permissions or super user authority for 
executing a shell script

W dniu 01.04.2021 o 22:01, Robert Hahne pisze:
> Greetings ,
>
> Is there a way a user can be allowed to execute a unix shell script in batch 
> without changing the file permission bits or granting SUPERUSER authority ?
>
> Currently the file has got 700 and the user is not the owner of the 
> file . Any suggestions would be great
>
>

Short answer: NO.

Longer answer: No. :-) Even superuser cannot execute script which is not marked 
as x (executable). Of course superuser can change it using chmod command.
However this is a script - some text file. Even regular user can run it
- assuming he have r right he can copy the script to other file and chmod the 
file to x. Of course it doesn't mean the user will have intended authorities 
and sometimes script have relative paths in the code, so it won't work 
correctly without modifications.

In your case the user has 0 (---) authorities - than means zero. Nothing.
Fine print: the above is NOT TRUE :-)
We don't know all the true, because we don't know the path and authorities. 700 
is enough to delete the file assuming the user has WRITE to the directory. He 
can't read it, he can't execute it, he can't write it, bu he can delete it. It 
is more than nothing.

--
Radoslaw Skorupka
(looking for new job)
Lodz, Poland

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


I'm asking this from a "I don't know" standpoint because I've never used them.  
Doesn't RACF have extended ACLs that could possibly come into play here?  As in 
using RACF to grant read or execute authority to the script?  If so, how would 
that be shown?  I would assume that the "normal" Unix security would remain at 
700 but the extended ACL would allow the access and show up elsewhere?

Rex

The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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

Re: No file permissions or super user authority for executing a shell script

[Radoslaw Skorupka]

W dniu 01.04.2021 o 22:01, Robert Hahne pisze:

Greetings ,

Is there a way a user can be allowed to execute a unix shell script in batch 
without changing the file permission bits or granting SUPERUSER authority ?

Currently the file has got 700 and the user is not the owner of the file . Any 
suggestions would be great




Short answer: NO.

Longer answer: No. :-) Even superuser cannot execute script which is not 
marked as x (executable). Of course superuser can change it using chmod 
command.
However this is a script - some text file. Even regular user can run it 
- assuming he have r right he can copy the script to other file and 
chmod the file to x. Of course it doesn't mean the user will have 
intended authorities and sometimes script have relative paths in the 
code, so it won't work correctly without modifications.


In your case the user has 0 (---) authorities - than means zero. Nothing.
Fine print: the above is NOT TRUE :-)
We don't know all the true, because we don't know the path and 
authorities. 700 is enough to delete the file assuming the user has 
WRITE to the directory. He can't read it, he can't execute it, he can't 
write it, bu he can delete it. It is more than nothing.


--
Radoslaw Skorupka
(looking for new job)
Lodz, Poland

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

Re: Accurate listing of IDRDATA to TRANSLATOR ID's

[Kenneth J. Kripke]

Thank you to Mike Schwab and Peter Farley for your information. 

 

Sincerely Yours; 

 

Kenneth J. Kripke 

k.kri...@comcast.net  


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