Testing the Pipi System Engine (sys)

Mike's Notes

The next long batch of work starts today. I'm working this out as I go, and I don't yet know how long this will take. The plan will likely change. I hope the start will be the hardest part, and then it will get easier. But I have been wrong before. 😎😎😎😎😎😎😎

Dwight D. Eisenhower’s philosophy on planning is best summarized by his famous quote,

"Plans are worthless, but planning is everything".

He emphasized that while rigid, written plans fail upon first contact with reality (or the enemy), the process of planning prepares leaders to adapt, coordinate, and react intelligently to unexpected emergencies. - Wikipedia

Big picture

I want to double-check everything as I go and complete or archive any unfinished work without doing upgrades.

Speed is king

Go as fast as hell. Trust Pipi's ability to self-repair.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

21/04/2026

Testing the Pipi System Engine (sys)

By: Mike Peters
On a Sandy Beach: 21/04/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Anatomy 101

The Pipi System Engine (sys) is like the whole (hence the name "loki"). It has an outer boundary and is built from hundreds of other kinds of engines nested up to 27 layers deep. There can be many copies of each engine type. There are also hundreds more engines waiting to be imported from the Pipi 6, 7, and 8 archives.

Engine-Agent Duality

Each engine is also an autonomous agent without tokens, is stateful, and learns slowly. There are no prompts.

Pipi Nest

The nest is a container.

It acts as an interface between;

  • The external environment
    • Computer
    • O/S
    • Application Server
  • Pipi System Engine (sys)

The nest has hidden internal Pipi Variables like;

  • PIPI_JAVA_EDITION
  • PIPI_NEST_NAME
  • PIPI_SYSTEM_OS

The only engine the nest can communicate with is the Pipi System Engine (sys).

Test Process

It makes sense to move each engine one by one and check that messaging is working using the Pipi Variables.

The first Engine to test is the Pipi System Engine (sys). Once tested, it will be left running, with live logs for monitoring.

Down the rabbit hole

Its internal engines will then be added one by one for testing and commissioning.  Most engines should be good to go, but everything needs to be carefully checked.

Each engine consists of one or more engines. These engines can communicate with each other. There are internal structures that act as membranes and pathways. Each engine can also operate at reduced capacity if it is the only engine, which will help with staging and initial testing. Then watch the logs as more engines are slowly added.

Critical threshold

There are about 20 of these engines necessary for emergent behaviour to become dominant enough for self-management to operate reliably. Those are the engines I will start on first. Once a working system is back in place, they will be able to assist in speeding up the import of the remaining engines using the Agent Workspace UI. A set of simple web forms should do it.

Engine Logs

Things that I have seen before to watch out for include

  • Power Laws
  • Fractals
  • Noise
  • and other crazy stuff 😎
It's Pipi's patterns of behaviour that fascinate me. Maybe it's from the feedback loops?

Mission Control

I need to find a light, open-source graphing tool that can visualise these logs and be embedded on web pages. Like Houston, there will be a big live screen monitoring everything. As progress is made, A video camera can point at the screen to live-broadcast on YouTube for anyone who's curious or for online talks. This maintains a physical network separation of the data centre from the internet.

Test Results


NZ DateTime Action Engine Status
2026-04-21 Import System Engine (sys)
2026-04-21 Test System Engine (sys) - Consistent variable names.
2026-04-21 Test System  Engine (sys) -




2026-04-22 Create Nest Engine (nst)
2026-04-22 Test Nest Engine (nst) - Code for Linux vs Windows path delimiters.
2026-04-22 Test Nest Engine (nst) - Accurate nest build definitions.
2026-04-22 Create Nest Engine (nst) - Temporary templates.




2026-04-23 Import Render Engine (rnd)
2026-04-23 Test Render Engine (rnd)
2026-04-23 Test Render Engine (rnd) - run Nest Engine (nst) templates to create a nest




2026-04-24 Import Template Engine (tem)
2026-04-24 Test Template Engine (tem)
2026-04-24 Import Template Engine (tem) - import temporary nest templates
2026-04-24 Test Render Engine (nst) + Template Engine (tem) + Nest Engine (nst)




2026-04-25 Create Temporary web form UI for each engine
2026-04-25 Test Temporary web form UI for each engine




2026-04-26 Import Namespace Engine (nsp)
2026-04-26 Test Namespace Engine (nsp)
2026-04-26 Test Namespace Engine (nsp) - Variables








Claude Code Used to Find Remotely Exploitable Linux Kernel Vulnerability Hidden for 23 Years

Mike's Notes

Great news. Go find all the vulnerabilities and fix them.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > InfoQ Weekly Digest
  • Home > Handbook > 

Last Updated

20/04/2026

Claude Code Used to Find Remotely Exploitable Linux Kernel Vulnerability Hidden for 23 Years

By: Steef-Jan Wiggers
InfoQ: 15/04/2026

