Re: How can I keep JES2 from being SYSPLEXed?

[Bruce Hewson]

Hi Wendell,

In our production  sysplex we have 6 different JESplexes.

One of those JES2 MASplex uses Checkpoint in the Coupling Facility.

The other 5 all use DASD checkpoint datasets.

Never had any sort of cross sysplex issues.

Regards
Bruce

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

Re: Transmitting SMF records

[Cheryl Watson]

I know that I’m late to this game, but we used to have a free tool to handle 
this called ‘WWUNTERSE’, which has been used by hundreds of people. It is now 
being made available by its original developer, Mario Bezzi, at this link - 
https://www.ap4zlabs.com/free-tools. 

All my best,
Cheryl Watson
==
Cheryl Watson Walker, CEO
Watson & Walker, Inc.
Sarasota, FL USA
www.watsonwalker.com
Cell/Text: 941-266-6609
==

On Jan 27, 2023, at 9:55 PM, Paul Gilmartin 
<042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

On Wed, 25 Jan 2023 20:24:59 +, Andrew N Wilt wrote:

>   ... Apparently, they are able to decipher the RDW records resulting from 
> uploading a RECFM=VBS as a RECFM=U. Unfortunately, at this time, GDKUTIL 
> doesn't have the smarts to parse the bytestream as RDW+data as it is writing 
> to the output data set. That is a current Request For Enhancement, though.
> 
It's not so hard.  The necessary format descriptions are in "Using Data Sets" (I
believe; perhaps also elsewhere.)  Long ago, I did an experiment; a PoC.  IBM
conveniently provided the input data in SMP/E SMPNTS which is exactly such
a bytestream representation of an IEBCOPY-unloaded data set, pax-compressed.
I uncompressed one with pax and allocated it as PATH(...) FILEDATA(BINARY)
RECFM(VB) LRECL(1000) ...  FILEDATA(BINARY) causes the BDW qnd SDW
images to be read as data (with EXECIO).  I was able to reorganize the 1000-byte
chunks into the original blocks.  In that era, EXECIO couldn't handle RECFM(U),
so I tried LMPUT.  First try  failed -- ISPF bug, fixed with APAR. (LMPUT had 
been
unable to deal with RECFM(U) with data above 16 MiB.  The surprising repair was
that LMPUT was changed to copy the data below the line.)  I took the output data
set, overrode RECFM(U) to RECFM=VBS and successfully reconstructed the
PDS with IEBCOPY.

Tthe RFE should provide a set of utilities to convert various DSORGs to simple
bytestreams and back.  They should be pipe-savvy, and FTP client should be made
pipe-savvy to eliminate requirements for temporary data sets.  Better sftp, 
which
is based on ssh, already pipe-savvy.  (But what about restart from broken
connection?)

All forbidden by Conway's Law.

> Sincerely,
> Andrew Wilt
> 
> DFSMSdfp Cloud Data Access Product Owner
> DFSMShsm development

-- 
gil

--
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: JES2 Policy Crafting

[Cheryl Watson]

Mike was the excellent source for that article in our Tuning Letter, and he is 
welcome to share it. Please respect the copyright.

All my best,
Cheryl

On Oct 26, 2023, at 6:25 AM, Mike Shorkend  wrote:

If you have access to SHARE or GSE UK proceedings, I have given a couple of
presentations on the subject. Also an article in Cheryl Watson's Tuning
Letter 2022, Vol 1.
Tom Wasik from IBM has also given some excellent JES2 Policy sessions at
SHARE.

Email me directly if you need more information.

Mike

m...@shorkend.com



On Tue, 24 Oct 2023 at 20:42, Mark Jacobs <
0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:

> Are there any examples or resources that would help in writing JES2
> Policies? I looked at the information in the manuals and it wasn't helpful
> to me.
> 
> Mark Jacobs
> 
> Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted
> email.
> 
> GPG Public Key -
> https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 


-- 
Mike Shorkend
m...@shorkend.com
Tel: +972524208743





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

Cheryl Watson
==
Cheryl Watson Walker, CEO
Watson & Walker, Inc.
Sarasota, FL USA
www.watsonwalker.com
Cell/Text: 941-266-6609
==





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

Re: SMF Interval

[Cheryl Watson]

Hi all,

Yes, 30 minutes was my recommendation for safety. But if it were my shop, I 
would use 15 minutes, but not 5. Here’s my reasoning. My recommendations go out 
to people who are experienced and those who are newbies. When SMF writes its 
records, it’s one of the highest priority tasks. If there are too many records 
to write, it could tie up other tasks needing to free locks, etc. So using 30 
minutes reduces those exposures.

But as several people mentioned, most of the peaks are hidden during 30-minute 
periods. So I would use 15 and make sure that nothing gets locked out during 
syncing. The reason I wouldn’t use 5 minutes is the same reason. I’ve seen too 
many times with a sync of 5 minutes where there is work that is blocked. My 
technique is to use an external monitor or RMF Monitor III at 1 minute 
intervals. The overhead is really minimal.

We have been busy the past few years on CMP, pricing, and new SW/HW, so the 
latest info I have on SMF parameters was in 2015 in a SHARE presentation. You 
can see that at 
https://watsonwalker.s3.us-west-1.amazonaws.com/ww/wp-content/uploads/2016/01/28151211/PR150812a.pdf.
 Alternatively, you can go to 
https://watsonwalker.com/publications/presentations/ and scan down to 2015.

Cheers,
Cheryl

On Dec 29, 2023, at 6:20 PM, Mark Zelden  wrote:

On Fri, 29 Dec 2023 13:57:35 -0600, Mark Zelden mailto:m...@mzelden.com>> wrote:

> On Thu, 28 Dec 2023 21:23:18 -0800, Ed Jaffe  
> wrote:
> 
>> What SMF interval do most folks use?
>> 
> 
> In my experience (from many shops / clients over the years), it matches the 
> RMF interval
> and the most common if 15 minutes.  Second most common is probably 30 (along 
> with
> RMF) but I think most shops moved away from that to go to at least 15 years 
> ago. I have
> seen some use 5 minutes and sometimes IBM will request that for a period of 
> time - perhaps
> for a week to get a more accurate picture for a CP3000 study.   
> 
> This is typically what I use in SMFPRMxx:
> 
> INTVAL(15) 
> SYNCVAL(59)
> 

You didn't way why you wanted to know.  But thinking about this more... I 
though i remembered
Cheryl Watson doing a poll on this once.  I searched her website and saw in 
2008 there was a 3 
part series on SMF / parms and she asked people to send in their parms, but I 
didn't see a follow
up on the results.  She did recommend setting INTVAL(30) and said using 
SYNCVAL(59) was no
longer required and to use SYNCVAL(0). I won't go into the history for why 
people 
started coded SYNVCAL(59) to begin with (she does).  Maybe someone on team 
Cheryl does
have poll results from back then or more recently. 

