Re: RMM tape movement to vault

[Joe Testa]

Jake,

RMM uses a Vital Record Specification (VRS) to control tape movement from one 
location to another.  A VRS can be defined with many attributes to select the 
criteria for moving tapes.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jake Anderson
Sent: Monday, November 30, 2020 2:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RMM tape movement to vault

Hello

I apologise for the dummy question as I am new to Tape DFRMM

We have a job which searches the RMM catalog for the tape to be in drive and 
vault.

Some questions popped out in my mind. How does RMM decides that a particular 
tape has to be moved to VAULT and how does it know that tape must be moved from 
VAULT to Tape drive .

Please help me to understand how this works out .

Regards
Jake

--
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: Need help with ISPF Dialogue Manager and VGET

[Joe Testa]

Yes, you need VDEFINEs to map the ISPF dialog variable names to storage 
locations in your Assembler program, so that VGET knows where to save the data 
it gets.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Beverly Caldwell
Sent: Wednesday, August 1, 2018 2:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Need help with ISPF Dialogue Manager and VGET

Well, you are almost there, Paul. You seem to have the hang of this. What do 
you need, someone to write it for you?

On Mon, Jul 30, 2018 at 1:45 PM, esst...@juno.com  wrote:

> Hello,
> .
> I need some clarification on using the ISPF VGET Service in an 
> Assembler Program, the examples I've found were not much help.
> .
> .
> I have a CLIST which issues a VPUT for three Fields Name, City,  
> STATE. These variable are placed on the SHARED POOL.
> The CLIST then invokes an Assembler Program which should issue a VGET 
> for the three variables and write them to a VSAM dataset.
> .
> In the examples I found I never see the Variables for the VGET defined 
> in the program.
> .
> I suspect I need to first issue a VDEFINE, with a Name List, Variable 
> list, Format List and Length List  prior to issuing the VGET.
> .
> THE VGET SERVICE only identifies a name-list like NAME-LIST EQU *
>   DC  A(3)
>   DC  A(0)
>   DC  CL8'NAME '
>   DC  CL8'CITY '
>   DC  CL8'STATE'
> .
> Do I need to issue a VDEFINE first  for the Variables specified in the 
> VGET. Would someone please clarify 
> .
> .
> Paul
> .
> .
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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

Re: An explanation for branch performance?

[Joe Testa]

There seems to be little point worrying about the time needed to branch past an 
eyecatcher at the start of a program, compared to the time used by the rest of 
the program.


From: Mike Schwab 
Sent: Friday, April 29, 2016 10:27 AM
Newsgroups: bit.listserv.ibm-main
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: An explanation for branch performance?

Well, the obvious solution is to code the eyecatcher literals before
the entry point.  It will be less obvious that the eyecatcher is part
of the program (and not the end of the previous program) but as the
technique become more widespread it should become more trusted.

On Fri, Apr 29, 2016 at 9:13 AM, David Crayford  wrote:
> On 29/04/2016 10:09 PM, Mike Schwab wrote:
>>
>> The pipeline is optimized for running many instructions in a row.  A
>> branch is not recognized until through a good part of the pipeline.
>> Meanwhile the data to be skipped is in the instruction pipeline.
>>
>> Results meet expectations.
>
>
> So branching over eyecatchers is expected to be x2 slower on a z13 than a
> z114? I was always lead to believe that new hardware always ran old code
> faster unless it was doing nasty stuff like storing into the instruction
> stream.
>
>
>>
>> On Fri, Apr 29, 2016 at 7:40 AM, David Crayford 
>> wrote:
>>>
>>> We're doing some performance work on our assembler code and one of my
>>> colleagues ran the following test which was surprising. Unconditional
>>> branching can add significant overhead. I always believed that
>>> conditional
>>> branches were expensive because the branch predictor needed to do more
>>> work
>>> and unconditional branches were easy to predict. Does anybody have an
>>> explanation for this. Our machine is z114. It appears that it's even
>>> worse
>>> on a z13.
>>>
>>> Here's the code.
>>>
>>> I wrote a simple program - it tight loops 1 billion times
>>>
>>>
>>>   L R4,=A(1*1000*1000*1000)
>>>   LTR   R4,R4
>>>   J LOOP
>>> *
>>> LOOP DS   0D  .LOOP START
>>>   B NEXT
>>>
>>> NEXT JCT   R4,LOOP
>>>
>>> The loop starts with a branch ... I tested it twice - when the CC is
>>> matched
>>> (branch happens) and when it is not matched (falls through)
>>>
>>> 1. When the CC is matched and branching happens, CPU TIME=2.94 seconds
>>> 2. When the CC is not matched the code falls through, CPU TIME=1.69
>>> seconds
>>> - a reduction of 42%
>>>
>>> --
>>> 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



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

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

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

