AW: Re: permissions to /bin/sh

[Peter Hunkeler]

1755, the shell has the sticky bit set by IBM's installation default.


-- 
Peter Hunkeler


 Von: ITschak Mugzach  An:   
IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: permissions to /bin/sh Datum: 21.08.17, 
11:34

 
0755 or less 
 
בתאריך 21 באוג 2017 11:12,‏ "R.S."  כתב: 
 
> What is default (suggested, typical) permission to /bin/sh ? 
> Of course I mean z/OS UNIX (2.2 if it makes a difference) 
> Is it rwxr-xr-t ? 
> 
> -- 
> Radoslaw Skorupka 
> Lodz, Poland 
> 
> 
> 
> 
> == 
> 
> 
>-- 
> Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
> przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być 
> jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś 
> adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej 
> przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, 
> rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie 
> zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, 
> prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale 
> usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub 
> zapisane na dysku. 
> 
> This e-mail may contain legally privileged information of the Bank and is 
> intended solely for business use of the addressee. This e-mail may only be 
> received by the addressee and may not be disclosed to any third parties. If 
> you are not the intended addressee of this e-mail or the employee 
> authorized to forward it to the addressee, be advised that any 
> dissemination, copying, distribution or any other similar activity is 
> legally prohibited and may be punishable. If you received this e-mail by 
> mistake please advise the sender immediately by using the reply facility in 
> your e-mail software and delete permanently this e-mail including any 
> copies of it either printed or saved to hard drive. 
> 
> mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
> www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy 
> XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru 
> przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 
> 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 
> 168.955.696 złotych. 
> 
> -- 
> 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: Competent managers (was Re: OT-retirement)

[Edward Gould]

> On Aug 21, 2017, at 8:12 PM, John McKown  wrote:
>> —SNIP
> ​How times have changed. I only turned in an expense report one - 2 weeks
> in a class in St. Paul. I filled out the report based on my receipts. My
> boss rejected it because IT WAS TOO LOW! I guess it made everybody else
> look bad. He instructed me to fill it out with numbers near those which
> were "recommend"​ on the form.
> 
—SNIP———
I won’t go into the details to much. The shift managers in the DC were always 
taking people out for dinners and then they would find other managers to take 
out for dinner. The expense accounts were (I heard) really high. A manger 
friend of mine was taken out for dinner and they ordered a $600 bottle of wine. 
He was sure that he was going to get called on the carpet for that, but no, it 
was paid in full. I had a few favorite dinner spots and the one place for 8 
people the check was $500 . One time I was out in Boston (I don’t remember if 
it was GUIDE or SHARE) the group I was with went out for dinner and someone 
ordered a bottle for $125 and he thought everyone would chip in. To make a long 
story short he drank the bottle himself.

On the other extreme, I was going to IBM classes 2-3 times a month and not in 
Chicago but DC and other nice places(LA, NYC, etc.). The hotel rate in DC was a 
little bit higher than the company liked. I ended up buying my own meals and 
not expensing them and I got called on the carpet for that. I had to redo the 
expense report and I was guessing (but making it reasonable for DC) and I think 
I came out ahead by 1.00. I was scolded for not spending money!

Then I went to work for another company and was asked to give a class on DFHSM 
to the HQ people in Dallas (IIRC). The company said they would take care of 
everything. SO I was flabbergasted, when the limo showed up to take me to the 
air port and it had a swimming pool in the back of the limo. I certainly didn’t 
need it especially a trip the the air port.

Then there was another company that was so cheap, I ended up arguing with the 
VP over $24 a month for the DFP option for SMS. Every time I saw him he would 
really give me a hard time. 
I got a little irratated and wrote up a 5 page executive over view of SMS and 
in a meeting with him I gave hime the overview and after he read it he shut up 
and OK’d the $24 a month additional charge, but it took a solid month of 
arguing. 

Ed


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

Re: HSM Query command

[David Crayford]

On 22/08/2017 3:55 AM, Wayne Bickerdike wrote:

Use the OUTTRAP command in a batch REXX program to direct the output to
stem variable and print the stem contents.


IIRC, that won't work. DFHSM doesn't use PUTLINE for terminal output.



On Tue, Aug 22, 2017 at 5:35 AM, Jeseritz, Tommy W 
wrote:


How do I write the output of the 'hsend q cds' to a dataset for our metric
reporting.

Query does not have the option to do a ODS('output.dsn.name') so was
wondering for our reporting, we want to automate this in a batch job.
If anyone has any idea's , please let me know.  I have tried sdsf batch
but have not been successful.

--
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: HSM Query command

[Ron hesketh]

HI ,
I use the following rexx exec ,  ZCOMMAND would be   'F HSM,Q CDS'
It uses Gilbert Stflours excellent STEMVIEW to display the output, that 
could easily be replaced
with an execio. 

Regards,
Ron

/* rexx */ 
 
parse upper arg ZCOMMAND 
 
IsfRC = isfcalls( "ON" ) 
if IsfRC <> 0 
then do 
   say "RC" IsfRC "returned from isfcalls( ON )" 
   exit IsfRC 
end 
ISFCONS = '' 
ISFDELAY = 5 
address SDSF "ISFEXEC '/"strip(ZCOMMAND,B,'"')||"' " 
if RC <> 0 then do 
   say "RC" RC "returned from ZCOMMAND " 
   call DisplayMessages 
end 
 
/* Display the user log associated with the action */ 
 
do i = 1 to isfulog.0 
   cmd.i =  substr(isfulog.i,43,80) 
end 
 
XTITLE = ZCOMMAND 
Call STEMVIEW  'BROWSE','cmd.',,,'Command output','DBPIRLMA' 
 
/* Unload the SDSF environment */ 
 
call isfcalls "OFF" 
 
exit 0 

/* Display the messages associated with the action */ 
 
DisplayMessages: 
 say "isfmsg: '"isfmsg"'" 
 say isfmsg2.0 "long messages in the isfmsg2 stem:" 
 do i = 1 to isfmsg2.0 
say " '"isfmsg2.i"'" 
 end 
return  




From:   Brian Fraser 
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   22/08/2017 11:20 AM
Subject:Re: HSM Query command
Sent by:IBM Mainframe Discussion List 



OUTDATASET(xxx..) is not a valid parameter to HSEND QUERY.

Even in  a TSO in batch job, the output will be returned to your TSO 
screen
and not sent to the SYSTSPRT DD.

I guess it just uses TPUT.

Regards
Brian

On Tue, Aug 22, 2017 at 4:00 AM, Carmen Vitullo  
wrote:

> something like
>
> //STEP2 EXEC PGM=IKJEFT01,TIME=2,REGION=4096K
> //SYSTSPRT DD SYSOUT=*
> //VTOCOUT DD SYSOUT=*
> //MSGPRINT DD SYSOUT=*
> //SYSPRINT DD SYSOUT=*
> //SYSTSIN DD *
> HSEND LIST TTOC OUTDATASET(xxx.HSM.TTOC.ML2LIST) SELECT(ML2)
> - Original Message -
>
> From: "Tommy W Jeseritz" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Monday, August 21, 2017 2:35:33 PM
> Subject: HSM Query command
>
> How do I write the output of the 'hsend q cds' to a dataset for our 
metric
> reporting.
>
> Query does not have the option to do a ODS('output.dsn.name') so was
> wondering for our reporting, we want to automate this in a batch job.
> If anyone has any idea's , please let me know. I have tried sdsf batch 
but
> have not been successful.
>
> --
> 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

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

___

This email has been scanned by the Bankwest Email Security System.
___


___
Unencrypted electronic mail is not secure and may not be authentic.
If you have any doubts as to the contents please telephone to confirm.

This electronic transmission including any attachments is intended only
for those to whom it is addressed. It may contain copyright material or
information that is confidential, privileged or exempt from disclosure by law.
Any claim to privilege is not waived or lost by reason of mistaken transmission
of this information. If you are not the intended recipient you must not
distribute or copy this transmission and should please notify the sender.
Your costs for doing this will be reimbursed by the sender.

We do not accept liability in connection with computer virus, data corruption,
delay, interruption, unauthorised access or unauthorised amendment.
___


__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

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

Re: HSM Query command

[Brian Fraser]

OUTDATASET(xxx..) is not a valid parameter to HSEND QUERY.

Even in  a TSO in batch job, the output will be returned to your TSO screen
and not sent to the SYSTSPRT DD.

I guess it just uses TPUT.

Regards
Brian

On Tue, Aug 22, 2017 at 4:00 AM, Carmen Vitullo  wrote:

> something like
>
> //STEP2 EXEC PGM=IKJEFT01,TIME=2,REGION=4096K
> //SYSTSPRT DD SYSOUT=*
> //VTOCOUT DD SYSOUT=*
> //MSGPRINT DD SYSOUT=*
> //SYSPRINT DD SYSOUT=*
> //SYSTSIN DD *
> HSEND LIST TTOC OUTDATASET(xxx.HSM.TTOC.ML2LIST) SELECT(ML2)
> - Original Message -
>
> From: "Tommy W Jeseritz" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Monday, August 21, 2017 2:35:33 PM
> Subject: HSM Query command
>
> How do I write the output of the 'hsend q cds' to a dataset for our metric
> reporting.
>
> Query does not have the option to do a ODS('output.dsn.name') so was
> wondering for our reporting, we want to automate this in a batch job.
> If anyone has any idea's , please let me know. I have tried sdsf batch but
> have not been successful.
>
> --
> 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: Competent managers (was Re: OT-retirement)

[Edward Gould]

> On Aug 21, 2017, at 7:36 PM, Phil Smith III  wrote:
> 
> I love it when companies nickel-and-dime on expenses. Do they really think
> that folks aren't gonna get it back some other way? A friend was once
> challenged (by Finance, not his manager) over a dime for a pay toilet. His
> manager came to him and said "Just bury it somewhere else"-he realized it
> was stupid, but not a winnable fight. Probably a firing offense for both,
> but c'mon…
A *LONG* time ago in the 1980’s I had set up to go to Guide in CA, after Guide 
I flew to Miami and then an Island I goto.
What I used to do was always fly first class. The company only paid for coach, 
which was fine with me. I expensed the trip flying coach. Then the auditors got 
involved. The company was billed for coach both ways and when it came time I 
went first class. I went through the costs to the auditor and he grumbled. I 
asked him what was the matter? He said the company lost .25 cents in the whole 
transaction. I looked at him and dug in my pocket a 25 cent piece and handed it 
to him. I told him as I got up to leave I am not going to waste your time and 
my time on 25 cents. I thought he was going to ballistic on me. I closed the 
door and I could hear him swear up a blue streak. From then on my travel agent 
made the reservations on all my flights. I always reimbursed the company for 
the difference, I never heard from the auditor again. My boss cubed never did 
either.

Ed

> 
> 
> 
> I may have told this story, but I was at a customer site in Chicago about 15
> years ago. At lunchtime, it was clear that as The Vendor, we were buying.
> That was fine with us until the customer headed down a street that dead-ends
> at the river, and we realized that the only sign we could see was for a
> strip club. My cow-orker and I were sharing glances and muttering "YOU get
> to expense this one".
> 
> 
> 
> Fortunately, just short of the club, the customer veered into an
> almost-invisible hole-in-the-wall deli, so we didn't have to try to fight
> that battle!
> 
> 
> --
> 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: Competent managers (was Re: OT-retirement)

[John McKown]

On Mon, Aug 21, 2017 at 7:36 PM, Phil Smith III  wrote:

> I love it when companies nickel-and-dime on expenses. Do they really think
> that folks aren't gonna get it back some other way? A friend was once
> challenged (by Finance, not his manager) over a dime for a pay toilet. His
> manager came to him and said "Just bury it somewhere else"-he realized it
> was stupid, but not a winnable fight. Probably a firing offense for both,
> but c'mon...
>
> I may have told this story, but I was at a customer site in Chicago about
> 15
> years ago. At lunchtime, it was clear that as The Vendor, we were buying.
> That was fine with us until the customer headed down a street that
> dead-ends
> at the river, and we realized that the only sign we could see was for a
> strip club. My cow-orker and I were sharing glances and muttering "YOU get
> to expense this one".
>
>
>
> Fortunately, just short of the club, the customer veered into an
> almost-invisible hole-in-the-wall deli, so we didn't have to try to fight
> that battle!
>
>
​How times have changed. I only turned in an expense report one - 2 weeks
in a class in St. Paul. I filled out the report based on my receipts. My
boss rejected it because IT WAS TOO LOW! I guess it made everybody else
look bad. He instructed me to fill it out with numbers near those which
were "recommend"​ on the form.

-- 
If you look around the poker table & don't see an obvious sucker, it's you.

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: Competent managers (was Re: OT-retirement)

[Phil Smith III]

I love it when companies nickel-and-dime on expenses. Do they really think
that folks aren't gonna get it back some other way? A friend was once
challenged (by Finance, not his manager) over a dime for a pay toilet. His
manager came to him and said "Just bury it somewhere else"-he realized it
was stupid, but not a winnable fight. Probably a firing offense for both,
but c'mon...

 

I may have told this story, but I was at a customer site in Chicago about 15
years ago. At lunchtime, it was clear that as The Vendor, we were buying.
That was fine with us until the customer headed down a street that dead-ends
at the river, and we realized that the only sign we could see was for a
strip club. My cow-orker and I were sharing glances and muttering "YOU get
to expense this one".

 

Fortunately, just short of the club, the customer veered into an
almost-invisible hole-in-the-wall deli, so we didn't have to try to fight
that battle!


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

Re: z14 and zBX

[Phil Smith III]

I believe zBX suffered from being too little, too late - if it had been
released a decade earlier, it might have been a killer. It was also a fairly
narrow solution in terms of what was available to run on it.

 

I also understand that it was dependent on specific hardware (blades), which
IBM did not manufacture. I heard (unsubstantiated) that when those blades
ended production, IBM they bought up a ton as spares; when zBX then failed
to take off, they were stuck with the inventory, and thus had dug themselves
a big hole from which the zBX could not escape.

 

Perhaps one of the ex-IBMers who lurk here can confirm or deny-I'm sure no
current IBMer would want to risk his/her job thusly!

 

.phsiii (who is sad, because he loved the idea of the zBX!)


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

Re: [EXTERNAL] Re: Removing Catalog Entries for Datasets That Do Not Exist

[Tom Marchant]

On Mon, 21 Aug 2017 12:40:50 -0400, John Eells wrote:

>IEFBR14 won't allocate a migrated data set to delete it in a batch job
>when IEFBR14_DELMIGDS(NORECALL) is specified in an active ALLOCxx member
>of parmlib.  Instead, Allocation will call DFSMShsm to (effectively)
>HDELETE the data set.
>
>However, LEGACY is the default, and the data set will be allocated if
>LEGACY is in effect.

And that doesn't help the OP who no longer has DFSMShsm.

-- 
Tom Marchant

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

Re: HSM Query command

[Steve Beaver]

Do you know rexx?

Steve 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo
Sent: Monday, August 21, 2017 2:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: HSM Query command

If batch processing, I'd guess you're using IKJEFT01 , I think the output 
should write to SYSTSPRT ? 
Carmen 

- Original Message -

From: "Tommy W Jeseritz" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Monday, August 21, 2017 2:35:33 PM
Subject: HSM Query command 

How do I write the output of the 'hsend q cds' to a dataset for our metric 
reporting. 

Query does not have the option to do a ODS('output.dsn.name') so was wondering 
for our reporting, we want to automate this in a batch job. 
If anyone has any idea's , please let me know. I have tried sdsf batch but have 
not been successful. 

--
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: HSM Query command

[Carmen Vitullo]

something like 

//STEP2 EXEC PGM=IKJEFT01,TIME=2,REGION=4096K 
//SYSTSPRT DD SYSOUT=* 
//VTOCOUT DD SYSOUT=* 
//MSGPRINT DD SYSOUT=* 
//SYSPRINT DD SYSOUT=* 
//SYSTSIN DD * 
HSEND LIST TTOC OUTDATASET(xxx.HSM.TTOC.ML2LIST) SELECT(ML2) 
- Original Message -

From: "Tommy W Jeseritz"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Monday, August 21, 2017 2:35:33 PM 
Subject: HSM Query command 

How do I write the output of the 'hsend q cds' to a dataset for our metric 
reporting. 

Query does not have the option to do a ODS('output.dsn.name') so was wondering 
for our reporting, we want to automate this in a batch job. 
If anyone has any idea's , please let me know. I have tried sdsf batch but have 
not been successful. 

-- 
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: HSM Query command

[Carmen Vitullo]

If batch processing, I'd guess you're using IKJEFT01 , I think the output 
should write to SYSTSPRT ? 
Carmen 

- Original Message -

From: "Tommy W Jeseritz"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Monday, August 21, 2017 2:35:33 PM 
Subject: HSM Query command 

How do I write the output of the 'hsend q cds' to a dataset for our metric 
reporting. 

Query does not have the option to do a ODS('output.dsn.name') so was wondering 
for our reporting, we want to automate this in a batch job. 
If anyone has any idea's , please let me know. I have tried sdsf batch but have 
not been successful. 

-- 
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: HSM Query command

[Wayne Bickerdike]

Use the OUTTRAP command in a batch REXX program to direct the output to
stem variable and print the stem contents.

On Tue, Aug 22, 2017 at 5:35 AM, Jeseritz, Tommy W 
wrote:

> How do I write the output of the 'hsend q cds' to a dataset for our metric
> reporting.
>
> Query does not have the option to do a ODS('output.dsn.name') so was
> wondering for our reporting, we want to automate this in a batch job.
> If anyone has any idea's , please let me know.  I have tried sdsf batch
> but have not been successful.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
Wayne V. Bickerdike

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

HSM Query command

[Jeseritz, Tommy W]

How do I write the output of the 'hsend q cds' to a dataset for our metric 
reporting.

Query does not have the option to do a ODS('output.dsn.name') so was wondering 
for our reporting, we want to automate this in a batch job.
If anyone has any idea's , please let me know.  I have tried sdsf batch but 
have not been successful.

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

Re: z14 and zBX

[Parwez Hamid]

zBX was withdrawn from marketing on March 31, 2017. However, if you have a zBX 
Model 004 and the z14 has the Ensemble feature code 0025, the zBX can be in the 
same Ensemble as the z14. Remember, the zBX Model 004 is a standalone node and 
not 'tied' to a CPC e.g. z13/z13s/z14

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

Re: Cobol Help

[Clark Morris]

[Default] On 21 Aug 2017 05:39:28 -0700, in bit.listserv.ibm-main
idfli...@gmail.com (scott Ford) wrote:

>Guys/Gals:
>
>I need some help on a error I am not real familiar with in Cobol.
>I need write a generalized file-handler for files. Where do I start ?
>These are mostly QSAM files.. but i have to deal with Open/close/empty
>files, wrong length records...I have seen U1035 or similar errors and have
>done some reading in the manuals. Whats the easiest most effective method
>to handle file errors ?

What are the characteristics of this file handler and how is it to be
use?  If this is to be a utility for any file, COBOL may not be
appropriate.  You would at least have to have separate FDs for
non-VSAM versus VSAM and FB non-VSAM versus VB non-VSAM versus V
non-VSAM.  While you at least used to be able to have RECORD 0, BLOCK
0 for input I don't recall what the limitations were on how you
described the record.  There are some cute things that can be done
with COBOL but there are limits.  

Clark Morris
>
>Regards,
>Scott

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

Re: [EXTERNAL] Re: Removing Catalog Entries for Datasets That Do Not Exist

[John Eells]

IEFBR14 won't allocate a migrated data set to delete it in a batch job 
when IEFBR14_DELMIGDS(NORECALL) is specified in an active ALLOCxx member 
of parmlib.  Instead, Allocation will call DFSMShsm to (effectively) 
HDELETE the data set.


However, LEGACY is the default, and the data set will be allocated if 
LEGACY is in effect.


Allan Staller wrote:

The key is that if the dataset is allocated, HSM will be invoked.

DEL dsn NSCR does not allocate the dataset
IEFBR14 (optional) does not allocate the dataset. This was introduce w/zOS 2.1 
IIRC.
Iehprogm uncatlg will not allocate the dataset.




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

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

Re: Possible COBOL RFE to abend if any warnings occured

[Frank Swarbrick]

I am a (lead) developer, not a sysprog, so I wouldn't be forcing anything on 
anyone but my own group.  We (I) already made the decision that SSRANGE (with 
abend, as that's the only option at our release) would be the development 
compile default for COBOL V5.2.  I have not heard one complaint, and I know 
that many errors have been fixed.  (Perhaps everyone is just afraid of me.)  If 
you truly have no time to fix any of the issues that setting these checks 
reveals then you certainly have the option to override it at dev compile time.

My concern is that if the issue isn't forced then no one has incentive to ever 
turn it on.  I'm not aware of anyone in my shop who used SSRANGE regularly 
prior to my forcing the issue with V5.2.  I myself only used it occasionally, 
and usually when I was experiencing an issue which might be explained by a 
subscript out of range issue.

I also turned on ZONECHECK (NUMCHECK(ZON)) for a couple programs where COBOL 5 
was giving different results from COBOL 4 and I was shocked how many issues it 
found.  Some affecting business logic and some not.  This was my incentive to 
desire this option to always be set.  At this point we have not turned 
ZONECHECK on by default, but I am leaning toward doing it with the MSG option 
(in dev only!).  And there lies my desire for the option to force an abend at 
the end of the job if any warnings were issue.  Obviously with the option of 
turning it off if there is no time to resolve the revealed issues!

Frank


From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Saturday, August 19, 2017 8:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Possible COBOL RFE to abend if any warnings occured

Apologies, you certainly did not say anything about production.

I don't like the idea of someone else turning on all the checking options 
"automatically" when my program needs some development or maintenance.  I 
prefer to be the one to decide which (if any) of those options I may need to 
debug a problem or verify new code.  Besides, all a programmer has to do to 
thwart any automatic option setting is to use a PROCESS card to turn off the 
options they don't want to use.

>From the application programmer's point of view, your RFE if automatically 
>imposed would force me to keep changing code until all messages were handled 
>because my program always abends when it completes if I don't handle those 
>messages.

>From a managers point of view, why are you forcing my programmer to make 
>unplanned code changes that may introduce as many bugs as it purportedly 
>resolves?  I don't necessarily always subscribe to this philosophy, but it is 
>very common and managers do have some legitimate concerns about unplanned code 
>changes.

Unit testing is a bit more challenging when your program always abends while 
you are trying to test a logic change not associated with the code that 
generates checking messages.  Annoying too if you are running an interactive 
debugging session and the program abends at the end of processing.

I might see turning the existing checking options on automatically with the ABD 
sub-option in the full-volume regression testing stage to see if any bugs were 
missed during unit testing because those logic paths were not exercised, but 
not otherwise and probably not at all if I know there are unhandled checking 
messages being generated for this particular maintenance cycle.

I still agree with Jeffrey's response that since the compiler options already 
allow for the ABD sub-option you will probably get "already delivered" as an 
answer to your RFE.  Not a big help if you have "legitimate" code that triggers 
the option check which you don't want to change right away, but I would first 
question whether any such code is actually legitimate and not a problem.  If 
it's actually broken it ought to be fixed ASAP, though one's manager may or may 
not agree with that opinion (see above).

If the point is to generate all the possible sub-option MSG messages from a 
batch run or CICS transaction and then "tell the programmer" via abend to be 
sure to go look at the message output, I do not see any real usefulness in such 
an option.  If the programmer doesn't know enough to go look at the messages 
when they asked for them (or were told they must ask for them and check the 
results), then there isn't much you can do beyond telling them to RTFM and talk 
to their manager about it.

OTOH I think the idea of being able to "turn off" selected options around 
sections of code could be a useful idea.  Kind of like C/C++ "pragma(packed) 
and "pragma(reset)" around structure definitions but for executable code.  That 
has possibilities, but again you (and your manager) should probably first 
question whether such code sections are really "ignorable" for any given check.

HTH

Peter

-Original Message-
From: IBM Mainframe 

OT-retirement

[Nightwatch RenBand]

At 70 1/2 you are forced to start taking out the RMD from your regular IRA
(not Roth).  If you are still earning a high salary that may mean the
government gets a big chunk (and will most likely do something stupid with
it).  SO, I expect to drop to part time, travel, practice my musical
instruments and enjoy life.

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

Re: Competent managers (was Re: OT-retirement)

[Edward Gould]

> On Aug 21, 2017, at 8:08 AM, Tom Marchant 
> <000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
> 
> On Sat, 19 Aug 2017 15:15:05 +, scott Ford wrote:
> 
>> What about having PC managers who don't understand z/OS or z/OS ppl?
> 
> One of the best managers I ever had was a PC weenie who knew 
> nothing about mainframes. He knew how to manage. He never tried 
> to make technical decisions because he knew that his people were 
> qualified to do that. He believed that the most important thing for 
> him to do was to keep the corporate bureaucracy out of our way 
> so that we could do our jobs. He enabled us to do our best work.
> ——SNIP—
The worst manager I have ever had did nothing but sharpen his pencils all day.
He was also the most political manager I have ever seen, he knew (somehow) that 
manager x was in a bad mood stay away from him, or that manager b was a good 
mood and you night get him to OK something. He would never go against the 
corporate thinking. In general he would never make a decision (except to order 
new pencils). I was told that he had worked his way up the corporate ladder as 
he started out as a gas meter reader. He was the least technical manager I have 
ever seen. He was also the cheapest manager I ever worked for. I got called in 
on a Sunday morning because the system was down. He refused to pay my 
parking($14), I told him to take my phone out the on call list as I will never 
answer/come in on a call again. I would not work OT again either.
Ed

> Tom Marchant
> 
> --
> 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: Removing Catalog Entries for Datasets That Do Not Exist

[Allan Staller]

The key is that if the dataset is allocated, HSM will be invoked.

DEL dsn NSCR does not allocate the dataset
IEFBR14 (optional) does not allocate the dataset. This was introduce w/zOS 2.1 
IIRC.
Iehprogm uncatlg will not allocate the dataset. 

HTH,


It's been a few years since I worked in a shop with DFHSM but I do recall that 
IEHPROGM didn't require a recall but that may have been in the last decade (or 
millennium).