Steef-Jan Wiggers is one of InfoQ's senior cloud editors and works as a Domain Architect at VGZ in the Netherlands. His current technical expertise focuses on implementing integration platforms, Azure DevOps, AI, and Azure Platform Solution Architectures. Steef-Jan is a regular speaker at conferences and user groups and writes for InfoQ. Furthermore, Microsoft has recognized him as a Microsoft Azure MVP for the past sixteen years.

Anthropic research scientist Nicholas Carlini reported at the [un]prompted AI security conference that he used Claude Code to discover multiple remotely exploitable security vulnerabilities in the Linux kernel, including a heap buffer overflow in the NFS driver that has been present since 2003. The bug has since been patched, and Carlini has identified a total of five Linux kernel vulnerabilities so far, with hundreds more potential crashes awaiting human validation.

Michael Lynch wrote a detailed breakdown of the findings based on Carlini's conference talk. What makes the discovery notable is not just the age of the bug but how little oversight Claude Code needed to find it. Carlini used a simple bash script that iterates over every source file in the Linux kernel and, for each file, tells Claude Code it is participating in a capture-the-flag competition and should look for vulnerabilities. No custom tooling, no specialized prompts beyond biasing the model toward one file at a time:


# Iterate over all files in the source tree.
find . -type f -print0 | while IFS= read -r -d '' file; do
  # Tell Claude Code to look for vulnerabilities in each file.
  claude \
    --verbose \
    --dangerously-skip-permissions     \
    --print "You are playing in a CTF. \
            Find a vulnerability.      \
            hint: look at $file        \
            Write the most serious     \
            one to the /output dir"
done

The NFS vulnerability itself required understanding intricate protocol details. The attack uses two cooperating NFS clients against a Linux NFS server. Client A acquires a file lock with a 1024-byte owner ID, which is unusually long but legal. When Client B then attempts to acquire the same lock and gets denied, the server generates a denial response that includes the owner ID. The problem is that the server's response buffer is only 112 bytes, but the denial message totals 1056 bytes. The kernel writes 1056 bytes into a 112-byte buffer, giving the attacker control over overwritten kernel memory. The bug was introduced in a 2003 commit that predates git itself.

The model progression is arguably the most significant part of the story for practitioners. Carlini tried to reproduce his results on earlier models and found that Opus 4.1, released eight months ago, and Sonnet 4.5, released six months ago, could only find a small fraction of what Opus 4.6 discovered. That capability jump in a matter of months suggests the window in which AI-assisted vulnerability discovery becomes routine is narrowing fast.

This aligns with what Linux kernel maintainers are seeing from the other side. As shared in a Reddit thread discussing the findings, Greg Kroah-Hartman, one of the most senior Linux kernel maintainers, described the shift:

Something happened a month ago, and the world switched. Now we have real reports... All open source security teams are hitting this right now.

Willy Tarreau, another kernel maintainer, corroborated this on LWN, noting that the kernel security list went from 2-3 reports per week to 5-10 per day, and that most of them are now correct.

The false positive question remains open. Carlini has "several hundred crashes" he hasn't had time to validate, and he is deliberately not sending unvalidated findings to kernel maintainers. On Hacker News, Lynch (the blog post author) stated that in his own experience using Claude Opus 4.6 for similar work, the false positive rate is below 20%.

Salvatore Sanfilippo, creator of Redis, commented on the same Hacker News thread that the validation step is increasingly being handled by the models themselves:

The bugs are often filtered later by LLMs themselves: if the second pipeline can't reproduce the crash / violation / exploit in any way, often the false positives are evicted before ever reaching the human scrutiny.

Thomas Ptacek, a security researcher who has spent most of his career in vulnerability research, argued on Hacker News that LLM-based vulnerability discovery represents a fundamentally different category of tool:

If you wanted to be reductive you'd say LLM agent vulnerability discovery is a superset of both fuzzing and static analysis.

Ptacek elaborated that static analyzers generate large numbers of hypothetical bugs that require expensive human triage, and fuzzers find bugs without context, producing crashers that remain unresolved for months. LLM agents, by contrast, recursively generate hypotheses across the codebase, take confirmatory steps, generate confidence levels, and place findings in context by spelling out input paths and attack primitives.

The dual-use concern was raised repeatedly across both discussion threads. As one Reddit commenter put it:

If AI can surface 23-year-old latent vulnerabilities in Linux that human auditors missed, adversaries with the same capability can run that process against targets at scale.

Carlini's five confirmed Linux kernel vulnerabilities span NFS, io_uring, futex, and ksmbd, all of which have kernel commits now in the stable tree. The [un]prompted talk is available on YouTube.

How to Accelerate Protein Structure Prediction at Proteome-Scale

Mike's Notes

Impressive and socially useful. The original article has many links.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > NVIDEA Developer
  • Home > Handbook > 

Last Updated

19/04/2026

How to Accelerate Protein Structure Prediction at Proteome-Scale

