First-response guide for GLOSS application incidents: connection failures, freezes, errors, slowness, printing issues and outages.
- Scope: one user, one team, one site, or everyone? One module or the whole application?
- Environment: PROD or UAT? Users regularly report UAT issues as production incidents after the monthly refresh.
- Timing: did a release, configuration change or batch replay happen in the last 24 hours?
- Exact error: error code (GL-xxxx), screenshot, screen name, time.
- Impact: settlement cut-offs at risk? Corporate action deadline today? If yes, treat as urgent regardless of scope.
- Single user: check account status (locked, expired password), then the profile assignment; a profile change during the day requires reconnection.
- Whole team: check the application server pool status and the session count against the session limit — month-end and batch delays push sessions to the ceiling.
- Error at login after a release: verify client/server version alignment — a workstation that missed the deployment cannot connect.
¶ Freezes and record locks
- Screen freeze on a specific record: almost always a record lock held by another session (or a dead session). Identify the lock owner in the admin console; kill only dead sessions — call the user first.
- Intermittent freezes for many users: check application server memory/GC and network latency to the site; collect timestamps for correlation.
- Never advise killing the local process as a first step — pending input is lost and locks may survive.
- Get precise measurements: which screen, which action, how long, compared to what baseline.
- Global slowness during the day often correlates with a heavy report or extraction launched interactively — check running jobs before blaming infrastructure.
- Slowness on position screens right after batch issues: statistics/indexes on movement tables — escalate to the DBA with query evidence.
¶ Errors and defects
- Error code GL-xxxx: search the KB and past tickets first; known codes have documented workarounds.
- Reproducible error after a release: raise to L2 with reproduction steps, screenshots and the user profile; candidate for a rollback decision — do not multiply retries on real client data.
- Display defect (wrong column, misaligned amounts): verify on a second workstation and a second profile before logging a defect.
- Confirm the failing layer: application servers, database, network — with infrastructure on the bridge.
- Communicate within 15 minutes to the business lines: what is down, workaround, next update time.
- Priorities during the outage: settlement cut-offs first (manual instructions via the custodian portal as fallback), then corporate action deadlines, then reporting.
- After recovery: verify queue catch-up, session cleanup, and run integrity checks before declaring the incident closed.
- No restart of an application server during market hours without the settlements manager's explicit go.
- Every incident record must contain: scope, environment, error code, timeline, workaround given.
Outage or settlement cut-off at risk → L2 + management immediately. Reproducible defect → SS&C case with the evidence pack.