Were these groups scheduled for skip for the job before the time you see in the log? If so, it is possible that skip job doesn't create jobid (makes sense) and message is just informational.

Hope you are not just using 7.3. You should use 7.3 Jumbo 8 or 7.3.1/7.3.2.

If you are using just 7.3, please upgrade immediately.

We are witnessing similar errors in our logs during a backup.

09/25/06 23:51:13 gstd: base: Failed to store session record for SERVER1-NIC2, MAIL1, 924e2d62-00000006-e818a36a-4518a36a-07190000-c0a800c9 insert failed.
09/25/06 23:51:13 gstd: base: Failed to store session info for SERVER1-NIC2, MAIL1
09/25/06 23:51:13 gstd: base: Failed to store data for MAIL1 on server SERVER1-NIC2
09/25/06 23:51:18 gstd: base: Failed to store session record for SERVER1-NIC1, MAIL1, 924e2d62-00000006-e818a36a-4518a36a-07190000-c0a800c9 insert failed.
09/25/06 23:51:18 gstd: base: Failed to store session info for SERVER1-NIC1, MAIL1
09/25/06 23:51:18 gstd: base: Failed to store data for MAIL1 on server SERVER1-NIC1

I'm wondering if this has something to do with multi-homed servers. Our server is Windows 2003 SP1, with NW 7.3.2 - clients match, with an STK L700e Autochanger (5 x 9840b drives).

In this particular instance this is not related to a skip issue as the job is reporting this during the end of it's run & it only runs at 2300hrs each evening so I have rule out the skip theory.

I just realized that we are talking about NMC here and not jobid as I thought. I have this error also in NMC 3.1.x (that would be NMC before it got integrated with NW). I simply ignore it. I assume it gstd pulling information and if no information is returned then it give that info looking ugly. However that is assumption. On my own example I would say it is harmless, but you may wish to verify it with support.

I have a customer with the same problem
The environment is
Server:
NW 7.3.2 with NMC 3.2.3
Client
Oracle 9.2 on Windows with a NW 7.3.1 client

In the gstd there are a lot of errors like:
09/13/06 13:12:57 gstd: Upgrade/Bootstrapping needed, performing ...
09/13/06 13:13:57 gstd: Done with Upgrade/Bootstrapping
09/13/06 13:16:08 gstd: base: Could not find Job ID for save group Informix, ntserver_3.imoppi.pt
09/13/06 13:16:08 gstd: base: Failed to get session info for ntserver_3.imoppi.pt, Informix
09/13/06 13:16:08 gstd: base: Failed to store data for Informix on server ntserver_3.imoppi.pt
09/13/06 13:16:10 gstd: base: Could not find Job ID for save group teste, ntserver_3.imoppi.pt
09/13/06 13:16:10 gstd: base: Failed to get session info for ntserver_3.imoppi.pt, teste
09/13/06 13:16:10 gstd: base: Failed to store data for teste on server ntserver_3.imoppi.pt
09/13/06 13:16:10 gstd: base: Could not find Job ID for save group Oracle_Logs, ntserver_3.imoppi.pt
09/13/06 13:16:10 gstd: base: Failed to get session info for ntserver_3.imoppi.pt, Oracle_Logs
09/13/06 13:16:10 gstd: base: Failed to store data for Oracle_Logs on server ntserver_3.imoppi.pt
09/13/06 13:16:10 gstd: base: Failed to store session record for ntserver_3.imoppi.pt, Oracle, 6aa430cc-00000006-f5075acf-45075acf-060c0000-ac100a17 insert failed.
09/13/06 13:16:10 gstd: base: Failed to store session info for ntserver_3.imoppi.pt, Oracle
09/13/06 13:16:10 gstd: base: Failed to store data for Oracle on server ntserver_3.imoppi.pt

The customer cannot see the save sets in the GUI
Any idea?

Thank you very much

Well, if you think those two are related I would suggest to open a call.

According to support, those messages within the gstd.log are a known issue and a fix is in the works. In our case, none of the backups appear to be affected.

As I said, in my own case, I had it with 3.1 (and still have) and never saw any impact to the backup. I'm not saying that perhaps there is no impact to reporting part, but I doubt. At this point I see that more as an cosmetic issue (hopefully I'm not wrong on that point).