Porting from D3

[gplc...@gmail.com]

Hi All,

I am porting a very large system consisting of a number of accounts from D3 and I have some questions:

1. In a D3 subroutine, I am 'EXECUTE'ing a 'SELECT' inside BASIC using the 'J' option to suppress all screen/print output. I have noticed that there are no options on the QM 'SELECT' statement. Is there anything equivalent to D3's 'J' option?

2. I am trying to load these D3 accounts under QM quickly but unfortunately, QM's 'SET.DEVICE' does not support 'Pick style use of floppy disks as tape devices'. I am not sure what this means but we backup the D3 system using a specific device. When I do a 'LIST-DEVICE' from D3, I see, for example, tape 7 which is of type 'Floppy', with the density 'Pseudo Floppy' and a path and file name in 'Device Name'. Is this one of the floppy disks as tape drives that manual mentions QM does not support?

If so, would I need to get an actual tape drive and create the D3 saves to a physical tape in order for it to be restorable under QM.

When I do a 'SET.DEVICE'  followed by an 'ACCOUNT.RESTORE', on a single account that I know is contained in the D3 save, QM does find the account but there are only a couple of small files that are restored. When I do a 'RESTORE.ACCOUNTS', I get nothing.

TIA,

Rick

[CDMI - Steve T]

I would do something like:

VERB = "SELECT CUSTOMERS BY LNAME"

EXECUTE VERB CAPTURING RESULT RETURNING ERRINFO

the above does not display to the screen

read the qm documentation under: RESTORE.ACCOUNTS & then ACCOUNT.RESTORE

you should be able to restore your accounts from D3 (to a point)

you can't restore binary compiled code (I don't think)

I believe you have to perform the D3 save in a backward compatible mode (but not sure)

Martin Phillips will probably get to you fairly quickly

good luck!

 

Steve Trimble

office (501) 615-8674

cell (501) 772-3450

Computerized Data Mgmt Inc (CDMI)

---

From: "gplc...@gmail.com" <gplc...@gmail.com>
To: OpenQM <ope...@googlegroups.com>
Sent: Tuesday, July 18, 2017 2:59 PM
Subject: Porting from D3

--
You received this message because you are subscribed to the Google Groups "OpenQM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openqm+un...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at https://groups.google.com/group/openqm.
For more options, visit https://groups.google.com/d/optout.

[Vasco Antonio]

Steve Trimble got it right...

I have done exactly the same job, restoring several D3 File Saves with a lot of D3 Accounts; browsing the OpenQM manual carefully, everything will work perfectly...

Any doubts or questions moving from D3 to OpenQM, please do not hesitate to contact.

Good Luck,

Vasco Antonio

(Software Systems Engineer)

Multi Digital Systems PTY Ltd

Cell Phone: +27 732031654

Office: +27 114650109

[gplc...@gmail.com]

Thanks,

I will try using CAPTURING.

I did carefully read the QM manual in the areas of SET.DEVICE, RESTORE.ACCOUNTS and ACCOUNT.RESTORE. I got what I stated in my original post: a couple of incomplete tables when using the ACCOUNT.RESTORE (with the NO.OBJECT option). I tried this three different ways. Once using the 'AS' format of SET.DEVICE (which turned out to be correct). I tried once with the 'R83' format of SET.DEVICE which QM could not recognize and I tried once without any explicit format letting QM figure the format out. In the first and last case, I got two partial files of the account I asked for. The file save I was using as the source was one of our daily full D3 backups.

When I tried RESTORE.ACCOUNTS (with the NO.OBJECT option), I got nothing. No accounts created.

Rick

[Vasco Antonio]

Hi Rick,

I assumed some kind of environment matching with my own environment; if for me worked, it must work for you too, unless...

What is the D3 version?

Is it Windows or other OS?

How the backups were done in D3?

Is the backup produced as a some kind of "Pseudo0.D3P" with no options like specific "block-size", or "incremental" type, etc...?