However she also recommended changing RMF invterval from 15 to 30 to match SMF 
INTVAL (she
previously suggested using RMF interval of 15, SMF INTVAL(30). Partially due to 
the number of 
SMF/RMF Type 74 records from DASD activity from the size of systems at the 
time.  That to me 
makes no sense because even though there is more RMF data to store and process, 
the CPUs 
are much faster, the disk & I/O is much faster and storage is "cheaper", so 
it's all relative. 
I know I'm talking RMF interval now as opposed to your question on SMF INTVAL, 
but 30
minutes is just not granular enough in the large installations I have worked 
in.  Be it for
typical performance report & capacity planning or looking at WLM reports 
(although I use
RMF III or Mainview CMF more for WLM tuning that post processing).  Even in 
small
environments I have always used 15 for both SMF and RMF/CMF.

Back to your question: While I have mostly seen 15 minutes to match RMF / CMF 
15 minutes,
in my personal experiences, 30 minutes is the default and lot of people listen 
to Cheryl's 
advise (because it is good), so without any scientific polling, I'm sure that 
it is still very
common to see INTVAL(30).I just don't agree and have never used anything 
higher
than 15.  

This paper from Scott Chapman of EPS talks about the subject and he agrees with
me that it should be no longer than 15 minutes and that RMF/SMF should be 
synced.  

https://www.pivotor.com/library/content/Chapman_SMFRecommendations_2022.pdf


Best Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html

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

Cheryl Watson
==
Cheryl Watson Walker, CEO
Watson & Walker, Inc.
Sarasota, FL USA
www.watsonwalker.com
Cell/Text: 941-266-6609
==





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

Re: Another Getting away from the mainframe tale

[Steve Beaver]

The more they want to move away the harder it becomes.  

A few years ago Coca-Cola moved to AWS but I have no idea how
They did it possible with Micro-Focus Cobol 



Steve 

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

Re: How can I keep JES2 from being SYSPLEXed?

[Paul Feller]

I'm not sure I have an answer for you at this time.  But I do have a few 
questions.

Are the JES2 checkpoint datasets for the two systems the same name?
Are the VOLSERs the same name?

I don't have access to any z/OS anymore but when I did, we had three different 
JES2 MAS in one sysplex and didn't have any issues.  The checkpoint (and spool 
datasets) datasets had different names and the volumes everything was on had 
different VOLSERs.  We even had a checkpoint structure for each MAS in our CF 
environment.

We had full shared DASD between the different z/OS lpars.


Paul

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Wendell Lovewell
Sent: Friday, January 19, 2024 3:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: How can I keep JES2 from being SYSPLEXed?

I have two systems that I want to share dasd and allow for VSAM RLS between the 
systems, but I don’t want to SYSPLEX JES2.  I have MASDEF SHARED=NOCHECK.  What 
else can I do to un-sysplex JES?  
 
Is it safe to delete the JES2 and/or SYSJES group definitions from XCF?  I 
don't have a JES_CKPT_1 structure defined at all.
 
Background:
 
I’m trying to add a z/OS 3.1 ( S0W1) to a sysplex where z/OS 2.5 
(Z3- S0W3) is running, but ONLY for VSAM RLS.  I don’t want to “plex” 
anything more than is needed for VSAM/RLS—not JES, not SYSLOG, not VTAM, not 
SMF or anything else.   

The systems are running fine stand-alone (each with their own set of disks, 
including the volume with the CDS), but when I try to use the same CDS disk 
between the systems, the first system comes up fine, but JES2 on the system 
brought up last complains that it cannot find the checkpoint datasets of the 
OTHER system: 

Z4  : H *$HASP284 JES2 INITIALIZATION CHECKPOINT DIALOG STARTED
Z4  : H *$HASP277 JES2 CAN NOT FIND OR USE THE CHECKPOINT DATA SET(S)
Z4  : H   THAT WERE IN USE WHEN THE MAS WAS LAST ACTIVE BECAUSE 
VOLUME
Z4  : H   FOR CKPT1 NOT MOUNTED
Z4  : H *
Z4  : H   CURRENT CHECKPOINT VALUES:
Z4  : H   CKPT1=(DSNAME=SYS1.HASPCKPT,VOLSER=B5SYS1,INUSE=YES),
Z4  : H   CKPT2=(DSNAME=SYS1.HASPCKP2,VOLSER=B5CFG1,INUSE=YES)
Z4  : H *
Z4  : H   VALID RESPONSES ARE:
Z4  : HCKPT1=...  - UPDATE CURRENT CHECKPOINT SPECIFICATION WITH
Z4  : HCKPT2=...THE VALUES USED WHEN JES2 MAS WAS LAST 
ACTIVE
Z4  : H'RECONFIG' - THE CHECKPOINT DATA SET(S) THAT WERE IN USE
Z4  : H WHEN JES2 WAS LAST ACTIVE ARE NO LONGER
Z4  : H AVAILABLE (ALL-MEMBER WARM START ONLY)
Z4  : H'CONT' - ATTEMPT INITIALIZATION WITH THE VALUES 
LISTED
Z4  : H'TERM' - TERMINATE JES2 INITIALIZATION ON THIS MEMBER
Z4  : H *04 $HASP272 ENTER RESPONSE (ISSUE D R,MSG=$HASP277 FOR RELATED MSG)

"Z4" is the z/OS 3.1 system.  The “B5SYS1” and “B5CFG1” volumes belong to the 
z/OS 2.5 system.  If I bring up z/OS 3.1 with z/OS 2.5 down and then try to 
bring up z/OS 2.5, the same message is displayed except it identifies the 
volumes belonging to the other system.

I can RECONFIG with the correct CKPT volumes, but it always ends with:

Z4  :  $HASP478 INITIAL CHECKPOINT READ IS FROM CKPT1
Z4  :   (SYS1.HASPCKPT ON A3SYS1)
Z4  :   LAST WRITTEN THURSDAY, 18 JAN 2024 AT 21:57:08 (GMT)

Z4  :  $HASP792 JES2 HAS JOINED XCF GROUP JES2 THAT INCLUDES ACTIVE MEMBERS
Z4  :   THAT ARE NOT PART OF THIS MAS
Z4  :   MEMBER=JES2$S0W3,REASON=DIFFERENT COLD START TIME

Z4  :  $HASP428 CORRECT THE ABOVE PROBLEMS AND RESTART JES2
Z4  :  IXZ0002I CONNECTION TO JESXCF COMPONENT DISABLED,
Z4  :   GROUP JES2 MEMBER JES2$S0W1
Z4  :  $HASP9085 JES2 MONITOR ADDRESS SPACE STOPPED FOR JES2
Z4  :  $HASP085 JES2 TERMINATION COMPLETE

Like I said, I don't want a MAS at all--each JES2 should be separate.  


(This has already gone too long, but here are some displays that might help:)

Both JES parms use the same MASDEF definition: 
MASDEF   SHARED=NOCHECK,   
 CKPTLOCK=INFORM,  
 RESTART=NO,   
 DORMANCY=(25,300),
 HOLD=10,  
 LOCKOUT=1200  
 
Z3 $dmasdef  (If other system is down, after a cold start.)
   $HASP843 MASDEF
> $HASP843 MASDEF  OWNMEMB=S0W3,AUTOEMEM=OFF,CKPTLOCK=INFORM,
   $HASP843 COLDTIME=(2022.313,18:50:45),COLDVRSN=z/OS 2.5,
   $HASP843 ENFSCOPE=SYSPLEX,DORMANCY=(25,300),HOLD=10,
> $HASP843 LOCKOUT=1200,RESTART=NO,SHARED=NOCHECK,  <==
   $HASP843 SYNCTOL=120,WARMTIME=(2024.018,22:05:36),
   $HASP843 XCFGRPNM=JES2,QREBUILD=0,CYCLEMGT=MANUAL,
   $HASP843 ESUBSYS=HASP

Z4 $DMASDEF  (If other system is down, after a cold start.)
Z4  :  $HASP843 MASDEF
Z4  :  $HASP843 MASDEF  OWNMEMB=S0W1,AUTOEMEM=OFF,CKPTLOCK=INFORM,
Z4  :  $HASP843 