--

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Monday, August 21, 2017 9:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: Removing Catalog Entries for Datasets That Do Not 
Exist

Typically for these types of cases, the problem is not the utility being used, 
but that the Entry MIGRAT(1/2) will force a recall.

Only way to get around it is to use the ARCCATGP.  Then IDCAMS, IEHPROGM, etc. 
will work.  You can do the delete noscratch easily then.

So batch job with GROUP=ARCCATGP on the JOBCARD or at TSO LOGON enter ARCCATGP 
in the GROUP field of the logon panel.




::DISCLAIMER::


The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information 
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on 
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the 
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, 
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written 
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please 
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and 
other defects.




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

Re: [EXTERNAL] Re: Removing Catalog Entries for Datasets That Do Not Exist

[Dyck, Lionel B. (TRA)]

It's been a few years since I worked in a shop with DFHSM but I do recall that 
IEHPROGM didn't require a recall but that may have been in the last decade (or 
millennium).

--
Lionel B. Dyck 
Mainframe Systems Programmer - TRA

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Monday, August 21, 2017 9:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: Removing Catalog Entries for Datasets That Do Not 
Exist

Typically for these types of cases, the problem is not the utility being used, 
but that the Entry MIGRAT(1/2) will force a recall.

Only way to get around it is to use the ARCCATGP.  Then IDCAMS, IEHPROGM, etc. 
will work.  You can do the delete noscratch easily then.

So batch job with GROUP=ARCCATGP on the JOBCARD or at TSO LOGON enter ARCCATGP 
in the GROUP field of the logon panel.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Dyck, Lionel B. (TRA)
> Sent: Monday, August 21, 2017 7:50 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXTERNAL] Re: Removing Catalog Entries for Datasets That 
> Do Not Exist
> 
> Wouldn't IEHPROGM be easier?
> 
> 
> --
> 
> Lionel B. Dyck
> Mainframe Systems Programmer - TRA
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of R.S.
> Sent: Monday, August 21, 2017 9:44 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: Removing Catalog Entries for Datasets That Do 
> Not Exist
> 
> To complement: ARCCATGP is *tricky*.
> It is NOT enough to be connected to the group. One has to logon with 
> ARCCATGP as current connect group.
> For TSO one has to provide his userid, password and the ARCCATGP as 
> the group.
> 
> HTH
> 
> --
> Radoslaw Skorupka
> Lodz, Poland
> 
> 
> 
> 
> 
> 
> 
> W dniu 2017-08-21 o 16:36, Allan Staller pisze:
> > My bad, it is *JUST* a group.
> >
> > Lizette provided the info in a later post. Thanks Lizette
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Elardus Engelbrecht
> > Sent: Monday, August 21, 2017 8:41 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Removing Catalog Entries for Datasets That Do Not Exist
> >
> > Allan Staller wrote:
> >
> >> See if you or your job has access to ARCCATGP in (IIRC) the RACF 
> >> facility class,
> > Sorry, but could you be kind to say what profile in that RACF 
> > FACILITY
> Class?
> >
> > AFAIK, ARCCATGP has no access to any profiles in RACF. (I have 
> > checked that
> in zSecure), I believe, just being a member, you get all the HSM goodies.
> >
> > Thanks in advance.
> >
> > Groete / Greetings
> > Elardus Engelbrecht
> >

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

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

Re: [EXTERNAL] Re: Removing Catalog Entries for Datasets That Do Not Exist

[Lizette Koehler]

Typically for these types of cases, the problem is not the utility being used, 
but that the Entry MIGRAT(1/2) will force a recall.

Only way to get around it is to use the ARCCATGP.  Then IDCAMS, IEHPROGM, etc. 
will work.  You can do the delete noscratch easily then.

So batch job with GROUP=ARCCATGP on the JOBCARD or at TSO LOGON enter ARCCATGP 
in the GROUP field of the logon panel.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Dyck, Lionel B. (TRA)
> Sent: Monday, August 21, 2017 7:50 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXTERNAL] Re: Removing Catalog Entries for Datasets That Do Not
> Exist
> 
> Wouldn't IEHPROGM be easier?
> 
> 
> --
> Lionel B. Dyck
> Mainframe Systems Programmer - TRA
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of R.S.
> Sent: Monday, August 21, 2017 9:44 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: Removing Catalog Entries for Datasets That Do Not
> Exist
> 
> To complement: ARCCATGP is *tricky*.
> It is NOT enough to be connected to the group. One has to logon with ARCCATGP
> as current connect group.
> For TSO one has to provide his userid, password and the ARCCATGP as the
> group.
> 
> HTH
> 
> --
> Radoslaw Skorupka
> Lodz, Poland
> 
> 
> 
> 
> 
> 
> 
> W dniu 2017-08-21 o 16:36, Allan Staller pisze:
> > My bad, it is *JUST* a group.
> >
> > Lizette provided the info in a later post. Thanks Lizette
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Elardus Engelbrecht
> > Sent: Monday, August 21, 2017 8:41 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Removing Catalog Entries for Datasets That Do Not Exist
> >
> > Allan Staller wrote:
> >
> >> See if you or your job has access to ARCCATGP in (IIRC) the RACF
> >> facility class,
> > Sorry, but could you be kind to say what profile in that RACF FACILITY
> Class?
> >
> > AFAIK, ARCCATGP has no access to any profiles in RACF. (I have checked that
> in zSecure), I believe, just being a member, you get all the HSM goodies.
> >
> > Thanks in advance.
> >
> > 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: Cobol Help

[John McKown]

On Mon, Aug 21, 2017 at 7:40 AM, scott Ford  wrote:

> Guys/Gals:
>
> I need some help on a error I am not real familiar with in Cobol.
> I need write a generalized file-handler for files. Where do I start ?
> These are mostly QSAM files.. but i have to deal with Open/close/empty
> files, wrong length records...I have seen U1035 or similar errors and have
> done some reading in the manuals. Whats the easiest most effective method
> to handle file errors ?
>

​We generally use the FILE STATUS clause
https://www.ibm.com/support/knowledgecenter/en/SS6SG3_4.2.0/com.ibm.entcobol.doc_4.2/PGandLR/ref/rliossta.htm

SELECT SOMEFILE ASSIGN TO UT-S-DDNAME
 FILE STATUS IS WS-SOMEFILE-STATUS WS-SOMEFILE-STATUS2
...

77 WS-SOMEFILE-STATUS PIC 99.​
01 WS-SOMEFILE-STATUS2.
   05 WS-SOMEFILE-VSAM-RC PIC S99 BINARY.
   05 WS-SOMEFILE-VSAM-FC PIC S99 BINARY.
   05 WS-SOMEFILE-VSAM-FB PIC S99 BINARY.


​The WS-SOMEFILE-STATUS2 only applies to VSAM data sets. This will handle
_most_ of the I/O "problems" which you may encounter. One thing you need to
remember is that a COBOL​ definition cannot handle a "generic" situation.
In particular, if you are reading an FB type data set, then the FD for that
data set _must_ have the proper record length. If it does not, you CANNOT
open it successfully. The above FILE STATUS will let you "trap" the problem
and report a failure. But that is _all_ that it can do. A single FD simply
cannot read both an FB/80 and an FB/90 (for example) file.

Another thing to look is the the DECLARITIVES section.
https://www.ibm.com/support/knowledgecenter/en/SS6SG3_4.2.0/com.ibm.entcobol.doc_4.2/PGandLR/ref/rlpdsdec.htm
This section can handle most error situations on a file.

The last thing that I will mention is not really a COBOL language facility,
but an LE facility. That is the LE abend handler, CEEHDLR.
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceea300/clchdlr.htm
Being LE in nature, it is not as easy to understand as COBOL. But it is
LE's version of an ESTAE.



> Regards,
> Scott
>
> --
>
>
>
> *IDMWORKS *
>
> Scott Ford
>
> z/OS Dev.
>
>
>
>
> “By elevating a friend or Collegue you elevate yourself, by demeaning a
> friend or collegue you demean yourself”
>
>
>
> www.idmworks.com
>
> scott.f...@idmworks.com
>
> Blog: www.idmworks.com/blog
>
>
>
>
>
> *The information contained in this email message and any attachment may be
> privileged, confidential, proprietary or otherwise protected from
> disclosure. If the reader of this message is not the intended recipient,
> you are hereby notified that any dissemination, distribution, copying or
> use of this message and any attachment is strictly prohibited. If you have
> received this message in error, please notify us immediately by replying to
> the message and permanently delete it from your computer and destroy any
> printout thereof.*
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
If you look around the poker table & don't see an obvious sucker, it's you.

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: [EXTERNAL] Re: Removing Catalog Entries for Datasets That Do Not Exist

[Dyck, Lionel B. (TRA)]

Wouldn't IEHPROGM be easier?


--
Lionel B. Dyck 
Mainframe Systems Programmer - TRA


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Monday, August 21, 2017 9:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Removing Catalog Entries for Datasets That Do Not Exist

To complement: ARCCATGP is *tricky*.
It is NOT enough to be connected to the group. One has to logon with ARCCATGP 
as current connect group.
For TSO one has to provide his userid, password and the ARCCATGP as the group.

HTH

--
Radoslaw Skorupka
Lodz, Poland