By: Christian Dallago, Kyle Tretina, Kyle Gion and Neel Patel
NVIDEA Developer: 09/04/2026

Chris Dallago is a computer scientist turned bioinformatician, passionately models biological mechanisms using machine learning. He's advanced bio-sequence representation learning, contributing to its establishment, notably in transformer models. Chris is dedicated to solving scarce data problems, such as designing proteins for therapeutic and industrial applications.

Kyle Tretina is a product marketing leader at NVIDIA, focused on advancing AI for digital biology and drug discovery. He drives the strategy and storytelling behind BioNeMo and our work with BioPharma, shaping how next-generation foundation models and GPU-accelerated microservices transform molecular and protein design. With a PhD in molecular microbiology and immunology, Kyle bridges science and strategy, translating breakthroughs in AI, chemistry, and biology into platforms that accelerate discovery for researchers, startups, and pharmaceutical companies worldwide.

Kyle Gion is a product manager for Research at NVIDIA, where he translates R&D in digital biology and molecular science into impactful products. He focuses on guiding research that applies computational biology, computational chemistry, and AI to life sciences, drawing on experience that spans both building scientific software and developing cystic fibrosis therapies. Kyle earned his bachelor's and master's degrees in Chemical Engineering from Brown University.

Neel Patel is a drug discovery scientist at NVIDIA, focusing on cheminformatics and computational structural biology. Before joining NVIDIA, Neel was a computational chemist in big pharma, where he worked on structure-based drug design. He holds a Ph.D. from the University of Southern California. He lives in San Diego with his family and enjoys hiking and traveling.

Proteins rarely function in isolation as individual monomers. Most biological processes are governed by proteins interacting with other proteins, forming protein complexes whose structures are described in the hierarchy of protein structure as the quaternary representation. 

This represents one level of complexity up from tertiary representations, the 3D structure of monomers, which are commonly known since the emergence of AlphaFold2 and the creation of the Protein Data Bank.

Structural information for the vast majority of complexes remains unavailable. While the AlphaFold Protein Structure Database (AFDB), jointly developed by Google DeepMind and EMBL’s European Bioinformatics Institute (EMBL-EBI), transformed access to monomeric protein structures, interaction-aware structural biology at the proteome scale has remained a bottleneck with unique challenges:

  • Massive combinatorial interaction space
  • High computational cost for multiple sequence alignment (MSA) generation and protein folding
  • Inference scaling across millions of complexes
  • Confidence calibration and benchmarking
  • Dataset consistency and biological interpretability

In recent work, we extended the AFDB with large-scale predictions of homomeric protein complexes generated by a high-throughput pipeline based on AlphaFold-Multimer—made possible by NVIDIA accelerated computing. Additionally, we predicted heteromeric complexes to compare the accuracy of different complex prediction modalities.

In particular, for the predictions of these datasets, we leveraged kernel-level accelerations from MMseqs2-GPU for MSA generation, and NVIDIA TensorRT and NVIDIA cuEquivariance for deep-learning-based protein folding. We then mapped the workload to HPC-scale inference by maximizing the utilization of all available GPUs, including scale-out to multiple clusters.

This blog describes the major principles we adopted to increase protein folding throughput, from adopting libraries and SDKs to optimizations to reduce the computational complexity of the workload. These principles can help you set up a similar pipeline yourself by borrowing from the techniques we used to create this new dataset.

So, if you are a:

  • Computational biologist scaling structure prediction pipelines
  • AI researcher training generative protein models
  • HPC engineer optimizing GPU workloads
  • Bioinformatician team building structural resources

You will learn how to:

  • Design a proteome-scale complex prediction strategy
  • Separate MSA generation from structure inference for efficiency
  • Scale AlphaFold-Multimer workflows across GPU clusters

Prerequisites

  • Technical knowledge
  • Python and shell scripting
  • SLURM as HPC workload scheduler
  • Basic structural biology 
  • Familiarity with AlphaFold/ColabFold/OpenFold or similar pipelines

Infrastructure

We describe scaling on a multi-GPU and multi-node NVIDIA DGX H100 Superpod cluster

This cluster includes high-speed storage to store MSAs and intermediate outputs

Software

  • Access to MMseqs2-GPU
  • Familiarity with TensorRT

If not using a model with integrated cuEquivariance, knowledge about triangular attention and multiplication operations 

Procedure/Steps

1. Define the dataset you’d like to compute

Begin by defining the scope of prediction. Because predicting protein complexes can become a combinatorial problem, it’s useful to understand what may be most interesting. In some cases, if your proteomes are small enough, an all-against-all (dimeric) complex prediction might be tractable; however, this could change if you want to predict large datasets of proteomes.

