Sharing libraries across Native VSE LPARs

michael...@gmail.com

unread,

Jul 31, 2017, 3:43:00 PM7/31/17

to

Do any of you share VSE libraries read/write between native VSE LPARs? If so, have you had library corruption requiring LIBR TEST REPAIR, and if so, did you get to the root cause? I realise that sharing them that way requires an active Lock File with VSE ADD cuu,SHR.

Do any of you instead duplicate the Library instead and use a staging mechanism to keep them in step?

I would be interested in your experiences.

I am more used to x-system sharing under VM using a mixture of R/O with one R/W user and have not had any Library corruption to date, but I could have been lucky.

Thanks.

Mike

Tony Thigpen

unread,

Aug 1, 2017, 8:23:18 AM8/1/17

to

Mike,

Until recently, I had libraries shared between LPARs, including one VM
which had multiple VSEs sharing the library. I did not have any
problems, but VM required something special on the lock file volume.
(And, of course, the lock file had to be on a real volume, not a VM
virtual volume.)

The special statements for VM:
'CP ATT A2F TO SYSTEM' /* Lock File */
'CP SET SHARED ON A2F'

Tony Thigpen

michael...@gmail.com wrote on 07/31/2017 03:42 PM:
> Do any of you share VSE libraries read/write between native VSE LPARs? If s=
> o, have you had library corruption requiring LIBR TEST REPAIR, and if so, d=
> id you get to the root cause? I realise that sharing them that way requires=

> an active Lock File with VSE ADD cuu,SHR.
>

> Do any of you instead duplicate the Library instead and use a staging mecha=

> nism to keep them in step?
>
> I would be interested in your experiences.
>

> I am more used to x-system sharing under VM using a mixture of R/O with one=
> R/W user and have not had any Library corruption to date, but I could have=
> been lucky.
>
> Thanks.
>
> Mike
>
> _______________________________________________
> VSE-L mailing list
> VS...@lists.lehigh.edu
> https://lists.lehigh.edu/mailman/listinfo/vse-l
>
>

_______________________________________________
VSE-L mailing list
VS...@lists.lehigh.edu
https://lists.lehigh.edu/mailman/listinfo/vse-l

Frank M. Ramaekers

unread,

Aug 1, 2017, 9:56:55 AM8/1/17

to

We actually have a z/VM Virtual disk for the lock file....not sure what you mean by "lock file had to be on a real volume"

Frank M. Ramaekers Jr.
Ext-(254)761-6649 Int-732-6649

_____________________________________________________ 
This message contains information which is privileged and confidential and is solely for the use of the 
intended recipient. If you are not the intended recipient, be aware that any review, disclosure, 
copying, distribution, or use of the contents of this message is strictly prohibited. If you have 
received this in error, please destroy it immediately and notify us at Priva...@torchmarkcorp.com.

Kevin Corkery

unread,

Aug 1, 2017, 10:00:15 AM8/1/17

to

I think he had the VSEs sitting in regular LPARS, one of which happened to
include a zVM with VSEs. This would require a physical disk for the lock
file since not all VSEs were running under VM.

Deetjen, Jean-Max

unread,

Aug 1, 2017, 10:01:32 AM8/1/17

to

I have the same environment as frank and have no issues.

> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.lehigh.edu_
> mailman_listinfo_vse-2Dl&d=DwICAg&c=YeYAMPPttvq4ETyeKJSq0w&r=hHNPnueqM
> KKXBToM2IebZPgM2C-rIA9ECd1t-Cs_YM0&m=tTVPdEUvR7-zmbumY_wF1iQT9XQw93jbU
> R0JGof9-vI&s=mqgpN4RHfqRivcnsyM_av5xH2wrxtAfQG7oqt6Kmj1c&e=

>
>

_______________________________________________
VSE-L mailing list
VS...@lists.lehigh.edu

https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.lehigh.edu_mailman_listinfo_vse-2Dl&d=DwICAg&c=YeYAMPPttvq4ETyeKJSq0w&r=hHNPnueqMKKXBToM2IebZPgM2C-rIA9ECd1t-Cs_YM0&m=tTVPdEUvR7-zmbumY_wF1iQT9XQw93jbUR0JGof9-vI&s=mqgpN4RHfqRivcnsyM_av5xH2wrxtAfQG7oqt6Kmj1c&e=

_____________________________________________________ 
This message contains information which is privileged and confidential and is solely for the use of the intended recipient. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution, or use of the contents of this message is strictly prohibited. If you have received this in error, please destroy it immediately and notify us at Priva...@torchmarkcorp.com.

_______________________________________________
VSE-L mailing list
VS...@lists.lehigh.edu