Re: Split screen ISPF edit copy?

[Joe Testa]

CLIP and GLUE



-Original Message- 
From: John McKown

Sent: Tuesday, June 23, 2015 12:40 PM Newsgroups: bit.listserv.ibm-main
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Split screen ISPF edit copy?

On Tue, Jun 23, 2015 at 11:24 AM, Charles Mills charl...@mcn.org wrote:


In a split screen ISPF session, with two edit logical screens open, is it
possible to do a line command CC/A type copy from one logical screen to 
the

other? That is, it does not seem to work. Is there some option I can turn
on
to enable it, or some trick to it?



​Sorry, Outta Luck on that. From what I can see, each ISPF edit instance
had its own buffers and there is no direct buffer to buffer copy.

I know I can do a command line CUT and PASTE but I have a lot of edits to
do
where a basic CC/A type copy would be more convenient.



​CUT and PASTE seem to be it for this function.





Charles



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

My sister opened a computer store in Hawaii. She sells C shells down by the
seashore.
If someone tell you that nothing is impossible:
Ask him to dribble a football.

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

10 to the 12th power microphones = 1 Megaphone

Maranatha! 
John McKown

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


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

Re: Split screen ISPF edit copy?

[Joe Testa]

Scratch that ... these seem to be local macros we have here.




-Original Message- 
From: Joe Testa

Sent: Tuesday, June 23, 2015 12:42 PM Newsgroups: bit.listserv.ibm-main
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Split screen ISPF edit copy?

CLIP and GLUE



-Original Message- 
From: John McKown

Sent: Tuesday, June 23, 2015 12:40 PM Newsgroups: bit.listserv.ibm-main
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Split screen ISPF edit copy?

On Tue, Jun 23, 2015 at 11:24 AM, Charles Mills charl...@mcn.org wrote:


In a split screen ISPF session, with two edit logical screens open, is it
possible to do a line command CC/A type copy from one logical screen to 
the

other? That is, it does not seem to work. Is there some option I can turn
on
to enable it, or some trick to it?



​Sorry, Outta Luck on that. From what I can see, each ISPF edit instance
had its own buffers and there is no direct buffer to buffer copy.

I know I can do a command line CUT and PASTE but I have a lot of edits to
do
where a basic CC/A type copy would be more convenient.



​CUT and PASTE seem to be it for this function.





Charles



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

My sister opened a computer store in Hawaii. She sells C shells down by the
seashore.
If someone tell you that nothing is impossible:
Ask him to dribble a football.

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

10 to the 12th power microphones = 1 Megaphone

Maranatha! 
John McKown

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

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


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

Re: Stop RELEASE of a tape

[Joe Testa]

From DFSMSrmm Guide and Reference

Changing Pending Actions 
To reclaim volumes: 
  a.. From pending release, use the CHANGEVOLUME subcommand with a volume 
serial number and either the RETPD or EXPDT operands.
-- jat