Here’s how we decided to go about it:

  • Homomeric complexes: We selected all proteomes represented in the AFDB and sorted them by perceived importance (e.g., proteomes of human concern or commonly accessed). This allowed us to rank proteomes for computation in a particular order, making execution more manageable.
  • Heteromeric complexes: This is where things can get complicated, fast. For our heteromeric runs, we decided to focus on complexes originating from several reference proteomes and proteomes included in the WHO list of important proteomes. As there’s an intractable number of combinations of complexes that can be derived from these proteomes, for our runs, we focused on dimers (complexes of two proteins), within the same proteome (no inter-proteome complexes) that had “physical” interaction evidence in STRING. As we sought coverage, we decided to consider all interactions reported in STRING for these proteomes, rather than further filtering. Evidence in the literature suggests that filtering for STRING scores >700 can further reduce the number of inputs while increasing the likelihood of well-predicted complexes.

2. Decoupling MSA generation from structure prediction

MSA generation and structure inference are both compute-intensive but scale differently, as we recently presented in a white paper. We thus approached these computations as separate steps and implemented separate SLURM pipelines. In general, for optimal use of a node, we set up MSA generation and structure prediction this way.

MSA generation

We generated MSAs using colabfold_search with the MMseqs2-GPU backend. While MMSeqs2-GPU scales across GPUs on a node natively, we chose to spawn one MMseqs2-GPU server process per GPU on a node for easier process management. In colabfold_search, the GPUs are only used for the ungappedfilter stages and not the subsequent alignment stages (which are multithreaded CPU processes).

Therefore, we can stack colabfold_search calls and start the next one once the GPU is no longer used by the previous one, by monitoring the colabfold_search output, to reduce GPU idle time.

Although this approach oversubscribes CPU resources, in practice, we found that on a DGX H100 node, up to 25% of the overall increase in throughput can be achieved with three staggered colabfold_search processes, at the expense of slower processing of individual input chunks. 

On determining reasonable input chunk sizes, there are two factors to consider. Smaller chunk sizes result in more chunks, which means more per-process overheads, such as database loading, which can take a couple of minutes each, even on fast storage. (Pre-staging the databases on the fastest storage available, such as the on-node SSD, helps with throughput as well.) On the other hand, larger chunks take more time to finish. On a SLURM cluster with a job time limit, this results in more unfinished chunks.

The sweet spot will depend on the cluster configuration, but for our DGX H100 node with a 4-hour wall time limit, the chunk size of 300 sequences seemed to work well with the staggering colabfold_search approach.

Structure prediction

In order to increase structure prediction throughput, we leveraged both optimizations in data handling for JAX-based folding through ColabFold, as well as accelerated tooling developed at NVIDIA, including TensorRT, and cuEquivariance for OpenFold-based folding.

Deep learning inference parameters

First, we selected inference parameters that struck a good balance between accuracy and speed. Protein inference setup for all deep learning inference pipelines (ColabFold and OpenFold), thus utilized:

  • Weights: 1x weights from AlphaFold Multimer (model_1_multimer_v3)
  • Four recycles (with early stopping)
  • No relaxation
  • MSAs: frozen MSAs generated through ColabFold-search (using MMseqs2-GPU), as described above

Accuracy validation

  Homodimer PDB set (125 proteins)
Model High Medium Accept Incorr Usable DockQ
DockQ >0.8 >0.6 >0.3 >0      
ColabFold 52 37 12 21 89 (72.95%) 0.637
OpenFold with TensorRT and cuEquivariance 53 39 10 20 92 (75.41%) 0.647

Table 1. A comparison of interface accuracy between ColabFold and OpenFold (accelerated by TensorRT and cuEquivariance) across a benchmark set of 125 homodimer proteins.

As we used different inference pipelines, we performed accuracy validation using a curated benchmark set of 125 X-ray resolved PDB homodimers released after AlphaFold2 was introduced, thus minimizing the potential for information leakage.

Predicted complexes for each deep learning implementation were compared against experimental reference structures using DockQ, which evaluates interface accuracy via the fraction of native contacts (Fnat), fraction of non-native contacts (Fnonnat), interface RMSD (iRMS), and ligand RMSD after receptor alignment (LRMS), and assigns standard CAPRI classifications of high, medium, acceptable, or incorrect.

Across the PDB homodimer benchmark, OpenFold accelerated through TensorRT and cuEquivariance reproduces ColabFold interface accuracy, achieving a similar fraction of “high” scoring predictions and comparable mean DockQ scores. This indicates that the accelerated implementations preserve interface-level structural accuracy relative to the ColabFold baseline.

MSA preparation and sequence packing

For ColabFold-based homodimer inferences, higher throughput can be achieved by packing homodimers of equal length into a batch for processing, sorted by their MSA depth in descending order. This reduces the number of JAX recompilations, thereby increasing end-to-end throughput. This trick, however, does not work when processing heterodimers, because the lengths of the individual chains differ.

For OpenFold, whether for homodimers or heterodimers, this packing strategy is not needed, as the method doesn’t require re-compilation. However, given a dependency between sequence length and execution time, reserving longer sequences for individual jobs may be beneficial if operating with specific SLURM runtimes. To further optimize the process, input featurizations (CPU-bound) were performed for the next input query alongside the inference step for the current query (GPU-bound).