https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.lehigh.edu_mailman_listinfo_vse-2Dl&d=DwICAg&c=YeYAMPPttvq4ETyeKJSq0w&r=hHNPnueqMKKXBToM2IebZPgM2C-rIA9ECd1t-Cs_YM0&m=tTVPdEUvR7-zmbumY_wF1iQT9XQw93jbUR0JGof9-vI&s=mqgpN4RHfqRivcnsyM_av5xH2wrxtAfQG7oqt6Kmj1c&e=

------------------------------------------------------------------------
The information contained in this communication is intended
only for the use of the recipient(s) named above. It may
contain information that is privileged or confidential, and
may be protected by State and/or Federal Regulations. If
the reader of this message is not the intended recipient,
you are hereby notified that any dissemination,
distribution, or copying of this communication, or any of
its contents, is strictly prohibited. If you have received
this communication in error, please return it to the sender
immediately and delete the original message and any copy
of it from your computer system. If you have any questions
concerning this message, please contact the sender.
------------------------------------------------------------------------

Tony Thigpen

unread,

Aug 1, 2017, 10:17:30 AM8/1/17

to

The discussion is about sharing VSE packs OUTSIDE of VM. :-)

Tony Thigpen

Mick Poil

unread,

Aug 1, 2017, 10:28:35 AM8/1/17

to

It seems that you just cannot perform a LIBR TEST REPAIR if the library is on a shared dasd volume even if no other system is using that volume!

Stuart, David

unread,

Aug 1, 2017, 10:33:08 AM8/1/17

to

Mike,

I have three LPARs (no z/VM) sharing a library. They have been sharing the library for years. No corruption problems.

Dave

Dave Stuart
Principal Info. Systems Support Analyst
County of Ventura
805-662-6731
David....@ventura.org

-----Original Message-----
From: VSE-L [mailto:vse-l-bounces+david.stuart=ventu...@lists.lehigh.edu] On Behalf Of michael...@gmail.com
Sent: Monday, July 31, 2017 12:43 PM
To: vs...@lehigh.edu
Subject: Sharing libraries across Native VSE LPARs

Do any of you share VSE libraries read/write between native VSE LPARs? If s= o, have you had library corruption requiring LIBR TEST REPAIR, and if so, d= id you get to the root cause? I realise that sharing them that way requires= an active Lock File with VSE ADD cuu,SHR.

Do any of you instead duplicate the Library instead and use a staging mecha= nism to keep them in step?

I would be interested in your experiences.

I am more used to x-system sharing under VM using a mixture of R/O with one= R/W user and have not had any Library corruption to date, but I could have= been lucky.

Thanks.

Mike

_______________________________________________
VSE-L mailing list
VS...@lists.lehigh.edu

Mick Poil

unread,

Aug 1, 2017, 10:34:29 AM8/1/17

to

As an FYI, this all started because CICS was getting LD domain dumps due to an I/O error while trying to load a CICS program from an application sublibrary. The options appear to be a TEST REPAIR or a restore (i.e. reformat) the whole library, which might also prove difficult. It suggests that sharing application libraries R/W between VSE systems might not be the best idea, which is why I wondered about using a staging library to limit the damage.

Mick Poil

unread,

Aug 1, 2017, 10:35:51 AM8/1/17

to

The customer has not yet identified how it might have occurred. Yes, VSE are involved but I think that there are only the two options as above.

Mondy, Stephen , US - Texas

unread,

Aug 1, 2017, 11:20:14 AM8/1/17

to

Mike,
Possibly already been covered, the disk volumes with the shared libraries would also need to be added with the SHR option.

Steve

-----Original Message-----
From: VSE-L [mailto:vse-l-bounces+steve.mondy=opensolu...@lists.lehigh.edu] On Behalf Of michael...@gmail.com
Sent: Monday, July 31, 2017 2:43 PM
To: vs...@lehigh.edu
Subject: Sharing libraries across Native VSE LPARs

Do any of you share VSE libraries read/write between native VSE LPARs? If s= o, have you had library corruption requiring LIBR TEST REPAIR, and if so, d= id you get to the root cause? I realise that sharing them that way requires= an active Lock File with VSE ADD cuu,SHR.

Do any of you instead duplicate the Library instead and use a staging mecha= nism to keep them in step?

I would be interested in your experiences.

Mick Poil

unread,

Aug 1, 2017, 11:34:10 AM8/1/17

to

Steve,

Thanks. It is not the setup that is at fault in any way. The library is on a dasd with ,SHR, all sublibraries are defined with REUSE=AUTO. Something nasty has screwed up the free space map, which LIBR TEST error codes say can be fixed by a REPAIR. The problem is that a REPAIR cannot be done without re-IPLing one VSE without the ,SHR active, doing the repair, then IPLing again with ,SHR again. This is a production system and CICS is impacted, so it is not a simple thing to arrange.

I don't remember ever trying to restore (with reformat) a whole library on a dasd defined with ,SHR.