Re: ADRDSSU COMPRESS and enq

[Radoslaw Skorupka]

Yes, I'm aware of this method, thank you for mentioning it.
However that way does not allow generics.
Obviously I could create some REXX script for that, but I don't want to 
reinvent the wheel.


--

Radoslaw Skorupka
Lodz, Poland




W dniu 19.01.2024 o 19:42, Matthew Stitt pisze:

I"ve used IEBCOPY with DISP=SHR and VOL=SER with no issues for years.

Matthew Stitt

On Fri, 19 Jan 2024 17:31:46 +, Ituriel do 
Neto  wrote:


BYPASSNQ program ?


Best Regards

Ituriel do Nascimento Neto
z/OS System Programmer
Hi Radek,
- Run ICKDSF to take the VTOC out of Indexed Format (BUILDOS)
- ZAP the VTOC  (i.e. FORMAT4.DSCB) to change the DSNAME to something
innocuous.
- Compress via IEBCOPY
- ZAP the DSNAME to SYS1.LINKLIB
- Run ICKDSF to put the VTOC into Indexed Format (BUILDIX)

I've done this, but, not recently.

Here is an article where someone else came up with the same idea:
Deleting a File That Is “In Use” | Steve Baugh - The CICS Guy
(wordpress.com)


Regards,
David

On 2024-01-19 07:27, Radoslaw Skorupka wrote:

I want to compress some system datasets like SYS1.LINKLIB, but *not*
real "live", rather offline copies.
DSS ends with RC8, because of failed serialization.
SETPROG LNKLST,UNALLOCATE will not solve all the enqueues, because
some datasets are serialized by other entities like TSO users.

And I also want to CONSOLIDATE some datasets as well.


Any clue?


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

How can I keep JES2 from being SYSPLEXed?

[Wendell Lovewell]

I have two systems that I want to share dasd and allow for VSAM RLS between the 
systems, but I don’t want to SYSPLEX JES2.  I have MASDEF SHARED=NOCHECK.  What 
else can I do to un-sysplex JES?  
 
Is it safe to delete the JES2 and/or SYSJES group definitions from XCF?  I 
don't have a JES_CKPT_1 structure defined at all.
 
Background:
 
I’m trying to add a z/OS 3.1 ( S0W1) to a sysplex where z/OS 2.5 
(Z3- S0W3) is running, but ONLY for VSAM RLS.  I don’t want to “plex” 
anything more than is needed for VSAM/RLS—not JES, not SYSLOG, not VTAM, not 
SMF or anything else.   

The systems are running fine stand-alone (each with their own set of disks, 
including the volume with the CDS), but when I try to use the same CDS disk 
between the systems, the first system comes up fine, but JES2 on the system 
brought up last complains that it cannot find the checkpoint datasets of the 
OTHER system: 

Z4  : H *$HASP284 JES2 INITIALIZATION CHECKPOINT DIALOG STARTED
Z4  : H *$HASP277 JES2 CAN NOT FIND OR USE THE CHECKPOINT DATA SET(S)
Z4  : H   THAT WERE IN USE WHEN THE MAS WAS LAST ACTIVE BECAUSE 
VOLUME
Z4  : H   FOR CKPT1 NOT MOUNTED
Z4  : H *
Z4  : H   CURRENT CHECKPOINT VALUES:
Z4  : H   CKPT1=(DSNAME=SYS1.HASPCKPT,VOLSER=B5SYS1,INUSE=YES),
Z4  : H   CKPT2=(DSNAME=SYS1.HASPCKP2,VOLSER=B5CFG1,INUSE=YES)
Z4  : H *
Z4  : H   VALID RESPONSES ARE:
Z4  : HCKPT1=...  - UPDATE CURRENT CHECKPOINT SPECIFICATION WITH
Z4  : HCKPT2=...THE VALUES USED WHEN JES2 MAS WAS LAST 
ACTIVE
Z4  : H'RECONFIG' - THE CHECKPOINT DATA SET(S) THAT WERE IN USE
Z4  : H WHEN JES2 WAS LAST ACTIVE ARE NO LONGER
Z4  : H AVAILABLE (ALL-MEMBER WARM START ONLY)
Z4  : H'CONT' - ATTEMPT INITIALIZATION WITH THE VALUES 
LISTED
Z4  : H'TERM' - TERMINATE JES2 INITIALIZATION ON THIS MEMBER
Z4  : H *04 $HASP272 ENTER RESPONSE (ISSUE D R,MSG=$HASP277 FOR RELATED MSG)

"Z4" is the z/OS 3.1 system.  The “B5SYS1” and “B5CFG1” volumes belong to the 
z/OS 2.5 system.  If I bring up z/OS 3.1 with z/OS 2.5 down and then try to 
bring up z/OS 2.5, the same message is displayed except it identifies the 
volumes belonging to the other system.

I can RECONFIG with the correct CKPT volumes, but it always ends with:

Z4  :  $HASP478 INITIAL CHECKPOINT READ IS FROM CKPT1
Z4  :   (SYS1.HASPCKPT ON A3SYS1)
Z4  :   LAST WRITTEN THURSDAY, 18 JAN 2024 AT 21:57:08 (GMT)

Z4  :  $HASP792 JES2 HAS JOINED XCF GROUP JES2 THAT INCLUDES ACTIVE MEMBERS
Z4  :   THAT ARE NOT PART OF THIS MAS
Z4  :   MEMBER=JES2$S0W3,REASON=DIFFERENT COLD START TIME

Z4  :  $HASP428 CORRECT THE ABOVE PROBLEMS AND RESTART JES2
Z4  :  IXZ0002I CONNECTION TO JESXCF COMPONENT DISABLED,
Z4  :   GROUP JES2 MEMBER JES2$S0W1
Z4  :  $HASP9085 JES2 MONITOR ADDRESS SPACE STOPPED FOR JES2
Z4  :  $HASP085 JES2 TERMINATION COMPLETE

Like I said, I don't want a MAS at all--each JES2 should be separate.  


(This has already gone too long, but here are some displays that might help:)

Both JES parms use the same MASDEF definition: 
MASDEF   SHARED=NOCHECK,   
 CKPTLOCK=INFORM,  
 RESTART=NO,   
 DORMANCY=(25,300),
 HOLD=10,  
 LOCKOUT=1200  
 
Z3 $dmasdef  (If other system is down, after a cold start.)
   $HASP843 MASDEF
> $HASP843 MASDEF  OWNMEMB=S0W3,AUTOEMEM=OFF,CKPTLOCK=INFORM,
   $HASP843 COLDTIME=(2022.313,18:50:45),COLDVRSN=z/OS 2.5,
   $HASP843 ENFSCOPE=SYSPLEX,DORMANCY=(25,300),HOLD=10,
> $HASP843 LOCKOUT=1200,RESTART=NO,SHARED=NOCHECK,  <==
   $HASP843 SYNCTOL=120,WARMTIME=(2024.018,22:05:36),
   $HASP843 XCFGRPNM=JES2,QREBUILD=0,CYCLEMGT=MANUAL,
   $HASP843 ESUBSYS=HASP

