Scribd
Upload
58 views

Releasing Software: Setting Default Production Software Level/Class Switching Users To Run Certain Level/Class Software

This document provides guidelines for releasing new versions of software and switching Dynata production users and systems to run certain software levels or classes. It outlines general rules such as not changing defaults on Fridays and only changing when jobs are not running. It describes editing configuration files to set new defaults for full service, SNAP, and database software. Exceptions and other considerations for dependent software and shortcuts are also discussed.

Uploaded by

jeff
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
58 views

Releasing Software: Setting Default Production Software Level/Class Switching Users To Run Certain Level/Class Software

This document provides guidelines for releasing new versions of software and switching Dynata production users and systems to run certain software levels or classes. It outlines general rules such as not changing defaults on Fridays and only changing when jobs are not running. It describes editing configuration files to set new defaults for full service, SNAP, and database software. Exceptions and other considerations for dependent software and shortcuts are also discussed.

Uploaded by

jeff
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

DYNATA, LLC October 2019 by Irina Krotova

RELEASING SOFTWARE
SETTING DEFAULT PRODUCTION SOFTWARE LEVEL/CLASS
SWITCHING USERS TO RUN CERTAIN LEVEL/CLASS SOFTWARE

The above triple-header shows synonymous terminology. VMS software developers at Dynata use any of
these phrases when notifying production team about software release.

Pre-release steps are described in separate documents:

- Updating_Software_inCMS.docx
- Building_Software_with_CMS_MMS.docx

The

General rule 1: Do not change default software level on Friday.

General rule 2: Change default production software levels when no sample production jobs are
executing, dialing, queued for execution or dialing.

Stop execution queues so that no new orders started while you are upgrading production software
(Database Administrator can assist with stopping queues.)

When changing default for full service production, ignore status of SNAP orders.

When changing default for SNAP, ignore status of full service orders.

Ignore the JOBDONE queue and the queues where Username is one of the following:

None/blank
DBOPER
DSD
SNAPD
SYSOPER
SYSTEM

To check all queues (majority of full service orders are executed on TOM$APT):
show queue/all

To check SNAP queues:


show queue *snap*/all

To check screeners:
sdt
wdt

1
An example of VMS response showing that a full service order submitted by EBEN and a SNAP order for
GALLUPG1K is in the screener:
Distributed Screener for SNAP Service on 10-OCT-2019 11:56:34.71
Connected to the VMS Process Server!

ID USER FILE-SPEC P S CY TOTAL DIALED ELAPSED ETA DEADLINE


==== ============ ============= = = == ====== ====== ======== ======== ========
218 EBEN PRT952823.001 5 D US 40000 29922 00 15:49 10-13-05 10-13:00
220 GALLUPG1K PRT456902.001 5 P US 3800 563 00 01:27 10-13-14 11-10:28

General rule 3: Typically, SNAP software level is changed to the same level as full service software in a
couple weeks after changing the full service software default.

General rule 4: Database software (software of groups UPDATE and RDDUPDATE) usually released
independently of sampling software (group PRODUCTION).

Exception from rules 3, 4: Some changes require simultaneous switch of full service and SNAP, (and
Database software). For instance, simultaneous switch is required if a structure of some database or bridge
file changed and software was adjusted to process the new structure.

To change default software level (or class) for FULL service production, edit
UTL:CURRENT_APT_VERSION.COM

There are 3 lines to edit. In each, replace software class with the one to use as default.
$ standard_apt_sw := class
$ UAT := class
$ QA := class

To change the default software level of standard ABS software, edit


UTL:CURRENT_ABS_VERSION.COM

There are 3 lines to edit. In each, replace software class with the one to use as default.
$ standard_abs_sw := class
$ UAT := class
$ QA := class

To change SNAP software level, edit


UTL:SNAP_ENV.COM

Replace class in 6 lines total (they look similar as for full service).

2
Depending on the scope of software changes, the following script may need editing:
UTL:SSISTD_ENV.COM

The script defines variety of logical names. These names may be hardcoded across software and also used
in symbol definitions.

When to edit this script?

Example 1.

MERLIN_ROUTINES.FOR and QC_TASK.FOR refer to ‘DIR$SSISTD_SW:KEYLINE_LIST.DAT’ (to display and


validate U.S. key-line items)

If keyline_list.dat differs between software levels, DIR$SSISTD_SW must point at a proper level.

Example 2.

When producing samples for Nielsen, users type certain symbols (such as SAM, RADUPDATE) that are
shortcuts for the command routines.
sho sym SAM
SAM*PLE == "@DIR$SAMPLEWIZ_SW:sample_wizard"
sho log DIR$SAMPLEWIZ_SW
"DIR$SAMPLEWIZ_SW" = "EXEROOT:[RELEASE.SAMPLEWIZ]" (LNM$PROCESS_TABLE)

Sho sym RADUPDATE


RADUPDATE == "@DIR$RAD_SW:RAD-CONTROL_PROCESS"
sho log DIR$RAD_SW
"DIR$RAD_SW" = "EXEROOT:[BETA.RAD]" (LNM$PROCESS_TABLE)

If software specified by these symbols differs between classes and you are switching users to use a certain
class as default, there are two options:

- Define logical name in UTL:SSISTD_ENV.COM to point at the default class

Or

- Instruct users not to use symbols but to run pertinent software explicitly.
For instance, if symbol SAM is set to run RELEASE and the user have to run BETA temporarily,
instruct to type the full command line instead of its shortcut SAM:

@EXEROOT:[BETA.SAMPLEWIZ]SAMPLE_WIZARD

New defaults take effect when user either logs in to VMS or starts APT or ABS production
system, or when SNAP job starts processing on VMS.

You might also like