Tools4i

English · Español

A suite of IBM i developer tools for Visual Studio Code, built on top of Code for IBM i. Tools4i adds a set of tools for tasks that come up during the day: finding objects and source, searching inside the code, looking at the data, modelling and documenting the database, managing jobs and spooled files, editing IBM i objects, and analysing what a change might affect — from the editor, and against the server.

Requires Code for IBM i (installed automatically as a dependency) and an active connection.

Features

Every tool below opens from the Tools4i view in the Activity Bar, or from the Command Palette (F1) by name. The headings match the groups in that view.

Most result panels share the same habits: per-column quick filters, sortable columns, CSV export, and — for the analysis and inspection tools — saving what is on screen as a snapshot you can reopen later, on another machine or with no connection at all.

Navigate

• Navigate Server — browse libraries, objects and source members. Filter by name, type, attribute, description and create/change date; sortable and resizable columns, quick filters and CSV export. Change a description or source type, rename, copy or delete, and drill from a library into its objects or sources. From here you can also download sources to a local project — one member, a source file, or a whole library — choosing how the folders are laid out, together with the metadata that lets them be sent back later. Once the sources sit in a folder they are within reach of whatever your team uses outside the server: source control and versioning, AI-assisted code analysis, or any other product that expects plain files rather than members in a library.
• Navigate Local — the same browser with the same capabilities — filters, sortable and resizable columns, quick filters, export and the actions on each row — applied to a local project folder of sources instead of the server.

Search

• Scan Server Sources — content search across source members of several libraries at once, with target and omit lists (wildcards allowed), a column range so fixed-format comments don't drown the result, and match modes.
• Scan Local Sources — the same search over a local project folder.
• Sources Scan Results — the results of each scan in its own tab: the members on one side, the matching statements on the other. Order the libraries by priority and highlight the lower-priority copies that a first-match rule would discard, filter per column, and export. And the option that saves the most time on an old code base: hide matches that fall on commented-out code, so looking for a field stops returning the twenty places where it was commented out years ago.

Compare & sync

• Sync Local Project — compare a local folder against a server library and see, member by member, what is in sync, what differs, and what exists on only one side. From there send the work done locally up to the server — replacing a member or creating one that isn't there yet — bring server changes back down, sync descriptions either way, or diff and edit both sides at once. To push a whole project in one operation instead of member by member, use Upload Local Project.
• Sync Server Library — compare a newer project library against one or more ordered base libraries and reconcile the differences.

Transfer

• Upload Local Project — send a local project back to a library, previewing what will be created and what replaced, and narrowing the upload by source file, member or type. When the target source file does not exist yet, you decide the character set it is created with; and when a character in your source has no equivalent on the server, you decide what is written in its place instead of finding out afterwards. It also creates or replaces *BNDDIR objects from the .BINDIR files in the project.
• SavF Manager — list the save files of a library or of a special value (*ALLUSR, *LIBL, *CURLIB, *ALL), each with what it holds: number of objects, saved libraries, compression, size, owner and last update. Browse the objects inside a save file, and restore everything, a library, a set of objects, or one single object into the library you choose. Save objects or a whole library into a save file, append more objects to one that already exists, create, clear, delete or copy a save file to another library, and move it between the server and your machine in either direction.

Editors

• Binding Directory Editor — a *BNDDIR is normally maintained one entry at a time, with no way to see the whole picture. Here the full list is on screen at once, sortable and filterable: add, edit and remove several entries and commit them in a single save, or discard the lot and start again. One pass tells you whether every referenced object still exists on the server, and a comparison against another binding directory shows what is missing, extra, or bound with a different activation. It works against the server or on a downloaded .BINDIR file, which the project upload can apply back to a library later.
• Binding Directory Sync — put two binding directories side by side, a target and a base, and see exactly how they differ: entries the target is missing, extras it carries that the base does not, and entries present in both but bound with a different type or activation. One action then brings the target in line with the base — adding what is missing, removing what is extra and aligning the rest — which is what you want when a development binding directory has drifted from the one production was built with.
• Message File Editor — open a *MSGF and view, add and edit its message descriptions, with search over ID, first-level text and help.

Spooled files and dumps