Z4 $DMASDEF  (If other system is down, after a cold start.)
Z4  :  $HASP843 MASDEF
Z4  :  $HASP843 MASDEF  OWNMEMB=S0W1,AUTOEMEM=OFF,CKPTLOCK=INFORM,
Z4  :  $HASP843 COLDTIME=(2024.019,21:00:02),COLDVRSN=z/OS 3.1,
Z4  :  $HASP843 ENFSCOPE=SYSPLEX,DORMANCY=(25,300),HOLD=10,
Z4  :  $HASP843 LOCKOUT=1200,RESTART=NO,SHARED=NOCHECK,   <==
Z4  :  $HASP843 SYNCTOL=120,XCFGRPNM=JES2,QREBUILD=0,
Z4  :  $HASP843 CYCLEMGT=MANUAL,ESUBSYS=HASP

Z3 d xcf,group
   IXC331I  17.49.11  DISPLAY XCF 833
  GROUPS(SIZE): 
  ATRRRS(3)COFVLFNO(2) DSNDPDG(2)
  EZBTCPCS(1)HSFIXC(1)   IDAVQUI0(3)
  IGG0CAS(2)   IGWXSGIS(4)  IOEZFS(2)
> ISTCFS01(1) IXCLO008(2)   JES2(1)   <==
  N1(3)  SYSBPX(2)  SYSDAE(4)
  SYSENF(2) SYSGRS(2)SYSGRS2(1)
  

Re: Another Getting away from the mainframe tale -- Jammed it in Reverse...

[Dave Beagle]

No wonder IBM stock is hitting another new high today.


Sent from Yahoo Mail for iPhone


On Friday, January 19, 2024, 3:44 PM, Steve Thompson  wrote:

They migrated to that mainframe environment as quickly as they 
could.

A reverse Boot Hill story.

Steve Thompson

--
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: Another Getting away from the mainframe tale

[Charles Mills]

LOL. I had a client -- it's been a while now but I still should not mention 
names, but a household name everyone in North America would recognize. They 
embarked on a project to get off the mainframe. They ended up getting rid of 
the SVP whose idea it was instead. Security walked him out the door. (Not for 
that reason, but still, it was enjoyable vindication for the mainframe tech 
staff.)

CM

On Fri, 19 Jan 2024 20:33:15 +, Pew, Curtis G 
 wrote:

>On Jan 19, 2024, at 1:51 PM, Charles Mills  wrote:
>
>"We're in the 25th year of a 3-year project to get off the mainframe."
>
>We started a five year project to get off the mainframe around 2012 or 2013.
>
>Interestingly, although we haven’t replaced the mainframe, we have replaced 
>all the upper management since then. Current management is a little

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

Re: Another Getting away from the mainframe tale -- Jammed it in Reverse...

[Steve Thompson]

They migrated to that mainframe environment as quickly as they 
could.


A reverse Boot Hill story.

Steve Thompson

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

Re: Another Getting away from the mainframe tale

[Pew, Curtis G]

On Jan 19, 2024, at 1:51 PM, Charles Mills  wrote:

"We're in the 25th year of a 3-year project to get off the mainframe."

We started a five year project to get off the mainframe around 2012 or 2013.

Interestingly, although we haven’t replaced the mainframe, we have replaced all 
the upper management since then. Current management is a little more sensible: 
while getting off the mainframe is still a long term goal, they aren’t setting 
any dates and concede it will be many, many years before it’s gone. Right now 
they seem to be more focused on migrating Unix and Windows servers to AWS or 
Azure.


--
Curtis Pew
ITS Campus Solutions
curtis@austin.utexas.edu




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

Re: Another Getting away from the mainframe tale

[Steve Thompson]

I can't resist this.

A certain Electric Utility asked some consultants about how to 
remediate for Y2K. They were told the best way to do it was to 
migrate off their mainframe to some fad app/language. So they 
made the cut some months before Y2K and reports they had done on 
demand (where do we have xxx Transformer(s) and yyy steel angle 
iron) kind of things so they could repair downed lines after a 
tornado or straight line winds, now had to scheduled a week in 
advance of when they needed them. No joke.


A few years go by and they have a chance to buy out another 
electric utility. And that entity was running on a mainframe. 
Guess what they did next?


Steve Thompson


On 1/19/2024 2:55 PM, Bob Bridges wrote:

Yes, Tim, perennially entertaining.

A client I did some work for a couple years ago has been working on a two-year 
project to dump their mainframe for the past six years; they're still plugging 
away at it.  A year ago they got new a new mainframe box which of course 
involved upgrading z/OS and a bunch of attendant apps.  But it turned out that 
an old app X wouldn't play nice with the new Omegamon, so they had to put the 
new mainframe hardware on the shelf for a while.  I hear they just finished 
replacing app X, and are now (re)embarked on the project to upgrade z/OS and 
all the other stuff and take their shiny new mainframe off the shelf.  I 
haven't yet asked my contacts there how this works with their goal of getting 
rid of the mainframe.




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

Re: ADRDSSU COMPRESS and enq

[Mike Schwab]

If the dataset goes into more extents the refresh won't pick up the new
extent(s) and the member fetch will fail.  Can also reach the maximum
number of extents.

On Fri, Jan 19, 2024 at 9:19 AM Steely.Mark  wrote:

> Unless I am missing something why not use IEBCOPY with specifying DISP=SHR
> on the dataset name.
> I have done this with datasets that were allocated to the LNKLST.
>
> Thanks
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Radoslaw Skorupka
> Sent: Friday, January 19, 2024 8:18 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ADRDSSU COMPRESS and enq
>
>
>
> CAUTION! EXTERNAL SENDER! STOP, ASSESS, AND VERIFY Do you know this
> person? Were you expecting this email? If not, report it using the Report
> Phishing Button!
>
> Gentlemen,
> First, thank you for your answers. I appreciate it.
>
> Regarding TOLENQF - it doesn't work with COMPRESS or CONSOLIDATE. The
> manual is clear here.
>
> Regarding rename - this is the thing I wanted to avoid for several reasons:
> 1. There is some risk to rename wrong "copy" of the dataset, or alter ICF
> entries for wrong copy.
> 2. Valid copies are located on non-SMS disk, but cataloged out of regular
> catalog search (SYS1.name in some UCAT). Plus some aliases, etc.
> I want to not destroy it.
> 3. I don't know how to rename such datasets! Yes, I could imagine access
> from another z/OS image, but it would be a series of manual ISPF r command.
> Non-repeatable, error prone. Is there any tool allowing to rename such
> datasets in batch? Wildcard support (i.e. REN SYS1.* SYS2.*) would be
> welcome.
>
>
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
> W dniu 19.01.2024 o 13:27, Radoslaw Skorupka pisze:
> > I want to compress some system datasets like SYS1.LINKLIB, but *not*
> > real "live", rather offline copies.
> > DSS ends with RC8, because of failed serialization.
> > SETPROG LNKLST,UNALLOCATE will not solve all the enqueues, because
> > some datasets are serialized by other entities like TSO users.
> >
> > And I also want to CONSOLIDATE some datasets as well.
> >
> >
> > Any clue?
> >
>
> --
> 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

Re: Another Getting away from the mainframe tale

[Bob Bridges]

Yes, Tim, perennially entertaining.

A client I did some work for a couple years ago has been working on a two-year 
project to dump their mainframe for the past six years; they're still plugging 
away at it.  A year ago they got new a new mainframe box which of course 
involved upgrading z/OS and a bunch of attendant apps.  But it turned out that 
an old app X wouldn't play nice with the new Omegamon, so they had to put the 
new mainframe hardware on the shelf for a while.  I hear they just finished 
replacing app X, and are now (re)embarked on the project to upgrade z/OS and 
all the other stuff and take their shiny new mainframe off the shelf.  I 
haven't yet asked my contacts there how this works with their goal of getting 
rid of the mainframe.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* The worst thing about new books is that they keep us from reading the old 
ones.  -Joseph Joubert (1754-1824) */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tim 
Ribble
Sent: Friday, January 19, 2024 13:42

