We are implementing z/OSMF software update functionality and when selecting "Install Recommended", this starts a TSO session for the Rest Service.  Then, even after properly logging out of z/OSMF, the TSO session that was started when clicking Install Recommended continues running on our system.  Is there a way to have this TSO session logoff when logging out of z/OSMF?  Is this a configuration setting for z/OSMF or a specific action we need to perform to logoff this TSO session when logging out of z/OSMF or exiting the software update feature of z/OSMF ?  Or does this session just continue running until it times out or someone cancels it?

Tracy, z/OSMF Software Update will start TSO address spaces explicitly in which to run SMP/E.  When the SMP/E commands (like LIST and APPLY) are done, then these TSO address spaces should end.  In addition, before running SMP/E, Software Update allocates temporary data sets to contain the SMP/E output.  It uses the z/OSMF Data sets REST API.  The z/OSMF Data sets REST API also starts a TSO address space to perform its actions.  Unlike the TSO address spaces where SMP/E runs, this address space for the Data set REST API seems to run longer, waiting for additional requests.  Off hand I do not know how long it will wait before timing out and ending, but I can find out.

Can you determine which TSO address space continues running after you log off z/OSMF?  Do you see any output from the TSO job, and if so can you share a snippet?  Has SMP/E processing completed when you observe the TSO address space still running?

We are implementing z/OSMF software update functionality and when selecting "Install Recommended", this starts a TSO session for the Rest Service.  Then, even after properly logging out of z/OSMF, the TSO session that was started when clicking Install Recommended continues running on our system.  Is there a way to have this TSO session logoff when logging out of z/OSMF?  Is this a configuration setting for z/OSMF or a specific action we need to perform to logoff this TSO session when logging out of z/OSMF or exiting the software update feature of z/OSMF ?  Or does this session just continue running until it times out or someone cancels it?

Hi Kurt,

Thank you for your reply.  We looked closer after seeing your response and it looks like when we click Install Recommended in Software Update, as you mentioned, a TSO address space starts, runs an apply check, and ends.  And there is another TSO address space that starts and doesn't end, even after logging out of z/OSMF.  It seems like this address space ought to end when a user logs out of z/OSMF.  I do see logging in this address space and it does look like what you described (allocating datasets) - pasting a snippet of the log here (with UID obfuscated):

