I wonder if we could "define a custom process" to prompt the developer for, "Connect to default2 database?" and execute a "connect.p" as they enter the environment and a "disconnect.p" as they leave?

To connect to the custom database in a Progress session it needs to be configured, which in YAB amounts to defining instances of the "db" and "dbserver" type. If the database is configured the following commands would list your custom database and database server.

> yab -instances config db
> yab -instances config dbserver

I'll assume you have that done, but if not and need some guidance let us know.

Your easiest path forward would be to simply configure the custom database for the compile of the code in "customizations/mfg/.../src", by adjusting the following setting:

> yab config code.mfg-customizations.databases
code.mfg-customizations.databases=db.qadcpl,db.configurator,db.qadadm,db.qadhlp,db.qadrcode

Whether or not this straighforward approach is acceptable depends on how strictly you want to hold to only compiling these programs with that database connected. By adjusting this configuration setting you would be compiling all operational customizations with the database connected but not any standard operational code or patches.

The alternative approach which is more involved would be to define a new compile for these four programs by defining a new instance of the "code" type. Typically this would mean that the compiler would write the r-code into a separate directory and then the appropriate runtime propaths would need to be adjusted to reference the r-code. Let us know if you want to head down this path and we can provide further details.

#solution makes sense if we wanted to have the custom database set up.  However, we already have a custom database set up for all our customizations.  And yes, we configured it as you describe.  This does not resolve our problem.  There are only 4 programs that connect to another custom database - from a vendor.  We don't want to be connected to that database unless we need to compile the 4 programs.  The hundreds of other custom programs don't require  connection to the vendor database.  Therefore, setting up a permanent connection isn't reasonable.  We only want to connect to it when we need to - which is not very often.

So far, I find myself thinking I should write a custom program that makes the connection and train the developers to run that program if they need to compile one or more of those 4 programs.  That would work - if not awkward.  I guess I am looking for a solution in YAB to prompt the developer or release engineer for a database to connect to when they compile the system and YAB comes across those 4 programs.  I don't see a way to do that yet...not with YAB anyway.

It sounds like you are looking for the "alternative" approach that I discussed in my previous comment. The configuration below will setup a new compile to compile JUST the four programs with the extra database connected. This compile can be called directly (yab code-fourprograms-update), otherwise it will be run after the customization compile.

The four programs should be copied into 'customizations/fourprograms/src' and the r-code will be written into 'dist/fourprograms'.

Of course, "fourprograms" is just a place holder name since we have not discussed a suitable name for these four programs. You should be able to replace all cases of "fourprograms" in the solution below with an alternative name that consists of lower case letters.

And the "code.fourprograms.databases" needs to be adjusted to reference the vendor database (e.g. db.somename).

Let us know if you have any questions.

# define a new compile to compile the four programs with the extra database connected
# @extends code._base
code.fourprograms.dir=${dist.dir}/fourprograms
code.fourprograms.databases=${code.mfg.databases},[PUT DATABASE REFERENCE HERE]
code.fourprograms.params=${code.mfg.params}
code.fourprograms.languages=${code.mfg.languages}
code.fourprograms.threads=${code.mfg.threads}
code.fourprograms.failonerror=${code.mfg.failonerror}
code.fourprograms.force=${code.mfg.force}
code.fourprograms.removeorphanedrcode=${code.mfg.removeorphanedrcode}
code.mfg-customizations.removeorphanedrcode=${code.mfg.removeorphanedrcode}
code.mfg-customizations.scan=false
# @ref code.mfg.propath
# @ref propath.mfg.customizations
code.fourprograms.propath=${code.fourprograms.sources.main.dir}
code.fourprograms.sources.main.dir=${customizations.dir}/fourprograms/src

# configure the compile to run after "code-mfg-customizations-update"
process.fourprograms.id=code-fourprograms-update
process.fourprograms.anchormeafter=code-mfg-customizations-update

# add the r-code to the runtime propaths
propath.mfg.customizations=${code.fourprograms.dir}
 

@Will
This approach seems promising.  I'll give it a go and see what comes of it.  Thanks for the direction!

So far so good.  However, we seem to be stuck on how to configure the "extend" database connections to the custom & sql databases:

We don't need to configure YAB to configure the database - only connect to it:

What are the YAB properties to set up the connections without YAB administrating the external databases?:

e.g.:​

From ABL Code:

CONNECT custom1 -H customserver -S 44550 -ld customld
-db customsql -dt MSS -ld customsql -H customserver -S 12345
-U user -P ***** -DataService customsql_broker -Dsrv SVUB,1
NO-ERROR.