• Spooled Files Manager — find spooled files by user, output queue, status, form type, user data, job or date-and-time range. View the content, download it as text, hold, release, change attributes, copy to another output queue, delete, and jump to the job that produced it. It also opens the path to producing a PDF out of a spooled file: the transform is performed by the server, or by a third-party conversion tool of your choice that you install locally and point the settings at.
• Dump Files Viewer — import an ILE program dump (QPPGMDMP) and read it as details, files, indicators, variables and the raw text, with search and expand/collapse. It also opens the source of the program that failed, resolved from its own library or the library list — so the dump and the code that produced it sit side by side.

Jobs

• Jobs Manager — filter active and completed jobs by user, name, status or subsystem, with per-column quick filters and an optional extra-detail pass (type, entry time, resource use). Act on one job or several at once: hold, release, end controlled or immediate, change attributes. Jump straight to the job log, the job info, its spooled files or the user profile.
• Job Info — a single job across ten tabs: attributes, job log, call stack, library list, open files, activation groups, locks, definition, file overrides and commitment control. Save the whole thing as a snapshot and reopen it later, or import a DSPJOB OUTPUT(*PRINT) report to study a job with no connection at all — useful when someone sends you the evidence instead of the access.
• Job Log Viewer — a job log as a table you can actually work through: time, message ID, severity, type, the program it came from and the text, colour-coded by severity. Narrow it down to a time window, filter by message type or severity from the values present in that log, or search the text with next/previous navigation. Expand the second-level text of one message or of all of them at once, and save the log to reopen later — or open one saved earlier, which is how you read a job log from a system you are not connected to.
• Job Description Info — look up *JOBD objects by name and library, with wildcards, and read each one's attributes in a grouped grid: the library list a job starts with, the job queue and priorities, the output queue, the message logging level, and the rest. It is where the answer usually is when the same program behaves differently depending on how it was submitted. The result can be saved and reopened later.
• Message Queue Viewer — browse a message queue filtered by user or originating job, expand second-level help, reply to inquiry messages, and clear what has been seen while inquiries still unanswered stay protected. A queue can be saved and reopened later, which is the simplest way to attach evidence to a ticket.

Database

• File Viewer — physical and logical files, tables, views and indexes, choosing the member in a multi-member file and the record format in a multi-format logical file. Six tabs:
  • Data — the rows, capped to the number you set, filtered per column or with a WHERE clause built by clicking on the columns, shown by short system name or by SQL long name, and exportable to CSV. On a physical file or table you can also add, change and delete records.
  • Info and Columns/Fields — the file's own attributes and the definition of every field, including its position in the record, filterable and exportable.
  • Dependents — the database relations of the file: every logical file, view or index built over it, each one with its object type, description and SQL long name, so a "who breaks if I change this record format" question is answered before the change, not by the compiler afterwards.
  • RPG Data Structure — generated in full free, free or fixed format, with or without positions, initialised from the data type defaults or from the first record, named with the prefix and suffix you choose, ready to paste.
  • Custom fields — read a file the way a legacy program reads a program-described file. Give the layout — name, positions, type and decimals — by hand or by importing RPG input specs or a positional data structure, and the decoded values come back as a normal grid, exportable to CSV.
• Journal Entries Viewer — for a journaled file, data area or data queue, list its journal entries and decode each record image into the file's own columns, with the before and after images of every update side by side. Narrow the search to a member, a date-and-time range, a set of entry types (writes, updates, deletes, or whatever codes you need) and a row cap, filter the result, export it to CSV, and jump straight to the File Viewer to compare what the journal recorded with what the file holds today.
• Stored Procedures Manager — filter SQL procedures and functions by schema, name, external program, or text inside the SQL definition itself; view the definition and parameters, generate a CALL template, run it, and drop the routine.
• Native Query Info — everything a *QRYDFN query holds, in four tabs: its attributes, the files it uses with their level-check status, the definition itself — selection, sorting, formatting, expandable section by section — and the SQL equivalent, ready to copy when the query has to become something a modern tool can run. From there you can open the level-check analyzer for that library, and save the whole thing to reopen later.
• Data Area Info — what a *DTAARA holds right now: type, length, decimal positions, its value and its description, each field copied with a click. Many applications keep their configuration and their run switches in data areas, so this is often the difference between a program that is wrong and a program that was told to behave that way.