W dniu 2017-08-21 o 16:36, Allan Staller pisze:
> My bad, it is *JUST* a group.
>
> Lizette provided the info in a later post. Thanks Lizette
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Elardus Engelbrecht
> Sent: Monday, August 21, 2017 8:41 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Removing Catalog Entries for Datasets That Do Not Exist
>
> Allan Staller wrote:
>
>> See if you or your job has access to ARCCATGP in (IIRC) the RACF
>> facility class,
> Sorry, but could you be kind to say what profile in that RACF FACILITY Class?
>
> AFAIK, ARCCATGP has no access to any profiles in RACF. (I have checked that 
> in zSecure), I believe, just being a member, you get all the HSM goodies.
>
> Thanks in advance.
>
> 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
>
>
> ::DISCLAIMER::
> 
>
> The contents of this e-mail and any attachment(s) are confidential and 
> intended for the named recipient(s) only.
> E-mail transmission is not guaranteed to be secure or error-free as 
> information could be intercepted, corrupted,
> lost, destroyed, arrive late or incomplete, or may contain viruses in 
> transmission. The e mail and its contents
> (with or without referred errors) shall therefore not attach any liability on 
> the originator or HCL or its affiliates.
> Views or opinions, if any, presented in this email are solely those of the 
> author and may not necessarily reflect the
> views or opinions of HCL or its affiliates. Any form of reproduction, 
> dissemination, copying, disclosure, modification,
> distribution and / or publication of this message without the prior written 
> consent of authorized representative of
> HCL is strictly prohibited. If you have received this email in error please 
> delete it and notify the sender immediately.
> Before opening any email and/or attachments, please check them for viruses 
> and other defects.
>
> 
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



==


--
 Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

 This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

 mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy 

Re: Removing Catalog Entries for Datasets That Do Not Exist

[Lizette Koehler]

I am glad to help

I am also glad IBM gave at least a way to do this.  But I would have preferred 
a Facility in the ARC stuff.  Easier to remember and see.  The use of a GROUP 
do to this seems a little kludgy


Lizette

;-D


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Allan Staller
> Sent: Monday, August 21, 2017 7:37 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Removing Catalog Entries for Datasets That Do Not Exist
> 
> My bad, it is *JUST* a group.
> 
> Lizette provided the info in a later post. Thanks Lizette
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Elardus Engelbrecht
> Sent: Monday, August 21, 2017 8:41 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Removing Catalog Entries for Datasets That Do Not Exist
> 
> Allan Staller wrote:
> 
> >See if you or your job has access to ARCCATGP in (IIRC) the RACF
> >facility class,
> 
> Sorry, but could you be kind to say what profile in that RACF FACILITY Class?
> 
> AFAIK, ARCCATGP has no access to any profiles in RACF. (I have checked that
> in zSecure), I believe, just being a member, you get all the HSM goodies.
> 
> Thanks in advance.
> 
> 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: Removing Catalog Entries for Datasets That Do Not Exist

[R.S.]

To complement: ARCCATGP is *tricky*.
It is NOT enough to be connected to the group. One has to logon with 
ARCCATGP as current connect group.
For TSO one has to provide his userid, password and the ARCCATGP as the 
group.


HTH

--
Radoslaw Skorupka
Lodz, Poland







W dniu 2017-08-21 o 16:36, Allan Staller pisze:

My bad, it is *JUST* a group.

Lizette provided the info in a later post. Thanks Lizette

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Monday, August 21, 2017 8:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Removing Catalog Entries for Datasets That Do Not Exist

Allan Staller wrote:


See if you or your job has access to ARCCATGP in (IIRC) the RACF
facility class,

Sorry, but could you be kind to say what profile in that RACF FACILITY Class?

AFAIK, ARCCATGP has no access to any profiles in RACF. (I have checked that in 
zSecure), I believe, just being a member, you get all the HSM goodies.

Thanks in advance.

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


::DISCLAIMER::


The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information 
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on 
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the 
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, 
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written 
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please 
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and 
other defects.




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




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.
   


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

Re: z14 and zBX

[Allan Staller]

More likely, no changes needed for zBx.


I haven't seen any information regarding zBX for z14 machine.
Does it mean IBM (quietly) closed the idea of zBX?



::DISCLAIMER::


The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information 
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on 
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the 
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, 
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written 
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please 
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and 
other defects.



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

Re: Removing Catalog Entries for Datasets That Do Not Exist

[Allan Staller]

My bad, it is *JUST* a group.

Lizette provided the info in a later post. Thanks Lizette

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Monday, August 21, 2017 8:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Removing Catalog Entries for Datasets That Do Not Exist

Allan Staller wrote:

>See if you or your job has access to ARCCATGP in (IIRC) the RACF 
>facility class,

Sorry, but could you be kind to say what profile in that RACF FACILITY Class?

AFAIK, ARCCATGP has no access to any profiles in RACF. (I have checked that in 
zSecure), I believe, just being a member, you get all the HSM goodies.

Thanks in advance.

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


::DISCLAIMER::


The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information 
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on 
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the 
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, 
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written 
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please 
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and 
other defects.




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

Re: OT-retirement

[Lund James E]

As they say... If you enjoy what you do, you never work a day in your life... 
just sayin'

James Lund
Texas A University

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jack J. Woehr
Sent: Saturday, August 19, 2017 12:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] OT-retirement

Ed Jaffe wrote:
> I'll probably die with one foot in the grave and one hand on the keyboard... 

Me too, I'm on the "Work Until You Drop" retirement plan. Along with many of my 
generation:

http://www.pressherald.com/2017/08/02/baby-boomer-dying-on-the-job/

-- 
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: Cobol Help

[Lizette Koehler]

So do you need  complete code? Or just guidelines on how to code cobol?

Any general COBOL text (class book or book from Amazon) or internet search 
should get you started.

If you need a simple read a record write a record, let me know and I can send 
you a sample COBOL program


A quick internet search with the key words

COBOL READ WRITE A RECORD

Brought up this lovely little code

http://people.sju.edu/~jhodgson/cobol/sample.html


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of scott Ford
> Sent: Monday, August 21, 2017 5:41 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Cobol Help
> 
> Guys/Gals:
> 
> I need some help on a error I am not real familiar with in Cobol.
> I need write a generalized file-handler for files. Where do I start ?
> These are mostly QSAM files.. but i have to deal with Open/close/empty files,
> wrong length records...I have seen U1035 or similar errors and have done some
> reading in the manuals. Whats the easiest most effective method to handle
> file errors ?
> 
> Regards,
> Scott
> 
> --
> 
> 
> 
> *IDMWORKS *
> 
> Scott Ford
> 
> z/OS Dev.
> 
> 

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

Re: Removing Catalog Entries for Datasets That Do Not Exist

[Lizette Koehler]

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.arci000/racf.htm




z/OS DFSMS
z/OS DFSMShsm Implementation and Customization Guide
Implementing DFSMShsm
Authorizing and protecting DFSMShsm commands and resources



DFSMShsm to recall the data set before the operation is performed unless you 
take action.

To allow certain authorized users to perform these operations on migrated data 
sets without recalling them, perform the following steps.

Define a RACF catalog maintenance group named ARCCATGP.

Example: ADDGROUP (ARCCATGP)
Connect the desired users to that group.
If you specify . . .Then . . .
CONNECT (userid1,. . .,useridn ) GROUP(ARCCATGP) AUTHORITY(USE) Each 
user (userid1,. . .,useridn) is authorized to bypass automatic recall for 
catalog operations.

Only when such a user is logged on under group ARCCATGP does DFSMShsm bypass 
the automatic recall for UNCATALOG, RECATALOG, and DELETE/NOSCRATCH requests 
for migrated data sets.
Example: The following LOGON command demonstrates starting a TSO session under 
ARCCATGP:

   LOGON userid | password GROUP(ARCCATGP)



Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Elardus Engelbrecht
> Sent: Monday, August 21, 2017 6:41 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Removing Catalog Entries for Datasets That Do Not Exist
> 
> Allan Staller wrote:
> 
> >See if you or your job has access to ARCCATGP in (IIRC) the RACF
> >facility class,
> 
> Sorry, but could you be kind to say what profile in that RACF FACILITY Class?
> 
> AFAIK, ARCCATGP has no access to any profiles in RACF. (I have checked that
> in zSecure), I believe, just being a member, you get all the HSM goodies.
> 
> Thanks in advance.
> 
> 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: [EXTERNAL] z14 and zBX

[Dyck, Lionel B. (TRA)]

Maybe they are putting all that processing into Containers :-)


--
Lionel B. Dyck 
Mainframe Systems Programmer - TRA


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Monday, August 21, 2017 8:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] z14 and zBX

I haven't seen any information regarding zBX for z14 machine.
Does it mean IBM (quietly) closed the idea of zBX?

-- 
Radoslaw Skorupka
Lodz, Poland




==


--
 Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

 This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

 mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.


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

z14 and zBX

[R.S.]

I haven't seen any information regarding zBX for z14 machine.
Does it mean IBM (quietly) closed the idea of zBX?

--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.
   


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

Re: Jol Universal Command Language and Enhanced JCL Language

[John McKown]

On Sun, Aug 20, 2017 at 11:56 PM, Clem Clarke 
wrote:

> ​
>
>
> And so today, Jol is now under the Open Source banner.  You are
> encouraged  use it for free, and the source code (which was examined and
> approved by IBM in the '80s) is available with the proviso and restriction
> that if it is turned into a commercial product, royalties must be paid.
>

​Thank you very much for opening the source. I have heard of JOL, but have
not tried it. This was mainly due to the directive that "since we are
abandoning z/OS, just keep it stable and don't do new things". Upper
management has reversed itself, and we are revitalizing z/OS.​ I don't know
if we'd actually use JOL. It depends on how well it integrates with CA-11
restart.



>
> There are three or so versions of Jol.
> 1. The 370 Assembler Z/OS Mainframe version.
> 2. The Windows, Linux and OS/2 "C" versions that either generate code that
> runs on the mainframe, or alternatively executes native applications on
> their own platforms. The Linux version is in Beta mode.
> 3. A Beta version of a compatible IBM VSE version.
>
> You can download Jol from the www.Oscar-Jol.com site which also has all
> the documentation and many examples.
>
> Now, there is no reason why you cannot move to the next generation JCL
> language.
>
> Clem Clarke
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
If you look around the poker table & don't see an obvious sucker, it's you.

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: GDPR for US companies (Was: Scrubbing sensitive data in dumps)

[R.S.]

W dniu 2017-08-14 o 18:29, Ron Hawkins pisze:

Then tell me why my overseas banks contacting me to provide details under FBAR.

What's good for the goose...


Yes, my bank also contacted me in regard of FBAR (or other US 
regulation). Neither me nor the bank has businesses in US.


--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.
   


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

Re: Removing Catalog Entries for Datasets That Do Not Exist

[Elardus Engelbrecht]

Allan Staller wrote:

>See if you or your job has access to ARCCATGP in (IIRC) the RACF facility 
>class,

Sorry, but could you be kind to say what profile in that RACF FACILITY Class?

AFAIK, ARCCATGP has no access to any profiles in RACF. (I have checked that in 
zSecure), I believe, just being a member, you get all the HSM goodies.

Thanks in advance.

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: Competent managers (was Re: OT-retirement)

[Lucas Rosalen]

I second you in every word.
So, by my own previous personal experience, having a PC weenie manager is
not necessarily a no go.

---
*Lucas Rosalen*
Emails: rosalen.lu...@gmail.com / *lrosa...@pl.ibm.com
*
LinkedIn: http://br.linkedin.com/in/lrosalen
Phone: +48 (71) 792 809 198


2017-08-21 15:08 GMT+02:00 Tom Marchant <
000a2a8c2020-dmarc-requ...@listserv.ua.edu>:

> On Sat, 19 Aug 2017 15:15:05 +, scott Ford wrote:
>
> >What about having PC managers who don't understand z/OS or z/OS ppl?
>
> One of the best managers I ever had was a PC weenie who knew
> nothing about mainframes. He knew how to manage. He never tried
> to make technical decisions because he knew that his people were
> qualified to do that. He believed that the most important thing for
> him to do was to keep the corporate bureaucracy out of our way
> so that we could do our jobs. He enabled us to do our best work.
>
> One of the worst managers was a highly competent technical person
> who seemed to think that he needed to second guess everything
> that we did. He didn't have the temperament to be a manager and
> should have remained in a technical position, but he accepted the
> change because idiotic bureaucracy couldn't give him a raise without
> making him a manager.
>
> --
> Tom Marchant
>
> --
> 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: Competent managers (was Re: OT-retirement)

[zMan]

And then there's the inverse stupid bureaucracy: I manage a team, but not
on paper, because making me a manager would involve a significant salary
reduction.

Every big company has a large and powerful Business Prevention Department!

On Mon, Aug 21, 2017 at 9:08 AM, Tom Marchant <
000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

> On Sat, 19 Aug 2017 15:15:05 +, scott Ford wrote:
>
> >What about having PC managers who don't understand z/OS or z/OS ppl?
>
> One of the best managers I ever had was a PC weenie who knew
> nothing about mainframes. He knew how to manage. He never tried
> to make technical decisions because he knew that his people were
> qualified to do that. He believed that the most important thing for
> him to do was to keep the corporate bureaucracy out of our way
> so that we could do our jobs. He enabled us to do our best work.
>
> One of the worst managers was a highly competent technical person
> who seemed to think that he needed to second guess everything
> that we did. He didn't have the temperament to be a manager and
> should have remained in a technical position, but he accepted the
> change because idiotic bureaucracy couldn't give him a raise without
> making him a manager.
>
> --
> Tom Marchant
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

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

Re: grabbing JES output via FTP

[Joel C. Ewing]

On 08/19/2017 08:34 PM, Tony Thigpen wrote:
> I am attempting to use FTP under VM to grab some job output from JES2.
> I am getting a strange error that I don't know where to start trying
> to resolve it. I also get the same messages when I try to ftp from a
> local pc.
>
> Command:
> site filetype=jes
> >>>SITE filetype=jes
> 200 SITE command was accepted
> Command:
> get JOB01106.2
> >>>EPRT |1|10.10.50.141|1170|
> 500 unknown command EPRT
> >>>PORT 10,10,50,141,4,146
> 200 Port request OK.
> >>>RETR JOB01106.2
> 451 Nlst failed due to internal error
> Command:
>
>
> thoughts?
>
There is an FTP exit the installation can use to restrict what can be
done by users via FTP.  Our installation used that exit and permissions
to installation-specific RACF profiles to restrict what RACF userids
(which were primarily CICS and TSO users) were authorized to login to
FTP and which of those were further authorized to use filetype=jes, so
that users who hadn't been properly trained or whose job function gave
them no legitimate reason to access FTP or FTP filetype=jes wouldn't be
given these tools and create unanticipated exposures.  Someone with a
RACF userid who hasn't been granted TSO access and trained in TSO/ISPF
would  be less likely to have the training to know whether jobs they
might submit to MVS via FTP were reasonable; and those with TSO/ISPF
access have much better interfaces than FTP to submit and access JES
jobs.  At least before my retirement, there had never had any  need or
requests for more than one or two userids to use FTP filetype=jes (and
those were in Tech Services, because some vendor made part of their MVS
product maintenance support dependent on that feature).

Not saying the site in question has done something like this, but that's
one possibility.
Joel C. Ewing.  

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

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

Competent managers (was Re: OT-retirement)

[Tom Marchant]

On Sat, 19 Aug 2017 15:15:05 +, scott Ford wrote:

>What about having PC managers who don't understand z/OS or z/OS ppl?

One of the best managers I ever had was a PC weenie who knew 
nothing about mainframes. He knew how to manage. He never tried 
to make technical decisions because he knew that his people were 
qualified to do that. He believed that the most important thing for 
him to do was to keep the corporate bureaucracy out of our way 
so that we could do our jobs. He enabled us to do our best work.

One of the worst managers was a highly competent technical person 
who seemed to think that he needed to second guess everything 
that we did. He didn't have the temperament to be a manager and 
should have remained in a technical position, but he accepted the 
change because idiotic bureaucracy couldn't give him a raise without 
making him a manager.

-- 
Tom Marchant

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

Re: Removing Catalog Entries for Datasets That Do Not Exist

[Allan Staller]

See if you or your job has access to ARCCATGP in (IIRC) the RACF facility class,

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rodatz, William J
Sent: Monday, August 21, 2017 6:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Removing Catalog Entries for Datasets That Do Not Exist

Hi,

I want to thank everyone who responded to my inquiry regarding the deletion of 
migrated datasets.  It looks like all of the responses have suggested using 
IDCAMS with the DELETE and NOSCRATCH control statements.  I tried that last 
week.  I ran the job again this morning.  Below is the job log and the control 
statements I used.  As you can see, a call is made to DFHSM to do a recall 
prior to deletion.

DELETE -
 EH.FP78.RESBHSFL -
 NOSCRATCH -
 NONVSAM


ICH70001I WR99900  LAST ACCESS AT 05:52:53 ON MONDAY, AUGUST 21, 2017
 $HASP373 IDCAMS1  STARTED - INIT D- CLASS Y- SYS 9121
 IEF403I IDCAMS1 - STARTED - TIME=05.57.52  ARC0050A DFSMSHSM IS NOT ACTIVE - 
START DFSMSHSM  ARC0051A JOB IDCAMS1  WAITING FOR DFSMSHSM TO RECALL 
DSN=EH.FP78.RESBHSFL
*06 ARC0055A REPLY 'GO' OR 'CANCEL'

Thanks again for the responses.

Bill

-Original Message-

From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rodatz, William J

Sent: Friday, August 18, 2017 10:41 AM

To: IBM-MAIN@LISTSERV.UA.EDU

Subject: Removing Catalog Entries for Datasets That Do Not Exist



Hello Everyone,



Recently I discovered some datasets with "MIGRAT" as the volser.  These 
datasets had been migrated with DFHSM many years ago.  My organization is no 
longer running the product.  I am attempting to remove the dangling catalog 
entries which appears to be challenging.  The pubs say to use IEHPROGM with the 
SCRATCH function if (1) the dataset is non-SMS managed and (2) you know the 
dataset's volser prior to migration.  I don't what the original volser was and 
I don't know why it matters.  The catalog entry has only the dataset name and 
"MIGRAT" for the volser.



When I execute IEHPROGM, I get messages denoting that DFHSM is not active.  I 
am unable to move past this point.



Does anyone have an idea how the catalog entries can be removed?  Any input 
would be greatly appreciated.



Thank you.



Bill


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


::DISCLAIMER::


The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information 
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on 
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the 
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, 
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written 
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please 
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and 
other defects.



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

Re: SMFLIMxx sample?

[Vernooij, Kees (ITOPT1) - KLM]

Steve,

Thanks, for the extensive answers. The picture is clear now.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Steve
> Sent: 18 August, 2017 15:35
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMFLIMxx sample?
> 
> Hello,
> 
> Kees, sorry for the delay in answering:
> 
>  >You say: "Note that SMFLIMxx REGIONBELOW/REGIONABOVE are *not* related
> to the IEFUSI's "region size" parameter"
>  >Am I correct to state that SMFLIMxx REGIONBELOW/REGIONABOVE are equal
> to IEFUSI setting a Regionsize=Regionlimit both below and above?
> 
> sbj:  As the function exists now, VSM sets the job step's limit and size
> values using a myriad of fields passed into it:
> - JCL Region= or REGIONX= values
> - SMFLIMxx REGIONx values (which will override the above JCL REGION
> values)
> - IEFUSI RegionLimit and RegionSize values
> - SMFLIMxx SYSRESVx values, which will essentially be used in place
> of the IEFUSI REGIONLIMIT value.
> 
> VSM will factor these values together and come up with a regionlimit and
> a regionsize.
> 
> Since there is no regionsize keyword, when SYSRESV is used, the
> regionsize should match the regionlimit.
> 
> If the JCL REGION or the SMFLIMxx REGIONx values are non-zero and
> lower than the determined regionlimit, that means the user (or SMFLIMxx
> coder) has a specific amount in mind and the regionsize will be set to
> that amount.  And as we know, if you request more region via JCL than is
> available, an abend will result.  IIRC, if SYSRESVx is not used and
> IEFUSI doesn't set any values, VSM will add a default value to the
> regionsize to set the regionlimit.
> 
> This is why people are simply coding REGIONBELOW(NOLIMIT)
> REGIONABOVE(NOLIMIT) to simply override whatever the user requested and
> giving them REGION=0M. I'm not sure why they aren't using SYSRESVx
> to protect private for system use, unless they still have their IEFUSI
> in place.
> 
>  >IEFUSI doc explains the value of difference between regionsize and
> regionlimit with regard to VL Getmains. Is this no important anymore,
> because SMFLIMxx does not provide control of a different regionlimit
> anymore?
> SBJ: I won't say it's not important, just that it was not in the
> function provided on day 1.  And that the nuance about VL Getmains is
> often missed.
> 
>  >Region=0M implies Memlimit=0M. Does the SMFLIMxx Memlimit parameter
> overrule Memlimit=0M for Region=0M tasks?
> sbj:  REGION=0M implies Memlimit=0M, but only when coded on the JCL.
> Using REGIONx(NOLIMIT) does not specifically alter the MEMLIMIT. The
> SMFLIMxx memlimit parameter will overrule the MEMLIMIT coded and the
> implied memlimit from region=0M.  Since IEFUSI and SMFLIMxx have the
> ability to set any MEMLIMIT, there is no reason to imply a memlimit.
> 
> 
> 
>  >If so, a filter on REGION= would be helpful or I need IEFUSI to ignore
> SMFLIMxx for Region=0M steps.
> sbj:  Please open an RFE in DeveloperWorks.  I think you'll get a lot of
> votes for the idea.
> 
> 
>  >Does NOHONORIEFUSIREGION in SCHEDxx also apply to SMFLIMxx, i.o.w. is
> SMFLIMxx also ignored like IEFUSI is? If so, will SCHEDxx docs be
> updated?
> sbj:  NOHONORIEFUSIREGION does override SMFLIMxx. I'll make a note to
> get the doc updated.
> 
> Thanks,
> Kees.
> 
> --
> 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: Removing Catalog Entries for Datasets That Do Not Exist

[Elardus Engelbrecht]

Rodatz, William J wrote:

>I wanted to let everyone that I have been able to remove the migrated dataset 
>names from the catalog.  Lizette Koehler suggested that try using ARCCATGP 
>which is a RACF group.

Excellent! I am glad for your part.

I did a little RTFM and came across this snippet in "DFSMShsm Storage 
Administration":

"The DELETE data set name NOSCRATCH command can be used to uncatalog migrated 
data sets. For this command to be used when RACF protection is used for 
DFSMShsm-owned data sets, two conditions must exist: 

- A RACF group of ARCCATGP must exist.
- The user who issues the DELETE NOSCRATCH command must be authorized to group 
ARCCATGP."

I totally forgot about this group, looking it up in my RACF I see I did created 
it in year 2006 to resolve a similar problem for my HSM gurus... ;-)

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

Cobol Help

[scott Ford]

Guys/Gals:

I need some help on a error I am not real familiar with in Cobol.
I need write a generalized file-handler for files. Where do I start ?
These are mostly QSAM files.. but i have to deal with Open/close/empty
files, wrong length records...I have seen U1035 or similar errors and have
done some reading in the manuals. Whats the easiest most effective method
to handle file errors ?

Regards,
Scott

-- 



*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”



www.idmworks.com

scott.f...@idmworks.com

Blog: www.idmworks.com/blog





*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*

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