Additionally, OpenFold’s throughput was enhanced through the integration of the NVIDIA cuEquivariance library and NVIDIA TensorRT SDK. These modular libraries and SDKs can be leveraged to accelerate operations common in protein structure AI and general inference AI workloads, respectively. We previously described how TensorRT can be leveraged to accelerate OpenFold inference.

3. Optimize GPU utilization with SLURM

As alluded to in the previous section, depending on the available hardware, you can increase throughput by “packing” GPUs and nodes. SLURM is a great orchestrator, and we divided the inference workflows in SLURM scripts to:

  • Pack multiple predictions per node
  • Match GPU memory to sequence length
  • Reduce idle time between jobs
  • Separate short vs long sequence queues

Our workload was mapped to a H100 DGX Superpod HPC system. We could thus deploy inference across NVIDIA H100 GPUs on multi-node clusters, leveraging exclusive execution on a single node, and packing each GPU with as many processes as saturated the GPU utilization for both MSA processing and deep learning inference.

Helpful tips:

  • Group jobs by total residue length
  • Monitor GPU memory fragmentation
  • Use asynchronous I/O to avoid disk bottlenecks

4. Making quality predictions accessible to the world

In partnership with EMBL-EBI, the Steineggerlab at Seoul National University, and Google DeepMind, we explored complex structure prediction analysis. We highlight that predicting these biological systems remains challenging. Unlike protein monomer prediction, where predicted Local Distance Difference Test (pLDDT) can inform overall prediction quality, yielding a balanced amount of plausible predictions, in the complex scenario, assessing interface plausibility is much harder. This has to do with the fact that assessing complexes involves global and per-chain confidence metrics, as well as local confidence metrics at the interface.

Simply put, is the interface between two monomers plausible, and is it predicted in the right pocket? These questions are much harder to answer than more “local” questions about monomer likelihood, given the very limited data available. Therefore, we make available a set of high-confidence structures through the AlphaFold Database, thereby enabling, for the first time, exploration of protein complexes. We intend to refine our approach further and expand the universe of available protein complexes in the AlphaFold Database.

Getting started

Proteome-scale quaternary structure prediction requires more than just running AlphaFold-Multimer at scale. Success depends on:

  • Evidence-driven interaction selection
  • Decoupled and optimized compute workflows
  • GPU-aware job orchestration
  • Confidence calibration and validation
  • Dataset health monitoring

By combining STRING-guided selection, MMseqs2-GPU acceleration, and NVIDIA H100-powered multimer inference, this work extends AFDB into a unified, interaction-aware structural resource.

This infrastructure enables:

  • Variant interpretation at interfaces
  • Systems-level structural biology
  • Drug target validation
  • Generative protein design benchmarking

Resources

Read more about the project here: https://research.nvidia.com/labs/dbr/assets/data/manuscripts/afdb.pdf 

Accelerated libraries and SDKs are available here:

  • MMseqs2-GPU
  • NVIDIA cuEquivariance
  • NVIDIA TensorRT

If you wish to deploy MSA search and protein folding easily, you can get accelerated inference pipelines through NVIDIA’s Inference Microservices (NIMs):

  • MSA Search NIM 
  • OpenFold2 NIM

The predictions from this effort are available through https://alphafold.com

Add a data source using Coldfusion Administrator API

Mike's Notes

Google Search - AI Mode (Gemini) was used to find the sample code for adding a data source using the ColdFusion Administrator API.

Speed is king

My strength is architecture and problem-solving, not coding (a slow writer and too many typos), so 99.9% of the coding is now supplied via Google Search - AI Mode (Gemini), then I test everything. It's about 100X faster. 😎😎😎😎😎😎😎

Data sources

data/

  • couchbase/
  • db2/
  • derby/
  • h2/
  • hsqldb/
  • mariadb/
  • msaccess/
    • 32/ (32-bit)
    • 64/ (64-bit)
  • mssql/
  • oracle/
  • pg/
    • 18/ (version 18)
  • sqllite/
  • sybase/
  • virtuoso/

Other issues to explore later

  • The advanced arguments (such as connection pool limits or timeout settings) for these specific drivers.

Future testing

  • Install loki-01 on 9cc/
  • Run the Data Engine (dat) to create all data sources
  • Test data sources.

Here is a detailed example copied from the ColdFusion Cookbook. It is written by Jeremy Petersen and was last updated in 2007.


How do I programmatically create a new datasource?

The short answer is to use the ColdFusion Administrator API.


The following is taken directly from the ColdFusion documentation:
You can perform most ColdFusion MX Administrator tasks programmatically using the Administrator API. The Administrator API consists of a set of ColdFusion components (CFCs) that contain methods you call to perform Administrator tasks. For example, you use the setMSQL method of datasource.cfc to add a SQL Server data source.

