Invision/Cloverleaf SNA

[Anonymous]

Having a strange problem with our Invision to Cloverleaf SNA interface (GRV3).  

For the last month or so, every time Siemens does maintenance on our Invision system, when the interface comes back up, the interface won’t send data.  The connection is ON/FREE, but no data comes.  We inevitably have to open a ticket with Siemens to get it going.

I just opened a ticket with Siemens, but got the typical “not sure how we can troubleshoot since you don’t have Openlink”.  Has any other Invision to Cloverleaf SNA users experienced this?  We’ve been running fine for years, which tells me something on Siemens side has changed…

Topic

[Susan Rosko]

Hi Matt:

Sorry for the extended response… the OPENLINK comment from Siemens sets my blood pressure up…

When I read your description it sounds to me like you might be experiencing a INVISION TIF abend when your regions are brought up again.  The interface states are ON/FREE, but no data passes on them.  This usually will display for the operations staff with a message similar to the following:

@ARKE21233: (A2G0  ) TIF ABEND T010 IN PROGRAM CHPPTIFM LOADING IGATMFUN

@A2K       01:29:07 ARKE21233: (A2G0  ) TIF ABEND T010 IN PROGRAM                                                    

Here’s what I do to resolve this:

Stop all your interfaces on INVISION.

First check to see if the COMQFILE is open.  If not, open it and reset the TIF switch in INVISION (this is in the OAS INTERFACE SUBSYSTEMS MENU, TIF SUBSYSTEM MENU, TURN OFF ABEND SWITCH; if you have INVISION model pathways this should be from the main menu options: 20,99,10, PF3, PF2).  Start your interfaces on INVISION.  You may not see anything happening at first.  If no patient updates or orders are being performed on INVISION right away, you may want to quickly “kick” the interface, just have someone do some kind of update on an active patient.  Once the first INVISION update takes place after the switch is reset the held messages should start showing up in the queue.  

If you find that the fix above does not work, you may need to skip a logfile record because it errored out on mappings or some other mismatch.   Stop all your interfaces again.  Go to the same TIF SUBSYSTEM MENU above, then SKIP LOGFILE RECORD (if you have INVISION model pathways, this should be 20, 99, 10, PF3, PF9).  You will get a warning about data being lost, but okay it.   Then TURN OFF ABEND SWITCH (on same screen PF2).  Again, you may need to kick the interface by having a patient update performed.  I find that skipping the logfile record usually takes care of the problem.

If anyone in your area has trouble ticket access in Siemens, ask for them to obtain the copy of the last resolution done for your problem.  I would bet they did one of the above fixes.  

Some other related tidbits:

A cleaner stop and start of all INVISION interfaces is to use Siemens CMONSTOP and CMONSTRT.  If you use these commands you may need to manually shut down the COMQFILE after performing the CMONSTOP and manually open the COMQFILE before performing the CMONSTRT.  After doing the CMONSTRT reset the TIF abend switch as stated above.  We typically have not had to do this with our SUT applies even our most recent ones.

We have found that the COMQFILE needs regular reorging or you might run into slow or stopped interface processing.  We have a job we created that does this during our weekly CICS recycle downtime.  If you want our JCL for that, contact me.  I assume you are an ICO site if you are doing your own SUT applies, we are an ICO site.

We have problems both with our weekly recycle of CICS regions and with SUT applies with some INVISION connections being in an unacquired state in CICS and then we need to manually acquire the CICS connections before they will connect with Cloverleaf.  Typically this has occured with our inbound (INVISION RTIF) interface connections and not our outbound (TIF) interface connections.

[Anonymous]

Hi Matt!..  Turn up your trace level to see what is going on with the interface on the Invision side, you’ll usually see some kind of error message… if not…

my thoughts: Usually a “ON/Free” state tells me that the mainframe VTAM node is released and has not been acquired. Try acquiring the connection on the Invision CICS (CEMT I CONN). If you can not acquire, try resetting the VTAM node for the cloverleaf connection and then try to acquire again.

If that all fails to connect, try to look at your SNA connections on cloverleaf. You may need to stop and start SNA on your server and then reacquire on the mainframe side…

Are you RCO or ICO? If your RCO, maybe they are just forgetting to aquire your connection?

Good Luck!  Mary.

[Anonymous]

Thank you both for your responses.  Here’s what Siemens said:

The hospital received a TIF abend at 00:40:26 this morning just as    

CICS was beginning to come down for scheduled maintainence.  The      

abend was a T034 with a return code of 5401.  This indicates that TIF

could not write to the COMQFILE because the control block could not  

be allocated for the system TIF was attempting to write to.  I went  

through the dump and found that TIF was trying to write a record to  

the B3M080AD queue.  System 80 is not in PRCOM so the control block  

could not be allocated for system 80.  There is code in place to      

check for this condition and just issue a message rather then abend  

all of TIF.  I did find these messages numerous times throughout    

the day including just before the abend:                            

00:40:25 ARKE20207: (B3M080) Interface definition not found          

****                                                                

However, since CICS was in shutdown mode I suspect that this code    

was somehow bypassed.                                                

I went in and added system 80 to PRCOM.  When I displayed the        

interface, I found in excess of 57000 records on the system.  This  

appears to be an interface that was used at one time but is currently

de-installed.  However because the TIF tables and triggers are still

there, records are still being generated wasting DASD and possibly    

affecting performance. SSKB# 3088983 talks about removing interfaces  

from the COM SUB that are no longer being used.  Because system 80 is

now in PRCOM though, the problem with the T034 should no longer occur.

I’m not sure exactly what that means (I’m not the Invision or SNA expert), but it sounds a little like what Susan was explaining.  They seem to think this is going to fix our problem, and that’s all I care about.

Susan, it almost sounds like you’ve heard the Openlink comment before  : )

[Author]

Replies