Re: Removing Catalog Entries for Datasets That Do Not Exist

[Rodatz, William J]

I wanted to let everyone that I have been able to remove the migrated dataset 
names from the catalog.  Lizette Koehler suggested that try using ARCCATGP 
which is a RACF group.  If you are connected to this group  you can delete 
migrated datasets without first recalling them.  I issued the RACF command:

CONNECT WR99900 GROUP(ARCCATGP) AUTHORITY(USE)

I then added GROUP=ARCCATGP to my job card and executed IDCAMS with the DELETE 
and NOSCRATCH control statements and got RC=0.  I'm glad to resolve this.

My thanks to everyone who responded to my posting.

William Rodatz



-Original Message-

From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rodatz, William J

Sent: Friday, August 18, 2017 10:41 AM

To: IBM-MAIN@LISTSERV.UA.EDU

Subject: Removing Catalog Entries for Datasets That Do Not Exist



Hello Everyone,



Recently I discovered some datasets with "MIGRAT" as the volser.  These 
datasets had been migrated with DFHSM many years ago.  My organization is no 
longer running the product.  I am attempting to remove the dangling catalog 
entries which appears to be challenging.  The pubs say to use IEHPROGM with the 
SCRATCH function if (1) the dataset is non-SMS managed and (2) you know the 
dataset's volser prior to migration.  I don't what the original volser was and 
I don't know why it matters.  The catalog entry has only the dataset name and 
"MIGRAT" for the volser.



When I execute IEHPROGM, I get messages denoting that DFHSM is not active.  I 
am unable to move past this point.



Does anyone have an idea how the catalog entries can be removed?  Any input 
would be greatly appreciated.



Thank you.



Bill



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

Re: Removing Catalog Entries for Datasets That Do Not Exist [Public Information]

[Styles, Andy (ITS zPlatform Services)]

Classification: Public
I imagine that a vendor product like CIM or TACM could surgically zap the 
catalog to remove the entries.

I checked with one of our storage folks, he suggested that the catalog entry 
actually has MIGRAT (I've checked that on one of my own migrated datasets with 
LISTC), and it's actually the listing that adds the "1" or "2" depending on the 
device type of the catalog entry. He suggests:

"As far as I can remember, the actual entry for a migrated entry is MIGRAT (as 
that is a 6 char VOLSER entry). It is the listing of it that adds the suffix 1 
or 2 depending on the catalog device type (either disk or tape) - but - to get 
rid of the entries, you need to connect to the ARCCATGP RACF group. That will 
cause allocation to just delete it rather than drive a recall attempt."

Sure enough that appears to be a valid group - whether you still need DFHSM to 
be active, though..

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.arci000/endus.htm

Not really my area, so I'm hoping some of this will help!

Andy Styles
z/Series Systems Programmer


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Dawes
Sent: 21 August 2017 12:50
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Removing Catalog Entries for Datasets That Do Not Exist [Public 
Information]

-- This email has reached the Bank via an external source --
 

Bill,I checked some of our migrated dsns.  They have the catalog entry as 
MIGRAT1 or MIGRAT2.  The status of MIGRAT (folks at FDR please correct me if I 
am wrong) indicates that the dsn was archived by FDR.

  From: "Usher, Darrold" <014f796d148d-dmarc-requ...@listserv.ua.edu>
 To: IBM-MAIN@LISTSERV.UA.EDU
 Sent: Friday, 18 August 2017, 11:58
 Subject: Re: Removing Catalog Entries for Datasets That Do Not Exist [Public 
Information]
   
Did your try DEL 'dsname' NSCR?

Classification: Public Information


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rodatz, William J
Sent: Friday, August 18, 2017 10:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Removing Catalog Entries for Datasets That Do Not Exist

Hello Everyone,

Recently I discovered some datasets with "MIGRAT" as the volser.  These 
datasets had been migrated with DFHSM many years ago.  My organization is no 
longer running the product.  I am attempting to remove the dangling catalog 
entries which appears to be challenging.  The pubs say to use IEHPROGM with the 
SCRATCH function if (1) the dataset is non-SMS managed and (2) you know the 
dataset's volser prior to migration.  I don't what the original volser was and 
I don't know why it matters.  The catalog entry has only the dataset name and 
"MIGRAT" for the volser.

When I execute IEHPROGM, I get messages denoting that DFHSM is not active.  I 
am unable to move past this point.

Does anyone have an idea how the catalog entries can be removed?  Any input 
would be greatly appreciated.

Thank you.

Bill

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


Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. 
Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. 
Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England 
and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered 
Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. 
Telephone: 03457 801 801. Cheltenham & Gloucester plc. Registered Office: 
Barnett Way, Gloucester GL4 3RL. Registered in England and Wales 2299428. 
Telephone: 0345 603 1637

Lloyds Bank plc, Bank of Scotland plc are authorised by the Prudential 
Regulation Authority and regulated by the Financial Conduct Authority and 
Prudential Regulation Authority.

Cheltenham & Gloucester plc is authorised and regulated by the Financial 
Conduct Authority.

Halifax is a division of Bank of Scotland plc. Cheltenham & Gloucester Savings 
is a division of Lloyds Bank plc.

HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in 
Scotland no. SC218813.

This e-mail (including any attachments) is private and confidential and may 
contain privileged material. If you have received this e-mail in error, please 
notify the sender and delete it (including any attachments) immediately. You 
must not copy, 

Re: Jol Universal Command Language and Enhanced JCL Language

[Edward Gould]

> On Aug 20, 2017, at 11:56 PM, Clem Clarke  
> wrote:
> 
> —snip-
> Clem Clarke
Clem, in the late 70’s (IIRC) we had a DC not to far from yours. I think we 
came over and met John (story forgot his name) and I think you.
We had a general discussion about JOL and IIRC you handed us a tape with it on.
We took it back and discussed it a little. I was given the task to unload it 
and poke around a little bit and see if it might be of general interest.
I really don’t remember what I wrote down about JOL other than at that point 
there was no real support and maybe about being OS specific (its been ages).
I guess my comments made everybody a little queasy and we put it on the shelf. 
We were already really busy with other MVS duties,
Ed

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

Re: Removing Catalog Entries for Datasets That Do Not Exist

[Gonzalo Cengotita]

Hi,
have you tried the TSO DELETE, instead of IDCAMS DELETE? I usually do this
task trying first online (in 3.4 list) and if it doesn't work, with JCL
batch.
I have done it many times, and it works even if you get the HSM error
message, if you have a reasonable recent version of zOS

regards,


*Gonzalo Cengotita*

2017-08-21 13:21 GMT+02:00 Rodatz, William J <
william.rod...@labor.alabama.gov>:

> Hi,
>
> I want to thank everyone who responded to my inquiry regarding the
> deletion of migrated datasets.  It looks like all of the responses have
> suggested using IDCAMS with the DELETE and NOSCRATCH control statements.  I
> tried that last week.  I ran the job again this morning.  Below is the job
> log and the control statements I used.  As you can see, a call is made to
> DFHSM to do a recall prior to deletion.
>
> DELETE -
>  EH.FP78.RESBHSFL -
>  NOSCRATCH -
>  NONVSAM
>
>
> ICH70001I WR99900  LAST ACCESS AT 05:52:53 ON MONDAY, AUGUST 21, 2017
>  $HASP373 IDCAMS1  STARTED - INIT D- CLASS Y- SYS 9121
>  IEF403I IDCAMS1 - STARTED - TIME=05.57.52
>  ARC0050A DFSMSHSM IS NOT ACTIVE - START DFSMSHSM
>  ARC0051A JOB IDCAMS1  WAITING FOR DFSMSHSM TO RECALL DSN=EH.FP78.RESBHSFL
> *06 ARC0055A REPLY 'GO' OR 'CANCEL'
>
> Thanks again for the responses.
>
> Bill
>
> -Original Message-
>
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Rodatz, William J
>
> Sent: Friday, August 18, 2017 10:41 AM
>
> To: IBM-MAIN@LISTSERV.UA.EDU
>
> Subject: Removing Catalog Entries for Datasets That Do Not Exist
>
>
>
> Hello Everyone,
>
>
>
> Recently I discovered some datasets with "MIGRAT" as the volser.  These
> datasets had been migrated with DFHSM many years ago.  My organization is
> no longer running the product.  I am attempting to remove the dangling
> catalog entries which appears to be challenging.  The pubs say to use
> IEHPROGM with the SCRATCH function if (1) the dataset is non-SMS managed
> and (2) you know the dataset's volser prior to migration.  I don't what the
> original volser was and I don't know why it matters.  The catalog entry has
> only the dataset name and "MIGRAT" for the volser.
>
>
>
> When I execute IEHPROGM, I get messages denoting that DFHSM is not
> active.  I am unable to move past this point.
>
>
>
> Does anyone have an idea how the catalog entries can be removed?  Any
> input would be greatly appreciated.
>
>
>
> Thank you.
>
>
>
> Bill
>
>
> --
> 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: Removing Catalog Entries for Datasets That Do Not Exist [Public Information]

[John Dawes]

Bill,I checked some of our migrated dsns.  They have the catalog entry as 
MIGRAT1 or MIGRAT2.  The status of MIGRAT (folks at FDR please correct me if I 
am wrong) indicates that the dsn was archived by FDR.

  From: "Usher, Darrold" <014f796d148d-dmarc-requ...@listserv.ua.edu>
 To: IBM-MAIN@LISTSERV.UA.EDU 
 Sent: Friday, 18 August 2017, 11:58
 Subject: Re: Removing Catalog Entries for Datasets That Do Not Exist [Public 
Information]
   
Did your try DEL 'dsname' NSCR?

Classification: Public Information


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rodatz, William J
Sent: Friday, August 18, 2017 10:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Removing Catalog Entries for Datasets That Do Not Exist

Hello Everyone,

Recently I discovered some datasets with "MIGRAT" as the volser.  These 
datasets had been migrated with DFHSM many years ago.  My organization is no 
longer running the product.  I am attempting to remove the dangling catalog 
entries which appears to be challenging.  The pubs say to use IEHPROGM with the 
SCRATCH function if (1) the dataset is non-SMS managed and (2) you know the 
dataset's volser prior to migration.  I don't what the original volser was and 
I don't know why it matters.  The catalog entry has only the dataset name and 
"MIGRAT" for the volser.

When I execute IEHPROGM, I get messages denoting that DFHSM is not active.  I 
am unable to move past this point.

Does anyone have an idea how the catalog entries can be removed?  Any input 
would be greatly appreciated.

Thank you.

Bill

--
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: Removing Catalog Entries for Datasets That Do Not Exist

[van der Grijn, Bart (B)]

Bill, not all the replies were to use DELETE NOSCRATCH. I suggested using the 
following sequence: 
- Create a new catalog (a throw-away catalog used just for this cleanup)
- REPRO MERGECAT your entries to this new catalog
- Delete the catalog (with RECOVERY)

As far as I know the above steps will not try to interact with HSM. I use this 
same approach when we have orphaned catalog entries of old archived datasets. 

Bart

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rodatz, William J
Sent: Monday, August 21, 2017 7:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Removing Catalog Entries for Datasets That Do Not Exist

Hi,

I want to thank everyone who responded to my inquiry regarding the deletion of 
migrated datasets.  It looks like all of the responses have suggested using 
IDCAMS with the DELETE and NOSCRATCH control statements.  I tried that last 
week.  I ran the job again this morning.  Below is the job log and the control 
statements I used.  As you can see, a call is made to DFHSM to do a recall 
prior to deletion.

DELETE -
 EH.FP78.RESBHSFL -
 NOSCRATCH -
 NONVSAM


ICH70001I WR99900  LAST ACCESS AT 05:52:53 ON MONDAY, AUGUST 21, 2017
 $HASP373 IDCAMS1  STARTED - INIT D- CLASS Y- SYS 9121
 IEF403I IDCAMS1 - STARTED - TIME=05.57.52
 ARC0050A DFSMSHSM IS NOT ACTIVE - START DFSMSHSM
 ARC0051A JOB IDCAMS1  WAITING FOR DFSMSHSM TO RECALL DSN=EH.FP78.RESBHSFL