Data model

• Data Model Extractor — build a data model from the Db2 catalog, from native DDS and SQL sources on the server or on disk, or from an SQL DDL script. Whole libraries or a single object, merging or replacing, with the result staged until you save it.
• Data Model Editor — add items to the model by hand, and edit items, keys, relationships and dependencies that no extraction can know about; group items into business processes; publish the model to the IFS for the team.
• Implied foreign keys — find the relationships that were never declared as constraints: a table holding every column of another table's key is a candidate, rated by confidence. None enters the model on a guess — each is confirmed against the catalog or against the data itself, counting the rows that would be left orphaned.
• Data Model Viewer — this is where entity-relationship diagrams (ERDs) are built, including the elements particular to IBM i: physical files, logical files and multi-format logical files drawn over the physicals they are built on, alongside tables, views and indexes. Add one item, its related items, or a whole business process, and the diagram grows around what you are explaining rather than showing the entire library. Notes can be pinned to the canvas, and diagrams saved, reopened and exported as an image.
• Data Model Dictionary — a business glossary at column level. One row per distinct column definition — two columns sharing a name but not a data type are two different things, and describing them as one produces a wrong glossary — with its business description, the text the source carries, a "used by" cross-reference across the model, a measure of how much is documented, and CSV/Markdown export.
• Personal data classification — mark which columns hold personal information and of what kind, inside the Dictionary. Detection proposes candidates from the column name, the source text and the description, but applies nothing on its own: every proposal goes through a review dialog. It warns when the same column name is classified in some files and not in others — under-tagging being the real exposure — and when a classification has come loose because the column definition changed, so it can be reattached or dropped deliberately.
• Model health checks — what a model accumulates over time: relationships pointing at items that are not there, references to items missing from the model, duplicated items and duplicated relationships, items nothing connects to, and redundant access paths. Each finding jumps to the item it is about.
• Data Model Comparison — compare the saved model against the server now, against another model file, or one library against another, flagging the differences that force a recompile.

Object references and impact — *beta

The tools in this group are in beta testing: they are usable and in daily use, but their results should be reviewed before you act on them. The side bar marks the section *BETA as a reminder.

• Programs Level Check Analyzer — programs that will level-check against files in your data libraries, in three views: the level-id comparison (with an "affected only" filter that also surfaces mismatches where level checking is simply turned off), the resulting list of programs to recompile, and the files involved. Copy the list or export any view.
• Native Query Level Check Analyzer — *QRYDFN queries that will fail because a file definition changed.
• Programs Signatures Analyzer — service-program signatures and the callers bound to them (Command Palette).
• Object Change Impact Analysis — what a change to an object would break: dependents to recreate, programs to recompile, stored procedures affected — plus the rebuild plan in the order it has to be run. Optionally it walks the call graph as well, to show who calls the programs that need recompiling.
• Procedure Change Impact Analysis — for an exported subprocedure, every module, service program and program to recompile, in order.
• Library Compile Order — every object in a library in a dependency-safe build order: files → modules → service programs → programs.
• Object & Sources — reconcile source members against compiled objects: objects with no source, sources with no object, and stale objects, with configurable skip rules.

System and users

• PTF Status — individual PTFs or whole PTF groups, filtered by ID or product, with their installed status (loaded, applied, superseded) and CSV export.
• User Info — look up a user profile by name, or several at once with a wildcard and pick from the matches, and read every attribute it carries in a grouped grid: class and special authorities, group profile and supplemental groups, initial program and menu, current library, limit capabilities, password and expiration state, sign-on attempts and status, storage used, and when it was last used. Enough to answer "why can this user do that" — or why it cannot — in one place, and the result can be saved and reopened later.
• Review Authority Failures — authorization-failure entries from the security audit journal over a date-and-time range (last 24 hours by default), with the noisy service users excluded, a row cap, drill-in to the authorities held on the object that refused the access, and CSV export.

From the editor

With a source member open, the editor's context menu adds:

• Copy Source to Location… — copy the member to another library or source file.
• Download Source to Local Project… — bring it into a local project folder.
• File Viewer — jump from the source to the data.
• Open Referenced Object Source ▸ From Server / From Local — select a program or copybook name in the code and open its source, resolved in library-list order (the same member the compiler would take) or from the open project.

Settings and About

• Tools4i Settings — every setting this extension contributes, in one searchable form.
• About Tools4i — version, author, license, and the Code for IBM i build it is running on.

Installation

From the Marketplace — the usual way, and the one that keeps you up to date:

1. Open the Extensions view (Ctrl+Shift+X / ⇧⌘X).
2. Search for Tools4i and install it.

New versions arrive from there automatically, like any other extension.

Or install a packaged .vsix file, which is how a pre-release or an internal build is distributed.

From the VS Code UI

1. Open the Extensions view (Ctrl+Shift+X / ⇧⌘X).
2. Click the ⋯ (More Actions) menu at the top → Install from VSIX….
3. Select the tools4i-<version>.vsix file.
4. Reload VS Code if prompted.

From the command line

code --install-extension tools4i-<version>.vsix

VS Code installs Code for IBM i automatically as a required dependency. If you are offline, install it first (it must be present for Tools4i to activate).

To update, install a newer .vsix the same way; to remove, use Uninstall in the Extensions view or code --uninstall-extension tools4i.tools4i.

Getting started

1. Install Code for IBM i (installed automatically as a dependency) and connect to your system.
2. Open the Tools4i view from the Activity Bar, or run any command from the Command Palette (F1 → type the tool name).

Settings

Run Tools4i Settings for a single searchable form covering every setting the extension contributes: spooled-file duplication, library compile-order naming, object/source reconciliation defaults, diagnostics logging, PDF creation, data model storage, colours and shapes, and the protections below. The same settings are available in the VS Code Settings editor under @ext:tools4i.tools4i.

Protected libraries — libraries the extension must never modify. Its own copy, rename, delete, change-text, deploys, sync writes and editor saves are blocked there, and their source members open read-only.

Production protection — any connection whose host name or IP is not in your list of development systems is treated as production: destructive changes, object creation, uploads and sync writes, editor saves and deploys can each be blocked, and the UI shows a red production warning.

Contributors

Juan J. Concepción — author and maintainer. Questions, bug reports and ideas: tools4i.support@gmail.com

Tools4i stands on work done by others:

• Code for IBM i and everyone who has contributed to it — Tools4i is built on top of it and depends on it; it extends that work rather than replacing it.
• Cytoscape.js and Dagre, which draw and lay out the data-model diagrams. Every bundled component and its licence is listed in THIRD-PARTY-NOTICES.md.

Thanks as well to the IBM i developers whose day-to-day work decided what got built: each tool here started as a task someone was doing the slow way.

License

MIT — see the LICENSE file shipped with the extension. Bundled third-party components are listed in THIRD-PARTY-NOTICES.md, also included in the package.

Español

Resumen en español. La documentación completa traducida viaja en el archivo README.es.md, dentro del paquete de la extensión. La interfaz de las herramientas está en inglés.

Un conjunto de herramientas de desarrollo para IBM i en Visual Studio Code, construido sobre Code for IBM i. Tools4i añade herramientas para las tareas que van surgiendo durante el día: encontrar objetos y fuentes, buscar dentro del código, mirar los datos, modelar y documentar la base de datos, administrar trabajos y archivos en spool, editar objetos de IBM i, y analizar a qué puede afectar un cambio — desde el editor, y contra el servidor.

Requiere Code for IBM i (se instala automáticamente como dependencia) y una conexión activa.

Las herramientas

Todas se abren desde la vista Tools4i de la barra de actividad, o desde la paleta de comandos (F1) escribiendo su nombre.

Navegación — recorrer bibliotecas, objetos y miembros con filtros por nombre, tipo, atributo, descripción y fechas, columnas ordenables y exportación, y hacer sobre ellos el mantenimiento de siempre: cambiar la descripción o el tipo de fuente, renombrar, copiar, eliminar. Desde ahí también se descargan fuentes a un proyecto local —un miembro, un archivo fuente o una biblioteca entera—, con lo que quedan al alcance de lo que su equipo use fuera del servidor. La misma navegación funciona sobre la carpeta local.