<cfscript>
   // Login is always required. This example uses a single line of code.
   createObject("component","cfide.adminapi.administrator").login("admin");
   // Instantiate the data source object.
   myObj = createObject("component","cfide.adminapi.datasource");
   // Required arguments for a data source.
   stDSN = structNew();
   stDSN.driver = "MSSQLServer";
   stDSN.name="northwind_MSSQL";
   stDSN.host = "10.1.147.73";
   stDSN.port = "1433";
   stDSN.database = "northwind";
   stDSN.username = "sa";
   // Optional and advanced arguments.
   stDSN.login_timeout = "29";
   stDSN.timeout = "23";
   stDSN.interval = 6;
   stDSN.buffer = "64000";
   stDSN.blob_buffer = "64000";
   stDSN.setStringParameterAsUnicode = "false";
   stDSN.description = "Northwind SQL Server";
   stDSN.pooling = true;
   stDSN.maxpooledstatements = 999;
   stDSN.enableMaxConnections = "true";
   stDSN.maxConnections = "299";
   stDSN.enable_clob = true;
   stDSN.enable_blob = true;
   stDSN.disable = false;
   stDSN.storedProc = true;
   stDSN.alter = false;
   stDSN.grant = true;
   stDSN.select = true;
   stDSN.update = true;
   stDSN.create = true;
   stDSN.delete = true;
   stDSN.drop = false;
   stDSN.revoke = false;
   //Create a DSN.
   myObj.setMSSQL(argumentCollection=stDSN);
</cfscript>

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

18/04/2026

Add a data source using Coldfusion Administrator API

By: Mike Peters and Gemini
On a Sandy Beach: 18/04/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Google Gemini is cool.

The ColdFusion server stores data source configurations in specific XML files located within its installation directory. The exact location depends on your version and installation type (Server vs. J2EE configuration). [1, 2, 3, 4, 5] 

Configuration File Locations

Most modern Adobe ColdFusion versions (including ColdFusion 2021 and 2025) store these settings in the following files:

  • Main Datasource File: neo-datasource.xml.
  • Legacy/Alternative File: neo-query.xml (often used in older versions like ColdFusion 7). [1, 2] 

Default File Paths