In this situation the best approach would be to define a PF file with connections and then adjust this setting to reference the PF file:

code.fourprograms.params=${code.mfg.params} -pf ${appdir}/fourprograms.pf

You should see the PF in the log when you compile:

2019-12-13 07:01:30,379 DEBUG [main:d582] OpenEdgeCompileCommand - params=-db "/dr01/qadapps/systest/databases/cpldb" -ct 120 -ld qaddb -RO -trig triggers, -db "/dr01/qadapps/systest/databases/cpddb" -ct 120 -ld procon -trig triggers, -db "/dr01/qadapps/systest/databases/admdb" -ct 120 -ld qadadm -trig triggers, -db "/dr01/qadapps/systest/databases/hlpdb" -ct 120 -ld qadhlp -trig triggers, -db "/dr01/qadapps/systest/databases/rcddb" -ct 120 -ld qadrcode -RO -trig triggers, -T /tmp -d mdy -yy 1950 -s 32768 -mmax 10000 -inp 32000 -rereadnolock -c 30 -D 1000 -Bt 350 -nb 200 -h 25 -tok 4096 -tmpbsize 8 -TB 31 -TM 32 -cpstream utf-8 -cpinternal utf-8 -cprcodeout utf-8 -cpcoll ICU-UCA -cpcase basic -v6colon , -pf /dr01/qadapps/systest/fourprograms.pf
 

I've been able to get this working using this approach.  I'll have to post what I did so that others won't suffer as I did!

In the meantime, there is a progress issue with connecting down from 11.7 client to 11.3 OpenEdge DataServer for MSS Server.In order to properly connect, we need to use the -znoencrypt switch on the YAB compiles.  Works well from an editor CONNECT.  Not sure where to apply the switch in the YAB configuration.properties.

Any idea?

e.g.  $DLC/bin/_progres -pf /app/qad/uat/build/work/generated/application-connected.pf -cpinternal $CODEPAGE -cpstream $CODEPAGE -cprcodeout utf-8 -znoencrypt

The related query you asked through Support was routed through an internal forum, so we have that background as well:

Progress figured out the problem.  I need to know how to tell YAB to add
the -znoencrypt switch on compile session startup so that YAB will connect
to a dataserver without encrypting the username and password.
e.g. $DLC/bin/_progres -pf /app/qad/uat/build/work/generated/application
-connected.pf -cpinternal $CODEPAGE -cpstream $CODEPAGE -cprcodeout utf-8 -znoencrypt
where and what is the syntax to tell YAB -znoencrypt
I tried this without success:
# @extends code._base
code.snr.dir=${dist.dir}/snr
code.snr.databases=${code.mfg.databases}
code.snr.params=${code.mfg.params} -znoencrypt -pf ${appdir}/snrdev.pf
code.snr.languages=${code.mfg.languages}
code.snr.threads=${code.mfg.threads}
code.snr.failonerror=${code.mfg.failonerror}
code.snr.force=${code.mfg.force}
code.snr.removeorphanedrcode=${code.mfg.removeorphanedrcode}
Or do I have to rebuild scripts?

 

I also tried this without success - even after running a scripts update

 # @append 

progress.startup.params=-t -znoencrypt

What you did (adding -znoencrypt to code.snr.params) defines that startup parameter in the compile session and there is no need to rebuild scripts. Basically the compile is an "incremental" wrapper around a standard Progress compile. It generates temporary scripts automatically that are normally deleted when the compile session ends. We can change that behavior by exporting an environment variable before running the compile (from the Troubleshooting section in the Admin Guide).

So I took your configuration (and added some source code) and then defined the export to keep temporary files.

> export KEEP_TEMP_FILES=true

Next I ran the compile:

> yab -v code-snr-update

The log indicates that we defined the startup parameter.

2019-12-20 13:31:00,339 DEBUG [main:fb94] OpenEdgeCompileCommand - params=-db "/dr01/qadapps/systest/databases/cpldb" -ct 120 -ld qaddb -RO -trig triggers, -db "/dr01/qadapps/systest/databases/cpddb" -ct 120 -ld procon -trig triggers, -db "/dr01/qadapps/systest/databases/admdb" -ct 120 -ld qadadm -trig triggers, -db "/dr01/qadapps/systest/databases/hlpdb" -ct 120 -ld qadhlp -trig triggers, -db "/dr01/qadapps/systest/databases/rcddb" -ct 120 -ld qadrcode -RO -trig triggers, -T /tmp -d mdy -yy 1950 -s 32768 -mmax 10000 -inp 32000 -rereadnolock -c 30 -D 1000 -Bt 350 -nb 200 -h 25 -tok 4096 -tmpbsize 8 -TB 31 -TM 32 -cpstream utf-8 -cpinternal utf-8 -cprcodeout utf-8 -cpcoll ICU-UCA -cpcase basic -v6colon -znoencrypt , -pf /dr01/qadapps/systest/snrdev.pf

