The problem with saving the DOS/BAM segments is because of two things: (1) The DOS/BAM segments are still below the 16M line. (2) The directory, (FSTs), for every accessed CMS disk or SFS directory
are also still below the 16M line. VMFBLD accesses a lot of disks/directories so when it went to save the BA M segment, the storage was in use. It released the disks before exiting so that's why the storage appeared to no longer be in use, (your CP DISPLAY command). I never used VMSES to manage my shared segments, I had my one procedure that I developed before VMSES had code to manage/mangle segments. :-)> I think the following steps will work, (but I don't have a system to test it with): ipl 190 clear parm nosprof access (noprof segment reserve cmsbam /* Do this before anything else! */ access 5e5 b access 51d d vmfppf segbld esasegs vmfbld ppf segbld esasegs (status vmfsetup zvm cms /* This may not be necessary, but shouldn't hurt */ segment release cmsbam /* has to be done before saving segs */ vmfbld list segbld esasegs dosbam blddata (all nosetup Hopefully, this will work, if not, I'll let know how I did it without VMSES, that always worked! :-)> The NOSETUP option on the last VMFBLD i s required to prevent VMSES from accessing disks, that's why the VMFSETUP command may be required. The SEGMENT RESERVE command will keep CMS from using the storage area where the DOS/BAM segments reside. If the SEGMENT RESERVE command fails, then that means the storage area for the segments is already in use. Another way around this problem is to have a special CMS nucleus/NSS that IPLs at a lower address, (for example 5-8M). Back when there were other products that used segments below the 16M line, I used this special "low" CMS to allow me to save segments that were right below where the "high" version of CMS started. Without a "low" CMS, I would not have been able to save segments in the megabyte immediately below CMS. -- Dale R. Smith "There is a theory which states that if ever anybody discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable. There is another theory which states that this has already happened." - Douglas Adams On Tue, 20 Nov 2007 15:24:42 -0500, Harland, Lawrence <[EMAIL PROTECTED]> wrote: > >We are installing zVM 5.3 and need to recreate the CMSDOS and CMSBAM >segments >on the current spool. I issued the following (results listed below) >from the >Service Guide and received this error for CMSBAM: > >"DMSDCS343E Storage in range 00B0D000-00B37FFF for CMSBAM in use." > >I displayed storage for this range and it showed nothing in that area of >storage. > >We keep the same spool packs between releases and rename the segments. >We >are using the default names for 5.3 so I thought this would be easy. >I'm >trying this from the MAINT id on a second level 5.3 system. Any help on >what >I might try or what I might be doing wrong would be appreciated. > >Larry Harland >Univ. of Connecticut > >----------------------------------------- > >ipl 190 clear parm nosprof instseg no >z/VM V5.3.0 2007-10-18 14:00 > >acc (noprof >Ready; T=0.01/0.01 09:57:07 > >acc 5e5 b >Ready; T=0.01/0.01 09:57:17 > >ac 51d d >Ready; T=0.01/0.01 09:57:20 > >vmfppf segbld esasegs >VMFPPF2760I VMFPPF processing started for SEGBLD ESASEGS >VMFOVE2760I VMFOVER processing started >VMFOVE1954I Locating ESASEGS tag in file SEGBLD $PPF on disk D2 >VMFOVE2760I VMFOVER processing completed successfully >VMFPPF2760I VMFPPF processing completed successfully for SEGBLD ESASEGS >VMFPPF2760I VMFPPF processing completed successfully >Ready; T=0.36/0.40 09:58:05 > >vmfbld ppf segbld esasegs (status >VMFBLD2760I VMFBLD processing started >VMFBLD1851I Reading build lists >VMFBLD2182I Identifying new build requirements >VMFBLD2182I No new build requirements identified >VMFBLD2180I There are 3 build requirements remaining >VMFBLD2760I VMFBLD processing completed successfully >Ready; T=1.63/1.71 09:58:54 > >vmfview build >Ready; T=0.06/0.06 10:01:55 > >vmfbld list segbld esasegs dosbam blddata (all >VMFBLD2767I Reading DOSBAM BLDDATA * for list of objects to process >VMFBLD2760I VMFBLD processing started >VMFBLD1851I Reading build lists >VMFBLD2182I Identifying new build requirements >VMFBLD2182I New build requirements identified >VMFBLD1851I (1 of 1) VMFBDSEG processing SEGBLIST EXC00000 D, target is >BUILD 51D (D) >VMFBDS2115I Validating segment CMSDOS >VMFBDS2115I Validating segment CMSBAM >VMFBDS2002I A DEFSEG command will be issued for 2 segment(s). >VMFBDS2219I Processing object CMSDOS.SEGMENT >HCPNSS440I Saved segment CMSDOS was successfully saved in fileid 0208. >RDR FILE 0018 SENT FROM MAINT53 PRT WAS 0018 RECS 0444 CPY 001 A >NOHOLD NOKEEP >DMSWGN715I DOSGEN COMPLETE >VMFBDS2219I Processing object CMSBAM.SEGMENT >DMSDCS1083E Saved segment $$DMY$$ does not exist >DMSSET1101I 100K DOS partition defined at hexadecimal location 020000 > >DMSSGN363R ENTER LOCATION WHERE CMSBAM WILL BE LOADED AND SAVED: >DMSSGN366R ENTER NAME OF SYSTEM TO BE SAVED: >DMSDCS343E Storage in range 00B0D000-00B37FFF for CMSBAM in use. >DMSSGN239E Cannot build segment. ReIPL CMS, ACCESS (NOPROF, and rebuild >segment. >VMFBDS1965E The command, $BAMGEN$ B0D000 CMSBAM, failed with return code >41 >VMFBLD1851E (1 of 1) VMFBDSEG completed with return code 100. Some >objects were not built >VMFBLD2180I There are 3 build requirements remaining >VMFBLD2760I VMFBLD processing completed unsuccessfully >Ready(00008); T=4.91/5.40 10:02:42 > > >d t00B0D000-00B37FFF >R00B0D000 00000000 00000000 00000000 00000000 F4 *................* >R00B0D010 to 00B0FFFF suppressed line(s) same as above .... >R00B10000 to 00B1FFFF suppressed line(s) same as above .... >R00B20000 to 00B2FFFF suppressed line(s) same as above .... >R00B30000 to 00B37FFF suppressed line(s) same as above .... >Ready; T=0.01/0.04 10:03:03 >