*06 ARC0055A REPLY 'GO' OR 'CANCEL'

Thanks again for the responses.

Bill

-Original Message-

From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rodatz, William J

Sent: Friday, August 18, 2017 10:41 AM

To: IBM-MAIN@LISTSERV.UA.EDU

Subject: Removing Catalog Entries for Datasets That Do Not Exist



Hello Everyone,



Recently I discovered some datasets with "MIGRAT" as the volser.  These 
datasets had been migrated with DFHSM many years ago.  My organization is no 
longer running the product.  I am attempting to remove the dangling catalog 
entries which appears to be challenging.  The pubs say to use IEHPROGM with the 
SCRATCH function if (1) the dataset is non-SMS managed and (2) you know the 
dataset's volser prior to migration.  I don't what the original volser was and 
I don't know why it matters.  The catalog entry has only the dataset name and 
"MIGRAT" for the volser.



When I execute IEHPROGM, I get messages denoting that DFHSM is not active.  I 
am unable to move past this point.



Does anyone have an idea how the catalog entries can be removed?  Any input 
would be greatly appreciated.



Thank you.



Bill

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

Re: AXR address space

[Steve Horein]

I took the opposite approach while we're in the process of implementing
System Automation:
Just prior to shutting down our JES3, one of the TERMINIT commands is to
invoke a STARTAXR exec that does a SAY to merely initiate a subtask for
later use.
After termination of the AM, it is this subtask that executes and
coordinates taking care of:

   - T DIAG=xx (sets up REIPL)
   - Z EOD
   - V XCF,,OFF,REIPL
   - R xx,SYS=

I found having System Rexx around after the SA environment had terminated
quite convenient.
I do not expect to use the System Rexx method once PROCOPS has been
customized and configured.

Could/Should the AXRxx subtasks be started SUB=MSTR to release its
dependency on JES? I don't know if that is covered in the documentation.

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

Re: Removing Catalog Entries for Datasets That Do Not Exist

[Dyck, Lionel B. (TRA)]

Why not use IEHPROGM to do the uncatalog

//UNCAT  EXEC PGM=IEHPROGM
//SYSPRINT  DD SYSOUT=*
//SYSIN DD *
  UNCATLG DSNAME=name