Haven't posted here in quite some time but I thought it'd be fun to post 
another "getting off the mainframe" story.  Been working for the City of San 
Antonio for 25 years now.  I started as part of the mainframe staff and that 
was my primary function until 2009 when it was decided to move away from the 
mainframe.  In the intervening years, my primary function moved to 
storage/backup systems which made sense for me since I dealt heavily with 
storage/backup operations on the mainframe and HDS storage.  We were supposed 
to be off the mainframe by 30 Sep 2012 but here we are in 2024 and it's still 
running production applications.  It's just a handful but they're critical.  So 
here I am maintaining both a z/890 & HDS USP-V with no IBM or Hitachi support 
(just hardware support contracts from third party vendors).  I'm now hearing 
we'll be off of it by Nov of this year.  You think I'm going to hold my breath? 
 I may actually retire before it's gone.  Anyway, I just thought this audience 
may be amused by this.

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

Re: Another Getting away from the mainframe tale

[Charles Mills]

"We're in the 25th year of a 3-year project to get off the mainframe."

CM

On Fri, 19 Jan 2024 12:42:11 -0600, Tim Ribble  wrote:

>Greetings all,
>
>Haven't posted here in quite some time but I thought it'd be fun to post
>another "getting off the mainframe" story.  Been working for the City of
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Another Getting away from the mainframe tale

[rpinion865]

2022???  




Sent with Proton Mail secure email.

On Friday, January 19th, 2024 at 2:40 PM, Steve Beaver 
<050e0c375a14-dmarc-requ...@listserv.ua.edu> wrote:


> I was up in Seattle at Pemco insurance. They made the decision to leave the 
> mainframe
> In 1995,
> 
> Well its 2022 and they are still on the mainframe
> 
> 
> 
> Regards,
> 
> 
> Steve
> 
> 
> Steve Thompson
> 
> On 1/19/2024 1:42 PM, Tim Ribble wrote:
> 
> > Greetings all,
> > 
> > Haven't posted here in quite some time but I thought it'd be fun to post
> > another "getting off the mainframe" story. Been working for the City of
> > San Antonio for 25 years now. I started as part of the mainframe staff and
> > that was my primary function until 2009 when it was decided to move away
> > from the mainframe. In the intervening years, my primary function moved to
> > storage/backup systems which made sense for me since I dealt heavily with
> > storage/backup operations on the mainframe and HDS storage. We were
> > supposed to be off the mainframe by 30 Sep 2012 but here we are in 2024 and
> > it's still running production applications. It's just a handful but
> > they're critical. So here I am maintaining both a z/890 & HDS USP-V with
> > no IBM or Hitachi support (just hardware support contracts from third party
> > vendors). I'm now hearing we'll be off of it by Nov of this year. You
> > think I'm going to hold my breath? I may actually retire before it's
> > gone. Anyway, I just thought this audience may be amused by this.
> > 
> > Cheers all,
> > 
> > Tim
> > 
> > --
> > 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: Another Getting away from the mainframe tale

[ITschak Mugzach]

Langsam langsam aber sicher... I saw that here in Israel. It take on a
stage of 15 years.

ITschak

*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **|  *

*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*





בתאריך יום ו׳, 19 בינו׳ 2024 ב-21:40 מאת Steve Beaver <
050e0c375a14-dmarc-requ...@listserv.ua.edu>:

> I was up in Seattle at Pemco insurance.  They made the decision to leave
> the mainframe
> In 1995,
>
> Well its 2022 and they are still on the mainframe
>
>
>
> Regards,
>
>
> Steve
>
>
> Steve Thompson
>
> On 1/19/2024 1:42 PM, Tim Ribble wrote:
> > Greetings all,
> >
> > Haven't posted here in quite some time but I thought it'd be fun to post
> > another "getting off the mainframe" story.  Been working for the City of
> > San Antonio for 25 years now.  I started as part of the mainframe staff
> and
> > that was my primary function until 2009 when it was decided to move away
> > from the mainframe.  In the intervening years, my primary function moved
> to
> > storage/backup systems which made sense for me since I dealt heavily with
> > storage/backup operations on the mainframe and HDS storage.  We were
> > supposed to be off the mainframe by 30 Sep 2012 but here we are in 2024
> and
> > it's still running production applications.  It's just a handful but
> > they're critical.  So here I am maintaining both a z/890 & HDS USP-V with
> > no IBM or Hitachi support (just hardware support contracts from third
> party
> > vendors).  I'm now hearing we'll be off of it by Nov of this year.  You
> > think I'm going to hold my breath?  I may actually retire before it's
> > gone.  Anyway, I just thought this audience may be amused by this.
> >
> > Cheers all,
> >
> > Tim
> >
> > --
> > 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: Another Getting away from the mainframe tale

[Steve Beaver]

I was up in Seattle at Pemco insurance.  They made the decision to leave the 
mainframe
In 1995,

Well its 2022 and they are still on the mainframe



Regards,


Steve 


Steve Thompson

On 1/19/2024 1:42 PM, Tim Ribble wrote:
> Greetings all,
>
> Haven't posted here in quite some time but I thought it'd be fun to post
> another "getting off the mainframe" story.  Been working for the City of
> San Antonio for 25 years now.  I started as part of the mainframe staff and
> that was my primary function until 2009 when it was decided to move away
> from the mainframe.  In the intervening years, my primary function moved to
> storage/backup systems which made sense for me since I dealt heavily with
> storage/backup operations on the mainframe and HDS storage.  We were
> supposed to be off the mainframe by 30 Sep 2012 but here we are in 2024 and
> it's still running production applications.  It's just a handful but
> they're critical.  So here I am maintaining both a z/890 & HDS USP-V with
> no IBM or Hitachi support (just hardware support contracts from third party
> vendors).  I'm now hearing we'll be off of it by Nov of this year.  You
> think I'm going to hold my breath?  I may actually retire before it's
> gone.  Anyway, I just thought this audience may be amused by this.
>
> Cheers all,
>
> Tim
>
> --
> 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: Another Getting away from the mainframe tale

[Steve Thompson]

Since this is a city, any way of getting reports that would allow 
you to see how much it cost to go off their mainframe? And then 
any way to project the cost of now (what ever architecture) to 
say a z14?


I think it could be instructive.

Steve Thompson

On 1/19/2024 1:42 PM, Tim Ribble wrote:

Greetings all,

Haven't posted here in quite some time but I thought it'd be fun to post
another "getting off the mainframe" story.  Been working for the City of
San Antonio for 25 years now.  I started as part of the mainframe staff and
that was my primary function until 2009 when it was decided to move away
from the mainframe.  In the intervening years, my primary function moved to
storage/backup systems which made sense for me since I dealt heavily with
storage/backup operations on the mainframe and HDS storage.  We were
supposed to be off the mainframe by 30 Sep 2012 but here we are in 2024 and
it's still running production applications.  It's just a handful but
they're critical.  So here I am maintaining both a z/890 & HDS USP-V with
no IBM or Hitachi support (just hardware support contracts from third party
vendors).  I'm now hearing we'll be off of it by Nov of this year.  You
think I'm going to hold my breath?  I may actually retire before it's
gone.  Anyway, I just thought this audience may be amused by this.

