Funny things happens in STMS

[Former Member]

Hi all

Transporting between two iSeries systems usually works fine, but in this case I have some mysterious things happening.

First of all, the transport is very slow. QFileSrv.400 is used in profile. Regarding Sap Note 68487 there is some improvement but I'm not sure if it applies to more than one-systems config. This is a two-systems config. (DEV -> PRD)

Second, newly added transports is missing when doing a refresh of the screen in STMS -> Import queue overview. Sometimes is just the text that is missing :-[ After a manual add of transport it then starts and runs for ever.....

Anyone with a good idea ?

Best regards

Mads Hammer

[Former Member]

Hi Mirchael

I checked your recommendations and all was OK.

I have now deleted the configuration and created a new config with new routes and groups.

I did create an empty request and transported that through the whole system and everything went fine. The request was vissible in the production system, which was the main problem before.

I hope this solves it.

Maybe the TPPARAM had some errors but it looked fine........

Best regards

Mads Hammer

[Former Member]

Hi Michael

I will check this tonight.

Thanks in advance.

Best regards

Mads Hammer

[Former Member]

Hi Mads

You need to check a few things-

assuming you have the global transport directory on the DEV host (let's call it sapdev) and the PRD host (sapprd) is pointing back to it , run:

WRKLNK DETAIL(EXTENDED) DSPOPT(ALL)

On sapdev, you will most likely have /usr/sap/trans being a symbolic link to /sapmnt/trans (what release are you on?)

On sapprd , you should have /usr/sap/trans as a symbolic link to /QFileSvr.400/sapdev/sapmnt/trans

If that's not the case, you need to fix with a MKDIR command on sapprd, make sure this is also in the system startup program, and remove and recreate the correct link with DEL and ADDLNK as per the note.

QSECOFR password on both hosts also must be the same.

On sapdev host, you should have the i5/OS user profile PRD<nn> where nn is the PRD instance number. If not you should create it with the CRTSAPUSR *SIDINST kernel command. If you haven't changed the password all should be good. See note 67213 also.

If you've made changes as above, do a restart of the instance.

regards,

Michael