Re: References for multiple UCBs
MVT IOS was the first one that I came up with, but it requires reading between the lines *"original research" in wikispeak) and I was hoping for "multiple exposures for dummies". I added a citation of IODEVICE in OS/360 Sysgen and the same editor deleted it and added a citation needed template in its place. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tony Harminc [t...@harminc.net] Sent: Tuesday, January 24, 2023 11:01 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: References for multiple UCBs On Tue, 24 Jan 2023 at 09:08, Seymour J Metz wrote: > I'm editing the UCB article in wikipedia, and the material on multiple > exposures has been deleted as unsourced. What are good sources to cite for > multiple exposures on 2305 fixed head disk, multiple virtual drives on 3850 > mass storage system and multiple exposures on EAVs? If possible I'd like a > mix of primary and secondary sources. > The MVT I/O Supervisor PLM on bitsavers ( http://secure-web.cisco.com/1bMbYZeENGLIKD_3C6tR2JyXHRpEjhGJFXeu5pTJjhawwrqm6JyIXQCnfJr6-L2hY-PWrhxyFX5FsgFqWuoQUQIrEw3DEjXWXpNgkQJ6cc0rtCraGmRzW2Y0urI8o1G0MGkfW8S6grPxQ4a-cDAhnZ7aMyu4UwIeEAdJjxy2AS12w1iEFcFwsiU_JSf2cl6aF66ULXsNd-3J3evTdTmg_iJdADYuzQHLOy9cA2WdifVyU9bBIBVbPsIk8lElmwyDUWC_d-z5Ti2Oo6RBu9DNTm3oiRtjKJUxvCfePNxNZlILDbE06fZKQFYufmvsPh4Rw1n5Er2-pt_cnVT_-zI5VatoaIg-b6ya3Dnsu1w8x_qcjmGqmJXDnDhH88JPIkL46quQBrf7P18WQPm_GRcYGmnYdm4NldRoiyCeLF-0wR7k/http%3A%2F%2Fbitsavers.org%2Fpdf%2Fibm%2F360%2Fos%2FR21.7_Apr73%2Fplm%2FGY28-6616-9_OS_IO_Superv_PLM_R21.7_Apr73.pdf is one) makes it clear that multiple exposures for the 2305 have multiple UCBs. It takes some careful reading to be sure of that, but there are 16 hits on "exposure" in the book, most of which are relevant. Then there's the source code... If that is the primary source, then perhaps the PLM is secondary? I guess those delete-heads on WP wouldn't fall for that. Tony H. -- 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: Tcpip ports
NETSTAT is great to see ports, but it is a snapshot. To view port usage over a period of time, perhaps you could define a SERVAUTH EZB.PORTACCESS.** profile with ID(*) READ and AUDIT(ALL). Specify a value for resname on the SAF keyword of the PORT statement in TCPPROF and obey it into TCP (or on the next TCP recycle) and the port will show up in the ACC_LOGSTR field on the SMF Type 80 ACCESS record. Armed with this information you could begin to secure the ports so that, for example, only the known FTP server STC USERID could bind to port 23. HTH Robyn Robyn E Gilchrist Senior RACF and ACF2 Consultant RSH Consulting, Inc. *** Celebrating our 30th Anniversary *** 617-977-9090 www.linkedin.com/in/robyn-e-gilchrist www.rshconsulting.com --- Upcoming RSH RACF Training - WebEx - RACF Level I Administration - APRIL 17-21, 2023 - RACF Level II Administration - FEB 27 - MAR 3, 2023 - RACF Level III Admin, Audit, & Compliance - MAY 1-5, 2023 - RACF - Securing z/OS UNIX - MAR 27-31, 2023 --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LDAP with TS7700 and/or DS8K's
On Mon, 23 Jan 2023 14:48:13 +, Benik, John E wrote: >I imagine HMC and LDAP would be for AOS access on the DS8K's, but it also >sounds like setting up the TS7700 would be a little more involved and a little >more complicated. I'd be curious as to the reasons you decided to go the LDAP >direction, and any pros or cons you may have found. > The setup of the TS7700 MI access authentication using zOS LDAP is poorly documented by IBM but I wouldn't say is was any more complicated than configuring AD authentication. We decided to go with zOS LDAP authentication for System z HMCs and TS7700 MI access was purely because these platforms are "mainfframe" use only, so why not keep everything "mainframe centric" and we retain overall management of the environment. If we had used AD, for example, then management of that environment is out of our hands. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
XL C\C+ strange compile errors
Hi
I have a very short C++ program compiling as /CXX which all it does is
basically open a file
I am getting a whole slew of errors but they are not from my program they
are standard includes CEE.SCEEH.H(STDDEF) and in fact I didn't explicitly
include them (maybe they got included by 2 includes that I included in my
program of and
Thing is I don't know why I am getting these errors they would seem to be
okay for C++ such as "extern" and size_t
Here is a screen shot of some of the errors
"//'CEE.SCEEH.H(STDDEF)'", line 39.4: CCN5063 (S) The text "extern" is
unexpecte"
"//'CEE.SCEEH.H(STRING)'", line 119.51: CCN5063 (S) The text "size_t" is
unexpec"
"//'CEE.SCEEH.H(STRING)'", line 120.54: CCN5063 (S) The text "size_t" is
unexpec"
"//'CEE.SCEEH.H(STRING)'", line 121.60: CCN5063 (S) The text "size_t" is
unexpec"
"//'CEE.SCEEH.H(STRING)'", line 122.45: CCN5063 (S) The text "size_t" is
unexpec"
"//'CEE.SCEEH.H(STRING)'", line 125.14: CCN5040 (S) The text "__strlen" is
unexpa
ambiguous.
"
"//'CEE.SCEEH.H(STRING)'", line 130.58: CCN5063 (S) The text "size_t" is
unexpec"
"//'CEE.SCEEH.H(STRING)'", line 131.58: CCN5063 (S) The text "size_t" is
unexpec"
"//'CEE.SCEEH.H(STRING)'", line 132.64: CCN5063 (S) The text "size_t" is
unexpec"
"//'CEE.SCEEH.H(STRING)'", line 144.51: CCN5063 (S) The text "size_t" is
unexpec"
"//'CEE.SCEEH.H(STRING)'", line 146.57: CCN5063 (S) The text "size_t" is
unexpec"
"//'CEE.SCEEH.H(STRING)'", line 148.43: CCN5063 (S) The text "size_t" is
unexpec"
Here is partial list of my compile JCL
* Top of Data *
//JOER$ JOB 'ADCD V2R9','SYSPROG',NOTIFY=&SYSUID,REGION=0M
//*
//*---
//* COMPILE STEP:
//*---
//COMPILE EXEC PGM=CCNDRVR,REGION=192M,PARM=('/CXX LIST,OBJ,DEBUG(FORMA
// T(DWARF),HOOK(LINE,NOBLOCK,PATH),SYMBOL,FILE(OPENFIL))')
//STEPLIB DD DSN=CEE.SCEERUN2,DISP=SHR
// DD DSN=CBC.SCCNCMP,DISP=SHR
// DD DSN=CEE.SCEERUN,DISP=SHR
Not sure why I am these are errors
If anyone can point me in the right direction would appreciate it
Thanks
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
zOSMF
Hi All Has anyone ever retrofitted their current SMPe environment into zOSMF? Regards, Steve -- 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
Hi Andrew, You have a good point. The GDKUTIL utility is pretty new to z/OS, and we were going for meeting the customer requirement. That was specifically to provide a JCL utility that could download the sequential data in a Cloud Object to z/OS, as well as upload z/OS data to a Cloud Object with the intent that the data was usable by applications running in the Cloud. I specifically added that note to the documentation so that no one was surprised by the behavior when targeting a z/OS data set. We are actively updating the functionality of the utility and would love some customer-driven direction. So, please open an RFE (or now Aha! Idea) against the cloud_data_access component under z/OS with whatever ideas or wishes you have. The GDKUTIL utility does allow an Upload of something with RECFM=U. This was done at the behest of a customer that was using ftp to put SMF data out for processing by the SAS tool. 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. Sincerely, Andrew Wilt DFSMSdfp Cloud Data Access Product Owner DFSMShsm development -Original Message- From: IBM Mainframe Discussion List On Behalf Of Andrew Rowley Sent: Monday, January 23, 2023 3:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Transmitting SMF records On 20/01/2023 7:07 am, Glenn Wilcock wrote: > Late to the party on this discussion... DFSMS recently shipped a new utility > named GDKUTIL. It converts z/OS data sets and UNIX files to cloud objects > and visa-versa. Reading the documentation, the following note looks like a problem: = /When specifying a z/OS Data Set for LOCAL or LOCNAME for a DOWNLOAD command without the CONVERT keyword, the Record Format should not be Variable. (RECFM=V or RECFM=VB) This is because in binary mode, there are no indicators in the data where a record ends, so the data is placed up to the maximum logical record length. If a Data Set with variable records was uploaded to a Cloud Object in binary mode, the indicators of where a record begins and ends are lost. Therefore, a download operation of that same data to a Variable record data set cannot tell when to start a new record in the data set./ = A useful function should be able to round trip the data to and from cloud storage and end up with exactly what you started with. If there is not enough information to recreate the records on z/OS with the correct length, there is probably not enough information to usefully process the data on another platform. FTP made the same mistake, assuming that the record length information was not part of the data. For variable length records it is critical. RECFM U presumably preserves the block & record length information, but makes it unnecessarily complex to decipher. From the documentation I can't tell whether uploading RECFM U data results in the same data you started with. At a minimum there must be complications to end up with the real/correct DCB attributes. -- Andrew Rowley Black Hill Software -- 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: Transmitting SMF records
On Wed, 25 Jan 2023 20:24:59 +, Andrew N Wilt wrote: >... > The GDKUTIL utility does allow an Upload of something with RECFM=U. > This was done at the behest of a customer that was using ftp to put SMF data > out for processing by the SAS tool. 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. > I've done that sort of thing with REXX. A small REXX utility, perhaps in SAMPLIB, to do that transformation would serve the purpose and might have more general use, as for files transmitted with FTP overriding to RECFM=U. Modularity is valuable. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFSORT OUTREC conditional formatting
W dniu 24.01.2023 o 22:52, Sri h Kolusu pisze:
The following scenario: Input file VB. At offset 23 (RDW included) 2-byte
field Other relevant fields are 101,8 109,8 181,8 No sort needed.
Radoslaw,
Use the following control cards which will give you the desired results. I
optimized the job a bit to include records that have a minimum length of 188
which is the last position of the field you are interested.
//TOOLIN DD *
COPY FROM(INPUT) TO(TMP) USING(ABCD)
DISPLAY FROM(TMP) LIST(REPORT) -
HEADER('CODE ') ON(001,8,CH) -
HEADER('DESC1') ON(009,8,CH) -
HEADER('DESC2') ON(017,8,CH) -
HEADER('DESC3') ON(025,8,CH) -
BLANK
/*
//ABCDCNTL DD *
INCLUDE COND=(1,2,BI,GE,188)
OUTFIL VTOF,
BUILD=(023,2,CHANGE=(8,X'',C'ALTER ',
X'0001',C'READ',
X'0002',C'UPDATE '),
NOMATCH=(C'ERROR '),
101,08,
109,08,
181,08)
/*
Thank you Sri.
Nice trick with record length (1,2,BI...) I have to remember about it.
I have another problem to solve:
Depending on the field 23,2 we have word ALTER/READ in the report.
However the field contain other values, let's say X'1101' which should
be translated to C'CHANGE'... but this record type implies slightly
different format. For X'1101' I should use
HEADER('DESC3') ON(175,8,CH) - note, 188->175
and
HEADER('DESC4') ON(189,8,CH) - that fiel can be empty for X'',
X'0001', X'0002'
In other words different column taken to the report, depending on value
in the field 23,2. Is it possible?
Currently I simply have two separate reports, which is a little bit
error-prone. Before the above solution there were 4 separate reports, so
there is some progress. :-)
--
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: Transmitting SMF records
On 26/01/2023 7:24 am, Andrew N Wilt wrote: The GDKUTIL utility does allow an Upload of something with RECFM=U. This was done at the behest of a customer that was using ftp to put SMF data out for processing by the SAS tool. Apparently, they are able to decipher the RDW records resulting from uploading a RECFM=VBS as a RECFM=U. I would be slightly surprised if SAS can't read VB records properly formatted with the RDW. RECFM U was a workaround for the problem where FTP stripped out the RDW. So GDKUTIL seems to be reproducing the brokenness of FTP, then providing the same workaround as a feature. It would be preferable if it retained the RDW in VB records by default. GDKUTIL seems new enough that the default could be changed without too much impact. I doubt there is anyone using variable length binary transfers currently who needs the data without the RDW. (However there might be people uploading data who haven't discovered the resulting data is unusable.) I have been working with SMF data myself for many years, and this problem with FTP causes a LOT of customer confusion and frustration. -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFSORT OUTREC conditional formatting
>> Depending on the field 23,2 we have word ALTER/READ in the report.
However the field contain other values, let's say X'1101' which should be
translated to C'CHANGE'... but this record type implies slightly different
format. For X'1101' I should use
HEADER('DESC3') ON(175,8,CH) - note, 188->175 and
HEADER('DESC4') ON(189,8,CH)- that fiel can be empty for X'', X'0001',
X'0002'
Radoslaw,
It is quite simple as CHANGE has more capability. You can pick and choose the
values based on the value. So, use the following control cards. Note : I
left the include condition of RDW check as is. You can change it if you want to
accommodate the additional description.
//TOOLIN DD *
COPY FROM(INPUT) TO(TMP) USING(ABCD)
DISPLAY FROM(TMP) LIST(REPORT) -
HEADER('CODE ') ON(001,8,CH) -
HEADER('DESC1') ON(009,8,CH) -
HEADER('DESC2') ON(017,8,CH) -
HEADER('DESC3') ON(025,8,CH) -
HEADER('DESC4') ON(033,8,CH) -
BLANK
/*
//ABCDCNTL DD *
INCLUDE COND=(1,2,BI,GE,188)
OUTFIL VTOF,
BUILD=(023,2,CHANGE=(8,X'',C'ALTER ',
X'0001',C'READ',
X'0002',C'UPDATE ',
X'1101',C'CHANGE '),
NOMATCH=(C'ERROR '),
101,08,
109,08,
* If position 23 has x'1101' then pick the contents at 175 *
* for a length of 8 bytes and for all other values pick*
* the contents at 181 for a length of 8 bytes *
23,02,CHANGE=(8,X'1101',175,8),
NOMATCH=(181,8),
* If position 23 has x'1101' then pick the contents at 189 *
* for a length of 8 bytes and for all other values space *
* it out. *
23,02,CHANGE=(8,X'1101',189,8),
NOMATCH=(C' '))
/*
And the sample report looks like this
CODE DESC1 DESC2 DESC3 DESC4
ALTER AAA0 BBB0 CCC0
READ AAA1 BBB1 CCC1
UPDATE AAA2 BBB2 CCC2
CHANGE AAA3 BBB3 DDD3 EEE3
ERROR AAA4 BBB4 CCC4
Further if you have any questions, please let me know
Thanks,
Kolusu
DFSORT Development
IBM Corporation
--
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
On Thu, 26 Jan 2023 09:23:54 +1100, Andrew Rowley wrote: >On 26/01/2023 7:24 am, Andrew N Wilt wrote: >... >I would be slightly surprised if SAS can't read VB records properly >formatted with the RDW. RECFM U was a workaround for the problem where >FTP stripped out the RDW. So GDKUTIL seems to be reproducing the >brokenness of FTP, then providing the same workaround as a feature. > At times, FTP is too damned smart. I have allocated a DDNAME with overriding RECFM=U and attempted to transfer from //DD:... But it failed. It appeared that FTP did a DYNALLOC INFO, found the attributes in the DSCB, and ignored those I specified. It's possibly catering to the novice user rather than the journeyman. -- gil -- 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
From my experience with one of the vendors, NOT SAS, all of these products just expect a stream of data to process. If you are using PC versions, just download as binary ... the VBS data. The import programs parse the data correctly. Going from Mainframe to Mainframe, save yourself a lot of headache and use ADRDSSU DUMP to create a Disk File of the data, Terse ( PACK ) it, and using TRANSMIT across NJE or TRANSMIT to a data set that is RECFM FB LRECL 80 BLKSIZE 0 ( 3120 ) and FTP the TRANSMIT DSN as binary, recfm fb, LRECL 80... and RECEIVE, deterse (unpack ) and ADRDSSU RESTORE ... We do this all the time with VSAM, QSAM, PDS, PDSE, data... even sometimes but a PC in between ... -- 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
Terse the file and be done with it Sent from my iPhone No one said I could type with one thumb > On Jan 25, 2023, at 17:31, Paul Gorlinsky wrote: > > From my experience with one of the vendors, NOT SAS, all of these products > just expect a stream of data to process. If you are using PC versions, just > download as binary ... the VBS data. The import programs parse the data > correctly. Going from Mainframe to Mainframe, save yourself a lot of > headache and use ADRDSSU DUMP to create a Disk File of the data, Terse ( PACK > ) it, and using TRANSMIT across NJE or TRANSMIT to a data set that is RECFM > FB LRECL 80 BLKSIZE 0 ( 3120 ) and FTP the TRANSMIT DSN as binary, recfm fb, > LRECL 80... and RECEIVE, deterse (unpack ) and ADRDSSU RESTORE ... > > We do this all the time with VSAM, QSAM, PDS, PDSE, data... even > sometimes but a PC in between ... > > -- > 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: Transmitting SMF records
ISTR that distributed SAS has an option to read binary byte stream files with BDW+RDWs, which is what you would get if the program were to produce a merged RECFM=U DCB. Kirk Wolf Dovetailed Technologies, LLC http://coztoolkit.com Dovetailed Technologies: +1 636.300.0901 Note: Our website and domain name have changed from dovetail.com to coztoolkit.com On Wed, Jan 25, 2023, at 4:23 PM, Andrew Rowley wrote: > On 26/01/2023 7:24 am, Andrew N Wilt wrote: > > > The GDKUTIL utility does allow an Upload of something with RECFM=U. This > > was done at the behest of a customer that was using ftp to put SMF data out > > for processing by the SAS tool. Apparently, they are able to decipher the > > RDW records resulting from uploading a RECFM=VBS as a RECFM=U. > > I would be slightly surprised if SAS can't read VB records properly > formatted with the RDW. RECFM U was a workaround for the problem where > FTP stripped out the RDW. So GDKUTIL seems to be reproducing the > brokenness of FTP, then providing the same workaround as a feature. > > It would be preferable if it retained the RDW in VB records by default. > GDKUTIL seems new enough that the default could be changed without too > much impact. I doubt there is anyone using variable length binary > transfers currently who needs the data without the RDW. (However there > might be people uploading data who haven't discovered the resulting data > is unusable.) > > I have been working with SMF data myself for many years, and this > problem with FTP causes a LOT of customer confusion and frustration. > > -- > Andrew Rowley > Black Hill Software > > -- > 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: Transmitting SMF records
Hi Paul, Do you DFSMSdss->AMATERSE->XMIT large amounts of SMF Data? (Probably not.) I would never try to XMIT a Dataset like this (assuming that you could even have enough space for the XMIT Output.) Not only that , but BLKSIZE=3120 is inefficient and really slow (and with no Transmit Exit, generate a huge amount messages to the TSO User). You're much better off FTPing the AMATERSE Output. Regards, David On 2023-01-25 18:31, Paul Gorlinsky wrote: >From my experience with one of the vendors, NOT SAS, all of these products just expect a stream of data to process. If you are using PC versions, just download as binary ... the VBS data. The import programs parse the data correctly. Going from Mainframe to Mainframe, save yourself a lot of headache and use ADRDSSU DUMP to create a Disk File of the data, Terse ( PACK ) it, and using TRANSMIT across NJE or TRANSMIT to a data set that is RECFM FB LRECL 80 BLKSIZE 0 ( 3120 ) and FTP the TRANSMIT DSN as binary, recfm fb, LRECL 80... and RECEIVE, deterse (unpack ) and ADRDSSU RESTORE ... We do this all the time with VSAM, QSAM, PDS, PDSE, data... even sometimes but a PC in between ... -- 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: Transmitting SMF records
On 26/01/2023 10:20 am, Paul Gilmartin wrote: It's possibly catering to the novice user rather than the journeyman. Unfortunately I don't think that's the case. When transferring variable length binary records, the default options give you unusable (I would call it corrupted) data. You need to delve into the details of record formats and RDWs to understand why. If using the data requires deblocking variable records from RECFM U blocks it's not for the novice user. More likely, the people writing FTP didn't properly understand the requirements for variable length records. You need the RDW. -- Andrew Rowley Black Hill Software -- 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
On 26/01/2023 10:40 am, Kirk Wolf wrote: ISTR that distributed SAS has an option to read binary byte stream files with BDW+RDWs, which is what you would get if the program were to produce a merged RECFM=U DCB. It does, but I can't see any reason to implement that other than to workaround IBM's broken FTP. It's easier to read data in record format with RDWs. IBM FTP will do the right thing if you specify the SITE RDW option - I assume that the SAS RECFM U support was added before that was available. EasySMF will automatically recognize RECFM=U, RECFM=V or TSO TRANSMIT format data, optionally in a gzip or zip file, and process it correctly. It will also recognize SMF data with no RDW and tell you what is wrong. -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
HOLDDATA Not Working as Expected
Actual Sysprogs, Recently I was surprised by an unexpected REPORT ERRSYSMODS behavior. I think I've had a misconception about this for a long time... Like many vendors, we maintain HOLDDATA with FIXCAT information as well as ERROR HOLD and RELEASE statements. One of our products had a bug in the base that was fixed by an APAR for which we added a ++HOLD(fmid) ERROR FMID(fmid) REASON(aparnum) statement to our HOLDDATA. Once the APAR was validated in the field and ready for PTF creation, a ++RELEASE(fmid) ERROR FMID(fmid) REASON(aparnum) statement was added to the HOLDDATA. After receiving the latest HOLDDATA but *not* the fixing APAR or PTF into the GLOBAL zone, I issued a REPORT ERRSYSMODS command and was dismayed to see the PTF in error (PE) no longer appears on the EXCEPTION SYSMOD REPORT. Unless I did something wrong in my testing, this behavior means that REPORT ERRSYSMODS stops helping our customers identify PEs on their systems the moment our HOLDDATA indicates a fix for the PE is now available -- even if the customer has not yet received or applied the needed fix! Is there an another way to tell if you have PEs applied that have not yet been corrected through service? Thanks, -- 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: HOLDDATA Not Working as Expected
++HOLD ACTION(Apply xx) On Thu, Jan 26, 2023 at 12:05 AM Ed Jaffe wrote: > > Actual Sysprogs, > > Recently I was surprised by an unexpected REPORT ERRSYSMODS behavior. I > think I've had a misconception about this for a long time... > > Like many vendors, we maintain HOLDDATA with FIXCAT information as well > as ERROR HOLD and RELEASE statements. > > One of our products had a bug in the base that was fixed by an APAR for > which we added a ++HOLD(fmid) ERROR FMID(fmid) REASON(aparnum) statement > to our HOLDDATA. Once the APAR was validated in the field and ready for > PTF creation, a ++RELEASE(fmid) ERROR FMID(fmid) REASON(aparnum) > statement was added to the HOLDDATA. > > After receiving the latest HOLDDATA but *not* the fixing APAR or PTF > into the GLOBAL zone, I issued a REPORT ERRSYSMODS command and was > dismayed to see the PTF in error (PE) no longer appears on the EXCEPTION > SYSMOD REPORT. > > Unless I did something wrong in my testing, this behavior means that > REPORT ERRSYSMODS stops helping our customers identify PEs on their > systems the moment our HOLDDATA indicates a fix for the PE is now > available -- even if the customer has not yet received or applied the > needed fix! > > Is there an another way to tell if you have PEs applied that have not > yet been corrected through service? > > Thanks, > > -- > 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 -- 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
