DFSORT: Building one record from two and ignore the rest

Hi, I have a file that was built by a HSM command and that has a few thousand groups of records such as this: +1+2+3+4+5+6+7+8+9+0+1+2- 1- DFSMSHSM CONTROL DATASET - BACKUP DATASET-- LISTING - AT

Whether MSGFLD handle IOS050I,SUP(NO) in MPFLST.

Hi all IOS050I is defines in MPFLST as below: IOS050I,SUP(NO) IOS050I is defines in MSGFLD as below: SPECIFIC MSGTHRESH=50,MSGLIMIT=20,INTVLTIME=1 SPECIFIC SYSIMTIME=0.25 SPECIFIC MSGIMTIME=0.25

Re: DFSORT: Building one record from two and ignore the rest

HI Kolusu, Many thanks for your help. If there is not a OHSM record for each DSNAME, I will have a bigger problem to solve. Best wishes, Jack On Thu, 24 Nov 2022 at 15:30, Sri h Kolusu wrote: > >>. So, what I need is to get the dataset name from the record that has > "DSNAME =", the volser

Re: Bytes in a 3390 track

Switching from "real" 3380s & 3390s to the emulated 3380s & 3390s has been an evolutionary path. For example, with the P370 and its derivatives, each DASD unit was implemented as a single file on the hosting PC; AWSDISK. Hercules implemented the same file structure and later added a

Re: Bytes in a 3390 track - reason for the question

i was just getting ready to say this same thing. The 3390 reference shows that for a 3120 byte block, only 15 blocks fit on a track, with a 16% space waste. Your best bet is to use TRKCALC... https://www.ibm.com/docs/en/zos/2.4.0?topic=instructions-performing-track-calculations-trkcalc-macro

Re: DFSORT: Building one record from two and ignore the rest

>>. So, what I need is to get the dataset name from the record that has "DSNAME >>=", the volser from the record that has "ODSN:" and format a single record >>with volser datasetname or datasetname volser Jack Use the following untested control cards which will give you the desired results

Re: Bytes in a 3390 track

But even if they do that under the covers at the track level, I would expect the DS8K boxes to still allocate/reserve total physical space for each emulated DASD unit under the worst case assumption that every track might be fully utilized.  Unless advertised as a more restricted version of

Re: Bytes in a 3390 track - reason for the question

You're missing an allowance for an inter-block gap. On Thu, 24 Nov 2022 at 16:14, John Gateley wrote: > The reason for asking the question about bytes on a track is that I am > writing programs to report on all disk datasets. > The first program looks at all on-line disk packs and extracts all

Re: DFSORT: Building one record from two and ignore the rest

>> I need to create a single record, from the records with "DSNAME =" and >> "OHSM." with the dataset name from the first one (11(44)) and the volser >> from the last (47(6)): volser datasename or datasetname volser Jack, Your requirements do NOT match the input data. For example, for

Re: DFSORT: Building one record from two and ignore the rest

Hi Kolusu, I must not have explained myself right. The dataset name starts on position 11 of the record with "DSNAME =" beginning on position 2 (the file has a recfm FBA); the volser starts on position 47 of the record with "OHSM." beginning on position 2; all the other records are irrelevant.

Re: Storage protection keys

Apples and Oranges ... The final chip fab is usually the product of an underlying chip designed set with additional customization. Apple's M1 chip is a great example it is licensed ARM chip arch with lots of enhancements. So it is the M1 built on an ARM. The way chips have been designed

Bytes in a 3390 track - reason for the question

The reason for asking the question about bytes on a track is that I am writing programs to report on all disk datasets. The first program looks at all on-line disk packs and extracts all format 1, 3, 8 and 9 DSCBs while also providing a summary of space available/used on each disk (similar to

Re: Bytes in a 3390 track - reason for the question

Subtracting the logical blocksize from either of those capacity numbers as you describe will not give correct results for blocks per track.  The only accurate way to determine how many blocks will fit on a 3390 track is to use the formulas from the 3390 Reference Summary (mentioned in previous

SAS ODS examples

Thank you Carmen and all who responded to my query. You have been MOST Helpful. Sincerely; Kenneth Kripke : k.kri...@comcast.net -- For IBM-MAIN subscribe / signoff /

To share or not to share DASD

G'day all, I've been having discussions with a small shop (single mainframe, 3 separate LPARs, no Sysplex) regarding best practices for DASD sharing. Their view is to share all DASD volumes across their 3 LPARs (Prod/Dev/Test) so their developers/sysprogs can get access to current datasets,

Re: To share or not to share DASD

Dave, Each LPAR has its own RACF and Catalogs, and they are using SMS. This shop is currently running z/OS 1.9 on very old hardware, in the process of upgrading to current H/W and S/W. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Gibney, Dave Sent: November 24,

Re: To share or not to share DASD

Different RACF and fully shared DASD is a recipe for security problems and inconsistencies. I suppose RRSF could help. GRS ring is reported to be abysmal and nodes > 2 Same issues in trying to keep the catalogs in sync, which is required to SMS to be reliable. As will as trying to keep the SMS

Re: To share or not to share DASD

If you were asking in a security context, I would advise against it in nearly all cases. Auditors will not like that a system's data can be accessed without reference to the RACF (or ACF2, or TSS) system that is supposed to protect it. Lennie Dymoke-Bradshaw -Original Message- From: IBM

Re: To share or not to share DASD

You can't share PDSE in such an environment. You can "get away" with only and rarely updating from one LPAR, and reading in the others. Multiple RACF databases? Are the Catalogs the same and shared between all 3 LPARS? Is the site using SMS? > -Original Message- > From: IBM

Re: To share or not to share DASD

Not necessarily true in a software development environment where all members of the team need to share all their data everywhere. "Zero trust" is anathema in a development environment. If you don't trust me then fire me. It's cleaner that way. Shakespeare was *almost* right. First get rid

Re: To share or not to share DASD

But its not just a case of whether you trust they will not intentionally damage something, but the ease of accidentally causing integrity problems by not knowing when others have touched catalogs, volumes, or datasets on DASD that is physically shared but not known to be shared by the

Re: Bytes in a 3390 track - reason for the question

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