TypeError: Cannot read properties of null (reading 'length')

[amcintyre98]

Running your latest release 2.0.12 with node v20.16 on z/OS.

This code has been working fine with only this single issue (one time failed). Ran a 2nd time and worked so sounds performance related.

memb = await za.downloadDataset(dsn + '(' + ent.name + ')')
mems = memb.toString()
mcnt = mems.match(/\n/g).length

One time got this error. Rerunning with same input works fine.
mcnt = mems.match(/\n/g).length
¬
TypeError: Cannot read properties of null (reading 'length')
at main (/XSYS/u/z1234567/genxlsx.js:230:31)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

thanks,
Andrew

[amcintyre98]

failed for the 2nd time today with same issue, usually runs 3 or 4 times a week so very intermittent

[std4lqi]

Hi @amcintyre98 , the contents in this member are random generated or fixed? Is it possible no \n in mems?

[amcintyre98]

It's very intrmittent but always fails in the same place. So no, I run it again and there is data in mems and no issue. And no the data is not random generated, it's always the same.

I think it's something in the await za.downloadDataset that's failing sometimes.

All I can think of are changes that get around the problem but don't fix what is wrong with the await line.

[std4lqi]

If any failure, it's expected to receive exception.

If mems is single line string, mems.match(/\n/g) return null. Could you print mems at failure? Or could you check whether it's due to the dataset is migrated?

[amcintyre98]

The var mems is a string created from memb which is the buffer returned for the entire member from the await, so no, not a single line string. It always has the entire member in it. Again, rerunning with exact same input and it works fine.

Printing mems would just return null.

And the dataset is NOT migrated.

[amcintyre98]

Happened again for the 3rd time. Thinking about how to work around, like retrying the await za.downloadDataset.

[amcintyre98]

While the LPAR was bumping 100% I submitted the job again and it failed in a new way on 2 different submissions. Both calling out different UV_xxxx modules. I'm starting to think there is some issue with Node z/OS 20.16.

I did have this line in my shell script that I just commented out so will go back to default. Let's see if it settles down.
export UV_THREADPOOL_SIZE=8