Is your OPENQM a licensed version? (Personal version doesn't allow you to do a complete restore!)

From my side all backus were done using straight "FILE-SAVE" or "ACCOUNT-SAVE" without any options and using D3 Version 7.x or below...

The only way to help you in efective is of course having a few files from one of your accounts, saved in D3 and trying to restore it myself...

Good luck again and keep me posted...

Vasco Antonio (va...@multidigitalsys.co.za)

(Software Systems Engineer)

Multi Digital Systems PTY Ltd

Cell Phone: +27 732031654

Office: +27 114650109

[gplc...@gmail.com]

Hi,

Thanks for the reply.

In answer to your questions:

1. D3 version is 7.x

2. the host backup OS is Windows Server 2012 R2. The host restore OS is AntiX linux (x64). Both of my QM licenses are based on a Linux host (could that be an issue?)

3. how the D3 backup is done is a mystery, it is an automatic scheduled thing, I don't know what command it runs

4. the backup file produced has no extension and is in the form 'filesave'01-05 representing the day of the week

5. both QM installations that I have are licensed, three (3) users each

Based on your comments, I will try a manual ACCOUNT-SAVE.

Rick

[Martin Phillips]

Hi,

Time to dive in to this conversation….

 

My guess is that the problem here will be that the D3 save was not done using "compatible mode" which I believe is the (a option.

 

Although a standard save should be restorable on a QM system, we have encountered a few cases of media format variations that we have been unable to resolve. Partly because of this, we produced the QMSAVE tool which has been used by several sites moving from Pick style systems to QM.

 

 

Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England
+44 (0)1604-709200

[CDMI - Steve T]

Martin:

perhaps you should enlighten where the 'qmsave tool' is documented.

 

Steve Trimble

office (501) 615-8674

cell (501) 772-3450

Computerized Data Mgmt Inc (CDMI)

---

From: Martin Phillips <sup...@openqm.com>
To: ope...@googlegroups.com
Sent: Thursday, July 20, 2017 10:35 AM
Subject: RE: Porting from D3

[Martin Phillips]

Good idea…

 

The QMSAVE tool is issued in source form in the BP file of the QMSYS account. It has conditional compilation constructs for different Pick style platforms. Sadly D3 doesn't support $IFDEF so you need to either edit the source code by hand or use the pre-processor that is also in the BP file. Once  edited, the program should compile on D3. Usage instructions appear in the comments at the start of the program.

 

The corresponding QMRESTORE program is a standard part of the QM global catalogue and is documented in the QM KnowledgeBase (http://www.openqm.com/?T0=h&t1=kb.00011).

[Felipe Gordillo]

My tip:

from Linux:

mv filesave.file filesave.file.gz

gunzip filesave.file.gz

from QM:

set.device  /path/to/filesave.file  FS

find.account myaccount

account.restore NO.CASE NO.OBJECT POSITIONED

   ...

hth

To unsubscribe from this group and stop receiving emails from it, send an email to openqm+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.
Visit this group at https://groups.google.com/group/openqm.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenQM" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openqm+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.
Visit this group at https://groups.google.com/group/openqm.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenQM" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openqm+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.
Visit this group at https://groups.google.com/group/openqm.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenQM" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openqm+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.
Visit this group at https://groups.google.com/group/openqm.
For more options, visit https://groups.google.com/d/optout.

--

Felipe Gordillo

[gplc...@gmail.com]

An Update,

I have been able to do a SET-DEVICE followed by an ACCOUNT-SAVE on the originating D3 system followed by a SET.DEVICE and ACCOUNT.RESTORE on the target QM system. I also did a T-REW on the source D3 system after the SET-DEVICE after reading in the D3 manual that the device should be rewound before applying any I/O.

I also tested the CAPTURING and RETURNING clauses of the EXECUTE statement which did not suppress the 'SELECT' message. I am still getting:

   1 record(s) selected to list 0

on the console when the function executes.

I have attached UTIL.BP, TEST which is the loader test program, LIB.BP, DB.GET.ONE which is the function in question and LIB.BP, CONSTANTS.H which is the function include file. These three modules are contained in an attached pdf (printed from wED).

Rick

[gplc...@gmail.com]

Thanks Martin,

I'll be using this extensively during my port.

BTW, I did not use the 'compatible option' on my transfer test account. In fact, the D3 manual makes no mention of this option for ACCOUNT-SAVE and mentions it only on the description of ACCOUNT-RESTORE.

Because the lack of D3 compiler directives, I too am using a preprocessor to implement BASIC code across multiple MV environments.. I am using Tony's preprocessor from Nebula Research. Can you please give me the record/item ID in the QMSYS BP file where I may find the preprocessor?

Thanks,

[Martin Phillips]

Hi,

 

The pre-processor that we issue in source form is in the BP file of the QMSYS account as PREPROC.

[fwi...@sbcglobal.net]

Yes, cutting the save with (A is essential on a d3/nt  aka d3/windows  platform -- it forces accounts on tape to be declared as being  in the 'VME'  instead of the 'FSI';
We commonly do this when porting an account from D3/Windows to a d3/linux box, for example;  d3/linux cannot read a tape from d3/windows at all without
this precaution, as the FSI:  prefixes do not seem to be compatible with the restore processor of d3/linux at all, 'poisoning' the whole tape for d3/linux.
To reiterate -- if your office is d3/linux and your boss hands you a file-save tape from a d3/nt box, you absolutely cannot read it on your d3/linux -- you must either
have it recut and resent to you using (A  or you must dig up a 3rd party d3/nt or d3/windows box that you can restore & recut the save with, again using (A for the recut.

I can only assume  cutting the save with (A  will yield similar benefits for reading it back with the OpenQM  tape restore program(s).

The reverse process, of migrating a d3/linux account to d3/windows, involves restoring the account on the d3/windows box using the (R  command line
flag to force the account into the 'FSI' of d3/windows event though the tape indicates {or is somehow defaulted to} the account came from the 'VME'.  In D3
the 'VME' is of a specified limited size, versus the 'FSI' is of unlimited size, which makes it worth the trouble to maintain this distinction I guess. This topic is not
addressed in the d3 reference manual or old HELP command as far as I've seen, but was discussed in the MVDBMS group and possibly in the old comp.databases.pick
newsgroup.  

Another limit of some old versions of d3/nt is inability of the restore processor to pull very large files from tape -- I forget what 'large' limit was, but at the time was agog at that
end-user keeping such whoppers around... At least it crashed the restore on large files instead of silently truncating them...

You can use linux tools to examine a troublesome d3 file-save tape, looking for 'FSI'  prefixes and  checking to see if it is compressed / gzipped/ bzipped/ etc {mostly a
problem on d3/linux platforms, not tapes cut from d3/windows}   You do not need the complete file-save data stream for this, and can use the  dd  command of a cygwin
install on windows for example to 'snip' off a sample for local examination or emailing to another site to be examined there...

On d3, after you cut a file-save { or just a 'save' tape -- the file-save command is a front end for the save command} you can  t-rew to start of tape and
try to account-restore bozodude   -- it will not find that account but in the process of looking it issues a line-item message for each account that _is_ on
the file-save tape, proving that your save has the account names you expected.   Suggest you  preface your file-save command with a
SSELECT  MDS,,   command to force the accounts onto tape in alphabetical order of account name {except dm account of vme gets pulled to front of
tape inside the file-save program}  Which gives you a rough indication of how far along you are during the save and then later the restore...

We once pulled all the accounts off an odd 'pick-like' platform box that was so odd that we had to resort to running a program on the odd box that
stuffed a bunch of T-DUMPs instead of account-saves -- that same program also produced a bunch of PROCS telling how to T-LOAD the tape back on the
d3/sco box, and assisted us in manually omitting all the compiled basic dictionaries from the endeavor too but I forget the details of that bit.  Arduous but
we finally sucked all the stuff off the odd box into d3.  That was like 25 years ago and we've not had to resort to t-dumps only but that one horrible time...

Frank

[fwi...@sbcglobal.net]

Oops; 
      a)  the  d3refman doesn't seem to cover the need for (A flag and (R flag when going from and coming back to a d3/nt box using save tapes;
      it absolutely does a splendid job of discussing VME versus FSI in general.  I inserted a digression that made that point unclear -- sorry.

     b)  Some old versions of d3/nt don't restore large individual  ITEMS -- I mistakenly wrote large FILES  in my post.

     c)  In a very few of the old d3 releases, only a few comonly-used command line flags of your file-save command get passed along to the eventual SAVE command,
          and I forget if (A    was on this  short-list for those releases;
          so if your   FILE-SAVE (A   still seems to be cranking out  FSI-ridden accounts on the resulting 'tape', try doing the bare SAVE  (A  manually instead of using
          the nice FILE-SAVE  front end command.  This is a low probability situation. 
          Source code is provided of FILE-SAVE in d3, so you can also rule this situation out by reading that.
     d) I think that odd box  /  t-dump   snafu was like 15 years ago, not 25...