Búsqueda — «hay que cambiar el campo X, ¿dónde se usa?». Busca en el contenido de los fuentes de varias bibliotecas a la vez, acotando con listas de objetivos y omisiones y con un rango de columnas que evita ahogarse en los comentarios del formato fijo. Y en los resultados, la opción que más tiempo ahorra en una base de código antigua: ocultar las coincidencias que caen sobre código comentado.

Comparar y sincronizar — ver, miembro por miembro, qué está igual, qué difiere y qué existe en un solo lado: entre una carpeta local y una biblioteca, o entre dos bibliotecas del servidor. Desde ahí se sube lo hecho localmente, se baja lo que cambió en el servidor, o se comparan las dos versiones lado a lado.

Transferencia — devolver un proyecto completo a una biblioteca, con vista previa de qué se va a crear y qué se va a reemplazar, y decidiendo de antemano qué ocurre con los caracteres que el servidor no admite. Y administrar archivos de salvado: inspeccionar lo que contienen y restaurar desde ellos todo, una biblioteca o un solo objeto a la biblioteca que usted elija.

Editores — un binding directory con todas sus entradas a la vista en lugar de una a una, comparable contra el de otro entorno y con comprobación de que cada objeto referenciado siga existiendo. Y las descripciones de mensaje de un *MSGF, con búsqueda por identificador, texto y ayuda.

Archivos en spool y volcados — encontrar la salida por usuario, cola, estado, trabajo o rango de fecha y hora; verla, retenerla antes de que se imprima, cambiar sus atributos o copiarla a otra cola para que el usuario la reciba sin volver a ejecutar nada. Y leer un volcado de programa —con sus indicadores y variables— junto al fuente que lo produjo.

Trabajos — localizar un trabajo entre los miles que puede haber activos y actuar sobre él; leer su registro en una tabla que se filtra por severidad, tipo y ventana de tiempo; consultar con qué descripción de trabajo se sometió, que suele ser donde está la causa cuando un programa se comporta distinto en producción; y atender las colas de mensajes, respondiendo la consulta que dejó un proceso esperando.

Base de datos — ver los datos de un archivo filtrados por una condición WHERE y editarlos; su definición campo por campo con las posiciones en el registro; generar la estructura de datos RPG lista para pegar en el programa; leer un archivo descrito por programa dándole el layout; y reconstruir desde el journal quién cambió un registro y cuándo, contrastándolo con lo que el archivo contiene hoy.

Modelo de datos — extraer el modelo desde el catálogo Db2 y desde los fuentes DDS y SQL; descubrir las claves foráneas que nunca se declararon y comprobarlas contra los datos reales antes de darlas por buenas; construir diagramas Entidad-Relación que incluyen los archivos lógicos y los multiformato dibujados sobre sus físicos; documentar cada columna en un diccionario de negocio; clasificar la información personal con revisión humana obligatoria; y comparar el modelo contra el servidor o una biblioteca contra otra.

Referencias entre objetos (en prueba beta) — lo que conviene saber antes de compilar: qué programas quedarán en error de nivel, qué rompe un cambio en un objeto o en un procedimiento exportado, en qué orden hay que reconstruir una biblioteca, y qué objetos se quedaron sin fuente o al revés.

Sistema y usuarios — el nivel de PTF del sistema, todos los atributos de un perfil de usuario, y los intentos de acceso que la seguridad rechazó, con el detalle de las autoridades sobre el objeto que los rechazó.

Protecciones

Bibliotecas protegidas — bibliotecas que la extensión no debe modificar nunca: ahí se bloquean sus operaciones de escritura y los fuentes se abren en solo lectura.

Protección de producción — toda conexión cuyo nombre de host o dirección IP no figure en su lista de sistemas de desarrollo se trata como producción, con bloqueo de los cambios destructivos, las cargas y los guardados, y un aviso rojo en la interfaz.

Contacto

Juan J. Concepción — autor y responsable del proyecto. Consultas, reportes de fallos e ideas: tools4i.support@gmail.com