-Original Message- 
From: Mark Pace 
Sent: Wednesday, May 06, 2015 10:37 AM Newsgroups: bit.listserv.ibm-main 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Stop RELEASE of a tape 

I screwed up and released a tape that I should not have.  I have not yet
run the process that actually puts the tape in SCRATCH status - so
currently it is PENDING RELEASE.

Is there some way to reverse that RELEASE?

-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

--
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: IBM’s reorg-from-Hell launches next week - Cringely

[Joe Testa]

To see the full article, use your favorite search engine and search, WITH 
quotes, for the full article title:


IBM Dismisses Report of Massive Layoffs

then click on the first search result.

-Original Message- 
From: Mark Regan

Sent: Monday, January 26, 2015 4:03 PM Newsgroups: bit.listserv.ibm-main
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM’s reorg-from-Hell launches next week - Cringely

Supposedly IBM is not dismissing the Cringle report and the massive layoffs. 
It was reported in WSJ today.
If you are like me, I don't have a WSJ account, so you will only get to see 
a few lines of the artice.


http://www.wsj.com/articles/ibm-dismisses-report-of-massive-layoffs-1422289059 
Thanks,

Mark Regan, USNR-Ret, 1969-1991

- Original Message -
From: Mark Regan 006f01c0dca1-dmarc-requ...@listserv.ua.edu
To: IBM-MAIN@LISTSERV.UA.EDU
Cc:
Sent: Friday, January 23, 2015 7:53 AM
Subject: IBM’s reorg-from-Hell launches next week - Cringely

http://www.cringely.com/2015/01/22/ibms-reorg-hell-launches-next-week/

Thanks,
Mark Regan, USNR-Ret, 1969-1991


--
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: curious: volsers 6 non-blank chars non-numeric tape

[Joe Testa]

From the JCL reference manual for the DD statement:

[volume] serial-number subparameters (1 - 255):
volume serial numbers (1 - 6
alphanumeric, $, #, @, or special
characters)


-Original Message- 
From: Ken Smith 
Sent: Friday, March 14, 2014 3:43 PM Newsgroups: bit.listserv.ibm-main 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: curious: volsers  6 non-blank chars  non-numeric tape 

Wasn't able to find a architectual requirement for MVS vol sers via search
at IBM.

But can report I just initialized DASD volumes with the names of 'K' and
'0' (zero).  MVS doesn't seem to care but other components might.

Ken

On Fri, Mar 14, 2014 at 2:07 PM, R.S. r.skoru...@bremultibank.com.plwrote:

 W dniu 2014-03-14 18:49, John McKown pisze:

 There is a thread over on TSO-REXX about splitting up a string into
 volume serials. This has occasioned two questions to me.

 1) Has anybody ever had a VOLSER which was not exactly 6 non-blank
 characters for a regularly used volume? Especially any trailing blanks?

 2) Has any commercial shop ever used non-numeric tape volume serials for
 normal in-house tapes? If so, why? I ask because, at least historically,
 CA-1's support of non-number tape serials was difficult (needed some
 sort
 of mapping exit as I recall).

 Just curious.


 2. Yes. We use alphanumeric volsers. Why? Naming convention. BTW: I know
 several shops, including large one which are using letters in volser.

 1. While shorter volume serials are clearly legal and possible, the
 spaces or special characters are simply out of standard, aren't they?

 --
 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 http://www.mbank.pl/, e-mail: kont...@mbank.pl Są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.2014 r. kapitał zakładowy mBanku S.A. (w
 całości wpłacony) wynosi 168.696.052 złote.


 --
 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: Volume Restriction Using an EXIT

[Joe Testa]

Maybe we should prepare him for DELETION (FREEZE).

-Original Message- 
From: mf db

Sent: Wednesday, March 12, 2014 11:26 AM Newsgroups: bit.listserv.ibm-main
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Volume Restriction Using an EXIT

The board is at the end of the month?

??


