[Info-vax] RMS-E-FNF, what file?

[Jan-Erik Söderholm]

Den 2020-11-22 kl. 21:02, skrev Arne Vajhøj:
> On 11/22/2020 2:45 PM, Arne Vajhøj wrote:
>> On 11/22/2020 7:34 AM, Jan-Erik Söderholm wrote:
>>> Den 2020-11-22 kl. 03:25, skrev Arne Vajhøj:
>>>> On 11/21/2020 9:19 PM, Jan-Erik Söderholm wrote:
>>>>> Den 2020-11-22 kl. 03:06, skrev Arne Vajhøj:
>>>>>> On 11/21/2020 8:00 PM, Jan-Erik Söderholm wrote:
>>>>>>> Den 2020-11-22 kl. 01:52, skrev Stephen Hoffman:
>>>>>>>> On 2020-11-22 00:36:28 +0000, Jan-Erik Sderholm said:
>>>>>>>>> How to know what file an "-RMS-E-FNF, file not found" message is 
>>>>>>>>> referring to?
>>>>>>>>>
>>>>>>>>> Probe Description :- AMQ6125: An internal MQSeries error has 
>>>>>>>>> occurred.
>>>>>>>>> Arith1            :- 10 a
>>>>>>>>> VMS Errorcode     :- -RMS-E-FNF, file not found (00018292)
>>>>>>>>>
>>>>>>>>> This application should not open any know file. It is the sharable 
>>>>>>>>> EXE for MQ that creates this error message.
>>>>>>>>
>>>>>>>> If the session is an interactive one, SET WATCH/CLASS=MAJOR FILE 
>>>>>>>> and watch for which file is referenced. This is a lot of data.
>>>>>>>>
>>>>>>>> if the session is batch or network or detached, I'd expect to be 
>>>>>>>> using security auditing to view file access. And that's a bigger 
>>>>>>>> pile of data.
>>>>>>>
>>>>>>> Fine! That gave a list that I will look at.
>>>>>>> Now, how to switch that off? HELP SET WATCH does not return anything...
>>>>>>
>>>>>> $ SET WATCH/CLASS=NOMAJOR FILE
>>>>>>
>>>>>> And not surprising that an undocumented command is not in help.
>>>>
>>>>> The output did not give any clear answer to the error.
>>>>>
>>>>> We have traditionally used MQ client API calls from Cobol.
>>>>> Now trying to get an C example code running. I have just
>>>>> noticed that we have got the same error earlier from our
>>>>> Cobol apps also, so I will dig into that and see in the
>>>>> sources from that time what could have been the cause and fix.
>>>>> And then see if that can explain the issues with the C code.
>>>>>
>>>>> The goal is to have PyMQI running. It is C code called from Python.
>>>>> Python, as being a dynamically typed language, is probably easier
>>>>> to use to recevie and decode XML messages...
>>>>
>>>> What version of IBM MQ are you using?
>>>>
>>>> If you are on 8.0+ then it supports AMQP and there
>>>> is an AMQP module for Python.
>>>>
>>>> That may be the easier path unless you need features
>>>> not supported by their AMQP channel.
>>>
>>> Right. I have to talk to the central WebSphere people also about AMQP.
>>> Our VMS MQ client kit is on V2.1, and has been so for decades. This works
>>> just fine from our Cobol apps, and do not see what the C code in PyMQI
>>> does differently.
>>>
>>> I did some test with a later MQ client kit many years ago, probably V5
>>> och V6, but never got it to work with our Cobol MQ "middleware" that
>>> someone before me wrote long ago. Without that we have to rewrite the
>>> main applications also.
>>>
>>> I have already removed some of the functions in the PyMQI.C file that
>>> is not supported by the V2.1 MQ client. There is a management interface
>>> that came in the MQ 5.x timeframe and there is an extendended MQCONNX
>>> API that is new. I only need the basic MQCONN, MQOPEN, MQGET and MQPUT
>>> calls.
>>>
>>> The MQCONN ("connect" to the central MQ sever) seems to work, but the
>>> MQOPEN (open the MQ queue) generates the DUMP file with the FNF message.
>>> There was no FNF message in the WATCH file, btw.
>>>
>>> But yes, I will ask about the support for AMQP also!
>>
>> Note that there are many different AMQP clients for Python.
>>
>> You need something that works with Python 2.7 since you
>> are on Alpha.
>>
>> And you want something pure Python to avoid any
>> problem with C code not supporting VMS.
>>
>> I have not tried it myself, but Pika or one of the libraries
>> build on top of Pika sounds "interesting".
> 
> Pika may actually be pre-installeed in VMS Python.
> 
> :-)
> 
> Arne
> 

Yes, it is, and a few other pre-installed AMQP tools.
https://www.vmspython.org/doku.php?id=downloadandinstallationpython

But...

I found an error when I build of the PyMQI EXE. I had by
mistake linked to the wrong sharable image.

$ d sys$share:mq*.exe

Directory SYS$COMMON:[SYSLIB]

MQIC.EXE;2        339/392       10-MAR-2000 14:06:27.42
MQICB.EXE;2       334/392       10-MAR-2000 14:13:43.28
MQMCS.EXE;2      1568/1617      10-MAR-2000 14:05:14.88

Total of 3 files, 2241/2401 blocks.

 From an IBM MQ manual from 1999:

In MQSeries for Digital OpenVMS, you must link your program to the
MQI library files supplied for the environment in which you are
running your application, in addition to those provided by the
operating system:

mqm.exe    Server for C
mqic.exe   Client for C  <<== right for C.
mqmzf.exe  Installable service exits for C
mqmxa.exe  XA interface for C
mqcbrt.exe MQSeries COBOL run-time
mqmcb.exe  Server for COBOL
mqicb.exe  Client for COBOL <<== we use this for our Cobol apps...

So by linking against MQIC instead of MKICB, it all came alive. :-)

PyMQI is written for later MQ versions, so some record definitions
had to be adjusted in the __init__.py file for PyMQI to match the
.H files that defines the MQIC.EXE API's.

We have two queues setup since befor that are just loppbacked
to each other in the WebSphere server, so I can now send a message
from one Python script and receive the data in another. Nice!

Currently trying to read an example XML structure. The decode tool
(ElemantTree) throws an error due to some UTF8 codes in the XML...
Each single XML message is approx 150 KB.

But the basic support for MQ in Python now works. And the reason to
switch from Cobol to Python in this case is that there are way better
XML decoding tools in Python.

Jan-Erik.