Open irfanshar opened 7 months ago
So is this in the standard error. What system was this on? WOuld you mind testing to see if including standard error into the name.splf files solves this problem
Seems like stderr does not contain all the errors when running the CRTBNDRPG command using BASH. But QSH returns all the errors. Errors using the BASH:
Errors using the QSH:
In code for ibm i, it uses the QSH for actions with environment ile
, that's why it can get back all the error message. Bur for bob, the environment is pase
and it uses the bash to run the command.
Probably we need to investigate how to change to use QSH for bob or the reason why it cannot get back all the errors using bash.
Bob depends on BASH so going to QSH is going to cause more problems the message CPFxxxx makes me thing that this is an IBM i QSYS message that would be captures in the joblog.json @irfanshar Can you check if the joblog has the info?
In general that is how you go one level deep if a command fails
@irfanshar how has your investigation progressed?
@irfanshar how has your investigation progressed?
These errors will be visible in the spool files. Did we want to change the behaviour to also be visible in stdout?
When testing on p8adt05, the license was expired but there is no informative message that is shown in the log even though the Code4i action has the information about the license being expired.
Bob:
Code4i Action:
A typical diagnostic approach would be to look at the job logs next and I believe the CPF9E73 would be found there. Running with QSH is a non-starter. If we want to grep for CPF9E73 and display that in stdout, that is possible. I imagine that will introduce some performance delays. I suspect this is a pretty rare situation for our customers.
BOB does not provide any information when the license key for a product expires, the build simply fails.
This is the error message we get when using Compile with CRTBNDRPG
We should have something similar to let the user know what's happening.