[09:09:32.614145] ServletDispatcher[I]: Received request: POST /ds/UID.T1684242.T571488.SMPOUT                                   
[09:09:32.615374] ServletDispatcher[I]: z/OSMF transaction: tx0000000000000037                                                     
[09:09:32.615513] ServletDispatcher[I]: Invoking Servlet: SELECT  PGM(IZUGPODS) PARM(-LI,t -q 983045 -r 0x19ffd028 )               
[09:09:32.626044] CreateDatasetServlet[I]: RequestInputStream={"secondary":30,"dsorg":"PS","recfm":"FB","unit":"SYSDA","           
blksize":12100,"alcunit":"CYL","primary":30,"lrecl":121}                                                                           
[09:09:32.669289] ServletDispatcher[I]: Servlet IZUGPODS completed,  RC=0                                                          
[09:09:32.676274] ServletDispatcher[I]: Received request: POST /ds/UID.T1684242.T571488.SMPRPT                                   
[09:09:32.676295] ServletDispatcher[I]: z/OSMF transaction: tx0000000000000039                                                     
[09:09:32.676368] ServletDispatcher[I]: Invoking Servlet: SELECT  PGM(IZUGPODS) PARM(-LI,t -q 983045 -r 0x19ffda60 )               
[09:09:32.681726] CreateDatasetServlet[I]: RequestInputStream={"secondary":30,"dsorg":"PS","recfm":"FB","unit":"SYSDA","           
blksize":12100,"alcunit":"CYL","primary":30,"lrecl":121}                                                                           
[09:09:32.713557] ServletDispatcher[I]: Servlet IZUGPODS completed,  RC=0                                                          
[09:09:32.718963] ServletDispatcher[I]: Received request: POST /ds/UID.T1684242.T571488.SMPHRPT                                  
[09:09:32.718980] ServletDispatcher[I]: z/OSMF transaction: tx000000000000003B                                                     
[09:09:32.719053] ServletDispatcher[I]: Invoking Servlet: SELECT  PGM(IZUGPODS) PARM(-LI,t -q 983045 -r 0x19ffda68 )               
[09:09:32.724906] CreateDatasetServlet[I]: RequestInputStream={"secondary":30,"dsorg":"PS","recfm":"FB","unit":"SYSDA","           
blksize":12100,"alcunit":"CYL","primary":30,"lrecl":121}                                                                           
[09:09:32.781763] ServletDispatcher[I]: Servlet IZUGPODS completed,  RC=0            

If we want this address space to end when a user logs out of z/OSMF, do we need to submit an enhancement request for this?  Or is there already a way to configure this?

I do believe all SMP/E processing has completed, given that the apply check runs with a CC 0 and the SMP/E TSO address space ends.

It looks like after roughly 20 minutes of inactivity, the REST API address space ends with a 222 on our system, I see this in the log when it ends (again UID obfuscated):

BPXP018I THREAD 19F3580000000000, IN PROCESS 50332159, ENDED  
WITHOUT BEING UNDUBBED WITH COMPLETION CODE 40222000               
, AND REASON CODE 00000000.                                        
IEF450I UID IZUFPROC IZUFPROC - ABEND=S222 U0000 REASON=00000000 

Thank you,
Tracy

Tracy, z/OSMF Software Update will start TSO address spaces explicitly in which to run SMP/E.  When the SMP/E commands (like LIST and APPLY) are done, then these TSO address spaces should end.  In addition, before running SMP/E, Software Update allocates temporary data sets to contain the SMP/E output.  It uses the z/OSMF Data sets REST API.  The z/OSMF Data sets REST API also starts a TSO address space to perform its actions.  Unlike the TSO address spaces where SMP/E runs, this address space for the Data set REST API seems to run longer, waiting for additional requests.  Off hand I do not know how long it will wait before timing out and ending, but I can find out.

Can you determine which TSO address space continues running after you log off z/OSMF?  Do you see any output from the TSO job, and if so can you share a snippet?  Has SMP/E processing completed when you observe the TSO address space still running?

We are implementing z/OSMF software update functionality and when selecting "Install Recommended", this starts a TSO session for the Rest Service.  Then, even after properly logging out of z/OSMF, the TSO session that was started when clicking Install Recommended continues running on our system.  Is there a way to have this TSO session logoff when logging out of z/OSMF?  Is this a configuration setting for z/OSMF or a specific action we need to perform to logoff this TSO session when logging out of z/OSMF or exiting the software update feature of z/OSMF ?  Or does this session just continue running until it times out or someone cancels it?

Tracy, yup, the TSO address space which continues to run does indeed look like it belongs to the z/OSMF Data Sets REST API.  I'm told it will end approximately 10 - 13 minutes after no activity.  As far as I know there are currently no external controls in z/OSMF which can affect how long the TSO address space lives after logging off z/OSMF.  I agree an enhancement request is warranted if you would like to change this processing.

Hi Kurt,

Thank you for your reply.  We looked closer after seeing your response and it looks like when we click Install Recommended in Software Update, as you mentioned, a TSO address space starts, runs an apply check, and ends.  And there is another TSO address space that starts and doesn't end, even after logging out of z/OSMF.  It seems like this address space ought to end when a user logs out of z/OSMF.  I do see logging in this address space and it does look like what you described (allocating datasets) - pasting a snippet of the log here (with UID obfuscated):

[09:09:32.614145] ServletDispatcher[I]: Received request: POST /ds/UID.T1684242.T571488.SMPOUT                                   
[09:09:32.615374] ServletDispatcher[I]: z/OSMF transaction: tx0000000000000037                                                     
[09:09:32.615513] ServletDispatcher[I]: Invoking Servlet: SELECT  PGM(IZUGPODS) PARM(-LI,t -q 983045 -r 0x19ffd028 )               
[09:09:32.626044] CreateDatasetServlet[I]: RequestInputStream={"secondary":30,"dsorg":"PS","recfm":"FB","unit":"SYSDA","           
blksize":12100,"alcunit":"CYL","primary":30,"lrecl":121}                                                                           
[09:09:32.669289] ServletDispatcher[I]: Servlet IZUGPODS completed,  RC=0                                                          
[09:09:32.676274] ServletDispatcher[I]: Received request: POST /ds/UID.T1684242.T571488.SMPRPT                                   
[09:09:32.676295] ServletDispatcher[I]: z/OSMF transaction: tx0000000000000039                                                     
[09:09:32.676368] ServletDispatcher[I]: Invoking Servlet: SELECT  PGM(IZUGPODS) PARM(-LI,t -q 983045 -r 0x19ffda60 )               
[09:09:32.681726] CreateDatasetServlet[I]: RequestInputStream={"secondary":30,"dsorg":"PS","recfm":"FB","unit":"SYSDA","           
blksize":12100,"alcunit":"CYL","primary":30,"lrecl":121}                                                                           
[09:09:32.713557] ServletDispatcher[I]: Servlet IZUGPODS completed,  RC=0                                                          
[09:09:32.718963] ServletDispatcher[I]: Received request: POST /ds/UID.T1684242.T571488.SMPHRPT                                  
[09:09:32.718980] ServletDispatcher[I]: z/OSMF transaction: tx000000000000003B                                                     
[09:09:32.719053] ServletDispatcher[I]: Invoking Servlet: SELECT  PGM(IZUGPODS) PARM(-LI,t -q 983045 -r 0x19ffda68 )               
[09:09:32.724906] CreateDatasetServlet[I]: RequestInputStream={"secondary":30,"dsorg":"PS","recfm":"FB","unit":"SYSDA","           
blksize":12100,"alcunit":"CYL","primary":30,"lrecl":121}                                                                           
[09:09:32.781763] ServletDispatcher[I]: Servlet IZUGPODS completed,  RC=0            

If we want this address space to end when a user logs out of z/OSMF, do we need to submit an enhancement request for this?  Or is there already a way to configure this?

I do believe all SMP/E processing has completed, given that the apply check runs with a CC 0 and the SMP/E TSO address space ends.

It looks like after roughly 20 minutes of inactivity, the REST API address space ends with a 222 on our system, I see this in the log when it ends (again UID obfuscated):

BPXP018I THREAD 19F3580000000000, IN PROCESS 50332159, ENDED  
WITHOUT BEING UNDUBBED WITH COMPLETION CODE 40222000               
, AND REASON CODE 00000000.                                        
IEF450I UID IZUFPROC IZUFPROC - ABEND=S222 U0000 REASON=00000000 

Thank you,
Tracy

Tracy, z/OSMF Software Update will start TSO address spaces explicitly in which to run SMP/E.  When the SMP/E commands (like LIST and APPLY) are done, then these TSO address spaces should end.  In addition, before running SMP/E, Software Update allocates temporary data sets to contain the SMP/E output.  It uses the z/OSMF Data sets REST API.  The z/OSMF Data sets REST API also starts a TSO address space to perform its actions.  Unlike the TSO address spaces where SMP/E runs, this address space for the Data set REST API seems to run longer, waiting for additional requests.  Off hand I do not know how long it will wait before timing out and ending, but I can find out.

Can you determine which TSO address space continues running after you log off z/OSMF?  Do you see any output from the TSO job, and if so can you share a snippet?  Has SMP/E processing completed when you observe the TSO address space still running?

We are implementing z/OSMF software update functionality and when selecting "Install Recommended", this starts a TSO session for the Rest Service.  Then, even after properly logging out of z/OSMF, the TSO session that was started when clicking Install Recommended continues running on our system.  Is there a way to have this TSO session logoff when logging out of z/OSMF?  Is this a configuration setting for z/OSMF or a specific action we need to perform to logoff this TSO session when logging out of z/OSMF or exiting the software update feature of z/OSMF ?  Or does this session just continue running until it times out or someone cancels it?

Thank you for confirming Kurt!  What's the best way to submit this enhancement request?

Tracy, yup, the TSO address space which continues to run does indeed look like it belongs to the z/OSMF Data Sets REST API.  I'm told it will end approximately 10 - 13 minutes after no activity.  As far as I know there are currently no external controls in z/OSMF which can affect how long the TSO address space lives after logging off z/OSMF.  I agree an enhancement request is warranted if you would like to change this processing.

Hi Kurt,

Thank you for your reply.  We looked closer after seeing your response and it looks like when we click Install Recommended in Software Update, as you mentioned, a TSO address space starts, runs an apply check, and ends.  And there is another TSO address space that starts and doesn't end, even after logging out of z/OSMF.  It seems like this address space ought to end when a user logs out of z/OSMF.  I do see logging in this address space and it does look like what you described (allocating datasets) - pasting a snippet of the log here (with UID obfuscated):

[09:09:32.614145] ServletDispatcher[I]: Received request: POST /ds/UID.T1684242.T571488.SMPOUT                                   
[09:09:32.615374] ServletDispatcher[I]: z/OSMF transaction: tx0000000000000037                                                     
[09:09:32.615513] ServletDispatcher[I]: Invoking Servlet: SELECT  PGM(IZUGPODS) PARM(-LI,t -q 983045 -r 0x19ffd028 )               
[09:09:32.626044] CreateDatasetServlet[I]: RequestInputStream={"secondary":30,"dsorg":"PS","recfm":"FB","unit":"SYSDA","           
blksize":12100,"alcunit":"CYL","primary":30,"lrecl":121}                                                                           
[09:09:32.669289] ServletDispatcher[I]: Servlet IZUGPODS completed,  RC=0                                                          
[09:09:32.676274] ServletDispatcher[I]: Received request: POST /ds/UID.T1684242.T571488.SMPRPT                                   
[09:09:32.676295] ServletDispatcher[I]: z/OSMF transaction: tx0000000000000039                                                     
[09:09:32.676368] ServletDispatcher[I]: Invoking Servlet: SELECT  PGM(IZUGPODS) PARM(-LI,t -q 983045 -r 0x19ffda60 )               
[09:09:32.681726] CreateDatasetServlet[I]: RequestInputStream={"secondary":30,"dsorg":"PS","recfm":"FB","unit":"SYSDA","           
blksize":12100,"alcunit":"CYL","primary":30,"lrecl":121}                                                                           
[09:09:32.713557] ServletDispatcher[I]: Servlet IZUGPODS completed,  RC=0                                                          
[09:09:32.718963] ServletDispatcher[I]: Received request: POST /ds/UID.T1684242.T571488.SMPHRPT                                  
[09:09:32.718980] ServletDispatcher[I]: z/OSMF transaction: tx000000000000003B                                                     
[09:09:32.719053] ServletDispatcher[I]: Invoking Servlet: SELECT  PGM(IZUGPODS) PARM(-LI,t -q 983045 -r 0x19ffda68 )               
[09:09:32.724906] CreateDatasetServlet[I]: RequestInputStream={"secondary":30,"dsorg":"PS","recfm":"FB","unit":"SYSDA","           
blksize":12100,"alcunit":"CYL","primary":30,"lrecl":121}                                                                           
[09:09:32.781763] ServletDispatcher[I]: Servlet IZUGPODS completed,  RC=0            

If we want this address space to end when a user logs out of z/OSMF, do we need to submit an enhancement request for this?  Or is there already a way to configure this?

I do believe all SMP/E processing has completed, given that the apply check runs with a CC 0 and the SMP/E TSO address space ends.

It looks like after roughly 20 minutes of inactivity, the REST API address space ends with a 222 on our system, I see this in the log when it ends (again UID obfuscated):

BPXP018I THREAD 19F3580000000000, IN PROCESS 50332159, ENDED  
WITHOUT BEING UNDUBBED WITH COMPLETION CODE 40222000               
, AND REASON CODE 00000000.                                        
IEF450I UID IZUFPROC IZUFPROC - ABEND=S222 U0000 REASON=00000000 

Thank you,
Tracy

Tracy, z/OSMF Software Update will start TSO address spaces explicitly in which to run SMP/E.  When the SMP/E commands (like LIST and APPLY) are done, then these TSO address spaces should end.  In addition, before running SMP/E, Software Update allocates temporary data sets to contain the SMP/E output.  It uses the z/OSMF Data sets REST API.  The z/OSMF Data sets REST API also starts a TSO address space to perform its actions.  Unlike the TSO address spaces where SMP/E runs, this address space for the Data set REST API seems to run longer, waiting for additional requests.  Off hand I do not know how long it will wait before timing out and ending, but I can find out.

Can you determine which TSO address space continues running after you log off z/OSMF?  Do you see any output from the TSO job, and if so can you share a snippet?  Has SMP/E processing completed when you observe the TSO address space still running?

We are implementing z/OSMF software update functionality and when selecting "Install Recommended", this starts a TSO session for the Rest Service.  Then, even after properly logging out of z/OSMF, the TSO session that was started when clicking Install Recommended continues running on our system.  Is there a way to have this TSO session logoff when logging out of z/OSMF?  Is this a configuration setting for z/OSMF or a specific action we need to perform to logoff this TSO session when logging out of z/OSMF or exiting the software update feature of z/OSMF ?  Or does this session just continue running until it times out or someone cancels it?

The IBM Z Hardware and Operating Systems Ideas Portal:
https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/

Thank you for confirming Kurt!  What's the best way to submit this enhancement request?

Tracy, yup, the TSO address space which continues to run does indeed look like it belongs to the z/OSMF Data Sets REST API.  I'm told it will end approximately 10 - 13 minutes after no activity.  As far as I know there are currently no external controls in z/OSMF which can affect how long the TSO address space lives after logging off z/OSMF.  I agree an enhancement request is warranted if you would like to change this processing.

Hi Kurt,

Thank you for your reply.  We looked closer after seeing your response and it looks like when we click Install Recommended in Software Update, as you mentioned, a TSO address space starts, runs an apply check, and ends.  And there is another TSO address space that starts and doesn't end, even after logging out of z/OSMF.  It seems like this address space ought to end when a user logs out of z/OSMF.  I do see logging in this address space and it does look like what you described (allocating datasets) - pasting a snippet of the log here (with UID obfuscated):

[09:09:32.614145] ServletDispatcher[I]: Received request: POST /ds/UID.T1684242.T571488.SMPOUT                                   
[09:09:32.615374] ServletDispatcher[I]: z/OSMF transaction: tx0000000000000037                                                     
[09:09:32.615513] ServletDispatcher[I]: Invoking Servlet: SELECT  PGM(IZUGPODS) PARM(-LI,t -q 983045 -r 0x19ffd028 )               
[09:09:32.626044] CreateDatasetServlet[I]: RequestInputStream={"secondary":30,"dsorg":"PS","recfm":"FB","unit":"SYSDA","           
blksize":12100,"alcunit":"CYL","primary":30,"lrecl":121}                                                                           
[09:09:32.669289] ServletDispatcher[I]: Servlet IZUGPODS completed,  RC=0                                                          
[09:09:32.676274] ServletDispatcher[I]: Received request: POST /ds/UID.T1684242.T571488.SMPRPT                                   
[09:09:32.676295] ServletDispatcher[I]: z/OSMF transaction: tx0000000000000039                                                     
[09:09:32.676368] ServletDispatcher[I]: Invoking Servlet: SELECT  PGM(IZUGPODS) PARM(-LI,t -q 983045 -r 0x19ffda60 )               
[09:09:32.681726] CreateDatasetServlet[I]: RequestInputStream={"secondary":30,"dsorg":"PS","recfm":"FB","unit":"SYSDA","           
blksize":12100,"alcunit":"CYL","primary":30,"lrecl":121}                                                                           
[09:09:32.713557] ServletDispatcher[I]: Servlet IZUGPODS completed,  RC=0                                                          
[09:09:32.718963] ServletDispatcher[I]: Received request: POST /ds/UID.T1684242.T571488.SMPHRPT                                  
[09:09:32.718980] ServletDispatcher[I]: z/OSMF transaction: tx000000000000003B                                                     
[09:09:32.719053] ServletDispatcher[I]: Invoking Servlet: SELECT  PGM(IZUGPODS) PARM(-LI,t -q 983045 -r 0x19ffda68 )               
[09:09:32.724906] CreateDatasetServlet[I]: RequestInputStream={"secondary":30,"dsorg":"PS","recfm":"FB","unit":"SYSDA","           
blksize":12100,"alcunit":"CYL","primary":30,"lrecl":121}                                                                           
[09:09:32.781763] ServletDispatcher[I]: Servlet IZUGPODS completed,  RC=0            

If we want this address space to end when a user logs out of z/OSMF, do we need to submit an enhancement request for this?  Or is there already a way to configure this?

I do believe all SMP/E processing has completed, given that the apply check runs with a CC 0 and the SMP/E TSO address space ends.

It looks like after roughly 20 minutes of inactivity, the REST API address space ends with a 222 on our system, I see this in the log when it ends (again UID obfuscated):

BPXP018I THREAD 19F3580000000000, IN PROCESS 50332159, ENDED  
WITHOUT BEING UNDUBBED WITH COMPLETION CODE 40222000               
, AND REASON CODE 00000000.                                        
IEF450I UID IZUFPROC IZUFPROC - ABEND=S222 U0000 REASON=00000000 

Thank you,
Tracy

Tracy, z/OSMF Software Update will start TSO address spaces explicitly in which to run SMP/E.  When the SMP/E commands (like LIST and APPLY) are done, then these TSO address spaces should end.  In addition, before running SMP/E, Software Update allocates temporary data sets to contain the SMP/E output.  It uses the z/OSMF Data sets REST API.  The z/OSMF Data sets REST API also starts a TSO address space to perform its actions.  Unlike the TSO address spaces where SMP/E runs, this address space for the Data set REST API seems to run longer, waiting for additional requests.  Off hand I do not know how long it will wait before timing out and ending, but I can find out.

Can you determine which TSO address space continues running after you log off z/OSMF?  Do you see any output from the TSO job, and if so can you share a snippet?  Has SMP/E processing completed when you observe the TSO address space still running?

We are implementing z/OSMF software update functionality and when selecting "Install Recommended", this starts a TSO session for the Rest Service.  Then, even after properly logging out of z/OSMF, the TSO session that was started when clicking Install Recommended continues running on our system.  Is there a way to have this TSO session logoff when logging out of z/OSMF?  Is this a configuration setting for z/OSMF or a specific action we need to perform to logoff this TSO session when logging out of z/OSMF or exiting the software update feature of z/OSMF ?  Or does this session just continue running until it times out or someone cancels it?