• If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Announcement

Collapse
No announcement yet.

fusion subsystem vs. multiple instances

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • fusion subsystem vs. multiple instances

    I don't want my fusion server-side jobs to run in the QHTTPSVR subsystem. So I followed these excellent instructions. https://valence6.helpdocsonline.com/...serversidejobs and set up a dedicated subsystem to handle these requests. It all works fine and dandy.... if you only have one instance. If you have 2 or more Valence instances and you point the other instance to the same subsystem and JOBQ, strange things happen. Portal Admin defaults the port for the fusion settings and I don't mess with that so the port numbers are different. You can launch a fusion 5250 session in instance A and all is well. But as soon as you start a 5250 fusion session on instance B, you get this
    WebSocket Error
    Error communicating with ws://valence6B.mydomain.com:16260. The port number might already be in use, the VVFUSIOND/P jobs on IBM i may not be started, or there could be a firewall blocking communications.

    Forget the firewall, that ain't it. And it's working fine in instance A
    The fusionD/P jobs are running for both instances, wrkactjob sbs(vvfusion)
    Remember that my fusion port numbers are not the same for A and B, B = 7160 and A = 6260

    There is clearly some sort of conflict with 5250 fusion requests hitting the same subsystem/JOBQ

    I tried using the same port number for fusion in A and B. That results in that P job going to MSGW

    CALL PGM(VALENCE6/VVFUSIONP)
    Data area VVCONTEXT created in library QTEMP.
    Data area VVOUTBUFF created in library QTEMP.
    Pointer not set for location referenced.
    Function check. MCH3601 unmonitored by VVSRVPGM at statement 0000117300,
    instruction X'0000'.
    The call to VVUTILITY_ ended in error (C G D F).

    Although there is nothing port or instance specific about the JOBQ, CLASS, routing entry, JOBD or anything, I experimented with a second JOBQ within my VVFUSION subsystem, one for A and one for B. I didn't have my hopes up for that idea and indeed it didn't work.

    I think the only way I can have my fusion jobs from multiple instances work is to repeat ALL the steps for every single instance. That means for each instance a dedicated fusion subsystem, JOBQ, JOBD, CLASS, port etc. etc. I really don't see what subsystem has to do with it, I should be able to run fusion stuff from A and B in the same subsystem I would think.

    I am also a bit concerned about job names and the daemon job VVFUSIOND. I do not want someone unchecking the Server Active checkbox in portal admin in instance B and then take down the daemon job for every instance. I want total and complete separation of daemon jobs for each instance and I want the daemon job name to be
    such that I can see which instance it serves. I think each instance needs to have its own fusion port and when you have that each instance will get his own D job and P jobs and have the name of instance.... but I just can't get it to work.


    Can you kindly advice what the proper way is to set this up and also update the instructions https://valence6.helpdocsonline.com/...serversidejobs how we need to set this up and how to make this work properly for multiple valence instances?

    Last edited by DrGadget; 07-30-2021, 09:04 PM.

  • #2
    There must be something else going on there, because there should be no limit to the number of different instances running Fusion that can be supported within the same subsystem. We have a partition here with multiple Valence instances -- a mix of different versions and builds -- coexisting in a single VVFUSION subsystem and working just fine...
    vvfusion_subsystem_jobs.jpg

    We can get on a web meeting with you Monday to see what's going on in your configuration. I suspect it could be a library list issue at play.

    Comment

    Working...
    X