On Wed, Mar 12, 2014 at 8:55 PM, Micheal Butz 
michealb...@optonline.netwrote:



One more thing
The board is at the end of the month?

Sent from my iPhone

 On Mar 12, 2014, at 11:05 AM, Joel C. Ewing jcew...@acm.org wrote:

 On 03/12/2014 06:53 AM, mf db wrote:
 Hello Group,

 Is there an exit which can help me to restrict a group of ID to access
 another Volume(Which has list of datasets).


 For example : JLAB001 must be restricted to access any dataset sitting
on
 JPM009.


 I am at Z/OS 1.8 level

 Peter

 Your wording is unclear:  Is the object (1) to only grant access to the
 data sets on the specific volume to members of the specific group; or
 (2) to only deny access to the specific volume to members of the
 specific group, or (3) to allow members of the specific group access to
 the volume and its data sets but restrict (deny) their access to any
 other volume,...?  And of course it makes a difference whether one is
 discussing DASD volumes or tape volumes.

 Aside from that and assuming you are talking about DASD volumes and are
 using  SMS (you really should be), managing DASD data set security on a
 volume level is not a good approach.  Restricting new data set
 allocation access on system volsers of course makes sense, but can be
 done with SMS ACS routines and RACF.  In an SMS world, access to
 existing data sets should be a security attribute associated with the
 data set and not dependent on the volume of residence, and restrictions
 on target volumes for new data sets would typically be done by requiring
 all non-system data sets to be under SMS and restricting access to the
 SMS class or STORGRP associated with those volumes.

 Data sets typically need to move at some point during their lifetime and
 their security requirements should go with them;  DASD volume volsers
 and unit addresses may need to change during DASD subsystem hardware
 upgrades, and usually one would want the security of application and
 system data on associated volumes to be unaffected by DASD hardware
 changes.  Data set naming conventions should be  designed so that
 security can be based on the data set name and not on the DASD volume of
 residence.

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

--
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: slightly O/T but interesting

[Joe Testa]

Biometrics not reliable:  at Heathrow Airport they have iris scanners. 
Once when you enter the security area, a second time when you are getting 
ready to go into the gate area.  I didn't match between the first time and 
the second time ... how could that be?  Well, I wear progressive-lens 
glasses.  Different angles, different magnifications.   I spent 10 minutes 
peering into the thing tilting and re-tilting my head to get it to match the 
first scan ... better than being hauled away by security officers ...


-Original Message- 
From: R.S.

Sent: Wednesday, January 23, 2013 10:53 AM Newsgroups: bit.listserv.ibm-main
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: slightly O/T but interesting

W dniu 2013-01-23 15:49, Scott Ford pisze:

It's time for biometrics passwords ...for PCs and mainframes ...


Or other means of security behind passwords. It can be also a token.
In order tolog on you have to provide password and the code displayed by
the token. The token can have a keyboard for PIN entering.
So stolen password is not a problem. Stolen/lost token is not a problem.
Stolen password  token is still not a problem (for tokens with PIN).

Such solution is available for many years, also on z/OS.
The only problem is a cost. Hint: cost of tokens + software/hardware is
not TCO.


BTW: I prefer tokens over biometrics for the following reasons:
1. Biometrics is not reliable. Depending on the method used it could
cause false failures, for example a fingerprint after some injury
cannot be recognized. Same about face recognition (BTDT), etc. So
usually biometrics is backed up with ...regular password.

2. Some biometrics are slooow. I saw room access control system which
had to be disabled, because there were long lines (queues) to the doors.

3. Some biometric devices built in your PC can be hacked, or in other
words, your PC will receive OK from phony device instead of real one.



--
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by 
jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste 
adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej 
przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, 
rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie 
zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, 
prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale 
usun t wiadomo wczajc 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 authorised 
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.


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, 
fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88.
Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w 
caoci wpacony) wynosi 168.555.904 zotych.



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