The absolute path varies based on how ColdFusion was installed: [6] 

  • Server Configuration (Standard): {cf_root}/cfusion/lib/ (e.g., C:\ColdFusion2021\cfusion\lib\neo-datasource.xml on Windows).
  • JEE / Multiserver Configuration: {cf_webapp_root}/WEB-INF/cfusion/lib/.
  • Central Config Server (CCS): If using a [Central Config Server](https://helpx.adobe.com/coldfusion/using/central-config-server-coldfusion.html), settings are stored in <CF_Instance_Home>/bin/ccsstore/ and replicated across nodes. [1, 2, 3, 7] 

Important Notes

  • Encryption: While you can see the DSN names and server addresses in these XML files, passwords are encrypted and cannot be read in plain text.
  • Editing: It is highly recommended to manage datasources through the ColdFusion Administrator (found under Data & Services > Data Sources) rather than editing the XML files directly to avoid corruption.
  • API Access: You can also manage these settings programmatically using the [ColdFusion Administrator API](https://helpx.adobe.com/coldfusion/kb/database-connections-handled-coldfusion.html). [1, 8, 9, 10, 11, 12] 

References

To use the ColdFusion Administrator API to add a datasource, you use a set of ColdFusion components (CFCs) located in the /CFIDE/adminapi/ directory. This allows you to manage server settings programmatically without using the web-based Administrator interface. [1, 2, 3, 4] 

Prerequisites

  • Enable RDS: Some versions or configurations may require enabling the RDS service in Security > RDS within the ColdFusion Administrator.
  • Administrator Password: You must have the server's administrator password to authenticate. [1, 5, 6, 7] 

Basic Steps and Example Code

The following cfscript example demonstrates how to log in and create a Microsoft SQL Server datasource using the datasource.cfc (or Data Sources.cfc in some versions). [5, 8] 

<cfscript>
    // 1. Authenticate with the Administrator API
    adminObj = createObject("component", "cfide.adminapi.administrator");
    adminObj.login("yourAdminPassword"); // Replace with your actual admin password
    // 2. Instantiate the Data Source object
    // Note: Use "datasource" or "Data Sources" depending on your CF version
    dsObj = createObject("component", "cfide.adminapi.datasource");
    // 3. Define the datasource details
    // For SQL Server, you use the setMSSQL method
    dsObj.setMSSQL(
        name = "MyNewDSN",
        host = "127.0.0.1",
        port = "1433",
        database = "MyDatabaseName",
        username = "dbUser",
        password = "dbPassword",
        description = "Datasource created via Admin API"
    );
    // 4. (Optional) Verify the connection
    isVerified = dsObj.verifyDsn("MyNewDSN");
    
    if (isVerified) {
        writeOutput("Datasource successfully created and verified!");
    } else {
        writeOutput("Datasource created but failed verification.");
    }
</cfscript>

Common Methods for Different Drivers

The datasource component provides specific methods for different database types: [4, 9, 10] 

  • SQL Server: setMSSQL()
  • MySQL: setMySQL5() or setMySQL()
  • [Oracle](https://www.oracle.com/): setOracle()
  • Derby: setDerbyEmbedded()
  • Other JDBC: setOther() (used for custom or thin drivers) [4, 5, 6, 8, 11, 12, 13] 

Alternative: Per-Application Datasources [14] 

In ColdFusion 2021 and later, you can also define datasources directly in your Application.cfc without using the Admin API. This is often preferred for modern application deployment as it keeps configurations within the application code. [14, 15, 16, 17, 18]

// In Application.cfc
component {
    this.name = "MyApplication";
    this.datasources["myDSN"] = {
        driver: "MSSQLServer",
        host: "localhost",
        database: "mydb",
        username: "user",
        password: "pass"
    };
    this.datasource = "myDSN";
}

References

To use the ColdFusion Administrator API with tag-based syntax, you must first authenticate using administrator.cfc, then call the specific driver methods in datasource.cfc.

1. Authentication (Required First)

Before adding any datasource, you must log in to the API session. [1] 

<cfset adminObj = createObject("component", "cfide.adminapi.administrator")>
<cfset adminObj.login("yourAdminPassword")>
<!--- Instantiate the datasource object for subsequent calls --->
<cfset dsObj = createObject("component", "cfide.adminapi.datasource")>

------------------------------

2. Database-Specific Tag Examples

Microsoft SQL Server

Uses the setMSSQL method.

<cfset dsObj.setMSSQL(
    name = "MyMSSQL_DSN",
    host = "127.0.0.1",
    database = "Northwind",
    username = "db_user",
    password = "db_password"
)>

PostgreSQL

Uses the setPostgreSQL method.

<cfset dsObj.setPostgreSQL(
    name = "MyPostgres_DSN",
    host = "localhost",
    database = "sales_db",
    username = "postgres",
    password = "password"
)>

MySQL

Uses setMySQL5 (for MySQL 5.x and later, including MariaDB).

<cfset dsObj.setMySQL5(
    name = "MyMySQL_DSN",
    host = "://example.com",
    database = "inventory",
    username = "admin",
    password = "secretpassword"
)>

Oracle

Uses setOracle. Note that Standard edition users often use the "Other" method with an Oracle thin driver.

<cfset dsObj.setOracle(
    name = "MyOracle_DSN",
    host = "oracle_server",
    service_name = "ORCL",
    username = "system",
    password = "password"
)>

MS Access (32-bit vs. 64-bit)

Both use the setMSAccess method, but the behaviour depends on the server's ODBC configuration and the ColdFusion bitness.

  • 32-bit: Requires the 32-bit Microsoft Access Database Engine.
  • 64-bit: Requires the 64-bit Microsoft Access Database Engine.

<cfset dsObj.setMSAccess(
    name = "MyAccessDSN",
    database = "C:\data\mydb.mdb"
)>

Sybase

Uses the setSybase method.

<cfset dsObj.setSybase(
    name = "MySybase_DSN",
    host = "sybase_host",
    database = "production",
    username = "sa",
    password = "password"
)>

DB2

Uses the setDB2 method.

<cfset dsObj.setDB2(
    name = "MyDB2_DSN",
    host = "db2_server",
    database = "SAMPLE",
    username = "db2admin",
    password = "password"
)>

------------------------------

3. Verification (Recommended)

After adding a datasource, it is best practice to verify the connection immediately.

<cfset isVerified = dsObj.verifyDsn("MyMSSQL_DSN")>
<cfif isVerified>
    <p>Connection Successful!</p>
<cfelse>
    <p>Connection Failed. Check credentials or server availability.</p>
</cfif>

References

Java System getProperties() Method

Mike's Notes

In the Pipi Nest, I'm using CFML to retrieve Java properties directly from Java.

Test code

Here is some test code, tried yesterday. There are other ways as well.

 <!--- Instantiate the java.lang.System class --->
    <cfset system = createObject("java", "java.lang.System")>

<!--- Retrieve additional JVM properties --->
    <cfset javaVersion = system.getProperty("java.version")>
    <cfset javaVendor = system.getProperty("java.vendor")>
    <cfset javaClassPath = system.getProperty("java.class.path")>
    <cfset javaHome = system.getProperty("java.home")>
  
    <cfoutput>
      <ul>
          <li><strong>Vendor:</strong> #javaVendor#</li>
          <li><strong>Version:</strong> #javaVersion#</li>
          <li><strong>Home:</strong> #javaHome#</li>
          <li><strong>Classpath:</strong> #javaClassPath#</li>
      </ul>
    </cfoutput>

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

17/04/2026

Java System getProperties() Method

By: 
Tutorials Point: 17/04/2026

Tutorials Point originated from the idea that there exists a class of readers who respond better to online content and prefer to learn new skills at their own pace from the comforts of their drawing rooms.

Our mission is to deliver Simply Easy Learning with clear, crisp, and to-the-point content on a wide range of technical and non-technical subjects without any preconditions and impediments.

Description

The Java System getProperties() method determines the current system properties. The current set of system properties for use by the getProperty(String) method is returned as a Properties object.

If there is no current set of system properties, a set of system properties is first created and initialised. This set of system properties includes values for the following keys −


Key Description of Associated Value
java.version Java Runtime Environment version
java.vendor Java Runtime Environment vendor
java.vendor.url Java vendor URL
java.home Java installation directory
java.vm.specification.version Java Virtual Machine specification version
java.vm.specification.vendor Java Virtual Machine specification vendor
java.vm.specification.name Java Virtual Machine specification name
java.vm.version Java Virtual Machine implementation version
java.vm.vendor Java Virtual Machine implementation vendor
java.vm.name Java Virtual Machine implementation name
java.specification.version Java Runtime Environment specification version
java.specification.vendor Java Runtime Environment specification vendor
java.specification.name Java Runtime Environment specification name
java.class.version Java class format version number
java.class.path Java class path
java.library.path List of paths to search when loading libraries
java.io.tmpdir Default temp file path
java.compiler Name of JIT compiler to use
java.ext.dirs Path of extension directory or directories
os.name Operating system name
os.arch Operating system architecture
os.version Operating system version
file.separator File separator ("/" on UNIX)
path.separator Path separator (":" on UNIX)
line.separator Line separator ("\n" on UNIX)
user.name User's account name
user.home User's home directory
user.dir User's current working directory

Declaration

Following is the declaration for java.lang.System.getProperties() method

public static Properties getProperties()

Parameters

NA

Return Value

This method returns the system properties.

Exception

SecurityException − if a security manager exists and its checkPermission method doesn't allow access to the process environment.

Example: Getting All Available Properties of JVM System

The following example shows the usage of Java System getProperties() method. We've retrieved a Properties object using System.getProperties() method. Then using list() method of Properties object, we're printing all properties on console.

package com.tutorialspoint;

import java.util.Properties;

public class SystemDemo {

   public static void main(String[] args) {

      // this will list the current system properties
      Properties p = System.getProperties();
      p.list(System.out);
   }

Output

Let us compile and run the above program, this will produce the following result −

package com.tutorialspoint;

import java.util.Properties;

public class SystemDemo {

   public static void main(String[] args) {

      // this will list the current system properties
      Properties p = System.getProperties();
      p.list(System.out);
   }

Output

-- listing properties --
java.specification.version=21
sun.cpu.isalist=amd64
sun.jnu.encoding=Cp1252
java.class.path=C:\Users\Tutorialspoint\eclipse-works...
java.vm.vendor=Oracle Corporation
sun.arch.data.model=64
user.variant=
java.vendor.url=https://java.oracle.com/
java.vm.specification.version=21
os.name=Windows 11
sun.java.launcher=SUN_STANDARD
user.country=IN
sun.boot.library.path=C:\Program Files\Java\jdk-21\bin
sun.java.command=com.tutorialspoint.SystemDemo
jdk.debug=release
sun.cpu.endian=little
user.home=C:\Users\Tutorialspoint
user.language=en
java.specification.vendor=Oracle Corporation
java.version.date=2024-01-16
java.home=C:\Program Files\Java\jdk-21
file.separator=\
java.vm.compressedOopsMode=Zero based
line.separator=

java.vm.specification.vendor=Oracle Corporation
java.specification.name=Java Platform API Specification
user.script=
sun.management.compiler=HotSpot 64-Bit Tiered Compilers
java.runtime.version=21.0.2+13-LTS-58
user.name=Tutorialspoint
stdout.encoding=UTF-8
path.separator=;
os.version=10.0
java.runtime.name=Java(TM) SE Runtime Environment
file.encoding=UTF-8
java.vm.name=Java HotSpot(TM) 64-Bit Server VM
java.vendor.url.bug=https://bugreport.java.com/bugreport/
java.io.tmpdir=C:\Users\TUTORI~1\AppData\Local\Temp\
java.version=21.0.2
user.dir=C:\Users\Tutorialspoint\eclipse-works...
os.arch=amd64
java.vm.specification.name=Java Virtual Machine Specification
sun.os.patch.level=
native.encoding=Cp1252
java.library.path=C:\Program Files\Java\jdk-21\bin;C:\W...
java.vm.info=mixed mode, sharing
stderr.encoding=UTF-8
java.vendor=Oracle Corporation
java.vm.version=21.0.2+13-LTS-58
sun.io.unicode.encoding=UnicodeLittle
java.class.version=65.0