But did we? To find out look for a line like this in the log:

2019-12-20 13:31:00,650 DEBUG [compile-0:fb94] ProgressProgramExecutor - /tech/progress/dlc1175_009/bin/_progres -pf /tmp/4465183555222778040/7185887727247998852.pf -T /tmp -b -param /tmp/4465183555222778040/86785516331779679/task-0 -p /tmp/4465183555222778040/86785516331779679/init.p

And then cat the PF file used for the compile session:

> cat /tmp/4465183555222778040/7185887727247998852.pf
-db "/dr01/qadapps/systest/databases/cpldb" -ct 120 -ld qaddb -RO -trig triggers
-db "/dr01/qadapps/systest/databases/cpddb" -ct 120 -ld procon -trig triggers
-db "/dr01/qadapps/systest/databases/admdb" -ct 120 -ld qadadm -trig triggers
-db "/dr01/qadapps/systest/databases/hlpdb" -ct 120 -ld qadhlp -trig triggers
-db "/dr01/qadapps/systest/databases/rcddb" -ct 120 -ld qadrcode -RO -trig triggers
-T /tmp -d mdy -yy 1950 -s 32768 -mmax 10000 -inp 32000 -rereadnolock -c 30 -D 1000 -Bt 350 -nb 200 -h 25 -tok 4096 -tmpbsize 8 -TB 31 -TM 32 -cpstream utf-8 -cpinternal utf-8 -cprcodeout utf-8 -cpcoll ICU-UCA -cpcase basic -v6colon -znoencrypt
-pf /dr01/qadapps/systest/snrdev.pf

Check if your results match up to mine. If they do the same temp directory also has the compile program we are running and that may provide a clue as to the difference, between your results in the Progress editor.

ok, I followed your suggestions and diagnosed the last remaining issue.

This was quite helpful:

export KEEP_TEMP_FILES=true

That enabled me to really dig into the issue:

[mfg@thor 8400092592512994408]$ ll -ltr
total 24
-rw-r--r-- 1 mfg qad   30 Dec 23 07:46 init.p
-rw-r--r-- 1 mfg qad  508 Dec 23 07:46 compile-error-handler.i
-rw-r--r-- 1 mfg qad 3117 Dec 23 07:46 task-0
-rw-r--r-- 1 mfg qad 8818 Dec 23 07:46 task-0.e
[mfg@thor 8400092592512994408]$ pwd
/tmp/2169280683644803621/8400092592512994408
[mfg@thor 8400092592512994408]$

I think we've finally got this down.

For documentation purposes, I will put this together after we've moved forward and provide a synopsis of all we did.
 

Good afternoon Will.  I hope you had a great holiday!

The approach does seem to be working.  However, the distributed code (.r code) does not seem to be in the runtime propath.

I added the following in config.properties without success:

#add the r-code to the runtime propaths
propath.mfg-customizations=${code.snr.dir}
propath.mfg-customizations=${code.pb.dir}
propath.mfg-customizations=${code.xserver.dir}

Is there something else I need to do in order to configure the runtime propath with yab?

You need to use annotations (special instructions in comments) to let YAB know if your intent is to replace a setting or to append to a setting.

If your problem is that the last two definitions were not applied (first wins) then this will address that problem:

# @append
propath.mfg-customizations=${code.snr.dir}
# @append
propath.mfg-customizations=${code.pb.dir}
# @append
propath.mfg-customizations=${code.xserver.dir}

Or more succinctly this:

# @append
propath.mfg-customizations=${code.snr.dir},${code.pb.dir},${code.xserver.dir}

You can use the "config" command afterwards to check the result:

yab config propath.mfg-customizations

Adding the -trace option will show where the values come from:

yab -trace config propath.mfg-customizations

If the value of "propath.mfg-customizations" is what you want but it is not being applied in the desired Progress session(s), then either the change has not been applied (yab reconfigure) or the session is not configured by default to inherit/use the "propath.mfg-customizations" paths. If that is the case let us know which Progress session(s) you are trying to target.