Cheers all,

Tim

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

Another Getting away from the mainframe tale

[Tim Ribble]

Greetings all,

Haven't posted here in quite some time but I thought it'd be fun to post
another "getting off the mainframe" story.  Been working for the City of
San Antonio for 25 years now.  I started as part of the mainframe staff and
that was my primary function until 2009 when it was decided to move away
from the mainframe.  In the intervening years, my primary function moved to
storage/backup systems which made sense for me since I dealt heavily with
storage/backup operations on the mainframe and HDS storage.  We were
supposed to be off the mainframe by 30 Sep 2012 but here we are in 2024 and
it's still running production applications.  It's just a handful but
they're critical.  So here I am maintaining both a z/890 & HDS USP-V with
no IBM or Hitachi support (just hardware support contracts from third party
vendors).  I'm now hearing we'll be off of it by Nov of this year.  You
think I'm going to hold my breath?  I may actually retire before it's
gone.  Anyway, I just thought this audience may be amused by this.

Cheers all,

Tim

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

Re: ADRDSSU COMPRESS and enq

[Matthew Stitt]

I"ve used IEBCOPY with DISP=SHR and VOL=SER with no issues for years.

Matthew Stitt

On Fri, 19 Jan 2024 17:31:46 +, Ituriel do Neto 
 wrote:

>BYPASSNQ program ?
>
>
>Best Regards
>
>Ituriel do Nascimento Neto
>z/OS System Programmer

>
>Hi Radek,
>- Run ICKDSF to take the VTOC out of Indexed Format (BUILDOS)
>- ZAP the VTOC  (i.e. FORMAT4.DSCB) to change the DSNAME to something 
>innocuous.
>- Compress via IEBCOPY
>- ZAP the DSNAME to SYS1.LINKLIB
>- Run ICKDSF to put the VTOC into Indexed Format (BUILDIX)
>
>I've done this, but, not recently.
>
>Here is an article where someone else came up with the same idea:
>Deleting a File That Is “In Use” | Steve Baugh - The CICS Guy 
>(wordpress.com) 
>
>
>Regards,
>David
>
>On 2024-01-19 07:27, Radoslaw Skorupka wrote:
>> I want to compress some system datasets like SYS1.LINKLIB, but *not* 
>> real "live", rather offline copies.
>> DSS ends with RC8, because of failed serialization.
>> SETPROG LNKLST,UNALLOCATE will not solve all the enqueues, because 
>> some datasets are serialized by other entities like TSO users.
>>
>> And I also want to CONSOLIDATE some datasets as well.
>>
>>
>> Any clue?
>>

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

Re: ADRDSSU COMPRESS and enq

[Ituriel do Neto]

BYPASSNQ program ?


Best Regards

Ituriel do Nascimento Neto
z/OS System Programmer






Em sexta-feira, 19 de janeiro de 2024 às 14:24:02 BRT, David Spiegel 
<0468385049d1-dmarc-requ...@listserv.ua.edu> escreveu: 





Hi Radek,
- Run ICKDSF to take the VTOC out of Indexed Format (BUILDOS)
- ZAP the VTOC  (i.e. FORMAT4.DSCB) to change the DSNAME to something 
innocuous.
- Compress via IEBCOPY
- ZAP the DSNAME to SYS1.LINKLIB
- Run ICKDSF to put the VTOC into Indexed Format (BUILDIX)

I've done this, but, not recently.

Here is an article where someone else came up with the same idea:
Deleting a File That Is “In Use” | Steve Baugh - The CICS Guy 
(wordpress.com) 


Regards,
David

On 2024-01-19 07:27, Radoslaw Skorupka wrote:
> I want to compress some system datasets like SYS1.LINKLIB, but *not* 
> real "live", rather offline copies.
> DSS ends with RC8, because of failed serialization.
> SETPROG LNKLST,UNALLOCATE will not solve all the enqueues, because 
> some datasets are serialized by other entities like TSO users.
>
> And I also want to CONSOLIDATE some datasets as well.
>
>
> Any clue?
>

--
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: ADRDSSU COMPRESS and enq

[David Spiegel]

Hi Radek,
- Run ICKDSF to take the VTOC out of Indexed Format (BUILDOS)
- ZAP the VTOC  (i.e. FORMAT4.DSCB) to change the DSNAME to something 
innocuous.

- Compress via IEBCOPY
- ZAP the DSNAME to SYS1.LINKLIB
- Run ICKDSF to put the VTOC into Indexed Format (BUILDIX)

I've done this, but, not recently.

Here is an article where someone else came up with the same idea:
Deleting a File That Is “In Use” | Steve Baugh - The CICS Guy 
(wordpress.com) 



Regards,
David

On 2024-01-19 07:27, Radoslaw Skorupka wrote:
I want to compress some system datasets like SYS1.LINKLIB, but *not* 
real "live", rather offline copies.

DSS ends with RC8, because of failed serialization.
SETPROG LNKLST,UNALLOCATE will not solve all the enqueues, because 
some datasets are serialized by other entities like TSO users.


And I also want to CONSOLIDATE some datasets as well.


Any clue?



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

STGADMIN.DPDSRN.dsname and RENAME

[Lennie Dymoke-Bradshaw]

Apologies Radoslaw,

It appears that IEHPROGM will not make use of STGADMIN.DPDSRN.olddsname 
profile. Use of that FACILITY class profile requires that a bit be set in the 
CAMLST macro expansion. It appears IEHPROGM has not been altered to support 
this.

The DFSMS Advanced Services manual states,
Your program sets on a certain bit in the CAMLST macro expansion. You 
can code this instruction: OI listname+2,X'10'.

Is there any program that supports this profile? 
Or do IBM expect we have to write our own?

Lennie

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lennie Dymoke-Bradshaw
Sent: 19 January 2024 14:42
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ADRDSSU COMPRESS and enq

Radoslaw wrote
>>3. I don't know how to rename such datasets! Yes, I could imagine 
>>access from another z/OS image, but it would be a series of manual 
>>ISPF r command. Non-repeatable, error prone. Is there any tool 
>>allowing to rename such datasets in batch? Wildcard support (i.e. REN 
>>SYS1.* SYS2.*) would be welcome. <<

Try IEHPROGM.
https://www.ibm.com/docs/en/zos/3.1.0?topic=program-scratching-renaming-data-set-member
 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: 19 January 2024 14:18
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ADRDSSU COMPRESS and enq

Gentlemen,
First, thank you for your answers. I appreciate it.

Regarding TOLENQF - it doesn't work with COMPRESS or CONSOLIDATE. The manual is 
clear here.

Regarding rename - this is the thing I wanted to avoid for several reasons:
1. There is some risk to rename wrong "copy" of the dataset, or alter ICF 
entries for wrong copy.
2. Valid copies are located on non-SMS disk, but cataloged out of regular 
catalog search (SYS1.name in some UCAT). Plus some aliases, etc. 
I want to not destroy it.
3. I don't know how to rename such datasets! Yes, I could imagine access from 
another z/OS image, but it would be a series of manual ISPF r command. 
Non-repeatable, error prone. Is there any tool allowing to rename such datasets 
in batch? Wildcard support (i.e. REN SYS1.* SYS2.*) would be welcome.



--
Radoslaw Skorupka
Lodz, Poland





