Re: STC JESYSMSG Quandry
The system that is showing the output. $DSTCCLASS,LONG $HASP837 STCCLASS $HASP837 STCCLASS AUTH=(ALL),BLP=YES,COMMAND=EXECUTE, $HASP837 CONDPURG=NO,DSENQSHR=ALLOW,IEFUJP=YES, $HASP837 IEFUSO=YES,JESLOG=(NOSPIN),LOG=YES, $HASP837 MSGLEVEL=(1,1),MSGCLASS=A,OUTDISP=(HOLD,HOLD), $HASP837 OUTPUT=YES,PERFORM=000,PROMO_RATE=0, $HASP837 PROCLIB=00,QAFF=(ANY),REGION=0004M,SWA=ABOVE, $HASP837 TIME=(001440,00),TYPE26=YES,TYPE6=YES,DESC= $DOUTCLASS(A) $HASP842 OUTCLASS(A) $HASP842 OUTCLASS(A) OUTPUT=PRINT,BLNKTRNC=YES,COMPRESS=YES, $HASP842 OUTDISP=(HOLD,HOLD),TRKCELL=YES The system that isn't showing the output $dstcclass,long $HASP837 STCCLASS $HASP837 STCCLASS AUTH=(ALL),BLP=NO,COMMAND=EXECUTE, $HASP837 CONDPURG=NO,DSENQSHR=ALLOW,IEFUJP=YES, $HASP837 IEFUSO=YES,JESLOG=(NOSPIN),LOG=YES, $HASP837 MSGLEVEL=(1,1),MSGCLASS=K, $HASP837 OUTDISP=(HOLD,HOLD),OUTPUT=YES,PERFORM=000, $HASP837 PROMO_RATE=0,PROCLIB=00,QAFF=(ANY), $HASP837 REGION=K,SWA=ABOVE,TIME=(001440,00), $HASP837 TYPE26=YES,TYPE6=YES,DESC= $DOUTCLASS(K) $HASP842 OUTCLASS(K) $HASP842 OUTCLASS(K) OUTPUT=PRINT,BLNKTRNC=YES,COMPRESS=NO, $HASP842 OUTDISP=(HOLD,HOLD),TRKCELL=YES Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Tuesday, April 6th, 2021 at 6:54 PM, Mike Schwab wrote: > Is the default MSGLEVEL different? > > https://www.ibm.com/docs/en/zos/2.1.0?topic=mp-subparameter-definition-6 > > JOB statement MSGLEVEL=(1,1) should print everything. > > On Tue, Apr 6, 2021 at 2:34 PM Mark Jacobs > > 0224d287a4b1-dmarc-requ...@listserv.ua.edu wrote: > > > On one system (different JES2 MAS), our STCs while executing only show this > > line in SDSF. > > > > STMT NO. MESSAGE > > > > 2 IEFC001I PROCEDURE XX WAS EXPANDED USING SYSTEM LIBRARY .. > > > > But on other systems it's showing much more. > > > > STMT NO. MESSAGE > > > > 2 IEFC001I PROCEDURE X WAS EXPANDED USING SYSTEM LIBRARY .. > > > > IEF695I START XX WITH JOBNAME XX IS ASSIGNED TO USER A , GROUP > > B > > > > IEFA111I XX IS USING THE FOLLOWING JOB RELATED SETTINGS: > > > > SWA=ABOVE,TIOT SIZE=64K,DSENQSHR=DISALLOW,GDGBIAS=JOB > > > > and so on. > > > > I've looked at the obvious places, STCCLASS and its defaulted OUTCLASS and > > everything relevant seems the same. > > > > What am I missing? > > > > Mark Jacobs > > > > Sent from ProtonMail, Swiss-based encrypted email. > > > > GPG Public Key - > > https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com > > > > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [External] Re: Debugging "A high error rate was detected on the Optical Link network." HMC alert
Cables dirty - have you cleaned the ends of the cables and the FSPs? I see you have the Brocade negotiating down to 2 Gb to talk to the 6800. Can you try forcing the Brocade port to 2 Gb instead of using autonegotiate? I seem to recall eons ago having an issue on some HP equipment where we needed to force the port speeds instead of using auto to make it work. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Radoslaw Skorupka Sent: Tuesday, April 6, 2021 5:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: Debugging "A high error rate was detected on the Optical Link network." HMC alert We've got it! "when it was connected to another mainframe, but it has it now" So something has changed. This is the most likely moment for error. Now it's time for investigation - what cable is new, what is old, what plug was inserted, etc. -- Radoslaw Skorupka (looking for new job) Lodz, Poland W dniu 06.04.2021 o 22:20, Christian Svensson pisze: > Hello, > > I understand that ideally I would find the error - but all the values seem > correct in my eyes. > The optical values are fine, no errors shown on the interfaces, etc. > > This bugs me a bit. I did not have this issue when it was connected to > another mainframe, but it has it now... > > Regards, > > On Tue, Apr 6, 2021 at 3:32 PM Radoslaw Skorupka > wrote: > >> You can disable that using HMC features (it is called Optical Network >> Errors or similar). >> However DON'T DO IT. >> This is symptom of some problem. It can be pinched FO cable, dirty >> connector or failing SFP module. >> Unfortunately it is almost good, so there is no simple way to know >> whether cable change helped or not. >> We like more consistent failures ;-) >> However I would start from visual inspection and then cable change. >> >> -- >> Radoslaw Skorupka >> (looking for new job) >> Lodz, Poland >> >> >> >> W dniu 05.04.2021 o 12:25, Christian Svensson pisze: >>> Good day, >>> >>> Recently I have been getting these kinds of alerts from my HMC. It all >>> started when I connected an old DS6800 and the details are: >>> >>> Node 1 >>> Machine: 2498-B40 >>> Serial: IBMCA107312B >>> Physical Interface: 6620 >>> Logical Interface: 0020 >>> >>> Node 2 >>> Machine: 1750-511 >>> Serial: IBM13715 >>> Physical Interface: 0100 >>> Logical Interface: >>> >>> I keep getting these errors about 3-4 per day with the exact same >>> interfaces specified. No others, just these. >>> >>> When I look at the referenced SAN switch and I do a "porterrshow" things >>> seem fine: >>> frames enccrccrctootoobadenc >> disc >>> link loss loss frjt fbsy c3timeoutpcs >>> tx rx inerrg_eof shrt long eof out c3 >>>failsync sig txrx err >>>20:4.8m 46.9k 0 0 0 0 0 0 0 0 >>> 0 2 2 0 0 0 0 0 >>>32: 27.5k 17.7k 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>>33: 19.3k 13.6k 0 0 0 0 0 0 0 0 >>> 0 0 1 0 0 0 0 0 >>>36: 78 79 0 0 0 0 0 0 0 0 >>> 0 0 1 1 0 0 0 0 >>>37: 56 57 0 0 0 0 0 0 0 0 >>> 0 0 0 1 0 0 0 0 >>> >>> I assume the interface given in the alert is in hex, so the error would >> be >>> about port 32 (which is indeed connected to the DS6800 controller 1, port >>> 0). >>> As you can see the port seems to be fine. >>> >>> The full portshow 32 is here: >>> portIndex: 32 >>> portName: port32 >>> portHealth: HEALTHY >>> >>> Authentication: None >>> portDisableReason: None >>> portCFlags: 0x1 >>> portFlags: 0x1020b03 PRESENT ACTIVE F_PORT G_PORT U_PORT >> LOGICAL_ONLINE >>> LOGIN NOELP ACCEPT FLOGI >>> LocalSwcFlags: 0x0 >>> portType: 17.0 >>> POD Port: Port is licensed >>> portState: 1Online >>> Protocol: FC >>> portPhys: 6In_Sync portScn: 32 F_Port >>> port generation number:16 >>> state transition count:3 >>> >>> portId:662000 >>> portIfId:43020017 >>> portWwn: 20:20:00:05:1e:e8:74:30 >>> portWwn of device(s) connected: >>> 50:05:07:63:0e:80:02:11 >>> Distance: normal >>> portSpeed: N2Gbps >>> >>> Credit Recovery: Inactive >>> Aoq: Inactive >>> FAA: Inactive >>> F_Trunk: Inactive >>> LE domain: 0 >>> Peer beacon: Off >>> FC Fastwrite: OFF >>> Interrupts:0 Link_failure: 0 Frjt: 0 >>> Unknown: 0 Loss_of_sync: 0 Fbsy: 0 >>> Lli: 15 Loss_of_sig: 0 >>> Proc_rqrd: 63 Protocol_err: 0 >>> Timed_out: 0 Invalid_word: 0 >>> Rx_flushed:0
Re: STC JESYSMSG Quandry
Is the default MSGLEVEL different? https://www.ibm.com/docs/en/zos/2.1.0?topic=mp-subparameter-definition-6 JOB statement MSGLEVEL=(1,1) should print everything. On Tue, Apr 6, 2021 at 2:34 PM Mark Jacobs <0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote: > > On one system (different JES2 MAS), our STCs while executing only show this > line in SDSF. > > STMT NO. MESSAGE > 2 IEFC001I PROCEDURE XX WAS EXPANDED USING SYSTEM LIBRARY .. > > But on other systems it's showing much more. > > STMT NO. MESSAGE > 2 IEFC001I PROCEDURE X WAS EXPANDED USING SYSTEM LIBRARY .. > IEF695I START XX WITH JOBNAME XX IS ASSIGNED TO USER A , GROUP > B > IEFA111I XX IS USING THE FOLLOWING JOB RELATED SETTINGS: > SWA=ABOVE,TIOT SIZE=64K,DSENQSHR=DISALLOW,GDGBIAS=JOB > > and so on. > > I've looked at the obvious places, STCCLASS and its defaulted OUTCLASS and > everything relevant seems the same. > > What am I missing? > > Mark Jacobs > > Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email. > > GPG Public Key - > https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com > > -- > 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
Re: Debugging "A high error rate was detected on the Optical Link network." HMC alert
The Marriage of Two Mainframes via Optical link ... Something old Something new Something borrowed? Something BIG BLUE Chris Hoelscher Lead Sys DBA IBM Global Technical Services on assignmemt to Humana Inc. T 502.476.2538 or 502.407.7266 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Radoslaw Skorupka Sent: Tuesday, April 6, 2021 6:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Debugging "A high error rate was detected on the Optical Link network." HMC alert [External Email: Use caution with links and attachments] We've got it! "when it was connected to another mainframe, but it has it now" So something has changed. This is the most likely moment for error. Now it's time for investigation - what cable is new, what is old, what plug was inserted, etc. -- Radoslaw Skorupka (looking for new job) Lodz, Poland W dniu 06.04.2021 o 22:20, Christian Svensson pisze: > Hello, > > I understand that ideally I would find the error - but all the values > seem correct in my eyes. > The optical values are fine, no errors shown on the interfaces, etc. > > This bugs me a bit. I did not have this issue when it was connected to > another mainframe, but it has it now... > > Regards, > > On Tue, Apr 6, 2021 at 3:32 PM Radoslaw Skorupka > > wrote: > >> You can disable that using HMC features (it is called Optical Network >> Errors or similar). >> However DON'T DO IT. >> This is symptom of some problem. It can be pinched FO cable, dirty >> connector or failing SFP module. >> Unfortunately it is almost good, so there is no simple way to know >> whether cable change helped or not. >> We like more consistent failures ;-) >> However I would start from visual inspection and then cable change. >> >> -- >> Radoslaw Skorupka >> (looking for new job) >> Lodz, Poland >> >> >> >> W dniu 05.04.2021 o 12:25, Christian Svensson pisze: >>> Good day, >>> >>> Recently I have been getting these kinds of alerts from my HMC. It >>> all started when I connected an old DS6800 and the details are: >>> >>> Node 1 >>> Machine: 2498-B40 >>> Serial: IBMCA107312B >>> Physical Interface: 6620 >>> Logical Interface: 0020 >>> >>> Node 2 >>> Machine: 1750-511 >>> Serial: IBM13715 >>> Physical Interface: 0100 >>> Logical Interface: >>> >>> I keep getting these errors about 3-4 per day with the exact same >>> interfaces specified. No others, just these. >>> >>> When I look at the referenced SAN switch and I do a "porterrshow" >>> things seem fine: >>> frames enccrccrctootoobadenc >> disc >>> link loss loss frjt fbsy c3timeoutpcs >>> tx rx inerrg_eof shrt long eof out c3 >>>failsync sig txrx err >>>20:4.8m 46.9k 0 0 0 0 0 0 0 0 >>> 0 2 2 0 0 0 0 0 >>>32: 27.5k 17.7k 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>>33: 19.3k 13.6k 0 0 0 0 0 0 0 0 >>> 0 0 1 0 0 0 0 0 >>>36: 78 79 0 0 0 0 0 0 0 0 >>> 0 0 1 1 0 0 0 0 >>>37: 56 57 0 0 0 0 0 0 0 0 >>> 0 0 0 1 0 0 0 0 >>> >>> I assume the interface given in the alert is in hex, so the error >>> would >> be >>> about port 32 (which is indeed connected to the DS6800 controller 1, >>> port 0). >>> As you can see the port seems to be fine. >>> >>> The full portshow 32 is here: >>> portIndex: 32 >>> portName: port32 >>> portHealth: HEALTHY >>> >>> Authentication: None >>> portDisableReason: None >>> portCFlags: 0x1 >>> portFlags: 0x1020b03 PRESENT ACTIVE F_PORT G_PORT U_PORT >> LOGICAL_ONLINE >>> LOGIN NOELP ACCEPT FLOGI >>> LocalSwcFlags: 0x0 >>> portType: 17.0 >>> POD Port: Port is licensed >>> portState: 1Online >>> Protocol: FC >>> portPhys: 6In_Sync portScn: 32 F_Port >>> port generation number:16 >>> state transition count:3 >>> >>> portId:662000 >>> portIfId:43020017 >>> portWwn: 20:20:00:05:1e:e8:74:30 >>> portWwn of device(s) connected: >>> 50:05:07:63:0e:80:02:11 >>> Distance: normal >>> portSpeed: N2Gbps >>> >>> Credit Recovery: Inactive >>> Aoq: Inactive >>> FAA: Inactive >>> F_Trunk: Inactive >>> LE domain: 0 >>> Peer beacon: Off >>> FC Fastwrite: OFF >>> Interrupts:0 Link_failure: 0 Frjt: 0 >>> Unknown: 0 Loss_of_sync: 0 Fbsy: 0 >>> Lli: 15 Loss_of_sig: 0 >>> Proc_rqrd: 63 Protocol_err: 0 >>> Timed_out: 0 Invalid_word: 0 >>> Rx_flushed:0 Invalid_crc: 0 >>> Tx_unavail:0
Re: OMVS
On 4/6/21 2:08 PM, Paul Gilmartin wrote: Bur if you have a mixture of OMVS and other UNIX, try to make the UID/GID agree across systems. I absolutely agree that consistent UID & GID are a Good Thing™. But, sometimes that's no small task. I've seen Unix shops spend a LOT of time, effort, and money to do that. -- Grant. . . . unix || die -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Debugging "A high error rate was detected on the Optical Link network." HMC alert
We've got it! "when it was connected to another mainframe, but it has it now" So something has changed. This is the most likely moment for error. Now it's time for investigation - what cable is new, what is old, what plug was inserted, etc. -- Radoslaw Skorupka (looking for new job) Lodz, Poland W dniu 06.04.2021 o 22:20, Christian Svensson pisze: Hello, I understand that ideally I would find the error - but all the values seem correct in my eyes. The optical values are fine, no errors shown on the interfaces, etc. This bugs me a bit. I did not have this issue when it was connected to another mainframe, but it has it now... Regards, On Tue, Apr 6, 2021 at 3:32 PM Radoslaw Skorupka wrote: You can disable that using HMC features (it is called Optical Network Errors or similar). However DON'T DO IT. This is symptom of some problem. It can be pinched FO cable, dirty connector or failing SFP module. Unfortunately it is almost good, so there is no simple way to know whether cable change helped or not. We like more consistent failures ;-) However I would start from visual inspection and then cable change. -- Radoslaw Skorupka (looking for new job) Lodz, Poland W dniu 05.04.2021 o 12:25, Christian Svensson pisze: Good day, Recently I have been getting these kinds of alerts from my HMC. It all started when I connected an old DS6800 and the details are: Node 1 Machine: 2498-B40 Serial: IBMCA107312B Physical Interface: 6620 Logical Interface: 0020 Node 2 Machine: 1750-511 Serial: IBM13715 Physical Interface: 0100 Logical Interface: I keep getting these errors about 3-4 per day with the exact same interfaces specified. No others, just these. When I look at the referenced SAN switch and I do a "porterrshow" things seem fine: frames enccrccrctootoobadenc disc link loss loss frjt fbsy c3timeoutpcs tx rx inerrg_eof shrt long eof out c3 failsync sig txrx err 20:4.8m 46.9k 0 0 0 0 0 0 0 0 0 2 2 0 0 0 0 0 32: 27.5k 17.7k 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 33: 19.3k 13.6k 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 36: 78 79 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 37: 56 57 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 I assume the interface given in the alert is in hex, so the error would be about port 32 (which is indeed connected to the DS6800 controller 1, port 0). As you can see the port seems to be fine. The full portshow 32 is here: portIndex: 32 portName: port32 portHealth: HEALTHY Authentication: None portDisableReason: None portCFlags: 0x1 portFlags: 0x1020b03 PRESENT ACTIVE F_PORT G_PORT U_PORT LOGICAL_ONLINE LOGIN NOELP ACCEPT FLOGI LocalSwcFlags: 0x0 portType: 17.0 POD Port: Port is licensed portState: 1Online Protocol: FC portPhys: 6In_Sync portScn: 32 F_Port port generation number:16 state transition count:3 portId:662000 portIfId:43020017 portWwn: 20:20:00:05:1e:e8:74:30 portWwn of device(s) connected: 50:05:07:63:0e:80:02:11 Distance: normal portSpeed: N2Gbps Credit Recovery: Inactive Aoq: Inactive FAA: Inactive F_Trunk: Inactive LE domain: 0 Peer beacon: Off FC Fastwrite: OFF Interrupts:0 Link_failure: 0 Frjt: 0 Unknown: 0 Loss_of_sync: 0 Fbsy: 0 Lli: 15 Loss_of_sig: 0 Proc_rqrd: 63 Protocol_err: 0 Timed_out: 0 Invalid_word: 0 Rx_flushed:0 Invalid_crc: 0 Tx_unavail:0 Delim_err:0 Free_buffer: 0 Address_err: 0 Overrun: 0 Lr_in:3 Suspended: 0 Lr_out: 0 Parity_err:0 Ols_in: 0 2_parity_err: 0 Ols_out: 3 CMI_bus_err: 0 As far as I can tell the port is doing just fine, and I have not received any reports of connectivity issues to the actual DASDs. Any suggestions on what is going on, or worst case - how I can disable these alerts? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STC JESYSMSG Quandry
Input on; DDNAME StepName ProcStep DsID JESJCLIN 1 JESMSGLG JES2CI01 2 JESJCL JES2CI01 3 JESYSMSG JES2CI01 4 $INTTEXT JES2CI01 5 $SWABLKS JES2CI01 7 EVENTLOG JES2CI01 8 Input off DDNAME StepName ProcStep DsID JESMSGLG JES2CI01 2 JESJCL JES2CI01 3 JESYSMSG JES2CI01 4 On the "working" system. Input on DDNAME StepName ProcStep DSID JESJCLIN 1 JESMSGLG JES2CI02 2 JESJCL JES2CI02 3 JESYSMSG JES2CI02 4 $INTTEXT JES2CI02 5 $SWABLKS JES2CI02 7 EVENTLOG JES2CI02 8 SYSPRINT ESWZK70D 101 SYSOUT ESWZK70D 102 and input off DDNAME StepName ProcStep DSID JESMSGLG JES2CI02 2 JESJCL JES2CI02 3 JESYSMSG JES2CI02 4 SYSPRINT ESWZK70D 101 SYSOUT ESWZK70D 102 Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Tuesday, April 6th, 2021 at 4:21 PM, Carmen Vitullo wrote: > that blows my theory - I only have one JES2 MAS and first saw these messages > with z/OS 2.3, in SDSF maybe INPUT ON Vs. INPUT OFF ? > > > > > > Carmen Vitullo > > -Original Message- > > From: Mark 0224d287a4b1-dmarc-requ...@listserv.ua.edu > > To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU > > Date: Tuesday, 6 April 2021 3:12 PM CDT > > Subject: Re: STC JESYSMSG Quandry > > Both systems are z/OS 2.4. > > Mark Jacobs > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com > > ‐‐‐ Original Message ‐‐‐ > > On Tuesday, April 6th, 2021 at 4:03 PM, Carmen Vitullo cvitu...@hughes.net > wrote: > > > Mark what OS release is the first example? > > > > IIRC the message was expanded with JES2 z/os 2.3 > > > > Carmen Vitullo > > > > -Original Message- > > > > From: Mark 0224d287a4b1-dmarc-requ...@listserv.ua.edu > > > > To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU > > > > Date: Tuesday, 6 April 2021 2:34 PM CDT > > > > Subject: STC JESYSMSG Quandry > > > > On one system (different JES2 MAS), our STCs while executing only show this > > line in SDSF. > > > > STMT NO. MESSAGE > > > > 2 IEFC001I PROCEDURE XX WAS EXPANDED USING SYSTEM LIBRARY .. > > > > But on other systems it's showing much more. > > > > STMT NO. MESSAGE > > > > 2 IEFC001I PROCEDURE X WAS EXPANDED USING SYSTEM LIBRARY .. > > > > IEF695I START XX WITH JOBNAME XX IS ASSIGNED TO USER A , GROUP > > B > > > > IEFA111I XX IS USING THE FOLLOWING JOB RELATED SETTINGS: > > > > SWA=ABOVE,TIOT SIZE=64K,DSENQSHR=DISALLOW,GDGBIAS=JOB > > > > and so on. > > > > I've looked at the obvious places, STCCLASS and its defaulted OUTCLASS and > > everything relevant seems the same. > > > > What am I missing? > > > > Mark Jacobs > > > > Sent from ProtonMail, Swiss-based encrypted email. > > > > GPG Public Key - > > https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com > > > > 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 > > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STC JESYSMSG Quandry
that blows my theory - I only have one JES2 MAS and first saw these messages with z/OS 2.3, in SDSF maybe INPUT ON Vs. INPUT OFF ? Carmen Vitullo -Original Message- From: Mark <0224d287a4b1-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN Date: Tuesday, 6 April 2021 3:12 PM CDT Subject: Re: STC JESYSMSG Quandry Both systems are z/OS 2.4. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Tuesday, April 6th, 2021 at 4:03 PM, Carmen Vitullo wrote: > Mark what OS release is the first example? > > IIRC the message was expanded with JES2 z/os 2.3 > > > > Carmen Vitullo > > -Original Message- > > From: Mark 0224d287a4b1-dmarc-requ...@listserv.ua.edu > > To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU > > Date: Tuesday, 6 April 2021 2:34 PM CDT > > Subject: STC JESYSMSG Quandry > > On one system (different JES2 MAS), our STCs while executing only show this > line in SDSF. > > STMT NO. MESSAGE > > 2 IEFC001I PROCEDURE XX WAS EXPANDED USING SYSTEM LIBRARY .. > > But on other systems it's showing much more. > > STMT NO. MESSAGE > > 2 IEFC001I PROCEDURE X WAS EXPANDED USING SYSTEM LIBRARY .. > > IEF695I START XX WITH JOBNAME XX IS ASSIGNED TO USER A , GROUP > B > > IEFA111I XX IS USING THE FOLLOWING JOB RELATED SETTINGS: > > SWA=ABOVE,TIOT SIZE=64K,DSENQSHR=DISALLOW,GDGBIAS=JOB > > and so on. > > I've looked at the obvious places, STCCLASS and its defaulted OUTCLASS and > everything relevant seems the same. > > What am I missing? > > Mark Jacobs > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com > > -- > > > 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 -- 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: Debugging "A high error rate was detected on the Optical Link network." HMC alert
Hello, I understand that ideally I would find the error - but all the values seem correct in my eyes. The optical values are fine, no errors shown on the interfaces, etc. This bugs me a bit. I did not have this issue when it was connected to another mainframe, but it has it now... Regards, On Tue, Apr 6, 2021 at 3:32 PM Radoslaw Skorupka wrote: > You can disable that using HMC features (it is called Optical Network > Errors or similar). > However DON'T DO IT. > This is symptom of some problem. It can be pinched FO cable, dirty > connector or failing SFP module. > Unfortunately it is almost good, so there is no simple way to know > whether cable change helped or not. > We like more consistent failures ;-) > However I would start from visual inspection and then cable change. > > -- > Radoslaw Skorupka > (looking for new job) > Lodz, Poland > > > > W dniu 05.04.2021 o 12:25, Christian Svensson pisze: > > Good day, > > > > Recently I have been getting these kinds of alerts from my HMC. It all > > started when I connected an old DS6800 and the details are: > > > > Node 1 > > Machine: 2498-B40 > > Serial: IBMCA107312B > > Physical Interface: 6620 > > Logical Interface: 0020 > > > > Node 2 > > Machine: 1750-511 > > Serial: IBM13715 > > Physical Interface: 0100 > > Logical Interface: > > > > I keep getting these errors about 3-4 per day with the exact same > > interfaces specified. No others, just these. > > > > When I look at the referenced SAN switch and I do a "porterrshow" things > > seem fine: > >frames enccrccrctootoobadenc > disc > >link loss loss frjt fbsy c3timeoutpcs > > tx rx inerrg_eof shrt long eof out c3 > > failsync sig txrx err > > 20:4.8m 46.9k 0 0 0 0 0 0 0 0 > > 0 2 2 0 0 0 0 0 > > 32: 27.5k 17.7k 0 0 0 0 0 0 0 0 > > 0 0 0 0 0 0 0 0 > > 33: 19.3k 13.6k 0 0 0 0 0 0 0 0 > > 0 0 1 0 0 0 0 0 > > 36: 78 79 0 0 0 0 0 0 0 0 > > 0 0 1 1 0 0 0 0 > > 37: 56 57 0 0 0 0 0 0 0 0 > > 0 0 0 1 0 0 0 0 > > > > I assume the interface given in the alert is in hex, so the error would > be > > about port 32 (which is indeed connected to the DS6800 controller 1, port > > 0). > > As you can see the port seems to be fine. > > > > The full portshow 32 is here: > > portIndex: 32 > > portName: port32 > > portHealth: HEALTHY > > > > Authentication: None > > portDisableReason: None > > portCFlags: 0x1 > > portFlags: 0x1020b03 PRESENT ACTIVE F_PORT G_PORT U_PORT > LOGICAL_ONLINE > > LOGIN NOELP ACCEPT FLOGI > > LocalSwcFlags: 0x0 > > portType: 17.0 > > POD Port: Port is licensed > > portState: 1Online > > Protocol: FC > > portPhys: 6In_Sync portScn: 32 F_Port > > port generation number:16 > > state transition count:3 > > > > portId:662000 > > portIfId:43020017 > > portWwn: 20:20:00:05:1e:e8:74:30 > > portWwn of device(s) connected: > > 50:05:07:63:0e:80:02:11 > > Distance: normal > > portSpeed: N2Gbps > > > > Credit Recovery: Inactive > > Aoq: Inactive > > FAA: Inactive > > F_Trunk: Inactive > > LE domain: 0 > > Peer beacon: Off > > FC Fastwrite: OFF > > Interrupts:0 Link_failure: 0 Frjt: 0 > > Unknown: 0 Loss_of_sync: 0 Fbsy: 0 > > Lli: 15 Loss_of_sig: 0 > > Proc_rqrd: 63 Protocol_err: 0 > > Timed_out: 0 Invalid_word: 0 > > Rx_flushed:0 Invalid_crc: 0 > > Tx_unavail:0 Delim_err:0 > > Free_buffer: 0 Address_err: 0 > > Overrun: 0 Lr_in:3 > > Suspended: 0 Lr_out: 0 > > Parity_err:0 Ols_in: 0 > > 2_parity_err: 0 Ols_out: 3 > > CMI_bus_err: 0 > > > > As far as I can tell the port is doing just fine, and I have not received > > any reports of connectivity issues to the actual DASDs. > > Any suggestions on what is going on, or worst case - how I can disable > > these alerts? > > -- > 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: STC JESYSMSG Quandry
Both systems are z/OS 2.4. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Tuesday, April 6th, 2021 at 4:03 PM, Carmen Vitullo wrote: > Mark what OS release is the first example? > > IIRC the message was expanded with JES2 z/os 2.3 > > > > Carmen Vitullo > > -Original Message- > > From: Mark 0224d287a4b1-dmarc-requ...@listserv.ua.edu > > To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU > > Date: Tuesday, 6 April 2021 2:34 PM CDT > > Subject: STC JESYSMSG Quandry > > On one system (different JES2 MAS), our STCs while executing only show this > line in SDSF. > > STMT NO. MESSAGE > > 2 IEFC001I PROCEDURE XX WAS EXPANDED USING SYSTEM LIBRARY .. > > But on other systems it's showing much more. > > STMT NO. MESSAGE > > 2 IEFC001I PROCEDURE X WAS EXPANDED USING SYSTEM LIBRARY .. > > IEF695I START XX WITH JOBNAME XX IS ASSIGNED TO USER A , GROUP > B > > IEFA111I XX IS USING THE FOLLOWING JOB RELATED SETTINGS: > > SWA=ABOVE,TIOT SIZE=64K,DSENQSHR=DISALLOW,GDGBIAS=JOB > > and so on. > > I've looked at the obvious places, STCCLASS and its defaulted OUTCLASS and > everything relevant seems the same. > > What am I missing? > > Mark Jacobs > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com > > -- > > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STC JESYSMSG Quandry
responding to myself, the IEFA111I message is stating either the ALLOCxx member settings or system defaults for ALLOCxx Carmen Vitullo -Original Message- From: Carmen To: IBM-MAIN Date: Tuesday, 6 April 2021 3:04 PM CDT Subject: Re: STC JESYSMSG Quandry Mark what OS release is the first example? IIRC the message was expanded with JES2 z/os 2.3 Carmen Vitullo -Original Message- From: Mark <0224d287a4b1-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN Date: Tuesday, 6 April 2021 2:34 PM CDT Subject: STC JESYSMSG Quandry On one system (different JES2 MAS), our STCs while executing only show this line in SDSF. STMT NO. MESSAGE 2 IEFC001I PROCEDURE XX WAS EXPANDED USING SYSTEM LIBRARY .. But on other systems it's showing much more. STMT NO. MESSAGE 2 IEFC001I PROCEDURE X WAS EXPANDED USING SYSTEM LIBRARY .. IEF695I START XX WITH JOBNAME XX IS ASSIGNED TO USER A , GROUP B IEFA111I XX IS USING THE FOLLOWING JOB RELATED SETTINGS: SWA=ABOVE,TIOT SIZE=64K,DSENQSHR=DISALLOW,GDGBIAS=JOB and so on. I've looked at the obvious places, STCCLASS and its defaulted OUTCLASS and everything relevant seems the same. What am I missing? Mark Jacobs Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email.. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OMVS
On Tue, 6 Apr 2021 14:24:43 -0500, Steve Beaver wrote: >Would someone please provide me with the BPX "stuff" to auto-magically >allocate a > >ZFS for a user when they first go into ISH? > See also: https://www.ibm.com/docs/en/zos/2.2.0?topic=unix-enabling-automatic-assignment-unique-identities Bur if you have a mixture of OMVS and other UNIX, try to make the UID/GID agree across systems. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STC JESYSMSG Quandry
Mark what OS release is the first example? IIRC the message was expanded with JES2 z/os 2.3 Carmen Vitullo -Original Message- From: Mark <0224d287a4b1-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN Date: Tuesday, 6 April 2021 2:34 PM CDT Subject: STC JESYSMSG Quandry On one system (different JES2 MAS), our STCs while executing only show this line in SDSF. STMT NO. MESSAGE 2 IEFC001I PROCEDURE XX WAS EXPANDED USING SYSTEM LIBRARY .. But on other systems it's showing much more. STMT NO. MESSAGE 2 IEFC001I PROCEDURE X WAS EXPANDED USING SYSTEM LIBRARY .. IEF695I START XX WITH JOBNAME XX IS ASSIGNED TO USER A , GROUP B IEFA111I XX IS USING THE FOLLOWING JOB RELATED SETTINGS: SWA=ABOVE,TIOT SIZE=64K,DSENQSHR=DISALLOW,GDGBIAS=JOB and so on. I've looked at the obvious places, STCCLASS and its defaulted OUTCLASS and everything relevant seems the same. What am I missing? Mark Jacobs Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com -- 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: OMVS
in /etc/u.map name * type ZFS filesystem omvs.u.sysplexname./ZFS < site specific mode RDWR parm rwshare,converttyov5 <- that's me duration 1 delay 10 allocany space(10,5) cyl setuid no security yes I think that's all then run the automount command pointing to auto.master /u /etc/u.map Carmen Vitullo -Original Message- From: Steve To: IBM-MAIN Date: Tuesday, 6 April 2021 2:25 PM CDT Subject: OMVS Would someone please provide me with the BPX "stuff" to auto-magically allocate a ZFS for a user when they first go into ISH? Thanks -- 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
STC JESYSMSG Quandry
On one system (different JES2 MAS), our STCs while executing only show this line in SDSF. STMT NO. MESSAGE 2 IEFC001I PROCEDURE XX WAS EXPANDED USING SYSTEM LIBRARY .. But on other systems it's showing much more. STMT NO. MESSAGE 2 IEFC001I PROCEDURE X WAS EXPANDED USING SYSTEM LIBRARY .. IEF695I START XX WITH JOBNAME XX IS ASSIGNED TO USER A , GROUP B IEFA111I XX IS USING THE FOLLOWING JOB RELATED SETTINGS: SWA=ABOVE,TIOT SIZE=64K,DSENQSHR=DISALLOW,GDGBIAS=JOB and so on. I've looked at the obvious places, STCCLASS and its defaulted OUTCLASS and everything relevant seems the same. What am I missing? Mark Jacobs Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
OMVS
Would someone please provide me with the BPX "stuff" to auto-magically allocate a ZFS for a user when they first go into ISH? Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS lifecycle
W dniu 06.04.2021 o 15:45, Kurt Quackenbush pisze: This page provides the life cycle dates for all z/OS V2 releases. https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=dd=sm=ShopzSeries=897/ENUS5650-ZOS Likewise this page for the z/OS V1 releases: https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=dd=sm=ShopzSeries=897/ENUS5694-A01 And this page for OS/390 V2: https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=dd=sm=ShopzSeries=897/ENUS5647-A01 Curious, why do you want this info for old releases, and why is the other info you found "horribly inconvenient"? First, thank you for your help, I appreciate it. Answering your question: 1. Why I want the info. Just curiosity and noticed discrepancies between some sources (i.e. wiki). Call it morbid pedantry. To be honest I have no business interest in it. 2. Convenience I remember simple table. Clear, easy to use. Similar tables can be found for z/VM and z/VSE systems - with really old system releases. Actually the information I found was OK, search process is inconvenient. I type "z/OS" or "z/OS 2.1" and I get a lot of products and only one or few z/OS entries. I can imagine more convenient interfaces. Further explanations on request. Regards -- Radoslaw Skorupka (looking for new job) Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS lifecycle
I don't know about the OP, but I'd love to have something going back to IBSYS/IBJOB that I could cite in wikipedia articles. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Kurt Quackenbush [ku...@us.ibm.com] Sent: Tuesday, April 6, 2021 9:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS lifecycle This page provides the life cycle dates for all z/OS V2 releases. https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=dd=sm=ShopzSeries=897/ENUS5650-ZOS Likewise this page for the z/OS V1 releases: https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=dd=sm=ShopzSeries=897/ENUS5694-A01 And this page for OS/390 V2: https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=dd=sm=ShopzSeries=897/ENUS5647-A01 Curious, why do you want this info for old releases, and why is the other info you found "horribly inconvenient"? Kurt Quackenbush -- IBM, SMP/E Development Chuck Norris never uses CHECK when he applies PTFs. -- 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: Assembler Language Programming for IBM System z Servers
They have introspection but not a macro language; macro languages have been written using introspection. I believe that LISP was the first to have introspection. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Pew, Curtis G [curtis@austin.utexas.edu] Sent: Tuesday, April 6, 2021 9:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Assembler Language Programming for IBM System z Servers On Apr 5, 2021, at 8:40 PM, Seymour J Metz wrote: > > Actually, the lack of a metalanguage is the norm except for assemblers; PL/I > is an exception in that regard. Ada, Go, Java, Perl, Python, Ruby, Raku (Perl > 6), Rust, etc., lack metalanguages. One might argue that Python and Ruby (at least, I’m not familiar enough with some of the others to say) are their own metalanguages. You can use things like metaclasses and decorators to dynamically generate a fair amount of code. I’ve noticed no one has mentioned Lisp in this discussion. -- Pew, Curtis G curtis@austin.utexas.edu -- 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: Assembler Language Programming for IBM System z Servers
On Apr 5, 2021, at 8:40 PM, Seymour J Metz wrote: > > Actually, the lack of a metalanguage is the norm except for assemblers; PL/I > is an exception in that regard. Ada, Go, Java, Perl, Python, Ruby, Raku (Perl > 6), Rust, etc., lack metalanguages. One might argue that Python and Ruby (at least, I’m not familiar enough with some of the others to say) are their own metalanguages. You can use things like metaclasses and decorators to dynamically generate a fair amount of code. I’ve noticed no one has mentioned Lisp in this discussion. -- Pew, Curtis G curtis@austin.utexas.edu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Meta languages [was: RE: Assembler Language Programming for IBM System z Servers]
> You don't use templates I certainly do use templates. Not sure how you get "don't use templates" from what I wrote. Heck, I *over* used templates in the first large C++ project I ever did, and boy, does that make a mess! Now I think I am down to a happy medium. I don't see them as "competitive" (in a design sense) with macros. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Tuesday, April 6, 2021 5:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Meta languages [was: RE: Assembler Language Programming for IBM System z Servers] On 6/04/2021 1:23 am, Charles Mills wrote: >> But IMHO none easy to learn or use. > I am generally not a fan of meta languages at all. I think writing programs > is hard enough, without having to write two effective programs: one that runs > at compile time and one that runs at run time. > > In my C++, which is now my primary language, I eschew the use of C macros as > much as reasonably possible. Reasonableness is a key here. For a few things, > macros make sense. That's interesting. You don't use templates which are one the most powerful features of C++? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS lifecycle
This page provides the life cycle dates for all z/OS V2 releases. https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=dd=sm=ShopzSeries=897/ENUS5650-ZOS Likewise this page for the z/OS V1 releases: https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=dd=sm=ShopzSeries=897/ENUS5694-A01 And this page for OS/390 V2: https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=dd=sm=ShopzSeries=897/ENUS5647-A01 Curious, why do you want this info for old releases, and why is the other info you found "horribly inconvenient"? Kurt Quackenbush -- IBM, SMP/E Development Chuck Norris never uses CHECK when he applies PTFs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Debugging "A high error rate was detected on the Optical Link network." HMC alert
You can disable that using HMC features (it is called Optical Network Errors or similar). However DON'T DO IT. This is symptom of some problem. It can be pinched FO cable, dirty connector or failing SFP module. Unfortunately it is almost good, so there is no simple way to know whether cable change helped or not. We like more consistent failures ;-) However I would start from visual inspection and then cable change. -- Radoslaw Skorupka (looking for new job) Lodz, Poland W dniu 05.04.2021 o 12:25, Christian Svensson pisze: Good day, Recently I have been getting these kinds of alerts from my HMC. It all started when I connected an old DS6800 and the details are: Node 1 Machine: 2498-B40 Serial: IBMCA107312B Physical Interface: 6620 Logical Interface: 0020 Node 2 Machine: 1750-511 Serial: IBM13715 Physical Interface: 0100 Logical Interface: I keep getting these errors about 3-4 per day with the exact same interfaces specified. No others, just these. When I look at the referenced SAN switch and I do a "porterrshow" things seem fine: frames enccrccrctootoobadenc disc link loss loss frjt fbsy c3timeoutpcs tx rx inerrg_eof shrt long eof out c3 failsync sig txrx err 20:4.8m 46.9k 0 0 0 0 0 0 0 0 0 2 2 0 0 0 0 0 32: 27.5k 17.7k 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 33: 19.3k 13.6k 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 36: 78 79 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 37: 56 57 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 I assume the interface given in the alert is in hex, so the error would be about port 32 (which is indeed connected to the DS6800 controller 1, port 0). As you can see the port seems to be fine. The full portshow 32 is here: portIndex: 32 portName: port32 portHealth: HEALTHY Authentication: None portDisableReason: None portCFlags: 0x1 portFlags: 0x1020b03 PRESENT ACTIVE F_PORT G_PORT U_PORT LOGICAL_ONLINE LOGIN NOELP ACCEPT FLOGI LocalSwcFlags: 0x0 portType: 17.0 POD Port: Port is licensed portState: 1Online Protocol: FC portPhys: 6In_Sync portScn: 32 F_Port port generation number:16 state transition count:3 portId:662000 portIfId:43020017 portWwn: 20:20:00:05:1e:e8:74:30 portWwn of device(s) connected: 50:05:07:63:0e:80:02:11 Distance: normal portSpeed: N2Gbps Credit Recovery: Inactive Aoq: Inactive FAA: Inactive F_Trunk: Inactive LE domain: 0 Peer beacon: Off FC Fastwrite: OFF Interrupts:0 Link_failure: 0 Frjt: 0 Unknown: 0 Loss_of_sync: 0 Fbsy: 0 Lli: 15 Loss_of_sig: 0 Proc_rqrd: 63 Protocol_err: 0 Timed_out: 0 Invalid_word: 0 Rx_flushed:0 Invalid_crc: 0 Tx_unavail:0 Delim_err:0 Free_buffer: 0 Address_err: 0 Overrun: 0 Lr_in:3 Suspended: 0 Lr_out: 0 Parity_err:0 Ols_in: 0 2_parity_err: 0 Ols_out: 3 CMI_bus_err: 0 As far as I can tell the port is doing just fine, and I have not received any reports of connectivity issues to the actual DASDs. Any suggestions on what is going on, or worst case - how I can disable these alerts? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Meta languages [was: RE: Assembler Language Programming for IBM System z Servers]
On 6/04/2021 1:23 am, Charles Mills wrote:
But IMHO none easy to learn or use.
I am generally not a fan of meta languages at all. I think writing programs is
hard enough, without having to write two effective programs: one that runs at
compile time and one that runs at run time.
In my C++, which is now my primary language, I eschew the use of C macros as
much as reasonably possible. Reasonableness is a key here. For a few things,
macros make sense.
That's interesting. You don't use templates which are one the most
powerful features of C++?
One example. I have a lot of bi-modal code: it runs "production" on z/OS and "limited unit
test" on Windows. Rather than wrap block after block with #ifdef WIN32 or #ifdef __MVS__, I do that
once, in a "universal" header file
#ifdef WIN32
static const bool IsZOS = false;
#else
static const bool IsZOS = true;
#endif
Then anywhere in the code I can write
if (IsZOS) {z/OS specific code}
else {Windows specific code}
I think it's a lot easier to read, and there is no runtime performance penalty.
The z/OS optimizing compiler is smart enough to totally eliminate conditionals
based on a constant.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Farley, Peter x23353
Sent: Monday, April 5, 2021 9:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Meta languages [was: RE: Assembler Language Programming for IBM System
z Servers]
True. There is m4 in *ix systems and going back a long time there was ML/1 (I
think there was an academic book published on that one, I think I have a copy
somewhere around here). Undoubtedly others I do not know of or remember.
Probably also Wirth's "literate programming" suite, TeX I think it is called.
But IMHO none easy to learn or use.
--
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: Meta languages [was: RE: Assembler Language Programming for IBM System z Servers]
hi, m4 is text substitution. 25 years ago we used it to create web pages. The same text to create the web and a a paper version. when you give some company "flyer" (5 pages) to clients, you may be interested to have semantically very similar info in the web, don't you. m4 was also used in thewml AFAIR. True. There is m4 in *ix systems and going back a long time there was ML/1 (I think there was an academic book published on that one, I think I have a copy somewhere around here). Undoubtedly others I do not know of or remember. Does someone know whether there is a version of FORMAC (either Fortran or PL/I). Well, it was from IBM ? ;-( Peter Sylvester -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
