The JCL manual explains:
By coding TIME=1440 or TIME=NOLIMIT, the TIME parameter can instead be used to 
give a job or step an unlimited amount of time. Specifically, the system allows 
a step to remain in a continuous wait state for an unlimited time, rather than 
the time limit established through SMF. However, if TIME=1440 is specified on 
the JOB statement, any TIME values on an EXEC statement and any default TIME 
values will be nullified. All steps within the job will have unlimited time, as 
with TIME=1440 or TIME=NOLIMIT.

So TIME=1440 should avoid an S522 abend.

Regards,

          Michael Joseph
Senior Software Engineer
Blue Hill Data Services | CAPS |XyberNET
Computer Technologies U.S.A LLC Companies
Fully Managed On-Shore IT and Data Center Hosting Services
2 Blue Hill Plaza | Pearl River, New York 10965
Direct: 845.875.7041 | Cell: 201.679.4902
[email protected] | www.BlueHillData.com || 

-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Jay 
Maynard
Sent: Sunday, May 18, 2025 9:41 AM
To: [email protected]
Subject: Re: Disable user timeout via JWT?

EXTERNAL EMAIL: Do not reply, click links, or open attachments until you verify 
the SMTP address (sender @domain.com) next to the display name is a trusted 
address.



OK, let's step back and look over things, start to finish.

What's being measured is continuous wait time while the application (whatever 
is on the EXEC= statement) is in control. The common case for TSO is the time 
that the TSO application program spends waiting for the user to press ENTER.

In SMFPRMxx, there are three parameters that control the wait time before the 
system calls IEFUTL: JWT, TWT, and SWT. JWT is the default wait time in hours 
and minutes; TWT and SWT supply the same values for TSO sessions and STCs, 
respectively, and default to JWT if not specified.

The documentation for SMFPRMxx says that if TIME=1440 is coded on the JOB or 
EXEC JCL statement, or if it is defaulted by the JES class attribute of 
TIME=1440, IEFUTL is not invoked for that job. It also says that the wait time 
interval is checked every 90 seconds, so the actual call to IEFUTL might be 
delayed up to that long.

The documentation for IEFUTL says that if it is not invoked (because it's been 
disabled or is not specified in the SMFPRMxx EXITS= parameter), the system 
proceeds to issue the S322 or S522 ABEND. There's no mention of
TIME=1440 turning that off in that discussion.

So there are a few parameters that can affect it: SMFPRMxx [JTS]WT, TIME= on 
the EXEC statement, JES2's class TIME= defaults, and IEFUTL itself.

Do you even have an IEFUTL? Is it specified in SMFPRMxx's EXITS= statement?

On Sun, May 18, 2025 at 8:24 AM Phil Smith III <[email protected]> wrote:

> I'm not arguing--I don't know, obviously--but that contradicts folks 
> who said that TIME= on the EXEC statement in the logon PROC would 
> work. You're saying no?
>
> But meanwhile, the PARMLIB member has
> JWT(2400)              /* 522 AFTER 24 HOURS  */
> so I'd expect it to be, like, 24 hours. And remember that 
> $TJOBCLASS(TSU),TIME= shows
> RESPONSE=S0W1
>  $HASP837 JOBCLASS(TSU)
>  $HASP837 JOBCLASS(TSU)       AUTH=(ALL),BLP=NO,COMMAND=EXECUTE,
>  $HASP837                     CONDPURG=NO,DSENQSHR=ALLOW,
>  $HASP837                     IEFUJP=YES,IEFUSO=YES,
>  $HASP837                     JESCANCEL=ALLOWED,JESLOG=(NOSPIN),
>  $HASP837                     LOG=YES,MSGLEVEL=(1,1),MSGCLASS=K,
>  $HASP837                     OUTDISP=(PURGE,HOLD),OUTPUT=YES,
>  $HASP837                     PERFORM=000,PROMO_RATE=0,
>  $HASP837                     PROCLIB=00,QAFF=(ANY),REGION=0000K,
>  $HASP837                     SWA=ABOVE,TIME=(001440,00),
>  $HASP837                     TYPE26=YES,TYPE6=YES,
>  $HASP837                     RESOURCE(TG)=(LIMIT=DEFAULT,
>  $HASP837                     ACTION=DEFAULT),
>  $HASP837                     RESOURCE(JOE)=(LIMIT=DEFAULT,
>  $HASP837                     ACTION=DEFAULT),DESC=
>
> So I'm feeling like it's not SMF?
>
> -----Original Message-----
> From: IBM Mainframe Discussion List <[email protected]> On 
> Behalf Of Seymour J Metz
> Sent: Sunday, May 18, 2025 9:18 AM
> To: [email protected]
> Subject: Re: Disable user timeout via JWT?
>
> There's nothing special about 24 hours; the wait-time limit is set by SMF.
> You can change it in JES parameters, but not in JCL.
>
> --
> Shmuel (Seymour J.) Metz
> https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!GHHOssT
> OuSZjAQ!ZpAT8X3v30Y8PkmKyAFqKbz73sKRjd8qKHzlcPnw_lVil_KAEIeJ_ustaUXSXa
> 2s5NYedgu78LJ_86NONVTwX_FBq387V0AS9G7BwQ$
> עַם יִשְׂרָאֵל חַי
> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>
>
>
> ________________________________________
> From: IBM Mainframe Discussion List <[email protected]> on 
> behalf of Phil Smith III <[email protected]>
> Sent: Sunday, May 18, 2025 9:13 AM
> To: [email protected] <[email protected]>
> Subject: Re: Disable user timeout via JWT?
>
>
> External Message: Use Caution
>
>
> I can try that, but it isn't even going 24 hours, so something else 
> must be triggering, no?
>
> Does this tell anyone anything:
> IEA631I  OPERATOR PHS      NOW INACTIVE, SYSTEM=S0W1    , LU=TCP00025
> IEF450I PHS DYNISPFM DYNISPFM - ABEND=S522 U0000 REASON=00000000  728
>         TIME=16.47.23
> $HASP395 PHS      ENDED - ABEND=S522
>
> Doc 
> (https://urldefense.com/v3/__https://www.ibm.com/docs/en/zos/2.5.0?topic=messages-iea631i__;!!GHHOssTOuSZjAQ!ZpAT8X3v30Y8PkmKyAFqKbz73sKRjd8qKHzlcPnw_lVil_KAEIeJ_ustaUXSXa2s5NYedgu78LJ_86NONVTwX_FBq387V0DnyzQgHw$
>  ) says:
> An extended MCS (EMCS) console has been deactivated.
>
> This suggests to me that my connection is 'special' but I don't know 
> what EMCS means, and some searching hasn't helped. If this turns out 
> to be key, I'll feel stoopid for not having pasted it earlier!
>
> -----Original Message-----
> From: IBM Mainframe Discussion List <[email protected]> On 
> Behalf Of Seymour J Metz
> Sent: Saturday, May 17, 2025 6:17 PM
> To: [email protected]
> Subject: Re: Disable user timeout via JWT?
>
> TIME=UNLIMITED?
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to [email protected] with the message: INFO IBM-MAIN
>
>
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to [email protected] with the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to [email protected] with the message: INFO IBM-MAIN
>


--
Jay Maynard

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
[email protected] with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to