开云体育

It was explained in this post from November 4th??Re: Understanding PDS in MVS 3.8? The interblock gap (big)?is what is taking the space. I don’t remember how big it is on a 3390. A sequential

When I run this: //IDCDEL JOB CLASS=A,MSGLEVEL=(1,1),MSGCLASS=X //STEP1 EXEC PGM=IDCAMS //WORK04 DD VOL=SER=WORK04,UNIT=SYSDA,DISP=SHR //SYSPRINT DD SYSOUT=*

Hi Andre, I haven’t found the reason. I still don’t know the cause. Kind Regards -- Sergio Lindo Mansilla Software developer with DevOps tendencies Portfolio:

Sergio, It looks like only i was able to reproduce your problem, and understand what you were talking about. I confirm that when PS dataset is created it is possible to use whole allocated space and

That tells, there was a previous DEFINE of a VSAM object on WORK04. Please check the catalog and the VTOC of WORK04. In the original distribution of MVS-TK5, all the WORKxx volumes are not owned by

Daniel, I was able to create the dataset on WORK04 with no issues.? But of course, I have not gone through whatever reorganization that you performed.? Im using TK5 update 3.? See below: IDCAMS

WORK04 (as well as WORK00) seems to be owned by SYS1.UCAT.TSO. I see no existing entry for NJE38.NETSPOOL. Do I need to tell IDCAMS to use SYS1.UCAT.TSO? [1] View/Reply Online (#4842)

Hi Dani?l, Possibly WORK04 belongs to another catalog. Please check the other catalogs in your system. That can be done with an IDCAMS job with control statement. LISTCAT CAT('catalog name')

The alias for NJE38 in TK5 is defined as: DEF ALIAS(NAME('NJE38') REL('SYS1.UCAT.TSO')) I'm a VSAM novice...how would I go about fixing what I broke here. I mean I could just go back to the

Wrong catalog. All VSAM datasets on a volume must be in the same VSAM catalog. Corrected with ICF catalogs. <dan@...> wrote:

I reorganized the work packs on my TK5 system and am now trying to re-create the NJE38 spool. Oddly, I can create and remove it just fine on a TSO pack, but it failed to create on a WORK

Hi Joe, Thanks for the illustration. Just to make it clear. A Count field in a CKD device is always there by architecture and contains as I wrote CCHHRKLL. In detail the Cylinder, Head, Record, key

" To summarize: A directory block consists of a 8-byte Count field, a 8-byte key field and a 256-byte data field." [image: image.png] As you can see, the DASD count field is unused. The key field

Dear all, Let's go back to the 60s where the CKD DASD Devices were developed. At that time a lot of constraints existed, especially concerning main storage. Supervisor functions had to work in a

It is not that easy to see what Sergio is asking about, so i made a visualization. When PDS has only one member with size of one track, oddly enough there is some space left at the end. What its

You can also look here, beginning on page 75: http://www.bitsavers.org/pdf/ibm/360/os/R21.7_Apr73/GC26-3746-2_OS_Data_Management_Services_Guide_Rel_21.7_Jul73.pdf Joe [email protected]> wrote:

PDS directory structure is very well defined. The access method for PDS is called BPAM. To build a directory list, you use the BLDL macro. [image: image.png] [image: image.png] [image:

You are looking at the way the emulated disk stores data, not the way an actual physical 3390 disk stored them. Each has different sets of overheads on the data. While you don't see the overheads

Or 52 byte long directory entries if one of the counters in the ISPF stats exceeds 64K. RPF and REVIEW/RFE also writes ISPF stats in the directory entries. Cheers, Rob

Hi :) Thank you all. I was able to verify what happens inside the directory block by creating my own uncompressed 3390 disk and inspecting it with an hexadecimal editor. ### PDS Directory block I