I would like to know if anybody has used other ways to sync libraries between VSE systems without sharing R/W, e.g. duplicating them and passing all changes through a shared staging library. Maybe nobody else has hit this problem. I haven't.

Mike

K and M

unread,

Aug 1, 2017, 11:42:57 AM8/1/17

to

I have used staged libraries in the past. In fact I advocated it at a few WAVV sessions.

Have you tried releasing the library so it can be fixed?

Ken

Duerbusch, Tom

unread,

Aug 1, 2017, 11:44:24 AM8/1/17

to

BTW, you can't restore a library or sublibrary while it is LIBDEF'ed in other partitions.

You can restore *.* members to an existing sublibrary however (do a delete *.* first). But that doesn't guarantee that the messed up data structure will be fixed.

If you can't take all systems down at the same time to do the repair, the only other option is create a new library with all the contents of the old library. Take out the old library and put in the new library in all the libdefs on each system as you can get to it. Syncing members between libraries is a manual job until all systems are on the new library. I've only had to do this once, but it bypassed the problem until I could get standalone time.

Tom Duerbusch

THD Consulting

_______________________________________________
VSE-L mailing list
VS...@lists.lehigh.edu
https://lists.lehigh.edu/mailman/listinfo/vse-l

--

Andy Engels

unread,

Aug 1, 2017, 11:54:29 AM8/1/17

to

We did this at one of my customers - no VM. The lock file was on a shared pack that they all shared. Ultimately, it's where I put the tape manager (they didn't have one of those until the operator overwrote the data base logs 3 times in one night). Really chewed on my customer that time. Had a tape manager ordered the next morning.....

____________________________________
Andy Engels
IS Team Leader - Technology Infrastructure
IMRF
Oak Brook, IL
630-368-5346

-----Original Message-----
From: VSE-L [mailto:vse-l-bounces+aengels=imrf...@lists.lehigh.edu] On Behalf Of Kevin Corkery
Sent: Tuesday, August 01, 2017 9:00 AM
To: 'VSE Discussion List'
Subject: RE: Sharing libraries across Native VSE LPARs

<table class=MsoNormalTable border=0 cellspacing=0 cellpadding=0 width="100%" style='width:100.0%;border-collapse:collapse'><tr><td style='border:solid #CBCBCB 3.0pt;background:#E35205;padding:0in 3.75pt 0in 3.75pt'>ATTENTION: This email is from an external source. Use caution before opening attachments or clicking on links.<o:p></o:p></td></tr></table>

> http://securemail.imrf.org:32224/?dmVyPTEuMDAxJiY2NzcyZDJiY2IwYzQ0NjZj
> YT01OTgwODk2Ql8yMDEwMF8xNDc3M18xJiY4NmFmYjIwZDY3YTRlMDI9MTIyMyYmdXJsPW
> h0dHBzJTNBJTJGJTJGbGlzdHMlMkVsZWhpZ2glMkVlZHUlMkZtYWlsbWFuJTJGbGlzdGlu
> Zm8lMkZ2c2UtbA==

>
>

_______________________________________________
VSE-L mailing list
VS...@lists.lehigh.edu

http://securemail.imrf.org:32224/?dmVyPTEuMDAxJiY2NzcyZDJiY2IwYzQ0NjZjYT01OTgwODk2Ql8yMDEwMF8xNDc3M18xJiY4NmFmYjIwZDY3YTRlMDI9MTIyMyYmdXJsPWh0dHBzJTNBJTJGJTJGbGlzdHMlMkVsZWhpZ2glMkVlZHUlMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZ2c2UtbA==

_____________________________________________________ 
This message contains information which is privileged and confidential and is solely for the use of the intended recipient. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution, or use of the contents of this message is strictly prohibited.
If you have received this in error, please destroy it immediately and notify us at Priva...@torchmarkcorp.com.

_______________________________________________
VSE-L mailing list
VS...@lists.lehigh.edu

http://securemail.imrf.org:32224/?dmVyPTEuMDAxJiY2NzcyZDJiY2IwYzQ0NjZjYT01OTgwODk2Ql8yMDEwMF8xNDc3M18xJiY4NmFmYjIwZDY3YTRlMDI9MTIyMyYmdXJsPWh0dHBzJTNBJTJGJTJGbGlzdHMlMkVsZWhpZ2glMkVlZHUlMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZ2c2UtbA==

_______________________________________________
VSE-L mailing list
VS...@lists.lehigh.edu

http://securemail.imrf.org:32224/?dmVyPTEuMDAxJiY2NzcyZDJiY2IwYzQ0NjZjYT01OTgwODk2Ql8yMDEwMF8xNDc3M18xJiY4NmFmYjIwZDY3YTRlMDI9MTIyMyYmdXJsPWh0dHBzJTNBJTJGJTJGbGlzdHMlMkVsZWhpZ2glMkVlZHUlMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZ2c2UtbA==