W dniu 19.01.2024 o 13:27, Radoslaw Skorupka pisze:
> I want to compress some system datasets like SYS1.LINKLIB, but *not* 
> real "live", rather offline copies.
> DSS ends with RC8, because of failed serialization.
> SETPROG LNKLST,UNALLOCATE will not solve all the enqueues, because 
> some datasets are serialized by other entities like TSO users.
>
> And I also want to CONSOLIDATE some datasets as well.
>
>
> Any clue?
>

--
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: ADRDSSU COMPRESS and enq

[Steely.Mark]

Unless I am missing something why not use IEBCOPY with specifying DISP=SHR on 
the dataset name. 
I have done this with datasets that were allocated to the LNKLST. 

Thanks

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: Friday, January 19, 2024 8:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ADRDSSU COMPRESS and enq



CAUTION! EXTERNAL SENDER! STOP, ASSESS, AND VERIFY Do you know this person? 
Were you expecting this email? If not, report it using the Report Phishing 
Button!

Gentlemen,
First, thank you for your answers. I appreciate it.

Regarding TOLENQF - it doesn't work with COMPRESS or CONSOLIDATE. The manual is 
clear here.

Regarding rename - this is the thing I wanted to avoid for several reasons:
1. There is some risk to rename wrong "copy" of the dataset, or alter ICF 
entries for wrong copy.
2. Valid copies are located on non-SMS disk, but cataloged out of regular 
catalog search (SYS1.name in some UCAT). Plus some aliases, etc.
I want to not destroy it.
3. I don't know how to rename such datasets! Yes, I could imagine access from 
another z/OS image, but it would be a series of manual ISPF r command. 
Non-repeatable, error prone. Is there any tool allowing to rename such datasets 
in batch? Wildcard support (i.e. REN SYS1.* SYS2.*) would be welcome.



--
Radoslaw Skorupka
Lodz, Poland





W dniu 19.01.2024 o 13:27, Radoslaw Skorupka pisze:
> I want to compress some system datasets like SYS1.LINKLIB, but *not* 
> real "live", rather offline copies.
> DSS ends with RC8, because of failed serialization.
> SETPROG LNKLST,UNALLOCATE will not solve all the enqueues, because 
> some datasets are serialized by other entities like TSO users.
>
> And I also want to CONSOLIDATE some datasets as well.
>
>
> Any clue?
>

--
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: ADRDSSU COMPRESS and enq

[Lennie Dymoke-Bradshaw]

Radoslaw wrote
>>3. I don't know how to rename such datasets! Yes, I could imagine access from 
>>another z/OS image, but it would be a series of manual ISPF r command. 
>>Non-repeatable, error prone. Is there any tool allowing to rename such 
>>datasets in batch? Wildcard support (i.e. REN SYS1.* SYS2.*) would be 
>>welcome. <<

Try IEHPROGM.
https://www.ibm.com/docs/en/zos/3.1.0?topic=program-scratching-renaming-data-set-member
 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: 19 January 2024 14:18
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ADRDSSU COMPRESS and enq

Gentlemen,
First, thank you for your answers. I appreciate it.

Regarding TOLENQF - it doesn't work with COMPRESS or CONSOLIDATE. The manual is 
clear here.

Regarding rename - this is the thing I wanted to avoid for several reasons:
1. There is some risk to rename wrong "copy" of the dataset, or alter ICF 
entries for wrong copy.
2. Valid copies are located on non-SMS disk, but cataloged out of regular 
catalog search (SYS1.name in some UCAT). Plus some aliases, etc. 
I want to not destroy it.
3. I don't know how to rename such datasets! Yes, I could imagine access from 
another z/OS image, but it would be a series of manual ISPF r command. 
Non-repeatable, error prone. Is there any tool allowing to rename such datasets 
in batch? Wildcard support (i.e. REN SYS1.* SYS2.*) would be welcome.



--
Radoslaw Skorupka
Lodz, Poland





W dniu 19.01.2024 o 13:27, Radoslaw Skorupka pisze:
> I want to compress some system datasets like SYS1.LINKLIB, but *not* 
> real "live", rather offline copies.
> DSS ends with RC8, because of failed serialization.
> SETPROG LNKLST,UNALLOCATE will not solve all the enqueues, because 
> some datasets are serialized by other entities like TSO users.
>
> And I also want to CONSOLIDATE some datasets as well.
>
>
> Any clue?
>

--
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: ADRDSSU COMPRESS and enq

[Allan Staller]

Classification: Confidential

1 copy w/ADRDSSU) TOLENQFAILURE and RENUNC
Or
Allocate new; copy from original w/IEBCOPY
3) test

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: Friday, January 19, 2024 8:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ADRDSSU COMPRESS and enq

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Gentlemen,
First, thank you for your answers. I appreciate it.

Regarding TOLENQF - it doesn't work with COMPRESS or CONSOLIDATE. The manual is 
clear here.

Regarding rename - this is the thing I wanted to avoid for several reasons:
1. There is some risk to rename wrong "copy" of the dataset, or alter ICF 
entries for wrong copy.
2. Valid copies are located on non-SMS disk, but cataloged out of regular 
catalog search (SYS1.name in some UCAT). Plus some aliases, etc.
I want to not destroy it.
3. I don't know how to rename such datasets! Yes, I could imagine access from 
another z/OS image, but it would be a series of manual ISPF r command. 
Non-repeatable, error prone. Is there any tool allowing to rename such datasets 
in batch? Wildcard support (i.e. REN SYS1.* SYS2.*) would be welcome.



--
Radoslaw Skorupka
Lodz, Poland





W dniu 19.01.2024 o 13:27, Radoslaw Skorupka pisze:
> I want to compress some system datasets like SYS1.LINKLIB, but *not*
> real "live", rather offline copies.
> DSS ends with RC8, because of failed serialization.
> SETPROG LNKLST,UNALLOCATE will not solve all the enqueues, because
> some datasets are serialized by other entities like TSO users.
>
> And I also want to CONSOLIDATE some datasets as well.
>
>
> Any clue?
>

--
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: ADRDSSU COMPRESS and enq

[rpinion865]

Do you have access to the FDR products?




Sent with Proton Mail secure email.

On Friday, January 19th, 2024 at 9:18 AM, Radoslaw Skorupka 
<0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote:


> Gentlemen,
> First, thank you for your answers. I appreciate it.
> 
> Regarding TOLENQF - it doesn't work with COMPRESS or CONSOLIDATE. The
> manual is clear here.
> 
> Regarding rename - this is the thing I wanted to avoid for several reasons:
> 1. There is some risk to rename wrong "copy" of the dataset, or alter
> ICF entries for wrong copy.
> 2. Valid copies are located on non-SMS disk, but cataloged out of
> regular catalog search (SYS1.name in some UCAT). Plus some aliases, etc.
> I want to not destroy it.
> 3. I don't know how to rename such datasets! Yes, I could imagine access
> from another z/OS image, but it would be a series of manual ISPF r
> command. Non-repeatable, error prone. Is there any tool allowing to
> rename such datasets in batch? Wildcard support (i.e. REN SYS1.* SYS2.*)
> would be welcome.
> 
> 
> 
> --
> Radoslaw Skorupka
> Lodz, Poland
> 
> 
> 
> 
> 
> W dniu 19.01.2024 o 13:27, Radoslaw Skorupka pisze:
> 
> > I want to compress some system datasets like SYS1.LINKLIB, but not
> > real "live", rather offline copies.
> > DSS ends with RC8, because of failed serialization.
> > SETPROG LNKLST,UNALLOCATE will not solve all the enqueues, because
> > some datasets are serialized by other entities like TSO users.
> > 
> > And I also want to CONSOLIDATE some datasets as well.
> > 
> > Any clue?
> 
> 
> --
> 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: ADRDSSU COMPRESS and enq

