Previous month:
November 2020
Next month:
January 2021

December 2020

How to schedule on MPE/iX using MPEX

Onscreen report
Newswire Classic

By Shawn M. Gordon

Inside VESOFT covers tips and techniques you can use with VESOFT’s products, especially MPEX. 

Some pretty sophisticated job scheduling abilities are inside MPEX/Streamx. They don’t get talked about often, but they are really very cool to use if you don’t already have a scheduler. Since this does rely on Streamx, it will be necessary for you to own Security/3000 for it to work. The SHOWJOB was enhanced to support this, a new command (SHOWSCHED) was added to give direct support, and a new parameter was added to STREAMX, ::SETSCHEDULE, that does some basic interfacing.

First let’s take a look at the SHOWJOB command below.:

Syntax:   %SHOWJOB [mpe showjob parameters]
                    [;JOB=@A]
                    [;NOSEC]

Examples: %SHOWJOB JOB=@A
           %SHOWJOB SCHED;NOSEC
           %SHOWJOB [email protected];*LP

%SHOWJOB

JOBNUM  STATE IPRI JIN  JLIST    INTRODUCED  JOB NAME

#S2     EXEC        20  20       WED  7:41A  SHAWN,MANAGER.SYS
#J3     EXEC        10R LP       WED  7:43A  BACKG,MANAGER.VESOFT
#S3     EXEC         2  2        WED  8:05A  SHAWN,MGR.SMGA
3 JOBS:
     0 INTRO
     0 WAIT; INCL 0 DEFERRED
     3 EXEC; INCL 2 SESSIONS
     0 SUSP
JOBFENCE= 6; JLIMIT= 2; SLIMIT= 40

JOBNUM  STATE R SCHED-CONDITION  SCHEDULED-INTRO   JOB NAME

#A1     SCHED +                   SMTWRFA  0:10    FYIMAIL8,MGR.SMGA
#A2     SCHED +                   -MTWRF-  0:15    DAILY,MANAGER.SYS
#A3     SCHED +                   S-----A  0:35    DISCLEAN,MANAGER.SYS
#A4     SCHED +                   -MTWRF-  1:30    BACKUP,MANAGER.SYS
#A5     SCHED + WHENEVER BETWEEN(HPDAY,2,6) AND...  DBTREND2,MANAGER.SYS

#A6     SCHED + WHENEVER (HPDATE=1)                REPORT,MANAGER.SYS
#A7     SCHED                FRI  9/16/94 10:00    TESTSCHD,MANAGER.SYS

7 STREAMX SCHEDULED JOBS.

The MPE :SHOWJOB command has been enhanced to display STREAMX scheduling information as well as MPE :SHOWJOB information. When appropriate, STREAMX scheduling information is automatically displayed after the status section of the MPE :SHOWJOB command. In addition, VESOFT has created a new %SHOWJOB userset of @A to represent all STREAMX scheduled jobs.

The SCHED-CONDITION/SCHEDULED-INTRO columns display different information depending upon whether or not the job repeats on specific days, is scheduled to submit on a particular day and time or if the job should be launched when a particular condition occurs. Repeating jobs are indicated by a “+” character after the word “SCHED”. For jobs that are scheduled for a particular day and time, that information is displayed much the same as MPE scheduled jobs. For conditional jobs, as much of the condition that can be displayed on one line will be printed, followed by “...” if the conditional expression is longer.

This is essentially the same format as the %SHOWJOB command, and shows the same information as the %SEC SHOWSCHED command. %SEC SHOWSCHED, however, will display the entire condition under which a job will be submitted, as you can see here:

Last -Days-
                                        #A Job Name Submitted By Job
# SMTWRFA-Time-

                                        6 REPORT,MANAGER.SYS
SMG,MANAGER.SYS J1032
                                        WHENEVER (HPDATE=1)
                                        CHECKEVERY DAY

Since the default is to display both jobs and sessions, simply typing %SHOWJOB alone will display MPE jobs and sessions, MPE scheduled jobs, the MPE status block, and STREAMX scheduled jobs in that order. To display only STREAMX scheduling information, type %SHOWJOB JOB=@A. To suppress STREAMX scheduling information, include ;NOSEC as part of the command.

With the ::SETSCHEDULE command, the job stream can specify its own scheduling parameters, e.g.

!JOB DELSPOOL,MANAGER.SYS; OUTCLASS=,1
::SETSCHEDULE AT=02:00
or
::SETSCHEDULE AT=?When would you like to schedule this job for?

What follows the ::SETSCHEDULE must be the :STREAM command scheduling parameters, exactly as they’d be specified after the “;” in the :STREAM command (e.g. “::SETSCHEDULE AT=02:00;DAY=MONDAY”).

Note that if the user explicitly specifies scheduling parameters when he runs STREAMX (e.g. in the STREAMX UDC), those parameters will be used and any ::SETSCHEDULE command in the file will be ignored. This lets a user override the ::SETSCHEDULE settings in the file.

Also note that if you specify several ::SETSCHEDULE commands in one job stream, the FIRST one will take precedence. It’s important to note that the new parameters can be specified at submission or with the ::SETSCHEDULE. So the STREAM command through STREAMX now supports the following syntax:

:STREAM filename
[;REPEAT= [DAILY|WEEKDAYS|day of week[, ...] ] [;WHENEVER=
condition]
[;WHEN= condition]
[;CHECKEVERY= minutes| DAILY ]
[;MPE SCHED PARMS]

It’s the “condition” that is so flexible in this new format. Check out some of these examples:

• ...stream a job at a scheduled time each day:
:STREAM MAINJOB ;REPEAT=DAILY ;AT=01:00
• ...stream a job several times each day (once each hour):
:STREAM XPMAIL.MAILJOB.SYS;&WHENEVER=
(BETWEEN(HPHOUR,6,17) and (HPMINUTE=0))
• ...stream a job once a month:
:STREAM REPORT.JOB.SYS;WHENEVER=(hpdate=1);
CHECKEVERY=DAILY
• ...stream a job if another job fails (aborts):
:STREAM RECOVER.JOB.SYS;
WHEN=JSCOUNT(‘POST,MGR.PAYROLL’)=0

The hard part really is just in making sure that your syntax and parameters are exactly what you want. Some trickier stuff you might try to do would be when you want to stream job A when job C finishes with no errors, but stream job B if it fails for some reason. All of this can be done, it just takes a little think time.

Photo by Brett Sayles from Pexels


3000 sites miss progressive tactics, then vendors

Puzzle pieces with hands
The word progressive is on the rise again in our vocabulary. The term rose at first in the turn of the 20th Century, when it signified something that envisioned a better future. In some cases, those progressive tactics were aimed at reforms. You might compare reforms to removing old, buggy versions of compilers to replace them with newer, more capable ones. If you go back far enough, people running HP 3000s were replacing FORTRAN 66 with FORTRAN 77, or replacing MPE written in SPL with MPE/iX in Modcal.

Then there's the progressive tactic of devising something new to meet a need where no solution is in place, old or otherwise. Progressives in the first decade of the 20th created the US Food and Drug Administration. Today, 114 years later, the FDA will be gatekeepers to our survival in the US. All COVID-19 vaccines pass through the FDA.

The HP 3000 equivalent of such a progressive tactic might be MPE/iX source code licenses. Nobody knew why the market would need access to the innermost code for the 3000's OS. Then the HP business changed, dropping 3000 future development. The hit on the market meant more internal designs had to become external tools. Independent support companies, as well as some well-schooled utility vendors, earned the right to read trade-secret code for MPE/iX.

While there's very little need today for that sweeping kind of progressive behavior for an HP 3000 customer, the other kind of forward-looking progressive plans have become too short in supply. Running an HP 3000 in a production environment with mission-critical duties isn't an automatic trigger for support anymore. This isn't true in every production case, but the decline of this progressive investment outlook is costing the community, even while it saves some dollars in operating expenses.

One notable loss is that our most stalwart sponsor, Pivital Solutions, is shifting its resources away from the HP 3000 starting in January. Other support companies have already sidetracked or ended their offerings. Pivital held on longer than nearly all of 3000 expert companies. It remains well-stocked with know-how, not to mention one of those rare MPE/iX source licenses. Source solves problems HP did not anticipate. But the growth of its 3000 customers stopped several years ago, president Steve Suraci reports.

"We will continue to honor our obligations to support our remaining base through 2027," he told me this week, "but we can no longer limit ourselves by our 3000 tethers." 

The situation may be different at other companies, but my experience and reports show that eliminating 3000-related budgets is everywhere. "The sites that remain are no longer looking to be progressive," Suraci says. "The vast majority of the remaining customers still use the 3000 for mission-critical functions, but they no longer invest in the platform. They make no pretense when it comes to budgets."

Suraci and his company have been ardent supporters of the 3000's mission ever since the company entered the market almost 30 years ago. At first, there was its work in the GrowthPower ERP market. GrowthPower was an MRP II system with integrated financials that ran exclusively on the HP 3000. There was, at one time, over 1,000 customers for GrowthPower.

About a decade later, Pivital joined the ranks of vendors who sold new HP 3000s as an authorized reseller. This promised to open the doors to sales to even more 3000 use that went beyond MRP. Less than a year after Pivital joined HP's reseller lineup, though, Hewlett-Packard canceled its future development for the 3000.

Pivital was being progressive about its role in the 3000 market. HP didn't reward anyone who stepped out like that, especially so in the case of Pivital. The company was the last one joining the reseller ranks. It didn't rattle Suraci and his team much. They stood their ground on support and remained exclusive to the HP 3000. Many support companies try to maintain a wider range of expertise. Sometimes that means the knowledge base isn't as deep.

It's better for the customer that we specialize, he told me more once. He also reminded the market that its support vendors need to have parts in a depot, rather than shopping for a replacement at the last minute.

"Customers are all too willing to risk their support on a pipe dream that a capable closet technician will show up at a moment's notice, with no service level agreement or parts inventory to support them," Suraci says. There are plenty of parts in the market — but having specifically what a customer needs within a four-hour response time means that the right way to support a site is with a depot.

HP abandoned its 3000 base almost two decades ago, "but we embraced the remnants," he said. "Initially, it was a great match. There was still a progressive base, and we were a willing partner capable of helping them reach their initiatives. "

Over time, he says, things changed. Suraci is unique among support firm presidents. For many years now, he's advised his customers to move onto a computing solution that's supported by a vendor or a marketplace. Something other than an HP 3000 and MPE/iX, to be precise. "For all the right reasons," he says, "the base dwindled as users migrated to more current technologies."

It might have happened more gradually without that vanishing progressive strategy. A site committed to a support budget, with some designs on refreshing architecture where they can, will still be able to rely on the HP 3000 for a good long while. There are seven more full years of MPE/iX use before the 2028 date decision looms. There are even solutions announced or in development to clear that hurdle.

What's not been done, however, is the adoption and practice of supporting every mission-critical 3000. That would include the archival systems holding key data, the kind that regulators demand. Since the progressive tactics have faded, these plans are sending 3000 vendors into new directions. Good vendors like Pivital are curtailing their connections. Supporting your vendor is good for your future.