/*

--
Lionel B. Dyck 
Mainframe Systems Programmer - TRA

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rodatz, William J
Sent: Monday, August 21, 2017 6:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Removing Catalog Entries for Datasets That Do Not Exist

Hi,

I want to thank everyone who responded to my inquiry regarding the deletion of 
migrated datasets.  It looks like all of the responses have suggested using 
IDCAMS with the DELETE and NOSCRATCH control statements.  I tried that last 
week.  I ran the job again this morning.  Below is the job log and the control 
statements I used.  As you can see, a call is made to DFHSM to do a recall 
prior to deletion.

DELETE -
 EH.FP78.RESBHSFL -
 NOSCRATCH -
 NONVSAM


ICH70001I WR99900  LAST ACCESS AT 05:52:53 ON MONDAY, AUGUST 21, 2017
 $HASP373 IDCAMS1  STARTED - INIT D- CLASS Y- SYS 9121
 IEF403I IDCAMS1 - STARTED - TIME=05.57.52  ARC0050A DFSMSHSM IS NOT ACTIVE - 
START DFSMSHSM  ARC0051A JOB IDCAMS1  WAITING FOR DFSMSHSM TO RECALL 
DSN=EH.FP78.RESBHSFL
*06 ARC0055A REPLY 'GO' OR 'CANCEL'

Thanks again for the responses.

Bill

-Original Message-

From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rodatz, William J

Sent: Friday, August 18, 2017 10:41 AM

To: IBM-MAIN@LISTSERV.UA.EDU

Subject: Removing Catalog Entries for Datasets That Do Not Exist



Hello Everyone,



Recently I discovered some datasets with "MIGRAT" as the volser.  These 
datasets had been migrated with DFHSM many years ago.  My organization is no 
longer running the product.  I am attempting to remove the dangling catalog 
entries which appears to be challenging.  The pubs say to use IEHPROGM with the 
SCRATCH function if (1) the dataset is non-SMS managed and (2) you know the 
dataset's volser prior to migration.  I don't what the original volser was and 
I don't know why it matters.  The catalog entry has only the dataset name and 
"MIGRAT" for the volser.



When I execute IEHPROGM, I get messages denoting that DFHSM is not active.  I 
am unable to move past this point.



Does anyone have an idea how the catalog entries can be removed?  Any input 
would be greatly appreciated.



Thank you.



Bill


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

Removing Catalog Entries for Datasets That Do Not Exist

[Rodatz, William J]

Hi,

I want to thank everyone who responded to my inquiry regarding the deletion of 
migrated datasets.  It looks like all of the responses have suggested using 
IDCAMS with the DELETE and NOSCRATCH control statements.  I tried that last 
week.  I ran the job again this morning.  Below is the job log and the control 
statements I used.  As you can see, a call is made to DFHSM to do a recall 
prior to deletion.

DELETE -
 EH.FP78.RESBHSFL -
 NOSCRATCH -
 NONVSAM


ICH70001I WR99900  LAST ACCESS AT 05:52:53 ON MONDAY, AUGUST 21, 2017
 $HASP373 IDCAMS1  STARTED - INIT D- CLASS Y- SYS 9121
 IEF403I IDCAMS1 - STARTED - TIME=05.57.52
 ARC0050A DFSMSHSM IS NOT ACTIVE - START DFSMSHSM
 ARC0051A JOB IDCAMS1  WAITING FOR DFSMSHSM TO RECALL DSN=EH.FP78.RESBHSFL
*06 ARC0055A REPLY 'GO' OR 'CANCEL'

Thanks again for the responses.

Bill

-Original Message-

From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rodatz, William J

Sent: Friday, August 18, 2017 10:41 AM

To: IBM-MAIN@LISTSERV.UA.EDU

Subject: Removing Catalog Entries for Datasets That Do Not Exist



Hello Everyone,



Recently I discovered some datasets with "MIGRAT" as the volser.  These 
datasets had been migrated with DFHSM many years ago.  My organization is no 
longer running the product.  I am attempting to remove the dangling catalog 
entries which appears to be challenging.  The pubs say to use IEHPROGM with the 
SCRATCH function if (1) the dataset is non-SMS managed and (2) you know the 
dataset's volser prior to migration.  I don't what the original volser was and 
I don't know why it matters.  The catalog entry has only the dataset name and 
"MIGRAT" for the volser.



When I execute IEHPROGM, I get messages denoting that DFHSM is not active.  I 
am unable to move past this point.



Does anyone have an idea how the catalog entries can be removed?  Any input 
would be greatly appreciated.



Thank you.



Bill


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

Re: AXR address space

[Richards, Robert B.]

In 2.2, the P AXR is all that is needed. It automatically shuts down the 
subtasks.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lucas Rosalen
Sent: Monday, August 21, 2017 6:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AXR address space

Hey Bob,

Exactly!
In one of my current customer's system right now we have AXR, AXR01 and AXR04. 
running.
That's exactly the reasion we use INGLKUP function to "grab and stop whatever 
is not in automation" first; then P AXR.
We're also z/OS 2.2.

Thanks,



---
*Lucas Rosalen*
Emails: rosalen.lu...@gmail.com / *lrosa...@pl.ibm.com
*
LinkedIn: http://br.linkedin.com/in/lrosalen
Phone: +48 (71) 792 809 198


2017-08-21 12:22 GMT+02:00 Richards, Robert B. :

> Issue the following command and you may be surprised to see  that 
> there is a subtask below AXR itself:
>
>  D A,AXR*
>
> Result on my system (z/OS 2.2):
>
>   JOBS M/STS USERSSYSASINITS   ACTIVE/MAX VTAM OAS
>  00014001415  00046000345/00060   00093
>   AXR  AXR  IEFPROC  NSW  *   A=001A   PER=NO   SMC=000
>   PGN=N/A  DMN=N/A  AFF=NONE
>   CT=000.071S  ET=00526.49
>   WKL=SYSTEM   SCL=SYSSTC   P=1
>   RGP=N/A  SRVR=NO  QSC=NO
>   ADDR SPACE ASTE=0F611680
>   DSPNAME=AXRTRDSP ASTE=6FFD7680
>   DSPNAME=AXRRXENV ASTE=0EA9F880
>   DSPNAME=AXRREQCP ASTE=0EDA2D80
>   AXR01AXR01 OWT  *   A=0100   PER=NO   SMC=000
>   PGN=N/A  DMN=N/A  AFF=NONE
>   CT=000.021S  ET=00428.23
>   WUID=S0105831 USERID=AXR
>   WKL=SYSTEM   SCL=SYSSTC   P=1
>   RGP=N/A  SRVR=NO  QSC=NO
>   ADDR SPACE ASTE=0F615000
>
> IIRC, try stopping AXR0n first, then AXR. And if you are at z/OS 2.2 , 
> the P AXR is sufficient in and of itself.
>
> Bob
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Gilson Cesar de Oliveira
> Sent: Friday, August 18, 2017 12:55 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: AXR address space
>
>
> Dear list:
>
> I'd like to know how to stop the AXR address space without using the 
> CANCEL command??
>
> I already tried with STOP but it didn't work.
>
> Any clues??
>
>
> Thanks in advance for any help.
>
> Regards,
>
> Gilson
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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

Re: AXR address space

[Lucas Rosalen]

Hey Bob,

Exactly!
In one of my current customer's system right now we have AXR, AXR01 and
AXR04. running.
That's exactly the reasion we use INGLKUP function to "grab and stop
whatever is not in automation" first; then P AXR.
We're also z/OS 2.2.

Thanks,



---
*Lucas Rosalen*
Emails: rosalen.lu...@gmail.com / *lrosa...@pl.ibm.com
*
LinkedIn: http://br.linkedin.com/in/lrosalen
Phone: +48 (71) 792 809 198


2017-08-21 12:22 GMT+02:00 Richards, Robert B. :

> Issue the following command and you may be surprised to see  that there is
> a subtask below AXR itself:
>
>  D A,AXR*
>
> Result on my system (z/OS 2.2):
>
>   JOBS M/STS USERSSYSASINITS   ACTIVE/MAX VTAM OAS
>  00014001415  00046000345/00060   00093
>   AXR  AXR  IEFPROC  NSW  *   A=001A   PER=NO   SMC=000
>   PGN=N/A  DMN=N/A  AFF=NONE
>   CT=000.071S  ET=00526.49
>   WKL=SYSTEM   SCL=SYSSTC   P=1
>   RGP=N/A  SRVR=NO  QSC=NO
>   ADDR SPACE ASTE=0F611680
>   DSPNAME=AXRTRDSP ASTE=6FFD7680
>   DSPNAME=AXRRXENV ASTE=0EA9F880
>   DSPNAME=AXRREQCP ASTE=0EDA2D80
>   AXR01AXR01 OWT  *   A=0100   PER=NO   SMC=000
>   PGN=N/A  DMN=N/A  AFF=NONE
>   CT=000.021S  ET=00428.23
>   WUID=S0105831 USERID=AXR
>   WKL=SYSTEM   SCL=SYSSTC   P=1
>   RGP=N/A  SRVR=NO  QSC=NO
>   ADDR SPACE ASTE=0F615000
>
> IIRC, try stopping AXR0n first, then AXR. And if you are at z/OS 2.2 , the
> P AXR is sufficient in and of itself.
>
> Bob
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Gilson Cesar de Oliveira
> Sent: Friday, August 18, 2017 12:55 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: AXR address space
>
>
> Dear list:
>
> I'd like to know how to stop the AXR address space without using the
> CANCEL command??
>
> I already tried with STOP but it didn't work.
>
> Any clues??
>
>
> Thanks in advance for any help.
>
> Regards,
>
> Gilson
>
> --
> 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: grabbing JES output via FTP

[Robert Hansel]

Hi Tony,

The article "FTP and JES" in the April 2010 edition of our RSH RACF Tips 
newsletter might be of help.

http://www.rshconsulting.com/racftips/RSH_Consulting__RACF_Tips__April_2010.pdf

Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc. *** Celebrating our 25th Year ***
617-969-8211
www.linkedin.com/in/roberthansel
http://twitter.com/RSH_RACF
www.rshconsulting.com

Upcoming RSH RACF Training - WebEx
- RACF Audit & Compliance Roadmap - SEPT 11-15, 2017
- RACF Level I Administration - DEC 5-8, 2017
- RACF Level II Administration - NOV 13-17, 2017
- RACF Level III Admin, Audit, & Compliance - OCT 2-6, 2017
- RACF - Securing z/OS UNIX  - OCT 23-27, 2017



-Original Message-
Date:Sat, 19 Aug 2017 21:34:57 -0400
From:Tony Thigpen 
Subject: grabbing JES output via FTP

I am attempting to use FTP under VM to grab some job output from JES2. I 
am getting a strange error that I don't know where to start trying to 
resolve it. I also get the same messages when I try to ftp from a local pc.

Command:
site filetype=jes
 >>>SITE filetype=jes
200 SITE command was accepted
Command:
get JOB01106.2
 >>>EPRT |1|10.10.50.141|1170|
500 unknown command EPRT
 >>>PORT 10,10,50,141,4,146
200 Port request OK.
 >>>RETR JOB01106.2
451 Nlst failed due to internal error
Command:


thoughts?

-- 
Tony Thigpen

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

Re: AXR address space

[Richards, Robert B.]

Issue the following command and you may be surprised to see  that there is a 
subtask below AXR itself:

 D A,AXR*

Result on my system (z/OS 2.2):

  JOBS M/STS USERSSYSASINITS   ACTIVE/MAX VTAM OAS 
 00014001415  00046000345/00060   00093
  AXR  AXR  IEFPROC  NSW  *   A=001A   PER=NO   SMC=000
  PGN=N/A  DMN=N/A  AFF=NONE   
  CT=000.071S  ET=00526.49 
  WKL=SYSTEM   SCL=SYSSTC   P=1
  RGP=N/A  SRVR=NO  QSC=NO 
  ADDR SPACE ASTE=0F611680 
  DSPNAME=AXRTRDSP ASTE=6FFD7680   
  DSPNAME=AXRRXENV ASTE=0EA9F880   
  DSPNAME=AXRREQCP ASTE=0EDA2D80   
  AXR01AXR01 OWT  *   A=0100   PER=NO   SMC=000
  PGN=N/A  DMN=N/A  AFF=NONE   
  CT=000.021S  ET=00428.23 
  WUID=S0105831 USERID=AXR 
  WKL=SYSTEM   SCL=SYSSTC   P=1
  RGP=N/A  SRVR=NO  QSC=NO 
  ADDR SPACE ASTE=0F615000 

IIRC, try stopping AXR0n first, then AXR. And if you are at z/OS 2.2 , the P 
AXR is sufficient in and of itself.

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gilson Cesar de Oliveira
Sent: Friday, August 18, 2017 12:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AXR address space


Dear list:

I'd like to know how to stop the AXR address space without using the CANCEL 
command??

I already tried with STOP but it didn't work.

Any clues??


Thanks in advance for any help.

Regards,

Gilson

--
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: permissions to /bin/sh

[ITschak Mugzach]

0755 or less

בתאריך 21 באוג 2017 11:12,‏ "R.S."  כתב:

> What is default (suggested, typical) permission to /bin/sh ?
> Of course I mean z/OS UNIX (2.2 if it makes a difference)
> Is it rwxr-xr-t ?
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
> ==
>
>
>--
> Treść tej wiadomości może zawierać informacje prawnie chronione Banku
> przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być
> jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś
> adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej
> przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie,
> rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie
> zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo,
> prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale
> usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub
> zapisane na dysku.
>
> This e-mail may contain legally privileged information of the Bank and is
> intended solely for business use of the addressee. This e-mail may only be
> received by the addressee and may not be disclosed to any third parties. If
> you are not the intended addressee of this e-mail or the employee
> authorized to forward it to the addressee, be advised that any
> dissemination, copying, distribution or any other similar activity is
> legally prohibited and may be punishable. If you received this e-mail by
> mistake please advise the sender immediately by using the reply facility in
> your e-mail software and delete permanently this e-mail including any
> copies of it either printed or saved to hard drive.
>
> mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
> www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy
> XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru
> przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień
> 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi
> 168.955.696 złotych.
>
> --
> 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

permissions to /bin/sh

[R.S.]

What is default (suggested, typical) permission to /bin/sh ?
Of course I mean z/OS UNIX (2.2 if it makes a difference)
Is it rwxr-xr-t ?

--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.
   


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

Re: CONSOLE command failing - what else to check?

[Elardus Engelbrecht]

Joel C. Ewing wrote:

>I seem to remember the CONSOLE command has a way to specify a logical console 
>name (optional NAME parameter on CONSOLE ACTIVATE), and if unspecified the 
>default was based on the RACF userid. 

Yes, I also remember that during my playing with CONSOLE inside a REXX program 
trying to debug a timing problem waiting to receive a message.


> -- you must also avoid console name conflicts.

More true, if you're logged on on several LPARs with same TSO id and having 
tried in SDSF to use 'Extended console name'.

So for example, on LPAR 1, I use 1 as Extended console name, on LPARX, I 
use X, and so on.


>... be sure that user is not running his batch job while holding an activated 
>console session with the same console name under his TSO session.

Ouch, I got burned by that one, quick to fix, but somewhat hard to debug... ;-D

Thanks Joel for sharing your wisdom. Much appreciated.

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

[Crispin Hugo]

Many thanks

Crispin Hugo
Systems Specialist
Macro 4 Limited
d: +44 1293 872121 | m: +44 7753951308 | t: +44 1293 872000 | www.macro4.com

      

Registered office: The Orangery, Turners Hill Road, Worth, Crawley, West 
Sussex, RH10 4SS
Registered in England no: 00927588

Please consider the environment and only print this email if you really need to.

This message (including any attachments) contains confidential information that 
is PRIVILEGED, CONFIDENTIAL and/or ATTORNEY WORK PRODUCT and is intended only 
for the individual(s) named herein. If you are not the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of this 
email is strictly prohibited. If you have received this message in error, 
please notify the Macro 4 Postmaster (postmas...@macro4.com) of the error 
immediately, do not read or use the email and any attachments in any manner, 
destroy all copies, and delete it from your system if the communication was 
sent via email. Macro 4 Limited, Tel: +44 1293 872000 Fax: +44 1293 872001.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lucas Rosalen
Sent: 21 August 2017 08:20
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM z14 availability

Planned GA is Sep 13th

---
*Lucas Rosalen*
Emails: rosalen.lu...@gmail.com / *lrosa...@pl.ibm.com
*
LinkedIn: http://br.linkedin.com/in/lrosalen
Phone: +48 (71) 792 809 198


2017-08-21 9:18 GMT+02:00 Crispin Hugo :

> Can anyone tell me when the z14 is actually available. I know we have 
> the announcement date but when are they actually available
>
> Crispin Hugo
> Systems Specialist
> Macro 4 Limited
> d: +44 1293 872121 | m: +44 7753951308 | t: +44 1293 872000 | 
> www.macro4.com
>
>
>
> Registered office: The Orangery, Turners Hill Road, Worth, Crawley, 
> West Sussex, RH10 4SS Registered in England no: 00927588
>
> Please consider the environment and only print this email if you 
> really need to.
>
> This message (including any attachments) contains confidential 
> information that is PRIVILEGED, CONFIDENTIAL and/or ATTORNEY WORK 
> PRODUCT and is intended only for the individual(s) named herein. If 
> you are not the intended recipient, you are hereby notified that any 
> dissemination, distribution or copying of this email is strictly 
> prohibited. If you have received this message in error, please notify 
> the Macro 4 Postmaster (
> postmas...@macro4.com) of the error immediately, do not read or use 
> the email and any attachments in any manner, destroy all copies, and 
> delete it from your system if the communication was sent via email. 
> Macro 4 Limited,
> Tel: +44 1293 872000 Fax: +44 1293 872001.
>
>
>
> --
> This e-mail message has been scanned and cleared by Google Message 
> Security and the UNICOM Global security systems. This message is for 
> the named person's use only. If you receive this message in error, 
> please delete it and notify the sender.
>
> --
> 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

-- 
This e-mail message has been scanned and cleared by Google Message Security 
and the UNICOM Global security systems. This message is for the named 
person's use only. If you receive this message in error, please delete it 
and notify the sender. 

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

Re: IBM z14 availability

[Lucas Rosalen]

Planned GA is Sep 13th

---
*Lucas Rosalen*
Emails: rosalen.lu...@gmail.com / *lrosa...@pl.ibm.com
*
LinkedIn: http://br.linkedin.com/in/lrosalen
Phone: +48 (71) 792 809 198


2017-08-21 9:18 GMT+02:00 Crispin Hugo :

> Can anyone tell me when the z14 is actually available. I know we have the
> announcement date but when are they actually available
>
> Crispin Hugo
> Systems Specialist
> Macro 4 Limited
> d: +44 1293 872121 | m: +44 7753951308 | t: +44 1293 872000 |
> www.macro4.com
>
>
>
> Registered office: The Orangery, Turners Hill Road, Worth, Crawley, West
> Sussex, RH10 4SS
> Registered in England no: 00927588
>
> Please consider the environment and only print this email if you really
> need to.
>
> This message (including any attachments) contains confidential information
> that is PRIVILEGED, CONFIDENTIAL and/or ATTORNEY WORK PRODUCT and is
> intended only for the individual(s) named herein. If you are not the
> intended recipient, you are hereby notified that any dissemination,
> distribution or copying of this email is strictly prohibited. If you have
> received this message in error, please notify the Macro 4 Postmaster (
> postmas...@macro4.com) of the error immediately, do not read or use the
> email and any attachments in any manner, destroy all copies, and delete it
> from your system if the communication was sent via email. Macro 4 Limited,
> Tel: +44 1293 872000 Fax: +44 1293 872001.
>
>
>
> --
> This e-mail message has been scanned and cleared by Google Message Security
> and the UNICOM Global security systems. This message is for the named
> person's use only. If you receive this message in error, please delete it
> and notify the sender.
>
> --
> 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

IBM z14 availability

[Crispin Hugo]

Can anyone tell me when the z14 is actually available. I know we have the 
announcement date but when are they actually available

Crispin Hugo
Systems Specialist
Macro 4 Limited
d: +44 1293 872121 | m: +44 7753951308 | t: +44 1293 872000 | www.macro4.com

      

Registered office: The Orangery, Turners Hill Road, Worth, Crawley, West 
Sussex, RH10 4SS
Registered in England no: 00927588

Please consider the environment and only print this email if you really need to.

This message (including any attachments) contains confidential information that 
is PRIVILEGED, CONFIDENTIAL and/or ATTORNEY WORK PRODUCT and is intended only 
for the individual(s) named herein. If you are not the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of this 
email is strictly prohibited. If you have received this message in error, 
please notify the Macro 4 Postmaster (postmas...@macro4.com) of the error 
immediately, do not read or use the email and any attachments in any manner, 
destroy all copies, and delete it from your system if the communication was 
sent via email. Macro 4 Limited, Tel: +44 1293 872000 Fax: +44 1293 872001.



-- 
This e-mail message has been scanned and cleared by Google Message Security 
and the UNICOM Global security systems. This message is for the named 
person's use only. If you receive this message in error, please delete it 
and notify the sender. 

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