[Radoslaw Skorupka]

Gentlemen,
First, thank you for your answers. I appreciate it.

Regarding TOLENQF - it doesn't work with COMPRESS or CONSOLIDATE. The 
manual is clear here.


Regarding rename - this is the thing I wanted to avoid for several reasons:
1. There is some risk to rename wrong "copy" of the dataset, or alter 
ICF entries for wrong copy.
2. Valid copies are located on non-SMS disk, but cataloged out of 
regular catalog search (SYS1.name in some UCAT). Plus some aliases, etc. 
I want to not destroy it.
3. I don't know how to rename such datasets! Yes, I could imagine access 
from another z/OS image, but it would be a series of manual ISPF r 
command. Non-repeatable, error prone. Is there any tool allowing to 
rename such datasets in batch? Wildcard support (i.e. REN SYS1.* SYS2.*) 
would be welcome.




--
Radoslaw Skorupka
Lodz, Poland





W dniu 19.01.2024 o 13:27, Radoslaw Skorupka pisze:
I want to compress some system datasets like SYS1.LINKLIB, but *not* 
real "live", rather offline copies.

DSS ends with RC8, because of failed serialization.
SETPROG LNKLST,UNALLOCATE will not solve all the enqueues, because 
some datasets are serialized by other entities like TSO users.


And I also want to CONSOLIDATE some datasets as well.


Any clue?



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

Re: Looking to invoke abend in IBM PC call Service

[Joseph Reichman]

Thanks all

I’m trying to report where whitin the service it abended and where the service 
was called I know most are space switching stacking routines 

My SDWA should therefore contain different entries for SDWAEC1 and SDWAEC2

Thank you

> On Jan 19, 2024, at 8:46 AM, Peter Relson  wrote:
> 
> Pick your favorite service, look what abends it issues and code the 
> parameters so that they match the thing that is complained about.
> How about STORAGE OBTAIN,COND=NO,LOC=24,LINKAGE=SYSTEM,SP=0 with a LENGTH 
> amount of 16M, which will get the abend indicating "could not get the storage 
> you asked for".
> 
> Or pick any valid PC where the target routine takes a parameter area pointed 
> to by a particular register, issue the PC, and set that input reg to 
> x'_7000'. Some PC routines will field the error and retry with a 
> bad return code. But many will percolate that error to user recovery.
> 
> If you're asking about a space-switch PC, that restricts the choices, but the 
> approach applies.
> 
> Peter  Relson
> z/OS Core Technology Design
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Looking to invoke abend in IBM PC call Service

[Peter Relson]

Pick your favorite service, look what abends it issues and code the parameters 
so that they match the thing that is complained about.
How about STORAGE OBTAIN,COND=NO,LOC=24,LINKAGE=SYSTEM,SP=0 with a LENGTH 
amount of 16M, which will get the abend indicating "could not get the storage 
you asked for".

Or pick any valid PC where the target routine takes a parameter area pointed to 
by a particular register, issue the PC, and set that input reg to 
x'_7000'. Some PC routines will field the error and retry with a 
bad return code. But many will percolate that error to user recovery.

If you're asking about a space-switch PC, that restricts the choices, but the 
approach applies.

Peter  Relson
z/OS Core Technology Design


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

Re: ADRDSSU COMPRESS and enq

[Allan Staller]

Classification: Confidential

Rename the "copy" prior to attempting compress.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: Friday, January 19, 2024 6:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ADRDSSU COMPRESS and enq

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

I want to compress some system datasets like SYS1.LINKLIB, but *not* real 
"live", rather offline copies.
DSS ends with RC8, because of failed serialization.
SETPROG LNKLST,UNALLOCATE will not solve all the enqueues, because some 
datasets are serialized by other entities like TSO users.

And I also want to CONSOLIDATE some datasets as well.


Any clue?

--
Radoslaw Skorupka
Lodz, Poland

--
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: ADRDSSU COMPRESS and enq

[Lennie Dymoke-Bradshaw]

Rename data set first?
https://www.ibm.com/docs/en/zos/3.1.0?topic=gcr-renaming-data-set-that-might-be-in-use
Lennie

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: 19 January 2024 12:27
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ADRDSSU COMPRESS and enq

I want to compress some system datasets like SYS1.LINKLIB, but *not* real 
"live", rather offline copies.
DSS ends with RC8, because of failed serialization.
SETPROG LNKLST,UNALLOCATE will not solve all the enqueues, because some 
datasets are serialized by other entities like TSO users.

And I also want to CONSOLIDATE some datasets as well.


Any clue?

--
Radoslaw Skorupka
Lodz, Poland

--
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: ADRDSSU COMPRESS and enq

[Colin Paice]

Try TOL(ENQ) for tolerate enqueue failure
https://www.ibm.com/docs/en/zos/2.4.0?topic=keywords-tolerate

On Fri, 19 Jan 2024 at 12:27, Radoslaw Skorupka <
0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote:

> I want to compress some system datasets like SYS1.LINKLIB, but *not*
> real "live", rather offline copies.
> DSS ends with RC8, because of failed serialization.
> SETPROG LNKLST,UNALLOCATE will not solve all the enqueues, because some
> datasets are serialized by other entities like TSO users.
>
> And I also want to CONSOLIDATE some datasets as well.
>
>
> Any clue?
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
> --
> 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

ADRDSSU COMPRESS and enq

[Radoslaw Skorupka]

I want to compress some system datasets like SYS1.LINKLIB, but *not* 
real "live", rather offline copies.

DSS ends with RC8, because of failed serialization.
SETPROG LNKLST,UNALLOCATE will not solve all the enqueues, because some 
datasets are serialized by other entities like TSO users.


And I also want to CONSOLIDATE some datasets as well.


Any clue?

--
Radoslaw Skorupka
Lodz, Poland

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

Re: Looking to invoke abend in IBM PC call Service

[Ed Jaffe]

On 1/18/2024 3:34 PM, Joseph Reichman wrote:

I am looking to cause an abend in IBM Service that is invoked by a PC call
(bad parameters) so as to test out Estate Type Recovery for CBT file 192


Just off the top of my head I would probably issue two ISGENQ 
REQUEST=OBTAINs requesting an exclusive ENQ for the same arbitrary resource.


You'll get an S138 abend issued by an IBM service invoked by a PC call.

There are literally hundreds of other possibilities. So many I'm 
surprised you couldn't find one on your own...


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: Looking to invoke abend in IBM PC call Service

[Rob Scott]

I would imagine that most PC routines would establish recovery and gracefully 
terminate with a "something bad was passed to me" RC+RSN for instances like 
this.

Perhaps forcing a well-known abend+rsn with a COND=NO style call might be 
better - maybe a flavour of STORAGE OBTAIN or IARV64 ?

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of 
Binyamin Dissen
Sent: Friday, January 19, 2024 6:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking to invoke abend in IBM PC call Service

EXTERNAL EMAIL



On Thu, 18 Jan 2024 18:34:43 -0500 Joseph Reichman 
mailto:reichman...@gmail.com>>
wrote:

:>I am looking to cause an abend in IBM Service that is invoked by a PC call
:>(bad parameters) so as to test out Estate Type Recovery for CBT file 192

:>If anyone has an example would appreciate it

One would think placing x'' in R15-R1 should do it.

--
Binyamin Dissen mailto:bdis...@dissensoftware.com>>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

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


Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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